要复核 AI 的操作清单，先按操作的影响范围分类：仅生成内容、仅修改本地状态、产生外部副作用（如发信、付款）。不同类别的复核逻辑不同，最终通过可追溯的记录确认每一步动作，而非模糊的完成提示。
这套做法适用于需要明确知晓 AI 执行的所有动作、避免遗漏或误判的场景，比如核对 AI 处理事务的完整性、确认 AI 是否执行了约定的委托事项。不适用的场景包括仅需大致知晓 AI 产出、不需要精确到每一步操作的情况，以及 AI 操作本身不产生可追溯记录的场景（这类场景无法通过本方法复核）。
读者可能不知道，AI 的操作可按三类划分：仅生成内容（如写文案）、仅修改本地状态（如调整个人笔记）、产生外部副作用（如发送消息、发起支付）。前两类的操作记录仅关联内部交互，第三类会留下外部系统的痕迹，这一划分决定了后续复核的重点方向，而非笼统地“查所有操作”。
多数人会试图查所有 AI 操作，但其实无需如此——仅需筛选与你委托的事务相关的操作，比如你让 AI 整理会议纪要，就只查 AI 在纪要生成过程中的动作，而非 AI 的所有对话记录。这能大幅减少复核的冗余信息，避免被无关操作干扰，提升复核效率。
很多人以为 AI 操作是无痕迹的，但实际上每类操作都有对应的可追溯节点：仅生成内容的操作关联内容的修改记录，仅修改本地状态的操作关联状态变更的时间戳，产生外部副作用的操作关联外部系统的确认凭证。这些节点是复核的核心依据，而非依赖 AI 的口头说明。
读者可能不清楚，AI 的操作需与你的委托事项一一对应——比如你委托 AI 发送邮件，就需核对 AI 是否执行了“撰写、发送”两个动作，而非仅核对是否有邮件发送记录。若操作与委托事项不匹配，说明存在 AI 未按要求执行的情况，这是复核的关键判断点。
成因是误以为需查 AI 的所有动作，导致信息过载，无法聚焦关键操作。卡住的表现是花费大量时间查看无关记录，找不到与委托相关的操作。绕过去的方法是先明确委托事项的范围，仅筛选与该范围相关的操作，忽略其他无关动作。
成因是认为 AI 操作仅在内部，未意识到部分操作会影响外部系统。卡住的表现是未核对外部凭证，误以为 AI 已完成操作但实际未执行。绕过去的方法是对涉及外部系统的操作，主动查找对应的外部确认记录，而非仅依赖 AI 的内部说明。
成因是未明确委托的具体动作，导致 AI 执行了额外或缺失的操作。卡住的表现是复核时发现 AI 做了未委托的事，或未做已委托的事。绕过去的方法是在委托时明确列出需执行的具体动作，复核时逐一核对这些动作是否存在。
在 OneOneTalk 中，复核 AI 操作的机制基于可验证的长期记忆与受委托执行留回执的功能：所有 AI 执行的操作都会被记录，每条记录包含操作的来源、时间、置信度及作用域，可随时纠错；受委托的操作会留下明确的执行回执，分级审批的记录也会同步关联对应操作。当前这一层的机制已覆盖常规操作的复核需求，若需更细粒度的动作拆分，我们还在完善对应功能，眼下可通过查看操作的作用域与回执来完成复核。