How should I build a SaaS with a coding agent?
It depends on how much structure the agent inherits. A coding agent moves fastest when the repository already defines authentication, tenancy, billing, jobs, and tests, because it can extend working seams instead of inventing them. Start with one observable outcome, keep changes small and reviewable, and make the agent run the checks that prove the change. If your repository has no foundations, spend the first days establishing them or start from a tested kit. The agent is an accelerator, not a substitute for boundaries or verification.
從可觀察的結果開始
程式設計 agent 可能在你決定好介面該做什麼之前，就產出一個看似可信的介面。先定義一個小的使用者結果：已登入使用者編輯個人資料、儲存、重新整理後看到已儲存的名字。這給實現與評審都提供了具體目標。
在簡報中寫清當前行為、期望行為與重要的失敗場景，並指出承擔該工作的現有模組。新增資料編輯這類請求應該指向認證層，而不是放任 agent 發明第二個使用者儲存。憑證不要出現在提示詞與截圖裡——貼上進去的 apps/web/.env.local 或會話 cookie 會成為對話記錄的一部分。
一份可用的簡報讀起來像這樣：“在賬戶介面中，讓已登入使用者編輯自己的顯示名，並在重新整理後看到它。auth 模組擁有使用者記錄；不要新增表。空名字、或指定了他人記錄的請求，必須被拒絕。用 pnpm test 和窄屏下的一次手動儲存來證明。”五句話，大部分猜測就消失了。
- 使用者可見的結果，措辭要讓你能在執行中的應用裡核對它。
- 今天擁有該行為的檔案或模組——以及應該保持不動的區域。
- 至少一個失敗場景：一次未認證的嘗試、非法輸入，或一次重複的請求。
- 證明它的檢查——一條測試命令、一個夾具，或一次明確的手動走查。
讓倉庫自己說明自己
寫清楚如何執行應用、哪些檢查是確定性的、歸屬在哪裡執行。在 supastack 中，AGENTS.md 記錄工作區邊界，.ai/ 記錄檔案級決策。這些筆記最有價值的時候，是告訴下一位貢獻者——無論是人還是 agent——某個實現為何存在，而不只是哪些檔案變了。agent 設定指南展示了套件如何暴露這些材料，本地設定指南則是 agent 實際會照做的走查。
讓 agent 在改動前先讀相關程式碼。一次小改動通常只需要介面、它的服務端邊界，以及圍繞該邊界的測試。載入整個倉庫，不如理解那幾個決定新行為是否正確的地方：歸屬檢查、schema、許可權。
當功能涉及配置時，點名檔案而不是謄寫內容——“把 key 加到 apps/web/.env.local”能讓金鑰留在磁碟上。同樣的紀律適用於供應商控制台：描述目的地，不要貼上憑證。
以小而可評審的變更推進
當一次變更只有一個負責方和一個可核查的結果時，agent 最可靠。“新增資料編輯”是可評審的；“改進賬戶區域”只會招來沒人要求的重構。如果一個功能能拆成 schema 變更、服務端邊界和一個介面，就把它們作為獨立簡報分別執行，每一步都讓構建保持綠色。
每次讓 agent 動手之前先提交或打檢查點。乾淨的基線能把糟糕的產出變成一刪了之的 diff，而不是一次考古發掘，也給評審留下穩定的前後對比。
一次評審一個完整變更
在改變行為之前先寫驗收檢查。以資料編輯為例，覆蓋一次合法更新與一次未授權嘗試。構建滿足這些用例的最小實現，然後用真實感的文本與窄視口檢查實際互動。
既看結果也看 diff。留意重複的業務邏輯、過寬的異常處理，以及解決現有技術棧本已覆蓋問題的新依賴。執行專案檢查並記錄它們證明瞭什麼。瀏覽器夾具可以驗證表單互動；它無法證明生產資料庫或外部供應商配置正確。
每條命令回答一個不同的問題。pnpm test 用確定性的 fake 與本地介面卡演練行為，pnpm check 覆蓋 lint、型別檢查與格式，pnpm build 暴露只在打包時才出現的整合錯誤。它們合起來是評審的底線——釋出檢查清單覆蓋了仍需在真實環境中證明的部分。
pnpm test
pnpm check
pnpm build當 agent 走錯方向時
結果不對時，忍住別在糟糕的 diff 上疊追問。回滾到檢查點，圍繞被誤解的地方收緊簡報——通常是沒寫出來的約束或缺失的負責方——然後重新執行。每次重試都應該帶著新資訊，而不只是新的緊迫感。
持續失敗通常意味著簡報假定了倉庫裡不存在的上下文。如果 agent 不斷髮明第二個存使用者的地方，修復辦法是在 AGENTS.md 里加一句身份歸誰管，而不是更強硬的語氣。先更新檔案再重試任務——套件把這套工作流放在 agent 指南裡。
關於 agent 工作流的常見問題
每當創始人開始把真實的產品工作交給程式設計 agent，總會出現這幾個問題。
- 程式設計 agent 能獨立構建整個 SaaS 嗎？ —— 它能很快拼出看得見的部分，但持久的部分——授權、計費生命週期、資料隔離——仍然需要簡報、檢查和評審。沒有這個閉環，速度會變成返工。
- 交給 agent 的任務應該多大？ —— 小到你能在幾分鐘內在執行中的應用裡驗證結果：一個使用者可見的結果、一個負責的模組、一條驗收檢查。
- 什麼絕不應該寫進提示詞？ —— 供應商金鑰、會話 cookie、
.env.local的內容和客戶資料。點名檔案讓工具在本地讀，而不是把值複製進聊天記錄。 - agent 寫的程式碼會改變評審方式嗎？ —— 評審從敲程式碼變成讀程式碼：檢查 diff 裡的重複邏輯、過寬的異常處理，以及重複解決技術棧本已覆蓋問題的依賴。
- 哪些測試對 agent 產出最重要？ —— 那些釘住歸屬與失敗行為的測試：未授權請求、非法輸入和重複提交，而不只是演示裡展示的順利路徑。