版权与内容来源声明
本文为原创整理。文中涉及官方文档、开源仓库、论文与公开报道的内容，均在附表 A 中标注来源；引用官方原文保持原样，不作改写。文中命令、版本号与界面截图以本文成文时的实测/核验结果为准，标注「待验证」的部分请以你本地环境实际输出为判断依据。本文不推荐任何不合规的软件获取方式，也不对任何收益结果作承诺。转载请注明出处。
1. 你其实早就做过一次「术语统一」，只是没把它当成模型问题
1.1 一个具体的活：同一个 SKU，八种语言的详情页
假设你手上有一款便携榨汁杯，要上架到德语、法语、西语、日语、韩语、葡萄牙语、俄语、阿拉伯语八个语站。每个语站至少要三份文案：标题、五点卖点、详情页长描述。这个产品里有三类说法必须固定：品牌名（固定拼写、固定大小写）、核心部件名（比如「刀头组件」）、以及一个你们自己造出来的卖点词组（比如「一键自清洗」）。
这三类词在不同语站写成不同样子，后果不是「不好看」，而是三件很具体的事：客服拿着德语的说法去对日语的说法，用户会觉得像两个产品；站内搜索会把同一个词的不同译法当成两个词；不同语站的品牌自造词写法不一致，容易被判成不同来源的内容。
SKU 第一次出现，给一句人话解释：SKU 就是「最小库存单位」，可以理解成「一个能单独上下架的货品」。
1.2 人力时代你是怎么做的：术语表 + 译审抽查
做过跨境的团队，流程大同小异：先把必须固定的词挑出来，做成一张对照表（源语术语 → 各语种指定译法），交给译员；译员交稿后，译审不逐字读，而是专门盯这张表——把每个固定词在稿子里出现的位置过一遍，看有没有跑偏。
这张表就是术语表（glossary）。术语表第一次出现，给一句人话解释：术语表就是一张「指定译法清单」，它规定某个词在每种语言里必须写成什么，其余写法一律算错。
关键不在「表做得多全」，而在它是一条硬规则：译员没有「我觉得这么翻更好」的空间，只有「按表来」。你付给译审的钱，买的不是文采，就是这个词有没有落回表里。
1.3 换成模型，问题一模一样，只是「译员」换成了模型
现在你想让模型批量出这八种语言的文案。你可能已经试过一句提示词：「请把下面这段中文翻译成德语、法语、西语……保持术语统一、风格一致。」结果往往是这样：读起来相当通顺，但**「刀头组件」在德语里叫 A、在法语里叫 B**，那个自造卖点词组更是每个语种一个新说法。
这不是模型「不听话」，而是你给的约束本身不算约束。「保持统一」是在要求一个结果，不是在给一条可执行的规则——它没说清「统一到哪个写法上」。这就是本文的分界线：多语言批量生成的一致性，靠的是术语表硬约束，而不是「请保持统一风格」这类软提示。
2. 为什么「请保持统一风格」这类软提示靠不住
2.1 软提示到底是什么
软提示在这里指「用自然语言描述希望达到的效果」。第一句人话解释：软提示就是你用日常语言对模型说「请保持风格统一」「语气专业一点」，把判断标准留给模型自己去理解。它和硬约束相对——硬约束第一次出现，人话解释：硬约束是把要求变成一份具体清单或一套能自动检查的规则，写死、没有解释空间的那部分。
软的坏处很具体：同一个要求，模型每次理解的都不一样。你在第一条文案上说「统一」，它就统一到当次想到的写法；生成到第五条，它换了一个「更自然」的写法。你什么都没改，结果却变了——软提示连「同一次会话内保持一致」都保证不了，更别提跨语种、跨批次。
2.2 官方指南自己也这么说：指令要具体、格式要用示例讲清、要给参考文本
OpenAI 的官方提示工程指南把策略分成六条，第一条就叫「编写清晰的指令」（Write clear instructions）。里面有一句几乎是本文论点的原话：「模型不会读心术……如果你不喜欢输出格式，就把你想要的格式演示给它看。模型需要猜的东西越少，你越可能得到想要的结果。」这条策略下的具体做法包括：在请求里补充细节、给模型提供示例、用分隔符（例如###或"""）把指令和上下文分开。
第二条策略是「提供参考文本」（Provide reference text），给的做法是：指示模型「用给定的参考文本作答」。以及最后一条策略「系统性地测试改动」（Test changes systematically），官方建议把模型输出与「黄金标准答案」比对来评测——也就是说，「好不好」必须能被度量，不能靠感觉。
把这几条落到多语言文案上，结论很直接：你说「保持统一」，既没给参考文本，也没给示例格式，更没有可度量的判据——它正好踩在官方指南提示的这些事情的反面。你需要的不是更委婉的措辞，而是把「必须写成什么」直接交给模型。
（说明：以上内容出自 OpenAI 官方指南页platform.openai.com/docs/guides/prompt-engineering；成文时本机抓取该页被 Cloudflare 拦截，内容经 OpenAI 官方帮助中心同主题文章逐条核对，详见附表 A。）
2.3 软提示 vs 术语表硬约束：差别在哪
| 维度 | 软提示（请保持统一） | 术语表硬约束 |
|---|---|---|
| 约束形式 | 一句自然语言要求 | 一份「源语术语 → 各语种指定译法」的清单 |
| 判断标准 | 模型自己理解「统一」 | 写死的指定译法，非指定写法一律算错 |
| 能否自动检查 | 不能，只能人来读 | 能，可按清单逐条回扫 |
| 跨批次一致性 | 差（每次理解可能不同） | 好（每次都读同一份表） |
| 出错时的表现 | 读起来很顺，术语悄悄换了说法 | 要么落回指定译法，要么被检查脚本抓出来 |
| 维护成本 | 低（写一句话） | 中（要维护一张表） |
术语表是有成本的，而这个成本恰恰是它生效的原因：你把「哪些词必须固定」想清楚了，才固定得住。
3. 术语表要写哪些字段
3.1 最小字段集：六个字段就够开跑
| 字段 | 写什么 | 为什么必须有 |
|---|---|---|
| 术语 ID | 一个稳定不变的编号或短名 | 后续回扫、改译法时要能对上号，不能靠「第几行」 |
| 源语术语 | 中文（或你的源语）原始写法 | 用来在上游文案里定位 |
| 目标语 | 语言代码，如 de / fr / ja | 一条术语一行撑不住八种语言，要拆开 |
| 指定译法 | 该语种必须使用的写法（逐字） | 这是硬约束的核心，必须逐字写死 |
| 大小写与格式 | 首字母是否大写、是否有连字符、是否全大写 | 品牌词、缩写最容易在这里跑偏 |
| 禁用替代写法 | 明确列出「不许写成什么」 | 光说「写 A」不够，模型仍可能用「更自然」的 B |
「短名」这个词在工程里常写成 slug，一句话解释：slug 就是给某个东西起的简短、稳定、只用字母数字和连字符的名字，方便程序引用。
「语言代码」也解释一句：这里用的是两位小写字母的通用缩写，比如 de 代表德语、fr 代表法语、ja 代表日语；不要用「德语」「法文」这种中文名当字段值，程序不好对齐。
3.2 一份能直接用的术语表长什么样
用 JSON 存最省事——JSON 第一次出现，人话解释：JSON 是一种用大括号和方括号组织「键—值」数据的文本格式，程序和人读起来都还算清楚。下面这份是示例结构，未在实际业务里跑过：
⚠️代码待验证
{"glossary_id":"portable-blender-v1","source_lang":"zh","terms":[{"term_id":"blade_assembly","source":"刀头组件","targets":{"de":{"text":"Klingenbaugruppe","case":"capitalize","forbidden":["Messerkopf","Klingenmodul"]},"fr":{"text":"bloc-lames","case":"lower","forbidden":["ensemble de lames"]},"ja":{"text":"ブレードユニット","case":"asis","forbidden":["刃アセンブリ"]}}},{"term_id":"self_clean_feature","source":"一键自清洗","targets":{"de":{"text":"Ein-Knopf-Selbstreinigung","case":"capitalize","forbidden":["automatische Reinigung"]},"fr":{"text":"auto-nettoyage en un clic","case":"lower","forbidden":["nettoyage automatique"]},"ja":{"text":"ワンタッチ自動洗浄","case":"asis","forbidden":["自動クリーニング"]}}}]}三个字段的用法：case写清大小写的处理方式（capitalize首字母大写、lower全小写、asis原样不动）；forbidden是禁用替代写法，它比「指定译法」更能挡住模型；term_id别看它不起眼，后面改译法时全靠它定位。
3.3 最容易漏的三个字段
一是大小写。德语的书写规则里，名词首字母大写是常规做法，但你的品牌名可能要求全小写；日语没有大小写问题，可片假名与汉字的选择同样要写死。大小写敏感的写法必须显式说明（本文未引具体正字法规范原文）。
二是禁用替代写法。只说「用 X」仍不够——模型在长文案里可能认为「用 Y 更自然」。把 Y 明确列出来，检查脚本才有东西可抓。
三是适用范围。一个术语不一定八个语种都要固定：某个词可能只在德语和法语需要统一，日韩语可以自由意译。不写适用范围，你会被迫在所有语种上硬套。建议给每条术语加一个applies_to字段，写清它管哪几个语种。
4. 把术语表变成「硬约束」的三种落地方式
4.1 方式一：生成前注入（把术语表塞进提示）
最直接的做法是：每次生成前，只把该语种、该批次用得上的术语按固定格式拼进提示，并写明「以下术语必须逐字使用，不得替换」。两个细节：只注入本批次用得上的术语（八个语言全塞进去，占上下文还让模型分心）；用分隔符把术语表和正文分开——这正是官方指南建议的做法。
⚠️代码待验证
GLOSSARY_SEP="###"INSTRUCTION=("你是跨境电商文案翻译助手。下面给出术语表，""术语表里的指定译法必须逐字使用，不得替换为其它说法。")defbuild_terms_block(glossary,lang,used_term_ids):lines=[]fortinglossary["terms"]:ift["term_id"]notinused_term_ids:continuespec=t["targets"].get(lang)ifnotspec:continueforbidden="、".join(spec.get("forbidden",[]))lines.append(f'-{t["source"]}=>{spec["text"]}'f'（大小写处理：{spec["case"]}；禁用：{forbidden}）')return"\n".join(lines)defbuild_prompt(source_text,glossary,lang,used_term_ids):terms_block=build_terms_block(glossary,lang,used_term_ids)return(f"{INSTRUCTION}\n"f"{GLOSSARY_SEP}\n"f"术语表（{lang}）\n{terms_block}\n"f"{GLOSSARY_SEP}\n"f"待翻译正文：\n{source_text}\n"f"{GLOSSARY_SEP}\n"f"输出格式：只输出译文正文，不要输出术语表。")「上下文」第一次出现，人话解释：上下文就是「这一次对话里模型能看到的所有文字」；它有长度上限，所以能少塞就少塞。
4.2 方式二：生成后回扫校验
注入能挡住大部分，但不能假设一定挡得住——模型仍可能在长文案里换了说法。所以必须有第二道：生成完成后按术语表回扫输出，逐条检查「指定译法在不在、禁用写法在不在」。
4.3 方式三：自动替换的边界——一定要说清
发现跑偏之后，有两种处理：自动替换（把错写法换成指定译法）和标记待人工复核。这里有一条必须记住的纪律：自动替换只对「不会破坏语法和语序的词」安全。
德语、法语有词形变化（同一个词在句子里会变格、变数），机械替换很可能让句子更差；日语、韩语有助词和语序问题，更不适合。能自动替换的，通常是名词性、形态不变化、逐字固定的词（比如品牌名、型号）；只要有词形变化，就一律走「标记待人工复核」。
⚠️代码待验证
glossary_policy:inject_before_generate:true# 方式一：生成前注入术语表rescan_after_generate:true# 方式二：生成后按表回扫auto_replace:enabled:trueonly_if:# 只有同时满足才允许自动替换-term_is_invariant:true# 该术语目标语形态不变化-no_grammar_dependency:true# 与前后文的性、数、格无关otherwise:flag_for_human_review# 否则一律标记待人工sampling:per_batch:30# 每批生成后，随机抽 30 条做人工核对must_cover:# 这几个语种每批必须被抽到-de-ja「形态不变化」解释一下：有些语言里，一个名词放进句子会随「性、数、格」改变拼写（比如德语、俄语），这种词不能机械替换；有些词（品牌名、型号）在任何句子里写法都一样，这种才安全。
5. 批量生成的一致性怎么验：一条判据 + 一张抽检节奏
5.1 核心判据：同一术语在多语言输出里，是否都落回指定译法
别的都在其次，先看这一条：把同一批文案的所有语种输出摆在一起，逐个术语检查——这个术语是否在每个语种里都用了你在术语表里指定的那个译法？
这条判据的好处是可以交给机器：指定译法逐字写死，脚本就能一条条比对。「读起来顺不顺」是主观的，「落没落回表里」是客观的——先用客观的筛，主观的留给人工。
5.2 一个能跑的术语回归检查（示例）
⚠️代码待验证
defscan_terms(outputs,glossary,lang):"""outputs: {sku: 文本}; glossary: 术语表; lang: 语种代码"""findings=[]forsku,textinoutputs.items():fortinglossary["terms"]:spec=t["targets"].get(lang)ifnotspec:continuemust_use=spec["text"]hit_used=must_useintext bad_hits=[wforwinspec.get("forbidden",[])ifwintext]ifbad_hits:findings.append({"sku":sku,"term_id":t["term_id"],"issue":"出现禁用写法","detail":bad_hits})elifnothit_used:findings.append({"sku":sku,"term_id":t["term_id"],"issue":"未使用指定译法","detail":must_use})returnfindings这里故意只用「是否包含某个字符串」这种最朴素的判断，因为复杂匹配反而容易漏。只有当术语带变体（同一词根的多种词形）时，才放宽匹配口径。
5.3 抽检节奏：批量生成多少条，抽检一次
| 生成规模 | 抽检方式 | 抽什么 | 触发停手的条件 |
|---|---|---|---|
| 首批（新术语表第一次用） | 全检 | 全部条文，逐术语核对 | 只要有一条术语跑偏，先修术语表再继续 |
| 稳定期每批不超过 50 条 | 随机抽 10–15 条 | 覆盖每个语种至少 1 条 | 抽检里出现 2 条以上同类跑偏，升为全检 |
| 稳定期每批超过 50 条 | 随机抽 20–30 条 | 优先抽术语密集的条文 | 脚本报出的问题明显变多，升为全检 |
| 术语表改动之后 | 全检该批 | 重点看被改动的那几条术语 | 改动没生效就不要放量 |
「全检」和「抽检」解释一句：全检是这一批每条都看一遍；抽检是按比例随机挑一部分看，用来看整体有没有系统性跑偏。
这份资料是什么：「AI 大模型知识库」里有一份 Agent Skills 从入门到落地的专题，讲的是怎么把一件事拆成「有明确职责、有明确产出」的步骤——和本章「先定判据、再定抽检节奏」是同一种拆法。放在资料包里，扫码即可获取：
6. 跨语言的坑：不是每个术语都能一一对应
6.1 四类「一一对应」会失效的地方
词义不对应。中文一个词在目标语里可能对应两个词，你指定了其中一个，模型在另一处语境会发现不合适，于是偷偷换成另一个——这就是必须写「禁用替代写法」的原因。
语序和语法性别。你的指定译法在名词短语里是那个形式，一进句子要变格、变数，逐字写死反而会让句子出错。这就是第 4.3 节「词形变化的词不许自动替换」的由来。
度量单位与尺码。同一个数字配不同单位，跨语种要换算或保留原单位，而「单位本身」也是一种术语，应进术语表（比如「毫升」在各语种的写法）。
姓名与地址顺序。文案里若带联系人或地址，东亚与欧美语种的书写顺序不同，这类要单列规则，别指望模型自动处理对。
6.2 什么情况必须人工复核（四条判据）
| 判据 | 具体表现 | 处理 |
|---|---|---|
| 术语有词形变化 | 目标语里该词随句法变格、变数 | 禁止自动替换，逐条人工看 |
| 一个术语触发多条禁用写法 | 同一句里既有指定译法又有禁用写法 | 人工确认到底该用哪个 |
| 术语表刚改过 | 该术语指定译法最近有变动 | 改了的那批全检 |
| 文案涉及合规表述 | 功效、安全、认证类自造词组 | 一律人工，并交合规确认，模型只出草稿 |
最后一行是硬边界：涉及功效、安全、认证的表述，模型只能出草稿，最终写法必须由人确认。这不是模型能力问题，是责任问题。
6.3 借鉴点：行业里早就有一套「术语随文档走」的规范
翻译行业解决「术语怎么跟着文档流转」这件事，有现成的国际规范可借：XLIFF。XLIFF 第一次出现，人话解释：它是一个在不同翻译工具之间「搬运待翻译内容」的 XML 标准格式，能把原文和译文装进同一种文件里交换。
截至 2026-10-14，OASIS 文档库里：XLIFF 2.0 是 2014-08-05 发布的 OASIS Standard；XLIFF 2.1 是 2018-02-13 发布的 OASIS Standard；XLIFF 2.2 为委员会规范（2025-03-13）。其中Glossary 模块专门解决术语怎么随文档走。
规范第 5.2 节 Glossary Module 的引言原文是：「Simple glossaries, consisting of a list of terms with a definition or translation, can be optionally embedded in an XLIFF document using the namespace mechanism to include elements from the Glossary module.」（简单术语表，由一组「术语 + 释义或译法」构成，可以用命名空间机制把 Glossary 模块的元素嵌进 XLIFF 文档里。）
它的命名空间是urn:oasis:names:tc:xliff:glossary:2.0，模块元素包括glossary（术语容器）、glossEntry（一条术语条目）、term（源语术语）、translation（目标语译法，规范写明可以给多条译法作为同义词）、definition（纯文本释义）。
⚠️代码待验证
glossary (术语容器) └─ glossEntry (一条术语条目) ├─ term : 源语术语 ├─ translation : 目标语译法（规范允许写多条作为同义词） └─ definition : 纯文本释义 对应的 XLIFF 片段（示意，未实际用于生产）： <gls:glossEntry> <gls:term>一键自清洗</gls:term> <gls:translation xml:lang="de">Ein-Knopf-Selbstreinigung</gls:translation> <gls:definition>按下单个按键即可完成自动清洗的功能</gls:definition> </gls:glossEntry>这套结构对做电商文案的人有两处直接可抄：一是术语要带释义（definition）——你写「一键自清洗」的时候顺手记一句它到底指什么，半年后接手的人和模型才不会曲解；二是允许一个术语对应多条译法作为同义词——这在电商里很常见（正式页面的说法和广告语的说法可以不同），但要注意：同义词一旦放开，「指定译法」这条判据就要跟着分场景，不能再用「唯一译法」去卡。
7. 从跨境运营转这条线，你手里的三张牌
7.1 你比纯技术背景的人多什么
| 你原来的能力 | 在「多语言批量生成」里的对应物 | 迁移成本 |
|---|---|---|
| 维护多语种术语表、定译法 | 术语表的字段设计 | 低 |
| 译审抽查的直觉（盯表不盯文） | 抽检节奏与一致性判据 | 低 |
| 平台合规表述的经验 | 判定「哪些文案必须人工加合规确认」 | 低 |
| 多语站运营的数据观察习惯 | 把「好不好」变成可核对的清单 | 中 |
| 与译员协作的沟通能力 | 把要求写成模型能执行的规则 | 中 |
前三行是纯技术背景的人很难短期补上的：他们很会调模型，但不一定知道「哪些词是绝对不能改的」——这恰好是你的主场。
7.2 要补的三样，按这个顺序补
一是把「要求」改写成「规则」的能力。你要能把「这个术语必须统一」变成「这个术语在德语里必须逐字写成 X，禁止写成 Y」。补法：拿手上任意一张术语表，给每条补上「禁用替代写法」和「大小写处理」两列。
二是读懂一段脚本的能力。你不必会写，但要能看懂「它在检查什么、报出来的问题是什么意思」。补法：把第 5.2 节那段脚本逐行读一遍，说清每行在干嘛。
三是把输出变得可核对的习惯。判据要能被机器执行，不能只留在脑子里。补法：为一份多语言文案写出一条「能自动判断对错」的规则。
顺序不能反：没有第一样，术语表就还是软提示；没有第二样，脚本报错你只能干看着；没有第三样，前面所有工作都无从验证。
7.3 第一个可交付物长什么样
别一上来就做「八语种全自动」。第一个可交付物建议是「一个语种 + 一张术语表 + 一次全检」：选德语或日语（术语一致性要求高、词形变化有代表性），挑二十条真实文案，把术语表写全六个字段，生成后全检，记下「哪几条跑偏、为什么跑偏」。
先让一个语种稳下来，再谈铺开。术语表的质量是靠一轮轮真实文案磨出来的，不是一次性设计出来的。
这份资料是什么：「大模型学习路线图」把从零基础到能自己动手做 Agent 的路径按阶段拆开了，可以对照本章的三样补课顺序挑起点。放在资料包里，扫码即可获取：
附表 A：本文引用事实与出处对照表
| 序号 | 事实 | 出处（文档名 + 发布方 + 链接） | 本文位置 |
|---|---|---|---|
| 1 | OpenAI 官方提示工程指南共六条策略，第一条为「编写清晰的指令」（Write clear instructions）；其中原文含「模型不会读心术……如果你不喜欢输出格式，就把你想要的格式演示给它看。模型需要猜的东西越少，你越可能得到想要的结果。」；该策略下做法包括补充细节、提供示例、用分隔符分隔指令与上下文 | 《Prompt engineering》，OpenAI，https://platform.openai.com/docs/guides/prompt-engineering | 第 2.2 节 |
| 2 | 第二条策略「提供参考文本」（Provide reference text），做法为指示模型用给定参考文本作答；最后一条策略「系统性地测试改动」（Test changes systematically），建议把输出与黄金标准答案比对来评测 | 同上（内容经 OpenAI 官方帮助中心同主题文章《Best practices for prompt engineering with the OpenAI API》逐条核对，https://help.openai.com/en/articles/6654000 ） | 第 2.2 节 |
| 3 | 成文时本机直接抓取 platform.openai.com 该指南页时被 Cloudflare 拦截，故第 2.2 节内容以 OpenAI 官方帮助中心文章为准；该页不代表平台承诺，读者请以官方当前页面为准 | 本文成文时的抓取情况说明，非文档结论，待验证 | 第 2.2 节 |
| 4 | XLIFF 版本谱系：XLIFF 2.0 为 OASIS Standard（2014-08-05）；XLIFF 2.1 为 OASIS Standard（2018-02-13）；XLIFF 2.2 为委员会规范（2025-03-13）；ISO 21720:2024 为 XLIFF 2.1 的 ISO 版本 | 《OASIS XML Localisation Interchange File Format (XLIFF) TC》页面，OASIS，https://groups.oasis-open.org/communities/tc-community-home2?CommunityKey=3d0f1f56-8477-4b53-9b14-018dc7d3eecf | 第 6.3 节 |
| 5 | Glossary 模块引言原文：「Simple glossaries, consisting of a list of terms with a definition or translation, can be optionally embedded in an XLIFF document using the namespace mechanism to include elements from the Glossary module.」（第 5.2.1 节） | 《XLIFF Version 2.1》，OASIS Standard，第 5.2 节，https://docs.oasis-open.org/xliff/xliff-core/v2.1/os/xliff-core-v2.1-os.html | 第 6.3 节 |
| 6 | Glossary 模块命名空间为urn:oasis:names:tc:xliff:glossary:2.0，模块片段识别前缀为gls（第 5.2.2、5.2.3 节） | 同上，XLIFF 2.1 规范第 5.2 节 | 第 6.3 节 |
| 7 | Glossary 模块元素：glossary（容器）、glossEntry（条目）、term（源语术语）、translation（目标语译法，规范写明可提供多条译法作为同义词）、definition（纯文本释义）；模块属性含id、ref、source（第 5.2.4、5.2.5 节） | 同上，XLIFF 2.1 规范第 5.2 节 | 第 6.3 节 |
| 8 | 术语表六字段设计（术语 ID / 源语术语 / 目标语 / 指定译法 / 大小写与格式 / 禁用替代写法）、applies_to适用范围字段 | 本文归纳的方法论，非平台官方结论 | 第 3.1、3.3 节 |
| 9 | 抽检节奏表（首批全检、稳定期按批量大小抽检、术语表改动后全检）与「必须人工复核的四条判据」 | 本文归纳的工程判据，未在真实电商团队实测 | 第 5.3、6.2 节 |
| 10 | 德语书写规则中名词首字母大写为常规做法 | 通用书写规则，本文未引具体正字法规范原文，如需引用请自行核对正字法资料 | 第 3.3 节 |
| 11 | 本文的 JSON 术语表示例、提示注入函数、术语策略 YAML、术语回归检查函数、XLIFF 片段示意 | 均为示意性示例，未在实际业务或真实服务上运行，待验证 | 第 3.2、4.1、4.3、5.2、6.3 节 |
| 12 | 选题去重：本号已发「供应链转大模型：企业语料清洗」（讲入库前清洗），本篇讲生成时术语约束，角度与判据不同 | 本号已发标题清单（work 目录），内部核对记录 | 全文 |
附表 B：术语速查表
| 术语 | 一句话解释 | 在本文哪里用到 |
|---|---|---|
| SKU | 最小库存单位，指一个能单独上下架的货品 | 第 1.1 节 |
| 术语表 | 一张「指定译法清单」，规定某个词在每种语言里必须怎么写 | 第 1.2、3 节 |
| 软提示 | 用日常语言描述希望达到的效果，把判断标准留给模型自己理解 | 第 2.1 节 |
| 硬约束 | 把要求变成具体清单或可自动检查的规则，写死、没有解释空间 | 第 2.1、4 节 |
| 语言代码 | 两位小写字母的语言缩写，如 de / fr / ja | 第 3.1 节 |
| JSON | 用大括号和方括号组织「键—值」数据的文本格式 | 第 3.2 节 |
| 上下文 | 这一次对话里模型能看到的所有文字，有长度上限 | 第 4.1 节 |
| 词形变化 | 一个词随句子的性、数、格改变拼写，因此不能机械替换 | 第 4.3、6.1 节 |
| 全检 / 抽检 | 全检是每条都看，抽检是按比例随机挑一部分看 | 第 5.3 节 |
| 术语回归检查 | 生成后按术语表逐条回扫输出，看有没有落回指定译法 | 第 5.2 节 |
| XLIFF | 在不同翻译工具之间搬运待翻译内容的 XML 标准格式 | 第 6.3 节 |
| Glossary 模块 | XLIFF 里专门承载术语（术语、译法、释义）的模块 | 第 6.3 节 |
写在最后：这篇用到的资料
写这篇文章时，把相关的官方文档和源码又翻了一遍，顺手也整理了几份配套的东西：
- 大模型学习路线图：从零基础到能自己动手做 Agent，按阶段说明每一步该学什么、哪些可以先跳过
- 《LangChain + LangGraph + MCP 智能体开发实战》视频课：7 个模块，从私有化部署、Embedding+RAG 到 MCP+Agent 全流程
- AI 大模型知识库（在线可查）：Agent Skills 从入门到落地、Claude Skills 完全指南等专题，按目录浏览即可
- 640 套 AI 大模型行业报告 + 经典 PDF 书籍：看行业落地案例和别人怎么做的时候用得上
- 大模型零基础到精通教学视频：跟着敲一遍，比只读文档快得多
资料是我自己整理的，放在下面这个码上，扫码即可获取：
添加时备注「AI」，优先通过。
资料按「先路线、再动手、最后查漏」的顺序整理好了，建议先看学习路线那一份，照着它挑一条适合自己当前基础的路径再往下看。
