Prompt 技巧

Claude Code 出问题，一半是它自己的问题，另一半是 Prompt 没说清楚。把 Prompt 写好，等于免费提速一档。

好 Prompt 的三要素

一条能让 Claude Code 一次做对的 Prompt，通常都包含三样东西：意图、约束、验收标准。这三样任何一样缺失，返工的概率就会明显上升。

• 意图：你想让它做什么。不是笼统的方向，而是这次动作要达成的具体目标。目标越明确，Claude Code 越不会自作主张地扩大范围。
• 约束：不能碰哪里、必须遵循哪些规范、用哪些库、走哪条现有的封装。约束是防止它把简单的事做复杂的最有效手段。
• 验收标准：怎么算做完了。可能是一段测试要通过、一个接口能返回什么、一段行为的输出长什么样。验收标准直接决定它自己会不会跑测试来自检。

记住这三点，你就不会写出那种自己都不知道要什么的 Prompt。反过来说，如果你在写 Prompt 的时候发现这三点有一个说不清楚，那就先别急着发出去，先自己想清楚。

反例正例对照

下面几组是我们在真实项目里反复见到的典型对比。

例一：加功能

反例：

帮我加个登录功能

正例：

在 src/routes/auth.ts 里加一个 POST /login 接口，用现有的 bcrypt 校验密码，
返回 JWT。JWT 密钥读 process.env.JWT_SECRET，过期时间一小时。
完成后跑 npm test，确保 auth.test.ts 全通过。

例二：修 bug

反例：

这段代码有 bug 你看看

正例：

src/utils/date.ts 的 parseDate 函数，输入 2026-02-30 时会返回 3 月 2 日，
应该抛错才对。改这个函数，并在 date.test.ts 里加一个覆盖非法日期的用例。

例三：重构

反例：

把这段代码优化一下

正例：

services/order.ts 里的 processOrder 函数太长，拆成 validate、charge、notify 三个私有方法。
保持对外行为不变，orders.test.ts 全部测试要继续通过。不要改数据库 schema。

例四：调研

反例：

帮我看看有没有更好的方案

正例：

我要把 Redis 队列换成 Kafka，先不要动代码。先看 src/queue/ 目录，
告诉我当前用了 Redis 哪些能力，Kafka 侧要补哪些概念，迁移的三种可能路径分别是什么，
最后给我推荐一种并说清风险。

一个规律：字数长的 Prompt 不一定好，但明显缺少约束和验收标准的 Prompt 一定差。

大任务先要方案

任务一旦超过一两百行代码或者要动多个文件，先别让它直接写。可以这样开场：

先给我一份方案。列出：会改哪些文件，各自改什么，为什么这样拆，
潜在风险是什么，验收怎么做。别写代码，等我确认。

或者用内置的 Plan Mode，按 Shift+Tab 切到 Plan，Claude Code 会自动进入只研究不落地的状态，产出方案后等你签字。

小提示

方案阶段花的十分钟，能省掉动手阶段一个小时的返工。越是大项目越明显。

让它复读你的理解

有时候你说的东西很复杂，或者你自己都没完全想清楚。可以在 Prompt 结尾加一句：

动手之前，用你自己的话复述一遍我要你做的事，包括约束和验收。
如果任何一点不确定，先问我，再动。

这个技巧的成本很低，收益极高。它逼 Claude Code 把隐藏的假设拿到台面上，也逼你自己确认这些假设对不对。很多时候你会发现它复述出来的东西跟你想的不一样，这时候立刻更正比等它写完再返工划算得多。特别是新加入项目的成员和 Claude Code 之间还没磨合的时候，前几次任务都可以加这一句。

长期规范放 CLAUDE.md

有些约束是一次性的，写在 Prompt 里就行，比如这次不要动数据库。有些约束是长期的，比如整个项目的代码风格、测试要求、分支策略、常用命令。把这类东西写进项目根目录的 CLAUDE.md，Claude Code 每次开会话都会自动读。

这样做的好处是你的 Prompt 可以变短，不用每次都提醒它别 force push、别改 main、写完必须跑 npm test。CLAUDE.md 就是你与 Claude Code 之间的合同，把该白纸黑字定的都定下来。团队协作时把这个文件提交到仓库里，所有队友和 CI 里跑的 Claude Code 都会遵守同一份约定，效果比口头约束好得多。

注意

CLAUDE.md 不是万能的。它太长了 Claude Code 会失焦，控制在几百行以内最合适，超过就该拆成子文件按需引用。也不要把一次性的临时任务写进去，那种东西写完就该删。