Agent 已經能做出第一版，這門課還要學什麼？
課程簡介｜AI Agent 開發與維運
投影片
Vibe coding 徹底改變生態
「幫我做一個簡易的地震監測系統」——現在對 agent 講一句話， 它就可以做出一個能動的第一版。
所以這堂課不是要教大家怎麼讓 AI 多寫一點程式， 因為現在最便宜的，可能已經是「做出第一版」。 真正昂貴的是：我們知不知道它做了什麼、為什麼這樣做、 結果能不能相信，以及下一次改動時還能不能控制它。
Coding 新範式
以前學 Coding 要從語法開始學，上課大部分時間都在找錯字。 後來 IDE 大幅解決了打字問題，但環境設定還是會勸退很多人。 從打孔卡、終端機到 IDE，學習的時間都花在瑣碎的事情上，而不是邏輯思考。
然後 AI Coding 出現了。2021 年，GitHub Copilot 第一代只能補齊一小段程式； 2024 年 10 月，Claude Computer Use 給 LLM 雙手操控對話外的螢幕； 2025 年 2 月，Claude Code CLI 開始跑迴圈自主寫程式。 現在使用者不用看到程式碼就可以改寫程式，大幅降低門檻。
AI FOMO
AI 變得越來越厲害，新名詞一直出現：Prompt、Context、Harness、Loop、Graph…… 人們開始出現技術焦慮，也就是所謂的 FOMO（fear of missing out）。 不過在研討會上，每個講者提出的新技巧都很類似——這幾乎成為一種必然。
為什麼會如此相似？
由於研究 AI 的人大部分都是軟體工程師， 就會想把自己的工作流程套用到 Agent 上做實驗。 大家面對的是同一個新模型的新特性，加上相似的軟體開發流程—— 所以工程師們在 Agent 上玩出來的 vibe coding 技巧， 大部分是從軟體工程的思維轉化而來。
這就是這門課的出發點：與其追逐每一個新名詞， 不如把底下那套共同的軟體工程思維學起來。
第一部分：Agent 簡介
LLM 是個很會接龍的程式
LLM 是個很會接龍的程式：給他對應的上下文，引導模型接龍出你要的東西。 Prompt／context engineering，就是給他合適的內容。
Agent 小轉變帶來新的突破
過去我們使用 AI 輔助寫程式的時候， 最初需要把程式段落貼給 AI，得到解答後再貼回來執行。 再來 context window 變大後就可以吃整個檔案，IDE 開始預設帶入當前檔案， 所以人就不用去找他在整個檔案的哪個位置。 後來 agent 尋找程式碼片段的能力增強了以後， 連程式碼本身在哪個檔案內都不用管了。
這個技術上雖然沒有很難實現，不過卻有很大的影響： 程式庫對人開始變得抽象，到了不用看到程式碼也可以開發的階段。
第一階段來回奔波的那個人就是你——你就是那個迴圈； 到第三階段，迴圈已經整個搬進了 agent。
Agentic loop
Agent 有了自己探索的能力後，就可以先假設需要的資料在哪， 執行工具獲取後再判斷下一步——這就變成一個可以循環的迴圈。
它可以使用工具，所以不只是回答問題，還可以實際修改系統； 它可以看到執行結果，所以能根據錯誤或測試輸出繼續修正。 但它每一步的判斷都依賴當下取得的 context： 如果背景不完整、工具回傳的訊息不清楚，或前面形成了錯誤假設， 它就可能一路往錯誤方向前進。
所以模型能力固然重要，但真正決定 Agent 能不能可靠工作的，還包括： 它拿到什麼脈絡、可以使用哪些工具、擁有哪些權限、 執行後能看到什麼回饋、工作流程有沒有設計檢查點。
Agent 分工
當工作變得複雜，就會用多個 Agent 分工合作，達到更高的效率。 這個派工的形式，就變成一種 Agent 之間的流程圖。
Agent 怕誤刪，導致程式庫膨脹
由於 Agent 誤刪事件頻傳，後來被調整成保守的做法： 害怕誤刪造成損失，傾向以新增、疊加的方式寫程式， 而不是修改或刪除既有的東西。
造成的結果：功能相似的片段散落各地、已棄用的程式碼沒有被清除， 程式庫快速膨脹。
AI 通靈很強的代價
現在一線模型的通靈能力很強，可以讀得懂字面以下的意思， 就變成可以補齊很多原本沒講的東西。 但是反過來說，很多他猜的東西是大部分的情況， 有時候自己的情況就不是這麼大部分—— 必然一定會有幾個條件不是跟大家一樣，這時候模型就會猜錯、越來越偏。
自己沒有開發經驗的話，也不會知道要給出什麼關鍵資訊。 就像 Andrew Ng 說的：the AI doesn’t know what it doesn’t know。
例如使用者沒有提的話，AI 會給雲端方案；實際上可能是地端更合適。
AI 的視野有限
當程式庫膨脹到塞不下 context window 後，Agent 其實也很難知道所有的事情： 缺少對應的資訊就會做出不準確的判斷，對話壓縮也會慢慢損失訊息。
甚至有些事情 AI 沒有權限、也沒有能力知道所有情況， 就沒有辦法像真的工程師給出準確的建議。
所以 vibe coding 卡住的人，大多是對軟體開發的知識比較模糊， 不知道哪些關鍵的資訊需要提供出來給模型——而不是少了 AI 的技巧或工具。
第二部分：認知模型
認知債累積
如果給 Agent 一直做都沒檢視，黑箱的部分會越來越大。 拿地震監測系統當例子：從測站感測器、資料接收 API、事件判定， 一路到地圖前端、通報服務、告警推播—— 一開始還能理解，後面 Agent 做太多跟不上，實際跟想像會越差越遠。
Agent 幾分鐘內可以修改十幾個檔案，但人未必能同步理解。 技術債是系統越來越難改；認知債是我們越來越不知道它為什麼能動。
認知債也可以欠，但不能欠太多； 欠太多時，專案出問題就不知道怎麼定位，也不知道要讓 agent 往哪裡查， 只能繼續依賴 agent 猜，債就越滾越大。
Agent 奪走了路上的風景
現在 agent 幾乎可以迭代後交出可以使用的程式碼，大幅減少人查找 API 的行為。 這直接減少了人認識整個套件能做的其他功能，會讓新的想法變少； 也會讓交流變得困難——很多運作原理跟設計的取捨，會放在 API 頁面裡面。
「問 agent 就好」比較像是完成一個已知範圍的任務； 如果更偏向探索型的開發，就會需要看到很多自己沒想過的東西—— 問 agent 通常只會問出自己知道的延伸，問不出自己不知道的東西。 這時去逛 API 就是一個很好的吸收方式： 開發者在整理 API 的時候，就是在整理那個領域的相關知識， 很容易可以發現相似的方法去延伸。
程式碼是意圖的產物
寫程式的主要工作是在設計意圖，程式碼只是意圖的產物。 Peter Naur 提到，軟體開發過程中有些思考邏輯， 很難用程式碼或文件完整記錄下來：
- 現實世界與原始碼的對應關係。
- 技術決策當下的背景與原因。
- 原始碼如何適應新的需求。
這些知識存在參與者的腦中，原始碼本身還原不出來—— 所以原始碼沒有想像中有價值。
出處：Peter Naur, “Programming as Theory Building,” Microprocessing and Microprogramming, Vol. 15, No. 5 (1985), pp. 253–261.
沒有人知道所有東西怎麼運作
寫程式本身就是在整理一個很大的流程圖： 起初只能看到很大很模糊的概念，像是前端、後端、資料庫； 想要更具體的時候，就往下把某一塊流程圖打開，把細節找出來觀察與思考。 在那個層級下（像是後端好了），就只會看到這一塊的細節—— 因為人的注意力是有限的，能在腦中思考的範圍就是這麼大。 所以整個軟體開發就很像在抽象與具體中來回遊走。
那這就有個結論：不用知道所有東西就可以開始做， 因為沒有人知道所有東西怎麼運作。
用了 agent 之後，人被迫往上一層思考更大的架構。 一方面不用因為不知道所有細節而擔心； 另一方面細節也不是不用學——當問題發生的時候，我們就是要往下去探索。
理解外部化
人的注意力有限，Agent 的 context 也有限。 關鍵的理解既無法從原始碼還原，也塞不進任何一顆腦袋——所以要外部化： 把腦中的理解，變成可以共同查看、修正、驗證的產物。 文件與工具，本質上是團隊的外部記憶，也是人與 Agent 的共同介面。
對應 Naur 那三條藏在腦中的東西，各有外部化的做法：
| 藏在腦中的理解 | 外部化的產物 |
|---|---|
| 現實世界與原始碼的對應關係 | 架構圖、資料流與任務拆解 |
| 技術決策當下的背景與原因 | 決策紀錄、Git commit 與 diff |
| 原始碼如何適應新的需求 | 規格與驗收條件、測試與 log |
《Beyond Vibe Coding》的講法是：程式設計現在變成在「設計意圖」， 我們實際上產出的東西，就是那些紀錄意圖的東西—— 規格是給人讀的意圖，agents.md 是給 agent 讀的意圖，測試是可執行的意圖。
Agent 帶來的角色轉變
過去寫程式大多都在最基層的角色； 現在 Agent 解放雙手後，人就會被推向更高層做規劃與決策， 去思考真正重要的問題。
而升上去之後會發現： 軟體工程的瓶頸一直都還是在人身上——真正會卡住專案的，是人的決策速度。
第三部分：軟體工程
軟體開發的領域知識
計算機科學大部分有最佳答案：演算法、資料結構、通訊協定、作業系統。 可以背答案與套模板——交給 AI 生成並驗證。
軟體工程則是看情況取捨、多跟人有關：專案管理、開發流程、軟體架構、團隊文化。 不同資源、團隊、時空背景——人做決策。
軟體工程的核心邏輯
從面試題目的方向，可以看出系統設計要具備什麼思維。 現在的技術面試其實不是在看你對於語法熟不熟， 而是在看怎麼解決問題， 還有為什麼選擇這個技術、這個技術的成本、與這個技術有什麼限制：
- 釐清模糊需求：先問清楚範圍與限制再設計。
- 提出設計取得共識：先講高層架構，再往下深入細節。
- 說明瓶頸與取捨：每個決策都要能講出它的代價。
參考：Alex Xu《系統設計面試指南》Ch.3
軟體工程要學什麼
以軟體工程的角度，Andrew Ng 建議可以學習：
- 全端程式設計
- 資料管理
- 系統架構設計
- 可靠性與安全性
- 生產環境的擴展性與維運
目前業界開始偏向不看程式碼
像 Ruby on Rails 的作者 DHH， 現在不逐行審查程式碼，改用自動化測試與工程指標把關品質。 人力往上移：設計架構、定義介面與驗收條件—— 從「寫程式碼」變成「設計品質關卡」。
Vibe Coding vs Agentic Engineering
Vibe coding 是探索式的開發：從想法或感覺出發，下提示、AI 生成、試錯調整。 有些需求還不明確，本來就很難規劃——vibe coding 是很好的探索方式， 很多東西拿在手上玩玩看之後會冒出新想法，探索到一個範圍就了解了實際需求。 所以 vibe coding 是探索需求的鷹架：必須存在的拋棄式物件。 以前軟工也一堆這種鷹架（prototype），做出來就是階段性要被丟掉的。
Agentic engineering 是規格式的開發：需求規格、拆解計畫、代理執行、測試驗證、交付迭代。 等需求探索得差不多，就把鷹架拆掉，把已經探索到的需求抽成規格重寫—— 換成一個可重現、可協作、可規模化的做法。
什麼時候該切換到 Agentic Engineering？
Vibe coding 在需求不明確時是個很好的探索工具， 但有些訊號代表該用更穩健的方式重建：
- 程式本身的狀態：亂到開始臃腫、改不動了。
- 軟體的壽命：如果很短、幾天而已用完即丟，那 vibe 無傷大雅； 但如果是要用好長一段時間，開始追求穩定時就會需要重構，也就會進入軟工領域。
- 責任與依賴：如果這東西只有自己用，那 vibe 沒什麼問題； 但這個東西開始要負責任、要給其他人用、別人的任務開始依賴這個東西的時候， 可靠性的需求提高，就得進入軟工領域。
所以要不要做到軟工，其實本身是個成本與風險之間的取捨： 我們學了也不一定每個專案都要這麼做， 但不學的話，直接拿 vibe 的東西推出去就是不負責任的行為。
第四部分：課程架構
從試錯中學習
學習就是從過程中的摩擦得來：自己要先想過， 然後去嘗試看看跟自己假設對不對，才會學到東西—— 這個就跟機器學習的訓練一樣。 光是把範例複製貼上也能做出東西， 但自己腦中就不會建構出對於這個課題的心智模型。
落到日常就是兩個動作：
- 測試：把對目標的理解寫下來——了解應該做到什麼跟邊界。
- 重構：帶著目的再把問題想一遍。如果只叫 AI 做一次，印象不會太深； 重構本身一定會有個要優化的目的在， 就可以把這個問題的成本跟價值好好分析一遍，就會學到新東西。
《Beyond Vibe Coding》對維護 AI 程式碼的總結也是這兩件事： 持續重構跟測試，而不是回去手寫程式碼。
課程目的
上完課不會馬上變成大神，而是想要在這 16 週讓你可以：
- 了解軟體開發的整個流程。
- 不盲目追求新的 Buzzword。
- 自己發現新的 Agent 使用方法。
課程架構
- 九月開始，每週二 11:00。
- 16 週 × 3 小時，共 48 小時。
- 前 30 分理論、後 30 分實作示範，剩下兩小時實作。
- 請攜帶筆電；推薦使用 Claude Code 與 Codex；歡迎帶問題來討論。
課程模組
- AI Agent 教學：Agentic Engineering 介紹、Skill 建立、Harness 技巧、Agent 基礎資安觀念。
- Agentic 開發與維運：DevOps 與 CI/CD、軟體開發生命週期、Git 版本控制、Docker 容器化、測試驅動開發（TDD）、規格驅動開發（SDD）、可觀測性工程。
- Agentic 舊專案實戰：抽取架構設計意圖、監控外顯表現、重構、除錯與優化、添加新功能。
三個實作
- 實作零：vibe coding 一個簡易地震監測系統——先做出來，用來探索需求。
- 實作一（第一階段）：開發簡易地震監測系統——加入軟體工程，從頭建穩。
- 實作二（第二階段）：接手舊有 AI 地震預警系統——讀懂既有程式，再改造。
課程方向
| 主軸 | 出現節奏 | 內容 |
|---|---|---|
| Agent 原理 | 貫穿全課程 | Context 工程、Prompt 與 Skill、Harness 技巧、Agent 資安 |
| 軟體工程 | 依專案進度出現 | Git、規格、測試、環境、CI、觀測、資安、交付證據 |
| 領域知識 | 地震資料流 | 固定波形、GDMS 資料、PhaseNet picks、關聯定位、事件頁面 |
三條主線穿插在實例當中。
結論
Agent 出現徹底改變了 Coding 的生態，讓人可以思考更重要的問題。 在快速產出的同時，建立驗證機制來確保品質， 並保持對系統架構的認知。
抱持著不滿足於現有方案的心態持續學習。