編譯 | 核子可樂、Tina

在 2025 年，對 GitHub 來說，更像是一場“回歸之后的再出發(fā)”。

一方面，它不再是一家獨(dú)立運(yùn)作的公司，而是更深地回到了微軟體系之中，與 CoreAI 綁定；另一方面，一位新加入的負(fù)責(zé)人，開始在這個(gè)節(jié)點(diǎn)上，為已經(jīng)走到一半的變革給出自己的理解與方向——他就是剛從 Vercel 離職、以 V0 等產(chǎn)品聞名業(yè)界的 Jared Palmer。

在他走馬上任的同一時(shí)間點(diǎn)上，GitHub 正在對外釋放兩條同樣重要的信號：

第一條，是在 Universe 2025 上正式發(fā)布的 Agent HQ——把 Anthropic 的 Claude Code、OpenAI 的 Codex、Google 的 Jules、Cognition、xAI 以及自家的 Copilot 等第三方編碼代理，統(tǒng)統(tǒng)拉進(jìn)同一個(gè)“任務(wù)控制臺”；

第二條，則源自一條頗具殺傷力的吐槽推文：“整個(gè) GitHub 首頁幾乎完全沒用”。

這條由開發(fā)者 Rhys 發(fā)出的帖子，在 X 上收獲了 280 萬次瀏覽、約 2 萬點(diǎn)贊、1100 多次轉(zhuǎn)推、近 500 條回復(fù)和超 1200 次收藏，直接把 GitHub 首頁推上了“公審臺”。圍繞這條吐槽，GitHub 隨后完成了首頁重構(gòu)：讓首頁不再是“大家隨手點(diǎn)掉的一頁”，而是承接任務(wù)、PR 與最近活動的真實(shí)工作起點(diǎn)。

表面上看，這只是兩個(gè)互不相干的產(chǎn)品更新：一個(gè)是多代理管理，一個(gè)是入口體驗(yàn)優(yōu)化。但結(jié)合 Jared 在這場采訪中的講述來看，這兩件事其實(shí)共同透露出一個(gè)非常明確的方向——

GitHub 正在重新定位自己在 AI 時(shí)代中的角色：從代碼托管平臺，走向開發(fā)者與智能體共同工作的統(tǒng)一中樞。

簡單來說，首頁改的是入口，Agent HQ 改的是底座。兩者共同構(gòu)成了 GitHub 在 AI 世代的下一條主線：讓開發(fā)者與智能體在同一個(gè)統(tǒng)一環(huán)境中協(xié)同工作。為了更好理解 GitHub 在這一輪演進(jìn)中的思路，以及 Jared Palmer 如何從 V0 的實(shí)踐走向 Agent HQ 和 GitHub 的平臺化愿景，我們翻譯并整理了他最近的一次公開采訪。

以下是采訪翻譯：

Swyx：說起來，您提到過想要重新設(shè)計(jì) GitHub 主頁，能具體說說嗎？

Jared Palmer：我們團(tuán)隊(duì)有認(rèn)真審視，根據(jù)反饋?zhàn)隽烁倪M(jìn)，讓新版主頁得以落地。

現(xiàn)在的版本，在頁面最上方增加了一個(gè)“任務(wù)區(qū)”，會集中展示你當(dāng)前要處理的事項(xiàng)——最近的 PR、待你跟進(jìn)的工作，同時(shí)也保留了很多人已經(jīng)習(xí)慣的“最近訪問倉庫”等信息。整體的信息結(jié)構(gòu)做了比較大的重構(gòu)，不再只是一個(gè)“裝飾性首頁”，而是一個(gè)你每天點(diǎn)開 GitHub 時(shí)，真的會用、會依賴的起點(diǎn)。

老實(shí)說，我覺得還有不少可以繼續(xù)打磨的地方，但這次的改版已經(jīng)讓人眼前一亮了，我自己也為團(tuán)隊(duì)感到非常自豪。當(dāng)然，產(chǎn)品永遠(yuǎn)沒有“完成”的那一天。接下來我們也希望能和社區(qū)一起，不斷迭代這個(gè)首頁。

Swyx：目前您同時(shí)擔(dān)任 GitHub 高級副總裁與微軟 CoreAI 副總裁，身兼兩職會不會讓您有別扭的感覺？

Jared Palmer：我才上任十幾天，還處于適應(yīng)階段，不過目前來講算是一切順利。

Swyx：在加入 GitHub 之前，您曾經(jīng)創(chuàng)立 Vercel 并打造 AI SDK，并擔(dān)任 v0.dev AI 副總裁。能不能聊聊這段經(jīng)歷？

Jared Palmer：沒問題。整個(gè) AI 項(xiàng)目發(fā)展理念的基本脈絡(luò)，就是從早期的單一編程智能體到如今為所有編程智能體建設(shè)活動空間。我覺得這也基本概括了 Agent HQ 的核心理念。

過去這兩年，我專注于構(gòu)建 Vercel、v0 和 AI SDK，并在今年夏季休息一陣之后加入了 GitHub，前段時(shí)間又推出了 Agent HQ 等項(xiàng)目。

我們希望 Agent HQ 不單成為智能體的活動空間，更成為開發(fā)者的聚集地，成為我們構(gòu)建的全新協(xié)作環(huán)境的運(yùn)轉(zhuǎn)中樞。

用 v0 的經(jīng)歷打造 GitHub？

Swyx：在 GitHub，您能實(shí)現(xiàn)哪些原本 v0 做不到的事情？

Jared Palmer：GitHub 這個(gè)平臺體量可觀，坐擁 1.83 億用戶，其中有開發(fā)者近 1800 萬。而 v0 不僅關(guān)注單一語言，更是聚焦特定框架與問題域，通過內(nèi)置渲染器為特定場景服務(wù)。有些朋友可能還不了解 v0，這是一款由 Vercel 開發(fā)，類似于 Lavable 的氛圍編程工具，但主要面向 Next.js 應(yīng)用的生成。這種聚焦度讓團(tuán)隊(duì)獲得了更大的自由空間，如激光般直搗希望實(shí)際的核心目標(biāo)。而在 GitHub，我們開始為所有語言、框架和開發(fā)者構(gòu)建活動空間，因此視野也更為廣闊。這種指向性的差異就是最大的區(qū)別。

Swyx：您幾乎涉足了編程智能體的整個(gè)發(fā)展過程，那您自己在其間的成長軌跡又是怎樣的？

Jared Palmer：我在很多場合下都不止一次回答過這個(gè)問題，而每次回憶好像都會解鎖大腦中不同的記憶片段——所以咱們不妨就從記憶檢索機(jī)制聊起。

智能體的記憶機(jī)制就很奇妙，類似于閑逛時(shí)偶爾會發(fā)現(xiàn)新路徑的感覺?？傊蟾诺倪^程是這樣：當(dāng)初 ChatGPT 甫一問世，就給從業(yè)者們帶來了巨大震撼，堪稱是改變世界且增長迅猛的革命性產(chǎn)品。

回顧自己的履歷，我意識到自己其實(shí)很早就開始在 Vercel 涉足 AI 領(lǐng)域，但最早的時(shí)候公司根本沒有 AI 部門或者團(tuán)隊(duì)，我擔(dān)任的是所有框架的工程技術(shù)總監(jiān)，并通過 Turborepo 等內(nèi)部開發(fā)工具協(xié)助 Next.js 團(tuán)隊(duì)進(jìn)行內(nèi)部測試，驗(yàn)證服務(wù)器操作的初始實(shí)現(xiàn)。

那會就有人提議：與其開發(fā)待辦事項(xiàng)應(yīng)用，為什么不打造一套實(shí)驗(yàn)平臺？我立馬覺得這事可辦，于是側(cè)重出了 AI 實(shí)驗(yàn)平臺，也就是如今 AI SDK 的組成部分。通過對各家模型提供商和組合方案的研究，我為 AI SDK 找到了這樣的定位：專注于我們擅長的用戶界面領(lǐng)域，同時(shí)不干擾用戶的其他操作。于是我們先發(fā)布演示平臺，隨后正式推出 AI SDK。到 2023 年夏天，整個(gè)原型開發(fā)由此進(jìn)入快車道，公司內(nèi)部也達(dá)成了全面轉(zhuǎn)向 AI 領(lǐng)域的共識。

記得當(dāng)時(shí)代碼執(zhí)行功能剛剛上線——名叫 Inter Code Interpreter，也就是代碼沙箱解釋器。我看到這項(xiàng)功能后，立刻萌生出一種雄心勃勃的構(gòu)想，意識到如果能以某種工具調(diào)用機(jī)制在 4000 個(gè) token 的上下文窗口內(nèi)實(shí)現(xiàn)以下功能：根據(jù)提示詞直接進(jìn)行代碼解釋、渲染 UI 界面、生成文檔或者直接在聊天框內(nèi)生成內(nèi)容，那么開發(fā)體驗(yàn)絕對會進(jìn)入全新的時(shí)代。比如生成不同類型的交互界面，或許還能串聯(lián)輸出，比如把代碼解析的輸入作為下一條提示詞中的一部分之類。這個(gè)想法雖然瘋狂，但本質(zhì)上跟工具調(diào)用并無區(qū)別。

隨著技術(shù)發(fā)展逐漸明朗，我們開始內(nèi)部商議，到底該不該向代碼解釋功能開放數(shù)據(jù)抓取能力。雖然現(xiàn)在大家覺得無所謂，但當(dāng)時(shí)為它提供網(wǎng)絡(luò)訪問權(quán)限確實(shí)有點(diǎn)可怕。最終我們決定放棄代碼解釋功能，只保留最酷炫的 UI 生成方案。這種直接用提示詞就能輸出界面的能力，堪稱是 v0 項(xiàng)目的頓悟時(shí)刻。

最早的 v0 記得是在 2023 年 9 月發(fā)布的，而且觀感上更類似于 Midjourney。時(shí)間快進(jìn)到產(chǎn)品上市九個(gè)月，我們的小團(tuán)隊(duì)用了三個(gè)季度才達(dá)成百萬級別的 ARR（年度經(jīng)常收入）。隨著模型持續(xù)迭代，我們也先后嘗試過更多新模型，但不知道為什么，GPT-4 Turbo 始終沒法成功接入。在轉(zhuǎn)用其他前沿模型之后，我們最終開始自研模型。

繼續(xù)快進(jìn)十個(gè)月左右，我們重新回歸聊天功能，終于讓模型能夠處理聊天任務(wù)。到這個(gè)階段，我們意識到重構(gòu)的最佳時(shí)機(jī)已經(jīng)到來，v0 也由此迎來新版。這時(shí)候項(xiàng)目的營收開始猛增，短短 14 天 ARR 就增加了百萬，又過 14 天再度增加百萬。

我們不斷精進(jìn)優(yōu)化，更重要的是期間我們始終專注單一技術(shù)棧和框架。那時(shí)候其他團(tuán)隊(duì)都在嘗試通用編程智能體，而我們堅(jiān)持只關(guān)注 Next.js 前端與 Shadcn，這也讓團(tuán)隊(duì)得以聚焦核心。

公平地講，Next.js 的統(tǒng)治地位讓這種定位獲得了強(qiáng)大的吸引力。而我們對包括 UI 庫和組件在內(nèi)的各種細(xì)節(jié)進(jìn)行專注打磨，也帶來了巨大優(yōu)勢。我們還開始與各大前沿模型實(shí)驗(yàn)室合作，確保他們的模型獲得愈發(fā)強(qiáng)大的 Next.js 生成能力。而我們也把自己開發(fā)的后訓(xùn)練框架與其他模型實(shí)驗(yàn)室共享，并對所有數(shù)據(jù)進(jìn)行嚴(yán)格處理，確保處于最優(yōu)狀態(tài)。

Swyx：那你們有沒有討論過在 v0 當(dāng)中融合不同模型的優(yōu)勢特性？

Jared Palmer：那肯定是有的，包括到底該提取各種模型的最佳特性并集于 v0 一身，還是提供模型選擇器以幫助客戶自由切換。我們確實(shí)反復(fù)討論過這些方案，最終發(fā)現(xiàn)這兩種方式各有優(yōu)劣。打造自研模型或者說復(fù)合模型的優(yōu)勢，在于可以自由組合這些元素。另外值得一提的是，搜索模型和生成模型完全不同，二者本質(zhì)上屬于兩個(gè)獨(dú)立的子系統(tǒng)。搜索模型可以完全獨(dú)立于生成模型運(yùn)行。

所以我們現(xiàn)在的解決方案是，不提供模型選擇器，而是通過自研復(fù)合模型實(shí)現(xiàn)不同優(yōu)勢的結(jié)合。我認(rèn)為這應(yīng)該是更好的方式，一方面是可以把成果作為產(chǎn)品進(jìn)行品牌化推廣，另外也能把我們的業(yè)務(wù)跟前沿實(shí)驗(yàn)室的發(fā)布剝離開。

再說說模型品牌化，這么做的優(yōu)勢是我們可以跟模型提供商合作發(fā)布，把很多工作交給他們。但相應(yīng)的問題是，我們能夠提出的計(jì)費(fèi)上限也就是零售價(jià)了，沒辦法進(jìn)一步營造溢價(jià)空間。

Swyx：就是說我們很難通過高質(zhì)量的客服等方式擴(kuò)大服務(wù)收費(fèi)。這就是理想與現(xiàn)實(shí)之間的兩難——我們既需要建立可持續(xù)的業(yè)務(wù)模式，擺脫對模型實(shí)驗(yàn)室的依賴；同時(shí)還要切實(shí)保證效益提升，并想辦法把二者整合起來。

Jared Palmer：是的。好在如今我們已經(jīng)轉(zhuǎn)向 GitHub，專注走上了模型選擇的道路。我們手頭能用的不光有 Copilot，還有第三方 Claude Code、Codex 和 Cognition，包括現(xiàn)在的 Agent HQ，可以說是魚與熊掌兼得了。這種形式的效果非常好，也符合用戶的最終需求。

沒錯，我認(rèn)為已經(jīng)不適合在模型層上做切換了，雖然當(dāng)初我們的 AI SDK 就是這么起家的。

現(xiàn)如今，模型與智能體必須緊密綁定，達(dá)到高度平衡的狀態(tài)。一旦使用泛型接口松散綁定，所有模型就會快速退化成最小公約數(shù)的水平。接觸過智能體的朋友應(yīng)該明白我說的意思，智能體對于抽象概念的處理遠(yuǎn)遠(yuǎn)超過聊天場景，其對應(yīng)的是包含計(jì)算運(yùn)行時(shí)和文件系統(tǒng)的循環(huán)系統(tǒng)。

這里再談?wù)勎覍?AI 智能體的理解。這事我跟很多同行爭論過，在我看來智能體本質(zhì)上就是用？加上 for 循環(huán)編排的 API 請求。只是如今的編程智能體已經(jīng)涵蓋更多功能，比如 SDK、沙箱環(huán)境、文件系統(tǒng)、工具調(diào)用等等，這已經(jīng)構(gòu)建起了獨(dú)特的智能體生態(tài)圈，我個(gè)人稱之為編程智能體領(lǐng)域。甚至我認(rèn)為 Claude Excel 智能體在本質(zhì)上也是基于 Claude Code——我不太清楚具體的底層實(shí)現(xiàn)，但若真是如此也在意料之中。

再就是 Skills 模塊，本質(zhì)上屬于 MCP 的捆綁版本。它同樣高度依賴大語言模型，比如讀取用戶提供的 Markdown 文件，參考文件目錄內(nèi)容再自由發(fā)揮。這其實(shí)就是一種文件系統(tǒng)，對吧？

掌控 Agent HQ 后，會設(shè)置怎么樣的發(fā)展路徑？

Swyx：是的，這種新形態(tài)的文件系統(tǒng)真的很酷。最近兩年編程智能體一路發(fā)展，您也親歷了整個(gè)過程。那從您掌控的 Agent HQ 入手，您希望這個(gè)項(xiàng)目未來如何發(fā)展、又從各種智能體中觀察到了怎樣的趨勢？

Jared Palmer：這是個(gè)好問題。我認(rèn)為 Agent HQ 和 GitHub 需要協(xié)同進(jìn)化。

微軟的一大優(yōu)勢，就是善于把同類成果更緊密地結(jié)合起來，比如新成立的 CoreAI 部門。再就是把 Visual Studio Code、GitHub 和部分 Azure 服務(wù)整合為一體。對我而言，Agent HQ 最酷的功能之一，也在于實(shí)現(xiàn)工作流的無縫銜接與流暢體驗(yàn)。從演示中可以看到，當(dāng)在 Agent HQ 中發(fā)起任務(wù)創(chuàng)建 PR 時(shí)，只需單擊即可在 VS Code 中直接打開該 PR，這種體驗(yàn)太棒了。

關(guān)于 GitHub 的未來發(fā)展，我希望能借此探索在哪些觸點(diǎn)上更自然地引入 AI——比如如何解決合并沖突、能否自動彈出操作界面等等。這就是我對 AGI 的理解——深度融合。一旦操作出現(xiàn)錯誤，我們總會遭遇本地環(huán)境無法正常運(yùn)行、工具卻一切正常的窘境。所以每次執(zhí)行推送時(shí)，我都希望能直接添加評論或者啟動任務(wù)來解決這類問題。

我設(shè)想的是一種無縫銜接的工作流，讓開發(fā)者無論是在移動端、Web 端、GitHub.com 還是全局編輯器中都能保持專注狀態(tài)。這也是我接下來半年左右的主要研究方向。

Swyx：那 Dev Containers 呢，你覺得這項(xiàng)技術(shù)會不會成為行業(yè)標(biāo)準(zhǔn)？我不確定 Dev Containers 是微軟還是 GitHub 搞出來的，我把它的本質(zhì)理解為一種沙箱環(huán)境，也是 Docker 容器的輕量版本。VS Code 對它支持得很好，但在 VS Code 之外好像還不太普及。那你們自己會用嗎？

Jared Palmer：其實(shí)我們自己就是用一些 K8s pod。這個(gè)問題屬于對運(yùn)行時(shí)的選擇啦，微軟內(nèi)部在這方面標(biāo)準(zhǔn)上還在進(jìn)行討論。

目前有幾個(gè)競爭方案，我們應(yīng)該會在下個(gè)周期內(nèi)找到答案。但你說得沒錯，Dev Containers 確實(shí)提供不少酷炫的功能：預(yù)裝 VS Code，帶文件系統(tǒng)，支持沙箱機(jī)制，兼容安全協(xié)議，還能直接對接 GitHub Enterprise，且支持隨時(shí)打包部署。這些優(yōu)勢確實(shí)都很令人心動。在我看來，Cognition 和 Codex 等服務(wù)的首要痛點(diǎn)就是倉庫配置——這恰恰是 Dev Containers 和 Dockerfile 擅長解決的問題。先運(yùn)行這個(gè)、再運(yùn)行那個(gè)，之后配置這個(gè)，最終執(zhí)行那個(gè)……這也太麻煩了。

我猜遲遲解決不了的難點(diǎn)，在于無法預(yù)知倉庫內(nèi)容——比如開發(fā)者是否打包了 ffmpeg 庫之類。如果只是 Next.js 庫，那直接執(zhí)行 pm install 就行。當(dāng)然，這些都有辦法做特殊處理，但通用容器本身仍然是個(gè)挑戰(zhàn)。

話雖如此，我覺得自動檢測和預(yù)判之類的工作還是有空間的。很早的時(shí)候我就想開發(fā)一款開源框架自動檢測工具，可惜這個(gè)想法始終沒能在公司里成為共識。我當(dāng)時(shí)一直覺得，這樣的工具不就該開源嗎？自動檢測本就是人人都需要的基礎(chǔ)功能。但話說回來，好像大家各自開發(fā)也不太好，把默認(rèn)偏好技術(shù)棧統(tǒng)一起來才是正道。

Swyx：好的。那您還有其他比較關(guān)注的協(xié)議或者標(biāo)準(zhǔn)嗎？比如 MCP 今年的表現(xiàn)就很亮眼，還有其他像 A2A、ACP 這類有趣的項(xiàng)目。

Jared Palmer：MCP 系統(tǒng)規(guī)模確實(shí)龐大，特別是在數(shù)字化轉(zhuǎn)型領(lǐng)域，正在成為許多企業(yè)客戶的核心解決方案，并借此實(shí)現(xiàn)上下文擴(kuò)展。

我們前陣子還發(fā)布了智能體定制化功能，用戶可以在 Agent HQ 中通過提示詞等方式針對不同任務(wù)定制智能體，再讓這些智能體集成多任務(wù)處理器等組件。從平臺角度看，這里的可擴(kuò)展空間非常大，也讓我倍感振奮。

Swyx：咱們繼續(xù)討論 AI 的話題。在計(jì)算機(jī)視覺應(yīng)用方面，起步階段大家都很興奮，后來卻發(fā)現(xiàn)速度慢還不夠準(zhǔn)確，占用的計(jì)算量也很大。好在改進(jìn)的速度也是肉眼可見的。

Jared Palmer：沒錯，目前的開源視覺模型對極端案例的支持還不夠好，似乎還有深入探索的空間。

Swyx：那在代碼生成領(lǐng)域，許多人正思考如何從開發(fā)者協(xié)同到代理程度更高的演進(jìn)路徑——類似于 Claude Code 環(huán)境那種。就目前的情況看，下一步該邁向哪里？

Jared Palmer：簡單講，就是要做得更好。魔鬼藏在細(xì)節(jié)里，成功率從 90% 提升到 95%、98% 乃至 99%，難度會呈指數(shù)級增長。要完成這波轉(zhuǎn)變還有很多工作要做。98% 和 99% 的準(zhǔn)確率其實(shí)差距很大，大到每位用戶都能感知到。

而且很多做 AI 產(chǎn)品的開發(fā)者可能沒意識到，大部分參與者其實(shí)活在幻想中，對自家 AI 產(chǎn)品的糟糕表現(xiàn)渾然不覺。他們不會去認(rèn)真測量無錯誤會話數(shù)量、請求丟失率、響應(yīng)速率這些指標(biāo)。Vercel 就一直非常重視且持續(xù)關(guān)注這方面指標(biāo)，我們會每三個(gè)小時(shí)匯總關(guān)鍵指標(biāo)和數(shù)據(jù)，其中無錯誤會話指標(biāo)尤其重要，也決定著智能客服這類多輪交互應(yīng)用的生死。

我記得 2024 年時(shí)曾經(jīng)發(fā)過條推文：智能體技術(shù)的真正成熟不僅要依賴更智能的模型，更要依賴基礎(chǔ)設(shè)施供應(yīng)商的可靠性升級。這類服務(wù)跟數(shù)據(jù)庫更新這類持續(xù)性服務(wù)不同，各廠商之間性能也存在差異，不同運(yùn)行時(shí)長就是造成不同網(wǎng)關(guān)產(chǎn)品成功的原因，因此 OpenRouter 這類產(chǎn)品才能大獲成功。畢竟可靠性問題迫使我們不得不經(jīng)常切換供應(yīng)商，借此回避停機(jī)。簡而言之，我們當(dāng)時(shí)的情況有點(diǎn)像玩游戲：所有數(shù)據(jù)實(shí)時(shí)涌入系統(tǒng)，我們只能根據(jù)數(shù)據(jù)波動調(diào)整工作狀態(tài)，猜測第二天會不會突然就崩了。

這種模式幫了我們不少，我覺得其他團(tuán)隊(duì)也該把數(shù)據(jù)驅(qū)動方法用起來。

但令人驚訝的是，數(shù)據(jù)分析類工具仍然相對匱乏——至今我還沒見到那種既能輕松生成精準(zhǔn)分析結(jié)果，又能像添加 Slack bot 那樣輕松使用的解決方案。

整個(gè)分析領(lǐng)域似乎仍停留在 BI 時(shí)代，這真的很奇怪。這個(gè)領(lǐng)域到現(xiàn)在還沒被充分開發(fā)，所以我一直在關(guān)注轉(zhuǎn)變到底何時(shí)到來。

Swyx：我還有個(gè)好奇的點(diǎn)，編程智能體能否應(yīng)用于非編程領(lǐng)域？您有沒有親自實(shí)踐過，具體做的是什么？

Jared Palmer：今年夏天，我?guī)臀野衷O(shè)計(jì)了一套工作自動處理流程。他手頭有一堆 Excel 表格，就是財(cái)會那個(gè)方面的東西。我試著把 Claude Code 套用上去，結(jié)果它用 Python 生成了幾個(gè)腳本，雖然有點(diǎn)小問題，但連我爸都覺得效果相當(dāng)不錯，整個(gè)流程跑起來也相當(dāng)順暢。

另外還有帶智能體的瀏覽器，也很有破圈的潛質(zhì)。

Swyx：那您用過哪些 AI 代理瀏覽器？

Jared Palmer：我目前主要用 Atlas，但還是更喜歡 Arc 瀏覽器的垂直標(biāo)簽布局。專業(yè)用戶需要面對多種業(yè)務(wù)場景，所以需要頻繁切換上下文。我自己就經(jīng)常會打開上百個(gè)標(biāo)簽頁，為此還專門開發(fā)了開源工具 Chrome Dump。它能把所有打開的標(biāo)簽頁導(dǎo)出為匯總，把內(nèi)容整理成 Markdown 再批量關(guān)閉。我一直覺得關(guān)閉標(biāo)簽頁應(yīng)該像寫 Markdown 一樣簡單，但 Chrome 在性能方面還是有問題。我還嘗試過用 Tori 框架開發(fā)，但 Tori 明確限制開發(fā)瀏覽器功能，就挺遺憾的。

Swyx：最后一個(gè)問題，您提到過 StackTips。這到底是什么功能，開發(fā)難度為什么那么大？

Jared Palmer：這個(gè)得慢慢解釋。跟 Facebook 打過交道的朋友應(yīng)該都聽說過 Fabricator 這款工具。我們都很熟悉 PR 這個(gè)概念，編寫代碼、提交記錄、發(fā)起 PR，合并后繼續(xù)工作。但當(dāng)組織規(guī)模擴(kuò)大之后，我們會發(fā)現(xiàn)有些人對 Git 操作方式有著近乎信仰般的執(zhí)著——比如總在強(qiáng)調(diào) rebase 和 merge 的區(qū)別。有些人覺得重寫提交歷史實(shí)現(xiàn)線性整合更重要，也有些人認(rèn)為該先創(chuàng)建合并提交保留分支結(jié)構(gòu)。總之我雖然沒在 Facebook 工作過，但之前曾經(jīng)認(rèn)真研究過構(gòu)建系統(tǒng)。

Facebook 不僅自研過 Buck 構(gòu)建工具，還開發(fā)過韌性的文件系統(tǒng)——對，他們不用 Git，而是采用自己的 Mercurial。如今這些系統(tǒng)已經(jīng)高度定制化，形成了一個(gè)緊密耦合的整體。

Facebook 也不采用 PR 機(jī)制，他們有自己的開發(fā)哲學(xué)。最貼切的比喻是：想象每個(gè) PR 都只包含單次提交。這樣不僅可以對提交做拆分處理，而且還能重新進(jìn)行堆疊。在后續(xù)修改時(shí)，可以將變更置于 stack 的早期位置，而這些 stack 的本質(zhì)就是提交差異。在堆疊之后，可以隨意合并最新提交或者其中的任意提交，提供更優(yōu)雅的工作流程。這對單體倉庫或者超大規(guī)模代碼庫來說簡直是絕佳方案。

更進(jìn)一步思考，我們甚至可以左右 stack 中的哪些差異需要 CI 測試——當(dāng)然，這需要配合更復(fù)雜的配置。比如根據(jù)提交信息篩選，或者直接跳過某些分支。這最終會形成分組形式的代碼 stack，對于代碼審查非常友好，也能更從容地更新 stack 中的不同部分，簡直太懂開發(fā)者的心思了。

目前市面上已經(jīng)有幾款工具支持這種模式，其中之一叫 Graphite。

整個(gè) GitHub 社區(qū)一直翹首期盼這樣一項(xiàng)功能，所以我也在加入 GitHub 之后把它當(dāng)成了頭等大事。而在回顧調(diào)查之后，我發(fā)現(xiàn) GitHub 內(nèi)部早就做過多次嘗試，最早一次是在 2020 年，2022 年的那次嘗試已經(jīng)有了頗為成熟的方案。當(dāng)時(shí)大家嘗試把所有工作都在客戶端完成，并在 GitHub PR 之外引入“stack”這一全新概念，只是因?yàn)轱L(fēng)險(xiǎn)稍高而放棄了。當(dāng)時(shí)的內(nèi)部討論覺得這樣的變革幅度太大，不適合推出。

目前我們已經(jīng)召開過幾次內(nèi)部會議，努力將其納入規(guī)劃路線圖，也期待跟大家分享更多進(jìn)展。總之像 GitHub 這樣體量的平臺，要想支持全新功能絕非易事——既要考慮平臺體量，也涉及 Git 的實(shí)現(xiàn)機(jī)制。但我們確實(shí)在積極探索。