devAlice
← AI Agents

Prompt 模板 — 复用你每天都在做的 AI 任务

不要每次从头给 AI 打简报 — 代码审查、调试、重构、测试、文档模板。

使用 AI 代理一周后，你每天都会重复相同类型的请求 — 「审查这段代码」、「追踪这个 bug」、「写测试」。与其每次重新描述上下文，不如使用可复用的 prompt 模板来节省时间、提高一致性并改善输出质量。

我认为模板的价值不在于节省打字，而在于固化判断。以前每次从空白 prompt 开始，输出质量随心智状态波动；如今通过结构化模板，所谓的「上下文 + 任务 + 格式 + 约束」四要素成为稳定的信号，因为那四要素才是决定输出质量的真正变量。

本指南涵盖五个日常模板（代码审查、调试、重构、测试、文档）及其存储方式。

TL;DR

  1. 模板 = 上下文 + 任务 + 输出格式 + 约束
  2. 存储：~/.prompts/ 或 chezmoi 管理
  3. 宏工具：Raycast Snippets、Cursor @docs、Claude Code slash command
  4. 好模板的四要素：角色 / 输入 / 输出格式 / 禁止事项

1. 好 Prompt 的四要素

占位符用 [...] 表示（避免 MDX/JSX 冲突）。

You are a [role].

Context: [context]

Task: [what to do]

Output format: [how to respond]

Constraints:

  • [prohibition 1]
  • [prohibition 2]

四个清晰的部分帮助模型区分「需要处理什么」和「需要跳过什么」。

2. 模板 1 — 代码审查

You are a senior code reviewer for [language] projects.

Context:

  • Code under review: [paste code or @file]
  • Project conventions: [link or paste relevant style guide / .cursorrules]
  • Reviewer focus: [correctness | security | performance | readability]

Task: Review the code. Identify:

  1. Bugs or logic errors (severity: critical / major / minor)
  2. Security issues (input validation, secrets, auth)
  3. Performance concerns (only if obvious O(n^2) or memory)
  4. Style violations against project conventions
  5. Suggestions for clarity

Output format: SUMMARY: [one-paragraph overall verdict] [CRITICAL] (line N): [issue] -> [fix] [MAJOR] ... [MINOR] ... [STYLE] ... [SUGGESTION] ...

Constraints:

  • Do not rewrite the entire file. Point and suggest.
  • Do not nitpick style if .cursorrules don't enforce it.
  • If no issues found at a level, omit that section.

使用方法

Cursor 侧边聊天 — @code-review.md + @src/auth/login.ts + focus: security。

Claude Code：将模板保存至 .claude/commands/review.md，通过 /review src/auth/login.ts 调用。

3. 模板 2 — Bug 调试

You are a debugging assistant.

Context:

  • Error message: [paste full stacktrace]
  • Code where it occurs: [paste minimal repro or @file]
  • What I tried: [hypotheses ruled out]
  • Expected behavior: [what should happen]

Task:

  1. Identify the most likely root cause (not just symptoms)
  2. Suggest a fix
  3. Suggest a test to prevent regression

Output format: ROOT CAUSE: [one sentence] EXPLANATION: [2-3 paragraphs of why] FIX: [patched code] REGRESSION TEST: [test code]

Constraints:

  • Do not guess. If you need more info (logs, full file), ask.
  • If 2+ hypotheses are equally likely, present both with discriminating signals.
  • Do not just say "try X" — explain the model.

「我尝试过的」这一字段至关重要 — 防止模型重新推荐你已经排除过的方案。

4. 模板 3 — 重构

You are a refactoring assistant for [language].

Context:

  • Current code: [paste or @file]
  • Pain point: [readability | duplication | testability | performance]
  • Constraints:
    • Must preserve public API
    • Must not break existing tests

Task: Refactor while preserving behavior. Show:

  1. The refactored code
  2. Diff vs original
  3. Tradeoffs of this approach vs at most 1 alternative

Output format: REFACTOR: [new code] DIFF:

  • Removed: [what]
  • Added: [what]
  • Renamed: [old -> new] TRADEOFF: [this approach]: [pros/cons] [alternative]: [pros/cons] RECOMMENDATION: [which and why]

Constraints:

  • Do not change behavior. If you think behavior should change, flag it separately.
  • Keep test compatibility — show how existing tests still pass.
  • Don't introduce new dependencies without explicit ask.

5. 模板 4 — 测试编写

You are a test writer for [language] (Vitest, Jest, Pytest, etc.).

Context:

  • Code to test: [paste or @file]
  • Existing test style: [paste sample test or @file]
  • Coverage focus: [happy path | edge cases | failure modes | all]

Task: Write tests that:

  1. Cover the happy path
  2. Cover at least 3 edge cases (boundary values, empty input, error cases)
  3. Are deterministic (no flaky time/network without mock)
  4. Follow the existing test style

Output format: a single test file in [language].

Constraints:

  • Use the same assertion library as existing tests
  • Mock external dependencies (don't hit real network/DB)
  • Keep each test focused (one assertion topic per test)
  • Name tests descriptively: "returns X when Y"
  • Do NOT write tests that just mirror implementation. Test behavior.

6. 模板 5 — 文档

You are a technical writer.

Context:

  • Code: [paste or @file]
  • Audience: [beginner | intermediate | expert]
  • Doc type: [README section | JSDoc | tutorial | reference]

Task: Write documentation that:

  1. States the purpose in 1 sentence
  2. Shows minimal usage example
  3. Lists parameters/returns with types
  4. Notes edge cases or gotchas (if any)

Output format: markdown or specific JSDoc/TypeDoc format.

Constraints:

  • No filler. Be direct.
  • Code examples must be runnable / pasteable
  • If the API is complex, link to deeper reference rather than dumping
  • For library/framework specifics, prefer official terminology

7. 存储 / 管理

方案 A — Claude Code slash command

将模板保存至 ~/.claude/commands/review.md。CLI 中 /review src/foo.ts 即可自动注入 system prompt。

方案 B — Cursor @docs

Cursor → Settings → Features → Docs → Add → URL/本地路径。聊天中：@my-review-template。

方案 C — Raycast Snippets

通过 mac/productivity 的 Raycast Snippets：

  • 添加 Snippet：粘贴完整模板
  • 关键词：!review
  • 任意文本框中，!review → 展开

方案 D — 简单目录 + 别名

将每个模板保存为 ~/.prompts/ 中的 .md 文件。.zshrc：

alias prompt='ls ~/.prompts'

prompt → 列表 → cat ~/.prompts/review.md | pbcopy → 粘贴到任何地方。

chezmoi 集成

将 ~/.prompts/ 加入你的 dotfiles chezmoi 树。在任何新机器上立即可用。

8. 模板演进

第一版模板质量约为 70%，随着使用逐步改进：

  1. 结果经常太长 → 添加「不超过 N 行」或「只输出 diff」约束
  2. AI 频繁偏离主题 → 加强约束（写出具体的禁止事项）
  3. 上下文不足 → 添加显式输入槽，如「我尝试过的」
  4. 输出格式不稳定 → 在输出格式区展示一个具体示例
  5. 结果过于保守 → 「推荐最优选项，不要罗列所有选项」

每次演进时写一行备忘。一年积累下来，这些模式会沉淀为宝贵资产。

9. 反模式

指令过于抽象

不好：「当一个好的代码审查者。」 好：「你是高级审查者。识别 bug / 安全 / 风格问题。按格式 X 输出。」

目标模糊

不好：「把这个做得更好。」 好：「让这个更易读。不改变行为。展示 diff。」

缺少输出格式

每个模型产生的输出结构各异；缺少格式规范会影响结果对比和自动化处理。

约束堆砌过多（「保险」思维）

「还要 X。也许 Y。别忘了 Z。」→ 模型会失去优先级判断。保留 3–5 个关键约束即可。

总是用中文写 prompt

在英文代码库上用中文 prompt 会降低 token 效率。代码上下文为英文时，英文 prompt 效果更好。

验证

  1. 用同一段代码分别用有模板和没模板审查 — 对比一致性 / 完整性
  2. 在新机器上应用 chezmoi → ~/.prompts/ 立即可用
  3. Raycast !review 触发器 → 在任何地方展开
  4. Claude Code /review file.ts → 相同的响应形状
  5. 使用一周后，每周演进一个模板（一行笔记）

故障排查

AI 忽略模板

  • 长模板会让模型在中途忘记指令。保持在 200 行以内
  • 在末尾重申最重要的约束（近因偏见）
  • Cursor @docs 可能会压缩上下文 — 提取关键内容

slash command 不工作

  • Claude Code：文件名/位置需在 ~/.claude/commands/foo.md
  • Cursor：slash command 的可用性取决于所选模型

输出格式损坏

展示一个明确的格式示例。「使用这个精确格式：」或类似的强烈措辞。

答案太长

「最多 N 行。」或「只要 diff，不要解释。」

语言混乱

同时说明 prompt 语言和输出语言。「用中文回答。」或「Respond in English.」

参考资料

更新日志

  • 2026-05-12：初稿。五个模板 + 四种存储方案 + 演进 + 五个反模式 + 五个故障排查案例。