Prompt工程不是玄学：可复用的提示词管理方案

团队里 Prompt 散落在个人备忘录、聊天记录和代码注释里？该治理了。

这一年我推动的最有价值的基础设施之一，就是把 Prompt 当代码管理。分享我们的完整方案。

先破除三个迷信

迷信一：Prompt 越长越好。 实测很多场景下，冗长的角色扮演描述反而稀释了关键指令。我们的生产 Prompt 平均 400 token，砍掉了所有"你是一个世界顶级的……"式废话。

迷信二：技巧是通用的。 "Let's think step by step" 在数学类任务有效，在分类任务里纯属浪费 token。任何技巧都要过你自己的评测集。

迷信三：写完就不用管。 模型在更新，用户在变化，Prompt 是需要持续迭代的活资产。

我们的 Prompt 管理四件套

1. 版本化：Prompt 即代码

所有生产 Prompt 存 Git 仓库，禁止在控制台手改线上 Prompt。每次变更走 MR，review 界面直接看新旧 diff。

2. 模板化：变量与逻辑分离

# intent-classify.prompt.yaml
system: |
  你是客服意图分类器。只输出以下标签之一：
  {{labels|join("/")}}
  无法判断时输出 unknown。不要输出任何解释。
user: |
  {{query}}
params:
  temperature: 0
  max_tokens: 20

意图标签是运营同学维护的配置，改标签不用改 Prompt；工程师不用碰文案，文案同学不用懂代码。

3. 评测化：变更必须过回归

每个 Prompt 挂一个评测集，CI 里自动跑。我们有一条铁律：Prompt 变更 + 评测集 + 评测结果三者不齐，禁止上线。 曾有同事的"优化"让主指标涨了 3 个点，回归评测发现边缘场景崩了 15 个点——没有评测体系，这种事故根本看不见。

4. 可观测化：线上全链路追踪

每次调用记录：Prompt 版本号、命中的模板变量、模型输出、最终结果。出现 badcase 时能精确回放到"当时用哪个版本、什么输入、什么输出"。

一些实测有效的写法

给输出格式上硬约束：JSON Schema + response_format 强约束，比"请输出 JSON"可靠得多
few-shot 要贴近线上分布：从真实流量里抽，不要自己编理想案例
负面指令前置："不要透露内部折扣规则"比放在 Prompt 末尾更有效
让模型先分类再回答：两段式（先判类型，再走分支 Prompt）普遍优于一个巨型 Prompt

组织层面的经验

最大的阻力不是技术，是习惯。推动落地的三个抓手：

先拿一个事故案例做内部宣讲（Prompt 改崩了没人知道怎么回滚）
给工具足够低的使用门槛（改 Prompt 像填表单，不像写代码）
把 Prompt 质量纳入绩效指标的一部分

Prompt 工程会随着模型变强而贬值，但**"对 AI 行为做工程化管理"的方法论，会是未来十年产品团队的通用能力。**