1. 從能跑就行到意圖驅(qū)動AI原生SDLC到底在重構(gòu)什么過去兩年我參與過好幾個把大模型塞進研發(fā)流程的項目絕大多數(shù)都卡在同一個地方Demo階段驚艷一進真實迭代就崩。原因不復(fù)雜——我們習(xí)慣性地把AI當成一個更聰明的代碼補全器而不是把它當成研發(fā)流程里的一等公民。直到我系統(tǒng)性地研究了一套六階段重構(gòu)方法論才意識到問題的根子在于我們從來沒有把意圖當成可交付物來管理。這套方法論的核心是把傳統(tǒng)軟件開發(fā)生命周期SDLC從需求→設(shè)計→編碼→測試→部署→運維的線性流水線改造成一個以意圖為中心、以持續(xù)評測為反饋回路的閉環(huán)系統(tǒng)。它把整個流程拆成六個階段每個階段都有明確的輸入、輸出和驗收標準而貫穿始終的兩個關(guān)鍵抓手一個是intent.md這個看起來平平無奇的Markdown文件另一個是持續(xù)評測Continuous Evaluation機制。先說清楚這套東西解決什么問題。傳統(tǒng)SDLC里需求文檔寫完就鎖進Wiki吃灰代碼評審靠人肉記憶測試用例和需求之間是弱關(guān)聯(lián)。一旦需求變更你根本不知道哪些代碼、哪些測試、哪些文檔需要跟著動。AI介入之后這個問題被放大了十倍——因為AI生成的內(nèi)容速度極快如果沒有一個穩(wěn)定的意圖錨點它會朝著你意想不到的方向狂奔而且跑得越遠越難拉回來。intent.md就是那個錨點。它不是需求文檔的替代品而是一個機器可讀、人類可維護的意圖聲明。它用結(jié)構(gòu)化的方式描述這個系統(tǒng)要做什么、不做什么、邊界在哪里、驗收標準是什么并且隨著項目演進持續(xù)更新。持續(xù)評測則是圍繞這個意圖錨點建立的自動化驗證體系確保AI每次生成的產(chǎn)物都還在意圖范圍內(nèi)。這套方法適合誰我的判斷是已經(jīng)在用AI輔助開發(fā)、但感覺越用越亂的團隊以及準備把AI深度嵌入研發(fā)流程、但不想重蹈覆轍的團隊。如果你還在單文件腳本階段這套東西可能有點重但只要你開始面對多模塊、多輪迭代、多人協(xié)作的場景它帶來的秩序感會讓你覺得前期投入完全值得。2. 六階段重構(gòu)手冊的整體設(shè)計思路拆解2.1 為什么是六個階段而不是三個或十個我一開始也懷疑過六個階段是不是為了顯得完整而硬湊的。實際拆下來發(fā)現(xiàn)這個數(shù)字是有講究的。階段太少顆粒度不夠AI在每個階段能做的事情太寬泛容易失控階段太多交接成本高每個階段的上下文都要重新建立反而拖慢速度。六個階段的劃分邏輯是這樣的意圖定義 → 上下文構(gòu)建 → 方案生成 → 實現(xiàn)落地 → 驗證評測 → 反饋迭代。前三個階段是想清楚后三個階段是做扎實。每個階段之間都有明確的交付物而且這些交付物是下一個階段的輸入。這種鏈式結(jié)構(gòu)的好處是任何一環(huán)出問題你都能快速定位到是哪個階段的交付物不合格而不是籠統(tǒng)地說AI生成的東西不行。我特別想強調(diào)的是這六個階段不是瀑布式的。它們更像是一個螺旋每一輪迭代都會回到意圖定義階段做微調(diào)。intent.md在這個過程中扮演的是活文檔的角色而不是一次性寫完就凍結(jié)的規(guī)格說明書。2.2 意圖優(yōu)先為什么把intent.md放在最前面?zhèn)鹘y(tǒng)開發(fā)里需求文檔通常是給人和流程看的。但AI原生SDLC里intent.md要同時服務(wù)三個讀者人類開發(fā)者、AI生成引擎、評測系統(tǒng)。這就要求它的寫法必須兼顧自然語言的可讀性和結(jié)構(gòu)化數(shù)據(jù)的可解析性。我見過太多團隊把intent.md寫成散文結(jié)果AI解析的時候抓不住重點評測系統(tǒng)也沒法從中提取驗收標準。正確的做法是采用分層結(jié)構(gòu)頂層用自然語言描述業(yè)務(wù)意圖中間層用結(jié)構(gòu)化列表定義功能邊界底層用可執(zhí)行的斷言描述驗收條件。提示intent.md里的每一條意圖聲明都應(yīng)該能回答如果這條不滿足系統(tǒng)算不算失敗這個問題。如果回答不了說明這條意圖寫得太模糊需要拆解。2.3 持續(xù)評測為什么不能等到最后再做這是我最想糾正的一個認知誤區(qū)。很多團隊把評測當成最后一道關(guān)卡代碼寫完了跑一遍測試就完事。但在AI原生流程里評測必須是貫穿始終的因為AI生成的內(nèi)容不確定性太高你必須在每個階段都設(shè)置檢查點。持續(xù)評測的核心思想是把驗收標準前置到意圖定義階段然后在每個后續(xù)階段都用這些標準來驗證產(chǎn)物。比如在方案生成階段評測系統(tǒng)會檢查生成的方案是否覆蓋了intent.md里定義的所有功能點在實現(xiàn)落地階段評測系統(tǒng)會檢查代碼是否違反了意圖里聲明的邊界條件。這種做法的好處是問題在最早的可能時間點被發(fā)現(xiàn)。我實測下來把評測前置之后返工成本大概能降低六成以上——因為大部分問題在方案階段就被攔住了不會流到編碼階段才暴露。3. intent.md 的寫法與核心細節(jié)解析3.1 intent.md 的最小可用結(jié)構(gòu)一個能用的intent.md至少應(yīng)該包含四個部分意圖聲明、邊界條件、驗收標準、變更記錄。我下面給一個簡化版的模板你可以直接抄去改。# 意圖聲明 ## 核心目標 - 系統(tǒng)需要完成什么一句話描述 - 服務(wù)的核心用戶是誰 - 成功的定義是什么 ## 功能邊界 - 必須做的Must have - 應(yīng)該做的Should have - 明確不做的Wont have ## 驗收標準 - 標準1可量化、可驗證的描述 - 標準2... ## 變更記錄 - 日期 | 變更內(nèi)容 | 變更原因 | 影響范圍這個結(jié)構(gòu)看起來簡單但每一條都有講究。核心目標必須是一句話能說清楚的如果一句話說不清楚說明意圖本身還沒想明白。功能邊界里的明確不做的這一項很多人會忽略但它恰恰是防止AI跑偏的關(guān)鍵——你不告訴它邊界在哪里它就會自由發(fā)揮。3.2 意圖聲明的顆粒度怎么把握這是實操中最難拿捏的地方。顆粒度太粗AI理解不了具體要做什么顆粒度太細intent.md就變成了偽代碼失去了意圖層面的抽象價值。我的經(jīng)驗是一條意圖聲明對應(yīng)一個可獨立驗證的功能單元。什么叫可獨立驗證就是你能為它寫出一條明確的通過/失敗判定條件。比如系統(tǒng)支持用戶登錄這個顆粒度就太粗因為登錄涉及密碼校驗、會話管理、錯誤處理等多個子功能。拆成系統(tǒng)在收到正確憑證時返回有效會話令牌和系統(tǒng)在收到錯誤憑證時返回明確錯誤碼且不泄露用戶存在性就合適了。注意不要試圖在intent.md里描述實現(xiàn)細節(jié)。意圖層只回答做什么和做到什么程度算好怎么做是后續(xù)階段的事情。把實現(xiàn)細節(jié)寫進意圖里會導(dǎo)致意圖和實現(xiàn)耦合后續(xù)變更時兩邊都要改維護成本翻倍。3.3 讓AI讀懂intent.md的三個技巧intent.md寫好了怎么讓AI真正讀懂它是另一個問題。我踩過的坑是直接把整個文件丟給模型結(jié)果它抓不住重點生成的內(nèi)容偏離意圖。第一個技巧是分節(jié)投喂。不要一次性把整個intent.md塞進上下文而是根據(jù)當前階段的需要只投喂相關(guān)章節(jié)。比如方案生成階段重點投喂核心目標和功能邊界驗證評測階段重點投喂驗收標準。第二個技巧是用顯式引用代替隱式理解。在提示詞里明確說請參考 intent.md 中的第X條驗收標準而不是籠統(tǒng)地說請參考 intent.md。顯式引用能大幅提升AI的遵循度。第三個技巧是給意圖聲明加上唯一標識符。比如給每條驗收標準編號AC-001、AC-002這樣在后續(xù)的評測報告和變更記錄里都能精確追溯到具體是哪條標準出了問題。4. 持續(xù)評測體系的落地實操4.1 評測體系的三個層次持續(xù)評測不是簡單地跑單元測試。在AI原生SDLC里評測至少分三個層次意圖一致性評測、功能正確性評測、回歸安全性評測。意圖一致性評測回答的是生成的東西還是不是我們想要的東西。這個層次的評測往往需要人工參與或者用另一個AI模型來做裁判。功能正確性評測就是傳統(tǒng)的單元測試、集成測試那一套但用例要從intent.md的驗收標準里自動生成?；貧w安全性評測確保新變更沒有破壞已有功能這個層次最容易被忽略但在AI頻繁生成代碼的場景下極其重要。評測層次評測對象執(zhí)行頻率主要工具意圖一致性方案、設(shè)計文檔每次方案變更AI裁判人工抽檢功能正確性代碼、接口每次提交自動化測試框架回歸安全性全量功能每日構(gòu)建回歸測試套件4.2 從驗收標準自動生成測試用例這是持續(xù)評測里最省力的一環(huán)也是最容易做砸的一環(huán)。省力是因為一旦intent.md的驗收標準寫得足夠結(jié)構(gòu)化生成測試用例就是水到渠成的事。容易砸是因為如果驗收標準寫得模糊生成的測試用例就是一堆廢紙。我的做法是驗收標準必須包含輸入-操作-預(yù)期輸出三要素。比如系統(tǒng)在收到錯誤憑證時返回明確錯誤碼這條標準三要素拆解后是輸入錯誤憑證操作調(diào)用登錄接口預(yù)期輸出返回非200狀態(tài)碼且響應(yīng)體包含錯誤碼字段。有了這三要素生成測試用例就是模板化的工作。# 從驗收標準生成測試用例的簡化示例 def generate_test_case(acceptance_criterion): return { name: acceptance_criterion[id], input: acceptance_criterion[input], action: acceptance_criterion[action], expected: acceptance_criterion[expected_output], assertion: build_assertion(acceptance_criterion) }這段代碼只是示意實際落地時你需要根據(jù)自己團隊的技術(shù)棧做適配。核心思路是驗收標準的結(jié)構(gòu)化程度決定了測試用例的自動化程度。4.3 評測結(jié)果如何反哺意圖迭代評測不是為了打分而是為了驅(qū)動迭代。每次評測跑完結(jié)果應(yīng)該自動匯總成一份意圖偏差報告列出哪些驗收標準沒通過、偏差程度如何、可能的原因是什么。這份報告是下一輪意圖迭代的直接輸入。我習(xí)慣在每輪迭代結(jié)束時做一次意圖回顧把評測報告和intent.md放在一起看。如果某條驗收標準連續(xù)多輪不通過要么是標準本身定得不合理要么是實現(xiàn)方案有系統(tǒng)性問題。這時候就需要回到意圖定義階段重新審視這條標準是否還成立。提示意圖偏差報告不要只給結(jié)論要給證據(jù)。比如AC-003未通過是結(jié)論AC-003未通過實際返回500錯誤預(yù)期返回400錯誤錯誤發(fā)生在輸入校驗環(huán)節(jié)是證據(jù)。有證據(jù)的報告才能驅(qū)動有效決策。5. 六階段逐階段實操要點與避坑指南5.1 意圖定義階段最容易被低估的階段這個階段看起來只是寫文檔但實際上它決定了后面五個階段的天花板。我見過太多團隊在這個階段草草了事結(jié)果后面反復(fù)返工。實操要點先做意圖訪談再做意圖建模最后寫 intent.md。意圖訪談是跟業(yè)務(wù)方、用戶、技術(shù)負責人分別聊把不同視角的期望收集起來。意圖建模是把這些期望整理成結(jié)構(gòu)化的意圖樹區(qū)分核心意圖和衍生意圖。最后才是落筆寫intent.md。避坑指南不要一個人悶頭寫intent.md。意圖是共識不是個人理解。我建議至少三個人參與意圖評審一個業(yè)務(wù)視角、一個技術(shù)視角、一個測試視角。三個視角都認可了意圖才算立住。5.2 上下文構(gòu)建階段給AI喂什么、怎么喂這個階段的核心任務(wù)是為AI準備一個干凈、相關(guān)、充足的上下文包。上下文包的質(zhì)量直接決定生成質(zhì)量。我的做法是把上下文分成三類領(lǐng)域上下文業(yè)務(wù)知識、行業(yè)術(shù)語、項目上下文代碼庫結(jié)構(gòu)、已有實現(xiàn)、技術(shù)棧、任務(wù)上下文當前要解決的問題、相關(guān)意圖聲明。三類上下文分開管理按需組合。避坑指南上下文不是越多越好。我實測過當上下文超過模型有效窗口的七成時生成質(zhì)量反而下降因為模型開始分心。正確的做法是精準投喂只給當前任務(wù)真正需要的信息。5.3 方案生成階段如何讓AI給出可落地的方案這個階段最容易出現(xiàn)的問題是AI給出的方案看起來很漂亮但落不了地。原因通常是方案里缺少對現(xiàn)有約束的考慮。實操要點在提示詞里明確列出約束條件包括技術(shù)棧約束、性能約束、兼容性約束、時間約束。約束越明確方案越可落地。避坑指南不要接受第一個方案。讓AI生成至少三個方案然后從可行性、成本、風(fēng)險三個維度做對比。我通常會讓AI自己先做一輪對比分析然后人工再復(fù)核一遍。5.4 實現(xiàn)落地階段代碼生成的質(zhì)量控制這個階段的核心矛盾是生成速度和質(zhì)量之間的平衡。AI生成代碼很快但快不等于好。實操要點建立生成-評審-修正的小循環(huán)。每生成一個功能單元立刻做意圖一致性檢查通過了再進入下一個。不要一次性生成一大堆代碼再統(tǒng)一評審那樣問題會堆積。避坑指南AI生成的代碼必須過靜態(tài)檢查。我見過太多因為AI生成了看似合理但實際有安全漏洞的代碼而翻車的案例。靜態(tài)檢查工具要配置成強制門禁不通過不允許合并。5.5 驗證評測階段讓評測真正跑起來這個階段的關(guān)鍵是自動化。如果評測還需要人工觸發(fā)、人工判斷那它就不可能持續(xù)。實操要點把評測集成到CI/CD流水線里每次提交自動觸發(fā)。評測結(jié)果自動生成報告自動通知相關(guān)人。避坑指南評測用例要定期維護。AI生成的代碼在變評測用例也要跟著變。我建議每輪迭代都花一點時間清理過時的評測用例保持評測套件的有效性。5.6 反饋迭代階段讓每一輪都比上一輪好這個階段是閉環(huán)的收口。核心任務(wù)是從評測結(jié)果中提取可行動的改進項并把這些改進項分配到下一輪的相應(yīng)階段。實操要點建立改進項看板把評測報告里的問題轉(zhuǎn)化成具體的改進任務(wù)標注優(yōu)先級和負責人。避坑指南不要試圖一次性解決所有問題。每輪迭代聚焦解決最關(guān)鍵的三個問題比撒胡椒面式地修修補補有效得多。6. 常見問題與排查技巧實錄6.1 意圖漂移AI生成的內(nèi)容越來越偏離初衷這是最高頻的問題。表現(xiàn)是前幾輪生成的內(nèi)容還符合意圖越往后越跑偏。根本原因通常是intent.md沒有及時更新或者上下文包里混入了過時的信息。排查思路先檢查intent.md的變更記錄看最近一次更新是什么時候。如果超過兩輪迭代沒更新大概率是意圖漂移了。然后檢查上下文包看是否包含了已經(jīng)被廢棄的舊方案或舊代碼。解決方法建立意圖同步機制每輪迭代開始前強制更新intent.md并清理上下文包里的過時信息。6.2 評測假陽性測試通過了但實際有問題這種情況通常是因為評測用例覆蓋不全或者斷言寫得太寬松。比如只檢查了接口返回200沒檢查返回內(nèi)容是否正確。排查思路對通過的評測用例做抽樣人工復(fù)核看是否存在通過了但不對的情況。解決方法提高斷言的嚴格程度增加邊界用例和異常用例。我習(xí)慣在每輪迭代里隨機抽10%的通過用例做人工復(fù)核這個比例可以根據(jù)項目風(fēng)險等級調(diào)整。6.3 上下文超限信息太多導(dǎo)致生成質(zhì)量下降前面提過上下文不是越多越好。當上下文超過模型有效窗口的一定比例時生成質(zhì)量會明顯下降。排查思路記錄每次生成時的上下文長度和生成質(zhì)量評分找出質(zhì)量下降的拐點。解決方法建立上下文優(yōu)先級機制只投喂高優(yōu)先級信息。低優(yōu)先級信息可以摘要化處理或者放到外部知識庫里按需檢索。6.4 評測套件維護成本過高這是持續(xù)評測落地后的常見問題。評測用例越積越多維護成本越來越高最后沒人愿意維護評測就名存實亡了。排查思路統(tǒng)計評測用例的有效率即最近N輪迭代中真正發(fā)現(xiàn)過問題的用例比例。有效率低于某個閾值的用例考慮歸檔或刪除。解決方法建立評測用例的生命周期管理機制定期清理低效用例。同時把評測用例和intent.md的驗收標準做關(guān)聯(lián)驗收標準變更時自動標記相關(guān)用例需要復(fù)核。常見問題典型表現(xiàn)排查方向解決手段意圖漂移生成內(nèi)容逐漸偏離檢查intent.md更新記錄建立意圖同步機制評測假陽性通過但實際有問題抽樣人工復(fù)核提高斷言嚴格度上下文超限生成質(zhì)量下降記錄上下文長度與質(zhì)量建立優(yōu)先級機制評測維護成本高用例越積越多統(tǒng)計用例有效率生命周期管理6.5 團隊協(xié)作中的意圖理解偏差不同角色對intent.md的理解可能不一致。業(yè)務(wù)方關(guān)注功能技術(shù)方關(guān)注實現(xiàn)測試方關(guān)注驗證三方對同一條意圖聲明的解讀可能完全不同。排查思路在意圖評審階段做解讀對齊讓每個角色用自己的話復(fù)述對意圖的理解看是否存在偏差。解決方法在intent.md里為每條意圖聲明附上解讀示例用具體場景說明這條意圖在實際中意味著什么。解讀示例不需要覆蓋所有情況但至少要覆蓋最容易產(chǎn)生歧義的情況。7. 我在這套方法上踩過的坑和總結(jié)的經(jīng)驗先說一個最反直覺的體會這套方法最大的價值不在于讓AI生成得更好而在于讓團隊想得更清楚。我一開始以為intent.md是寫給AI看的后來發(fā)現(xiàn)它更大的作用是逼著團隊把意圖想明白。很多團隊在寫intent.md的過程中才發(fā)現(xiàn)原來大家對這個系統(tǒng)要做什么的理解根本不一致。第二個體會是持續(xù)評測的投入產(chǎn)出比在前期是負的在后期是正的。前兩輪迭代你會覺得評測拖慢了速度因為要寫用例、要跑評測、要分析報告。但從第三輪開始評測攔下來的問題開始超過它帶來的開銷ROI就轉(zhuǎn)正了。關(guān)鍵是熬過前期的負收益期。第三個體會是不要追求一步到位。我見過團隊試圖一次性把六個階段全部落地結(jié)果每個階段都做得半吊子。正確的做法是先落地意圖定義和持續(xù)評測這兩個最核心的環(huán)節(jié)跑通一輪完整迭代再逐步補齊其他階段。第四個體會是工具是次要的紀律是主要的。這套方法用Excel也能跑用最樸素的Markdown也能跑。真正難的不是工具是堅持每輪迭代都更新intent.md、都跑評測、都做回顧。我見過太多團隊工具鏈很先進但紀律松散最后效果還不如用Excel但紀律嚴明的團隊。最后一個實用建議從一個小項目開始試點。不要一上來就在核心項目上搞找一個邊界清晰、周期短、風(fēng)險低的小項目先跑一輪。跑通了有了體感再往大項目上推。我在一個小工具項目上跑了三輪把流程磨順了之后才推到主項目上省了很多溝通成本。這套東西后續(xù)還可以這樣擴展把intent.md和需求管理工具打通實現(xiàn)意圖的自動同步把評測結(jié)果和項目管理工具打通實現(xiàn)問題的自動創(chuàng)建和跟蹤把意圖偏差報告和迭代回顧會議打通實現(xiàn)改進項的自動提取。每一步擴展都不難難的是先把基礎(chǔ)流程跑順。