本文來自微信公眾號： 葉小釵 ，作者：葉小釵
最近國外大佬們又在搞事情：
他的大概意思是：
你不再需要為編碼智能體編寫提示詞了，你應(yīng)該設(shè)計(jì)循環(huán)來提示你的Agent
而后Addy Osmani又有一篇實(shí)踐案例被推崇：《Loop Engineering》，于是整個(gè)Loop Engineering就火了起來。
只不過就我研究下來，他們說的未必完全是同一件事，或者說大方向一樣，都是在回答Agent如何與人協(xié)作的問題，所以：
Loop Engineering可以被看作一次AI原生研發(fā)團(tuán)隊(duì)的實(shí)踐案例
或者說，是AI原生在研發(fā)協(xié)作場景里的一個(gè)具體切面
其實(shí)類似于《Loop Engineering》里面替代的案例，我已經(jīng)看了很多了，跟他類似的案例還有內(nèi)容團(tuán)隊(duì)圍繞著AIGC工作流做展開的案例。
于是這里真正的問題也就出來了：為什么當(dāng)前很多實(shí)踐案例全部是圍繞Agent展開的，更進(jìn)一步說是圍繞著Coding Agent展開的？
原因很簡單：現(xiàn)階段通用大模型基本能力包括通識、推理、成本、效率，都沒什么問題了，那么他一定會演進(jìn)為某“通用垂直領(lǐng)域的偏科模型”，而事實(shí)上也確實(shí)如此：
現(xiàn)階段基座模型有很大的精力都是圍繞Coding展開的
關(guān)于為什么選AI Coding，或者產(chǎn)研這個(gè)領(lǐng)域，之前我們也有過探討，無非是Coding首先最好做，其次他既是通用能力，又具備收集垂直領(lǐng)域知識的能力，什么意思呢？
意思是，GitHub提供了海量優(yōu)質(zhì)數(shù)據(jù)，搞Coding這批人對于程序員的KnowHow又尤其熟悉
最后就是一旦這個(gè)工作臺做好后，各行各業(yè)只要用它去實(shí)現(xiàn)業(yè)務(wù)，基模就有可能完成優(yōu)質(zhì)垂直領(lǐng)域數(shù)據(jù)收集
整個(gè)一套是陽謀，說實(shí)話挺聰明的，所以最近一年AI Coding演進(jìn)的速度很快，而從去年下半年開始就已經(jīng)有很多優(yōu)秀實(shí)踐案例了，比如《Loop Engineering》中提到的案例，又比如我們之前的實(shí)踐案例：
《AI Coding實(shí)戰(zhàn)：效率成本提升》
這里可以下個(gè)結(jié)論就是：AI Coding對于每個(gè)個(gè)人的效率提升的有效且夸張的！
但現(xiàn)在有個(gè)實(shí)際且尷尬的情況是：個(gè)人提效≠整體提效，現(xiàn)階段團(tuán)隊(duì)層面的提升，相較于個(gè)人就很不明顯了。
所以技術(shù)負(fù)責(zé)人的課題就出來了：團(tuán)隊(duì)要怎么和AI合作，這個(gè)問題比Coding工具選型更重要：
進(jìn)一步，我為什么會說思考清楚AI如何與團(tuán)隊(duì)協(xié)作更重要呢？
他們都在坑你
現(xiàn)階段市面上有很多坑逼，以《Loop Engineering》為例：
這篇文章很有啟發(fā)，但也很容易誤導(dǎo)團(tuán)隊(duì)
因?yàn)樗此瓢袰oding Agent如何循環(huán)起來講得很清楚，但卻隱去了很多細(xì)節(jié)，比如：
這個(gè)Loop到底運(yùn)行在什么組織環(huán)境里？
什么意思呢？意思是你正在做的工作，或者AI所需的運(yùn)行環(huán)境是誰在維護(hù)，這里有非常多的前提：
是一個(gè)人自己寫項(xiàng)目？
是兩三個(gè)人的小團(tuán)隊(duì)？
還是一個(gè)幾十人、上百人的產(chǎn)研團(tuán)隊(duì)？
是一個(gè)新項(xiàng)目？
還是一個(gè)跑了五六年的遺留系統(tǒng)？
是一個(gè)內(nèi)部工具？
還是一個(gè)有真實(shí)用戶、有線上SLA、有合規(guī)要求、有歷史包袱的生產(chǎn)系統(tǒng)？
這些問題不說清楚，Loop Engineering就很容易被理解成，按照那個(gè)老哥的方法論：
搭好Automations、Worktrees、Skills、Connectors、Sub-agents，再搞一個(gè)Memory，團(tuán)隊(duì)研發(fā)就能自動提效了。
這不是扯犢子嗎？？？
再比如Boris Cherny6個(gè)月沒打開IDE、一個(gè)人靠AI循環(huán)產(chǎn)出259個(gè)PR、497次提交、4萬行代碼。
這看起來很酷吧？但各位注意到關(guān)鍵詞了嗎：一個(gè)人，他說的是一個(gè)人呢，而你的工作環(huán)境是一個(gè)人嗎？
這就是問題所在：Loop Engineering的原始敘事，本質(zhì)上是一個(gè)單人超級程序員借助多智能體放大自身產(chǎn)能的故事，而不是一個(gè)多人異構(gòu)團(tuán)隊(duì)協(xié)作治理的故事。
就文章《Loop Engineering》中至少有三個(gè)被有意無意隱藏的關(guān)鍵前提：
一、Skill從哪來？誰來維護(hù)？
Loop的五個(gè)組件中，Skill負(fù)責(zé)把項(xiàng)目知識（代碼風(fēng)格、規(guī)范、架構(gòu)、踩過的坑）打包給Agent看。
原文說Agent每跑一遍都讀一次，無需每次都重新輸入，聽起來簡單。
但在真實(shí)團(tuán)隊(duì)中，這個(gè)Skill誰來寫？誰來評審？誰來保證它和實(shí)際代碼庫的一致性？
當(dāng)業(yè)務(wù)規(guī)則發(fā)生變化時(shí)，誰來更新？如果Skill寫錯(cuò)了，會不會扯皮，進(jìn)一步會不會內(nèi)耗？
二、誰來做最終驗(yàn)證？
Addy原文中其實(shí)也承認(rèn)了這一點(diǎn)：驗(yàn)證仍然在你身上。一個(gè)無人值守的循環(huán)也是一個(gè)在無人值守時(shí)犯錯(cuò)的循環(huán)。
他還警告說：Loop雖然很好，但是不要被其誘惑，變成不會思考、只會點(diǎn)開始鍵的人。
但在真實(shí)團(tuán)隊(duì)中，驗(yàn)證在你身上意味著什么？
意味著技術(shù)負(fù)責(zé)人要審核每一個(gè)Agent生成的PR？那和之前人在循環(huán)里的尷尬狀態(tài)有什么區(qū)別？
Loop Engineering并沒有回答：當(dāng)Loop同時(shí)跑幾十個(gè)任務(wù)時(shí)，人類有限的審閱帶寬如何跟得上？
所以說他們雞賊?。?/p>
三、token成本誰來買單？
Loop模式總token消耗是手動Prompt的3-8倍，單任務(wù)成本是人工的2-4倍。
Loop Engineering方向沒錯(cuò)，但你的團(tuán)隊(duì)適不適合，這個(gè)是要考慮的，因?yàn)閭€(gè)人的Loop和團(tuán)隊(duì)的Loop不可能是一個(gè)概念，只不過我們這里只是探討架構(gòu)，就不考慮成本問題了。
個(gè)人效率≠團(tuán)隊(duì)效率
Loop Engineering的原始案例Boris Cherny一個(gè)人搞259個(gè)PR，充分證明了AI是個(gè)人效率的極致放大；
但是當(dāng)10個(gè)工程師各自設(shè)計(jì)了自己的Loop，這些Loop之間如何協(xié)作？當(dāng)A的Loop改了一個(gè)公共模塊，B的Loop完全不知情，怎么辦？當(dāng)產(chǎn)品經(jīng)理的需求變更了，如何同步給所有正在運(yùn)行的Loop？
方向正確和實(shí)現(xiàn)簡單之間，隔著大量的工程細(xì)節(jié)，每個(gè)細(xì)節(jié)都能讓你在錯(cuò)誤的方向上耗幾個(gè)月
他們那套系統(tǒng)跟Loop Engineering的方法論很像，但他花了三個(gè)月才真正跑通，中間經(jīng)歷了十多次設(shè)計(jì)推翻。
這里的三個(gè)月+十幾次設(shè)計(jì)推倒，才是真實(shí)團(tuán)隊(duì)落地AI自動化的常態(tài)，而不是Boris Cherny那種刪掉IDE、259個(gè)PR的傳奇敘事：
綜上，Loop Engineering是一個(gè)美好愿望，他不看團(tuán)隊(duì)規(guī)模，但我們要看，因?yàn)榇髨F(tuán)隊(duì)和小團(tuán)隊(duì)在實(shí)施AI原生的過程中面臨的問題完全不同，比如：
skill的維護(hù)變成了一個(gè)需要版本管理和變更流程的工程項(xiàng)目
多Loop并行時(shí)，需要統(tǒng)一的上下文治理；
token成本變成了需要預(yù)算管理的財(cái)務(wù)問題；
不同Loop生成的代碼風(fēng)格和架構(gòu)一致性需要統(tǒng)一的規(guī)范約束；
......
所以，真正的問題不是要不要搞Loop，而是應(yīng)該如何搞，或者說要搞Loop需要補(bǔ)足什么，于是這里再次回到了之前的課題：AI如何與團(tuán)隊(duì)協(xié)作更重要呢？
關(guān)于這個(gè)課題，我們之前就給出了答案：SDD。
組織級補(bǔ)?。篠DD
很多人一聽到SDD，就容易把它理解成先寫一堆文檔。PRD、技術(shù)方案、架構(gòu)文檔、測試文檔，然后用這些文檔去讓AI生成代碼。
這個(gè)理解，你不能說它錯(cuò)了，但確實(shí)過于簡單粗暴些。真正的SDD想解決的是AI編程進(jìn)入真實(shí)團(tuán)隊(duì)項(xiàng)目后所面臨的核心問題：
AI到底應(yīng)該基于什么上下文去開展工作？
AI到底應(yīng)該恪守的邊界是什么？哪些有所為，哪些不能為？
AI生成的結(jié)果，到底應(yīng)該用什么標(biāo)準(zhǔn)去判斷對錯(cuò)？
到了團(tuán)隊(duì)級別的AI提效，一個(gè)長期穩(wěn)定、可追溯、可復(fù)用的標(biāo)準(zhǔn)交付流程就很重要了：
為什么需要SDD
多數(shù)同學(xué)開啟AI編程都很幼稚：一句話生成頁面、修復(fù)bug、補(bǔ)全測試...
在這個(gè)階段，開發(fā)者通過自然語言描述意圖，AI快速生成代碼，人類再調(diào)整。功能邊界小，影響面簡單，效率提升非常明顯。
但進(jìn)入團(tuán)隊(duì)開發(fā)，項(xiàng)目變大變復(fù)雜后，問題就來了：
AI不知道哪個(gè)模塊不能隨便改動，因?yàn)楸欢鄠€(gè)應(yīng)用共享；
AI不知道哪些接口要做兼容；
AI不知道哪些組件是共性的、需要復(fù)用而不是重寫；
AI也不知道某些看起來別扭的業(yè)務(wù)邏輯，恰恰是因?yàn)榻鉀Q過特定線上問題才長成那樣的。
AI當(dāng)前最大的問題不是輸出速度，這是從底層實(shí)現(xiàn)上釘死了的，他只解決了干得快的問題，不解決干得對的問題：
所以說，Coding Agent被設(shè)計(jì)成協(xié)作型Agent，其原因就是需要人去補(bǔ)足，那么補(bǔ)足的是什么呢？補(bǔ)足的是邊界與標(biāo)準(zhǔn)，用各種約束盡量去解決AI的不可控性。
而SDD就是為此而生，他提供一整套完整的方法論：共享上下文、共享規(guī)則、共享邊界、共享驗(yàn)收標(biāo)準(zhǔn)。
在這個(gè)基礎(chǔ)下，我們再探討SDD是什么就順滑得多了：
SDD到底是什么？
SDD：Spec-Driven Development，規(guī)格驅(qū)動開發(fā)，他是一套方法論；Spec是這套方法論的核心產(chǎn)物。
他是為了解決我們前面所說的問題而生，這些問題包括：文檔寫完沒人看、和代碼脫節(jié)、更新不及時(shí)、難以驗(yàn)證、只是溝通材料...
這里的Spec是研發(fā)流程里的事實(shí)真相，它有三個(gè)核心角色：
第一，Spec是上下文。
它告訴AI：業(yè)務(wù)目標(biāo)是什么？當(dāng)前需求解決什么問題？哪些范圍可以改、哪些不能動？系統(tǒng)有什么歷史約束？接口、數(shù)據(jù)、權(quán)限、狀態(tài)如何定義？
第二，Spec是協(xié)作契約。
它讓產(chǎn)品、研發(fā)、測試、架構(gòu)、AI這些不同角色圍繞同一份理解展開工作——而不是產(chǎn)品說一套、研發(fā)理解一套、AI生成一套、測試驗(yàn)另一套。
第三，Spec是質(zhì)量基準(zhǔn)。
它定義了什么叫做"完成"：功能是否滿足？邊界是否覆蓋？接口是否兼容歷史？性能是否達(dá)標(biāo)？安全合規(guī)是否達(dá)到？測試是否通過？
SDD的關(guān)鍵，在于這些規(guī)格能不能真正進(jìn)入有AI參與的工作流，成為代碼生成、驗(yàn)收和演進(jìn)的依據(jù)。
TDD和BDD
這里也順便說下TDD和BDD，畢竟他們看著單詞挺像的：
TDD的重點(diǎn)是先寫測試再寫實(shí)現(xiàn)，它解決的是代碼到底有沒有按預(yù)期工作。
但TDD更靠近技術(shù)實(shí)現(xiàn)層，對產(chǎn)品方和業(yè)務(wù)方不夠友好，而且測試用例本身也很依賴研發(fā)對需求的理解能力，所以現(xiàn)在不太使用，畢竟測試這個(gè)工種都要被干沒了。
BDD是用行為場景對齊業(yè)務(wù)理解。
它通過Given-When-Then這樣的方式，把業(yè)務(wù)行為表達(dá)出來，讓業(yè)務(wù)和研發(fā)圍繞用戶場景達(dá)成一致。
BDD解決的是業(yè)務(wù)行為有沒有被正確理解。
但BDD主要停留在場景和測試層，對代碼實(shí)際編寫過程中的架構(gòu)約束、代碼結(jié)構(gòu)、上下文治理，以及AI協(xié)作支持有限。
而SDD關(guān)注的問題更偏上游，他把要做什么、不能做什么、怎么判斷完成這幾個(gè)問題進(jìn)一步前移，并讓這些內(nèi)容友好的被AI消費(fèi)，所以最終他勝出了。
了解了SDD后，我們再說下實(shí)操問題。
Spec應(yīng)該怎么寫？
根據(jù)幾個(gè)學(xué)員SDD實(shí)踐情況來說，很多團(tuán)隊(duì)會踩一個(gè)常見的坑：以為Spec越長越好。
這不是的，內(nèi)容越多，審閱壓力越大。有價(jià)值的Spec，不以長短做依據(jù)，核心還是要圍繞AI輸出的穩(wěn)定性出發(fā)。
經(jīng)過實(shí)踐，有六點(diǎn)心得可供參考：
一、目標(biāo)：這個(gè)需求要達(dá)到什么效果？
第一點(diǎn)是要說清楚用戶、系統(tǒng)或業(yè)務(wù)流程在需求完成后能獲得什么能力。
錯(cuò)誤寫法：新增管理后臺商品訂單詳情頁。
更好的寫法：為運(yùn)營人員提供商品訂單詳情查看能力，支持查看訂單狀態(tài)、支付狀態(tài)、物流狀態(tài)和異常原因，便于定位履約問題。
二、范圍：這次做什么，不做什么
AI太容易過度發(fā)揮了，所以除了告訴它做什么，第二重要的事就是告訴它不做什么。
例如：本期只支持查看，不支持編輯訂單；本期只支持手機(jī)號驗(yàn)證碼登錄，不要密碼登錄及任何第三方快捷登錄。
三、約束：AI必須遵守的邊界
這里沒什么好說的，直接舉個(gè)例子吧：
涉及用戶敏感信息的數(shù)據(jù)，落庫時(shí)必須加密存儲，前端展示時(shí)必須脫敏；調(diào)用外部AI接口的超時(shí)時(shí)間必須控制在15秒內(nèi)，超時(shí)或不可用時(shí)觸發(fā)降級策略，嚴(yán)禁阻塞主流程。
四、決策：不允許AI重新設(shè)計(jì)
AI很容易在執(zhí)行時(shí)重新做架構(gòu)設(shè)計(jì)。
所以需要明確：使用哪個(gè)表、復(fù)用哪個(gè)組件、使用哪個(gè)狀態(tài)枚舉、接口路徑如何命名。
五、任務(wù)：拆解小任務(wù)
不要讓AI一次性完成大功能。
雖然現(xiàn)在模型支持百萬級上下文，但隨著上下文增長，幻覺問題會越來越嚴(yán)重。
應(yīng)該讓AI在較低的上下文體量下完成單個(gè)任務(wù)：數(shù)據(jù)模型調(diào)整、接口定義、前端頁面編寫、測試用例，逐項(xiàng)推進(jìn)。
六、驗(yàn)收
寫清楚：正常流程怎么驗(yàn)、異常流程怎么驗(yàn)、邊界場景有哪些、哪些需要自動化測試、是否需要端到端驗(yàn)證、是否需要灰度或監(jiān)控。
綜上，就是如何寫好一個(gè)Spec的建議，Spec的價(jià)值是明確告知哪些事不能靠猜。
大家照著目標(biāo)、范圍、約束、決策、任務(wù)、驗(yàn)收來就行，這六個(gè)部分構(gòu)成了Spec的基本骨架。
全鏈路研發(fā)協(xié)作
前面聊了Spec怎么寫、SDD是什么，但這些都還停留在怎么把需求說清楚的層面，接下來我們看看Spec如何影響團(tuán)隊(duì)協(xié)作。
一、客服反饋案例
客服在群里反饋一個(gè)問題：用戶說訂單詳情頁打不開，你們看看是不是系統(tǒng)Bug？而這句話本身是沒法直接進(jìn)入研發(fā)流程的。
研發(fā)接到以后會有一套SOP：
是不是操作問題；
重啟后會不會發(fā)生；
確實(shí)沒辦法才會動手走后續(xù)；
哪個(gè)用戶？哪個(gè)訂單？什么環(huán)境？有沒有截圖？
是所有用戶都有問題還是個(gè)別用戶？
最近有沒有發(fā)布？日志有沒有異常？
客服說的是現(xiàn)象，研發(fā)關(guān)心的是復(fù)現(xiàn)路徑，技術(shù)Leader關(guān)注有沒有鍋，但無論如何都會有很多角色參與其中，這些信息全部靠群聊來回補(bǔ)。
但在AI參與的鏈路里，Agent收到這條反饋后，新的SOP就開始了，我們會按規(guī)則把這條反饋整理成一個(gè)輕量Spec（有模板）：
問題現(xiàn)象：訂單詳情頁打開失敗；
影響對象：某一類訂單、某一批用戶，還是所有用戶；
復(fù)現(xiàn)路徑：從哪個(gè)入口進(jìn)入，執(zhí)行了什么操作；
相關(guān)上下文：訂單狀態(tài)、用戶身份、客戶端版本、最近發(fā)布記錄；
初步判斷：前端展示問題、接口異常、數(shù)據(jù)異常，還是權(quán)限問題；
修改范圍：涉及哪些模塊，哪些模塊不能動；
驗(yàn)收標(biāo)準(zhǔn)：什么情況下算修復(fù)完成；
風(fēng)險(xiǎn)提示：是否影響核心流程，是否需要灰度和回滾。
這就是Spec的第一個(gè)價(jià)值：把非結(jié)構(gòu)化反饋，變成結(jié)構(gòu)化任務(wù)。
二、Spec在鏈路里怎么流轉(zhuǎn)
如果把從反饋到上線的過程拉通，Spec的流轉(zhuǎn)鏈路是這樣的：
第一步，信息收集。
Agent先接收問題，自動追問必要信息，比如訂單號、報(bào)錯(cuò)時(shí)間、操作路徑、客戶端版本...
第二步，初步判斷。
Agent結(jié)合日志、接口返回、最近發(fā)布記錄、代碼變更，先判斷問題屬于哪一類：用戶操作問題？配置問題？數(shù)據(jù)問題？產(chǎn)品體驗(yàn)問題？代碼Bug...
如果不是Bug，Agent生成解釋口徑同步給客服；如果是Bug，進(jìn)入下一步。
第三步，生成Spec。
Agent把問題整理成一份輕量Spec，進(jìn)入研發(fā)流程。
研發(fā)看到的是一份已經(jīng)整理過的工程任務(wù)：問題現(xiàn)象、影響范圍、復(fù)現(xiàn)路徑......
這個(gè)模板越詳細(xì)，研發(fā)乃至后續(xù)AI自動化的效率越高。
第四步，邊界確認(rèn)。
如果問題簡單，Agent直接基于Spec生成修復(fù)方案；
如果問題復(fù)雜（涉及訂單狀態(tài)、支付鏈路），Agent先把方案發(fā)給研發(fā)確認(rèn)，不直接改。
第五步，執(zhí)行修復(fù)。
研發(fā)確認(rèn)邊界后，AI再開始基于Spec去執(zhí)行，Spec里已經(jīng)寫清楚了目標(biāo)、范圍、約束、決策和驗(yàn)收。AI知道解決什么問題，也知道哪些地方不能碰，這時(shí)候Loop才有意義。
第六......
后續(xù)模塊就不贅述了，大家應(yīng)該能夠理解SDD是如何參與AI協(xié)作的了。
三、代碼只是過程量
在這個(gè)鏈路里，寫代碼僅僅是很小的一環(huán)。
在案例中，AI參與了問題識別、上下文整理、任務(wù)拆解、邊界確認(rèn)、測試驗(yàn)收和經(jīng)驗(yàn)沉淀，那它改變的就是整個(gè)團(tuán)隊(duì)的信息流轉(zhuǎn)方式。
這里我需要再強(qiáng)調(diào)一下：
需要改造整個(gè)團(tuán)隊(duì)的信息流轉(zhuǎn)方式，以去更好的適應(yīng)AI帶來的效率
個(gè)人提效看的是AI輸出快不快；團(tuán)隊(duì)提效看的是從問題出現(xiàn)到問題解決，整個(gè)鏈路有沒有更短、更穩(wěn)。
SDD的三個(gè)層次
前面講了全鏈路里Spec怎么流轉(zhuǎn)，但不同團(tuán)隊(duì)落地的深度不一樣。根據(jù)實(shí)際情況，SDD可以分成三個(gè)層次：
第一層：Spec First，規(guī)格先行。
這是大部分團(tuán)隊(duì)的起手式。先寫需求規(guī)格，再讓AI生成方案、拆任務(wù)。
這個(gè)層次解決的核心問題是需求別做偏，適合新功能、中大型需求、獨(dú)立模塊、邊界相對明確的迭代。
第二層：Spec-Anchored，規(guī)格錨定。
這一層比Spec First更進(jìn)一步。規(guī)格不再是單次輸入，而是整個(gè)需求、缺陷、重構(gòu)、測試的長期錨點(diǎn)。
功能上線后，規(guī)格作為系統(tǒng)資產(chǎn)持續(xù)維護(hù)，改模塊前先看規(guī)格，AI理解模塊也要先讀規(guī)格，測試補(bǔ)用例也基于規(guī)格編寫。
第三層：Spec as Source，規(guī)格即源碼。
這是SDD的終極形態(tài)。人只維護(hù)規(guī)格，所有代碼由工具生成。
但在大多數(shù)業(yè)務(wù)系統(tǒng)里，這個(gè)階段很難一步到位，畢竟歷史包袱、隱性規(guī)則、工程妥協(xié)、非標(biāo)準(zhǔn)實(shí)現(xiàn)太多了，沒法完全靠規(guī)格生成所有代碼。
不是所有任務(wù)都需要SDD
還有一個(gè)重要前提需要說清楚：如果所有需求都套進(jìn)完整規(guī)格流程，那原本的AI提效就會變成文檔負(fù)擔(dān)。
比如：改個(gè)文案也要寫完整規(guī)格？沒必要吧。所以SDD按任務(wù)復(fù)雜度又可以做分級：
小改動，比如改文案、調(diào)樣式。這類任務(wù)用Prompt就足夠了，最多補(bǔ)充一下目標(biāo)、影響文件，以及告訴AI不要改哪些地方。
中等需求，比如新增一個(gè)接口、調(diào)整一個(gè)流程。需要輕量規(guī)格：目標(biāo)、影響范圍、約束、驗(yàn)收標(biāo)準(zhǔn)，四樣寫清楚。讓AI先出計(jì)劃，人確認(rèn)以后再實(shí)現(xiàn)。
大型任務(wù)，比如新模塊開發(fā)、多端業(yè)務(wù)聯(lián)動、新業(yè)務(wù)流程接入。需要完整規(guī)格：需求規(guī)格、技術(shù)方案、接口契約、數(shù)據(jù)模型、任務(wù)拆解、測試策略、發(fā)布方案、回滾方案。
成熟團(tuán)隊(duì)需要能根據(jù)任務(wù)復(fù)雜度選擇合適的規(guī)格強(qiáng)度。
難在維護(hù)
只要做過文檔管理的同學(xué)都會清楚：所有的知識類管理的難度一定不是寫而是數(shù)據(jù)更新！
SDD的核心難點(diǎn)也是如此，如何讓規(guī)格長期穩(wěn)定維護(hù)，始終是項(xiàng)目里的真實(shí)來源（Source of Truth），這個(gè)會是AI負(fù)責(zé)人長期的命題，他的背后是管理成本的持續(xù)投入。
如果你的老板以為AI自動化/SDD是一次性工作，那多半要完?duì)僮?..
落地SDD的四步路徑
說了這么多問題，來聊點(diǎn)實(shí)在的：想落地SDD，怎么開始？
第一步，選一個(gè)高價(jià)值場景做切入點(diǎn)。
不要一上來就搞完整流程。先選一個(gè)場景試點(diǎn)，比如：新模塊開發(fā)、遺留系統(tǒng)遷移、外部平臺接入。
這些場景的共同點(diǎn)是：復(fù)雜度高、溝通成本高、返工成本高、上下文容易丟，在這里引入SDD，價(jià)值體現(xiàn)最明顯。
第二步，定義輕量Spec模板。
不需要很復(fù)雜，先把關(guān)鍵問題固定下來：
背景與目標(biāo)、本期范圍、明確不做、業(yè)務(wù)規(guī)則、技術(shù)約束、接口和數(shù)據(jù)影響、任務(wù)拆解、驗(yàn)收標(biāo)準(zhǔn)、風(fēng)險(xiǎn)與回滾。
模板不需要每次全填滿，但只有這個(gè)模板，有沒有AI效率都會提示。
第三步，建立項(xiàng)目級上下文。
真正持續(xù)提升AI研發(fā)質(zhì)量的，是項(xiàng)目級的上下文資產(chǎn)：項(xiàng)目原則、架構(gòu)約束、目錄規(guī)范、接口規(guī)范、權(quán)限模型、狀態(tài)機(jī)、錯(cuò)誤碼、數(shù)據(jù)字典。
這些內(nèi)容一旦沉淀下來，就可以反復(fù)喂給AI作為所有需求的基礎(chǔ)上下文，比每次從零解釋項(xiàng)目背景高效得多。
第四步，把Spec納入研發(fā)流程，明確人工卡點(diǎn)。
需求進(jìn)入開發(fā)前先寫輕量Spec，AI輔助補(bǔ)充遺漏邊界和風(fēng)險(xiǎn)。產(chǎn)品、研發(fā)、測試評審關(guān)鍵邊界。AI基于Spec生成計(jì)劃和任務(wù)。
開發(fā)過程中持續(xù)更新Spec，測試基于Spec生成用例。發(fā)布后把長期有價(jià)值的內(nèi)容沉淀到項(xiàng)目上下文。
AI進(jìn)入組織
前面花了很多篇幅在介紹SDD，甚至用他去復(fù)刻了Loop工程類似的案例，搞這么多事情的目的只有一個(gè)，告訴技術(shù)負(fù)責(zé)人，你需要關(guān)注：
AI應(yīng)該在什么規(guī)則下參與研發(fā)流程？
而SDD的價(jià)值就在這里，他的意思是：你如果沒有方法論，那就用我這一套，其本質(zhì)也是去構(gòu)造信息流，構(gòu)造AI需要的環(huán)境。
Loop Engineering這東西給了個(gè)美好的愿望，但他更多是一人和AI的狂歡，這里確實(shí)會很歡，但他意義有限。
如果要讓這個(gè)美好的愿望更多更大，那就一定要解決信息通道建設(shè)的問題，而SDD應(yīng)運(yùn)而生，但他其實(shí)也只是解決了產(chǎn)研體系的工作。
綜上，SDD可以協(xié)助我們完成研發(fā)團(tuán)隊(duì)的全鏈路AI升級
那么，更大范圍，比如企業(yè)級的方法論是什么，或者說更宏觀的視角是什么樣的呢？
AI原生：更高的視角
其實(shí)無論是Loop工程還是SDD，他們最終要解決的問題都是一個(gè)：大模型這個(gè)跨時(shí)代的技術(shù)進(jìn)入組織后引起的復(fù)雜度如何消化？
大家這里可能不太懂，我們補(bǔ)兩個(gè)案例：
一開始，AI只是進(jìn)入工作任務(wù)：寫文檔、寫代碼，效率很高；
然后，AI開始進(jìn)入流程：它開始改變輸入、輸出、協(xié)作、交付和驗(yàn)收標(biāo)準(zhǔn)；
從這里開始就不僅是工具導(dǎo)入的問題，影響面開始從個(gè)人到組織，這里會涉及機(jī)制流程，會引發(fā)很多人的不適感，最終體現(xiàn)出來的就是各種管理成本。
PS：《Loop工程》里面的案例更多是在這里打轉(zhuǎn)
再往后，AI會進(jìn)入組織：它會沖擊角色邊界、責(zé)任邊界、資源調(diào)度和評價(jià)體系；
所以AI進(jìn)入組織:
最初是單點(diǎn)效率提升；
其次是組織為匹配個(gè)人效率提升最初的機(jī)制流程改變；
然后是整個(gè)公司為了適應(yīng)AI而宣布新的組織結(jié)構(gòu)；
最后是穩(wěn)定后整個(gè)評價(jià)體系基于新技術(shù)的重塑；
從這里大家再看看Loop工程和SDD的關(guān)系：
Loop工程描述的是一個(gè)效率超高的美好愿望
SDD是在實(shí)現(xiàn)這個(gè)愿望過程中所爆發(fā)的問題的某種解法
進(jìn)一步來說他遭遇的是AI工具在促使個(gè)人提效后，如何轉(zhuǎn)向組織提效過程中的信息流建設(shè)方法論
總結(jié)一下，AI進(jìn)入組織以后，是一個(gè)連續(xù)爬坡的過程，他會分為四層：
第一層解決個(gè)人工具問題，會暴露團(tuán)隊(duì)協(xié)作問題；
第二層解決流程標(biāo)準(zhǔn)問題，會暴露組織邊界問題；
第三層解決組織協(xié)作問題，會暴露專業(yè)評價(jià)問題；
第四層解決評價(jià)權(quán)專業(yè)問題，又會最終暴露商業(yè)模式問題；
這里如果要展開會很復(fù)雜，但只要大家想實(shí)現(xiàn)Loop工程的目標(biāo)，就一定會遭遇這四層循環(huán)，并且不用著急：上一層的問題解決以后，會把下一層的問題推出來。
并且，這些問題并不是AI帶來的，就我對管理及AI的認(rèn)知，我會認(rèn)為：組織原本就存在的問題。
只是過去這些問題可以被低效率掩蓋，但AI進(jìn)來以后，某些節(jié)點(diǎn)突然變快了，舊系統(tǒng)的不均衡就被放大了，所以你想推AI原生，就必須關(guān)注到每一層的問題，解決每一層的問題：
結(jié)語
AI Coding把代碼寫快了，但交付并沒有等比例變快，最終結(jié)構(gòu)是：
個(gè)人提效≠整體提效
現(xiàn)階段，寫代碼不是瓶頸，所以瓶頸在往他的上下游延伸，而解決的方法就是構(gòu)建規(guī)則和信息流。