研发管理中的人机分工要落到可执行层面，核心是把每项管理活动拆成“判断责任、执行动作、产出物、复核方式”四个字段，逐项写明由人还是由 AI 助手承担，并规定 AI 输出须经人确认才能进入正式流程。落地顺序是：盘点管理活动清单，按风险与可逆性划定边界，为每类活动写清输入、动作、输出与完成标志，再用评审和抽样复核验证分工是否被遵守。这套方法适用于使用 AI 助手辅助研发管理的团队，不涉及算法研发与模型训练。
要点总览（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 输出未经确认就进入流程，是否有人发现、记录并修订分工规则。
- 是否安排了定期复盘，按迭代或季度检查分工执行情况，把偏离案例转化为规则修订。
分工规则要落到日常协作的载体上才便于执行和检查。在 ONES 中，研发管理活动可以对应为工作项与文档：活动清单和操作定义表以文档形式维护，每项活动的责任人、完成标志可写入工作项字段，AI 生成的初稿作为待确认内容进入评审流程，确认记录留在工作项的流转历史与文档评论中，使复核链条可查。这样分工规则与执行记录在同一处对应，检查时不必另行追溯。
完成标志：检查清单逐项通过，分工规则有明确的维护责任人和复盘周期，偏离案例有记录和修订去向。
常见问题
团队规模小、管理活动不多，也需要做完整的人机分工定义吗？
活动清单和操作定义可以按实际管理复杂度裁剪，但四字段定义不宜省略。小团队的管理活动条目少，盘点工作量不大，仍建议把排期、进度跟踪、质量把关、复盘这几项核心活动写清判断责任与复核方式。省略定义后，常见的问题是 AI 生成的初稿被直接当作结论使用，事后难以追溯是谁确认的。条目可以少，每条的完成标志和确认人应当保留。
AI 助手给出的排期或风险判断看起来合理，能否跳过人工确认直接发布？
不建议跳过。排期涉及优先级取舍和资源冲突裁决，风险判断涉及是否上报与如何应对，这类结论的影响范围通常超过单个任务，纠错成本也高。可行的做法是把 AI 输出定位为初稿，标记为待确认状态，由研发管理者确认后再转为正式计划；确认动作和调整内容留在原文档或工作项中，便于后续复盘时回看判断依据。
分工规则写好后，怎么发现实际执行已经偏离？
可以从两个方向检查。一是抽样复核：定期抽取若干 AI 参与的产出物，核对是否有对应的确认记录、确认人是否为该活动的验收人。二是流程观察：查看是否有 AI 初稿未经确认就进入评审或对外发布的情况。发现偏离后，记录具体案例，判断是规则本身不合理还是执行不到位，前者修订操作定义，后者在复盘中明确提醒。偏离案例应有记录去向，避免同类问题反复出现。
人员或工具环境变化后，人机分工需要重新做一遍吗？
不需要整体重做，按变化范围局部修订即可。人员变动时，更新活动清单中的负责人和操作定义中的验收人，确认交付物责任链条不断。引入新的 AI 能力或调整数据范围时，更新对应活动的提示信息范围与人工复核要求，并评估该活动是否应从人决策调整为协作类。修订后同步检查相关活动的完成标志是否仍然成立，避免规则与执行脱节。
研发管理者和一线工程师在人机分工中的复核职责如何区分？
按活动的影响范围区分。研发管理者复核涉及取舍与担责的输出，如优先级排序、资源冲突裁决、发布放行结论、排期正式版。一线工程师复核与本人任务相关的事实性内容，如工时数据、任务状态、技术判断的准确性。两类复核都应有记录，管理者确认的是结论，工程师确认的是数据与事实，二者不能相互替代。
