考察点
这道题区分「写过 Prompt」和「管过 Prompt 资产」的候选人。团队规模上来后，Prompt 散落在代码字符串、数据库、配置文件里，谁改了什么、为什么改、改完效果变差了怎么回滚，全是真实痛点。面试官想听你有没有建立过「改动→评测→发布→回滚」的完整闭环。
参考答案
核心立场：Prompt 就是代码
改一行 Prompt 和改一行业务代码的影响等价——都会改变线上行为，都可能引入回归。所以治理手段直接照搬软件工程那套：
进版本库。 Prompt 模板以文件形式进 git（YAML 或 markdown + front matter），禁止散在代码里的裸字符串和数据库里无人认领的字段。每次修改有 commit、有 review。review 重点看两件事：有没有动不该动的部分（比如顺手改了输出格式）、改动理由是否写清。我们要求 Prompt 的 commit message 必须带关联的 badcase 编号。
有显式版本号。 模板文件里带 version 字段，调用日志里记录每次请求用的模板版本。没有这个，线上出了问题根本没法定位是哪版 Prompt 引入的——模型版本、Prompt 版本、检索库版本，三者都得打进日志，排障时缺一不可。
改动必须绑评测
这是和纯代码管理最大的不同点：代码有编译和单测兜底，Prompt 没有，改一个字效果可能天差地别。规矩是：任何 Prompt 改动合入前，必须过评测集，关键指标不掉才允许上线。
评测集从哪来？线上 badcase 的持续积累。每次线上发现问题（用户投诉、抽检不合格、格式解析失败），把 case 脱敏后补进评测集，同时修 Prompt。这样评测集随业务生长，回归能力越来越强。一个新人的 Prompt 改动如果恰好修好了 badcase 集里三条老 case 且没引入新问题，这就是高质量的迭代，走查时一目了然。
灰度和回滚
- 灰度：重要场景的 Prompt 更新按流量百分比灰度，新老版本并行跑一段时间，对比解决率、投诉率、格式失败率再全量。技术实现不复杂，配置中心按用户 ID 哈希分流即可。
- 回滚：因为模板在 git 且带版本号，回滚就是把配置指回上一个版本，分钟级完成。前提是所有渲染逻辑只认版本号，不缓存模板内容。
- 紧急通道：线上 Prompt 引发事故时，允许绕过评测直接回滚，事后补评测和复盘——安全优先，流程不能变成挡箭牌。
工具和协作
团队大了可以上 LangSmith、Langfuse 这类 Prompt 管理平台，自带版本管理、评测、trace 记录， tracing 和 Prompt 版本天然绑定，排查「这次回复为什么变差」效率高很多。小团队不必上平台，git + 配置中心 + 一个跑评测的脚本就够了，流程比工具重要。
还有一个协作细节：Prompt 的修改权放开给产品和运营，但合入权留在工程侧。运营最懂话术问题出在哪，让他们直接改模板文件提 MR，工程师 review 格式和副作用后合入，比「运营提需求、工程改字」的串行模式快一个量级。
可能的追问
- Prompt 迭代和模型升级的关系？ 换底座模型时所有旧 Prompt 都要重新评测——为老模型绕过缺陷写的指令（「不要输出 markdown 代码块」），新模型可能本来就不需要，留着反而干扰。模型升级是 Prompt 瘦身的好机会。
- 多条 Prompt 共用的片段怎么管？ 抽公共片段（安全红线、格式约定）做模板继承或 include，改一处全量生效，改动后所有下游 Prompt 跑全量评测。
- 怎么防止评测集过拟合？ 评测集只进 badcase 不够，要保留一定比例随机采样的正常流量 case 作为「防线样本」；定期用新鲜流量刷新评测集，防止团队把 Prompt 调成只会在老评测集上拿分。