共用 API，不等於共用權限

顧客網站與門市 POS 共用需要授權的 API，由 Cloudflare Workers 處理授權、計價與訂單。共用的是服務邏輯，不是讓每個入口都能看見所有資料。前端負責呈現與輸入，重要判斷留在伺服器端，才不必讓網站與門市各寫一套價格計算。

D1 保存訂單等結構化紀錄，R2 保存檔案；紀錄與檔案分開，各自承擔不同責任。這也符合官方對 SQL 資料庫與物件儲存的區分，可參考 Cloudflare 儲存選型文件。

1
2
3

顧客網站 ─┐
          ├→ 授權 API／Workers → D1：業務紀錄
門市 POS ─┘                  → R2：檔案

這張圖只說明責任分工，不包含部署位置、管理入口或實際資料。

先留下交易，再處理同步

門市 POS 的交易先在本機保存，再由背景同步送往服務端。這個順序關注的是：網路暫時不穩時，已完成的操作仍有紀錄可追，而不是讓一次連線失敗直接抹掉現場工作。

但「本機先存」不等於所有功能都能離線，也不代表同步永遠成功。重送、資料衝突與同步失敗仍是需要處理的問題；本機有紀錄，也不能直接視為雲端已確認。這些狀態值得被清楚區分，而不是只顯示一個含糊的成功訊息。

付款與列印，都不能只看畫面

付款狀態以通過驗證的綠界伺服器通知更新，不以顧客瀏覽器跳回網站作為依據。顧客可能關掉分頁，回跳也可能受網路影響；綠界付款結果通知文件 同樣要求驗證通知，並留意重複處理。

列印工作則排入佇列，目的是讓待處理工作不只存在於一次按鈕操作中。佇列不是「一定印得出來」的保證：設備故障與紙張問題仍可能發生，工作送出與實際完成也必須分開理解。

已有架構，與尚未啟用的功能

會員、預約、優惠券與底片流程構成平台的服務脈絡，顧客可從公開網站查看入口與當下可用項目。本文描述的是已確認的架構，不把它包裝成所有情境都驗證完成的保證。

LINE Pay 目前僅有準備工作，尚未啟用，不是已上線的付款方式。 後續完善同步與例外處理，也應視為持續工作，而非完成宣言。這次實作讓我更在意的不是功能清單長度，而是每一步出了問題，事情是否還能被找回、說明與接續。

功能型網站，從下一個動作開始

形象網站回答「你是誰」，功能型網站還要回答「我現在能做什麼」。FepPhoto 的服務脈絡包含會員、預約、優惠券與底片處理；Pixel364 則把菜單、客製選項與點餐連在一起。顧客可從各自的公開網站接觸服務，實際可用項目以網站當下呈現為準。

兩個場景不同，卻讓我看見同一個問題：表單送出不是流程的終點。接下來由誰確認、如何交付、遇到例外怎麼辦，才是網站能否融入日常工作的關鍵。這也是我想繼續研究的方向，而不是先替每間店套上相同模板。

先畫流程，再列功能

如果要替小店規劃網站，我會先把一件常見工作拆開：顧客提出需求、店家接收、確認內容、完成服務。每一步都問三件事：

• 哪些資訊是完成這一步真正需要的？
• 誰有權確認，顧客需要看見什麼狀態？
• 如果操作失敗，能否補救或改由人工接手？

例如，預約送出不一定代表時段已確認，點餐送出也不等於付款完成。先說清楚這些差異，比先增加通知、報表或會員等級更重要。功能的價值應該回到具體情境，而不是只用清單長短衡量。

自動化不是把人全部拿掉

我想探索的自動化，是把重複抄寫、狀態傳遞與固定提醒交給系統，讓人把注意力留給需要判斷的事情。但這是設計方向，不代表兩個專案已經把這些工作全部自動化。

遇到需求變更、付款疑問或設備故障，仍需要有人負責。我會把「誰接手失敗情境」放進規劃，而不是把例外藏起來。資料也應以完成服務所需為範圍；公開分享設計方法，不需要帶出顧客紀錄、交易內容或店內管理細節。

我會如何界定下一步

對我而言，下一階段不是盲目增加功能，而是挑一段流程，確認它的輸入、完成條件與例外，再決定是否值得自動化。合作前也應談清楚功能範圍、後續維護與外部服務依賴，不能把「做得出介面」當成「已經可以承擔所有營運」。

目前這些專案是實作與學習的起點，不是營收提升或效率改善的成效報告。我沒有足夠證據宣稱它們替店家省下多少時間。若要評估價值，未來應先約定觀察方式，再用實際使用回饋檢查。比起先說服別人技術很厲害，我更想把一件小事做得清楚、可靠，而且願意長期維護。

菜單不是一張圖片

把菜單放上網，只解決了看見商品；點餐還需要把商品、可選項目與數量組合成明確內容。客製選項不應只靠自由文字表達，否則顧客以為選好了，店家卻可能收到無法判讀的需求。

我的設計思考是：先讓人選商品，再依商品提供適用選項，最後確認完整內容。並不是每杯飲品都應有相同設定，也不能為了畫面整齊，讓顧客選出無法製作的組合。這是規劃與檢查的準則，不是宣稱所有例外都已處理完成。

入口不同，確認內容也不同

桌邊 QR 的情境是「我正在店裡」，外帶則需要說清楚取餐安排；預約更不能直接等同一張已成立的餐點訂單。公開網站提供這些入口，實際開放項目與服務方式仍以網站當下顯示為準。

1
2

桌邊 QR／外帶入口 → 菜單 → 客製選項 → 確認內容 → 送出點餐
預約入口         → 填寫需求 → 送出預約 → 後續確認

這是顧客操作的簡化示意，不是付款或接單成功的證明。我希望確認畫面能讓人檢查商品、選項與服務方式，而不是只看到總價；送出之後也應明確區分「已提交」與「已確認」，避免讓顧客自行猜測。

前端與資料服務的分工

專案採用 React、Vite 與 TypeScript，搭配 Cloudflare Workers 與 D1。前端負責點餐介面與互動，Workers 承接 API，D1 保存結構化資料。平台機制上，React 前端可透過 Worker 使用服務綁定，而不是直接存取綁定資源；這點可參考 Cloudflare React 與 Vite 官方指南。

這套技術組合不會自動保證訂單正確。選項是否有效、送出失敗如何提示、重複操作如何處理，都需要另外設計與驗證。我更願意把它看成責任分工的起點，而不是用框架名稱代替品質說明。

網站可用，不等於所有整合已上線

實際付款、退款與硬體 POS 整合尚未全部上線，仍屬待完成與驗證的範圍。 不能因為有點餐入口，就宣稱顧客已能完成所有支付與門市作業。

接下來我想優先檢查手機操作、內容確認與失敗提示，再逐步完善外部整合；這些是後續方向，不是既有成效。本文也不宣稱點餐速度或營收已經改善。這個專案讓我體會到，小店系統的難處常常不在新增按鈕，而在讓顧客與店家對同一筆需求有相同理解。

如果只用一句話留下這次經驗，我之前寫的是：很好的回憶，明年日本不見不散。

但除了回憶，我也想把這次活動和一般比賽、個人開發不同的地方整理下來。

FtO 是什麼？先不用想著「要拿第幾名」

Facing the Ocean 連結臺灣、日本與韓國等地的 Civic Tech 社群。2026 首爾活動於 9 月 18 至 20 日在 Haja Center 舉行，主要協作活動在 19、20 日。

它是非競賽式的社群黑客松，沒有以排名或獎金為中心。參與者帶著公共議題、正在進行的專案與自己的經驗，來交流並一起動手。

Civic Tech 可以先理解成「用科技參與公共事務」。重點不一定是某個特別複雜的技術，而是資訊能不能更容易取得、工具能不能降低參與的門檻，以及它是否真的回應了使用者的需要。

加入 rep0rter：先理解已經存在的東西

這次我加入的專案是 rep0rter。相關開發討論涉及內容發布、Threads API，以及多平台流程。

進入一個既有專案，和從零開始做自己的作品不同。自己的專案可以依照熟悉的習慣安排；共同開發則需要先理解現在的結構、原本的需求，以及夥伴對系統的想法。

所以，「開始寫程式」不一定是第一步。先把問題與流程對齊，確認誰正在處理什麼，反而能避免大家各自做出一套互不相容的答案。

這篇是參與紀錄，不把討論過的功能當成全部已完成，也不把團隊成果寫成由我一個人完成。

發布工具背後，其實都是使用者的細節

內容發布看起來可能只是呼叫一次 API，但實際討論會延伸出許多情境：

• 新內容要怎麼發布，舊內容又怎麼處理？
• 重試時如何避免同一份內容重複出現？
• 發送前能不能先看到預覽？
• 如果其中一個平台失敗，使用者要怎麼知道？
• 自動化與人工操作之間，要保留哪些控制？

這些問題也提醒我，API 串接不是「收到成功回應」就結束了。可靠的工具還需要讓人看懂狀態、知道能做什麼，以及遇到問題時有路可以走。

這和我正在整理 BoyceLab 的方向很像：功能存在是一回事，讓人容易理解與使用，是另一件必須認真完成的事。

和不同背景的人一起做事

我在活動中認識了不同國家與背景的參與者。這次交流對我來說，不只是交換名字或社群帳號；一起討論與開發，會讓人看見別人怎麼理解問題，也需要練習說明自己的想法。

同一個需求，不同人可能會先注意不同的部分。有的人從資料出發，有的人關心介面，有的人更了解議題的實際情境。這些差異不一定是阻力，反而是共同專案值得存在的原因。

我想把這種合作方式帶回平常的學習：不急著證明自己知道多少，而是先確認大家正在解決同一個問題。

留下紀錄，也留下下一次合作的可能

FtO 對我而言，不是一張可以列上排名的證明，而是一次進入跨國技術社群的經驗。

回來後整理這篇文章，也是想把「參加過」往前推一步：我加入了什麼、當時討論了哪些問題，以及哪些觀點值得留在之後的作品裡。

很好的回憶，也期待下一次再見。希望到時候不只帶著新的作品，也能帶著這段合作經驗繼續往前。

活動背景：Facing the Ocean · Code for Korea 的首爾活動介紹

本文於 2026 年 10 月回顧整理，個人經驗依既有活動與開發討論紀錄撰寫；FtO 為非競賽活動，本文不宣稱獲獎或獨立完成整個專案。

這段學習最值得留下的，是技術不再只出現在程式編輯器裡：我們需要把 AI、永續議題與英文表達放在同一張桌上，讓不同背景的人都能理解提案。

學習場域改變，問題也會改變

這次見習包含 UC Davis、California State University, Monterey Bay，以及矽谷的學習與探索。課程涵蓋永續發展、AI 工具應用與領導力，讓我從原本比較熟悉的技術視角，接觸更多與生活和社會有關的問題。

「永續」很容易被當成一個口號。但是當它和食物浪費、物品再利用或循環經濟連在一起，問題就具體了：哪些資源正在被浪費？人們為什麼不選擇再利用？我們提出的方法，會不會增加另一種負擔？

這也改變了討論 AI 的方式。不是先問「哪裡可以放 AI」，而是先說清楚原本的困難，再判斷 AI 是否真的能幫忙。

ReValue AI：讓二手物品有機會再次被使用

我們的團隊提案叫做 ReValue AI，把 AI 與物品再利用連在一起。

概念是：協助使用者辨識物品、理解可能的價值，再提供重新使用或轉售的建議。它想處理的不是一個炫技問題，而是人們面對閒置物品時常有的困惑——不知道它還能做什麼，也不知道怎麼開始處理。

我參與的部分包括 AI 與技術流程、風險分析、Responsible AI，以及英文簡報與排練。要把提案說清楚，就不能只把模型名稱或流程圖放上去，還必須說明使用者會經歷什麼，以及每一步需要哪些資訊。

這裡也要區分成果的性質：ReValue AI 是這段見習中整理的團隊概念與成果發表，不代表已經上線營運、完成市場驗證的商業產品。

AI 的限制，也應該是提案的一部分

如果 AI 提供估價或辨識建議，使用者可能會把它當成答案。但物品的狀況、地區、交易市場與圖片品質，都會影響判斷。

因此，一個負責任的提案不能只說「AI 可以幫你估價」，也要想到：

• 建議值不等於保證成交的價格。
• 輸入資訊不足時，應該提醒使用者，而不是假裝很確定。
• 判斷需要保留人工確認的空間。
• 蒐集資料時，必須留意隱私與用途。

這些是提案設計需要面對的問題，不是已經完成的功能宣告。對我而言，把限制說出來，不是在削弱技術，而是在讓它更可信。

用英文合作，不只是把中文換成英文

成果發表的主題是 Learning in California, Leading in Taiwan。

準備英文簡報的過程，包含內容安排、句子的簡化、銜接與團隊排練。這和自己完成一份技術筆記不同：台上的每一段，都必須讓聽眾接得上，也要讓團隊成員知道彼此怎麼銜接。

我也更清楚地看到，「理解技術」與「讓別人理解技術」需要一起練習。把話說得清楚，不代表內容變得不專業；相反地，它要求我先知道自己到底想表達什麼。

回來之後，讓經驗繼續流動

返國後，我也把申請、海外學習與自主學習的經驗整理成分享。對我而言，機會的價值不只在於自己去了哪裡，也在於能不能讓下一個正在找資源的人，更容易知道有哪些可能。

我希望 BoyceLab 同樣扮演這個角色：不是只展示完成的成果，而是把背景、方法與限制寫出來，讓讀者有機會接著思考。

這次加州見習留下的，不只是一段海外經驗，而是一個持續提醒：先理解問題，再選擇技術；做好作品，也要讓人看得懂。

活動背景：Fulbright Taiwan 的加州見習介紹 · 青年百億海外圓夢基金計畫

本文於 2026 年 10 月回顧整理；課程背景參考主辦單位公開資訊，個人參與內容依既有見習與成果發表紀錄整理。

從第 65 屆分區科展的智慧回收系統，到第 66 屆第 6 分區中小學科展特優，以及第 25 屆旺宏科學獎佳作，我想留下的不只是結果。更重要的是：每次整理作品、準備說明與重新檢查方法，都讓我看到自己還能做得更好的地方。

還在不斷精進自己，每天都不一樣。

這也是我最近整理這段經歷時，最想表達的一句話。

第一段：讓 AI 從螢幕走進真實環境

智慧回收系統是我早期將 AI 與硬體串起來的研究。影像辨識只是其中一環，後面還有 Raspberry Pi、感測器、馬達，以及整個回收流程。

如果只看程式畫面，很容易覺得「模型辨識出來了，作品就完成了」。但是把它放進實際裝置後，問題會變得不同：圖片輸入是否穩定？辨識結果如何交給控制程式？裝置遇到錯誤時要如何處理？

這讓我開始理解，模型、程式與硬體要放在同一個流程裡看。其中一段出了問題，使用者看到的就是整個系統沒有正常工作，而不是「這一小段其實很成功」。

第二段：從使用 AI，走向研究 AI 的安全

後來，我把研究方向延伸到 RAG 與文件注入。

先用比較白話的方式說明：RAG 就是讓 AI 回答前，先查閱一份外部資料庫或文件。這個方法很實用，例如讓助理依照公司文件回答問題，而不是只依賴模型記得的內容。

但也因此多了一個問題：如果被查到的文件，混入了不應該被當成指令的文字，AI 會不會跟著它走？

這就是文件注入研究想追問的事情。外部內容應該是「可供參考的資料」，不應該因為出現在檢索結果裡，就取得指揮系統的權限。

研究裡涉及的切片、重疊與檢索參數，看起來像很細的技術設定，但它們其實都在影響同一件事：模型最後會看到哪些內容，以及它如何使用這些內容。

科展讓我練習的不只是上台

作品可以執行，和研究可以被理解，是兩件不同的事。

整理報告時，我必須把問題、方法與觀察分開，不能只把畫面或功能一口氣堆上去。準備說明時，也要練習先交代問題的重要性，再介紹專有名詞。

我現在也把這個要求帶回網站：如果一個頁面看起來很專業，卻讓人不知道可以做什麼，那還不算完成；研究也是一樣，如果只能列出很多技術，卻說不清楚它們在回答什麼問題，就還需要整理。

對我而言，下一步不是把所有事情說得更大，而是把每個結論的範圍、限制與驗證方法說得更清楚。

把研究帶進大學的學習

現在進入中興大學應用數學系，我希望把過去實作的經驗，和數學、資料分析與計算方法連起來。

以前遇到問題時，我常先想「要用什麼工具做」。接下來，我也想更有能力判斷資料、設計比較方式，理解結果背後的條件，而不只是讓程式跑出一個數字。

這條路還沒有走完。科展和競賽是階段性的紀錄，持續提問、修正和公開整理，才是我想長期留下的部分。

延伸閱讀：我的資安學習筆記 · 關於我的學習路線

本文於 2026 年 10 月整理發布；活動成果依既有個人紀錄整理，不把分區成果或代表資格當作全國賽得獎。

這次參加 SITCON，對我來說不只是去聽幾場技術議程而已，更像是一次把自己從日常學習環境中抽離、重新看見資訊領域樣貌的機會。

平常待在屏東，能接觸到的活動、社群與現場交流機會，本來就和北部有明顯落差。很多時候，網路上的文章、影片、論文當然也能學習，但那種「人在現場」的感受其實完全不同。親自走進會場、聽講者分享、看到台下聽眾的反應、感受到整個社群對技術議題的熱情，這些東西不是只靠看轉播就能完全取代的。

所以這次能夠參與 SITCON，我最想先說的，其實是感謝。

特別感謝 SITCON 提供遠道而來的補助，讓像我這樣從屏東出發的學生，也有機會到現場接觸這麼高品質的議程內容。這不只是減輕交通與參與上的負擔而已，更重要的是，它真的讓不同地區的學生有機會站在同一個場域裡學習、思考與交流。對我來說，這份補助不只是資源上的幫助，而是一種很實際的支持：讓我知道即使人在南部，也一樣可以被接住，也一樣有機會靠近這些前沿的技術討論。

也很謝謝主辦方籌備這場活動。從議程安排、主題深度，到整體社群氛圍，都能感受到這不是一場只是把人聚在一起的活動，而是一個真的希望讓大家交流、思辨與成長的技術場域。能夠參與其中，我很珍惜。

而在這次的所有議程中，我最有感的兩場，分別是：

1. 透視 AI 抓內鬼：以注意力防範提示注入
2. 語言模型的認知、認同與對齊

這兩場表面上切入角度不同，一場偏 AI 安全與攻擊防禦，一場偏模型行為、價值塑形與對齊問題；但聽完之後，我反而覺得它們都指向同一件事：

語言模型不是只要會用就好，更重要的是要知道它為什麼會這樣運作。

一、整體參與心得：SITCON 讓我重新感受到「資訊社群」的力量

這次參加 SITCON，我最大的感受之一，是我重新感受到資訊社群的密度與能量。

平常自己學技術時，很容易把注意力放在「我要學哪個工具、我要做哪個專案、我要把哪篇論文看懂」。但到了現場之後，我反而更明確感受到，技術不是只有工具本身，還包含很多更深的東西：

• 有人在思考模型安全怎麼做得更扎實
• 有人在思考語言模型的偏見與對齊問題
• 有人在做系統、做研究、做社群
• 也有人在試著把困難的東西講清楚，讓更多人能進來理解

這種感覺很重要，因為它會提醒我：資訊不是只是在電腦前面寫程式而已，而是一整個持續發展、彼此交流、互相推進的領域。

而且我覺得 SITCON 很好的地方，是它不是只有很表面的「技術新知展示」，而是真的有不少議程在處理本質問題。像這次我最喜歡的兩場，就都不是停留在「這個模型很好用」「這個方法很強」這種層次，而是會進一步追問：

• 模型到底為什麼會被攻擊？
• 模型對世界的理解是怎麼形成的？
• 所謂的對齊，到底是在對齊什麼？
• 模型的立場，是它真的有認同，還是只是表面表現？

這些問題不是那種聽完馬上就能寫成程式的內容，但它們反而是更重要的基礎。因為如果連問題本身都沒有想清楚，那之後做出來的系統，很可能只是能跑，卻不一定真的可靠。

這次參與下來，我也更確定自己喜歡的方向，不只是單純把系統做出來，而是那種會去追問底層原因、會想理解模型行為、會想把安全性與實務場景一起考慮進去的題目。這也是這次 SITCON 對我最大的價值之一。

另外一個讓我印象很深的，是這次活動中的「大地遊戲」。這個設計其實不只是好玩而已，它很有效地讓大家在活動一開始就有機會互動、破冰，讓原本彼此不認識的人可以自然地開始交流。我覺得這點很關鍵，因為很多技術活動的問題是大家都各自聽講，很難真正建立連結，但這個設計讓整體社群感更強。

除此之外，會場外也有很多攤位可以逛，不只是拿贈品（雖然真的拿了不少），更重要的是能直接和不同團隊、社群或公司的人交流。我自己也有趁這個機會去問了一些關於未來方向與就職的問題，某種程度上也幫我更釐清自己之後想走的路。

整體來說，這次 SITCON 對我來說，不只是學到技術內容，更像是讓我更確定「我要成為什麼樣的工程師，以及我要在這個領域做什麼」。

二、議程心得（一）：透視 AI 抓內鬼：以注意力防範提示注入

這一場是我非常有感的一場，因為它談的問題本身就很實際：Prompt Injection 到底要怎麼防？

現在大家在談 AI 應用時，常常會把重點放在模型有多強、功能有多少，但只要系統真的開始接外部資料、接工具、接網頁、接信件，Prompt Injection 這種問題就不是「會不會發生」，而是「什麼時候會出事」。

而這場議程厲害的地方，是它不是只停在外部防禦，而是往模型裡面看。

1. 提示注入的本質，不只是惡意字串，而是讓模型分心

這場最讓我記住的一個觀點，就是：

提示注入的本質，可能是讓模型不再專注於原本應該遵守的系統指令。

這個說法我覺得很強，因為它把問題從「外部輸入長得像不像攻擊」拉到「模型內部到底發生了什麼」。

很多防禦方法其實都像是在外面貼膠帶：加規則、加過濾器、加黑名單、加額外 classifier。這些方法不是沒用，但問題是攻擊一直在變，如果永遠只是補外面，常常就只是追著攻擊跑。

這場議程給我的啟發是：如果注入攻擊真的造成的是注意力偏移，那就應該從模型的注意力機制本身下手。這個視角讓我覺得很新鮮，也很合理。

2. 用注意力找「分心」的頭，這個想法很漂亮

講者提到的方法，核心是先找出那些在攻擊出現時，會明顯對系統指令失去關注的 attention heads，再用這些 heads 的表現去計算 Focus Score。當分數低到某個程度，就代表模型可能已經被帶偏，這時候就拒絕回答或阻擋輸入。

我喜歡這種方法，不是因為它聽起來高級，而是因為它有一種「從現象回到機制」的感覺。

它不是只說「這段文字像攻擊」，而是去問：

• 攻擊進來之後，模型還有沒有在看系統指令？
• 哪些頭本來負責規則相關的關注？
• 它們是不是在攻擊時開始失去功能？

這種做法比單純做字串比對更像是在理解模型，而不是只是把模型當黑盒子。

3. 真正有價值的地方，是講者沒有把方法講成萬能

這場另一個我很喜歡的地方，是它沒有把這種方法包裝成「完美解法」。

講者後面有繼續做很多壓力測試，例如：

• 如果惡意內容藏在長文本中間怎麼辦？
• 如果系統指令和攻擊語言不同怎麼辦？
• 如果模型變大或變小，效果是否穩定？
• 如果輸入越來越長，固定閾值還合理嗎？

而結論也不是那種「方法超強完全能擋」，而是更誠實地指出它的邊界：

• 長文本會讓模型對固定系統指令的關注自然下降
• 小模型在長文本下效果明顯更差
• 跨語言情境仍然可能讓判斷難度上升
• 真實部署時需要考慮動態閾值，而不能只用固定 cutoff

這一段我特別有感，因為這才是真正接近研究與實務的樣子。很多東西不是「有用或沒用」二分法，而是它在什麼條件下有效、又會在什麼條件下失效。

4. 我自己的收穫

這場議程對我的影響，不只是學到一種 prompt injection 防禦方法，而是讓我更確定一件事：

AI 安全不能只停在表面規則，真正有價值的防禦，應該盡可能往模型機制本身靠近。

而且我覺得這種思維不只適用在提示注入上，放到我自己關注的 RAG、文件內容污染、模型被上下文誤導等問題，其實也很有共鳴。因為很多時候，真正值得研究的不是「模型有沒有出錯」，而是「模型是怎麼一步一步被帶到錯的地方去的」。

三、議程心得（二）：語言模型的認知、認同與對齊

如果說第一場是在談模型如何被攻擊，那第二場更像是在談：

模型平常看起來那麼會回答，它到底是真的理解，還是只是被訓練成看起來很像理解？

這場我很喜歡，因為它不是從應用層面切入，而是直接拆解語言模型的行為基礎。整場圍繞三個問題展開：

1. 模型怎麼形成對世界的認知？
2. 訓練資料真的能正確呈現世界嗎？
3. 模型真的有穩定的認同或立場嗎？

我覺得這三題問得非常準，因為現在很多人用模型時，太容易直接把輸出當成理解、把回覆當成立場、把順從當成對齊。

1. 模型的「知道」，和人的知道不是同一件事

這場議程重新梳理了模型在預訓練與後訓練中的角色分工。預訓練讓模型透過大量文字去學習世界中各種統計規律與抽象概念，而後訓練則更多是在調整它怎麼回應人類、怎麼展現出一種「好用」的樣子。

這裡最值得記住的一點是：

模型在預訓練中做的是下一個 token 預測，但在這個過程裡，它會被迫壓縮、抽取、內化世界中的某些規律。

所以它看起來像知道很多事，但這種「知道」和人類從經驗、理解、脈絡中形成的知識，並不相同。

這也讓我反思，平常在和模型互動時，很容易不自覺把它擬人化，覺得它「懂」「認同」「站在某一邊」。但這場提醒我，這些詞都需要更小心地使用。

2. 資料不是世界，而是被偏差、被過濾過的世界

這場另一個我覺得很重要的部分，是對資料偏差的討論。

講者不是只講「資料有偏見」這種很常見的話，而是具體談到兩個層次：

第一個層次，是資料本身的代表性不足。像繁體中文、台灣語境相關的內容，在大型模型訓練資料裡的占比本來就偏低，這會直接影響模型對在地文化、語言使用與概念脈絡的掌握。

第二個層次，是資料清洗流程本身也會加劇問題。當資料集用某些規則去排除不符合標準的內容時，少數族群、非主流語言風格、特殊文化用法，反而更容易被刪掉。

我覺得這件事很重要，因為它不是單純的準確率問題，而是更深的代表性問題。也就是說，模型後來長成什麼樣子，不只是由資料量決定，而是由「哪些東西被留下來，哪些東西被過濾掉」共同決定的。

這對台灣使用者尤其有感。因為很多模型雖然支援中文，但它不一定真的理解台灣脈絡中的中文。這兩者差很多。

3. 模型的「立場」，很可能只是學到某種回應風格

後半段談到「認同」與「對齊」時，我覺得是整場最有後勁的部分。

平常大家很常說某個模型比較保守、比較中立、比較傾向某個價值，但這場議程提醒了一件事：模型表現出來的立場，不一定等於它像人一樣真的形成穩定價值觀。

它更可能是：

• 受訓練資料影響後學到某種回答傾向
• 在特定 prompt 和上下文下抽出某種最適合的說法
• 在不同情境中展現不同的表面立場

換句話說，它表現得像有立場，不代表它真的像人一樣有穩定的信念結構。

我覺得這點很值得反覆想。因為如果我們一開始就把模型當成有穩定人格、有一致價值、有固定認同的主體，那很多 alignment 的討論其實很容易偏掉。

4. 我自己的收穫

這場議程對我最大的提醒，是：

在評估語言模型時，不能只看它回答了什麼，還要追問它為什麼會回答成這樣。

這句話聽起來很簡單，但其實會影響很多事。

像是：

• 模型輸出的偏見，是來自資料分布還是後訓練？
• 模型看起來很中立，是真的中立，還是只是學會迴避？
• 模型表現出某種價值觀，是內在一致，還是被 prompt 拉出來的暫時人格？

這些問題沒有簡單答案，但正因為沒有簡單答案，才更值得研究。

四、總結：這次 SITCON 讓我更想理解模型，而不只是使用模型

回頭看這次 SITCON，我覺得自己最大的收穫，不是哪一個新名詞，也不是哪一篇論文，而是一種看待語言模型的方式被重新整理了。

第一場讓我看到，模型不是只要外面包幾層規則就安全，它的內部機制本身就值得被打開來看。

第二場則讓我意識到，模型看起來會回答問題，不代表它真的像人一樣理解；模型看起來有立場，也不代表它真的像人一樣擁有穩定認同。

而把這兩場放在一起看，我最後得到的一個很清楚的感想是：

語言模型不是一個只要會下 prompt 就能完全掌握的工具，它是一個會被資料塑形、會被攻擊牽動、會被訓練方式改變行為的複雜系統。

這也讓我更確定，之後不管是在做研究、做專題、做應用，自己不該只滿足於「它能不能跑」，而是要更常去追問：

• 它為什麼這樣回答？
• 它在什麼條件下會失效？
• 它表面的表現，背後到底是能力還是偏差？

最後，再次感謝 SITCON 與主辦團隊，也感謝提供遠道補助，讓我能從屏東到現場參與這場活動。對我來說，這不只是一趟聽議程的行程，而是一個讓我更確定自己想往哪裡走的經驗。

如果要用一句話總結這次心得，我會這樣寫：

這次 SITCON 讓我學到的，不只是怎麼使用語言模型，而是怎麼更認真地理解語言模型。

什麼是 Big O (時間複雜度)?

Big O 描述演算法在資料量 n 趨近無限大時的效能趨勢。

🔴 Bubble Sort（氣泡排序）

核心思想：每輪把相鄰的兩個元素互比，如果左邊比較大就交換。這樣最大數字會像泡泡一樣「浮」到最右端，然後一直縮小範圍重複這個動作。

什麼時候用？ 幾乎不用於實戰，但因為邏輯最直覺，是學習演算法的起點。

C++ 競程寫法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

#include <bits/stdc++.h>
using namespace std;

void bubbleSort(vector<int>& arr) {
    int n = arr.size();
    for (int i = 0; i < n - 1; i++) {
        bool swapped = false;
        for (int j = 0; j < n - i - 1; j++) {
            if (arr[j] > arr[j + 1]) {
                swap(arr[j], arr[j + 1]);
                swapped = true;
            }
        }
        if (!swapped) break; // 優化：提早結束
    }
}

int main() {
    vector<int> v = {64, 34, 25, 12, 22, 11, 90};
    bubbleSort(v);
    for (int x : v) cout << x << " ";
}
// Output: 11 12 22 25 34 64 90

🔴 Selection Sort（選擇排序）

核心思想：每一輪從「尚未排序的部分」找出最小值，然後跟最前面的元素交換。每輪確定一個位置正確的元素。

注意：Selection Sort 永遠執行 O(n²) 次比較，無論資料本身是否已排序，這是它的最大缺點。

C++ 競程寫法：

1
2
3
4
5
6
7
8
9
10
11
12
13

#include <bits/stdc++.h>
using namespace std;

void selectionSort(vector<int>& arr) {
    int n = arr.size();
    for (int i = 0; i < n - 1; i++) {
        int minIdx = i;
        for (int j = i + 1; j < n; j++) {
            if (arr[j] < arr[minIdx]) minIdx = j;
        }
        swap(arr[i], arr[minIdx]);
    }
}

🔴 Insertion Sort（插入排序）

核心思想：想像左手拿著已排好的牌，右手每次從右邊抽一張，然後插進左手牌堆的正確位置。

什麼時候用？ 資料已接近排序完成時（nearly sorted），時間複雜度接近 O(n)！在 std::sort 的 IntroSort 實作中，當子陣列縮到小於 16 個元素時，會切換為 Insertion Sort。

C++ 競程寫法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#include <bits/stdc++.h>
using namespace std;

void insertionSort(vector<int>& arr) {
    int n = arr.size();
    for (int i = 1; i < n; i++) {
        int key = arr[i];
        int j = i - 1;
        while (j >= 0 && arr[j] > key) {
            arr[j + 1] = arr[j];
            j--;
        }
        arr[j + 1] = key;
    }
}

🟡 Merge Sort（合併排序）

核心思想：分治法 (Divide and Conquer). 不斷把陣列對半切，直到每個子陣列只剩 1 個元素。然後再一一將兩個有序陣列「合併」成一個有序陣列。

什麼時候用？ 需要穩定排序且時間複雜度穩定在 O(n log n) 的場合，例如處理鏈結串列、外部排序（待排資料超過記憶體大小）。

C++ 競程寫法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

#include <bits/stdc++.h>
using namespace std;

void merge(vector<int>& arr, int l, int m, int r) {
    vector<int> L(arr.begin() + l, arr.begin() + m + 1);
    vector<int> R(arr.begin() + m + 1, arr.begin() + r + 1);
    int i = 0, j = 0, k = l;
    while (i < L.size() && j < R.size()) {
        if (L[i] <= R[j]) arr[k++] = L[i++];
        else arr[k++] = R[j++];
    }
    while (i < L.size()) arr[k++] = L[i++];
    while (j < R.size()) arr[k++] = R[j++];
}

void mergeSort(vector<int>& arr, int l, int r) {
    if (l >= r) return;
    int m = l + (r - l) / 2;
    mergeSort(arr, l, m);
    mergeSort(arr, m + 1, r);
    merge(arr, l, m, r);
}

int main() {
    vector<int> v = {38, 27, 43, 3, 9, 82, 10};
    mergeSort(v, 0, v.size() - 1);
    for (int x : v) cout << x << " ";
}

🟡 Quick Sort（快速排序）

核心思想：挑一個 Pivot（基準點），把所有比 Pivot 小的元素放到左邊，比 Pivot 大的放到右邊。然後遞迴對左右兩側重複這個動作。

什麼時候用？ 這是實際最常用的排序法。std::sort 的底層 (IntroSort) 即是以 Quick Sort 為核心。平均 O(n log n)，且記憶體使用效率高（In-place）。

⚠️ 坑點：如果每次都選最小/最大值當 Pivot，退化成 O(n²)。實務上要用亂數選 Pivot 或三數取中來避免。

C++ 競程寫法（推薦用 std::sort）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

#include <bits/stdc++.h>
using namespace std;

// 競程直接用 std::sort，底層已是 IntroSort (Quick+Heap+Insertion)
int main() {
    vector<int> v = {10, 7, 8, 9, 1, 5};
    sort(v.begin(), v.end()); // 升冪
    sort(v.begin(), v.end(), greater<int>()); // 降冪

    // 自訂排序
    sort(v.begin(), v.end(), [](int a, int b) {
        return a % 3 < b % 3; // 按模 3 餘數升冪
    });
}

// 手刻版本（理解用）
int partition(vector<int>& arr, int low, int high) {
    int pivot = arr[high];
    int i = low - 1;
    for (int j = low; j < high; j++) {
        if (arr[j] < pivot) swap(arr[++i], arr[j]);
    }
    swap(arr[i + 1], arr[high]);
    return i + 1;
}

void quickSort(vector<int>& arr, int low, int high) {
    if (low < high) {
        int pi = partition(arr, low, high);
        quickSort(arr, low, pi - 1);
        quickSort(arr, pi + 1, high);
    }
}

🟡 Heap Sort（堆積排序）

核心思想：利用 Max-Heap（最大堆積） 這種資料結構。先把陣列建成 Max-Heap，然後每次把堆頂（最大值）取出放到末端，再對剩下的部分重新整理成 Heap，重複直到結束。

什麼時候用？ 當你需要 O(n log n) 且 O(1) 空間複雜度的穩定效能（Quick Sort 最差退化，Merge Sort 需要額外空間）。

C++ 競程寫法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

#include <bits/stdc++.h>
using namespace std;

// 競程中 priority_queue 就是一個 Max-Heap
int main() {
    priority_queue<int> maxHeap;
    vector<int> v = {3, 1, 4, 1, 5, 9, 2, 6};
    for (int x : v) maxHeap.push(x);

    vector<int> sorted;
    while (!maxHeap.empty()) {
        sorted.push_back(maxHeap.top());
        maxHeap.pop();
    }
    reverse(sorted.begin(), sorted.end());
    for (int x : sorted) cout << x << " ";
}

// 手刻 Heap Sort
void heapify(vector<int>& arr, int n, int i) {
    int largest = i, l = 2*i+1, r = 2*i+2;
    if (l < n && arr[l] > arr[largest]) largest = l;
    if (r < n && arr[r] > arr[largest]) largest = r;
    if (largest != i) {
        swap(arr[i], arr[largest]);
        heapify(arr, n, largest);
    }
}

void heapSort(vector<int>& arr) {
    int n = arr.size();
    for (int i = n/2-1; i >= 0; i--) heapify(arr, n, i);
    for (int i = n-1; i > 0; i--) {
        swap(arr[0], arr[i]);
        heapify(arr, i, 0);
    }
}

🔵 Counting Sort（計數排序）

核心思想：不靠「比較」來排序！先統計每個數字出現幾次，再依序填回陣列。

限制條件：只適用於整數，且數值範圍 k 不能太大（k = max - min），因為需要建立大小為 k 的計數陣列。

什麼時候用？ 數字範圍明確且較小時（例如成績 0100、字元 0255、APCS 中 N ≤ 10⁶ 且值域為 0~10⁶）可達到 O(n+k) 的速度，比比較式排序更快。

C++ 競程寫法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

#include <bits/stdc++.h>
using namespace std;

void countingSort(vector<int>& arr) {
    if (arr.empty()) return;
    int maxVal = *max_element(arr.begin(), arr.end());
    int minVal = *min_element(arr.begin(), arr.end());
    int range = maxVal - minVal + 1;

    vector<int> count(range, 0);
    for (int x : arr) count[x - minVal]++;

    int idx = 0;
    for (int i = 0; i < range; i++) {
        while (count[i]-- > 0) arr[idx++] = i + minVal;
    }
}

int main() {
    vector<int> v = {4, 2, 2, 8, 3, 3, 1};
    countingSort(v);
    for (int x : v) cout << x << " ";
    // Output: 1 2 2 3 3 4 8
}

結論

💡 競程中 99% 的排序直接用 sort() 就夠了。理解底層邏輯的意義在於：當題目限制特殊時，你才知道挑哪把刀。

🔴 Bubble Sort（氣泡排序）

核心思想：每輪把相鄰的兩個元素互比，如果左邊比較大就交換。這樣最大數字會像泡泡一樣「浮」到最右端，然後一直縮小範圍重複這個動作。

什麼時候用？ 幾乎不用於實戰，但因為邏輯最直覺，是學習演算法的起點。

C++ 競程寫法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

#include <bits/stdc++.h>
using namespace std;

void bubbleSort(vector<int>& arr) {
    int n = arr.size();
    for (int i = 0; i < n - 1; i++) {
        bool swapped = false;
        for (int j = 0; j < n - i - 1; j++) {
            if (arr[j] > arr[j + 1]) {
                swap(arr[j], arr[j + 1]);
                swapped = true;
            }
        }
        if (!swapped) break; // 優化：提早結束
    }
}

int main() {
    vector<int> v = {64, 34, 25, 12, 22, 11, 90};
    bubbleSort(v);
    for (int x : v) cout << x << " ";
}
// Output: 11 12 22 25 34 64 90

🔴 Selection Sort（選擇排序）

核心思想：每一輪從「尚未排序的部分」找出最小值，然後跟最前面的元素交換。每輪確定一個位置正確的元素。

注意：Selection Sort 永遠執行 O(n²) 次比較，無論資料本身是否已排序，這是它的最大缺點。

C++ 競程寫法：

1
2
3
4
5
6
7
8
9
10
11
12
13

#include <bits/stdc++.h>
using namespace std;

void selectionSort(vector<int>& arr) {
    int n = arr.size();
    for (int i = 0; i < n - 1; i++) {
        int minIdx = i;
        for (int j = i + 1; j < n; j++) {
            if (arr[j] < arr[minIdx]) minIdx = j;
        }
        swap(arr[i], arr[minIdx]);
    }
}

🔴 Insertion Sort（插入排序）

核心思想：想像左手拿著已排好的牌，右手每次從右邊抽一張，然後插進左手牌堆的正確位置。

什麼時候用？ 資料已接近排序完成時（nearly sorted），時間複雜度接近 O(n)！在 std::sort 的 IntroSort 實作中，當子陣列縮到小於 16 個元素時，會切換為 Insertion Sort。

C++ 競程寫法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#include <bits/stdc++.h>
using namespace std;

void insertionSort(vector<int>& arr) {
    int n = arr.size();
    for (int i = 1; i < n; i++) {
        int key = arr[i];
        int j = i - 1;
        while (j >= 0 && arr[j] > key) {
            arr[j + 1] = arr[j];
            j--;
        }
        arr[j + 1] = key;
    }
}

🟡 Merge Sort（合併排序）

核心思想：分治法 (Divide and Conquer). 不斷把陣列對半切，直到每個子陣列只剩 1 個元素。然後再一一將兩個有序陣列「合併」成一個有序陣列。

什麼時候用？ 需要穩定排序且時間複雜度穩定在 O(n log n) 的場合，例如處理鏈結串列、外部排序（待排資料超過記憶體大小）。

C++ 競程寫法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

#include <bits/stdc++.h>
using namespace std;

void merge(vector<int>& arr, int l, int m, int r) {
    vector<int> L(arr.begin() + l, arr.begin() + m + 1);
    vector<int> R(arr.begin() + m + 1, arr.begin() + r + 1);
    int i = 0, j = 0, k = l;
    while (i < L.size() && j < R.size()) {
        if (L[i] <= R[j]) arr[k++] = L[i++];
        else arr[k++] = R[j++];
    }
    while (i < L.size()) arr[k++] = L[i++];
    while (j < R.size()) arr[k++] = R[j++];
}

void mergeSort(vector<int>& arr, int l, int r) {
    if (l >= r) return;
    int m = l + (r - l) / 2;
    mergeSort(arr, l, m);
    mergeSort(arr, m + 1, r);
    merge(arr, l, m, r);
}

int main() {
    vector<int> v = {38, 27, 43, 3, 9, 82, 10};
    mergeSort(v, 0, v.size() - 1);
    for (int x : v) cout << x << " ";
}

🟡 Quick Sort（快速排序）

核心思想：挑一個 Pivot（基準點），把所有比 Pivot 小的元素放到左邊，比 Pivot 大的放到右邊。然後遞迴對左右兩側重複這個動作。

什麼時候用？ 這是實際最常用的排序法。std::sort 的底層 (IntroSort) 即是以 Quick Sort 為核心。平均 O(n log n)，且記憶體使用效率高（In-place）。

⚠️ 坑點：如果每次都選最小/最大值當 Pivot，退化成 O(n²)。實務上要用亂數選 Pivot 或三數取中來避免。

C++ 競程寫法（推薦用 std::sort）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

#include <bits/stdc++.h>
using namespace std;

// 競程直接用 std::sort，底層已是 IntroSort (Quick+Heap+Insertion)
int main() {
    vector<int> v = {10, 7, 8, 9, 1, 5};
    sort(v.begin(), v.end()); // 升冪
    sort(v.begin(), v.end(), greater<int>()); // 降冪
    
    // 自訂排序
    sort(v.begin(), v.end(), [](int a, int b) {
        return a % 3 < b % 3; // 按模 3 餘數升冪
    });
}

// 手刻版本（理解用）
int partition(vector<int>& arr, int low, int high) {
    int pivot = arr[high];
    int i = low - 1;
    for (int j = low; j < high; j++) {
        if (arr[j] < pivot) swap(arr[++i], arr[j]);
    }
    swap(arr[i + 1], arr[high]);
    return i + 1;
}

void quickSort(vector<int>& arr, int low, int high) {
    if (low < high) {
        int pi = partition(arr, low, high);
        quickSort(arr, low, pi - 1);
        quickSort(arr, pi + 1, high);
    }
}

🟡 Heap Sort（堆積排序）

核心思想：利用 Max-Heap（最大堆積） 這種資料結構。先把陣列建成 Max-Heap，然後每次把堆頂（最大值）取出放到末端，再對剩下的部分重新整理成 Heap，重複直到結束。

什麼時候用？ 當你需要 O(n log n) 且 O(1) 空間複雜度的穩定效能（Quick Sort 最差退化，Merge Sort 需要額外空間）。

C++ 競程寫法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

#include <bits/stdc++.h>
using namespace std;

// 競程中 priority_queue 就是一個 Max-Heap
int main() {
    priority_queue<int> maxHeap;
    vector<int> v = {3, 1, 4, 1, 5, 9, 2, 6};
    for (int x : v) maxHeap.push(x);

    vector<int> sorted;
    while (!maxHeap.empty()) {
        sorted.push_back(maxHeap.top());
        maxHeap.pop();
    }
    // sorted 是降冪，反轉後得升冪
    reverse(sorted.begin(), sorted.end());
    for (int x : sorted) cout << x << " ";
}

// 手刻 Heap Sort
void heapify(vector<int>& arr, int n, int i) {
    int largest = i, l = 2*i+1, r = 2*i+2;
    if (l < n && arr[l] > arr[largest]) largest = l;
    if (r < n && arr[r] > arr[largest]) largest = r;
    if (largest != i) {
        swap(arr[i], arr[largest]);
        heapify(arr, n, largest);
    }
}

void heapSort(vector<int>& arr) {
    int n = arr.size();
    for (int i = n/2-1; i >= 0; i--) heapify(arr, n, i);
    for (int i = n-1; i > 0; i--) {
        swap(arr[0], arr[i]);
        heapify(arr, i, 0);
    }
}

🔵 Counting Sort（計數排序）

核心思想：不靠「比較」來排序！先統計每個數字出現幾次，再依序填回陣列。

限制條件：只適用於整數，且數值範圍 k 不能太大（k = max - min），因為需要建立大小為 k 的計數陣列。

什麼時候用？ 數字範圍明確且較小時（例如成績 0100、字元 0255、APCS 中 N ≤ 10⁶ 且值域為 0~10⁶）可達到 O(n+k) 的速度，比比較式排序更快。

C++ 競程寫法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

#include <bits/stdc++.h>
using namespace std;

void countingSort(vector<int>& arr) {
    if (arr.empty()) return;
    int maxVal = *max_element(arr.begin(), arr.end());
    int minVal = *min_element(arr.begin(), arr.end());
    int range = maxVal - minVal + 1;
    
    vector<int> count(range, 0);
    for (int x : arr) count[x - minVal]++;
    
    int idx = 0;
    for (int i = 0; i < range; i++) {
        while (count[i]-- > 0) arr[idx++] = i + minVal;
    }
}

int main() {
    vector<int> v = {4, 2, 2, 8, 3, 3, 1};
    countingSort(v);
    for (int x : v) cout << x << " ";
    // Output: 1 2 2 3 3 4 8
}

結論

💡 競程中 99% 的排序直接用 sort() 就夠了。理解底層邏輯的意義在於：當題目限制特殊時，你才知道挑哪把刀。

今天是平安夜。
這篇文章，當作我送給所有正在準備、或即將踏上特殊選才這條路的學弟妹的一份聖誕禮物。

沒有雞湯，沒有過度美化，
只有一個真實走過 115 資工特選的人，把一路上的現實、心態崩潰與轉彎，完整寫下來。

如果你現在也正在等結果、懷疑自己，
希望這篇能讓你知道：你不是唯一一個撐得很辛苦的人。

📊 115特殊選才報名學校與結果 (沒人權了)

• 清大 刷掉
• 交大 刷掉
• 成大 備取
• 中央 刷掉
• 中興 正取
• 暨南 備取(備上放棄)
• 高師 正取(放棄)
• 逢甲 備取(備上放棄)

放榜前的真實心態：其實真的很難撐

老實說，在特殊選才放榜前那段時間，我的心態非常不穩。

不是因為我沒準備，而是「連續被一階刷掉」這件事，本身就很消耗人。
很多學校連二階都沒進，只在系統上看到一句冷冰冰的「未通過」，卻不知道問題到底出在哪裡。

那段時間，我反覆出現這些念頭：

• 是不是我高估了自己？
• 是不是我做的專題其實根本不被看重？
• 是不是走特殊選才，本來就是一個錯誤？

即使理性上知道「資工特選本來就極度競爭」，
但當結果一次又一次出來，要保持冷靜，其實非常困難。

一階篩選帶來的現實感

這次特殊選才，讓我非常清楚地感受到一件事：

資工相關科系的一階門檻，真的非常高。

不論你做過多少專題、寫過多少程式，只要在量化指標上沒有站在前段班——
例如 APCS 成績、資奧相關經歷、或是非常亮眼的全國競賽名次，
很多學校在第一階段就會直接刷掉。

這不代表你不努力，也不代表你沒能力，
而是資工特選的競爭，本來就集中在極少數頂尖背景的人身上。

心態調整：我到底在證明什麼？

在那段每天都在等結果的時間裡，我後來逼自己冷靜下來，問了自己一個問題：

我是想證明自己，還是真的想找一個能繼續累積能力的地方？

想清楚之後，心態反而慢慢穩定下來。
我開始接受「不是每一條路都一定要從資工系開始」，
也開始認真去看課程結構，而不是只盯著系名。

給想走資工特殊選才的一句實話

這是我親身走過後，非常真心的一段建議。

如果你 沒有 APCS 4 級分以上，
也 沒有資奧或非常亮眼的全國競賽背景，
想走資工特殊選才，真的要有非常強的心理準備。

這條路不只競爭激烈，
而是會長時間消耗你的心態與自信。

如果你的條件比較接近學測體制，
乖乖準備學測，未必是比較差的選擇。

📄 三折頁真的大加分

這一點我一定要特別說。

三折頁在二階面試時，真的非常加分。

它可以幫教授在極短時間內：

• 快速理解你的背景
• 記住你這個人
• 面試時更有依據提問

很多教授其實會一邊翻、一邊問，
有準備三折頁，真的差很多。

🎤 面試時，一定要注意的細節

再來是面試當下的「做人基本功」，但很多人會忽略。

• 一定要等教授講完話再回答
• 即使教授講話慢、時間有限，也請體諒
• 記得你面對的是長輩與學者，不是比賽評審

我知道你可能會很緊張、很想把話一次講完，
但禮貌與態度，本身就是評分的一部分。

Discord 群組：非常重要的自我定位工具

如果你未來有打算走特殊選才，
我真的非常推薦一定要進入特殊選才相關的 Discord 群組。

你會看到來自不同學校、不同領域的強者，
很多人真的是所謂的「電神」。

但也正因為如此，你會更清楚知道：

• 自己大概落在哪個區間？
• 要不要 all in？
• 還是該保留退路？

這個自我定位，比盲目投入還重要。
Discord 群組連結

關於 all in 與退路

我一開始，其實是打算 all in 特殊選才。

但隨著一間又一間學校在一階被刷掉，
心態真的會開始動搖。

後來我選擇把心態調整回來，同步準備學測。
但老實說，大概到十一月才全力拉回學測，其實已經非常困難。

如果你要 all in，請非常清楚風險；
如果要保留退路，請越早開始越好。

不要省特殊選才的錢

這件事很現實，但一定要說。

整個特殊選才下來，報名費大約 1～1.5 萬元。
這不是一個小數目。

我很感謝家裡、尤其是媽媽，一直支持我嘗試。
沒有這份支持，其實很可能中途就被迫停下來。

特殊選才，不只是學生一個人的事，
而是整個家庭一起承擔風險。

結語

回頭看這段特殊選才的過程，我不會說它輕鬆，
但我也不後悔。

它讓我很清楚地看見自己的位置，
也讓我學會在不理想的結果裡，重新為自己做選擇。

最後進入 中興大學應用數學系（數據科學與計算組），
對我來說不是退而求其次，
而是一個重新出發的起點。

如果你正在這條路上，
希望你能撐住，
也希望你不要因為一時的結果，否定整個努力的自己。

我之後會發各校有進入面試的心得感想喔!

🎄 平安夜，祝你聖誕快樂。

這篇文章紀錄我在 2025 AIS3 Junior 中的學習歷程，從基礎 Web 題目開始，一路接觸到前端 XSS 與後端常見漏洞（PHP、SQL Injection、SSRF 等）。

這份內容除了當下的解題紀錄，也整理了我對每一類題目的理解與反思，作為自己之後複習 Web Security 與 CTF 的學習筆記。

一、基礎 Web 題目：培養觀察力

GET aHEAD — HTTP Method 的差異

這題讓我第一次明確感受到，HTTP Method 本身就可能是漏洞來源。

我使用 Burp Suite 攔截請求，將原本的 POST 改成 HEAD，結果在回應標頭中直接看到 flag。

1

HEAD /index.php HTTP/1.1

這題讓我學到：
有些伺服器會把敏感資訊放在 header，而 HEAD 請求因為不回傳 body，反而更容易被忽略。

Cookies — 修改 Cookie value

在瀏覽器中開啟 F12 → Application → Cookies，可以直接修改 Cookie 的 value。這題透過不斷嘗試不同數值，最後在特定值時直接顯示 flag。

這提醒我：
只要沒有在後端驗證，Cookie 就永遠不能被信任。

Inspect HTML / Web Inspector

這幾題都圍繞在一個核心概念：

使用者看到的畫面，往往只是實際 HTML 與 DOM 的一小部分。

包含：

• HTML 註解中藏 flag
• DOM 深層節點藏 Base64 編碼字串
• 將 Base64 解碼後取得 flag

也再次驗證了一件事：Web 題目一定要先打開 F12 看一輪。

二、Linux 基礎操作：CTF 的基本功

在 Linux 題目中，大多數考的不是複雜技巧，而是對基本指令的熟悉度，例如：

• ls -la：查看隱藏檔案
• cat：讀取檔案內容
• touch：建立檔案
• mv：移動檔案
• rm：刪除檔案

這些指令看似簡單，但在 CTF 中就是最重要的「肌肉記憶」。

三、前端題目：XSS 攻擊實作

Stored XSS — Note Sharing

當使用者輸入的內容沒有經過過濾就被直接渲染成 HTML，就可能導致 Stored XSS。

透過插入 <script>，確認可以執行 JavaScript 後，再將 cookie 透過 fetch 傳送到自己的 webhook。

這類題目讓我清楚理解：
只要惡意內容會被存起來並再次顯示，就有機會影響其他使用者。

DOM XSS — innerHTML

這題使用 innerHTML 將使用者輸入直接插入 DOM，導致事件屬性（如 onerror）仍可執行。

即使不能直接使用 <script>，仍可以透過圖片錯誤事件來觸發 JavaScript。

javascript: URL 與 <base> 利用

在某些題目中，使用者輸入會被放入按鈕連結或相對路徑中：

• javascript: URL 可在點擊時執行程式碼
• <base> 標籤可以改變整個頁面的相對路徑解析方式

這些技巧讓我理解到：
XSS 不只存在於 <script>，而是存在於所有「可被解譯的位置」。

四、後端漏洞：邏輯錯誤比技巧更重要

PHP 鬆散比較（Loose Comparison）

透過陣列傳參，讓 strcmp 與 md5 發生型別錯誤回傳 null，再搭配鬆散比較 (==) 繞過條件判斷。

這類題目不需要高深技巧，只要理解 PHP 的型別系統就能突破。

檔案上傳與 WAF 繞過

利用：

• 偽造 Content-Type
• 副檔名大小寫差異（.phP）

即可繞過簡單檢查並成功上傳可執行檔案。

LFI、SQL Injection 與 SSRF

後端題目涵蓋：

• 路徑回跳繞過白名單
• include() 導致的 LFI 轉 RCE
• UNION-based SQL Injection
• 利用 open redirect 繞過 SSRF 主機名檢查

這些題目讓我最大的收穫是：
很多漏洞並不是因為少了 WAF，而是因為「邏輯假設錯誤」。

收穫與反思

這次 2025 AIS3 Junior 對我來說，不只是解題，而是一個完整的 Web Security 入門體驗。

我學到的關鍵包括：

• 永遠不要相信使用者輸入
• 前端與後端的每一個假設，都可能成為漏洞
• 比起背 payload，更重要的是理解程式怎麼「想錯了」

這些經驗也讓我更確定，未來想繼續往資安與系統安全方向深入學習。

Apache 是什麼？模組是幹嘛？

Apache 是高度模組化的 Web 伺服器；處理一個 HTTP 請求時，很多模組會共同讀寫 request_rec 的欄位（如 r->filename、r->args）。不同模組對同一欄位的「語意」若不一致，就可能誤判。Orange Tsai 的研究把這些不一致系統化，歸納出三大類 Confusion 攻擊，其中之一就是 Filename Confusion。

Filename Confusion 的核心：

多個模組對 r->filename 的理解不同——有的把它當檔案路徑，有的把它當URL。這種不一致會造成安全問題。

關鍵：URL 編碼 %3F

• 在網址裡 ? 代表「後面是 query string」。
• 如果要在網址中表示字面上的 ?，需要 URL 編碼：? → %3F。
• Apache 在不同處理階段可能把 %3F 解回 ?，這就是漏洞能被利用的時機差。

1. RewriteRule（mod_rewrite）

RewriteRule 是 mod_rewrite 用來改寫 URL的指令。語法：

1

RewriteRule Pattern Substitution [Flags]

• Pattern（樣式）：正則表達式，用來比對目前請求的 URL 路徑。
• Substitution（替換結果）：匹配後要改到哪裡（可為檔案路徑或 URL）。可用 $1、$2 這類反向引用插入 Pattern 抓到的內容。
• Flags（旗標，可選）：放在 [] 內，調整這條規則的行為，例如：

L：命中後停止再處理後續規則（Last）。
QSA：保留原始 query string 並附加到新 URL。
H=…：指定處理器（Handler），例如 H=application/x-httpd-php。

小例子（Pattern / Substitution / Flags）

想把 https://example.com/user/orange 對應到伺服器檔案 /var/www/user/orange/profile.yml：

1
2

RewriteEngine On
RewriteRule "^/user/(.+)$" "/var/www/user/$1/profile.yml"

• Pattern：^/user/(.+)$ 會抓到 /user/ 後面的使用者名稱到 $1。
• Substitution：/var/www/user/$1/profile.yml → 例如 $1=orange 就是 /var/www/user/orange/profile.yml。
• 這裡沒寫 Flags，使用預設行為。

1‑1-1 Path Truncation（路徑截斷）

成因：

mod_rewrite 在套用 RewriteRule 後，會把替換結果當「URL」處理，呼叫 splitout_queryargs() 把 ? 後的部分視為 query 分離。當替換結果其實是檔案路徑時，還是會被「當 URL 來切」，於是產生可控截斷。

1
2
3
4

RewriteEngine On
RewriteRule "^/user/(.+)$" "/var/user/$1/profile.yml"
# 攻擊請求（%2F = /, %3F = ?）
# /user/orange%2Fsecret.yml%3F  → 讀到 /var/user/orange/secret.yml

因為 %3F 在後續階段被視為 ?，/profile.yml 被當作 query 切掉了。

splitout_queryargs() 在幹嘛？

它把替換結果中的 ? 後段剝離到 r->args（query），? 前面留在 r->filename：

1
2
3

r->filename = "/var/user/orange/profile.yml?debug=1"
               └─── 路徑 ───┘ └─ query ─┘
r->args     = "debug=1"   ← 被 splitout_queryargs() 剝出去

1‑1‑2 Mislead RewriteFlag Assignment（誤導旗標設定）

利用點：

先 Pattern 比對 → 套 Flags → 再把結果當 URL 拆 query。

在比對階段使用 %3F（編碼的 ?）讓請求看起來像是 .php，使規則套上不該有的 Flag（例如指定 PHP Handler）。等到拆 query之後，實際要處理的檔案變回 .gif，但 Flag 不會被移除，導致圖片被當作 PHP 來跑。

規則長這樣

1
2

RewriteEngine On
RewriteRule ^(.+\.php)$ $1 [H=application/x-httpd-php]

攻擊步驟

1. 上傳看似普通的圖片 /upload/1.gif，實際內容藏有 PHP
   例如：

   1	<?php echo shell_exec('id'); ?>

2. 送出請求：

   1	/upload/1.gif%3Faaa.php

3. Pattern 比對：%3F 尚未解碼，/upload/1.gif%3Faaa.php 尾端看起來是 .php → 命中 → 套上 H=application/x-httpd-php。

4. 拆 query：%3F 解為 ?，?aaa.php 被分離到 r->args，留下 /upload/1.gif。

5. 實際處理：雖然是 .gif，但已指定 PHP Handler → 由 PHP 執行圖片內的程式碼。

對照表

1-2. ACL（Access Control List）與 <Files> / PHP‑FPM

要先了解以下三個角色:

• mod_proxy：代理模組，負責把請求轉送到別的服務。

mod_proxy_fcgi：把請求用 FastCGI 協定轉給 PHP‑FPM。

• PHP‑FPM：PHP FastCGI Process Manager，Apache 把 .php 請求交給它執行。
• <Files>（ACL）：針對「檔案名稱」設定限制，例如特定檔案需登入才可訪問。

常見把 .php 交給 PHP‑FPM 的做法

1
2
3

<FilesMatch ".+\.ph(?:ar|p|tml)$">
  SetHandler "proxy:unix:/run/php/php8.2-fpm.sock|fcgi://localhost"
</FilesMatch>

意思是：

遇到 .php、.phtml… 就不要由 Apache 直接讀檔，而是交給 mod_proxy_fcgi → PHP‑FPM。

1‑2-1 ACL Bypass（存取控制繞過）

情境：用 <Files> 來保護單一檔案，例如：

1
2
3
4
5
6

<Files "admin.php">
  AuthType Basic
  AuthName "Admin Panel"
  AuthUserFile "/etc/apache2/.htpasswd"
  Require valid-user
</Files>

正常流程（安全）

1. 請求 /admin.php。
2. ACL 檢查：r->filename = admin.php → 命中 <Files "admin.php"> → 要求驗證。
3. 驗證通過後，交給 PHP‑FPM 執行 admin.php。

漏洞流程（繞過）

1. 請求：/admin.php%3Fooo.php（%3F 是 ?）

2. ACL 檢查：此時尚未解碼 → r->filename = admin.php%3Fooo.php，不等於 admin.php → 不要求驗證。

3. SetHandler 命中：仍視為 .php → 交給 mod_proxy_fcgi。

4. mod_proxy_fcgi 轉交：把 r->filename 改寫為：

   1	proxy:fcgi://127.0.0.1:9000/var/www/html/admin.php?ooo.php

5. PHP‑FPM 行為：

• 去掉 proxy:fcgi://… 前綴與主機資訊，只留 /var/www/html/admin.php?ooo.php。
• 找到第一個 ?，截斷為 /var/www/html/admin.php。
• 實際執行 admin.php。

6. 結果：受保護的 admin.php 被直接執行，完全跳過 ACL。

對照表

受影響的常見保護寫法（都可能被 %3F 打穿）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<Files "php-info.php">   
Require ip 127.0.0.1   
</Files>

<Files "adminer.php">    
Deny from all          
</Files>

<Files "xmlrpc.php">     
Deny from all          
</Files>

<Files "cron.php">       
Deny from all          
</Files>

修補辦法

• 升級 Apache 至 2.4.60+：新版本把舊有危險行為改為預設拒絕；請勿開啟 RewriteOptions UnsafeAllow3F（除非完全理解風險）。
• 避免用 <Files> 保護單一 PHP 檔（在 PHP‑FPM 架構下）。改用 <Location> / <LocationMatch>（比對 URL 而非檔名），或把敏感腳本移出 DocumentRoot，只透過應用層載入。
• Rewrite 規則審視：不要讓「使用者可控片段」直接拼到檔案路徑；能用 mod_alias（Alias/Redirect）就避免過度使用 mod_rewrite 做檔案映射。
• 監控與偵測：

• 日誌尋找可疑編碼：%3F、%2F；
• 特別是「非 .php 路徑 + %3F...php」的請求模式；
• 除錯時可暫時開 LogLevel rewrite:trace2 觀察改寫流程（完畢務必關閉）。

誤區／備註

• 不是「PHP Handler 會神奇多做什麼」，而是被錯誤套用到不該由 PHP 處理的檔案上。
• %3F 的解碼與處理發生在不同階段；理解「哪一步解、何時解」是這類漏洞的核心。
• 範例程式碼僅用於安全測試與理解機制，請勿在生產環境或未授權系統操作。

文獻來源:Orange Tsai (Orange Tsai)

GitHub 連結

🧩 系統原理與架構

本系統以 Python Flask 為後端主體，結合 Arduino 控制投幣與硬體訊號，並透過熱感應印表機完成現場列印。流程自動化，並以 ngrok 實現公網穿透，讓手機可即時上傳照片。

主要流程

1. 投幣啟動：使用者投幣 40 元，投幣機將訊號傳給 Arduino，Arduino 透過序列埠（Serial）傳送 coin_ok 訊號給主機。
2. QRCode 產生與列印：主機收到訊號後，產生唯一 Token 與專屬上傳網址，並生成 QRCode 票券（含說明、Logo、簽名等），自動列印並切紙。
3. 照片上傳與模板選擇：使用者掃描 QRCode，進入網頁上傳照片並選擇拍貼模板，支援即時預覽與互動。
4. 列印成品：完成後自動將美編照片傳送至印表機列印，現場立即取件。

🔌 技術整合

• Flask 網站系統：提供照片上傳、模板選擇、即時預覽與互動介面。
• 印表機控制：支援多台印表機（如 Xprinter、EPSON），可自動裁切。
• Arduino 投幣與列印指令：硬體負責投幣偵測、列印流程控制與狀態回饋。
• 多種主題模板 + 圖層疊加處理：支援多款拍貼模板，並可自訂圖層與特效。
• 自動 QRCode 產生與票券設計：每次投幣自動產生專屬 QRCode，票券含說明、簽名、直橫排文字、Logo。
• ngrok 公網穿透：自動啟動 ngrok，讓外部手機可連線上傳照片。
• Token 防重複機制：每張票券唯一 Token，防止重複上傳與列印。
• 多執行緒與序列通訊：背景監控硬體訊號，並確保 Token 持久化與執行緒安全。

🛠️ 系統架構

• 前端：RWD 響應式網頁（HTML/CSS/JavaScript），支援手機掃描 QRCode 操作。
• 後端：Python Flask，負責 API、圖片處理、列印指令下發。
• 硬體：Arduino（投幣、訊號控制）、熱感應印表機、顯示模組。
• 通訊：USB/Serial 連接 Arduino 與印表機，HTTP 通訊前後端，ngrok 公網穿透。

⚡ Arduino 與投幣機連接與偵測原理

• 投幣機：將投幣訊號（透過上拉電阻完成脈衝偵測）連接至 Arduino 數位輸入腳位。
• Arduino 程式：偵測到投幣訊號後，透過 Serial（如 COM7, 9600 baud）傳送 coin_ok 給主機。
• 主機（Flask）：背景執行緒監控 Serial 埠，收到 coin_ok 後自動產生 QRCode 並列印，可回傳狀態訊息給 Arduino。
• 安全防呆：主機會記錄 Token，防止重複上傳、重複列印，異常時自動復原。

連接示意圖

graph TD;    A[投幣機] -- 投幣訊號 --> B("Arduino");    B -- "Serial (coin_ok)" --> C["主機 (Flask)"];    C -- QRCode 產生與列印 --> D[熱感應印表機];    D -- 列印完成 --> C;    C -- 狀態回傳 --> B;    B -- 控制訊號 --> A;

📂 主要檔案結構

1
2
3
4
5
6
7
8
9

.
├── app.py               # Flask 主程式
├── config.py            # 主程式設定
├── static/              # 前端網頁
│   ├── simulate_coin_page.html    # 管理端頁面
│   ├── upload.html       # 上傳照片頁面
├── templates/           # 模板圖層
├── qr_codes/            # QRCode 票券
├── uploads/             # 上傳照片

🚀 特色與未來規劃

• 支援多模板、動態特效與自訂票券頁面
• 可加入雲端備份與下載功能
• 多語系介面
• 優化列印速度與美編演算法
• 增加現場狀態顯示與錯誤自動復原