我是小兵，一个动手派AI架构师。「AI工程化实战」系列第 4 篇。
值班同学改了句 Prompt，4 分钟后想撤销
上篇《灰度发布+自动熔断》结尾预告的《Prompt 即代码》，就是这篇。
熔断器装好的第一周，转人工率又爬回 3 倍基线。这次不是发版——值班同学直接在管理面板改了句 Prompt：“回复前先核实支付状态”，想压压转人工。4 分钟后曲线没下来，他想撤销，编辑器早关了——连 Ctrl+Z 都没得按。
Git 里没有 Prompt，后台只有“当前生效”一个版本。他最后翻着聊天记录，把昨天那条一个字一个字抄回去——抄完还是差一个标点。
上篇我们说，灰度/熔断能回滚，是因为你“精确知道该回滚到哪个版本”。可 Prompt 压根没有“版本”这回事。改之前长什么样、谁改的、改了什么，全没留痕。Prompt 是字符串，不是资产。
三连错：Prompt 现状是“复制粘贴的字符串”
先看最常见的三种翻车姿势，你多半踩过至少一个：
-
后台热改 Prompt，无版本——改完不知道改了什么，也退不回去，撤销靠 Ctrl+Z。 -
Prompt 混在代码字符串里——改一行提示词要动整个服务发布，上篇说的“回滚粒度是整个服务”就是它。 -
改 Prompt 不跑评测直接上线——评测门禁早就给 prompts 路径挂了触发，但没有版本可对比，门禁有钩子没抓手。
三个错法病在同一个地方：Prompt 打一开始就没被当成代码资产来管。代码有的待遇清单是啥？Git 版本、PR 评审、CI 校验、发布单、回滚。现在的 Prompt 呢？热改无版本、评审靠“我觉得这句话顺”、上线靠人肉贴、回滚靠抄聊天记录。
先说结论，后面全是落地：把「Prompt 是代码」当一份待遇清单来兑现，落到三件事——版本化、评审、回滚。这不是“怎么写好 Prompt”的技巧题，是工程题：Prompt 作为 LLM 应用的逻辑载体，凭什么拿不到代码那套待遇？
版本化：内容哈希当身份，semver 只是标签
第一步，Prompt 从“管理面板里的一个框”变成“仓库里的一个文件”，文件头带元数据：名字、版本号、改动类型、谁改的、为什么改。文件化只是第一步，真正关键的是落库时算的那串 sha256 内容哈希。
内容哈希才是版本身份，版本号只是给人看的标签。为什么必须用哈希当身份？Prompt 字节敏感——多一个标点就可能变行为，甚至变好或变坏。“回滚到 v1.1.0”是标签，“内容和评测过的那一份字节完全一致”才是给机器和评测集的契约。标签可能起错名、被重复、甚至排不出序，哈希不会：同一份内容永远同一个 ID，你回滚到的，就是你评测过的。
registry 的职责是存全量历史，绝不丢。每注册一次，append 一条版本记录（含作者、原因、改动类型、时间戳），改动变成账本上的一行，而不是面板上覆盖掉的旧值。
这里有个常见疑问：Prompt 文件进了 Git，Git 不就能管版本吗？分工是这样的——Git 管“文件改了没有”，registry 管“内容变成哪一版了”。一次 commit 可能同时改 5 个 Prompt；registry 的版本是字节的单位，一个标点就是一个新版本。回滚 Prompt 时你要的是后者：精确到那一版字节，而不是“那次 commit 里的所有改动”。
评审：人看 diff，机器看校验
代码上线前要过 PR，Prompt 为什么就能拍脑袋上线？评审拆成两半。
人看的一半是 diff。Prompt 进 Git 之后，PR 里就是 git diff——这行改了什么，一屏看完。评审人的问题从“这句话顺不顺”变成“这次改动的意图和 diff 对不对得上”，这是质的区别：后者是评审，前者是聊天。
机器看的一半是三道闸，全挂 CI：
-
占位符完整性：模板里写了 {order_id}，调用方到底传没传？没传，线上就是一段带花括号的裸文本。 -
token 预算 / schema 绑定：改动后 token 消耗是否超预算、输出结构是否仍能过契约。 -
最小评测回归：把候选版本喂给第 2 篇的评测集跑一轮，复用它的三层级联和门禁口径。
机器看的一半为什么省不掉？人不可能盯住每一个标点——今天改的这版，占位符少没少传，靠人眼在 PR 里找，找到的几率和你翻聊天记录抄 Prompt 差不多。这三道闸全是“便宜、确定、机器该管”的活，人只配碰语义。
回滚：新增“内容等于旧版”的新版本，不删历史
版本化 + 评审都齐了，回滚才有资格谈“精确”。回滚的语义就三条：
-
路由只认版本 ID。线上“当前生效”不是一个字符串，是一个版本指针；回滚 = 把指针切回旧版本 ID。 -
回滚是“新增”，不是“删除”。回滚 = 新建一个“内容等于旧版”的新版本，历史一条不删。 -
落一条回滚记录。谁、几点、从哪版回滚到哪版、为什么，全部留痕。
这里焊死一个容易混的点：回滚是两件事同时做——账本侧 append 一条 revert 版本（留审计），路由侧把钉住的版本 ID 指向目标（切流量）。别以为 append 完就回滚完了：账本多了行 revert，线上指针还得有人去切。
为什么回滚必须走“新增”而不是“把指针直接改回去”？你想一个场景：出了事故，回滚了，线上恢复了。但账本上如果只是指针被拨回旧版，历史里就没有“回滚”这个动作——一周后复盘，谁都回答不了“线上为什么变回旧版了、谁干的、当时为什么”。回滚动作本身成为一行历史，审计链条才完整。这就是上篇那份回滚记录心智的延续——上篇回滚的是服务，这里回滚的是真正的逻辑。
坑一：回滚“删掉坏版本”，历史少了关键一版
线上 Prompt 出错，运维同学直接把“坏版本”删了、把旧版内容贴回去。一周后复盘，查不到线上跑过那版坏 Prompt——账本里只有连续两个“旧版”，坏版本像从没存在过。
根因：把回滚理解成“编辑”，而不是“版本操作”。回滚是 revert，不是 delete。历史不可变，出事才能回答“线上跑的是哪版、谁几点改的、为什么回滚”——账本上不许有洞。
坑二：版本号拍脑袋，回滚时排不出序
版本靠文件名管理，改着改着出现 v2_final、v3_最终、v2_final_真_最终版2。要回滚时，谁也不知道哪个才是线上那版。
根因：把“版本号”当成了身份。身份应该是内容哈希（同一内容永远同一 ID），版本号只是给人看的标签，按改动类型自动推断 semver 就行（1.0.0 → 1.0.1 / 1.1.0 / 2.0.0）。名字随便起，身份不会错。
坑三：模板里混了环境变量，diff 全是噪声
PR 里 diff 满屏都是“今天是 2026 年 8 月 15 日，天气晴朗”这种行，评审人看几行就放弃了——分不清哪行是逻辑改动。
根因：模板不纯净，把“变量”和“内容”混在一起。
修复：参数注入占位符，模板文件本身纯净，日期、环境、用户信息全部运行时注入。只有 diff 里每一行都是逻辑改动，“回滚精确到一个标点”才成立。
边界：registry 管资产，网关管路由
必须说清一层边界：registry 管的是“资产”，不是“路由”。它回答“有哪些版本、怎么回滚”，但不回答“线上此刻到底该按哪个版本 ID 路由”——这个决策点不在 registry，在网关层。下一篇《LLM 网关选型》，把“支持按版本 ID 路由 Prompt / 从 registry 拉取”列为硬指标。
把这套落地，记住四条就够了：哈希是身份、回滚是新增、模板要纯净、路由在网关。
我是小兵，一个动手派AI架构师。这里只写自己跑过、摔过、复盘过的AI工程化案例。如果你想持续收到这类实战内容，点击关注，下篇见。