TCDEV Blog

让您的 LLM 用英语思考

2026-04-27T00:00:00Z

您为德国团队开发了一个聊天机器人。用户界面是德语。源文档部分为德语，部分为英语。助手背后的工具希望使用英文枚举值、英文功能描述、英文产品名称等所有英文内容。

然后有人用德语问了一个非常正常的问题，模型选择了正确的工具，传递了一个德语参数，而不是英语参数，然后整个事情就悄然崩塌了。

这种情况我已经见过很多次了，所以我不再认为这是翻译问题。**这是一个执行问题。

我目前的默认做法很简单：用户想说什么语言就让他们说什么语言，但只要可靠性确实重要，就让 LLM 用英语完成检索、推理和工具工作。然后在这个循环之外将答案本地化。

这听起来有点异端。在我看来，这也是目前最实用的方法。

研究开始大声说出这句话

数字不再微妙。

在MASSIVE-Agents 基准中，研究人员对 52 种语言、47,020 个样本和 21 个模型的多语言函数调用进行了评估。所有语言的最佳平均得分仅为 34.05%。英语达到了 57.37%。阿姆哈拉语降至 6.81%。

这可不是一个小的质量波动。这是一个可靠性悬崖。

还有更接近真实系统问题的[Lost in Execution]（https://arxiv.org/abs/2601.05366）。论文显示，许多多语言工具调用失败都发生在模型已经理解了意图并选择了正确工具之后。主要问题是参数值语言不匹配。通俗地说，模型知道要做什么，但却用用户语言而不是界面语言来表达可执行位，因此调用还是失败了。

这种情况不仅限于工具调用。Etxaniz 及其同事在多语言语言模型的英语思维能力更强吗? 一文中发现，在五项任务中，自我翻译成英语的结果始终优于直接非英语推理。他们的措辞直截了当，令人耳目一新：模型 "在非英语语言的提示下无法充分发挥其多语言潜力"。

所以是的，多语言模型令人印象深刻。但是，如果你的标准不是 "听起来不错"，而是 "在生产中必须表现正确"，那么英语在很多时候看起来仍然是更安全的操作语言。

为什么 RAG 会在同一个地方断裂

人们听到这个论点通常会首先想到代理。函数调用、结构化输出、API 执行，诸如此类。

RAG 也有同样的弱点，只是早了一层。

如果你的检索层必须将用户的本地用语与混合语言编写的内容相匹配，同时还要使用不一致的术语、翻译过的产品名称和半本地化的分类标签，那么你就会创造更多机会，让系统在开始生成之前就发生偏移。老实说，这就是很多人抱怨 "模型不可靠 "的原因。模型可能是好的，但内容界面却不是。但内容界面却不是。

我宁愿尽早规范化。

将问题翻译成英语。根据英语规范语料库进行检索。让模型在一个稳定的术语层上进行推理。必要时生成英文版的答案草稿。然后为用户翻译或本地化最终答案。

这样，您就可以在一个地方保持命名的稳定性：

一个规范文档标题
一个规范的产品词汇
一个统一的工具模式
一套统一的检索标签

您仍然可以在外部支持每种用户语言。您只需停止要求核心执行路径在每一步都完美地使用多种语言。

这不是反本地化

恰恰相反。

糟糕的多语言人工智能架构通常会首先伤害本地用户。他们得到的是漂亮的本地化界面，然后隐藏在界面下的以英语为中心的系统却表现不一致，让他们付出代价。

正确的本地化意味着要诚实地对待语言在哪些地方应该灵活运用，哪些地方不应该。

对我来说，这种划分是这样的

本地化用户界面、提示、帮助文本、入职培训和最终答案。
本地化人们在市场中需要直接阅读的源内容。
如果内部工具定义、规范标识符、检索标签和推理枢纽是最稳定的层，则将其保留为英文。
在本地化输出具有法律、监管或合同权重的情况下，添加明确的后处理或人工审核。

最后一点比团队愿意承认的更为重要。如果模型是与人对话，本地化就是一个用户体验决策。如果模型是在与另一个系统对话，语言就是界面合同。

这两者不是一回事。

我现在最信任的架构

这是我目前最信任的多语言人工智能产品版本：

1.用户用自己的语言提问。 2.系统将请求翻译或规范化为英语。 3.根据英文规范数据进行检索、推理、排序和工具调用。 4.将最终答案本地化为用户的语言。 5.高风险输出在离开系统前会有额外的验证步骤。

这在哲学上并不纯粹。它在操作上是合理的。

好在最近的研究也指出了同样的方向。Lost in Execution发现，对用户查询进行预翻译通常比事后修复能更好地减少语言不匹配错误，尽管它仍然不能完全恢复英语级别的性能。这与许多构建者在实践中已经怀疑的情况不谋而合。如果等到最后才清理多语言不一致问题，通常为时已晚。

当然，也有例外。如果你正在为低资源语言、特定领域语言或文化依赖性措辞进行构建，将所有内容翻译成英语可能会带来漂移。上述论文明确警告了这一点。所以，不要把这变成教条。

但作为企业副驾驶、内部助理、多语种 RAG 和工具使用代理的默认设置，我认为这条规则的适用性出奇地好。

这对 Rasepi 意味着什么？

这正是我如此关注规范内容结构的原因。

如果你的知识库有一个简洁的源代码层、稳定的术语和可控的本地化，那么人工智能就更容易被信任。如果每种语言版本都在执行路径中独立漂移，你就会要求模型在系统应该精确的地方随机应变。

Rasepi 的整个方法就是围绕着将这些关注点清晰地分离出来而构建的。保持核心规范。有意识地进行本地化。跟踪存在变体的地方。不要因为用户界面是多语言的，就认为堆栈的每一层都应该是多语言的。

我曾经认为，最好的多语言人工智能体验意味着 "用用户的语言完成一切"。现在我不再这么想了。对于那些必须检索正确的段落、选择正确的工具并返回值得信赖的内容的系统来说，就不是这样了。

实际规则很简单：用户应保持本地化，但 LLM 的执行路径应保持稳定。现在，这通常意味着中间是英语，边缘是本地化。

这将随着时间的推移而改变。我希望它能尽快改变。但是，如果您现在正在发货，而且可靠性比美观更重要，那么我会让模型用英语思考，让您的产品用用户的语言说话。

克劳德设计和一人创意公司

2026-04-18T00:00:00Z

昨天，Anthropic 推出了 Claude Design，这是 Anthropic Labs 团队的一款新产品，通过与 Claude 对话，您可以创建设计、原型、演示文稿和营销资料。我坐在那里看着公告，心想：好吧，现在一个人订阅了克劳德，就真正拥有了一家小型创意公司所能提供的大部分服务。设计。代码。自动化。演示文稿。品牌一致性。一切都在同一个生态系统内。

在 2026 年写下这样的句子，真是天方夜谭。但我认为这并不夸张。

克劳德设计公司的实际工作

简而言之：您描述自己的需求，克劳德设计出第一个版本。然后，你可以通过对话、内嵌评论、直接编辑或克劳德为你生成的自定义滑块来改进。它由 Opus 4.7提供支持，在保持视觉一致性方面有惊人的表现。

但最吸引我的是它的入职功能。在设置过程中，Claude 会读取你的代码库和现有的设计文件，为你的团队建立一个设计系统。颜色、排版、组件。之后的每个项目都会自动遵循您的品牌。你可以导入图片、文档（DOCX、PPTX、XLSX），也可以直接指向你的代码库。还有一个网络捕捉工具，可以从你的实时网站上抓取元素，让原型看起来像真实的产品。

你有想要迭代的 Figma 模型吗？将其导出，放到 Claude Design 中，然后开始讨论需要修改的地方。或者直接捕捉您现有的网站，然后说 "把英雄部分做大，并添加一个推荐旋转木马"。诸如此类。

公告中的评价很能说明问题。Brilliant 的高级产品设计师说，他们最复杂的页面在其他工具中需要20 多条提示才能重新创建，而在 Claude Design 中只需要 2 条提示。Datadog 的产品经理介绍说，从一个粗略的想法到工作原型，在所有人离开房间之前就已经完成了。

一周的反反复复，就在一次谈话中完成。想一想吧。

改变一切的堆栈

有趣的地方就在这里。克劳德设计公司并不是孤立存在的。Anthropic 公司现在有三种产品，它们加在一起涵盖了大量领域：

克劳德代码**：编写、审核和交付实际软件。截至今年二月，运行率收入达 25 亿美元，负责全球约 4% 的 GitHub 公共提交。
克劳德协同工作**：知识工作自动化。研究、分析、文档处理、桌面经常性任务。
克劳德设计**：创建视觉作品。原型、演示文稿、营销资料、品牌资产。

它们可以互相传递。当设计准备就绪时，Claude 会将所有内容打包成一个移交包，您只需发出一条指令即可将其移交给 Claude Code。设计到生产一气呵成。无需 Jira 票据。没有交接会议。不需要 "你能不能把 Slack 中的规格发送给我"。

我一直在想 Sam Altman 在 2024 年初关于[一人十亿美元公司]的预测(https://every.to/napkin-math/the-one-person-billion-dollar-company)。当时，这听起来很有抱负，也许有点夸张。当时的工具还不成熟。当然，你可以生成文本和图像，但生成东西和交付实际产品之间的差距是巨大的。

这种差距正在迅速缩小。

两个月前我会为此付出多少代价

当我创建 Rasepi 时，营销网站是最繁琐的部分之一。不是代码。代码没问题，克劳德处理 HTML 和 CSS 的能力超强。但视觉设计决策呢？英雄布局、定价页卡、功能对比表？我用文字描述，克劳德制作，然后我花几个小时来回调整间距、颜色和排版。所有这些都是通过文字提示完成的。没有视觉反馈回路。

有了克劳德设计公司，工作流程就变了："这里是我的网站"（网页截图），"重新设计定价部分，以强调团队计划"（对话），用滑块调整绿色重点色，批准，交给 Claude Code 实施。我估计这样可以节省我一整个周末的时间。

(老实说，我有点懊恼没有早两个月上线）。

Canva 的导出功能也很聪明。Canva拥有2.2亿活跃用户，年收入30亿美元。Anthropic 并不想取代 Canva。他们试图成为创意的发源地，然后再进入 Canva 进行最终润色和发布。这是一个明智的定位。您可以在 Claude Design 中生成创意，然后导出到 Canva，由营销团队进行处理。或者导出为 PPTX 格式，用于制作投资者简报。或者导出为独立的 HTML，用于登陆页面。

只需添加工具 "倍增器

这是我在 2026 年人工智能领域不断看到的模式。基础模型当然会变得更智能，但真正的生产力飞跃来自于将工具连接在一起。克劳德本身就是一个非常智能的文本生成器。带有代码的克劳德是一名软件工程师。使用 Cowork 的 Claude 是一位研究分析师。带有设计功能的 Claude 是一位创意总监。三者合一的 Claude？那就是个小公司了。

联系还在不断增加。Anthropic 表示，他们将在未来几周内增加更多集成。MCP 服务器已经可以将克劳德连接到外部工具和数据源。生态系统正在自我构建。

对于个人创始人、自由职业者和小型团队来说，这完全改变了他们的计算方式。你不需要聘请设计师来制作专业外观的演示文稿和原型。你不需要一个单独的前端开发员来将模型转化为代码。你不需要项目经理来协调设计和工程之间的交接，因为没有交接。这是一次持续的对话。

我并不是说设计师已经过时了。远非如此。Brilliant和Datadog都描述了他们的设计师使用Claude Design的情况。该工具能让优秀的设计师更快地完成设计，让其他人也能获得合格的视觉输出。这与取代人是两码事。

这对文档产品意味着什么

我正在密切关注这一点。在 Rasepi，我们正在建立一个文档平台，在这个平台上，视觉质量非常重要。入门页面必须美观大方。快速入门指南需要清晰的图表。市场文档需要跨语言和团队的品牌一致性。

在这样一个世界里，每个团队成员都能生成符合品牌的可视化文档，将其交给翻译引擎，并以七种语言发布，而无需接触 Figma、Photoshop 或 InDesign？这正是我们要从另一个角度解决的问题。(没错，这正是 Rasepi 所支持的工作流程）。

成本奇高的部分

现在，大家都还没有谈论这件事。我创建了一个全新的 Anthropic 账户，专门用来试用 Claude Design。新账户，无历史记录，无使用记录。我导入了一个小的 Figma 文件，并生成了一个资产。就这样。两次操作。我的信用点数就用完了。

在一个全新的账户上。有了新的分配

我不知道当 Opus 4.7 进行视觉生成时，Anthropic 方面的代币计算是怎样的，但不管怎样，它消耗代币的速度让 "一人创意公司 "的宣传感觉比预期的要昂贵得多。如果导入一个小型 Figma 模拟并生成一张图片就耗尽了你的全部预算，那么将它作为日常设计工具的经济效益就不太理想了。

公平地说，这只是研究预览版，定价可能会有变化。但现在，在承诺（取代你的设计工作流程）和现实（你可能在午餐前就用完了点数）之间存在着巨大的差距。生产率的提高是实实在在的。至于每次产出的点数比例是否适合常规使用，则完全是另外一个问题。

诚实的注意事项

克劳德设计 "处于研究预览阶段。它将有粗糙的边缘。这些评价来自资金雄厚、拥有成熟设计系统的公司的设计团队。具体情况因人而异，尤其是如果你是白手起家，没有品牌准则可循。

但轨迹是清晰的。18 个月前，你需要一个设计师、一个开发人员和一个项目经理，才能完成从概念到着陆页面的整个过程。如今，一个人只要订阅 Claude，一个下午就能完成同样的工作流程。

我们还没有发展到一个人就能创造数十亿美元的公司。但一人创意公司？我认为我们刚刚到达。

一个 API 密钥，多个租户：我们如何在不同客户间隔离 DeepL 翻译

2026-04-18T00:00:00Z

每次我向其他开发人员解释 Rasepi 的翻译架构时，他们都会提出一个问题："等等，你们的所有租户都共享一个 DeepL API 密钥？你如何保证他们的词汇表和风格规则不会相互泄露？

这个问题很有道理。答案涉及的设计工作比你想象的要多。

我们在上一篇文章中介绍了完整翻译流水线，包括块级散列、协调器以及从文档保存到翻译输出的整个流程。本篇文章将深入探讨多租户的具体问题。如何使用没有租户概念的第三方 API 并在其基础上构建租户隔离。

问题：DeepL 不了解您的客户

DeepL 的 API 使用单个 API 密钥进行验证。在该密钥下创建的所有内容、词汇表、样式规则列表、翻译历史都属于同一个账户。DeepL 没有 "此词汇表属于租户 A "的概念。

当您调用 GET /v2/glossaries时，您将获得来自 ** 个租户的 ** 份词汇表。创建样式规则列表时，该列表与其他租户的样式规则位于同一命名空间。API 是扁平的。

对于自托管产品来说，每个客户都使用自己的 DeepL 密钥运行自己的实例，这样就可以了。对于我们管理基础设施的多租户 SaaS 而言？你需要一个隔离层。

数据库是真相之源

我们的核心设计决策：数据库拥有所有词汇表内容和样式规则配置。DeepL 是运行时的执行目标，仅此而已。

每个 TenantGlossary 和 TenantStyleRuleList 实体都实现了 ITenantScoped，这意味着 EF Core 全局查询过滤器会自动将所有读取范围限定为当前租户。在租户 A 的请求上下文中查询词汇表，永远不会返回租户 B 的条目。这也是我们在 Rasepi 中随处使用的隔离模式，在 ORM 层级强制执行。

有趣的地方就在这里。当租户编辑词汇表术语时，我们不会立即调用 DeepL。我们会更新数据库行并设置 IsDirty = true。就是这样。实际的 DeepL 词汇表会在下一次翻译需要它之前懒散地创建（或重新创建）。

_codeblock_0

TenantGlossaries上的查询过滤器会进行隔离。IsDirty标志实现了懒同步。命名约定（_rasepi-{glossary.Id}）仅用于在 DeepL dashboard 中调试，没有任何功能用途。

为什么是懒同步？因为 DeepL v2 词汇表是不可变的。您无法编辑它们。任何更改都意味着删除和重新创建。如果一个团队导入了包含 200 个术语的 CSV，然后修改了一个词条中的一个错字，我们不希望两次删除和重新创建 DeepL 词汇表。我们只需两次都设置 IsDirty，下一次翻译运行时就会进行一次重新创建。

样式规则：相同的模式，不同的应用程序接口

DeepL's样式规则是较新的（v3 API），实际上是可变的，这一点更好。你可以使用 PUT /v3/style_rules/{style_id}/configured_rules 就地更新已配置的规则，还可以单独添加或删除自定义指令。

不过，我们仍然使用相同的 IsDirty 模式。一个 TenantStyleRuleList 有一个 DeepLStyleId 映射到 DeepL 的运行时标识符，另外还有 ConfiguredRulesJson 用于格式化规则，以及一个 TenantCustomInstruction 条目集合用于自由文本翻译指令。

真正的威力在于这些自定义指令。每条指令都是最多 300 个字符的纯语言指令，可影响 DeepL 的翻译方式。来自我们租户的真实例子：

_"始终使用'Sie'形式，而不是'du'"_一家德国律师事务所
_"将'deployment'翻译为'Bereitstellung'，而不是'Deployment'"_对于依赖于上下文的术语，这超出了简单的词汇表映射范围
_"使用英式英语拼写（颜色、组织、许可证）"_适用于在英语变体之间进行翻译的英国公司
_"在数字金额后加上货币符号"_用于欧洲惯例

每个租户的每种目标语言都可以有完全不同的指令，但都使用相同的 API 密钥。每一次翻译调用都只包含属于请求租户的 glossary_id 和 style_id_，从而实现了隔离。其他租户的 DeepL 资源永远不会被引用。

翻译调用：所有内容组成

当协调器翻译一个程序块时，它会将所有租户的特定设置合并到一个请求中：

代码块_1__

这里的每个参数都针对租户。glossaryId 是通过租户过滤查询解决的。styleId 也是通过同样的方式解析的。formality来自TenantLanguageConfig，也是租户作用域。甚至___DEBLOCK_23__（为提高翻译质量而发送的周边段落，不计费）也来自租户自己的文档。

我想强调的一点是：当设置 style_id 时，DeepL 会自动使用他们的 quality_optimized 模型。您不能将样式规则与 latency_optimized 结合使用。这是一个 DeepL 限制，但说实话是一个合理的限制。如果您要投资自定义样式规则，您可能希望获得最佳的输出质量。

块级缓存：数据库作为翻译记忆库

我们不会调用 DeepL 来处理没有变化的代码块。缓存机制就是 TranslationBlock 表本身。

每个 EntryBlock源都有一个 ContentHash，这是其语义内容的 SHA256 值（去除了 blockId和 deleted等元数据属性）。每个 TranslationBlock都存储了翻译时的 SourceContentHash。当源代码块发生变化时，其哈希值也会发生变化。协调器会比较哈希值，并只对不匹配的区块进行排队。

每个区块的决策树如下所示：

1.哈希值匹配、翻译存在 = 跳过（缓存、最新） 2.哈希值已更改、机器翻译、未锁定 = 自动重新翻译 3.哈希值已更改，人工编辑或锁定 = 标记为过时，不覆盖

第三种情况至关重要。如果您的德语译员对某个段落进行了人工润色，我们不会因为英文来源发生了变化就将其删除。我们会将其标记为 "过期"，以便他们知道需要对其进行审核，但翻译后的文本保持不变。

实际结果是：在 30 个段落的文档中编辑一个段落，只需触发一个 DeepL API 调用（嗯，一个批次，包括一个区块）。所有语言的其他 29 个段落都已缓存，不会产生任何费用。

为什么不对每个租户使用单独的密钥？

我认真考虑过。给每个租户一个自己的 DeepL API 密钥，完全消除隔离问题。

我们没有这么做有三个原因

1.** 计费复杂性。** 每个租户都需要自己的 DeepL 订阅或提供子账户的方法。DeepL 本身不提供多租户密钥管理。 2.共享基础设施意味着共享费率限制和批量折扣。我们的总使用量可获得更优惠的价格。 3. 操作简单。**只需轮换一个密钥，监控一个配额，维护一个集成。

代价是我们需要我所描述的隔离层。但是，鉴于我们已经为系统中的其他一切提供了租户范围的 EF Core 查询，因此将其添加到词汇表和样式规则中就变得简单易行了。模式已经存在。

##真正保护您的是什么

总结一下隔离保证：

词汇表条目**存储在 TenantGlossary（实现 ITenantScoped）中，由 EF Core 全局查询过滤器过滤。DeepL 词汇表 ID 是不透明引用，只能在租户上下文中解析。
样式规则和自定义说明**通过 TenantStyleRuleList_遵循相同的模式。
翻译内容**位于 TranslationBlock中，通过其父 Entry → Hub链进行作用域划分，该链也是租户作用域划分。
SaveChanges防护**会在新实体上自动设置TenantId，并在跨租户写入时抛出。
生产代码中没有 __DEBLOCK_42**。永远不会

设计原则很简单：DeepL 查看资源 ID。Rasepi 看到的是租户范围内的实体。它们之间的映射永远不会跨越租户边界，因为解析映射的查询在物理上无法返回另一个租户的数据。

如果你正在构建一个多租户的 SaaS，并与没有原生租户支持的第三方应用程序接口集成，那么这种模式就能很好地发挥作用。将外部 API 视为无状态执行引擎，将所有配置保存在你自己的租户范围数据库中，懒散地同步，永远不要相信外部资源列表的隔离性。

代币烧毁是新的代码行数

2026-04-13T00:00:00Z

我的 LinkedIn feed 几周来一直充斥着这些术语。我的 X 时间轴上也是。人们像发布进度报告一样发布代币花费截图。创业公司创始人吹嘘他们上个月在克劳德代码上花了 1.6 万美元，下个月的目标是 6 万美元。排行榜。排行榜。代币传奇"、"人工智能之神 "等头衔。

上周，这一切达到了临界点。福布斯》报道了席卷硅谷的 "tokenmaxxing "运动，在这场运动中，各家公司都在比拼谁烧的人工智能代币最多。Jensen Huang 在 "All-In "播客中说道：_"那个 50 万美元的工程师，到了年底，我会问他：'你在代币上花了多少钱？'如果他说'5000 美元'，我就会勃然大怒。如果这位 50 万美元的工程师没有消费至少 25 万美元的代币，我将深感震惊。

随后，《财富》报道一名 Meta 员工建立了一个名为 "Claudeonomics "的内部排行榜，跟踪公司 85000 多名员工的代币消耗情况。排名靠前的用户可以获得头衔。在 30 天的时间里，代币总使用量达到 60 万亿。最高个人用户的平均使用量为 2810 亿。马克-扎克伯格甚至没有进入前 250 名。与此同时，Meta 首席技术官安德鲁-博斯沃思（Andrew Bosworth）公开表示，他最好的工程师用代币支付的薪水相当于他的工资，但运行效率却 "高出 5 到 10 倍"。"这就像，这是很容易赚到的钱，"博斯沃思说。"没有限制"。

我在软件行业工作了很长时间，知道这里发生了什么。这是价格更高的 "代码行"。

我们以前来过这里

2003 年，马丁-福勒（Martin Fowler）写了一篇关于软件生产率为何无法衡量的短文，这或许应该成为每位技术主管的必读文章。他对代码行数的论证非常精确：

"我最恼火的是基于代码行数的生产率研究。任何优秀的开发人员都知道，他们可以在代码行数差异巨大的情况下编写相同的代码"。

只要你大声说出来，问题就显而易见了。LOC 衡量的是活动，而不是产出。两个开发人员可以创建相同的功能：一个写了 1200 行，另一个写了 80 行。简洁的那个人可能构建了一个更好的系统。而在 LOC 制度下，啰嗦的那个看起来更有生产力。

根据 LOC 进行评估的团队做出了理性的回应。他们写了更多行。他们复制粘贴，而不是抽象化。他们避免重构，因为删除代码会损害他们的数据。指标影响了行为，但并不是为了更好的软件。更多的代码。更糟糕的系统。

2023 年，麦肯锡发表了一篇文章，声称已经破解了客观的开发人员生产力衡量标准。Gergely Orosz 和 Kent Beck 的详尽回应指出了同样的缺陷：麦肯锡的几乎所有指标都在衡量努力和产出，而不是结果。肯特-贝克讲述了目睹 Facebook 内部开发人员情绪调查从有用的反馈演变成经理与工程师谈判以获得更高分的过程。这就是激励代理指标的结果。分数提高了。而你真正关心的事情却没有改善。

你以为我们会吸取教训。但我们没有。

∮同样的错误，不同的单位∮

代币大爆炸的诱人逻辑是这样的：代币消耗=人工智能使用率。更多的人工智能使用率 = 团队正在使用人工智能。因此，代币消费高 = 人工智能采用率高 = 好。

这恰恰与衡量代码行数一样有缺陷，只是用的是计费仪表盘而不是提交图。为了对《福布斯》的文章公平起见，Sendbird 的首席执行官约翰-金（John Kim）基本上就是这么说的："我们以前看过这部电影"。他指的是 20 世纪 90 年代和 2000 年代的 LOC 文化。他指出，真正的指标是人工智能生成的代码有多少能真正投入生产。代币支出 "更多的是引发话题"。我同意这一点。当话题启动器被提升为头条关键绩效指标时，问题就来了。

GitHub 的 2024 年开发者调查发现，97% 的企业开发者在工作中使用过人工智能编码工具。不过，真正的组织采用需要明确的政策、工作流程以及与实际业务成果挂钩的可衡量成果。不仅仅是使用。不仅仅是消费。

克劳德代码背后的工程师鲍里斯-切尔尼（Boris Cherny）公开分享说，他在一个月的工作中根本没有打开过集成开发环境，用 Opus 4.5 编写了大约 200 份 PR。这令人印象深刻。但让人印象深刻的不是这 200 个 PR 消耗了多少代币。而是它们是 200 个真正的合并贡献，其另一端是可运行的软件。

价值在于结果。代币只是让你达到目的的能量，仅此而已。

当指标成为目标

有一条原则叫古德哈特定律：当度量变成目标时，它就不再是好的度量了。软件开发的历史基本上就是古德哈特定律的博物馆。

将追踪代币作为人工智能采用的关键绩效指标，也会产生完全相同的动力。以代币消耗量为衡量标准的工程团队将消耗更多的代币。这就是激励机制的作用。想要看起来更有生产力？多运行几个代理循环。在生成输出之前，让模型进行详细推理。将每项任务都包裹在一个协调层中，调用四个工具就能完成的任务。代币花费会增加。交付的价值却不会增加。

实际上，Claudeonomics 的故事几乎立即证明了这一点。财富》杂志指出，"一些员工让人工智能代理工作数小时，以最大限度地提高代币使用率"。就是这样。古德哈特定律在一家本应处于人工智能驱动生产力前沿的公司内部得到了实时执行。在排行榜被关闭之前，它可能已经存在了几个星期，员工们已经开始通过循环运行代理来玩弄它。这个指标已经使用了三个星期，但它已经无法衡量它应该衡量的东西。

任何开发人员读到这里，大概都能想到五种夸大令牌使用指标的方法，但对任何人都没有好处。我就不一一列举了。但是，如果我能想到五种，那么被测量的工程师也能想到五种。

Andrej Karpathy 将软件工程的当下描述为该行业的 "9 级地震"。他说得没错。但地震并不能用耗电量来衡量。地震是用移动的东西来衡量的。

这个问题的文档版本

这不仅仅是工程团队的问题。我在知识管理中也看到了同样的动态，而这与我们 Rasepi 的情况更为接近。

"本季度我们发布了 400 份文件"，这个数字在幻灯片中听起来不错。至于这些文件是否准确，是否有人读过，或者其中的信息在六个月后是否仍然真实，这些都与数字无关。你可以通过人工智能，不假思索地得出这个数字。代币辅助噪声大规模发布。

诚实的指标更难收集，但却有用得多：你的知识库有多大比例真正反映了你的系统如今是如何工作的？有多少人通过你的文档找到了正确答案？有多少人尝试过，但失败了，最后还是去问 Slack 上的人？

这些问题还没有漂亮的仪表盘。这些问题还没有漂亮的仪表盘，它们需要实际思考你希望文档为你的组织做些什么。(无独有偶，这也正是 Rasepi 的问题所在。强制过期日期的存在，正是为了让团队必须考虑内容是否仍然有效，而不是让它在高页数指标背后默默衰减）。

##应该追踪什么

"我们的人工智能投资是否有回报？"这个问题的真实答案无法从计费仪表盘上读出。

你可以用更好的问题来概括：周期时间是否有所改善？功能交付与错误报告的比例是否朝着正确的方向发展？工程师们是否报告说，他们花在判断力强的工作上的时间多了，而花在打字上的时间少了？您的文档是否与时俱进，而不是像泥沙一样堆积如山？

从应用程序接口中提取这些信息比较困难。这就需要思考你究竟希望你的团队取得什么样的成果，诚然，这是最困难的工作。但这些问题才是最重要的，因为它们涉及的是结果而不是投入。

代币支出告诉你买了多少计算。至于这些计算是否变成了有用的东西，则是完全不同的问题。如果公司不加以区分，就会建立非常昂贵的仪表盘，而这些仪表盘几乎什么也显示不出来。

我们花了数年时间优化错误的开发人员生产力指标。在企业的每份人工智能应用报告中都出现同样的错误之前，我们或许还有一个季度的时间。避免这种情况的窗口已经打开，但不会一直这样下去。

人工智能鸿沟正在将您的团队一分为二

2026-04-10T00:00:00Z

上周，我和一位朋友通了一次电话，他向我介绍了他们的一个客户--一家物流公司。那里的一位团队领导在一次计划会议上，她的两个同事在会议开始前就用人工智能建立了一个完整的情景模式。预测、风险分解、三种备选方法。团队中的另外四个人则带着他们已经用了两年的幻灯片格式出席会议。同样的结构、同样的手动流程、同样的时间估算。

会议迅速陷入僵局。人工智能辅助的两人不明白为什么其他人没有做 "现在只需要五分钟 "的基本准备工作。其他人感觉被埋伏了，好像游戏规则变了，却没人告诉他们。团队负责人花了一天的时间来进行损害控制。

这个故事已经不再让我感到惊讶了。几个月来，我一直在听这个故事。

现在差距是可以衡量的

这不仅仅是感觉。微软的2025工作趋势指数对31个国家的31000名员工进行了调查，发现67%的领导者熟悉人工智能代理，而员工中只有40%。领导者更倾向于将人工智能视为职业生涯的加速器（79%，而员工仅为 67%），而且他们还能通过人工智能节省更多时间。近三分之一的领导者表示，人工智能每天能为他们节省一个多小时。

但真正让我印象深刻的是：当被问及如何看待人工智能时，52% 的受访者表示，他们将其视为一种基于命令的工具。给它一个指令，得到一个结果。只有 46% 的受访者将其描述为思想伙伴，即与你有来往的东西。

这可不是一个小差别。这是同一种技术的两种根本不同的关系。而这两组人正坐在同样的会议上，为同样的项目工作，理应朝着同一个方向前进。

两种速度，一个团队

实际后果是，团队现在以两种完全不同的速度运作。将人工智能融入日常工作的人，不仅生产速度更快。他们的思维方式不同。他们处理问题的方式也不同。他们在参加会议时，只需一个下午就能完成过去需要一周的工作。

而那些还没有采用人工智能的人（或者尝试过一次，觉得效果不佳，就放弃了）则在做着真正扎实的工作。这一点我想说清楚。这并不是说他们的工作不好。而是可能的上限发生了变化，而他们正在旧的上限下工作。

一项哈佛大学关于团队中生成式人工智能的研究发现了一个显著的现象：使用人工智能的单个个体胜过没有使用人工智能的整个团队。但在一个团队中，每个人都使用人工智能，那么这个团队的表现就会胜过他们所有人。这意味着什么？混合采用不会给你带来中间地带。它只会带来摩擦。

我在上个月举办的一次研讨会上亲眼目睹了这一点。那些经常使用人工智能的学员只用了一半的时间就完成了练习，然后在等待剩下的练习时感到非常沮丧。而不使用人工智能的学员则感到仓促，老实说，还有点丢脸。没有人想要这样的结果。只是因为现在的速度差距太大了。

无人提及的竞争优势

这才是真正有意义的地方。麦肯锡的2025 年人工智能现状调查发现，88% 的组织至少在一项职能中使用了人工智能。听起来不错吧？但近三分之二的组织仍停留在实验和试点阶段。只有约三分之一的企业开始在其业务中推广人工智能。而那些已经扩大规模的公司，也就是麦肯锡所说的 "绩优公司 "呢？它们约占受访者的 6%。

我认为大多数人都低估了这 6% 的速度。

绩优企业围绕人工智能从根本上重新设计工作流程的可能性是其他企业的三倍。他们的高层领导积极倡导并以身作则使用人工智能的可能性要高出三倍。他们中有四分之三的人正在或已经在整个组织内推广人工智能，而其他人只有三分之一。

微软的数据也讲述了类似的故事。被微软称为 "前沿企业 "的公司（那些在全组织范围内部署了人工智能并已达到较高成熟度的公司）报告了截然不同的结果。71%的 "前沿企业 "领导者表示他们的公司正在蓬勃发展，而全球只有39%的员工这么认为。55%的人说他们可以承担更多的工作，而全球只有 25%。他们不太害怕人工智能抢走他们的工作，而不是更害怕。

这些公司与其他公司之间的差距并没有缩小。而是在加速。

这是一个伪装成技术问题的人的问题

用工具来解决这个问题很有诱惑力。推出 Copilot，购买一些许可证，向全公司发送有关人工智能资源的电子邮件。完成。

但实际的挑战在于文化。在电话中，团队领导者要努力把一半人团结起来，而另一半人则觉得自己被抛弃了。经理必须向一位工作了 20 年的老员工解释，他们十多年来完善的工作流程可能不再是最好的方法。基层员工悄悄使用人工智能完成高级工作，却不知道是该感到自豪，还是该担心政治后果。

微软发现，47% 的领导者将提升现有员工的技能列为首要劳动力战略。我想这是令人鼓舞的。但只有当人们真正愿意学习时，技能提升才会奏效。而现在，有相当一部分员工认为，人工智能要么与他们无关，要么不可靠，要么不值得付出努力。他们中的一些人对特定工具的看法可能是对的。但从更广泛的轨迹来看，人工智能并非可有可无（多年来，我对很多科技炒作周期都持怀疑态度，但这次感觉不同）。

何去何从

我不认为鸿沟会消失。我认为它会扩大。采用人工智能的人会越来越快，产量越来越高，不断提高 "正常产量 "的标准。而不采用人工智能的人则会感到越来越大的压力，无论是来自管理层、同行，还是来自周围的现实，即他们的同事正在做他们做不到的事情。

如果公司能够想办法带动整个团队，而不仅仅是热衷于此的人，那么它就会拥有真正的优势。而且这种优势还会不断扩大。组织人工智能流畅度每提高一个月，你的竞争对手就会多花一个月时间争论是否要购买 ChatGPT 许可证。

人工智能时代最大的竞争优势将不是你使用哪种模型。而是你的整个团队是否真正使用它。

我提到的那个物流团队？我的朋友告诉我，团队负责人预订了一个为期两天的内部研讨会。不是 "这里是如何提示"。更像是 "这将如何改变我们共同计划的方式"。持怀疑态度的人需要看到在他们的工作背景下可能发生的事情，而不是在一些编造场景的通用演示中。热心人需要学会耐心。带着大家一起前进，而不是一味地往前冲。

这感觉就像现在的工作。不仅仅是采用人工智能。缩小差距。在它把你逼入绝境之前。

重新想象构建与购买：2026 年的实际意义

2026-04-07T00:00:00Z

上周，我亲眼目睹了我们团队的一名初级开发人员在 90 分钟内开发出了一个可以正常运行的 CRUD 应用程序，其中包含认证、数据库迁移和半成品用户界面。使用的是 Copilot。从零开始。

五年前，同样的任务需要一周的时间。如果算上部署配置和 OAuth 流程，可能需要两周。而这种转变，将构建时间从几天压缩到几小时，正在悄然瓦解软件领域最古老的问题之一：我们应该构建还是购买？

旧框架已死

几十年来，"构建还是购买 "一直是一个成本计算问题。你会估算构建一个东西需要多少个开发月，乘以加载的工资，再加上一些维护的缓冲，然后与做大致相同事情的 SaaS 产品的年许可费进行比较。如果 SaaS 便宜，你就买。如果你的要求足够奇怪，你就构建。

这种框架假定构建是昂贵的。的确如此。但是，根据GitHub的Octoverse 2025数据，人工智能辅助开发现在使吞吐量提高了20%到30%。GitHub上80%的新开发者在第一周内就使用了Copilot。超过 110 万个公共软件源已经集成了 LLM SDK。几乎在一夜之间，构建成本大幅降低。

因此，问题不再是 "构建还是购买"。它更像是：当你购买 SaaS 时，你究竟为什么买单？

新计算

我认为大多数 SaaS 创始人（包括我自己，说实话）都不想听到这样的话：如果你的整个价值主张是 "我们帮你免于构建"，那你就有麻烦了。因为护城河变浅了。

如果一个团队可以在一天内完成一个功能性内部工具的原型，那么包月的标准就会大大提高。你不仅要比他们做得更好。你需要比他们在人工智能的帮助下所能构建的更好。

Gartner在2026年4月预测，到2028年，一半以上的企业将停止为辅助智能付费，转而青睐致力于工作流结果的平台。更令人震惊的是：他们预计，到2030年，软件公司如果在传统应用程序上附加人工智能，而不是为代理执行而重新设计，将面临高达80%的利润压缩。

80%。这可不是四舍五入的误差。

那么，什么才能真正存活下来？

我一直在思考这个问题，部分原因是我们正在构建 Rasepi，我需要诚实地面对自己，了解我们的价值所在。我认为答案可以归结为三点，无论你的人工智能助手有多优秀，这三点都很难在周末的编码冲刺中复制。

**任何人都可以创建一个文本编辑器。建立一个翻译系统，跟踪段落级别的内容变化，通过内容散列检测陈旧的翻译，并处理跨语言的结构调整？这需要在架构中融入多年的领域知识。人工智能可以帮助你更快地编写代码，但它不能告诉你应该构建什么。

**还是得有人来运行和维护它。维护？一点都不好玩。处理多租户权限系统中的边缘情况，跟上浏览器的怪异之处，管理跨版本的数据库迁移，在凌晨两点修补 CVE，处理只在 Safari 中出现的 PDF 导出错误。当然，人工智能可以加快初始构建速度。但是，Forrester 2026 年 4 月的研究显示，大多数企业仍无法将人工智能的应用转化为可衡量的影响，部分原因是困难的部分从来不是编写代码。难的是多年来一直保持运行、更新和正常工作。构建是容易的部分。正常运行时间、轮换值班和增量修复才是真正要花费成本的部分。

信任、安全和数据隐私 这一点被低估了。当你自己构建一个东西时，你**拥有安全性。你要负责静态加密、审计日志、渗透测试、GDPR 合规性、SOC 2 以及下一个还没人听说过的法规。一个好的 SaaS 供应商有整个团队，他们唯一的工作就是确保你的数据不会出现在不该出现的地方。对于大多数公司来说，这不是他们想在内部承担的成本。老实说，我见过的大多数内部工具甚至没有适当的访问控制，更不用说安全审计跟踪了。

可组合的中间地带

有趣的是，答案越来越多地不是 "构建 "或"购买"。而是组合。选择那些能很好地完成艰巨任务的 SaaS 工具，提供良好的应用程序接口，并让你围绕它们进行构建。

这就是插件架构现在如此重要的原因（是的，这正是我们对 Rasepi 插件系统的投资）。能够茁壮成长的 SaaS 产品都会这样说："我们处理的是坚硬的、特定领域的核心。你可以定制其他一切"。而不是 "这是我们的单体，要不要随你"。

Forrester 2026 年 4 月的报告发现，大多数企业仍在努力将人工智能的采用转化为可衡量的业务影响。采用率高的企业与咨询合作伙伴合作准备数据和系统的可能性要高出 47%。信息很明确：原始能力建设不是瓶颈。知道要构建什么，并拥有支持它的基础设施，这才是真正的制约因素。

这对 SaaS 意味着什么？

如果你在 2026 年经营一家 SaaS 公司，我认为有几个令人不安的事实：

你的 "我们将为你节省时间 "的宣传比以往任何时候都要薄弱。但当人工智能将构建时间压缩 20-30% 时，你的投资回报率电子表格中的 "节省时间 "数字就会成正比地缩水。你需要一个不同的故事。
**功能是赌注，结果才是产品。**没人在乎你有 47 个集成。他们关心的是文档是否新鲜、翻译是否准确、团队是否真正使用了该工具。Gartner 关于 "注重结果的工作流程 "的说法不仅仅是分析师的行话。它是市场发展的方向。
** 开放性胜过封闭性。** 本能地封闭自己的平台并使转换变得困难是可以理解的。但 Gartner 明确警告说，"试图关闭记录系统的传统 SaaS 供应商有可能被企业更信任的协调层绕过"。哎哟

##诚实版本

我将直言不讳我的观点。自建与购买从来都不是真正的技术问题。它始终与信任有关。我是否相信这个供应商对我的问题有足够深刻的理解，他们的解决方案会比我拼凑出来的更好？

2026 年，"拼凑 "得到了大规模升级。因此，信任度也随之提升。

对于我们 Rasepi 来说，这意味着我们不能只是一个碰巧支持翻译的文档工具。我们必须非常擅长解决各种棘手的问题，如块级翻译跟踪、内容新鲜度强制执行、多租户复杂性等，即使使用世界上最好的人工智能工具，构建替代品也会非常痛苦。

这就是新的构建与购买之争。不是 "你能构建它吗？"而是 "当别人已经解决了困难部分时，你是否应该花费精力去构建它？

这个问题其实与成本无关。问题在于你想把精力花在哪里。在一个建造成本低廉的世界里，注意力是仅存的稀缺资源。

不要因为人工智能的存在而解雇员工

2026-04-04T00:00:00Z

我的一位朋友在一家中型 SaaS 公司负责内容。去年，她的团队有八个人。撰稿人、编辑、本地化专家、知识库负责人。团队不错，产出稳定。后来，首席执行官参加了一个会议，回来后对人工智能大加赞赏，三个月内，团队就只剩下了三个人。理由是什么？有了人工智能工具，三个人就能完成过去八个人的工作量。

从技术上讲，确实如此。剩下的三个人的工作量大致相同。博客文章、帮助文档、产品更新、内部沟通。这些数字在仪表盘上看起来还不错。

但我的朋友已经好几个月没好好睡过觉了。她要在写作、编辑、工程提示、人工智能输出质量保证、翻译管理之间切换，还要做所有过去由整个团队分担的战略工作。她剩下的两位同事也是如此。其中一位已经在找另一份工作了。

公司节省了五份薪水。同时，公司也慢慢失去了三个真正了解工作原理的人。

看似正确实则错误的计算

自从 ChatGPT 成为主流以来，董事会上就一直在讨论这个问题：现在，一个拥有人工智能的人可以完成十个人的工作。既然如此，为什么还要保留十个人呢？

这是一个令人信服的论点。简单。简洁。适合放在幻灯片上。

但也有不完整的危险。

是的，人工智能可以压缩任务。根据微软2024年工作趋势指数，90%的人工智能工作用户表示，这些工具能帮助他们节省时间。微软团队的最大用户在一个月内使用 Copilot 总结了 8 个小时的会议。光是会议总结就节省了整整一个工作日。85%的用户表示，人工智能可以帮助他们专注于最重要的工作。

这些都是真实的数字。生产力的提高并非凭空想象。

但是，"炒掉九个人 "的那群人从来没有提到过：留下的人并不只是吸收产出。他们吸收的是认知负荷、背景、决策、协调、质量保证，以及与这九位前同事一起走出大门的每一点机构知识。

心理负荷不是电子表格

心理学中有一个概念叫认知负荷理论。它描述了在任何给定时间内，工作记忆中所使用的脑力劳动总量。每当你要求一个人完成过去由五个人分担的思考工作时，你并没有节省精力。你是在集中精力。

当人们告诉我人工智能能让工人的工作效率 "提高 10 倍 "时，我经常会想到这一点。提高什么效率？生产更多的文字？出更多票？制作更多的幻灯片？当然，但知识工作中最难的部分从来都不是生产，而是思考。而是思考。决定生产什么。了解背景。做出判断。即使表面看起来正确，也要知道什么时候是错的。

人工智能不会为你做这些。人工智能会给你一个初稿，现在你需要有足够的智慧来评估它，有足够的经验来捕捉细微的错误，有足够的洞察力来注意到输出结果是错误的。(如果你曾经看过有人在没有阅读的情况下就将人工智能生成的内部文档发送出去，你就会明白我的意思）。

盖洛普发布的《2025 年全球职场状况》报告发现，2024 年全球员工敬业度从前年的 23% 降至 21%。这一下降估计会给世界经济造成 4380 亿美元的生产力损失。管理者敬业度的下降幅度更大，从 30% 降至 27%。女性经理人下降了 7 个百分点。35 岁以下的经理人下降了 5 个百分点。

这些人本应领导人工智能的应用。而他们正处于焦头烂额的状态。

放大论证

让我换个角度来思考这个问题。

如果一个拥有人工智能的人可以完成十个人的工作，那么十个拥有人工智能的人就可以完成一百个人的工作。

再读一遍。因为这部分内容几乎无人问津，而这部分内容应该让每一位首席执行官彻夜难眠。不是因为它可怕，而是因为它是一个巨大的机遇，而大多数公司却将其弃之不顾。

那些因为 "人工智能可以胜任 "而裁掉一半员工的公司并不高效。他们目光短浅。他们在优化每季度的员工数量，而他们的竞争对手却在研究，如果把强大的工具交给一个由积极进取、经验丰富的员工组成的完整团队，会发生什么。

上个月，我在苏黎世的一次创业活动中看到了这种情况。同属一个领域的两家公司。规模大致相同，市场也相同。A 公司将内容团队从 12 人减少到 4 人。B 公司保留了全部 12 人，并为他们提供了人工智能工具和培训。猜猜哪家公司正在用六种语言制作多语种内容，试验新的格式，每周向知识库发送产品更新？(不是 A 公司）。

当你裁员时，实际上会发生什么？

让我来介绍一下用一两个 "人工智能增强型 "超级员工取代十人团队的实际情况。

**第一周感觉很好。**剩下的人充满活力。他们有了新工具。他们创造了很多成果。领导非常兴奋。相对于人数，仪表盘上的数字看起来令人难以置信。

**第二个月，裂缝出现了。**负责文档的人发现，人工智能生成的内容需要认真审核。不是简单的编辑。而是深度审核。因为人工智能并不了解产品的细微差别、客户背景，也不知道你上周改动的三件事会导致所写内容的一半失效。光是审核工作就耗掉了因更快生成内容而 "节省 "下来的时间。

第四个月，机构知识差距显现 还记得你解雇的那八个人吗？他们不仅仅是编写内容。他们与产品经理有着良好的关系。他们从多年的支持单模式中了解客户的痛点。他们知道哪些文档主题产生的问题最多。这些知识已经不复存在。人工智能当然也不具备这些知识。

**第六个月，你雇佣了承包商。**因为剩下的人不堪重负，质量下降，终于有人注意到知识库已经有几周没有适当更新了。但承包商也不了解情况，所以你每小时付出更多，结果却更糟。

这可不是我瞎编的。仅去年一年，我就目睹了这种模式在三家不同的公司重演。

数据表明，要留住你的员工（并对他们进行培训）

世界经济论坛 2025 年未来工作报告](https://www.weforum.org/publications/the-future-of-jobs-report-2025/digest/) 向全球 1000 多名雇主询问了他们的劳动力计划。这些数字讲述了一个有趣的故事。是的，40% 的雇主计划在人工智能实现任务自动化的情况下裁员。但85%的雇主计划提高现有员工的技能。70%的雇主希望雇佣掌握新技能的员工，而不是减少员工数量。

报告预计，到2030年，就业岗位将净增7800万个。这还不算9200万被取代的职位。世界并不是在减少工人。而是在向拥有不同技能的工人发展。

这里有一条应该让每一位 "让我们裁员吧 "的首席执行官暂停一下：64%的雇主将支持员工的健康和福利视为人才可用性的关键战略。不是 "降低成本"。不是 "一切自动化"。支持员工身心健康，因为耗尽人力的公司以后就无法再雇佣优秀的员工了。

与此同时，BCG 和哈佛商学院的一项研究发现，当团队使用人工智能执行创意任务时，约 90% 的团队提高了绩效，产出质量比对照组提高了 40%。但是，这项研究也发现了一些应该让每个领导者都感到不安的事情：在人工智能辅助下的团队中，创意的多样性下降了 41%。

想想这意味着什么。你从你的十人团队中解雇了七个人。剩下的三个人使用人工智能完成同样的工作量。但想法、观点和方法的范围却缩小了近一半。你的产出看起来很高产，但逐渐变得千篇一律。没有人注意到这一点，直到竞争对手推出了真正有创意的产品，而你却不明白为什么你的团队没有这样做。

无人预算的精神负担

微软的调查发现，68% 的人对工作节奏和工作量感到吃力，46% 的人感到身心俱疲。而这是在你告诉他们他们现在正在做他们三个前队友的工作之前的状况。

这是生产力仪表盘上没有显示的：作为最后一道防线的认知成本。当只有你一个人审核人工智能的产出时，你就没有休息日。当你是知识库的唯一拥有者时，每个支持问题都会出现在你的办公桌上。当因为团队 "规模适当 "而没有人可以交流想法时，每一个决定都只能由你一个人做出。

我之所以建立 Rasepi，部分原因是我近距离地看到了这个问题。当文档团队缩减时，知识却不会随之缩减。需要存在、保持最新和准确的跨语言内容并不会因为维护人员的减少而减少。相反，它还会增加（顺便说一下，这正是我们正在构建的 Rasepi 所要解决的问题，它具有强制有效日期和块级翻译等功能，能让小型团队真正提高效率，而不是不堪重负）。

但即使是最好的工具，也无法从根本上解决人员配置决策失误的问题。你无法自动消除对人工判断、语境和关怀的需求。你只能让人更有效率。

聪明公司的实际做法

微软数据中最令人印象深刻的是 "人工智能高级用户 "的样子。这些人每天多次使用人工智能，并能节省 30 分钟以上的时间。他们尝试不同方式使用人工智能的可能性高出 68%。他们不只是产生更多的产出。他们会重新设计工作方式。

更重要的是：他们存在于对其进行投资的组织中。人工智能高级用户从其首席执行官那里听到人工智能在工作中的重要性的可能性要高出 61%。他们从领导层那里得到重新思考整个职能的鼓励的可能性要高出 53%。他们获得的是量身定制的培训，而不仅仅是一个 ChatGPT 登录。

换句话说，最有生产力的人工智能员工并不是裁员后的幸存者。他们是得到支持和投入的团队成员。

让我来对比一下我在那些采取 "裁员 "路线的公司看到的情况。他们剩下的员工都不是高级用户。他们是不堪重负的通才，拼命地维持着运转。他们没有时间去尝试人工智能，因为他们忙于使用人工智能来维持生存。他们没有时间重新思考职能，因为职能就是......他们，独自一人，做着一切。

无人提及的知识问题

还有一件事我没听到有人说起它这很奇怪因为它应该是显而易见的

当你解雇经验丰富的知识型员工时，知识也会随之流失。知识不会留在大楼里。它不在维基里。不在人工智能里。它存在于那些建立流程、了解边缘案例、知道哪些客户关心哪些细节的人的脑子里。

你知道，当你拥有强大的人工智能工具，却没有机构知识时，会发生什么吗？你会得到格式精美、自信满满、完全错误的信息。规模化。

上个月，我与一家金融科技公司的文档主管进行了交谈（她不愿意透露姓名，这说明了一些问题）。在他们的团队从六个人裁减到两个人之后，他们开始严重依赖人工智能来维护开发人员的文档。不到四个月，他们就发现支持单激增。文档看起来很好。它们写得很好，表面上是最新的。但是，它们包含了一些只有对产品有深入了解的人才能发现的细微错误。一个 API 参数说明在技术上是正确的，但实际上却具有误导性。迁移指南漏掉了旧团队中每个人都知道的一个步骤。人工智能不可能知道这些细枝末节，因为人工智能不会参加你的团队会议，不会阅读你的 Slack 线程，不会听到咖啡机旁的支持工程师沮丧地说 "哦，那个文档又错了"。

##真正的问题

因此，我认为对话应该围绕以下内容展开。

而不是"现在有了人工智能，我们还能裁掉多少人？"

而是_"当我们把人工智能赋予现有的每个人时，会有什么可能？"_

拥有人工智能工具的十人文档团队不会变得多余。它变成了一个可以用十二种语言而不是两种语言维护内容的团队。这支团队可以通过自动新鲜度检查保持每篇内容的最新性。他们可以尝试新的格式、对帮助内容进行 A/B 测试、构建交互式指南，同时还有时间从战略角度思考客户的实际需求。

有了人工智能，你的十人营销团队就不会变成五个人做同样的工作，承受更大的压力。它变成了十个人，他们可以以以前不可能达到的规模开展个性化营销活动，测试更多的创意变体，更快地应对市场变化，并且仍有足够的认知带宽来提出人工智能不可能产生的真正原创的想法。

这不是成本。这是一项投资，其回报会不断累积。

##最终结果

未来五年的赢家不会是那些砍掉最多脑袋的公司。他们将是那些想出了如何让现有团队真正更有能力的人。

问题不在于一个人能否完成十个人的工作。问题是，当十个人都能完成一百个人的工作时，会发生什么？

如果你是正在阅读这篇文章的领导者，我想问你一件事。在你批准下一轮 "人工智能驱动的重组 "之前，先和上一轮重组后留下来的人谈谈。问问他们做得怎么样。问他们因为没有时间而停止了做什么。问他们有哪些事情正在被遗忘。

然后想象一下，如果他们有一个完整的团队和最好的工具，而不是独自承担重任，他们会取得怎样的成就。

这不是天方夜谭。对于那些愿意投资于员工而不是更换员工的公司来说，这就是未来 12 个月的目标。

读者和写作者的思维模式不同。为什么每种工具都给他们提供相同的用户界面？

2026-04-03T00:00:00Z

现在打开 Confluence，找到您需要阅读的文档。您会看到什么？

工具栏。编辑按钮。评论框页面历史链接满是你不需要的导航的侧边栏。面包屑元数据字段权限指示器整个创作界面都围绕着你来这里阅读的文本。

现在想想你真正想要的是什么：问题的答案、流程的下三个步骤、十分钟后开会前需要参考的政策。

你是来消费的。界面假定你是来创造的。

这几乎是所有文档平台的默认设置。Confluence、Notion、SharePoint、GitBook、Nuclino、Slite。它们都为读者和作者提供了相同的环境。页面就是页面。每个人都能获得相同的视图，或多或少会有一些权限按钮。

这感觉很正常，因为我们从来没有过其他的东西。但这只是一个设计决定，而不是自然法则。而且这是个错误的决定。

读写界面相同会造成认知开销](/zh/blog/img/readers-writers-ui.svg)

阅读和写作不是同一种认知任务

这不是用户界面的偏好。这是大脑工作方式的根本区别。

当你写作时，你处于生成模式。你在构思、组织、决定包含什么、省略什么。你需要工具：格式选项、结构控制、媒体嵌入、元数据字段、版本历史、协作功能。界面应该给你带来力量和灵活性。

阅读时，你处于接受模式。你在扫描、过滤、提取相关内容，并试图继续前进。你需要清晰：简洁的排版、集中的布局、最小的干扰。界面应该让路。

认知心理学对此有一个清晰的框架。认知负荷理论由约翰-斯韦勒（John Sweller）在 20 世纪 80 年代末提出，它将负荷分为内在负荷（材料本身的难度）、外在负荷（学习和整合的努力）和外在负荷（环境中添加的一切无用的东西）。读者可以看到的每一个工具栏、侧边栏和编辑按钮都是无关负荷。它们无助于读者理解内容。它们会主动争夺读者的注意力。

梅尔和莫雷诺（2003 年）](https://doi.org/10.1207/S15326985EP3801_6) 对多媒体学习的研究表明，减少无关元素可以提高理解能力和保留率。他们的连贯性原则很直接：如果文档界面向读者显示编写控件，则在每次页面加载时都违反了这一原则。

**读者不需要看到作者的工具。无论如何显示它们都不是中立的。这对理解是有害的。

##目前的平台如何处理这个问题（它们大多不处理）

让我们看看现有的平台。

Confluence有阅读模式和编辑模式，但阅读模式仍被平台的导航、元数据和页面树所包围。当你不编辑时，编辑工具栏就会消失，但 "这是一个可编辑的维基页面 "这一心理框架却从未完全消失。每个读者都能看到 "编辑 "按钮。页面在低语你可以修改它。

在这方面，Notion的情况更糟。它的核心设计理念是一切都可以编辑。点击任何地方，你就可以打字。这对作家来说很好。但对于那些只想吸收内容而不想担心不小心修改了什么的读者来说，这就糟透了。Notion 自己的模板库就说明了这一点：每个模板都是一个工作区，而不是出版物。

从技术上讲，SharePoint支持用于查看和编辑的不同页面布局，但整体体验仍然是企业内部网。读者感觉自己是在使用企业工具，而不是在阅读一份为理解而优化的文档。

GitBook以其简洁的文档式输出最接近阅读优先的体验。但即使是这样，读者体验也是基于这样一个假设，即读者是一名正在阅读技术文档的开发人员。它不是为普通知识消费者设计的。

这些平台都没有将阅读视为与写作有本质区别的活动。它们将阅读视为隐藏工具栏的写作。

当前工具：一个界面，所有受众](/zh/blog/img/readers-writers-current-tools.svg)

单一界面的代价

这不仅仅是一个美学问题。它的后果是可以衡量的。

信息过载降低理解能力

发表在《消费者研究杂志》上的一项研究](https://doi.org/10.1086/209336) 发现，信息超载会导致决策质量下降，随着无关信息与相关信息的比例增加，这种影响也会增加。文档页面上有可见的编写控件、导航树和元数据字段，这就增加了非编写读者的信息比例。

###上下文切换需要付出实际代价

当一个界面信号说 "你可以编辑这个 "时，它激活的认知框架与 "阅读这个 "是不同的。格洛丽亚-马克（Gloria Mark）在加州大学欧文分校进行的关于注意力和多任务处理的研究发现，在上下文切换之后，平均需要 23 分 15 秒才能完全重新集中注意力。如果读者一时考虑编辑（哪怕是修改错别字），就会被拉出阅读模式。这不是假设。使用过 Notion 的人都知道点击选择文本后不小心开始打字的经历。

读者和作者对相同内容的需求不同

写作者需要看到结构、格式标记、块类型、元数据和协作信号。他们需要完整的机制。

读者需要看到简洁的文本、清晰的层次结构，以及通往所需信息的最快路径。他们需要的是内容，而不是机器。

在同一个界面上为两者提供服务，意味着两者都无法获得针对其实际工作进行优化的体验。

第三种受众：人工智能

这就是问题变得复杂的地方，也是现有平台完全没有准备好的地方。

2026 年的文档有三个不同的消费者，而不是两个：

1.创建和维护内容的撰稿人 2.直观消费内容的读者 3. 3.以编程方式检索、解析和合成内容的人工智能系统

这些受众对相同的底层内容都需要一个基本不同的界面。

写作者需要丰富的编辑工具、协作功能和结构控制。读者需要简洁、重点突出、干扰最少的呈现方式。人工智能需要结构化、机器可解析的输出，并带有明确的元数据：新鲜度信号、分类标签、块级寻址和简洁的语义标记。

正如我们在《建设者，不是开发者》（/blog/builders-not-developers-how-claude-changed-devrel/）一文中所讨论的，人工智能中介已经成为越来越多知识工作者的主要文档消费者。GitHub的2024年开发者调查发现，97%的企业开发者使用过人工智能编码工具。到 2026 年，84% 的开发人员经常使用人工智能工具，41% 的代码都是人工智能生成的。

这些人工智能系统并不关心你的侧边栏或工具栏。它们需要的是干净的数据。而将读者视图与作者视图混为一谈的平台，也是将人工智能可消费表面与人类创作表面混为一谈。这就是一个界面中的三个不匹配。

三个受众，三种不同需求](/zh/blog/img/readers-writers-three-audiences.svg)

##Rasepi 如何分离体验

创建内容和消费内容是不同的活动，因此需要不同的界面。

作者环境

当您在拉塞皮中写作时，您将获得一个完整的写作环境。使用 TipTap 进行富文本编辑、块级控件、翻译状态指示器、过期管理、协作工具、内容结构视图，以及作者创建和维护高质量文档所需的其他一切。

撰稿人看到机器是因为他们需要机器。

读者环境

当读者阅读 Rasepi 文档时，他们看到的是简洁、集中的阅读体验。没有编辑铬。没有工具栏。没有 "您可以修改这个 "的信号。只有内容，以最适合理解和扫描的布局呈现。

读者看不到编辑按钮，因为他们不是来编辑的。他们是来学习知识、遵循流程或寻找答案的。界面尊重这种意图。

人工智能表面

对于人工智能消费者而言，Rasepi 通过结构化的应用程序接口（API）提供带有完整元数据的内容。每个区块都有其新鲜度得分、翻译状态、内容哈希值和分类标签。人工智能系统可以在区块级别查询内容，根据新鲜度进行过滤，排除陈旧或草稿材料，并准确检索所需的结构化数据。

无需刮擦维基页面，也无需寄希望于最好的结果。人工智能获得一个专门设计的界面，就像读者和作者一样。

一个内容层，三个界面

重要的是，我们并没有维护三份内容。这不是我们在【停止维护同一文档的五个副本】（/blog/stop-maintaining-five-copies-of-the-same-document/）一文中讨论过的入职五份副本的问题。

这是一个内容层，以结构化块的形式存储，通过三个不同的视图为三个不同的受众提供优化服务。

撰稿人编辑区块。读者看到的是组装好的、风格化的内容。人工智能查询带有元数据的结构化数据。相同的块。相同的真相来源。为每个消费者提供不同的呈现层。

只有块级架构才能做到这一点。每块内容都是可单独寻址的单元，有自己的元数据。您可以根据用户的需求，以不同的方式呈现这些内容块：

| 受众 | 需求 | 获取 | 内容 |----------|-------|------| | 撰稿人 | 格式、结构、协作、元数据 | 具有块级控制功能的完整撰稿环境 | 读者 | 格式、结构、协作、元数据 | 具有块级控制功能的完整撰稿环境 Reader | 简洁的文本、清晰的层次结构、快速扫描 | 集中阅读视图，无编辑铬 AI | 结构化数据、新鲜度评分、分类 | 具有完整元数据的块级应用程序接口

为什么这比看起来更重要

读到这里，你可能会想："这只是用户界面。对同一事物的不同看法。能有多重要？"

事实证明，它非常重要。

读者的信任

人们会信任那些看起来已经发布的内容。当一个页面看起来像一个任何人都可以编辑的 wiki 时，读者会不自觉地对它打折扣。当同样的内容以简洁、具有出版质量的阅读视图呈现时，它就更有权威性。这并非不合理。这是一个信号，表明有人认真对待了页面展示，这意味着他们也认真对待了内容。

尼尔森-诺曼集团对此进行了广泛的研究。他们的关于内容可信度的研究表明，设计质量和表现形式是用户评估内容可信度所依赖的最强信号之一。杂乱无章的编辑视图会主动削弱所显示内容的可信度。

撰稿人的工作效率

在专用创作环境中工作的写作者不必在 "我是在阅读还是在写作？"之间进行上下文切换。这些工具之所以存在，是因为它们理应存在，而不是因为界面无法确定谁在看它。

人工智能的可靠性

当人工智能系统有了一个带有结构化元数据的专用表面时，它们就能更好地决定检索什么、排除什么。它们可以在将区块纳入答案之前检查新鲜度得分。它们可以尊重分类标签。它们可以根据语言、状态或受众进行过滤。而当人工智能刮取的是为人类读者设计的 HTML 页面时，这些都是不可能实现的。

思维模式的转变

大多数文档平台的基本假设都是页面是单位，每个人都与页面交互。

拉塞皮的假设则不同：拉塞皮的假设则不同：_块是单元，不同的受众通过特制的表面与块进行交互。

这听起来像是一个很小的建筑区别。其实不然。这就是一个偶然向人工智能系统展示内容的工具和一个刻意为人工智能系统服务的工具之间的区别。是碰巧可读的写作环境，还是从头开始设计的阅读体验。一个足够好的界面和三个很棒的界面之间的区别。

文档不再只是写和读。它需要编写、阅读、查询、翻译、评分、分类，并大规模地提供给人工智能系统。单个界面不可能对所有这些进行优化，而假装可以优化的结果就是，维基文档无人问津，人工智能助手从页面中提取答案，而这些页面的设计根本不适合机器使用。

读者和作者处于不同的思维模式中。人工智能则处于完全不同的模式。界面应该反映出这一点。

2026 年的文档现状：定义下一个时代的五大趋势

2026-04-03T00:00:00Z

每隔几个月，我都会抽出一个上午来阅读。不是阅读 Rasepi 代码，也不是阅读 GitHub 上的问题。竞争对手的博客、行业报告、主题演讲公告、开发者调查。只要是上个季度出货的、涉及文档、知识管理或人工智能辅助工作流的内容。

上周我做了这项工作，结果比我预想的更清晰。这并不是因为任何一项公告都具有突破性意义，而是因为有五种不同的趋势正在汇聚在一起，当你把它们排列在一起时，就会非常清晰地描绘出文档平台在未来两年需要做的事情。

以下是我的发现。

1.人工智能现在是主要的阅读者。而不是人类。

GitBook 在他们的 AI 文档数据报告中公布了一个惊人的数字：2025 年，人工智能对文档的阅读量增长超过 500%。百分之五百。这可不是四舍五入的误差。

同时，Stack Overflow 的 2024 年开发人员调查显示，61% 的开发人员每天花 30 分钟以上的时间搜索答案。但他们的搜索方式已经发生了变化。GitHub 自己的调查发现，97% 的企业开发人员使用过人工智能编码工具。到 2026 年，84% 的开发人员每天都会使用人工智能工具，41% 的代码现在都是人工智能生成的。这些人不是在浏览你的维基侧边栏。他们在询问克劳德或 Copilot，而人工智能正在代表他们阅读你的文档。

这其中的含义不言而喻。最常阅读文档的人不再是打开浏览器标签的人。而是一个正在进行检索调用的语言模型。而这个模型没有能力眯着眼睛看一页，然后想 "嗯，这个看起来过时了"。

GitBook 很早就发现了这一点，并通过他们的State of Docs 2026 report和向机器可读格式的推进做出了回应。他们还发布了 skill.md，这是一种专门为人工智能代理构建产品信息的惯例。谷歌更进一步，推出了Gemini API Docs MCP，通过模型上下文协议将编码代理与当前文档连接起来。他们的理由很明确：代理会生成过时的代码，因为它们的训练数据有截止日期。MCP 修正使他们的评估通过率达到 96.3%。

因此，第一个趋势已经确定。人工智能是主要的阅读器。将此作为核心设计约束而非后期添加功能的平台将拥有结构性优势。

2.新鲜度和信任元数据成为必备条件

Anthropic 于 2025 年 12 月采访了 81,000 名克劳德用户，并于 2026 年 3 月公布了调查结果。这是迄今为止对人工智能用户进行的最大规模的定性研究（159 个国家，70 种语言）。最受关注的问题是什么？不可靠。27%的受访者将其列为最担心的问题，其中79%的人有过亲身经历。

这个数字应该会让每个文档团队彻夜难眠。

当人工智能的答案不可靠时，问题并不总是出在模型上。通常情况下，模型只是忠实地再现了它在陈旧文档中发现的内容。模型并没有产生幻觉。你的文档只是出错了，却没有人标注出来。

Stack Overflow 的数据从另一个角度强化了这一点：81%的开发人员预计人工智能将在未来一年中更多地融入他们的代码文档中。如果 81% 的用户正在将文档提供给人工智能，而 27% 的人工智能用户表示不可靠是最大的问题，那么你就遇到了信任问题，这是任何及时的工程设计都无法解决的。解决之道在于源头。

这就是为什么新鲜度元数据很重要。而不是 "最后编辑 "的时间戳（这些时间戳告诉你什么时候有人碰过文件，而不是内容是否仍然准确）。真正的新鲜度：审核状态、链接健康、翻译对齐、读者信号、内容漂移检测。机器可以读取的元数据，并利用这些元数据来决定文件是否可以安全引用。

我一直在回想一个简单的框架。你的文档需要一个信用评分。不是时间戳。而是信用评分。(我们一直在使用 Rasepi 的新鲜度评分系统来实现这一点。）

3.翻译从 "项目 "转向 "管道"

DeepL 在二月份发表了一篇名为"全球企业不能错过的 6 个翻译转型"的文章。他们的论点是：翻译正在成为一项持续运营的挑战，而不是每季度进行一次的批量项目。

这与我所看到的一切不谋而合。

以前的模式很简单。用英语写作。当你有预算时，聘请翻译或通过服务机构进行翻译。翻译回来。上传。完成，直到下次。问题是，当你的产品每周发货，文档不断更新时，"下一次 "来得越来越快。当德文版从审核中返回时，英文源代码已经更改了两次。

DeepL 自己的 Customization Hub现在提供了词汇表、样式规则和格式设置，这很好。但是，如果这些工具不在文档平台上，你就需要管理一个翻译工具链：编辑器、导出、翻译、审核、重新导入、重复。每一步都有可能出现偏差。

Notion 完全没有本地多语言支持。Confluence 通过市场插件提供多语言支持。GitBook于 2025 年 8 月添加了自动翻译功能，这是一个步骤，但它是在页面级别运行的。

真正的转变是从页面级到块级。当你在段落层面跟踪翻译时，你只能重译实际发生变化的内容。一般情况下，40 个段落中可能有两个段落需要编辑。这就减少了 94% 的翻译工作。(这就是 Rasepi 的核心翻译架构，老实说，这也是我最引以为豪的地方。但即使抛开我们不谈，行业的发展方向也是明确的：持续、渐进、嵌入式翻译是未来的发展方向）。

4.人工智能代理需要结构化的内容，而不是维基页面

当 Notion 在二月份发布 Custom Agents时，我就意识到了这一点。在早期访问期间，共创建了 21000 个代理。这些代理可以回答知识库中的问题、路由任务、编制状态报告。仅 Ramp 就有 300 多个代理。

Atlassian 也朝着类似的方向发展。Confluence 中的 Rovo AI从 Atlassian 和第三方应用程序中提取上下文来生成内容。他们的口号是"以团队现有工作为基础，提供语境丰富的高质量内容"。

然后 Anthropic 推出了Claude Code 中的代理团队，多个人工智能代理可自主协调完成复杂任务。Opus 4.6 在 8 针 100 万 MRCR 基准测试中的得分率为 76%（比前一型号的 18.5% 有所提高），这意味着它能真正检索到深埋在海量文档集中的信息，而不会迷失方向。

这三家公司都在开发能消耗文档的代理。它们都没有解决源质量问题。

Notion 的定制代理文档明确承认，当代理读取不受信任的内容时，存在提示注入风险。Atlassian 的 Rovo 会抓取在 Confluence 中找到的任何内容。如果这些内容已经过期三个月，Rovo 也不会知道。无论如何，它都会在此基础上进行构建。

要让代理可靠地工作，它们需要的不仅仅是几页文本。它们需要具有稳定标识符的结构化内容、明确的新鲜度信号、清晰的分类元数据，以及区分 "这是最新的并已审核过的内容 "和 "这是存在的但一年来没人碰过的内容 "的能力。维基页面不具备这些功能。而具有信任元数据的结构化块级内容则能做到这一点。

5.开源和自托管正在卷土重来

最后一条更像是一种有数据支持的直觉，而不是一个单一的公告。

2024 年底，GitBook 将其发布的文档开源，并启动了开源软件基金。他们的理由是：开源项目理应获得免费、高质量的文档工具。但此举也预示着更广泛的意义。

Notion 仅提供云服务。没有自托管选项。Confluence Data Center 存在，但需要许可证。当您的文档平台保存着最敏感的操作知识（事件操作手册、合规程序、架构决策）时，"谁来控制这些数据？"这个问题并不抽象。

Anthropic 在二月份发表的"Claude is a space to think"一文中就信任和商业模式提出了一个有趣的论点。他们的核心主张是：广告激励与真正有用的人工智能助手是不相容的。他们选择了无广告的方式，这样用户就能信任这个工具。

我认为文档平台也有类似之处。如果你的文档系统是封闭源代码的，而且仅限云端，你就无法验证它向人工智能提供了什么。你无法审核新鲜度计算。你无法确保数据在你的掌控之中。对于在知识库之上部署人工智能助手的团队（越来越多的人都在这么做）来说，可审计性非常重要。

这并不是一场关于开源在道德上更优越的论战。闭源产品绝对值得信赖。但当你在内部文档的基础上构建人工智能驱动的工作流程时，检查和验证系统的能力是一个实际的优势。对我们来说，MIT 许可 Rasepi 并不是事后才想到的。它是基于同样的逻辑做出的设计决定：文档基础架构应该是可审计的。

这五大趋势的共同含义

单独来看，每种趋势都是可控的。人工智能会阅读你的文档？好吧，添加一些机器可读的元数据。新鲜度很重要？好，添加审核日期。翻译需要连续性？当然，整合 DeepL。代理需要结构？很好，改进内容模式。主权很重要？很好，提供自托管选项。

但综合来看，它们所描述的平台与大多数团队目前使用的平台有着本质区别。

差距在于架构。这并不是你可以随意添加的五项功能。它们是需要嵌入到基础中的五个假设。内容的存储方式（块级，而非页面级）。如何建立信任模型（新鲜度分数，而非时间戳）。翻译如何进行（增量、嵌入式、按段落）。人工智能代理如何访问内容（带元数据的结构化应用程序接口，而不是页面搜刮）。如何控制数据（开放、可审计、可自托管）。

没有一个成熟的平台是同时围绕这五个方面设计的。有些平台正在逐一添加。GitBook 在人工智能可读性方面进展最快。Notion 正在构建代理基础架构。Atlassian 拥有企业级发行版。

但从一开始就为这五个方面进行设计？这就是在环境发生变化时重新开始的优势。

我意识到自己有失偏颇。我们之所以建立 Rasepi，就是因为我们看到了这些趋势的交汇点，并希望有一个平台能从一开始就考虑到所有这些趋势。块级翻译、强制过期、新鲜度评分、结构化人工智能就绪内容、开源。这是整个项目的论点。

但即使我们不存在，我认为任何对 2026 年第一季度发生的事情的诚实解读都指向同一个方向。文档正在成为基础设施。而基础设施与维基页面有着不同的要求。

最先意识到这一点的团队将不仅仅拥有更好的文档。他们还将拥有更可靠的人工智能代理、更低的翻译成本、更少的合规意外，以及长期保持可信度的知识库。

这就是 2026 年的文档现状。问题不在于这些趋势是否真实存在。而是您的平台是否为这些趋势而设计。

五大趋势。一个架构问题：你的文档平台是为 2026 年设计的，还是仍在为 2016 年的假设服务？

Sources：GitBook AI 文档数据报告、GitBook State of Docs 2026、GitBook skill.md、Google Gemini API Docs MCP、Stack Overflow 2024 开发者调查、GitHub 2024 开发者调查、Index.dev 开发者生产力统计、Anthropic "What 81,000 People Want from AI", Anthropic "Claude is a space to think", Claude Opus 4.6, Notion Custom Agents, Atlassian Rovo in Confluence, DeepL "6 Translation Transformations", DeepL Customization Hub, GitBook open source documentation, GitBook auto-translate..

建设者，而非开发者：克劳德如何改变文档的对象

2026-04-02T00:00:00Z

此时此刻，有人正在某处集成你的 API。他们不在你的文档网站上。他们没有打开你的入门指南。他们从未见过你的互动游乐场或精心设计的侧边栏导航。

他们正坐在 Claude 中。或 Copilot。或光标。他们输入类似于_"使用应用程序路由器将 Stripe 账单 API 与我的 Next.js 应用程序集成"_这样的内容，然后等待工作代码的返回。人工智能代表他们阅读你的文档。它找到了相关的端点，理解了身份验证流程，选择了正确的 SDK 方法，并生成了一个实现。

两周前，在圣加仑举行的 Start Summit 黑客马拉松上，我亲眼目睹了这一切的发生。我与一群计算机科学专业的学生和几位早期初创企业的创始人讨论了他们如何开发新的应用程序接口，他们每个人都描述了同样的工作流程：把问题粘贴到人工智能中，得到代码反馈，再从那里开始迭代。当我问她是否读过文档时，其中一位学生笑了。"我为什么要读？克劳德都帮我读了"。

这个人从未访问过你的网站。他们可能永远都不会访问你的网站。而这正是软件越来越多的构建方式。

核心转变

文档现在有两个根本不同的消费者：阅读文档的人类和代表构建者阅读文档的人工智能助手。大多数文档都是专门为人类优化的。人工智能已经成为主要的阅读者。

这将改变下游的一切：

当人工智能提供过期内容时，构建者无法发现问题。损害无声无息地扩大。
**"开发者 "这个词太狭隘了。**产品经理、设计师和分析师正在通过人工智能助手开发软件，而他们自己往往连一行文档都没读过。
简洁的标记符、自成一体的区块和明确的元数据能让人工智能准确地呈现你的产品。
**格式要求已经分化。**人类读者需要叙述。人工智能中介需要结构化、可解析的规范。你需要为两者服务。

这篇文章的其余部分将阐述我们是如何走到这一步的，这对 DevRel 意味着什么，以及你现在可以做些什么。

无人计划的旅程

长期以来，开发人员关系遵循的是一条众所周知的道路。你编写了全面的文档。出版快速入门指南。在会议上发表演讲。你在 Stack Overflow 上保持存在。你让你的 API 参考可被搜索，让你的 SDK 简明易懂，让你的错误信息很有帮助。

这条路径假定开发人员会阅读你的内容。浏览你的结构。遵循你的步骤。

GitHub 的 2024 年开发人员调查发现，97% 的企业开发人员在某个阶段使用过人工智能编码工具。Stack Overflow 的年度调查显示，76% 的开发人员正在使用或计划使用人工智能工具，其中 62% 的专业人员每天都在积极使用这些工具。到 2026 年，这一数字攀升至 84%，41% 的代码由人工智能生成，51% 的专业开发人员每天都在使用人工智能工具。这些数字不会放缓。

新的旅程看起来有所不同。有人用自然语言描述他们想要什么。人工智能助手会阅读文档，找到相关部分并生成集成。构建者审查输出结果，也许会完善提示，也许会提出后续问题。只需几分钟，无需数小时。

DevRel 团队花费数年时间完善的启动漏斗？它被绕过了。并不是因为它不好。只是切入点变了。

两个消费者，一套文档

现在，文档有两个根本不同的受众。

第一种是人类读者。这个人仍然存在。他们为架构决策、边缘案例调试、合规性审查和概念理解而出现。他们需要的是叙述性的解释、条理清晰的参考资料和清晰的权衡推理。

第二种是人工智能中介。它代表构建者阅读您的文档。它不关心你的侧边栏。它不会欣赏你的视觉设计。它需要的是结构化的、机器可解析的内容：简洁的标记符、一致的格式、明确的规范，它可以毫不含糊地进行推理。

如今，几乎所有的文档网站都只针对第一类受众进行了优化。第二类受众已经成为主流消费者。

杰里米-霍华德（Jeremy Howard）在 2024 年提出 /llms.txt 标准时就发现了这种紧张关系。他的观察非常准确：_"大型语言模型越来越依赖于网站信息，但却面临着一个关键的限制：上下文窗口太小，无法处理大多数网站的全部内容。在_______________________________________________________________________中，一个经过策划的标记符文件可以为人工智能模型提供产品的结构化概述以及最重要资源的链接。FastHTML、Anthropic自己的文档以及不断增长的项目目录现在都提供了这样的文件。

这是一个有用的惯例。但这也是更深层次问题的表象。真正的问题不在于格式。而是大多数文档在设计时从未考虑过机器的使用。

建造者没有偷工减料

看着那些不阅读文档而是提示 Claude 的人，我们很容易得出结论：他们在走捷径。他们并不真正理解代码中发生了什么。他们在某种程度上是低级的开发人员。

这样的对话我已经听过很多次了，所以我知道这通常是错误的。

这些开发者中的许多人都是高级工程师，他们会有意识地提高效率。他们理解代码，只是不想翻阅四页文档来查找实际需要的三行代码。他们已经了解到，人工智能助手提取这些行的速度比他们扫描这些行的速度还要快，所以他们把阅读工作委托给了人工智能助手。(老实说，我自己也是这么做的。我都不记得上一次从头到尾阅读入门指南是什么时候了）。

Anthropic公司在构建模型上下文协议时就意识到了这种模式。现在，克劳德、ChatGPT、VS Code、光标等公司都支持 MCP。它的明确设计目的是让人工智能助手可以进入外部系统，获取上下文，并根据上下文采取行动。规范将其描述为提供_"对数据源、工具和应用程序生态系统的访问，这将增强功能并改善最终用户体验"_。

请仔细阅读。这是基础架构语言，不是便利语言。使用这些工具的构建者并不是在逃避工作。他们正在通过一个新的层进行工作，而无论你是否设计了文档，你的文档都是这个层的一部分。

数字证明了这一点。目前，仅 Claude 一家就处理了每月 250 亿次 API 调用，在 159 个国家/地区拥有 3000 万月活跃用户。70%的财富 100 强公司都在使用 Claude。根据门罗风险投资公司（Menlo Ventures）的一项调查，Anthropic 占据了按模型使用率计算的 32% 的企业人工智能市场份额，领先于 25% 的 OpenAI。汇丰银行（HSBC）的一份研究报告则认为这一比例更高：按人工智能总支出计算，Anthropic 占 40%。这些都不是实验工具。它们是主要的基础设施。

开发者关系是为不同的时代而建立的

如果你的 DevRel 战略是在 2023 年之前设计的，那么它是为开发人员直接阅读文档的世界设计的。这个世界并没有消失，但对于越来越多的构建者来说，这已不再是主要的交互模式。

这就改变了一些长期存在的 DevRel 活动。

**会议演讲：**在开发者大会上进行 45 分钟的演讲，可以吸引几百人的关注。而结构良好的/llms.txt文件和简洁的机器可读文档则能让每一位随时随地向任何人工智能助手询问您的产品的开发人员了解。讲座是一次性活动。机器可读文档是复合型的。我并不是说会议毫无价值（我刚参加完一次会议），但杠杆等式已经发生了变化。

入门指南 经典的五步快速入门教程越来越流于形式。建设者并不按部就班。他们只需描述自己的需求，并期望人工智能能够实现集成。如果应用程序接口以机器友好的格式进行了详细说明，人工智能就能比任何教程更有效地处理入门体验。相反，教程应该成为概念性材料：解释为什么你会选择方法 A 而不是方法 B。但在解释如何取舍方面，人工智能就不那么可靠了。

Stack Overflow. 他们自己的调查数据显示，84%的开发者直接使用技术文档，其中90%依赖于API和SDK包中的文档。但他们访问这些文档的方式越来越多地是通过人工智能层，而不是浏览器标签。Stack Overflow 上仍然存在的问题往往是难题。边缘案例、生产调试、需要细微差别的问题。当然，这些问题很有价值。当然，这些问题很有价值，但已经不再重要。

当人工智能阅读你的文档时，新鲜度变得至关重要

这是大多数团队没有考虑到的部分。

当人类阅读文档页面时，他们可以做出判断。他们可能会注意到截图看起来很旧，或者底部的注释说流程改变了。他们会眯着眼睛看，然后想 "这感觉过时了"。

人工智能助手做不到这些。它能读取文本，将其作为事实进行处理，并满怀信心地生成答案。如果文档中描述的是已过时的端点，人工智能会欣然推荐与之集成。如果文档中提到的基础架构在六个月前已被替换，人工智能会将旧设置描述为当前设置。毫不犹豫。

这里的问题比听起来更糟糕：66%的开发人员已经表示，人工智能工具的最大问题是它们给出的结果 "几乎正确，但又不完全正确"。陈旧的文档直接导致了这个问题。人工智能并没有产生幻觉。它是在忠实地复制过时的内容，而构建者根本无法分辨。

建设者信任人工智能。人工智能相信文档。如果文档是过时的，信任链就会提供一个完全错误的答案。

显然，这一直是个问题。陈旧的内容总是让人感到困惑。但由于人类读者有时可以发现，因此这种损害得到了控制。人工智能中介却做不到。它们通过大规模、权威性地向那些没有理由怀疑的人提供陈旧内容，从而扩大了陈旧内容的影响。

新鲜度不再是一个内容质量问题。对于每一个接触文档的人工智能工作流来说，这都是一个可靠性问题。

##"开发者 "这个词过于狭隘

2026 年的软件开发人员并不都是开发人员。有些人是设计师，他们会提示克劳德构建工作原型。有些是产品经理，他们使用 Cursor 发布内部工具。有些是数据分析师，他们用自然语言描述数据管道，然后让代理进行组装。在 Start Summit 上，有一半的黑客马拉松团队成员没有编程背景，但他们在周末结束时都开发出了可运行的软件。

Ramp就是一个很好的例子。这家金融科技公司的估值从2023年的58亿美元上升到2025年末的320亿美元，年收入一路突破10亿美元。这是历史上发展最快的初创公司之一。他们的方法中有一个被广泛讨论的部分：产品经理直接使用人工智能工具构建功能，而不是在工程积压中等待。Ramp 的项目经理不仅仅是编写规格。他们会发送代码。人工智能负责实现。项目经理负责意图。

这不是捷径。这是一种全新的运营模式，而且其规模之大，让人很难将其视为一种实验。

Anthropic公司自己的内部研究揭示了这一点。当他们调查了 132 名自己的工程师了解他们如何使用 Claude 时，工程师们报告说，他们约有 60% 的工作任务使用 Claude。最常见的用途是什么？调试现有代码、了解代码库的各个部分在做什么，以及实现新功能。工程师们表示，他们倾向于将 "不复杂、不重复、代码质量不重要 "的任务交给 Claude。他们现在使用 Claude 所做的工作中，有 27% 以前根本无法完成。

这就是 Anthropic 自己的团队。建立模型的人将其用作文档阅读器、代码库导航器和初稿生成器。其他人也在做同样的事情，只是用的是你的文档，而不是他们的。

Anthropic 一直有意将其称为 "构建者 "角色。他们的工具不仅是为专业软件工程师设计的，也是为任何能够描述自己想要构建的东西的人设计的。当 Claude 可以通过 MCP 从 Figma 设计中构建一个全栈应用程序时，"开发者 "和 "非开发者 "之间的传统界限就消失了。

这对任何维护文档或关注开发人员体验的人都有实际意义。你的受众不再局限于知道什么是 REST 端点的人。它包括任何人工智能助手可能与你的产品进行交互的人。Ramp 的项目经理会使用你的 API 发布功能吗？他可能永远不会直接阅读您的文档。但他们的人工智能代理绝对会。

这对文档意味着什么

如果文档现在要为人类读者和人工智能中介这两种受众服务，那么它就需要同时为这两种受众服务。听起来很明显。但实际上，几乎没人这么做。

以下是我认为真正重要的内容：

**机器可读格式与人类可读格式并存。**如果你的 API 文档是一个精美的 HTML 页面，而 LLM 不得不对其进行搜刮和解析，那么人工智能的工作就会比它应该做的更辛苦。在提供渲染版本的同时，也要提供原始的 OpenAPI 规范。提供简洁的标记符。无需人工智能解释页面布局即可访问规范。

**人工智能助手不会一页一页地阅读文档。它们会提取相关部分。对于人工智能来说，标题清晰、段落自足、块级语义明确的文档，要比需要阅读整页才能了解上下文的流畅叙述有用得多。

信任机器可以阅读的信号 这份文档上一次审核是什么时候？是否仍然有效？内容是否被标记过？这些信号需要以人工智能可以访问的形式存在，而不仅仅是网页上的视觉提示。新鲜度评分、过期状态、审核日期，这些元数据可以让人工智能决定是否可以安全地将文档用作信息源。

**新鲜度是先决条件，而不是特征。**当人工智能助手根据一个已废弃的端点向构建者提供一个有把握的答案时，所造成的损失比404更严重。构建者会在此基础上进行构建。将其交付使用。然后它就在生产中崩溃了，没人知道原因，直到有人追溯到几个月前就应该更新的文档。人工智能可能参考的每一份文档都需要一种机制来证明它仍然是最新的。(这正是我们构建 Rasepi 所要解决的问题。文件块强制过期，这样陈旧的内容就无法隐藏）。

开始：审核当前文档

如果你读到这里还在想 "好吧，但我周一到底要做什么呢？"那么，以下是你本周可以检查的四件具体事情。

1.通过人工智能测试你的文档。 打开 Claude 或 ChatGPT，让它在现实场景中整合你的产品。不要使用你的内部知识。只需查看人工智能生成的结果。是否正确？是否最新？是否使用了正确的端点、正确的 SDK 版本和正确的认证流程？如果人工智能弄错了，那就是构建者现在得到的结果。

2.检查是否有过时的内容。 挑选五个访问量最大的文档页面，并询问：上次审查是什么时候？它是否仍然描述了产品的当前状态？如果你不能自信地回答这个问题，人工智能也无法回答。对于大多数团队来说，这是最有效的修复方法。

3.提供机器可读格式 如果您没有 /llms.txt文件，请创建一个。如果您的 API 参考只能以渲染 HTML 的形式提供，请导出原始 OpenAPI 规范并使其可访问。如果你的文档使用的 CMS 不能输出干净的标记符，这也是一个值得现在就解决的问题。

4.添加审核日期和新鲜度元数据。 即使是很简单的事情，在内容管理系统中添加last-reviewed字段，为高流量页面设定一个强制审核周期。这将为人类和人工智能提供内容是否可信的信号。像 Rasepi 这样的工具可以通过在区块级别强制过期来实现自动化，但即使是手动流程也聊胜于无。

产品表现方式的悄然转变

这一切还有一个更广泛的结果值得直接说明。

您的文档不再仅仅是开发人员的参考手册。它是人工智能助手用来向世界展示产品的原始资料。当一个开发者向克劳德询问如何使用你的产品时，克劳德的回答会根据它能从你的文档中找到并解析的内容来确定。

文档好，答案就好。过时的、含糊不清的、锁定在模型难以解析的 HTML 中？那就是更差的答案，或者是不正确的答案。就这么简单。

现在，人工智能对产品的回答质量直接代表了开发人员的体验。大多数公司还没有这样做。

在这方面走在前面的团队，如 Stripe、Vercel、Cloudflare 和 Anthropic 本身，都将人工智能的可读性视为头等大事。这是一项基础性要求，决定了文档的编写、结构和维护方式。而不是下一季度的积压项目。

现在，构建者坐在克劳德的办公室里，描述着他们想要构建的东西，期待着几分钟内就能完成代码。他们可能再也不会访问文档网站了。但为他们提供服务的人工智能会。持续不断

该人工智能现在是您最常见的读者。问题是，您的文档是否已经为此做好了准备。

2026 年最佳开发人员体验战略不是会议演讲或快速入门指南。而是要确保人工智能能够正确处理。

本文章参考了公开的研究和产品文档。统计数据来自 GitHub 2024 年开发人员调查、Stack Overflow 2024 年开发人员调查、Index.dev 2026 年开发人员生产力报告、Incremys Claude 统计数据，以及 Fortune 关于 Anthropic 的报道。/llms.txt规范由llmstxt.org维护。模型上下文协议在 modelcontextprotocol.io. 进行了记录。

翻译引擎内部：词汇表、风格规则和智能重译

2026-03-31T00:00:00Z

我们的[上一篇架构文章]（/en/blog/how-plugin-guardrail-and-pipeline-systems-work/）介绍了插件、动作保护和管道系统。这篇文章深入探讨了翻译引擎，我认为它是 Rasepi 与其他文档平台的根本区别所在。

这不是关于翻译段落而非页面的营销宣传。而是实际代码。每个租户的词汇表是如何解析的，DeepL 的样式规则和自定义指令是如何塑造每次翻译的，内容散列是如何驱动陈旧检测的，以及协调器是如何决定哪些区块需要重新翻译的。

翻译引擎：词汇表、样式规则和智能重译](/zh/blog/img/translation-engine-deep-dive.svg)

翻译流水线

当用户保存文档时，系统不会简单地重新翻译所有内容。它会运行一个相当特定的序列：

1.将 TipTap JSON 解析为单个块 2.比较内容哈希值，检测哪些区块发生了实际变化 3.对于已更改的区块，解析租户的术语表和语言对的样式规则列表 4.应用租户配置中的样式规则、自定义说明和格式 5. 5.仅向 DeepL 发送已更改的块 6.更新翻译块并同步内容哈希值

每个步骤都有自己的服务和接口。这一点很重要，因为任何一个步骤都可以换成其他东西，不同的翻译提供商、不同的哈希算法、不同的词汇表来源。

词汇表解析：租户范围、DeepL 同步

DeepL 词汇表有一个大多数人不知道的限制：** 它们是不可变的。** 您无法编辑 DeepL 词汇表。任何更改都意味着删除旧的词汇表并创建新的词汇表。

Rasepi 将数据库视为真理之源，将 DeepL 词汇表视为可丢弃的运行时工件。TenantGlossary 实体在本地存储所有内容：

代码块_0_

当用户添加词汇表条目时，例如将 EN→DE 的 "Sprint Review "映射为 "Sprint-Überprüfung"，数据库记录会立即更新，IsDirty会被设置为 true。DeepL 词汇表不会在此时重新创建。它会在下一次翻译实际需要它时被懒散地重新创建。

同步流程

在每次翻译调用之前，系统都会解析词汇表：

代码块_1__

这里有三点值得注意：

1.**我们只在真正需要翻译时才调用 DeepL API。批量编辑词汇表条目不会触发数十次 API 调用。 2.2. 租户隔离。 查询通过 EF 全局查询过滤器运行，因此 TenantGlossaries 会被自动范围化。租户 A 的词汇表条目绝不会泄漏到租户 B 的翻译中。 3.每对语言只使用一个词汇表。 DeepL 会强制执行这一规定。一个 EN→DE 词汇表，一个 EN→FR 词汇表，以此类推。每个租户的 (SourceLanguage, TargetLanguage) 对是唯一的。

词汇表条目

单个词条只是术语映射：

代码块_2___

API 提供完整的 CRUD 和 CSV 导入/导出功能，以便进行批量管理：

代码块_3_

CSV 导入对于从现有翻译记忆库系统迁移的团队来说非常有用。导出术语、清理术语、导入 Rasepi，下一次翻译运行就会自动使用新的术语表。

风格规则、自定义说明和正式性

词汇表处理术语。但术语只是其中的一半。翻译可以使用所有正确的词汇，但听起来仍然是错误的。错误的语气、错误的日期格式、错误的标点习惯。

DeepL 的 ** 样式规则 API** (v3) 解决了这个问题。您可以创建可重复使用的样式规则列表，将两种类型的控件结合起来：

1.** 配置规则**，预定义的日期、时间、标点符号、数字等格式约定 2.自定义说明，自由文本指令，可塑造语气、措辞和特定领域的惯例

Rasepi 为每个租户、每种目标语言创建并管理这些指令。TenantStyleRuleList 实体存储 DeepL style_id，以及租户配置的规则和自定义指令：

代码块_4_

创建样式规则列表

当管理员为德语设置翻译规则时，Rasepi 会调用 DeepL 的 v3 API 创建样式规则列表。如下所示

codeblock_5

与词汇表不同，DeepL 样式规则列表是可变的。您可以使用 ______________________________________________________________________替换已配置的规则，也可以单独添加、更新或删除自定义指令。这对于迭代改进来说要友好得多。

配置的规则看起来像什么

配置规则涵盖了因语言或公司偏好而异的格式约定。比如

codeblock_6

这些规则听起来很琐碎，但复合起来却很快。一份使用 AM/PM 时间格式和以句号分隔的小数点的德文文档，对于德文读者来说只是 "从英文翻译过来的"。为所有德语翻译的小数分隔符设置 use_24_hour_clock 和 use_comma_，可以立即消除这种情况。

自定义指令：这才是真正的力量

自定义指令是自由文本指令，每个样式规则列表最多 200 条，每条指令最多 300 个字符。基本上，您可以用简洁的语言告诉 DeepL 如何塑造翻译：

codeblock_7

来自我们租户的真实例子：

"Always use 'Sie' form, never 'du'" 适用于一家德国律师事务所
__DEBLOCK_28___用于需要根据上下文处理的术语，而非简单的词汇表映射
___DEBLOCK_29____用于英国公司的英语变体之间的翻译

自定义指令对于不适合放在词汇表条目中的特定领域惯例来说非常强大。词汇表将一个术语映射到另一个术语。自定义指令可以说 "翻译 API 文档时，使用命令式语气而不是被动语态"。这是一种完全不同的控制方式。

形式

DeepL 的 formality 参数（default, more, less, prefer_more, prefer_less）仍可作为单独的控件与样式规则一起使用。德语 "du "与 "Sie"、法语 "tu "与 "vous"、日语礼貌等级。这些都是通过TenantLanguageConfig_为每种租户语言设置的：

代码块_8__

格式、风格规则和词汇表都是一个整体。一次翻译调用可包含所有三项内容：

代码块 9

这里有两点值得注意：

1.**我们将相邻的代码块作为上下文传递，以提高翻译质量。DeepL 使用它来解决歧义问题，但不翻译或计费。一个关于 "单元格 "的段落，当周围的上下文是生物文档和电子表格手册时，翻译效果就会不同。 2.**任何带有 style_id 或 custom_instructions 的请求都会自动使用 DeepL 的 quality_optimized 模型。这是最高质量层。您不能将它们与 latency_optimized 结合使用，这是 DeepL 故意作出的限制。风格定制需要完整的模型。

###为什么这比你想象的更重要

想象一下，一家公司在用德语编写内部文档时使用非正式的 "du"，而在翻译部分突然改用正式的 "Sie"。说得好听点是不一致，说得难听点就是不专业。正规性可以解决这个问题。但是，如果您的德国办公室使用 24 小时制，而您的文档却使用 AM/PM 时间戳，或者将货币符号放在数字前而不是数字后，那么仅凭正式性是无法解决这个问题的。

所有这些叠加在一起（样式规则、自定义说明、格式化、词汇表）产生的译文读起来就像你团队中的某个人写的一样。而不是从一台不知道贵公司存在的机器上输出。

DeepL 服务层

所有 DeepL 通信都要通过 IDeepLService。它封装了官方 DeepL .NET SDK，并处理样式规则的 v3 API 调用：

代码块_10_

实现处理语言代码规范化。DeepL 需要 EN-US 或 EN-GB，而不是简单的 en，还需要 PT-PT 或 PT-BR，而不是 pt：

代码块_11_

批量翻译使用 50 个项目的分块，以保持在 DeepL 的 API 限制范围内，同时最大限度地提高吞吐量：

codeblock_12

由于我们只发送陈旧的分块，而不是整个文档，因此单个编辑的典型翻译批次只包含 1-3 个分块，而不是 40 多个。这就是成本降低 94% 的原因所在。

翻译协调器

当源文件发生变化时，TranslationOrchestrator_ 会决定如何处理每个区块。让我们来看看决策树：

代码块_13__

关键点**如果译员手动调整了一个语块，可能是添加了文化背景或重新措辞以求清晰，系统会尊重译员的工作。系统会将区块标记为 "过期"，以便译员知道源代码发生了变化，但不会默默替换他们的编辑。

启用 AlwaysTranslate 的机器翻译区块会被立即重译。使用 TranslateOnFirstVisit 的机器翻译块会被标记为过时，并在有人实际打开该语言文档时进行翻译。

翻译触发器：翻译何时发生

每种语言都有一个 _DEBLOCK_53，用于控制时间：

codeblock_14

AlwaysTranslate_适用于需要立即翻译的高优先级语言。法语适用于在巴黎设有大型办事处的公司。德语适用于总部设在慕尼黑的公司。

_CODEBLOCK_55__适用于偶尔需要但不值得花费 API 成本使其始终保持完全最新的语言。当有人用该语言打开文档时，过时的语块会被即时翻译。

这两种模式使用相同的词汇表分辨率、相同的格式设置和相同的内容散列。唯一的区别在于时间。

独特的内容和结构适应性

这就是架构的真正价值所在，而不仅仅是翻译。

当德语翻译人员添加英语中不存在的 DSGVO 合规性部分时，他们会将其作为一个新块添加到德语版本中。系统从未将其发送给重新翻译，因为没有翻译源。它只存在于德语版中。

当日语翻译人员将项目列表改为编号列表时（这是日语技术写作中的一种常见习惯），该语块的 IsStructureAdapted 标记会在未来的重译周期中保留下来：

代码块_15_

IsNoTranslate 标志用于处理应逐字复制的内容：代码块、URL、产品名称、数学符号。翻译提供程序会完全跳过这些内容。

将所有内容放在一起

让我们来看看整个流程。伦敦的一位用户编辑了英文源文档中的一个段落，而慕尼黑办公室将德语设置为 _____________________________________________：

1.用户保存 TipTap 发送 JSON 到 API。 2.**CreateBlocksFromDocumentAsync 解析 JSON，重新计算内容哈希值，并比较新旧哈希值，以确定哪些区块实际发生了更改。 3.**找到德语 EntryTranslation，检查德语区块。它是机器翻译的，没有锁定，也未经人工编辑，因此符合重译条件。 4.**通过 GetOrSyncDeepLGlossaryIdAsync("en", "de") 解决词汇 ID 问题，通过 GetOrSyncStyleRuleListAsync("de") 解决样式规则问题，将格式设置为 "more"（正式名称为 "Sie"），将相邻区块作为上下文进行消歧。 5.DeepL call. 发送包含词汇表 ID、样式 ID、格式和上下文的单个块。 6.**存储翻译内容，同步 SourceContentHash，状态设置为 UpToDate。翻译了一个区块，而不是 40 多个。其余 39 个区块呢？没动。

与此同时，东京办公室的日语设置为 TranslateOnFirstVisit_。同样的编辑将日语翻译块标记为 Stale。当东京的某个人打开文档时，第 5-9 步会自动执行。它们的结构调整（编号列表）被保留下来。它们的独特块会保持原样。

我认为翻译引擎是 Rasepi 中最能体现价值的部分。翻译使用您的术语，遵循您的格式约定，遵从您的自定义指令，符合您的语气，尊重您的译员的工作，而且成本仅为全文重译的一小部分。该架构可自动完成所有这些工作，并在人类想要接手时不插手。

支持书面翻译的 DeepL 引擎同样支持 Talk to Docs（我们的对话式文档界面），DeepL Voice 负责口语交互。同样的词汇表、同样的风格规则、同样的形式、同样的一致性。无论您的团队是阅读文档还是与文档对话，语言质量都是相同的。

探索翻译 API →

与文档对话比阅读它们更有意义

2026-03-10T00:00:00Z

当事情比较复杂时，人们会说_"让我们来讨论一下"_，这是有原因的。

当我们试图理解一个新想法、解决一个问题或在压力下回忆一个过程时，对话往往比阅读更容易。这并不是因为阅读不好。阅读是人类发展至今最强大的工具之一。但阅读是一种学习技能，它的基础是更古老的语言。

早在阅读之前，我们就已经会说话了。

这一点比人们意识到的更为重要，尤其是现在，世界上更多的知识都存在于文档、维基、PDF 和冗长的内部页面中，除非万不得已，否则没人愿意打开它们。

阅读是学来的。对话是天生的。

人类在写下任何东西之前，已经说了很长时间的话。儿童自然而然地学会理解口语。阅读则需要明确的指导、反复的练习和多年的实践。

即使是识字率很高的成年人，阅读仍然比听或说更需要深思熟虑。它要求视觉集中、持续关注、工作记忆以及对页面结构的解读。你要解码符号、解析句子、建立上下文，并决定什么是重要的。

对话的工作方式则不同。当信息以口语、互动的形式传递时，大脑会获得不同的体验：

它给人的感觉是连续的，而不是视觉上的压倒性
它能提供即时反馈和说明
减少了扫描和过滤大段文字的需要
它反映了人们在现实生活中寻求帮助的方式

最后一点非常重要。在不确定的情况下，大多数人不会本能地想要阅读 1500 字的内容。他们想问：_"接下来我该怎么做？

交谈降低认知摩擦

文件是静态的。它一次性包含所有内容。

这听起来很有用，而且经常如此。但它也会产生摩擦。满页的标题、提示、链接、注释、示例和边缘案例迫使读者决定忽略哪些内容。这在认知上是很昂贵的。

当你与信息系统交谈时，通常会得到相反的体验：相关性第一，细节第二。

你只问一个问题。得到一个答案。然后再追问。

这种互动模式在几个重要方面减少了心理开销：

1.缩小问题空间

一份完整的文档展示了整个情况。一次对话展示下一个有用的步骤。

当有人问_"我怎样才能让新工程师入职？"_时，他们通常不会立即想要整个手册。他们需要的是指导。对话可以让他们从小处入手，只在需要时才扩展。

2.保留工作记忆

阅读要求你在寻找相关部分的同时在脑子里记住多方面的内容。而口语或对话交互则将这种努力外部化。系统会为你做更多的筛选工作。

3.社会熟悉感

人类深深地适应了来来回回的交流。我们问。有人回答。我们完善。他们澄清。这种循环是我们最古老的学习方式之一。

即使 "有人 "是一个系统，这种结构仍然让人感觉自然。

阅读不是被动的。这正是问题所在。

说话让人感觉轻松的一个原因是，阅读并不像人们想象的那样毫不费力。熟练的阅读者会让阅读看起来毫不费力，但阅读过程却是非常主动的。

要想读得好，你必须

识别结构
推断重要性
消除歧义
记住上下文
将一个章节与另一个章节联系起来
决定何时略读，何时慢读

这才是真正的认知工作。

在很多情况下，这种工作是值得的。深层阅读有助于细微差别、精确性和长篇理解。但在其他情况下，尤其是当一个人感到疲惫、压力过大、负担过重或只是想摆脱困境时，交谈往往是精神上更轻松的选择。

在工作场所尤其如此，因为人们通常不是在理想状态下处理文件的。他们是

任务进行中
中断
情境切换
试图快速解决问题
往往已略显沮丧

在这种状态下，以对话方式获取信息会比以页面优先方式获取信息感觉好得多。

##说话改变了与信息的关系

这里还有一个情感维度。

文件会让人感觉正式而疏远。它们意味着对于参考资料来说，这可能很有用，但也可能让人犹豫不决。

对话给人一种放任的感觉。你可以含糊其辞。你可以问得不好。你可以承认困惑。你可以说_"我真的不知道我在找什么，但我需要关于访问请求的东西"_。

这很重要，因为人们经常回避文件，不是因为他们不喜欢信息，而是因为他们不喜欢在寻找信息的正确部分时所付出的努力和不确定性。

交谈可以减少这种障碍。

为什么这很重要

在很长一段时间里，人们必须阅读文档，因为没有其他切实可行的选择。搜索帮助人们找到页面，但并没有改变交互模式。你仍然需要打开页面、扫描并提取所需内容。

这种情况正在改变。

随着界面变得更加对话化，人们越来越期待信息能够做出回应，而不仅仅是存在。他们希望用通俗易懂的语言询问所需的信息，并获得符合当下需要的信息。

这并不会使阅读过时。它只是改变了阅读的角色。

阅读成为深层。对话则成为访问层。

最好的系统将同时支持这两种功能：

在需要定位或速度时进行对话
需要深度、验证或完整上下文时进行阅读

过度简化的风险

有一个重要的注意事项：只有在答案可靠的情况下，与信息交谈才会感觉更好。

如果对话界面给出的答案片面、误导或过于自信，那么这种体验就会比阅读更糟糕，因为它剥夺了用户直接查看源材料的能力。

因此，未来不是 "用语音取代所有文档"。未来是让人们以更人性化的方式访问文档，同时又不失去书面知识所提供的深度和精确性。

这种平衡很重要。对话更容易，但文件仍具有组织所需的持久结构、细节和责任。

更人性化的知识界面

更深层次的观点很简单：人们不会自然而然地用书页来思考。他们用问题、故事、片段和对话来思考。

我们问

这意味着什么？
我首先要做什么？
重要的部分是什么？
你能换个说法吗？
有什么变化？

这些是对话动作，不是阅读动作。

因此，当与信息对话感觉比阅读信息更容易时，这并不是智力懒惰的表现。这通常是一种迹象，表明界面与大脑喜欢接近不确定性的方式相匹配。

阅读仍然必不可少。但作为知识的切入点，交谈往往感觉更好，因为它更接近我们的天性。

我们首先不是读者。我们首先是交谈者。最直观的知识系统会记住这一点。

为另一个时代构建的文档平台

2026-03-08T00:00:00Z

Confluence 和 Notion 并不是糟糕的产品。这一点需要在一开始就说清楚。

它们成功的原因是充分的。Confluence成为许多公司内部文档的默认归属，因为它为团队提供了一个集中的地方来编写、组织和分享知识。Notion以其灵活性、更简洁的写作体验和更现代的产品外观赢得了人们的青睐](https://www.notion.com/about)。

这两个平台都解决了它们所处时代的实际问题。

现在的问题是，周围世界的变化比它们的基础变化得更快。

我们不再是一个只需要编写、存储和搜索文档的世界。我们所处的世界越来越需要文档：

机器可读
具有保鲜意识
可安全进行人工智能检索
结构化程度足以实现自动化
跨语言和受众的动态性
持续可信，而不仅仅是可用

这是一个不同的标准。

它们是为人工智能之前的知识模型而构建的

传统文档平台的设计基于一个简单的假设：如果页面存在并且可以搜索，问题就基本解决了。

当主要用户是人类打开维基、浏览页面并做出判断时，这种假设已经足够好了。在这种模式下，平台的工作就是让编写和导航变得更容易。

人工智能改变了工作描述。

现在，平台不仅仅是为人们存储知识。它正在为自动检索、排序、总结和回答问题的系统提供源材料。

这就提出了旧架构没有优先考虑的新要求：

哪些内容现在值得信赖？
哪些网页已经过时但仍可搜索？
哪些部分最近发生了变化？
哪些语言版本是最新的？
哪些内容是草稿、存档、特定区域或低可信度？
哪些文件应完全排除在人工智能答案之外？

没有围绕这些问题建立的平台必须对其进行改造。这总是比从一开始就为这些问题进行设计要困难得多。

传统优势变成传统拖累

成熟产品有其优势：分销、生态系统、品牌、客户熟悉度、集成以及知道如何发货的团队。但这些优势也会减缓结构性变革。

为什么？因为成熟的平台有承诺。

它们有

多年积累的产品决策
拥有现有工作流程的庞大安装基础
对向后兼容性的期望
依赖于旧有行为的插件和扩展
数据模型针对昨天的用例进行了优化

当 Confluence 或 Notion 等平台想要添加真正的新功能时，往往需要将该功能与现有系统相匹配，而不是通过现有系统来实现。

这就是现有系统所面临的挑战：你不仅在构建未来，还在拖着过去的后腿。

增加人工智能功能并不等于成为人工智能原生系统

很多成熟的平台现在都在人工智能的基础上进行分层。摘要。写作辅助。搜索改进。问答界面。Confluence 有Atlassian Intelligence，Notion 有Notion AI，GitBook 增加了AI-powered search。这些都是有用的功能。其中有些很不错。

但这两者之间存在着明显的区别：

为文档产品添加人工智能功能
建立一个文档产品，其核心架构从一开始就假定人工智能的使用

第一种方法通常会导致辅助功能的边缘化。第二种方法则会改变基础。

人工智能原生知识平台从一开始就提出了不同的设计问题：

应该如何构建文档，以便系统能够安全地对其进行推理？
如何表示信任？
哪些元数据必须是一流的，而不是可有可无的？
陈旧内容如何降低可见度？
当基础来源薄弱时，应如何限制答案？

这些都是架构问题，而不是功能问题。

新鲜平台具有暂时的优势

这就是新平台的优势所在，至少在一段时间内是这样。

新平台可以自由地根据当今的限制条件而不是昨天的习惯进行设计。它不必保留十年来关于文档是什么或维基应如何运行的假设。它可以尽早做出不同的选择：

将新鲜度作为头等概念
让人类和机器都能看到源信任
存储更丰富的内容状态元数据
在核心模型中建立多语言工作流程，而不是将其附加在核心模型上
决定搜索和人工智能检索应根据信任度而不仅仅是相关性进行排序

自由很重要。

在技术领域，现存企业往往在稳定时期最为强大。新进入者往往在模式本身发生转变时最为强大。

人工智能时代就是这种转变之一。

为什么这对 Confluence 尤为困难？

Confluence功能强大，但它的世界观比较陈旧。它是围绕团队空间、页面、分层导航和插件丰富的企业模型而构建的。这些选择是合理的。对于许多组织而言，它们仍然是合理的。

但这也意味着产品具有很大的复杂性。企业平台很少能干净利落地重塑自己。它们必须与自己的历史协商。

这使得现代化进程变得缓慢。并非不可能。只是慢一些。

当人工智能时代的要求需要更简洁的元数据、更明确的信任建模或更有主见的内容管理时，通过多年扩展而建立的最大灵活性系统就很难协调一致地前进。

为什么这对 Notion 来说尤为棘手

Notion 面临着不同的问题。它给人的感觉更新、更轻、更灵活。但灵活性也可能对它不利。

Notion 的优势在于几乎任何东西都可以成为页面、数据库、笔记、轻量级文档或协作空间。这种灵活性非常适合团队使用。但当你需要对内容的含义、内容所处的状态以及人工智能系统是否应将其作为可信来源提供强有力的保证时，这种灵活性就显得不那么重要了。

平台的形式越自由，以后就越难强加可靠的语义。

人工智能系统的发展离不开结构、明确的元数据和信任信号。灵活的通用工作区通常需要大量的解释工作，其内容才能安全使用。

这并不意味着它们注定要失败

如果说Confluence和Notion无法适应环境，那就太懒惰了。它们当然可以。

它们拥有精明的团队、大量的资源和强大的激励机制。它们将推出更多的人工智能功能。它们将改进检索、辅助撰写、摘要、管理和结构化工作流。随着时间的推移，它们可能会缩小很多差距。

但时机很重要。

当这样的转变发生时，谁愿意最快地重建假设，谁就能获得优势。较新的平台可以更连贯地行动，因为它们没有进行太多的改造。这给了他们一个窗口。

这可能不是一个永久的窗口。但它是真实存在的。

文件平台的下一阶段

下一代文档工具的评判标准将不再是如何让人们书写页面，而是如何将知识管理成一个可信的系统。

这意味着获胜者可能会做好以下五件事：

1.明确建立信任模型。 2.他们会区分最新知识和过时知识。 3.它们将把人工智能检索作为核心产品表面处理，而不是附加产品。 4.它们将支持多语言和特定受众的知识，而不会支离破碎。 5.5. 它们将使团队能够更有力地控制在什么条件下向谁、向什么人展示什么信息。

这与传统的维基不同。

新起点为何重要

在软件领域，有些时候，清一色的产品具有优势，不是因为现任者无能，而是因为历史代价高昂。

现在就是这样的时刻。

一个新的平台可以从一开始就决定，文档不仅仅是页面。它们是人类、代理、搜索系统和人工智能助手的活跃来源。这一假设将改变下游的一切。

Confluence 和 Notion 可以做到这一点。但这条路比较漫长，因为它们必须改造为另一个时代优化的系统。

这种转变需要时间。与此同时，较新的平台还有空间来定义现代知识基础设施应该是什么样的。

新平台的最大优势不是新颖性。而是在旧有假设不再起作用的时候，摆脱旧有假设的束缚。

*这是一篇透视文章。对竞争对手产品的评论基于截至 2026 年 3 月的公开产品文档和公告。我们对 Confluence 和 Notion 都怀有由衷的敬意--它们都是出色的产品，为数百万团队提供了良好的服务。

Rasepi 架构内部：插件、动作保护和管道

2026-03-06T00:00:00Z

大多数文档平台谈论 "可扩展性 "就像航空公司谈论 "腿部空间 "一样。技术上存在，实际上却令人失望。我希望 Rasepi 的架构既具有真正的可扩展性，又不会变得不可预测，因此我们建立了三个环环相扣的系统：插件负责功能，动作保护负责控制，管道负责确定性执行。

本篇文章将介绍每个系统在我们的实际代码库中是如何工作的。

插件系统：模块化设计

Rasepi 中的每一个插件都实现了 IPluginModule_，这是一个单一的接口，它声明了插件是什么、需要哪些服务、暴露哪些路由：

codeblock_0

PluginManifest 是纯数据。它描述插件而不执行任何操作：

codeblock_1

注意 UiContributions。该字典将前端扩展点映射到组件名称，因此 Vue 前端知道每个插件贡献了哪些 UI 组件（工具栏按钮、侧边栏面板、设置页面）。

每个插件只需注册一行

启动时，我们通过流畅的 API 注册插件：

codeblock_2

每次调用都会实例化模块，将其存储在注册表中，并调用 RegisterServices() 来连接其依赖关系。应用程序构建完成后，只需一行即可映射所有插件路由：

代码块_3_

在引擎盖下，每个插件都会在 /plugins/{pluginId}/ 处获得一个范围路由组，并自动应用授权。

真实例子：工作流插件

下面是一个真实的插件，即工作流程与审批模块：

codeblock_4

核心平台从不直接引用 WorkflowService或 WorkflowPublishGuard。它是通过 DI 容器发现它们的。这就是零耦合的关键所在。核心应用程序从不接触插件代码。

操作防护：控制层

插件添加功能。操作保护器决定是否允许继续执行该功能或任何核心操作。它们是同步验证器，可在执行前拦截操作。

行动保护评估流程](/zh/blog/img/action-guard-flow.svg)

该接口特意做到了最小：

codeblock_5

当 _ActionName_为 _null_时，防护程序会在每个操作中运行。当设置为 "Entry.Publish"_时，它只拦截特定的操作。

上下文和结果合约

每个 guard 都会收到一个类型化的上下文，其中包含操作名称、租户、用户、实体和一个属性包：

codeblock_6

每个监控程序都会返回一个可预测的结果：允许、拒绝或允许-带修改：

代码块_7_

Modifications 字段非常重要。保护程序可以批准一项操作，但重写部分内容（例如，在发布前编辑机密）。

###规范操作名称

我们将所有可拦截的操作都定义为字符串常量，因此防护程序的目标操作不会有任何歧义：

codeblock_8

真实例子：阻止未经批准的发布

工作流插件注册了一个拦截 _Entry.Publish的保护程序：

代码块_9__

核心平台对审批工作流一无所知。

操作管道：一切汇聚之处

ActionPipeline 是所有受保护操作的单一执行路径。它会确定哪些防护措施适用，对其进行评估，并阻止或执行操作。

代码块_10_

_EvaluateAsync方法负责执行繁重的工作：

代码块_11_

这里有三个重要的设计决定：

1.**TenantPluginResolver会检查每个租户安装并启用了哪些插件。禁用插件的防护程序永远不会运行。 2.2. 全部必须通过。 如果任何防护措施被拒绝，该操作就会被阻止。这是故意采取的安全立场。 3.**如果防护程序出现异常，它将被记录并被视为 Allow()。这可以防止损坏的插件锁定整个平台。

每租户插件解决方案

解析器会查询 TenantPluginInstallations 表（通过 EF 全局查询过滤器自动扩展到当前租户）：

代码块_12_

事件驱动的副作用

操作是同步的。而副作用不是。操作完成后，服务会发布一个域事件：

codeblock_13

事件被挂起到内存通道，并由后台 _________________________________________________处理。Worker 将事件路由到多个系统：

** 活动跟踪 ** 记录谁在何时做了什么。
跟踪每个提供商的成本
任何插件都可以订阅域事件

插件事件处理程序实现 IPluginEventHandler：

编码块_14_

Worker 只调用租户已启用插件的处理程序。这意味着插件 A 的副作用永远不会泄漏到只安装了插件 B 的租户中。

块级翻译引擎

这是该架构最明显的优势所在。

块级翻译：仅对已更改的块进行重译](/zh/blog/img/block-translation.svg)

传统平台翻译整个文档。我们翻译的是单个块：段落、标题、列表项。当用户编辑 50 块文档中的一个段落时，只有该段需要重新翻译。这就是我们节省 94% 成本的原因所在。

如何从 TipTap JSON 创建块

当用户保存文档时，TipTap 编辑器会发送这样的 JSON：

codeblock_15

BlockTranslationService_会解析该 JSON 并创建单独的EntryBlock_记录：

代码块_16_

SHA256 哈希算法用于过期检测

内容散列是过期检测的核心。我们使用 SHA256 对区块内容（去掉 blockId 和 deleted 等元数据属性后）进行散列：

代码块_17_

当源代码块发生变化时，它的哈希值也会发生变化。然后，系统会将每个翻译块的 SourceContentHash与当前的源哈希值进行比较，不匹配的部分会被标记为 Stale：

代码块_18_

结构适应

翻译人员可以改变不同语言的代码块类型。英语的项目列表可能会变成德语的编号列表，这是一种文化偏好。系统会对此进行跟踪：

codeblock_19

翻译提供者作为插件

外部翻译服务（DeepL、Google Translate 等）通过 _ITranslationProviderPlugin_插入：

代码块_20_

批处理方法接收内容块 ID 词典，翻译所有内容块，并返回翻译结果和计费字符数。由于我们只发送陈旧的块，而不是整个文档，因此成本保持在最低水平。

租户隔离：无形的安全网

上述每个系统都在严格的租户隔离内运行。

TenantContextMiddleware 会根据每次请求中的 JWT 解析租户，并验证成员身份：

代码块_21_

Entity Framework 全局查询过滤器可确保即使开发人员忘记按租户进行过滤，数据库层也会自动进行过滤：

代码块_22___

结果：db.Hubs.ToListAsync() 总是只返回当前租户的集线器。数据泄露需要主动绕过查询过滤器，这在我们的代码库中是禁止的。

完整图片

当用户点击 "发布 "条目时，会发生以下情况：

1.请求进入身份验证验证 JWT，TenantContextMiddleware_解析并验证租户。 2.控制器调用管道 IActionPipeline.ExecuteAsync("Entry.Publish", context, action) 3.** 管道解析保护** 查询租户启用了哪些插件，并选择适用的保护。 4.4. 防护装置进行评估。 工作流防护装置检查审批，保留防护装置检查策略，规则防护装置验证内容。全部通过？条目已发布。 5.5. 事件触发 _CODEBLOCK_54__事件被触发。后台工作者记录活动、更新翻译计费并调用插件事件处理程序。 6.检查块翻译过时块将被识别，以便重新翻译。

各层各司其职。各层各司其职，互不影响。这就是架构。

我们建立这个平台并不是因为可扩展性很时髦。我们之所以构建它，是因为一个不能适应每个团队工作流程的文档平台最终会被一个能适应的平台所取代。而一个没有护栏的平台最终会破坏一些重要的东西。