提示词工程实战：维护、调试与评估

来源：Anthropic 应用 AI 团队工程师 Margot Van Laar 在 Code with Claude 大会的分享。
核心观点：我们很少从零写提示词，大部分时间都在调试和维护已有的生产提示词。

一、场景一：客服机器人提示词维护

1.1 第一步不是改内容，而是结构化清理

团队接手一个已经在跑的提示词后，第一步是用 XML 标签把不同部分拆开：

<role>：角色定义
<policy>：可执行的政策
<tone>：语气要求
<guidelines>：操作指南
<output_format>：输出格式

这样做的好处是：每个部分职责清晰，后续改动不会牵一发而动全身，也更容易做版本对比和回归测试。

1.2 经典陷阱：旧模型的”禁止列表”会拖累新模型

团队曾为旧模型加了一条指令：”不要告诉用户某些信息”。旧模型能力不够，需要这种硬性约束。但换到新模型后，同样的指令导致模型过度拟合——它开始隐瞒自己其实可以提供的信息。

更好的做法是定义信息边界：明确”可以公开的信息”和”不得公开的信息”，而不是列禁止项。

1.3 精确计算：给工具，而不是给嘱咐

提示词里写”请仔细计算”基本没用。需要精确计算时，应该让模型调用计算器或代码解释器。工具调用比模型在脑子里算靠谱得多。

1.4 转人工决策：要讲清代价与收益

如果提示词只说”用户不满就转人工”，模型会过度优化这一边，把所有对话都转出去。

正确做法是把两面都说清楚：

转人工的成本是什么（人力、等待时间、用户体验）
不转的风险是什么（问题升级、投诉、流失）

让模型在提示词里自己权衡，而不是被单一信号驱动。

二、场景二：零售排班 Agent 从零构建

2.1 复杂单提示词的失败

团队最初想写一个复杂提示词，把所有逻辑塞进去：生成排班、检查合规、修复违规、优先安排有经验的员工……结果频繁失败。

2.2 更好的方式：生成-评估-修复循环

拆成三个简单提示词：

生成器：只负责根据可用时间和需求生成初步排班表
评估器：只负责检查是否合规
修复器：只负责根据违规项修复排班表

每个提示词只做一件事，组合起来比一个大提示词稳定得多，也更容易定位问题。

三、模型选择：有时候更好的模型更省事

团队测试发现，用更强的推理模型（如 Opus）加自适应思考，效果往往比小模型加复杂提示词更好。

不是所有场景都需要优化成本。有时候，用更好的模型反而最省事——因为你花在提示词工程、调试和回归测试上的时间可能比模型差价更贵。

四、关键原则：没有评估，就是在碰运气

Margot 反复强调一句话：

评估是唯一能告诉你改动是否真正有效的严谨方式。

大部分人改提示词的方式是”感觉这样写更好”，然后上线看效果。但”感觉”不是评估。

你需要一个可量化的基准：

定义成功指标（准确率、用户满意度、转人工率、合规率等）
每次改动后跑一遍测试集
对比改动前后的指标变化

没有评估，就只是在碰运气。

五、简单测试验证

我用 DeepSeek Chat 跑了三个小实验来验证上述观点。

测试1：结构化清理确实让输出更聚焦

非结构化提示词让模型给出较泛的回答（”库存、物流高峰期、订单信息核实”），没有明确下一步。

结构化提示词让模型直接请求订单号，并说明将查询订单状态和物流时效，输出更可预测。

测试2：”禁止列表”导致过度隐瞒

对”退款一般多久到账”：

旧式禁止列表提示词让模型回避具体时间
信息边界式提示词让模型给出银行卡/信用卡 3-7 个工作日、支付宝/微信 1-3 个工作日的具体信息

测试3：单提示词 vs 生成-评估-修复流水线

在只有 3 名员工、班次需求较高的情况下：

单提示词虽然分析了约束，但最终排班仍有违规，且”自动修复”没有真正解决问题
流水线把问题显式拆出来：生成器产出初步方案，评估器识别超时和连续工作违规，修复器明确指出”现有员工数量下无法同时满足所有规则”

即使最终没有完美解，流水线的透明度和可调试性都更好。

六、 takeaway

生产提示词的核心工作是维护，不是从零创作。
结构化清理是维护的第一步，XML 标签能让提示词更可读、可改、可测。
警惕为旧模型写的补丁，它们可能在新模型上产生反效果。
精确任务交给工具，不要让模型硬算。
决策类任务要讲清代价与收益，避免模型过度优化单一目标。
复杂任务拆成多提示词流水线，每个只做一件事。
模型选择要算总账，更好的模型有时更省钱。
评估是底线，没有量化基准的改动就是碰运气。

本文基于 Margot Van Laar 在 Code with Claude 大会的分享整理，并加入简单实验验证。

提示词工程实战：维护、调试与评估 —— Margot Van Laar Code with Claude 分享总结