做 AI 产品时，有一种结果比失败更难处理：它看起来有效，却没有好到足以让人放心。
最近，我为自己开发的浏览器翻译扩展 OnlyTranslate（只译）做了两轮实验，共生成 990 次翻译。
把现有方案的相对表现指数记为 100，最好的候选方案达到了 117.6。如果只看这个数字，它似乎已经足够成为一次版本更新：候选方案总体得分更高，也符合一个自然的直觉——给模型更多上下文，翻译结果应该更准确。
但拆开 165 组直接比较，结果是 52 组更好、90 组没有明显差别、23 组反而更差。汇总结果变好了，用户能明显感受到的改善却只出现在大约三成样本中。
但最后，我没有上线这个方案。
这篇文章想讨论的不是怎样写出一套更复杂的 Prompt，而是另一个更难回答的问题：
当实验结果总体更优时，怎样判断它是否已经好到可以成为默认功能？
一个很合理，但不一定成立的假设
浏览器翻译经常需要处理缺少语境的文本。
标题可能没有主语，短句可能依赖前文，一个单词在技术文档和新闻报道里也可能有完全不同的含义。
因此，最直观的改进是：不要只把待翻译文本交给模型，同时提供页面标题、待翻译内容所在的段落，以及它在段落中的位置。
现在也有越来越多产品提供“AI翻译增强”“高质量翻译”或“语义重写”等功能。它们通常会引入更多上下文，或者要求模型进一步润色和自我检查。这些功能很有吸引力，我也一直想让只译的翻译质量更进一步。
但在早期尝试中，我很快遇到了一个问题：结果很飘。
同一套Prompt换一个模型，效果可能完全不同；给某个模型增加几句要求，质量明显提高，换到另一个模型却可能不升反降。
有时标题和上下文可以帮助模型消除歧义，有时这些额外信息反而会把模型带偏。
几句出彩的译文很容易让人兴奋，却无法证明一套方案真的更好。
所以这一次，我决定不再凭几条样例判断好坏，而是先把“什么样的结果才值得上线”说清楚，再开始实验。
论文给我的，不是一个现成答案
在动手改Prompt之前，我集中读了十多篇与文档级翻译、上下文选择和翻译自我修正有关的论文，也检查了其中一些项目公开的实现。它们没有给出一段可以直接复制到产品里的“最强Prompt”，这个信号说明：这件事比我想象中的更复杂。
第一，上下文确实有用，但带来的不全是好处。 一项覆盖18个语言方向的人工评测发现，整段翻译比逐句翻译更连贯，误译、语法错误和风格不一致也更少；与此同时，遗漏内容等严重错误依然存在。上下文解决了一部分问题，也可能制造另一类更难发现的问题。相关研究：WMT 2023
第二，关键不是上下文越多越好，而是上下文是否真的相关。 有研究专门训练了独立的选择模块，为不同句子挑选不同数量的上下文。这个结果很有启发，论文中的收益来自“选择”，不能简单理解成“每次都附上固定范围的上下文”。相关研究：动态上下文选择
第三，很多看起来像Prompt优化的方法，实际是一整条翻译流水线。 MAPS 会先生成关键词、主题和参考样例，再生成多份候选译文并筛选；TEaR 则采用“翻译—评估—修订”的多阶段过程。它们能提高部分场景的质量，但已经不是一次模型调用。MAPS · TEaR
成本同样不能忽略。另一项比较单次翻译和多代理翻译的研究发现，顺序代理大约消耗单次方案 5 倍的 Token（模型输入输出用量），迭代代理约为 15 倍，而且质量并没有稳定胜出。相关研究：翻译质量与代理成本
这些论文没有替我选出一个现成方案，却改变了实验的重点：不能只比较哪些句子翻得更漂亮，还要同时观察严重错误、模型差异、格式失败和 Token 成本。论文验证有效的是整套方法，而不是其中某一句 Prompt；我们没法直接套用，所以我们设计的简化后的方案需要从头测试。
我给新方案设定的门槛
论文里效果更好的方案，往往愿意用更多步骤换取质量。但只译的默认翻译不能变成一条不断叠加模型调用的流水线。
大多数时候，用户只是想顺畅读完一篇文章，并不需要把每个段落都加工到可以出版。如果为了偶尔更自然的一句话，让所有内容都多调用一次模型，延迟、Token 和接口费用都会明显增加。
因此，候选方案需要同时满足几项要求：
- 默认仍然只调用一次模型；
- 不增加需要用户理解的新配置；
- 不依赖某个特定模型；
- Token 和延迟不能发生质的变化；
- 在不同通用模型上，都能稳定、明显地优于现有方案。
最后一条最重要：如果一套新方案只是“有时更好”，它增加的首先是系统复杂度，而不是可靠的产品收益。
第一轮：660 次翻译，没有一个方案过线
第一轮实验以只译1.8.2版本当时使用的简单 Prompt 作为基线 L，同时准备了三套候选方案：
- A：结构化上下文。 分开提供页面标题、目标文本和所在段落；
- B：精简上下文与自检。 缩短 Prompt，同时要求模型兼顾准确、自然，并在输出前自行检查；
- C：原位标记目标。 在原段落中标出待翻译文本，帮助模型理解指代和词义。
测试材料来自 11 个真实文章来源，每个来源选取 5 个片段，共 55 个测试单元。
我选择了 3 个通用模型，让它们分别运行基线和三套候选方案，温度及其他调用参数保持一致。
55 个片段 × 3 个模型 × 4 套方案 = 660 次翻译评分时，方案名称会被替换成匿名标签。每个被测模型生成的译文，再交给另外两个模型独立排序，允许并列；我也会人工抽查有争议的译文，并记录 Token、重大错误和格式异常。
为了汇总结果，我们把胜、平、负分别计为 1、0.5、0 分，再将基线 L 换算为 100，其他方案按相同比例折算：
| 方案 | 相对表现指数（L = 100） | 主要问题 |
|---|---|---|
| L：现有方案 | 100.0 | 基线 |
| A：结构化上下文 | 106.0 | 平均总 Token 从约 100 增至 234，差距仍不足以确认优于基线 |
| B：精简上下文与自检 | 100.0 | 不同模型上的效果方向会反转，重大错误率达到 15.2% |
| C：原位标记目标 | 63.6 | 格式失败率达到 42.4%，弱模型容易输出标记或错误格式 |
A 的指数是 106.0，但这不等于翻译质量稳定的提高了 6%。它只是在配对比较中略占上风，差距还不足以确认它真的优于基线，Token 却增加了一倍多。B 说明“更自然”和“输出前自检”并不是跨模型都有效的指令；C 在理论上让目标位置更明确，但只要模型不能稳定遵守输出格式，它就会从质量优化直接变成产品故障。
这轮实验让我比较清楚地看到：
上下文能够帮助某些句子，不等于把上下文加入默认流程就能提高整体体验。
第二轮：胜出的更多，但一半以上看不出差别
我没有马上停止实验。
第一轮的问题也可能不是上下文本身，而是上下文太多、结构太复杂，或者 Prompt 同时要求模型完成了太多事情。
第二轮把方案收敛得更加克制：完整段落仍然作为翻译单元，只为标题、划词和孤立短句补充更有针对性的语境；Prompt 则回到准确优先、不得增删的简单约束。
这一次继续使用相同的 11 个来源、55 个片段和 3 个模型，只比较基线和新的候选方案：
55 个片段 × 3 个模型 × 2 套方案 = 330 次翻译它们组成了 165 组一一对应的比较。这一次，与其先看一个压缩后的总分，不如直接看结果分布：
| 比较结果 | 数量 | 占比 |
|---|---|---|
| 候选方案更好 | 52 | 31.5% |
| 两者持平 | 90 | 54.5% |
| 基线更好 | 23 | 13.9% |
换成更直观的说法：大约三成译文变好了，超过一半看不出明显差别，同时仍有约一成半变得更差。
按照第一轮的相同规则折算，现有方案 L 为 100，候选方案的相对表现指数是 117.6。它在配对比较中比基准高出 17.6 个指数点。如果改用 5 分制直接评价译文质量，候选方案平均提高了 0.23 分。
这是整个实验中最有希望的结果。但重新阅读这些译文，问题也同样明显：
- 超过一半的比较没有明显差别；
- 同一句话换一个模型，优劣方向仍可能反转；
- 另外 23 组退步会直接表现为误译、遗漏或生硬改写。
汇总数字告诉我“它总体更好”，实际阅读却告诉我“用户未必能稳定感受到它更好”。这两句话并不矛盾。
平均更优，不等于适合成为默认值
离线实验关心的是：候选方案在一批样本中是否更常胜出。
产品默认值还要回答另外几个问题：
- 用户能否清楚感知到提升？
- 退步发生时，代价有多大？
- 换模型、换网页之后，改善方向是否仍然一致？
- 为了这点提升，系统增加了多少成本和故障面？
假设一个方案在 100 个段落里让 20 个略微变好，却让 5 个出现明显误译。平均分可能仍然上升，但在连续阅读时，那 5 次错误很可能比 20 次细微改善更容易被用户记住。
翻译也不是一个“赢了就结束”的排序游戏。用户真正关心的不是某个方案在匿名评测里取得了多少积分，而是自己能不能相信页面上的译文。
因此，这组结果对我来说是一个“值得继续研究”的信号，却不是一个“应该替换默认值”的结论。
我也考虑过增加一个“精译”按钮
既然全局增强不够稳定，我又延伸出一个按需处理的设想：普通翻译保持不变，用户觉得某个段落不好时，再点击“精译”或“优化译文”。这是我们在实验中自己提出的思路，不是照搬某个竞品已有的功能。
这样可以把额外调用限制在少数段落，不会拖慢整篇文章。
把它做成原型后，我发现它只是减少了调用次数，并没有解决质量判断：
- 模型经常只是换一种说法，并没有发现和修正明确问题；
- 标题、卡片、导航等短文本，很难决定按钮应该放在哪里；
- 如果只在正文段落提供入口，就必须先可靠判断什么是正文；
- 即使增加“先审校，再决定是否修改”的流程，最终仍然依赖模型不稳定的判断。
一个按钮很容易做出来，但要证明它按下去之后大多数时候真的更好，并不容易。
所以我最后也没有保留这个入口。
最后的产品选择：把难点交给划词
只译现在采用了一个更简单的方案：
- 普通网页翻译继续优先保证稳定和速度；
- 页面标题只作为较弱的上下文；
- 遇到不满意或难理解的内容时，由用户主动划词翻译；
- 划词只处理被选中的词、短语或句子，并利用所在段落的局部语境。
划词翻译并不是换了名字的“高质量模式”。它解决的是另一个问题：用户已经明确指出了哪里需要更多帮助。
系统不再需要猜测每个段落是否值得付出更多成本，也不必把实验中的不稳定性扩散到整篇页面。只有用户真正遇到理解困难时，系统才针对被选中的内容补充局部语境。
它未必是最炫的方案，却更符合我对默认功能的要求：可预测、可解释，而且失败范围有限。
暂时不做，也可以是一次完整的产品工作
AI 产品很容易陷入一种节奏：模型又进步了，竞品又增加了一个入口，我们似乎也应该尽快跟上。
但一个功能是否值得存在，不能只看它能不能做出来，也不能只看最佳样例有多惊艳。它还要看普通样例中是否存在稳定收益、失败时会伤害什么，以及它是否让整个产品变得更可信。
这次实验让我接受了一个不那么令人兴奋的结论：
暂时不做，也可以是一次完整的产品工作。
我仍会持续关注模型、Prompt 和上下文技术的变化，也会在合适的时候重新验证新的方案。不过在短期内，AI 翻译增强不会成为只译的重点。
这轮实验不是失败。它只是说明，新方案还没有好到足以替代一个简单、稳定、已经被用户理解的默认方案。
如果你想体验 OnlyTranslate，可以从 Chrome Web Store 安装：
从 Chrome Web Store 安装 OnlyTranslate
项目已开源：GitHub
如果你也在做 AI 产品，我很想知道你如何定义“足以上线”的门槛，尤其是当平均指标变好、个别失败却仍然明显的时候。
本文实验、数据与产品判断由作者完成；文章结构和文字整理使用了 AI 辅助，并由作者逐段修改、核对。
