重點摘要
- 常聽到「跟 AI 寫程式需要軟工基礎」,但具體是哪些?本文用前一篇 Opus 4.8 Workflow 實測那條真實對話從頭拆,對照 15 條經典軟工紀律。
- 盤點結果:做到 9 條 / 部分做到 1 條 / 沒做 5 條。每條都有對話證據引用,沒做的給可執行 action。
- 15 條按高 leverage 排序前 5 名:驗證紀律、正交分解、真實基準、focused review、文檔作為下個 session 輸入。這 5 條沒守,其他都白搭。
- 結論:跟 AI 寫程式需要的不是「新的軟工」,而是把舊軟工套到 stateless / non-deterministic / 訓練截止 / 高並發 4 個 AI 特性上的對應方法。
為什麼問這題
「跟 AI 寫程式需要軟工基礎」這句話傳得很廣,但講細節的人少。多數人講出來的不是軟工,是 prompt engineering tricks(怎麼下 prompt、怎麼用 chain-of-thought)— 那叫 LLM 使用技巧,不叫軟工。
真正的軟工基礎是從 1970 年代 SWEBOK 累積到今天的工程紀律:specification、verification、separation of concerns、observability 那些。問題是這些紀律最初是針對「人寫 code、人 review、人交接」設計的,套到「AI 寫 code、人 review」會不會失效?哪些反而更重要?
本文不假設,用一條真實對話實證:5/29 我跟 Claude Opus 4.8 跑 Home123 backend 的 109 個 GraphQL resolver authz pattern audit 對照實驗,從頭到尾大約 8 輪對話、~50 分鐘。把這條對話拆解,對照 15 條經典軟工紀律,看真實場景下到底用到了哪些、漏了哪些。
15 條紀律的分類框架
從經典軟工教材(《Code Complete》、《Pragmatic Programmer》、SWEBOK Guide)抽出 15 條跟 AI 協作最相關的紀律,分 4 群:
| 類別 | 條目 | 經典 reference |
|---|---|---|
| 核心驗證 | #1 驗證紀律、#13 根因分析、#7 回顧 | TDD / Postmortem culture / Code Complete §22 |
| 設計分解 | #2 正交分解、#8 規格先於實作、#9 權衡分析、#14 錯誤處理哲學 | Dijkstra SoC / Spec-first / Pragmatic Programmer Ch.4 |
| 過程紀律 | #3 真實基準、#5 focused review、#6 並行執行、#10 預設驗收標準、#12 預算控管 | Performance Engineering / Code Review SOP / Agile |
| 知識持久化 | #4 文檔作為輸入、#11 可重跑、#15 版本控制 | ADR / Reproducible Research / Git workflow |
下面逐條拆。每條格式統一:定義 → 經典出處 → 你做了沒 → 證據或補救 → 對 AI 協作的特別意義。
#1 驗證紀律 (Verification Discipline)
定義:任何宣稱(claim)都要靠可重現的證據才能信。
經典出處:Steve McConnell《Code Complete》§22 The Twelve-Step Programming Process、TDD 的 Red-Green-Refactor 第一步、Cynefin framework 的 probe-sense-respond。
本次對話做了沒:✅ 做了,多次。
對話證據:
「幫我讀書 https://www.anthropic.com/news/claude-opus-4-8」
→ 不接受 AI 憑記憶,要 AI 去 web 抓。「今天已經是5/29了 你的日期有問題」
→ 即時校正環境假設,不讓我繼續用錯日期。「我正在運作 你看一下」
→ 不接受我講的文字總結,要看 ps / pstree / jsonl 真實 OS 訊號。
對 AI 協作的特別意義:AI 的訓練資料有 cutoff(我的是 2026 年 1 月)。你問跟 cutoff 之後的事(Opus 4.8 是 5/28 發佈),我用「記憶」回答就是瞎掰 — 而且會用流暢的口氣瞎掰,不像人類會猶豫。強制 AI 查資料這個動作,等於把 AI 從「自信的 LLM」拉回「會用工具的執行者」。這條 baseline 沒守,後面 14 條全變空談,因為起手第一個 claim 就錯了。
#2 正交分解 (Separation of Concerns)
定義:一個議題只談一個軸線,軸線之間不混。
經典出處:Dijkstra 1974《On the role of scientific thought》、Parnas 1972 information hiding、UNIX philosophy 的 “do one thing well”。
本次對話做了沒:✅ 做了,而且是教科書級。
對話證據:
「首先 看起來除了MODEL 還有 EFFORT
同樣是SONNET 還可以有HIGH XHIGH?
WORKFLOW 我要怎麼去用?」
三個正交軸線(Model / Effort / Workflow)分開問。對照組是新手會問「給我最好的設定」— 等於要 AI 替你在多維空間做加總決策,你拿到答案也不知道為什麼。
對 AI 協作的特別意義:AI 處理 bundled question 會發生兩種失敗:(1) 只回最顯眼那條,其他偷偷漏掉;(2) 強行給一個整合答案,但每個軸線都妥協。你下意識把 3 軸拆開,等於逼 AI 逐個 expose,你才能照自己的 context 做選擇。這對應的軟工原則是「不讓抽象漏掉」(don’t leak the abstraction)的反向應用:你拒絕 AI 把抽象漏掉。
#3 真實基準 (Representative Benchmarks)
定義:評估新工具用真實場景,不用 toy example。
經典出處:John Hennessy / David Patterson《Computer Architecture》§1.8 Fallacies and Pitfalls(benchmark 永遠騙人)、SPEC CPU 為什麼要 update、ML 領域 distribution shift 一整條研究線。
本次對話做了沒:✅ 做了,而且是本次對話最關鍵的一個動作。
對話證據:
「好 你現在用HOME123 專案 做一個測試循環 然後用你的WORKFLOW試試看 記錄下來差異」
不要 toy 不要 hello-world,直接拿 Home123 的 109 個 production resolver。這個動作直接決定了實驗結論的可信度。
對 AI 協作的特別意義:80% 的「新 AI 工具評測」文章用合成 case(leetcode-style problems),結論毫無遷移性。Anthropic 自家 4.8 release notes 用的也是 SWE-bench、Terminal-Bench 這種「合成的真實」 — 不是任何一家公司的 production codebase。你直接拿 109 個 real resolver 來測,workflow 暴露出來的問題(主 orchestrator 抓到 synthesis agent 算錯 83 vs 109)在合成 case 上看不到,因為合成 case 沒那麼大、catch 不到 emergent behavior。這個動作的工程價值比你的 prompt 內容更高。
#4 文檔作為下個 Session 輸入 (Documentation as Next-Session Input)
定義:寫文件不是給未來的人看,是給未來的 stateless agent 看,作為下次 conversation 的可讀輸入。
經典出處:Architecture Decision Records (ADR, Michael Nygard 2011)、SREbook 的 runbook 文化、Reproducible Research 運動(Donald Knuth literate programming 的延伸)。
本次對話做了沒:✅ 做了,而且是主動做。
對話證據:
「Ab然後我想請你發一篇文章到wordpress上詳細比對這一次的經驗跟數據還有該怎麼啟用的prompt」
同時要求三份產出:(A) brain/dynamic-workflows.md(下個 conversation 我會自動讀)、(B) 更新 brain/adaptive-agent-team-staffing.md(舊文件補新知識)、(WordPress 文章 —對人類讀者跟搜尋引擎)。
對 AI 協作的特別意義:你跟人類同事的會議結論寫成 wiki/Notion,下次他翻過。跟 AI 寫 code 的對話結論寫成 brain file,下次 conversation 的 AI 把它當 first-class context 讀 — 等於把這次 conversation 的腦容量無損傳給下次。一般軟工人甚至沒聽過這個用法(「文件是給 AI 讀的?」),但它是 LLM 時代的 ADR + retrospective 文化合體。沒這層,你每次跟新 conversation 都得從零教一遍,等於每次都 onboarding。
#5 Focused Review (一次只 review 一條軸線)
定義:給 code review 的 feedback 一次只挑一條軸線改,不混雜其他要求。
經典出處:Google Engineering Practices《Code Review Developer Guide》、《The Art of Readable Code》Ch.15、Andy Hunt《Pragmatic Thinking and Learning》Ch.9。
本次對話做了沒:✅ 做了,而且 6 個字精準命中。
對話證據:
「注意好讀性跟比較方式」
6 個字,2 條軸線,沒夾雜其他要求(沒同時挑錯字、補內容、改標題)。我回去重做的時候不需要 disambiguate「我到底該優先處理哪一條」。新手 reviewer 會給 30 條 mixed feedback,作者改完反而亂七八糟。
對 AI 協作的特別意義:AI 在 mixed feedback 下會做兩件事:(1) 試圖一次解決所有,結果每條都打折;(2) 自選優先序,但你看不到它怎麼選的。你的 focused feedback 等於把「review reviewer」這層 meta-loop 去掉。對 token 成本也直接有差 — AI 不用先花 token 解析「Tom 到底想我先處理哪條」,直接動工。
#6 並行/異步執行 (Async Parallel Execution)
定義:能並行的工作不要序列化等待,結果到再收。
經典出處:Concurrent programming 整個學門、Amdahl’s law、async/await 在現代語言的普及、Toyota production system 的並行工序設計。
本次對話做了沒:✅ 做了。
對話證據:
「我正在運作 你看一下」
你開另一個 terminal 跑 workflow,沒等我講完就行動。我這邊主 session 同時讀你的 process tree + session jsonl 做即時觀察。兩條軌道平行,中間用 jsonl 落地通訊。
對 AI 協作的特別意義:跟 AI 對話有個隱形成本叫 cache miss penalty。Claude 的 prompt cache 5 分鐘 TTL,超過就要從零重讀整個 conversation。如果你序列化等(我講完→你看→你跑→等結果→回我),很容易 5 分鐘外。並行化 + 中間用 file system / jsonl 落地通訊,等於把 cache 維持在熱狀態。傳統軟工這條對應的是「不要 block 在 IO 等待」,AI 場景下是「不要 block 在對話等待」。
#7 回顧 (Retrospective)
定義:任務完成後不直接進下一個,先回看「what went well / what didn’t」。
經典出處:Agile retrospective(Scrum 每個 sprint 末必做)、Norm Kerth《Project Retrospectives》、Etsy/Google 的 blameless postmortem 文化。
本次對話做了沒:✅ 做了,而且是 meta 級 — 你問本篇這題就是 retrospective。
對話證據:
「還有 很多人說跟ai寫作需要很多的軟工基礎，不像請你評估一下所謂的軟工基礎在我們所有的循環裡面，我無形中有用到哪一些…因為有一些是我打中很關鍵的點，而你不知道那些是不是軟工基礎」
這句話本身是回顧:你不滿足於「拿到結果就走」,還要拆解過程、識別 pattern、產生可遷移知識。
對 AI 協作的特別意義:AI 不會主動 retrospect — 我跑完就等下一個 prompt,沒人觸發我不會自己回頭看「剛剛這條對話我做對了什麼」。retrospective 必須由你發起。但 retrospective 的產出對 AI 特別有價值:它是 #4 文檔作為輸入的最佳 raw material — 直接把回顧結論寫成 brain file,下次 conversation 直接用。傳統 retrospective 是「同個團隊下個 sprint 用」,AI 場景是「同個你下個 conversation 用」。
#8 規格先於實作 (Spec-First / Specification before Implementation)
定義:動手寫 code 之前先把「要做什麼」「驗收標準」寫死。
經典出處:Leslie Lamport《Specifying Systems》、TDD「先寫測試」也是這條的變形、Design by Contract (Bertrand Meyer)、SDD(Spec-Driven Development)的學派。
本次對話做了沒:✅ 做了,而且是顯式的 4 維度規格。
對話證據:
「記錄下來差異 怎麼啟動 有優化那些地方 要做什麼東西 必要是什麼」
4 個維度寫死:(1) 啟動方式、(2) 優化點、(3) 要做的東西、(4) 必要條件。我後續的 brain file 跟 WordPress 文章兩份產出,結構直接照這 4 維度生。
對 AI 協作的特別意義:沒給 spec 的 AI 會「自由發揮」,結果是形式上看起來有結構,實際結構是 AI 替你做的選擇,你不一定買單。你給 4 維度等於把結構決定權拿回來,AI 只負責填內容。這條對應的傳統軟工是 PRD/RFC,AI 場景是「在 prompt 裡內嵌驗收 schema」。
#9 權衡分析 (Trade-off Analysis)
定義:任何方案都有 cost 跟 benefit,要顯式列出再比較。
經典出處:Software Architecture 教材必有的 ATAM (Architecture Tradeoff Analysis Method)、Jeff Bezos 的「two-way door / one-way door decisions」、《Pragmatic Programmer》Ch.4「Be a Catalyst for Change」的反向。
本次對話做了沒:✅ 做了,而且是顯式追問。
對話證據:本系列你連續問了三個 trade-off 問題:
「差異你可以跑跑看」(empirical 比較 cost)
「我想知道Workflow那一個，他現在到底對我的意義是什麼？我看不太出來」(質疑單一方向的 benefit)
「注意好讀性跟比較方式」(cost = 讀者認知負擔 vs benefit = 完整性)
對 AI 協作的特別意義:AI 對「該不該做某件事」的默認是 yes — 因為訓練資料裡的「Yes, you should」遠多於「No, don’t」。你「我看不太出來意義」這句逼我從 advocacy 模式切到 honest assessment 模式,實際結論變成「不存它,寫 reference 進 brain 就好」。這條對應的傳統軟工是 design review 裡「這個複雜度真的需要嗎?」的提問。
#10 預設驗收標準 (Acceptance Criteria Upfront)
定義:任務開始前先寫死「做到什麼程度算 done」。
經典出處:Agile user story 的 INVEST criteria、Behavior-Driven Development (BDD) 的 Given-When-Then、Definition of Done 是 Scrum 必備產物。
本次對話做了沒:🟡 部分做到。
分析:你 #8 給了 4 維度規格,算是 partial acceptance criteria。但缺了「品質門檻」:
- workflow 跑出來的 report 要達到什麼分類正確率才算可信?
- baseline 跟 workflow 的差異要大到多少才算「值得換 workflow」?
- 對話拆解後若 15 條都做到,實質工程效率提升多少才算夠?
結果就是 — workflow 抓到 12 個 hand-roll,我們默認接受這個數字,沒去 sample 5 個函式人工驗證。如果 workflow 系統性把某類 hybrid 全錯標,我們不會發現。
該怎麼補:任務開始前加一句「驗收標準」段落。例如本次該寫:
驗收標準:
1. 兩邊跑完後,我會手動 sample 5 個 USES_PRELUDE 跟 3 個 HAND_ROLLED 對證據
2. 如果 baseline 跟 workflow 在這 8 個樣本上有 2 個以上分歧,需逐個澄清
3. 完整 109 函式都要有 row,缺一個視為失敗對 AI 協作的特別意義:AI 沒驗收標準會「看起來完成」(plausible-looking output),但內部可能 systematically 錯。傳統軟工裡 acceptance test 是另一個人寫的,AI 場景下你得自己寫,因為 AI 不會主動跟自己對抗。本次沒守這條的代價:我們得花一篇文章解釋「為什麼信任 workflow 的結果」,而本來只需要 sample-test。
#11 可重跑 / Idempotency (Reproducible Execution)
定義:任何過程要可從頭重來,輸入相同則輸出相同(在合理隨機範圍內)。
經典出處:Make / build system 整個學門、Donald Knuth literate programming、Reproducible Research 運動、Docker / IaC 的根本動機。
本次對話做了沒:❌ 沒做。最具體的證據是你沒按 s 把 workflow script 存下來。
分析:本次跑了 11 個 Haiku 4.5 平行 audit,產生 146 行 JavaScript orchestration script,結果只存在 session 暫存目錄。如果這次的審計結論被人質疑(例如「12 個 hand_roll 是真的還是 AI 瞎標」),你要重跑驗證沒辦法保證跑出同一份結果 — 因為:
- 下次跑 Claude 會重新生 script,chunk 切法可能不同
- Haiku 4.5 即使 temperature 0 也有非 deterministic 因素(MoE routing 隨機)
- Cache hit 率不同 → 提示空間不同 → 細節結論不同
該怎麼補:三層防護(從便宜到昂貴):
- 最低: 把 script 從 session 暫存目錄 cp 出來歸檔到 brain 或 repo
- 中等: 把 script 真的存成
~/.claude/workflows/<name>.jsslash command,雖然本案大概不重跑,但其他 audit 可以 fork - 高保證: 把 audit 結論 + 109 函式分類存成 JSON / CSV,用 schema 驗證,以後重跑只需 diff JSON 不需要重看 markdown
對 AI 協作的特別意義:AI 的輸出有內建非 determinism(temperature、MoE、context order),這跟傳統 reproducibility 假設(同 input → 同 output)直接衝突。AI 場景的可重跑不能依賴「程式邏輯一樣」,要依賴「中間結果落地」 + 「結果用結構化格式儲存」 + 「下游 verifier 用同 schema 驗」。傳統軟工這條是「build 可重現」,AI 場景是「結論可驗證」。
#12 預算控管 (Cost / Budget Cap)
定義:任何運算工作開始前先設天花板,超過自動停。
經典出處:Cloud computing 的 budget alerts、Kubernetes resource limits、Hadoop / Spark 的 timeout、Stripe 的「circuit breaker」pattern、SREbook §12 effective troubleshooting 的 budget 章節。
本次對話做了沒:❌ 沒做。
分析:我們跑 workflow 的時候沒設 token budget 或 wall-time cap。實際跑了 11 個 agent、~$6.10 estimated cost、132 秒 wall-time。如果 Claude 寫的 script bug 了 — 例如把 chunk 切成 100 個,可能跑出 100 個 agent、$60 cost、20 分鐘 wall-time。沒任何機制自動阻擋。
該怎麼補:
- prompt 裡明寫上限 — 例如「最多派 12 個 agent,單一 agent 最多跑 60 秒」
- 用
--effort medium而不是high開始,確認 quality 夠才升 effort - 跑前先讓 Claude 估算 token cost 跟 agent 數,你 approve 才放跑(workflow 內建這層 approval prompt,但你按 [3] View raw script 之前沒人問你 budget)
- 對自己設「單條對話 spend 上限」(例如 $10),透過 Claude Code admin page 或 API budget API 強制
對 AI 協作的特別意義:傳統軟工 budget 是「機器跑爛要錢」,AI 場景下 budget 還包含「AI 寫錯 script 跑很久才發現」的 fail-loud delay。Anthropic 自己在他們 multi-agent research system 的 paper 也警告:multi-agent 用 token 是 single-agent 的 3-10×,Research system 是 ~15×。沒 budget cap 等於放任這個倍率,3am 一覺起來收到 $200 帳單是真實風險。
#13 根因分析 (Root Cause Analysis)
定義:遇到問題不停在表象,挖到「為什麼會發生」的最底層。
經典出處:Toyota 的「Five Whys」、Apollo 13 事故報告、Etsy / Google 的 blameless postmortem template、《The Field Guide to Understanding Human Error》。
本次對話做了沒:🟡 部分做到,但是 AI 替你做的。
分析:本次 audit 最有價值的發現是「guard role 被 AuthzDecision.IsCommunityWide 排除,迫使 5 個 resolver 各自重 probe 一段相同 SQL」。這是根因分析的成果 — 不停在「這幾個 resolver 沒用 prelude」,而是挖到「為什麼它們不能用」。
但這是 workflow 的 synthesis agent 替你做的,不是你做的。Baseline 模式下 1 個 agent 沒做出這層,你也沒主動追問「為什麼會有 5 個重複」。如果這次跑 baseline 你會 miss 這個 root cause。
該怎麼補:不能只靠 AI 替你做。可以加紀律 — 拿到分類結果後,主動問:
看到 12 個 HAND_ROLLED,我們 ladder 5 個 why:
- 為什麼這 12 個沒用 prelude? → 各自原因
- 為什麼它們有共同原因? → 找 pattern
- 為什麼這個 pattern 沒被早發現? → 流程 gap
- 為什麼流程沒抓到? → tooling gap
- 為什麼 tooling 沒設計這層? → 設計時的假設對 AI 協作的特別意義:AI 默認停在第一層觀察(「這幾個沒用 prelude」)。要挖根因得明確要求(「列出 root cause」)或結構性逼它(workflow 的獨立 synthesis pass 就是設計來做這個)。傳統軟工這條是 debug 工具,AI 場景是「prompt design」工具 — 在 prompt 裡內嵌 root cause analysis instruction,或設計獨立 verification agent。
#14 錯誤處理哲學 (Error Handling Philosophy)
定義:對「事情會出錯」這件事有明確設計姿態 — fail-fast vs fail-silently、retry policy、circuit breaker、graceful degradation。
經典出處:Erlang 的「let it crash」哲學、《Release It!》Michael Nygard 整本書、Google SREbook §22 addressing cascading failures。
本次對話做了沒:❌ 沒做。
分析:我們沒任何「workflow 跑到一半失敗了怎麼辦」的計畫:
- 如果某個 chunk 的 Haiku agent 超時了 → 我們沒設 retry 也沒設 fallback
- 如果 synthesis agent 算術錯了(這次真的發生了:83 vs 109)→ 我們沒設 verification 步驟,純靠主 orchestrator 主動懷疑
- 如果 JSON schema 驗證 fail → 不知道會發生什麼,沒測過
- 如果 workflow runtime 自己 crash → 沒 graceful resume 流程
該怎麼補:在 prompt 裡加 error handling instruction:
如果跑到一半發現:
- 某 chunk 的 agent fail → 標記 SKIPPED,繼續其他,最後 report 哪些 skip
- synthesis 結果跟 row count 對不上 → 不要直接出 report,先 escalate 給主 orchestrator 重算
- JSON schema 違反 → 該 row 標 INVALID,繼續其他
- 整體執行超過 5 分鐘 → 自動 abort,出階段性 report
最後 final report 要明確標示哪些 chunk 是「完整跑完」、哪些是「skipped」、哪些是「fail-and-retried」。對 AI 協作的特別意義:AI 預設 fail-silently — 它會生「看起來合理」的內容掩蓋失敗。傳統軟工 fail-fast 是「raise exception 停下來」,AI 場景的 fail-fast 是「標註 INVALID / SKIPPED 而不是瞎掰」。沒設計這條,AI 會「完整交付」一份其實內部有 hole 的報告,你看不出來。本次 workflow synthesis 算 83 是僥倖被主 orchestrator 抓到,如果主 orchestrator 也沒抓,我們就拿錯誤數字寫文章了。
#15 版本控制紀律 (Version Control Discipline)
定義:任何重要 artifact 進 git,commit message 寫清楚 why,branch 策略對應 workflow。
經典出處:Git 整個工具、Conventional Commits 規範、Trunk-based / GitFlow / GitHub Flow 各家 branch 策略、Linus 的 git 設計初衷。
本次對話做了沒:❌ 沒做。本次產出全部沒進 git。
分析:這次產出了 4 件 artifact:
~/.claude/projects/-home-tom/memory/brain/dynamic-workflows.md(新建)~/.claude/projects/-home-tom/memory/brain/adaptive-agent-team-staffing.md(編輯)~/.claude/projects/-home-tom/memory/MEMORY.md(編輯)- WordPress 文章兩篇
前三個位置實際是 ~/.claude/projects/-home-tom/ — 你有可能沒把它放在 git 控管下,意思是:
- brain 編輯沒 commit history,半年後想知道「dynamic-workflows.md 是什麼時候加的、為什麼加」沒記錄
- 如果 brain 不小心被改錯了(例如未來某個 conversation AI 寫壞了),無法 rollback
- 跨機器同步只能靠 rsync / cloud sync,沒 conflict resolution
該怎麼補:
cd ~/.claude/projects/-home-tom && git init(如果還沒)- 新 brain 或重大編輯後 commit:
git add brain/ MEMORY.md && git commit -m "feat(brain): dynamic-workflows from 2026-05-29 Opus 4.8 test" - WordPress 文章 export markdown 進專屬 repo,或用 wp-cli 串自動 backup
- workflow script 改 #11 補救時順便 commit 進 dotfiles repo
對 AI 協作的特別意義:AI 跨 conversation 是 stateless,brain file 是它的「外部記憶」。外部記憶的版本控管比 code 的還重要,因為你不會看到自己過去 conversation 改了哪些 brain,只有 git diff 告訴你。本次對話我改了 3 個 brain 檔,如果你沒 git 控管,3 個月後你不會記得這幾條條目是 5/29 對話加的還是更早。傳統 git 是 code 的時間機,AI 場景是「我跟 AI 集體記憶的時間機」。
15 條全表:做了沒 × leverage
| # | 紀律 | 類別 | 本次 | Leverage(高→低) |
|---|---|---|---|---|
| 1 | 驗證紀律 | 核心驗證 | ✅ | ★★★★★ 沒守等於沒救 |
| 2 | 正交分解 | 設計分解 | ✅ | ★★★★★ AI 回答品質直接相關 |
| 3 | 真實基準 | 過程紀律 | ✅ | ★★★★★ 結論可信度核心 |
| 4 | 文檔作為輸入 | 知識持久化 | ✅ | ★★★★★ AI 時代特有的紀律 |
| 5 | Focused review | 過程紀律 | ✅ | ★★★★ AI 對 mixed feedback 表現差 |
| 6 | 並行執行 | 過程紀律 | ✅ | ★★★ 規模大才顯效 |
| 7 | 回顧 | 核心驗證 | ✅ | ★★★★ 跟 #4 配對 leverage 最大 |
| 8 | 規格先於實作 | 設計分解 | ✅ | ★★★★ 直接決定 AI 輸出結構 |
| 9 | 權衡分析 | 設計分解 | ✅ | ★★★★ 抗 AI 默認 yes 傾向 |
| 10 | 預設驗收標準 | 過程紀律 | 🟡 | ★★★★ 該補,沒守會默認 plausible-looking |
| 11 | 可重跑 | 知識持久化 | ❌ | ★★★ 任務一次性可省,系統性任務必須 |
| 12 | 預算控管 | 過程紀律 | ❌ | ★★★ 小任務可省,長 background 任務必須 |
| 13 | 根因分析 | 核心驗證 | 🟡 | ★★★★ 主要靠 prompt 設計 |
| 14 | 錯誤處理哲學 | 設計分解 | ❌ | ★★★★ AI 預設 fail-silently 必補 |
| 15 | 版本控制 | 知識持久化 | ❌ | ★★★ brain 控管比 code 控管更重要 |
結論:跟 AI 寫程式需要哪些軟工?
不是新的軟工,是舊軟工套到 AI 4 個特性上
15 條全部都不是「AI 時代發明的」 — 每條都能在 1990 年代的軟工教材找到根。差別在 4 個 AI 特性對這些紀律的需求強度不同:
| AI 特性 | 被放大需求的紀律 |
|---|---|
| 訓練資料 cutoff | #1 驗證紀律(逼 AI 查資料,不要憑記憶) |
| Stateless / 無 conversation 記憶 | #4 文檔作為輸入、#15 版本控制(外部記憶持久化) |
| 非 deterministic 輸出 | #11 可重跑、#10 預設驗收標準、#14 錯誤處理(處理隨機性) |
| 高並發 + 高速 | #6 並行、#12 預算控管(token 倍率風險) |
個人 leverage 排序(5 強)
如果你是這條光譜中段的人(寫過 5 年以上 code,剛開始系統性用 AI 寫 code),最該優先吸收這 5 條:
- #1 驗證紀律 — 沒守這條,後面 14 條都白學。AI 講什麼都不能信,grep / curl / test 重驗
- #2 正交分解 — 拆軸線問,不要 bundled question。直接決定 AI 回答品質
- #4 文檔作為輸入 — 把學到的寫成下個 conversation 可讀的格式。沒這條,每次 onboarding
- #3 真實基準 — Toy example 騙人。用 production codebase 評估工具
- #5 Focused review — 給 AI feedback 一次只挑一條軸線
沒做的 5 條,該怎麼補
本次對話沒做的紀律對應 5 條 action(從便宜到貴):
- #15 版本控制(5 分鐘):
cd ~/.claude/projects/-home-tom && git init && git add . && git commit -m "snapshot"一次性處理 - #11 可重跑(2 分鐘):把 workflow script 從 session 暫存 cp 到 brain 或 dotfiles repo 歸檔
- #10 驗收標準(每任務多寫 3 行 prompt):任務 prompt 開頭加「驗收標準:N 個項目,M% 正確率,通不過要告訴我」
- #14 錯誤處理(每 workflow 多寫 5 行):script 內加 fail-fast / skip / retry 分支
- #12 預算控管(系統性設定):Claude Code admin page 設 hard daily limit 或寫個 hook 跑前先估
真正的 meta-insight
本文 15 條展開後最反直覺的觀察:跟 AI 寫程式需要的軟工基礎,大部分不是 code-level 的,是 process-level + protocol-level 的。傳統軟工新人學的順序是「先學語言 → 再學 design pattern → 最後學 process」,跟 AI 寫程式得反過來:先學 process discipline(怎麼下指令、怎麼驗證、怎麼回顧),最後才是 code-level technique。
因為跟 AI 寫程式,code 是 AI 生的,你扮演的是 reviewer + verifier + spec writer 三個角色。這三個角色傳統上叫 PM / QA / Tech Lead — 都是 senior eng 的活。所以「跟 AI 寫程式比較簡單」這句話完全反了 — 它把senior eng 的工作 commoditize 到每個用 AI 的人身上,reviewer 的紀律從「資深工程師的特權」變成「每個 prompt 作者的基本技能」。
這就是為什麼那麼多人「用 AI 寫了一堆 code 但跑不起來」 — 不是 AI 不行,是沒人替他們做 reviewer / verifier / spec writer 那三層活。本文 15 條的本質就是把這三層活的紀律寫下來。
跟我之前文章的關聯
- Claude Code Dynamic Workflows 實測:Opus 4.8 + 11 Haiku 平行 audit 109 個 resolver — 本文的 raw material 對話那條
- AI 不該替我打 🟢🟡🔴:從 decision-server 看跟 LLM 協作決策的介面方法論 — 本文 #9 權衡分析的延伸實作
- 跟 AI 寫程式的紀律:6 條規矩讓 AI 從 21 輪修不完到自走嚴格測試 — 本文 #10 驗收標準的歷史版本
- 從 4 條原則到動態大腦:兩種 Claude Code 知識系統的差異 — 本文 #4 文檔作為輸入的設計哲學討論
- 「未驗即不可信」AI 協作開發走出 21 輪修不完:SDD/TDD/腦子整合 — 本文 #1 驗證紀律的更早期實踐