原来我一直在像猴子一样使用Claude Code

看着Anthropic的两个工程师24分钟的演讲，然后意识到我一直在像猴子一样使用Claude Code

最近，X（原Twitter）上一段长达24分钟的Anthropic工程师内部分享视频在AI圈引发了疯狂转发。

它拆解了在实际复杂业务中，应该如何调教和指挥Claude完成高难度任务。很多开发者看完后直呼：“原来我过去用大模型的方式都太糙了，那根本不叫写提示词，只是在闲聊。”

如果你还在抱怨AI“不够聪明”、“总是在关键时刻掉链子”，那么这篇基于官方工程师分享的深度长文，将为你重塑对大模型交互的认知。

一、 核心认知重塑：提示词工程绝不是“用自然语言描述需求”

很多人对提示词工程（Prompt Engineering）存在一个致命的误解：认为只要用清晰的日常英语（或中文）把要做的事情描述出来就可以了。

Anthropic工程师在开篇就无情地打破了这种幻想：仅仅用自然语言描述事物是行不通的。

【深度洞察】：真正的提示词工程，本质上是一种“系统工程”（Systematically crafting）。它要求你精心打磨清晰的指令（Instructions）、严密的上下文（Context）以及高度结构化的框架（Structure），才能获得极其稳定的LLM输出。在企业级应用中，我们要的是99.9%的可靠性，而不是偶尔一次的“表现惊艳”。

二、 真实业务挑战：当AI把“车祸现场”看成“滑雪事故”

为了证明这一点，工程师展示了一个极具挑战性的真实商业案例：瑞典保险公司的AI理赔系统。

在这个业务场景中，AI需要同时分析：

1. 充满专业术语的交通事故理赔表单。
2. 客户手绘的、极其潦草的车祸现场草图。最终，AI需要综合两者信息来判断“是谁的责任”。

【翻车现场】：当工程师使用简单的提示词（Simple prompts）让Claude去分析时，彻底翻车了——Claude竟然产生幻觉，把两辆车相撞的草图，识别成了一场“滑雪事故”。

【实操启示】：迭代是关键（Iteration is key）。 不要指望第一版提示词就能解决复杂业务。当你发现AI理解偏差时，这说明你的“上下文边界”没有划定清楚，必须通过不断打磨指令来收拢AI的发散性思维。

三、 官方盖章的“黄金提示词结构”

既然简单的描述行不通，那应该怎么写？Anthropic工程师给出了一套经过无数次测试的“完美框架结构（Ideal Structure）”。

建议大家直接把这个结构刻在DNA里，它由五个循序渐进的模块组成：

1. 角色与任务（Role/Task）：先给AI定调（例如：“你是一个拥有20年经验的瑞典交通理赔专家”）。
2. 上下文内容（Content）：清晰地提供需要分析的数据源（包含表单文本、现场图片等）。
3. 分步指令（Step-by-step instructions）：不要给一个大目标，而是拆解成SOP（标准作业程序）。
4. 参考示例（Examples）： 给出几个标准的输入输出案例。
5. 关键提醒（Key reminders）： 在提示词的最后，强调最重要的限制条件（比如“不要随意假设”）。

四、 性能优化的隐秘角落：静态信息前置与XML标签的妙用

在掌握了骨架之后，如何让Claude跑得更快、更稳？视频中提到了两个极具可行性的高阶技巧：

1. 将“静态细节”塞进系统提示词（System Prompt）

在瑞典保险的案例中，理赔表单的格式是固定的：总共有17个复选框、特定的瑞典语理赔术语、固定的排版布局。

【可行性操作】：千万不要把这些每次都不变的规则放在用户对话（User Prompt）里。把它们全部提取出来，放进System Prompt中。这不仅能让AI的输出保持高度的一致性（Consistency），还能大幅提升处理速度（Speed）并节省Token。

2. 疯狂使用 XML 标签（Use XML tags heavily）

这是Claude用户必须掌握的独门秘籍。Claude的底层训练极其偏爱XML这样的结构化格式。

不要用连篇累牍的段落来区分指令，而是用 <instruction>...</instruction>，<input_data>...</input_data> 将不同的部分隔开。这能让Claude的大脑形成清晰的“逻辑分区”，极大地提升推理的清晰度和输出的规范性。

五、 降维打击：多模态下的“少样本提示”（Few-Shot）

当业务中存在大量模棱两可的“边缘情况（Edge cases）”时该怎么办？

【深度洞察】：单纯的规则描述是苍白的。视频指出，少样本提示（Few-shot examples）是降低错误率的终极武器，甚至对于图片（Images）也同样适用。

【实操建议】：在提示词中，直接喂给Claude 2到3个“极难判断的边缘案例”，并附带人类专家的分析过程和最终结论。这种“打样”行为，能让错误率呈指数级下降（Reduce errors dramatically）。

六、 防御性设计：杜绝AI幻觉的“三板斧”

在金融、医疗、保险等严肃场景，AI的“幻觉（Hallucinations）”是致命的。工程师给出了防范幻觉的三个强制性规范：

1. 建立认怂机制： 明确在提示词中命令Claude——“如果不确定，请直接说‘我不知道（I don’t know）’”。
2. 证据驱动型自信： 限制Claude的表达语气。只有在能从表单或图片中找到明确证据（Clear evidence）时，才允许它输出事实并保持自信。
3. 强迫“深思熟虑”： 要求它在给出结论前，必须一步步写出思考过程（Think step-by-step），让“思考过程”作为结论的护城河。

七、 逻辑顺序决定最终成败

最后，工程师强调了一个常常被开发者忽略的细节：指令的逻辑先后顺序（Logical order matters）。

在大模型的世界里，先看什么、后看什么，直接决定了它的注意力分配。在车祸理赔案例中，正确的顺序应该是：

• 第一步： 先分析结构化的理赔表单（获取基本事实和数据）。
• 第二步： 再去看那张潦草的手绘草图（将事实与图像进行印证）。
• 最后一步： 按照极其严格的XML格式（Strict XML），输出最终的责任判定结果。

如果顺序反过来，先看草图，AI很容易立刻陷入无端的脑补，从而影响对后续表单事实的判断。

结语：从“聊天者”到“架构师”

这向我们揭示了一个残酷的事实：AI本身并不总是一个魔法棒，它更像是一台马力强劲的超级引擎。

如果你只是用日常语言对它喊话，就等于用手推车去拉这台引擎；只有当你学会使用系统框架、XML标签、防幻觉机制和逻辑拆解时，你才真正为这台引擎装上了方向盘和传动轴。

是时候升级你的提示词工程思维了——别再把大模型当人来“聊天”，而是把它当作一个系统去“架构”。