04 · 怎么和 AI 说话

翔宇一开始也在网上搜最佳提示词模板，照着抄，有时有效有时没效。后来想明白了——模板不是重点，你给 AI 的信息才是。一旦把注意力从怎么措辞转到给什么信息，一切都清楚了。——翔宇

1. 一个 40 秒和一个 5 秒

你对 Claude Code 说：帮我优化这段代码。

它改了。你一看——变量名全换了，加了一堆你不需要的注释，还把一个函数拆成了三个。方向完全不是你想要的。你重新解释，它再改，又错。来回 40 秒没办法继续干活。

现在换一种说法：这段代码有内存泄漏问题，请找出泄漏点，重点关注数据库连接和文件句柄，给出修复方案，不要重命名变量也不要拆分函数。

同一个 AI，同一段代码，这次的输出精准得像换了一个人。5 秒钟你就能继续往下干。

发生了什么？AI 没变，代码没变。唯一变了的是你输入的信息。第一次你给了一个模糊方向（优化），第二次你给了精确目标（找泄漏）+ 范围（数据库 / 文件句柄）+ 期望产出（修复方案）+ 边界（不重命名、不拆分）。

2. 模型不读心

如果只能记住一句话，记这一句：模型不读心。

它没办法猜你脑子里那个具体场景。它只看到你输入的那些字。你脑子里清楚但没说的部分——它当成自由发挥的空间。

flowchart LR
    Brain["🧠 你脑子里<br/>真实想要的"]
    Words["⌨️ 你打出来的字<br/>只是一部分"]
    AI["🤖 模型基于字推断<br/>缺失部分用最可能的填"]
    Output["📦 输出<br/>跟你想要的差距 = 缺失部分"]

    Brain -.信息丢失.-> Words
    Words --> AI
    AI --> Output

    Brain -.->|对照差距| Output

    style Brain fill:#dcfce7,stroke:#22c55e
    style Words fill:#fef3c7,stroke:#f59e0b
    style AI fill:#dbeafe,stroke:#3b82f6
    style Output fill:#fee2e2,stroke:#ef4444

这就是为什么信息越精确，输出越精准。不是提示词模板的功劳，是信息量的功劳。

3. 信息四件套

要让模型有能力做你想要的事，每条指令本质上要给 4 类信息。这 4 类构成一套可调的工程语言：

把开头那两个例子拆成四件套对比：

差别不在措辞——在信息量。

4. 把模糊变具体的 3 个杠杆

知道了四件套，怎么让每件都变具体？三个杠杆：

杠杆 1 · 把抽象动词换成可验证动词

判断标准：动词要能验证——做完了能不能客观判断完没完？模糊动词做不完，具体动词做完了能跑测试。

杠杆 2 · 给显式范围（路径 / 表 / 时间 / 数量）

显式范围让模型不需要猜——它直接照着做。

杠杆 3 · 显式说出隐含约束

每个项目都有人人都知道但没人写下来的约定。模型没法靠常识猜出来。

• 我们这个项目所有 API 必须返回 { data, error } 结构 → 写进 CLAUDE.md（03 篇）或临时说明
• 测试不要 mock 数据库 → 写进 CLAUDE.md，否则每次都要提醒
• 这个函数虽然看起来简单但有 3 个隐藏调用方 → 临时上下文必须写
• 这段代码 2 周后要重构，临时方案别太完美 → 边界

每次纠正 Claude，都是在补这一类隐含约束。补一次写进 CLAUDE.md，比补十次省心。

5. 何时用结构化提示

正常对话——四件套用自然中文写下来，够了。

但长指令、复杂任务、多步骤——结构化能让模型更稳定。

<task>修复支付回调幂等性 bug</task>

<context>
- 文件：controllers/webhook.ts、queue/retry.ts
- 现象：webhook 重试时 transaction 创建多次
- 已知线索：retry.ts 第 34 行没读 idempotency_key
</context>

<constraints>
- 不改 controllers/webhook.ts 的对外接口
- transaction 表 schema 不动
- 修复 diff < 100 行
</constraints>

<acceptance>
- 跑 tests/payment/retry.test.ts 全过
- 手动跑 scripts/replay-webhook.sh 重放 3 次只创建 1 个 transaction
- 不引入新依赖
</acceptance>

XML 标签是事实标准（Claude 系列对它训练得最熟）。4 个标签对应 4 件套——目标、上下文、边界、验收。

什么时候不用 XML：日常 1-2 句的对话不要用 XML 包裹（噪音大于信号）。指令长度超过 200 字、或要求 ≥ 3 个独立约束时，结构化才有收益。

6. 跟人说话 vs 跟 Claude 说话

很多人觉得跟 Claude 说话像跟实习生说话。这个比喻 80% 对——但有 20% 关键差异：

结论：跟 Claude 说话前置成本更高——你得提前说清楚，因为它不会问你。但你说一次，写进 CLAUDE.md，以后不用再说。这是值得的交易。

7. 一个反复有效的工作流

把上面所有内容串成一个可重复的工作流：

flowchart TD
    Start["📝 写一条指令"]
    Check{"4 件套<br/>都给了吗？"}
    Run["▶️ 跑一遍 Claude"]
    OK{"输出方向<br/>对吗？"}
    Done["✅ 收工"]
    Diag["🔍 诊断<br/>哪一件套缺了？"]
    Fix["✍️ 补缺失的"]
    Save{"是不是<br/>项目级规则？"}
    CLAUDE["📜 写进 CLAUDE.md"]

    Start --> Check
    Check -->|是| Run
    Check -->|否| Fix
    Run --> OK
    OK -->|对| Done
    OK -->|不对| Diag
    Diag --> Fix
    Fix --> Save
    Save -->|是| CLAUDE
    Save -->|否| Run
    CLAUDE --> Run

    style Done fill:#dcfce7,stroke:#22c55e
    style CLAUDE fill:#dbeafe,stroke:#3b82f6
    style Diag fill:#fef3c7,stroke:#f59e0b

第一次问 → 检查 4 件套齐不齐 → 跑 → 不对就诊断哪件套缺了 → 补 → 如果是项目级规则就写进 CLAUDE.md → 再跑。

跑通几个周期后，CLAUDE.md 越写越完整，你给 Claude 的指令会越来越短——因为公共上下文都已经在文件里了，每次只需要补这次任务特有的目标 + 范围 + 边界。

8. 检验你真懂了吗

接下来去哪

不用按顺序全读。挑你最好奇的那条线走就行。