Claude Code 提示词怎么写？把模糊需求改成工程任务的新手指南

⏱️ 预计阅读 18 分钟 ｜ 🎯 目标：让你学会把一句模糊想法，改写成 Claude Code 能执行、能自我验证、少返工的工程任务——这就是「Claude Code 提示词怎么写」的核心答案。

你搜「Claude Code 提示词怎么写」，多半是因为同样一句话，今天它做得很漂亮，明天它跑偏到看不懂。问题往往不在它，在你给的那句话本身：太像在跟聊天框许愿，不像在给同事派活。这篇用一套五件套 + 3 组真实「模糊需求 → 工程任务」前后对照，教你把许愿改成派活。

30 秒答疑

先用一张表回答你最关心的几个问题：

最常见的新手误区：以为提示词工程是「学一套神奇咒语，模型就听话」。不是——它是「把模糊需求翻译成工程任务」的沟通基本功，咒语不存在，说清楚才存在。

🔥 翔宇判断：为什么这篇值得你读完

我把市面上讲「Claude Code 提示词」的中英文文章翻了一圈，发现大家几乎都停在「列原则」：要清晰、要给上下文、要拆任务——道理都对，但全是抽象名词，没人把「一句模糊的话」当着你的面改成「一条能跑的任务」。新手缺的从来不是「知道要清晰」，是「不知道怎么从模糊变清晰」。这篇填的就是这个缺口：下面第三节给你 3 组完整的「❌ 模糊原话 → ✅ 工程任务」逐字对照，每一组都标出补齐了哪几件信息；再配上我自己每天用 Claude Code 攒下的取舍判断——什么时候该先计划、什么时候直接干、产出不好时先回看哪一件。原则你别处也能看到，逐字改写和真实取舍是这篇独有的。

下面把这件事一层层讲透。

一、Claude Code 的提示词，到底在写什么？

很多人把「提示词」理解成「换个说法哄 AI」，于是到处找「万能提示词模板」。在 Claude Code 这里，这个理解会让你一直踩坑。

1.1 它不是聊天内容，是一张任务单

Claude Code 不是聊天框。Anthropic 官方在最新文档里把它定义为「代理式编程环境」（agentic coding environment）：和「回答完就等你」的聊天机器人不同，Claude Code 会自己读你的文件、跑命令、改代码、一步步把问题解决掉，你在旁边看、纠偏，或者干脆走开。

所以你写下去的那段话，会决定它去读哪些文件、要不要先做计划、能不能动文件、改完跑不跑测试、最后怎么汇报。它不是一句聊天，是一张任务单。

任务单写得好，它少问、少猜、少改错地方；写得差，它可能读错目录、把改动范围越扩越大、跳过验证，最后丢给你一个「看起来完整、不一定能用」的结果。很多人说的「AI 不靠谱」，背后常常是任务单没给够边界。

💡 通俗讲

想象你请了一个很能干、但完全不读心的远程同事。你跟他说「把项目弄好一点」，他只能凭手上的文件猜你要什么；你跟他说「把登录页这个报错修掉，只改这个文件，改完跑一遍测试给我看」，他立刻知道该干嘛。提示词就是你写给这位同事的派活单——他多能干，取决于你单子写得多清楚。

1.2 这就是「提示词工程」对新手的真正含义

「提示词工程」（prompt engineering）这个词听起来很玄，新手一看就以为要学一套黑话。对用 Claude Code 的新手来说，它其实只意味着一件朴素的事：

把你脑子里那句模糊的想法，翻译成对方能照着执行、还能自己检查对错的清晰任务。

不是写咒语，不是堆英文标签，不是讨好模型。是减少误会。你给真人同事派活时本来就会做的事——说清范围、说清为什么、说清哪里别碰、说清什么时候算完——搬到 Claude Code 上，就是全部的提示词工程。

🔥 翔宇判断

我观察下来，新手在 Claude Code 上卡住，十有八九不是不会用工具，是还把它当聊天框在许愿。把心态从「我问一句、它答一句」切换成「我派一个任务、它执行并交付」，提示词质量会立刻上一个台阶——这个切换比任何模板都值钱。先有这个心态，下面的五件套才有意义。

二、一条能执行的任务，要包含哪五件事？

把模糊需求翻译成工程任务，靠的是补齐五件信息。我把它叫五件套：目标、背景、输入、限制、验收。下面这张表是全文的骨架，记住它，后面所有改写都是在填这五个格子。

2.1 五件套总表

记忆口诀：目标 + 背景 + 输入 + 限制 + 验收。

2.2 不是填表，是别漏信息

看到五个格子，新手容易走到另一个极端：每次都写成一张冷冰冰的表单。没必要。五件套的作用是提醒你别漏，不是逼你把话说得像机器。

Anthropic 官方文档里给的优秀提示词例子，全是大白话的自然句，比如：「用户反馈会话超时后登录就失败，查一下 src/auth/ 里的认证流程、尤其是 token 刷新，先写一个能复现问题的失败测试，再修。」——这一句话里目标、背景、输入、限制、验收全有了，但读起来就是一句正常的话。

所以正确姿势是：脑子里过一遍五件套，落笔写大白话。 熟练之后，你一段自然语言就能把五件事讲齐。

💡 通俗讲

五件套像出门前的检查清单：钥匙、手机、钱包、门窗、火。你不会每次出门都举着清单一项项念，但心里扫一遍就不会落东西。提示词同理——心里扫一遍五件套，落笔写大白话。

三、3 组真实改写：把模糊需求改成工程任务

这是全文最该收藏的一节。下面三组覆盖三个最常见场景——修 bug、加功能、重构。每组都给你「❌ 新手原始写法」和「✅ 改写后的工程任务」，并标出补齐了哪几件。

3.1 改写组一：修 bug（最高频）

新手第一个想交给 Claude Code 的，几乎都是「我这有个 bug」。但下面这种写法，它只能靠猜：

❌ 模糊原始写法

我的登录有问题，帮我修一下。

它会反问你一堆：哪个登录？什么现象？什么环境？还是干脆自己满仓库翻、猜一个改了，结果可能改错地方。补齐五件套后：

✅ 改写成工程任务

用户反馈：会话超时后再点登录按钮没反应，刷新页面才恢复。
（背景）这是线上 Next.js 站点，Chrome 正常，主要出现在 Safari。
（输入）相关逻辑在 @src/lib/auth.ts 和 @src/app/login/page.tsx。
（限制）不要改 signIn() 的函数签名，不要引入新依赖。
（验收）先写一个能复现这个问题的失败测试，再修到测试通过；
改完告诉我动了哪些文件、跑了哪些验证。

补齐对照：

🔥 翔宇判断

这一组里最值钱的不是「@ 引用」，是「先写一个能复现的失败测试，再修」。这是 Anthropic 官方反复强调、我自己也最认同的一句——给它一个能自己验证对错的标准，是提示词里投入回报最高的一件事。有了失败测试，它就有了客观的「红变绿」目标，不会改个看起来对、其实没修好的版本糊弄你。

3.2 改写组二：加功能

加功能比修 bug 更容易跑偏，因为「功能」两个字底下藏着无数选择。看这个典型：

❌ 模糊原始写法

给我加一个用户头像上传功能。

它要替你做一连串决定：存哪？限不限大小？要不要裁剪？前端长什么样？跟现有代码风格一致吗？每个决定都可能和你想的不一样。补齐后：

✅ 改写成工程任务

（目标）在用户资料页加「上传头像」功能。
（背景）现有上传组件可以参考 @src/components/FileUpload.tsx 的写法，
风格、错误提示都跟它对齐，不要另起一套。
（输入）资料页是 @src/app/profile/page.tsx，
后端上传接口已有，在 @src/app/api/upload/route.ts。
（限制）只接受 jpg/png、单张 ≤ 2MB；超限要给中文错误提示；
不要新增图片处理库，用项目里已有的依赖。
（验收）上传成功后头像立刻刷新；给我截图看一下最终效果；
跑 npm run lint 不报错。

这一版的关键是「参考现有写法」和「别另起一套」。官方文档里专门有一条最佳实践叫「指向已有模式」（reference existing patterns）——与其让它凭空造一个，不如指给它看「就照 FileUpload.tsx 这个例子的样子来」。新手最容易忽略这句，结果项目里风格越来越乱。

💡 通俗讲

「参考现有写法」就像装修时跟师傅说「新做的柜子，颜色和样式照客厅那个来」，而不是「随便做个好看的柜子」。前者出来的东西和家里融为一体，后者大概率突兀。代码也一样，风格统一比单点漂亮重要得多。

3.3 改写组三：重构 / 改造现有代码

重构是风险最高的一类，因为它要动已经在跑的代码。新手最危险的写法是这种：

❌ 模糊原始写法

这段代码太乱了，帮我重构一下，写好看点。

「乱」和「好看」都不可验证——它可以改成十种样子，每一种它都觉得「更好看了」，但可能顺手改坏了行为。重构必须把「保持行为不变」和「具体哪里改」钉死：

✅ 改写成工程任务

（目标）重构 @src/utils/order.ts，把那个 200 行的 calculateOrder
函数拆成几个职责单一的小函数，可读性更好。
（背景）这是结算核心逻辑，线上在用，行为绝对不能变。
（限制）对外暴露的 calculateOrder 入参、返回值、函数名都不许改；
不要改其他文件；不要引入新依赖；每个拆出来的函数尽量 ≤ 30 行。
（验收）重构前先确认现有测试能跑过、把它当基线；
重构后这些测试必须依然全过——这就是「行为没变」的证明；
改完列出你拆成了哪几个函数、各自负责什么。

补齐对照：

🔥 翔宇判断

重构这一组的命门是那句「现有测试当基线，重构后必须依然全过」。重构的定义本来就是「改结构、不改行为」，而「行为没变」唯一可信的证明就是测试还绿着。新手要是没有测试兜底就让 AI 大改核心逻辑，等于闭着眼开车——这也是为什么我会建议，动重要代码前先 git commit 一次留个还原点，万一不对，一键回滚比手工撤销省心太多。

多说一句别踩的坑：Claude Code 现在确实自带「检查点」（按两下 Esc 或 /rewind 能回退），但官方写得很清楚——检查点只跟踪它自己的改动，不是 git 的替代品。它管不住你手动跑的脚本、装的依赖、改的数据库。所以真正重要的代码，护身符永远是先 git commit，检查点只是会话内的小撤销，两者别混为一谈。

3.4 三组的共同套路

回头看这三组，你会发现改写的动作完全一样：把动词换成结果，把「注意」换成具体边界，给一条能自己验证的完成标准。 场景不同，套路相同。你下次遇到任何新场景，照着这个套路填五件套就行。

四、上下文（Context）怎么给才不添乱？

五件套里，新手最常给错的是「背景 / 输入」这两件——要么不给，要么一股脑全塞。这一节单独讲清楚。

4.1 越相关越好，不是越多越好

上下文不是堆得越多越聪明。Claude Code 有个绕不开的硬约束：上下文窗口（context window）会被填满，越满它表现越差——官方把这条列为几乎所有最佳实践的根因。你的对话、它读过的每个文件、每条命令输出，都在占这个窗口。你塞一堆无关材料进去，等于把它的「工作记忆」挤爆，它反而开始忘事、出错。

所以给上下文的原则是：精准给相关的，别一把全倒。

4.2 用 @ 直接把文件喂给它

Claude Code 最顺手的给法是 @ 引用。直接说路径和用 @ 有实际区别：

• 只说路径：「改 src/auth.ts 里的那个问题」——它得先自己 grep、再 Read 找到并读进来，多走一两步。
• 用 @ 引用：「改 @src/auth.ts 里的那个问题」——它当场把这个文件的完整内容塞进上下文，省掉查找。

官方文档里 @ 的几个事实，记牢能少踩坑：

• @文件路径：把整份文件内容读进上下文（路径可相对可绝对）。
• @目录：给的是该目录的文件清单，不是内容——想看内容得点到具体文件。
• 一条消息里可以 @ 多个文件，比如「@file1.ts 和 @file2.ts」。
• @ 一个文件时，它还会顺带把该文件所在目录及上层目录的 CLAUDE.md 拉进来——这也是项目记忆文件能自动生效的原因之一。

🔥 翔宇判断

我的用法很固定：精准 @ 几个关键文件，好过让它自己满仓库翻。 @ 上 README、package.json 这种能给它全局视角的，再 @ 上这次要动的那一两个文件，基本就够了。千万别 @ 整个 src/ 目录——那等于把上下文窗口一次性塞爆，得不偿失。

再补一个新手常忽略的细节：又长又不一定每次都用到的文档，别用 @ 钉进去。 @ 是「现在就把整份内容塞进来」，你 @ 一个几千行的设计文档，它每次都得整份背着走，很快就把窗口占满。这类材料更好的写法是「需要时去 docs/xxx.md 查」——让它需要的时候自己读，而不是一开始就全压进上下文。@ 留给这次一定要看的那几个文件。

4.3 任务大就先让它「复述理解」

如果任务比较大、文件比较多，别急着让它动手。先用一句话逼它把理解吐出来：

先只读 @src/payment/ 这些文件，告诉我你理解的目标、
现状有哪些问题、你打算怎么改——先别动任何文件。

它复述的过程，就是暴露误解的过程。理解错了，你当场纠正；理解对了，再放它去做。这一步花的几分钟，比改完整个返工省太多。它属于下一节要讲的「先计划再执行」。

4.4 任务太大、你自己都没想清楚？让它反过来「访谈」你

还有一种更值钱的情况：任务大到连你自己都说不清要什么——比如「做一个会员后台」「把这个老项目重做一遍」。这时候逼自己一次写齐五件套反而很痛苦，因为很多决定你还没拍板。

Anthropic 官方文档给了一个很妙的办法：别急着派活，先让 Claude Code 来访谈你。 用一句话起头，让它对你提问，把你没想到的实现细节、交互、边界、取舍一个个问出来：

我想做一个用户会员后台。请你用提问的方式访谈我，
把技术实现、界面交互、边界情况、取舍这些都问清楚，
别问显而易见的，专挑我可能没想到的难点问；
问完之后，把我们聊定的内容整理成一份完整的需求说明，写进 SPEC.md。

它会像个有经验的同事一样，一条条问你「头像存本地还是对象存储」「会员过期当天怎么处理」「要不要留导出数据的口子」——这些正是你没想清楚、回头最容易返工的地方。聊完它把结论落成一份 SPEC.md，你再开一个干净的新会话，让它照着 SPEC.md 执行。这样实现会话的上下文是干净的，全用在干活上，而不是和你来回确认需求。

🔥 翔宇判断

「让它先访谈我」是我做大任务时几乎必用的一招，也是大多数中文教程没讲的。它的本质和五件套是一回事——把模糊变清晰，只是换了个方向：不是你单方面写齐五件套，而是让它帮你把五件套问出来。一份越具体的 SPEC.md，回报远高于你盯着它一行行写代码。记住一条：你越说不清要什么，越要让它先问、别让它先做。

五、限制（Constraints）怎么写才管得住它？

限制不是为了捆住 Claude Code，是为了守住任务边界。新手最容易漏、也最容易写废的就是这一件。

5.1 「注意安全」是废话，具体边界才有用

「注意安全」「小心一点」这类话对它几乎没作用——因为「安全」在不同任务里含义完全不同。要把它翻译成这次任务里具体不能碰什么：

5.2 限制要可验证，强调词能提一提遵守度

官方有一条很反直觉但很关键的事实：Claude 能理解模糊指令，但不一定执行。「保持代码整洁」它听得懂，却落不了地；「每个函数 ≤ 30 行、单一职责」它就能照做——因为后者可验证。所以限制要尽量写成能检查的规则，别写成形容词。

另外，官方明确说可以用强调词提高关键约束的遵守度，比如 IMPORTANT:、YOU MUST、NEVER。真正绝对不能破的红线，用强调词点一下，比平铺直叙更容易被它当回事。

💡 通俗讲

「保持整洁」对 AI 就像家长说「乖一点」——孩子不知道具体指什么。「函数别超过 30 行、一个函数只干一件事」才像「九点前写完作业、不许看手机」——边界清楚，照着做就行。

5.3 担心它越界？先把任务设成「只读」

对高风险任务，最稳的限制是：先不给它写权限。 让它先读文件、列计划、指出风险，你确认计划没问题了，再放开让它改指定文件。这个节奏对新手特别友好，下一节细讲。

六、验收（Done-When）怎么写？这是回报最高的一件

如果五件套里只能写好一件，写验收。Anthropic 官方原话是：给 Claude 一个能验证自己工作的方式，是你能做的回报最高的单件事（the single highest-leverage thing you can do）。

6.1 验收要能客观检查

不可检查的验收等于没验收。对照一下：

6.2 让它「拿证据」，别让它「报喜」

官方有个很实用的提法：让它出示证据，而不是声称成功。 测试输出、它跑了什么命令返回了什么、结果的截图——你审证据，比你自己重新跑一遍验证快得多，尤其是那些你没全程盯着的任务。所以验收里可以直接加一句：「改完把测试输出和你跑的命令贴给我看。」

还有个 2026 年越来越好用的兜底动作：让它改完之后，用「另一双眼睛」复查一遍。 Claude Code 自带一个 /code-review 命令，会在一个全新的、不带之前推理过程的上下文里审查这次的改动，专挑 bug 和边界遗漏报给你；你也可以自己写一句「开一个子任务，只看这次的 diff，对照我前面定的验收标准，缺哪条就指出来，别提风格偏好」。它的妙处在于：审查的那个「分身」只看到结果和标准，看不到「为什么这么写」的自我辩护，所以挑得比写代码的本人狠。注意一点：审查者被要求「找毛病」，就一定会找出点什么，别它说什么你都照单全收——只认那些真影响正确性或没满足验收的，其余当参考即可，否则容易把代码越改越复杂。

6.3 写不出验收，说明任务还没想清楚

这是新手最该建立的一条直觉：如果你连「怎么算干完」都写不出来，先别让它开工。 先让它帮你把模糊目标拆成一张可验收清单，再决定动不动手。提示词工程的价值，很多时候就在按回车之前那几分钟。

不过这里要诚实补一个例外，免得你把它用僵：只有「真要交付东西」的任务才必须写死验收，纯探索不用。 当你只是想摸摸底——「这个文件你看有什么能改进的」「这块代码大概什么思路」——故意把话说得开放一点反而更好，它会冒出一些你压根没想到要问的点。判断很简单：这次是「让它干活、要结果」，验收必须有；这次是「让它给我点灵感」，放它发散。别把适合探索的场合，也套上交付的紧箍咒。

🔥 翔宇判断

我自己判断一条提示词好不好，标准很土：它读起来像不像一份靠谱同事的任务交接。 接手的人看完，知道现在什么情况、要交付什么、哪里不能碰、做完怎么汇报——能做到这四点，Claude Code 就有了稳定执行的地基。华丽的英文标签、长长的咒语，都不如这四点实在。

七、先让它出计划，还是直接让它干？

这是新手第二高频的纠结。答案不是「都要计划」也不是「都直接干」，而是看任务。

7.1 官方推荐的四阶段：探索 → 计划 → 执行 → 提交

Anthropic 把这套叫「先探索、再计划、后编码」（Explore, then plan, then code）。完整四步是：

1. 探索（Explore）：进入计划模式（Plan Mode），让它只读文件、回答问题，不改任何东西。
2. 计划（Plan）：让它产出一份详细的实施计划——要改哪些文件、按什么顺序。
3. 执行（Implement）：退出计划模式，让它照计划改代码，并对照计划自查。
4. 提交（Commit）：让它写一条清楚的提交信息、开一个 PR。

7.2 Plan Mode 怎么开、是什么

计划模式（Plan Mode）是 Claude Code 的「先规划、不动手」开关。按官方文档，开它有三种方式，挑顺手的用：

• 会话中按 Shift+Tab 切换（最常用）。这个键是在三档权限模式间循环：默认（每步都问）→ 自动接受编辑 → 计划模式，连按到状态栏显示计划模式即可。
• 只想让某一条指令先出计划，在这句话前面加 /plan 前缀就行，不用切整个会话的模式。
• 启动时加参数：claude --permission-mode plan，开局就进计划模式。

进入后它只能读、只能分析、只能给方案，碰不了任何文件。等它把方案给你，会停下来问你怎么往下走——你可以选「批准并开始改」「批准但每步都让我确认」，或者「继续给反馈、再改改计划」。批准了才进入执行模式真正动手。如果想直接编辑它给的计划，按 Ctrl+G 能把计划在你的文本编辑器里打开来改。

7.3 什么时候该计划、什么时候直接干

官方说得很直白：Plan Mode 有用，但也有额外开销。一句话能描述清楚的改动，就跳过计划。

🔥 翔宇判断

我的拇指法则就一句：这个改动你能不能用一句话把 diff 描述出来？ 能，直接干，开计划反而是浪费时间；不能——比如「重构整个结算模块」「把这个老项目迁到新框架」——那一定先 Shift+Tab 进计划模式，让它先把路线图摆给我看。让它先想清楚，比让它先动手，省下的返工时间多到惊人。

八、Claude Code 没干好，怎么排查是哪一件没写够？

提示词写出去结果不对，先别急着换模型、也别急着骂 AI。官方专门提醒：产出不好时，第一反应不该是换模型，而是回看任务里漏了什么。 五件套正好是一张排查清单——哪件没补够，对应一种典型症状。

8.1 症状 → 缺哪一件 对照表

8.2 纠偏要趁早，别让错误堆进上下文

官方强调「尽早、频繁地纠偏」（Course-correct early and often）。几个实用动作：

• 发现它跑歪，按 Esc 当场叫停，上下文还在，可以马上重新指方向。
• 按两下 Esc 或输入 /rewind，能回到之前的对话和代码状态（检查点）。
• 同一个问题纠正超过两次还不对，别再纠了——这时上下文已经被失败的尝试污染了。跑 /clear 清空，用一条吸取了教训的、更具体的新提示词重开。官方明确说：「干净会话 + 好提示词」几乎总是赢过「长会话 + 反复纠正」。

💡 通俗讲

/clear 就像把写满涂改的草稿纸揉掉，换一张干净的重写。很多新手舍不得——「它好不容易熟悉这个项目了」——结果在一张越改越花的纸上硬撑，越写越乱。其实换张干净纸、把这次学到的东西一次写清楚，往往三两笔就成了。

8.3 反馈要落到「可观察的现象」上

纠偏时别只说「你理解错了」，要指出错在哪个具体现象：「你把那份参考文章当成要改的文件了」「你动了 frontmatter，我只让你改正文」「你没检查 FAQ 数量」。AI 不怕你指出问题，怕的是问题没落到它能观察到的现象上。 反馈越具体，下一轮越好。

8.4 进阶一招：让「写的它」和「审的它」分开

新手排查靠回看五件套就够了。但当你开始放手让它做大一点的任务，会撞上一个微妙的问题：让它自己检查自己，它常常看不出问题——因为它会下意识维护「我刚才那么写是对的」。这不是 AI 笨，是同一段上下文里，写和审的立场是冲突的。

官方推荐的解法很巧：把「写」和「审」拆到两个独立上下文里。 两种轻量做法，新手也能上手：

• 开两个会话（写/审分离）：会话 A 让它实现功能；会话 B 用一句话只让它审——「审一下 @src/middleware/rateLimiter.ts 这个限流实现，盯边界情况、竞态、和现有中间件风格是否一致」。B 没有「我写的」包袱，挑得更准。把 B 的意见贴回 A 去改。
• 让它派一个「子任务」专门审：在同一个会话里说「开一个子任务，只看这次的 diff，对照计划逐条检查有没有漏、该测的边界有没有测、有没有动到范围外的东西，只报缺口」。这个子任务在干净上下文里跑，看不到「为什么这么写」的辩解，评判更客观。

🔥 翔宇判断

这一招把验收从「我一个人审」升级成「让另一个它先帮我审」，是我处理稍大任务时省心的关键。但有个反直觉的点必须记住：审查者被要求「找毛病」，它就一定会找出毛病，哪怕代码本来没问题。 所以一定在审查指令里写死「只报真影响正确性或没满足验收的，风格偏好不用提」——否则它会给你列一堆「可以更健壮」的建议，把你引向过度设计，代码越改越臃肿。让它审，但你来拍板该不该改。

九、提示词、CLAUDE.md、Slash Commands 怎么分工？

学会写提示词后，新手常犯一个反向错误：把每次任务都写成一封超长说明书，把项目的固定规则一遍遍手打。没必要，而且有害。 三样东西各管一摊：

判断很简单，每次任务结束回看一下：

• 哪些信息每次都要重复讲？ → 沉淀进 CLAUDE.md，它每次会话自动加载，不用再手打。
• 哪些步骤经常整套复用？ → 做成可复用流程。
• 哪些只是这次需要？ → 留在当前提示词里就够。

🔥 翔宇判断

提示词随项目成熟会越写越短，这是好事不是偷懒。第一周你可能要写很多背景；把固定背景挪进 CLAUDE.md 之后，第三周一条任务可能只剩「按发布前检查流程过一遍这篇」。把稳定知识放到更合适的位置，本次提示词就能瘦下来——这正是成熟工作流的样子。CLAUDE.md 具体怎么写，单独讲透了，见 CLAUDE.md 怎么写。

十、新手的一周练习路径

提示词写好不是天赋，是肌肉记忆。下面这套按天练，四步走完五件套就成了本能。

练完这一周，你写提示词的压力会明显下降——因为很多规则已经不用每次重复讲了。

10.1 别忘了存下「有效的那条」

还有个容易忽略的动作：一次成功的任务，把那条真正有效的任务说明存下来。 不是存整段聊天，是存那条管用的提示词。下次遇到类似任务，先复用、再按当前材料微调。这样你的提示词能力会从「临场发挥」慢慢变成「可复用的工作资产」。

十一、提示词自检清单

任务发出去之前，对着这张表过一遍：

• [ ] 目标：我说的是「要什么结果」，不是「改一改」这种动作词？
• [ ] 背景：项目是什么、现状什么问题、为什么改——我写出来了吗？
• [ ] 输入：关键文件我用 @ 点出来了吗？参考用的文件我说明「只参考不要改」了吗？
• [ ] 限制：「不能碰什么」写成了具体边界，而不是「注意安全」？
• [ ] 验收：完成标准是它能自己验证、我也能客观判断的吗？
• [ ] 节奏：这个改动我能一句话描述 diff 吗？不能就先让它出计划。
• [ ] 证据：我让它「贴测试输出 / 截图 / 跑了什么命令」，而不是只口头报喜？
• [ ] 长期：这条里有没有「每次都要重复」的规则，该挪进 CLAUDE.md？

任何一条答「没」，回去补对应那一节。

11.1 怎么反过来判断「这条提示词写得好不好」

不确定自己写得够不够清楚，看它的反应就知道：

• ✅ 它没追问、直接进入工作模式 → 说明上下文给够了。
• ✅ 第一次产出基本可用、不用重试三遍 → 说明约束够具体。
• ✅ 你能客观说出「干完没干完」 → 说明验收标准明确。
• ❌ 它反复问「你是说 X 还是 Y」 → 目标 / 背景不清。
• ❌ 产出和你想的差很远 → 限制不够。
• ❌ 你不知道「到底干完没」 → 验收缺失。

一句话收官

「Claude Code 提示词怎么写」的全部答案，就一句：不要让它猜你的目标。 把目标、背景、输入、限制、验收这五件事说清楚，它就像在工作；你只给一句情绪化的「优化一下」，它就只能在聊天。

新手第一阶段不用追求一次写完美。第一次写得粗，跑完看哪里出问题；第二次补边界；第三次把固定规则沉淀进 CLAUDE.md。提示词是可以迭代的——真正成熟的提示词，不是第一版就漂亮，而是经过真实任务验证后越来越少废话。

如果这篇你只想记一件事，就记那张五件套总表：目标 + 背景 + 输入 + 限制 + 验收。 把它变成肌肉记忆，你和 Claude Code 的协作就稳了。

相关阅读

• Claude Code 是什么？新手一篇看懂这个编程代理 —— 还没搞清 Claude Code 到底是什么，先看这篇打底。
• Claude Code 完整学习指南：核心知识点 + 学习路径 ⭐ 整个 Claude Code 系列的中枢页，告诉你按什么顺序学。
• CLAUDE.md 怎么写？项目记忆文件新手完整指南 —— 把提示词里每次重复的规则，沉淀成项目自动加载的记忆文件。
• Claude Code thinking 思考模式指南
• Claude Code 三入口怎么选？App、CLI、IDE 区别 —— 同一套提示词在三个入口都能用，先选对入口。
• vibe coding 是什么？讲清氛围编程能不能用、适合谁 —— 把需求说清楚交给 AI 执行，正是 vibe coding 的核心动作。

• OpenAI Codex 提示词工程指南 —— 同类工具的对应专题，对照看更完整。

外部参考（按本文引用顺序）：

• Claude Code 官方文档 —— 产品总入口与最新事实来源（官方域名已是 code.claude.com）。
• Claude Code Best Practices —— 「验证是回报最高的单件事」「先探索再计划后编码」「具体上下文」「让 Claude 先访谈你」等最佳实践原文。
• Claude Code Permission Modes —— Plan Mode 怎么开（Shift+Tab / /plan / --permission-mode plan）、批准计划后的选项、检查点等官方说明。
• Claude Code Memory（CLAUDE.md） —— CLAUDE.md 加载规则、@path 导入语法的官方说明。

📚 更多 Agent 编程方法论：Agent 编程方法论：不教工具教方法，让 AI 按你的规矩干活