實作零：vibe coding 一版簡易地震監測系統
投影片
任務情境
老闆今天說要做一個簡單的地震監測系統， 然後也沒說什麼細節，叫你弄一個 demo 出來。
想做成什麼樣子都行——顯示波形、放張地圖、跳警報，隨你。 能動就好，不評分。
兩種開發方式
這門課會經過兩種開發方式，實作零用的是第一種。
Vibe coding 是探索式的開發。有些需求還不明確，本來就很難規劃—— vibe coding 是很好的探索方式， 很多東西拿在手上玩玩看之後會冒出新想法，探索到一個範圍就了解了實際需求。 所以 vibe coding 是探索需求的鷹架：必須存在的拋棄式物件。 以前軟工也一堆這種鷹架（prototype），做出來就是階段性要被丟掉的。
Agentic engineering 是規格式的開發。等需求探索得差不多， 就把鷹架拆掉，把探索到的需求抽成規格， 用軟體工程的方式重新建立穩固的程式： 先寫規格、拆解計畫，再讓 agent 照著執行、用測試驗證。 這是實作一之後要走的路。
什麼時候該切換？
Vibe coding 在需求不明確的時候是很好的探索工具， 但出現這幾個訊號的時候，就代表該切換成穩健的開發方式了：
- 程式本身的狀態：亂到臃腫、改不動了。
- 軟體的壽命：只活幾天、用完即丟，vibe 無傷大雅； 要用好長一段時間、開始追求穩定，就需要重構。
- 責任與依賴：只有自己用，vibe 沒什麼問題； 一旦要給別人用、別人的任務開始依賴它，可靠性需求提高，就得換方式。
三個都還沒發生，繼續 vibe 沒關係。
目標一：可以 vibe coding
- 裝好 agent：Claude Code 或 Codex 擇一即可。
- 辦好 GitHub 帳號，並設定好 git。
- 通過標準：把系統做出來，顯示出網頁介面。
卡住就問 agent，問法可以參考工具索引。
目標二：探索需求
我們現在不知道想要什麼效果——vibe coding 就是很好的探索工具。 做的過程留意一下你跟他講了什麼， 和他最後給你的有多少地方跟想像不一樣：多了什麼？少了什麼？ 那些對不上的地方，就是還沒被講出來的需求。
目標三：觀察認知債
在需求一直疊加後，你腦中的架構想像跟實際的架構會開始對不上。 找個時間讓 agent 調查一下實際的架構， 拿它整理出來的跟你腦中想的比一比，看有什麼不一樣—— 對不上的部分就是課堂上講的認知債。
認知債也可以欠，但不能欠太多； 欠太多時，專案出問題就不知道怎麼定位， 也不知道要讓 agent 往哪裡查。
目標四：觀察修改效率
程式庫膨脹之後，修改會越來越慢： 一開始什麼都改得動，中期開始變慢，到後期幾乎改不動。 留意一下你自己走到哪個階段了。
那具體的原因有辦法找出來嗎？這就是第三週開始要講的東西。
第二週：拿技巧回來玩你的第一版
上完 Agent 技巧之後，回到你的第一版，每個技巧都拿它試一輪：
- 寫一份 agents.md：讓一個全新開的 agent 不用問你，就知道這個專案是什麼、怎麼啟動。寫完開個新對話驗證。
- 做一個 skill：找一件你這兩週重複做的事，讓 agent 把流程整理成 skill，下次直接用。
- 看懂它改了什麼：讓 agent 改一個小東西，改完先看 diff 再決定收不收，然後 commit——訊息寫「為什麼改」。
- 問它為什麼：挑一個它做過的決定，問它是根據什麼判斷的。看看它的理由跟你想的一不一樣。
玩完之後，回頭看目標二到四的觀察，有哪幾個變了？
留著你的第一版
不要刪。之後每一週我們都會回頭看它一眼； 期末再拿它跟你最後做出來的系統比， 你就知道這 16 週學了什麼。