跳到主要内容

一个可维护的 Prompt 模板体系应该长什么样

· 阅读需 6 分钟
一介布衣
一介布衣
全栈开发者 / 技术写作者

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-03-05 10:20。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

我越来越觉得，很多 AI 项目后期维护困难，并不是因为模型太难控，而是因为 Prompt 被当成了一堆零散字符串在使用。哪个页面要改一句，在哪个文件里搜一搜；哪个流程要加个限制，直接往模板里塞；哪个实验效果好一点，就把那段提示词复制到另一个地方。短期看，这种方式很快；长期看，它会让整个系统越来越难治理。

当 Prompt 还是一两个的时候，这种混乱不太明显。但只要项目开始进入多任务、多模型、多流程、多角色协作阶段，Prompt 很快就会变成一层隐形配置系统。它既决定输出质量，又影响业务行为，还会牵连评测、日志和回滚。到这个时候，如果还把它当作普通字符串处理，迟早会出问题。

所以我更关心的不是“某一版 Prompt 写得多漂亮”，而是“这套 Prompt 有没有可维护的组织方式”。

为什么 Prompt 体系会越来越像配置系统​

很多人一开始把 Prompt 当成文案，这是最自然的理解方式。但到了工程化阶段，它已经具备了配置系统的几个典型特征：

  • 不同环境可能要用不同版本
  • 不同任务有不同模板
  • 一次改动会影响线上行为
  • 出问题时需要快速回滚
  • 不同人会对它提出修改需求

一旦具备这些特征，你就不能再只用“复制一段字符串”的方式维护它了。

真正需要考虑的是：

  • 模板怎么命名
  • 模板怎么分层
  • 模板怎么版本化
  • 模板和业务规则怎么解耦
  • 改动后怎么验证

这些事情如果不先想清楚，Prompt 很快就会成为系统里最难解释的一层。

我更倾向的 Prompt 分层方式​

对我来说，一个可维护的 Prompt 体系至少应该拆成三层。

1. 角色层​

这一层回答“你是谁、你要遵守什么基本边界”。

例如：

  • 你是客服助手
  • 你是知识问答助手
  • 你只能根据上下文回答
  • 无法确认时必须明确说明

这一层应该足够稳定，不要混太多业务细节。

2. 任务层​

这一层回答“这次到底要完成什么任务”。

例如：

  • 做分类
  • 做字段抽取
  • 做摘要
  • 做改写
  • 做回复草稿

这一层可以有多份模板，但职责要清晰，最好一份模板只服务一类任务。

3. 展示层​

这一层回答“结果应该怎么表现出来”。

例如：

  • 是否要礼貌
  • 是否要简洁
  • 是否要中文输出
  • 是否要带引用
  • 是否要固定 JSON 结构

这层最好尽量轻，不要顺手把业务规则也塞进来。

一旦这三层混在一起，后面每次改动都会牵一发动全身。

什么叫“可维护”​

我现在对“可维护”的判断很朴素，主要看这几个问题能不能回答：

1. 这份 Prompt 属于谁​

有没有明确 owner，谁能改、谁负责验收、谁决定上线。

2. 这份 Prompt 影响哪里​

能不能知道它被哪些任务、哪些页面、哪些工作流依赖。

3. 这次改动改了什么​

是否有版本记录，能不能清楚看到变更内容。

4. 改完之后效果有没有变​

有没有固定样本、对比结果、失败样本回收机制。

5. 如果改坏了能不能退回去​

能不能快速回滚到上一版，而不是靠记忆恢复。

如果这些问题都答不上来，那这套 Prompt 就谈不上“体系”，最多只能算“积累了一堆能跑的模板”。

我最不建议的几种做法​

1. 一个超级大模板解决所有问题​

这种模板前期最省心，后期最难维护。因为任何小需求都会继续往这个模板里堆，最后没人敢动。

2. 每个页面复制一份再微调​

这样做的后果通常是：

  • 看起来都差不多
  • 实际上各自漂移
  • 出问题时不知道哪份是真正基线

3. 把业务规则硬写进展示模板​

业务规则更适合放在上游配置、后处理或任务层逻辑里，而不是全都堆在输出提示词里。

4. 改完直接上线，不做样本对比​

Prompt 的危险之处在于，很多改动不会立刻报错，但会悄悄改变表现。没有对比样本，你很难知道是优化了还是变差了。

我更愿意的组织方式​

如果今天让我从头整理一套 Prompt 体系，我会更偏向下面的组织方式：

prompts/
  roles/
    support-assistant.md
    analyst-assistant.md
  tasks/
    classify-intent.md
    summarize-ticket.md
    draft-reply.md
  output/
    concise-cn.md
    strict-json.md
  scenarios/
    support-reply-v3.md
    kb-answer-v2.md

这里的关键不是目录结构本身，而是把职责拆清楚：

  • 通用角色放在一起
  • 任务模板放在一起
  • 输出约束放在一起
  • 具体场景只做组合，而不是重新发明一套 Prompt

这样做的最大收益，是改动更可控。

Prompt 也应该进入版本管理和评测流程​

只要 Prompt 真会影响线上结果，它就应该像代码和配置一样被治理。

我至少会要求：

  • 有版本号或明确命名
  • 变更有记录
  • 有固定测试样本
  • 能比较新旧差异
  • 能快速回滚

哪怕只是很简单的一套流程，也比“大家在文档里手改”强得多。

一个我越来越认同的原则​

Prompt 不是越聪明越好，而是越容易被团队理解、验证、替换越好。

真正可维护的体系，通常都有两个特点：

  • 模板本身足够克制
  • 系统其余部分愿意分担职责

也就是说，不要指望 Prompt 独自承担规则、风格、流程、异常和治理。只要团队愿意把这些职责分散到更合适的层，Prompt 反而会更稳定。

总结​

一个可维护的 Prompt 模板体系，不是把所有经验堆成一大段提示词，而是把 Prompt 当成系统中的一类可治理资产来组织。

当它有分层、有 owner、有版本、有评测、有回滚时，团队才真正拥有了一套可以长期演进的 Prompt 体系。否则你拥有的只是一些暂时有效的字符串片段，迟早会在项目变复杂时失控。