你已经在译文上运行了 AI Reviewers，所以一旦质量下滑，你就能及时发现——可能是某个术语表词条被忽略了、某条正式程度规则没有遵守，或者分数跌破了门槛。看到问题是一回事，把它转化成正确的引擎调整又是另一回事：你得阅读那些未通过的审校结果，找出它们的共同点，判断问题该落在术语表、规则还是品牌语调上，然后再亲手写出来。第二步才是最耗时的，而它往往也会在不知不觉中被搁置。
Engine Suggestions 会替你完成这一步。当审校结果分数偏低时，Lingo.dev 会读取这些结果，找出共性，并准确提出该如何修改 术语表、规则 或 品牌语调——还会附上原因说明。你只需查看后点击 Apply，或选择 Dismiss。低分进来，明确的引擎修复建议出来。
建议是对配置的拟议修改，不是对翻译结果的改动
一个 suggestion，就是对引擎所用配置的一项待处理更改。应用后，会写入一条真实的术语表词条、规则或品牌语调文本——和你手动创建的是同一种记录。它不会重新翻译任何内容：这项更改会在引擎下一次执行翻译时生效。
低分自动触发建议#
这是 suggestion 最常见的来源。如果你在运行 AI Reviewers，那么每条译文其实都已经在根据你的术语表、规则和自定义标准接受评分。连续出现低分——无论是布尔检查未通过，还是百分比分数低于门槛——都说明引擎里有些地方需要微调。开启 auto-suggestions 后，Lingo.dev 就会替你利用这个信号：它会读取未通过的审校结果，找出其中的共性，并在后台主动提出修改建议，无需你手动触发。
你可以在引擎的 Reviews 标签页中启用它。从那之后，一波低分就会悄悄生成建议；你会在 Suggestions 标签页里看到它们，也会收到通知，不会让它们默默躺着没人发现。
会批量处理，不会刷屏
自动生成带有防抖机制，大致控制在每个引擎每十分钟运行一次。因此，一波低分只会产出一批经过归纳的建议，而不是一连串消息轰炸。相同的提议也会自动去重，所以你不会两次看到同一条编辑建议。
任何翻译都可能触发#
真正的触发信号是审校分数，而不是翻译来源。无论引擎执行的是 synchronous call、async job，还是通过完整 localization pipeline 运行的任务，结果都会由同一套 AI Reviewers 评分——低分也都会进入同一套建议机制。因此，经过审校引擎处理的翻译流量越多，这些建议就越能准确反映生产环境里真正出问题的地方。
人工修正本身也是一种信号#
当审核者手动修正译文时，其实已经明确告诉你引擎错在哪里——这次修正本身就是答案，只是还没有体现在你的配置中。所以，每当人工编辑完成后，Lingo.dev 都会将修改结果与引擎产出进行比对，并给出一条规则建议：如果这条规则当时已存在，这次修改原本就可以省去。无论是你的团队直接在应用内编辑、外部认证译者进行修订，还是同事接手一个卡住的外部审核，传递的都是同一种信号，得到的也会是同样的建议。只有审核者实际改动过的键才会计入，因此原样批准一条翻译，既不会产生任何成本，也不会带来任何学习。
基于编辑的建议绝不会替你自动应用
修正可能来自团队之外，因此基于修正生成的建议会始终保持 pending，直到你点击 应用——即使是在会自动应用自身建议的引擎上也是如此。引擎只能通过你，才能从外部译者的修正中学习。
按需生成#
你不必等下一次低分出现。点击 Generate suggestions 按钮，就会立刻运行同样的分析——基于近期的低分审校结果和引擎当前配置——无论是否启用了 auto-suggestions 都可以使用。适合在你做了其他修改后想重新判断一次时使用，或者当你更想主动获取建议，而不是被动等待它们出现时使用。
建议会改什么#
每条 suggestion 都会指向引擎配置中的三个部分之一，并且要么是新增，要么是更新现有条目：
| 操作 | 应用后会发生什么 |
|---|---|
| 新增 / 更新术语表项 | 创建或修改一个 术语表 词条——可以是强制采用的译法，也可以是标记为不可翻译的术语。 |
| 添加 / 更新规则 | 在引擎使用的规则集中，按语言区域创建或修改一条 规则。 |
| 新增 / 更新品牌语气 | 为某个语言区域创建或修改 品牌语调 文本，供引擎在该语言区域使用。 |
每条建议都会附带 reasoning——也就是一段简短说明，解释它为什么提出这项修改——以及它适用的目标语言区域。你不需要去盲目信任一次黑盒变更：在任何内容被写入之前，你都能先看清它要改什么、为什么这么改。
由于这套配置归组织所有，应用一条 suggestion，实际上是在编辑一个其他引擎也可能会使用的容器。suggestion 会标明目标对象，因此你可以在批准前先看清这次写入会影响到哪里。
建议足够精准，不会大动干戈
模型提出的是原子级修改——一条术语表词条、一条规则——而不是重写整个引擎。每一项都会单独审核、单独应用，因此你可以保留其中三个正确的，舍弃那个不合适的。
审核、应用、忽略#
建议会以 pending 的形式出现在引擎的 Suggestions 标签页中。每条建议都会展示拟议的修改、目标语言区域和理由。你有两个操作：
Apply
将建议的更改写入引擎所用的配置中——写入的是一条真实的术语表词条、规则或品牌语调文本。Apply 是对所提议修改的一次确定性写入：不会再发起第二次 AI 调用，也不会有意外。该 suggestion 会被标记为 applied，并且更改会在引擎下一次翻译时生效。
Dismiss
丢弃这条建议。当某项提议不适合你的产品时，就用它——你对自己的术语体系，比任何模型都更了解。Dismiss 不会对引擎做任何改动。
由于 Apply 写入的是和你手动创建时完全相同类型的记录，所以一条已应用的 suggestion 之后并不是黑盒：它就是一条普通的术语表词条、规则或品牌语调文本，你可以像处理其他条目一样打开、编辑或删除它。
Apply 不会重新翻译
应用建议修改的是引擎配置，不是历史翻译。已经翻译过的内容会保留现有输出，直到再次被翻译。改进会在下一次通过该引擎运行时体现出来。
通知#
当一次生成产生了新的建议时，引擎成员会收到通知——包括应用内通知和电子邮件——这样改进建议就不会躺在某个没人打开的标签页里。这和平台其他功能使用的是同一套通知系统：如果你不想收到这类提醒，可以在通知偏好中将 Engine suggestions generated 设为静音。
根据你的反馈生成建议#
并不是每个问题都会表现为低分。有时候，语言学家或支持工单会直接用明确的话告诉你问题出在哪里——“德语文案太生硬了”“不要再翻译产品名了”。你可以通过 Engine Suggestions API 直接输入这些文本，得到同样类型的建议。流程还是这里这套审核—应用—忽略；不同的只是触发方式——触发它的是你写下的反馈，而不是审校分数。
Reviewers 负责衡量，Suggestions 负责行动#
AI Reviewers 和 Engine Suggestions 是同一个质量闭环中的两部分。Reviewers 负责衡量——它们根据你的术语表、规则和自定义标准为每条译文打分，并告诉你质量是从哪里开始下滑的。Suggestions 负责行动——它们读取这些低分，并提出能够提升分数的引擎修改建议。Reviewers 发现问题；suggestions 起草修复方案；由你来决定。它们一起补上了这个闭环：翻译、评分、建议、应用，然后下一次翻译就会更好。
