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

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

发布于: 2026/05/18 作者: AI Productivity Guide Team 🌐 查看英文版本

全仓审查不是”告诉我哪里不好”——这种 prompt 只会得到泛泛建议。好的审查 Prompt 必须先列维度（架构、安全、测试覆盖、依赖、性能、文档），强制要求证据（file:line），并约束输出格式（markdown 表格或带 severity 的编号清单）。下面 15 个模板覆盖你仓库真实需要的审查角度。

适合哪些场景

正在接手陌生代码库的资深工程师、上线前做硬化审查的技术负责人、准备尽调材料的创业团队、季度做技术债 review 的独立开发者。

什么时候不建议这样写 Prompt

小脚本（< 500 行）别用——成本大于收益。也不要在不能共享上下文的闭源仓上用公网模型。

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.”

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.

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 ↔ 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 工具，比手动粘贴文件更准。
把审查结果保存成 /docs/audits/2026-05-18.md，下次能 diff。
架构 audit 之后追问：“给 PM 用 8 句话总结。” 检验输出清晰度。

FAQ

每个 PR 都跑一遍？: 不要——噪音太大。季度 / 上线前 / 接手代码 / 大重构前跑即可。
AI 会漏吗？: 会。当作 80% 看：再配合依赖 CVE 扫描、lint 规则、人工 review 至少一遍。
闭源仓能用吗？: 只能用 on-prem / 私有部署（Claude Code 走 VPC、Codex on-prem、Bedrock）。别贴公网 chat。
一次审查要多久？: 5 万行仓库：跑 30 分钟，triage 1-2 小时。维度拆开会更快。
审查结论和我的架构决策冲突？: 标 out-of-scope 而不是忽略——写明原因，下次 audit 不会重复 flag。
怎么让审查不变成只读文档？: 一定要跑模板 15（行动 ticket 转换）。