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 只能生成内容，却无法观察执行结果，它只能不断猜测。当 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 员工进一步探索的，则是：
一个研发组织未来应该怎样工作。
