你已经提交了源内容，任务正在运行。引擎 ID 已通过 202 返回，引擎配置也在逐步补齐。本页要回答的，正是那个决定你会不会信任结果的问题：到底有哪些内容正在被补齐？
“AI 配置了我的引擎”这句话，足以让工程师本能地警惕，而这种警惕完全合理。它可能意味着一个你无法检查的黑箱；可能意味着记录散落在各个语言环境里，你根本对不上账；也可能意味着代理读到的源内容过于单薄、几乎没提取出什么，却悄悄只创建了寥寥几条记录。所以这一页会把这三件事讲得非常具体：代理会产出三类配置；每一类都会按可预测的规则映射到你的语言环境；任务还会返回一份摘要，逐条列出它创建的所有记录。最终输出的是你可以查看和编辑的普通记录，而不是一个只能靠信任接受的结论。
如果你刚接触异步 provisioning，建议先看 Async Provisioning API 概览 建立整体认知，再看 源类型 了解什么样的源内容值得提交。本页讲的是另一端最终产出的内容。
本页内容
三类组成部分#
代理会读取所有内容——无论是抓取到的页面，还是直接提供的原始内容——并创建三类引擎配置。它们不是 provisioning 专用的新格式，而是你原本就会在 engine 上手动创建的同一套基础配置。也正因如此，代理创建的所有内容，之后都能在控制台里继续编辑，和你编辑自己创建的内容完全一样。
| 组成部分 | 识别内容 | 示例 |
|---|---|---|
| 品牌语调 | 语气、风格、正式程度、写作规范 | “使用正式德语（Sie 形式）。句子保持简洁直接。” |
| 术语表条目 | 产品名称、技术术语、品牌专属译法、不可翻译术语 | “Acme” → 不可翻译，“workspace” → “Arbeitsbereich”（de） |
| 指令 | 格式规则、文化惯例、领域专属指南 | “德语翻译中的日期一律使用 DD.MM.YYYY 格式。” |
真正让译文听起来像你的产品、而不是泛泛直译的，正是这三类内容——你选定的正式程度、永远不翻译的名称、始终统一的日期格式。代理的工作，就是从源内容里找出这些已经明确表达过的决策，并把它们写成记录。
这里有一个影响预期的重要前提，必须说清楚：代理提取的是明确写出来的内容，不是字里行间的暗示。源内容把规则说清楚，就会生成记录；如果源内容只是示范了不错的语气，却没有明确写出规则，提取结果往往就会很少。这是源内容本身的特性，不是引擎的问题——源类型 会说明如何挑选那些会把规则明确写出来的源内容。
每一类如何映射到语言环境#
本地化引擎的配置是按目标语言环境组织的，所以一条记录不仅要说明规则是什么，还要说明它适用于哪里。代理会按一套你可以预期的规则为每条记录分配语言环境，而在阅读输出之前，最值得先理解的，就是 * 这个通配符。
- 品牌语调和指令在适用于所有语言时会使用
*。 像“句子保持简洁直接”这样的语气规则，并不是德语专属；它描述的是你的产品在所有语言中的写作方式。代理会把它分配到*这个目标语言环境上，因此它会应用到引擎支持的所有目标语言。真正只适用于某一种语言的规则（例如“德语使用 Sie 形式”），则会分配给对应的语言环境。 - 术语表条目会按语言对分别创建，因为翻译总是从一种语言到另一种特定语言——“workspace” → “Arbeitsbereich” 这个对应关系只属于德语。
- 不可翻译术语是例外，它们使用
*。 像 “Acme” 这样永远不翻译的品牌名，在所有语言里都不可翻译，因此它只需按*存储一次，而不必为每个语言对重复录入。
所以，当你在任务创建的记录里看到 * 时，它既不是占位符，也不代表有缺失。它的意思是“这条规则全局适用”——比如全局语气规则、全局指令，或者在任何语言中都不翻译的术语。相应地，具体的语言环境代码则表示：这条规则只作用于那一种语言。
为什么通配符是一种特性，而不是等着你去覆盖的默认值
对 * 最常见的一种怀疑是：“代理只是懒得判断这到底属于哪个语言环境。” 实际上正好相反。一个在所有语言中都成立的品牌语调或不可翻译术语，本来就应该是全局的——如果把它钉死在某一个语言环境上，反而会导致它悄无声息地无法应用到其他语言。通配符表达的正是“这条规则与具体语言无关”，而这恰恰就是语气规则或品牌名称最常见的情况。
输出摘要#
任务完成后，会返回一份摘要，点名列出代理创建的全部内容。这就是你的收据：每一条记录都有计数和标识，同时还会附带失败项清单。
{
"brandVoices": {
"count": 3,
"ids": ["bv_A1b2C3d4", "bv_B2c3D4e5", "bv_C3d4E5f6"]
},
"glossaryItems": {
"count": 12,
"ids": ["gi_A1b2C3d4", "gi_B2c3D4e5", "..."]
},
"instructions": {
"count": 5,
"ids": ["ins_A1b2C3d4", "ins_B2c3D4e5", "..."]
},
"errors": []
}每个组成部分都会返回一个 count，以及已创建记录的 ids——品牌语调对应 bv_，术语表条目对应 gi_，指令对应 ins_。这些不是含糊的确认信息，而是引擎中真实存在的记录 ID。你可以从列表里拿任意一个 gi_，在控制台中打开，准确查看或修改代理提取出的内容。摘要让你从“AI 做了一些事”，走到“它具体做了这二十件事”，这正是黑箱和你可以查看、可以编辑的普通记录之间的根本区别。
摘要会通过你在创建任务时设置的渠道送达给你：如果你配置了 webhook，它会出现在任务完成后发送到回调 URL 的 payload 中，并作为 summary 字段返回。如果你是通过 WebSocket 观察任务进度，那只是一个存活与进度通道——它会持续推送抓取和配置的进展，而不会发送这个摘要对象。摘要会随完成时的 webhook 一起到达；WebSocket 负责告诉你该在什么时候去读取它。
单条失败项不会导致整个任务失败。
如果某一条记录创建失败，也不会拖累其余结果。失败会记录在 errors 数组中，成功创建的记录仍会应用到引擎，任务也依然会正常完成。你拿到的是一个已部分配置好的引擎，以及一份精确列出待回查项的清单——而不是一个空引擎加一段堆栈跟踪。只有在整次运行完全没有产出任何可用内容时，任务才会整体失败；例如所有源都抓取失败。关于这种失败场景及其 provisioning.failed payload，可参见 Webhook delivery。
如何解读内容偏少的摘要#
摘要不仅告诉你创建了什么，也会通过计数告诉你这次运行到底值不值得。某个组成部分的 count 为 0 并不代表出错——摘要结构仍然完整，引擎也确实已创建——但这本身就是信息。三个品牌语调加十二个术语表条目，说明这是一个已经配置起来的引擎。相反，如果所有项都是零，且 errors 数组也是空的，那就说明返回的引擎几乎是空白的，代理其实是在告诉你：它几乎没找到多少可提取的规则。
出现这种情况时，原因几乎总在上游：源内容里明确写出的具体规则太少，代理没有足够内容可提取。摘要是你发现问题的地方；源类型 是你解决问题的地方。第一次运行时，最现实的预期应该是：这张收据只会如实反映你的源内容到底说了什么——摘要丰富，说明源内容丰富；摘要单薄，说明可提取的信息本来就不多。
这也是为什么摘要和引擎本身同样重要：它让你能够验证配置，而不是靠猜。看一眼计数，再按 ID 打开几条记录，确认代理确实抓到了你预期的内容——你可以查看和编辑的普通记录，外加一张清清楚楚告诉你该检查什么的收据。
