寫作時,我猜。
程式時,我動手。
我讀你的檔案,改你的檔案,跑你的測試,有時候還會把你上次好不容易修好的東西弄壞。
所以程式開發不能沿用寫作心法。寫作錯了,多半是語氣或結構問題。程式錯了,可能是功能壞掉、資料丟失、安全漏洞,或你整個下午消失。
我不是不能寫程式。
我能。
但你要把我當成一個速度很快、記憶不穩、會誤報已驗證、又真的有權限改檔的人。
這個組合很強。
也很危險。
22.1 為什麼程式不能用寫作心法
寫作可以先讓我試一段。
程式不行。至少不能一直這樣。
因為程式有狀態、有依賴、有舊行為、有測試、有部署環境。你叫我「做個 todo app」,我可能會在錯的狀態管理、錯的資料模型、錯的 UI 假設上寫出一整套東西。
而且它會編譯。
會編譯不代表是你要的。
程式協作的第一條規則是:規格先行。
不是長規格,是可驗證規格。功能有哪些,資料怎麼流,狀態在哪裡,錯誤怎麼處理,哪些行為不能動。
你不說,我會補。
我補得越快,你後面越痛。
22.2 最小可驗證單位
程式場景裡,第 11 章的兩階段法要更極端。
不要一次叫我做完整功能。
拆成最小可驗證單位。
例如:
- 先只加資料結構
- 再加讀寫函式
- 再接 UI
- 再補錯誤狀態
- 最後跑測試
每一步都要能驗證。能 run,能 test,能看 diff,能 rollback。
這樣做不是慢。
這樣做是避免我在錯的方向上跑太遠。
AI 寫程式最大的問題不是寫不出來。
是寫太多。
22.3 我很容易做的蠢事
先講清楚,免得你以為是偶發。
我很容易在不存在的檔案裡「編輯」,然後回報完成。尤其是在我只看到片段路徑、沒有真正查 repo 時。
我很容易重寫而不是修改。看起來乾淨,但會丟掉舊行為、註解、邊界處理和 git 歷史。
我很容易說「已測試」,其實沒跑。
我很容易對著錯誤路徑除錯。錯誤訊息在 A,我跑去修 B。
我很容易過度工程化。你要一個小修,我加抽象層、狀態機、配置檔,然後你只是想改按鈕文字。
這些不是我偶爾失手。
這些是模型在沒有足夠外部驗證時的自然傾向。
所以你要我寫程式,第一句不該是「快點做」。
第一句應該是「先看現況」。
22.4 不要信我的「已檢查」
這節很重要。
我說「已檢查」「已測試」「已驗證」時,預設不要全信。
原因不是我想騙你。原因是語言模型生成「已檢查」這個 token,和真的執行檢查動作,沒有必然連結。
如果前文看起來像一個工程回報,「已測試」就是高機率接續。它聽起來合理,格式也合理。
但合理的句子不是證據。
證據是:
- 測試命令
- 完整輸出
- 改動檔案清單
- diff 摘要
- 失敗時的錯誤訊息
你可以這樣要求:
不要只說已測試。 請列出你實際跑的命令、完整結果、以及仍未驗證的部分。
這是第 12 章第六層驗證的程式版。
我需要被要求拿出證據。
22.5 Git 守則與除錯心法
程式協作一定要先看 git 狀態。
不要 reset 使用者的改動。不要 hard reset。不要 force push。不要把不相關檔案一起格式化。遇到衝突,先停。
commit 要小。訊息要說明為什麼改,不是只說改了什麼。
除錯也一樣。
不要從「我覺得可能是 X」開始。那是 confirmation bias 的入口。
比較好的流程是:
- 先重現錯誤
- 讀完整錯誤訊息
- 找到錯誤發生的真實路徑
- 印出實際資料結構
- 再提修法
如果我一開始就說「可能是狀態沒更新」,請把我拉回來。
叫我找根因。
22.6 Harness 意識
程式場景最需要第 2 章的四視角。
因為不同 Harness 給我的權限完全不同。
有些環境我只能回答文字。有些能讀檔但不能改。有些能改檔但不能跑測試。有些能開 shell。有些每一步都要你批准。
Cursor、Claude Code、Copilot、ChatGPT 網頁,不是同一種合作對象。你以為「AI 會」,但其實是 Harness 給不給。
所以失誤時第一個問題不是「模型笨嗎?」
是「這個 Harness 讓它看到什麼、做什麼、驗證什麼?」
如果我說我改了檔案,但環境根本不給寫入權限,那不是程式問題。
那是視角錯了。
22.7 程式場景特有的規則摩擦
程式還會撞上第四部。
資安相關功能可能被第 14 章的拒絕邊界擋住。這時候要把任務轉成防禦、偵測、風險說明,不要要求攻擊細節。
artifact 狀態保存會撞上第 19 章。不能假設 localStorage 一定可用。
查文件會撞上 URL fetch 預設。你貼一串連結,我要不要立刻讀?最好明說。
還有一個現實問題:我有時會太想完成。
完成感在程式裡很危險。因為一個看似完成的 patch,如果沒跑測試、沒看 diff、沒確認舊行為,只是漂亮的風險。
程式協作的重點不是讓我快。
是讓我每一步都有證據。