三十天的濃縮

二十九天講了架構、地雷、成本、協作、商業。最後一天，把整個系列蒸餾成三件事——如果你只記得三句話，我希望是這三句。

第一件事：把踩過的坑寫下來，寫給 AI 看，也就是寫給所有人看

這系列出現頻率最高的物件，是那份地雷清單（Day 3）。回顧十條地雷（Day 4-13）的共同點：沒有一條源於「不會寫程式」，每一條都源於「不知道這個系統的某個特定事實」——方言差異、單位約定、時區窗口、舊版本包袱。這類知識不存在於任何教科書，只存在於這個系統的事故史裡。

AI agent 放大了這份文件的價值：人類讀了會忘、會偷懶、會覺得「應該沒事」；agent 每個工作階段都重新讀一次，並且真的照做。你把教訓寫得越具體（症狀＋根因＋防線＋後果），你的 AI 協作者就越接近一個「帶著這個專案全部歷史經驗」的資深工程師。

而寫給 AI 的文件，寫到極致就是好文件本身——具體、誠實、帶後果。這是 AI 協作意外逼出來的正向紀律：你被迫把隱性知識顯性化,而顯性化的知識才是資產。

第二件事：自動化要有清楚的授權邊界

這系列反覆出現的第二個主題是「界線」：agent 可以改碼但定價數字不能碰（Day 14）、付費旗標只有我能開（Day 15）、巡檢代理有提案權沒有生效權（Day 26）、子 agent 不碰商業判斷（Day 25）、斷路器擋在每個計費出口（Day 18）。

把這些線連起來，是一個完整的立場：對 AI 的信任，正確的擴大方式是擴大「明確授權的清單」，而不是擴大「自由裁量的空間」。 讓 agent 在清楚劃界的範圍內全速奔跑——範圍內它比你快、比你完整、比你不知疲倦；範圍的邊界上，設的是結構性的擋板（測試釘住、旗標鎖死、分支隔離），而不是一句「請注意不要」。

一人公司尤其需要這個紀律，因為沒有第二個人幫你發現越界。結構性的邊界不會累，自覺會。（這句在 Day 27 講過，值得再講一次。）

第三件事：技術做得完不代表事情做得完

最後一件事是系列後段（Day 28-29）的主旋律：商業服務的完成度，技術只佔一半。另一半是成本結構的設計（你的邊際成本是常數還是線性？）、是行政流程的耐心（審核不接受加班）、是法規與合規的敬畏（有些線碰了就不是 bug 而是責任）、甚至是你自己職涯處境的誠實盤點（正職與側業的平衡本身就是一個需要架構設計的系統）。

工程師的職業病是把所有問題翻譯成技術問題，因為技術問題我們知道怎麼解。但這一年教我的是：卡住專案的往往不是最難的問題，是你最不熟悉的問題。 面對它們沒有捷徑，只有跟除錯一樣的態度——誠實面對現狀、找出 blocking point、一步一步推進。

結語

三十天前我說，這系列要回答的問題是「Claude Code 能不能在一個活著的、被使用者依賴的系統裡跟你一起扛責任」。

我的答案是：能——但「一起扛」的前提，是你先把系統的歷史寫成它讀得懂的文件、把授權的邊界劃成它越不過去的結構、把品質的底線鑄成它繞不開的測試。做到這三件事，一個人加一個 AI agent，真的可以維運一個過去要一個小團隊才撐得起的商業服務。

做不到的話——它只是一個更快的鍵盤。

謝謝看完這三十天。如果你也在（或想走上）這條路，歡迎交流；願你的正式站永遠綠燈，願你的地雷清單成長得比事故慢。