修复审查

要解决什么问题

安全审计或代码审查往往会产出一份「发现清单」：某处存在漏洞、逻辑缺陷或不符合规范。开发随后提交修复 PR 或 commit，但修复是否真的对症、是否只改了表面症状、是否在别处留下同类问题，往往仍需要人工对照原文逐条核对。更麻烦的是，匆忙补丁容易引入回归——新 bug 或新的安全面。

技能如何工作

本技能面向「审查修复提交」这一环节，而不是替代初次审计。典型流程包括：

1. 对照原始发现：把提交 diff 与审计条目一一比对，确认每条发现都有对应改动。
2. 验证根因：判断改动是否消除根本原因，而非仅绕过触发路径。
3. 检查副作用：在完整代码库上下文中看边界条件、错误处理与依赖调用是否产生新问题。
4. 测试与相似模式：确认修复场景有测试覆盖，并检索代码库中是否存在相同反模式需要一并处理。

建议同时记录「发现 → 修复思路 → 验证结论」，便于后续审计追溯。

适用边界

• 适用于已有一次明确审计结论之后的 fix review，不替代威胁建模或首次渗透测试。
• 深度依赖你提供的发现描述、提交范围与仓库上下文；缺少原始发现时，只能做一般性代码审查，无法声称「审计闭环」。
• 不能替代自动化 SAST/DAST；它帮助 Agent 按结构化清单做人工式核对与追问。