用途：评审自己或他人的书面代码，关注代码日后被修改时的成本，而非当下是否违反规则。风格交给格式化器，正确性交给测试，评审负责那些使下一个功能从一天变成三天的隐性代价。
主要能力：先带着“六个月后没有上下文”的视角自上而下通读，按名称跟踪逻辑，记下理解中断之处——名称承诺与实现不符、需要大段解释才能衔接的两行，这些就是评审重点。随后按未来成本排序指出问题：错误的断言（类型允许领域不存在的状态、不变式只在一处强制）、会传递变更的边界（业务逻辑放进工具函数、第二次使用就抽抽象、两个模块必须同步修改）、丢失信息的错误（吞掉异常、丢失 cause、失败返回 null）、不必要副作用（决策逻辑中间做 I/O、隐藏修改调用方仍持有的对象）、缺失的内容（未处理的用例、没有名字的概念、本可捕获该类错误的测试）、已值得抽象的重复及其反面——只服务一个调用方的抽象。偏好类意见只轻说一次或不说。
使用方式：每条意见写明位置、后果与处理路径；有多种走法时给出选项并推荐一种；区分“本次应改”与“值得知晓”；具体地指出做得对的地方以校准判断。评审自己的代码时，读实际写的内容而非原本意图，最好隔一段时间或倒序阅读，最难写的部分最值得怀疑。
适用场景：代码评审、自查与变更审查。限制：避免清单式评审、严重程度不分、把风格当实质、复述 diff、模糊不适感、按个人习惯重写、只看 diff 不看上下文。