AI研发流程自动化的起点是拆解流程节点，而不是直接引入工具。先把需求、开发、测试、发布各环节拆成可判断的节点，识别哪些动作适合AI承担判断或生成，再为每个节点定义输入、AI动作、人工确认点和产出物。本文给出从场景筛选到上线检查的完整做法，并说明ONES在节点承载与人工确认环节可提供的支持。
要点总览（TL;DR）
- 先按节点拆解研发流程，区分AI执行、确定性规则和接口连接三类工作，只把输入以文本为主、输出可人工核对、错误可回退的节点交给AI。
- 每个AI节点写成作业卡，固定输入来源、AI动作、输出格式、确认人、完成标志和失败处理，四步依次推进。
- 角色分工落到交付物：研发负责人定试点与验收，流程/效能角色维护作业卡，一线角色担任确认人，平台管理员负责配置与运行记录。
- 试点先选一到两个高频、输入稳定、错误可回退的节点，运行两到四周，按人工修改比例、返工次数、处理时长和误判类型判断是否扩大。
- 上线前逐项核对输入数据、输出格式、确认人、回退路径、边界划分和试点数据，任何一项未确认就停留在试点状态。
先划清AI自动化的边界：哪些环节交给AI
研发流程里同时存在三类工作：需要理解和生成的判断类动作、条件固定的规则类动作、跨系统的数据连接。把三类混在一起交给AI，往往导致结果不稳定、责任不清。落地前先按节点分类，是控制风险的第一步。
判断一个节点是否适合AI，可以看三个特征：输入以自然语言或半结构化文本为主，例如需求描述、缺陷记录、评审意见；输出允许存在多个合理答案，需要人做取舍；错误后果可被下游人工确认拦截。满足这三点的节点，AI可以承担初筛、摘要、草稿和建议生成。反过来，状态流转、字段必填校验、超时通知这类动作有明确判定条件，交给流程引擎执行更稳定，也便于追溯。
接口连接是另一类工作。系统之间通过MCP等开放接口传递数据、触发外部工具，属于接口方案与扩展开发范畴，需要单独评估权限、数据范围和调用频率，不与AI节点定义混在同一张清单里。
候选清单建议按节点逐行填写，至少包含四列：节点名称、当前做法、拟承担方（AI执行／规则执行／接口连接）、判断理由。填写时以“这个节点的产出能否被人快速核对”为筛选标准，核对成本高的节点先不纳入首轮试点。
| 节点类型 | 典型动作 | 承担方 | 纳入首轮试点的建议 |
|---|---|---|---|
| 判断与生成 | 需求要点提炼、缺陷分类、评审风险提示、任务拆分建议 | AI执行，人工确认 | 优先，输入稳定且错误可回退 |
| 确定性规则 | 状态流转、字段校验、到期提醒、权限控制 | 流程引擎 | 不纳入AI试点，按原方式配置 |
| 接口连接 | 跨系统同步数据、调用外部工具 | 接口与扩展开发 | 单独排期，不与AI节点合并评估 |
核心操作步骤：为每个AI节点定义输入、动作与产出
选中的节点需要变成可运行的AI环节，关键是把它写成一张作业卡。作业卡固定回答四个问题：AI拿到什么、做什么、交什么、什么时候算完成。四步依次推进，前一步没有定清楚，后一步的确认就无从谈起。
第一步：明确节点输入
输入决定输出质量。为每个节点列出AI可读取的材料及其来源，例如需求文档正文、历史相似需求、缺陷描述与复现步骤、构建日志片段、上一轮评审记录。同时标注输入的可得性和质量前提：文档是否完整、历史数据是否已归档、日志是否保留足够时长。输入缺失时，节点应直接标记为“信息不足”并退回，而不是让AI在残缺信息上生成结论。
第二步：定义AI动作与输出格式
动作要写成一句话可执行的指令，例如“从需求文档中提取功能点，标注待澄清问题”“按模块和严重程度对缺陷分类”。输出格式必须固定，便于下游消费：分类结果用枚举值，摘要控制在约定字数，任务拆分建议以“任务名＋建议负责人角色＋预估工作量区间”的表格形式给出。格式固定后，人工核对和后续统计才有统一口径。
第三步：设置人工确认点与回退路径
每个AI节点都要指定确认人和确认方式。确认人看到AI输出后做三选一：采纳、修改后采纳、退回重做。退回时记录原因类型，例如信息缺失、判断偏差、格式不符，这些记录是后续调整提示与规则的依据。确认点应设在产出进入下游之前，避免未经核对的结果直接触发状态变更或通知。
第四步：定义完成标志与失败处理
完成标志描述节点结束的可观察状态，例如“评审记录已归档且任务清单已创建”“缺陷已带上模块标签并进入待修复状态”。失败处理要覆盖三类情况：AI无输出或超时，转人工处理并记录；输出格式不符合约定，退回重生成一次后仍失败则转人工；输出被确认人判定为误判，按回退路径处理并计入误判统计。
| 作业卡字段 | 填写要求 | 示例 |
|---|---|---|
| 节点输入 | 列出材料、来源与质量前提 | 需求文档正文、近半年相似需求记录 |
| AI动作 | 一句话指令，说明处理对象与目标 | 提取功能点并标注待澄清问题 |
| 输出格式 | 固定结构、字段与字数限制 | 功能点列表＋问题清单，各不超过10条 |
| 确认人 | 具体角色，不用“相关同事” | 产品负责人、开发负责人 |
| 完成标志 | 可观察的状态或产物 | 评审记录归档、任务清单已创建 |
| 失败处理 | 按失败类型写明去向 | 格式不符退回一次，仍失败转人工 |
节点定义完成后，需要有承载工作项、文档和状态流转的地方。ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项、迭代和 Wiki 页面等工作上下文，并把自然语言指令转化为可追踪的工作。在需求澄清与任务拆解这类节点上，它可以提炼要点、待澄清问题与拆解建议，生成的建议进入工作项后仍由确认人核对，符合前述“AI生成、人工确认”的分工。
角色与交付物分工
AI节点落地失败的常见原因是职责悬空：场景有人提，提示有人写，结果没人认。落地前把四类角色和对应交付物定下来，并明确每项交付物由谁确认。
- 研发负责人：确定试点节点清单与验收口径，确认试点是否达到扩大条件。交付物为试点范围说明和验收标准。
- 流程／效能角色：拆解节点，定义输入字段、输出格式与状态流转规则，维护作业卡。交付物为节点作业卡和字段说明。
- 一线角色（开发、测试、产品）：提供样本数据，担任确认人，按采纳、修改、退回三选一处理AI输出并记录原因。交付物为确认记录与误判类型汇总。
- 平台／工具管理员：在工作项、文档与自动化触发中配置节点，保证输入可取、输出可落库、状态可流转。交付物为配置说明与运行记录。
| 交付物 | 负责人 | 确认责任 | 评审节奏 |
|---|---|---|---|
| 试点节点清单与验收标准 | 研发负责人 | 研发负责人 | 试点启动前一次 |
| 节点作业卡 | 流程／效能角色 | 研发负责人＋确认人代表 | 每个节点上线前 |
| 确认记录与误判汇总 | 一线确认人 | 流程／效能角色 | 每周汇总一次 |
| 配置说明与运行记录 | 平台／工具管理员 | 流程／效能角色 | 配置变更时更新 |
评审节奏建议与试点周期对齐：启动前评审一次范围与标准，试点期间每周看一次确认记录，试点结束时评审是否扩大。交付物归属写进表格并指定确认人，避免出现“都参与、都不负责”的状态。
示例：需求评审到任务拆解的一段AI流程
以下为演示情景，用于说明输入、AI动作、人工确认与产出如何衔接，不代表真实客户案例。
输入。产品经理提交一份需求文档，同时关联近半年的相似需求记录与上一版本的相关评审意见。文档需包含背景、目标用户和功能描述，缺失关键章节时节点直接退回补充。
AI动作。AI读取需求文档与历史记录，生成三部分内容：评审要点，覆盖范围、依赖与验收标准；风险提示，指出与历史需求的冲突点或描述模糊处；初步任务拆分建议，按功能模块给出任务名、建议负责角色和预估工作量区间。
人工确认。产品负责人核对评审要点与风险提示，开发负责人核对拆分粒度与遗漏项。两人分别对各自部分做采纳或修改，拆分建议被调整后由开发负责人确认最终任务清单。确认环节保留原始AI输出与修改记录，便于回溯。
产出。评审记录归档到项目文档，任务清单创建为工作项并进入待排期状态，需求状态由“评审中”流转为“已评审”。状态流转由流程规则执行，不由AI直接触发。
异常处理。AI输出缺少风险提示或拆分明显遗漏模块时，确认人选择退回并标注原因；同一需求退回两次后转人工评审，AI输出仅作为参考附在记录中。若输入文档本身不完整，节点在第一步即终止，不进入生成环节。
这段流程可以迁移到缺陷分诊、测试用例初稿生成等节点，迁移时保留同样的结构：固定输入、固定输出格式、明确确认人、明确退回条件。
试点与推广：怎么验证再扩大
试点的作用是用小范围数据回答一个问题：这个节点的AI输出是否稳定到可以进入日常流程。范围宜小，节点宜少，通常先选一到两个节点，运行两到四周再评估。
试点节点按三条原则选择：发生频率高，样本量足够观察规律；输入相对稳定，文档或记录格式统一；错误可回退，AI输出不直接触发对外通知或不可逆的状态变更。
观察指标建议固定四项，并在试点前约定记录方式：
- 人工修改比例：AI输出被修改后采纳的比例，反映输出可用程度。
- 返工次数：同一节点因输出问题被退回的次数。
- 处理时长：从输入提交到确认完成的时间，与试点前同类节点对比。
- 误判类型分布：按信息缺失、判断偏差、格式不符等归类，指导后续调整。
复盘按周进行，看指标趋势而非单次结果。扩大条件建议同时满足：人工修改比例稳定在团队可接受范围、返工次数逐周下降或持平、确认人认为核对成本低于自行完成、失败处理路径被实际触发过且运转正常。满足后扩到下一个节点，每次只增加一个，避免同时铺开导致问题难以归因。
| 试点阶段 | 范围 | 主要动作 | 判断依据 |
|---|---|---|---|
| 准备 | 1个节点 | 完成作业卡、确认人指定、样本准备 | 作业卡评审通过 |
| 运行 | 同1个节点 | 按周记录四项指标，处理退回与失败 | 指标趋势可读 |
| 复盘 | 同1个节点 | 汇总误判类型，调整提示与格式 | 扩大条件逐项核对 |
| 扩展 | 增加1个节点 | 重复准备到复盘 | 前一节点指标稳定 |
完成检查：上线前逐项确认
每个AI节点进入日常流程前，按下表逐项核对。任何一项未确认，节点应停留在试点状态。
| 检查项 | 确认内容 | 通过标准 |
|---|---|---|
| 输入数据 | 所需文档、记录、日志是否可得，格式是否统一 | 试点期间未因输入缺失频繁终止 |
| 输出格式 | 字段、枚举值、字数是否固定，下游能否直接消费 | 输出可被工作项或文档直接接收 |
| 人工确认点 | 确认人是否明确到角色或个人，确认方式是否固定 | 每个节点均有指定确认人 |
| 回退路径 | 误判、格式不符、无输出三类情况是否有处理去向 | 失败处理被实际触发并正常运转 |
| 边界划分 | 状态流转、字段校验由规则执行，接口连接单独排期 | AI节点不承担确定性规则与接口职责 |
| 试点数据 | 四项指标是否有记录，扩大条件是否满足 | 指标趋势支持继续推广 |
检查完成后，把作业卡、角色分工表和试点记录一并归档，作为下一个节点复用的模板。随着节点增多，这套材料本身会成为团队调整流程和评估AI投入的依据。
常见问题
AI输出被确认人判定为误判时，应该怎么处理？
按作业卡中约定的回退路径处理：确认人选择退回并标注原因类型，例如信息缺失、判断偏差或格式不符。同一节点因同类原因连续退回时，先调整输入材料或输出格式，再重新运行；同一需求或任务退回两次后转人工处理，AI输出仅作为参考附在记录中。误判记录要计入统计，作为后续调整提示与格式的依据。
试点期间人工修改比例一直降不下来，应该先查什么？
先区分修改集中在哪一类问题。如果集中在信息缺失，说明输入材料不完整或格式不统一，应回到第一步补齐输入前提；如果集中在判断偏差，说明AI动作的指令边界不清，需要把动作写得更具体；如果集中在格式不符，说明输出结构没有固定到下游可直接消费的程度。三类问题的处理方向不同，混在一起调整容易反复。若调整两轮后指标仍无改善，可暂停该节点，换一个输入更稳定的节点试点。
确定性规则和AI节点在同一流程里怎么衔接？
让两者各管一段。AI负责生成建议、草稿和初筛结果，产出进入人工确认；确认通过后，状态流转、字段校验、到期提醒等动作由流程引擎按既定规则执行。AI不直接触发不可逆的状态变更或对外通知。这样划分后，规则部分的行为可追溯、可复现，AI部分的问题也能通过确认记录单独定位。
团队规模小、没有专职效能角色，分工表还能用吗？
可以合并角色，但不能合并确认责任。小团队里研发负责人可以同时承担流程拆解，平台配置可由熟悉工作项和文档结构的人兼任。需要保留的是：每个AI节点有明确的确认人，确认记录有人汇总，试点指标有人看。角色名称可以少，交付物和确认人不能空着，否则退回原因和误判类型无人整理，试点数据就失去参考价值。
ONES Assistant在这套方法里承担哪部分工作？
ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项、迭代和 Wiki 页面等工作上下文，并把自然语言指令转化为可追踪的工作。在需求澄清与任务拆解这类节点上，它可以提炼要点、待澄清问题与拆解建议，生成的建议进入工作项后仍由确认人核对。它承担的是AI生成与上下文理解这一段，状态流转等确定性动作仍按流程规则执行。
