从人工到 AI：文案 -> Key 替换工具的演进与实践

前言

Web 国际化一文通

我们团队需要常年面对文案设计与开发并行的情况，设计任务多介入太晚，同时文案管理的权限不在研发手中，这导致了研发需要在流程后期文案准备好后，再进行一次文案替换。

为了在文案问题上，实现极致化地效率提升，以及规范化的准入准出原则，考虑到我们内部中台能力的局限性，创造了一套文案使用系统矩阵。

其中的关键，是我们一款持续迭代的文案替换插件，用于扫描并把项目中的国际化源文案自动替换成 key。但该工具依然会因为一些问题，导致整体覆盖率不高。

在新的时代下，我们通过 llm 的语义理解能力，针对源文案更新后与代码文案不同的问题，创新性地尝试匹配出相似语义的文案，更进一步地提高了文案匹配率！

一、问题背景与挑战

1.1 流程困境

如上一篇文章Web 国际化一文通所述，虽然有不少团队能够做到在开发流程完成之前，content designer 就完成了 key - 源文案材料准备，或者直接由开发提供 key - 源文案，使整个开发流程不受阻，令人羡慕。但是在我们这种中小型项目组内，由于各种各样流程化、文案保护与人力的问题，还是很难实现的。

为此我们需要在开发中直接填写源文案，在文案准备好了再去把这些文案换成 key。 这是目前大部分的国际化团队的工作流程，区别仅在于文案是否前置准备好，多少浪费了一些研发时间来做这种毫无技术含量的事情。

1.2 开发习惯

不想去找 key: 首先一点，我们在开发过程中，并不想花时间去找 key，直接复制粘贴文案当然比去找它背后的 key 快多了！麻烦的事情放到最后一起做！

不想多写代码: 另一方面，在 key 没有准备好的情况下，正常来讲 i18n 有一个兜底能力，及给它多传一个默认值，它在找不到 key 的时候会去使用这个默认值，所以只要我们填这个默认值，在 key 的位置留白或者留点别的，就可以方便后面的替换了，如下：

t('留白', {}, '默认源文案')

但是！所谓不想偷懒的研发不是好研发！为什么要多写那么长的东西？我们直接写 t('默认文案') 的效果是一样的！除了难找一点没有任何缺点！

更何况，在这种写法这么简易的情况下，我们没有理由强制团队成员写完整的 key + 兜底！

1.3 问题与后果

由于语料的翻译也是后置的，QA(测试) 只会在英语环境、也就是源文案的语言环境下测试。这个环境下看起来毫无问题，就会导致后续可能会漏文案 case。

1. 漏替换：看漏了没用 key 的地方 / key 用其他方式存储 / key 是动态的，导致忘了把源文案转换成 key；
2. 漏需求：CD(Content Designer，内容设计师) 也不知道你逻辑中有什么文案不在设计稿里，等到上线根本来不及；
3. 代码沉疴：上线时没转换好的，以后再也找不到了。

1.4 问题总结

总的来说，在跨国协作开发场景中，我们面临以下核心挑战：

• 流程异步：文案调整与开发周期时间经常重叠
• 动态变更：20% 以上的文案，内容在联调或提测阶段发生语义调整
• 时间浪费：为了给文案替换 key ，根据内容量的大小，每个 RD(研发) 有可能会浪费数十分钟在文案排查上
• 技术债务：上线后可能存在遗留未替换文案，不断累积递增

二、现有中台能力与局限性

2.1 中台能力矩阵

我们公司内的中台做了很多工作，在译员端和文案管理上付出了非常多的努力，除了自身有智能翻译、语料库、记忆库等等，还提供划词翻译上传、内部文档接入、vscode & chrome & figma 插件划词上传、词语匹配等等能力。

同时，在脚本方面，中台同样提供了丰富的工具，该工具的主要能力如下：

1. 基本能力: 能够提供下载、扫描的能力
2. 额外支持: 提供了一些静态分析、替换、生成插件，支持 AST 扫描、中文替换、key 生成、commit diff 等等
3. 插件开发: 支持插件开发，为进一步扩展提供了可能。
4. 工具生态: 持续多角度迭代各种文案一键上传及翻译能力，如 vscode 插件、chrome 插件圈选、截图提取等，以及文档翻译、音视频翻译、截图翻译等能力

我们的项目基于中台基本的文案管理能力，目前使用了下载能力，来自动加载英文文案兜底，未来也会使用中台的 vscode 插件进行开发提效。

2.2 在业务流程中的局限

我们目前主要的问题在于 Content design 与开发的流程上，在译员端和文案管理上反而没什么问题，因此需要的是一整套从生产、使用、检查到上线的能力矩阵，替换插件是其中的一个重要部分。

中台支持文件 AST 插件工具，来定位国际化文案 / key 的位置。为了尽可能不出错、以及早期为了最大程度适配国内团队开发国外项目问题，考虑到不会有人用中文写代码，但中国人会用中文写文案，所以仅匹配替换中文部分。

而我们不仅仅是国内团队，我们在团队成员与设计规范上都是国际化的，都是使用英语的，这个功能对我们来说没法用！为了应对这个问题，AST 插件支持了业务方自定义扫描方式，交给业务自己处理。

同时由于当时中台在插件这块儿缺少给业务单独服务的人力，因此我们需要开发能够适用我们业务的插件，来处理英文文案。

三、提效系统架构

为了更丝滑地写代码，也为了项目稳定过关，我们做了很多事情。

3.1 整体系统流程

人工流程

graph TD
设计稿+评审 --> RD流程
设计稿+评审 --> CD流程
CD流程 --> 设计项目文案 --> 产出源文案并生成key
RD流程 --> 开发使用设计稿文案 --> RD将设计稿文案替换对应意思源文案的key
产出源文案并生成key --> RD将设计稿文案替换对应意思源文案的key
RD将设计稿文案替换对应意思源文案的key --> 交付上线
交付上线 --> 人工/oncall/pso检查
人工/oncall/pso检查 --> 设计稿+评审

引入工具后的初版系统

graph TD
设计稿+评审 --> RD流程
设计稿+评审 --> CD流程
CD流程 --> figma修改文案并生成key
figma辅助插件 --> CD流程
RD流程 --> 开发使用设计稿文案 --> 工具替换文案为key
vscode插件辅助 --> RD流程
figma修改文案并生成key --> 工具替换文案为key
工具替换文案为key --> review缺失内容
review缺失内容 --> figma修改文案并生成key
工具替换文案为key --> CI工具 --> 交付上线
交付上线 --> 人工/oncall/pso检查 --> 设计稿+评审
交付上线 --> 自动上报缺失 --> 设计稿+评审

3.2 创新点：英文文案的扫描替换工具

3.2.1 功能关键

我们首先有了第一版替换工具，它结合已有的文件 AST 加载与 git diff 的插件工具，再进一步处理扫描出的英文，与远端文案匹配替换，并能够输出没有匹配到的文案，同时发送 lark 通知给个人。

这一版工具在我们日常工作中，根据不同情况，能够解决我们 25% -50% 的文案匹配问题。

这个完成率早期还可以，现在不算很好，尤其在 CD 后期改了很多文案的情况下。

3.2.2 第一遗留问题

为什么替换率这么低？

一方面，文案的使用在代码中是十分复杂的，我们日常会遇到以下几种 key 的形式：

1. Call 型文案：直接由 t function 包裹的静态文案，如 t('xxx')
2. 翻译组件: 组件属性值，如 <trans i18nkey="xxx" ...
3. 变量存储: 静态变量、Object 对象等存储的 key，然后再用 t function 动态渲染，如 const a = { b: 'xxx' }; t(a.b);
4. 动态文案: Key 本身由后端下发，或者 key 是动态的，如 t(xxx${data.something})

在这版工具中，文件 AST 加载工具本身只能加载 component & function，也就是说我们只能处理 1 与 2 的文案，这是第一问题。

3.2.3 第二遗留问题

第一问题中的 3 和 4 导致的问题其实并不影响扫描的完成率，影响最大的是第二问题，以及最耗时的原因：源文案根本不匹配。

问题原因: 还是由开发流程与内容设计流程并行导致的，由于源文案根本不是开发提交的，CD 内容设计过程中，设计稿文案到源文案有可能发生改变，甚至有可能是只是更换了形容词、量词，最终导致源文案与代码中的设计稿文案匹配不上，工具无法识别。

案例: 如设计稿文案 You completed payment and the collaboration established，CD 贴心地发现没加 the ，又改了统一名词，就变成了 You completed the payment and the order has been created。明明有这段文案，死板的工具没法匹配了。

算法能力: 我们首先可以想到字符串匹配算法：余弦相似度、矩阵相似度与编辑距离算法，但是这个匹配比较机械，它不符合业务场景，譬如某两个句子，使用了相似意思的 collaborations 和 orders，但算法在大量语料库的情况下很难把这两个句子匹配起来。

结果: 问题长期无法解决，遇到这种情况，需要靠人力去处理。

3.3 其他工具

• 源文案的查看与 CI 工具：如前文静态扫描部分所述，根据相同的 AST 搜索思路，我们的 vscode 插件支持了匹配获取 key ，再远程找到对应的文案。同理，CI 也可以利用相同的方法，扫描 diff 代码中 key 是否完成了替换。
• 合作 Figma 提效：内部 Figma 组提需接入中台 Figma 插件，根据圈选的文案，直接生成 key - 源文案，便于 CD 直接在设计稿上
• 翻译缺失自动上报：这里在之前那篇文章的 runtime 检查部分已经叙述过，我们通过 i18n 框架的钩子，实现上报缺失的翻译到我们的追踪平台，便于我们直接收集错误信息。

四、探索替换工具的创新路线

如上所述，我们遗留最大的问题，是文案扫描的不够彻底，以及文案匹配不上。

4.1 优化扫描问题：范围扩大与过滤

4.1.1 理论性

中台提供的 AST 扫描工具，默认只输出了 function & component，但它提供了一个钩子。

我们可以自己手动分析 AST 结构，做到对字符串、Object 属性等的分析，这就让第一遗留问题的第 3 点：静态变量、Object 中的 key 的转换成为了可能。

4.1.2 可行性

识别静态变量和属性是非常危险的，因为没人知道扫描出来的那个字符串，它到底是需要翻译的，还是一个代码关键字。

换句话说，扫描走到这一步，就几乎不可能直接做到准确，极有可能一不小心把原代码替换坏了，这也是这个插件默认不做这件事情的原因。

4.1.3 折中方案

1. 我先实现了对 Object 属性的扫描，仅在扫描选项开启的情况下，约定对以 'Key' 结尾的属性名进行扫描，如 {'somethingKey': 'xxx'} 的形式。
2. 同时，对于静态变量，只要它被 String 函数包裹且文案以 '__todo '开头，如 String('__todo hello') 也可以被扫描。
3. 再排除常用关键字，如 useQuery 里面用的 queryKey

if (['CallExpression', 'JSComponent', 'VueComponent'].includes(path.type)) {
  return false;
}
if (
  path.type === 'StringLiteral' &&
  ['ObjectProperty'].includes(path.parent.type) &&
  // && ['ObjectProperty', 'ParenthesisExpression'].includes(path.parent.type)
  ['ObjectExpression'].includes(path.parentPath.parent.type)
  // && ['ObjectExpression', 'VariableDeclarator'].includes(path.parentPath.parent.type)
) {
  if (
    path.parent.key &&
    path.parent.key.value &&
    path.parent.key.value.endsWith('Key') &&
    !path.parent.key.value.endsWith('mutationKey') &&
    !path.parent.key.value.endsWith('queryKey')
  ) {
    return false;
  }
}
return true;

它在安全的前提下，几乎极致地扩大了扫描范围，尽可能地解决第一问题。

4.1.4 未来方向

如 TRAE、Cursor 等的 IDE 已经在对整仓进行向量化了，借助其能力，未来可以有更智能的识别方式！

4.2 优化匹配问题：创新 AI 语义匹配能力

匹配问题在旧时代很难解决，早期文本含义的相似度模型并不是能给消费级个人使用的，且效果也不尽人意，我们没办法让机器去寻找意思相近的源文案。

而 LLM 的出现改变了这一现状。在原始版本工具扫描后，把匹配不上的文案收集起来，与我们的源文案库进行大模型匹配，或许我们可以利用大模型的能力再做进一步匹配？

4.2.1 工具核心流程调整

原流程:

graph TD
AST扫描 --> 匹配源文案库
匹配源文案库 -- 匹配 --> 替换 --> 发送通知
匹配源文案库 -- 不匹配 --> 生成excel --> 发送通知

接入大模型后的流程:

graph TD
AST扫描 --> 匹配源文案库
匹配源文案库 -- 匹配 --> 替换 --> 发送通知
匹配源文案库 -- 不匹配 --> 大模型再次匹配
大模型再次匹配 -- 匹配 & 替换 --> 替换
大模型再次匹配 -- 不替换 or 不匹配 --> 生成excel --> 发送通知

4.2.2 资源选型

可行性

我们先用一小段语料库构建 prompt，再给 GPT 输入调换顺序、修改形容词的一段文案，进行了一些尝试，结果非常不错，能够准确匹配到相似文案。

那么理论上，这个方案是可行的！

模型选型

这里借用内部其他同学的一部分调研结果（大模型迭代太快了）

模型	Tokens	返回效果	流式返回	稳定性	运行速度	备注
gpt-4o-2024-08-06	128K	中	Y	高	快(<5s)	输出效果一般
o1-preview-2024-09-12	128K	高	N	中	快	贵
doubao-256k	256k	低	Y	低	快	接口不稳定
deepseekR1	128K	高	Y	中	过慢(>20s)	思考模型，慢

实际测试下来，deepseek 的输出效果最准确，但是对于大量输入的场景，思考太慢。

4o 模型次一些，输出效果凑合，偶尔会有幻觉问题，但是相对非常快。

模型可切换应当是适应时代的基本要求，考虑到我们会多次大量处理英语文本、服务稳定性以及当前公司内生态，我们暂使用 4o 作为主要大模型。

4.2.3 输入处理

考虑 token 量的问题，以及输入越多，幻觉问题越严重的情况：

我们可以对输入内容进行分块处理！所幸我们的输入输出非常直白简单，因此我们每次处理几个单词，最后把回答合并起来，就能得到一个非常不错的处理结果！

分块前：token 不足

graph TD
输入 --> 大模型 --> 输出

分块后

graph TD
输入 -- 分片 --> 输入块1.2...N --> 大模型 --> 输出块1.2...N -- 合并 --> 输出

4.2.4 Prompt 与语料库搭建

Prompt 格式

为了让代码更好地处理大模型输出结果，我们可以利用大模型的格式化理解能力，在 prompt 里让它规范地输出 JSON 格式的信息。

prompt 里除了我们的要求外，还需要给它一个用于匹配的语料库。

语料库问题

我很快就遇到一个问题：我们的语料库太大了！

gpt4o 的 token 数不够塞进全部的语料，而且未来会更大！我们每周都会增加数十到上百条文案！我们也不太可能为了这件事情申请n张卡进行模型微调！

而此刻，我想起了一个业界通用的 langchain RAG 方案：embedding + vectorStore，也是所谓知识库的搭建方法。

同时，我们还有另一个多次合并方案：直接把语料库切割，对同一输入问题进行基于不同语料库的多次提问，最后合并结果。

多次合并方案

这个方案比较适合语料库与输入不是特别大的情况。

方案需要把多次提问的结果再进行一次大模型合并，这有可能导致结果更好，也可能导致进一步不稳定，尤其对于 chatgpt 的 prompt 驱动型模型，如果 prompt 没处理好，效果会差很多。对于语料库与输入特别大的情况，该方案会导致运行时间特别长。

我们设输入切片为 N 块，语料库切片为 M 块，整套流程下来运行 M * N 次，llm 时间复杂度基本为 O(n^2)

graph TD
语料库 -- 切分 --> 语料库1.2...M
输入1.2...N --> 语料库1.2...M --> 大模型1 --> 输出1-1.1-2...N-M --> 大模型2 --> 输出

因此我们优先考虑 langchain 知识库方案，本方案可以对短语料场景备用。

向量数据库搭建(知识库)

其原理，是把知识库，也就是我们当前所说的语料库，进行分片、并利用 embedding 模型转换成向量存储起来。

• 为什么要转换成向量？ 大模型的本质就是向量，同时向量也能更快速地对输入进行相似度匹配！
• 使用它有什么用？ 为了不把整个语料库塞进 prompt，为了缩减 token 数，分片的向量数据库可以帮我们匹配出与输入内容最相似的 n 片语料！这样我们就不用把整块语料库塞进 prompt 里，而是把与输入内容相似的那些提取出来，生成一个新的语料库来进行匹配！
• 局限性 其实问题和相似性算法类似，对于语义相同但字母完全不同的单词，向量数据库很难匹配上对应分片，只能期待它能被松散带入 prompt

这完全符合我们的需要！我们就是要一些有点相似的语料库！

同样设输入切片为 N 块，语料库切片为 M 块，该流程运行次数约为 M + N，根据 M 的情况，llm 时间复杂度在 O(n) - O(n^2) 之间

graph TD
语料库 -- 切分 --> 语料库1.2...M -- embedding --> 向量数据库
向量数据库 --> 相似度匹配 --> prompt
输入1.2...N --> 相似度匹配
输入1.2...N --> 大模型
prompt --> 大模型 --> 输出1.2...N -- 合并 --> 输出

这时候又出了个问题！转换向量数据库也需要时间！语料库分片太多(> 200)，它好慢！

针对性预处理数据

生成向量数据库的时间问题如何解决？

1. 通用方案

方法：生成好的向量数据库可以存储，我们可以预制向量数据库，保存在远端，然后每次下载下来，同时增量文本再去训练新的分片。

问题：需要我们有一个服务来上传下载管理向量数据库，以及需要处理好分片的问题。

2. 针对场景的特殊方案

方法：我们可以根据需要处理的文本，结合实际情况，对语料库进行一些预先的粗糙算法处理：对于长文本，提前匹配其中的几个单词，加入新的语料库；对于简单单词，直接全量预设。毕竟，人工算法速度可比 embedding 模型快多了！

问题：相对第一个方案，理论上会慢一点，但在尝试后，如果输入在 6 个文案左右，以我们当前的文案库的量，每次大约会有20个左右的文档库，且使用 embedding-small 速度并不慢。

同时，还有一个问题，向量数据库同样也有幻觉问题！量越大，幻觉同样越严重！考虑到灵活性与实际 roi，我们目前使用了针对场景的第二方案。

提前预处理过的语料库，不仅可以瘦身，而且比直接切片的输出效果要好很多！

预处理数据库产生的切片，相关性会比直接切高，能够更好地让知识库匹配到正确的切片。

直接拆分语料库:

graph TD
语料库 -- 切分 --> 语料库1.2...M -- embedding --> 向量数据库
向量数据库 --> 相似度匹配 --> prompt
输入1.2...N --> 相似度匹配
输入1.2...N --> 大模型
prompt --> 大模型

预处理再拆分语料库

graph TD
语料库 --> 语料库1.2...N
输入1.2...N --> 语料库1.2...N -- 简单筛选 --> 语料库1.2...M -- embedding --> 向量数据库1.2...N
向量数据库1.2...N --> 相似度匹配 --> prompt
输入1.2...N --> 相似度匹配
输入1.2...N --> 大模型
prompt --> 大模型

4.2.5 Deepseek 对结果清洗

让我们回过头来看 4.2.2 中的模型选型，我们选用 gpt4o 是因为他快、便宜、效果也算凑合，量大管饱，但同时也带来了很多脏数据。那我们是不是可以用其他效果好但是成本高、速度慢的模型去清洗一遍？

在合并方案的研究、与模型选型中，我们发现 deepseek 虽然很慢，但对于结果校验与过滤的效果非常好，一次运行的时间还是可以接受的，因此可以针对幻觉输出进行一遍清洗，顺便还能处理一个文案匹配到多条的情况。

同时，deepseek 清洗偶尔也会有过于严格的情况，不过对比原来的大量脏数据，效果已经好很多了。

4.2.6 最终产品形态

LLM 整体流程

整个工具，在匹配与直接替换后，剩余没有匹配上的源文案，会再进行一次 llm 匹配。

1. 首先这些文案会进行分块，比如我们现在每块 7 个文案。
2. 这 7 段文案先通过算法与整个语料库匹配，将有相似长单词的语料保留下来，形成一个新的语料库，这个步骤耗时在 100ms 以内。
3. 这个新的语料库进一步按照 embedding 模型的 token 长度分片，生成向量数据库的多个分片。
4. 向量数据库与这几个文案进行相似度匹配，取出最相近的 10 个分片，拼接成用于向 gpt 提问的语料 prompt
5. 语料 prompt 拼接提问 prompt，要求让 gpt 输出某 json 格式，再加上作为用户输入的文案，喂给 gpt 进行处理
6. Gpt 输出或是没找到这批文案对应的相似 key-源文案，加入到结果中。
7. 下一块的7个文案再从第2步开始重复，直到文案全部处理完。
8. 对处理完的 JSON 再用 deepseek 进行一遍清洗，尽量解决 gpt 幻觉问题。

4.2.7 结果比对

1. 通过这一整套流程下来，团队开发流程上，整体的匹配率可以提升到 70% 以上，且能够更准确地暴露出漏提翻译需求的问题！
2. 由于大模型的运行结果并不一定准确，工具允许用户选择是否应用替换，用户也可以手动处理 ai 匹配结果。

匹配率提升

对50%以上匹配不成功内容实现了进一步匹配

消除 GPT 幻觉

原结果

Export all cooperations -> Export creator list
Search by creator name or collaboration ID -> Search by creator name or project ID
Weekly application -> {num, plural, one {{count} creator applied to join the campaign. Review this creator to start your order.} other {{count} creators applied to join the campaign. Review them to start your orders.}}
{remain} / {total} -> {num, plural, one {{count} result for “{keywords}”} other {{count} results for "{keywords}"}}
No result -> No results found
Negotiating creator pay -> {count} creator negotiations to review.
Video Submitted -> Video submitted 
Product redemption -> Product to deliver
Edit redemption details -> Edit invitation settings
shortlist can add up to 1000 creators -> Shortlist's creator limit reached
Users with Analyst role can't send invites -> Analyst
Please select campaign country first -> Please select a campaign country or region first.
Creator applied this campaign with proposed price -> The creator applied to this campaign with a price offer
You completed payment and the collaboration established -> You completed the payment and the order has been created
Error: duplicate codes -> Error: duplicate codes found

清洗后

Search by creator name or collaboration ID => Search by creator name or project ID
No result => No results found
Video Submitted => Video submitted 
shortlist can add up to 1000 creators => Shortlist's creator limit reached
Please select campaign country first => Please select a campaign country or region first.
Creator applied this campaign with proposed price => The creator applied to this campaign with a price offer
Error: duplicate codes => Error: duplicate codes found

清洗后 Deepseek 几乎完全消除了幻觉匹配

五、对 LLM 的感悟与展望

5.1 大模型能力边界与适用场景

1. 核心认知：大模型是工具而非解决方案

虽然对话与简单任务效果很好，当前主流 LLM 的幻觉率（5%-15%）使其无法直接用于关键决策场景，需结合人工校验。

即使本方案在 LLM 方面，使用了多种过滤策略，LLM 同输入情况下的输出每次依然都会不同，依然不能保证匹配结果绝对正确。

2. 能力适配场景

适合场景	典型应用案例
从 0 到 1 生成	代码骨架生成、文案创意
信息结构化	日志摘要、用户反馈分类
知识提炼与翻译	文档概括、知识问答、全文翻译
轻量级数据转换	SQL 语句生成、JSON/YAML 格式互转

3. 待优化的能力

• 大型定制项目的局部多方位调整、修改
• 专业领域高精工作，如量化计算、投资、处方
• 主观判断、重要决策
• 实时事件
• 敏感信息

5.2 业务场景适合用大模型干什么？

1. 基本原则

• 模型可切换：目前市面上大模型迭代速度极快、散布范围广，模型淘汰速度会很快！
• 不做重复轮子: 一些 chatbot 直接能用的基本功能根本不需要我们多此一举去提供，有其他团队愿意做自然不需要我们浪费人力。
• 工具链闭环: 作为业务方，我们提供的应是定制化的 agent、一套完整的工具链，大模型只应该是这个工具链的一环！

2. 核心方向

• 生成与创意：单纯的生成能力不需要我们做，我们需要的是跟业务关联的。譬如能够适配项目依赖的代码生成、适配业务场景的内容生成、D2C 等。又如 Trae 或 cursor 这类 AIGC 编辑器，不论是补全还是单测生成，想要做到更好，都会根据活跃代码、项目的上下文进行 prompt 提取。
• 概括与提取：简单的 chatbot 概括也不是我们要做的，我们要做的应是与实际场景结合的大量数据处理概括能力，来补全大脑记忆力不足的问题。譬如大量代码、文档整合理解、业务具体内容的分析、客服提问助手等
• 翻译与理解：同样翻译是需要语境和场景的，如本文的文案处理，是基于我们语料库的场景之下，其他如多语种 oncall & 问卷的分析、文案校对等。
• 转换与智能agent：对于不会某些领域专业知识的同学，如查数、数据导出等，能够根据描述直接找到对应数据表、转为查询语句，同样需要人工的前置干预与包装。

3. LLM 的未来

• 不断增强: 大模型未来会变得更快、更准确，token 容纳量也必然会不断增加
• 横向扩展: 结合大模型和其他深度模型的 agent 也会出现，一个 agent 能够生产多种不同的媒体资源
• 定制化: 针对数据保密需求与业务定制场景，未来必然会有轻量化的模型或部署服务，提供给企业团队微调部署

5.3 文案设计流程的优化

本文尝试在研发工作层面上极致地提高效率，但归根结底，如果我们文案设计流程能加速，就能解决很多问题。

CD 最耗时的工作依然是做文案

CD 工作中遇到的麻烦，主要是以下几个：

• 名词统一
  • 问题：需要保证名词的一致性，如一个合作订单，应该叫 order 还是叫 collaboration？
  • 方向：一个业务应该有它的术语库，用于特定场景语义化校验。这或许可以通过 LLM 自动整理，也依赖语料库与平台需求文档的上下文
• 需求理解
  • 问题：如我们一个流程叫 Lite 一个叫 Full，这两个词好像对不上，又要和产品协商，根据需求的含义调整语义。
  • 方向：同样或许可以由 llm 进行矫正，llm 同样需要需求上下文