別再跟 AI 瞎聊了：Thoughtworks 提出的 SPDD，讓 prompt 變成工程資產
整理版優先睇
SPDD（結構化提示詞驅動開發）將 prompt 視為一等公民交付物，透過 REASONS Canvas 七維框架鎖死意圖，讓 AI 生成代碼可治理、可審查、可複用。
呢篇文章由 Thoughtworks 嘅 Wei Zhang 同 Jessie Jie Xia 喺 Martin Fowler 網站發佈，指出而家團隊用 AI 編程嘅困境：工具愈來愈勁，單兵效率爆升，但成個交付鏈條——需求理解、Code Review、集成測試、生產風險——都冇變好，甚至更亂。作者想解決嘅問題係：「點樣將 prompt 由聊天記錄變成可管理嘅工程資產？」
SPDD 嘅核心主張係：將 prompt 當作一等公民嘅交付物，唔係臨時指令。佢哋提出咗一個叫 REASONS Canvas 嘅七維框架——R（需求）、E（實體）、A（策略）、S（結構）、O（操作）、N（規範）、S（護欄）——喺寫 code 之前鎖死意圖。呢個框架同時 serve LLM 同人類隊友，係設計文檔亦係 prompt。
整體結論係：SPDD 透過「先修 prompt，再改 code」嘅閉環規則，將 prompt 地位拉到同 code 平等，甚至更高。文章用一個 token 計費引擎嘅案例示範點樣由故事拆解到生成代碼，最終意圖對齊率達 99%。作者強調，AI 時代開發者嘅核心價值唔係寫 code 快，而係思考清晰度。
- SPDD 將 prompt 視為可版本控制、可審查、可複用嘅團隊資產，而唔係一次性聊天記錄。
- REASONS Canvas 七維框架（R、E、A、S、O、N、S）喺寫 code 前鎖死意圖，同時服務 LLM 同人類。
- 閉環法則：當現實偏離時，先修 prompt 再改 code；重構則先改 code 再同步 prompt。
- 實戰案例顯示，透過 /spdd-* 指令自動化流程，業務邏輯意圖對齊率可達約 99%。
- 開發者需要三項核心能力：先抽象（釐清結構）、意圖對齊（鎖定做與唔做）、迭代審查（紀律性循環）。
原文：Structured Prompt-Driven Development
Martin Fowler 網站上嘅 SPDD 原文，包含完整框架、案例同工具鏈說明。
問題：局部加速，全局更亂
你買咗法拉利，但開喺泥巴路上——呢個係而家大多數團隊用 AI 編程嘅寫照。Cursor、Copilot、Claude Code 呢啲工具越嚟越猛，一個人一日可以產出一週嘅代碼量。
局部加速，全局冇變，甚至更亂
但成條交付鏈條出咗問題：需求理解偏咗，代碼生成得越快，錯得越遠；Review 要處理嘅變更量暴增；集成測試問題此起彼伏；生產環境風險更難推理。唔係 AI 嘅問題，係我哋用 AI 嘅方式有問題。
SPDD 核心：REASONS Canvas 七維框架
SPDD 嘅核心工具叫 REASONS Canvas，一個七維度結構化框架，喺寫 code 之前先寫清楚意圖。七個維度分別係：
- 1 R（Requirements）：解決咩問題？完成定義係咩？
- 2 E（Entities）：領域實體同關係係咩？
- 3 A（Approach）：用咩策略滿足需求？
- 4 S（Structure）：變更喺系統嘅位置？涉及邊啲組件同依賴？
- 5 O（Operations）：將策略拆成具體、可測試嘅實現步驟
- 6 N（Norms）：橫切面工程規範——命名、可觀測性、防禦性編碼等
- 7 S（Safeguards）：不可逾越嘅紅線——不變量、性能上限、安全規則
閉環法則：先修 prompt，再改 code
When reality diverges, fix the prompt first — then update the code.
呢條規則將 prompt 嘅地位拉到同 code 平等，甚至更高。喺 SPDD 中，結構化 prompt 必須始終同 code 保持同步——好似一面鏡子。具體分兩類修改：
- 邏輯修正（改變可觀測行為）→ 先改 prompt，再改 code。例如字段由必填變可空，用 /spdd-prompt-update 更新 Canvas，再用 /spdd-generate 重新生成受影響 code。
- 重構（唔改變可觀測行為）→ 先改 code，再同步 prompt。例如提取魔法數字為常量，先做重構，再用 /spdd-sync 同步變更。
Martin Fowler 嘅重構定義喺呢度被完美複用：改變內部結構，唔改變可觀測行為
實戰案例：token 計費引擎加多套餐
文章用一個真實案例行咗一次 SPDD 全流程：為 token 計費引擎增加多套餐能力。原系統得一個全局費率，增強後支援 Standard Plan（有配額，超出按模型計費）同 Premium Plan（無配額，prompt token 同 completion token 分開計價）。
- 1 創建需求：用 /spdd-story 拆分用戶故事
- 2 澄清分析：明確核心邏輯、範圍邊界、完成定義
- 3 生成分析上下文：用 /spdd-analysis 做領域概念識別同風險分析
- 4 生成結構化 prompt：用 /spdd-reasons-canvas 生成七維度畫布
- 5 生成代碼 + 驗證 + Review：用 /spdd-generate 生成代碼，/spdd-api-test 做功能驗證
- 6 生成單元測試：基於模板生成測試場景，去重後生成測試代碼
業務邏輯意圖對齊率達到約 99%
成個過程完全可追溯。文章反覆強調：唔好怕犯錯，唔好試圖一次做對所有事。只要喺 SPDD 閉環中持續迭代，細 micro 嘅 code smell 可以後面再處理，先確保核心功能正確。
開發者新能力：抽象、對齊、迭代審查
AI 時代，開發者嘅核心價值唔在於寫 code，而在於思考清晰度
SPDD 背後係對開發者能力模型嘅重新定義，文章提出三項核心技能：
- Abstraction First（先抽象）：生成 code 前先搞清對象、協作方式同邊界，避免 AI 將混亂放大。
- Alignment（意圖對齊）：寫 code 前講清「做咩 / 唔做咩」，鎖定標準同硬約束，否則只會「快速產出 + 緩慢返工」。
- Iterative Review（迭代審查）：冇紀律嘅審查循環會令團隊不斷打補丁，最終偏離方案，失控於成本同時間。
你買咗一架法拉利，但係揸喺泥路上面。
呢個就係今日大多數團隊用 AI 編程嘅真實寫照。
Cursor、Copilot、Claude Code……工具越嚟越勁，個人效率真係爆燈。一個人一日可以做到過去一個禮拜嘅代碼量。但你仔細睇曬成個交付鏈條——需求理解錯咗，代碼生成得越快，錯得越遠；Review 要處理嘅變更量暴增；集成測試問題此起彼伏；生產環境嘅風險變得更難推理。
「局部加速，全局冇變，甚至更亂。」
呢個唔係 AI 嘅問題，係我哋用 AI 嘅方式有問題。
4 月 28 日，Thoughtworks 嘅 Wei Zhang 同 Jessie Jie Xia 喺 Martin Fowler 嘅網站上發佈咗一篇重磅文章，提出咗一個叫 「SPDD（Structured Prompt-Driven Development，結構化提示詞驅動開發）」 嘅方法。核心主張只有一句話：
「將 prompt 當作一等公民嘅交付物嚟管理。」
唔係聊天記錄，唔係臨時指令，而係好似代碼咁——版本控制、代碼審查、複用迭代。
你以為瓶頸係「生成代碼」，其實係「對齊意圖」
大多數開發者用 AI 嘅方式係咁：打開對話框，用自然語言描述需求，AI 吐出代碼，行一次，唔啱就再傾幾輪，啱就提交。
呢個過程有一個致命嘅隱患：「你同 AI 對齊意圖嘅過程，全部消失喺聊天記錄裏面。」
三日後你返嚟睇呢段代碼，你唔記得當時點解做咗呢個設計決策。你嘅同事嚟 Review，佢見到嘅係一堆代碼，但見唔到背後嘅「點解」。下一個迭代要改呢個功能，新嚟嘅人只能重新猜測原始意圖。
❝代碼係「點樣做」嘅記錄，但「點解咁做」被掉咗。
❞
SPDD 要解決嘅，就係呢個問題。
REASONS Canvas：一張畫布鎖死七個維度
SPDD 嘅核心工具叫 「REASONS Canvas」，一個七維度嘅結構化框架，喺寫代碼之前，先將意圖寫清楚：
「R（Requirements）」：我哋到底喺解決咩問題？完成嘅定義係咩？ 「E（Entities）」：領域實體同關係係咩？ 「A（Approach）」：用咩策略嚟滿足需求？ 「S（Structure）」：變更喺系統中嘅位置，涉及邊啲組件同依賴？ 「O（Operations）」：將策略拆成具體嘅、可測試嘅實現步驟 「N（Norms）」：橫切面嘅工程規範——命名、可觀測性、防禦性編碼等 「S（Safeguards）」：不可逾越嘅紅線——不變量、效能上限、安全規則
前四個維度係「意圖同設計」，第五個係「執行」，最後兩個係「治理」。
呢個唔係咩新發明。如果你熟悉 Spec-Driven Development，你會覺得似曾相識。但 SPDD 嘅差異在於：「佢將結構化 prompt 當作可治理、可複用、可版本化嘅團隊資產」，而唔單止係「先寫 spec 再畀 AI 實現」。
換句話講，REASONS Canvas 唔單止係畀 AI 睇嘅指令，更加係畀人睇嘅設計文檔。佢同時服務於兩個讀者：LLM 同你嘅隊友。
閉環法則：現實偏離咗，先改 prompt，再改代碼
SPDD 工作流中有一條簡單但顛覆性嘅規則：
❝「When reality diverges, fix the prompt first — then update the code.」
（當現實偏離時，先修 prompt，再改代碼。）
❞
呢條規則將 prompt 嘅地位拉到同代碼平等，甚至更高嘅位置。
喺傳統開發中，需求文檔寫完就掉咗，代碼先係「唯一嘅真相來源」。但喺 SPDD 中，結構化 prompt 必須始終同代碼保持同步——好似一面鏡咁。
具體點樣做？文章將代碼審查後嘅修改分成咗兩類：
「1. 邏輯修正（改變咗可觀測行為）→ 先改 prompt，再改代碼」
例如發現一個字段應該係必填而唔係可空嘅，呢個係業務規則嘅變更。先用 /spdd-prompt-update 更新 REASONS Canvas 中嘅對應部分，再用 /spdd-generate 重新生成受影響嘅代碼。
「2. 重構（唔改變可觀測行為）→ 先改代碼，再同步 prompt」
例如提取 magic number 做常數，呢個係代碼質量優化。先做重構，再用 /spdd-sync 將變更同步返去 prompt。
Martin Fowler 嗰句經典嘅重構定義喺呢度被完美複用：
❝"A change made to the internal structure of software to make it easier to understand and cheaper to modify 「without changing its observable behavior」."
❞
一個完整嘅例子：畀計費引擎加多套餐
文章用一個真實嘅案例行完咗 SPDD 全流程——畀一個 token 計費引擎增加多套餐計費能力。
原系統只有一個全局費率。增強之後要支持：
「Standard Plan」：有月度配額，超出部分按模型計費 「Premium Plan」：無配額，prompt token 同 completion token 分開計價
六步行完：
「創建需求」：用 /spdd-story拆分用戶故事「澄清分析」：明確核心邏輯、範圍邊界、完成定義 「生成分析上下文」：用 /spdd-analysis做領域概念識別同風險分析「生成結構化 prompt」：用 /spdd-reasons-canvas生成七維度畫布「生成代碼 + 驗證 + Review」：用 /spdd-generate生成代碼，/spdd-api-test做功能驗證「生成單元測試」：基於模板生成測試場景，去重後生成測試代碼
最終結果：業務邏輯嘅意圖對齊率達到約 99%。成個過程完全可追溯。
關鍵感受係文章中反覆強調嘅一點：「唔好怕犯錯，唔好試圖一次做啱所有嘢。」 只要喺 SPDD 嘅閉環中持續迭代，細嘅代碼異味可以遲啲再處理。先確保核心功能正確，再優化細節。
三項核心能力：AI 時代開發者嘅新護城河
SPDD 唔止係一套流程，佢背後係對開發者能力模型嘅重新定義。文章提出咗三項核心技能：
「1. Abstraction First（先抽象）」
喺生成任何代碼之前，先搞清楚有啲咩對象、佢哋點樣協作、邊界喺邊度。AI 最擅長嘅係衝刺實現細節，但如果結構冇諗清楚，佢只會將混亂放大。
「2. Alignment（意圖對齊）」
喺寫代碼之前，將「做咩 / 唔做咩」講清楚，將標準同硬約束提早鎖定。否則你得到嘅係「快速產出 + 緩慢返工」。
「3. Iterative Review（迭代審查）」
畀 AI 輔助開發好似工程流程咁運轉，而唔係一次性出稿。冇紀律嘅審查迭代循環，團隊要麼不斷要模型打補丁直到解決方案偏離，要麼反覆重來，失控於成本同時間。
呢三項能力嘅共同指向係：「AI 時代，開發者嘅核心價值唔在於寫代碼，而在於思考清晰度。」
文章最後引用咗 Richard Hamming 嘅一句話，精準咁概括咗 SPDD 嘅精神：
❝"In science, if you know what you are doing, you shouldn't be doing it. In engineering, if you don't know what you are doing, you shouldn't be doing it."
（喺科學中，如果你知道自己做緊咩，你唔應該做。喺工程中，如果你唔知道自己做緊咩，你唔應該做。）
❞
佢唔係銀彈，但值得認真睇
SPDD 唔係適用於所有場景。文章好誠實咁畀出咗適用性評估：
「強烈推薦」：標準化規模交付、高合規強約束場景 「推薦」：多人協作審計、跨服務一致性重構 「唔推薦」：緊急熱修復、探索性原型、一次性腳本 「唔適用」：業務規則模糊嘅黑洞、純視覺創意類工作
前期投入都唔細：團隊需要完成從「先寫代碼」到「先做設計」嘅心智轉換，需要有能夠將業務規則翻譯成清晰抽象嘅資深工程師，需要配套嘅自動化工具鏈。
但回報都好明確：確定性提高、可追溯性增強、Review 效率提升、演進更安全。
「喺 AI 編程越嚟越普及嘅今日，真正嘅競爭力唔係「邊個生成代碼更快」，而係「邊個嘅工程實踐可以令 AI 生成嘅代碼可治理、可審查、可複用」。」
SPDD 畀出咗一個認真嘅回答。
你喺團隊中係點樣管理 AI 生成嘅代碼嘅？係散落喺聊天記錄裏面，定係已經有咗某種結構化嘅方式？歡迎喺評論區傾下你嘅實踐。
❝原文連結：https://martinfowler.com/articles/structured-prompt-driven/
❞
你買了一輛法拉利，卻開在泥巴路上。
這就是今天大多數團隊用 AI 編程的真實寫照。
Cursor、Copilot、Claude Code……工具越來越猛，單兵效率確實炸裂。一個人一天能產出過去一週的代碼量。但你仔細看看整個交付鏈條——需求理解偏了，代碼生成得越快，錯得越遠；Review 要處理的變更量暴增；集成測試問題此起彼伏；生產環境的風險變得更難推理。
「局部加速，全局沒變，甚至更亂。」
這不是 AI 的問題，是我們用 AI 的方式有問題。
4 月 28 日，Thoughtworks 的 Wei Zhang 和 Jessie Jie Xia 在 Martin Fowler 的網站上發佈了一篇重磅文章，提出了一個叫 「SPDD（Structured Prompt-Driven Development，結構化提示詞驅動開發）」 的方法。核心主張只有一句話：
「把 prompt 當作一等公民的交付物來管理。」
不是聊天記錄，不是臨時指令，而是像代碼一樣——版本控制、代碼審查、複用迭代。
你以為瓶頸是"生成代碼"，其實是"對齊意圖"
大多數開發者用 AI 的方式是這樣的：打開對話框，用自然語言描述需求，AI 吐出代碼，跑一下，不對就再聊幾輪，對了就提交。
這個過程有一個致命的隱患：「你跟 AI 對齊意圖的過程，全部消失在了聊天記錄裏。」
三天後你回來看這段代碼，你不記得當時為什麼做了這個設計決策。你的同事來 Review，他看到的是一堆代碼，但看不到背後的"為什麼"。下一個迭代要改這個功能，新來的人只能重新猜測原始意圖。
❝代碼是"怎麼做"的記錄，但"為什麼這麼做"被扔掉了。
❞
SPDD 要解決的，就是這個問題。
REASONS Canvas：一張畫布鎖死七個維度
SPDD 的核心工具叫 「REASONS Canvas」，一個七維度的結構化框架，在寫代碼之前，先把意圖寫清楚：
「R（Requirements）」：我們到底在解決什麼問題？完成的定義是什麼？ 「E（Entities）」：領域實體和關係是什麼？ 「A（Approach）」：用什麼策略來滿足需求？ 「S（Structure）」：變更在系統中的位置，涉及哪些組件和依賴？ 「O（Operations）」：把策略拆成具體的、可測試的實現步驟 「N（Norms）」：橫切面的工程規範——命名、可觀測性、防禦性編碼等 「S（Safeguards）」：不可逾越的紅線——不變量、性能上限、安全規則
前四個維度是"意圖和設計"，第五個是"執行"，最後兩個是"治理"。
這不是什麼新發明。如果你熟悉 Spec-Driven Development，你會覺得似曾相識。但 SPDD 的差異在於：「它把結構化 prompt 當作可治理、可複用、可版本化的團隊資產」，而不僅僅是"先寫 spec 再讓 AI 實現"。
換句話說，REASONS Canvas 不只是給 AI 看的指令，更是給人看的設計文檔。它同時服務於兩個讀者：LLM 和你的隊友。
閉環法則：現實偏離了，先改 prompt，再改代碼
SPDD 工作流中有一條簡單但顛覆性的規則：
❝「When reality diverges, fix the prompt first — then update the code.」
（當現實偏離時，先修 prompt，再改代碼。）
❞
這條規則把 prompt 的地位拉到了和代碼平等，甚至更高的位置。
在傳統開發中，需求文檔寫完就扔了，代碼才是"唯一的真相來源"。但在 SPDD 中，結構化 prompt 必須始終與代碼保持同步——像一面鏡子。
具體怎麼做？文章把代碼審查後的修改分成了兩類：
「1. 邏輯修正（改變了可觀測行為）→ 先改 prompt，再改代碼」
比如發現一個字段應該是必填而非可空的，這是業務規則的變更。先用 /spdd-prompt-update 更新 REASONS Canvas 中的對應部分，再用 /spdd-generate 重新生成受影響的代碼。
「2. 重構（不改變可觀測行為）→ 先改代碼，再同步 prompt」
比如提取魔法數字為常量，這是代碼質量優化。先做重構，再用 /spdd-sync 把變更同步回 prompt。
Martin Fowler 那句經典的重構定義在這裏被完美複用：
❝"A change made to the internal structure of software to make it easier to understand and cheaper to modify 「without changing its observable behavior」."
❞
一個完整的例子：給計費引擎加多套餐
文章用一個真實的案例走完了 SPDD 全流程——給一個 token 計費引擎增加多套餐計費能力。
原系統只有一個全局費率。增強後要支持：
「Standard Plan」：有月度配額，超出部分按模型計費 「Premium Plan」：無配額，prompt token 和 completion token 分開計價
六步走完：
「創建需求」：用 /spdd-story拆分用戶故事「澄清分析」：明確核心邏輯、範圍邊界、完成定義 「生成分析上下文」：用 /spdd-analysis做領域概念識別和風險分析「生成結構化 prompt」：用 /spdd-reasons-canvas生成七維度畫布「生成代碼 + 驗證 + Review」：用 /spdd-generate生成代碼，/spdd-api-test做功能驗證「生成單元測試」：基於模板生成測試場景，去重後生成測試代碼
最終結果：業務邏輯的意圖對齊率達到約 99%。整個過程完全可追溯。
關鍵感受是文章中反覆強調的一點：「不要怕犯錯，不要試圖一次做對所有事。」 只要在 SPDD 的閉環中持續迭代，小的代碼異味可以後面再處理。先確保核心功能正確，再優化細節。
三項核心能力：AI 時代開發者的新護城河
SPDD 不只是一套流程，它背後是對開發者能力模型的重新定義。文章提出了三項核心技能：
「1. Abstraction First（先抽象）」
在生成任何代碼之前，先搞清楚有哪些對象、它們如何協作、邊界在哪裏。AI 最擅長的是衝刺實現細節，但如果結構沒想清楚，它只會把混亂放大。
「2. Alignment（意圖對齊）」
在寫代碼之前，把"做什麼 / 不做什麼"說清楚，把標準和硬約束提前鎖定。否則你得到的是"快速產出 + 緩慢返工"。
「3. Iterative Review（迭代審查）」
讓 AI 輔助開發像工程流程一樣運轉，而不是一次性出稿。沒有紀律的審查迭代循環，團隊要麼不停地讓模型打補丁直到解決方案偏離，要麼反覆重來，失控於成本和時間。
這三項能力的共同指向是：「AI 時代，開發者的核心價值不在於寫代碼，而在於思考清晰度。」
文章最後引用了 Richard Hamming 的一句話，精準地概括了 SPDD 的精神：
❝"In science, if you know what you are doing, you shouldn't be doing it. In engineering, if you don't know what you are doing, you shouldn't be doing it."
（在科學中，如果你知道自己在做什麼，你就不應該做。在工程中，如果你不知道自己在做什麼，你就不應該做。）
❞
它不是銀彈，但值得認真看
SPDD 並非適用於所有場景。文章很誠實地給出了適用性評估：
「強烈推薦」：標準化規模交付、高合規強約束場景 「推薦」：多人協作審計、跨服務一致性重構 「不推薦」：緊急熱修復、探索性原型、一次性腳本 「不適用」：業務規則模糊的黑洞、純視覺創意類工作
前期投入也不小：團隊需要完成從"先寫代碼"到"先做設計"的心智轉換，需要能把業務規則翻譯成清晰抽象的資深工程師，需要配套的自動化工具鏈。
但回報也很明確：確定性提高、可追溯性增強、Review 效率提升、演進更安全。
「在 AI 編程越來越普及的今天，真正的競爭力不是"誰生成代碼更快"，而是"誰的工程實踐能讓 AI 生成的代碼可治理、可審查、可複用"。」
SPDD 給出了一個嚴肅的回答。
你在團隊中是怎麼管理 AI 生成的代碼的？是散落在聊天記錄裏，還是已經有了某種結構化的方式？歡迎在評論區聊聊你的實踐。
❝原文連結：https://martinfowler.com/articles/structured-prompt-driven/
❞