我很興奮能再次與 Microsoft 合作，共同贊助 AI 工程師世界博覽會！今天我們將在 Microsoft Build 大會上進行直播，與 No Priors 的朋友們以及獨一無二的 Satya Nadella 進行一場特別的跨界訪談。
然而，這次訪談我們毫不保留，提出了所有關於服務穩定性 (uptime) 和 Copilot 的熱門問題，我們知道這些問題也存在於你們心中。開始吧！近二十年來，GitHub 一直是軟體開發的家園，無論是開源或閉源專案，都透過提交 (commits)、拉取請求 (pull requests)、審查 (reviews) 和動作 (actions) 等方式在此流動。
Kyle Daigle@kdaigleGitHub 生日快樂！我用一個故事來慶祝我們的生日：18 年前 GitHub 創辦人 defunkt 在他們推出後拒絕了我的工作申請... 但最終一切都順利了。🤣就在 18 年前的今天，GitHub 由 defunkt 和 @mojombo 正式推出。
下午 12:33 · 2026 年 4 月 10 日 · 2.19 萬次瀏覽16 則回覆 · 18 次轉發 · 243 個讚隨著開源專案的維護者和貢獻者不斷為社群提供程式碼，這個生態系統蓬勃發展。然而，當程式碼生成代理 (coding agents) 開始大量輸出程式碼，在 2026 年增長了 1400%，這標誌著 GitHub 進入了一個既令人興奮又充滿挑戰的新時代。
Kyle Daigle@kdaigle沒錯，平台活動正在激增。2025 年有 10 億次提交。現在，每週有 2.75 億次，如果增長保持線性，今年將達到 140 億次（劇透：不會）。GitHub Actions 的使用時間從 2023 年的每週 5 億分鐘增長到 2025 年的每週 10 億分鐘，而現在 ThePrimeagen @ThePrimeagen 我想為我為 M$ 辯護而道歉，但我必須不時地這樣做。
我必須向 GitHub 致敬，感謝他們處理了過去三個月內新增的數十億行「垃圾程式碼」。這些程式碼可能永遠不會被 CPU 執行。下午 8:29 · 2026 年 4 月 3 日 · 262 萬次瀏覽156 則回覆 · 569 次轉發 · 7140 個讚儘管這些代理幫助更多人交付更多專案，但它們也顯著提高了程式碼交付的數量、頻率、提交程式碼的人數，以及 GitHub 基礎設施各個層面的規模，基本上是數量級的倍數增長。
現在，GitHub 不可避免地面臨基礎設施的更大壓力，這些基礎設施最初是為人類開發者以人類的速度運作而設計的。這導致了一個非常引人注目的服務穩定性事件：chloe 🐇@SapphoSysworld 全球第一個達到「零個九」服務穩定性的企業解決方案。
上午 11:31 · 2026 年 4 月 2 日 · 62 萬次瀏覽120 則回覆 · 474 次轉發 · 1.26 萬個讚因此，這引出了一個問題：目前的程式碼相關系統能否吸收 AI 生成的內容？當每個想法都變成一個建構 (build) 時，CI/CD (持續整合/持續交付) 能否跟上？
開源專案的維護者能否在 AI 生成的「劣質」貢獻洪流中倖存下來？GitHub 能否在成為代理的運作層的同時，保留軟體的人類社會契約？這讓我們找到了回答這些問題的最佳人選：GitHub 營運長 Kyle Daigle。在本集中，他與 swyx 一同探討當 AI 不僅僅是自動補齊程式碼，而是開始改變公司運作方式、開源專案的運作模式、拉取請求的審查方式，以及 GitHub 本身如何擴展時，會發生什麼。
我們深入探討 GitHub 內部的 AI 工作流程：微技能 (micro-skills)、WorkIQ、MCP、Slack、Teams、電子郵件、Copilot 工作流程、新的 Copilot 桌面應用程式、命令列介面 (CLI)、雲端代理，以及 Kyle 如何利用代理回溯公司背景資訊，然後決定下一步行動。
Kyle 也回顧了 GitHub 建立 webhooks、API、Actions、npm、Dependabot 和 Semmle 的歷史，解釋了為何 AI 時代以新的方式「打破」GitHub，Actions 如何成為通用運算層，以及 Copilot 在程式碼補齊之後將會變成什麼。
我們討論了：Kyle 在 GitHub 的擴展職責AI 如何讓 Kyle 在擔任領導職位多年後重新開始寫程式為什麼 GitHub 透過現有工作流程推出 AI，而不是強制使用新工具WorkIQ、MCP、Slack、Teams、電子郵件和 GitHub 作為公司背景資訊為什麼龐大的「巨型技能」(mega-skills) 正在讓位給小型、原子化的「微技能」(micro-skills)AI 如何改變摘要、溝通、行銷和分析師工作為什麼擔任領導職位的前開發者在 AI 時代可能擁有獨特優勢Kyle 的「週六 15 個代理」工作流程Kyle 如何為 CRO/CFO 團隊建立 AI 生成的高階主管簡報為什麼 AI 改變了幕僚長 (chief of staff) 的角色，但沒有取代人類工作GitHub Actions、webhooks、任意程式碼執行和安全的代理運算npm 收購、供應鏈安全、雙因素驗證 (2FA) 和權杖失效「劣質分支」(slop forks)、供應商化 (vendoring) 以及 AI 代理是否改變了依賴管理當大多數拉取請求來自代理時，拉取請求會變成什麼提示請求 (prompt requests)、擔保 (vouching)、AI 審查和開源中的信任當 AI 降低建構門檻時，什麼才算「開發者」GitHub Spark、低程式碼 (low-code) 以及為什麼 GitHub 拒絕隱藏程式碼提交量增長 14 倍、Actions 負載、資料庫、單一儲存庫 (monorepos) 和可用性Copilot 從程式碼補齊演進到 CLI、桌面應用程式、雲端代理和 SDK上下文、記憶體、規則以及讓 GitHub「按照 Kyle 期望的方式運作」環境 AI (Ambient AI)、OpenClaw、企業安全以及代理的新作業系統swyx 應該向 Satya Nadella 詢問 Microsoft AI 未來的問題Kyle DaigleLinkedIn: https://www.linkedin.com/in/kyledaigleX: https://x.com/kdaigle00:00:00 引言00:03:36 為什麼 AI 讓 Kyle 重新開始寫程式00:07:04 使用 AI 營運 GitHub：WorkIQ、MCP、Slack、Teams 和技能00:15:39 擔任領導職位的前開發者的黃金時代00:17:31 週六 15 個代理和 AI 生成的高階主管工作00:20:20 AI 如何改變幕僚長的角色00:21:45 GitHub 的歷史：Actions、npm、Webhooks 和開源00:28:45 劣質分支、供應商化和 AI 依賴管理00:33:57 拉取請求、提示請求和代理生成程式碼的信任00:41:21 GitHub Stars、2 億多開發者和新的 AI 建構者浪潮00:45:15 GitHub Spark、低程式碼以及為什麼 GitHub 仍然顯示程式碼00:47:38 GitHub 最艱難的時代：14 倍增長、可靠性和規模00:59:21 Actions 作為 CI/CD 和自動化的運算層01:02:04 GitHub Copilot 的現況與未來01:08:24 環境 AI、背景代理和 SDLC 的未來01:13:09 OpenClaw、企業安全和代理的新作業系統01:18:03 Build 大會公告、WorkIQ、FoundryIQ 和 Microsoft 背景資訊01:21:41 swyx 應該問 Satya 什麼？
Swyx [00:00:00]: 我們與 GitHub 營運長 Kyle Daigle 在這裡。歡迎。Kyle [00:00:07]: 嘿，謝謝邀請我。Swyx [00:00:08]: 你不只是 GitHub 的營運長。人們都知道你是。你現在有了一個新職位。
Kyle [00:00:11]: 是的，我現在的職責擴大了。我在 GitHub 工作了十三年，負責所有與開發者相關的事務。我本身就是一名開發者。現在，我同時也是 Microsoft 開發者行銷長 (CMO of Developer)。因此，所有關於開發者的學習和熱情，以及我們如何與他們合作、如何溝通、如何將產品推向市場，我們也將這些專業知識帶到更廣泛的 Microsoft 生態系統中，幫助每一位使用 Microsoft 產品或希望獲得與他們多年來在 GitHub 上類似體驗的開發者。
所以在某些方面這是一個不同的角色，但它也只是建立在我過去在 GitHub 的經驗之上，也就是實話實說、真誠、展示人們如何使用它，然後讓產品自己說話。現在只是將這一切應用到整個 Microsoft。Swyx [00:01:09]: 我們將與 Build 大會同步發布這個內容。
你有很多計畫，我們可以在適當的時候談談。我認為有趣的一點是，我很少遇到同時擔任營運長和行銷長的人。你似乎非常外向，在公開場合也非常自信。這很罕見。你真的認為自己是營運長嗎？你的主要職責是什麼？Kyle [00:01:33]: 我覺得這很有趣。
對我來說，這些頭銜一直都感覺有點奇怪。我以開發者的身份加入 GitHub？我寫了那麼多的 Swyx [00:01:46]: 我們來談談這個。你寫了後端嗎？Kyle [00:01:48]: 我當時正在翻看一些舊照片，當時人們正在談論事物是如何被建構的，或者 GitHub 是如何被建構的。
我建構了 webhooks，並與團隊合作建構 API，建構了平台層。任何與 GitHub 整合的東西，直到 2018 年，都是我建構或管理工程團隊的。這就是我熱情的起點，總是幫助人們建構東西，將它們交付給客戶。因此，作為一名開發者，為開發者建構東西總是超級獨特的。
我認為隨著我的角色擴大，我能夠不僅與開發者對話，還能與企業客戶或業務領導者對話，並充當這個翻譯層。然後在這些年裡，GitHub 一直以非常獨特的方式運作。在疫情之後，遠端工作不再像 GitHub 在 2008 年剛開始時那麼新奇。但是所有這些管理遠端團隊的專業知識，並且做得很好，變成了這個更大的角色，最終轉變為營運長的角色，即在 Microsoft 收購之後，我們如何以 GitHub 一直以來的運作方式來營運 GitHub。
諸如此類。所以對我來說，我仍然寫程式。我喜歡寫程式，但問題始終是人。同時支援我們的員工，以及向開發者和企業買家傳達我們正在建構什麼以及為什麼它很重要，這是一個更困難的問題，因為這是兩種非常不同的訊息。因此，能夠在營運長、行銷長以及開發者的多重角色中工作，我想這就是我能在 GitHub 待這麼久的原因。
Swyx [00:03:40]: 顯然，你的提交量增加了。這是怎麼回事？Kyle [00:03:45]: Rui 相當直接地指出了這一點。所以我想，你可以想像，對吧，你可以看到我在 2013、2014 年作為開發者的正常時期，然後轉向管理職位，最終擔任營運長。
我想你看到的是，多虧了 AI，我真正回歸了程式設計。我，類似於將行銷、業務營運和程式設計之間的問題聯繫起來，我發現，建構連接非常不同問題的代理和工作流程是推動這一切的原因。所以，其中一部分是編寫軟體。很大一部分是連接大量不同的資料來源來幫助我。
但這完全是我真正深入 AI 領域，嘗試我們的工具，嘗試每個人的工具，但為我建構，為非技術領導者建構，儘管我是技術出身，以及我們如何能夠使用這些工具，而不僅僅是簡單的呼叫和回應，我認為很多非技術人員，你的雇主，你必須，你必須使用 AI，所以每個人都使用 ChatGPT 或 Copilot 或 Claude 或其他什麼。
要真正深入了解，這將如何幫助我，我發現它不是我需要寫一篇部落格文章，我需要那些簡單的例子。幫助人們找到工作流程，例如：「好的，我需要你今天審查所有的 PR。我需要你審查我們在網路上發布的所有內容。我需要你審查我們過去三個月所做的事情。審查我所有 Obsidian 筆記中提及此事的內容，然後審查我工作中的會議記錄。」
我們使用 Teams，所以，使用 WorkIQ，呼叫那個 MCP 伺服器，抓取所有會議記錄，審查所有 Slack 訊息，然後為我建構本週實際的訊息傳遞計畫。這在以前是不可能的，因為對我來說，我發現 AI 在這次發布中，實際上更多的是向後遞迴循環，而不是向前建構。
我總是先看發生了什麼。回顧本週，告訴我我們做了什麼，什麼有效，什麼無效？然後在接下來的三四天內告訴我，你會根據這種回顧過去然後展望未來的方式做出什麼調整？我發現這對非技術人員來說更有價值，因為這種回顧實際上...
