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