全项目审查 Prompt:15 个让 Claude Code 帮你扫整个仓库的模板

全仓库审查 Prompt——架构 / 安全 / 测试覆盖 / 依赖漂移 / 性能热点 / 文档,每个维度独立模板,附 file:line 证据要求,适配 Claude Code、Codex、Cursor。

全仓审查不是”告诉我哪里不好”——这种 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 CodeOpus 4.7 / Sonnet 4.61M 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 Pro1M 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 #编程 #代码审查 #审计 #Claude Code