研发团队引入 AI 后，工程师写代码的速度可能明显提升，但产品交付周期未必同步缩短。原因在于，代码生成只是研发流程中的一个环节。真正的组织级提效，需要让 AI 从辅助个人编码，逐步走向独立执行任务，并最终进入工单、缺陷、需求和测试等团队协作流程。
为什么个人效率提升了，研发周期却没有明显缩短
过去几年，研发团队应用 AI 的方式发生了明显变化。
最早，AI 主要存在于编辑器中，帮助工程师补全代码、解释函数、生成注释。随后，Coding Agent 开始具备读取代码仓、制订方案、修改代码、运行测试和提交 Pull Request 的能力。如今，一些企业已经开始尝试让 AI 以相对稳定的角色进入研发流程，承担工单诊断、缺陷修复和小需求开发等工作。
GitHub 官方文档显示，Copilot Agent 已经可以研究代码仓、形成实施计划、在分支中修改代码，并创建 Pull Request 供开发人员审核；OpenAI Codex 也能够执行功能开发、代码重构、缺陷修复、测试和代码审查等多步骤软件工程任务。
这说明，AI 在研发中的定位，正在从“给人提供建议”，转向“替人执行一部分任务”。
但从组织管理角度看，工具能力增强，并不等于研发效能自然提升。DORA 2025 年研究将 AI 定义为一种“放大器”：组织原有的工程基础、流程能力和协作质量越好，AI 越可能带来正向收益；如果需求混乱、测试薄弱、职责不清，AI 也可能放大返工和交付风险。
因此，判断研发团队的 AI 应用水平，不能只看“有多少人用了 AI”，而应当看 AI 已经进入了研发工作的哪一个层次。
阶段一：代码补全，解决的是个人操作效率
1. AI 是工程师身边的辅助工具
第一阶段的典型形态，是代码补全和对话式编程助手。
工程师仍然是任务的完整执行者，需要自行理解需求、查找代码、设计方案、完成编码并验证结果。AI 主要负责预测下一段代码、生成重复性逻辑、解释陌生代码，以及减少查阅资料和手工输入的时间。
这一阶段的价值非常直接：使用门槛低、反馈及时，几乎不需要调整原有研发流程。GitHub 对 Copilot 的官方定位，也是帮助开发人员在编码过程中提高生产力，并通过代码建议、对话和相关辅助能力完成开发工作。
2. 为什么个人提效不等于组织提效
代码编写只是软件交付链条的一部分。一项需求从提出到上线，通常还要经历：
- 需求澄清与范围确认；
- 技术方案评审；
- 跨团队依赖协调；
- 编码、测试与缺陷修复；
- 发布审批与结果验收。
即使工程师的编码时间减少了30%，如果需求等待了三天、评审排队了两天、测试环境又阻塞了一天，整体交付周期仍然不会发生根本变化。
ONES 的研发实践也经历了这一阶段：智能补全显著减少了输入和部分思考时间，但组织层面的效率感受并不明显，研发周期仍然较长。所以，代码补全解决的是“人怎样更快地写代码”，还没有回答“研发任务怎样更快地流动”。
阶段二：Coding Agent，解决的是完整任务的执行效率
1. 从回答问题转向交付结果
Coding Agent 与传统代码助手的核心区别，不在于模型是否更聪明，而在于它是否能够独立完成一段连续工作。一个具备基本工程能力的 Coding Agent，通常需要完成以下闭环：
- 理解任务和代码上下文；
- 定位相关代码与依赖；
- 制订修改方案；
- 编辑代码；
- 运行编译、检查和测试；
- 根据结果修正；
- 提交可供人工审核的变更。
例如，Codex 可以在预装代码仓的独立环境中读取和编辑文件，运行测试框架、代码检查工具和类型校验器，并通过终端日志和测试结果提供可验证的执行证据。这一变化非常重要。工程师不再需要逐行指挥 AI，而是可以将一个边界相对明确的任务交给 Agent，再对结果进行审核。
2. 人的角色从执行者转向评审者
在这一阶段，人机分工开始改变。
AI 可以承担代码分析、方案草拟、代码修改和测试执行；工程师则负责判断任务边界、审核技术方案、识别业务风险，以及决定结果能否进入正式环境。这并不意味着人的价值下降。恰恰相反，随着执行成本降低，判断质量会变得更加重要。
GitHub 在 Coding Agent 的使用说明中也明确强调，Agent 完成代码修改后，开发人员仍需像审查其他贡献者的 Pull Request 一样检查变更，可以要求修改、人工补充，最终再决定是否合并。
3. Coding Agent 仍然可能“各自为政”
Coding Agent 能显著提高单个任务的执行速度，但它仍然可能停留在个人工具层面。
不同工程师可能使用不同模型、不同提示词和不同工作方式。有人能让 Agent 稳定完成复杂重构，有人却只能生成简单函数。优秀实践依赖个人经验，组织很难追踪 AI 参与了哪些任务、产出了什么，以及失败原因是什么。
这时，新的管理问题会出现：
- 如何沉淀高质量提示词和工程经验；
- 如何统一代码规范、测试标准和交付要求；
- 如何管理 AI 的代码仓与环境权限；
- 如何记录 AI 的执行过程和产出质量；
- 如何让 AI 与需求、缺陷和发布流程连接。
如果这些问题没有得到解决，团队获得的仍然只是“更强的个人生产力工具”，而不是组织级能力。
阶段三：AI 员工，解决的是研发流程与组织协作效率
1. AI 员工不是一个聊天窗口
本文所说的“AI 员工”，并不是简单地给聊天机器人起一个名字，而是指一种组织化的 AI 工作方式：
AI 拥有明确职责、固定工作流、必要的系统权限和可追踪的产出，并在人类设定的规则和审批节点下持续执行任务。
它关注的已经不只是“能不能写出代码”，而是“能不能在复杂流程中稳定出活”。
例如，一条线上工单进入系统后，AI 可以先收集版本信息、日志和历史记录，定位可能涉及的代码仓，形成诊断结论；研发人员确认后，AI 再生成修复方案、补充测试用例、修改代码并执行验证。所有动作、结论和人工反馈都保留在同一条工作流中。
在 ONES 的研发实践中，AI 已被用于工单诊断、逃逸缺陷修复和小需求开发。相关实践数据显示，工单诊断时间由数小时缩短到分钟级，缺陷修复中人工占用时长减少到20分钟以内，小需求的研发投入周期也由周级缩短到天以内。
这些数据的真正意义，不只是“AI 写代码更快”，而是原本分散在多人、多系统和多个等待环节中的工作，被重新组织成了一条可持续流转的人机协作链路。
2. AI 员工需要四类组织能力
第一，明确而稳定的业务流程
AI 必须知道任务在什么条件下开始、完成到什么程度、遇到什么情况需要转交给人。如果流程本身含糊不清，AI 只能依赖猜测。企业不能指望通过一个复杂提示词，修复长期存在的职责和流程问题。
第二，可复用的提示词与 Skills
高价值的 Skills 并不是把操作步骤写得越来越长，而是把专家的经验、判断标准和取舍原则固化下来。例如，缺陷诊断 Skill 不仅要告诉 AI 去哪里查日志，还要说明如何判断问题等级、哪些证据足以支持结论、什么情况下不得自动修改代码。OpenAI 当前也将 Skills 用于向 Coding Agent传递团队标准、工作流程和工作方式，使这些规则能够在不同任务中持续应用。
第三，完整的反馈闭环
AI 不能只获得输入，还要能够观察执行结果。在代码场景中，编译、单元测试、Lint、类型检查和运行日志都是反馈渠道；在产品场景中，API 返回、界面状态和业务数据则帮助 AI 判断操作是否成功。没有反馈，AI 只能生成一个“看起来合理”的答案；有了反馈，AI 才能完成“行动—观察—修正—再行动”的闭环。
第四，可审计的人机协作机制
企业需要清楚地知道：哪一步由 AI 完成；哪一步由人审核；AI 使用了哪些权限；失败后如何回退；最终责任由谁承担。因此，AI 员工不应绕开原有治理体系，而应被纳入账号、权限、审批、审计和效能度量之中。
企业应该如何判断自己处在哪个阶段
三个阶段并不是简单的产品升级关系，也不意味着进入第三阶段后就不再需要代码补全。它们更像三层相互叠加的能力：
阶段 |
主要目标 |
AI 的角色 |
人的主要职责 |
代码补全 |
提高个人操作效率 |
编码助手 |
完整执行任务 |
Coding Agent |
提高任务执行效率 |
独立任务执行者 |
分配任务、审核结果 |
AI 员工 |
提高组织流转效率 |
流程中的稳定协作者 |
设计规则、评审决策、承担责任 |
对于多数企业，更稳妥的路线不是一开始就让 AI 承担复杂需求，而是逐步扩大任务范围：
- 先从代码解释、测试生成和文档补充开始；
- 再尝试边界清晰的缺陷修复和小型重构；
- 接入编译、测试和代码审查反馈；
- 与需求、缺陷和工单流程连接；
- 最后再探索跨系统、长周期的复杂需求开发。
每推进一步，都要同时评估效率、质量、风险和人工审核成本，而不是只统计生成了多少代码。
AI 研发的终点不是“更快”，而是“更顺”
研发团队使用 AI 的三个阶段，对应的是三个不同层次的问题：代码补全解决个人操作效率，Coding Agent 解决完整任务的执行效率，AI 员工则开始解决研发流程和组织协作效率。
真正值得管理者关注的，不是工程师每天调用了多少次模型，而是 AI 是否缩短了任务等待时间、减少了重复沟通、提高了问题闭环速度，并沉淀为可复用的组织能力。
AI 不会自动带来先进的研发管理。只有当流程、知识、反馈和治理机制同时升级时，AI 才能从一个高效工具，真正成为研发团队中稳定、可靠的协作者。
