为什么只译暂时不做 AI 翻译增强
让翻译质量更好，一直是只译想解决的事情。
我们也持续关注同类产品。近来，越来越多产品开始提供「AI 翻译增强」「高质量翻译」或「语义重写」：有的引入更多网页语境，有的通过不同的 Prompt 强调更自然的表达。
这些功能很有吸引力，我们也一直想加入。之所以迟迟没有实践，并不是没有看到它们，而是我们在早期尝试中就遇到了一个问题：翻译结果很飘。
同一套 Prompt 换一个模型，结果可能完全不同；给某个模型增加几句指令，质量可能明显提高，换到另一个模型却可能不升反降。有时增加标题和上下文能解决歧义，有时模型反而会被这些信息干扰。单看几句出彩的译文，很难判断一套方案是否真的更好。
最近看到更多竞品继续在这条路上投入，我们决定不再只凭印象讨论，而是认真做一次测试。
先把「更好」说清楚
开始实验前，我们先给这项功能划定了边界。
语义重写或二次润色不应该成为每一段翻译的常态。大多数时候，我们只是想顺畅读完一篇文章，并不需要把每段译文都处理到可以出版的程度。如果为了偶尔更自然的一句话，让所有段落都多调用一次模型，延迟、Token 和接口费用都会显著增加。
因此，我们希望找到的方案必须满足：
- 默认仍然只调用模型一次；
- 不增加需要用户理解的新配置；
- 不依赖某个专用翻译模型；
- Token 和延迟不能发生质的变化；
- 在不同通用模型上，都能显著、稳定地优于现有方案。
这里最重要的是最后一条。新方案如果只是「有时更好」，那我们增加的就只有复杂度，而不是可靠的产品收益。
实验一：更多上下文，能否让一次翻译明显变好？
实验假设
第一轮实验从一个直观想法开始：模型翻错，可能是因为看到的信息不够。
如果把页面标题、所在段落和目标文本的关系说得更清楚，再补充对准确性和自然度的要求，模型也许可以在不增加调用次数的情况下，减少歧义和翻译腔。
实验设计
我们以 1.8.2 的简单翻译方式作为基线 L，又准备了三套候选方案，用来拆开比较「上下文本身」「Prompt 写法」和「目标位置」的作用：
- A：结构化上下文。 把页面标题、目标文本和所在段落分开提供给模型。
- B：精简上下文与自检。 缩短 Prompt，同时要求模型兼顾准确、自然，并在输出前自行检查。
- C：原位标记目标。 把待翻译文本标记在原段落中的位置，帮助模型理解指代和词义。
小样本里，每一种方案都有表现出彩的时候，也都有明显失误。为了避免凭感觉挑选，我们把测试扩大为：
- 11 个真实文章来源，每个来源选取 5 个片段，共 55 个测试单元；
- 3 个通用翻译模型；
- L、A、B、C 四套方案，温度和调用参数保持一致；
- 共执行
55 × 3 × 4 = 660次翻译。
评分时，方案名称会被随机替换为匿名标签。每个被测模型生成的译文，都交给另外两个模型独立排序，允许并列；最后再按文章来源汇总，避免把同一篇文章中的五个片段当成完全无关的样本。我们同时抽查争议译文，并记录 Token、延迟、重大错误和格式异常。
实验结果与反思
相对 L 的基准得分率 50%，三套候选方案的总体结果是：
| 方案 | 相对 L 得分率 | 主要问题 |
|---|---|---|
| A：结构化上下文 | 53.0% | 95% 置信区间仍跨过 50%；平均总 Token 从约 100 增至 234 |
| B：精简上下文与自检 | 50.0% | 不同模型上的方向会反转，重大错误率达到 15.2% |
| C：原位标记目标 | 31.8% | 格式失败率达到 42.4%，弱模型容易输出标记或错误格式 |
这里的 53.0% 不是「质量提高了 3%」。它只说明 A 在这次测试中略占上风，但差距还不足以让我们确认 A 真的比基线更好。
第一轮没有任何方案达到「稳定、显著优于现有翻译」的门槛。
A 是唯一表现出正向趋势的方案，但优势很小，Token 却增加了一倍多。B 说明更强的自然表达和自检要求并不具备跨模型通用性；C 则说明一个理论上更准确的上下文结构，如果模型不能稳定遵守输出协议，反而会直接变成产品故障。
这一轮最重要的结论不是「上下文没用」，而是：某些句子从上下文中受益，不代表把上下文加入默认流程就能稳定提高整体质量。
实验二：更克制地使用上下文，会不会更稳定？
实验假设
我们没有立刻停止。第一轮的问题也可能不是「上下文」本身，而是上下文太多、组织方式太复杂，或者 Prompt 同时要求模型完成太多事情。
新的假设是：完整段落继续作为翻译单元，只在标题、划词和孤立短句中补充更有针对性的语境；Prompt 回到一次调用、准确优先、不得增删的简单约束。这样也许能保留下上文消歧的收益，同时减少复杂指令带来的波动。
实验设计
第二轮继续使用相同的 11 个来源、55 个片段和 3 个模型，只比较基线与新的候选方案：
- 每个片段分别生成一份基线译文和一份候选译文，共 330 次翻译；
- 形成 165 组一一对应的比较；
- 继续使用匿名排序与双裁判，胜、平、负分别计 1、0.5、0 分；
- 除总体得分率外，还比较不同模型的方向、平均质量分和人工阅读感受。
50% 表示候选方案与基线总体持平。只有明显高于这条线，而且不同模型上的方向一致，才有资格成为新的默认方案。
实验结果与反思
第二轮最好的候选方案取得了：
| 结果 | 数量 | 占比 |
|---|---|---|
| 候选方案更好 | 52 | 31.5% |
| 两者持平 | 90 | 54.5% |
| 基线更好 | 23 | 13.9% |
按胜一分、平半分计算，它相对基线的得分率是 58.8%，比 50% 持平线高 8.8 个百分点。这个数字不是「翻译质量提高了 8.8%」，而是候选方案在这套配对规则下取得了更多比较积分。平均质量分提高了 0.23 分（5 分制）。从实验数字看，这是我们测试过最有希望的结果。
但回到实际阅读和人工复核，问题仍然存在：90 组、也就是超过一半的译文没有明显差别；同一句话在不同模型上仍可能出现相反结果；23 组退步会直接表现为误译、遗漏或生硬改写。
这让我们区分了两件事：实验中总体更优，不等于产品里稳定可感知地更好。 58.8% 说明方案值得继续研究，却还不能证明用户在连续阅读时会明确感受到提升。
另一个假设：只优化用户不满意的段落
实验假设
既然全局增强的成本太高，我们在实验过程中又自行延伸出一个按需处理的设想：普通翻译保持不变，用户觉得某段不好时，再点一次「精译」或「优化译文」。这不是照搬某个竞品已有的功能，而是我们试图在质量和成本之间寻找的另一条路。
这个方案把额外调用限制在少数段落，理论上不会拖慢整篇文章。
实际遇到的问题
新的问题很快出现了：
- 模型经常只是换一种说法，更像重译，而不是发现并修正明确问题；
- 标题、卡片、导航和 GitHub 首页这类非文章页面，不知道应该在哪里提供「精译」入口；
- 如果只在正文段落显示，就要先可靠判断什么才是高置信度正文；
- 即使增加「先审校、再决定保留或修改」的结构化输出，最终仍要面对模型判断本身不稳定的问题。
我们的反思
一个按钮很容易做出来，但要证明按钮点下去后大多数时候真的更好，并不容易。按需精译减少了调用次数，却没有解决「如何确认结果真的改善」这个核心问题，还额外带来了入口位置和正文识别的复杂性。
当前答案：普通翻译保持稳定，难点交给划词
最终，我们没有把这套 AI 增强做成默认功能，也没有保留一个效果尚不稳定的「精译」入口。
当前更简单、也更符合真实使用习惯的方案是：
- 普通网页翻译继续追求稳定与速度。 页面标题只作为弱上下文，模型只能输出待翻译文本。
- 遇到不满意或难理解的内容时，使用划词翻译。 用户可以只选中一个词、短语或句子，让模型在所在段落的局部语境中重新理解它。
划词翻译并不是「高质量模式」的替代包装。它的优势在于目标明确、由用户主动触发，也只为真正需要理解的部分付出额外成本。相比在每篇文章、每个段落上持续增加 Prompt 和调用，这更符合只译在质量、性能与成本之间的取舍。
继续关注，但暂不作为重点
我们仍会持续关注模型、Prompt 和上下文技术的最新发展，也会在合适的时候重新验证新的方案。不过，根据目前的实验结果，AI 翻译增强在短期内不会成为只译的重点。我们会把精力放在更稳定、更明确，也更容易被用户感知的改进上。