代码审查

它解决什么问题

手动审查 PR 的瓶颈在于注意力：diff 动辄几百行，读代码的同时还要想「这段逻辑在什么输入下会崩」「这个查询会不会在循环里跑 N 次」，漏掉一处边界条件就进了主干。这个技能把审查拆成固定维度和检查项，让代理逐条走一遍，输出带严重级别、指向具体代码行的反馈，而不是一句「看起来还行」。

审查如何组织

输入解析与上下文对齐：先判断输入是单个文件、目录还是 PR；若是 PR，会拉取 diff 并识别 base branch，只审变更行及其紧邻上下文。同时读取 linter 配置、风格指南和类型定义，避免用通用标准替代项目自身的标准。

先理解意图再挑错：读 commit message、PR 描述和周边代码，用一句话概括这次改动的目的。这一步能挡掉大量误报——不知道作者想解决什么问题就评判实现，很容易把有意的取舍判成缺陷。

按维度逐层检查：

• 正确性：遍历每个变更函数的数据流，找空指针、off-by-one、布尔逻辑错误、未处理的异常路径、并发竞态与资源泄漏；验证空输入、极大值、非预期类型等边界。
• 安全：扫描未过滤的用户输入（SQL 注入、XSS）、硬编码密钥、不安全的加密用法、过宽的文件或网络权限、缺失的鉴权检查；新增依赖会查已知 CVE。
• 性能：识别嵌套循环、循环内的重复数据库查询、无界内存增长、不必要的分配、异步上下文中的阻塞调用。
• 可读性与可维护性：命名清晰度、函数长度、重复逻辑（DRY）、是否遵循项目风格指南、公共函数是否有 docstring 或类型注解、魔数是否提取为常量。

报告按 Critical / Warning / Info 分级，每条反馈附带可执行的修改建议（替换代码片段或具体重构步骤），而不是含糊的「这里可以优化」。单轮聚焦最紧要的 5–7 个问题，避免一次性淹没作者。测试也会被一起检查：新逻辑没有测试要标记，已有测试要确认覆盖了变更行为而不只是 happy path。

适用范围与注意点

• 代码生成器、协议缓冲区编译产物、vendored 依赖默认跳过，除非明确要求。
• 超过 1000 行的 PR 很难审透，代理会提示拆分，并先聚焦高风险文件。
• 语言习惯不同：Go 的显式 error 返回在别的语言里可能显得冗余，代理会按检测到的语言调整预期。
• 仅有格式或改名改动的 PR，只确认无语义差异并给出简短通过结论，而不是完整报告。
• 缺少完整仓库上下文时（例如只能看到 diff），类型定义、配置和上游调用方无法验证，代理会显式写出假设。