编者按: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」这个词不再有意义时,我们就知道自己做对了。
