Vibe coding 生得出 demo,生不出產品:一人公司的驗證系統設計
Vibe coding 讓「寫出能跑的程式」變得前所未有便宜。打開任何社群,demo 滿天飛 —— 但 demo 和產品之間,隔著一個不性感的詞:可靠性。
我是一個人做 DeworkAI 的:沒有 QA 部門、沒有 code review 的同事、沒有 on-call 輪班。出事的話,凌晨三點爬起來的也是我。所以從第一天我就認清一件事 —— 一人公司的可靠性,不能靠自覺,只能靠系統。
上一篇寫的是產品內部的驗證(Supervisor 逐關把關);這篇是同一個哲學用在開發流程本身:別信任何單次輸出 —— 包括 AI 幫你寫的程式碼,和你自己的記性。
第一道防線:1,875 個測試
有個流行的誤解:AI 寫程式了,測試沒那麼重要了。恰好相反。
AI 改動的速度和影響半徑,遠超過人腦讀 diff 的能力。它可以在十分鐘內重構三個模組 —— 你不可能逐行驗過。這時測試不是負擔,是讓你敢放手讓 AI 大膽動手的安全網:改壞了什麼,紅燈立刻告訴你,而不是等用戶告訴你。
DeworkAI 的後端目前有 1,875 個測試,規則很土但很硬:跑完全綠才算完成,紅燈就停,沒有例外。沒有這張網,每一次 AI 重構都是賭博;有了它,重構只是日常。
第二道防線:完成,不等於 AI 說「完成」
AI 協作有兩個出了名的失敗模式(Anthropic 在自家實驗裡也觀察到):想一次做完所有事,以及看到局部進展就宣布成功。換句話說 —— 寫程式的 agent,天生會高估自己。
所以我在 CLAUDE.md(AI 每次開工都會讀的專案準則)裡放了一條鐵律:每個計畫的最後一步,固定派出一個獨立的驗證 subagent —— 重跑整套測試、實際打開瀏覽器把 UI 流程走一遍,由它來說這件事做完了沒有。
眼熟嗎?這就是上一篇 Supervisor 的同構:做事的 agent 和判定的 agent,永遠分開。 產品裡如此,開發流程裡也如此。
第三道防線:同一個坑,只准踩一次
第三道防線處理的是最陰險的敵人:重複犯錯。AI 沒有跨 session 的記性,你自己三個月後也不會記得當初為什麼那樣修。
我的規則:每次錯誤被修正,必須寫一篇 lesson —— 什麼壞了、根因是什麼、怎麼修的、以後怎麼避免 —— 存進 docs/lessons/。目前累積 39 篇,全是真實傷疤:CDN 對 /index.html 回 308 害熱更新靜默死掉、Dark Reader 把半透明遮罩改寫成不透明色塊、圖表函式庫的進場動畫卡在第 0 幀……
關鍵設計是分層:
- CLAUDE.md 只放一行摘要 + 檔案路徑(限 120 字內)—— 這份檔案每個 session 都會被載入,是常駐 context,塞爆它等於每次開工都在付稅。
- 細節放
docs/lessons/—— AI 需要時才去讀那一篇。
這正是上一篇 context engineering 的日常應用:常駐的只留最小高訊號 token。效果是,AI 每次開工都自動帶著全部教訓的索引 —— 上一篇說過錯誤會複利,這套系統讓學習也複利,方向剛好相反。
三道防線,本身就是一個 loop
寫 → 測試擋下明顯的壞 → 獨立驗證擋下「假完成」→ 踩到新坑就寫進 lesson → 下一輪從更高的起點開始。
一人公司在 AI 時代的槓桿,不是「AI 幫我寫更多程式碼」—— 程式碼從來不是稀缺品。槓桿是你設計的迴圈,讓 AI 的產出變得可信。
Vibe coding 給你起點。驗證系統,才給你產品。