Anthropic 工程师说他们很少从零写提示词？那他们在干啥？

“Anthropic 应用 AI 团队的工程师 Margot Van Laar 在 Code with Claude 大会上做了一个分享。 她没有讲"如何写一个好的提示词"。她讲了一个更反直觉的观点：我们很少从零写提示词，大部分时间是在调试和维护已有的生产提示词。 两个真实的生产场景案例，和一个让我重新理解"提示词工程"的方法论。 我是大树，一个差点开始放弃折腾的AGI学习与实践者。 最近在探索和从事的事儿：

• AI智能体生态研究
• AI 安全与信任链

欢迎大家关注微信公众号 做棵大树，有想要长期联系的朋友也可以通过公众号菜单栏找到我~ ”

先说那件让我"等一下，你是说……"的事。

市面上几乎所有"提示词教程"都在教你同一个东西——从零写一个完美的提示词。

结构、格式、框架、技巧。一堆方法论，让你觉得提示词工程是一门从零开始的创作。

Margot Van Laar 在台上说了一句话，直接打脸了这套叙事：

“"我们很少从零写提示词。大部分时间，我们都在调试和维护已有的生产提示词。" ”

她不是某个博主。她是 Anthropic 应用 AI 团队的工程师。她每天都在生产环境里写提示词——那些真正被用户用、真正影响产品体验的提示词。

她分享的两个场景，每个都有数据、有细节、有翻车教训。

读完这篇文章，你可能不会再用同样的方式写提示词了。

场景一：客服机器人——"禁止列表"是旧模型的遗毒

第一个案例：一个客服机器人。

这个客服机器人跑了一套生产提示词，已经在线上运行了很长时间。一切正常，直到——

模型升级了。

换了更强的模型之后，客服机器人的回答质量反而下降了。用户反馈说"太机械了"，转化率掉了。

Margot 的团队花了几天排查，最后发现问题出在提示词里一段不起眼的指令：一个"禁止列表"。

“这个列表是三年前加上去的。当时用的是旧模型，新模型对某些表达方式过度拟合——它把"禁止说这些话"的规则理解成了"这些话永远不能说"，导致输出极度保守。 ”

他们做了两件事：

第一，用 XML 标签把提示词结构化。

不是用一堆大段的自然语言指令堆在一起，而是用 <system>, <instructions>, <constraints> 这样的标签把不同部分的指令隔离开。这样模型能更清晰地理解"哪些是规则，哪些是示例，哪些是例外"。

打个比方：你以前给员工发了一封 5000 字的邮件，告诉他什么能做、什么不能做、怎么做。然后换了个新员工——他不是故意不看邮件，而是 5000 字的信息密度超过了他的处理能力。

XML 标签的作用就是把 5000 字的邮件拆成一份员工手册：有目录、有分类、有优先级。

第二，移除那个"禁止列表"。

新模型不需要这个列表了。甚至这个列表本身就是个问题——它告诉模型"不要做 X"，但模型反而更关注 X，产生过度防御的行为。

移除之后，客服机器人的回答质量恢复了。

“这件事教会了她一个生产环境里的核心原则：提示词不是写完了就完事的东西，它是会"老化"的。 模型升级了，提示词也要跟着变。 ”

场景二：零售排班 Agent——"拆成三步"比"写一个完美的"更稳定

第二个案例更有趣：一个从零开始构建的零售排班 Agent。

这个 Agent 的需求是：根据门店的人流量预测、员工偏好、法律法规（比如每人每天最多工作 8 小时），自动生成最优排班表。

听起来很简单对吧？

但排班问题的搜索空间非常大——10 个员工、5 个门店、7 天，组合数量就超过了 10 的 20 次方。让一个语言模型"一次性"解决这个问题，成功率极低。

“Margot 的团队试了几十个不同的提示词写法，没有一个稳定的。后来他们换了一个思路：不写一个"完美的"提示词，写三个"简单的"提示词。 ”

三步法：生成 → 评估 → 修复

他们把排班 Agent 拆成了三个独立的提示词，每个只做一件事：

Step 1：生成提示词

告诉模型排班规则，让它生成一个初始排班表。简单、直接、不复杂。

Step 2：评估提示词

用一个专门的提示词，检查生成的排班表是否符合所有规则——工作时间有没有超、员工偏好有没有违反、门店人力够不够。

Step 3：修复提示词

如果评估发现问题，用另一个提示词让模型"修复"问题部分，而不是从头再来。

“关键洞察：一个复杂的任务，如果拆成"生成→检查→修复"三步，每一步只让模型做一件简单的事，比让模型"一次性做对"要稳定得多。 ”

生成→评估→修复：复杂任务的三步解法

生成→评估→修复：复杂任务的三步解法

而且这个案例里，他们选的是 Opus——不是因为它聪明，而是因为排班问题需要很强的逻辑推理能力，Opus 在逻辑推理上的表现优于其他模型。

“这里还有一个重要的实践细节：用不同的模型做不同的步骤。 生成可以用便宜的快速模型，评估和修复用更强的推理模型。成本可控，效果稳定。 ”

"评估是唯一严谨的方式"

整场分享里，Margot 反复说的一句话：

“"评估（Eval）是唯一严谨的方式。没有评估就是碰运气。" ”

这不是口号。她说的"评估"不是模糊的"看看效果好不好"，而是一套系统化的测试方法：

• 每个提示词版本发布前，用一套固定的测试用例跑一遍
• 记录每个用例的成功率、响应质量、延迟
• 模型升级后，用同一套测试用例回归测试
• 如果某个用例的表现下降，立刻知道是"模型的问题"还是"提示词的问题"

“用她自己的话说：**"你在生产环境里维护提示词，不是在写小说。写小说改完了就完了。维护提示词，每次改完你都要知道——哪个变好了，哪个变差了，为什么。"** ”

这其实就是软件工程里的"测试驱动开发"在提示词工程上的翻版。

你写代码的时候，不会写完就跑——你会写单元测试。每次修改代码，先跑一遍测试，确保没有引入回归。

提示词也是代码。只是它的"代码"是自然语言。

你立刻能用到的三个方法

说了这么多，回到你身上。你每天用 AI 写东西、做分析、跑流程——以下三个方法，今天就能用上：

XML结构化 + 三步拆分 + 回归测试

XML结构化 + 三步拆分 + 回归测试

方法一：给你的提示词加"标签"

不管你是用 Claude、GPT 还是别的模型，把你的提示词用 XML 标签结构化。

试试这样写：

<system>
你是XX领域的专家助手。
</system>

<instructions>
你的任务是：...
第一步：...
第二步：...
</instructions>

<constraints>
- 不要说"仅供参考"
- 不要用"首先、其次"
- 字数不超过800字
</constraints>

<examples>
用户：...
助手：...
</examples>

“这看起来多写了 5 行，但效果天差地别。模型对结构化指令的遵循度远高于对大段自然语言指令的遵循度。 ”

特别是 <constraints> 部分——Margot 的客服案例里，"禁止列表"导致模型过度防御的问题，用结构化标签+正向指令可以大幅缓解。

方法二：复杂任务拆成"生成-评估-修复"

如果你的任务超过 3 个步骤，不要写一个"全能提示词"让它一次性完成。

拆成三步：

1. 生成：让模型产出初稿
2. 评估：让模型（或另一个提示词）检查初稿是否符合要求
3. 修复：让模型根据评估结果修正

你可以用代码里的多轮对话来实现，也可以用工作流工具（n8n、Dify 等）串联三个独立的 API 调用。

这个方法的本质是把"一次大考"拆成了"三次小测"。 模型每次只需要集中处理一件事，出错率大幅下降。

方法三：给提示词加"回归测试"

你每次修改提示词之前——不管改了什么——用一组固定的输入跑一遍，看看输出有没有变差。

不需要复杂工具。简单到一个 Excel 表格就够了：

每周跑一次。你会发现：有些提示词看着没问题，数据一跑，问题全出来了。

“这不叫"过度工程"。这叫"在生产环境里做事的专业方式"。 ”

写提示词，本质上是在设计一个系统

回到 Margot 整场分享的核心观点。

提示词工程不是"写好一段文字让模型听你的"。

提示词工程是设计一个系统——这个系统包含指令、约束、示例、评估。模型是这个系统的"执行者"，但你不能只信任执行者。你要设计一整套机制来验证执行结果对不对。

提示词工程 = 设计一个系统

提示词工程 = 设计一个系统

“就像你建一座桥。你不会只信任"材料好"——你会设计承重测试、抗震测试、疲劳测试。 ”

提示词也一样。你设计了一组指令，但不能只信任"模型聪明所以能听懂"——你要设计 eval，让它反复证明自己在各种场景下都听得懂。

这才是生产环境里真正的"提示词工程"。

更大的视角：为什么"不要从零写"

最后一件事我想聊点更宏观的。

Margot 说"我们很少从零写提示词"——这句话背后有一个更深的趋势：

AI 产品的核心壁垒，正在从"你会不会用模型"转移到"你会不会维护一套生产系统"。

一个能写得一手好提示词的人，在半年前可能很有竞争力。但在生产环境里——你的提示词每天都要跑几千次请求、每个模型升级都要回归测试、每个用户反馈都可能暴露一个边缘 case——这时候"会写提示词"不再是一门手艺，而是一个系统。

Anthropic 自己的工程师都在说"大部分时间在调试和维护"，这意味着什么？

“意味着**"提示词写得漂亮"不是核心竞争力，"能持续维护一个让提示词持续有效的系统"才是。** ”

你花 3 个小时从零写一个"完美提示词"，不如花 3 个小时设计一套"让我知道提示词什么时候开始变差"的 eval 机制。

因为变差一定会发生。模型升级会变差。用户行为会变。数据分布会变。

一个需要被维护的系统，比一个完美的提示词，才有真正的价值。

“写完这篇文章我又想了想。 我们这代人从小被教育"从 0 到 1"——从零开始创造、从零到一创业、从零到一写作。 但 AI 时代真正值钱的能力，可能是"从 1 到 1.01"——持续微调、持续评估、持续优化。 不是从零开始的创造力。是从已有基础上持续迭代的能力。 这可能才是提示词工程真正想教我们的事。 ”

如果这篇文章对你有一点启发：

• 💬 欢迎在 评论 区聊聊——你的提示词是怎么维护的？有没有翻车经历？
• 👍 点个赞/爱心，让我知道这类内容有人看
• 🔁 收藏/转发，如果觉得"评估是唯一严谨的方式"这句话对你有用

你的每次互动，都是我继续写实战内容的动力。

推荐阅读

我用 Remotion 剪了一个口播视频，感触甚多

创业者和产品经理的能力又要增强了：Notion × Cursor，开发入口正在从 IDE 移出

为什么不建议让AI用你不熟悉的语言和框架？