differential-review

differential-review 技能概览

differential-review 是什么

differential-review 是一个面向安全审查的工作流，用来比普通 prompt 更严谨地检查 PR、commit 和 diff。它专为需要判断某个变更是否引入回归的审查者设计，尤其适合 auth、crypto、外部调用、状态变更以及其他高风险路径。

最适合哪些人使用

如果你正在审查安全敏感代码、接手了一个很大的 diff，或者需要一个能随代码库规模调整的可重复方法，那么 differential-review 很适合你。它尤其适合工程师、安全审查者，以及希望得到有证据支撑的结论、而不是粗略逐行扫一遍的 AI 辅助审计人员。

它为什么不一样

differential-review 的核心价值在于，它会先要求上下文，再下结论：基线历史、影响范围、测试覆盖，以及明确的信心边界。这个仓库还会把输出整理成结构化的 markdown 报告，所以它不只是一个分析 prompt，而是一套带交付物的审查流程。

如何使用 differential-review 技能

安装并加载该技能

典型的 differential-review install 会先从仓库工具链开始，然后把代理指向技能目录。对于这个包，安装路径是 plugins/differential-review/skills/differential-review。如果你使用的是 Trail of Bits skills repo，可以先用项目的 skills 命令安装，然后先打开 SKILL.md。

提供符合审查场景的输入

要获得最佳的 differential-review usage，请让它审查明确的 base/head 范围、commit 或 PR，并在有的话注明安全关注点。好的输入类似：“审查 base..head 是否存在 auth bypass、reentrancy 和缺失测试；重点看外部调用路径和状态转换。” 像“帮我看看这个 diff”这种弱输入，会留给模型太多猜测空间。

先读对文件

一份好的 differential-review guide 应该先看 SKILL.md，再看 methodology.md、adversarial.md、patterns.md 和 reporting.md。这些文件会告诉代理如何建立基线上下文、该使用什么攻击模型、要扫描哪些模式，以及最终报告该怎么写。这个插件里没有辅助脚本或额外的参考目录，所以这些 skill 文件就是唯一的事实来源。

会直接影响输出质量的工作流建议

当你能提供干净的 diff、基线 commit，以及足够的仓库上下文来检查调用方和测试时，这个技能效果最好。你可以告诉它代码库是小型、中型还是大型，或者让它自行判断规模，但不要跳过基线/历史这一步。对于 differential-review for Code Review，最有价值的输入是具体信息：改动文件、可能的信任边界、可疑函数，以及你已经知道的任何回归历史。

differential-review 技能 FAQ

differential-review 只适合安全审查吗？

是的，主要是。它是为安全导向的 differential review 设计的，不是用来做通用样式清理或功能验收的。你当然也可以把它用于普通 code review，但它真正的价值主要在变更可能影响信任边界、数据完整性或可利用性的时候体现出来。

它和普通 prompt 有什么区别？

普通 prompt 可能只是总结 diff；differential-review 会尝试结合历史、影响范围和攻击者建模来证明或证伪风险。它还要求输出 markdown 报告，这让结果更方便交接、归档。

它适合新手吗？

新手也能用，但它默认用户能指出具体 diff，并且希望得到结构化分析。如果你对代码库不够熟悉，这个技能反而会帮上忙，因为它要求提供基线上下文，并把缺失的覆盖面明确暴露出来。

什么时候不该用它？

不要把 differential-review 用在很小的文本改动、低风险的纯格式调整 PR，或者你只需要一段话摘要的场景里。没有明显安全风险或回归风险时，它就显得过度；只有在确实有值得深入检查的内容时，它的流程才会体现价值。

如何改进 differential-review 技能

提供更强的审查上下文

最大的提升来自于把审查面说清楚：PR 编号、commit 范围、目标分支，以及任何你怀疑有风险的区域。如果你了解项目领域，一开始就说明：Solidity 变更、API auth flow 或支付路径，会把分析引向更合适的攻击模型。

第一次就提出合适的深度要求

如果你想获得更好的 differential-review usage，请明确你更关心正确性、可利用性，还是回归风险。例如：“重点看可外部调用的函数、变更后的校验逻辑，以及新分支是否缺少测试。” 这样可以把搜索范围收窄到最重要的路径，减少噪音发现。

注意常见失误模式

最常见的遗漏包括：把小 diff 误判为低风险、忽略被删除代码的历史、以及在判断影响范围时忘记传递调用方。这个技能本身就是为避免这些错误而写的，但它仍然需要明确的基线和边界清晰的 diff，才能发挥效果。

基于第一份报告继续迭代

把第一份报告当作下一轮的起点。如果结果太宽泛，就要求更窄的攻击者模型，或者更深入地检查某个子系统。如果结果太浅，就要求它带着更多历史重新跑一遍、加强对测试的审视，或者更严格地关注不变量和回归路径。