code-review

代码评审

两件事：主动求审（趁早、常审，把问题挡在扩散前）+ 理性收反馈（技术评估，不是表演式同意）。

何时主动求审

• 完成一个重要功能后
• 合并到主干前
• 卡住时（换个视角）
• 修完复杂 bug 后

怎么审：优先用项目自带的 review 工具 / 命令；没有就派一个干净上下文的 reviewer，只给它工作产物（diff + 需求），别给你的思考过程——让它聚焦结果。拿到反馈按下面处理。

架构约束交叉检查

review 不只看代码能不能跑，还要看它是否越过既有决策边界：

1. 先找约束：README / CLAUDE.md / ADR / docs / 模块文档 / 入口规则 / 最近相关 commit。
2. 对照 diff：有没有默认分支、批量处理、抽象复用、降级路径等“看起来省事”的改动跨过语义边界。
3. 逐个对外行为 / 跨模块接口问：
   • 这个行为的业务语义是什么？
   • 它是否绑定租户、权限、状态、数据归属、幂等键、外部系统或生命周期？
   • 省事抽象、默认路径、批量处理会不会绕过这个绑定？
   • 既有 ADR 或模块文档有没有拒绝过类似方案？
4. 发现语义绑定但代码没表达：要求补测试 / 模块文档 / ADR 引用；能机械检查的再建议 hook / CI。

没有 ADR / spec 时

老项目没规范，不等于没约束；别把“查不到文档”当成“可以自由设计”：

1. 从事实还原隐性契约：真实调用方、DB schema / migration、配置、接口响应、日志、线上兼容、最近 commit、现有测试。
2. 给结论标证据强度：文档 / 测试 / 代码强约束 = 强；多处调用和数据形态一致 = 中；命名 / 直觉 = 弱。
3. 弱证据只写成风险或待确认，别升级成架构禁令。
4. 如果发现应长期固化的规则，转 decision-layering：该补 ADR、模块文档、测试、hook 还是 CI？

收反馈的姿势

1. 读完整反馈，先不反应
2. 用自己的话复述要求（或发问）
3. 对照代码库现实核验
4. 评估：对这个代码库技术上成立吗？
5. 回应：技术性确认 或 有理有据反驳
6. 实现：一次一项，逐项测

禁止的回应

• ❌ "你说得太对了！" / "好主意！" / "感谢指出！"——表演式同意 / 任何感谢
• ❌ 还没核验就"我马上改"

改为：复述技术要求 / 发问澄清 / 有技术理由就反驳 / 直接动手改（行动胜于话）。catch 到自己要写"谢谢"——删掉，改成陈述修法。

反馈不清时

任何一项不清楚 → 停，先问清楚，别先实现别的。
为什么：各项可能相关，局部理解 = 错误实现。

例：让你"修 1-6"，你懂 1/2/3/6 不懂 4/5 → 说"1/2/3/6 明白，4/5 需要澄清后再动手"，别先做懂的。

该反驳的时候

反馈会破坏现有功能 / reviewer 缺上下文 / 违反 YAGNI（加没人用的功能）/ 对这个技术栈不成立 / 有遗留兼容原因 / 和既定架构决策冲突 / 与 ADR、模块文档、入口规则不符 / 把语义绑定行为错误抽象成无差别复用——用技术理由反驳，不是辩护性情绪。

外部反馈尤其要核：先 grep 代码库确认真实用法。reviewer 说"实现得更完整些"，先查这功能有没有被调用——没用就提议删（YAGNI），有用才正经实现。

反驳错了就如实纠正："核过了你是对的，我之前理解错在 X，改。"——别长篇道歉、别辩解。

底线

外部反馈 = 待评估的建议，不是必须照办的命令。核验、质疑、再实现。技术严谨永远优先于社交舒适。