當(dāng)AI能寫代碼時，人類的唯一價值就是“知道要寫什么”
我入行那會兒，寫代碼是一件很“手工”的事情。每個函數(shù)、每個類、每個模塊，都是程序員一行一行敲出來的。那時候，代碼就是真相。
后來有了Copilot，有了Cursor，有了AI Agent。我開始發(fā)現(xiàn)一個微妙的變化：寫代碼這件事，正在從“執(zhí)行”變成“描述”。我不再需要關(guān)心怎么實現(xiàn)一個排序算法，我只需要說“按時間倒序排列”，AI就幫我寫好了。
但問題也隨之而來——當(dāng)AI能寫代碼時，人類的獨特性在哪里？
答案是：意圖。
一、從“如何做”到“做什么”
過去十年，軟件開發(fā)經(jīng)歷了兩次認(rèn)知躍遷：
當(dāng)前我們正處于從“AI輔助編碼”向“規(guī)范驅(qū)動開發(fā)”遷移的關(guān)鍵時期。
AI輔助編碼的模式——也就是當(dāng)下大多數(shù)人正在使用的模式——本質(zhì)上是“對話式編程”。開發(fā)者打開Cursor或Copilot，通過自然語言與AI對話，生成代碼片段。這種模式的問題是：對話歷史就是唯一的真相來源。一旦對話中斷、上下文溢出、或者開發(fā)者換了一個工具，之前達(dá)成的共識就丟失了。代碼跑偏了，需求漏掉了，邊界條件忘了處理——這些都是“氛圍編碼”的典型癥狀。
而規(guī)范驅(qū)動開發(fā)的核心主張是：意圖，而不是代碼或?qū)υ?，是唯一的真理來源?/strong>
代碼只是意圖的一種實現(xiàn)，對話只是意圖的傳遞媒介。真正應(yīng)該被版本控制、被審計、被繼承的，是意圖本身。
二、為什么意圖必須是唯一的真理
為了說清楚這個問題，我們先回顧一個普通的功能開發(fā)流程。
假設(shè)產(chǎn)品經(jīng)理說：“我們要加一個用戶注冊功能?！?/p>
傳統(tǒng)模式下，這個需求會經(jīng)過需求文檔 → 技術(shù)方案 → 代碼實現(xiàn) → 測試用例 → 上線交付的流程。每個環(huán)節(jié)都有信息損耗，最終代碼和最初需求之間往往存在鴻溝——業(yè)務(wù)方說“我要的是A”，開發(fā)說“你當(dāng)時說的是B”，最后上線的是C。
AI輔助模式下，開發(fā)者直接對AI說：“幫我寫一個用戶注冊功能?！盇I生成代碼，開發(fā)測試上線。但問題是——如果三個月后需要修改這個功能，開發(fā)者打開代碼，發(fā)現(xiàn)沒有注釋、沒有文檔、沒有任何痕跡說明當(dāng)初為什么要這樣設(shè)計。他只能靠猜，或者重新和AI對話，而AI也已經(jīng)忘了當(dāng)時的上下文。
規(guī)范驅(qū)動模式下的做法完全不同。
首先，意圖被顯式地記錄下來：
markdown
# 用戶注冊功能規(guī)范
## 業(yè)務(wù)目標(biāo)
允許新用戶通過郵箱和密碼創(chuàng)建賬戶，注冊后自動發(fā)送歡迎郵件。
## 功能需求
- 郵箱格式校驗（RFC 5322標(biāo)準(zhǔn)）
- 密碼強度要求：至少8位，包含大小寫字母和數(shù)字
- 防止重復(fù)注冊（同一郵箱只能注冊一次）
- 注冊成功后自動發(fā)送確認(rèn)郵件
## 非功能需求
- 響應(yīng)時間 < 500ms（P95）
- 支持100 QPS的注冊并發(fā)
- 密碼存儲使用bcrypt（salt rounds=12）
## 邊界與錯誤處理
- 郵箱已存在 → 返回409 Conflict，提示“該郵箱已注冊”
- 密碼強度不足 → 返回422 Unprocessable Entity，明確列出密碼要求
- 郵件服務(wù)不可用 → 注冊事務(wù)回滾，返回503 Service Unavailable
## 測試驗收標(biāo)準(zhǔn)
- 正常流程：注冊成功，數(shù)據(jù)庫有記錄，郵件隊列有任務(wù)
- 重復(fù)郵箱：返回409，數(shù)據(jù)庫無新增記錄
- 弱密碼：返回422，錯誤信息包含具體規(guī)則
- 郵件失敗：事務(wù)回滾，無臟數(shù)據(jù)
這份規(guī)范就是“唯一真理”。它不依賴某個人的記憶，不依賴某次對話的上下文，不依賴AI工具的版本。它被提交到代碼倉庫，和代碼一起被版本控制。
接下來，AI讀取這份規(guī)范，生成代碼。如果生成的代碼有偏差，修改的不是代碼——而是規(guī)范。規(guī)范改了，代碼重新生成。規(guī)范永遠(yuǎn)正確，代碼只是規(guī)范的投影。
三、規(guī)范驅(qū)動的三層架構(gòu)
在實踐中，規(guī)范驅(qū)動開發(fā)可以抽象為三層架構(gòu)：
第一層：意圖層（What）
這一層是純粹的“意圖表達(dá)”，不涉及任何技術(shù)實現(xiàn)細(xì)節(jié)。它回答的是：我們要解決什么問題？ 用戶故事、業(yè)務(wù)目標(biāo)、驗收標(biāo)準(zhǔn)都在這一層。
這一層的產(chǎn)物是面向人的——產(chǎn)品經(jīng)理、業(yè)務(wù)方、開發(fā)者都能理解。它也是唯一應(yīng)該被手工維護(hù)的內(nèi)容。
第二層：規(guī)范層（How to what）
這一層將意圖轉(zhuǎn)化為可執(zhí)行的技術(shù)規(guī)格。它回答的是：在技術(shù)層面，這個意圖如何被精確描述？
包括：
- 接口定義（OpenAPI/GraphQL Schema）
- 數(shù)據(jù)模型
- 狀態(tài)機
- 錯誤碼定義
- 性能指標(biāo)
- 安全要求
這一層是“人與AI的合同”——人負(fù)責(zé)定義邊界和約束，AI負(fù)責(zé)在這些約束內(nèi)生成實現(xiàn)。
第三層：實現(xiàn)層（Implementation）
這一層是AI根據(jù)規(guī)范生成的代碼。它回答的是：具體的代碼長什么樣？
代碼應(yīng)該被視為“編譯產(chǎn)物”——你可以讀它、調(diào)試它，但不應(yīng)該手工修改它。如果需要修改，應(yīng)該回到規(guī)范層去改，然后重新生成。
這種做法的好處是顯而易見的：代碼永遠(yuǎn)和規(guī)范保持一致。再也不用擔(dān)心“文檔和代碼對不上了”。
四、一種典型的規(guī)范驅(qū)動工作流
以O(shè)penSpec為例，一個完整的規(guī)范驅(qū)動開發(fā)流程是這樣的：
text
1. 起草提案
開發(fā)者：我想加一個用戶注冊功能，具體需求是……
AI：生成了 proposal.md（為什么要做）、tasks.md（做什么）、specs/（詳細(xì)的規(guī)范增量）
2. 審查對齊
團(tuán)隊：這個規(guī)范覆蓋了所有邊界情況嗎？性能指標(biāo)合理嗎？安全要求夠嗎？
AI：根據(jù)反饋迭代修改規(guī)范，直到所有人都同意
3. AI實施
AI：根據(jù)鎖定的tasks.md和規(guī)范文件生成代碼
AI：運行測試 → 失敗 → 讀取錯誤 → 修正代碼 → 再運行 → 通過
4. 歸檔更新
開發(fā)者：批準(zhǔn)這個變更
AI：將規(guī)范合并到主規(guī)范庫，代碼合并到主分支
注意一個關(guān)鍵節(jié)點：在第2步之前，沒有一行代碼被寫出來。 所有的時間都花在澄清意圖、定義邊界、鎖定契約上。一旦規(guī)范鎖定，代碼生成就是一個幾乎確定性的過程。
這與傳統(tǒng)開發(fā)形成鮮明對比——傳統(tǒng)開發(fā)中，需求往往是模糊的，邊寫代碼邊澄清，最后發(fā)現(xiàn)做錯了，推倒重來。規(guī)范驅(qū)動的成本前移，但總成本更低。
五、規(guī)范即代碼
規(guī)范驅(qū)動開發(fā)的另一個核心理念是：規(guī)范也是代碼。
這意味著：
- 規(guī)范被提交到Git倉庫
- 規(guī)范可以被diff、被review、被blame
- 規(guī)范可以被自動化工具驗證（比如檢查OpenAPI規(guī)范是否與代碼一致）
- 規(guī)范可以被版本化、被分支管理
想象一下這樣的場景：產(chǎn)品經(jīng)理在GitHub上提交了一個PR，修改了某個功能的驗收標(biāo)準(zhǔn)。CI自動觸發(fā)，AI讀取新的規(guī)范，重新生成代碼，運行測試。如果測試通過，這個PR就可以被合并——需求變更到代碼交付的全流程自動化。
這不是科幻。這已經(jīng)發(fā)生在一些前沿團(tuán)隊的實踐中。
六、意圖成為唯一真理之后
當(dāng)意圖成為唯一真理，整個軟件開發(fā)的工作方式都會發(fā)生變化：
對人的影響
產(chǎn)品經(jīng)理：不再只是提需求，而是編寫規(guī)范。產(chǎn)品經(jīng)理的技能棧需要擴展：邏輯清晰、邊界周全、表達(dá)精確。
開發(fā)者：不再只是寫代碼，而是設(shè)計規(guī)范架構(gòu)、建立規(guī)范模板、審查AI生成的規(guī)范、調(diào)試規(guī)范與代碼的偏差。
測試工程師：不再只是寫測試用例，而是定義測試規(guī)范、驗證規(guī)范是否覆蓋了所有場景、確保生成的代碼符合規(guī)范。
對組織的影響
溝通成本大幅下降：規(guī)范取代了“口口相傳”的需求傳遞
知識沉淀更自然：規(guī)范庫就是組織的知識庫
交接成本趨近于零：新成員閱讀規(guī)范就能理解系統(tǒng)
審計和合規(guī)更容易：規(guī)范可以追溯到每一個業(yè)務(wù)決策
對AI的影響
AI的角色從“代碼生成器”變成“規(guī)范執(zhí)行者”
人類對AI的控制從“每次對話”變成“規(guī)范版本控制”
AI的輸出質(zhì)量可以通過規(guī)范的質(zhì)量來預(yù)測
七、如何開始實踐規(guī)范驅(qū)動開發(fā)
如果你對規(guī)范驅(qū)動開發(fā)感興趣，可以從以下幾步開始：
第一步：從新功能試點
不要試圖改造所有歷史代碼。選擇一個新功能，嘗試先寫規(guī)范（用Markdown即可），再讓AI根據(jù)規(guī)范生成代碼。對比這個流程和你平時的工作流有什么不同。
第二步：建立規(guī)范模板庫
收集你常用的功能類型（CRUD、認(rèn)證、集成第三方API等），為每種類型建立規(guī)范模板。這樣下次遇到類似需求時，只需要填空。
第三步：引入規(guī)范工具鏈
嘗試使用OpenSpec、SpecKit或AWS Kiro等工具，讓規(guī)范管理更加結(jié)構(gòu)化。這些工具能幫助你自動生成tasks.md、管理規(guī)范增量、與AI Agent集成。
第四步：規(guī)范納入代碼審查
在PR審查中，強制要求規(guī)范的變更和代碼的變更同時出現(xiàn)。如果代碼變了而規(guī)范沒變，PR應(yīng)該被拒絕。
第五步：持續(xù)迭代規(guī)范質(zhì)量
回顧哪些規(guī)范寫得好（AI一次就生成正確代碼）、哪些寫得不好（AI反復(fù)出錯）。提煉出好的規(guī)范模式，分享給團(tuán)隊。
八、寫在最后
我經(jīng)常思考一個問題：在AI可以寫代碼的世界里，開發(fā)者的價值到底是什么？
如果AI已經(jīng)可以寫90%的代碼，那么開發(fā)者剩下的10%是什么？是調(diào)試？是部署？是運維？
我認(rèn)為都不是。
剩下的10%是定義意圖。
是知道“應(yīng)該做什么”，而不是“怎么做”。是在模糊的需求中提煉出清晰的邊界。是在無數(shù)的可能性中，選擇唯一正確的路徑。是在AI迷失方向時，為它提供錨點。
規(guī)范驅(qū)動開發(fā)的本質(zhì)，就是把這種“意圖定義”的能力系統(tǒng)化、工具化、工程化。它把開發(fā)者的注意力從“如何寫代碼”解放出來，聚焦在“我們要解決什么問題”。
代碼會變，框架會變，語言會變，但意圖——那個最初的“為什么”——才是唯一值得被永久保存的真理。
