前言¶
2026 年 8 月 3 日，exe.dev 聯合創始人、Tailscale 聯合創始人 David Crawshaw 在官方博客發表文章《Devtools must be open source》（開發者工具必須開源）。文章很快被推上 Hacker News 熱榜，獲得 500 分以上討論熱度，評論超過 190 條。Simon Willison 等開發者也在個人博客轉述並補充觀點。
Crawshaw 的核心論點並不複雜：當 AI Agent 可以直接讀源碼、改源碼、自動 rebase 上游更新時，「插件 API + 配置文件」這套延續了幾十年的定製範式，正在被另一種更底層的能力取代——源碼本身就是擴展系統。這對正在選 IDE、終端、Coding Agent 的開發者來說，不是哲學辯論，而是實實在在的選型問題。
從「改配置」到「改源碼」¶
Crawshaw 在文中回顧了一個長期存在的現象：多數工程師整天用別人寫的工具寫代碼，卻很少爲自己寫程序。偶爾有人用靜態站點生成器搭博客、用插件改編輯器主題，但真要 fork 一個 Vim 或 VS Code 來加一行「默認顯示行號」，時間成本幾乎沒人付得起。
AI Agent 改變了這筆賬。Crawshaw 給出了兩條可複用的 Agent 提示詞模板：
- 初始化個性化：拉取某軟件的源碼、本地編譯安裝；告知 Agent 今後任何改動都直接改源碼；在版本控制裏記錄每次改動的動機。
- 持續同步上游：用 cron 定時執行——拉取上游更新，將本地改動 rebase 到最新版，驗證可用後替換當前安裝。
關鍵不在「能改代碼」，而在 Agent 可以自動管理 fork 與上游的同步。過去 fork 一次工具，一年後回來維護是噩夢；現在模型可以承擔 rebase、編譯、冒煙測試，個性化軟件的固定成本和持續成本同時下降。
案例：Shelley、meat.dev 與 VS Code 擴展 API 的對比¶
Crawshaw 用自家產品做了兩個具體演示。
Shelley 是 exe.dev 推出的開源 Coding Agent。Crawshaw 團隊把上述兩條提示詞做成了 Agent 的內置 Skill：用戶甚至不需要手動配置 cron，直接說「把 Shelley 的 UI 改成高對比度」即可完成個性化。
meat.dev 是 Crawshaw 的個人 side project：用 LLM 過濾 Git diff 中的「噪音行」（import、nil-check、樣板 error handling），讓人類 reviewer 只看「肉」（架構與業務邏輯）。他希望 meat 在 Shelley 創建 commit 時就在後臺預處理 diff，而不是在終端裏手動跑命令。
他給 Agent 的提示詞大意是：把 meat.dev 集成進 Shelley；安裝到 PATH；Shelley 創建 git commit 時在後臺啓動 meat 處理；在 Diffs 視圖加一個切換開關；處理中則提示用戶等待。
一條 prompt 搞定。 Crawshaw 特意對比：若走 VS Code 擴展 API，要在 commit 創建的同一時刻觸發後臺 LLM 預處理，擴展系統的掛載點幾乎對不上——更現實的方案可能是另起一個 meatd 守護進程監聽文件系統，再讓擴展去讀緩存。能做成，但「曲率」遠大於直接改 Shelley 源碼。
這就是他所說的根本差異：經典定製受限於 API 暴露的形狀；Agent 定製受限於你有沒有源碼。
開源 Agent 與閉源 Agent 的分野¶
文章後半段把討論從編輯器延伸到 Coding Agent 本身。
Crawshaw 認爲，Shelley 上這套 Skill 技巧可以平移到其他開源 Agent，例如 Pi；開源版 Codex 理論上也能做，只是 token 開銷更大。他甚至反問：Pi 還需要內置擴展系統嗎？源碼就是擴展系統。
而 Claude Code 被點名爲例外的反面：閉源，用戶無法讓 Agent 改其核心行爲，只能在廠商提供的 hooks、配置項裏打轉。「希望你的需求恰好落在他們的鉤子裏；否則，換一個能個性化的 Agent。」
HN 熱評裏，Simon Willison 表達了相近感受：以前 clone 一個項目並編譯，摩擦大到常常放棄；現在他會讓 Codex 或 Claude Code 去 checkout 並 build，十分鐘後回來看結果。他尚未習慣「日常改自己用的軟件」，但路徑已經清晰。
社區裏也有實踐佐證：有開發者用 AI 維護 Ghostty 終端的個人 fork——只爲加一個圖形化設置頁，而不是手改配置文件；另有人維護約 6 個工具的私有 fork，靠 Agent rebase 上游，並選擇性把 bug fix 貢獻回上游。
同時，反對意見同樣尖銳：fast-moving 項目 fork 後 merge conflict 仍是現實；「AI slop PR」讓上游維護者更不願合併；插件系統的價值在於可共享、可維護的定製邊界，而不是每個人都養一套私有分支。Crawshaw 本人也在回覆中承認，exe.dev 這類帶大量託管側能力的平臺，全盤開源仍有產品節奏與自託管門檻的問題。
Zed、Ghostty、Cursor：選型地圖上的三個座標¶
原文並未逐一點名 Zed 或 Ghostty，但 HN 討論與開發者社區實踐，把這張地圖畫得更完整。
Zed 是開源、Rust 實現的高性能編輯器，從設計之初就把 AI 協作寫進產品敘事（如 DeltaDB 等方向）。在 Crawshaw 的邏輯下，Zed 屬於「Agent 可以 fork、可以改 UI、可以接私有工作流」的一側。
Ghostty 是 Mitchell Hashimoto 發起的終端模擬器，本身刻意保持簡潔、無插件體系。社區裏的應對方式恰恰是 Crawshaw 論點的活樣本：有人 fork Ghostty，用 Agent 保持與上游同步，並加上內置設置頁；也有人像 Henry Chen 那樣，用 Ghostty + tmux 跑 Agent、用 Zed 做 diff 審閱——工具鏈按角色拆分，終端與編輯器都選可組合、可hack 的開源組件。
Cursor 代表另一條路：閉源 AI IDE，集成度高、開箱體驗好，但核心行爲與模型路由掌握在廠商手中。若你的個性化需求超出官方能力邊界，無法像改 Shelley 源碼那樣「一句話改核心邏輯」，只能等 roadmap 或換工具。
這不是說閉源工具沒有價值——Claude Code 在不少場景下 benchmark 表現依然強勁，許多團隊也在 Copilot、Cursor、Claude Code 與開源 Agent 之間混用。Crawshaw 強調的是：當 Agent 成爲 daily driver，「能否改源碼」從 nice-to-have 變成了 first-class 需求。
對開發者的 practical takeaway¶
Crawshaw 的論斷可以壓縮成三句話：
- 個性化成本驟降：Agent 負責讀代碼、改代碼、rebase、編譯；單人維護私有 fork 從「不理性」變成「可日常化」。
- 插件 API 相對貶值：不是插件無用，而是「API 形狀不對就永遠做不到」的上限，在開源 + Agent 組合下被抬高。
- 閉源 DevTools 的隱性鎖：不是今天就要 fork，而是廠商在賭你永遠不會行使「改核心」的權利；AI 時代這個賭注值得重新評估。
2026 年選 DevTools，不妨多問一個問題：如果下週 Agent 能改它的源碼，我是否拿得到源碼？ 答案爲否的工具，不是不能用，但要清楚自己買的是「配置空間」，不是「邏輯空間」。
開源 DevTools 在 AI 個性化時代獲得的，不是道德優越感，而是結構性的可選權。爭論還會持續——fork 維護、許可證、上游 slop、託管側不可 fork 的子系統，都是真實約束。但方向已經明確：源碼訪問權，正在成爲新一代開發者工具競爭力的一部分。
