擁有更強的模型之後

昨天 7/27，Y Combinator 上傳了一場訪談，由 Managing Partner Diana Hu 訪問 Claude Code 創作者 Boris Cherny。整場談了 Opus 5、Claude Code、長時間運作的 agent 與 AI 時代的工程師，但我覺得可以用一個角度把內容串起來：拿到能力更強的模型之後，我們原本使用 AI 的方法也要重新檢查。

Boris 提到，Claude Code 團隊在 Opus 5 發布時，刪除了超過 80% 的 system prompt。每次有新模型，他們都會重新做 ablation，先移除原有指令，再一行一行加回去，確認每一行是否仍然有作用。他甚至建議 Claude Code 使用者，每隔一段時間可以暫時移除 CLAUDE.md、skills 與 hooks，看看新模型在沒有這些設定時會怎麼做。

這些設定很多是為了修正舊模型的問題。模型當時不會主動讀測試、不懂專案慣例，或者經常在某個步驟失敗，我們便增加一條指令。累積久了，system prompt 看起來像一份完整的最佳實務，裡面其實混合了專案必要規則，以及為舊模型增加的補救規則。新模型可能已經自然具備那些能力，原本的指令反而限制它處理問題的方法。

Boris 建議的順序是先移除、實際使用、觀察失敗，再補回必要的規則。只有當模型反覆在同一個地方出錯，才增加對應的指令。這個做法讓 system prompt 從「預先寫好所有可能用到的規則」，變成根據實際行為持續校正的設定。

所以模型升級不只是把名稱從上一版換成下一版。工具、system prompt、skills、hooks，甚至原本用來評估模型的 eval，都需要重新跑過一輪。模型能力進步得很快，舊 eval 可能在幾代模型後就被跑到接近滿分，無法再告訴我們模型在哪裡有問題。升級模型的同時，也要重新建立自己對它的認識。

第二個建議是給模型更困難的任務。很多人使用 AI 時，會把每個步驟寫得非常細，要求它先做一、再做二、最後只能用某種方法完成。Boris 認為現代模型更適合接收高一層的任務描述：說清楚目標、限制與完成條件，讓模型自己規劃方法。

訪談裡有兩個例子。Bun 團隊讓 Claude 把超過十萬行、原本以 Zig 撰寫的 JavaScript runtime 改寫成 Rust。這項工作持續 11 天，過程中有人引導，大量分析、實作與修正由 dynamic workflow（動態工作流）調度多個 AI agent 完成。另一個實驗是把 Claude 桌面版從 Electron 改寫成原生 Swift。Boris 提供 macOS runner，要求 Claude 同時執行兩個版本、截圖、逐像素比較，沒有符合就繼續修改。受訪時，這個工作階段已經持續超過兩週。

這兩個案例都有一個共同點：模型知道如何檢查自己的成果。Bun 有完整測試套件，桌面 App 有可以反覆比較的畫面。模型每完成一輪，都能取得明確回饋，判斷目前結果和目標之間還有哪些差異，再開始下一輪。

這也是 loop 與 eval 在現在變得更有意義的原因。Loop 必須讓模型經歷執行、觀察、判斷與修正，重複同一段 prompt 並不會自然形成這個過程。Eval 的用途也延伸到執行過程，持續提供方向，讓模型知道哪些部分已經完成、哪些部分還需要處理。如果沒有測試、畫面比較、資料檢查或清楚的成功條件，模型運作兩週也可能只是反覆產生無法驗證的結果。

Prompt 當然仍然有作用，只是工作重心正在改變。以前我們花很多時間研究某個詞該怎麼寫、步驟要怎麼排列；現在要多想一層：模型能取得哪些工具與上下文、如何看見執行結果、失敗時會收到什麼訊號，以及什麼條件代表工作真的完成。模型的自主能力提高之後，loop 與 eval 會直接影響這份能力能否用在真實工作上。

Boris 在訪談中半開玩笑地說，不要聽 LinkedIn influencers，也不要看 Twitter，因為不存在一個能讓所有人成為 AI 高手的神奇技巧。我會把外部經驗視為試驗方向，最後仍要回到自己的任務、資料、限制與驗證結果。

AI 工具變化很快，一個在六個月前有效的技巧，今天可能已經沒有必要。別人的 system prompt、skills 或工作流程，也可能只是為了解決他的模型版本與工作場景。看完 KOL 分享後親自跑一次，保留有效的部分，移除沒有作用的部分，才會形成適合自己的方法。對 AI 的理解很難只靠閱讀累積，它需要持續實驗。

訪談最後談到 CS 學生現在還應該學什麼。Boris 從國中使用 TI-83 計算機開始學程式，先用 BASIC 寫數學解題工具，遇到更困難的 calculus 問題後再去學 assembly。他學習技術的方式一直圍繞著一個想解決的具體問題。

他的建議是，CS 學生仍然要學 computer science，也要學會把技術放進真實世界，包括產品設計、商業判斷、data science、和使用者交談，以及創業與產品開發。當 coding 的執行工作逐漸交給 agent，定義問題、理解使用者、判斷結果是否正確，以及決定什麼東西應該被做出來，都會成為工程工作的一部分。

這也呼應我一直在想的工程師角色變化。寫 code 仍然存在，工程師的工作範圍正在往外延伸。能不能定義對的問題、提供足夠的上下文、建立可驗證的 loop，並判斷 AI 的能力邊界，會決定更強的模型最後能產生多少實際價值。

下一次拿到更強的模型，可以先暫時關閉一部分舊設定，挑一個以前覺得太困難的任務，替它準備可以自行驗證的環境，再觀察它實際做到哪裡。每個人面對的問題不同，親自跑過的結果，才會成為下一輪真正有用的經驗。

資料來源：

Y Combinator：Boris Cherny - Building Claude Code https://www.youtube.com/watch?v=qyPCVqFUyDo

Claude Code 官方文件：How Claude Code works https://code.claude.com/docs/en/how-claude-code-works

Claude Code 官方文件：Automate work with routines https://code.claude.com/docs/en/routines

Garry Tan 談 AI 原生公司：真正的競爭力，是把經驗沉澱成 Skill

 

近期 AI Engineer World’s Fair 上，Y Combinator 執行長 Garry Tan 分享他對 AI 原生公司的看法。他談的重點不只是一個人能生成多少程式碼，而是團隊怎麼把角色、流程、標準與組織記憶接到 Agent 上，讓每次工作都能累積成下一次可重用的能力。

Garry 用組織來解釋 Agent 系統：skill 像一個寫清楚職責的角色，resolver 決定任務由誰處理，檔案規則是內部流程，觸發 eval 則像績效檢查。這個比喻對實際工作有幫助，因為它把焦點從「要用哪個模型」移到「工作如何被定義、分派、驗收與改善」。同一個模型交給不同團隊，產生的效益會受到這些設計影響。

第二層是公司知識庫。Agent 的 context window 再大，也裝不下公司的每封郵件、每次會議、每個客戶案例與決策理由。Garry 把這套系統形容成圖書館加上管理員：知識庫保存內容，管理員依照任務挑出此刻需要的資料。真正困難的地方包括哪些資訊值得保存、兩份資料衝突時採用哪一份、舊資訊何時淘汰，以及每項事實能不能追到來源。

他提出一個很強的工作紀律：做完任務後，把成功方法整理成 skill，避免公司每天重新教 Agent 同一件事。我覺得還得再加上一個判斷。重複發生、交接成本高或出錯風險高的工作，確實該變成 skill；一次性的小事全部變成 skill，最後可能得到一個沒人維護、彼此重疊，而且每次執行都增加 context 成本的目錄。

因此，skill 需要跟程式碼一樣有生命週期。每個 skill 要有清楚的適用情境與不適用情境、負責人、版本、依賴關係、驗收案例和退場條件。流程改變時，相關 eval 要能指出哪些行為退化；模型本身已經能穩定完成時，也可以移除多餘指令。公司知識庫同樣要保留來源、處理衝突、定期淘汰過時資料，否則搜尋能力愈強，只會讓 Agent 更快取得錯誤的 context。

我認為 AI 原生組織的差異，會逐漸出現在這套累積機制。團隊完成一項工作後，能不能把判斷標準、流程與知識留下來，讓下一次執行有更好的起點；又能不能持續驗證這些內容仍然有效。模型能力可以向外購買，組織怎麼工作、如何判斷品質，以及從錯誤中學到什麼，才是公司自己能長期累積的部分。而這也是我認為公司應該要有自己的 FDE 組織的價值，只有公司內的 FDE，才能真正協助 BU 單位建立真正有價值的 AI 流程，並將有價值的 skill 留存下來。

參考資料：

https://www.youtube.com/watch?v=eBUyTS7SzV4

https://github.com/garrytan/gbrain

https://github.com/garrytan/gstack

AI Agent 時代的新瓶頸：不是產出，而是驗收

近期 AI Engineer World’s Fair 有幾場演講都在談同一個問題：Agent 可以很快產生程式碼、文件與各種產物，團隊卻還沒有同樣成熟的方法判斷工作是否真的完成。當產出速度超過審查速度，「完成」這個狀態本身已經不夠用了。

Sumaiya Shrabony 分享她維護一套 19 個 skill 的內容系統，從排程、研究、製作到保存，中間有七次交接。她遇到的危險情況，是產物格式完整、文字看起來也能用，實際上聲音規則不符、數字沒有來源，或開場跟舊內容重複。系統若只檢查檔案存在與欄位齊全，這類產物仍會被送進待發布目錄。她後來加入輸出格式、領域規則、來源驗證、去重與稽核紀錄，整套系統逐漸具備 CI/CD 的基本控制。

Paperclip 創辦人 Dotta 對「完成」的定義更接近一組資料。裡面要有交付產物、適用範圍、驗收標準、完成證據、驗證者、核准權限、剩餘風險與下一個負責人。這個做法讓 Agent 不只把任務狀態改成完成，也讓後續的人知道這項工作依照什麼標準通過、誰做過確認，以及接下來能不能合併或部署。

因為真實的世界有其限制：所有產物都交給人從頭檢查，審查能量很快就會塞滿。eBay 工程師 Sachin Gupta 把這種負擔稱為 ReviewDebt（審查債），並嘗試用變更範圍、測試證據、跨團隊檔案分布與變更理由等可計算訊號，先找出需要較多注意力的 PR。這個方向的重點是把人的判斷留給高風險項目，同時讓一般項目先通過可重跑的機械驗證。

Google DeepMind 的 Philipp Schmid 在 skill eval 分享中也採用類似做法。每個 skill 都需要附上測試案例，變更時在隔離環境重跑，檢查是否在正確情境觸發、產出是否符合要求，也保留不應觸發的反例。很多檢查只需要 regex 或腳本，不必每次再請另一個 LLM 判斷。這讓驗收標準比較穩定，也能在模型或 harness 更新後持續檢查退化。

我覺得企業導入 Agent 的 KPI 可以開始記錄「附可驗證證據的合格交付率」。一次合格交付至少要能回答：產物在哪裡、依什麼標準驗收、哪個驗證程式成功、輸入與版本是什麼、證據能不能重跑、還有哪些風險。產出如果是文章就必須附上來源；如果是程式碼，則可能附上測試與 diff，UI 可能附操作錄影或截圖；不同工作需要不同證據，但都要讓下一個人可以重新判斷產出是否合格。

當 Agent 能大量工作，真正需要擴充的是整套驗收能力。把驗收標準、validator、evidence 與責任歸屬放進工作流程，Agent 的速度才會轉成團隊可以信任的交付，也讓人在需要判斷時看得到完整脈絡。

參考資料：

https://www.youtube.com/watch?v=WLXxTaPagA8

https://www.youtube.com/watch?v=7P0elyLIxXo

https://www.youtube.com/watch?v=TJPInBjhE4Q

https://www.youtube.com/watch?v=0vphxNt4wyk

https://www.youtube.com/watch?v=8G_1-3IO4ZQ

Anthropic 的 8 倍 code 產出，後面真正的問題是組織吃不吃得下

Lenny's Podcast 這次訪談 Fiona Fung，我覺得最有用的地方，不是又多一個「AI 讓工程師更有效率」的案例，而是她把 AI 原生工程團隊的管理問題講得很具體。

Fiona 現在在 Anthropic 帶 Claude Code 和 Claude Cowork 相關團隊。訪談一開始提到一個很令人印象深刻的數字，Anthropic 工程師平均每季產出的 code，大約是 2021 到 2025 年期間的 8 倍。這個數字很容易被拿來當生產力指標，但如果只停在這裡，反而會錯過比較重要的部分。

當 coding 本身不再是最稀缺的環節，瓶頸會移到別的地方。

以前工程組織最常卡在寫 code 的人力不夠。需求排隊、spec 排隊、review 排隊、測試排隊，最後大家都會說工程 bandwidth 不夠。AI coding agent 進來以後，寫 code 這件事的成本大幅度降低，很多原本不值得做的小改動、實驗、內部工具、修 bug，突然都變得可以做。但這不代表組織自動變快。新的瓶頸會出現在 review、驗證、產品判斷、品質定義、跨團隊同步，以及 manager 是否真的看得懂現在正在發生什麼。

Fiona 講到她自己的管理方式時，這點很明顯。她不是只把 Claude Code 當成更好的工具。她會讓 Claude Code 開 remote session，跨 repo、Slack channel、metrics 去整理某個人的關注的領域、最近作出的的產品、收到的反饋、使用者反應、市場 impact，然後用這些資料來做 1on1 面談前的準備。

這個用法對我來說很有啟發。AI 在這裡已經不只是單純代寫 PR，而是讓 manager 比較有機會追上團隊實際工作的速度。當一個團隊裡很多人同時用 agent 做事，傳統靠週會、狀態更新、少數幾個 dashboard 來掌握進度，很快就會不夠用。管理者需要新的觀測機制，不只是系統觀測機制，而是工作觀測機制。

她也提到 routine 的用法。以前早上可能是看幾個 feedback channel、喝咖啡、整理今天要看的東西。現在 routine 可以先幫她整理 feedback、找出需要注意的地方，有時甚至先產出 PR 讓她 review。這代表很多管理工作會從「我親自收集資訊」變成「我設計好問題，讓 agent 先幫我收斂資訊，再由我判斷」。

這件事延伸到 code review 也一樣。

Claude Code Reviews 是 Anthropic 內部後來才多出來的能力，因為當 code 產出大幅增加，人類 reviewer 會變成瓶頸。Fiona 的說法不是讓 AI 全面取代 review，而是把 review 分層。某些重複性、規格型、可驗證的部分，可以交給 AI 先做。某些需要深度 domain knowledge 思考、判斷的地方，仍然要靠人。

這裡的重點不是「AI review 準不準」這麼簡單，而是團隊能不能把好品質寫清楚。她提到，如果 repo 裡有清楚的 spec、framework、標準，Claude 就比較能判斷什麼是好的結果。換句話說，文件、測試、架構原則，不再只是給新人看的 onboarding 材料，也會變成 agent 工作時的重要上下文。而這會改變很多工程實務的價值排序。

以前大家都知道 TDD 好，但很多團隊做不起來，因為寫測試的成本太高，時間壓力一來就先犧牲。當 Claude 可以先幫你寫測試，再用測試帶出實作，TDD 的實務門檻就低很多。這不是因為大家突然更有紀律，而是因為原本最痛的成本被降低了。

招募的部分也很值得分享。

Fiona 講到她現在會看兩種人。一種是很有 product sense 的 builder，能自己想出方向、做出東西、反覆調整，並且對最後的產品體驗負責。另一種是很深的系統專家，能處理模型、架構、效能、安全、複雜平台這些難題。

這跟過去很多公司只用職能切分人才很不一樣。AI 讓更多人可以跨到原本不熟的工作區域，PM 可以更像 builder，designer 可以更接近 prototype，engineer 也必須更懂產品。可是深度專業沒有消失。越是關鍵的底層問題，越需要真正知道細節的人做驗證。

她用的原則是 trust but verify。我覺得這句話很適合描述現在的工程管理。你必須信任 AI 讓更多事情開始動起來，但你不能把判斷責任外包出去。越是用得重，越需要清楚知道哪些地方可以自動化，哪些地方一定要人做最後判斷。

訪談裡另一個我覺得實用的分享，是她談 metrics 的態度。

8 倍的代碼產出聽起來很強，但她也很清楚說，程式碼數量不是完美指標。有些工作本來就會產生大量 code，例如 library migration 或 framework 變更。有些高價值工作反而不會留下很多 code。PR 停留時間也一樣有用，但仍然不完整。

所以她更在意的是指標有沒有服務當下的問題。當團隊開始用 AI 以後，指標也要跟著調整，否則很容易只看到大家在做甚麼，卻看不到真正的進展。

她提到一個品質框架，我覺得非常適合拿回團隊內部討論。Anthropic 會區分 bad experience 和 sad experience。

Bad experience 是很嚴重、不可接受、可能讓使用者失去工作成果的問題，例如 CLI crash 或資料遺失。Sad experience 則是可恢復，但體驗很差的問題，例如畫面閃爍、等待太久、流程卡住。這種分類讓品質討論不只是看 bug 數，而是回到使用者到底遇到什麼狀況，以及哪些問題不應該被當成一般 bug 排隊處理。

我喜歡這個框架，因為它把品質從抽象的 dashboard 拉回產品體驗。AI coding agent 會讓改動速度變快，如果沒有一套共同的品質語言，團隊很容易在更高速度下累積更多使用者不舒服的細節。

這次訪談裡也有一個比較少被討論，但我覺得很重要的面向，就是 AI 原生工作方式的副作用。

Fiona 說，當大家越來越常跟 agent 一起工作，工程工作可能會變得更孤單。Claude Code 團隊後來甚至開始安排 pair-wise programming lunch，讓大家分享自己怎麼用 Claude Code 和 Cowork。這不是為了形式上的 team building，而是因為每個人跟 agent 協作的方式差異很大，這些 tacit knowledge 如果不被交換，很難自然擴散。

另一個副作用是 context switching。當你可以同時讓很多 agent 在背景工作，表面上產能提高了，但你也會得到更多待 review、待確認、待接續的工作。你要記得每個 agent 在做什麼、卡在哪裡、哪個結果可信、哪個需要重來。這會把人的工作從 單純執行變成指揮協作，但指揮協作本身也會變成新的負擔。

所以我不覺得 AI 原生工程團隊只是「大家都買 coding agent 帳號」這麼簡單。

真正要改的是整個工作系統。你需要更清楚的 spec，讓 agent 有足夠上下文。你需要更好的測試，讓產出的 code 可以被快速驗證。你需要新的 review 分層，避免人類 reviewer 被大量 PR 淹沒。你需要新的管理機制，讓管理者能看見更快流動的工作。你也需要新的團隊儀式，讓人和人之間的學習不要被人和 agent 的互動取代。

Fiona 最後談到她最擔心的不是某個產品或工程挑戰，而是文化能不能在快速擴張時維持。這點我覺得很真實。AI 會把很多個人的執行能力放大，但組織能不能承接這些能力，靠的還是共同標準、互相信任、願意爭論、願意在快到終點時回頭看誰需要支援。

很多公司接下來都會說自己是 AI-first 或 AI-native。這些口號不難講，工具也不難買。比較難的是回答幾個更具體的問題。

• 我們的 spec 是否清楚到 agent 可以使用？
• 我們的測試是否足夠快，能支撐更高頻率的改動？
• 我們的 review 流程是否知道哪些交給 AI，哪些必須由人判斷？
• 我們的 manager 是否看得見 agent 協作後的真實工作狀態？
• 我們的團隊是否還有足夠的共同學習，而不是每個人各自和自己的 agent 工作？

這才是我覺得 Fiona 這次訪談最值得帶走的重點。AI 讓寫 code 變得便宜，接下來稀缺的會是判斷、驗證、品質語言、組織節奏，以及文化本身。

工具會讓個人更強，但最後能不能變成團隊能力，還是要看組織怎麼設計工作。

來源：Lenny's Podcast, “Building the most AI-pilled engineering team in the world | Fiona Fung (Anthropic)”, YouTube, https://www.youtube.com/watch?v=Ybrl4FYM57c 。Lenny’s Newsletter episode page and transcript, https://www.lennysnewsletter.com/p/building-the-most-ai-pilled-engineering 。Anthropic 官方 X 貼文提到工程師每季平均產出約 8 倍 code, https://x.com/AnthropicAI/status/2062568864240836995 。

Anthropic 執行長 Dario Amodei：AI 為何需要像飛機一樣被監管？

2026 年 6 月 10 日，Anthropic 執行長 Dario Amodei 發表新文章〈Policy on the AI Exponential〉，主張 AI 進步的速度遠遠超過政府立法的速度，並且提議該用管飛機的方式來管 AI。文章一開頭他借《魔戒》裡那棵走路、講話都很慢的樹人 Treebeard 來比喻政府在政策制定上的動作：AI 用四年從「連一行像樣的程式都寫不出來」，變成「在主要 AI 公司裡包辦了大部分的程式碼」，但國會要推動一條法案往往要好幾年。

但是，真正讓我想寫這篇文章的，是 Dario 整篇文章透出來的那種對於 AI 深信不已的信念。Dario 不是把 AI 當成又一個很強的軟體工具，他是真心相信 AI 會變成「a country of geniuses in a datacenter」（一整個資料中心的天才之國），在認知工作上全面超過人、變成人類腦力的通用替代品。他把 AI 拿來跟核武、工業革命並列，說它會重設整個地緣政治的棋盤。文章裡有一句：一個有強 AI 的國家對上沒有強 AI 的國家，差距就像是二戰的美國海軍陸戰隊對上一群拿劍的中世紀士兵。會這樣寫的人，心裡對 AI 的認定的絕對不只是「工具升級」，是典範轉移等級的改變。

我個人也覺得這個信念是真的，不是行銷話術。Dario 自己在文章裡反過來拒絕「AI 只是公關問題、需要更好的行銷」這種說法，他說大家會怕 AI 是因為風險真的存在。他舉的具體證據是 Anthropic 自家 Claude Mythos Preview 在資安攻防上展現的能力，他說這證明 AI 已經是「具有全球與國家戰略後果的工具」。一個會把自家模型的能力講成國安威脅、還主動要求政府應該有權擋下自家產品上市的人，我覺得是很難說他只是在演戲。

但是，到底會不會真的走到那一步，另一派有完全不同的看法。a16z 的合夥人 Martin Casado 長期的論點是：AI 的影響力大概就跟微晶片、跟網路同一個等級。很大、會改變很多產業，但它畢竟還是工具。他公開說自己不是 AGI 那一派的，覺得 AGI 這個詞反而讓討論失焦；他把現在的 AI 形容成「感覺像 1996 年」，意思是還在很早期、後面還有很長的路要走。他做了一個有趣的算數：AI 要競爭的對象其實是人腦，而人腦只用 15 瓦、又便宜又有效率。在這個計算框架下，AI 只是一個成本被壓得很低的工具，不是一個新的智慧生命。

這兩種看法差距非常明顯，而且現在還沒辦法判斷誰對。我自己比較靠近後面這種：AI 是我這些年看過最強的工具，但「工具」這兩個字我還是想留著。它跟網路、跟 iPhone 一樣，會重新分配誰有生產力、會長出新的公司和新的工作，可是它終究要有人去用、去指揮它做什麼。Dario 描繪的那個「比所有人都強、還會自己把自己愈做愈好」的版本，有沒有可能發生？有可能，我不敢說一定不會。但把「有可能」直接當成「已經是現狀」來規劃，跟 Casado 講的「先看清楚多出來的風險再動手」，中間的作法差很多。

不過講到要不要監管，我反而覺得不用先吵贏「AI 到底是天才之國還是高級工具」這一題。有意思的是，兩派講監管時抓的比喻其實是同一組。Dario 拿汽車、飛機、藥物來類比，說 AI 該像美國聯邦航空總署（FAA）管飛機那樣，超過一定運算規模的模型，上市前要先過第三方安全測試，政府有權擋下或召回不合格的模型。Casado 那一派則拿網路來類比，說當年網路出現新型威脅（像電腦蠕蟲）時，我們是看清楚「相對於既有系統多出來的那部分風險」才動手，主張用證據、不要用生存焦慮去立法。

可是網路這個比喻，其實同時也是支持監管的理由。網路一開始也被當成「只是一個很強的工具」，結果這二、三十年我們還是替它建了一大堆規矩：個資保護、網路犯罪、平台責任、反壟斷。社群平台的推薦演算法在過去十幾年對社會做了什麼，大家也都還記得。所以用「它只是個工具、跟網路一樣」這句話，並不會推導出「不用管」，反而正好說明我們最後一定會去管它，就像我們管每一個夠強的工具一樣。你不需要先相信 AI 會變成資料中心裡的天才之國，才會覺得這東西需要被治理；一個很強、很多人手上都有、又確實能造成真實傷害的工具（Dario 舉的那個資安能力已經是真的），這個理由就夠了。

真正要小心的不是「該不該管」，而是「誰來寫規則」。Dario 的提案一出來，Steven Sinofsky 這些人馬上點出 regulatory capture（監管俘獲）的疑慮：當被監管的公司自己跳出來設計監管，而且這套規則剛好對資本雄厚的大公司（Anthropic、Google、Microsoft）比較有利、對小新創比較難跨過門檻時，你就得多注意了。想要監管，跟想要好的監管，是兩件不同的事。

所以我讀完這篇的感想是，大家現在花很多力氣在吵 AI 到底是神還是烤麵包機，可能吵錯了方向。網路當年也「只是個工具」，我們照樣替它寫了幾十年的法規。AI 會不會強到取代人，這題可以慢慢辯論；但它需要被好好管理這件事，這應該是無庸置疑的。比起要多害怕它，我比較在意的是這支筆最後握在誰手上。

資料來源：

Dario Amodei〈Policy on the AI Exponential〉：https://darioamodei.com/post/policy-on-the-ai-exponential

a16z, Martin Casado〈The Economic Case for Generative AI and Foundation Models〉：https://a16z.com/the-economic-case-for-generative-ai-and-foundation-models/

The Generalist 對 Martin Casado 的訪談〈This feels like 1996〉：https://www.generalist.com/p/this-feels-like-1996-martin-casado

Every AI 自動化案例：為什麼員工從 4 人增加到 30 人？

Every 是 Dan Shipper 自己創的媒體與軟體公司，從 2020 年起到現在 6 年多。他們從 GPT-3 那一刻就開始把 AI 塞進每個工作流程，包括寫稿、編輯、客服、設計、行銷、工程，Codex 跟 Claude Code 是預設的工作介面，新模型還沒對外公開他們就先拿到 alpha。理論上這是「自動化到極致」最徹底的活樣本。結果他在 2026-05-21 發了一份報告 After Automation，標題說的就是「我們什麼都自動化了，但人卻變多了」，從 GPT-3 時代的 4 人擴到現在 30 人。隔幾天他上 Lenny's Podcast，端出一組明顯逆主流的預測，這篇我想分享 3 個最有實質意義的。

第一個是反直覺事實本身。Dario Amodei 公開預測 AI 會在幾年內讓 50% 的入門級白領工作消失，Citadel 的 Ken Griffin 也說在看到「極高技能職位正被自動化」。Every 提出的數字卻站在相反方向。Dan 給的解釋走的是結構性論點，AI 訓練資料是「過去人類專家做出來、能被明文記下來的東西」，模型擅長壓縮並重現這些東西，但越擅長壓縮，默認輸出就越像，「跟其他人的 AI 輸出長一樣」這件事變成新常態。當默認品質爛大街，人對「不一樣」的需求暴增，而「不一樣」目前只能由人來判斷。瓶頸從生產位移到審查跟判斷。Apollo 首席經濟學家 Torsten Slok 最近也在追蹤同一個現象，他把這稱作勞動市場版的 Jevons Paradox：當一項服務成本下降，市場規模反而擴大，就業人口跟著增加，這是 19 世紀煤炭效率提升後的歷史模式。Every 把這個機制變成可觀察的內部數字，6 年從 4 人到 30 人，自動化程度跟人數一起上升。

第二個是 Forward Deployed Engineer (FDE) 這個職位的崛起，這跟第一個機制是同一件事的延伸。Google CEO Sundar Pichai、Box CEO Aaron Levie 最近都公開說 FDE 是 2026 最難招的職位。Lightcast 的職缺資料顯示 FDE 從 2024 年底約 200 個職缺到 2025 年底翻了 5 倍以上，TeamLease Digital 估全球 FDE 需求年增 800%。原因藏在 MIT NANDA 那份 2025 報告：95% 的企業 GenAI pilot 沒有可衡量的商業影響，問題出在部署層而不是模型本身。能寫一個會跑的 LLM API call 是一回事，能在客戶的 RBAC、合規、舊系統、髒資料、人為流程裡讓 agent 真正產生價值是另一回事，這需要一種混血工程師，既懂模型、又願意進客戶辦公室裡 debug 五個禮拜的整合問題。Palantir 在 2009 年就發明這種角色，後來 Q1 2026 法說會講出 85% 年增、商業營收 133% 年增的數字，市場才正視「派駐客戶現場部署模型」這件事能跑出多大規模。OpenAI 直接成立 Deployment Company 把 FDE 業務獨立出來，Google Cloud CEO Thomas Kurian 也宣布在 GTM 團隊裡新設 AI 專責 FDE 組織，面試流程從 4-6 輪壓到最少 2 輪。同一份 Lightcast 資料顯示 mid-level FDE 起薪 30 萬美金總包，senior 過 50 萬，FDE 已經是 AI 時代的 staff engineer 等級稀缺資源。

第三個是 SaaS 不死，這條反直覺得最徹底。主流敘事是 agent 會 bypass 所有 SaaS 介面直接 call API，所以 SaaS 公司會被取代。Dan 的看法相反，他直接說「我現在就會買 SaaS 股票」。Every 自己的 SaaS 開支是過去三年一路成長，而不是下降，原因是每個 agent 都是一個高頻 SaaS user。一個人類員工可能一天開幾次 Salesforce，但 agent 可以一秒打十次 API、一天填 200 個工單、自動產出帶完整 reproduction step 的 bug report。GitHub 2026 年因為 agent PR 暴增已經吃力到要重寫底層，這就是 SaaS 廠商現在最具體的訊號：誰能處理「人類跟 agent 同時用」的併發場景，誰就是接下來幾年的贏家。產品該往的方向是把 UI 分成「人類版」跟「agent 版」、加 rollback log、加 approval inbox、開 BYO token 讓使用者把自己的模型 token 帶進來，而不是貼一層 AI 還自己扛 token 成本。這個方向反而提升 SaaS 毛利，因為 AI 算力成本不在你家。

Dan 真正的論點是：AI 自動化把「執行」變便宜，但同時把「判斷」「框問題」「在組織裡讓模型真的有用」這三件事的價值推高。Every 那 30 人裡頭多出來的位置是寫手、編輯、FDE、盯著 agent 輸出做判斷的人，不是行政、不是 PM 堆疊。他在 podcast 裡有句話我覺得是這集最重要的：「Data is the visible residue of competence。」模型學的是過去專家留下的痕跡，等模型學會的時候，活著的專家早就走到下一個地方了。這個結構不會在某個版本停下來，就算到了 AGI 階段也一樣，只要模型訓練的是過去，現在的判斷力就有人類的位置。

Dan 跟 Lenny 約好一年後回節目對答案。一年前他預測 Claude Code 對非工程師會起飛、被很多人當熱話，後來 Anthropic 推 Cowork、OpenAI 推 Codex Desktop 印證了他的判斷。這次他的預測範圍更大，涵蓋 SaaS 不死、CLI 過時、Codex 是新 OS、FDE 是新核心工程角色、自動化越多人越多。我不知道一年後對得起幾條，但這幾條都值得放進今年自己的工作判斷裡。如果你在組織裡能扮演 framer、能把模型輸出變成有人會買的東西、能在客戶現場讓 AI 真的跑起來，今年到明年你的價值將會非常高。

來源：

- Dan Shipper, After Automation (Every, 2026-05-21): https://every.to/p/after-automation

- Lenny's Podcast: The AI paradox - More automation, more humans, more work | Dan Shipper (2026-05-24): https://www.lennysnewsletter.com/p/the-ai-paradox-dan-shipper

- MarkTechPost: What is a Forward Deployed Engineer (2026-05-20): https://www.marktechpost.com/2026/05/20/what-is-a-forward-deployed-engineer-the-ai-role-openai-anthropic-and-google-are-hiring-in-2026/

- The Pragmatic Engineer: Forward deployed engineering heats up again (2026-05-24): https://blog.pragmaticengineer.com/the-pulse-forward-deployed-engineering-heats-up-again/

- Yahoo Finance: AI Automation Creates More Expert Work Not Less (2026-05-23): https://ca.finance.yahoo.com/news/ai-automation-creates-more-expert-215306141.html

- The Times: The 19th-century paradox that gives hope for jobs in AI (2026-05-25): https://www.thetimes.com/business/economics/article/jevons-paradox-jobs-ai-s59fsndxt

工程師還需要刷 LeetCode 嗎？Sierra 新面試流程引發討論

Sierra 4 月公開他們把白板題、演算法題、原本的 coding 電話面談 全砍的細節，換上的東西更值得關注。

Bret Taylor（OpenAI 董事會主席、前 Salesforce co-CEO、Google Maps 共同創造者）跟 Clay Bavor 2023 創辦的 Sierra，4/22 在官方 blog 發了一篇 "The AI-native interview"。他們原本的工程師面試是 2 場 coding、1 場 algorithms、1 場 system design、1 場 culture，五輪標準大廠流程。他們把前三場合併成一場 onsite，分三個階段：Plan、Build、Review。

Plan 階段是面試官跟候選人坐在一起，由候選人主導、定義一個要做的產品。面試官的角色是一直追問把想法問清楚，題目限定在候選人自己的領域 — 這樣才看得到產品思維。Build 階段面試官離開，候選人單獨 2 小時，用任何 AI 工具、任何 框架把這個產品做出來，明確被告知「可以中途 pivot、可以砍功能」。Review 階段面試官回來，候選人 demo，討論 product flow、code review 看 data model 跟 abstraction 的取捨、討論到產品還缺什麼，並且明確問「你怎麼用 AI 的」。

這個流程改變的不是面試題目，是面試在測的東西。以前測的是「能不能把腦中的演算法翻譯成程式語言」、「記不記得二元樹怎麼寫」 — 而這兩件事 AI 現在做得比任何人都快。Sierra 在 blog 裡說：當寫 code 的瓶頸被 AI 解決，工程師的價值來自「結合技術能力、產品思維、商業 context」。換句話說，定義要做什麼、做取捨、跟客戶迭代到能交付影響 — 這些事 AI 還做不了，所以面試就改測這些。

另外兩個改動我覺得也值得單獨講。原本的 coding 電話面談 是「不能用 AI、線上 editor 寫 code」，他們把這場直接砍，換成系統設計。Sierra 自己的解釋是：「vibe-coding an app is easy. The harder, more relevant problem is getting it into production in a scalable way.」這句話比新流程本身還有意義 — 他們承認單純會 vibe-coding 已經沒有分辨力，能不能上線到正式環境才是真難題。

第二個改動是 debugging interview pilot。AI-native onsite 測的是 0→1 的能力（從零做出一個產品），但工程師日常做更多的是 1→N（在既有的、有點亂的 codebase 上加功能）。他們現在試一個新關卡：給候選人一個中型 codebase + 一個同事提交的 draft PR，要候選人 pull 下來、跑起來、用 coding agent 迭代把它改好。能不能在雜亂的代碼裡找到方向、能不能跟 AI 工具配合修出可合併的東西 — 這個能力在大型專案裡其實比寫新功能還重要。

最讓我多想一會的不是流程本身，是 Sierra 在文章裡講的這句：「Our debriefs have shifted from 'should we hire this person?' to 'where would this person thrive, and how do we support them?'」面試結束後的討論從「錄不錄取」變成「他會在哪裡發揮、需要什麼支援」。這對應的是 hiring philosophy 的轉變 — 從「找完人沒有明顯短板」變成「找出每個人的 spike 跟 gap」。當每個工程師可以靠 AI 補上自己不擅長的部分，組織就不再需要「全能型」的人，反而是「有強烈 spike」的人更值得簽下來。

對求職者意義很直接。如果你還在練習刷 LeetCode，你訓練的能力 AI 已經比你做得好。值得花時間練的是：在白紙前主導一個產品討論、在 2 小時內取捨什麼該做什麼該砍、做完能辯護為什麼這樣設計、能說清楚自己怎麼用 AI 配合做出來。這些事在 Sierra 面試裡會被直接看到，在其他公司也會越來越會被看到。

Sierra 自己承認新流程不完美 — 沒有標準產出的格式很難標準化。他們用與結果無關的評價標準 + 雙人面試彼此參照結果解決。其他公司要不要複製、用什麼方式對應標準化成本，很困難。但「測 AI 做不了的事」這個方向，是目前看到最有意義的動作。

---

來源：

- The AI-native interview, Sierra blog (2026-04-22): https://sierra.ai/blog/the-ai-native-interview

- Sierra AI Just Reinvented the Software Engineering Interview, Quasa (2026-04-28): https://quasa.io/media/sierra-ai-just-reinvented-the-software-engineering-interview-and-it-s-brilliant

- Working at Sierra in 2026, JobsByCulture (2026-05-20): https://jobsbyculture.com/blog/working-at-sierra-2026

- Hiring engineers in the age of AI, DEV Community (2026-05-24): https://dev.to/b0gy/hiring-engineers-in-the-age-of-ai-4peg