语言领域缺失的操作系统

想想软件已经发展到了什么程度，能够为团队提供共享工具，以一致的方式开展工作。框架让开发者能够以可预测的模式表达逻辑。设计系统让设计师和工程师能够在每一个屏幕和界面上共享统一的视觉语言。Git为协作、版本管理和审查奠定了基础，而 GitHub 和 GitLab 则将其发展为数百万人每天都在使用的工具。

现在再想想语言。您的产品实际用来与用户沟通的措辞。错误消息采用的语气。营销文案在日语中的表达方式与在德语中的表达方式有何不同。支持团队使用的术语与产品用户界面中的表述有何差异。

这些方面没有任何共享系统。没有框架。没有设计系统。没有 Git。什么都没有。

我们从未构建所需的基础设施

问题并不在于缺少理论。语言学是一个内涵丰富的领域。尤金·奈达提出的动态对等概念告诉我们，优秀的翻译并非替换词语，而是要重现读者与信息之间相同的感受关系。话语分析、语用学、社会语言学等学科，已经用数十年时间研究语言如何在具体语境中发挥作用。理论基础早已存在。

但没有人围绕这些理论构建一套系统。

互联网兴起后，本地化公司将其专有桌面应用程序迁移到了浏览器。底层模式保持不变：翻译记忆库、模糊匹配、按字计费。他们继续在同一个基础上构建产品。当机器翻译有所改进时，他们只是将其附加到现有系统之上。没有重新思考，也没有重新构想。只是相同的工作流，底层引擎变得更快而已。

随后，中间商出现了。

在您（拥有内容的个人或公司）和语言专家（真正理解语言的人）之间，形成了一个由大量中间商组成的完整行业。集成平台。翻译管理系统。翻译机构。质量保证环节。项目管理仪表板。每一层都增加了复杂性，每一层都要从中分成。贡献价值最大的人，也就是具备文化意识、术语精确度和创造性判断力的语言专家，最终却处于产业链的最末端，获得的报酬也最低。

行业报告显示，人工智能译后编辑费率可能降至原本就不高的按字费率的 50% 至 70%，而翻译机构还会在此基础上要求再降低 30% 至 40%。这条供应链正在挤压其最为依赖的人群。

缺失某种关键事物的迹象

有一个现象表明，现有工具还不够完善：企业正在设立一个名为“语言经理”的岗位。他们的全部职责是维护术语、监督翻译工作流、确保术语一致性，以及协调语言专家、产品团队和营销部门。

这一岗位的存在本身就是一个信号。它意味着组织需要在所有渠道中保持语言一致性，但现有工具无法满足这一需求。因此，他们需要聘请专人充当各方之间的纽带。

而这些人最终会陷入两难处境。一方面，他们可以申请工程资源来构建内部系统，但这需要对一项并非雇主核心业务的工作进行巨额投入。另一方面，他们可以寻找外部工具，但目前并没有人真正构建出完整的解决方案。现有工具大多是规模较小且相互割裂的组件，需要由他们自行编排和整合。这两种选择都不理想。

这正是一个系统应当填补的空白。它不是要取代语言经理，而是要为他们以及与其合作的每一位语言专家提供一个完善的工作操作系统。

我们正在用 Glossia 构建什么

我们认为，答案与其说是一个翻译工具，不如说更接近 GitHub 为代码所做的事情。

GitHub 将 Git 这一用于跟踪文件变更的系统转变为一个协作平台，开发者可以在其中相互审查工作、讨论变更并共同迭代。在 GitHub 出现之前，参与软件项目需要通过电子邮件反复传送文件。GitHub 出现后，任何拥有账户的人都可以参与其中。

我们希望为语言做同样的事情。

Glossia 是一个操作系统，组织可以在其中记录自己的语言偏好、语言风格、术语、语气和受众期望，而语言专家则处于持续完善这些偏好的核心位置。他们不在流程末端，不被隔在三层中间环节之后，而是处于核心位置。

我们曾在关于上下文图谱的文章中讨论过这一点：我们正在构建一张由相互关联的知识组成的结构化图谱，用于持续记录组织掌握的全部语言知识，包括语言风格定义、术语条目、受众画像和正式程度规则。每一项内容都有版本记录，因此您可以查看何时发生了哪些变化，并且它们与所有相关内容相互关联。当某项内容发生变化时，系统能够准确识别受到影响的内容以及需要重新审视的部分。

这是您在 Glossia 上的账户，以及您可以参与的众多项目。语言专家可以跨多个组织开展工作，将自己的专业知识应用于不同情境，并看到其决策的影响在整个系统中传播。正如开发者可以在 GitHub 上为多个项目做出贡献一样，Glossia 上的语言专家也可以塑造数十款产品的表达方式。

人工智能是能力放大器，而非替代者

围绕人工智能和语言的主流叙事往往聚焦于替代：速度更快、成本更低、人工更少。我们认为这种观点存在根本性错误，而且坦率地说，这是对语言专家深厚专业能力的不尊重。

我们的观点不同。人工智能是在一个由语言专业知识塑造的系统上运行的工具。它不会取代语言专家，而是放大语言专家所能实现的价值。

当语言专家在 Glossia 上完善一项语言风格定义时，这项改进会应用到系统处理的每一项内容中。当术语专家更新一个术语条目时，任何智能体下一次为该组织生成或转换内容时，都会采用这一更新。一项由人作出的决策可以扩展至数百甚至数千项输出。这是一种前所未有的规模化影响力。

翻译是最显而易见的用例，也是我们的起点，但并非唯一的用例。当一个组织构建起丰富的上下文图谱，其中积累了语言专家团队历经数月乃至数年形成的语言记忆，便会涌现更多可能：

• 营销团队可以通过 MCP（模型上下文协议，一种让人工智能工具与外部系统通信的标准）将写作工具连接到这一操作系统，并确保每项营销活动都遵循公司的术语和语言风格。
• 产品团队可以验证用户界面文案是否符合为目标受众定义的语气。
• 客户支持团队可以生成符合品牌风格的回复，而不是千篇一律的聊天机器人话术。

语言知识由此成为共享资源，如同专门用于语言的设计系统。

语言专家理应拥有更好的工具

如果你是一位正在阅读本文的语言专家或译者，我想让你知道，这个项目因你而存在，而不是无视你的存在。

多年来，本地化行业不断将你推离所服务的人和组织。它将你的工作商品化，压低你的报酬，并在一条以吞吐量为优化目标的流程中，将你的专业能力视为次要因素。

我们认为，语言专家应当成为组织沟通方式中的核心参与者。你理解语域、语用、文化语境，以及一句话的字面表达与真实含义之间的细微差别。任何模型都无法取代这些能力。但系统可以让你的洞见传播得更广、保留得更久，并产生超越任何单次翻译的影响。

我们构建 Glossia，是为了让你的专业能力成为其他一切运行的基础。它不是流程末端的一个步骤，而是整个系统的基础。

接下来

我们仍处于早期阶段。我们选择从命令行界面代理（一种命令行工具，即通过在终端中输入命令与其交互，而不是在图形界面中点击按钮）开始，是因为最棘手的基础设施问题都集中在这里：读取源文件、生成输出、使用你自己的工具进行验证，以及完成反馈闭环。但正如我们在首篇文章中所述，终端只是第一个界面，而非唯一的界面。

我们正在设计新的使用体验，让语言专家可以并排查看内容与上下文，通过协作会话完善语言风格定义，并实时观察他们的决策如何在整个系统中发挥作用。我们希望，贡献语言专业知识可以像在 GitHub 上贡献代码一样自然，并同样富有成就感。

如果这些内容引起了你的共鸣，无论你是曾因被要求使用的工具而感到自身价值被忽视的语言专家，还是正在寻找理想系统的本地化经理，抑或只是相信沟通方式与构建方式同样重要的人，我们都期待听到你的声音。欢迎加入我们的 Discord，或持续关注我们的博客。这场对话才刚刚开始。