3.12 提示词进阶
预计耗时：12 分钟
本关任务简报
同一个任务，有人让 Claude 三轮搞定，有人来回十几轮还没对齐。差距不在模型，在于提问方式。
这一关不讲那种"神奇魔法词"——那些东西大多没用。讲的是更底层的原则：如何把一个模糊的想法转化成 Claude 能稳定执行的指令，如何在复杂任务上减少反复沟通的成本，以及如何建立一套让 Claude 越用越顺手的工作方式。
通关奖励：解锁以下技能
- 🎯 能把模糊需求转化成结构化、可执行的指令
- 📋 掌握"先规划再执行"的工作流，减少返工
- 🔧 知道如何给 Claude 足够的上下文而不是让它猜
- 🔄 能用迭代细化的方式稳定提升输出质量
开始前先检查装备
| 前置知识 | 说明 |
|---|---|
| 有一些实际使用 Claude Code 的经验 | 这一关是从真实使用里提炼方法论——最好已经用它做过几个任务，对"什么情况下 Claude 没达到预期"有直觉 |
| 2.7 CLAUDE.md 配置 → | 原则六讲"把偏好沉淀进 CLAUDE.md"，需要知道这个文件是什么 |
机制解析
原则一：说清约束，而不只是目标
大多数含糊的提示词不是因为没说目标，而是因为没说约束。
❌ 帮我优化这个 API 的性能
✅ 帮我优化这个 API 的性能。
约束：不能改数据库 schema，不能引入新的依赖，
要保持向后兼容（现有客户端不用改代码）。
当前 P99 延迟是 800ms，目标是 200ms 以内。约束就是边界。没有边界，Claude 给的方案可能技术上正确但对你完全不适用——然后你还要再解释一遍为什么不行，等于浪费了一轮。
原则二：给上下文"为什么"，不只是"什么"
告诉 Claude 为什么要做这件事，它能做出更好的判断：
❌ 把这段代码里的 async/await 改成 Promise 链
✅ 把这段代码里的 async/await 改成 Promise 链。
原因：这个模块要在一个不支持 async/await 的老旧 Node.js 环境里运行。
要保持功能完全等价，注意错误处理逻辑不能丢失。知道"为什么"之后，Claude 遇到边界情况会做出更符合你意图的决策，而不是机械地执行字面要求。
原则三：先规划，再执行
对于复杂任务，先让 Claude 出方案，你审核后再执行。不要一步到位让它直接改代码。
我想把当前项目的用户认证从 JWT 迁移到 Session Cookie。
先不要动代码，告诉我：
1. 需要改哪些文件？
2. 改动的大致顺序是什么？
3. 有哪些风险点需要注意？
让我确认方案后再开始。这对应 ⏸ plan mode on（Shift+Tab 切换）。在 plan mode 下 Claude 只输出计划，不执行任何工具调用，你确认后再切回普通模式执行。
好处是：把"判断"和"执行"分开——你对判断有完整掌控，执行阶段 Claude 按确认好的路线走，很少跑偏。
原则四：给输出格式，减少猜测
如果你对输出有格式要求，直接说出来：
分析 src/services/ 下所有服务类的复杂度，输出格式如下：
| 服务名 | 方法数 | 最长方法行数 | 复杂度评级（低/中/高）| 建议 |
按复杂度从高到低排序。给我列出三个解决方案，每个方案包含：
- 一句话总结
- 优点（最多3条）
- 缺点（最多3条）
- 实现难度（低/中/高）
最后加上你的推荐和理由。输出格式定好了，你不需要再去整理 Claude 的回答，直接用就行。
原则五：分步细化，而不是一次要求完美
复杂任务先要"够用的版本"，再迭代：
第一轮：要框架
帮我写一个用户注册 API 的骨架，
只需要函数签名、注释说明每步做什么，不用写实现。第二轮：要具体实现
好，现在实现上面骨架里的 validateEmail 和 hashPassword 两个函数。第三轮：要边界处理
现在给 registerUser 加上错误处理：
- 邮箱已存在
- 密码强度不够
- 数据库写入失败分步做的好处：每一步你都能看清楚 Claude 的理解是否正确，及时纠偏，不用等写完一大坨再发现方向不对。
原则六：CLAUDE.md 沉淀你的偏好
经过几次对话，你会发现有些要求需要反复说：比如"总是先规划"、"注释用中文"、"不要为了演示随意引入依赖"。
把这些放进 CLAUDE.md，以后不用每次重复：
## 协作约定
- 涉及改动超过 3 个文件的任务，先出改动计划让我确认，再执行
- 代码注释和变量命名用英文，与用户沟通用中文
- 不要因为"演示方便"引入你自己选的依赖，引入新依赖前必须说明
- 给出多个方案时，先说你的推荐，再列其他选项常见反模式（踩了会浪费时间）
| 反模式 | 问题 | 改进方法 |
|---|---|---|
| 把所有要求堆在一条消息 | Claude 顾此失彼 | 拆成多轮，每轮一个重点 |
| 只说"修一下这个 bug" | Claude 猜症状而不是查根本原因 | 提供错误日志 + 复现步骤 + 期望行为 |
| 对不满意的回答只说"不对，重来" | Claude 不知道哪里错了 | 指出具体哪里不对，说明期望是什么 |
| 一次要求整个项目的架构重构 | 任务太大，Claude 容易失控 | 按模块拆分，逐步推进 |
| 问法太开放（"怎么优化这段代码"） | 浪费时间对齐目标 | 说清优化目标（性能/可读性/测试性） |
难题再叠一层：让它多想
把上面这些原则用好之后，遇到真正烧脑的问题（架构权衡、疑难 Bug），还能再叠加推理深度：在提示词里加 ultrathink 让这一轮多想几步，或用 /effort 把整个会话的推理强度调高。原理和用法见 3.1 扩展思考模式 →。
开始闯关
目标：把你最近遇到的一个让 Claude 没做好的任务，用这一关的方法重新试一次。
第 1 步：找一个之前做得不好的场景
回忆一次 Claude 输出质量让你不满意的情况——它可能没满足你的格式要求、给了不实用的方案、或者需要来回多轮才搞定。
第 2 步：分析差距
对照这几个问题：
- 有没有说清约束？
- 有没有解释为什么？
- 有没有要求先规划？
- 输出格式是否明确？
第 3 步：重新用改进后的提示词试一次
对比两次的输出质量，感受差距。
第 4 步：把常用偏好写进 CLAUDE.md
把这次发现的"需要反复说明"的偏好整理成 1-3 条，加进当前项目的 CLAUDE.md。
通关检定
- [ ] 能在提示词里说清约束（不只是目标）
- [ ] 知道什么时候应该先用 plan mode 出方案、再执行
- [ ] 用过"分步细化"的方式完成一个复杂任务
- [ ] 在 CLAUDE.md 里记录了至少一条自己的协作偏好
- [ ] 知道"只说不对重来"的反模式有什么问题
全部点亮就算通关 ✓
卡关了？翻车指南在这
用了这些原则，但 Claude 还是跑偏了
如果 Claude 在执行过程中偏离了你的要求，不用等它做完——发现偏差就立刻用 Escape 中断，直接说"停，我需要你先确认一下 X"。让它完成一个错误方向的工作再纠正，比在中途纠正成本高得多。
任务太复杂，不知道怎么拆
让 Claude 帮你拆：
这是我要做的事：[描述你的任务]
帮我把它拆成几个独立的、可以分别完成的子任务，按推荐的执行顺序排列。通常它拆得比你想的更细，有时候你会发现某些步骤根本不需要做。
输出每次都不一样，无法稳定
稳定性差的根源通常是提示词里有歧义——Claude 在多种合理解读之间随机选择。把"加强测试"改成"给 src/payment/ 下的每个 public 方法各写一个正常场景测试和一个边界场景测试"，具体了，输出就稳定了。
下一关
提示词优化解决"怎么更好地用 Claude"，下一关解决另一个问题："Claude 出了问题怎么办"——当会话失控、工具反复出错、或者 Claude 坚持做错误的事，应该怎么诊断和处理。