· 6 分鐘閱讀
Day 9｜Harness AI 怎麼做？先寫 spec，再寫 plan
第九天，我想分享我怎麼用 AI 做出不同功能的網站。
上一篇聊到，我把品味和判斷力放在很前面。到了實際做網站，這件事就變得很具體：AI 建議了一個方案，我為什麼要採用？這個功能要解決什麼問題？做完之後，我準備怎麼用？
這些問題，自己得先想清楚。
AI 提出三個選項，我們很容易接著比較，然後挑一個開始做。但它列出的選項，未必包含最適合自己的做法。自己的使用習慣、真正覺得麻煩的地方，可能根本還沒告訴它。更好的選項，有時候就藏在這些還沒說出口的事情裡。
所以我會先跟 agent 討論，把目的和取捨寫下來，再讓它開始實作。我的順序是：先寫 spec，再寫 plan，review 過後才執行。
第一步：寫 spec
spec 是規格。我會先用它說清楚這次要做什麼，以及為什麼要做。
例如，我說「想做一個像 Notion 那樣的內容管理工具」。Notion 很具體，但還不夠讓 agent 決定要做哪些功能。
我想要的是編輯頁面？整理文章？還是讓 agent 產出的內容有地方可以保存，並且能在畫面上檢視和管理？目的不同，後面的設計就會不同。
假設這次想解決的是：agent 產出內容之後，可以繼續管理它，而我也有頁面能打開來看、修改，再決定要不要發布。
這時，spec 就可以往下寫得更具體。
首先，內容要用 agent 能處理的方式保存。Markdown 可以是討論中的一個選項；給人閱讀的頁面，則可以用 HTML 呈現。接著要討論的是，這兩邊怎麼接起來：我在頁面修改後，agent 下次讀到的是哪一份？它改完之後，我又從哪裡接手？
要不要採用，還是得回到目的和操作習慣。我在意的是整個流程能不能接著用，不能只因為 AI 提出某種格式，就直接把它當成答案。
以這個例子來說，一份 spec 可以先交代：
目的： 集中保存 agent 產出的內容，讓我能在頁面上閱讀、修改和審核。
使用流程： agent 送入草稿，我打開編輯；之後再次交給 agent 修改時，要接著目前的版本處理。
內容管理： 說清楚內容保存在哪裡，以及人工修改和 agent 修改如何銜接。
發布範圍： 草稿、審核和發布分別由誰操作，要符合我原本的習慣。
完成條件： 用一份內容走過保存、閱讀、修改和重新讀取，確認前後接得起來。
這是一個規格的示意，細節仍然要在討論中確認。寫到這個程度，agent 才比較有辦法判斷它提出的功能，究竟有沒有幫上忙。
為什麼 spec 這麼重要
很多時候，我不會一路盯著 agent 做事。
它要自行整理資料、補細節，還要決定先做哪一步。如果目的只留在前面幾句對話裡，後面要檢查它有沒有走偏，就得重新把那些討論翻出來。
寫成 spec 之後，我和 agent 都有同一份依據可以看。當它提出新的做法，我可以問：這符合原本要解決的問題嗎？有沒有改掉已經確認的使用流程？
我說「不能違背 spec」，指的是後面的實作要受這些決定約束。有規格以後，仍然要拿成果回來對照；光是多了一個檔案，不能代替驗收。
內容管理的例子尤其明顯。畫面可以已經做得很好看，但如果我改過的文章，下次又被 agent 用舊稿蓋回去，那整個修改流程就沒有做好。要不要加一個按鈕，和內容能不能正確接續，是不同程度的問題。
這也接回上一篇說的度量衡。spec 把「怎樣才算完成」寫出來，讓我能分辨現在看到的是局部功能，還是已經能實際使用的流程。
如果討論到一半發現原本的規劃不適合，也可以回頭改 spec。重要的是把改動和理由寫清楚，讓後面的計畫跟著更新。否則文件說一套、實際做另一套，之後就不知道該用哪個標準檢查。
第二步：用 writing plan 寫計畫
spec 確認後，我會用 Superpowers 的 writing-plans，把實作計畫展開。
到了這一步，才要具體處理架構怎麼做、SQL 怎麼寫、網站的 JavaScript 要負責哪些互動，以及需要到哪些服務設定權限。
兩份文件的差別，可以用同一個例子看。
spec 寫的是：「agent 再次修改文章時，要接著目前的版本處理。」plan 就要往下拆：怎麼找到目前版本、透過什麼入口讀取、修改後保存在哪裡，以及怎麼確認沒有蓋掉使用者已經改過的內容。
這些才是接下來能逐項執行的工作。
如果 plan 只有「建立後端、建立前端、完成測試」，看起來有順序，實際上很多決定還沒處理。agent 開始動手後，仍然得自己補上那些空白。
我希望 review 計畫時，至少能看懂每一步要完成什麼、前面需要先準備什麼，以及做完要怎麼檢查。需要我開權限或提供設定的地方，也應該先列出來，才知道哪些步驟有前置條件。
不用把每一行程式都提前寫好，但足以影響架構和使用方式的決定，應該在這裡說清楚。
第三步：review 完，交給 agent 跑
計畫寫完，我會先看過，再交給 agent 執行。
review 時，我會把 plan 拿回去對照 spec。這些步驟做完，真的能解決我一開始的問題嗎？有沒有安排了很多功能，卻漏掉最重要的操作？需要我介入的地方，有沒有先講清楚？
方向確認後，在我的工作流裡，我會用 Codex 的 goal 推進需要持續處理的任務。交給 agent 的目標，也要包含成果、工作範圍和驗證方式，讓它有依據判斷接下來還缺什麼。
沿用內容管理工具的例子，任務就不只是一句「把頁面做出來」。還要把 spec 裡的流程走過：內容能不能保存、能不能打開、修改後重新讀到的是不是最新版本。
這樣 agent 回報完成時，我才有東西可以驗收。如果某一步因為缺少權限或設定而停住，也要交代已經完成哪些、還缺哪些，方便接著處理。
我不需要盯著每一個操作，但最後仍然要看實際成果。網站就用操作流程和相應的檢查確認；文章則打開來讀，確認內容和保存位置都對。
一步一步做，是把想法說清楚
對我來說，用 AI 做網站的「一步一步」，包含把自己還沒說清楚的想法，整理到 agent 能執行、我能驗收的程度。
一開始可能只有「我想做一個內容管理工具」。討論過後，要能說出我為什麼需要它、內容怎麼進來、我從哪裡接手，以及做到什麼程度才算可以用。
spec 留下這些決定，plan 再把它們拆成實際工作。等 agent 動手時，就能沿著已經確認的方向補細節，不必讓每個重要選擇都留到寫程式時才決定。
所以當 AI 給我幾個選項，我會先想：我真正要解決的問題，有沒有說完整？自己的習慣和限制，有沒有交代？這些補上之後，才比較能判斷它的建議適不適合，也比較知道要把哪個方向寫進 spec。