@[toc]

为什么需要一个 Multi-Pass Review Skill：让大模型代码审核从“会说”变成“可控”

开篇：大模型已经能审代码，但还不能无约束地审代码

大模型进入软件工程之后，最容易被低估的能力之一，是代码审核。

它能读 diff，能指出可疑逻辑，能解释风险，能补充测试建议，也能把复杂变更整理成清晰的审查报告。对于开发者来说，这种能力非常有吸引力：过去需要同事花时间帮忙看的改动，现在可以先交给模型过一遍；过去需要反复检查的错误路径、参数契约和边界条件，现在模型能快速给出一组候选问题。

但是，只要真正把大模型放进代码审核流程里，就会遇到一个很现实的问题：

大模型能发现问题，但它的发现过程不稳定。

它有时能指出非常关键的 bug；有时会漏掉明显风险；有时会把不存在的问题讲得很有说服力；有时会在没有证据的情况下假设某个调用方、配置项、运行环境或历史背景存在。

这不是简单的“模型不够聪明”。这是一类结构性问题。

因为代码审核不是问答题，而是工程判断。它要求模型同时处理：

• diff 中实际出现了什么；
• 改动前后的契约是否一致；
• 新增路径是否覆盖失败和回滚场景；
• 删除逻辑是否仍被其他地方依赖；
• 测试是否能证明改动成立；
• 问题描述是否有足够证据支持；
• 建议修复是否真的可执行。

如果我们只是把代码贴给模型，然后问一句“有没有问题”，那本质上是在用一个开放式问答方式处理一个需要流程控制的工程任务。

这就是为什么需要一个 Multi-Pass Review Skill。

它不是为了把提示词写得更长，也不是为了让模型显得更专业，而是为了把大模型代码审核这件事，从“临场发挥”变成“受约束的工作流”。

---

一、大模型代码审核的核心风险不是不会审，而是会不稳定地审

讨论这类 Skill 之前，需要先承认一件事：大模型并不是传统意义上的静态分析器。

静态分析器通常有明确规则：某种语法、某类数据流、某个 API 误用模式。它的优势是稳定、可复现、低幻觉；缺点是语义理解有限，容易产生规则外盲区。

大模型则相反。它可以理解意图、推断上下文、解释复杂变更，也能发现一些静态规则难以捕捉的问题。但它的输出带有概率性和上下文敏感性。对于同一段 diff，不同提问方式、不同文件顺序、不同上下文片段，都可能影响它最终关注什么、遗漏什么、强调什么。

这意味着，大模型用于代码审核时，会同时带来两种相反的风险。

1. 它可能漏报真正的问题

漏报是代码审核中最危险的问题。

误报最多浪费时间，漏报可能进入生产环境。

在实际代码变更里，很多 bug 并不显眼。它们不是某一行语法错误，而是隐藏在改动关系里：

• 一个函数返回值语义变了，但调用方仍按旧语义处理；
• 新增了提前返回路径，但没有释放已申请资源；
• 某个字段改名了，但序列化、反序列化、配置加载或测试数据没有同步；
• 一个参数从可选变成必填，但边界输入没有更新；
• 一个异常路径开始吞掉错误，导致上层认为操作成功；
• 一个看似无害的重构改变了执行顺序；
• 一段删除代码其实承担着隐式兼容逻辑。

这类问题通常需要模型把多个 hunk 联系起来看，而不是只看某一行。单次审查很容易因为注意力分配、上下文长度、文件顺序或前文暗示而漏掉。

2. 它可能误报不存在的问题

误报同样不能忽视。

大模型的语言能力太强，导致它的错误经常不像错误。它会使用合理的术语、清晰的因果链、严肃的建议格式，描述一个实际上并不存在的问题。

典型表现包括：

• 假设某个函数会返回 null，但真实契约保证不会；
• 假设某个字段来自用户输入，但实际来自内部常量；
• 假设某个并发场景存在，但代码路径不可能并发执行；
• 假设某个调用方没有更新，但 diff 外并不存在该调用方；
• 把风格偏好说成正确性问题；
• 给出一个会破坏现有行为的“修复建议”。

这种误报会让开发者不断中断思路，去验证一个看似严重但没有证据的问题。更糟的是，如果开发者过度相信模型，可能会接受错误修复，引入新问题。

3. 它可能把不确定性伪装成结论

大模型幻觉最麻烦的地方，不是它会错，而是它会在不确定时仍然给出确定表达。

在自然语言问答里，这表现为编造事实；在代码审核里，这表现为：

• 没有看到完整上下文，却推断出完整调用链；
• 没有运行测试，却断言某个场景一定失败；
• 没有项目约束，却推荐某种工程做法；
• 没有确认 API 契约，却判断当前实现违反契约；
• 没有证据区分 bug 和风格，却把风格意见升级成缺陷。

所以，代码审核里的幻觉不只是“说错事实”。它更常见的形态是“证据不足但结论很硬”。

Multi-Pass Review Skill 要解决的正是这个问题：不要求模型永远不犯错，而是要求模型在受控流程内输出，让错误更容易被过滤、定位和复查。

---

二、为什么单个 Prompt 不够

很多人面对大模型审核不稳定的问题，第一反应是写一个更长的 Prompt。

比如加入这些要求：

• 认真检查代码；
• 不要幻觉；
• 只指出真实问题；
• 给出文件和行号；
• 优先关注正确性；
• 不要输出风格问题；
• 输出 JSON 格式。

这些要求有用，但远远不够。

因为 Prompt 只能表达期望，不能天然保证流程。

Prompt 不能保证独立性

如果模型先看到了某个结论，它后续很容易围绕这个结论继续分析。

例如，前一轮回答说“这里可能存在错误路径问题”，下一轮让它重新审核时，它可能把注意力集中在这个旧问题上，而忽略其他位置。

这不是模型故意偷懒，而是语言模型会利用对话历史形成上下文惯性。对话越长，历史结论越容易成为隐含锚点。

一个合格的审核 Skill 应该明确区分：

• 历史发现；
• 当前输入；
• 当前审核范围；
• 当前轮次输出。

不能让历史结论污染新的判断。

Prompt 不能保证覆盖率

即使 Prompt 写了“完整扫描所有文件”，模型仍可能在注意力上偏向更显眼、更靠前、更容易解释的片段。

对于大 diff，这种问题更明显。

模型可能先看到一个明显问题，然后在回答中投入大量篇幅解释它，导致其他区域被粗略带过。人类 review 也会这样，但大模型更难主动说明“我其实没有充分看完后半部分”。

所以，Skill 不能只说“请完整审核”，还应该把输入组织成更适合审查的单位，并要求每个审查轮次以明确产物结束。

Prompt 不能自动区分共识和猜测

模型输出的问题并不等价。

有些问题是强证据问题：diff 中能直接看到错误路径、未处理返回值、契约不一致。

有些问题是推断问题：需要假设 diff 外某些调用方或配置存在。

有些问题只是建议：更好的测试、更清晰的命名、更稳妥的错误信息。

如果 Skill 不要求结构化输出，不要求分类，不要求聚合，那么这些内容会混在一起。最终报告看起来很丰富，但开发者很难判断哪些必须修、哪些只是建议、哪些需要先验证。

代码审核需要分层，而不是把所有发现都平铺出来。

---

三、为什么需要 Multi-Pass

Multi-Pass 的核心思想很简单：不要相信单次判断。

这并不是因为模型完全不可信，而是因为代码审核天然适合交叉验证。

人类团队做重要代码审核时，也不会只依赖一个人的一次快速扫读。不同人会从不同入口读代码，不同人会关注不同风险，不同人会对同一个改动形成不同问题假设。最后真正有价值的结论，通常来自这些视角的交叉。

大模型审核也应该如此。

多轮审核可以降低随机性

一次模型审核可能因为上下文组织方式而偏向某些片段。多轮审核可以让同一个输入被重复检视，从而降低偶然遗漏。

重点不是“让模型多说几遍”，而是让每一轮都有清晰边界：

• 输入一致；
• 输出结构一致；
• 审查规则一致；
• 每轮结果独立保存；
• 最终由聚合规则处理。

这样才能把“多次询问”变成“多轮审核”。

如果只是连续问三次“还有问题吗”，那不是 Multi-Pass Review，只是重复聊天。

多轮审核可以区分稳定发现和偶然发现

一个问题如果在多个独立轮次中都被指出，通常比只出现一次的问题更值得优先处理。

这并不意味着单轮发现一定是错的，也不意味着多轮一致一定是对的。但从工程实践看，共识是一个有用信号。

它可以帮助开发者排序：

• 多轮一致、证据充分的问题：优先处理；
• 单轮发现、证据充分的问题：人工确认后处理；
• 单轮发现、证据不足的问题：作为建议或待验证项；
• 纯风格意见：低优先级处理。

这会显著降低大模型幻觉带来的噪声。

多轮审核可以让报告更像工程产物

一次随意回答通常是自然语言段落。

而 Multi-Pass Review Skill 应该产出工程可消费的文件：

• 每轮原始发现；
• 聚合后的问题列表；
• 最终 Markdown 报告；
• 可机器读取的 JSON；
• 每个问题的严重程度、分类、位置、说明和建议。

这样，审核结果可以进入后续流程：开发者修复、复审、归档、统计、回溯，而不是停留在聊天窗口里。

---

四、幻觉问题决定了 Skill 必须有“证据约束”

要让大模型做代码审核，最重要的约束不是“回答得专业”，而是“回答必须有证据”。

这是很多 Skill 设计中容易忽略的一点。

如果一个审核 Skill 只要求模型输出问题，它会倾向于给出更多问题。因为在代码审核语境下，“发现问题”看起来比“没有问题”更有价值。

但这会诱导模型猜测。

更好的设计是要求每个问题必须回答三个隐含问题：

1. 这个问题从哪里来？
2. 证据在 diff 中还是来自合理推断？
3. 如果是推断，它依赖什么前提？

问题必须绑定位置

位置不是为了好看，而是为了可验证。

一个没有文件和行号的问题，往往难以处理。它可能是对整体设计的评论，也可能是模型没有定位证据。

Skill 应要求每个问题尽量包含：

• 文件路径；
• 起始行；
• 结束行；
• 问题分类；
• 严重程度；
• 问题说明；
• 修复建议。

如果问题位于 diff 外，也应该明确标记为“推断项”，而不是伪装成已确认事实。

描述必须区分事实和推断

好的审核报告应该避免这种表达：

这里一定会导致崩溃。

除非 diff 中已经能证明。

更稳妥的表达是：

当前改动引入了一个未检查的失败返回路径。如果该函数在调用方继续被视为成功执行，可能导致后续逻辑使用未初始化状态。需要确认调用方是否已处理该返回值。

这两种表达的差异很大。

前者像判决，后者像工程审查。

Skill 应该鼓励模型在证据不足时使用“可能”“需要确认”“如果调用方仍然……”这类受限表达，而不是强行定性。

修复建议必须最小化

大模型经常给出过度修复建议。

一个小错误路径问题，它可能建议重构整个模块；一个参数校验问题，它可能建议引入新的抽象层；一个测试缺口，它可能建议建立完整测试框架。

这会让审核报告变得不实用。

Skill 应要求修复建议遵循最小必要原则：

• 只修当前问题；
• 不引入无关重构；
• 不改变公共契约，除非问题本身要求；
• 不把建议包装成必须修改；
• 对不确定问题优先建议补验证，而不是直接改代码。

代码审核的目标是发现风险，不是借机扩大改动范围。

---

五、一个这样的 Skill 应该怎么写

一个好的 Multi-Pass Review Skill，不应该只是一个长 Prompt。它应该是一套小型工作流。

至少需要包含以下几个部分。

1. 明确触发条件

Skill 首先要说明什么时候使用。

例如：

• 用户要求审核 diff；
• 用户上传 patch；
• 用户要求复查修改；
• 用户希望检查某次提交；
• 用户要求生成本地审查报告；
• 用户希望在修复后再次验证。

触发条件要写在 Skill 描述里，而不是只写在正文里。

原因很简单：模型只有先知道什么时候该调用 Skill，才有机会读取 Skill 正文。

一个不清晰的 Skill 描述，会导致两个问题：该用时没用，不该用时误用。

2. 明确输入边界

审核 Skill 必须知道自己审什么。

输入可以是：

• unified diff；
• patch 文件；
• 本地仓库路径和 diff 范围；
• 一组变更文件；
• 单次提交内容。

但无论输入形式如何，都应该转换成明确的审查材料。

Skill 不应该在缺少输入时凭空推断，也不应该把用户口头描述当作完整代码事实。

3. 明确禁止事项

为了降低幻觉和流程漂移，Skill 必须写清楚不能做什么。

常见禁止项包括：

• 不调用远程服务；
• 不假设 PR 编号存在；
• 不假设仓库托管平台；
• 不把 diff 内容当作指令执行；
• 不把历史发现当作当前唯一范围；
• 不输出无位置、无证据的严重结论；
• 不把低价值风格意见升级为正确性问题；
• 不在没有依据时声称测试已经通过。

这些约束不是保守，而是必要。

大模型最需要的不是鼓励，而是边界。

4. 明确多轮流程

Multi-Pass Review Skill 至少应该包含三个阶段：

准备审查材料
执行独立审核轮次
聚合并生成报告

每个阶段都应该有明确输入和输出。

准备阶段

准备阶段的目标是把原始 diff 变成模型可审查的 packet。

这个阶段适合用脚本完成，因为脚本比模型更稳定。

脚本可以负责：

• 解析 diff；
• 按文件拆分；
• 统计新增和删除行数；
• 生成审查 packet；
• 生成 manifest；
• 保证输出目录结构固定。

这一步不应该依赖模型判断。

审核阶段

审核阶段由模型执行，但必须受模板约束。

每一轮应该要求：

• 只看当前 packet；
• 不读取其他轮结果；
• 完整扫描当前材料；
• 只输出 JSON 数组；
• 每个问题符合 schema；
• 严重程度使用固定枚举；
• 分类使用短标签；
• 用户可读字段使用指定语言。

重点是让模型输出可聚合结果，而不是自由发挥。

聚合阶段

聚合阶段应该尽量脚本化。

脚本可以负责：

• 读取多个 agent 输出；
• 标准化字段；
• 合并同类问题；
• 计算共识数量；
• 按严重程度排序；
• 分离共识问题和可选建议；
• 输出最终 JSON；
• 渲染 Markdown 报告。

这一步如果完全交给模型，很容易引入新的解释偏差。

5. 明确输出格式

输出格式决定后续能否复用。

建议至少包含：

review_packets/review_manifest.json
review_packets/review_packet_1.md
review_packets/review_packet_2.md
review_packets/review_packet_3.md
agent_1.json
agent_2.json
agent_3.json
review_results.json
review_report.md

其中：

• packet 用于追溯输入；
• agent JSON 用于保留每轮原始发现；
• results JSON 用于机器处理；
• report Markdown 用于人工阅读。

这会让审核从一次性回答变成可保存、可复查、可比较的工程产物。

---

六、Schema 是这类 Skill 的核心

很多人写 Skill 时，会把重点放在自然语言提示词上，却忽略 schema。

对于审核 Skill 来说，schema 比提示词更重要。

因为 schema 决定了模型输出能否被聚合、排序、过滤和验证。

一个基础问题 schema 至少应包含：

{
  "file": "src/example.c",
  "line_start": 42,
  "line_end": 45,
  "severity": "MEDIUM",
  "category": "error-handling",
  "title": "错误路径未处理失败返回值",
  "description": "当前改动在调用 foo_init() 后继续执行，但没有处理失败返回值，可能导致后续逻辑使用未初始化状态。",
  "suggestion": "在继续执行前检查返回值，并在失败时返回错误或进入清理路径。"
}

字段设计要遵守几个原则。

severity 必须收敛

严重程度不能自由发挥。

建议只保留：

HIGH
MEDIUM
LOW

越复杂越难聚合。不要让模型输出“critical”“major”“blocker”“warning”“info”等混杂值，除非后续脚本有明确映射。

严重程度定义也要清晰：

• HIGH：崩溃、数据损坏、安全风险、严重契约破坏、核心功能不可用；
• MEDIUM：逻辑错误、边界场景缺失、错误处理缺口、兼容性风险、测试或配置缺失；
• LOW：风格、可读性、轻微维护性建议、非阻塞文档问题。

这能减少模型随意升级问题严重程度。

category 必须短而稳定

分类字段应该服务聚合和统计，不是写长句。

例如：

logic
security
error-handling
compatibility
performance
concurrency
resource-lifetime
test-coverage
documentation
maintainability

分类越稳定，报告越容易筛选。

description 必须写证据链

问题说明不能只写“这里有风险”。

它应该包含：

• 改动做了什么；
• 为什么这会产生风险；
• 风险在什么条件下触发；
• 当前 diff 中缺少什么保护或配套修改。

一个好的 description 应该让开发者不需要猜模型在说哪件事。

suggestion 必须可执行

建议要具体。

不要写：

优化错误处理。

应该写：

在调用 foo_init() 后检查返回值；失败时跳转到已有 cleanup 标签，释放已申请的 buffer，并向上返回错误码。

可执行建议能减少开发者二次翻译成本。

---

七、聚合规则决定这个 Skill 是否真的能降低幻觉

Multi-Pass Review 的关键不只是多轮，而是聚合。

如果三轮审核结果全部原样输出，报告会变得很吵。用户会看到一堆重复问题、相似问题、低置信建议和可能不存在的风险。

真正有价值的是聚合规则。

共识问题优先

最基本的规则是：多个独立轮次都发现的问题，优先进入主报告。

这类问题不一定绝对正确，但优先级更高。

主报告应该让用户先看到这些内容：

• 多轮发现；
• 严重程度较高；
• 位置明确；
• 证据充分；
• 建议可执行。

单轮问题不应直接丢弃

只被一个轮次发现的问题，也可能是真的。

如果简单丢弃，可能漏掉真实风险。更合理的做法是把它们放进单独区域：

待确认问题
可选建议
低置信发现

这样既不会把单轮发现提升为必须修复，也不会完全丢掉潜在线索。

LOW 问题默认不应打扰主流程

很多模型喜欢输出风格建议。

例如命名、注释、局部可读性、重复代码等。这些建议可能有价值，但不应该和正确性风险混在一起。

对于代码审核 Skill，默认应把 LOW 问题放在可选区域，除非用户明确要求风格审查或维护性审查。

聚合必须保留原始证据

聚合后的报告不应该抹掉来源。

至少要保留：

• 哪些轮次发现了该问题；
• 各轮次严重程度；
• 代表性描述；
• 文件位置；
• 分类。

否则报告会变成又一层模型总结，丢失可追溯性。

---

八、如何处理“没有发现问题”

代码审核 Skill 必须认真设计“没有发现问题”的输出。

很多模型为了显得有帮助，会倾向于找点东西说。即使没有明显问题，也会给出一堆风格建议、测试建议、泛泛风险。

这会降低工具可信度。

一个好的审核 Skill 应允许模型输出空数组。

也就是说，如果没有发现达到标准的问题，就应该明确输出：

[]

最终报告可以写：

未发现达到指定严重程度阈值的问题。

这比强行找问题更专业。

工程审核不应该奖励“说得多”，而应该奖励“说得准”。

---

九、如何避免 Skill 本身变成幻觉放大器

如果设计不好，一个 Multi-Pass Review Skill 反而可能放大幻觉。

例如：

• 三轮都使用相同上下文和相同暗示，导致错误结论被重复强化；
• 聚合规则只看标题相似，不看位置和分类；
• 报告渲染时把低置信问题写成确定问题；
• Skill 鼓励模型“尽可能多找问题”；
• 输出 schema 没有证据字段；
• 没有区分主问题和建议。

所以，设计这类 Skill 时必须有几个硬约束。

约束 1：不要鼓励数量

不要写：

尽可能多地找出问题。

应该写：

只报告有明确代码证据或合理工程依据的问题。

数量不是目标，可信度才是目标。

约束 2：不要让模型审自己的报告

模型可以参与审核，但聚合、排序、过滤最好由脚本完成。

如果让模型读三个 agent 的输出，然后自由总结，它可能再次引入幻觉：

• 合并了不该合并的问题；
• 改写时改变严重程度；
• 增加原始输出中没有的结论；
• 删除了重要条件。

脚本化聚合虽然不完美，但更可控。

约束 3：不要把不确定推断写成事实

Skill 应明确要求模型区分：

• diff 中直接可见的问题；
• diff 外可能缺失的配套修改；
• 需要人工确认的上下文问题；
• 单纯建议。

这是降低幻觉感知成本的关键。

约束 4：不要混淆审核和修复

审核 Skill 的主要职责是发现问题，不是自动重写代码。

如果用户要求修复，可以进入修复流程；但审核报告本身应保持克制。

尤其不要在报告里给出大段未经验证的重构方案。

约束 5：不要声称运行过没有运行的验证

这是大模型最常见的不良模式之一。

如果 Skill 没有真实执行测试，就不能写：

测试通过。

只能写：

建议补充测试。

或者：

当前审核未执行测试，仅基于 diff 静态分析。

这个边界必须非常清楚。

---

十、公开资料中的相邻思路

虽然“Multi-Pass Review Skill”本身是一种具体工作流设计，但它背后的思想并不孤立。公开研究和工程讨论中，已经有几类相邻方向。

1. 幻觉不是小概率瑕疵，而是大模型可靠性问题

OpenAI 关于语言模型幻觉的研究文章指出，模型幻觉可以理解为模型在不确定时仍然猜测，并且现有很多评估方式会奖励猜测而不是奖励承认不确定。

这对代码审核很重要。

因为代码审核中最危险的输出，往往不是“我不知道”，而是模型在不知道完整上下文时仍然给出确定结论。

所以，一个审核 Skill 应该允许模型表达不确定，甚至应该奖励它在证据不足时降级问题。

2. 幻觉检测需要关注语义一致性

一些研究尝试通过语义熵等方法检测模型是否在不同回答中表达不一致。这个方向说明了一个关键事实：模型的不确定性常常可以从多次生成之间的差异中暴露出来。

这与 Multi-Pass Review 的思路一致：不要只看一次输出，而要观察多轮结果是否稳定。

3. Self-Consistency 说明“多条推理路径的一致性”有价值

Self-Consistency 是大模型推理中的一个经典思路：不是只取一次推理结果，而是采样多条推理路径，再选择更一致的答案。

代码审核虽然不是数学题，但同样存在类似需求：同一个风险如果能从不同轮次中稳定浮现，它更值得关注。

4. Multi-Agent Debate 说明多实例讨论可以改善事实性和推理

多智能体辩论相关研究尝试让多个模型实例提出观点、互相质疑、再形成最终结论。这类方法说明，单个模型实例的一次回答不是唯一选择。通过结构化互动，可以改善事实性和推理质量。

对于代码审核来说，不一定需要复杂辩论，但可以借鉴它的基本原则：

• 多个独立判断；
• 显式冲突；
• 聚合前保留中间结果；
• 最终结论不是简单照抄某一轮输出。

5. LLM 代码审核研究仍在关注可靠性

近年的自动化代码审核和代码质量修复研究，已经开始系统评估大模型在发现代码问题、修复代码问题、处理静态分析结果方面的表现。

这些研究共同指向一个现实：大模型在软件工程任务上很有潜力，但不能只看“能不能生成答案”，还要看“答案是否可靠、是否可验证、是否能稳定复现”。

这正是 Skill 设计要解决的问题。

---

十一、这类 Skill 的最小实现建议

如果想做一个可用的最小版本，可以只做四件事。

1. 一个 packet 生成脚本

负责把 diff 变成多个审查 packet。

它不需要理解代码语义，只需要稳定处理输入。

2. 一个 issue schema

规定每轮模型必须输出什么。

没有 schema，就没有可靠聚合。

3. 一个聚合脚本

负责合并多轮输出。

初版可以很简单：同文件、近似行号、相同分类，就认为可能是同一问题。

4. 一个报告渲染脚本

把 JSON 转成 Markdown。

报告不应由模型自由改写，避免再次引入幻觉。

这四件事做完，就已经比单轮 Prompt 强很多。

---

十二、这类 Skill 的常见反模式

反模式 1：把 Skill 写成一篇长教程

Skill 不是教程。

它应该告诉模型怎么做，而不是长篇解释代码审核的重要性。

教程可以放在文章里；Skill 里应该保留执行规则、输入输出、约束和脚本入口。

反模式 2：没有脚本，全部靠模型自觉

只靠模型自觉执行多轮审核，结果往往不稳定。

能脚本化的部分应脚本化：解析、拆分、聚合、渲染。

模型负责语义判断，脚本负责流程确定性。

反模式 3：没有输出 schema

没有 schema 的多轮审核无法可靠聚合。

自然语言报告很适合阅读，但不适合作为中间产物。

反模式 4：把所有问题都输出到主报告

这样会让报告噪声很大。

主报告应该服务行动，而不是展示模型“想到了很多”。

反模式 5：复审时只看旧问题

复审不能只验证旧问题是否修复。因为修复本身可能引入新问题。

更好的做法是把旧问题作为回归检查线索，同时仍然对当前材料做完整分析。

注意，这里强调的是复审原则，不是要求文章读者采用某个固定实现细节。

反模式 6：把模型建议当成自动修复

审核和修复是两个阶段。

审核报告应该指出问题和建议方向；真正修改代码时，还需要测试、编译、人工判断和再次审核。

---

十三、为什么这类 Skill 适合团队长期使用

团队最怕的不是工具不够聪明，而是工具不可预测。

一个不可预测的 AI 审核助手，会带来几个问题：

• 每个人问法不同，输出质量不同；
• 同一个改动多次审核结论不同；
• 问题严重程度没有统一标准；
• 报告格式不一致，无法沉淀；
• 误报和建议混在一起，难以执行；
• 模型是否真的看完输入不可确认。

Skill 的价值是把这些隐性差异固化成流程。

它让团队形成统一的审核入口：

给定代码变更
生成审查材料
执行多轮审核
结构化输出问题
聚合共识结果
生成报告
人工处理和复查

当流程稳定之后，团队可以逐步优化：

• 调整严重程度定义；
• 增加新的分类；
• 改进聚合逻辑；
• 接入更多验证步骤；
• 统计常见问题类型；
• 建立修复前后的对比记录。

这就是 Skill 和普通提示词的差别。

普通提示词解决一次对话。

Skill 解决重复工作流。

---

十四、真正目标：不是相信 AI，而是约束 AI

很多关于 AI 编程的讨论，都停留在“AI 能不能替代开发者”。

但在代码审核这个场景，更现实的问题不是替代，而是约束。

我们不应该问：

大模型能不能完全正确地审核代码？

更应该问：

在大模型可能遗漏、可能幻觉、可能不稳定的前提下，怎样设计流程，让它的输出仍然对工程有帮助？

Multi-Pass Review Skill 的意义就在这里。

它承认模型不完美，所以引入多轮。

它承认模型会幻觉，所以要求证据和结构化输出。

它承认单次判断不稳定，所以做聚合。

它承认自然语言报告不可控，所以保留 JSON 和中间产物。

它承认审核不是测试，所以明确边界。

这不是把 AI 神化，而是把 AI 工程化。

---

结语：好的 Skill 是给大模型加工程护栏

大模型代码审核很有价值，但不能只依赖一个漂亮回答。

在真实工程流程中，一个审核结论要能被验证、被复查、被排序、被讨论、被修复。它不能只是模型临时生成的一段自然语言。

因此，我们需要一个 Multi-Pass Review Skill。

不是因为它能让大模型永远正确，而是因为它能让大模型在有限边界内工作：

• 输入有边界；
• 轮次有隔离；
• 输出有 schema；
• 问题有证据；
• 聚合有规则；
• 报告有层级；
• 结论可复查。

这类 Skill 的本质，不是“更强的提示词”，而是“给大模型设计一套工程护栏”。

当我们把大模型用于代码审核时，真正重要的不是让它多说，而是让它少猜；不是让它看起来像专家，而是让它的每个结论都有出处；不是让它一次性给出完美答案，而是让它的输出能进入一个可验证的工程流程。

这就是 Multi-Pass Review Skill 存在的理由。