评审标准
更新于 2026-10-01
按相关维度评审。不是每个维度都适用于每次变更。自行判断。
代码是否真的做到意图所要求的事？
- 边缘情况：空输入、nil/undefined、边界值、并发访问
- 错误处理：错误是被捕获、传播，还是被静默吞掉？
- 差一错误、类型强制、整数溢出、字符串编码
- 状态管理：竞态、陈旧闭包、悬空引用
- 正常路径是否成立？异常路径是否成立？
- 幂等：操作跑两次，或上次半途崩溃，会怎样？若答案是「取决于留下了什么状态」，说明缺对账/协调步骤。
- 并发：多个参与者能否碰到同一可变状态（文件、分支、共享数据）？访问是结构上串行（锁、顺序阶段、独占所有权），还是靠约定撑不住？
发现潜在 bug 时，追踪执行路径。不要只标「可能为 nil」，要展示使其为 nil 的调用链。
根因 vs 症状
Section titled “根因 vs 症状”代码是在修真正问题，还是在掩盖症状？
回答这题常需看变更文件之外。读周围代码（调用方、被调方、类型定义、兄弟模块），理解变更所在的架构。用 Read、Grep、Glob 探索。沿调用链走。读类型。在评判变更是否打对层之前，先理解代码为何存在。
- 用守卫分支掩盖更深的不变式违反
- 用重试逻辑隐藏已破裂的契约
- 用类型转换掩盖建模错误
- 见到变通方案就问：为什么需要变通？正确修复应是什么样？
- 在模块 A 修，其实应是模块 B 契约层面的修
- 用注释/约定代替结构：若修复是「别做 X」的注释或靠人记的约定，能否改成类型约束、lint 或运行时检查，让错误做法不可能发生？
代码是否融入它所在的系统？
- 边界纪律：校验在系统边界，还是散落在业务逻辑里？数据进入系统时校验一次，内部可信任。
- 抽象层级：是否混用高层编排与低层细节？
- 耦合：这次变更是否引入让未来改动更难的依赖？
- 数据模型是否匹配真实访问模式？对的结构让下游代码一目了然；错的结构步步受阻。
- 外挂 vs 融入：是硬贴到现有设计上，还是读起来像设计一直为此预留？若需求一开始就明确，代码会写成这样吗？
- 遗留双路径：引入新 API 却保留旧的？若无外部消费者，应在同一波迁移调用方并删旧路径。不要留会变永久的兼容层。
不要因缺少抽象而惩罚简单代码。过早抽象比重复更糟。
读代码能否判断它有效？
- 有测试吗？测行为还是实现细节？
- 有断言/不变式防回归吗？
- 若是 bug 修复：有复现该 bug 的测试吗？
- 若碰集成边界：整条路径测了吗？
- 查真实状态，不要查代理指标。若用文件修改时间或缓存判断存活，而非读真实值，是验证缺口。
- 委派或异步工作：验证的是实际产物，还是自报/摘要？
复杂度是否值得？
- 可在不损正确性或清晰度下更简单的代码
- 只服务一个调用点的抽象
- 为尚不存在场景的配置/参数化
- 死代码、未用 import、遗留参数
- 过度工程：「以防万一」的路径无当前调用者
- 为已不需要的过渡期稳定而保留的过时兼容路径。迁移完成就删脚手架
- 用户体验撑得起这份复杂度吗？每个功能、控件、选项都要值回它的成本。半成品比没有更糟。
更简单更好，除非更简单是错的。三行重复胜过过早抽象。
每条安全发现都要追踪输入路径并展示。
- 用户输入流入危险终点（SQL、shell、eval、innerHTML）且无净化
- 新 endpoint 的认证/授权缺口
- 密钥出现在代码、日志或错误信息中
- 安全关键路径上的「检查与使用」时间窗问题
本站是非官方的 pstack 中文学习站，和 poteto 没有隶属关系。译文对照的是 cursor/plugins 仓库里的 pstack/ 目录。本站不发行中文版插件。 github.com/cursor/plugins