AI任务执行前的人工确认，需要围绕四类依据收集材料：任务输入依据、AI建议依据、风险与权限依据、可追溯依据。确认人据此判断“这个动作是否可以执行”，并把结论留痕到对应工作项。本文按任务工作项的操作层面展开，给出确认步骤、角色分工、填写示例和完成检查清单，适用于研发、运营等场景中由AI生成执行建议、由人决定是否放行的任务。
要点总览（TL;DR）
- 人工确认的对象是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收窄改动范围后重新提交建议。无论哪种处理，结论和理由都要写入确认记录，避免后续执行时范围再次扩大。缩小范围后通过时，附加条件中应写明允许改动的边界。
