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