Simon Willison：軟體工程在 11 月跨過了門檻，「暗工廠」正在成形

本文整理自《Lenny's Podcast》2026 年 4 月 2 日播出的單集，受訪者為 Django 共同創造者 Simon Willison，他也是 Datasette 開源工具作者，並在 2022 年首次為「prompt injection」這個攻擊類別命名。本系列共三篇，這是第一篇談 11 月拐點與「暗工廠」模式，第二篇談中段工程師被夾擊的求生建議，第三篇談致命三角與「挑戰者號災難」預言。

{{< youtube wc8FBhQtdsA >}}

{{< spotify "episode/0DVjwLT6wgtscdB78Qf1BQ" >}}

{{< apple-podcast "tw/podcast/an-ai-state-of-the-union-weve-passed-the/id1627920305?i=1000758850377" >}}

---

11 月那個讓所有工程師假期破功的拐點

Simon Willison 在訪談一開頭就回顧整個 2025 年。他的判斷很直接：那是 Anthropic 與 OpenAI 同時意識到「程式碼就是這個世代的應用層」的一年。Anthropic 在 2025 年 2 月推出 Claude Code，意外發現有大量工程師願意每月付 200 美元訂閱，這個市場訊號讓兩家實驗室把所有強化學習的火力都壓在程式碼任務上。整個 2025 年，模型的訓練資源、紅隊測試、評估基準幾乎都圍繞著「能不能寫出可以跑的程式」這件事。

到了 2025 年 11 月，GPT-5.1 與 Claude Opus 4.5 幾乎同時上線。Simon 說，這兩個模型就絕對能力來說只是漸進式的進步，但它們跨過了一個「門檻」：先前的 coding agent「大部分情況下能跑、但你必須緊盯著」，到了 11 月之後，模型變成「幾乎都能照你說的去做」。差別聽起來很微妙，落在實際工作流上卻是天壤之別。在這個門檻之前，工程師啟動一個 coding agent 是「有風險的賭博」；在這個門檻之後，你可以告訴它「幫我做一個 Mac 應用程式做這件事」，回來的東西通常還能再迭代，而不是一坨跑都跑不起來的垃圾。

這個門檻效應，Simon 說，是讓 2026 年 1 月、2 月一大批工程師「假期破功」的原因。耶誕假期裡有興趣摸這些工具的人，回到工位時都帶著同一種震驚：「這東西真的能用了。」他自己對這個轉變的描述更直白：今天他寫的程式碼大約 95% 都不是自己打字打出來的。更誇張的是工作場景，他經常在海邊遛狗的時候用手機上的 Claude Code App 啟動代理，「我在手機上寫程式的比例高到很瘋狂」。

Vibe coding 是什麼，又不是什麼

跨過拐點之後，業界對「人跟 AI 一起寫程式」這件事的詞彙開始失序。Simon 花了不少篇幅幫 vibe coding 這個詞畫界線，因為他擔心這個本來很有意義的詞被泛用之後就失去溝通價值。

vibe coding 這個詞最早是 Andrej Karpathy 提出的，原意非常具體：你完全不看程式碼，連基本的 review 都不做，純粹「跟著感覺走」，給模型一句話、看它產出、能跑就好。Simon 認為這個用法本身很美，因為它降低了「自動化生活中無聊事情」的門檻。不會寫程式的人現在可以告訴 Claude 「幫我做一個小工具」，幾分鐘後就有東西可以用。對非工程師來說，這是一場真正的解放。

但他同時也立下了一條使用者責任界線。他的原話是：「如果你是在 vibe coding 一個只有自己會被 bug 傷到的東西，盡情去玩；但只要你 vibe code 的東西開始給其他人用，當你的 bug 可能傷到別人，你就必須退一步，問自己這樣做對嗎？」這句話聽起來簡單，背後的判斷其實很需要經驗。要分辨什麼情境下 bug 只會傷到自己、什麼情境下會牽連到別人，這本身就是資深工程師才有的直覺。比方說，你 vibe coding 一個爬蟲爬別人的網站，可能就因為流量打太兇而傷到別人的伺服器，你卻不知道。

問題是，當 vibe coding 被泛用到所有「碰到 AI 的程式工作」上，這個詞就等於程式設計本身了，因為大家現在或多或少都會用到 AI 工具。Simon 因此提出他偏好的另一個詞：代理工程（agentic engineering）。這個詞要強調的是「代理」這個關鍵元素，也就是 Codex、Claude Code 這類能寫程式、跑程式、debug 程式、執行測試的完整工作流，跟單純去 ChatGPT 問一段程式碼複製貼上是兩回事。Simon 說，他現在在自己的部落格上一章一章寫一本關於代理工程的書，因為這是一個值得用整本書來說明的學問。

StrongDM 的「暗工廠」：沒人寫、沒人讀

訪談裡最讓人印象深刻的案例，是 Simon 介紹的「dark factory」概念，我們翻成「暗工廠」。這個詞借自製造業：當一座工廠的自動化程度高到不需要人在現場，理論上你可以把燈關掉，機器自己在黑暗裡運轉。Simon 把這個比喻搬進軟體開發，要描述的是兩條政策的疊加：第一條是「沒有人能用鍵盤打程式碼進電腦」，第二條是「沒有人會去讀那些被產生出來的程式碼」。

第一條規則 Simon 自己半年前還覺得很瘋狂，現在他覺得完全合理。畢竟他自己 95% 的程式碼也都不是手敲的。今天的模型已經好到你直接告訴它「幫我把這個變數改名、加一行、把這段 refactor 一下」，它執行的速度比你自己打字還快。第二條規則才是真正前衛的部分，而 StrongDM 是 Simon 點名的先驅。這家公司做的是企業權限管理軟體，是非常資安敏感的領域，但他們從 2025 年 8 月開始貫徹「不讀程式碼」的政策。

要怎麼讓沒人讀過的程式碼可以放心上線？StrongDM 的答案是把 QA 部門完整地用代理重建出來。傳統有 QA 的公司會把工程師寫好的東西丟給品保部門人工測試，但這個職位在過去十年的矽谷已經逐漸消失，因為大家認為工程師應該對自己的程式碼負責。StrongDM 等於是把那個被消滅的角色用 AI 招回來，而且把它放大到「永不睡覺」的程度。他們的做法是讓一群模擬員工代理在一個模擬的 Slack 頻道裡 24 小時不停發出請求：「能不能幫我開通 Jira」「我需要 Slack 的權限」，所有真實使用者會做的事，全部由代理代勞。

更瘋狂的是那個被測試的環境本身。StrongDM 沒有用真的 Slack、Jira、Okta 來跑這些測試，因為那些 SaaS 都有頻率限制，不可能讓你同時跑一萬個假員工。所以他們乾脆把整套企業協作工具的 API 都重新模擬了一遍。他們把 Slack 和 Jira 公開的 API 文件、開源客戶端函式庫丟給 coding agent，讓代理「複製」出一個假的 Slack、假的 Jira，連介面都 vibe code 出來給內部使用。整套模擬環境一旦跑起來就是個小小的 Go binary，不需要再付任何外部成本。Simon 說他在 2025 年 10 月去看過 StrongDM 的展示，他們每天花在代理測試上的 token 成本大約是一萬美元。一萬美元一天聽起來嚇人，但對一家上線後不容許資安事故的公司來說，這個保險費非常划算。

對 Simon 來說，StrongDM 的案例不是要你照抄整套基礎設施，而是要你接受一個範式轉移：當「人類審查程式碼」不再是品質保證的主要機制，你必須創造新的機制來補位，而代理測試、代理 QA、代理紅隊都會在這個空缺裡長出來。

瓶頸搬家：構想與品味才是稀缺品

當「寫程式碼」這個原本最耗時的步驟突然變得很快，整條軟體開發流程的瓶頸就會搬到別的地方去。Simon 認為今天的瓶頸明顯在前端：構想本身。

一個產品工作者都知道，最初的構想多半是錯的，重點在於驗證。過去因為原型成本高，你只敢做一兩個版本，反覆試錯。Simon 現在的習慣完全不同：任何要設計的功能，他會同時 prototype 三個版本，因為 ChatGPT 跟 Claude 可以幾分鐘內就生出像樣的 UI。他的觀察是，今天還在做產品設計但還沒開始 vibe code 小原型的人，等於少用了這代工具最大的紅利。

但這也帶來新的問題：當你手上有三個都能跑的版本，你怎麼決定哪個最好？Simon 對 AI 模擬使用者測試這件事抱持懷疑。他覺得 ChatGPT 假裝點擊你的原型、給你回饋，這件事的可信度遠不如真人在 Zoom 上分享螢幕做可用性測試。產品的「品味」這一段，目前還是一個必須留給人類的判斷，AI 只能加速到「給你三個選項」這一步。

這種瓶頸搬家還影響到資安研究。過去三到六個月，OpenAI 與 Anthropic 都做出了專門做資安研究的內部模型，因為這類模型如果開放給大眾就等於變成入侵工具，所以採邀請制，只給註冊有案的安全研究員使用。這些代理已經能找出真實的漏洞，Simon 提到 Mozilla 不久前釋出的 Firefox 安全更新，就修補了 Anthropic 安全團隊用代理找出的大約一百個潛在漏洞，由 Anthropic 的人類研究員逐一驗證後才提交給 Mozilla。這種「代理找洞、人類複核」的協作正在資安圈造成震撼。

代理工程的日常實踐：囤積、紅綠 TDD、薄樣板

Simon 在訪談中分享了他自己每天怎麼用代理寫程式，這部分對想要落地的工程師非常實用。他的核心日常工具是 Claude Code，特別是 Claude Code for web 這個雲端版本，因為它跑在 Anthropic 的伺服器上，他可以放心開啟「dangerously-skip-permissions」這個被內部稱為 YOLO mode 的模式，讓代理不再每兩分鐘問一次「我可以執行這個指令嗎」。代理在不斷被打斷的安全模式下像「永遠在鬧的學步兒」，但在 YOLO 模式下你可以同時跑四個代理，去泡杯茶回來看成果。Simon 把私密程式碼留在自己的筆電 Claude Code 上做最後審查，把 95% 不那麼敏感的工作丟到雲端版本去跑，搭配 GitHub 的 Pull Request 機制做最後 review。

第二個工具是「囤積你會做的事」（hoarding things you know how to do）。Simon 的職涯智慧是：你做為工程師的價值，來自一個夠大的「我試過、可以用」的方法庫，新問題出現時，你能組合過去的解法。AI 把這套智慧放大成一個具體的工程實踐：他在 GitHub 上的 simonw/tools 倉庫已經累積 193 個小型 HTML/JavaScript 工具，simonw/research 倉庫則放滿用 coding agent 跑出來的研究報告（重點是「跑過程式碼」的研究，不是「LLM 嘔吐物式」的純文字 deep research）。當他遇到新問題，他會直接告訴 Claude Code「去看 simonw/research 裡面跟 WebAssembly 跟 Rust 有關的東西，用那些東西去解決這個新任務」，代理就能自己 grep、組合、引用。

第三個是「紅綠 TDD」（red/green TDD）這個壓縮 prompt。Simon 自己說他人生大部分時間都討厭測試驅動開發（先寫測試、看它失敗、寫實作、看它通過），但他發現代理特別吃這套：你叫它先寫測試再實作，產出的程式碼品質會明顯提升。問題是寫一段「請先寫測試、確認失敗、再實作、再確認通過」的指令很冗長，Simon 後來發現只要打「red/green TDD」這四個字，代理就懂了。這就是這個時代很有趣的一個發現：有些幾秒鐘就能打完的行話，在 prompt 裡的價值大到不成比例。

第四個是「薄樣板優於厚 CLAUDE.md」。代理特別會「抄」現有程式碼的風格，所以 Simon 每個新專案都從一個極薄的樣板開始：裡面只放一個測試 1+1=2、加上幾行他偏好的格式樣式。代理看到這個樣板就會自動模仿，整個專案都會貼著他喜歡的風格走。他不喜歡寫長篇大論的 CLAUDE.md，因為一個示範檔案勝過一千字的指令。他在 GitHub 上分別準備了 Python 函式庫、Datasette 外掛、命令列工具的薄樣板，需要時 fork 一份就開始。

鵜鶘騎腳踏車：一個玩笑變成全行業基準

訪談的最後，Simon 講了一個很能總結他這個人風格的故事：他用「請畫一張鵜鶘騎腳踏車的 SVG」這個荒謬的問題當作模型基準測試。一年半前他做這個基準是為了反諷那些「在 Terminal-Bench 拿 72 分」的數字基準，因為光看一個分數很難真的告訴你模型強在哪。SVG 不是測圖像模型，是測文字模型的空間推理能力，因為模型必須用向量座標把鵜鶘和腳踏車的關係畫出來，這對沒有真正空間感的語言模型很難。

奇妙的是，模型畫鵜鶘騎腳踏車的能力，竟然跟它整體能力呈現很強的相關性。這個基準變成了一個業界都認可的「能用」訊號，連 Google 在 Gemini 3.1 的發表會上都放了一段鵜鶘騎腳踏車的動畫。Simon 因此偷藏了「ocelot 騎機車」「長頸鹿開小車」這種備用版本，準備抓哪家實驗室專門針對鵜鶘做過特訓，結果 Gemini 3.1 連備用題都解出來了。Simon 說，他原本就只是想要一張漂亮的鵜鶘騎腳踏車圖，如果為了騙到所有實驗室都針對他的基準作弊，就達成了他的目標。

這個故事為什麼重要？因為 Simon 認為，要在 AI 浪潮裡活得好，「擁抱荒謬感」是一個被低估的特質。我們手上有人類史上最昂貴、最耗能的計算機，請它畫鵜鶘騎腳踏車卻像幼稚園小孩塗鴉。這件事很可笑，他喜歡把這份可笑當作工作的一部分。許多工程師對職涯轉變充滿焦慮，Simon 反而玩得很開心，這份輕盈感本身就是他生產力的一部分。

我的觀察

我自己讀完這集，最在意的不是「11 月拐點」這個敘事本身，而是這個拐點在臺灣產業的感受落差。

矽谷工程師在 1 月、2 月放假回來震驚於「這東西真的能用了」的時候，臺灣很多公司還在盤算要不要花錢買 Claude Code 訂閱。差距不只是工具導入的時間差，而是「容許工程師在上班時間 vibe code 自己想試的東西」這種文化的落差。Simon 在訪談裡反覆強調，他的 simonw/tools 倉庫裡有 193 個工具，許多都是當下隨手做、後來在新問題裡派上用場。一個整天被排滿衝刺會議、要求每行 code 都對應一張 ticket 的工程組織，根本不可能長出這種「囤積式智慧」。

第二件事是「暗工廠」對接案文化的衝擊。臺灣有大量中小型軟體外包廠商，靠的是把人時打包賣出去；當客戶端開始接受 StrongDM 那種「沒人寫、沒人讀」的工作流，按 manhour 計價的整個邏輯就要重新談判。這未必是壞消息：能展示「我用代理工程把過去三人月的專案壓進兩週」這種能力的公司，反而能脫離削價競爭，重新拿回定價權。但前提是組織要先完成 Simon 描述的那種日常實踐：囤積方法庫、用紅綠 TDD 跟代理對話、用薄樣板讓代理一致地產出風格穩定的程式碼。

最後一點是 Simon 在訪談中沒明說、但我從他的工作型態讀出來的：拐點之後，「個人工程師的產出力」可能會比「組織工程師的產出力」放大得更快。Simon 一個人能用四個並行代理，做掉以前要一個工作小組才做得完的事。當這種模式擴散，臺灣那種「找一個技術合夥人就能撐起整家公司」的早期新創團隊，很可能會迎來新一波創業窗口。