全仓审查不是”告诉我哪里不好”——这种 prompt 只会得到泛泛建议。好的审查 Prompt 必须先列维度(架构、安全、测试覆盖、依赖、性能、文档),强制要求证据(file:line),并约束输出格式(markdown 表格或带 severity 的编号清单)。下面 15 个模板覆盖你仓库真实需要的审查角度,模型版本信息更新至 2026 年 6 月。
一句话总结
- 一个维度开一个对话——把架构、安全、性能塞进一个 prompt,每条结论都会被互相稀释。
- 永远要
file:line证据。没有定位字符串,就当作幻觉处理。 - 整仓阅读现在真的可行了:Claude Opus 4.7 和 Sonnet 4.6 都是 1M token 上下文(2026 年 3 月正式可用,且不再加收长上下文溢价),Claude Code 一次能装下成千上万个源文件;Codex 跑 GPT-5.5,约 400K token。
- 安全审查可以先用 Claude Code 自带的
/security-review命令(终端 + GitHub Action),再用模板 6 扩展,而不是替代它。 - 每次审查最后都跑模板 15,让结论变成 ticket,而不是一份只读文档。
哪个工具能读整个仓库(截至 2026 年 6 月)
| 工具 | 默认模型 | 上下文窗口 | 读仓库的方式 |
|---|---|---|---|
| Claude Code | Opus 4.7 / Sonnet 4.6 | 1M token(正式版) | Read/Grep/Glob 由 agent 自己挑文件,可派多个并行 review 子代理 |
| Codex CLI / 云端 | GPT-5.5 | 约 400K token | 克隆仓库进沙箱,对整棵树 + 依赖推理,并能跑测试 |
| Cursor(Agent) | Sonnet 4.6 / GPT-5.5 / Gemini 3.1 Pro | 取决于模型 | 交互式;索引工作区,你实时确认改动 |
| Gemini(AI Pro/Ultra) | Gemini 3.1 Pro | 1M token | 粘贴或连接仓库,长单文件推理强 |
只读审查最省事的是 Claude Code,因为 agent 自己抓文件,你什么都不用粘贴。Codex 适合你还想让它跑测试套件来验证结论的场景。运行循环看Claude Code 执行 Prompt,diff 级别的审查看代码审查 Prompt。
适合哪些场景
正在接手陌生代码库的资深工程师、上线前做硬化审查的技术负责人、准备尽调材料的创业团队、季度做技术债 review 的独立开发者。
什么时候不建议这样写 Prompt
小脚本(不到 500 行)别用——成本大于收益。也别把闭源仓贴进公网 chat,应该用私有部署(见 FAQ)。
Prompt 结构公式
全仓审查 Prompt 一定要带这六个要素:
- 角色:让 AI 扮演谁(资深 reviewer / SRE / staff 工程师)。
- 上下文:仓库 / 框架 / 运行时版本 / 涉及哪些文件。
- 目标:一个具体可交付物——review 笔记、diff、计划、checklist。
- 限制:AI 不能做什么(别动 X、别静默改名、别自动 format)。
- 输出格式:编号清单、markdown 表格、JSON、unified diff。
- 示例 / 信号:1-2 条”好输出”示例,或者说明什么是糟糕输出。
这套 Prompt 适合用在哪
- 上线前硬化扫描
- 接手陌生代码库的入职审查
- 季度技术债 review
- 尽调材料准备
- 大重构前的基线评估
15 个可直接复制的 Prompt 模板
1. 仓库整体健康度快照
第一次打开陌生仓库时用。
You are a staff engineer doing a 30-minute audit of this repository. Produce a 1-page report with these sections: (1) Stack & framework summary in 3 sentences, (2) Three architecture smells you can spot with evidence (file:line), (3) Three security risks (auth / data / secret handling), (4) Test coverage signal (yes/no per top-level dir), (5) Top 5 follow-ups ranked by impact / effort. Do not propose rewrites — only diagnose.
可替换变量: 仓库文件(Claude Code 自动读)——其他对话工具需手动粘贴
优化建议: 如果模型一上来就想动手改,加一句:“Skip implementations. We are mapping the territory, not refactoring.”
2. 仅架构 audit
Audit this repo for ARCHITECTURE only. Ignore style / naming. Report: (1) Top 3 layering violations with file:line, (2) Modules with > 5 incoming deps (god-objects), (3) Any "data flow surprise" where state mutates across module boundaries, (4) One paragraph: "If I had to redraw the boxes-and-arrows, here is the cleaner version."
3. 依赖漂移 audit
Read package.json (and lockfile if present). Report: (1) Direct deps that are > 2 major versions behind latest, (2) Any deprecated / abandoned packages, (3) Duplicate logical deps (e.g., axios + fetch wrapper + got), (4) Native bindings or post-install scripts that warrant attention, (5) Upgrade roadmap: which to bump now / next sprint / never.
优化建议: 再追一句:“Mark any of these that have known CVEs against the version we pin.” 要确认 CVE 是否真实匹配,到 GitHub Advisory Database 复核——模型对精确 CVE 编号的记忆并不可靠。
4. 死代码 / 孤儿代码
Find dead and orphaned code: (1) exported functions / components that are never imported, (2) routes / pages that are unreachable from the main router, (3) env vars referenced in code but never set, (4) feature flags that have been "on" for > 6 months. Return a table: kind | path | evidence | safe to delete? (yes/no/maybe).
5. 测试覆盖定性 audit
Don't run coverage tools. Instead, do a qualitative test audit: (1) Which critical paths have ZERO tests? Name them, (2) Which existing tests are tautological (testing mocks of mocks)? File:line, (3) Where is the test pyramid inverted (too many e2e, too few unit)? (4) Suggest 5 highest-ROI tests to write next.
6. 安全风险 audit
Audit only for SECURITY: (1) Unvalidated user input reaching DB / shell / template / fetch, (2) Secrets in code or in .env.example, (3) AuthN/AuthZ gaps — any route lacking auth middleware? Any role check missing? (4) Logging that leaks PII / tokens, (5) CORS / CSRF posture. For each finding: file:line, severity (Critical / High / Med), one-line fix sketch.
优化建议: 在 Claude Code 里先跑自带的 /security-review 命令(2026 年 3 月起内置,覆盖 SQL 注入、XSS、认证缺陷、不安全数据处理),再用这个模板把范围扩到默认命令权重不足的日志泄露和 CORS/CSRF。
7. 性能热点 audit
Audit for PERFORMANCE without running benchmarks. Find: (1) N+1 patterns in DB calls (file:line), (2) Synchronous I/O in hot paths, (3) Missing caches where the same fetch repeats across requests, (4) Bundle bloat suspects (large deps imported eagerly), (5) Re-render storms (React only): components missing memo / unstable deps in useEffect / context churn.
8. 文档 audit
Audit project docs: (1) Does README explain "what + why" or just commands? (2) Is the run-locally path actually current? (3) Are public functions / exported types missing TSDoc / docstrings? List 10 worst offenders, (4) Are env vars documented? (5) Suggest 5 doc sections that would make onboarding 50% faster.
9. 类型安全 audit
Audit for type-safety: (1) Count `any` / `as unknown as` / `// @ts-ignore` (or Python `# type: ignore`), (2) List API boundary types that come from `any`, (3) Functions with > 4 args missing a typed args-object, (4) Type definitions duplicated across the repo. Return file:line evidence.
10. 错误处理 audit
Audit ERROR HANDLING only: (1) try/catch blocks that swallow errors silently, (2) `catch (e) {}` empty handlers, (3) Promise chains missing `.catch`, (4) API routes that 500 instead of returning typed errors, (5) Background jobs lacking retry / dead-letter. Each finding: file:line + one-line fix sketch.
11. 数据库与 schema audit
Audit DB code: (1) Tables without explicit indexes on FKs, (2) Migrations that drop / rename columns without backfill, (3) ORM `.findAll()` without limits, (4) Transactions missing for multi-row writes, (5) Soft-delete columns referenced unevenly. Return findings with file:line and severity.
12. 日志与可观测性 audit
Audit OBSERVABILITY: (1) Any service-critical path with zero logs? Name it, (2) Logs that include PII or secrets, (3) Inconsistent log shape (some JSON, some console.log), (4) Metrics / counters missing on auth-fail / payment-fail / external-API calls, (5) Trace propagation gaps. Suggest the 5 highest-ROI log/metric additions.
13. 构建与工具链 audit
Audit BUILD / TOOLING: (1) Steps that take > 60s and can be cached, (2) Lint config inconsistencies between root and packages, (3) CI jobs that never fail (warning-only that should be error), (4) Pre-commit hooks that are skipped via --no-verify in scripts, (5) Node / Python / Go version mismatch between local / CI / Docker.
14. 跨语言仓库 audit
This repo mixes [languages]. Audit cross-language boundaries: (1) Where do TS / Python (or whichever pair) types diverge? List schemas, (2) Are message contracts versioned? (3) JSON keys casing inconsistencies (camelCase vs snake_case)? (4) Build-order dependencies between sub-packages.
可替换变量: [languages] —— 例如 “Next.js + Python FastAPI + Go workers”
15. 审查发现 → 行动 ticket 列表
最后跑;把发现转成 ticket。
Take all audit findings above and turn them into a prioritized ticket list. For each: (1) Title, (2) One-paragraph description, (3) Acceptance criteria (3 bullets), (4) Estimated effort (S / M / L), (5) Risk if not done. Group by: Now (this sprint) / Next (next quarter) / Later. Output as markdown table.
容易踩的坑
- 上来就问”哪里不好”——不列维度,输出就是空话。
- 没限定输出格式——拿到大段散文而不是 triage 清单。
- 让 AI 一边 audit 一边改写——诊断清晰度立刻丢失。
- 没有 severity 分级——所有问题看起来一样紧急。
- 没要求
file:line证据——没法验证。 - 一次 prompt 跑所有维度——结论会互相稀释。
- 改一条就重跑审查——应该批量修完再重审。
优化技巧
- 按维度分线程——架构 / 安全 / 性能各开一个对话,别合并。
- 永远要
file:line证据,没有就是幻觉。 - 在 prompt 里加 severity 枚举(Critical / High / Med / Low),强制排序。
- 长仓库先让 AI 列出”它认为有风险的目录”,再针对性 audit,能去噪。
- 用 Claude Code 的
Read工具,比手动粘贴文件更准;1M token 下它能一次装下整棵树。 - 在 Claude Code Team/Enterprise 上,基于 agent 的 PR review(2026 年 4 月推出,研究预览)会派出并行 reviewer 并验证结论以减少误报——把你的审查维度写进它的配置。
- 把审查结果保存成
/docs/audits/2026-05-18.md,下次能 diff。 - 架构 audit 之后追问:“给 PM 用 8 句话总结。” 检验输出清晰度。
FAQ
- 每个 PR 都跑一遍?: 不要——噪音太大。季度 / 上线前 / 接手代码 / 大重构前跑即可。逐 PR 的检查交给 Claude Code 的
/security-review和基于 agent 的 PR reviewer。 - AI 会漏吗?: 会。当作 80% 看:再配合依赖 CVE 扫描、lint 规则、人工 review 至少一遍。
- 闭源仓能用吗?: 只能用私有部署——Claude Code 走自有云 / VPC、Codex 在私有 org 的沙箱里、或通过 AWS Bedrock / Google Vertex 调模型。别贴公网 chat。
- 一次审查要多久?: 5 万行仓库:跑约 30 分钟,triage 1-2 小时。用 1M 上下文的 Claude Code 直接读树,跑的阶段更快,但 triage 时间几乎不变。
- 要最深的审查该选哪个模型?: 截至 2026 年 6 月,硬核代码推理 Opus 4.7 领先(SWE-bench Verified 87.6%、SWE-bench Pro 64.3%);想让 agent 在沙箱里跑测试时 GPT-5.5 很强(Pro 58.6%)。批量低成本扫描用 Sonnet 4.6。
- 审查结论和我的架构决策冲突?: 标
out-of-scope而不是忽略——写明原因,下次 audit 不会重复 flag。 - 怎么让审查不变成只读文档?: 一定要跑模板 15(行动 ticket 转换)。
相关阅读
- 代码审查 Prompt
- Bug 审计 Prompt
- 安全审计 Prompt
- Claude Code 执行 Prompt
- 架构审查 Prompt:分层与依赖审计模板
- Build 失败排查 Prompt:12 个红 CI 调查模板
- CI/CD 流水线审计 Prompt:又快又可信模板
- 代码约定识别 Prompt:12 个读懂陌生仓库的模板
- 多 Agent 交接 Prompt:Claude Code 子代理模板
- Next.js App Router 审查 Prompt:服务端组件模板
- 性能回归审计 Prompt:12 个 p99 急救模板
- 编程开发 Prompt 总目录
标签: #Prompt #编程 #代码审查 #审计 #Claude Code