给评审 agent 写 prompt 的常见写法，是先交代一段「这段代码是为了解决什么问题」，让它理解得更充分再动手。我的判断相反：在评审场景里，这段背景是污染源。评审的价值来自不知情，前提是切断之后把客观事实补回去。
作者的解释会把评审变成确认
我积累的 424 条去重后的子代理任务指令里，有 46 条评审任务以完全相同的一句话开场：
你是一名独立代码评审员，对这段代码的开发过程一无所知——这是有意安排的，请只基于代码本身和仓库现状做判断，不要假设作者意图。写成显式声明而不是直接省略背景，是因为两者的效果不同：省略会让 agent 以为信息不全而去猜，显式声明则把「不知情」定义成它的工作前提。
意图一旦进入上下文，就会成为评审的默认前提。评审者不再问「这段代码的行为是什么」，而是问「这段代码是不是在做作者说的事」。后一个问题几乎总会得到肯定答案——代码确实是照着那个意图写的，内部完全自洽。缺陷藏在意图和行为的落差里，而这个落差只有在不知道意图时才看得见。
配套还有两条：不相信提交说明里的声称，不轻信注释。代码里的自我声明同样是作者叙述的一部分。注释写着「此处已处理并发」不构成证据，必须在代码里找到对应的同步点。
一次评审里，评审 agent 从兼容性维度报出了单元测试全绿时发现不了的问题：某个函数把抛出的异常类型收窄了，调用方原有的 except 分支因此不再命中。这类缺陷不在改动内部，而在改动与外部约定的关系上。如果评审者事先知道「这次改动是为了让异常更精确」，它很可能把收窄读成改进，而不是破坏。
切断过程，就必须补足客观背景
少给上下文和刻意隔离，写出来的 prompt 都很短，区别只在有没有补偿。没有补偿的隔离失败得很安静：agent 不会停下来说信息不够，它会自行构造一个看起来合理的意图，再照着评。这个结果比给了背景更差，因为构造出来的意图既不准确，也无从纠正。
所以切断过程信息的同时，要把这些补进去：
| 补什么 | 为什么必须由我给 |
|---|---|
| 仓库路径与本次变更文件清单 | 评审范围不能靠它推测 |
| 应当一并阅读的上下游文件 | 跨文件影响是它最容易漏掉的部分 |
| 仓库内已有的约定文档 | 这是契约，不是我对改动的叙述 |
分界线是：凡不包含「我想怎么做」的事实都可以给；实现思路、取舍理由和自我辩护一律不给。代码本身需要的上下文，让它自己去仓库里读，而不是由我转述——转述会自动带上我的理解方式。
同一条原则也用在只读契约的测试设计角色上，那里的边界划得更细：仓库路径可以用来阅读 README 和设计文档以了解项目背景，但禁止打开实现目录。禁止的是一个具体的信息源，不是全部信息。
这套做法不适用于哪些情况
评审范围本身尚未确定时。 如果改动分散在多处、连哪些属于本次变更都说不清，零背景 agent 会评错对象。先把范围确定下来，再做隔离。
需要评价方案取舍时。 「为什么选 A 而不是 B」的答案不在代码里。不知道约束条件的评审者只能给出纸面上的更优解，看起来有道理，实际不可行。取舍评审要给足背景，它和缺陷评审是两件事。
改动小到一眼能看完时。 单行修改走完整的隔离流程，成本高于收益。
最后一种情况和上面三条不同：补偿清单写不出来。如果我自己也说不清这次改动该连带检查哪些上下游文件，说明我对影响范围的理解还不完整。那要补的不是 prompt，是我的理解。