用独立AI会话复核代码与执行计划

让一个 AI 写代码，再让另一个 AI 审核，Atlarix 把这件事接进了会话之间的审批流程。作者介绍的跨会话审查（cross-session review）可以批准或拒绝待执行操作，也能替换另一会话的计划，但高风险请求仍须由所有者批准。

它值得关注的地方，是把第二个 AI 的意见变成能影响执行的决定。不过，审批机制已经落地，不等于「两个 AI 一定比一个可靠」也得到了验证。实际用起来，要分清权限审批和代码质量审查。

第二个会话为什么可能发现遗漏

作者的理由是：写代码的会话已经接受了一组假设，继续让它自查，很容易沿着原来的思路走。另一个新启动、或从较早状态分叉出来的会话，没有完整经历这条推理路径，更可能追问前一个会话默认成立的条件。

例如，执行者认为某个修改符合需求，审查者可以重新检查这个前提，而不只是看实现是否自洽。这是第二视角的价值。

但原文没有给出缺陷检出率、误报率，也没有展示具体代码案例。因此，「第二个会话能抓到单会话漏掉的错误」在这里仍是作者的经验判断，不能当作有对照实验支持的结论。

怎么让审查结果真正影响执行

跨会话审查在 Atlarix 15.11 上线。操作从同一工作区中的两个会话开始：第一个负责执行任务，推进到计划审批或权限请求时暂停；第二个负责查看并回应待审批状态。

入口是 list_sessions。审查者可以看到目标会话的 hasApproval: true，或发现它有待批准的计划。接下来有两种方式：

• 使用 send_message，带上 review: true，把待审批状态附到消息中。
• 直接通过 approval: <operationId> 回应某个权限请求，或用 plan: approve 批准计划。

需要读完整计划时，使用带 plan_of 的 list_sessions。对于权限请求，pendingApprovals 会列出每项请求的 operationId、操作类型和摘要，审查者可以逐项批准或拒绝，也可以批准将执行这些操作的计划。

这些字段解决的是「找到哪项请求、对哪项请求作答」。原文没有展示完整调用代码，也没有说明审查者会自动拿到哪些文件内容、差异或测试结果，不能仅凭操作摘要就认为已经完成代码审查。

AI 批准以后，操作会直接继续

批准的效果与所有者点击 Approve 相同：目标会话继续执行。拒绝会阻止该请求，并把原因告诉目标会话；替换计划则会让目标会话按新计划推进。

每次回应都会在目标会话中显示由谁作答，审批过程可见。这里的「替换」针对计划，原文没有说明审查者能通过审批接口直接替换代码。

第二个 AI 拿到的是受限的审批权。

可能造成数据丢失或安全问题的高风险请求，不能由同级会话批准，仍然需要所有者处理。限制按每一项请求判断，而不是给某个会话整体贴上可信标签。不过，原文没有解释高风险请求如何识别，也没有列出具体判定规则。

我的判断

这个设计合理的地方，是把审查接到执行之前。相比让另一个 AI 在聊天里提建议，它能直接阻止操作、退回原因或改写计划，减少「意见给了，执行者却没处理」的脱节。

但权限审批与代码质量是两回事。一个文件编辑请求可以获准执行，代码仍可能有逻辑错误；一份计划读起来合理，实现也未必符合预期。

第二个会话还能否保持独立视角，同样有前提。若它只接收执行者整理好的摘要，或从已经形成相同假设的位置分叉，仍可能重复原来的判断。原文也没有比较这种方式与单会话自查、人工审查、自动化测试的效果和成本。我会把它看作多一道检查，而不会据此取消已有验证。

能拿来做什么

• 在使用 Atlarix 15.11 的日常 AI 编程任务中，可以让执行会话停在计划审批处，由另一个会话先检查范围、前提和执行顺序，再决定是否批准。
• 审核文件修改时，先通过 pendingApprovals 和 operationId 确认具体操作，再检查相关代码；不要只凭摘要作出批准决定。
• 拒绝请求时写清原因；如果问题出在整体方案，就替换计划，让执行会话得到明确的下一步。
• 把跨会话审批放进现有验证流程，同时保留测试与人工审查；遇到高风险请求，由所有者按实际操作内容判断。