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 在人主控的上下文中提供小范围的辅助。	< 50%
智能开发第二阶段	智能体独立完成分钟级任务，个别智能体协作，人面向具体任务为 AI 提供上下文	50% ~ 90%
智能开发第三阶段	智能体独立完成小时级任务，多角色智能协作，人基于项目或工程为 AI 提供上下文	> 90%

对于后两个阶段，度量“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）。

我们讨论实现可控制性的一些关键要素：

• 包括测试在内的高质量规约。不论 AI 的能力如何发展，只要服务于人的需求，必然存在人的意图与 AI 对齐以及验收产出的过程，所以作为双方协议的规约必然存在，并且是控制 AI 行为的核心——结构化、表述清晰的规约能让 AI 发挥出最佳效能，而模糊残缺的规约会在根本上影响 AI 实现的效能。规约是 AI 编程的首要控制面。这是规约驱动开发的本质。有人说规约“复辟”瀑布模型、规约越写越复杂最后变成了代码，都存在对规约本质的误解。

  • 规约原本就应当是迭代的、模块化的，伴随开发的整个过程，而非指望谁在 Day 1 就全部定义清楚。
  • 规约是对用户需求和系统设计的描述，而非每一个实现细节。虽然两者之间的边界在实操中做不到泾渭分明，但规约的信息量应当数量级地少于程序代码。并且，随着基础大模型能力、上下文工程、驾驭工程的发展，这个数量级的差距会合理地增大，也就是人需要审查的内容会越来越少，更多实现细节可以放心地交给 AI 处理。
  • 规约本身也不要求人一字一句地写，AI 可以辅助人表达，帮助人发散、收敛、找到盲点等。规约本身应当具备组合性、复用性和可扩展性，进一步降低人的负担——限于篇幅，这个话题我们将在后续讨论 AI 原生软件工程新范式的文章中另行展开（欢迎关注“思码逸研发效能”公众号）。
  •   以下工具可以帮助项目快速搭建起符合 GEARS 标准的规约脚手架（参见github.com/sublang-ai/…

  •   npm install -g @sublang/spex
      spex scaffold
    

• 把握关键动作的工作流程（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 智能体工程峰会上开源支持多智能体运行的底座以及将自然语言编译成状态机的基础工具。

• 设立好边界。大部分团队都有这方面的意识，但从理念到落地，还有一段路要走，这里给出常见的行动指南。

策略设计可以借助指标观察，支持团队动态调整控制强度：控制过松，风险、缺陷和返工会上升；控制过严，效率和体验会下降。团队可通过指标数据找到适合自己的平衡点。

• 闭合反馈回路。AI 不会每次都一步到位地给出正确答案，往往会出现理解偏差、遗漏约束、局部合理但整体不成立、改对一处却破坏另一处等情况，提供更多更好的上下文也无法解决所有问题。因此真正重要的不是“首轮成功率”，而是系统是否具备低成本发现问题、明确指出偏差、并驱动下一轮改进的能力。闭合反馈回路的核心，就是让 AI 的每一步产出都能进入可验证、可纠偏、可继续推进状态。这就要求我们为 AI 构建一个闭合的反馈回路——让它像人类开发者一样，在“尝试 → 失败 → 理解原因 → 再次尝试”的循环中不断逼近目标。

  • 真实可运行的测试环境。AI 生成的代码必须在真实环境中执行，而不是仅凭 LLM 自身“推理”其正确性。仅有单元测试和各种 mock 仍然不足，属于让大模型既当“运动员”又当“裁判员”，不排除有些单元测试在错误代码逻辑上“将错就错”，通过只是掩盖了 bug。只有让代码实际运行、观察真实的输出和报错，AI agent 才能获得可靠的、基于事实的反馈信号。
  • CI 质量门禁，包括自动化测试、lint 规则、Sonar 扫描、安全漏洞扫描、构建验证，乃至规约符合度验证，为 AI 提供即时、客观、可解读的反馈。每一次检查失败都不是终点，而是一条清晰的修正线索：错误信息本身就是引导 AI 进行下一轮修正的提示词。智能体可以据此自主定位问题、修正代码，直至通过全部关卡。
  • 必要的人工审查。并非所有问题都能被自动化测试捕获——需求理解是否到位、设计取舍是否合理、代码是否符合长期演进方向、实现是否真正贴合业务，这些往往需要人类的判断。要求 AI 的特定产出必须经过人类审核通过后才能继续推进，不仅是一种边界的控制机制，更是人类为 AI 提供高质量反馈的窗口。工程师可以在 coding agent 的对话窗口中指出问题所在、补充隐含约束、澄清真实意图、调整实现计划，甚至重新定义目标。

• 合理拆分需求和任务颗粒度。GPT-5 能在程序员的“奥林匹克”竞赛（ICPC）中发挥出实力超越人类队伍，依赖的一个重要前提是所有题目都有严谨清晰的定义。将工作拆分成更小、更独立的任务，有利于 AI 稳定地发挥，工程师也有更多机会去检查和调整方向。通常我们让 AI 根据需求描述拆分并计划下一个或多个迭代，需要给出各个迭代的目标、交付物、任务和验收标准，其中每个任务大致颗粒度控制在一次提交的变更量。这些迭代计划和进行状态（如交付物完成打勾）应记入文件系统，供智能体读取和共享，并建议提交到 Git 等与代码同步的版本控制系统。

• 融合的上下文与记忆管理。Coding agent 进步日新月异、百家争鸣，对大部分落地应用的团队，一般原则是不介入 Codex CLI、OpenCode 等产品的内部（如记忆或检索机制），不花精力为某个智能体做特异性优化（如细微的流程或提示词修改），因为基础大模型和智能体工程进步会迅速将其覆盖。我们不如将主要精力放在项目和团队的知识治理，打通各类信息孤岛，以 Markdown 等形式沉淀到代码库或知识库中，为智能体获得匹配的高质量上下文提供支持。实操中，我们并不为了追求“记忆”而长期使用单一 session，因为上下文窗口填充过满后，大模型的智力表现会有所下降；相反，在几组任务或迭代后，能够做到重开 session 清空初始上下文并不影响 LLM 继续工作，才说明智能体可控制性做到位了。

此外，“传统”编程规范、DevOps 基础设施等在 AI 时代同样必备，甚至变得更加重要。统一编程规范可以降低智能体之间以及与人协作的成本，特别是清晰明了的命名（从目录、文件，到类和对象）。CI/CD 更是很多质量关卡的“守门员”，也是构成 AI 反馈闭环必不可少的部分。

可控制性与可观测性是对偶概念，相互依存。可控制性最终应体现在指标上。特别是从团队转型和管理的角度，没有指标做抓手，很多实践恐怕会长久地停留在口号上。例如“规范使用 AI”“提升质量意识”，有了指标才能评估其效果或转型进展，可采用上文中的规约符合度、规约测试覆盖度、系统测试/验收测试通过率，以及缺陷逃逸率、回滚率和修复时长等传统度量指标。

对研发团队而言，可控制性的直接益处是降低不确定性。传统软件工程重视流程，并不是为了制造繁琐，而是为了在复杂协作中建立可靠性。AI coding 时代更需要这种可靠性，因为 AI 放大了产出速度，也放大了错误传播速度。一个不受控的 AI agent 可能在短时间内改动大量文件、引入架构偏差或错误逻辑，甚至让团队在“看起来很忙”的状态下持续偏离目标。可控制性就是为这种高速系统加上方向盘、刹车和护栏。它让团队能够决定：AI 可以访问什么信息、能调用哪些工具、哪些改动必须经人工批准、哪些测试不通过绝不能合并、哪些场景必须升级为人工决策。这样，团队获得的不是单点的效率，而是可放心倍增的效率。

---

在即将于 5 月 17 日 举办的 AES 智能体工程大会上（议题征集｜早鸟票折扣），我们将发布三个重要更新：

• VibeInsight 开发智能体可观测性工具，思码逸继开源 Apache DevLake、企业版 DevInsight 度量平台之后面向 AI 原生软件工程的新一代产品。
• 企业级高可靠多智能体开发解决方案，实现工程师对大模型的可控制性，打包服务开发团队向 AI 原生更高阶晋级。
• DevData '26 研发效能基准调研报告，18个指标最新鲜的行业数据即将出炉！

敬请期待！

---

提效能“复制”，才谈得上 AI 转型

智能体时代的软件开发，虽然部分被“AI 黑盒”接管，但效能最核心的原理从来没变过——就是用系统的方法，让提效的过程能看到、能控制、能 复刻。可观测性与可控制性给我们提供了一个破解复杂系统问题的框架，再结合 AI agent 和项目的特点衍生出新流程、新指标，就能构建出一套适合人-智协同的高效能研发体系。

总体来看，可观测性让团队知道系统处于什么状态，可控制性让团队能够把系统带向想要的状态。前者解决“看不清”的问题，后者解决“管不住”的问题。对 AI coding 而言，两者缺一不可：没有可观测性，可控制性就会失去依据；没有可控制性，可观测性再强也只能旁观问题发生。真正成熟的 AI 原生研发体系，应当把两者结合起来，用指标驱动过程治理、质量保障和效能提升，让大模型从一个“会写代码的助手”进化为一个可被团队稳定纳入生产系统的研发能力。

未来，AI 技术还将不断发展，人-智协同的模式也会继续演变；相应地，度量体系需要不断进化。但只要遵循“通过观察数据，找到控制要素”这个核心思路，以可观测性和可控制性为锚点，就能在变化中抓住提效的本质，实现软件生产力的跃升。