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

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

作者 | 任晶磊

轉載 | 思碼逸研發效能

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

根據控制理論的基本要素和可觀測性的概念——能否通過系統的外部輸出推斷其內部狀態，我們對智能開發的可觀測性做出如下定義：

• 系統：人與 AI 協作開發軟件的過程

• 狀態：人的意圖，AI 的理解，設計、決策、計劃、執行狀態，開發過程中的記憶與知識

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

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

（注：代碼、規約等既作為一個狀態的輸出，也可能作為下一個狀態的輸入）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

人與 AI 的性格

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

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

下面兩張圖是我們在思碼逸內部員工數據上完成的實驗，展示了 AI 對一位同事使用 Coding Agent 模式的觀察和建議。雖然現在還沒有像“MBTI”一樣對人-智協作模式的全面歸納總結，但工程師已經可以獲得有益的反饋，并根據這些反饋調整自身行為，或將對大模型的要求寫入 CLAUDE.md、AGENTS.md 等記憶/個性化知識中，讓雙方后續協作更高效。

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

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

可控制性：管理關鍵動作

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

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

它提出的問題是：團隊是否有能力通過規則、流程、輸入和反饋，把整個協作過程穩定地引導到期望結果上。結合前述可觀測性的定義，達成可控制性的過程是，通過反饋閉環持續迭代規則和流程，以優化輸入使系統狀態符合人的預期，并由觀測指標體現。

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

我們討論實現可控制性的一些關鍵要素：

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

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

• 規約是對用戶需求和系統設計的描述，而非每一個實現細節。雖然兩者之間的邊界在實操中做不到涇渭分明，但規約的信息量應當數量級地少于程序代碼。并且，隨著基礎大模型能力、上下文工程、駕馭工程的發展，這個數量級的差距會合理地增大，也就是人需要審查的內容會越來越少，更多實現細節可以放心地交給 AI 處理。

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

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

spex scaffold

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

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

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

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

當 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 的流程描述視作“用戶故事”，統一轉化為 GEARS 格式的一組規約項，并用狀態機建模，將確定性的狀態與轉換自動編寫成可運行的框架，而主控的 AI agent 依然可以智能地從有限個狀態集合中轉換并執行允許的行為。我們稱之為規約狀態機，既包含確定性運行的基本框架，又支持自然語言描述、保持大模型主控。我們應用兩個智能體配合生成代碼的狀態機，在規約項符合標準（含測試）情況下持續領取任務，實測 Claude Code + Claude Opus 4.6（Developer）和 Codex CLI + GPT-5.3-Codex（Reviewer）配合可以穩定運行若干小時，實現人晚上下任務、早上起來拿結果。

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

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

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

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

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

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

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

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

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

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

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

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

提效能“復制”，才談得上 AI 轉型

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

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

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

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

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