一人产品的提示资产：模板、变量、版本与可复现

提示不是草稿，是资产；资产要有编号、版本和回滚点。

一、七个文件里，有三个叫「最终版」

叶岚一个人做跨境电商的差评回复工具：卖家把一条差评粘进来，工具输出一段可以直接发出去的回复草稿，按月 15 美元。上线四个月，付费用户 63 个。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

她的提示存在七个文本文件里，文件名分别是 prompt.txt、prompt_v2.txt、prompt_v2_new.txt、prompt_最终版.txt、prompt_最终版2.txt，还有两个躺在聊天记录里，是某次调试时直接改在代码里的。哪个是线上正在跑的，她需要打开部署日志才能确认。

某个周一，一位老客户来信：「上个月它还会直接说『这条差评涉及退款，建议先私信处理』，今天只会道歉，一点用都没有。」叶岚打开代码，发现上周五她为了修另一个问题，把 system 提示里一段关于「识别诉求类型」的说明删掉了，删的时候以为那是重复内容。

她想回滚，却发现自己回不去：线上没有记录当时用的是哪个模型快照，temperature 在两个月前调过一次但没人记得具体值，渲染后的 prompt 也没有留档，因为变量里拼进了用户原文，她不确定当时那段原文被截断到了多少字。

提示出问题时的痛苦，几乎都不是「模型变笨了」，而是「我不知道当时到底发了什么」。 这句话对应四个具体缺口：没有唯一编号、没有版本指针、没有渲染记录、没有回滚路径。

二、最小 registry：九个字段就够用

九个字段里，最容易被忽略的是「模型快照」。 供应商会在不通知的情况下更新同名模型，你的提示没动，输出却变了。把快照写进 registry，至少能在事后区分「是我改坏了」还是「模型换了」。

registry 用一张表或一个 JSON 文件都行，关键是唯一。 不需要数据库，一个版本化的配置文件加一个约定就够了。真正要防止的是「同一个功能有两份配置，谁也不知道哪份生效」，而不是「格式不够漂亮」。

ID 用功能名，不要用文件名。 文件名会变，功能名相对稳定。日志里记 reply-draft@v7，比记 prompt_最终版2.txt 有用得多，因为后者在三个月后连你自己都认不出是什么。

变更记录只写三件事：为什么改、改前改后的评测分、谁点的头。 不要写「优化了一下措辞」这种无法验证的描述。半年后你回看这条记录，需要的是能判断「这次改动值不值」的信息。

registry 要跟代码一起进版本库。 提示放在某个后台的输入框里、只存在于线上环境，是最危险的一种状态：没有 diff、没有评审、没有回滚，改错一次只能靠记忆恢复。

每个季度清理一次。 下线功能对应的模板要标记为废弃而不是直接删除，保留一个季度；仍在引用但没人认领的模板，要么补负责人，要么下线。registry 的价值在于「当前有效的集合是明确的」，不在于「历史上所有东西都留着」。

三、模板与变量分离：五条校验

模板与变量分离，收益在测试。 模板是一段带占位符的固定文本，变量是运行时填进去的值。分离之后，你可以用一组固定 fixtures 反复渲染，检查「模板本身有没有被改坏」，而不需要真的调用模型。

system 与 user 要分开存。 system 承载角色、边界、输出格式；user 承载这一次的具体输入。两者混在一个字符串里，会导致你想改边界时必须连带改输入拼接逻辑，也让「同一段 system 配不同 user」的对照实验做不了。

必填变量的校验要发生在调用之前。 缺变量的典型后果不是报错，而是拼出一个语义不完整的提示，模型仍然会一本正经地回答。这种错误最难查，因为日志里一切正常。所以缺变量必须直接拒绝，并把缺的字段名写进日志。

按序列化格式转义，按 token 预算限长。 引号和分隔符按实际模板或 JSON 编码规则处理，不手工替换后就宣称安全；长度同时包含 system、工具描述和输出预留。这些能防止格式损坏与部分资源滥用，但模型仍可能把用户文本当指令。检索与工具权限必须由服务端检查，详见第 07 篇。

长度上限要从上下文预算反推，不要拍脑袋。 先确定这次请求最多能用多少 token，减去 system 段、输出预留与安全余量，剩下的才是用户变量的上限。这个上限写进 schema，超出的部分截断并打标记，而不是让供应商在服务端悄悄截断。

fixtures 要覆盖边界，不只是正常路径。 至少四组：最典型的输入、最短输入、超长输入、含特殊字符的输入。每组存一份渲染后的快照，模板一改，测试立刻告诉你哪一组的输出变了。

变量契约要写进文档，而不只是代码里。 谁在调用这个模板、传了哪些字段、哪些可选，这些信息应该和 registry 放在一起。一个人维护时你觉得不需要，等你三个月后回来改，它就是唯一的线索。

四、可复现与变更流程：改提示等于改代码

重放需要输入，不只需要哈希。 保存模板及渲染器版本、获准保留的完整渲染输入或不可变引用、输入摘要、模型标识与配置、响应及 usage。按授权和保留期加密存储敏感内容；不能合法留存的输入标为不可重放，不能承诺三十天内任意调用都能复现。固定模型与采样参数也不保证生成逐字相同。

哈希用于核对，快照用于恢复。 模板和变量相同，渲染器版本、截断策略及默认值变化仍可能改变输入。摘要只能比较已有字节，不能还原丢失的内容；实际送出的消息、配置及版本共同组成可追溯记录。

输入摘要与行为差异分开排查。 输入摘要不同，先查输入快照、渲染器和截断策略；输入相同而输出不同，再查模型标识、采样配置与服务变更。若配置也参与了摘要，先按摘要定义拆出差异，不能把任意变化都归因于模型。

改提示要走代码评审的流程。 一个人开发时没有评审人，那就用「自己隔一天再看」替代：今天改完先不合，明天用 50 条评测集跑一遍再决定。这个延迟能过滤掉相当一部分冲动修改。

灰度从 5% 开始，并且要能按用户切。 按请求随机切会让同一个用户在两次调用里看到不同风格，体验很怪；按用户 ID 哈希切，同一个用户始终落在同一侧，对比才干净。

回滚要能在 10 分钟内完成。 前提是上一版模板的指针还在、部署流程不依赖手工操作、回滚不需要重新跑评测。这三条任何一条不成立，10 分钟就只是口号。

灰度期间盯三个数，不盯总体感受。 严重错误数、格式解析失败率、平均输出长度。前两个决定要不要立刻回滚，第三个能提前发现「模型开始啰嗦」这种还没被用户投诉的退化。总体满意度太慢，等它动起来已经烧掉一天的流量。

五、行动清单与复算验收

先把线上正在跑的那一版找出来。 多数人的第一步不是建 registry，而是确认「现在生效的是哪个文件」。把部署日志、代码里的字符串、后台配置三处对齐，通常会发现至少一处不一致。

再用三个数字验收。 可复现率衡量你能不能解释过去，模板覆盖率衡量你有没有漏网的提示，变量缺失率衡量你的校验是否真的在拦。三个数字都不需要新工具，从现有日志里就能算。

• 把线上所有提示收进一个目录，标注每个提示当前是否生效。
• 为每个生效提示补齐九个 registry 字段，模型快照写到具体版本。
• 把模板拆成 system 与 user 两段，占位符统一命名规范。
• 为每个模板写变量 schema，声明必填、类型与长度上限。
• 加四条校验：必填、类型、长度、转义，缺变量直接拒绝。
• 用四组 fixtures 渲染并保存快照，接入现有测试流程。
• 在日志里记录 prompt 哈希、快照、参数、响应 ID 与 token 数。
• 把改提示接进发布流程：50 条评测、5% 灰度、10 分钟回滚。

验收标准：随机抽 40 条历史请求，能用日志还原出当时的完整 prompt 与参数，且结构一致的比例不低于 85%。

可复现率 = 重放结构一致样本 ÷ 抽检样本
示例：抽检 40 条，结构一致 34 条 → 34 ÷ 40 = 85%
模板覆盖率 = 已版本化模板 ÷ 线上模板总数 = 9 ÷ 12 = 75%
变量缺失率 = 缺变量请求 ÷ 总请求 = 37 ÷ 4200 = 0.88%
结论：可复现率达标，覆盖率不足，先补 3 个未版本化模板

使用边界与实操验收

本文讨论的是「一个人维护的 AI 功能如何管理提示资产」，不涉及训练、微调与多轮对话的上下文压缩策略。它假设你已经有线上流量与至少一次「改了不知道哪里变了」的经历，需要的是把提示管起来，而不是从头设计提示。

• Prompt 版本管理与 A/B 实验 ：它讲版本管理与实验分流的完整体系，本文讲一个人维护时的最小 registry 与回滚路径。
• 提示工程与上下文工程：从指令设计到生产评测 ：它讲提示怎么写、怎么评测，本文讲写完之后的资产化与可复现。
• 上下文工程实战：从上下文窗口到长上下文管理的工程体系 ：它讲长上下文的组织与压缩，本文讲变量、模板与版本这条更窄的链路。

实操验收建议做一次「盲重放」：从上周的日志里随机抽 20 条，只给当时的输入与 registry 记录，让流程重新渲染一遍，再与当时的 prompt 哈希比对。如果一致率低于八成，问题通常不在模型，而在渲染逻辑或默认值；把差异逐条列出来，就是下一轮要补的校验。

三个月后做一次回滚演练。 挑一个非高峰时段，把线上指针切到上一版，观察指标、确认用户无感，再切回来。没演练过的回滚路径，在真出事时大概率因为某个手工步骤而卡住，而那时你没有时间调试发布流程。

本文的阈值是教学刻度。 85% 可复现率、5% 灰度、10 分钟回滚、40 条抽检，都是为了让你能立刻开始而选的经验值，不是外部标准。你的调用量越小，抽检比例可以越高；调用量越大，越应该依赖自动化的哈希比对。

本文不覆盖的三种情形。 一是提示由非技术同事在后台直接编辑，需要额外的权限与审计设计；二是多轮对话中上下文会累积，重放需要连同历史一起保存；三是同一功能同时跑多个模型做对照，registry 要按「功能加模型」建复合键。

关键参考与核验范围

核对日期：2026-10-25。下列来源仅支持明确标注的机制或原则。

• Claude：Prompting best practices : 用于核对指令组织与输入结构化的厂商建议。
• OWASP：LLM Prompt Injection Prevention : 用于区分文本分隔、权限隔离与输出检查的作用。

使用边界。 registry 字段、版本流程与重放比例是本文设计；结构化输入或模板转义不能保证模型服从，也不保证两次生成逐字一致。

如何自行复核。 先离线核对渲染后输入的结构与哈希，再独立运行行为评测；权限边界由服务端执行，不以提示模板是否渲染成功替代。

系列导航

• 上一篇：模型供应商选择：五维打分、两条备选与迁移成本
• 下一篇：小样本评测：50 条用例、评分表与上线门槛
• 回到目录：一个人给产品加 AI：判据、成本、护栏与验收
• 相关阅读：模型路由与选型：大小模型分层调度 、LLM 成本治理与 Token 优化