提示版本和代码版本管理差在哪？

代码改坏了，回滚到上一个版本，一切照旧；提示词改坏了，回滚回去，输出照样变了样——不少用大模型干活的人都撞过这堵墙。同一套版本管理习惯，搬到提示上为什么会失灵，值得单独说清楚。

结论：工具能共用，节奏不能照搬

代码管理工具记提示词完全没问题，问题出在照搬代码的节奏。代码按功能提交，一个功能一批改动；提示得按效果提交，哪怕只改了一个形容词，只要输出变了，就该记一笔。提示的改动粒度比代码细得多，一个词就能让整段输出转向，所以它的版本记录密度天然更高，这是两套管理的根本差异。

两套管理差在提交粒度、绑定物和节奏上，逐项对照：

改一个词为什么影响这么大

代码里改一个变量名，行为不变；提示里改一个词，输出方向就可能整段改变。原因在于提示没有精确语义：你写严谨一点，模型会自行解释严谨指什么，每次解释还可能不一样。把模糊词换成具体指令，输出才会稳下来。这种不确定性决定了提示的版本必须绑定当时的输出样本，光记文字、不记效果，等于只存了半条版本。

顺便提一个版本之外的组织问题：提示之间怎么分组也影响版本压力。按任务分组还是按场景分组，可以参考通用提示和领域提示有什么区别？里的分层思路，把稳定的通用部分和常改的领域部分分开管，需要记版本的条目立刻少一半。

从代码管理里借得走的习惯

有三条习惯直接搬过来就值：一是改动说明必填，写清为什么改，而不是只写改了什么；二是每次提交绑定测试结果，跑一遍固定输入集，把输出摘录贴进说明里；三是命名带语义，v3没有信息量，加了字数上限的v3才有。另一条要反着来：代码合并讲究攒一批再提，提示恰恰建议小步提交，改一处提一次，因为不这样你就定位不了是哪个改动引起的输出变化。

提交前的验证怎么做，人工和自动的分工在人工测试和自动评测有什么区别？里已经拆开讲过，这里只需记住一条：没有验证记录的版本，将来回滚时你都不知道自己在回滚到什么效果。

提示版本记什么才有用

一份够用的提示版本记录，每条包含四项：版本号和日期、改了哪几处、当次的典型输出摘录、改动原因。文本本身放在工具里，效果摘录放在说明里，两者用版本号对上。这样翻历史时，你看到的不再是干巴巴的文字快照，而是这条提示在当时的实际表现，比较不同版本才有依据。别嫌这套流程重，它换来的是可回溯：三个月后想知道当初为什么删掉某条要求，翻记录就能找到答案，不用靠回忆重建现场。

回滚频率本身也是观察指标：一条提示如果频繁回滚，说明某处要求写得不稳，该回头把那句指令改具体，而不是继续靠回滚兜底。改到什么程度该换思路，比如从改措辞转向更底层的方案，可以看提示调优和模型微调差在哪？改问法和改模型的分工。

自查清单：提示版本记全了吗

• 每条版本有改动原因，不只是改动内容
• 绑定当次典型输出摘录，文字和效果对得上
• 小步提交，改一处记一笔
• 频繁回滚是信号：回头改指令，别只顾回滚。

换个问法再问提示版本管理三句

• 个人用记事本管理提示版本行不行？：行，起步阶段够用。关键是坚持记原因和效果摘录这两项，工具反而是其次。
• 版本号该按什么规律编？：大改加一，小改加点，比如v2改措辞是v2.1，重组结构才是v3。规律比编号本身重要。
• 输出变了但没找到原因怎么办？：先排查这次提交之外的变量，比如换了模型或参数设置，再回滚对照，别急着改提示。