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