代码评审

解决的评审盲区

很多代码评审会陷入命名、格式、单行写法，忽略真正会导致线上问题的业务语义、状态机偏离、异常补偿缺失和并发/事务风险。这个技能面向 Git 分支变更，把评审重点收敛到业务实现与设计一致性、逻辑正确性与简洁性以及核心架构与并发安全。它先读取 ./review/ 下的需求或设计文档，再对照 origin/master...HEAD 的变更文件，避免只看 diff 片段后做判断。

工作方式

核心流程包括：

• 环境感知：执行 git fetch origin master --depth=1、git branch --show-current 和 git --no-pager diff --name-status origin/master...HEAD，识别当前分支与变更文件；若变更文件超过 20 个，会提示优先评审核心业务线。
• 上下文加载：扫描 ./review/ 目录，读取 .md、.docx 等文档；对 .docx 可借助 docx-reader 或 read_docx.py 提取文本与图片，帮助理解流程图、状态机和业务约束。
• 深度审查：不只看 diff，而是读取复杂方法完整上下文，交叉验证代码逻辑与设计文档是否一致、异常分支是否完整、是否存在过度设计或更简洁实现。
• 报告落盘：生成 ./review/review_[分支名].md，分支名中的 / 替换为 _；报告包含业务概览、安全评估、核心隐患、逻辑优化、肯定项和待确认问题。

适用边界

它更适合有明确需求文档、概要设计或状态机说明的业务代码评审。如果没有文档，技能会标注为仅基于代码推演，结论可信度会下降。对于纯格式、命名、注释风格类问题，它不会作为核心评审维度；对于高度依赖运行环境、外部系统或历史包袱的改动，仍需结合测试与线上上下文判断。