我做过不少跨语言的内容项目，几乎每一次都会在同一个地方卡壳：同一个术语，翻成不同语言之后就开始“各自为政”。这事说起来不复杂，但真正处理起来，比我最初预想的要麻烦得多。
1.1 多语言术语统一的核心痛点：同一概念在不同语言中译名漂移、同义词混用与上下文误判
我最头疼的一件事，就是同一个英文词，在法语里被译成A，在日语里被译成B，到了中文又变成了C。单看每种语言都没问题，放在一起就像三个人在讲三件不同的事。译名漂移这毛病特别隐蔽，它不是明显的错译，而是一种“看起来都对”的偏差。你今天让模型翻“deployment”，它给你“部署”；明天换个上下文，它可能就变成“展开”或者“投放”。没有约束的话，模型很乐意每次都给你一点新鲜感。
同义词混用也是常见坑。一个产品功能，官方文档叫“工作区”，UI文案叫“工作台”，客服知识库里又写成了“操作区”。用户读着读着就开始怀疑这三个是不是不同的东西。我自己审稿的时候就经常被这种细节绊住，得反复确认它到底指哪个概念。
上下文误判更微妙。有些词在技术语境和法律语境里的含义差得很远，模型如果没有明确的领域信号，就会按它认为“更常见”的那个意思去翻。结果就是术语层面看着没错，放进句子里却完全不是那个意思。这种错误最难被发现，因为它往往语法通顺、读起来也不别扭。
1.2 提示词在术语统一中的定位：从“翻译指令”升级为“术语约束与一致性校验协议”
我以前用提示词，基本就是一句“请把下面内容翻译成日语，保持专业语气”。这种写法能用，但它本质上是个翻译指令，不是术语管理工具。模型收到这种指令，会优先考虑“翻得顺”，而不是“翻得一致”。这两件事经常打架。
后来我慢慢意识到，提示词真正应该承担的角色，是一份约束协议。它得告诉模型哪些词必须怎么翻、哪些词不许用、遇到歧义时该怎么办、输出里要不要附术语清单。这已经不是简单的“翻译一下”了，更像是在跟模型签一份小合同。合同写得越清楚，交付物就越可控。
这个定位转变带来的直接好处是：术语一致性从“事后检查”变成了“生成时约束”。我不用等翻完了再去一条条比对，而是在提示词里就把规则立好。模型按规则办事，审校的工作量能降下来一大截。当然，前提是规则本身得写得足够明确，含糊的约束等于没有约束。
1.3 典型应用场景梳理：产品文档、UI文案、法律合规、技术手册、客服知识库与营销内容
产品文档是我最常碰的场景。一份用户手册可能要同时出五六种语言，里面的功能名、菜单名、状态词必须完全对齐。只要有一个词漂了，用户按文档操作就会找不到对应按钮。这种错误在支持工单里出现的频率高得吓人。
UI文案是另一个极端。字符串短、空间紧、还得考虑不同语言的词长差异。一个“Settings”在德语里能撑出老长一串，按钮直接爆版。这时候提示词里就得提前声明长度约束和首选译法，不然模型给你一个“正确但装不下”的答案，等于白干。
法律合规和技术手册对术语的要求更硬。法律文本里一个词的微妙差别可能改变责任边界，技术手册里的部件名称错一个字就可能造成误操作。客服知识库的问题在于量大且更新频繁，术语不统一会让客服在检索时漏掉关键条目。营销内容相对灵活，但品牌词和产品名同样不能乱来，那是门面。
1.4 成功标准定义：术语命中率、跨语言对齐度、上下文适配性、可审核性与可复用性
我怎么判断一套提示词到底管不管用？第一个指标是术语命中率。我给定术语表之后，模型输出里有多少术语是按我指定的译法来的。这个数字能直接反映约束有没有生效。命中率低，说明提示词里的术语表没被模型当回事，或者格式让它没法正确读取。
跨语言对齐度是第二个关键指标。同一份源文档翻成多种语言之后，各语言版本之间的术语是不是指向同一个概念。这个比单语言命中率更难保证，因为它涉及多路输出之间的一致性。我通常会抽一组核心术语，逐语言对照检查。
上下文适配性和可审核性是我后来才重视起来的。术语对了但语气不对、术语对了但句式别扭，这些都属于适配性问题。可审核性指的是输出里有没有留下足够的痕迹，让我能快速定位哪些术语被用了、哪些没命中、哪些地方模型自己做了判断。可复用性则决定了这套提示词能不能沉淀下来，下次换个项目还能不能接着用。这五点凑在一起，才算是一套真正能落地的成功标准。
我写坏过很多版提示词。早期那些失败的经历让我慢慢摸出了一些门道，说“原则”有点正式，其实就是几条我觉得不能丢的底线。这一章我按自己踩坑的顺序讲，未必全面，但都是实打实用过、知道哪里会翻车的东西。
2.1 角色与任务边界原则：明确模型角色、目标语言对、输出用途与禁止行为
我刚开始写提示词的时候，角色设定就一句话：“你是一个专业翻译。”后来发现这句话太虚了。模型不知道自己该按哪个行业的标准来，也不知道译文是给谁看的。现在我一定会写清楚：你是法律本地化译者/你是UI文案本地化专家/你是技术文档术语审校。角色越具体，模型在拿不准的时候越会往正确的方向靠。
任务边界这件事我吃过亏。有次我没说禁止行为，模型在翻译过程中自作主张帮我把几个长句“优化”了结构，术语是对的，但句式全变了。客户审校的时候直接问我：“这跟原文怎么对不上？”从那以后我学乖了，提示词里固定加一段禁止行为清单：禁止合并或拆分原文段落、禁止省略任何源术语、禁止自行替换术语表中未收录的同义词、禁止改变数字和单位格式。这些话说在前面，能省掉后面很多返工。
目标语言对也要写死。不能只说“翻译成欧洲语言”，得写“简体中文→法语（法国）”，或者“英语（美国）→日语”。地区变体这事不写清楚，模型就按它默认的来，法国法语和加拿大法语混着用，用户一眼就能看出来不对劲。输出用途也得交代，是给内部审校用的粗翻，还是直接上线的终稿，模型对准确度和流畅度的权衡完全不一样。
2.2 术语优先级原则：强制术语、推荐术语、禁用术语与行业惯用表达的层级管理
术语表最怕平铺直叙。所有词条长得一模一样，模型分不出哪个是“必须这么翻”、哪个是“差不多就行”。我给术语分层级已经成了肌肉记忆。强制术语标【MUST】，意思是出现就必须用这个译法，没有商量余地。推荐术语标【PREFER】，模型可以用，也可以在特定语境下换更自然的说法。禁用词标【BAN】，看到就绕开，连近义词都不许碰。
行业惯用表达是单独一档。这类词没有硬性译法，但业内有个约定俗成的说法。比如“onboarding”在SaaS行业中文里常说“上手引导”而不是“入职流程”，你得告诉模型这个偏好，不然它按通用词典翻出来的东西业内人一看就觉得外行。我通常会在术语表备注栏里写一句“行业惯用，优先于直译”，让模型知道这条的分量。
层级管理还有一个容易忽略的点：优先级冲突时听谁的。同一个词在不同产品线可能有不同译法，提示词里得声明当前项目适用哪一套。我现在的做法是术语表按项目走，每个项目一个独立表，项目之间不共享强制术语，避免A项目的硬性规定污染B项目。
2.3 上下文约束原则：领域、受众、语气、句式、地区变体与合规要求的显式声明
领域信号我吃过太多亏了。“protocol”在IT语境是“协议”，在医疗语境是“方案”，在外交语境是“议定书”。提示词里不写领域，模型就按统计上最高频的那个意思来，大概率不是你需要的那个。我现在会在提示词开头单起一段写“领域：企业级网络安全产品文档，涉及零信任架构和身份认证”，让模型进入正确的语义空间再开始干活。
受众和语气是连在一起的。给开发者看的API文档和给财务人员看的合规说明，语气完全是两回事。我会写“受众：具备基础IT知识的企业IT管理员，语气：专业但不堆砌术语，解释性内容可适当展开”。句式上我有时会加一条“优先使用短句，单句不超过40个汉字”，这是被德语和日语的长句逼出来的经验——不约束的话，模型翻出来的句子能绕晕审校。
地区变体和合规要求属于必须显式声明的那一类。西班牙语有欧洲和拉美之分，葡萄牙语有巴西和欧洲之分，不写清楚模型就可能给你混搭。合规方面，涉及个人数据的文本我会加一句“避免使用可能被解读为数据跨境传输的表述”，有些词在GDPR语境下敏感，模型不知道就会踩雷。这类约束宁可写细一点，也别指望模型自己悟。
2.4 输出可控原则：统一输出结构、术语标注方式、歧义说明与不确定项处理机制
输出格式不固定，后面就没法自动化校验。我现在的提示词里输出结构是硬性规定的：译文正文放第一部分，术语使用清单放第二部分，未命中术语说明放第三部分。三块用固定分隔符隔开，方便我用脚本直接拆。术语使用清单我要求列出“源术语→目标术语→是否命中术语表”，三个字段对齐，一眼就能扫出问题。
术语标注方式也得统一。我要求模型在译文里用方括号标注强制术语，比如“配置[configuration]”，方便审校快速定位。这个做法一开始觉得有点碍眼，后来发现真香——审校不用逐字比对，扫一眼方括号就知道强制术语有没有被替换掉。歧义说明我单独设了一个字段，模型如果遇到术语表里没有但拿不准的词，必须在这里写一句“术语X在上下文中可能指A或B，当前按A处理”，不许闷头翻完拉倒。
不确定项的处理机制是最后一道保险。我写了一条规则：如果源文本中某个术语在术语表里找不到匹配，模型必须保留源语言原文并用【UNMATCHED】标记，同时在输出末尾汇总所有未匹配项。这条规则救过我很多次，因为有些新术语术语表还没收录，模型瞎翻一个反而更麻烦。标记出来我自己补进术语表，下次就命中了。
2.5 可维护原则：术语表版本、提示词模块化、变量占位与跨项目复用设计
提示词写死是最省事也最要命的做法。我早期把所有内容塞在一个大段文字里，改一个术语要全文搜索替换，改完之后还经常忘了哪里漏了。现在我把提示词拆成模块：角色模块、术语表模块、约束模块、输出格式模块、自检模块。每个模块独立成段，用标记分开，改哪个模块就动哪一段，互不影响。
变量占位是复用性的关键。语言对、领域、受众、术语表版本号、输出格式类型，这些都用{{变量名}}占位，调用的时候再填充。我有一套基础模板，换个项目只需要替换变量值和术语表文件，骨架不动。这么做的好处是模板经过多个项目验证，稳定性有保证，不会每次从零开始试错。
术语表版本号我要求写在提示词头部，格式是“术语表版本：v2.3，更新日期：2025-03-15”。这样做有两个目的：一是模型输出里如果出现术语表没收录的词，我能快速判断是不是版本没更新；二是跨项目复用的时候，版本号能提醒我这个术语表是不是适用于当前项目。我还会在提示词末尾加一行“本提示词版本：v1.4”，配合版本记录文档，谁在什么时候改了什么一目了然。可维护这件事，说白了就是让下一次修改的人（很可能就是三个月后的自己）少骂几句脏话。 你是一名{{ROLE}}，负责将{{SOURCE_LANG}}内容翻译为{{TARGET_LANG}}。 领域：{{DOMAIN}} 受众：{{AUDIENCE}} 术语表版本：{{GLOSSARY_VERSION}} 输出格式：{{OUTPUT_FORMAT}}
模板给了我骨架，真正让我头疼的是填进去的血肉。同样一份术语表，写法不同，模型给出的结果天差地别。我在这块反复栽跟头，慢慢摸出几条自己觉得靠谱的路子。
4.1 跨语言术语一致性提示词写法总则：先对齐概念再约束表达，先定义规则再给出示例
我最初写提示词的习惯是上来就列术语对照表，源术语、目标术语排成一排，想着模型照着替换就行。用了两个月发现这条路走不通。模型经常抓住目标词的表层意思乱用，因为它根本不知道这个词背后指的是什么概念。比如“deployment”在软件语境里指的是把系统推上生产环境，模型在别的语境里把它翻成“部署部队”，术语表里明明写着对照，它照样翻车。后来我把顺序调过来：先用一两句话说清楚这个概念是什么、在什么场景下出现，再给出目标语言的首选表达。概念对齐了，词就只是个标签。
规则和示例的顺序我也改过。早期我把示例句全堆在最后，模型读的时候早把规则忘光了。现在我把规则写在前头，语言对、领域、优先级、禁止行为逐条列清楚，示例句紧跟其后，作为规则的注释存在。这个顺序看起来是小事，实际用下来模型对规则的遵守率明显上去了。
我总结下来就两句话：先讲概念、再讲词；先立规矩、再举例子。这两条写进模板开头的注释块里，谁用谁看见。
4.2 多语言术语对齐写法：源语言概念锚点、目标语言首选词、允许变体与地区差异的处理
术语对齐我现在的做法是给每个术语设一个“锚点”，通常是源语言里一段两句话的定义，把这个概念框死。定义不写全，只抓区分度最高的特征。比如“onboarding”我写的是“新用户第一次接触产品到完成核心操作之间的引导流程”，这句话一出来，模型就不会把它跟“入职培训”搞混。
目标语言首选词我会明确标成“首选”，同时留一个“允许变体”字段。有些词在目标语言里确实没有唯一正确译法，强行统一反而别扭。西语的“dashboard”在西班牙常用“panel de control”，拉美一些市场习惯用“tablero”。我在提示词里把首选和变体都写出来，加一句“同一文档内只使用一种”，让模型在一个项目里保持一致就行，不追求跨地区绝对统一。地区差异这块我吃过亏，早期提示词里只写“西班牙语”，模型一会儿用西班牙用法一会儿用拉美用法，同一份文档里自相矛盾。现在语言对必须精确到地区变体，{{TARGET_LANG}}填的是“西班牙语（墨西哥）”这种粒度。
概念锚点、首选词、允许变体三件事在提示词里的排布我固定了顺序：锚点在前，首选词居中，变体列在后面并标注适用地区。模型读的时候有层次，不会把变体当成首选来用。
4.3 消歧与约束写法：利用定义句、示例句、反例、禁用词与上下文片段降低术语漂移
消歧这件事光靠定义句不够。我的经验是要把正例、反例、禁用词三样配齐。正例就是术语在真实句子里怎么用，反例是“这个译法看起来对但在这里是错的”。比如“cloud”在技术文档里指“云计算服务”，我给的例句是“将数据同步到云端”，反例写的是“不要译为‘云朵’，不要用于天气或比喻语境”。反例这句话模型真的会看，加了之后天气类误译基本归零。
禁用词字段是我后来补的，因为发现模型有时候会自作聪明找同义词替换强制术语。术语表里写“configuration”对应法语的“configuration”，模型给你换成“paramétrage”，意思差不多，但在产品文档里是对不上的。提示词里专门加一段“以下译法禁止使用”，把常见的同义词替换列进去，模型换词的冲动就压住了。
上下文片段这个手段我用得少但有效。长文档里有些术语只在特定章节出现，我会在提示词里附一段“该术语仅用于第三章及以后的API参考部分”这种位置说明。模型对位置约束的敏感度不低，写清楚之后跨章节乱用的情况少了很多。这些手段堆在一起，术语漂移的概率能压到很低。
4.4 自检与回译写法：要求模型输出术语使用清单、回译检查项、未命中术语说明与替换建议
我在模板里强制模型输出一份术语使用清单，这件事改变了我对提示词的理解。清单格式固定：术语、出现次数、所在段落编号、是否命中术语表、命中的是哪条记录。模型输出译文之后必须附带这份清单，不附就算失败。有了这份东西，审校的人扫一眼就知道术语用没用对，不用逐句去对。
回译检查是最近半年才加的。做法是让模型在完成翻译后，把目标语言的关键术语单独回译成源语言，跟原术语做对比。不一致的地方让它标出来，附一句“可能存在的偏差说明”。这个动作能暴露很多“看起来通顺但术语偏了”的问题。我印象很深的一次，模型把“compliance”翻成西语的“cumplimiento”，回译回去却变成了“完成、履行”，模型自己标了偏差，提示在该语境下应该用“conformidad”。没有回译这一步，这个错误就漏过去了。
未命中术语的处理我也写进了要求里。模型遇到术语表里没有但觉得重要的词，不能自己硬翻，要单独列出来，附上“建议译法”和“建议加入术语表”的标记。这样每次跑完，术语表就有机会被补充，提示词也跟着迭代。替换建议字段是给审校留的口子，模型对自己不确定的地方给出两到三个候选译法，审校来定。这套自检和回译的组合拳打下来，术语相关的返工大约少了六七成。
4.5 多语言批量处理写法：分语言调用、术语命中校验、跨语言结果对照与一致性复核提示
一个源语言对多个目标语言的时候，我试过一次性把所有语言塞进一个提示词。结果很糟，模型在不同语言之间串味，法语的术语跑到西语输出里去了。后来改成按语言对分次调用，一次只处理一个目标语言，每次调用都带上该语言专属的术语子表。这个改动让输出稳定了很多，代价是调用次数增加，但对质量来说值。
分次调用之后我加了一步跨语言结果对照。所有语言跑完，把术语命中清单合并成一张总表，看同一个源术语在各个目标语言里是不是都命中了对应记录。有一次对照发现“workflow”在德语里用了术语表里的“Arbeitsablauf”，在法语里模型却用了表外的“flux de travail”，单独看每种语言的输出都挺顺，合起来才发现法语那条漏了。这种问题不做跨语言对照根本发现不了。
批量处理的提示词里我会固定加一段一致性复核语，让模型在输出前自己回答三个问题：本语言内同一术语是否全文一致、术语表强制项是否全部使用、未命中项是否已单独列出。这三个问题直接写进自检模块，模型回答“是”才允许输出。多语言项目里这条复核语帮我把不少批次性问题挡在了交付前。写提示词这件事，写到多语言这一步，考验的已经不只是措辞，是对整个术语治理流程的理解。
写到这一章，我其实有点不知道该怎么开头。前面四章讲的都是“怎么写”，这一章讲的是“怎么知道写得好不好，以及写好了之后怎么让它别烂掉”。这个部分听起来最不像写提示词，实际做下来，它才是让前面所有工作没白费的那根绳子。我自己在这块摔过好几次，每一次都跟一件事有关：我以为提示词跑通了就结束了，结果过两个月回头看，术语又乱了，只是乱的地方换了。
5.1 评估体系设计：术语命中率、跨语言一致率、人工审校通过率、歧义暴露率与回归测试集
我最开始评估提示词的方式特别朴素，就是自己读几段译文，觉得顺就过了。这种评估放到多语言场景里基本等于没有，因为我看不懂的语言我只能看术语表有没有对上，而对上的标准是我随便挑两段看看。后来被坑了一次大的，德语项目交付之后客户反馈说“同一页里同一个词用了两种译法”，我回去翻了输出，确实是这样，但那两段恰好都不在我抽检的样本里。
吃过亏之后我硬着头皮搞了一套最小的评估指标体系。最核心的是术语命中率，做法很简单：把术语表里所有强制项拉出来，逐条到译文里数，出现了几次、是不是出现在该出现的位置。这个数值我一般要求到百分之九十五以上才允许往下走。跨语言一致率是第二个指标，把所有目标语言的命中结果摆成一张表，同一个源术语在每个语言里是不是都命中了对应记录，有没有哪个语言的命中数是零。这个指标特别容易暴露“某一种语言被模型系统性忽略”的问题。
人工审校通过率我交给审校同事来打分，让他们按“术语全部正确、术语部分错误、术语严重错误”三档来标，通不过的句子标出来原因。这个数据攒多了之后我发现，审校打回来的问题里大部分不是翻译质量本身，是术语表的定义写得不够清楚。歧义暴露率这个指标是我自己加的，专门统计模型在输出里标注“不确定”或者“建议替换”的比例，这个数高不一定是坏事，说明模型在老老实实暴露风险，比它闷头硬翻强得多。
回归测试集是这套评估里我觉得最值钱的东西。我攒了一份大概两百句的测试语料，每一句都绑定了特定术语和预期译法，每次改完提示词都拿这份语料跑一遍，看改动有没有把原来对的东西改坏。有一回我为了修一个法语的问题调了提示词顺序，跑完回归发现西语的三个术语全掉了，这种连锁反应光靠人眼看是看不出来的。回归集不用大，但覆盖面要够，每个语言对至少得有几十句，行业和场景得撒开。
5.2 错误分析与迭代机制：误译、漏译、过度统一、地区变体冲突与提示词修订记录
错误这件事我分了几类来看，因为不同类别的错背后原因完全不一样，改法也不一样。误译是最常见的，术语表里的词没用对，或者用了别的词替代。漏译是模型压根没处理那个术语，跳过去了。这两类错误大多跟术语表本身的定义质量有关，我回头去改术语表的锚点句和反例，比在提示词里加十句强调有用。
过度统一这类错误是我一开始没料到的。有段时间模型特别听话，同一个词在任何语境下都用同一个译法，比如“operation”在医疗文档里指的是手术，在产品手册里指的是操作，我术语表里只写了一条“operación”，模型就把手册里的“操作”也翻成“operación”，读起来很怪。这种错不是模型不听话，是我提示词里没给语境分层。后来我在术语表里加了“适用领域”字段，同一个源词在不同领域下可以挂不同的目标词，这个问题才收住。
地区变体冲突是另一个坑。西语项目里我把目标语言写成“西班牙语”，结果模型在同一批文档里一会儿用西班牙半岛的用法一会儿用拉美的，同一个词前后不统一。我现在的做法是提示词里语言变量的粒度必须到地区，比如“西班牙语（墨西哥）”，术语表里也给每个地区单独标注首选词。这个改动很小，效果很明显。
提示词修订记录这件事我做得比较土，就是一张表格，每次改动记下日期、改了什么、为什么改、回归测试结果、谁审的。一开始我觉得这是形式主义，后来有一次线上出了术语问题，我翻记录发现是三周前一次改动引入的，没有这张表我得从零开始排查。现在这张表是我们团队改提示词的前置条件，不填不让改。
5.3 团队协作流程：术语管理员、译者、审校、产品与本地化团队在提示词生命周期中的职责
提示词这件事一个人干久了会出问题，我深有体会。我自己维护的那套提示词用了半年，后来交给另一个同事接手，他完全看不懂我为什么在某一段里加了三条看起来重复的禁用词，因为那是我被一个具体的线上事故逼出来的，没写进任何记录里。人一换，知识就断了。
后来我们慢慢把角色分开了。术语管理员负责术语表的准入和定义质量，谁的术语想进表得经过这个人，定义句写不清楚要打回去重写。译者负责提供各个目标语言的首选词和允许变体，这个必须让懂目标语言的人来定，模型定不了，我也定不了。审校负责按我上面那套评估标准打分，并且把打回来的问题归类到误译、漏译、过度统一这几档里去。产品和本地化团队负责提需求和定优先级，哪些术语是强制的、哪些是推荐的，这个得从业务侧来定，不是语言问题。
提示词的生命周期我是这么切分的：需求提出、术语表更新、提示词修改、回归测试、小流量验证、全量上线、定期复审。每个阶段有明确的负责人，术语管理员管前两个，译者管目标语言侧的改动，审校管回归和小流量验证的结果确认，产品和本地化团队管上线决策和复审排期。这套流程听起来挺重，实际上跑顺了之后每周花不了多少时间，比出了事回头救火省得多。
我特别想说的是复审这个环节，我们一开始完全没有，导致有些半年前定的术语到现在还在用，行业里早就不这么叫了。现在每季度做一次术语表复审，把使用频率低的、有争议的、跟行业标准脱节的挑出来重新讨论。这个动作不做，术语表就会慢慢变成一个只进不出的垃圾场。
5.4 工具与系统衔接：术语库、翻译管理系统、CAT工具、质量检查规则与提示词模板库的联动
我早期维护术语的方式是在文档里手写表格，后来术语多了就换成在线表格，再后来发现表格和提示词之间永远对不上，改了一边忘了另一边。这个问题的根源是术语表和提示词是两套东西，各管各的。
现在的做法是术语库作为唯一的真相来源，提示词里的术语表部分是从术语库自动导出的，不是手抄的。术语库更新之后，跑一个导出脚本，把提示词模板里的术语变量重新填充一遍，然后跑回归测试。这一步省下来的时间不多，但省下来的错误很多，手抄时代我至少犯过三次“术语库改了提示词没改”的错。
翻译管理系统和CAT工具的衔接我做得比较浅，主要是把提示词输出的术语使用清单导回去，作为CAT里质量检查规则的参照。CAT工具自带的术语检查是按术语库逐条比对的，它不知道上下文，也不知道允许变体。我把清单里的“允许变体”和“未命中项”也导进去，质量检查的误报率降了很多。这个事我觉得还没做到位，理想状态是提示词模板库和CAT里的项目配置能双向同步，现在还是半手动。
提示词模板库是我们最近才开始正经建的。之前每个项目一个提示词文件，散在各自的文件夹里，想复用的时候找不到，找到了也不知道哪个版本是对的。现在按语言对、领域、场景三个维度建目录，每个模板带版本号和变更记录，新项目先来这里找，找不到再新建。模板库这个东西刚开始用会觉得约束太多，用顺了之后新项目启动的时间能砍掉一小半。
5.5 扩展大纲：从单次提示词到多语言术语治理体系，包括术语准入、版本管理、监控告警与持续优化
写到这里我想往回看一眼。这本书从第一章开始讲的是“怎么给多语言术语写一条好的提示词”，写到这一章，说的其实已经不是一条提示词的事了，是一套让提示词能持续有效的东西。这两件事之间的距离，我自己是用了差不多一年才走过来的。
术语准入这块我现在的做法是有明确的门槛：新术语进表必须有定义句、有示例句、有至少一个目标语言的首选词、有优先级标注。缺一项就打回去。这个门槛听着不高，实际执行下来发现大部分被拒的术语都是因为定义句写不清楚，写不清楚的术语进表之后模型用不对，后面全是麻烦。
版本管理我前面提过修订记录，这里想说的是术语表的版本要和提示词的版本绑在一起。术语表升到二点三版，提示词模板也得跟着升，两边版本对不上的时候禁止上线。监控告警这块我们做得还比较初级，主要是靠定期跑回归测试集和线上抽检，发现问题了人来看。理想状态是有一套自动的术语漂移监测，每次输出之后自动比对术语命中情况，异常了自动告警。这个方向我觉得值得做，但还没动手。
持续优化这件事我想换个角度说。前面讲的都是流程和工具，我想说的是心态。多语言术语治理不是一个能“做完”的项目，它是一个一直要维护的东西。行业术语在变，产品在变，模型在变，用户的语言习惯也在变，你今天定的首选词明天可能就不合适了。接受这件事之后，我看待那些定期复审、回归测试、修订记录的态度就完全不一样了，它们不是额外负担，是这个东西能活下来的基本条件。写提示词写到这个份上，考验的确实已经不只是写的能力了。
