提示词不是玄学：可复用的工程方法

在很多团队里，提示词是一门「玄学」：谁手感好谁来写，写出来效果不错，但说不清为什么不错，换个人就接不住。这不是某个人能力的问题，而是缺少方法——我们用对待手艺的方式对待提示词，却没用对待工程的方式管理它。

把提示词工程化，第一步是模板化。我会把团队里反复出现的任务——摘要、抽取、分类、改写、对话——抽象成带变量的模板，每个模板配上使用说明、适用场景和正反例，清楚地告诉使用者什么时候该用、变量怎么填、容易踩哪些坑。这样提示词就从「某个人脑子里的土方」变成了「全团队可以共享的资产」。

第二步是版本化。提示词应该像代码一样有版本、有记录、可回滚。当线上效果突然变差，你需要能快速回答「是哪次改动引入的问题」，而不是在一堆叫「最新版」「最终版」「真的最终版」的文件里抓瞎。把提示词纳入版本管理，改动就有了可追溯的历史。

第三步，也是最关键的一步，是可评测。过去判断一个提示词好不好，全靠几个人随手试几条「感觉不错」就上线，这其实和算命没太大区别。我引入了 A/B 流程：每次改提示词，都拿一套固定的评测集跑一遍，用数据判断它是真的变好，还是只是这次随手试的几条凑巧顺眼。改坏了，评测会第一时间告诉你，而不是等用户来告诉你。

让方法真正落地，还有个小诀窍：不要写一份厚文档塞给大家，而要把规范嵌进日常工作流。新建任务时直接从模板库选起，改提示词时评测自动触发——让正确的做法成为最省力的做法，规范才不会沦为没人看的摆设。

当提示词可以被复用、被版本管理、被评测，它就不再是某个人的秘密，而成了团队工程能力的一部分。很多看起来玄乎的东西，其实只是还没被认真地工程化而已。提示词，就是其中之一。