代码审查助手

解决的问题

代码审查容易变成两种极端：要么走马观花只看表面，要么拿着静态扫描结果逐条粘贴。前者漏掉真正危险的缺陷，后者把工具告警当成证据，却说不出触发条件和影响范围。更常见的是把个人风格偏好包装成"严重问题"，既浪费了评审时间，又降低了团队对审查结论的信任。

这个技能针对的是 基于证据的风险审查，而不是泛泛的"建议优化"。它要求先重建变更意图，再沿着执行路径检查副作用，最后用触发条件和可观察影响来证明每个发现。

核心能力与工作步骤

技能的工作流固定为八步：

• 固定审查边界：记录基准分支、目标分支和不在本次处理的事项，遇到大变更按模块或调用链分批。
• 重建变更意图：从需求、提交信息、测试和代码共同推断期望行为，写出用户可观察的变化、必须保持不变的约束。
• 画出受影响路径：从入口追到关键副作用，包括输入验证、权限判断、数据库写入、外部调用和缓存。
• 风险优先审查：按后果从高到低检查，优先处理数据损坏、越权、泄露和不可逆操作。
• 检查测试是否证明行为：警惕只断言调用次数、不检查结果的测试，缺失测试时说明应证明的行为。
• 编写问题条目：一个条目只描述一个可修复根因，先给结论，再给证据和触发条件。
• 交叉验证：用现有测试、静态检查或最小复现验证发现，无法执行时列出未验证原因。
• 给出合并建议：结论只能是"可合并"、"修正后合并"或"需重新设计"之一。

输出按固定顺序：审查范围与关键假设、按 P0→P3 排序的问题、测试与验证缺口、已确认没有问题的高风险路径、合并建议与剩余风险。

适用边界

技能不替代人工判断。它不会在缺少代码或执行证据时伪造逐行问题，也不会把格式、命名这类个人偏好列为高优先级缺陷。它不泄露仓库密钥或内部地址，不提供用于真实系统攻击的利用步骤，也不自动修改或合并代码，除非用户明确要求并授权。

关键边界在于区分 代码可证实、需运行验证 和 仅为假设。每个问题必须同时包含触发条件和可观察影响，没有具体执行路径的怀疑不会升级为阻断问题。同样，静态扫描的告警会先经过去重和可达性确认，再决定是否写入问题清单。