分類: 🤖 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 率不同 → 提示空間不同 → 細節結論不同

該怎麼補:三層防護(從便宜到昂貴):

1. 最低: 把 script 從 session 暫存目錄 cp 出來歸檔到 brain 或 repo
2. 中等: 把 script 真的存成 ~/.claude/workflows/<name>.js slash command,雖然本案大概不重跑,但其他 audit 可以 fork
3. 高保證: 把 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

該怎麼補:

1. cd ~/.claude/projects/-home-tom && git init(如果還沒)
2. 新 brain 或重大編輯後 commit:git add brain/ MEMORY.md && git commit -m "feat(brain): dynamic-workflows from 2026-05-29 Opus 4.8 test"
3. WordPress 文章 export markdown 進專屬 repo,或用 wp-cli 串自動 backup
4. 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. #1 驗證紀律 — 沒守這條,後面 14 條都白學。AI 講什麼都不能信,grep / curl / test 重驗
2. #2 正交分解 — 拆軸線問,不要 bundled question。直接決定 AI 回答品質
3. #4 文檔作為輸入 — 把學到的寫成下個 conversation 可讀的格式。沒這條,每次 onboarding
4. #3 真實基準 — Toy example 騙人。用 production codebase 評估工具
5. #5 Focused review — 給 AI feedback 一次只挑一條軸線

沒做的 5 條,該怎麼補

本次對話沒做的紀律對應 5 條 action(從便宜到貴):

1. #15 版本控制(5 分鐘):cd ~/.claude/projects/-home-tom && git init && git add . && git commit -m "snapshot" 一次性處理
2. #11 可重跑(2 分鐘):把 workflow script 從 session 暫存 cp 到 brain 或 dotfiles repo 歸檔
3. #10 驗收標準(每任務多寫 3 行 prompt):任務 prompt 開頭加「驗收標準:N 個項目,M% 正確率,通不過要告訴我」
4. #14 錯誤處理(每 workflow 多寫 5 行):script 內加 fail-fast / skip / retry 分支
5. #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 驗證紀律的更早期實踐