AI创建任务后，人工复核的对象是一份“待验收的工作项草稿”，重点核对任务内容、责任人、排期、依赖关系和字段规范是否成立。复核在任务进入待办或排期前完成，涉及范围、责任与验收标准的项目应设为阻断项，未通过不得直接执行。以下清单按角色时点、检查项、通过标准、证据与放行规则展开，可直接用于逐项判定。
要点总览（TL;DR）
- 复核发生在AI生成任务之后、进入待办或排期之前，由任务提出人、模块负责人、项目经理分工检查内容、责任关系与排期合规。
- 任务内容类检查以原始需求为基准，重点确认标题与描述无凭空补充、验收标准可用通过或不通过判定、一条任务只对应一个可独立验收的目标。
- 责任与关系类检查要落到真实承担者：负责人为在职成员且本人确认承接，截止时间与依赖顺序不冲突，项目内无重复任务。
- 范围错误、责任人不实、验收标准缺失、重复任务、依赖方向错误应设为阻断项，未通过不得进入执行；其余问题记录后限期修正。
- 复核结论需书面留痕，谁检查谁确认，记录随任务保存至关闭，范围调整后重新执行阻断项检查。
谁在什么时点做这次复核
复核发生在AI生成任务之后、任务进入待办列表或正式排期之前。这个位置决定了复核的性质：它是对生成结果的验收，也是任务进入执行前的最后一道人工判断。任务一旦进入排期，就会被其他成员当作承诺看待，此时再修改范围或责任人，成本明显上升。
复核由三类角色分工完成，各自检查自己最有判断依据的部分。任务提出人最了解原始需求，负责判断任务内容是否还原了真实意图；模块负责人熟悉本模块的成员分工与技术边界，负责确认责任人和依赖关系；项目经理掌握整体排期与资源承诺，负责核对优先级、截止时间以及任务之间是否存在重复。
| 角色 | 复核时点 | 负责检查的范围 | 输出 |
|---|---|---|---|
| 任务提出人 | AI生成后第一时间 | 标题与描述是否还原原始需求、验收标准是否可判定、是否存在多目标混装 | 内容确认或退回修改意见 |
| 模块负责人 | 内容确认后、进入排期前 | 负责人与协作人是否为真实承担者、依赖与关联方向是否正确、拆分粒度是否合理 | 责任与关系确认 |
| 项目经理 | 排期前统一核对 | 优先级与截止时间是否符合当前排期、是否与已有任务重复、字段与标签是否合规 | 放行或阻断结论 |
复核与后续的技术评审、需求评审是两件事。复核解决的是“这条任务记录是否成立”，评审解决的是“这个方案是否可行”。复核通过只代表任务可以进入待办，不代表方案已经获得认可。团队可以把复核结论作为评审的输入，但不能用评审替代复核，否则任务记录中的错误会一路带到执行阶段。
任务内容与验收标准检查项
内容类检查回答一个核心问题：这条任务是否准确对应了原始需求。AI在拆解过程中可能补充原文没有的细节，也可能把一句模糊描述扩写成看似完整的任务，复核时要回到原始需求文档逐句比对，而不是只看生成结果是否通顺。
| 检查项 | 通过标准 | 证据来源 | 负责人 | 阻断 |
|---|---|---|---|---|
| 标题准确性 | 标题中的动作对象和预期结果能在原始需求中找到对应表述，无凭空新增的范围 | 原始需求文档、PRD对应段落 | 任务提出人 | 是 |
| 描述完整性 | 描述覆盖背景、要做的事和边界，AI补充的内容已标注来源或经提出人确认 | 需求原文与任务描述逐段比对 | 任务提出人 | 是 |
| 验收标准可判定 | 每条验收标准都能用通过或不通过来回答，避免“体验良好”“性能达标”这类无法判定的表述 | 验收标准条目本身 | 任务提出人 | 是 |
| 完成定义与交付物 | 明确列出交付物形态，如文档、接口、页面、测试报告，并说明完成时这些交付物处于什么状态 | 任务描述中的交付物字段 | 任务提出人 | 是 |
| 单一目标 | 一条任务只对应一个可独立验收的目标；若包含多个目标，已拆分为子任务或标注拆分计划 | 任务列表结构 | 任务提出人 | 否 |
验收标准的写法值得单独说明。可判定的标准通常包含对象、条件和期望结果，例如“提交订单后，订单状态在列表中显示为已支付，且支付时间与操作时间一致”。这类表述让执行人和验收人对同一结果有相同理解。AI生成的标准如果停留在“功能正常可用”，复核时应退回补充，而不是在执行阶段再解释。
多目标混装是常见问题。一条任务同时包含接口开发、页面联调和文档更新，执行人很难判断何时算完成，进度统计也会失真。复核时发现这种情况，可以要求拆分为子任务，或在任务中明确各目标的完成顺序和验收节点。
责任、排期与依赖关系检查项
内容成立之后，要确认这条任务落到了真实的人和真实的时间上。AI按模块分配负责人时，可能匹配到名称相近的成员、已离职账号或默认指派的空账号，这类问题在排期后才暴露，会直接造成任务无人推进。
| 检查项 | 通过标准 | 证据来源 | 负责人 | 阻断 |
|---|---|---|---|---|
| 负责人真实性 | 负责人是在职成员，且本人知晓并认可该任务；不存在默认账号、公共账号或已停用账号 | 成员名单、负责人确认记录 | 模块负责人 | 是 |
| 协作人完整 | 需要配合的角色已列入协作人，如设计、测试、运维，且协作范围在描述中可查 | 任务协作人字段与描述 | 模块负责人 | 否 |
| 优先级合理 | 优先级与当前迭代目标、承诺交付时间一致，不存在全部标为最高优先级的情况 | 迭代计划、排期表 | 项目经理 | 否 |
| 截止时间可行 | 截止时间落在当前排期内，与依赖任务的时间顺序不冲突 | 排期表、依赖任务时间 | 项目经理 | 是 |
| 依赖方向正确 | 前置任务指向真正需要先完成的工作，父子关系与任务层级一致，无循环依赖 | 依赖关系图、任务层级 | 模块负责人 | 是 |
| 无重复任务 | 在项目内检索标题与关键词，确认没有与已有任务重复或应合并的条目 | 项目任务列表检索结果 | 项目经理 | 是 |
依赖关系的方向错误比缺失更难发现。AI可能把“等待接口联调”写成被依赖项，实际应该是接口开发完成后才能联调。复核时按时间顺序读一遍依赖链，确认每个前置任务确实先于当前任务完成，比逐个检查字段更快。
拆分粒度需要结合团队习惯判断。粒度过粗的任务难以在一周内看到进展，粒度过细则会产生大量需要维护的条目。一个可操作的判断是：一条任务应当能由一位负责人在一个迭代内完成并交付可验收的结果，超出这个范围考虑拆分，明显小于半天工作量的条目考虑合并。
字段、标签与记录合规检查项
字段规范决定后续的统计、检索和报表是否可用。AI生成任务时可能按语义猜测类型、模块或迭代归属，这些猜测需要对照团队既有口径逐项确认。
| 检查项 | 通过标准 | 负责人 |
|---|---|---|
| 必填字段齐全 | 团队约定的必填字段均有值，无空置或默认占位值 | 项目经理 |
| 归属正确 | 类型、模块、迭代、版本等归属字段与任务实际内容一致 | 模块负责人 |
| 标签口径一致 | 标签使用团队已有标签库中的条目，未新增同义标签或自造分类 | 项目经理 |
| 无残留占位内容 | 描述、验收标准、备注中无“待补充”“示例”“TODO”等AI生成残留文本 | 任务提出人 |
| 引用有效 | 附件可打开，链接指向正确页面，引用的文档版本与当前需求一致 | 任务提出人 |
残留占位内容是容易被跳过的一项。AI生成的描述中常出现“根据实际情况调整”这类句子，读起来通顺，实际没有提供任何可执行信息。复核时把这类句子当作未完成项处理，要求替换为具体条件或删除。
在ONES中，AI生成的任务以工作项形式存在，复核动作可以直接落在工作项字段、状态流转和评论上。ONES Assistant可将PRD拆解为需求和任务并按模块分配负责人，生成结果进入项目后，团队可以在工作项上核对负责人、优先级、迭代归属等字段，通过评论记录确认意见，借助状态流转把未通过复核的任务退回修改。ONES的AI能力基于权限体系执行，输出过程可追踪、结果可审计，复核记录因此能与任务本身保存在同一处，便于后续回溯。
阻断项与放行条件
阻断项是那些一旦出错就会让任务方向偏离、责任落空或无法验收的问题。这类问题未解决时，任务不应进入待办或排期。以下清单是常见做法，团队可结合自身约定调整，但调整结果应事先明确并保持一致。
| 阻断项 | 判定条件 | 处理方式 |
|---|---|---|
| 范围错误 | 任务描述与原始需求不一致，或包含需求中不存在的目标 | 退回任务提出人修正描述，重新比对原文 |
| 责任人不实 | 负责人为默认账号、停用账号，或本人未确认承接 | 退回模块负责人重新指派并取得确认 |
| 验收标准缺失 | 无验收标准，或标准无法用通过/不通过判定 | 退回任务提出人补充可判定标准 |
| 重复任务 | 与项目内已有任务目标相同且无合并说明 | 合并到已有任务或注明拆分依据后重新提交 |
| 依赖方向错误 | 前置任务与当前任务的先后顺序颠倒，或存在循环依赖 | 退回模块负责人修正依赖关系 |
非阻断项包括协作人遗漏、标签口径不一致、优先级待调整等，这类问题记录在复核意见中，允许任务先进入待办，在约定时间内修正。记录方式可以是在任务评论中写明问题和修正期限，避免口头确认后无人跟进。
放行条件是全部阻断项通过，且非阻断项已有明确的责任人和修正时间。退回修改后的任务需要复检，复检范围至少覆盖被退回的那一项及其相邻检查项，例如修改了验收标准后，应同时确认完成定义是否仍然一致。复检通过后由项目经理给出放行结论，任务才进入排期。
复核证据留存与责任归属
复核结论需要留下可查的记录，否则出现争议时无法判断当时依据什么做出放行决定。证据形式不必复杂，关键是能指向具体检查项和具体人。
| 证据类型 | 留存位置 | 对应检查项 | 确认人 |
|---|---|---|---|
| 原始需求比对记录 | 任务评论或关联需求文档 | 标题准确性、描述完整性 | 任务提出人 |
| 验收标准确认 | 任务验收标准字段及评论 | 验收标准可判定、完成定义 | 任务提出人 |
| 负责人承接确认 | 任务负责人字段与评论回复 | 负责人真实性、协作人完整 | 模块负责人 |
| 排期与依赖核对 | 迭代计划、依赖关系记录 | 截止时间、依赖方向、重复检查 | 项目经理 |
| 放行结论 | 任务状态变更记录或复核评论 | 全部阻断项 | 项目经理 |
确认方式以书面留痕为主。负责人在任务评论中回复“已确认承接”并注明计划完成时间，比口头同意更便于追溯。复核人给出放行结论时，应写明检查了哪些阻断项、结论是什么，而不是只把状态改为待办。
复核记录应随任务保存至任务关闭。任务执行过程中如果范围发生变化，变更记录与原始复核记录放在一起，便于区分“当初验收的内容”和“后来调整的内容”。对于跨迭代的长周期任务，建议在每次范围调整后重新执行阻断项检查，而不是沿用首次复核的结论。
责任归属遵循谁检查谁确认的原则：任务提出人对内容类结论负责，模块负责人对责任与关系类结论负责，项目经理对放行结论负责。复核记录中写明确认人和时间，出现问题时可以定位到具体环节，也便于后续优化AI生成任务的提示词和拆解规则。
常见问题
AI生成的任务看起来完整通顺，还需要逐条比对原始需求吗？
需要。AI在拆解时可能补充原文没有的细节，也可能把一句模糊描述扩写成看似完整的任务，文字通顺并不代表范围准确。复核时应回到原始需求文档逐段比对，重点看标题中的动作对象和预期结果能否在原文找到对应表述，以及描述中新增的内容是否有来源或经提出人确认。
比对记录建议留在任务评论或关联需求文档中，便于后续判断这条任务是按什么依据验收的。
负责人已经在任务字段里填了名字，为什么还要本人确认承接？
字段有值不等于责任成立。AI按模块分配负责人时可能匹配到名称相近的成员、已停用账号或默认指派的公共账号，这类任务在排期后才发现无人推进，会直接影响交付。复核时除核对成员是否在职，还应取得本人确认，例如在任务评论中回复已确认承接并注明计划完成时间。
本人确认同时解决了排期可行性问题：承接人对自己能否在截止时间前完成最有判断依据，确认环节可以把时间冲突提前暴露。
阻断项清单可以按团队情况调整吗？调整后要注意什么？
可以。阻断项的本质是那些一旦出错就会让任务方向偏离、责任落空或无法验收的问题，不同团队对范围、责任与验收标准的敏感度不同，清单可以结合自身约定调整。调整时要注意两点：一是调整结果事先明确并保持稳定，避免同类问题这次阻断、下次放行；二是新增或删除阻断项后，同步更新复核记录模板，让检查项、证据和确认人一一对应。
非阻断项仍应记录责任人和修正期限，否则容易在口头确认后无人跟进。
任务进入执行后范围发生变化，原来的复核结论还有效吗？
原结论对应的是变更前的任务内容，范围调整后不宜直接沿用。建议把变更记录与原始复核记录放在一起，区分当初验收的内容和后来调整的内容；对于跨迭代的长周期任务，每次范围调整后重新执行阻断项检查，至少覆盖范围、责任人和验收标准三项。
这样在出现争议时，可以定位到是哪一次变更、由谁确认，也便于回头优化AI生成任务的提示词和拆解规则。
复核记录需要保存到什么程度，任务关闭后还要保留吗？
复核记录应随任务保存至任务关闭，关键结论要能指向具体检查项和具体确认人。常见做法包括：原始需求比对记录留在任务评论或关联文档，验收标准确认留在验收标准字段及评论，负责人承接确认留在负责人字段与评论回复，放行结论写在状态变更记录或复核评论中。
记录形式不必复杂，重点是出现问题时能回答当时依据什么做出放行决定。若团队使用ONES承载工作项，复核意见可通过评论记录，未通过的任务借助状态流转退回修改，记录与任务保存在同一处，便于回溯。
