Claude Code 提示词不灵时，试这 5 个进阶技巧

「这个组件，帮我好好重构一下吧。」

我这么扔过去之后，半小时后回来一看，Claude Code 确实重构了。命名也很干净。问题是，它还「顺手」把隔壁那个我根本没让它碰的文件的 import 顺序也整理了一遍，结果代码评审时差异膨胀到了 200 行。

一开始我把锅甩给模型，怪它「擅自扩大解读我的指令」。但同样的事故反复发生几次后我才明白：错的不是模型，是我提需求的方式。

基础那套套路（具体、上下文、输出格式、举例、迭代）我写在另一篇 写出更好提示词的 5 个技巧 里了。这篇文章只讲它的下一步：专门在实战中提示词「不灵」的那一刻才管用的 5 个进阶技巧。消除模糊、用文件名传上下文、让它分步验证、固定输出格式、失败后重新拆解。这些全是我亲手踩坑踩出来的。

本文要点

• 提示词的精度不取决于「措辞」，而取决于「固定边界」。先写清楚能碰什么、不能碰什么，差异就不会失控。
• 上下文别往聊天框里贴，用文件名传。「先读一下某某文件」这一句，是阻止它凭想象写代码最有效的咒语。
• 别让它一口气全干完，指定读取→计划→编辑→验证→报告的顺序。尤其「先只给计划」一句，能让事故率暴跌。
• 固定输出格式（差异怎么给、报告什么结构），评审会更快，返工会更少。
• 失败时别把同一条指令再扔一遍。把试过什么、哪里不行交给它，从定位原因开始让它做。

Claude Code 是一个会读代码库、改文件、跑命令的代理（agent），这一点可以在官方的 Claude Code overview 里确认。它不是「返回一段文字的 AI」，而是「真去干活的 AI」，所以你提需求的精度，会直接决定事故率。

技巧 1：消灭「好好弄」——模糊要用具体的禁止来填掉

最常见的失败，就是把评价性的词直接扔过去。「好好弄」「弄漂亮点」「弄正经点」「优化一下」。人和人之间能懂，但对 Claude Code 来说这是无法判定的指令。没有标准来界定什么叫「好」，模型只能靠猜。一旦开始猜，开头那个 200 行事故就发生了。

真正管用的做法，是把想让它做的事和不想让它做的事写得一样清楚。只写允许范围，它会读成「其他都随便」。

Before（模糊、没有边界）：

把这个组件好好重构一下，顺便弄得好看点。

After（有标准、有边界）：

请重构 src/components/UserCard.tsx，让它更易读。

要做的：
- 把超过 60 行的函数按职责拆成更小的函数
- props 类型有缺失就补全

不要碰的：
- 不要编辑 src/components/UserCard.tsx 以外的任何文件
- 不要做 import 排序之类只改外观的变更
- 不要改对外暴露的 props 名（会让调用方崩掉）

重点是「不要重排 import」这种乍看很细的禁止项。我那次 200 行事故，恰恰就是因为缺了这一行。加否定句不是为了把模型捆死，而是为了消除它「自以为帮你」的越界空间。怎么挡住过度删除和误触生产环境，我整理在 为什么「全部交给你」是禁句 里了。

技巧 2：上下文别贴聊天框，用文件名传

你有没有过「这代码是凭空想出来的」那种感觉？调用了根本不存在的函数，或者把现成的工具函数重新发明了一遍。这通常是因为 Claude Code 没拿到必要的上下文。

很多人会把参考代码整段贴进聊天框。这往往适得其反。一贴进去，上下文就被定死了，和最新的文件对不上；而且贴得越长，关键的指令越容易被淹没。

更好的做法，是用文件名告诉它「先读一下」。Claude Code 能自己打开文件，会基于最新内容来干活。

动手实现前，请先按下面的顺序阅读：

1. src/lib/api-client.ts （现有的 fetch 封装，必须用这个）
2. src/features/orders/orderList.tsx （类似的列表页，结构和命名照它来）
3. src/types/order.ts （类型定义，不要擅自新建类型）

在此基础上，实现订单详情页 src/features/orders/orderDetail.tsx。
只用 api-client.ts 里的函数，不要自己写 fetch。

「先读一下」这一句之所以管用，是因为它逼模型在凭空写之前先去看事实。再加上「只挑一个相似实现作为参照基准」，文风和结构就会和现有代码对齐。反过来，要是塞 10 份参考资料给它，它分不清该优先看哪个，光是探索就把时间烧光了。诀窍是收窄阅读顺序，和允许采用的基准。

顺带一提，那些「希望它一直遵守」的东西（构建命令、命名规则、禁区），每次手写很烦，应该放进 CLAUDE.md 而不是聊天框。官方的 Memory 文档里也说明了，CLAUDE.md 是每个会话都会被加载的上下文。粒度怎么定，我单独写在 CLAUDE.md 由「不写什么」决定 里了。

技巧 3：别让它一口气干完，要分步验证

越聪明的模型，你一让它干，它就越想一气呵成跑到底。这恰恰是坑：中途某个前提偏了，它就会朝错误的方向全力冲刺，最后只把结果甩给你。等你看到差异时，已经来不及了。

管用的做法，是给一条在执行前先停一下的指令。我用得最多的就是「先只给计划。我说 OK 之前不要改代码」这一句。光这一句，就让跑偏的大改少了一大半。

更进一步，可以把工作本身切成阶段。

请按下面的步骤推进。每一步做完先停下来，等我说「下一步」再继续。

步骤 1：列出目标文件，以及可能受影响的调用方，做成清单报告（先别编辑）
步骤 2：把要改的函数和改动理由，简短地列成要点（先别编辑）
步骤 3：得到我批准后，只在范围内编辑
步骤 4：运行 npm test，把结果（PASS/FAIL）原样贴出来
步骤 5：报告改动的文件，以及残留的疑虑

如果觉得「每一步都停」太麻烦，那至少要把步骤 1 设为必做。光是先让它列出影响范围，就能尽早发现意料之外的文件混了进来。

验证如果用「能做就做」来提，忙的时候一定会被跳过。要写具体的命令名，比如 npm test，并让它把结果贴出来。万一跑不了，也让它报告「哪个没跑成」，这样你才好判断。这种「别轻信自我申报」的思路，我在 别信 Claude Code 说的「搞定了」 里写得更细。

技巧 4：固定输出格式，让评审更快

同样一份活，如果报告方式每次都不一样，评审就会变慢。「大概弄好了，应该没问题」这种回复，结果就是逼你把所有东西重新确认一遍。

事先把输出格式交给它，每次就会以同样的粒度返回。评审会变成「照着格式读一遍」，漏看也会减少。

干完活后，请只用下面的格式报告。不要前言和感想。

## 改动的文件
- （列出路径）

## 改动内容（一文件一行）
- 路径：改了什么，为什么改

## 运行的命令和结果
- 命令 → PASS / FAIL（FAIL 的话贴对应日志末尾 5 行）

## 还没确认的
- （需要人工看的地方、没能跑的验证）

让它做代码评审时，输出格式更重要。说「整体看一下」，回来的是一篇读后感。让它必须用一张包含严重度、文件名、行号、修复方案的表格来给结果，就更接近实战评审了。

要指定的项	写它的理由
严重度（高/中/低）	能定出修复顺序
文件名和行号	立刻能追到是哪儿的事
复现条件	能验证是不是真问题
修复方案	不让它「只指出问题」就完事

再指定个观察角度，比如「优先看安全、数据破坏、对外 API 变更、测试不足」，回来的就不是一堆无关痛痒的指摘，而是真正有用的评审。

技巧 5：失败了，别把同一条指令再扔一遍

这是最浪费的一个点。Claude Code 的输出不理想时，人很容易把同一条提示词再发一遍。但输入几乎没变，输出也几乎不会变。你会永远撞在同一堵墙上。

重新拆解的诀窍，是把现在是什么状态和哪里不行具体地交给它，让它从定位原因开始，而不是靠猜。

Before（单纯重发）：

跑不起来，修一下。

After（交出现状和症状，让它先定位）：

刚才那次改动之后，npm test 里只有 orderDetail 的测试挂了。

- 失败的测试：tests/orderDetail.test.ts 的 "renders total price"
- 错误：Expected "¥1,200" but received "1200"
- 最近的改动：价格显示的格式化处理

修复前，请按可能性从高到低，列出 2 到 3 个原因候选并解释。
然后用最小的差异来修。不要删测试。

加上「修复前先解释原因候选」这一句，就能切断「Claude Code 乱动一个没关系的地方、结果又弄坏另一处」的连锁反应。失败日志很容易让人只看末尾一行就早早下结论，所以你把症状整理好再交过去，重新拆解就越快。

要是还是对不上，那就果断重置上下文。拖着很长的对话不放，它会带着过去那些偏掉的前提来修。开一个新会话，把整理好的症状和目标文件重新给它，往往反而更快。

可以直接复制：用脚本机器检查提示词的「破绽」

就算心里装着这些进阶技巧，赶时间的时候还是会忘了写「不要碰的范围」或「验证命令」。所以我改成把需求写进文件（prompt.md），在扔出去之前用脚本检查最低限度的项目齐没齐。

下面这个 Node.js 脚本，会检查目标、范围、禁区、验证命令、输出格式是否都在。零依赖，直接能跑。

// check-prompt.mjs —— 在扔出去之前检测需求文里的缺漏
// 用法: node check-prompt.mjs prompt.md
import { readFileSync } from "node:fs";

const file = process.argv[2] || "prompt.md";
const text = readFileSync(file, "utf8");

// 把「缺了就会出事」的最低条件规则化
const checks = [
  { ok: /(目标|目的|Goal)/i.test(text), msg: "缺少目标（要达成什么）" },
  { ok: /(目标文件|范围|Scope|可以编辑)/i.test(text), msg: "缺少可以碰的范围" },
  { ok: /(不要碰|不要编辑|不要改|do not)/i.test(text), msg: "缺少不要碰的范围（禁区）" },
  { ok: /(npm |pnpm |yarn |node |test|构建|运行)/i.test(text), msg: "缺少验证命令" },
  { ok: /(报告|输出格式|格式|用.*格式)/i.test(text), msg: "缺少输出格式的指定" },
];

const failed = checks.filter((c) => !c.ok);

if (failed.length > 0) {
  console.error(`这样扔出去容易出事（${file}）：`);
  for (const f of failed) console.error(`  - ${f.msg}`);
  process.exit(1);
}

console.log("OK：主要项目都齐了，可以扔出去了。");

运行就这一句。

node check-prompt.mjs prompt.md

虽然只有几十行，但每次我在文章重写或加功能时出事，几乎都是「不要碰的范围」或「验证命令」漏了其中之一。扔出去前先过一遍这个脚本，返工就明显变少了。怎么把有效的需求文存下来、模板化，我整理在 别把管用的提示词用完就扔 里。

常见问题

Q. 提示词是不是写得越长越详细，精度越高？ 不是。比起长度，结构更重要。官方的 Memory 文档里也说明了，指令越长越难被遵守，越具体简洁反而越容易被照做。与其啰啰嗦嗦地写，不如用标题把目标、范围、禁区、验证分开，更管用。

Q. 每次都写「不要碰的东西」太麻烦了。 每次活儿都通用的禁止项（不要碰生产数据库、不要擅自加依赖等），移到 CLAUDE.md 里。只针对本次工作的禁止项，写在需求文里。把存放位置分开，重复就少了。

Q. 让它分步停下来，反而会更慢吧？ 小而安全的活儿，让它一气呵成也没关系。分步管用的场合，是影响范围摸不清的变更，或者会波及多个文件的工作。最起码留一句「先只给计划」，会更稳妥。

Q. 给了示例（样板代码），它就照抄，很头疼。 原因是你把示例和约束混在了一起。要写明角色：「这个文件只作为『结构和命名』的参考，里面的处理逻辑不要复制。」把希望它当样板的点，和希望它遵守的边界分开写，就能如你所愿。

Q. 在 CLAUDE.md 里写「绝对不准做某某」，它就一定会停吗？ 不会停。CLAUDE.md 不是强制，而是被当作上下文处理。真正想拦住的操作（删除、应用到生产等），用官方介绍的 PreToolUse 钩子从机制上拦截，才靠谱。

实际试下来的结果

开头那次 200 行事故之后，我就不再去打磨提示词的「措辞」了。我改做的是：每次在需求文开头，固定加上「不要碰的东西」和「验证命令」这两行。光这样，意料之外的文件混进来的事故就几乎归零了。

最管用的是技巧 3 的「先只给计划」。自从把它变成口头禅，被跑偏的大改抢走时间的情况就暴跌了。Claude Code 越聪明就越会全力冲，所以在它冲出去之前先让它停一下——这一道工序，到头来反而是最快的，这是我现在的真实体会。

说是进阶技巧，其实做的事就是「消除模糊、固定边界、让它验证」而已。先从下一个任务开始，在需求文里加上「不要碰的东西」这一行试试看。等你攒下一批反复能用的模板，也欢迎来 教材与模板一览 逛逛；想把 CLAUDE.md、权限、评审、验证流程落到真实团队仓库里，可以看看 Claude Code 培训与咨询。