大厂 Evals 经验系列 · EDD 专题
团队给提示词加了一句“不要使用这种标题”，失败样本终于过了。接下来可以合并这次修改吗？
如果只检查刚才那条样本，还无法回答。新规则可能解决了眼前的问题，也可能让其他稿件的标题变得拘谨。本文想讨论的是：一次提示词修改，怎样取得值得保留的证据。
Google 在 web.dev 的 EDD 指南中，把提示词开发放在“简洁与有效”的取舍里：过短可能缺少必要指令，过长增加成本和维护负担；先有基线，再做小幅针对性调整。原文
这里的 EDD 指评测驱动开发。下面只保留一条短译句，其余以我的产品分析展开。标题助手是贯穿全文的假设场景，未运行实验，也不代表 Google 验证过的成果。
先明确：这次想减少哪一种失败
设想一个内部标题助手。编辑输入文章，系统返回几个标题供人选择。编辑抱怨“每次都像同一个模版”。这句话可以启动调查，却还不足以验收修改。
我会先问：相似发生在哪里？不同文章都套“全面解析”，还是同一篇的候选只有词语不同？两种问题对应不同要求。前者涉及跨文章的表达习惯，后者涉及同批候选的视角差异。混在一个“多样性分数”里，团队容易各自想象一种成功。
还要核对什么必须保留：标题能否准确表达正文，候选是否有可识别的区别，编辑是否能在有限时间内做选择。减少重复只是本次改善目标，准确性仍是要保护的要求。
我的建议是先写一句可核对的变更目标：“减少同批候选只替换近义词的情况，保留正文真实支持的判断。”这里没有承诺一定提高点击，也没有把编辑的选择替换成模型决定。
如果业务要求尚未说清，暂时增加提示词可能把争议藏起来。产品和编辑应先确认：是允许不同表达，还是要求不同读者收益？是否接受准确但朴素的候选？这些答案决定评测应该看什么。
基线留下的是比较条件
对这个假设产品，我会保存当前提示词、模型配置、输入集、评分规则和输出。基线就是这套条件下的初始表现。有了它，下一版才能与同一个参照比较。
样本可以包含短知识稿、长教程、观点稿和证据不足的手稿。这是我为例子设计的覆盖方式，实际分类应从产品服务的内容里确定。只选文笔整齐的稿件，会让团队低估编辑最常遇到的输入问题。
检查也可以分开做：结构和数量能否被程序读取；候选是否只是改写同一句话；每个标题是否得到正文支持。后一项需要看文章内容，不能靠扫描禁词完成。分开记录有助于知道改动到底影响了什么。
基线不是一次输出截图。假如两版只各跑一次，碰巧出现一个好标题，也可能改变结论。我建议在预算允许时对关键样本重复运行，保留失败的具体内容。若结果忽好忽坏，先报告不稳定，暂时不把它写成可靠改善。
还应留下运行耗时和输入输出用量。提示词缩短可能减少输入量，但整次任务的耗时也受输出长度、模型服务和其他环节影响。没有测量，就不能把“少写了几句话”直接换算成“产品更快”。
把一轮修改写成一个可以否定的猜想
Google 提醒：
“Be careful not to overfit.”
译：小心过拟合。原文“小幅针对性调整”一节
过拟合在这里可以理解为：提示词越来越适合手里的几道题，却未必适合下一批输入。以下是我对这条提醒的具体用法。
假设失败表现是：几个候选都用同一个结论，只换修饰词。先提出一个猜想：“候选之间没有被要求说明不同的内容角度。”这轮只尝试补清这个要求，不同时更换模型、增加示例、修改字数限制。
针对同批候选，可以试写：“各候选分别突出文章支持的不同问题或判断；如果文章只有一个核心观点，可以改变表达，但不要编造新的收益。”这是一条待验证的指令示例，不保证有效。
运行后，看此前失败的样本是否改善，也看原先表现合格的样本是否受损。如果候选看起来差别更大，却开始夸大正文，那么“多样性提升”不足以批准这版。
这里的一次针对性修改是为了便于解释结果，不代表系统永远只能改一个参数。若发现模型根本没有拿到完整正文，应该先修输入链路；提示词措辞不是这类失败的主要原因。评测需要帮助团队定位问题，而不是让团队只能在提示词里寻找答案。
修一类问题，需要用另一种表达来检查
若系统频繁输出“终极指南”，可以暂时加禁用词保护品牌规范。但如果真正的问题是空泛承诺，只禁这个短语，下一次仍可能出现“看完彻底掌握”。
我的判断是，应该区分业务明确禁止的词语，与用于说明失败的某个短语。前者可以直接约束；后者只是线索，需要找出更一般的要求，例如标题的承诺必须得到正文支持。
怎样检查是否形成了更一般的改善？我会留出一些未用于本轮修改的稿件，尤其包含表达不同、主题相近的输入。再看系统是否能识别新的空泛承诺，而不是仅仅避开已经写进提示词的词。
也要防止修得过头。假设正文确实系统介绍了某个主题，合理的概括性标题可以成立。不能为了降低“模版感”，要求每篇都制造冲突或问句。表面变化更多，也可能削弱表达。
如果“新样本”反复参与修改，它也会逐渐成为开发样本。我的建议是记录样本用途，定期补充未参与当前修改的材料；报告中写清观察到的覆盖范围，不把有限样本通过描述成通用能力。
把合并理由写到别人能够复核
在这个假设团队里，我会要求每轮留下四项说明：失败是什么；这轮改了什么；哪些输出发生变化；还有哪些输入没有改善。结果截图附在说明后，方便编辑检查判断。
保留修改，可以有不同理由。它可能改善了目标问题，也可能在质量相近时降低维护成本。两类收益应分别说明，避免把“更短”自动写成“更好”。对结果尚不明确的版本，保留实验记录，继续调查。
上线后若再次出现相似反馈，我会先核对输入和版本，再决定是否加入样本。单条点踩可能来自标题质量，也可能来自读者偏好；未经阅读就追加规则，容易增加提示词的矛盾。
这篇指南给我的启发，是把修改提示词当成需要解释的产品变更。下一次提交时，先写清“我认为哪种失败会减少”，再让比较结果决定这句话是否成立。编辑应能看到候选变好了哪些地方，仍然需要承担哪些判断。
系列相关阅读
本专题阅读顺序：完整理解 EDD → Google 的提示词实验 → OpenAI 的评测位置 → 微软的需求断言 → MLflow 的回归任务 → AWS 的协作验收 → 美团的双环评测。
评测基础可回读再读A社博文：怎样建立可信的 Agent 评测；判断评分可靠性，可继续阅读谁来给 AI 裁判打分与Agent 分数涨了，能力真的变强了吗。