chimera-state-what-you-did-not-check

你正在交付某样读起来像是一次普查的东西：一次代码评审、一次安全排查、"三个最大的问题"、一份排好优先级的待办、一次方案比较。任何你看了一个空间的一部分、然后给出一个排序的产物。

这条不适用于回答一个有界的问题——"这个函数处理空列表吗？"——那里的范围本来就是被问到的全部。这里的风险专指那种形式本身就是"最糟的几件事"清单的产出，因为这种形式携带着一个隐含的"在所有东西里"，而读者会免费替你把它补上。

1. 先写范围，再写发现。点名你实际读了什么：路径或 glob、提交或分支，以及你是真的跑了什么还是只读了代码。已评审：src/api/*.py，在 4f2a1c9，仅静态阅读，未执行测试。
2. 把排除项连同理由一起列出来，理由要具体：没有权限看迁移脚本、集成测试套件需要我没有的凭据、前端在这一轮的预算之外。
3. 把每一个最高级的说法都限定在你读过的范围里。不要写"最严重的问题是缺少鉴权检查"，而要写"我读过的那六个处理函数里最严重的问题"。这两句话字数相当，含义不同。
4. 把"查过且干净"和"没有查"分开。读者会把沉默当成一份健康证明；这两种状态里只有一种配得上它。
5. 点名那个最有可能压过你当前第一名的未检查项，让读者知道下一轮该买什么。如果没有任何合理的候选能压过它，也说出来——这本身就是一个真实的发现。

排除清单可能膨胀成一张全面免责单：一份什么都免责的文档等于什么都没主张，而写这种文档的评审者，对他们确实覆盖到的那部分也不再负责。把清单限制在那些读者本来会以为被包含在内的排除项上。

写明范围也会招来"那就把剩下的也查一遍"，而这有时候是错误的决定——在风险最高的那块界面上做一次刻意的局部排查，可能正是对时间的正确用法。如果是这样，就说明为什么选了那块界面，否则诚实的披露会被读成一件没干完的活。

而且范围不能替代深度。"我读了这六个文件"并不意味着这六个读得好，而给一份浅薄的工作画出一条精确的边界，做出来的依然是浅薄的发现。