Token燒了幾十億，代碼還是一團亂！AI原生開發(fā)該怎么管理？

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

作者 | 任晶磊

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

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

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

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

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

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

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

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

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

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

“三級跳”，你到了哪一步？

最近常聽到客戶向我們詢問如何統(tǒng)計 AI 代碼占比、AI 時代的工具鏈如何構建、企業(yè)應關注什么新指標等問題。其實這些問題的答案，與企業(yè)當前研發(fā)中 AI 滲透的程度密切相關。

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

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

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

可觀測性：從外部破解“黑盒”

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

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

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

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

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

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

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

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

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

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

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

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

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

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)訪問權限的情況下，當用戶請求代碼生成，編程智能體將把輸出寫入指定文件。

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

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

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

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

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

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

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

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

人與 AI 的性格

任何管理都需要關注人性，AI 也不例外。

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

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

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

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

可控制性：管理關鍵動作

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

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

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

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

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

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

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

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

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

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

spex scaffold

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

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

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

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

當 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ī)約項，并用狀態(tài)機建模，將確定性的狀態(tài)與轉(zhuǎn)換自動編寫成可運行的框架，而主控的 AI agent 依然可以智能地從有限個狀態(tài)集合中轉(zhuǎn)換并執(zhí)行允許的行為。我們稱之為規(guī)約狀態(tài)機，既包含確定性運行的基本框架，又支持自然語言描述、保持大模型主控。我們應用兩個智能體配合生成代碼的狀態(tài)機，在規(guī)約項符合標準（含測試）情況下持續(xù)領取任務，實測 Claude Code + Claude Opus 4.6（Developer）和 Codex CLI + GPT-5.3-Codex（Reviewer）配合可以穩(wěn)定運行若干小時，實現(xiàn)人晚上下任務、早上起來拿結(jié)果。

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

3. 設立好邊界。大部分團隊都有這方面的意識，但從理念到落地，還有一段路要走，這里給出常見的行動指南。

策略設計可以借助指標觀察，支持團隊動態(tài)調(diào)整控制強度：控制過松，風險、缺陷和返工會上升；控制過嚴，效率和體驗會下降。團隊可通過指標數(shù)據(jù)找到適合自己的平衡點。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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