研发管理中的人机分工，核心是把任务按“判断责任”和“执行动作”拆开：需求澄清、优先级取舍、验收判定、风险决策由人负责；信息汇总、初稿生成、例行检查、状态同步、变更提醒交给 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 的职责范围。
这些任务状态、复核结论和交接记录需要有承载位置。在 ONES 中，需求、任务、缺陷可以作为工作项管理，状态流转和确认记录留在工作项里，需求文档和发布说明放在文档中，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 服务不可用或输出明显异常时，相关任务回退到原有手工流程，由原责任人继续推进。这条规则需要在分工方案里提前写明，并明确每类任务的手工替代方式，避免工具故障时临时找人接手。回退期间产生的记录仍要留在工作项中，便于恢复后核对。
