ONES 如何让 AI 员工处理工单？从自动诊断到人工验收

客户提交一张工单，里面可能只有一句现象描述、几张截图和一段日志。真正耗费研发时间的，往往是后续的复现问题、查日志、定位代码、判断是缺陷、使用问题还是新需求。单个任务不大，但数量一多，就会持续占用工程师处理复杂工作的时间。

AI 很适合接手这类高频、可标准化的分析工作。但关键不是让 AI “自己把工单解决掉”，而是建立一套 AI 自动诊断、人工关键验收、结果继续流转 的协作流程。

要点速览

让 AI 员工处理工单，关键不是自动生成一段回答，而是把 AI 作为一个有明确职责的处理节点嵌入现有工作流。

一套更稳妥的做法通常包括：

• AI 自动读取工单标题、描述、附件、日志以及必要的研发上下文；
• 输出问题类型、复现条件、判断证据、临时解决方案和后续处理建议；
• 由研发或领域负责人对诊断结论进行验收；
• 验收通过后，自动进入需求、缺陷或其他对应流程；
• 验收不通过时，携带人工反馈返回 AI 重新分析；
• 涉及修改代码、测试、发布等高风险动作时，继续设置人工评审节点。

这套方法的核心不是“无人化”，而是把人的工作从大量重复排查转向评审、判断和风险控制。NIST 的 AI 风险管理框架同样强调，应明确人机协作中的职责、监督机制和人工审查流程；在高风险或不可逆动作中保留人工介入，是企业级 Agent 落地的重要原则。

在 ONES 的内部研发实践中，这一模式已经被用于工单诊断、缺陷修复和小需求开发：AI 员工负责具体执行，人负责关键节点验收，再通过 ONES 工作项和工作流完成流转与结果沉淀。

一、为什么工单适合先交给 AI，而不是直接让 AI“接管研发”

很多团队开始尝试 AI Agent 时，第一反应是追求端到端自动化：

收到问题 → AI 分析 → AI 改代码 → AI 发布 → 自动关闭。

技术上越来越接近可行，但管理上并不是最稳妥的起点。

工单有三个典型特点。

1. 数量多，但大量工作属于重复判断

同一种问题，工程师可能已经处理过很多次。区别只是客户环境、版本、日志和触发条件不同。

真正需要完成的动作往往非常固定：读取信息 → 判断问题类型 → 找证据 → 给出结论 → 决定下一步。

这类流程天然适合标准化。

2. 信息分散，但判断规则相对稳定

一张工单很少包含全部答案。AI 可能需要同时查看：

• 标题和问题描述；
• 截图、录屏和日志；
• 产品版本与部署环境；
• 历史工单；
• 代码实现；
• API、测试环境或运行结果。

因此，企业级 AI 工单系统的价值，不只是“模型懂不懂技术”，而在于能不能把正确的上下文和工具交给它。

3. 最终判断仍然存在业务风险

AI 认为这是缺陷，并不代表它一定是缺陷；AI 给出的修复方案技术上可行，也不代表值得采用。

尤其是涉及线上系统、客户数据、代码修改和版本发布时，错误成本远高于生成一段文字。

所以，工单自动化更合适的目标应该是：让 AI 承担高频执行，让人控制关键决策。

ONES 的实践也是如此：AI 员工负责分析、出方案、写用例、写代码和执行测试，人仍负责评审与反馈，业务知识、领域经验和判断力没有被移除。

二、第一步不是训练模型，而是重新设计工单处理流程

要让 AI 真正接手工单，最重要的工作往往不是 Prompt，而是先明确：AI 到底负责哪一步？什么结果算完成？哪里必须经过人？

一个适合企业研发团队的基础流程可以设计为：提交工单 → AI诊断 → 人工验收 → 分类流转 → 后续处理

其中，如果人工验收不通过，则进入：人工反馈 → AI重新诊断 → 再次验收

ONES 内部的工单实践采用的就是类似结构：AI 首先完成诊断，再将结果流转给研发验收；研发确认后，缺陷进入缺陷跟踪流程，需求进入需求流程，判断不正确则返回 AI 重新处理。

可以进一步拆成下面几个节点：

这样设计以后，AI 就不再是旁边一个需要工程师主动打开的聊天窗口，而成为工作流中真正承担责任的“执行角色”。

三、让 AI 诊断工单，输入不能只是一段文字

工单诊断失败，很多时候不是模型能力不足，而是它看到的信息不完整。一套比较完整的输入上下文至少可以分为四类。

第一类：工单本身的信息

包括标题、描述、截图、录屏、日志、环境、版本等。

如果这些信息已经足够，AI 应直接开始判断；如果不足，则应该明确指出还缺什么，而不是强行猜测。

第二类：产品和研发上下文

例如：

• 当前版本有哪些功能；
• 某个页面对应哪个模块；
• 某条 API 如何工作；
• 某段逻辑在哪个代码仓；
• 历史版本是否存在相同实现。

这里有一个很重要的实践经验：成熟软件本身的代码，就是极高密度的系统事实来源。

ONES 内部首先让 AI 学会如何阅读现有代码仓，再基于代码理解业务逻辑和产品行为。目前相关实践覆盖几十个代码仓和超过 300 万行代码。

这并不意味着文档不重要，而是没有必要为了 AI 先花几个月重写所有产品和架构文档。更实际的做法是告诉 AI：代码在哪里、不同仓负责什么、应该怎样读取。

第三类：组织规则

例如什么情况定义为 P1/P2、什么问题需要转研发、什么修改不能直接执行、测试方案应该满足什么标准。这些内容更适合沉淀到 Prompt 和 Skills 中。

真正有价值的 Skill，不应该只是把流程说明复制进去，而应该压缩领域专家长期积累的判断规则、边界和经验。

第四类：反馈渠道

AI 不能只“看资料”。如果要进一步提高准确率，还要让它看到自己的动作有没有产生正确结果，例如：

• 编译是否通过；
• 单元测试是否通过；
• lint 是否报错；
• API 返回什么；
• UI 实际显示什么；
• 测试环境日志发生了什么变化。

这样 AI 才能形成：行动 → 观察 → 修正 → 再行动。而不是生成一次答案以后就结束。

四、不要让 AI 只输出“答案”，而要输出可以验收的结论

企业工单场景里，“我认为这是一个 Bug”价值很低。研发真正需要的是：为什么？证据是什么？接下来怎么办？因此可以规定 AI 的诊断结果至少包含以下内容：

1. 问题分类：缺陷、需求、配置问题、使用问题还是暂无法判断；
2. 诊断结论：一句话描述核心原因；
3. 复现条件：什么环境、版本和操作路径下可以触发；
4. 判断依据：来自日志、代码、截图或运行结果的证据；
5. 影响范围：哪些版本、模块或用户可能受到影响；
6. 临时解决方案：如果暂时无法立即修复，是否存在规避方案；
7. 后续建议：是否转缺陷、是否需要补充信息、修复难度如何。

ONES 的实际工单中，AI 会结合工单信息和代码判断问题类型，并提供复现条件、判断依据、临时解决方案以及后续修复思路。

这个设计有两个好处。

第一，人类评审速度会明显提高，因为不需要重新从零开始调查。

第二，即使 AI 判断错误，团队也能知道它错在什么证据、哪一步推理或者哪项输入不足，从而继续优化工作流。

五、人工验收不是降低自动化程度，而是在正确的位置控制风险

很多人会问：既然最后还要研发审核，为什么不直接让研发自己处理？

区别在于，传统模式中研发负责的是：搜集信息 + 排查 + 复现 + 查代码 + 推理 + 输出结论。人机协作模式下，研发负责的是：审查一份已经完成的分析。两者占用的注意力完全不同。

因此，人类不需要介入 AI 的每一步，而应该集中在几个风险边界，也就是必须重点评审的节点：

• AI 对问题性质的最终判断；
• 修复方案涉及较大影响范围时；
• 测试方案是否覆盖关键路径；
• 代码修改是否符合设计和工程规范；
• 测试结果是否足以支持发布；
• 涉及生产、权限、客户数据或不可逆操作。

NIST AI RMF 明确要求组织定义人机配置中的角色、责任与监督方式，并对 AI 输出和运行状态进行评估、记录和监测。 OpenAI 在企业 Agent 实践指南中也建议，对高风险操作以及超过失败阈值的任务设置人工介入。

换句话说：AI 自动化的目标不是取消检查点，而是让人工检查点变得更少、更集中、更有价值。

六、工单诊断跑通后，再逐步扩展到缺陷修复

自动判断一张工单相对简单。真正进入研发执行以后，风险和复杂度都会显著增加。因此更合理的方式不是一步实现“AI 自动修 Bug”，而是继续把任务拆成多个单一节点。ONES 内部的逃逸缺陷修复流程大致可以概括为：

AI分析根因和修复方案

→ 研发评审

→ AI生成测试方案

→ 测试评审

→ AI修改代码

→ 研发Review代码

→ AI执行测试

→ 人工验收测试结果

→ 进入发布流程

如果某个环节没有通过，就返回对应 AI 节点重新处理，而不是继续往后执行。

这种设计背后的原则非常简单：每个 Agent 节点只解决一个清晰问题。不要要求一个 Agent 做到“分析问题、设计方案、改代码、做测试并发布“。

而应该分别问：

• 根因是什么？
• 修复方案是什么？
• 怎么验证这个方案？
• 根据已经批准的方案改哪些代码？
• 按已经批准的测试用例执行结果是什么？

ONES 将这种思路概括为 Agent 设计中的“高内聚、低耦合”：只提供当前节点真正需要的信息，让每一步目标尽量单一。

这通常比继续堆 Prompt 更有效。

七、如何判断 AI 工单流程到底有没有效果？

AI 项目最容易出现的问题，是 Demo 看起来很好，但没人知道它是否真的提升了组织效率。所以从一开始就应该设置可以持续统计的指标。建议至少观察四类数据：

在 ONES 内部一段阶段性实践中，AI 共诊断 241 条工单，其中 127 条形成明确结论；对已有明确结论的工单统计，一次性接受率为 88%，诊断时间从人工处理的数小时缩短到分钟级。

进入缺陷修复后，内部阶段性数据则包括：235 条完成修复，修复方案一次通过率 77%、测试方案 94%、代码 87%；人工在单个缺陷上的占用时长从数小时降低到 20 分钟以内。

这些数据更适合看作特定研发环境下的实践结果，而不是所有企业部署 AI 后都能复制的通用基准。真正值得参考的是指标体系：不仅统计 AI 做了多少，还要统计结果是否被人接受、人工究竟节省了多少时间。

八、ONES如何把这套方法真正放进研发流程？

如果只使用独立的聊天机器人，上面的协作模型很难长期运行。

原因很简单：工单、负责人、状态、权限、历史记录和后续缺陷都在研发管理系统里，而 AI 在系统外。

企业级 AI 员工需要做的是相反的事情：把 Agent 放进原有工作流，而不是把工作搬到 Agent 的聊天框。

ONES 当前公开的 AI 研发管理方案强调围绕真实项目、真实知识和真实权限运行，并将 AI 接入研发协同和交付流程；ONES Assistant 的生成和分析结果也可以直接回写、沉淀到 ONES 中。

在内部 AI 员工实践中，一套 Agent 节点主要由几部分组成：

1. 工作流

定义：什么时候 AI 做、什么时候人做、什么条件可以进入下一步。

工作项进入 AI 节点后，Agent 自动执行；完成后再进入下一个人工或 AI 节点。

2. 输入和输出字段

不是把整个项目全部塞给模型，而是只开放这个节点真正需要的上下文。

例如工单诊断 Agent 可以读取：

• 工单描述；
• 日志；
• 产品版本；
• 关联信息。

并把诊断结论、问题分类等结果写回指定字段。

3. Prompt 与 Skills

Prompt 定义目标和判断标准，Skills 则让 Agent 具备读取代码、操作 API、使用 UI、修改代码、寻找负责人等实际能力。

4. Workspace 与系统连接

将代码仓、测试环境、外部工具以及必要凭证接入 Agent 的运行环境，使 AI 不只是“生成文字”，而是能够真正执行工作和验证结果。

5. 身份、权限和审计

AI 员工需要拥有明确执行身份。谁修改了工作项、谁提交了代码、Agent 调用了什么能力、最终结果是什么，都应该能够追踪。

这也和 ONES 对企业 AI 的公开原则一致：透明、负责、可控、人类监督与审查，并强调 AI 带来的收益应该能够量化。

九、最容易踩的四个坑

坑一：一开始就追求全自动

流程越长，错误越容易累积。

先自动诊断，再自动生成方案，再逐步开放代码和测试权限，通常比直接做端到端 Agent 更容易成功。

坑二：把所有资料全部塞给 AI

上下文不是越多越好。

与当前任务无关的大量群聊、文档和历史信息反而可能稀释关键线索。Agent 应只读取完成当前节点所需要的信息。

坑三：只有 Prompt，没有反馈环境

如果 AI 改完代码却无法编译、测试、调用 API 或观察 UI，它永远不知道自己到底有没有做对。

反馈闭环通常比继续增加 Prompt 长度更重要。

坑四：只统计 AI 完成了多少任务

“AI 一个月处理了 1000 张工单”并不能证明成功。

更重要的是：多少结果一次通过？多少被打回？人工时间减少了多少？错误发生在哪里？

这些数字才决定 AI 有没有真正成为组织生产力。

结语：AI 员工真正改变的，是人的工作位置

让 AI 处理工单，并不是把工程师从流程中删除。真正的变化是：

过去，工程师花大量时间查信息、排问题、写方案、执行测试；

未来，更多时间可以用于审查结论、做业务判断、处理复杂问题和设计更好的流程。

因此，企业研发场景里的 AI Agent，不应该只是一个更聪明的聊天框，而应该成为现有协作系统中的一个可配置、可授权、可评审、可追踪的执行角色。

工单诊断只是一个很好的起点。当“AI执行—人工验收—反馈修正”这套机制跑通以后，同样的方法还可以继续扩展到缺陷修复、需求开发、测试以及更多标准化业务流程。

FAQ

1. AI员工处理工单后，还需要研发看吗？

需要。更合理的方式不是让研发重新排查一次，而是让研发对 AI 已经完成的诊断进行验收。AI 负责耗时的执行工作，人负责判断结论和控制风险。

2. 用户提交的工单是不是必须写得非常规范？

不一定。自然语言描述、截图和日志都可以成为输入。但信息不足时，系统需要允许 AI 明确提出补充信息要求，而不是为了自动化而强行得出结论。

3. 老系统、代码仓很多，还适合做 AI 工单诊断吗？

可以尝试。关键并不是代码仓少，而是能否让 AI 理解不同代码仓的职责和读取方式。ONES 内部实践覆盖了前端、后端、BI、开放平台等多个代码仓。

4. 如果 AI 判断错了，责任怎么算？

企业场景中不应该把最终责任交给模型。应该通过独立执行身份、日志、权限和人工评审节点，确保 AI 的每次操作都可以追踪，并由明确的业务负责人对关键结果进行确认。ONES 公开的 AI 原则同样强调责任归属、人类监督与审查。

5. 第一次做 AI 员工，应该从哪个场景开始？

优先选择高频、重复、流程清晰、结果容易验收、错误可回退的任务。工单初步诊断、缺陷分类、信息完整性检查通常比“让 AI 独立完成一个大型需求”更适合作为第一阶段 POC。