Claude Code 提示词指南：从工程实战中提炼的可复用模板
我维护 OpenClaw 期间，每天有几十次和 Claude Code 互动。一年下来积累出一套自己用得最顺手的 prompt 模板。这篇就是那套模板，按真实开发流程组织，拿去就能用。
拼车前置：如果你还没接通 Claude Code 大额配额，下面所有 prompt 都得先有底层模型跑得起。一行命令搞定：
curl -fsSL https://cp.bizq.net/setup.sh | bash -s -- claude-max-20x跑通之后再谈 prompt 才有意义——否则配额一限速，再好的提示词也会被截断。
写好 prompt 的三个内核
不啰嗦，先说三件事：
- 先读再写——任何复杂任务，先让模型把代码读完、把意图说回来，再开干。模型瞎写代码 90% 的原因是没读项目。
- 设硬边界——明确告诉它「不要做什么」。“暂时不要写代码”、“只输出修改 diff，不要重写整个文件”。
- 分阶段确认——多步任务每完成一步暂停，避免一口气滑出 1000 行你不想要的代码。
下面所有模板都内置了这三条。
项目初始化
刚 clone 一个陌生仓库，第一句别让它写代码，让它建立心智模型：
请阅读项目根目录的 README.md、package.json（或 pyproject.toml / Cargo.toml）、
以及 src/ 一级目录结构，给我一个 200 字以内的项目摘要，包括：
1. 这是什么项目
2. 用了什么技术栈
3. 入口文件在哪
4. 有哪些核心模块
请暂时不要写任何代码，也不要修改任何文件。随后建立项目级约束文件：
基于你刚才对项目的理解，请生成 CLAUDE.md，写入项目根目录。需要包含：
- 项目架构简述
- 常用 npm / make 命令
- 代码规范（缩进、命名、文件组织）
- 你写代码时必须遵守的项目约定（例如「不要在业务层直接调 fetch」）
不要超过 100 行。CLAUDE.md 是 Claude Code 的「项目记忆」，一次写好，后续每次对话都自动注入。
功能开发：分阶段实现
直接说「帮我写一个登录功能」是最低效的方式。改成五步法：
我需要实现 [功能描述]。请按以下顺序执行，每一步完成后暂停等我确认：
第 1 步：阅读现有相关代码（@src/auth、@src/api），告诉我会涉及哪些文件
第 2 步：列出实现计划（步骤 + 影响范围 + 风险点）
第 3 步：实现核心逻辑
第 4 步：补齐测试
第 5 步：更新 CLAUDE.md / README
每步完成后输出"--- 步骤 N 完成，等待确认 ---"，等我说"继续"再往下走。这种节奏感的 prompt，一个晚上能稳定推进 2-3 个中等功能，比放任它一口气写出来再人肉 review 快得多。
测试驱动开发
我要实现 [功能]。请走 TDD 流程：
1. 基于我描述的输入输出，先写失败的测试用例（确认测试能跑、确认它失败）
2. 再写实现代码让测试通过
3. 重构（如有必要）
全程不要跳步。这条对 Claude 特别有效——它天生倾向于先写实现再凑测试，强制 TDD 反而能逼出更干净的接口。
调试与错误诊断
报错日志直接贴进去，加一段约束：
错误信息：
[贴报错日志]
请按以下顺序排查：
1. 定位错误发生的文件和行号
2. 解释这个错误的根本原因（不是表面症状）
3. 提供 2-3 种可能的修复方案，按推荐度排序
4. 暂时不要直接改代码，等我选定方案「2-3 种方案」这个细节很关键。Claude 默认只给一种解法，但 debug 场景下经常第一种是治标不治本。
代码重构
重构是最容易翻车的场景——模型改完之后行为可能微妙变化，但单测又恰好不覆盖。我用这个模板：
请重构 [文件名] 中的 [函数/类]。约束如下：
- 目标：[提高可读性 / 拆分职责 / 消除重复 / ...]
- 行为完全不能变，所有现有测试必须通过
- 先输出重构计划（哪些步骤、每步的 diff 概要）
- 我确认后再实际修改
- 重构完成后跑一遍测试，把结果贴出来API 接口开发
请设计并实现 [API 路径与功能]，输出：
- 路由定义（含 method、path、auth 要求）
- 请求 schema（用项目里已有的 validator，例如 zod / pydantic）
- 业务逻辑（service 层）
- 响应 schema 与错误码
- OpenAPI 文档片段
- 至少 3 个测试用例（成功、参数错误、auth 失败）
遵循 src/api/ 现有的目录与命名约定。前端组件
请创建 [组件名] 组件，要求：
- 路径放在 src/components/[模块]/ 下，与现有组件保持一致
- TypeScript 严格模式，导出 props 类型
- 支持 [深色模式 / 响应式 / 无障碍 / ...]
- 跟着写一个 *.test.tsx，覆盖至少 3 个交互场景
- 不要引入新依赖，只用 package.json 里已有的库最后那条「不要引入新依赖」常被忽略，但一旦没加，模型很爱顺手 npm install。
Git 工作流
请帮我 review 当前 staged 的修改（git diff --staged），然后：
1. 用一句话概括这次改动的意图
2. 写一条符合 conventional commits 规范的 commit message
3. 不要执行 git commit，只输出 message 文本，我自己提交最后一句很重要——除非你完全信任，否则不要让 AI 直接执行 commit/push。
提示词中常用的「修饰词」
经过反复实测，这些短语对 Claude Code 行为影响最大：
| 修饰词 | 作用 | 何时用 |
|---|---|---|
请先分析... | 强制先读后写 | 任何中等以上复杂度任务 |
暂时不要修改文件 | 阻止它进入 edit 模式 | 探索 / 调研阶段 |
每完成一步都暂停 | 拆步执行 | 多文件、多模块改动 |
遵循项目现有的 [模式] | 风格一致 | 写新代码 |
如果不确定请问我 | 触发 clarifying question | 需求模糊时 |
只输出 diff，不要重写整个文件 | 避免上下文炸裂 | 改动大文件时 |
@ 引用与 plan 模式
两个 Claude Code 内置技巧，配合 prompt 模板效果翻倍：
请基于 @src/auth/login.ts 和 @src/api/session.ts 的现有实现，
帮我加一个 refresh token 的支持。@文件路径 让 Claude 精确读取文件，比「请阅读 auth 相关代码」省 token、更聚焦。
按 Shift+TAB 两次进入 PLAN 模式——它只规划不执行，规划阶段你再确认是否进入实施。这个交互比在 prompt 里写「先规划再实现」更稳定。
上下文管理
prompt 写得好，但聊到第 30 轮还是会糊。三招：
/clear— 完全清空，开新会话/compact— 让 Claude 自己压缩历史（保留要点）- 把项目级长期约束写进
CLAUDE.md，避免每次重复
我的经验：每个独立功能开一个新会话，比硬撑一个超长会话效果好得多。
自定义 slash 命令
把你常用的 prompt 模板放进 .claude/commands/ 目录，每个文件一条命令：
# .claude/commands/refactor.md
请重构指定的函数/类...（贴上面那个模板）下次直接 /refactor src/foo.ts 就能调用。OpenClaw 的 claude 兼容层完全支持这套。
拼车 token 用在刀刃上
提示词写得再漂亮，没有跑得起的额度也是空谈。Claude Code 默认依赖 Anthropic 配额，单人 Pro 跑大型重构经常被 rate limit 拦下。OpenClaw Carpool 走 Max 20× organization seat，4-7 人拼车按团队规模定制（加微信咨询），跑 Sonnet/Opus 都不限速：
curl -fsSL https://cp.bizq.net/setup.sh | bash -s -- claude-max-20x接通后所有上面这些 prompt 都能跑得透。
立即开始
把这套模板抄进 ~/CLAUDE-prompts.md，配合：
curl -fsSL https://cp.bizq.net/setup.sh | bash -s -- claude-max-20x—— 当天就能感觉到生产力曲线的台阶。
相关文章
- OpenClaw Claude Code 拼车配置指南 — 提示词跑起来的前置：拼车通道接入
- Claude Code 拼车最佳实践 — 把 token 花在最值的地方
- Claude Code MCP 服务器入门 — 给 prompt 加上工具调用能力