作者：@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」這個詞不再有意義時，我們就知道自己做對了。
