把 AI 引入研发流程，难点通常不在模型本身，而在划清哪些环节交给 AI、哪些继续用确定性规则，以及每个环节的输入、确认点和输出物怎么定。本文给出一套可执行的做法：从需求澄清、任务拆解、代码评审辅助、测试用例生成、缺陷归因、发布说明与复盘六类高频动作中选一到两个试点，跑通一轮再扩展。AI 输出最终要落到工作项状态和文档评审里，ONES 可作为承载这一管理动作的系统之一。
要点总览（TL;DR）
- 先按判断复杂度、容错要求、可解释性三个维度给研发环节分类：规则明确、结果可枚举的继续用确定性规则，需要语义理解且有人工兜底的环节才进入 AI 试点。
- 从需求澄清、任务拆解、代码评审辅助、测试用例生成、缺陷归因、发布说明与复盘六类动作中选一到两个试点，每步写清输入、AI 动作、人工确认点、输出物和完成标志。
- AI 输出由明确的审核人确认后才进入下一环节，最终结果由该环节既有责任人负责；审核责任要写进环节定义卡，避免无人签字。
- AI 输出应落到工作项字段或文档页面，随状态流转被评审，原始草稿与人工修改记录保留，复盘时可直接取数。
- 一轮试点结束后按输入完整性、确认点执行、可追溯性、回退记录、完成标志、角色责任六项核对；连续两轮达标再复制到输入结构相似的环节。
先划清 AI 驱动与规则自动化的边界
研发流程里的自动化有两类。一类是确定性规则自动化：条件明确、结果可枚举，比如代码提交后自动触发构建、工作项状态从“开发中”变为“待测试”时自动通知测试负责人、缺陷严重级别达到某档自动升级。这类环节用规则引擎或流水线配置即可，结果稳定、可复现、易审计。另一类是 AI 驱动执行：输入是自然语言或半结构化材料，输出需要理解和生成，比如把一段用户访谈整理成澄清问题、根据需求描述生成任务拆解草稿、对代码变更给出评审关注点。两类自动化的验收方式不同，混在一起设计，往往既说不清 AI 该做什么，也说不清规则该管什么。
判断一个环节该用哪类方式，可以看三个维度。判断复杂度：输入是否多样、边界是否模糊、是否需要理解语义。容错要求：出错后的代价有多大，是否必须每次结果一致。可解释性：是否需要向他人说明“为什么得出这个结论”。三个维度组合起来，就能形成环节分类。
| 环节名称 | 判断复杂度 | 容错要求 | 建议采用 |
|---|---|---|---|
| 构建触发与制品归档 | 低，条件固定 | 高，结果必须一致 | 确定性规则 |
| 工作项状态流转通知 | 低，状态机明确 | 高，漏发影响协作 | 确定性规则 |
| 需求澄清问题生成 | 高，依赖语义理解 | 中，人工确认后使用 | AI 驱动 |
| 任务拆解草稿 | 高，依赖需求上下文 | 中，需负责人审核 | AI 驱动 |
| 代码评审关注点提示 | 高，依赖变更语义 | 中，评审人最终判断 | AI 驱动 |
| 测试用例初稿生成 | 中高，依赖需求与历史用例 | 中，测试人员审核 | AI 驱动 |
| 缺陷初步归因 | 高，依赖日志与上下文 | 中，需开发确认 | AI 驱动 |
| 发布说明与复盘纪要整理 | 中，依赖工作项与文档 | 低中，编辑校对即可 | AI 驱动 |
这张表的作用是帮助团队在试点前达成一致：哪些环节本轮不动，哪些环节进入 AI 试点。判断复杂、容错中等、需要人工确认的环节适合先试 AI；规则明确、结果可枚举的环节继续用确定性规则，避免为了“用上 AI”把稳定流程改得不可控。接口连接与扩展开发属于另一类技术任务，本文不展开。
核心操作步骤：从选点到跑通一轮
试点阶段的目标是跑通一轮完整闭环，而非铺开全部环节。下面五步按顺序执行，每步都写清输入、动作、输出和完成标志。
第一步：选试点环节并写清现状输入
从需求澄清、任务拆解、代码评审辅助、测试用例生成、缺陷归因、发布说明与复盘六类动作中选一到两个。选择标准是：发生频率高、输入材料已经存在、出错后有人能兜住。选定后，把该环节当前的输入逐项列出来，包括材料来源、格式、由谁提供、更新频率。输入写不清，后面就无法判断 AI 输出是否靠谱。
- 输入：候选环节清单、近一个月的实际样例材料。
- 动作：按频率、输入可得性、容错空间排序，确定试点环节。
- 输出：一页试点说明，含环节名称、输入清单、当前人工耗时。
- 完成标志：试点说明经研发负责人确认，输入样例不少于五份。
第二步：定义 AI 动作与人工确认点
把 AI 在该环节要做的事写成一句可验收的话，例如“根据需求描述生成待澄清问题列表”或“根据变更内容生成评审关注点”。紧接着定义人工确认点：谁在什么时点看 AI 输出、确认什么、不通过时怎么处理。人工确认点是流程的必备设计，缺少确认点的环节不应进入试点。
- 输入：试点说明、AI 动作的一句话描述。
- 动作：写明 AI 动作的触发条件、输出格式、确认人、确认标准。
- 输出：环节定义卡，含 AI 动作、确认点、不通过时的处理方式。
- 完成标志：确认人明确到岗位，确认标准可逐条核对。
第三步：确定输出物落在哪个工作项或文档
AI 输出不能停留在对话窗口里。要指定它写入哪个工作项字段、哪类文档页面或哪条评论，并说明写入后由谁接手。输出物落点决定了后续能否追溯：落在工作项上，可以随状态流转被评审；落在文档里，可以进入评审和版本记录。
- 输入：环节定义卡、现有工作项类型与文档结构。
- 动作：指定输出物载体、字段或页面位置、接手人。
- 输出：输出物落点说明，含载体名称、字段、接手角色。
- 完成标志：在测试项目中完成一次写入，接手人能看到并处理。
第四步：设定完成标志与回退方式
完成标志要可观察，例如“五份样例中至少四份的 AI 输出经确认人修改后进入下一环节”“确认平均耗时低于原人工耗时”。同时约定回退方式：AI 输出不可用时，流程回到人工处理路径，并记录回退原因。回退记录是评估试点是否成立的重要证据。
- 输入：环节定义卡、输出物落点说明。
- 动作：设定数量、质量、耗时三类完成标志，写明回退触发条件。
- 输出：验收标准表与回退记录模板。
- 完成标志：验收标准经确认人认可，回退记录模板可用。
第五步：一轮跑完后评估是否扩展
跑完一轮后，汇总确认记录、修改比例、回退次数和耗时变化，判断该环节是否达到完成标志。达到则考虑在同一环节增加样例量，或复制到结构相似的第二个环节；未达到则先修输入质量或确认标准，暂不扩展。
- 输入：一轮试点的全部记录。
- 动作：对照验收标准逐项核对，形成结论。
- 输出：试点评估纪要，含结论、问题和下一步。
- 完成标志：评估纪要经研发负责人确认，扩展或整改决定已记录。
角色分工与各环节交付物
AI 驱动流程最容易出问题的地方，是没人对 AI 输出负责。原则是：AI 输出由明确的审核人确认后才进入下一环节，最终结果由该环节的既有责任人负责，AI 不承担结果责任。下表按角色列出职责与交付物。
| 角色 | 职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 需求方 | 提供原始需求材料，回答澄清问题，确认需求理解无误 | 需求原始材料、澄清答复 | 需求澄清开始前提供材料；澄清问题答复后交接给研发负责人 |
| 研发负责人 | 确定试点环节与验收标准，指定确认人，对试点结论负责 | 试点说明、验收标准表、试点评估纪要 | 试点启动前确认说明；一轮结束后确认评估结论 |
| 执行工程师 | 准备输入材料，触发 AI 动作，对 AI 输出做第一轮修改 | 输入样例、AI 输出初稿及修改记录 | AI 输出生成后修改，再交给评审者 |
| 评审者 | 审核 AI 输出与修改结果，决定是否进入下一环节 | 审核意见、通过或不通过的结论 | 输出物写入工作项或文档后审核 |
| 测试或质量角色（涉及测试环节时） | 审核测试用例初稿的覆盖与可执行性 | 用例审核记录 | 用例初稿生成后、进入执行前 |
审核责任归属要写进环节定义卡，避免出现“大家都看过、没人签字”的情况。交接时点与工作项状态对应：材料提供对应需求工作项创建，AI 输出生成对应工作项进入待审核，审核通过对应状态流转到下一阶段。这样每个角色的动作都能在工作项历史里找到痕迹。
一个完整示例：需求澄清到任务拆解的 AI 辅助流程
以下为演示性构造的场景，用于说明流程结构，不代表真实客户案例。某团队选择“需求澄清到任务拆解”作为试点环节，周期两周。
起始输入：需求方提交一份产品需求说明文档，包含背景、目标用户和三条功能设想，附两段用户访谈记录。材料上传到项目文档页面，并创建一条需求工作项，状态为“待澄清”。
AI 动作：执行工程师在关联的项目与文档上下文中发起 AI 辅助，要求生成两类内容——待澄清问题列表和任务拆解草稿。澄清问题按“目标、范围、验收标准、依赖”分组；拆解草稿按“前端、后端、测试、文档”给出任务项和预估依赖关系。
人工确认：需求方在澄清问题列表上逐条答复，删除不适用的条目；研发负责人审核拆解草稿，合并过细的任务、补充遗漏的联调任务。确认标准是：每条澄清问题有答复或明确标记为暂不处理；拆解草稿的每个任务有负责人角色和完成定义。
结果写入与状态流转：确认后的澄清结论写入需求工作项的描述字段或关联文档页面，拆解出的任务作为子工作项创建，需求工作项状态从“待澄清”流转到“待评审”，评审通过后进入“已规划”。AI 生成的原始草稿与人工修改记录保留在文档版本中，便于回溯。
边界条件：该示例假设团队已有结构化的需求文档和可访问的历史项目数据；若输入材料只有口头描述，应先补齐材料再启动。AI 输出仅作为草稿，澄清结论以需求方答复为准，拆解结果以研发负责人确认为准。涉及跨团队依赖的任务，仍需人工与相关团队对齐后再定稿。
用工作项与文档承载 AI 输出：ONES 的衔接方式
上面示例里的关键管理动作有三个：AI 输出要进入流程、要有审核交接、要能追溯。这三件事需要系统承载，ONES 的衔接方式可以从这条流程看。
输入与执行环节，ONES Assistant 智能助手连接 ONES Project、ONES Wiki 与 ONES TestCase，理解项目、工作项、迭代和 Wiki 页面等真实工作上下文，把自然语言指令转化为可追踪的工作。在需求澄清场景中，它可以围绕需求材料提炼要点、待澄清问题与拆解建议，帮助团队更快完成澄清和录入；在计划环节，可基于项目目标、范围和关键交付物生成结构化的计划、里程碑、阶段任务与责任分工。这些输出仍需人工确认后使用。
承载与交接环节，AI 执行的结果可以保存为工作项、Wiki 页面等内容，减少页面切换和重复录入。这意味着澄清结论可以落在需求工作项或关联文档上，拆解结果可以作为子工作项进入待评审状态，评审者的审核意见随工作项记录留存。从需求、计划、协作、测试到发布与知识沉淀，输出物沿同一条链路流转，复盘时可以直接从工作项历史和文档版本中取数。
需要说明的是，具体可用范围、状态流转配置和追溯粒度需按实际部署与授权核验。团队在试点前应确认当前环境中的工作项类型、字段和文档结构能否支撑上述落点设计。
完成检查：判断这一轮是否跑通
一轮试点结束后，用下面的清单逐项核对。全部通过，说明流程结构成立，可以考虑扩展；有关键项未通过，先整改再评估。
| 检查项 | 通过标准 | 证据来源 |
|---|---|---|
| 输入是否完整可复现 | 试点说明中的输入清单齐全，样例不少于五份，他人按清单能复现同一输入 | 试点说明、输入样例归档 |
| 人工确认点是否被执行 | 每份 AI 输出都有确认人记录，确认意见可逐条对应输出内容 | 工作项评论、文档评审记录 |
| 输出物是否可追溯 | AI 原始输出、人工修改、最终版本三者可区分，能定位到具体工作项或文档版本 | 工作项历史、文档版本记录 |
| 异常与回退是否被记录 | 每次回退都有触发原因和处理结果，回退次数已统计 | 回退记录模板、试点评估纪要 |
| 完成标志是否达到 | 数量、质量、耗时三类标志按验收标准逐项判定，结论有数据支撑 | 验收标准表、评估纪要 |
| 角色责任是否清晰 | 每个环节的确认人和结果责任人在环节定义卡中明确，无空缺 | 环节定义卡、角色交付物对照表 |
扩展前还需满足两个条件：一是该环节连续两轮达到完成标志，说明结果稳定而非偶然；二是回退原因已归类，属于输入质量问题的已修复，属于确认标准模糊的已细化。满足后，优先复制到输入结构相似的环节，例如从需求澄清扩展到测试用例初稿生成，两者都依赖需求材料且都需要专业角色审核。结构差异大的环节单独设计，不套用同一套确认标准。
常见问题
试点环节跑了一轮，AI 输出质量不稳定，应该先改模型还是先改流程？
先查流程侧的三件事，再考虑模型。第一，输入是否完整可复现：样例材料是否齐全、格式是否统一、是否包含足够的上下文，输入质量差时输出波动是正常结果。第二，确认标准是否可逐条核对：如果确认人只能凭感觉判断“好不好”，输出就会显得时好时坏，应把标准细化到可勾选的程度。第三，AI 动作的描述是否过宽：一句“帮我整理需求”覆盖太多目标，输出自然发散，应收窄为“生成待澄清问题列表”这类单一动作。三项都排查过仍不稳定，再评估是否更换模型或调整提示方式。
团队规模较小、没有专职评审者，人工确认点怎么设？
确认点的核心是“有人对输出签字”，与是否设专职岗位无关。小团队可以让同一人兼任执行与审核，但要保留两个动作的区分：先由执行人提交 AI 输出与修改说明，再由其以审核身份给出通过或不通过的结论，两条记录分开留存。涉及需求结论的，仍应由需求提出方确认；涉及测试覆盖的，由实际执行测试的人确认。角色可以合并，确认动作与记录不能合并，否则后续无法判断输出是否被真正看过。
AI 输出写入工作项后，还需要保留原始草稿吗？
建议保留。原始草稿、人工修改和最终版本三者可区分，是判断试点是否成立的基础证据：复盘时能看出 AI 输出被改了多少、改在哪些方面，从而判断是输入问题、确认标准问题还是环节本身不适合 AI。保留方式可以是在文档版本中留存草稿，或在工作项评论中记录修改要点。若只保留最终版本，评估时只能凭印象判断效果，扩展决策缺少依据。
哪些环节不适合作为第一个试点？
三类环节建议往后放。一是出错代价高且难以回退的环节，例如直接影响对外发布或生产变更的操作，试点期缺乏足够的安全垫。二是输入材料尚不存在的环节，AI 没有可用上下文，跑出来的结果无法判断是能力问题还是材料问题。三是跨多个团队交接的环节，确认链条长，一轮试点内难以收敛结论。优先选发生频率高、输入已存在、出错后有人能兜住的环节，跑通后再向复杂环节延伸。
试点达标后扩展到第二个环节，需要重新设计一套确认标准吗？
不必整套重做，但也不能直接套用。可复用的是流程结构：输入清单、AI 动作描述、确认点、输出物落点、完成标志这五项框架保持一致。需要重新设计的是确认标准的具体内容，因为它取决于该环节的专业判断。输入结构相似的环节，例如从需求澄清扩展到测试用例初稿生成，两者都依赖需求材料、都由专业角色审核，标准可以借鉴后调整；结构差异大的环节，例如缺陷归因依赖日志与运行上下文，确认标准应单独制定。
