别再幻想提示词工程是挥洒创意的魔法了。Anthropic应用AI工程师Margot Van Laar在Code with Claude上泼了盆冷水：团队里80%的精力，都耗在调试和维护那些已经跑在生产环境里的提示词上。从零编写？那只是开始，真正的硬仗在后面——你得像个机械师一样，不断拆解、清理、校准，而唯一靠谱的尺子，叫评估。
提示词的真相：维护，而非编写
客服机器人的“考古”工作
想象一个已上线半年的客服机器人。用户投诉它反应迟钝，回答总带着莫名的限制。Van Laar的团队接手后，没急着写新指令，而是像考古一样，用XML标签把原有提示词结构化地拆解开来。他们发现了什么？一堆来自更早版本模型的“禁止列表”指令。旧模型时代，这些条条框框或许能控制输出，但新模型更强了，它会过度拟合这些旧规则，结果反而束手束脚。清理这些历史遗留的“脂肪”，让提示词轻装上阵，响应速度立刻提升了。
零售排班Agent：三个提示词的舞蹈
另一个案例是从零构建一个零售排班Agent。这里的关键不是写出一个包罗万象的超级提示词。Van Laar的团队把它拆成了三个相对简单的提示词，形成一个循环：第一个生成初步排班方案，第二个评估方案的合理性（比如考虑员工偏好、工时法规），第三个则根据评估结果进行修复和调整。这个“生成-评估-修复”的循环，比单一复杂提示词稳定得多。有意思的是，他们在这个环节特意选用了Opus这样推理能力更强的模型，因为修复步骤需要模型真正“理解”矛盾并推理出解决方案。
评估：唯一严谨的迭代方式
没有评估，就是碰运气
Van Laar在分享中反复敲打一个观点：评估（Eval）是唯一严谨的方式。她不是在说漂亮话。在生产环境里，每次修改提示词都像是在给心脏做手术，你不能凭“感觉这次改得不错”就上线。她举了一个例子：团队曾经优化客服机器人的提示词，想让它更友好。直观测试时，几个测试案例效果拔群。但上线后，真实用户的复杂、情绪化查询让模型直接“懵圈”，输出变得冗长且答非所问。为什么？因为他们的测试集覆盖不足，没有模拟到那些边缘情况。没有系统化的评估，上线就是在赌。
从“我觉得”到“数据说”
那么，严谨的评估长什么样？它不是让几个同事问两句就完事。Van Laar的方法是构建一个持续运行的评估管线。首先，从真实用户对话中采样，建立代表性的评估数据集，覆盖常见问题、棘手case、以及各种语言风格。其次，定义清晰的评估指标：对于客服机器人，可能是“问题解决率”、“响应是否扣题”、“是否违反安全规则”；对于排班Agent，则是“是否满足所有硬约束”、“员工满意度得分”。每次提示词迭代后，新旧版本必须在同一个评估集上跑分对比。数据涨了，迭代才通过。这个过程听起来枯燥，但它是区分玩具项目和生产级应用的分水岭。
工程化思维：提示词不是咒语
结构化清理与精确计算
Van Laar的方法透着一股软件工程的味道。她提到，在客服机器人维护中，他们会精确计算模型应调用的工具。什么意思？就是明确告诉模型，在何种上下文下，应该优先调用知识库搜索工具，而不是自由发挥；何时又该直接转人工。这需要将工具调用的逻辑、触发条件，以一种无歧义的方式写入提示词，并辅以示例。这不是文学创作，这是编程。
转人工的代价与收益决策
另一个工程化细节是转人工决策需明确代价与收益。早期系统可能设定一个简单的阈值，比如“信心分低于0.7就转人工”。但Van Laar的团队做了更精细的建模：计算每次转人工带来的时间成本、用户体验折损，以及可能避免的误解决成本。他们把这些权衡“编码”进提示词的逻辑中，让模型或后续的路由系统能做出更优决策。这已完全超出了“写好一段话”的范畴，进入了系统设计领域。
给实干者的启示
抛弃模板迷信
行业里流传着太多“万能提示词模板”，好像背下来就能点石成金。Van Laar的实战故事揭开了这层面纱。没有放之四海而皆准的模板，只有针对特定任务、特定模型、特定用户群体的持续校准。她的建议是，忘记寻找“银弹”，把你的提示词当作一个活的、需要维护的软件组件来看待。
投资你的评估体系
如果你正在构建或维护一个AI应用，现在最该做的投资可能不是招一个更会“写提示词”的人，而是建立你的评估流水线。它意味着你需要收集数据、定义指标、自动化测试。这个过程初期很慢，但它能让你的每次迭代都脚踏实地，让产品改进可衡量、可回滚、可持续。正如Van Laar所言，没有评估的优化，和在黑暗中乱挥拳头没什么两样。
