AI研发流程自动化落地时，容易把所有环节都交给模型处理，结果确定性规则和需要理解上下文的判断混在一起，流程难以验收。更稳妥的路径是先划分AI执行、规则自动化和人工处理的边界，再选一个高频、低风险、输入输出明确的节点做试点，定义输出字段与确认点，把结果写回工作项或文档，用返工率和处理时长验证后再扩展。流程结果最终要落到可追踪的工作项与文档状态中，ONES可承载这一层记录与协作。
要点总览（TL;DR）
- 先按三个问题划分节点归属：输入是否结构化、判断是否需要理解上下文、出错代价是否可回退，把每个节点标注为AI执行、规则自动化或人工处理。
- 首轮只选一个试点节点，用频次、输入输出可定义、错误可回退、有明确验收人四个条件打分排序，避开跨系统、跨团队的复杂链路。
- 流程设计要写清触发条件、输入材料、AI输出字段与格式、人工确认点和退回路径，结果写回工作项或文档并保留确认记录。
- 验证看处理时长、返工率、确认人修改比例三个指标，按周观察三到四周，再判断达标、继续调整还是停止扩展。
先划分AI执行与规则自动化的边界
划分边界的目的是让每个流程节点都有明确的责任主体：由AI生成判断建议、由规则引擎执行确定性动作，还是保留人工处理。操作方法是对节点清单中的每一项依次回答三个问题，再根据答案组合确定归属。
第一个问题：输入是否结构化。字段值、状态码、日期、枚举选项这类输入，规则可以直接判断；会议记录、缺陷描述、用户反馈、评审意见这类自然语言材料，需要理解上下文才能处理。第二个问题：判断是否需要理解语义。判断“状态是否为已完成”属于字段比较，判断“这条反馈是否属于性能问题”需要语义理解。第三个问题：出错代价是否可回退。生成一条待确认的建议、草稿或分类标签，错了可以修改；直接关闭工单、变更发布状态、删除数据，错了影响面大，应保留人工确认或交给规则做严格校验。
三个问题的答案组合后，节点归属大致如下：
| 节点类型 | 典型例子 | 建议归属 |
|---|---|---|
| 需要理解文本与上下文，输出为建议或草稿 | 需求整理与拆解建议、缺陷归因、测试用例初稿、评审意见汇总、发布说明编写 | AI执行，人工确认后生效 |
| 输入为结构化字段，判断规则明确 | 状态流转校验、必填字段检查、定时提醒、超期升级、权限校验 | 规则自动化 |
| 出错代价高且难以回退，或涉及责任认定 | 发布审批、缺陷严重级别最终定级、对外承诺变更 | 人工处理，AI可提供参考信息 |
| 输入材料不完整或判断标准尚未统一 | 跨团队优先级仲裁、模糊需求的最终范围确认 | 暂留人工，待条件成熟再评估 |
边界划分的结果要记录成一份节点清单，而不是停留在讨论中。清单至少包含这些列：节点名称、所属流程阶段、输入材料、当前处理方式、三个判断问题的答案、归属结论（AI执行/规则自动化/人工）、出错后的回退方式、备注。清单由流程负责人维护，每新增一个候选节点就补一行，后续选试点和设计流程都从这份清单出发。
选试点节点：四个筛选条件与评估表
节点清单里标注为“AI执行”的节点可能不止一个，首轮只选一个。筛选条件有四个：频次足够高，每周都有稳定发生量，否则验证周期会被拉长；输入输出可定义，能说清AI拿什么材料、产出哪些字段；错误可回退，输出错了可以修改或重做，不直接造成对外影响；有明确验收人，知道谁来判断输出是否合格。四个条件同时满足的节点才进入候选排序。
用下表对候选节点逐项打分，1分表示弱、3分表示强，加权后排序。权重可按团队实际情况调整，但首轮建议把“错误可回退”和“有明确验收人”设为必要条件，不满足的直接排除。
| 候选节点 | 频次（权重30%） | 输入输出可定义（25%） | 错误可回退（25%） | 验收人明确（20%） | 加权得分 | 排序 |
|---|---|---|---|---|---|---|
| 缺陷归因与建议处理人 | 3 | 3 | 3 | 3 | 3.00 | 1 |
| 测试用例初稿生成 | 2 | 3 | 3 | 3 | 2.70 | 2 |
| 评审意见汇总 | 2 | 2 | 3 | 2 | 2.25 | 3 |
| 发布说明编写 | 1 | 3 | 3 | 2 | 2.20 | 4 |
表中分值为演示情景，团队应按自己的实际发生量和材料完整度重新打分。排序第一的节点进入流程设计，其余节点保留在清单中，等首轮验证达标后再评估。
首轮不选跨系统、跨团队的复杂链路，原因有三点。链路一长，输入材料分散在多个系统，任何一处缺失都会让AI输出质量不稳定，难以判断问题出在模型还是数据；跨团队意味着确认人和责任边界不清晰，试点阶段出现分歧时缺少快速裁决机制；复杂链路的失败影响面更大，一旦输出错误波及下游多个环节，回退成本高，容易让团队对后续扩展失去信心。先用单节点跑通“输入—生成—确认—写回”的完整闭环，再考虑串联。
设计一条AI自动化流程：输入、动作、输出与确认点
选定节点后，把它展开成一条可执行的流程设计说明。设计说明要回答四个问题：什么时候触发、AI拿到什么材料、输出必须包含哪些字段、人在哪里确认以及结果写回哪里。
触发条件要具体到事件和状态。例如“缺陷单创建并提交后触发”，或“需求文档进入评审状态时触发”。触发条件写清楚，才能避免重复触发或漏触发。输入材料列明来源和范围：缺陷单的标题、描述、复现步骤、环境信息、历史相似缺陷记录。材料清单要注明哪些是必需项，缺失时流程是等待补齐还是带缺省信息继续执行。
AI输出必须包含固定字段和格式，便于确认人快速判断，也便于后续统计。建议至少包含：结论或分类字段、依据说明、置信度或不确定项标注、建议的下一步动作。字段用结构化格式承载，避免只返回一段自由文本，否则确认人每次都要重新理解输出结构。
人工确认点是流程设计中的关键控制。确认人看到输出后有三个动作：接受并写回、修改后写回、退回重做。退回时要记录退回原因分类，例如“分类错误”“依据不足”“材料缺失”，这些记录是后续调整提示词和输入材料的依据。确认点应设置在结果生效之前，而不是生效之后补救。
结果写回位置要事先约定：写回哪个工作项、更新哪些字段、是否改变状态、是否通知相关人。写回动作可以由确认人手动执行，也可以在确认通过后由流程自动执行，但状态变更类动作建议保留确认环节。以ONES为例，ONES Assistant可理解项目、工作项、迭代和Wiki页面等上下文，把自然语言指令转化为可追踪的工作，并将结果保存为工作项、Wiki页面等内容，适合承载“生成建议—人工确认—写回记录”这一段流程；具体的状态流转配置需按团队权限和流程设置确定。
角色分工与各环节交付物
流程上线后无人负责是常见失败原因。每个节点至少涉及四类角色，职责和交付物要在设计阶段就写清楚。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 流程负责人 | 维护节点清单，组织试点选择与验证，决定是否扩展 | 节点清单、试点评估表、验证结论 | 试点启动前、每周复盘、扩展决策时 |
| 业务节点负责人 | 定义触发条件和输入材料，保证材料完整可用 | 流程设计说明中的输入清单、材料补齐规则 | 流程设计阶段、材料缺失时 |
| AI输出确认人 | 审核AI输出，执行接受、修改或退回 | 确认记录、退回原因分类 | 每次输出生成后 |
| 平台维护人 | 维护提示词、字段格式、写回配置和权限 | 配置变更记录、问题处理记录 | 流程上线前、输出异常时 |
确认人缺席时，流程应暂停在待确认状态并通知备份确认人，不由系统自动通过。输出不合格时，退回路径要明确：退回给AI重新生成，还是退回给业务节点负责人补充材料，两种情况在流程设计说明中分别写明处理动作和时限。平台维护人收到退回原因分类后，按周汇总高频问题，判断是提示词需要调整、输入材料需要补充，还是该节点暂不适合AI执行。
示例：缺陷单归因与修复建议的自动化流程
以下为演示情景，用于说明流程结构，不代表真实客户案例。某团队选择“缺陷归因与建议处理人”作为首个试点节点。
触发条件：缺陷单创建并提交后自动触发。输入材料包括缺陷标题、详细描述、复现步骤、环境与版本信息、附件日志，以及系统中历史相似缺陷的记录。材料缺失时，流程标记“材料不完整”并通知提交人补充，不进入生成环节。
AI输出字段固定为四项：归因分类（如前端交互、接口异常、数据问题、环境配置、需求理解偏差）、疑似模块、建议处理人、判断依据摘要。输出以结构化字段形式呈现，确认人可逐项查看。
确认人收到输出后执行审核：分类和模块判断合理则接受，系统将字段写回缺陷单并通知建议处理人；判断有偏差则直接修改字段后写回，同时选择退回原因；依据不足或材料明显缺失则退回，由提交人补充信息后重新触发。退回原因按“分类错误”“模块判断错误”“依据不足”“材料缺失”四类记录。
结果写回后，缺陷单进入“待处理”状态并指派给确认后的处理人，原确认记录保留在缺陷单的活动中，便于后续追溯。每周由流程负责人汇总退回原因分布和处理时长，判断输出质量是否稳定。这一流程在ONES中的承载方式可以是：Assistant基于缺陷单与历史记录生成归因建议，确认后把结果写回工作项并更新状态、通知负责人，形成可追踪的记录。
上线后的验证指标与完成检查
试点是否达标，要用事先约定的指标判断，而不是凭感觉。核心指标有三个，计算口径要在试点启动前确定。
| 指标 | 计算口径 | 观察用途 |
|---|---|---|
| 处理时长 | 从触发到结果写回完成的平均耗时，与试点前人工处理同一节点的平均耗时对比 | 判断自动化是否真正缩短了流转时间 |
| 返工率 | 被退回重做的输出数 ÷ 总输出数 | 判断输入材料和输出格式是否稳定 |
| 确认人修改比例 | 确认人修改过至少一个字段的输出数 ÷ 总输出数 | 判断AI输出可直接采用的程度 |
按周观察的检查清单包括：本周触发次数与预期发生量是否一致；材料缺失导致的退回占比是否下降；退回原因是否集中在某一类；确认人平均审核耗时是否在可接受范围；写回后的状态流转是否出现卡单；平台维护人是否处理了配置类问题。每周记录一次，连续观察三到四周再下结论。
结论分三种。达标：处理时长明显短于试点前，返工率和修改比例稳定在团队可接受范围内，且没有出现因输出错误导致的下游问题，此时可以把同一模式复制到清单中排序靠前的下一个节点。继续调整：指标有改善但波动大，或退回原因集中在输入材料缺失、字段格式不合理等可修复问题上，此时保持单节点运行，调整输入清单和输出字段后再观察一个周期。停止扩展：返工率持续偏高且原因分散，确认人审核耗时接近甚至超过人工处理时间，或出现难以回退的错误，此时暂停该节点，回到节点清单重新判断归属，必要时改为人工处理或拆分为更小的子节点。
常见问题
流程节点已经用规则引擎跑通了，还需要再引入AI吗？
不需要替换已有规则。规则引擎负责字段校验、状态流转、定时提醒这类确定性动作，AI适合处理规则难以覆盖的部分，例如缺陷描述归因、评审意见汇总、测试用例初稿。两者可以在同一条流程里分工：规则负责触发和状态校验，AI在需要理解文本的节点生成建议，人工确认后由规则完成写回和流转。判断标准回到三个问题——输入是否结构化、是否需要理解上下文、出错代价是否可回退。
确认人经常直接接受AI输出、很少修改，是不是说明流程已经稳定？
接受率高是积极信号，但要结合退回原因和下游反馈一起看。建议抽查一部分被直接接受的输出，核对分类和依据是否准确；同时观察写回后是否出现处理人反馈“归因不对”“模块判断有误”的情况。如果接受率高但下游返工多，说明确认环节的把关标准偏松，需要细化输出字段的核对要求，或调整确认人分工。
试点期间输入材料经常不完整，流程反复卡住怎么办？
把材料缺失当作流程设计问题处理，而不是让AI在缺材料时勉强生成。做法是在输入清单中标注必需项和可选项，必需项缺失时流程停在“待补充”状态并通知提交人，不进入生成环节；同时统计缺失集中在哪些字段，判断是提交表单设计不合理，还是提交人不知道要填什么。连续几周材料缺失占比下降，再评估输出质量的变化。
一个节点验证达标后，可以直接把多个节点串成一条长链路吗？
建议先复制单节点模式到下一个节点，而不是立刻串联。单节点跑通说明输入、输出、确认点这套结构可行，但串联会引入新的问题：上游输出是否满足下游输入要求、多个确认点的先后顺序、某一环退回时如何回滚。可以先把两个相邻节点串起来做小范围验证，明确交接字段和退回规则，再逐步延长链路。
AI输出写回工作项后，状态变更要不要也交给AI自动执行？
状态变更类动作建议保留人工确认。生成建议、草稿、分类标签这类输出错了可以修改，状态变更影响下游排期和通知，出错后回退成本更高。可以在确认人接受输出后由流程自动执行写回和状态更新，但触发条件要写清楚，例如“确认人点击接受后更新为待处理并指派处理人”。以ONES为例，ONES Assistant可将自然语言指令转化为可追踪的工作，结果保存为工作项或Wiki页面，具体的状态流转配置需按团队权限和流程设置确定。
