摘要：研发 AI Agent 的选型，不能只比较代码生成质量或模型能力。对于多代码仓、历史包袱重、研发流程成熟的企业系统，更应判断 AI 是否能理解真实上下文、完成缺陷修复中的人机协作、接收测试反馈并在流程中留下可追溯记录。本文以 ONES 研发团队的 AI 员工实践为案例，给出一套面向研发负责人和技术管理者的选型框架。

本文涉及的工具与能力：研发 AI Agent、AI 编程工具、代码理解、多代码仓、缺陷修复、工作项管理、工作流、代码评审、测试环境、API 测试、UI 验证、CI/CD。

一、为什么不能只看代码生成能力？

AI 编程工具已经能够帮助开发者补全代码、解释函数、生成测试用例，甚至完成一些局部修改。对于个人开发者而言，这类能力足以带来明显的效率提升。

但当企业尝试将 AI 用于真实研发流程时，问题会发生变化。研发负责人关心的通常不是“AI 能不能写出一段代码”，而是：

• 它能否理解一个运行多年的系统，而不是只处理新建项目；

• 它能否结合缺陷描述、日志、附件和代码定位根因；

• 它能否在修改代码后完成测试、识别失败结果并继续修正；

• 它是否能进入需求、缺陷、代码评审和发布流程，而不是只停留在个人终端；

• 它做过什么、谁审核过、为什么被打回，是否可以被团队追溯。

这也是“AI 编程工具”和“研发 AI Agent”的分界线。

前者主要解决个人生产力问题：开发者发起指令，AI 协助完成编码工作。后者则要解决组织协作问题：AI 需要获得上下文、调用真实工具、完成多步骤任务，并将结果交回已有研发流程。

如果没有流程承载，AI 的产出往往难以规模化复用。不同开发者会用不同提示词、不同工具和不同操作路径，最佳实践难以沉淀，结果质量也难以衡量。即使某位工程师用得很好，团队也无法确认这种能力能否稳定复制到其他项目。

因此，选型时需要从“模型是否会写代码”转向“AI 是否能在受控流程中持续交付”。

一个可进入研发流程的 AI Agent，至少应满足四个条件：

1. 能理解当前任务和相关代码，而不是只处理单次对话；

2. 能执行分析、方案、编码和测试等多个步骤；

3. 能接收真实环境反馈，而不是仅依赖文本推理；

4. 能在人工评审、权限控制和过程追溯下协作。

这四个条件并不意味着企业要追求完全自动化。恰恰相反，成熟的研发 AI Agent 应将人和 AI 放在不同但衔接紧密的角色中：AI 处理细节执行，人处理业务判断、技术风险和最终验收。

二、代码理解、缺陷修复与测试闭环

判断一款工具能否真正进入存量研发流程，可以先看三道门槛：它是否读得懂代码、是否修得了缺陷、是否能证明自己做对了。

1. 代码理解：AI 是否看得懂现有系统？

企业系统很少是从零开始的。它们往往经历多年迭代，包含多个前后端代码仓、不同版本分支、历史模块、组件库和外部系统集成。产品文档、架构文档可能不完整，但代码、接口、配置和测试用例仍记录着系统的真实运行方式。

因此，研发 AI Agent 的第一项能力不是“生成新代码”，而是理解存量代码。

选型时，应重点追问：

• 是否支持多个代码仓，并能识别不同仓库的职责与依赖；

• 是否能结合缺陷工作项、日志、截图、附件和历史讨论理解问题；

• 是否支持为不同仓库配置阅读规则、修改规则和领域知识；

• 是否能处理多版本、多分支中的差异，并判断修复方案是否可复用；

• 是否能在受控权限下访问代码，而不是无限制读取或修改全部仓库。

在 ONES 的研发实践中，AI 已绑定 34 个代码仓，覆盖超过 300 万行代码。这一案例说明，多仓库并不必然阻碍 AI 使用；真正的难点在于是否为 AI 建立了“如何读代码”的方法。

例如，AI 需要知道每个仓库承担什么职责、前后端如何关联、哪些模块是公共组件、哪些分支对应不同版本，以及改动一处是否会影响其他仓库。没有这些规则，AI 即使拥有代码访问权限，也可能只能做表层检索，无法形成可靠判断。

对团队而言，代码理解能力可以通过一个简单问题验证：给 AI 一个包含日志、截图和工作项描述的真实问题，它能否说明根因在哪里、依据是什么、影响范围是什么？

如果它只能给出泛泛解释或直接猜测修复方式，说明工具还没有真正进入存量工程语境。

2. 缺陷修复：AI 是否能完成可评审的工程协作？

缺陷修复是检验研发 AI Agent 的典型场景。它比代码补全复杂，因为 AI 不仅要改代码，还要理解问题、设计方案、验证结果，并接受研发与测试人员的审核。

一个较完整的缺陷修复流程应包括：

1. 读取缺陷标题、描述、日志、附件和相关上下文；

2. 结合代码分析根因，给出可验证的依据；

3. 生成修复方案，并说明修改范围和风险；

4. 由研发人员评审方案，必要时打回要求重新设计；

5. 生成测试方案，覆盖修复点和潜在影响范围；

6. 在方案确认后修改代码并提交；

7. 接受代码评审，再进入测试与发布流程。

其中最容易被忽略的是“可评审性”。

很多 AI 工具可以直接生成代码，但如果团队看不到它为什么做出某个判断、方案依据是什么、改动范围有多大，那么一旦发生问题，研发人员仍需从头分析，AI 反而增加了审核成本。

因此，选型时不应只问“能否自动修复 Bug”，而应问：

• 能否把根因、证据和修复方案结构化输出；

• 是否支持在改代码前进行人工方案评审；

• 是否能将代码修改、提交记录和评审结果放回同一流程；

• 当方案被打回时，能否读取反馈后重新分析，而不是重新开始一次对话；

• 是否能处理同一缺陷在多个版本或分支中的差异。

真正能进入研发流程的 AI Agent，不是把人从流程中移除，而是让人将精力从重复执行转向判断、审核和风险控制。

3. 测试闭环：AI 能否从结果中学习和修正？

AI 在研发中最容易被高估的环节，是测试。

生成测试用例并不等于完成测试；执行一条脚本并不等于验证业务结果；测试结果显示通过，也不等于所有风险都被排除。

如果 AI 只接收任务指令、生成代码和测试文本，却看不到编译结果、单测结果、运行日志、页面状态和接口返回，它本质上仍在猜测。

因此，测试闭环是研发 AI Agent 的第三道门槛。选型时，需要判断工具是否能获得足够的反馈渠道：

能力	选型时应确认的问题
编译与静态检查	能否执行编译、Lint、依赖检查等基础验证？
单元与集成测试	能否运行已有测试，并读取失败信息？
测试环境	能否创建、更新或连接必要的测试环境？
API 验证	能否调用接口、判断响应并保存结果？
UI 验证	涉及页面改动时，能否执行操作并确认界面状态？
失败处理	是否能根据日志、报错和测试证据调整方案？
结果沉淀	是否能保存截图、录屏、运行数据和测试报告？
人工验收	是否支持将异常项交由研发、测试人员确认？

测试闭环的本质是“行动—观察—修正—再行动”。

如果没有反馈渠道，AI 只能生成看似合理的方案；如果能看到真实结果，它才有机会判断修改是否有效。对研发负责人而言，这往往比模型回答是否流畅更重要。

三、ONES 如何将 AI 员工接入研发流程？

从选型视角看，研发 AI Agent 的能力不能只看模型层，还要看它如何获得上下文、如何执行任务、如何接入流程、如何受到权限和人工治理约束。

ONES 的实践提供了一个值得观察的路径：不是将 AI 放在研发流程之外，而是将 AI 员工嵌入工作项和工作流，使其与产品、研发、测试人员在同一协作体系中工作。

1. 工作项：为 AI 提供连续且可追溯的上下文

一个真实缺陷往往不只有一句描述。它可能包含用户反馈、日志、截图、录屏、历史评论、关联需求、版本信息和代码仓线索。

如果这些信息散落在客服系统、聊天记录、代码平台和文档中，AI 每一步都需要重新被告知背景，研发人员也难以确认它到底依据什么做出判断。

ONES 工作项可以承载这些上下文。缺陷描述、附件、AI 的根因分析、修复方案、人工评审意见、测试方案和测试记录，都可以围绕同一工作项沉淀。

这带来三个直接价值：

• 上下文连续：AI 在不同节点可以读取任务历史和必要字段，而不必重复提问；

• 过程可审：研发和测试人员可以查看 AI 的判断依据、修改过程和测试证据；

• 经验可复用：经过验证的流程、输入输出字段和评审方式可以沉淀为团队实践，而不是只留在个人终端。

对选型者来说，一个重要问题是：工具是否能把 AI 的输入和输出连接到真实业务对象，还是只能在独立聊天窗口中工作？前者更容易形成组织能力，后者通常更依赖个人使用习惯。

2. 工作流：为 AI 和人工划分明确的责任边界

研发 AI Agent 的风险，往往不来自某个单独动作，而来自它在缺少检查的情况下连续完成多个动作。

例如，AI 先误解缺陷，再基于错误理解提出方案、修改代码并判断测试通过。若过程没有评审节点，错误会一路放大。

ONES 工作流的价值，在于将缺陷修复拆成不同节点：根因分析、修复方案、测试方案、编码、代码评审、测试、验收和发布可以分别流转。

AI 员工接管需要执行的节点；研发和测试人员则在关键节点做判断：

• 研发评审根因分析和修复方案是否合理；

• 测试评审测试方案是否覆盖充分；

• 研发评审代码是否符合工程规范；

• 研发或测试验收测试结果，确认异常项是否为误判；

• 团队按既有发布节奏完成上线。

这种机制并不要求研发人员全程盯着 AI 写代码。相反，研发人员可以将注意力集中在方案、代码和异常结果上，而把大量重复性执行工作交给 AI。

从组织治理角度看，工作流解决的是两个问题：谁在何时负责什么，以及当 AI 的结果不可靠时，如何及时中断、反馈和修正。

3. Agent、Skills 与工作区：为 AI 提供执行能力和受控环境

工作项和工作流解决了上下文与协作问题，但 AI 还需要实际执行条件。

在 ONES 的案例中，Agent 可以定义目标、提示词、输入字段和输出字段。输入输出字段并非简单配置项，它们决定 AI 在当前节点能够看到什么、需要产出什么。

例如，缺陷分析节点需要读取标题、日志、附件和相关代码线索；测试节点则需要读取已确认的测试方案、代码状态和环境信息。将不同任务拆分为相对单一的目标，可以减少 AI 被无关信息干扰的风险。

Skills 用于扩展 Agent 的实际能力。对于研发场景，技能可以包括代码理解、代码修改、UI 操作、API 调用或其他工具调用。AI 若要稳定处理存量系统，首先需要具备阅读代码仓和理解模块关系的能力；若要完成测试闭环，还需要能操作环境并获取结果反馈。

工作区则将执行能力与具体业务环境连接起来。不同产品线、不同代码仓、不同测试环境拥有不同权限和凭证，AI 不应在模糊、无限制的环境中运行。通过工作区绑定代码仓、管理凭证和控制对外部系统的连接，团队可以将执行范围限定在可管理边界内。

因此，ONES 在这一实践中形成的是一条完整链路：

工作项提供上下文 → 工作流划分节点与责任 → Agent 定义目标与输入输出 → Skills 提供执行能力 → 工作区绑定代码仓与受控环境 → 人工在关键节点审核和验收

这也是评估研发 AI Agent 时，应同时关注研发管理平台与 AI 执行能力的原因。

四、从逃逸缺陷修复案例看数据和边界

在 ONES 逃逸缺陷修复场景中，AI 已完成 235 条修复；修复方案、测试方案和代码的一次性通过率分别为 77%、94% 和 87%；测试有效率为 50%；缺陷处理时长由数小时缩短至 20 分钟以内。（数据来源见文末）

首先，修复方案一次性通过率为 77%，意味着仍有约四分之一的方案需要研发反馈或重新设计。这说明 AI 适合先生成可评审的第一版，而不适合跳过方案评审直接改代码。

其次，测试方案一次性通过率为 94%，高于修复方案和代码。这很符合工程实践：当修复方向已经确定后，围绕该方向设计测试用例相对更容易；但如果根因和修复边界判断错误，后续测试再完整也无法弥补前面的偏差。

再次，代码一次性通过率为 87%，说明经过前序方案和测试评审后，AI 的编码结果会更稳定。这也反向说明了分阶段流程的价值：不要把所有质量压力都放在最终代码评审上，而应在需求、方案和测试阶段逐步降低不确定性。

最值得注意的是测试有效率只有 50%。这并不意味着 AI 测试没有价值，而是提醒团队：复杂系统中的 UI 操作、环境状态、接口路径和异常场景仍可能造成误判。AI 可以承担测试执行、证据收集和初步排查，但最终验收仍必须保留人工判断。

对于选型者而言，这些数据的正确用法不是拿来比较“谁的数字更高”，而是据此设计 POC 验证：

• 方案是否可被研发快速审核？

• 被打回后，AI 能否根据反馈修正？

• 测试是否覆盖真实环境和关键路径？

• 失败项中有多少是真问题、多少是误判？

• 人工审核时间是否下降，而不是转移到更复杂的返工中？

• 过程是否能留在团队的工作项和工作流中？

只有当这些问题得到回答，团队才能判断工具的“落地能力”，而不只是“演示能力”。

五、研发 AI Agent 选型清单

研发 AI Agent 的选型不应依赖单次演示。更可靠的方式，是选择一个真实但风险可控的缺陷或小需求，按下表逐项验证。

维度	需要验证的问题
代码理解	能否理解存量代码、多仓库、分支、日志和业务上下文？
工作项接入	能否读取缺陷、需求、附件、字段和历史讨论？
方案质量	能否输出根因、证据、修复方案和风险说明？
人工评审	是否支持方案、代码、测试等关键节点的人工审核与打回？
编码执行	能否在受控范围内修改代码、提交变更并保留记录？
测试闭环	能否完成编译、单测、Lint、API、UI 或运行验证，并读取失败反馈？
测试证据	能否保存日志、截图、录屏、报告和异常项说明？
流程回写	能否将分析、状态、结果和证据回写到工作项与工作流？
权限安全	是否具备执行身份、代码仓绑定、凭证管理和工作区隔离？
组织复用	是否能将提示词、Skills、字段规则和工作流沉淀为可复用实践？

除了能力清单，还应提前确定 POC 的验收指标。建议至少包含四类：

• 质量指标：方案一次性通过率、代码评审通过率、测试有效率；

• 效率指标：从任务进入流程到人工确认完成的时长；

• 人工投入指标：研发、测试人员花在重复执行上的时间是否下降；

• 风险指标：误判数量、高风险变更数量、回滚或重新修复情况。

常见问题 FAQ

1. 研发 AI Agent 与普通 AI 编程工具有什么区别？

普通工具主要服务于个人编码；研发 AI Agent 则需要接入工作项、代码仓、测试和发布流程，并在人工治理下完成多步骤任务。

2. 多代码仓项目能使用研发 AI Agent 吗？

可以，但必须为 AI 提供仓库职责、依赖关系、阅读规则和权限边界。多仓库不是最大障碍，缺少结构化上下文才是。

3. AI 修复缺陷后还需要人工测试吗？

需要。AI 可以减少分析和回归成本，但复杂业务系统中仍存在误判、边界遗漏和环境差异。人工验收是必要的质量边界。

4. 是否应该从复杂需求开始试点？

不建议。更适合从真实但范围可控的缺陷、工单诊断或小需求开始，先验证上下文、流程、测试和治理是否跑通，再逐步扩大范围。

资料来源与写作说明

本文以 ONES 研发团队《AI 员工在 ONES 研发中的落地成果及工程实践》直播中的案例为观察对象，结合公开回放进行整理与分析。

文中涉及的流程、能力与数据均来自该案例，不构成对其他产品的实测排名，也不代表其他企业或项目的普遍效果。

直播回放：观看视频号回放