04 · 怎么和 AI 说话
翔宇一开始也在网上搜「最佳提示词模板」，照着抄，有时有效有时没效。后来想明白了一件事：模板不是重点，你给 AI 的信息才是。一旦把注意力从「怎么措辞」转到「给什
翔宇一开始也在网上搜「最佳提示词模板」，照着抄，有时有效有时没效。后来想明白了一件事：模板不是重点，你给 AI 的信息才是。一旦把注意力从「怎么措辞」转到「给什么信息」，一切都清楚了。——翔宇
要点速览
- 你将理解为什么同一个问题换一种说法结果天差地别——关键在信息结构
- 你将学会对话设计的三个层次：具体的任务、充足的背景、合理的节奏
- 你将理解 XML 结构化思维为什么有效
- 你将理解为什么「说目标」比「说步骤」更能发挥 AI 的能力
1. 从一句话开始
我们从最简单的情况开始。
你对 Claude Code 说：「帮我优化这段代码。」
它改了。你一看——变量名全换了，加了一堆你不需要的注释，还把一个函数拆成了三个。方向完全不是你想要的。
现在换一种说法：「这段代码有内存泄漏问题，请找出泄漏点，重点关注数据库连接和文件句柄，给出修复方案。」
同一个 AI，同一段代码，这次的输出精准得像换了一个人。
发生了什么？AI 没变，代码没变。唯一变了的是你输入的信息。第一次你给了一个模糊的方向（「优化」），第二次你给了精确的目标、范围和期望产出。
🧠 底层逻辑 AI 是在「基于你提供的信息做推断」。信息越模糊，它能推断的方向越多——每个方向都「合理」，但大多数不是你想要的。信息越精确，它被引导到正确方向的概率越高。这不是理解力问题，是信息量问题。
这就是对话设计的起点。接下来我们一层一层搭建——从最基础的具体性，到背景信息，到完整的对话策略。
2. 第一层：把任务说具体
如果只能记住一条对话设计的原则：具体胜于模糊。
看两个例子：
「帮我修 Bug。」—— Bug 是什么？在哪个文件？表现是什么？复现步骤？Claude 需要猜这一切。
「修复 src/auth/login.js 中的登录 Bug，用户输入错误密码后会看到空白屏幕而不是错误提示。」—— 文件路径、问题现象、预期行为，全都有了。
差别在哪？第二个版本多了三类信息：做什么（修 Bug）、在哪里（src/auth/login.js）、具体表现（空白屏幕而非错误提示）。
这三类信息是一个万能框架。不管让 Claude 做什么任务，只要提示词包含了这三点，质量就会显著提升。
🎯 一句话理解 做什么 + 在哪里 + 具体表现。三个维度，覆盖大多数场景。
想一想你平时给 Claude 的指令，有没有缺少其中某一点的？缺了哪一点，Claude 最可能在哪个方向跑偏？
3. 第二层：补上背景信息
任务说清楚了，还不够。Claude 再聪明，也不知道你没告诉它的事情。
比如你让它写一个缓存功能。它给你写了一个基于 Redis 的方案——代码很好，但你的项目根本没装 Redis，也不打算装。
这不是 Claude 的问题。它不知道你没有 Redis。
背景信息包含四个维度：
技术栈。 你用什么语言、什么框架、什么版本。不同版本的 API 可能完全不同。
约束条件。 性能要求、兼容性要求、安全要求。比如「不能引入新的依赖」「必须兼容 Node.js 16」。
已经试过的方案。 如果你已经试了某个方法没用，告诉 Claude——否则它可能重新建议同一个方法，浪费双方时间。
为什么要做这件事。 这是最容易被忽略的。你告诉 Claude「把这个函数的返回类型从 string 改成 number」，它照做了。但如果你说「因为下游需要做数值计算，所以返回类型要从 string 改成 number」——Claude 除了改类型，可能还会注意到下游有一个隐式类型转换的 Bug，一并帮你修了。
🎨 打个比方 给背景信息就像看病时告诉医生你的病史。医生问「以前得过什么病？吃过什么药？对什么过敏？」不是闲聊，是因为这些信息直接影响治疗方案。你给 Claude 的背景也一样——它影响的是解决方案的方向。
4. 第三层：控制对话节奏
任务具体了，背景也给了。现在加第三层：一次只做一件事。
这条解释起来最简单，实践中最难做到。人有一个心理倾向：既然 AI 这么强大，一次多交代几件事吧，省得来回跑。
「帮我重构这个模块，顺便写单元测试，再加上 API 文档，最好还能优化一下性能。」
结果 Claude 给了一大段代码，重构了一半，测试写了几个但不完整，文档一笔带过，性能完全没碰。
回到上下文窗口的概念（第 2 篇）。Claude 在一次回答中能投入的「注意力」是有限的。同时交代四件事，每件只分到 25% 的注意力。四件事都做了，但没一件做好。
正确的做法是拆分：
第一轮：「分析这个模块的结构，告诉我哪些地方需要重构。不要写代码，只做分析。」
第二轮（确认分析后）：「好的，开始重构第一个部分。」
第三轮（重构完成后）：「给重构后的代码写单元测试。」
每一轮 Claude 只专注一件事，质量自然上去了。
🔑 关键点 「不要写代码，只做分析」这句话非常关键。不加这个约束，Claude 会直接开始写代码——跳过分析和规划阶段。明确告诉 Claude「这一步做什么、不做什么」，是控制质量的重要手段。
5. 给目标，不给路径
三个层次搭完了。现在讲一个贯穿三层的原则，它能进一步释放 Claude 的能力。
很多人给 Claude 的指令是这样的：
「第一步，读取 config.json。第二步，解析 JSON。第三步，提取 database.host 字段。第四步，用这个 host 创建连接……」
每一步都规定好了。看起来很周到，但效果往往不好。
因为 Claude 可能知道更好的方法。比如它知道连接池比单个连接更高效，但你的步骤里没提到连接池——它就不会用。你规定了路径，也限制了它发挥的空间。
更好的方式是告诉它为什么：
「我需要从配置文件读取数据库连接信息并建立连接。要求：支持连接失败重试（最多 3 次）、有清晰的错误提示、代码要易于测试。」
你给了目标和约束，没有规定具体步骤。Claude 有空间选择最优实现——而它作为当前最强的代码模型之一，选择通常不差。
当然有例外：如果你对实现方式有明确要求——比如安全规范要求必须使用特定加密库——那就直接说清楚。关键是区分「我有明确要求」和「我只是习惯了一种做法」。
💬 通俗讲 你是领导，不是微管理者。好的领导说「一周内把注册成功率从 60% 提到 90%」，让团队决定怎么做。坏的领导说「周一改按钮颜色，周二调表单布局」。给 Claude 发挥空间，它能做得比你规定的更好。
6. 用结构组织复杂信息
前面讲的三个层次是内容层面的。当任务变复杂——多个维度的信息交织在一起——形式上也需要一个工具：XML 标签。
Claude 对 XML 标签特别敏感。你可以用标签把不同类型的信息分隔开。
不用标签时：
「帮我写一个用户注册功能，用 TypeScript，要有邮箱验证，密码至少 8 位，不使用第三方验证库，错误信息用中文。」
所有信息挤在一段话里。Claude 需要自己判断哪些是需求、哪些是技术约束、哪些是格式要求。
用标签后：
<task> 用户注册功能 </task> <tech> TypeScript + Next.js 16 </tech> <requirements> 邮箱格式验证；密码至少 8 位，含大小写和数字 </requirements> <constraints> 不使用第三方验证库；错误信息用中文 </constraints>
同样的信息，分成了四个清晰区块：任务、技术栈、需求、约束。Claude 不需要猜每条信息属于什么类别——标签已经告诉它了。
🔍 深入一步 标签名完全自由定义，不需要记「标准标签」。你觉得什么名字最能描述这块信息，就用什么名字。关键不是标签本身，而是「把不同类型的信息分开」这个思维方式。简单任务一句话就够，加标签反而啰嗦。但任务有多个维度时，标签能显著提升 Claude 的理解准确度。
7. 关于礼貌的一个纠偏
这里纠正一个流行的说法：「要对 AI 说请和谢谢，它会表现更好。」
研究表明，过于礼貌的措辞可能让 Claude 进入一种「讨好模式」——更倾向于快速给一个你可能想听的答案，而不是认真深入地分析问题。
「你好，请问能不能帮我看一下这段代码，如果方便的话……」—— 有效信息几乎为零。Claude 花了 token 处理「你好」「请问」「如果方便的话」，但这些都不是它做出好回答需要的信息。
「审查下面的代码，找出潜在的 Bug。」—— 直接、清晰、具体。每个词都承载有效信息。
⚡ 速记 Claude 不需要寒暄。直接、清晰、具体的指令效果最好。你的每一个 token 都应该承载有效信息。
如果礼貌是你的习惯，完全没问题。但要知道，提升输出质量的方法是提升信息质量，不是措辞客气。
8. 三个层次合在一起
用一个完整场景把三个层次串通。
你的项目有一个用户列表组件，数据更新时不重新渲染。
只用一句话：
「组件不渲染了，帮我看看。」
缺了什么？几乎所有有效信息。Claude 只能猜——哪个组件？什么场景？什么框架？
三个层次叠加后：
具体性：「用户列表组件在数据更新时不会重新渲染。」—— 哪个组件、什么问题、什么时候出现。
背景信息：「项目是 React 18 + TypeScript，使用 Zustand 做状态管理。已经试过用 useEffect 监听 state 变化和用 immer 中间件，都没效果。」—— 技术栈、已尝试方案。
节奏控制：「请分析可能的原因，给出 3 个最可能的解决方案。不要直接写代码，先分析。」—— 清晰的任务范围和输出期望。
同一个问题，第二种方式几乎一定得到更好的答案。不是因为 Claude「更听话了」，而是你给了它足够的信息做出准确推断。
🎯 一句话理解 对话设计的核心公式：具体的任务 + 充足的背景 + 一次一事。三个层次叠加使用，效果远大于单独使用。
9. 你真的懂了吗
这篇拆了一个概念：对话设计的三个层次。
费曼检验时间：
- 有人在网上搜「最强 Claude 提示词模板」，你会怎么告诉他这个方向的问题在哪？对话设计的本质到底是什么？
- 「具体性」的核心是三个维度——做什么、在哪里、具体表现。你能用一个你实际工作中的场景，写出一个「模糊版」和一个「具体版」的提示词吗？
- 为什么「告诉 Claude 为什么」比「告诉 Claude 怎么做」通常更有效？什么情况下应该例外？
- XML 标签提升理解准确度的原理是什么？用你自己的话解释——不要说「因为 Claude 对 XML 敏感」，要解释得更深一层。
这篇在概念网络中的位置
前三篇构建了 Claude Code 的信息架构：位置（AI 住在哪）→ 上下文（AI 能看多少）→ 记忆（AI 怎么跨会话保留信息）。
这篇讲的是你和 AI 之间的信息接口——你怎么把信息传递给它。这和前面三篇紧密关联：
- 你的提示词占上下文空间（第 2 篇），所以每个词都要有效
- CLAUDE.md 减少了你在对话中需要重复的背景信息（第 3 篇），让你可以直接进入任务
- 提示词的信息量和上下文窗口的空间是一对博弈——你需要给足信息，但又不能浪费空间
你知道了怎么和 Claude 沟通。但 Claude 不只是一个对话伙伴——它能根据问题复杂度自动调节思考深度。→ 下一篇「思考」
