我們剛剛開源了一整套 AI 開發技能與方法論：IDD（Intent Driven Development）
我們開源了一套叫 IDD（Intent Driven Development）的方法論和工具鏈。核心理念一句話：告訴 AI “要什麼”，而不是 “做什麼”。
在 AI 輔助程式設計成為日常之後，傳統的需求文件、user story、技術 spec 這些東西越來越顯得不合時宜。它們是為人類協作設計的，搬到人機協作的場景下，寫了一堆文件 AI 還是經常理解偏，然後就是一輪輪的修正。IDD 的思路是換一個方向：與其告訴 AI 怎麼做，不如把"要什麼"說清楚，讓 AI 自己規劃實現。這篇文章想聊聊我們為什麼這麼做，以及這套東西具體是怎麼運作的。
SDD vs IDD
軟體工程領域有過很多嘗試來解決"先想清楚再動手"的問題。SDD（Spec Driven Development）就是其中之一，核心思路是先寫詳細的規格說明，再按規格實現程式碼。聽起來很合理，但在 AI 時代暴露出問題。
| 方法 | 流程 | 問題 |
|---|---|---|
| Traditional | Code → Test → Docs | 文件經常過時或缺失 |
| SDD | Spec → Code → Test | Spec 容易過時，分散在多個檔案裡 |
| TDD | Test → Code → Docs | 測試不能表達設計意圖 |
| DID | Intent → Test → Code → Sync | Intent 表達"要什麼"和"為什麼"，AI 負責"怎麼做" |
我對 SDD 這套形式主義有些切身體會。多年前在西雅圖某大軟體公司工作時，團隊有位 PM，任何東西到他手裡都會變成極為冗長的制式文件，幾句話能說清的事情非要拆成十幾個 user story，格式工整，滴水不漏，看完之後你依然不知道這東西到底要做什麼。去年試用 Amazon 的 Kiro 時，那種熟悉的感覺又回來了。Kiro 是典型的 SDD 工具，它會幫你產生一堆 spec 檔案，結構很規範，但「為了寫而寫」的感覺非常強烈。這不是工具的問題，而是思路的問題，把傳統軟體工程那套直接搬到 AI 時代，工具變了但思維方式沒變。
SDD 的問題在於它還是按傳統方式組織資訊：按需求型別分（功能需求、UX 需求、技術需求），拆成 user story，維護單獨的任務檔案。這種分類對人類協作有意義，產品經理看功能需求，設計師看 UX 需求，架構師看技術需求。但對 AI 來說，這種分類把完整的上下文打散了。AI 需要理解一個模組的全貌，而不是從五個檔案裡拼湊資訊。你按傳統方式拆得越細，AI 越要花力氣重新拼裝，拼錯了就是反覆修正。
IDD 的思路不同：按模組組織而不是按需求型別組織，保持完整的上下文；不寫任務檔案，讓 AI 自己分解任務；Intent 的抽象層級更高，描述"要什麼效果"而不是"怎麼實現"。和 TDD 比，IDD 在 Test 之前加了一層 Intent；和 SDD 比，IDD 不規定實現細節，讓 AI 有空間規劃更好的方案。
為什麼 IDD 可行
你可能會問：不寫詳細 spec，AI 怎麼知道具體要做什麼？這裡有一個反直覺的事實：在很多領域，AI 比人類更懂"怎麼做"。
前段時間我想實現一個 6502 CPU Emulator，這種任務傳統上屬於「硬核」級別，需要理解 CPU 架構、暫存器設計、指令編碼解碼，光設計階段就要翻閱大量技術手冊。如果用 SDD 的方式，我得先寫幾十頁文件把每條指令、每種定址模式都列清楚，spec 還沒寫完專案可能就夭折了。但我只告訴 AI：我需要一個 6502 Emulator，能正確執行標準指令集，要有基本的除錯能力。就這些。
結果讓我意識到一件事：6502 是 1975 年的晶片，驅動過 Apple II、NES 遊戲機，圍繞它的技術文件和開源實現多到難以計數，LLM 見過的 emulator 程式碼比任何人類專家都多。AI 給出的模組劃分比我自己設計的還清晰，結合 TDD 的要求整個實現一氣呵成。過去被認為需要最資深工程師的任務，對 AI 來說反而輕鬆，因為這類經典問題在訓練資料裡覆蓋最充分。
這就是 IDD 可行的基礎：在 AI 訓練資料覆蓋充分的領域，你不需要告訴它怎麼做，你只需要把"要什麼"說清楚。AI 見過的模式比我們多，它規劃的方案可能比我們自己想的更合理。人類的價值在於判斷"要什麼是對的"，這才是真正需要人類智慧的部分。
Intent 是新的原始碼
這句話的意思是：Code review 可以交給 AI，Intent review 必須由人類完成。
AI 擅長檢查程式碼是否符合規範、是否有安全漏洞、是否遵循專案風格。但 AI 無法判斷"這個功能是不是我們真正想要的"，這個判斷只能由人類做出。所以人類的精力應該集中在 Intent 的稽核上，而不是逐行 review AI 生成的程式碼。
Intent 和傳統需求文件的區別：
| 傳統需求 | IDD Intent |
|---|---|
| 按型別分（功能/技術/UX） | 按模組分 |
| 描述"做什麼" | 描述"要什麼" |
| 寫給人看 | 寫給 AI + 人看 |
| 寫完容易過時 | 持續與程式碼同步 |
Intent 的抽象層級更高。你不用告訴 AI 用什麼技術、怎麼分層，這些讓 AI 自己規劃。你要做的是描述清楚：最終效果是什麼、有什麼約束、邊界情況怎麼處理。
Intent 檔案結構
DID 的 Intent 檔案用三層結構：
1. 結構圖 - ASCII 圖展示模組關係、資料流向。圖比文字精確，LLM 能直接"看懂"。
2. 約束規則 - 必須遵守的限制，如依賴方向、邊界規則。可直接轉化為 lint 規則或測試斷言。
3. 行為示例 - 具體的輸入輸出，包括邊界情況。可直接轉化為測試用例。
設計原則：每一層都必須是可驗證的。 不是模糊描述，而是可以用程式碼檢查的約束。
工具鏈
我們做了一套 Claude Code 外掛：
| 命令 | 功能 |
|---|---|
/intent-assess | 評估專案是否適合 DID |
/intent-init | 初始化 IDD 目錄結構 |
/intent-interview | 透過訪談把想法轉化為 INTENT.md |
/intent-review | 審批 Intent 的關鍵 section |
/intent-check | 驗證程式碼與 Intent 是否一致 |
/intent-report | 從 Intent 產生文件 |
完整流程：
/intent-assess # 評估是否適合
↓
/intent-init # 初始化結構
↓
/intent-interview # 建立 Intent
↓
/intent-review # 審批關鍵部分
↓
[AI 實現程式碼]
↓
/intent-check # 驗證一致性
安裝：
npx add-skill arcblock/idd
適用場景
適合 IDD：
- AI 輔助開發是主要工作方式
- 系統軟體、框架、基礎設施
- 需要嚴格架構邊界的專案
可能不適合：
- 高度監管的產業，必須使用傳統文件格式
- 團隊沒有 AI 工具
- 需要給非技術人員看 user story
寫在最後
回到開頭的問題：人類應該告訴 AI 什麼？我覺得答案是告訴它"要什麼"，而不是"怎麼做"。Spec-driven 在 AI 時代容易變成形式主義，寫了一堆文件 AI 還是不理解你要什麼。IDD 換了個方向，與其詳細規定怎麼做，不如把"要什麼"說清楚，讓 AI 自己規劃實現。
這套東西我們自己用了一段時間，感覺方向是對的。開源出來，希望對其他團隊也有幫助。
GitHub: github.com/ArcBlock/idd