考察点
这道题区分「会写 prompt」和「会做 prompt 工程」。面试官想看你有没有把 prompt 当代码管理的意识：版本化、可评测、可回归。只会说「多试试，看效果」的直接出局。追问常往评测集怎么建、LLM-as-judge 可靠性、线上怎么灰度走。
参考答案
核心思路：badcase 驱动 + 评测集兜底
凭感觉调 prompt 的最大问题是改 A 坏 B：修了一个 badcase，悄悄破坏了十个本来好的 case，没有评测集根本发现不了。工程化的目标就是把 prompt 迭代变成「写测试 → 改代码 → 跑回归」的循环。
第一步：建评测集
评测集是整套方法的地基，来源按优先级：
- 真实 badcase：线上日志里用户点踩、重问、转人工的 case，这是最有价值的部分，直接反映分布。
- 业务方定义的 golden case：和需求方一起梳理的典型场景，几十条起步。
- 合成数据扩充：用强模型按场景模板批量生成变体，人审后入库，把几十条扩到几百条。
每条样本要有明确的期望输出或评分标准。量级上，几十条能看出大问题，几百条才谈得上统计意义。评测集要和迭代同步生长——每修一个 badcase，它就进评测集成为永久回归项。
第二步：选评估方式
按任务类型选：
- 有标准答案的（分类、抽取）：准确率、F1，脚本直接算，成本为零。
- 格式类的：schema 校验通过率、关键词包含率，程序化检查。
- 开放生成的（摘要、问答）：没有标准答案，用 LLM-as-judge——让强模型按评分细则（rubric）对输出打分或做两两对比。注意裁判模型要比被测模型强，评分标准要具体到可执行（「答案包含 X 要点得 1 分」而不是「答案好不好」），且裁判结果要抽样人工校准，人机一致率太低（比如低于 80%）的 rubric 要回炉。
- RAG 场景：拆开评检索和生成，faithfulness（答案是否忠于检索内容）单独测，避免检索的锅甩给生成。
工具层面 promptfoo、LangSmith、Braintrust 这类平台都能跑批量评测和对比，自建的话核心就是一个「样本 × prompt 版本 → 批量推理 → 打分 → 出报告」的脚本，不难写。
第三步：版本管理与回归
Prompt 进 git，每次修改有 commit，评测报告和版本号绑定。任何改动先在评测集上跑出对比报告，整体指标不掉、目标 badcase 修复，才允许上线。线上灰度：新版本先切 5%-10% 流量，观察线上指标（采纳率、重试率、点踩率）无回退再全量。线上日志持续回流成新 badcase，闭环成型。
迭代时的几个纪律
一次只改一个变量，同时改指令又换示例，效果好坏都无法归因。优先修高频 badcase 模式，不要为单一边界 case 把 prompt 打满补丁——补丁摞补丁的 prompt 最后谁都维护不动，该重构就重构。改动幅度大时警惕过拟合评测集，留一份不参与迭代的 holdout 集做终验。如果迭代十几轮指标纹丝不动，停下来想想是不是到 prompt 的天花板了，该换模型或上微调。
一个可抄的最小闭环
Git 仓管 prompt 模板 + 一个 100 条左右的评测集 + 一个跑评测出对比报告的脚本 + 上线前必跑回归。这套东西一个人一两天就能搭起来，但它把 prompt 迭代从玄学变成了工程，这是面试官最想听到的答案。
可能的追问
- 评测集和线上分布漂移怎么办？ 定期从线上日志采样新 case 补充评测集（比如每月），淘汰不再出现的旧模式；监控线上输入分布的变化信号（新意图占比、长度分布漂移），分布变了评测集必须跟着变。
- LLM-as-judge 有什么已知偏差？ 位置偏差（两两对比时偏好先出现的）、长度偏差（偏好更长的回答）、自我偏好（裁判模型偏好自己风格的输出）。对策：交换顺序跑两轮取一致结果、rubric 里明确「长度不计分」、裁判和被测用不同家的模型。
- 多个 prompt 版本线上怎么共存？ 按租户或流量百分比路由到不同版本，配置中心管理版本标识，日志里记录每条请求用的版本号，指标按版本维度拆开看——没有版本标识的日志等于没记。