作者：@danbeksha

编译：Peggy，BlockBeats

编者按：AI 正在进入企业，但真正的问题并不是「要不要用 agent」，而是这些 agent 能不能理解公司本身。

本文以作者加入 Ramp 后的 100 天为线索，讨论了一个更底层的问题：高速运转的公司，不能只靠新人慢慢读文档、问同事、补上下文，也不能让每个 AI 工具各自为战。真正重要的是搭建一个持续更新的「公司大脑」，把会议、文档、Slack 讨论、客户反馈和产品决策沉淀下来，让新人和 agent 都能从同一套上下文出发。

当上下文被系统化，入职不再只是漫长的适应过程，AI 也不再只是一个个孤立工具。企业 AI 的价值，最终可能不在于部署多少 agent，而在于公司能否先建立起一个可信、可读、可复用的知识底座。

以下为原文：

在 4×100 米接力赛中，胜负往往不是由全程决定，而是被压缩在一段 20 米的交接区里。跑者必须在高速状态下完成接棒：接棒者起跑太早，接力棒会掉到地上；起跑太晚，交棒者不得不减速，整支队伍也会在瞬间失去优势。如果交接动作本身不够精准——手位、角度、时机任何一个环节出错——结果同样可能是掉棒。

一支队伍可以拥有全场最快的选手，却依然输在这 20 米里。速度重要，交接也重要。真正决定胜负的，是二者能否同时成立。

我见过的每一次岗位交接，本质上都像一场接力赛，只不过其中一名选手还停在起跑器上。新人周一入职，一切从零开始；组织却不会因此减速，仍然以原有节奏向前运转。于是，新人只能靠读文档、潜伏在 Slack 里、反复问同样几个问题，再花上三个月时间摸清组织的运行模式，直到自己终于变得「有用」。

我们通常把这段差距视为时间问题，仿佛只要足够久，新人自然会跟上。但事实并非如此。这个差距要么由系统解决，要么就会持续存在。

上下文，才是组织真正的交接系统

我加入 Ramp 大约 100 天了。在此之前，我在 Plaid 工作了五年，熟悉每一个产品、每一个客户故事，以及每一个决策背后的背景。我可以不假思索地讲出这些故事。但来到 Ramp 后，我对这一切几乎一无所知。

而产品营销的核心，恰恰是讲故事。如果你不知道故事里的角色、情节和前因后果，就不可能真正讲好这个故事。

从第一天起，我的目标就是搭建一个 AI-native 的产品营销组织。但要在缺乏上下文的情况下做到这一点，我首先必须扩展自己的知识底座——也就是支撑所有工作的「上下文层」。

Ramp 是一家以速度著称的公司。这里没有「下个季度再慢慢跟上」的空间。公司每周都在发布、迭代、推进。你要么跟上节奏，要么就会变成组织运行中的额外成本。

与此同时，我还在经历另一层 onboarding。Ramp 已经很快，但 AI 的变化更快，而我必须同时学习一家新公司和一个新的工作环境。我不是工程师，上一次打开终端还是大学计算机课。也就是说，我既要补上组织语境，又要适应新的 AI 工作方式，而这两件事彼此叠加，让难度进一步放大。

最终让我从这种压力中脱身的，不是完成某篇具体文章、某次产品发布，或某个工作流，而是把「上下文」本身当作交付物。只要上下文层搭建正确，后续所有工作都会变得更低成本。

于是，我开始构建真正可扩展的东西：一个能像优秀 wiki 帮助研究者一样，帮助我快速补课的系统。到第三周，它已经能基于我的笔记起草内容；到第八周，它已经能总结我没有参加的会议。学习和补课并没有消失，但随着系统不断填充，它们的成本开始一天比一天低。

这个想法的个人版本，其实已经出现一段时间了。曾任特斯拉 AI 负责人、OpenAI 创始成员之一的 Karpathy，在 4 月写过一篇文章，描述了他所说的「个人 LLM 知识库」：一个存放原始输入的文件夹，包括论文、文章、转录稿和个人笔记；一个在这些材料之上生成 wiki 的 LLM；再用 Obsidian 这样的编辑器作为前端。当资料积累到大约 100 篇文章时，LLM 就可以围绕个人语料库回答复杂问题，而不再需要复杂的检索技巧。

他的判断是：这里有机会诞生一个真正出色的新产品，而不是一堆临时拼凑的脚本。

个人版本今天已经存在了。但公司版本还没有。这正是问题所在。

大致来说，我在入职前 100 天搭建的是这样一套系统。它们都还不算精致，但共同构成了组织内部的「结缔组织」。

核心是一个 Obsidian vault，由 Claude 读取和写入。我接触过的会议转录、文档、公开观点和个人笔记，都会进入这个知识库。当我问「Geoff 和我三周前关于首页到底决定了什么」时，它会从这个 vault 中寻找答案，而不是依赖模型本身的泛化记忆。

为了持续给这个 vault 输入内容，Granola 会默认记录每一场会议，并在夜间归档转录稿。于是，我周一错过的会议，到周三就已经可以被查询。为了让公司其他人也能跟上，我选择公开工作——大多数我正在搭建的内容，会先出现在 #team-pmm 或相关发布项目频道里，然后才进入 Notion 文档。构建过程本身，就是一种同步机制。

在这个 vault 之上，还有一个小型的命名技能库，agent 可以按需调用。一个技能可以根据我和某个人最近四次会议生成议程；另一个技能可以扫描 Slack 中一周的产品动态，并转化为文章选题。每个技能大约是 200 行 markdown，用来替代过去需要手动完成的一类工作。

此外，我还基于 Ramp 的内部应用平台搭建了一个动态产品路线图。它读取的是同一套上下文层，因此它不会过期，因为它从一开始就不是静态文档。还有一份每天早上 8 点发到我 Slack 私信里的晨间摘要：昨天上线了什么、哪里卡住了、哪些事情需要我回应。这些内容在我睡觉时已经被整理好。

单独看，这些东西都不算惊艳。但放在一起，它们给出了一个可运行的答案：如果一家公司也拥有 Karpathy 所说的那种 wiki，它会是什么样子？

你可以称它为 wiki、图谱、上下文层，或者公司大脑。名字并不重要，功能才重要。它必须能够吸收公司已经产生的所有信号：会议、Slack 讨论、文档、代码、转录稿、客户电话和关键决策，并且在不依赖人工手动维护的情况下持续保持更新。它也必须成为每一位新员工、每一个新 agent 开始工作之前，首先读取的东西。

如果明天有一位新员工入职，他第一天应该读什么？如果真实答案是一份 2024 年的 Notion 文档，外加一个已经失效的 Confluence 链接，那本质上就是在让他从静止状态接棒。

从单点工具到公司大脑，AI 的真正缺口

今天，AI 进入企业的主要方式，仍然依赖 forward-deployed engineers。无论是 OpenAI、Anthropic，还是大型咨询公司，都会选择在模型之上搭建具体工作流。

这些工作是真实的，也有价值。但它们仍然停留在企业 AI 的「聊天机器人时代」：围绕特定任务封装出来的窄工具，单独看有用，却没有被接入一个能够持续复利的系统。

真正的「公司大脑」还没有出现。客服 agent 和 HR onboarding agent 可能是在不同月份、由不同团队分别搭建出来的。它们彼此并不知道上一次全员会决定了什么，不知道公司如何理解自己的市场，也不知道销售负责人在上一次管理层 offsite 上提出了什么判断。每个 agent 都只是一个有具体职责的聊天机器人，但它们并不共享同一个大脑。

这就是当前最大的缺口。而在实验室之外，几乎没有多少人在围绕这个问题构建产品。

如果你在 2026 年要组建一个团队或创办一家公司，操作顺序已经不同于 2022 年。先写上下文文件，再安装工具。记录每一场会议。先搭建 wiki，再搭建 dashboard。交付技能，而不是幻灯片。让新员工第一天阅读 wiki，第二天就开始为它贡献内容。招聘和晋升那些能让「公司大脑」持续运转的人，也要重用那些真正会读取公司大脑的 agent。

上下文不是副项目。它是让所有 AI 投资真正产生回报的基础设施。

我现在正在 Ramp 搭建其中的一部分：wiki、技能库、从同一个上下文层读取信息的应用，以及持续给它输入内容的组织机制。它还很小，也很早期。如果你也在其他地方尝试构建公司级版本，我很想交流经验。比一个值得信任的大脑更有用的，是两个大脑出现在同一个房间里。

回到接力赛。真正的胜利条件，不是最干净的交接，也不是最快的一棒，而是二者在同一段 20 米里同时发生。

新员工读取公司大脑，然后开始冲刺。新 agent 读取公司大脑，然后开始工作。新客户接入公司大脑，然后从第一天起就进入运行状态。

当「ramp-up」这个词不再有意义时，我们就知道自己做对了。

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。