提示词设计原则

提示词设计原则

提示工程不是「念咒」——不是把词儿凑对了就能召唤出想要的结果。它是与 Claude 对话的艺术：你得想清楚要什么、给它够用的弹药、给它验证自己的方式，并在它走偏时及时拉回来。

官方 best-practices 把这套对话艺术拆成了若干条心法。这一篇把它们梳理成八条原则，每条都配真实场景的 Before vs After 对比——你看了能直接抄。

原则 0：上下文是会满的，性能是会退化的

这是地基，必须先说。

Claude 的上下文窗口很大，但不是无限的。每读一个文件、跑一次命令、看一段日志，都在往这块「短期记忆」里塞东西。塞到一定程度（社区作者 Eyad 的经验是 45% 左右就开始退化），它会开始忘事、丢细节、重复探索。

所以一切原则的前提是：带着「上下文会满」的意识去提示。给指令时，能引用文件就别复制粘贴，能让子代理去读大块代码就别让主会话扛着。详见后面的 上下文工程。

原则 1：给 Claude 验证自己工作的方式

官方原话大意：别只让 Claude 写完就说「做完了」，给它一种检查自己工作的方法——测试、构建、截图、linter、脚本。

为什么这条排第一？因为「看起来不错」是 Claude 最危险的失败模式。它会自信地说「我改完了」，但你一跑发现崩了。给它验证手段，就是把「主观断言」变成「客观证据」。

Before	After
帮我修这个 bug	帮我修这个 bug。改完跑一遍 npm test，把输出贴给我看，全绿才算完
重构这块代码	重构这块代码。改完跑 npm run build 确认没编译错误，再跑 lint 确认没警告
做个登录页	做个登录页。改完用 playwright 截张图，把截图给我看

差别就一句话：让它拿出证据，而不是断言成功。这条单独成篇，见 反馈循环设计。

原则 2：先探索，再规划，最后写代码

官方四阶段：Explore → Plan → Implement → Commit。一上来就 Implement，等于没看地图就开车。

# 低阶
帮我实现 OAuth2 刷新令牌

# 高阶
先读 @src/auth/ 摸清现在认证怎么走的，然后进 plan mode 给我方案，
包括要改哪些文件、边界情况、风险点。我点头后再动手。

「先想后做」这件事详见 Plan-first 提示模板。这里只说核心：让 Claude 在只读模式里把方案摆出来，你审完再让它动手，能省掉 80% 的返工。

原则 3：给具体的上下文，而不是模糊的指令

官方建议四件事：scope task（圈定范围）、point to sources（指给来源）、reference patterns（指给参考模式）、describe symptom（描述症状而非结论）。

模糊指令让 Claude 瞎猜，具体指令让它精准命中。

Before	After
fix the bug	登录页输入正确密码点登录，控制台报 401，但网络面板看请求体里 password 字段是空的。怀疑是表单序列化的问题。看 @src/login/form.ts 第 42 行
优化性能	首页加载 lighthouse 跑分 LCP 4.2s，目标是降到 2.5s 以内。瓶颈看起来在 @src/pages/index.tsx 的图片没懒加载
加个错误处理	给 @src/api/user.ts 的 fetchUser 函数加 try/catch，错误时返回 null（参考 @src/api/post.ts 里 fetchPost 的写法）

注意 After 版都做了一件事：圈定范围 + 指给文件 + 描述症状。Claude 不用猜在哪、猜什么、猜怎么改。

原则 4：给丰富的内容（@file、图片、URL、pipe、let Claude fetch）

官方列了一串「rich content」来源：@ 引用文件、贴图片、给 URL、管道喂输出、让 Claude 自己 fetch。

这条和原则 3 是一对：原则 3 说「指给来源」，原则 4 说「来源可以多种多样」。

# 贴图：报错截图、设计稿、UI 截图
> 看这张截图，登录页的按钮和输入框对齐有问题，帮我修 @src/login/LoginForm.tsx

# @ 目录：摸清全貌
> 通读 @src/payment/ 目录，画一份模块依赖图

# 管道：喂日志
cat error.log | claude "总结这个错误日志的根因"

# 让 Claude 自己 fetch
> 用 Bash 跑 curl https://api.example.com/health，把返回结果分析一下

详见 @ 文件引用。核心一句话：别当人肉中转站，让 Claude 直接读、直接拿。

原则 5：配置环境，让规则不用每次重说

官方建议把「每次都要交代的事」写进环境：CLAUDE.md（项目公约）、permissions（权限）、CLI tools、MCP（外接服务）、Hooks（强制规则）、Skills（操作手册）、Subagents（独立工位）、Plugins（插件）。

这是「配一次，永久生效」的思路。

每次都交代（坏）	写进环境（好）
「记得用 TypeScript，不要 any」	写进 CLAUDE.md 的 ## 代码规范
「改完跑 prettier」	挂 PostToolUse Hook 强制跑
「审查时查这三项」	写成 review Skill，让子代理按手册走
「这个项目用 GitHub」	配 GitHub MCP，让 Claude 直接读 PR/issue

环境配好了，对话里就只剩「这个具体任务要做什么」——背景规则已经在墙上了。详见 Skills 深入、Hooks 深入与实战、Subagents 深入。

原则 6：有效沟通——问代码库，让 Claude 反过来采访你

官方两条沟通建议：

• Ask codebase questions——别问「这段代码怎么样」，问「这段代码在哪里被调用、谁依赖它」。
• Let Claude interview you——给它机会反问澄清，而不是逼它基于不完整信息硬猜。

# 坏：问 Claude
> 你觉得这个文件写得怎么样？

# 好：让 Claude 问你
> 我想给支付模块加重试逻辑，但你先问我 3 个问题搞清楚需求，别假设。

第二种问法逼着 Claude 把模糊的地方先问清楚，而不是按它的猜测往下走。这一招在需求不明时特别管用——模糊的需求先对齐，再动手。

原则 7：管好会话——早纠偏、控上下文、用子代理、rewind、resume

官方 best-practices 的 session 管理建议：

• Course-correct early——发现走偏马上拉回，别等写完一大坨再说。
• Manage context——/compact 带聚焦点、/clear 任务间清空、看 /stats。
• Use subagents——重活甩给子代理隔离上下文。
• Rewind——走错了用 /rewind 回退，别硬着头皮继续。
• Resume——/resume 接着干，不用从头交代背景。

具体见 会话管理、上下文管理、/rewind 安全绳。

原则 8：自动化与扩展

官方建议把流程规模化：

• Non-interactive——headless 模式跑脚本。
• Multiple sessions——多会话并行。
• Fan out——派多个子代理并行干活。
• Auto mode——放开权限让它自己跑。
• Adversarial review——对抗式审查，派一个不同意它的子代理挑刺。

这条不是新手关心的，但等你用熟了会发现：单会话手工指挥能做的事，多会话自动化能做十倍。详见 Headless 模式、Agent Teams 多代理。

培养你的直觉

官方最后一条建议：Develop your intuition。

提示工程不是背口诀，是练出「直觉」。八条原则读一遍没用，得在日常用里反复试：

• 这次提示让 Claude 走偏了？想想哪句话该改。
• 这次它一气呵成？记住这个 prompt 的结构。
• 这次上下文爆了？看看 /stats 哪步烧的。

每次复盘一点点，几个月下来你就能凭直觉判断：什么任务该 plan、什么该拆、什么该甩给子代理。这时候你不再「照着清单用」，而是「按感觉用」——而感觉对了，才是真会了。

Before vs After 总览

把八条原则的精髓压成一张表：

维度	Before（新手）	After（高手）
验证	「改完了」	「跑过测试，输出贴给你看」
探索	直接让它写	先 Explore 摸清现状
上下文	模糊「fix the bug」	圈范围、指文件、描述症状
内容	复制粘贴	@ 引用、贴图、管道、fetch
环境	每次交代规则	写进 CLAUDE.md/Hooks/Skills
沟通	命令式	让 Claude 反问澄清
会话	一路写到底	早纠偏、控上下文、用 rewind
规模	单会话手操	多会话、子代理、auto mode

一句话总结

提示工程是「与 Claude 对话的艺术」：给验证方式、先探索再写、给具体上下文、给丰富内容、配置环境、有效沟通、管好会话、自动化扩展。八条心法背一遍没用，在日常用里练成直觉才算会。

---

下一步，去看 Plan-first 提示模板——原则 2「先探索再写」的深度拆解。🚀