你與大模型聊天干活的記錄，或許可用于做一次新的“MBTI”性格測(cè)試。當(dāng)駕馭工程的不少事兒都能交給 AI 工具去做，我們只需要“觀測(cè)”與“控制”，迎接“人人都是技術(shù)管理者”的時(shí)代。

作者 | 任晶磊

轉(zhuǎn)載 | 思碼逸研發(fā)效能

以前，寫代碼的都是工程師，純純的“人治”時(shí)代。

現(xiàn)在 AI 可以代勞大多數(shù) Coding 工作，未來勢(shì)必成為研發(fā)的“主力軍”。工程師以后可能只參與 10% 的工作，甚至更少。 這種變化將徹底改變我們生產(chǎn)軟件的方式，管理和衡量研發(fā)效能的老辦法也要升級(jí)。

現(xiàn)在最讓人頭疼的問題是：人和 AI 一起干活，自由發(fā)揮靠“手感”，我們?cè)趺粗?AI 用法好不好？效能發(fā)揮出來多少？

不論從企業(yè)還是個(gè)人視角，這都是大家面臨的一個(gè)棘手問題。

研發(fā)過程變“AI 黑盒”，麻煩在哪？

AI 寫代碼確實(shí)快，門檻也低了。但它怎么寫的，我們看不清，整個(gè)開發(fā)過程就像一個(gè)不可見的“黑盒”。

1. 協(xié)作過程不好管：大部分團(tuán)隊(duì)用 AI 寫代碼是靠“手感”的。跟 AI 怎么互動(dòng)、能否有效生成好代碼都看不清，各人有各自的“土辦法”。這導(dǎo)致有人 AI 用得好，有人用得差，代碼產(chǎn)出和質(zhì)量參差不齊。過程沒法控，結(jié)果不好預(yù)期，也影響經(jīng)驗(yàn)積累。

2. 提效成果說不清：AI 應(yīng)當(dāng)用在哪、怎么用，業(yè)界還沒有形成統(tǒng)一的方法，各家各類項(xiàng)目本就情況不同。AI 在研發(fā)各個(gè)環(huán)節(jié)到底能帶來什么價(jià)值，如果缺乏明確的指標(biāo)去衡量，就會(huì)導(dǎo)致研發(fā)管理者很難說清楚 AI 到底提效多少，更別提在這個(gè)基礎(chǔ)上進(jìn)行團(tuán)隊(duì)管理和向上匯報(bào)了。

3. 轉(zhuǎn)型 AI-Native 走不快： 團(tuán)隊(duì)缺乏 AI 應(yīng)用的參考和培訓(xùn)，也很難高效找到適合組織的協(xié)作模式。如果還用老一套的研發(fā)流程，組織層面就形不成合力，向 AI 原生轉(zhuǎn)型也就成了空談。

“三級(jí)跳”，你到了哪一步？

最近常聽到客戶向我們?cè)儐柸绾谓y(tǒng)計(jì) AI 代碼占比、AI 時(shí)代的工具鏈如何構(gòu)建、企業(yè)應(yīng)關(guān)注什么新指標(biāo)等問題。其實(shí)這些問題的答案，與企業(yè)當(dāng)前研發(fā)中 AI 滲透的程度密切相關(guān)。

在展開討論之前，我們首先需要一個(gè)坐標(biāo)系來定位團(tuán)隊(duì)所處的位置。回顧過去兩年，AI Coding 工具發(fā)展大體經(jīng)歷了三代。相應(yīng)地，研發(fā)團(tuán)隊(duì) AI 實(shí)踐的程度可以劃分為三個(gè)階段，輔以“AI 代碼占比”這個(gè)大家普遍關(guān)心的指標(biāo)，我們對(duì)三個(gè)階段描述如下表。

對(duì)于后兩個(gè)階段，度量“AI 代碼占比”的意義已經(jīng)不大，而無人干預(yù)任務(wù)執(zhí)行的時(shí)長(zhǎng)會(huì)成為更能反映 AI 實(shí)踐水平和實(shí)際價(jià)值的指標(biāo)。

在第一階段，由于人站在主控位，AI 行為大多處于“白盒”狀態(tài)；而在后兩個(gè)階段，人逐步退出 coding 環(huán)節(jié)，對(duì)代碼細(xì)節(jié)的了解日益模糊，對(duì) AI 行為的可觀測(cè)性需求就會(huì)凸顯出來。

可觀測(cè)性：從外部破解“黑盒”

可觀測(cè)性與可控制性是源自控制理論的一對(duì)基礎(chǔ)概念。之前伴隨微服務(wù)等分布式系統(tǒng)興起以及 DevOps 的廣泛實(shí)踐，可觀測(cè)性已逐漸為廣大開發(fā)者所熟知，也誕生了一批有代表性的工具。它們通常包含日志、追蹤和指標(biāo)三個(gè)基礎(chǔ)模塊，同樣適用于 AI 系統(tǒng)。

今天人與 AI 的交互日益復(fù)雜，而人又將撤出大部分環(huán)節(jié)，只有保持開發(fā)過程的可觀測(cè)性，才有可能回答技術(shù)團(tuán)隊(duì)關(guān)切的問題。

根據(jù)控制理論的基本要素和可觀測(cè)性的概念——能否通過系統(tǒng)的外部輸出推斷其內(nèi)部狀態(tài)，我們對(duì)智能開發(fā)的可觀測(cè)性做出如下定義：

• 系統(tǒng)：人與 AI 協(xié)作開發(fā)軟件的過程

• 狀態(tài)：人的意圖，AI 的理解，設(shè)計(jì)、決策、計(jì)劃、執(zhí)行狀態(tài)，開發(fā)過程中的記憶與知識(shí)

• 輸入：給 AI 的提示詞、上下文，直接對(duì)代碼、規(guī)約（spec）、文檔等所做的修改

• 輸出：生成的代碼、規(guī)約、文檔等軟件制品，AI 交互追蹤、日志和指標(biāo)

（注：代碼、規(guī)約等既作為一個(gè)狀態(tài)的輸出，也可能作為下一個(gè)狀態(tài)的輸入）

可觀測(cè)性希望回答一個(gè)問題：我們能否在足夠充分地還原 AI 與人協(xié)作過程中的狀態(tài)，從而發(fā)現(xiàn)問題、持續(xù)改進(jìn)并實(shí)證提升效果？

當(dāng)一個(gè)任務(wù)執(zhí)行了 30 輪對(duì)話、100 次工具請(qǐng)求、花費(fèi)已超過千萬 token，是不是大模型鉆進(jìn)了“死胡同”？任務(wù)該不該中止交由人干預(yù)？ AI coding 的很多失敗并不是明顯的“報(bào)錯(cuò)”，而是“看起來像對(duì)的”。代碼也許能跑，解釋也許很順，但它能通過驗(yàn)收測(cè)試嗎？ 團(tuán)隊(duì)成員使用 AI 的經(jīng)驗(yàn)有長(zhǎng)有短，誰用的 ROI 最高？有什么經(jīng)驗(yàn)可以提取和分享？

回答這些問題的關(guān)鍵在于建立洞察指標(biāo)?？捎^測(cè)性需要以收集人和 Coding Agent 的行為數(shù)據(jù)為基礎(chǔ)，但關(guān)鍵和最大挑戰(zhàn)不在于“追蹤多少日志”。指標(biāo)把零散的過程信息轉(zhuǎn)化為可以分析、比較和改進(jìn)的依據(jù)，并且相對(duì)于人工或 AI 掃讀日志更加簡(jiǎn)單易行，成本也更低。

這里的指標(biāo)集應(yīng)包含過程指標(biāo)、結(jié)果指標(biāo)以及兩者的組合，它們對(duì)于多維度系統(tǒng)洞察不可或缺。我們這里列舉一些典型的指標(biāo)。

• 規(guī)約符合度。規(guī)約（specification）是對(duì)軟件需求、系統(tǒng)設(shè)計(jì)的自然語言描述，應(yīng)按約定格式逐項(xiàng)列出，類似于“需求條目化”；同時(shí)不宜陷入實(shí)現(xiàn)細(xì)節(jié)。規(guī)約項(xiàng)（spec item）是保證意圖表達(dá)清晰、AI 行為可控、可觀測(cè)、可度量的基礎(chǔ)。對(duì)規(guī)約格式的約定就像傳統(tǒng)軟件開發(fā)中的編碼規(guī)范，開發(fā)者和 AI 都應(yīng)當(dāng)遵守，建議參考 GEARS——將業(yè)界已廣泛采用多年的需求表達(dá)式 EARS 擴(kuò)展適配規(guī)約的一種格式。借助 AI 本身，我們完全可以做到規(guī)約項(xiàng) 100% 符合規(guī)范。以下是一個(gè)符合 GEARS 語法的規(guī)約項(xiàng)示例：

Where the user has granted file system access, when the user requests code generation, the coding agent shall write output to the specified file. 在用戶被授予文件系統(tǒng)訪問權(quán)限的情況下，當(dāng)用戶請(qǐng)求代碼生成，編程智能體將把輸出寫入指定文件。

• 規(guī)約項(xiàng)數(shù)。規(guī)約的完整性和顆粒度需要人結(jié)合項(xiàng)目實(shí)際情況進(jìn)行把握。規(guī)約項(xiàng)數(shù)過少、描述太籠統(tǒng)，不利于 AI 可靠地實(shí)現(xiàn)；規(guī)約項(xiàng)目過多、描述太細(xì)節(jié)，會(huì)給人的審核與后期維護(hù)增加大量負(fù)擔(dān)。為此，我們可以計(jì)算規(guī)約代碼比，即規(guī)約項(xiàng)數(shù)除以對(duì)應(yīng)的代碼變更規(guī)模。規(guī)約代碼比的范圍目前還沒有業(yè)界統(tǒng)計(jì)，研發(fā)團(tuán)隊(duì)可以著眼自身項(xiàng)目，從時(shí)間等維度進(jìn)行觀察、對(duì)比和調(diào)整。

• 規(guī)約測(cè)試覆蓋度。當(dāng)智能開發(fā)進(jìn)入到上述第二階段或第三階段時(shí)，人已經(jīng)趕不上細(xì)讀智能體生成的每一行代碼；相應(yīng)地，處理同量級(jí)信息的代碼審查（review）環(huán)節(jié)也將交給 AI 完成。人將主要專注于信息少一個(gè)數(shù)量級(jí)的需求和驗(yàn)證，保證每一個(gè)描述需求或系統(tǒng)的規(guī)約項(xiàng)都有對(duì)應(yīng)的測(cè)試用例，而測(cè)試用例也可以用規(guī)約描述。通過解析符合格式規(guī)范的規(guī)約項(xiàng)，我們可以計(jì)算出多大比例的需求或系統(tǒng)規(guī)約項(xiàng)被對(duì)應(yīng)的測(cè)試覆蓋。借助 AI，我們完全可以實(shí)現(xiàn) 100% 自動(dòng)化覆蓋，這也是智能開發(fā)時(shí)代“質(zhì)量左移”的一種形式。

• 代碼當(dāng)量。是不是代碼都靠 AI 生成之后，度量代碼規(guī)模就變得不再重要了呢？這是一種表面化的關(guān)聯(lián)，甚至?xí)砗艽箫L(fēng)險(xiǎn)。代碼寫得快慢與代碼如何治理是兩件事情，如果因?yàn)?AI 寫代碼快，就降低代碼治理的標(biāo)準(zhǔn)，完全是背道而馳。亞馬遜接連出現(xiàn)事故并禁止初級(jí)程序員用 AI 提交代碼就是前車之鑒。當(dāng)量作為代碼規(guī)模的基礎(chǔ)指標(biāo)，對(duì)評(píng)估變更大小、質(zhì)量（如千當(dāng)量 bug 率）、需求顆粒度等都很重要。當(dāng)然，代碼當(dāng)量的算法需要抵御用 AI 低成本增刪代碼帶來的 code churn，這也是需要程序分析而不是簡(jiǎn)單數(shù)行數(shù)的原因之一。

• 每提交對(duì)話輪數(shù)、token 用量、工具（MCP/CLI）調(diào)用次數(shù)、skill 數(shù)量等。這些是反映 AI agent 工作過程的指標(biāo)，可作為日常監(jiān)測(cè)手段，發(fā)現(xiàn)異常情況時(shí)查找原因和問題。其中 token 用量、skill 數(shù)量在 AI 工具推廣、團(tuán)隊(duì)轉(zhuǎn)型的早期，可以積極鼓勵(lì)，有人戲稱每日消耗 token 過億的人才算進(jìn)入“億元俱樂部”。但到了上述第二階段或者第三階段，團(tuán)隊(duì)實(shí)踐比較成熟后，可以開始關(guān)注代碼詞元比，即產(chǎn)出代碼當(dāng)量與投入 token （詞元）量的比值，越高代表 ROI 更好，畢竟 token 背后是真金白銀的成本，不能單純刷量。此外，還可以將 token 量與千當(dāng)量 bug 率等質(zhì)量指標(biāo)關(guān)聯(lián)分析。這個(gè)階段的宗旨是將 token 消耗從“成本中心”，變成“效能杠桿”。

• 智能體連續(xù)自主時(shí)長(zhǎng)。智能體執(zhí)行任務(wù)時(shí)可能多輪調(diào)用 LLM，如果自主執(zhí)行、中間無需人干預(yù)，可以計(jì)入“連續(xù)”時(shí)長(zhǎng)。在大多數(shù)產(chǎn)出有效的前提下，智能體每次連續(xù)自主執(zhí)行的平均時(shí)長(zhǎng)，是衡量 AI coding 成熟度的“黃金指標(biāo)”。一方面，長(zhǎng)時(shí)間代理人的工作能實(shí)實(shí)在在地為我們節(jié)省時(shí)間，又避免反復(fù)干擾人，減少我們切換上下文的損耗；另一方面，能夠長(zhǎng)時(shí)間保持有效工作狀態(tài)，對(duì)智能體構(gòu)建上下文的質(zhì)量、駕馭工程（harness engineering）等都有較高要求。

• 系統(tǒng)測(cè)試/驗(yàn)收測(cè)試通過率。我們按通常的定義將測(cè)試分成單元測(cè)試、集成測(cè)試（或接口測(cè)試）、系統(tǒng)測(cè)試和驗(yàn)收測(cè)試四層。隨著智能體逐步成長(zhǎng)為我們開發(fā)團(tuán)隊(duì)中的一員，人對(duì)單元測(cè)試和集成測(cè)試的實(shí)現(xiàn)會(huì)參與得越來越少。人的重點(diǎn)審查對(duì)象將是系統(tǒng)測(cè)試和驗(yàn)收測(cè)試——兩者分別對(duì)應(yīng)于規(guī)約中描述系統(tǒng)設(shè)計(jì)和描述用戶需求的規(guī)約項(xiàng)，符合一定標(biāo)準(zhǔn)的規(guī)約通常要求建立測(cè)試與對(duì)應(yīng)規(guī)約項(xiàng)的聯(lián)系。把開發(fā)過程中“提測(cè)”的通過率記錄下來，可以反映人駕馭 AI 達(dá)到質(zhì)量要求的水平。當(dāng)然，這里需要工程師管控好系統(tǒng)測(cè)試和驗(yàn)收測(cè)試本身的質(zhì)量，做好 AI coding 質(zhì)量保證的“守門員”。

• 需求吞吐率/交付周期。不論是否采用智能體、是否轉(zhuǎn)型 AI 原生，軟件工程最終都以完成需求的方式交付業(yè)務(wù)價(jià)值，而業(yè)務(wù)方永遠(yuǎn)希望排隊(duì)的需求能更多、更快地完成。因此，對(duì)需求價(jià)值流的統(tǒng)計(jì)依然是最重要的結(jié)果指標(biāo)。而每個(gè)需求的顆粒度或復(fù)雜度各異，單算個(gè)數(shù)會(huì)讓結(jié)果的準(zhǔn)確度大打折扣。有團(tuán)隊(duì)在嘗試使用 AI 對(duì)需求復(fù)雜度做預(yù)估，但大模型靠讀需求描述猜復(fù)雜度好比“快思考”，永遠(yuǎn)比不上真正實(shí)現(xiàn)中的“慢思考”，會(huì)存在很大幻覺；以往人都難以預(yù)估準(zhǔn)確，包括使用功能點(diǎn)（FP）等方法，并非上了 AI 就萬事大吉，還要占用緊張的 token 配額。所以，在需求完成后通過代碼當(dāng)量做“決算”依然是最經(jīng)濟(jì)準(zhǔn)確的途徑。配合規(guī)約驅(qū)動(dòng)開發(fā)（SDD）的實(shí)踐，我們可以對(duì)需求對(duì)應(yīng)的規(guī)約項(xiàng)數(shù)和實(shí)現(xiàn)后的當(dāng)量加權(quán)平均，作為需求復(fù)雜度或顆粒度的指標(biāo)，是無需額外人力/ token 成本同時(shí)又能實(shí)現(xiàn)有效量化的評(píng)估方法。

其他傳統(tǒng)指標(biāo)不再一一列舉，應(yīng)該說大部分指標(biāo)依然有效，比如 DORA 指標(biāo)，又比如缺陷逃逸率、事故響應(yīng)時(shí)長(zhǎng)等。我們也不重復(fù)度量中基本的 GQM（目標(biāo)-問題-指標(biāo)）、團(tuán)隊(duì)/項(xiàng)目/時(shí)間分布等分析方法。實(shí)踐中同樣要注意從目標(biāo)和問題開始，而不是一味堆砌指標(biāo)。

人與 AI 的性格

任何管理都需要關(guān)注人性，AI 也不例外。

不同人與智能體的溝通模式，與各自的性格有很多關(guān)聯(lián)。這部分觀測(cè)無法單純用統(tǒng)計(jì)方法獲得，而會(huì)涉及大模型對(duì)日志進(jìn)行分析，相應(yīng)需要一定的 token 消耗和投入。

下面兩張圖是我們?cè)谒即a逸內(nèi)部員工數(shù)據(jù)上完成的實(shí)驗(yàn)，展示了 AI 對(duì)一位同事使用 Coding Agent 模式的觀察和建議。雖然現(xiàn)在還沒有像“MBTI”一樣對(duì)人-智協(xié)作模式的全面歸納總結(jié)，但工程師已經(jīng)可以獲得有益的反饋，并根據(jù)這些反饋調(diào)整自身行為，或?qū)?duì)大模型的要求寫入 CLAUDE.md、AGENTS.md 等記憶/個(gè)性化知識(shí)中，讓雙方后續(xù)協(xié)作更高效。

另一方面，智能體的個(gè)性，既來自于它們被定義的不同角色、維護(hù)的不同上下文，也在于它們底層使用了不同的大模型。很多人對(duì)不同 LLM 的行為和性格都有感知，比如 Claude 有時(shí)會(huì)丟三落四，GPT 比較嚴(yán)謹(jǐn)認(rèn)真，Gemini 文字洋洋灑灑，生成前端比較美觀等等。在我們的實(shí)踐中，搭配諸如 Claude Opus 4.6 + GPT-5.4 這樣的組合，相互 review 代碼、文檔或觀點(diǎn)，可以很有效地抵御幻覺，極大提升輸出結(jié)果的可靠性。GitHub 最近推出的 Rubber Duck，開放性地引入多個(gè)模型家族，協(xié)作共事。在 SWE-Bench Pro 基準(zhǔn)測(cè)評(píng)中，Sonnet 組合 GPT-5.4 能彌補(bǔ)其與 Opus 之間 74.7% 的差距。這種思路與我們的實(shí)踐不謀而合。

拋開多個(gè)廠商不談，一家的幾代模型之間也會(huì)有差異，甚至同一個(gè)模型因?yàn)榛A(chǔ)設(shè)施配置或運(yùn)營(yíng)狀態(tài)也會(huì)有不同的表現(xiàn)，時(shí)不時(shí)被熱議的“降智”就是一種外部現(xiàn)象。從擬人的角度說，各個(gè)大模型的“背景”和“經(jīng)歷”不同（訓(xùn)練數(shù)據(jù)和過程差異），自然會(huì)形成不同的“性格”。就像人類職場(chǎng)需要多樣化，同事間互相補(bǔ)齊長(zhǎng)短板，多個(gè) AI Agent 也應(yīng)該做類似的安排。

可控制性：管理關(guān)鍵動(dòng)作

AI 很強(qiáng)，但其輸出天然不可控：同一個(gè)任務(wù)在不同上下文、不同提示詞、不同模型狀態(tài)下，可能給出差異很大的結(jié)果。

因此，團(tuán)隊(duì)真正需要的不是“AI 偶爾很聰明”，而是“AI 在大多數(shù)情況下都能被穩(wěn)定驅(qū)動(dòng)”。如果說可觀測(cè)性關(guān)乎“看見”，那么可控制性則關(guān)乎“駕馭”。

它提出的問題是：團(tuán)隊(duì)是否有能力通過規(guī)則、流程、輸入和反饋，把整個(gè)協(xié)作過程穩(wěn)定地引導(dǎo)到期望結(jié)果上。結(jié)合前述可觀測(cè)性的定義，達(dá)成可控制性的過程是，通過反饋閉環(huán)持續(xù)迭代規(guī)則和流程，以優(yōu)化輸入使系統(tǒng)狀態(tài)符合人的預(yù)期，并由觀測(cè)指標(biāo)體現(xiàn)。

這里的規(guī)則和流程不是像傳統(tǒng)腳本一樣“硬編碼” AI 的行為，而是設(shè)立邊界、提供特定場(chǎng)景和領(lǐng)域中的 know-how、相關(guān)的知識(shí)以及優(yōu)質(zhì)上下文。根據(jù)任務(wù)的適用性，它們可以實(shí)現(xiàn)為給予智能體足夠發(fā)揮空間的工作流、技能指令（skill）以及配套的各類工具（通過 MCP 或 CLI）。

我們討論實(shí)現(xiàn)可控制性的一些關(guān)鍵要素：

1. 包括測(cè)試在內(nèi)的高質(zhì)量規(guī)約。不論 AI 的能力如何發(fā)展，只要服務(wù)于人的需求，必然存在人的意圖與 AI 對(duì)齊以及驗(yàn)收產(chǎn)出的過程，所以作為雙方協(xié)議的規(guī)約必然存在，并且是控制 AI 行為的核心——結(jié)構(gòu)化、表述清晰的規(guī)約能讓 AI 發(fā)揮出最佳效能，而模糊殘缺的規(guī)約會(huì)在根本上影響 AI 實(shí)現(xiàn)的效能。規(guī)約是 AI 編程的首要控制面。這是規(guī)約驅(qū)動(dòng)開發(fā)的本質(zhì)。有人說規(guī)約“復(fù)辟”瀑布模型、規(guī)約越寫越復(fù)雜最后變成了代碼，都存在對(duì)規(guī)約本質(zhì)的誤解。

• 規(guī)約原本就應(yīng)當(dāng)是迭代的、模塊化的，伴隨開發(fā)的整個(gè)過程，而非指望誰在 Day 1 就全部定義清楚。

• 規(guī)約是對(duì)用戶需求和系統(tǒng)設(shè)計(jì)的描述，而非每一個(gè)實(shí)現(xiàn)細(xì)節(jié)。雖然兩者之間的邊界在實(shí)操中做不到?jīng)芪挤置鳎?guī)約的信息量應(yīng)當(dāng)數(shù)量級(jí)地少于程序代碼。并且，隨著基礎(chǔ)大模型能力、上下文工程、駕馭工程的發(fā)展，這個(gè)數(shù)量級(jí)的差距會(huì)合理地增大，也就是人需要審查的內(nèi)容會(huì)越來越少，更多實(shí)現(xiàn)細(xì)節(jié)可以放心地交給 AI 處理。

• 規(guī)約本身也不要求人一字一句地寫，AI 可以輔助人表達(dá)，幫助人發(fā)散、收斂、找到盲點(diǎn)等。規(guī)約本身應(yīng)當(dāng)具備組合性、復(fù)用性和可擴(kuò)展性，進(jìn)一步降低人的負(fù)擔(dān)——限于篇幅，這個(gè)話題我們將在后續(xù)討論 AI 原生軟件工程新范式的文章中另行展開。

  以下工具可以幫助項(xiàng)目快速搭建起符合 GEARS 標(biāo)準(zhǔn)的規(guī)約腳手架（參見https://github.com/sublang-ai/spex）。

spex scaffold

2. 把握關(guān)鍵動(dòng)作的工作流程（procedure）。工作流程中蘊(yùn)含著個(gè)人或者團(tuán)隊(duì)處理各類問題的 know-how，包括何時(shí)引入哪些工具、知識(shí)和上下文（這些操作可由 AI agent 具體執(zhí)行）。它們可由如下三種方式實(shí)現(xiàn)。

• 固化工作流（workflow）。以傳統(tǒng)腳本和早期 LangGraph、Dify、n8n 等工具為代表。大模型會(huì)被調(diào)用完成智能化的操作，有時(shí)可以決定分支選擇，但并不主導(dǎo)整個(gè)過程，而是被限制在預(yù)定義的流程框架中。這種限制一方面帶來確定性的優(yōu)勢(shì)，另一方面也會(huì)在復(fù)雜多樣的環(huán)境中面臨適應(yīng)性和靈活性的挑戰(zhàn)。如果逐一處理各個(gè) corner case，工作流可能會(huì)變得日益復(fù)雜，給人帶來比較大的認(rèn)知負(fù)擔(dān)，讓構(gòu)建可靠的工作流本身成為瓶頸。

• Skill 自然語言指令。從 Claude Code 到“小龍蝦”（OpenClaw），skill 已經(jīng)成為人和智能體表達(dá)、沉淀和交換經(jīng)驗(yàn)的一種主要載體。不像工作流需要精確可運(yùn)行的實(shí)現(xiàn)，用 skill 描述工作流程允許某些“灰度”，只要 AI 能夠理解人的自然語言描述即可。這種低門檻的途徑極大方便了人或智能體的表達(dá)，社區(qū)貢獻(xiàn)和分享不斷豐富，生態(tài)日益繁榮。相應(yīng)地，skill 的劣勢(shì)也來自于這種“灰度”，一方面它允許 AI 適度發(fā)揮，而 AI 未必總能與人的意圖或判斷對(duì)齊，另一方面沒有確定性的外部框架，AI 有時(shí)會(huì)自主決定突破人原本的計(jì)劃，特別是長(zhǎng)時(shí)任務(wù)。如果想在小時(shí)級(jí)控好自主執(zhí)行的智能體，單純依賴 skill 達(dá)到的可靠性往往不夠。

• 規(guī)約狀態(tài)機(jī)。能否在固化工作流和 skill 自然語言指令間找到一個(gè)中間形態(tài)兼具兩者的優(yōu)勢(shì)？我們發(fā)現(xiàn)人在表達(dá)流程時(shí)傾向于采用“某種情況下如何做”“當(dāng)完成某個(gè)操作時(shí)進(jìn)行另一個(gè)操作”等表達(dá)方式，一方面與規(guī)約項(xiàng) GEARS 模式相近，另一方面或可與狀態(tài)機(jī)對(duì)應(yīng)起來。例如下面就是描述流程的一個(gè) GEARS 格式的規(guī)約項(xiàng)：

當(dāng) Developer 角色的智能體完成代碼提交，Reviewer 角色的智能體接收如下指令開始審查代碼：Review the latest commit. Flag any issues or improvements (numbered; no duplication). Think thoroughly — don't just approve or reject. If the commit is push-ready, don't raise nitpicks. Consult @specs/map.md to find relevant context if needed.

因此，我們可將類 skill 的流程描述視作“用戶故事”，統(tǒng)一轉(zhuǎn)化為 GEARS 格式的一組規(guī)約項(xiàng)，并用狀態(tài)機(jī)建模，將確定性的狀態(tài)與轉(zhuǎn)換自動(dòng)編寫成可運(yùn)行的框架，而主控的 AI agent 依然可以智能地從有限個(gè)狀態(tài)集合中轉(zhuǎn)換并執(zhí)行允許的行為。我們稱之為規(guī)約狀態(tài)機(jī)，既包含確定性運(yùn)行的基本框架，又支持自然語言描述、保持大模型主控。我們應(yīng)用兩個(gè)智能體配合生成代碼的狀態(tài)機(jī)，在規(guī)約項(xiàng)符合標(biāo)準(zhǔn)（含測(cè)試）情況下持續(xù)領(lǐng)取任務(wù)，實(shí)測(cè) Claude Code + Claude Opus 4.6（Developer）和 Codex CLI + GPT-5.3-Codex（Reviewer）配合可以穩(wěn)定運(yùn)行若干小時(shí)，實(shí)現(xiàn)人晚上下任務(wù)、早上起來拿結(jié)果。

單看狀態(tài)機(jī)邏輯并無太多特別之處，主要差異在具體提示詞和規(guī)約項(xiàng)能提供什么樣的上下文。我們將在 5 月份 AES 2026 智能體工程峰會(huì)上開源支持多智能體運(yùn)行的底座以及將自然語言編譯成狀態(tài)機(jī)的基礎(chǔ)工具。

3. 設(shè)立好邊界。大部分團(tuán)隊(duì)都有這方面的意識(shí)，但從理念到落地，還有一段路要走，這里給出常見的行動(dòng)指南。

策略設(shè)計(jì)可以借助指標(biāo)觀察，支持團(tuán)隊(duì)動(dòng)態(tài)調(diào)整控制強(qiáng)度：控制過松，風(fēng)險(xiǎn)、缺陷和返工會(huì)上升；控制過嚴(yán)，效率和體驗(yàn)會(huì)下降。團(tuán)隊(duì)可通過指標(biāo)數(shù)據(jù)找到適合自己的平衡點(diǎn)。

4. 閉合反饋回路。AI 不會(huì)每次都一步到位地給出正確答案，往往會(huì)出現(xiàn)理解偏差、遺漏約束、局部合理但整體不成立、改對(duì)一處卻破壞另一處等情況，提供更多更好的上下文也無法解決所有問題。因此真正重要的不是“首輪成功率”，而是系統(tǒng)是否具備低成本發(fā)現(xiàn)問題、明確指出偏差、并驅(qū)動(dòng)下一輪改進(jìn)的能力。閉合反饋回路的核心，就是讓 AI 的每一步產(chǎn)出都能進(jìn)入可驗(yàn)證、可糾偏、可繼續(xù)推進(jìn)狀態(tài)。這就要求我們?yōu)?AI 構(gòu)建一個(gè)閉合的反饋回路——讓它像人類開發(fā)者一樣，在“嘗試 → 失敗 → 理解原因 → 再次嘗試”的循環(huán)中不斷逼近目標(biāo)。

• 真實(shí)可運(yùn)行的測(cè)試環(huán)境。AI 生成的代碼必須在真實(shí)環(huán)境中執(zhí)行，而不是僅憑 LLM 自身“推理”其正確性。僅有單元測(cè)試和各種 mock 仍然不足，屬于讓大模型既當(dāng)“運(yùn)動(dòng)員”又當(dāng)“裁判員”，不排除有些單元測(cè)試在錯(cuò)誤代碼邏輯上“將錯(cuò)就錯(cuò)”，通過只是掩蓋了 bug。只有讓代碼實(shí)際運(yùn)行、觀察真實(shí)的輸出和報(bào)錯(cuò)，AI agent 才能獲得可靠的、基于事實(shí)的反饋信號(hào)。

• CI 質(zhì)量門禁，包括自動(dòng)化測(cè)試、lint 規(guī)則、Sonar 掃描、安全漏洞掃描、構(gòu)建驗(yàn)證，乃至規(guī)約符合度驗(yàn)證，為 AI 提供即時(shí)、客觀、可解讀的反饋。每一次檢查失敗都不是終點(diǎn)，而是一條清晰的修正線索：錯(cuò)誤信息本身就是引導(dǎo) AI 進(jìn)行下一輪修正的提示詞。智能體可以據(jù)此自主定位問題、修正代碼，直至通過全部關(guān)卡。

• 必要的人工審查。并非所有問題都能被自動(dòng)化測(cè)試捕獲——需求理解是否到位、設(shè)計(jì)取舍是否合理、代碼是否符合長(zhǎng)期演進(jìn)方向、實(shí)現(xiàn)是否真正貼合業(yè)務(wù)，這些往往需要人類的判斷。要求 AI 的特定產(chǎn)出必須經(jīng)過人類審核通過后才能繼續(xù)推進(jìn)，不僅是一種邊界的控制機(jī)制，更是人類為 AI 提供高質(zhì)量反饋的窗口。工程師可以在 coding agent 的對(duì)話窗口中指出問題所在、補(bǔ)充隱含約束、澄清真實(shí)意圖、調(diào)整實(shí)現(xiàn)計(jì)劃，甚至重新定義目標(biāo)。

4. 合理拆分需求和任務(wù)顆粒度。GPT-5 能在程序員的“奧林匹克”競(jìng)賽（ICPC）中發(fā)揮出實(shí)力超越人類隊(duì)伍，依賴的一個(gè)重要前提是所有題目都有嚴(yán)謹(jǐn)清晰的定義。將工作拆分成更小、更獨(dú)立的任務(wù)，有利于 AI 穩(wěn)定地發(fā)揮，工程師也有更多機(jī)會(huì)去檢查和調(diào)整方向。通常我們讓 AI 根據(jù)需求描述拆分并計(jì)劃下一個(gè)或多個(gè)迭代，需要給出各個(gè)迭代的目標(biāo)、交付物、任務(wù)和驗(yàn)收標(biāo)準(zhǔn)，其中每個(gè)任務(wù)大致顆粒度控制在一次提交的變更量。這些迭代計(jì)劃和進(jìn)行狀態(tài)（如交付物完成打勾）應(yīng)記入文件系統(tǒng)，供智能體讀取和共享，并建議提交到 Git 等與代碼同步的版本控制系統(tǒng)。

5. 融合的上下文與記憶管理。Coding agent 進(jìn)步日新月異、百家爭(zhēng)鳴，對(duì)大部分落地應(yīng)用的團(tuán)隊(duì)，一般原則是不介入 Codex CLI、OpenCode 等產(chǎn)品的內(nèi)部（如記憶或檢索機(jī)制），不花精力為某個(gè)智能體做特異性優(yōu)化（如細(xì)微的流程或提示詞修改），因?yàn)榛A(chǔ)大模型和智能體工程進(jìn)步會(huì)迅速將其覆蓋。我們不如將主要精力放在項(xiàng)目和團(tuán)隊(duì)的知識(shí)治理，打通各類信息孤島，以 Markdown 等形式沉淀到代碼庫(kù)或知識(shí)庫(kù)中，為智能體獲得匹配的高質(zhì)量上下文提供支持。實(shí)操中，我們并不為了追求“記憶”而長(zhǎng)期使用單一 session，因?yàn)樯舷挛拇翱谔畛溥^滿后，大模型的智力表現(xiàn)會(huì)有所下降；相反，在幾組任務(wù)或迭代后，能夠做到重開 session 清空初始上下文并不影響 LLM 繼續(xù)工作，才說明智能體可控制性做到位了。

此外，“傳統(tǒng)”編程規(guī)范、DevOps 基礎(chǔ)設(shè)施等在 AI 時(shí)代同樣必備，甚至變得更加重要。統(tǒng)一編程規(guī)范可以降低智能體之間以及與人協(xié)作的成本，特別是清晰明了的命名（從目錄、文件，到類和對(duì)象）。CI/CD 更是很多質(zhì)量關(guān)卡的“守門員”，也是構(gòu)成 AI 反饋閉環(huán)必不可少的部分。

可控制性與可觀測(cè)性是對(duì)偶概念，相互依存?？煽刂菩宰罱K應(yīng)體現(xiàn)在指標(biāo)上。特別是從團(tuán)隊(duì)轉(zhuǎn)型和管理的角度，沒有指標(biāo)做抓手，很多實(shí)踐恐怕會(huì)長(zhǎng)久地停留在口號(hào)上。例如“規(guī)范使用 AI”“提升質(zhì)量意識(shí)”，有了指標(biāo)才能評(píng)估其效果或轉(zhuǎn)型進(jìn)展，可采用上文中的規(guī)約符合度、規(guī)約測(cè)試覆蓋度、系統(tǒng)測(cè)試/驗(yàn)收測(cè)試通過率，以及缺陷逃逸率、回滾率和修復(fù)時(shí)長(zhǎng)等傳統(tǒng)度量指標(biāo)。

對(duì)研發(fā)團(tuán)隊(duì)而言，可控制性的直接益處是降低不確定性。傳統(tǒng)軟件工程重視流程，并不是為了制造繁瑣，而是為了在復(fù)雜協(xié)作中建立可靠性。AI Coding 時(shí)代更需要這種可靠性，因?yàn)?AI 放大了產(chǎn)出速度，也放大了錯(cuò)誤傳播速度。一個(gè)不受控的 AI Agent 可能在短時(shí)間內(nèi)改動(dòng)大量文件、引入架構(gòu)偏差或錯(cuò)誤邏輯，甚至讓團(tuán)隊(duì)在“看起來很忙”的狀態(tài)下持續(xù)偏離目標(biāo)?？煽刂菩跃褪菫檫@種高速系統(tǒng)加上方向盤、剎車和護(hù)欄。它讓團(tuán)隊(duì)能夠決定：AI 可以訪問什么信息、能調(diào)用哪些工具、哪些改動(dòng)必須經(jīng)人工批準(zhǔn)、哪些測(cè)試不通過絕不能合并、哪些場(chǎng)景必須升級(jí)為人工決策。這樣，團(tuán)隊(duì)獲得的不是單點(diǎn)的效率，而是可放心倍增的效率。

提效能“復(fù)制”，才談得上 AI 轉(zhuǎn)型

智能體時(shí)代的軟件開發(fā)，雖然部分被“AI 黑盒”接管，但效能最核心的原理從來沒變過——就是用系統(tǒng)的方法，讓提效的過程能看到、能控制、能復(fù)刻?？捎^測(cè)性與可控制性給我們提供了一個(gè)破解復(fù)雜系統(tǒng)問題的框架，再結(jié)合 AI agent 和項(xiàng)目的特點(diǎn)衍生出新流程、新指標(biāo)，就能構(gòu)建出一套適合人-智協(xié)同的高效能研發(fā)體系。

總體來看，可觀測(cè)性讓團(tuán)隊(duì)知道系統(tǒng)處于什么狀態(tài)，可控制性讓團(tuán)隊(duì)能夠把系統(tǒng)帶向想要的狀態(tài)。前者解決“看不清”的問題，后者解決“管不住”的問題。對(duì) AI coding 而言，兩者缺一不可：沒有可觀測(cè)性，可控制性就會(huì)失去依據(jù)；沒有可控制性，可觀測(cè)性再?gòu)?qiáng)也只能旁觀問題發(fā)生。真正成熟的 AI 原生研發(fā)體系，應(yīng)當(dāng)把兩者結(jié)合起來，用指標(biāo)驅(qū)動(dòng)過程治理、質(zhì)量保障和效能提升，讓大模型從一個(gè)“會(huì)寫代碼的助手”進(jìn)化為一個(gè)可被團(tuán)隊(duì)穩(wěn)定納入生產(chǎn)系統(tǒng)的研發(fā)能力。

未來，AI 技術(shù)還將不斷發(fā)展，人-智協(xié)同的模式也會(huì)繼續(xù)演變；相應(yīng)地，度量體系需要不斷進(jìn)化。但只要遵循“通過觀察數(shù)據(jù)，找到控制要素”這個(gè)核心思路，以可觀測(cè)性和可控制性為錨點(diǎn)，就能在變化中抓住提效的本質(zhì)，實(shí)現(xiàn)軟件生產(chǎn)力的躍升。

作者介紹：任晶磊，思碼逸創(chuàng)始人兼 CEO。清華大學(xué)計(jì)算機(jī)系博士，前微軟亞洲研究院研究員，斯坦福大學(xué)、卡內(nèi)基梅隆大學(xué)訪問學(xué)者；多篇論文發(fā)表在 FSE、OSDI 等頂尖國(guó)際學(xué)術(shù)會(huì)議上。曾參與微軟下一代服務(wù)器系統(tǒng)架構(gòu)設(shè)計(jì)，獲 4 項(xiàng)美國(guó)發(fā)明專利；《軟件研發(fā)效能度量規(guī)范》標(biāo)準(zhǔn)核心起草專家，參編《軟件研發(fā)效能權(quán)威指南》《軟件研發(fā)效能提升實(shí)踐》；研發(fā)大數(shù)據(jù)平臺(tái) Apache DevLake 等開源項(xiàng)目發(fā)起人。

【活動(dòng)分享】"48 小時(shí)，與 50+ 位大廠技術(shù)決策者，共探 AI 落地真路徑。"由 CSDN&奇點(diǎn)智能研究院聯(lián)合舉辦的「全球機(jī)器學(xué)習(xí)技術(shù)大會(huì)」正式升級(jí)為「奇點(diǎn)智能技術(shù)大會(huì)」。2026 奇點(diǎn)智能技術(shù)大會(huì)將于 4 月 17-18 日在上海環(huán)球港凱悅酒店正式召開，大會(huì)聚焦大模型技術(shù)演進(jìn)、智能體系統(tǒng)工程、OpenClaw 生態(tài)實(shí)踐及 AI 行業(yè)落地等十二大專題板塊，特邀來自BAT、京東、微軟、小紅書、美團(tuán)等頭部企業(yè)的 50+ 位技術(shù)決策者分享實(shí)戰(zhàn)案例。旨在幫助技術(shù)管理者與一線 AI 落地人員規(guī)避選型風(fēng)險(xiǎn)、降低試錯(cuò)成本、獲取可復(fù)用的工程方法論，真正實(shí)現(xiàn) AI 技術(shù)的規(guī)?；涞嘏c商業(yè)價(jià)值轉(zhuǎn)化。這不僅是一場(chǎng)技術(shù)的盛宴，更是決策者把握 2026 AI 拐點(diǎn)的戰(zhàn)略機(jī)會(huì)。