引擎建议
你已经在译文上运行 自定义测量，因此能发现质量何时下滑——遗漏了某项要求、没有遵守正式程度规范，或分数跌破了门槛。发现问题是一回事，找到正确的引擎调整方案又是另一回事：你需要阅读未达标的 AI 评估，找出共性，判断该修改术语表词条、规则还是品牌语调，再写出具体方案。这第二步最耗时，也往往就这样被悄悄搁置。
引擎建议会替你完成这一步。当这些结果偏低时，Lingo.dev 会分析它们，找出共性，并针对引擎所应用的 术语表、规则 或 品牌语调 提出具体修改方案，同时附上理由。你可以审核后点击 应用，也可以选择 忽略。输入低分结果，得到具体的引擎修正方案。
建议是对配置的拟议修改，不是对翻译结果的改动
一个 suggestion，就是对引擎所用配置的一项待处理更改。应用后，会写入一条真实的术语表词条、规则或品牌语调文本——和你手动创建的是同一种记录。它不会重新翻译任何内容：这项更改会在引擎下一次执行翻译时生效。
低分自动触发建议#
建议主要通过这种方式生成。如果你对引擎的译文运行 自定义测量，测量选中的每条译文都会按你自己的标准接受检查。结果偏低——未通过，或分数低于 80——就意味着引擎需要调整。开启 提出改进建议 后，Lingo.dev 会自动响应这个信号：分析低分结果，找出共性，并在后台提出修改建议，无需你主动请求。
只有自定义测量会为建议提供依据。内置检查——术语表遵循度、规则遵循度和 MQM——会报告引擎配置的表现，但不会触发建议，也不会为建议提供依据；对历史译文补跑测量所得的结果也不会。
在引擎的 AI 评估器 选项卡中，进入 建议 部分并启用此功能。此后，低分结果会在后台自动生成建议，你可以在 队列 的 建议 下找到它们。
下面还有第二个开关：无需询问直接应用。打开后，建议会直接写入引擎，而不是先进入 队列 等待你决定。它只有在 提出改进建议 开启时才会生效；一旦关闭 提出改进建议，它也会随之关闭。
会批量处理，不会刷屏
自动生成会合并短时间内的触发，每个引擎大约每十分钟运行一次。因此，集中出现的低分结果会生成一批经过综合分析的建议，而不是大量零散建议。相同的建议会自动去重，同一项修改不会出现两次。
任何翻译都可能触发#
触发信号来自测量结果，而非译文来源。无论引擎执行的是 同步调用、异步任务，还是经过完整 本地化流水线 的任务，完成的本地化内容都会接受相同的自定义测量检查，低分结果也会为同样的建议提供依据。因此，经过启用 AI 评估的引擎处理的翻译越多，建议就越能反映生产环境中实际出现的问题。
人工修正本身也是一种信号#
当评审者手动修正一条翻译时，其实已经告诉你引擎哪里出了问题——这次修正本身就是答案，只是还没写进你的配置里。所以，只要某个开启了 提出改进建议 的引擎完成了一次人工编辑，Lingo.dev 就会把修改后的内容与引擎原本产出的结果进行比对，并提出那条本可以让这次编辑变得不必要的规则。无论是你的团队在应用里自行编辑、外部认证译者修改，还是同事接手卡住的外部审核，收到的都是同一种信号，生成的也会是同一类建议。只有评审者实际改动过的键才会被计入，所以原样批准一条翻译既不会带来额外成本，也不会教会引擎任何东西。
基于编辑的建议绝不会替你自动应用
修正也可能来自你的团队之外，因此基于这类修正生成的建议，在你点击 应用 之前都会保持 pending，即使 无需询问直接应用 已开启也是如此。引擎只能通过你来学习外部译者的修改。
按需生成#
你不必等到下一个低分结果出现。控制面板上没有对应的按钮，但 引擎建议 API 中的 POST /engines/:id/suggestions/generate 可以立即执行同样的分析，综合考虑近期的人工修正、自定义测量的低分结果，以及引擎的当前配置，无论是否开启 提出改进建议。做了其他调整后想重新分析，或想主动获取建议而不是等待它们出现时，都可以使用它。
建议会改什么#
每条 suggestion 都会指向引擎配置中的三个部分之一，并且要么是新增，要么是更新现有条目：
| 操作 | 应用后会发生什么 |
|---|---|
| 新增 / 更新术语表项 | 创建或修改一个 术语表 词条——可以是强制采用的译法，也可以是标记为不可翻译的术语。 |
| 添加 / 更新规则 | 在引擎使用的规则集中，按语言区域创建或修改一条 规则。 |
| 新增 / 更新品牌语气 | 为某个语言区域创建或修改 品牌语调 文本，供引擎在该语言区域使用。 |
每条建议都会附带 reasoning——也就是一段简短说明，解释它为什么提出这项修改——以及它适用的目标语言区域。你不需要去盲目信任一次黑盒变更：在任何内容被写入之前，你都能先看清它要改什么、为什么这么改。
由于这套配置归组织所有，应用一条 suggestion，实际上是在编辑一个其他引擎也可能会使用的容器。suggestion 会标明目标对象，因此你可以在批准前先看清这次写入会影响到哪里。
建议足够精准，不会大动干戈
模型提出的是原子级修改——一条术语表词条、一条规则——而不是重写整个引擎。每一项都会单独审核、单独应用，因此你可以保留其中三个正确的，舍弃那个不合适的。
审核、应用、忽略#
建议会以 pending 的形式出现在 队列（/orgs/<org-id>/queue）的 建议 下，等待你处理。每条建议都会显示建议的修改、目标语言区域、理由、建议依据——自定义测量的低分结果、人工修正，或两者兼有——以及修改将应用到哪里：写入引擎已应用的术语表（或规则集、品牌语调）时，显示 写入术语表（或规则集、品牌语调）；新建时，显示 创建术语表（或规则集、品牌语调）。你可以执行两种操作：
Apply
将建议的更改写入引擎所用的配置中——写入的是一条真实的术语表词条、规则或品牌语调文本。Apply 是对所提议修改的一次确定性写入：不会再发起第二次 AI 调用，也不会有意外。该 suggestion 会被标记为 applied，并且更改会在引擎下一次翻译时生效。
Dismiss
丢弃这条建议。当某项提议不适合你的产品时，就用它——你对自己的术语体系，比任何模型都更了解。Dismiss 不会对引擎做任何改动。
由于 Apply 写入的是和你手动创建时完全相同类型的记录，所以一条已应用的 suggestion 之后并不是黑盒：它就是一条普通的术语表词条、规则或品牌语调文本，你可以像处理其他条目一样打开、编辑或删除它。
Apply 不会重新翻译
应用建议修改的是引擎配置，不是历史翻译。已经翻译过的内容会保留现有输出，直到再次被翻译。改进会在下一次通过该引擎运行时体现出来。
根据你的反馈生成建议#
并不是每个问题都会表现为低分。有时候，语言学家或支持工单会直接用明确的话告诉你问题出在哪里——“德语文案太生硬了”“不要再翻译产品名了”。你可以通过 Engine Suggestions API 直接输入这些文本，得到同样类型的建议。流程还是这里这套审核—应用—忽略；不同的只是触发方式——触发它的是你写下的反馈，而不是审校分数。
Reviewers 负责衡量，Suggestions 负责行动#
AI 评估器 和引擎建议共同构成一个质量闭环。AI 评估器负责 衡量——根据你的术语表、规则和自定义标准检查每条译文，指出质量下滑之处。建议负责 行动——分析自定义测量的低分结果，提出能改善这些结果的引擎调整方案。AI 评估器发现问题，建议拟定修正方案，由你做决定。两者共同形成闭环：翻译、评分、建议、应用，让下一条译文更好。