實作一：開發簡易地震監測系統

從老闆的一句需求開始，用 agent 走完第一次完整迭代：需求、看板、設計、實作、審查、發布。

投影片

今天老闆叫你開發一個類似 earthworm 的地震監測系統：看地震波、地震定位、算規模。

我怎麼知道該怎麼做？

在實作零你已經試過「AI 救救我」：丟一句話讓 agent 做出 V0，也體會過它跟你想像的差多少、卡在什麼地方。接下來這條實作主線要做的，就是把那個憑一句話生出來的東西，變成一個真的能持續開發下去的系統。

我們用敏捷的方式進行：把工作切成一次次迭代，每一圈都從需求走到發布，做完一圈再回頭修正方向。這篇文章就是完整的一圈。

專案目標一句話：做一個簡易的地震監測系統。但每個人對這個系統的想像都不一樣，會有不同的功能與呈現方式。

先把想到的功能列出來：

再列偏品質的需求：

然後整理：歸類成功能需求與非功能需求，再用開發難度和重要程度排序，先湊出一個最小可行的方案。

需求整理好之後放上 Kanban 看板管理。 Todo（backlog）裡隨便什麼都可以放：bug、新功能、邏輯修改。放進來之後做分類和排序，每張卡片最後會拆成一個可以實現的功能。

分析流程是軟體設計的真正產出。把流程圖畫出來—— 經過的節點不一定是軟體，可以是人，也可以是行政流程。可以的話，流程最好是能唸出來的。

「把使用者的需求講成故事、畫成圖」這件事有一套現成的思考框架：領域驅動設計（DDD）與 Domain Storytelling。課堂上不會講得很細——知道有這個框架可以把需求整理成系統的流程圖，卡住的時候可以拿這些關鍵字去問 agent，就夠了。

選技術是具體化的分水嶺。根據手上的資源選擇對應的複雜度：

技術是會隨著時間更新的，所以不用太執著第一次一定要選對。

API 簡單來講就是插頭跟插座：不同區塊之間傳輸的資料格式要固定下來。固定不代表不能變，只是改動成本比較高。介面的目的是把實作細節藏起來——也就是抽象化。

技術固定下來後，就可以根據 API 把功能組合出來。把功能拆成幾個小的開發週期，每一個都是可以測試驗收的目標；用功能之間的相依性決定開發順序，不相依的區塊可以同時開發。

切成功能後就是根據規格開發。兩種開發模式：

檢查一致性：CI/CD 先跑過自動化測試，加上手動測試的結果，比對實作跟規格有沒有一致。再進一步問：

功能確定正確後就可以上線了。

恭喜，你完成了第一次迭代。

上面的每一步——列需求、整理看板、畫流程圖、拆功能、寫測試、審查—— 都可以讓 agent 幫忙做，而且它做得很快。但每一步的判斷：要做哪些功能、選哪個技術、收不收這次的實作，是你的。