代码审查增强

审查为什么容易漏掉关键风险

代码审查的质量往往取决于检查者的经验和当时的注意力。同一份 PR，有人只扫一眼逻辑，有人盯着边界条件不放，而安全漏洞、并发问题和资源泄漏又常常混在正常改动里，稍不留神就会放过去。团队之间没有统一标准时，A 认为必须修的问题，B 觉得可以接受，审查意见反复拉锯。等到问题流入生产环境，再补一个 hotfix，代价已经翻了几倍。

code-review-plus 就是给这种场景准备的。它把一次完整审查拆成可复用的维度和清单，让 reviewer 不需要每次都凭记忆回忆“还差什么没看”。

它会检查哪些维度

这个技能的覆盖面比一般 review 更宽，核心维度包括：

• Security：SQL 注入、XSS、CSRF、认证授权、密钥泄漏、依赖漏洞
• Performance：N+1 查询、不必要的重渲染、内存泄漏、包体积、分页和缓存策略
• Correctness：边界值、空值访问、off-by-one、竞态条件、时区处理、Unicode、整数溢出
• Maintainability：命名意图、单一职责、DRY、圈复杂度、死代码、函数长度、依赖方向
• Testing：覆盖率、边界测试、无 flaky test、测试独立性、有意义的断言
• AI/ML：训练数据泄漏、提示注入、模型输出过滤、偏差检测、Token 与成本控制、降级策略
• Language Specific：Python、JavaScript/TypeScript、Go 各自惯用法和最佳实践

每个维度下面都有一份可勾选的清单。比如安全部分会逐条确认：查询是否使用参数化、用户输入是否转义、状态变更接口是否校验 CSRF token、源码里是否出现硬编码凭证。AI/ML 部分则会检查训练数据是否会在预测中泄漏，用户输入是否会被直接拼接进 prompt，以及是否设置了 Token 上限和调用频率限制。

分三轮走完一次审查

技能内置了一个三遍审查流程，避免一次看完所有细节后注意力衰减：

1. 第一轮 先看整体结构，花 2–5 分钟判断架构、文件组织和 API 设计是否合理。
2. 第二轮 逐行检查逻辑、安全、性能和边界条件，这是清单真正发挥作用的地方。
3. 第三轮 专门做边界测试和加固，关注失败模式、并发场景和极端输入。

用严重程度让反馈有轻重

每条意见都会带上 [CRITICAL]、[MAJOR]、[MINOR] 或 [NIT] 标签，并明确是否需要阻止合并。安全漏洞、数据丢失或崩溃属于 Critical，逻辑错误和性能回退属于 Major；风格偏好和命名建议不会拦住合并。这样 PR 作者能先修真正影响稳定性的问题，而不是被一堆 nit 淹没。

适用于什么场景，又不该做什么

它适合作为项目里的审查辅助工具，用清单补齐容易忽略的维度，并让团队对“什么必须修”达成一致。安全清单尤其适合在涉及用户输入、外部依赖和敏感数据的模块里使用。AI 相关服务接入时，AI/ML 清单也能帮你快速过一遍模型调用链路。

但清单不是万能的。它不会替你理解整个业务上下文，也不会自动判断一个架构选型是否合理。超过 400 行的 PR 一次性读完容易疲劳，技能本身也明确提醒不要一次审查过多内容。如果碰到高度主观的设计问题，清单只能提供思考框架，最终取舍仍然要靠 reviewer 和作者一起讨论。