企业官网建设流程全解析

• 文档
• 提示工程
• 人工智能

导读

/code-review是 Claude Code 内置的代码审查斜杠命令，本文聚焦其high effort（高投入）档位的 Agent Prompt 设计——来自 claude-code-system-prompts 仓库中 agent-prompt-code-review-part-7-high-effort-mode.md 一份真实运行于 Claude Code v2.1.288 的提示词切片。读完本文，你将掌握 high effort 模式的完整审查流水线：8 个独立查找角度并行产出候选、单票召回偏向验证、一次 ReportFindings 调用输出最多 10 条按严重度排序的 JSON 结论，并能对照 low / medium / extra-high / max 档位理解其设计取舍。

一、这份文档在仓库中的位置：模块化拼装的"高投入档位切片"

Claude Code 的系统提示词并非单一字符串，而是大量按环境与配置条件拼接的模块。仓库 README.md 明确说明：这些提示词是从最新 npm 版 Claude Code 的编译产物中直接提取的，与官方实际运行时完全一致。/code-review的提示词被拆成 10 个 part 文件，high effort 档位正是其中的 part 7（README 标注其规模为511 tokens）。

part 7 本身是一个"骨架模板"：文件头的 front matter 声明了 9 个待注入变量，正文通过${VAR}占位符引用兄弟文件中的内容块，运行时由 Claude Code 的主进程完成拼装：

理解了这种拼装机制，就能读懂 part 7 正文为何如此精炼——它只负责定义 high effort 档位的审查哲学、阶段编排与预算约束，具体招式（角度、验证细则、输出契约）由注入的块提供。

二、一图看懂流水线：一行公式浓缩全部流程

part 7 正文第 16 行给出了整个 high effort 模式的浓缩定义：

high effort → 3+5 angles × 6 candidates → 1-vote verify (recall-biased) → ≤10 findings

逐段拆解：

1. 审查目标：recall（召回率）优先。正文开门见山："You are reviewing forrecallat high effort: catch every real bug a careful reviewer would catch in one sitting. At this level, catching real bugs matters more than avoiding false positives. Err on the side of surfacing."（你在以高投入审查召回率：抓住一位细心审查者在一次评审中能抓到的每一个真实 bug。此档位下，抓住真实 bug 比避免误报更重要，宁可多报。）
2. 8 个角度（3+5）：3 个正确性角度 + 3 个清理角度 + 1 个海拔（altitude）角度 + 1 个约定（conventions）角度 = 8 个独立查找角度。
3. 每个角度最多 6 个候选：全流程理论候选池上限为 8×6 = 48 条。
4. 单票召回偏向验证：每条候选由一个验证子代理投出 CONFIRMED / PLAUSIBLE / REFUTED 三态之一，其中 PLAUSIBLE 默认成立，仅 REFUTED 被丢弃。
5. 输出最多 10 条：通过一次 ReportFindings 工具调用提交，按严重度降序。

对比同一仓库中 medium 档位（part 6）的公式：

medium effort → 3+5 angles × 6 candidates → 1-vote verify → ≤8 findings

两者角度配置与候选预算完全相同，差异集中在两点：medium 目标是precision（精确率）（"every finding you surface should be one a maintainer would act on"），因此采用更严格的三态验证；而 high 档位把验证切换到"默认可信"的召回偏向，并把结论上限从 8 提到 10。这正是高投入档位"宁多勿漏"在预算层面的量化体现。

三、Phase 0：收集 diff，划定审查范围

DIFF_GATHERING_PHASE注入的 Phase 0 来自 skill-code-review-phase-0-gather-the-diff.md，是所有档位共用的第一步：

# 有 upstream 时的标准做法：合并 upstream 到 HEAD 的全部改动 git diff @{upstream}...HEAD # 无 upstream 时的回退 git diff main...HEAD # 或审查最近一次提交 git diff HEAD~1

关键细节：

• 未提交改动同样纳入范围：如果存在未提交改动，或范围 diff 为空（审查常常发生在提交之前），需追加git diff HEAD并把工作区改动纳入审查。
• 显式目标优先：如果命令行传入了 PR 编号、分支名或文件路径，则改为审查该目标，而非默认 diff。
• 该 diff 即审查范围的唯一权威依据，后续所有角度都在此范围内作业。

四、Phase 1：8 个独立查找角度，每个最多 6 条候选

part 7 的 Phase 1 标题明确写出角度构成：3 correctness angles + 3 cleanup angles + 1 altitude angle + 1 conventions angle, up to 6 each。执行方式是：通过${AGENT_TOOL_NAME}（即 Claude Code 的 Agent/Task 子代理工具）运行 8 个相互独立的查找代理，每个代理独立产候选，互不干扰；每条候选必须携带四要素：

• file：文件路径
• line：行号
• summary：一行话概括问题
• failure_scenario：具体的失败场景（什么输入/状态 → 什么错误输出或崩溃）

4.1 三个正确性角度（BASE_FINDER_ANGLES_BLOCK）

由 part 1 与 skill-code-review-correctness-finder-angles.md 定义：

Angle A — 逐行 diff 扫描：逐行读取 diff 的每个 hunk，再读取每个 hunk 所在的外层函数——被改函数中未改动的行若有 bug 同样在范围内（因为 PR 重新暴露了它，或本应修复却未修复）。对每一行都追问：什么样的输入、状态、时序或平台会让这一行出错？重点寻找：条件写反/写错、差一错误（off-by-one）、空值/未定义解引用、缺失await、falsy-zero 判断、复制粘贴错变量、catch 中吞掉错误、正则元字符未转义。

Angle B — 被删除行为审计（见 skill-code-review-angle-b-removed-behavior-auditor.md）：对 diff 中每一行被删除或被替换的代码，先说出它原本保证的不变量或行为，再在新代码中寻找该不变量被重新建立的位置。找不到？那就是候选：被移除的守卫、被丢弃的错误路径、被收窄的校验、被删除但确实覆盖了真实场景的测试。

Angle C — 跨文件追踪（见 skill-code-review-angle-c-cross-file-tracer.md）：对 diff 改动的每个函数，用 Grep 找到它的调用方，检查改动是否破坏了调用点的契约——新增的前置条件、改变的返回结构、新增异常、时序/顺序依赖；同时检查被调函数：同一 PR 中的并行改动是否让某个调用变得不安全。

4.2 三个清理角度（cleanup）

清理角度承接 agent-prompt-simplify-slash-command.md 中定义的 reuse / simplification / efficiency 三类问题（altitude 在 code-review 中被单列）：

• Reuse（复用）：新代码重复了 diff 上下文中可见的既有 helper，或本可复用的实现被复制粘贴。
• Simplification（简化）：存在更简单、更易维护的等价写法。
• Efficiency（效率）：按 skill-code-review-efficiency-dimension.md，标记 diff 引入的浪费——冗余计算或重复 I/O、本可并行的操作被串行执行、启动路径或热路径上新增阻塞工作；以及由闭包或捕获环境构造的长生命周期对象（对象存活期间整个外层作用域无法释放，若作用域持有大值即内存泄漏），应改为只拷贝所需字段的 class/struct。每个效率候选须指出更省成本的替代方案。

4.3 海拔（altitude）角度

检查改动所处抽象层级是否恰当——在错误的层级做了本应在更合适位置做的事（例如把领域逻辑塞进 UI 层、或把通用能力写进一次性调用处）。它与清理角度共同构成CLEANUP_AND_ALTITUDE_CANDIDATES_NOTE注入块的内容。

4.4 约定（conventions）角度：以 CLAUDE.md 为规则源

按 skill-code-review-conventions-dimension.md，此角度只审查"被改动代码受其管辖"的 CLAUDE.md：

• 用户级~/.claude/CLAUDE.md、仓库根目录CLAUDE.md，以及改动文件所有祖先目录中的CLAUDE.md/CLAUDE.local.md（一个目录的 CLAUDE.md 只适用于该目录及以下文件）。
• 只允许在能同时引用出"确切规则原文"与"违规行原文"时标记违规——不查风格偏好，不做"文档精神"式的模糊推断；结论中必须给出 CLAUDE.md 路径并引用规则原文，便于报告引用。
• 若没有适用的 CLAUDE.md，该角度返回空结果。

4.5 候选纪律：有名字的失败场景必须放行

part 7 正文对 Phase 1 提出了最关键的纪律要求：

Pass every candidate with a nameable failure scenario through — finders that silently drop half-believed candidates bypass the verify step and are the dominant cause of misses.

（让每一个具有可命名失败场景的候选通过——那些悄悄丢弃"半信半疑"候选的查找器绕过了验证步骤，而这正是漏报的主因。）

这条规则直接服务于 recall 目标：查找阶段宁可让"半信半疑"的候选进入验证阶段，也绝不在源头静默丢弃——因为验证阶段有专门的回召偏向规则兜底，而源头丢弃则直接造成漏报。

五、Phase 2：单票召回偏向验证（1-vote, recall-biased）

Phase 2 的注入块来自 agent-prompt-code-review-part-5-recall-biased-verification-phase.md，执行流程由 skill-code-review-phase-2-verify-recall-biased.md 定义：

1. 先去重：合并近重复候选（同一缺陷、同一位置、同一原因 → 保留一条）。
2. 每候选一个验证子代理：通过 Agent 工具把 diff、相关文件和候选交给验证者，验证者必须且只能返回CONFIRMED / PLAUSIBLE / REFUTED三态之一。
3. 保留 CONFIRMED 与 PLAUSIBLE，丢弃 REFUTED。

5.1 PLAUSIBLE 默认成立：别用"太投机"当借口

召回偏向规则的核心是给不确定性定了一个"默认放行"的基调：

PLAUSIBLE by default— do not refute a candidate for being "speculative" or "depends on runtime state" when the state is realistic.

（默认视为 PLAUSIBLE——当候选所依赖的运行时状态是现实存在时，不得以"太投机"或"依赖运行时状态"为由反驳它。）

part 5 明确列举了这些"现实存在"的典型情形：

• 并发竞态（concurrency races）；
• 在少见但可达路径上的空值/未定义（错误处理器、冷缓存、缺失的可选字段）；
• falsy-zero 被当作"缺失"处理；
• 代码并未排除的边界上的差一错误；
• 重试风暴 / 部分失败；
• 丢了锚点的正则或白名单。

这些场景意味着验证者不能以"也许不会发生"为由否决候选——这正是 high effort 与 medium 档位在验证哲学上的分水岭。

5.2 REFUTED 的四种"从代码可构造"情形

作为对照，part 5 规定只有以下四种情况才允许给出 REFUTED，且每条都必须从代码本身可构造、可引用：

注意与 三态验证（part 4） 的差异：part 4 的 CONFIRMED 要求"能说出触发它的输入/状态以及错误输出或崩溃，并引用该行"，PLAUSIBLE 要求"机制真实、触发不确定（时序、环境、配置），并说明什么能确认它"——这是 medium（precision）档位的更严口径；而 high 档位的 part 5 把"机制真实"放宽为"默认成立"，使更多不确定候选得以存活。

六、输出：一次 ReportFindings，最多 10 条按严重度排序的结论

输出契约由OUTPUT_FORMAT_FN(MAX_FINDINGS)注入，来自 agent-prompt-code-review-part-10-reportfindings-output-format.md。high effort 档位的MAX_FINDINGS为10（README 与 part 7 文件头描述均为"up to ten JSON findings"）。

6.1 调用方式

审查结束时，只调用一次ReportFindings 工具，携带{level, findings}；findings是最多 10 条、按严重度降序的数组。两点硬性约束：

• 验证后存活超过 10 条时，只保留最严重的 10 条；
• 一条都没存活时，以空数组调用；
• 不得再以文本形式打印结论，不得创建或发布审查 artifact——工具调用本身就是报告（这与 tool-description-report-code-review-findings.md 的描述一致）。

6.2 每条结论的字段

category的标准取值包括：correctness、simplification、efficiency、reuse、altitude、conventions，或更具体的标签（如test-coverage）。

一个符合契约的结论条目示意（字段结构来自上述文档）：

{ "file": "path/to/file.ext", "line": 123, "summary": "错误处理分支中解引用可能为空的对象", "short_summary": "错误路径空指针解引用", "failure_scenario": "上游返回错误且 payload 缺失时 → 直接崩溃而非返回错误", "category": "correctness", "verdict": "CONFIRMED" }

七、high effort 在 /code-review 努力档位矩阵中的定位

/code-review命令本身（见 tool-description-code-review-command.md）支持多档努力水平："从少数高置信结论到许多（部分不确定）结论"；不传档位时复用你上一次输入的档位。结合本文与仓库中各档位文档，可得到完整对照：

extra-high/max 档位（part 3）在 high 的基础上再进一步：正确性角度从 3 个扩到 5 个（新增Angle D 语言陷阱专家与Angle E 包装器/代理正确性，见 skill-code-review-angle-d-language-pitfall-specialist.md 与 skill-code-review-angle-e-wrapper-proxy-correctness.md），候选上限从 6 提到 8，并追加gap sweep（skill-code-review-phase-3-sweep-for-gaps.md：以全新审查者身份重读 diff，只找尚未列出的缺陷，最多再补 8 条，不硬凑）。由此可见 high effort 处于"8 角度全覆盖 + 宽容验证"的中坚位置：角度覆盖与 medium 相同，验证口径与 extra-high 同向，是"一次坐下来仔细审查能抓到的所有真实 bug"的落点。

八、实战配套：--comment 与 --fix，以及 Agent 不可用时的内联降级

high effort 模式产出的结论列表，还可以被命令开关进一步加工：

• --comment（PR 评论模式）：若审查目标是 GitHub PR，逐条把结论发为行内 PR 评论（每条一次mcp__github_inline_comment__create_inline_comment调用，仅当建议块能完整修复问题时才附建议块；工具不可用时回退gh api）；目标是 GitLab MR 时则以一条glab mr note汇总评论（见 part 8 GitHub 与 GitLab 评论）。非 PR 目标则打印结论并注明--comment被忽略。
• --fix（修复模式）：产出结论列表后直接修改工作区——正确性 bug 与 reuse/simplification/efficiency 清理一并修复；跳过会导致行为改变、超出 diff 范围或判定为误报的条目，并逐条说明跳过原因（见 part 9）。
• --max-findings <n>/--max-findings all：覆盖结论上限；设置会持续生效，直到显式传--max-findings default。
• Agent 不可用时的内联降级：若会话中没有 Agent 工具，AGENT_UNAVAILABLE_INSTRUCTIONS会切换为内联模式——在当前上下文中按顺序自行跑完各角度（不派子代理）、仅去重并自查、可选做 gap sweep，同样以{level, findings}上报；内联 medium/high 模板见 skill-code-review-inline-medium-high-template.md，其 Phase 2 为"仅去重、不验证、不重新评判"。

九、延伸阅读：仓库中的相关文件导航

如需把 high effort 模式的每一块拼图读全，可按下列相对路径继续深入：

• 档位本体：agent-prompt-code-review-part-7-high-effort-mode.md（511 tokens）
• 注入块：part 1 基础角度、part 4 三态验证、part 5 召回偏向验证、part 10 输出格式
• 档位对照：part 2 low、part 6 medium、part 3 extra-high/max、minimal mode
• 技能化实现：Phase 0 收集 diff、召回偏向验证、三态验证、gap sweep、角度 A–E、conventions 维度、efficiency 维度
• 命令与工具契约：code-review 命令说明、ReportFindings 工具

总的来说，high effort 档位是 Claude Code 在"召回率"与"成本"之间找到的平衡点：用 8 个互不干扰的角度把候选池铺满，再用"默认可信、证据反驳"的单票验证最大限度保留真实缺陷，最后以 ≤10 条、按严重度排序的结构化结论交付给宿主 UI 渲染。理解这份提示词的拼装方式与验证哲学，也能帮助你为自己的审查类 Agent 设计类似的"多角度查找 + 宽容验证 + 结构化上报"流水线。

• 文档
• 提示工程
• 人工智能