AI 正在从单纯的代码补全工具，逐步走向完整的软件研发流程。本文基于 ONES 研发团队真实的 AI 员工落地实践，介绍 AI 如何参与工单诊断、缺陷修复与小需求开发，以及人在其中承担的评审、把关与决策角色。阶段性实践数据显示，AI 已参与 241 条工单诊断和 235 条缺陷修复，工单明确结论的一次性接受率达到 88%，缺陷修复方案一次性通过率达到 77%。这些实践说明，企业部署 AI 员工的关键不仅在于大模型能力，更在于代码上下文、Skills、反馈闭环以及人机协作流程的整体设计。

关键词： AI员工、AI研发流程、AI Agent、工单诊断、缺陷修复、需求开发、研发效能

内容说明： 本文整理自 ONES AI 研发负责人的直播分享及配套实践材料，涉及的数据均为分享时点下的 ONES 内部阶段性实践统计，并不代表所有企业、所有研发场景中的普遍效果。

一、AI正在从“辅助写代码”走向“承担任务”

过去几年，AI 在软件研发中的角色已经发生了显著变化。

最初，研发团队引入 AI，主要是为了进行代码补全、减少重复输入。随着 Coding Agent 能力持续增强，AI 开始具备理解代码、生成代码的能力，甚至能够完成部分相对完整的开发任务。

但对于一个研发组织而言，“工程师写代码更快”并不等同于“整个研发流程效率更高”。

工单分析、缺陷排查、测试方案设计、小需求开发等大量工作，依然需要产品、研发和测试人员持续投入时间。同时，不同工程师使用 AI 的方式、深度和习惯存在明显差异，也很难沉淀为稳定的组织级能力。

ONES 内部的 AI 研发实践，大致经历了三个阶段。

第一阶段是智能补全。2025 年 7 月以前，主要通过 Copilot、Cursor 等工具减少代码输入量和部分思考时间，工程师个人体感效率提升约 30%，但组织整体开发周期变化并不明显。

第二阶段是 Coding Agent。随着 Codex、CC 等工具逐步进入研发过程，AI 开始承担更多代码编写工作，个人效率和组织效率都出现了更明显的提升。但研发团队依然要处理大量琐碎任务，而且每个人使用 AI 的深度不同，最佳实践也难以沉淀成统一能力。

第三阶段，则是 Coding Agent + AI 员工。

在这一阶段，AI 不再只是等待某位工程师打开对话窗口并手动下发任务，而是被真正嵌入研发工作流，在指定节点自动接手工单诊断、缺陷修复、小需求开发等任务。

根据 ONES 分享时的阶段性统计，引入 AI 员工后，缺陷修复带宽和小需求流转效率提升约 3～5 倍。

这也是 AI 员工与常规 AI Coding 工具之间的核心差异之一：

Coding 工具主要提升个人效率，AI 员工则进一步进入流程，成为组织协作中的执行角色。

二、AI员工如何参与研发？核心是重新分工

企业将 AI 引入研发流程，并不意味着把一个需求直接交给 AI，然后等待最终交付结果。

从 ONES 当前的实践来看，更现实、更可落地的方式是：

AI 负责大量具体执行动作，人负责关键节点的判断、评审与反馈。

例如在缺陷修复过程中，AI 可以先读取缺陷信息和相关代码，分析根因并设计修复方案；研发人员负责判断方案是否合理。方案通过后，AI 再编写测试方案，由测试人员评审；随后 AI 修改代码，研发进行 Code Review；代码通过以后，再由 AI 执行测试，人继续审核测试结果。

因此，一个完整研发流程中往往会持续出现：

AI 执行 → 人评审 → AI 继续执行 → 人再次评审。

ONES 的实践材料也明确指出，AI 员工当前主要承担出方案、写用例、写代码和执行测试等执行性动作，而人的业务知识、领域理解和判断能力仍然十分关键。

基于这一实践，可以得出一个更贴近现实的判断：

现阶段企业引入 AI 员工的目标，不应简单理解为“取消人工”，而应聚焦于减少人在标准化执行工作中的投入，把人的精力集中到业务判断、风险控制和复杂问题处理上。

三、场景一：AI员工如何做工单诊断？

工单诊断是 ONES 较早落地 AI 员工的研发应用场景之一。

一条客户工单通常不仅包含一两句话的问题描述，还可能附带截图、日志、录屏等材料。研发人员需要先理解客户究竟遇到了什么问题，再结合代码判断它到底是产品缺陷、需求反馈还是使用问题。

在传统方式下，这一过程通常需要研发人员人工逐步排查。

在 ONES 的流程中，工单进入系统后，可以先由 AI 员工进行初步诊断。

AI 会读取工单标题、描述和附件，并结合相关代码分析问题。如果判断为缺陷，它还可以给出复现条件、判断依据、可能的临时解决方案以及后续修复思路。

分析完成后，结果并不会直接成为最终结论，而是流转给研发人员进行验收。

如果研发确认诊断正确，工单继续进入后续流程；如果判断不准确，则可以打回并补充反馈，让 AI 再次分析。

工单诊断的实际效果如何？

根据 ONES 研发团队在直播中披露的阶段性实践数据：

AI 累计参与诊断 241 条工单，其中 127 条已经形成明确结论。对于已经形成明确结论的工单，其诊断结果一次性接受率约为 88%，诊断时间由传统人工处理的数小时级缩短到分钟级。

这里需要特别说明，“一次性接受率 88%”并不等于所有工单的“准确率为 88%”。其统计口径是：在已经形成明确结论的工单中，AI 首次给出的诊断无需研发打回重新分析即可被接受的比例。

AI 工单诊断还有一个人工处理方式难以提供的特点：持续响应能力。

客户可能会在夜间或周末提交问题。如果由 AI 先完成初步诊断，团队就无需等到研发人员上线后才开始排查，也更有机会缩短客户问题从提交到进入处理流程之间的等待时间。

四、场景二：AI员工如何参与缺陷修复？

相比工单诊断，“修 Bug”对 AI 的要求显然更高。

工单诊断主要回答“这是什么问题”，而缺陷修复还需要进一步回答三个问题：为什么会出现问题？应该如何修复？修改之后又该如何证明它确实被修好了？

在 ONES 当前的缺陷修复流程中，AI 首先根据缺陷标题、描述、附件和代码分析问题根因，并提出修复方案。研发人员确认方案后，AI 再制定测试方案和测试用例，由测试人员评审。随后，AI 才真正进入 Coding 阶段，修改并提交代码。

代码提交之后，仍然需要研发人员进行 Review。代码审核通过后，AI 按照此前设计的测试方案执行测试，包括必要的静态检查、API 测试和 UI 验证，并保留相关测试结果。

最终，人继续审核 AI 的测试结果，再进入后续发布流程。也就是说，AI 虽然承担了大量研发工作，但关键质量关口并没有消失。

缺陷修复的阶段性数据

根据 ONES 研发团队本次分享时的内部统计，AI 已累计完成 235 条逃逸缺陷修复。

其中：

修复方案一次性通过率约为 77%，测试方案一次性通过率约为 94%，代码一次性通过率约为 87%；单个缺陷对研发人员的实际时间占用，可以从原来的数小时减少到 20 分钟以内。

需要注意的是，AI 在不同研发环节中的表现并不完全一致。

同一批实践数据中，AI 测试有效率约为 50%。直播中进一步解释，在操作 ONES 这样的复杂业务系统时，AI 有时会因为操作路径不正确、没有找到正确入口等原因，把实际可能正常的结果判断为“不通过”。

因此，企业评估研发 AI 时，不应只看“代码能不能生成”，更应该分别观察需求理解、方案设计、Coding、测试等不同节点的真实效果。

五、场景三：AI员工可以参与需求开发吗？

需求开发比修复一个已有缺陷更加复杂，因为 AI 首先要正确理解“要做什么”。

在 ONES 的小需求开发流程中，产品经理提交原始需求后，AI 首先进行需求分析，并形成包含业务规则和 Use Case 等内容的 PRD。

产品经理对 PRD 进行 Review。

需求理解确认后，AI 再设计技术方案，由研发人员评审；随后继续生成测试方案、编写代码并执行测试。

因此，与缺陷修复相比，小需求开发只是进一步向研发流程前端延伸，增加了一个非常关键的“需求理解”环节。

ONES 当前的实践已经覆盖传统情况下研发周期约为 1～2 周的小需求。

从阶段性效果来看，需求理解一次性通过率约为 70%，技术方案一次性通过率约为 56%，代码一次性通过率约为 44%；研发人员在这类需求上的实际投入周期，可以从原来的周级缩短到一天以内。

这些数据也反映出一个较为典型的规律：

任务越复杂，AI 第一次提交结果就完全满足要求的概率通常越低，人机协作的重要性也就越高。

因此，AI 员工的价值并不一定意味着“第一次交付就达到 100%”。

更现实的衡量方式是：原本需要人花大量时间亲自分析和执行的工作，现在是否可以先由 AI 完成大部分内容，再由人把时间集中在 Review、判断和少量调整上。

六、300万行代码、34个代码仓，AI为什么还能参与老系统开发？

很多研发团队在评估 AI Agent 时都会遇到一个问题：

新项目也许更容易让 AI 编写，但一个已经运行多年、历史代码复杂、产品文档又不一定完善的大型软件系统，AI 还能不能真正参与研发？

ONES 的实践给出了一个值得借鉴的经验：

对于成熟的软件系统，代码本身就是非常重要的知识来源。

一个长期被真实用户使用的系统，即使代码质量并不完美，它依然沉淀了大量真实的业务逻辑、数据结构、技术实现以及系统之间的关系。

所以，让 AI 进入成熟系统，并不一定需要先花大量时间重新编写完整的产品文档和技术文档。

更关键的是让 AI 知道：这些代码应该如何阅读和理解。

在 ONES 的工程实践中，一个重要的基础能力是 understand-ones-code Skill，用来告诉 AI 如何理解 ONES 的代码仓和模块结构。

在此基础上，再进一步提供修改代码、使用 API、操作 UI、创建测试环境等能力。

根据分享时的数据，目前 AI 面对的是 34 个代码仓、超过 300 万行代码的企业级系统。因此，从 ONES 当前的实践经验来看，判断一个成熟项目是否适合引入 AI，不能只看“代码量大不大”或者“历史包袱重不重”。

更值得关注的是：AI 能否知道去哪里获取正确上下文、不同代码仓分别承担什么职责，以及修改完成后应该如何验证结果。

七、让AI员工稳定“出活”，关键不只是模型

如果企业希望 AI 从偶尔“写对一次代码”，变成持续参与研发流程，就必须解决模型之外的工程问题。

ONES 在实践中总结出的第一个关键点，是代码和有效上下文。

AI 需要知道当前任务与哪些业务、哪些模块、哪些代码相关，而不是简单地把大量资料一股脑塞进上下文。

第二个关键点是 Prompt 和 Skills。

这里的价值并不在于写出越来越长的提示词，而在于让真正懂业务、懂系统的人，把高价值经验、判断标准和执行方法沉淀进去。ONES 的实践认为，如果只是让 AI 自动生成大量产品和技术文档，再把这些内容重新提供给 AI，其中的冗余和噪声甚至可能削弱模型表现。

第三个关键点，是反馈闭环。

编译结果、单元测试、API、UI、测试环境、日志等内容，本质上都可以成为 AI 判断“自己到底做没做对”的反馈信号。如果 AI 只会产出内容，却无法看到执行后的实际结果，那它本质上仍然只能不断猜测。只有当它既能动手执行、又能观察当前状态，还能识别问题并持续修正，真正的“行动—观察—修正—再行动”闭环才算建立起来。

第四个关键点，是高内聚、低耦合的 Agent 和流程设计。

不要一次给 AI 一个无限大的目标，同时塞入大量无关信息，而应该把复杂任务拆解成边界清晰的环节。需求分析就是需求分析，技术方案就是技术方案，Coding 就是 Coding，测试就是测试。每个 Agent 或流程节点只解决相对明确的问题，再通过工作流把这些任务串联起来。

从这些实践可以看到：

模型能力决定 AI 能做到什么，而工程设计很大程度上决定 AI 能否长期、稳定地做到。

八、AI员工会取代研发工程师吗？

至少从 ONES 当前的实践结果来看，更准确的表述并不是“替代研发人员”，而是人与 AI 的工作边界正在重新划分。

当 AI 可以阅读代码、分析问题、制定方案、编写代码并执行测试之后，工程师确实不再需要亲自完成所有细节性工作。

但需求是否理解正确、技术方案是否合理、修改范围是否存在风险、代码是否符合长期架构要求，这些问题仍然需要业务知识、工程经验和判断能力。

人的角色因此可能逐渐从“执行大量研发动作”，转向：定义问题、评审结果、控制风险，以及设计让 AI 能够稳定工作的流程和能力体系。

AI 承担更多执行，人承担更关键的判断。

从企业研发管理的角度看，这可能比简单讨论“AI 会不会替代程序员”更接近当前真实发生的变化。

关于AI员工参与研发的常见问题 FAQ

Q：AI员工和AI Coding工具有什么区别？

A：AI Coding 工具的核心作用，主要仍然是为单个工程师“提效”——无论是写代码还是做分析，通常都需要工程师先发起任务，它才会开始介入。AI 员工则更进一步，不只是提供辅助，而是直接嵌入工作项、研发流程以及组织上下文中。任务一旦推进到某个特定节点，AI 就可以按照预设好的工作流和 Skills 自动接手，把该完成的动作做完，再继续流转给人，或者交给下一个节点处理。所以，二者真正拉开差距的地方，并不只是模型本身，更关键的是：AI 是否真正进入了组织流程。

Q：没有完善的产品文档和技术文档，还能使用AI吗？

A：从 ONES 的实践来看，可以。对于成熟系统，真实代码本身就是非常重要的系统描述。更关键的是通过 Skills 等方式，让 AI 知道代码结构、模块关系以及正确的阅读和修改方式。这并不意味着文档不重要，而是企业不一定需要等到所有文档都补齐后，才能开始尝试 AI 研发。

Q：AI员工可以完全取消人工Review吗？

A：从目前的实践数据来看，并不适合。无论是工单诊断、修复方案、技术方案还是代码，都仍然存在需要人工反馈和调整的情况。更可靠的方式，是让 AI 承担大量执行性工作，同时在人真正需要发挥业务判断和风险控制能力的位置保留 Review 节点。

结语：AI研发的下一个问题，不再只是“怎么让AI写代码”

从代码补全，到 Coding Agent，再到进入工作流的 AI 员工，AI 在软件研发中的角色正在持续向前演进。

当 AI 可以持续参与工单诊断、缺陷修复和需求开发时，真正值得研发团队关注的问题，已经不只是“AI 写代码快不快”。

而是：哪些研发任务适合交给 AI？哪些判断必须由人负责？如何让 AI 获得正确的上下文和反馈？又如何把人与 AI 纳入同一套可管理、可评审、可追踪的研发流程？

ONES 当前的实践提供了一条可参考的路径：

从边界清晰的任务开始，让 AI 承担执行，让人保留关键判断；通过代码上下文、Skills、反馈闭环和工作流不断提升 AI 的稳定性，再逐步扩大 AI 能够承担的任务范围。

如果说 Coding Agent 首先改变的是“一个工程师如何写代码”，那么 AI 员工进一步探索的，则是：

一个研发组织未来应该如何工作。