文案漂移：它是什么、成因是什么、如何预防

文案漂移是指界面文案在不同界面之间、随时间推移偏离已批准的源文案，而且根本没有一个统一的权威来源可供对照。字符串既没有缺失，也没有损坏——变的是措辞本身，没有人决定要改，结果营销页、落地页和产品对同一个功能各说各的，细节略有出入。globalize.now 是代码原生的文案管理系统，内置本地化能力，而漂移正是它专门要防止的故障。

什么是文案漂移？

文案漂移是指界面文案在不同界面之间、随时间推移偏离已批准的源文案，而且根本没有一个统一的权威来源可供对照。

这个定义由两部分共同支撑。偏离已批准的源文案，说明曾经有人约定过这个字符串该怎么说。没有统一的权威来源，说明已经没有任何产物还保存着这个约定，因此在可检查的意义上，根本无从对照——这也是没人能指出漂移从哪一刻开始的原因。

漂移是常态，而非例外。任何拥有多个界面、由多人编辑的产品，只要没有结构性的手段来阻止，就一定会漂移。

文案漂移不是什么

三种故障常被混为一谈，但各自的修复方式并不相同。判断错了，团队就会去解决错误的问题。

硬编码字符串是直接写进组件、而不是放进语言文件的文本。工具链和翻译流程都看不到它，但措辞本身可能完全正确。这是另一类问题，我们在 为什么 AI 编程工具总在添加硬编码字符串 中已经讨论过。

不同步的翻译文件指的是语言文件都在，但彼此已经脱节。源文件没问题，派生出来的副本却过期了。

文案漂移则两者都不是。字符串可以有翻译键，文件可以保持同步，产品里却依然可能一处写“开始免费试用”，另一处写“免费体验”，而真正触发操作的按钮上写的是“立即开始”。

三个问题可能同时存在，而且不会互相修复。

文案漂移是怎么产生的？

有三种机制，按造成的破坏程度由大到小排列。

**不同的人负责不同的界面，还用不同的工具编辑。**营销文案放在 CMS 里。落地页因为持续做实验，更新得最快。产品字符串则写在组件里。每个界面内部可能都是一致的，整个产品却不一致，而且没有人会在同一时间把三处都看一遍。

**没人当作文案修改的小改动。**有人为了适配移动端断点缩短了一个标签，有人为了和相邻页面保持一致，把标题改成了句首大写。单看每一处都说得过去，但没有一处会经过类似文案评审的环节，因为在工具链眼里，它只是 JSX 属性里的一个字符串字面量。

**编程 Agent。**让 Agent 添加一个加载状态，它可能顺手改写文件里的某个标签——在它看来，整理字符串和整理代码没有区别。目前社区的做法是用规则文件：AGENTS.md、.cursorrules，或者在提示词里加一段 UI 文案规范。这些做法有帮助，也值得采用。但约定不等于检查。它能降低文案被改写的频率，却无法告诉你改写何时发生了。

为什么没有任何工具能发现文案漂移？

因为什么都没有坏。

改过的标签照样能编译，照样能渲染。类型检查器看到的是合法字符串，linter 看到的是合法语法。快照测试即便失败，通常的处理也是更新快照，这等于把漂移记录了下来，而不是标记出来。构建不会变红，不会触发告警，监控面板也不会变黄。

只有知道“已批准的措辞是什么”的东西，才能看出漂移。大多数工具链没有这样的记录，所以第一个发现问题的往往是人：客服回复引用的措辞和界面对不上，客户来问“工作区”和“项目”是不是一回事，或者译者来问英文的三种写法到底该翻哪一种。

文案漂移究竟会造成多大代价？

说实话：没人量化过，我们也没有，所以我们不会编一个数字出来。

这一点必须说清楚，因为这个领域充斥着经不起溯源的数字——关于品牌与营收的调查数据、每张工单的支持成本、归因于文档不一致的工单占比。我们内部删掉了好几条这类数据，也不打算转述。真正能回答这个问题的测量——真实代码库里到底有多少漂移，以及它对下游有什么影响——至今没有人做过。

不用数字也能描述的是它的机制，而这个机制会不断累积：

• **不出事则无感，一出事就贵。**修复成本低的时候，没有任何东西会暴露漂移。等到有人需要措辞保持一致时，它才浮出水面，而且通常是在时间紧迫的时候。
• **每个界面都要单独修。**改一个说法，就得找出它被重复写过的每一处，而这些位置并没有清单可查。
• **本地化会把问题成倍放大。**这是最要命的一点。同一个意思的三种写法送去翻译，每种语言都会得到三种译文。原本只出现在英文里的不一致，会按语言区域的数量被复制一遍，母语用户读起来就像三个不同的功能。

最后这一点说明，文案一致性和本地化不是两个独立的项目。如果说不清哪种写法才是已批准的，就无法正确翻译其中任何一种——源文案在译者看到之前就已经含糊了。解决这两个问题的是同一种架构，我们在 代码原生的产品文案 中有详细阐述。

如何预防文案漂移？

让措辞只有一个存放位置，并让对它的改动可审查，其余的自然水到渠成。

**一份语言文件。**所有用户可见的字符串集中在一处，而不是散落在各个组件里。这样才有了可以对照的“基准”。

**用翻译键，不用字面量。**组件引用翻译键，而不是重复写一遍文字。同一个说法不可能出现在两个地方、悄悄分叉，因为它只存在一份。

**改动出现在 diff 里。**文案改动和其他改动一样，会出现在评审中。真正起作用的是这一步：一致性不再靠某个人记得风格指南，而是在有人一定会认真查看的那个时刻变得可见。

产品之外的界面——营销页、落地页——是更难的那一半，我们坦白说明目前的进展：把营销、落地页和产品的文案作为一个整体来统一，是 globalize.now 正在努力的方向，目前还不能一键启用。机制和上面说的相同，只是延伸到了应用边界之外：如果每个界面都通过翻译键引用已批准的字符串，而不是各自重写，改一个说法就只需要做一次决定，而不是三次。

使用 AI 编程工具交付产品的团队最早碰到这个问题，所以我们既为 开发者 写文章，也为 用 AI 工具构建产品 的人写。

风格指南能解决文案漂移吗？

不能——风格指南和统一的权威来源解决的是不同的问题，团队常常买了前者，却指望它起到后者的作用。

风格指南描述的是好文案该是什么样：语气、大小写、术语，以及什么时候用“删除”、什么时候用“移除”。它确实有用，每个团队都应该有一份。但它做不到的是告诉你某个字符串被改了。它没有旧措辞的记录，也没有挂钩到改动发生的那一刻，只能靠恰好看到对应界面的人来执行。

漂移是状态问题，不是品味问题。修复手段必须放在状态所在的地方。

同样的文字一旦存在于两个地方，漂移就开始了。globalize.now 会在你连接的仓库里把它们收敛为唯一来源，并由这一份派生出所有语言版本。