After Code

GTM engineer

2026-09-02T13:21:16.337+08:00

近期，AI Engineer YouTube 頻道在 8/27 集中分享了許多關於 GTM 的影片，裡面有不少公司把自己如何找客戶、理解客戶、安排銷售流程和導入 AI 的做法講得很具體。我想很值得把這些內容整理一下分享，而過程中最明顯的感受是，GTM 目前仍然很難。難的地方不在於能不能生成一封 email，而在於公司能不能知道該找誰、何時聯絡、用什麼內容、由誰負責，並且在錯誤發生時把影響控制住。

Notion 的 Flora Liu 把 GTM 描述成分散式系統問題。客戶只有一段旅程，公司裡的行銷、銷售、客戶營運和產品團隊卻各自使用 Salesforce、Gong、Outreach、ZoomInfo、Snowflake、筆記和文件等工具。資料可能互相衝突，重要資訊可能藏在會議紀錄裡，外部工具之間也會產生延遲。比如 champion 已經離職、客戶要求暫停聯絡，這些資訊如果只存在一份非結構化筆記裡，下一個流程就可能做出錯誤決定。

Cloudflare 的 Justin Joyce 看到的是另一種困難。傳統 GTM 團隊經常在 Excel、Google Sheets、CRM 和 dashboard 之間切換，dashboard 可以回答固定問題，卻很難回答每個業務正在面對的特殊情況。新人缺少資料與產業脈絡，資深業務則要把時間花在重複分析。這個問題讓 AI agent，也就是能根據目標自行執行多步驟工作的 AI，有機會進入 GTM 流程，但前提是 agent 必須理解公司的商業規則和資料定義。

所以，產生了 GTM engineering 這個概念，重點放在 CRM 之外的整體系統。Ramp 把它定義成，團隊先描述一個市場推進方案，再讓系統找出受眾、產生內容、啟動不同渠道，最後交給負責人審核；Notion 則把它寫成 Know、Decide、Act、Learn 的循環；Exa 直接把 GTM 當成資料問題。這些做法都在處理同一件事，如何把原本分散在不同部門和工具裡的工作，整理成可以被資料驅動、被 agent 執行、被人審核和被結果修正的流程。

Ramp 的做法很接近「從一個想法直接走到一套 GTM 行動」。分享裡的例子是找出美國東岸建築業、喜歡打高爾夫的目標客戶，再針對這群人準備 Pro V1 高爾夫球、主動開發流程、廣告文案、網站內容和產品內通知。團隊不用分別把這個想法交給行銷、業務、廣告和產品團隊處理，系統先把它組成一個完整方案，再由各渠道的負責人確認是否適合執行。

Ramp 認為，這套做法的基礎是 customer data platform，也就是把客戶、產品、CRM、公司資料、網站行為、購買訊號、募資、招聘、email、會議和通話紀錄放在一起的資料層。Ramp 會用即時事件、交易資料庫、資料倉庫與反向資料同步，把不同來源的資料送到需要使用它的流程。會前 brief 是一個具體例子，系統會整理參與者、職稱、會議目標、產品使用狀況、帳戶健康度、客戶 email 和未解決的 ticket。

Exa 的 Jeffrey Wang 將這個問題再往外延伸。Exa 需要建立一個持續更新的市場模型，裡面有客戶、人物、產品使用量等內部資料，也有公司、新聞、招聘、募資和技術棧等外部資料。Exa 會把公司描述轉成可比較的向量，替目標市場裡的公司分類，判斷它們屬於模型供應商、AI coding 平台或 GTM intelligence 等類別，再針對特定帳戶深入研究。這種做法讓 GTM 團隊處理整個市場，而不只是一份固定名單。

Exa 的 Request Lens 會把市場資料轉成可行動的提醒。當目標公司註冊、搜尋量突然增加、使用量下降，或重要帳戶出現在系統裡，團隊可以收到通知，再決定要不要研究、聯絡或調整客戶策略。這和固定每週匯出名單的差別，在於系統開始追蹤「什麼事情改變了」，而不只是保存「目前有哪些公司」。

Clay 的 Everett Berry 也把帳戶視為持續變動的市場 entity。公司可能被收購、換辦公室、推出新產品、增加招聘，聯絡人也可能離職或更換，因此 CRM 裡的帳戶狀態不能只在建立時填一次。Clay 使用 waterfall，讓多家資料供應商依序填補缺漏欄位，再用評估比較不同供應商的準確度，並依照欄位的變動速度選擇更新頻率。這些資料工作會直接影響 agent 是否找對人、寄對訊息和判斷對帳戶。

Clay 還提到 entity resolution，也就是確認不同系統裡的資料是否指向同一家公司或同一個人。如果這件事沒有做好，同一個人可能被當成兩個對象，Salesforce 和 Outreach 的同步也可能因為時間差而重複執行。對 GTM agent 來說，資料品質不只是欄位有沒有值，還包含資料來源、更新時間、可信程度，以及每個 entity 和其他記錄的關係。

Notion 的資料架構提供了另一個實作方向。Snowflake 負責計算 accounts、contacts、workspaces、eligibility 和 facts 等資料，DynamoDB 則提供低延遲的客戶 profile，同時保存研究摘要和其他生成內容。Notion 也把資料同步回熟悉的工作介面，讓團隊能在相同的資料基礎上研究帳戶、回答問題，再把任務送往 Nooks 或 Outreach。這樣的設計把資料計算、資料提供和團隊操作分開，讓每一層都能有清楚的責任。

Cloudflare 的做法是把公司的商業規則寫成 skill files，也就是 agent 可以依照執行的技能檔案。當業務問「為什麼成交日期或金額改變了」，agent 要先理解公司的成交定義、金額計算方式、區域劃分和時間範圍。Cloudflare 也建立集中管理的 skill repository，由 GTM 和營運團隊共同審查，避免每個部門各自建立一套互相衝突的規則。這些內容看起來不像 AI 功能，卻決定了 agent 能不能在同一套商業語言下工作。

有了資料和規則，下一個問題是什麼時候該行動。Notion 將 signal 定義成足以改變下一步的事件，例如使用者碰到 AI 使用上限、填寫 contact sales、公司開始招聘，或外部出現募資和技術棧變化。系統會先判斷行動和負責人，再建立人或 agent 的任務；沒有明確事件時，才使用預測模型推薦功能、生命週期 email 或產品內訊息。這讓 GTM 流程從固定排程，變成依照客戶狀態調整。

Cloudflare 採用的是「查詢、推送、自助」並行的方式。需要答案時，使用者可以讓 agent 查資料；需要團隊掌握狀況時，系統每週主動產生 business summary；需要建立新流程時，GTM 人員可以在 Cloudflare OS 裡產生 forecast brief、QBR 簡報、purchase deck、account plan、renewal 和 upsell 分析。這個內部工作空間建在 Workers 和 Durable Objects 上，重點是讓不同角色都能直接使用相同的資料和技能。

Cloudflare 的每週 summary 會經過多個 agent 處理。第一個 agent 產生草稿，第二個 agent 檢查資料正確性，第三個 agent 針對語氣、風險與機會重新整理，最後才推送給團隊。Cloudflare 報告整體效率約提升 2 倍，但也承認報價、審批和 Salesforce 寫入仍然很難放心自動化。這說明 GTM 的工作量可以由 agent 放大，但涉及對外承諾和正式資料寫入仍需要更嚴格的控制。

Ramp 把這種控制放進可恢復的工作流程裡。它使用 Temporal，把每個工具呼叫和模型呼叫記成可以重試的步驟；如果背景 worker 失敗，流程可以從中斷的地方繼續，不需要整個任務重新開始。夜間的背景 agent 可以替每個帳戶準備會議資料，遇到需要人工判斷的地方就暫停，等人補充資料或批准後再往下執行。這讓自動化從一次性的 prompt，變成可以長時間運作的工作流程。

Clay 的圖形化流程則把 agent、工具、條件判斷、程式碼和批次處理組成一個執行圖，再連到 CRM、資料倉庫、寄信工具、撥號工具、通話紀錄和 Slack。Clay 進一步提出每個帳戶各自擁有長時間運作的 agent，平時休眠，收到新的 signal 或固定檢查時間到來時再被喚醒。這種設計能持續累積帳戶脈絡，但也要求系統清楚區分哪些 CRM 欄位可以自動更新，哪些欄位必須由人或固定規則管理。

Notion 在這裡保留了更明確的人機邊界。Agent 可以研究帳戶、整理上下文、草擬 email、建立任務和推薦下一步，人則判斷內容是否正確、現在是否適合聯絡，以及這個行動是否會影響客戶關係。Notion 預設不讓 agent 直接和客戶聊天，sales-assist 的行動仍需要人批准。Notion 分享的早期結果是，加入客戶上下文的推薦，讓使用者採取下一步的機率提高 63%。

Clay 提醒，文案生成通常只佔 GTM agent 工作的一小段。錯誤的 CRM 同步、重複寄信、客戶已安排會議卻沒有停止其他活動、寄信網域信譽受損，都會直接影響商業結果。Ramp 也把報價、審批和 CRM 寫入列為較難自動化的區域。只要 agent 開始對外發送訊息，資料錯誤就不再只是內部回答品質問題，而會變成客戶體驗和收入風險。

Snowflake 的 Sait Izmit 從內部 GTM assistant 的部署經驗，說明了信任要怎麼建立。這套 assistant 已經服務超過 6,000 名使用者，每週約回答 40,000 個問題，累積超過 100 萬個問題。Snowflake 一開始先收集 150 個真實 sales 問題，初始正確率約 50%，因此先把回答範圍縮小，優先把少數高頻問題做到可信任，再逐步增加資料和能力。

Snowflake 採取先試用、再擴大的方式。團隊先讓 AI-native 使用者試用，再開放給約 10%、600 人的 beta 群組，觀察資料需求和每週留存，最後才全面推出。Sait Izmit 提到，初期只有約 20% 的人嘗試產品，因此他花了大量時間進入 sales meeting、做 demo、展示 dashboard，並請主管協助推動。這個案例說明，企業 agent 的導入包含產品設計、品質驗證、教育和管理支持，使用率本身不能直接代表產品成敗。

Snowflake 也接受系統需要持續重構。這套 assistant 的架構在演進過程中約有 80% 被重寫，團隊從長篇 agent instructions、Cortex Analyst 和 semantic views，逐步加入評估測試、routing、skill library、MCP、記憶、排程與 Slack 介面。團隊也把使用者問題分類，從真實問題裡找出功能缺口、資料缺口和品質問題。對一個每天處理數萬個問題的系統來說，問題紀錄本身就是產品設計的輸入。

Sourcegraph 的 Stephanie Jarmak 把這種評估往 agent 的使用體驗延伸。Sourcegraph 建立 CodeScaleBench，讓 agent 執行數百種軟體開發生命週期任務，比較有沒有 code-navigation MCP 時的成功率、錯誤、token 和延遲。MCP 是讓 agent 呼叫外部工具的介面協定。她舉例說，agent 把參數名稱搞錯後雖然能自行修正，卻浪費了一整輪工作。對 agent 來說，文件裡一個不清楚的參數名稱，就是 GTM 流程裡的額外摩擦。

Sourcegraph 也做了 GEO 測試。GEO 是讓 AI 搜尋更容易找到、理解與引用產品內容的方法。當問題是一般性的產品比較時，Sourcegraph 約有 65% 的推薦率；當問題改成「修改共用函式庫時常破壞下游服務，因為看不到所有使用者」這種具體痛點時，Sourcegraph 卻完全沒有被提到。Stephanie Jarmak 的判讀是，產品功能可能存在，網站內容卻沒有把產品和使用情境連起來。這個測試讓 AI 搜尋的曝光問題，從排名問題變成產品定位與內容證據問題。

Inth 的 Christopher Burns 把這件事做成產品文件策略。Inth 維護開源的 cookie consent library c15t，團隊從使用者問卷發現，Claude、ChatGPT、Codex 和 Gemini 開始成為重要的 inbound 來源。Burns 因此把 agent-facing discoverability，也就是讓 agent 找到並理解產品的能力，做成一套工具組，包括手寫的 llms.txt、sitemap、每頁 markdown、WebMCP、package docs 和 AGENTS.md。

Inth 的做法有一個很實用的細節。Burns 說，手寫約 40 行有用內容的 llms.txt，在他們的測試裡比自動產生 1,000 行雜訊更有價值；coding agent 常常會直接讀 repository 和 node_modules，不一定會開官方網站，所以把文件一起放進 package，再用 AGENTS.md 指示 agent 如何找到，反而能減少理解成本。他們報告在不同模型上接近節省 50% token，這些數字是講者分享的內部測試結果。

Exa 也從另一個角度處理 agent 的分發問題。Jeffrey Wang 認為內部與外部系統都應該先提供良好的 API，讓 agent 可以透過程式穩定存取資料，也減少對人工操作介面的依賴。Exa 的 GTM 團隊在 Slack 中使用多個 coding agent，業務可以讓 agent 研究帳戶和製作 demo；Jeffbot 則把 email 寫作風格和過去決策整理成可重複使用的個人工作方式。這表示分發對象已經多了一種，產品要進入 agent 的選擇和執行流程。

AI 也改變了企業買方的 GTM 節奏。Aliisa Rosenthal 以她早期參與 OpenAI 企業市場 GTM 的經驗說，ChatGPT 上線時沒有 SSO、NDA 和 invoice 等企業功能，OpenAI 在企業需求很強的情況下，約 9 個月後先推出 enterprise 版本，幾個月後再推出 self-serve。後來 self-serve 成長更快，也對 enterprise 方案形成影響。她回頭看，較好的順序可能是先讓 self-serve 使用者暴露產品缺口，再補上企業功能。

Rosenthal 也分享過一個 inbound 處理失敗。當時 4 名 sales rep 一天收到約 10,000 個 inbound，團隊沒有及時收集電話、寄出自動回覆或處理 waitlist，導致部分企業客戶等不到回應，最後選擇 Microsoft Copilot。她因此建議把帳戶研究、sequence 和 dialing 交給工具與 agent 協助，讓 sales rep 把時間留給已經具備資格、需要信任和判斷的對話。

她對企業採購流程的建議也很具體。企業可以把 trust portal、NDA、滲透測試文件和 AI 資安問卷做成可非同步取得的資料，降低買方等待時間；可以用 reference customer、部分資料評估、custom demo 或 opt-out clause 取代所有漫長 POC；價格則可以採用 base license 加 usage，並提供 spend cap。她分享 OpenAI 早期曾以每位使用者每月 60 美金設定 Enterprise 價格，後來調整計價方式，目標是降低客戶開始使用的阻力。

當研究、資料整理、草稿和基本執行都逐步自動化，人仍然會留在幾個位置。Notion 讓人批准高風險的 sales-assist 行動，Cloudflare 把報價和 CRM 寫入列為難題，Clay 關注寄信網域信譽和跨渠道停止發送規則，OpenAI 則認為高單價 enterprise deal 仍需要 demo、會議和客戶 champion 的信任。自動化讓人從重複工作移開，也讓人的責任更集中在客戶信任、價值判斷和關鍵承諾。

這也解釋了新角色為什麼會出現。Sourcegraph 把 DevRel 延伸成 Agent Advocate，工程負責介面、MCP 和評估，Product 負責完整 agent 體驗，Marketing 則追蹤產品是否被 agent 找到和推薦。Exa 的 GTM 團隊則由 FDE，也就是 Forward Deployed Engineer，直接進入客戶場域協助導入與維護 AI 系統；非 FDE 的 GTM 人員則學會使用這些系統。這個角色的價值，在於把客戶問題、資料、產品能力和工作流程接起來。

如果要把這些公司的做法轉成一套落地順序，我會先選一個可以驗證的工作流程。Snowflake 從 150 個真實 sales 問題開始，Ramp 先做單一團隊的會前 brief，Notion 先處理 cold outbound 和 sales-assist，這些案例都從明確任務開始。先把成功條件、資料來源、人工介入點和錯誤處理寫清楚，再增加其他帳戶與渠道，團隊才知道每一次擴張帶來了什麼。

接著要把上下文資料的責任寫清楚。Exa 把市場、客戶和決策資料放在一起，Clay 處理帳戶變化、供應商資料和 entity resolution，Cloudflare 把商業規則寫進 skill files，Notion 則在資料中保留 owner、時間戳和 eligibility。這些資料工作不一定會出現在產品 demo 裡，卻會決定 agent 的回答能不能被相信。

再來是把人工責任寫進流程。Notion 讓 agent 草擬但不直接對客戶行動，Ramp 讓工作流程在需要時暫停，Clay 將可自動更新的 CRM 欄位和人類管理的欄位分開，Cloudflare 對 CRM 寫入與審批保持保留。這些設計都先回答三個問題：agent 可以做什麼，必須停在哪裡，錯誤發生後誰負責。

最後是把評估和結果紀錄當成產品的一部分。Sourcegraph 用 agent friction、token、延遲和成功率評估文件與工具體驗，Snowflake 從真實問題找出品質缺口，Cloudflare 為每週 summary 加上事實檢查和模型觀測。當同一個問題重複出現時，Ramp、Cloudflare 和 Inth 的做法都指向同一個方向，把人工解法整理成可重用的 skill、自助流程或產品文件，讓下一個人可以自己完成。

從 Notion、Cloudflare、Exa、Ramp 和 Clay 的案例來看，GTM engineering 的競爭力會逐漸集中在四件事：公司是否掌握可信任的客戶上下文，是否能把上下文轉成正確訊號，是否有可靠的跨工具工作流程，以及是否把人的判斷和責任放在適合的位置。模型能力會持續變化，這四件事卻會在每一次 GTM 執行裡累積影響。

GTM 目前仍然很難，因為它同時牽涉市場判斷、資料品質、客戶關係、內部協作、工具整合和商業責任。Cloudflare、Exa、Notion、Ramp 和 Clay 的做法讓我看到，AI 的作用在於把困難的部分逐步寫進資料、流程、權限、評估和產品裡。當 agent 可以替團隊做更多研究、整理、草擬和執行，GTM 團隊要回答的問題也會變成：我們是否知道要讓什麼事情發生，以及怎麼證明它正在發生。

來源：

The Death of Developer Advocates, Stephanie Jarmak, Sourcegraph

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

How AI Agents Let GTM Teams Scale, Justin Joyce, Cloudflare

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

Knowledge Systems: The New GTM Stack, Jeffrey Wang, Exa

https://www.youtube.com/watch?v=6pbQgnJ9Voc

How We Got LLMs to Recommend Our Open Source Library, Christopher Burns, Inth

https://www.youtube.com/watch?v=V_5bn4q-vAI

Building GTM AI Agents: Lessons from Deploying to 6,000 Users, Sait Izmit, Snowflake

https://www.youtube.com/watch?v=DrTdD-ttjCY

The Building Blocks of GTM Orchestration, Ramp

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

AI in GTM at Notion, Flora Liu

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

GTM Engineering: The Technical Bits, Everett Berry, Clay

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

Reverse-Engineering the AI Buyer, Aliisa Rosenthal, Acrew Capital

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

擁有更強的模型之後

2026-07-28T11:33:51.541+08:00

昨天 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

2026-07-18T14:57:51.102+08:00

近期 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 時代的新瓶頸：不是產出，而是驗收

2026-07-18T10:41:35.130+08:00

近期 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 產出，後面真正的問題是組織吃不吃得下

2026-06-22T09:32:02.246+08:00

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-06-11T10:57:32.837+08:00

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 人？

2026-05-29T08:50:04.444+08:00

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 新面試流程引發討論

2026-05-28T00:56:18.955+08:00

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

「中國工程師才是真工程師」：Palmer Luckey 真正想說的是什麼？

2026-05-28T00:52:54.707+08:00

Palmer Luckey 在胡佛研究所那句「中國工程師才是真工程師」，真正該注意的是後面那段論述。

5 月 7 日錄製、5 月 20 日上線的 Uncommon Knowledge，Anduril 創辦人 Palmer Luckey 跟主持人 Peter Robinson 聊了 53 分鐘，標題下得很聳動，但他真正的論點不是中美對立，而是一條清楚的因果關係：當你長期只做高層次的設計、把實作丟給別人去做，最後連設計能力本身也會跟著流失。

Luckey 自己講的原文是這樣：「我們已經不教工程師怎麼做工程了。我們在教他們當 high-level 設計公司，把設計結果丟給中國真正的工程師，由他們去搞定怎麼真的做出來。」他講的不是製造線上的鎖螺絲，是電子工程師、機械工程師越來越只會挑零件、擺一個 nominal layout，但「我這條生產線要怎麼建？這塊板子要改幾版才能過 EMI 認證？」這些事都不再做。久了之後，原本的「設計」也只剩下挑選別人做過的元件。他舉的例子是 Apple — 以前 Apple 真的會自己想怎麼把東西做出來，現在大多數真正困難的工作是中國工程師完成的。

這個因果關係在硬體業講了好幾年，但讓我在意的是它跟 AI 寫 code 的對應關係。當工程師越來越只負責「描述意圖、收 PR、看結果」，把規格落實成可運作 code 的部分交給 AI，這跟美國電子業把製造交給深圳基本上是同一個劇本。短期來看你速度更快，長期來看你會逐漸失去判斷力 — 不知道某個架構決定為什麼會在實作層撞牆，不知道某個 API 設計為什麼會讓三個月後的擴展變痛苦。Apple 把製造交給富士康沒有立刻變笨，是花了 15 年才被人指出來「他們已經不會自己想怎麼做了」。軟體工程的版本，可能會比 15 年快。

Luckey 的另一個論點我覺得更值得細看。他說，創新跟製造是不能切開的：「你以為可以保留創新能力，把實作外包出去，但長期下來，創新能力會跟著實作能力一起流失。」這在企業組織裡也成立。太多公司把核心系統「外包給顧問團隊」「外包給乙方」，理由是「我們專注在 product / business，技術交給專業的」。三年後想要把系統收回來自己做的時候，發現公司裡已經沒有人懂這個系統了，連改一個欄位都得回頭找原本的外包商。Luckey 講的是國家層級的版本，但邏輯是一樣的。

Anduril 自己的反例就是 Arsenal-1。他們在俄亥俄 Pickaway County 蓋的 5 百萬平方英尺工廠，3 月開始量產 FURY 自主戰鬥機，目標是用汽車業的量產工具做武器，年產數萬台自主載具。重點不是「自製多炫」，是他們明確選擇把「怎麼真的做出來」這件事留在公司內部 — 用自己的錢、用自己的工程師、用自己的產線。Luckey 在訪談裡講為什麼這樣做：「如果我們連自己 Pentagon 用最多的筆電都是聯想做的，那我們已經不在跟中國競爭的軌道上了。」

Anduril 在台灣的動作可以這樣看。2025 年 8 月 Luckey 來台大演講、設立辦公室、跟中山科學研究院簽 MOU，跟中光電等 ODM 開始合作。他在那場演講講的話跟胡佛訪談是同一條邏輯：「製造手機、相機、筆電的技能，跟製造大規模自主彈藥、無人機、感測器需要的技能驚人地相似。」台灣的 ODM 體系是少數還同時保有「會設計也會做」的雙重能力的地方 — 從筆電、手機、伺服器到光學模組，這套能力是真的還能整套運作。Luckey 不是因為地緣親近選台灣，是因為這個能力在全世界已經很罕見。

回到工程師個人。如果你接受 Luckey 的論述（製造跟創新不能分），那 AI 寫 code 的時代有一件事值得想：把產出交給 AI 沒問題，但把判斷也一起交出去就不行。判斷力來自親自做過、踩過坑、看過真實環境怎麼出問題。當你願意親自寫一段、親自 debug 一次、親自把一個系統從零搭起來，這些經驗會回到你做設計、做 review、做架構決策的能力上。把這件事完全外包給 AI，省下的時間是真的，消失的判斷力也是真的。

---

來源：

- Palmer Luckey on Uncommon Knowledge, Hoover Institution (2026-05-20): https://www.hoover.org/research/palmer-luckey-wants-america-win

- 訪談影片: https://www.youtube.com/watch?v=--Ef5Q-3Iq8

- 狐說八道中文整理: https://www.anduril.tw/real-engineers/

- Anduril Industries Business Breakdown, Contrary Research (2026-04-28): https://research.contrary.com/report/anduril

- Palmer Luckey 台灣大學演講全文 (2025-08-04): https://www.anduril.tw/palmer-luckey-ntu/

- 美國國防新創 Anduril 來台設辦事處, 數位時代 (2025-08-04): https://www.bnext.com.tw/article/84085/anduril-palmer-luckey-speech

軟體工程師不會被 AI 取代，但是角色和能力正在改變

2026-05-26T10:22:51.308+08:00

這幾年 AI agent 把寫 code 這件事從工程師的核心動作，變成可以指派出去的步驟。寫 code 不會消失，但它從工程師最大的時間花費，退到日常輸入的一部分。當這件事發生，工程師的價值點會跟著移位。我想從技術、角色、context engineering、能力四個面向，講這個位移是怎麼發生的。

過去幾十年我們評斷一段 code 寫得好不好看三件事：效率、正確性、可讀性。這三件事的隱含主詞都是人，跑這段 code 的機器要快、邏輯要對、未來接手的同事要看得懂，團隊協作的成本決定了這些判準。但現在最先接手這段 code 的對象經常是 AI。它要讀懂你寫了什麼、知道你想做什麼、然後往下延伸或重寫。code 的好壞因此多了一條判準：你給 AI 的東西能不能讓它正確接手。

這條判準的重點落在 code 之外的那份文件。spec-driven 開發在這裡變得關鍵。一份寫得清楚、把意圖、邊界、預期行為講明白的規格，能讓 AI 產出對的程式碼。一份模糊的、靠團隊默契填空的規格，AI 接到只會猜，然後猜錯。過去工程師「會寫」這份文件是加分項，現在是必要條件。

連帶地，工程師個人的能力核心也在移動。過去比的是「你 coding 寫得多快、多好」，未來比的是「你能不能設計一套 agent harness 來指揮 AI 做事」。這裡講的是 builder 級的設計能力。Builder 級要面對的是：怎麼切任務讓 AI 不會搞混、怎麼設停損避免它跑偏、怎麼讓多個 AI agent 平行做事還能合得起來、怎麼把錯誤回饋餵回去讓下一輪做得更好。這套設計能力過去不存在，現在是工程師能不能拉開差距的關鍵。

角色端的變化則要看你原本走哪條路。技術型工程師那條路最大的特色是系統架構能力，這件事沒變。怎麼把一個複雜系統拆成可以維護、可以擴張、可以容錯的模塊，怎麼選資料庫、怎麼設計 API 邊界、怎麼讓服務之間溝通乾淨，這些事 AI 還做不到。它可以幫你實作其中某個組件，但不會替你決定整個系統長怎樣。技術型工程師的價值在這層判斷上，這條路在 AI 時代沒有變窄。

PM 型工程師那條路變化比較大。過去這個角色的位置是需求的聆聽者，聽客戶或產品 PM 講想要什麼，翻成技術可行的方案，再找方法去執行。重點在聽、翻譯、執行。未來這個角色要變成需求的討論者。客戶說的「需求」往往只是他自己對解法的猜測，工程師要從中還原他真正的「意圖」，也就是他想解的問題是什麼、為什麼這對他重要、不解會怎樣。理解了意圖之後，重點是找 solution（解決方案），也就是真正解掉客戶問題的路徑；method（執行方法）只是達成 solution 過程中的選項之一。這個位置實質上就是 Forward Deployed Engineer（FDE），帶著 AI 工具到客戶現場，邊問邊做邊調整，幫客戶把意圖落地。

除了 spec-driven 跟 agent harness，還有一層新的工程設計面向冒出來，叫 context engineering 架構。過去做軟體系統，我們設計的是資料怎麼流、服務怎麼切、狀態怎麼存。AI 進來之後，系統裡多了一個會「思考」但需要被餵 context 才能做對事的角色。問題是 context 從哪裡來？怎麼確保使用者在過程中產生的脈絡，他剛剛做了什麼、為什麼這樣做、他現在卡在哪，被正確保留下來，等到 AI 要做事的時候能讀懂？

這層架構過去不存在。它要決定的是：系統在哪些點記錄使用者的動機、在哪些點記錄他的決策、這些訊號怎麼儲存、AI 需要時怎麼撈出來。設計得好，AI 能聰明地接續使用者的脈絡，知道他真正想完成的事，給出對的回應。設計不好，AI 每次都從零開始猜，輸出讀得通但對不上使用者真正要的東西。

這件事跟 prompt engineering 不是同一層。Prompt engineering 是當下這次互動怎麼跟模型講話，context engineering 是整個系統怎麼把使用者的歷程留下來讓 AI 在任何時刻都能讀懂。

最後是能力面。這層其實在前面三件事裡已經出現過，但值得單獨拉出來講。

第一個是理解跟溝通能力被同時放大兩次。你要對人聽懂他真正想做什麼，這部分過去就重要，未來更重要，因為 AI 把翻譯成 code 的部分接走了，前面這段「聽懂並還原意圖」變成更核心的動作。你還要對機器，用 spec、prompt、context 把這個意圖翻成 AI 能正確執行的指令。兩端都得要強，才能讓需求真正被落地。

第二個是 AI 邊界的識別能力。AI 在它熟悉的範圍裡可以快速試很多方案，可以把可讀性、效能、邊界情況都顧到。但它無法替你判斷哪些事它做得到、哪些事它在編造你看不出來的東西。能準確說「這個交給 AI 做、這個千萬不能讓 AI 做」的工程師，產出品質會跟「丟給 AI 看結果如何」的工程師差非常多。

這兩件事過去都算 senior 工程師的隱性差異，現在是所有層級都要面對的明確分水嶺。

把這四件事擺在一起，方向就清楚了。技術評斷在變，角色職責在變，多了一層 context engineering 的設計面向，能力的比重也在重新分配。四件事都圍繞同一條軸線：能不能定義對的問題、能不能給 AI 對的 context、能不能判斷 AI 的邊界。寫 code 這件事還在，工程師也還在。只是工程師價值的中心，從產出 code 移到了這條軸線上。

AI 會取代軟體工程師嗎？最新數據顯示職缺反而增加

2026-05-26T09:08:25.152+08:00

David Sacks 說當 AI 將寫程式變的成本異常便宜，工程師職缺反而變多了。從數據來看，的確他是對的，但只講了一半。

事情是這樣。前白宮 AI 與加密貨幣事務主管 David Sacks 上週日在 X 上發了一篇文，問了一個看起來反直覺的問題：AI coding agent 已經能自己開發功能、開 PR、跨專案 debug 了，為什麼軟體工程師的職缺不減反增？他自己給的答案是「AI 大幅降低了寫程式的成本，同時也造成現在要管理的程式碼比以往任何時候都還要多」，還引了一個數字，GitHub 上的 commit 年增 14 倍。這篇被 Hugging Face 執行長 Clément Delangue 轉發，被到處廣傳。

先說我認同的部分。Sacks 講的其實是經濟學上的 Jevons 悖論：當一個東西的使用效率變高、成本變低，總用量通常不會下降，反而會上升。1865 年 Jevons 觀察到蒸汽機燒煤效率變好之後，整個社會的煤消耗量不減反增，因為便宜讓更多原本不划算的用途變得划算。套到軟體上就是，寫一個功能從兩週變成三天，公司不會說「太好了，可以裁掉八成工程師」，而是把那些一直擱著、以前不值得做的東西全部撈出來做。

數字確實撐得起這個說法。GitHub 的 commit 從 2025 全年約 10 億，到 2026 預估會衝到 140 億，每週 2.75 億筆，這就是 Sacks 講的 14 倍。AI 開的 PR 半年內從每月 400 萬暴增到 1700 萬。美國勞工統計局（BLS）預估軟體開發者職位 2024 到 2034 會成長 15%，遠高於全職業平均的 3%，而且報告裡直接點名 AI 是需求推力。今年初軟體工程師的職缺也確實年增約 11%。所以「AI 讓程式碼總量爆炸、進而推升工程師需求」這個方向，是有實際數據支撐的，不只是猜測，也不只是口號。

問題在「工程師職缺變多」這句話，把一件真正需要注意的事情掩蓋掉了：增加的職缺，到底是哪一種工程師？

把同一批資料拆開看，會發現成長幾乎全部集中在資深和 AI 專長這一類需求。

入門職缺從 2022 的高點減少了大約 67%。史丹佛 AI Index 2026 的數字更直接，22 到 25 歲的軟體開發者就業人數，從 ChatGPT 出現後掉了將近 20%，而資深開發者的人數持續成長，衝擊完全集中在最資淺這一層。新鮮人現在只佔大型科技公司新進人數的 7%。換個角度看職缺結構，入門職缺佔比從 8.1% 滑到 7.4%，資深職缺佔比則從 38.8% 爬到 43.1%。一般軟體工程師的職缺量比 2020 年的基準還低了快一半，真正在成長的是 AI/ML 工程師，年增 59% 到 85%。所以總量是成長的，但工程師人力需求底部在減少、頂部在增長。

再來是第三件事，也是我覺得最該想清楚的：Sacks 拿來解釋職缺成長的那個機制，「要管理的程式碼變多了」，剛好就是把剛入門這條路堵死的同一股力量。當每個人都用 AI 一天產出三倍的程式碼，瓶頸就從「寫」搬到了「審查、整合、確認這東西在正式環境會不會出問題」。而審查和架構判斷是資深工作。AI 接手的那些寫 template 程式碼、修小 bug、補測試的工作，正好都是過去新人用來練功、慢慢變成資深的那條路。GitClear 的資料也顯示，AI 產生的程式碼每個 PR 平均有 10.83 個問題，人寫的是 6.45 個，寫出來的量更大，要人檢查的地方也變得更多。

這就帶出一個五到七年後可能會浮現的問題。資深工程師都是先做過資淺的活才變資深的。如果現在這條入門的路被 AI 大幅壓縮，等到要補這些資深人力缺口的時候，能夠往上補的人，已經因為這幾年入門被收窄而變少了。需求在增長，但能滿足需求的供給，不一定跟得上。

所以 Sacks 沒講錯，AI 確實在把整個軟體業的餅做大。我只是覺得，當一個說法讓人鬆一口氣的時候，特別值得看它把什麼東西藏在底下。對已經在業界、能用 AI 把自己變成三倍產出的人，這是最好的時代；對剛畢業、還在找第一份工作的人，同一份數據就變成另一個故事。而這兩件事是同時都成立的。

來源：

David Sacks 原始論點與 14 倍 commit 數據：https://www.benzinga.com/markets/tech/26/05/52765410/former-wh-advisor-pushes-back-on-job-loss-fears-says-ai-has-dramatically-lowered-the-cost-of-writing-co

GitHub commit／AI PR 量與 GitClear 品質數據：https://byteiota.com/github-ai-agents-275m-commits-are-breaking-the-platform/

軟體開發者就業預估 +15%：美國勞工統計局 BLS Occupational Outlook https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm

22–25 歲開發者就業 -20%：史丹佛 HAI AI Index 2026 https://hai.stanford.edu/ai-index

職缺結構（入門 8.1%→7.4%、資深 38.8%→43.1%、IT/CS 年增 14.2%）：ZipRecruiter 資料（WSJ 報導），轉引自 https://www.metaintro.com/blog/tech-jobs-rebound-2026-it-cs-postings-up-entry-level-shrinks

入門職缺 -67%、新鮮人佔比、一般 SWE 與 AI/ML 職缺消長：jobsbyculture 2026 職缺分析 https://jobsbyculture.com/blog/junior-developer-crisis-2026

微軟取消使用 Claude Code

2026-05-23T10:43:58.669+08:00

微軟給員工試用 Claude Code 六個月，經過這段時間後，工程師大多選了 Claude Code；但是，微軟卻決定把它砍了。大多數報導抓的角度是公司政治和商業套利，但我認為這則消息最重要的訊號不是那裡，而是在成本。

真正的重點是 token 計費的成本已經讓公司撐不住。Hedgie（@HedgieMarkets）點出微軟砍掉 Claude Code 的原因是 token-based billing 讓成本變得無法承受——連一家擁有近乎無限雲端資源的公司都撐不住。而且這不是個案。Uber CTO Praveen Neppalli Naga 證實，Uber 在四個月內就燒光了整個 2026 年的 AI 預算，原因正是 Claude Code 的採用率從 32% 一路衝到 84%（一個 5,000 名工程師的組織），每名工程師每月 API 成本落在 500 到 2,000 美元之間，Uber 自己的說法是「回到白板重新規劃」。

所以可以清楚看見：工具越好用、採用率就會衝得越快，但是 token 帳單也會衝得越快。微軟和 Uber 是同一個現象的兩個資料點，agentic coding 的「按 token 計費」模式正在撞上企業預算的天花板。

回到事件本身。2026-05-14，The Verge 的 Tom Warren 獨家報導: 微軟 Experiences + Devices 部門副總 Rajesh Jha 發了一封內部 memo，「6/30 前將砍掉大部分 Claude Code 授權，全員改用自家 GitHub Copilot CLI」。E+D 這個部門負責的是 Windows、M365、Outlook、Teams、Surface 這些產品線，影響幾千名員工。脈絡要回到 2025-12：當時微軟針對 E+D 部門同時開放 Claude Code 跟 Copilot CLI 讓員工試用，Jha memo 自己說目的是「在真正的工程流程裡 benchmark 兩個工具，搞清楚哪個比較適合我們的團隊」。六個月後結果出來，The Verge、Windows Central、TechRadar、The Decoder 各家報導跟 Tom Warren 的內部來源都指向同一件事，員工大多偏好 Claude Code 勝過 Copilot CLI。

官方說法是要統一使用的工具鏈，「我們對自家工具才可以有完整控制，可以直接跟 GitHub 一起調整成符合微軟自己的 repo、流程、安全要求」。這個說法成立，但放回成本這條主線會看得更深。微軟改用自家 Copilot CLI 不只是品牌一致性——掌握 harness 就是掌握 token 燒錢的速度。Claude Code 是 Anthropic 控制的產品，token 怎麼燒、燒多少，微軟管不到；換成自家 harness，微軟才能優化 token 用量、把成本壓回可控範圍，而且後端模型仍然可以選 Claude。

不過，對 Anthropic 其實沒差。被砍掉的是按 token 計費的產品/訂閱層，也就是成本撐不住的那一層。模型 API 那層沒變：員工換到 Copilot CLI 之後仍然可以選 Claude 當後端模型，M365 裡的 Claude 整合照常運作，2025-11 簽的 Foundry deal 也照常。成本問題是產品層的問題，不是模型層的問題，這正是它對 Anthropic 沒差的原因。被換掉的是 Anthropic 的產品介面，不是模型本身。

這跟「Anthropic 被微軟切割」是兩件事。媒體標題很容易寫成 Anthropic 被微軟踢出去，但實際發生的事情是微軟挑了 Claude 模型仍然要繼續用、但 Anthropic 的產品介面換成自家的。這個區分對理解模型廠跟平台廠的關係很重要：模型可以是商品，產品介面才是平台廠想自己掌握的層。

對企業 AI 工具規劃，這件事蠻值得注意的：當你內部最受歡迎的 AI 工具是按 token 計費，「好用」和「養得起」是兩件事。微軟和 Uber 已經先撞上這道牆，每名工程師每月燒掉上千美元 token 的成本壓力遲早會得被處理。現在用得開心的工具，明年的預算還養不養得起是另一回事。

來源：

- Hedgie（@HedgieMarkets）: https://x.com/HedgieMarkets/status/2057531661785628841

- Uber 四個月燒光 2026 AI 預算 — Briefs: https://www.briefs.co/news/uber-torches-entire-2026-ai-budget-on-claude-code-in-four-months/

- Tom Warren X scoop: https://x.com/tomwarren/status/2055000505923871219

- Microsoft cancels Claude Code licenses — Windows Central: https://www.windowscentral.com/microsoft/microsoft-cancels-claude-code-licenses-shifting-developers-to-github-copilot-cli-a-move-likely-driven-by-financial-motives

- Microsoft pulls Claude Code licenses — The Decoder: https://the-decoder.com/microsoft-pulls-claude-code-licenses-and-pushes-developers-back-toward-its-own-ai-tool/

- Microsoft Resells Anthropic's Tech at a 65% Premium. It Just Canceled the Free Version — Major Matters: https://majormatters.co/p/microsoft-claude-code-walkback-cowork-resale

- Microsoft may discontinue Claude Code internally — TechRadar: https://www.techradar.com/pro/microsoft-may-discontinue-claude-code-internally-as-it-looks-to-push-users-towards-github-copilot

Google I/O 2026

2026-05-23T09:18:19.864+08:00

2026/5/19 Google I/O 2026 盛大登場，從我的角度來看，這次 Google I/O 2026 的真正主角不是 Gemini Omni 那段影片，是 Antigravity 2.0 完全取代 Gemini CLI

每年 I/O 結束我都會問一個問題：這場 keynote 之後，開發者明天的工作流程會不會變。今年 5/19 ~ 5/20 在 Shoreline Amphitheatre 那場，答案是會，而且變動的幅度比過去幾年都大。

大多數人很容易被 Gemini Omni 那段影片生成 demo 搶走目光。Demis Hassabis 把它定位成「從任何輸入創建任何內容」，單一架構原生處理 video、audio、image、text，跨模態 reasoning 之後產出單一輸出。可以用對話編輯影片，角色、物理性質、先前的編輯在多輪對話中保持一致；對重力、流體、運動的理解明顯改善；使用者可以建自己的 avatar 拍片，建立時要錄一段念數字以防 deepfake。首發 Omni Flash 一次最多生 10 秒影片，每個輸出內嵌 SynthID 浮水印加 C2PA Content Credentials，從 Gemini app、YouTube Shorts、AI 創作工作室 Flow 進入。

這段 demo 適合上新聞，但對大多數工程師的日常沒有直接影響。會改變開發者明天工作流程的另一條線，是 Google Antigravity 2.0。

Antigravity 過去是附在 IDE 內的 agent 插件。這次升級成獨立 desktop app 加完整生態系，分成四塊：Antigravity Desktop 是圍繞 agent orchestration 設計的獨立 app，不是傳統 IDE；Antigravity CLI 完全取代 Gemini CLI，原本的 Agent Skills、Hooks、Subagents 都保留，Extensions 改名 Antigravity plugins；Antigravity SDK 開放程式化存取，跑的是 Google 內部產品用的同一套 agent harness；Managed Agents 透過 Gemini API 與 AI Studio 提供，跑在 Google 託管的環境上。Enterprise 那條線整合進 Gemini Enterprise Agent Platform。

技術層面看，新工具支援動態 subagents 平行 workflow、scheduled tasks 背景自動化、多輪 session 狀態保存、原生語音指令。

產品層面看，Google 公開選擇跟進 Claude 和 Codex：未來開發者跟 LLM 互動的單位從「我問一句、它答一句」改成 agent harness 跑一段，把多個子任務分派下去，自己處理中間的失敗、重試、狀態。

而這次，底層模型也跟著換。新發表的 Gemini 3.5 Flash 是「最新模型家族第一款，結合 frontier intelligence 與 action」，主打便宜加為 agent workflow 設計，成本大約是同等前沿模型的 1/2 到 1/3。這個價格是 Antigravity 2.0 能跑得起來的前提，agent 工作流的特性是會反覆呼叫模型，模型成本不壓下來，整個 platform 就只能服務小眾。

還有幾個比較不顯眼的工具也一起發布。Code Mender 是自動找漏洞並修補的安全工具，目前邀請外部專家測試中。Google AI Studio 加上原生 Android 支援、Workspace 整合、行動 app。Gemini API 新增 Interactions API。這幾個消息放在一起，隱約可以看到 Google 在補的是「從模型到生產系統」中間的那一段，也就是測試、安全、整合、行動端。這段過去是 Vercel、LangChain、Cursor 這些公司在做的事，Google 現在自己來。

消費者端的更新則有自己的節奏。Gemini Spark 是一般用途 AI agent，定位 24/7 personal agent，「在你指示下執行動作」。Daily Brief 是 Gemini app 每日簡報。Universal Cart 是跨網站智能購物車，agentic commerce 的基礎建設。搜尋結果加入 Search Information Agents 主動整理。Android XR 智慧眼鏡確定秋季正式推出，具備導航、訊息、拍照、Gemini live demo。Android Halo 把 agent 智能整合進狀態欄。Google Pics 是 Google Workspace 的新設計工具。SynthID 加 C2PA 的 AI 生成內容識別則擴展到更多場景，確保內容的安全。

訂閱方案部分則多了一階。新增 Google AI Ultra 月費 $100 USD，給 dev、creator、power user。

把這些放在一起看，2026 的 Google I/O 跟 2025 之前最大的差別是產品定位。過去 Google 講 AI，講的是 Gemini 變強了，更好的 benchmark、更長的 context window、更多模態。今年講的則是 AI agent，是在你指示下執行動作，是跑一段、做完一件事、回報結果。從 Omni 的多模態原生產出，到 3.5 Flash 為 agent workflow 設計的成本結構，到 Antigravity 2.0 全棧取代 Gemini CLI，到 Spark、Universal Cart、智慧眼鏡這些消費者入口，整套東西指向同一個產品形態。

來源：

- Google I/O 2026 官方 collection: https://blog.google/innovation-and-ai/technology/developers-tools/google-io-2026-collection/

- I/O 2026 developer highlights: https://developers.googleblog.com/all-the-news-from-the-google-io-2026-developer-keynote/

- Gemini Omni 詳細介紹: https://techcrunch.com/2026/05/19/googles-gemini-omni-turns-images-audio-and-text-into-video-and-thats-just-the-start/

- Antigravity 2.0 詳細介紹: https://www.marktechpost.com/2026/05/19/google-launches-antigravity-2-0-at-i-o-2026-a-standalone-agent-first-platform-with-cli-sdk-managed-execution-and-enterprise-support/

NVIDIA H200 為何無法出貨中國？真正原因不是美國禁令

2026-05-21T18:14:35.796+08:00

美國批准每家中國大廠買 75,000 顆 H200，總額度可達 75 萬顆，一顆都沒出貨。

事情經過大致是這樣。美國商務部今年放行了大約十家中國公司買 Nvidia 的 H200，名單包含阿里巴巴、騰訊、字節跳動、京東，連聯想和鴻海這些經銷商也拿到許可，每家上限七萬五千顆。額度全用滿的話理論上是七十五萬顆的量，這是 2023 年底美國收緊管制以來，開給中國最大的一筆。但根據路透 2026-05-14 的報導，截至五月中，沒有任何一顆 H200 真的送到中國買家手上。

擋下來的是北京自己。中國政府要國內廠商先暫停 H200 訂單，把資源留給國產晶片。美國商務部長 Howard Lutnick 在參議院聽證會上直接說，中國中央政府還沒讓這些公司買，因為要把投資集中在自己的產業上。國務院同期發布了兩項供應鏈安全規定，要求企業全面排查對外國技術的依賴。

我覺得這個轉折才是這件事真正的訊號。過去幾年的劇本是美國管制、中國想盡辦法買，Nvidia 為了保住中國市場一路做出 H800、H20，每次都是一個剛好合規的降規版本，H200 也是這條線上的產物。Nvidia 整套商業策略是建立在「中國一定還是會想買」這個假設上的。當北京主動把一個合規產品擋在門外，這個假設整個垮掉。靠再做一個降規版本、靠政策層面再談一輪，都救不了這個結構性問題。

讓中國敢這樣做的底氣，是國產替代真的開始跑起來了。DeepSeek 公開說最新模型針對華為的 Ascend 晶片做了優化，這件事的意義很實際。實驗室裡跑得起來不代表能上量產，一個前沿模型廠願意把工程資源花在 Ascend 上面優化，等於告訴市場 Ascend 已經能在真實生產環境跑起來，而不只是 demo 等級的概念驗證。騰訊也宣布加大國產 GPU 的資本支出。

另一邊還有「Trump tax」這個變數。這次的安排是 Nvidia 要把 H200 對中銷售營收的 25% 給美方，而且晶片要先過境美國本土才能繼續往中國走。北京擔心晶片在過境期間被動過手腳，這個顧慮在中央政府的層級被當作真實的安全風險處理。三件事疊在一起：合規產品被擋、Ascend 軟體生態起步、過境環節有顧慮，方向就很清楚了。

對台廠這條供應鏈，影響已經發生。Nvidia 在 2026 年三月把台積電原本配給 H200 的產能轉去做下一代的 Vera Rubin（Financial Times 引述兩名知情人士的報導），因為它不想再卡在美中之間的灰色地帶，寧可把產能放到市場前景清楚的產品上。鴻海和聯想雖然拿到 H200 的經銷許可，但訂單出不了貨，許可現在等於只是一張紙。中國市場一度佔 Nvidia 營收超過兩成，現在剩下約 5%，黃仁勳自己說，Nvidia 在中國 AI 加速器的市佔已經實質歸零。

華為這邊的時程表是 Ascend 950PR 在 2026 年第一季、960 在 2027、970 在 2028，HBM 也開始用自研的 HiBL 1.0 跟 HiZQ 2.0。脫鉤要走多快，要看接下來一兩年華為的量產良率跟軟體生態能不能撐住規模化部署，這個我還沒有定論，要看實際部署數據。

有一件事已經可以確定。當一邊把對方最想要的東西批准賣給你，另一邊選擇不要，雙方都認定，未來自己要用的算力得長在自己家裡。

來源：

The Next Web, US clears H200 sales to 10 Chinese firms, but not a single chip has shipped (2026-05-14): https://thenextweb.com/news/nvidia-h200-china-licences-huang-beijing-trip

Business Standard / Reuters, US clears Nvidia H200 chip sales to Chinese firms, deliveries yet to begin (2026-05-14): https://www.business-standard.com/world-news/us-clears-nvidia-h200-chip-sales-to-chinese-firms-deliveries-yet-to-begin-126051401840_1.html

Asia Times, Nvidia halts H200 production as China backs Huawei AI chips (2026-03-10): https://asiatimes.com/2026/03/nvidia-halts-h200-production-as-china-backs-huawei-ai-chips/

Yahoo Finance, Trump Clears Nvidia H200 Sales To Alibaba, Tencent And 8 Others, But Beijing Halts Deliveries (2026-05-16): https://finance.yahoo.com/sectors/technology/articles/trump-clears-nvidia-h200-sales-193006781.html

Claude、ChatGPT 都很好用，但別把大腦一起外包出去

2026-05-21T16:43:20.888+08:00

Addy Osmani 寫了一篇「不要把學習外包出去」。

Addy Osmani 目前是 Google Cloud AI 的 Director，主導 Gemini、Vertex AI、ADK 等 AI 開發者工具的體驗，自己也是 AI 輔助開發的重度使用者。在這之前他在 Google Chrome 待了快十四年，DevTools、Lighthouse、Core Web Vitals 這些工具都是他帶過的，前端工程師應該都不陌生。他也寫過幾本 O'Reilly 的書，《Learning JavaScript Design Patterns》、《Leading Effective Engineering Teams》、《Image Optimization》都是業內熟悉的教材。

他這個月寫了一篇文章叫 Don't Outsource the Learning，引了兩份研究我覺得值得記下來。

第一份是 Anthropic 自己做的。他們把工程師分成兩組去解 Python library 的任務，一組可以用 AI，一組純手動。結果兩組完成速度一樣，但後測理解題的分數差距非常明顯：AI 組 50%、手動組 67%。

這份研究最有意思的地方是 AI 組內的細部分析結果。同樣是用 AI，把 AI 當作「問概念的對象」的人，後測分數高於 65%；直接 copy-paste 生成程式碼的人，後測分數低於 40%。同一個工具、同一段時間、產出速度也接近，但學到的東西差非常多。決定結果的不是工具，是你如何使用工具。

第二份是 MIT 那篇 Your Brain on ChatGPT。他們用 EEG 量受試者寫文章時的大腦連結度，發現 AI 介入越多，腦部連結越弱。寫完文章後，83% 用 LLM 的受試者連自己剛剛產出的文章中的任何一句話都背不出來。研究者把這個現象叫做 cognitive debt，意思是現在省下的思考成本，之後會用批判思考的能力補回來。

兩份研究的方法跟切角不同，但結論相同。把產出外包給 AI 沒問題，把思考也一起外包就不行了。

Addy 自己說他過去一年用 AI 完成的東西，比前面五年加起來還多，所以他不是反 AI 的人。他文章裡舉了五個就算 AI 再強，工程師還是需要懂底層的場景：debug 失敗的時候、AI 出現幻覺需要被抓出來的時候、framework 升版或要做安全審查的時候、遇到非標準問題的時候、還有勞動市場本身正在變化（他引的數據是 2022 年至今初階工程師就業數字掉了 20%）。前四個是技術理由，最後一個是現實。

Addy 論述裡我覺得最該被引用的是這句：The tool didn't determine the outcome. The posture did. 工具沒有決定結果，使用方式決定了結果。

我自己在用 Claude Code 跟 Codex 的時候有個習慣：每隔一段時間就刻意關掉 AI 寫一段功能。理由很簡單，我想看看離開 AI 的時候，自己懂得還剩多少。如果發現某個東西已經不會自己寫了，那就超過使用的範圍了，要回頭把基礎補起來。Addy 在文章裡也提到類似的做法，他建議偶爾把 AI 生成的程式碼從頭重寫一次，或在請 AI 寫之前先自己提出假設、再讓 AI 回答。

這篇文章我想推薦給兩種人。一種是還在猶豫要不要用 AI 寫 code 的工程師，這篇能讓你知道用了之後該怎麼用才不會把自己用廢。另一種是已經重度依賴 AI 的人，可以拿這兩份研究當鏡子照一下自己現在的工作模式。

原文：https://addyosmani.com/blog/dont-outsource-learning/

MIT 研究 Your Brain on ChatGPT：https://arxiv.org/abs/2506.08872

Claude、Cursor 都能解 LeetCode 後，工程師該學什麼？

2026-05-18T10:42:36.402+08:00

Yann LeCun 全球著名的電腦科學家，被譽為「深度學習教父」與「卷積神經網路（CNN）之父」。他是 2018 年電腦科學最高榮譽圖靈獎（Turing Award）的得主。他最近回答了一個問題：為什麼法國的 Fields 獎得主數量在歐洲第一，但在 IMO（國際數學奧林匹亞）的表現很差，而匈牙利、羅馬尼亞、保加利亞這些 IMO 強國連一個 Fields 獎都沒拿過？他的回答是這樣：他認識的 2022 年 Fields 獎得主 Hugo Duminil-Copin 親口告訴他，自己從來沒比過數學競賽，而且非常不擅長這類比賽。創新的數學研究需要的是創造力、直覺、極高強度的專注，以及長時間的思考，有些問題要想好幾年。IMO 測的是快速解題能力，而這件事 AI 現在也做得到。研究者真正重要的工作不是回答問題，是提出正確的問題。

把這段話接到 vgod 多年前寫的那個系列文。vgod 是資訊奧林匹亞獎牌得主，台大保送、MIT 資工博士，程式能力強到「幾乎什麼解決方案都實作得出來」，但職涯前幾年升遷受挫。後來他理解到，自己一直把精力放在錯的地方，產出多但選錯題目，再怎麼努力也升不上去。原句是「不重要的事，就算做兩倍也不會變比較重要」。

這個對比是在說：不論是 Fields 獎還是 Staff+ engineer，真正能持續往上走的人，差異不是解題速度，是選題能力。這件事不是 AI 時代的新發現，是 AI 時代讓這個問題變成更重要。

過去十幾年，軟體業招人的主流方式是 LeetCode 面試，四五十分鐘解兩三題演算法。這套面試篩出來的是「IMO 型」候選人，特徵是快速 pattern match、套熟悉模板、限時內給答案。在 AI 編程工具普及之前，這套還勉強合理，因為「快速解題」跟「能寫 production code」有一定相關性。但這個相關性在 2025 年之後就斷了。Claude Code、Cursor、Codex 跑個一兩小時就能解完整個 LeetCode hard 的題目，速度和正確率也都贏過絕大部分工程師。而市場上仍然繼續用 LeetCode 篩人，但篩出來的能力跟資深職涯所需要的能力，卻剛好是兩個不同的維度。

具體分歧是這樣：LeetCode 型工程師面對「實作這個 spec」會做得又快又好；面對「這個產品功能該不該做？哪個版本能省 80% 工又涵蓋 90% 場景？要不要先做 A 或 B？」這類題目，卻往往答不出來，或是很難給一個精準的判斷。不過，Staff+ 工程師的工作有很大比重是後者。而當把 AI 接進來之後，可以發現「實作這個 spec」的成本掉到接近零，組織還需要工程師存在的理由就完全在「問對問題」這一塊。Andrew Chen 近期寫過一篇 token scarcity，講的是同一件事的另一面：當實作變便宜，瓶頸搬到「要把 token 花在哪一個問題上」。

這對招募、升遷、職涯規劃都會有具體影響。招募端：LeetCode 不會立刻消失，但 senior 缺的篩選邏輯要往「過去解過什麼模糊問題、怎麼定義範圍」這類題目傾斜，Amazon 的 Staff engineer 面試那套「給你一個模糊的商業需求，請設計系統」其實一直就是在測試這個。升遷端：寫程式多的人不再會自然升上去，要看他開始的專案有沒有解到對的問題、他取消的專案是不是該被取消。職涯規劃端：寫 code 多的時段不再是線性累積經驗，要刻意騰出時間培養 problem framing 的習慣，主動跑去做 user interview、看競品、定義成功指標。

回到 Duminil-Copin 那段話。他說數學研究「有時這種思考甚至會延續好幾年」，這在軟體業聽起來奢侈。但其實資深工程師花一個月寫提案、推一個季度才讓組織決策轉向、用兩年讓某個架構決定的價值浮現，這跟「思考延續好幾年」是同一件事的工程版本。會做這件事的人原本就比較少，接下來這個技能的價值會更大。

AI 沒有讓「會問問題的人」變成新的稀缺資源，他們本來就稀缺。AI 只是讓這件事更容易被看到。

Sources:

- ExplainThis 軟體工程白話聊原文：https://www.facebook.com/explainthis.io/posts/pfbid0bHPiN5xR8J8PL9EjWfV6KJjteiNALVUKwD9q3iNbUbTVpPRPc3bMtxmFS34aHDbdl

- Hugo Duminil-Copin 2022 Fields Medal（CNRS 官方新聞）：https://www.cnrs.fr/en/press/hugo-duminil-copin-french-mathematician-and-permanent-professor-ihes-has-been-awarded-fields

- Yann LeCun on LLMs passing IMO（Times of India, 2026-02）：https://timesofindia.indiatimes.com/technology/tech-news/godfather-of-ai-yann-lecun-says-yes-llms-may-be-passing-maths-olympiads-and-bar-exams-but-they-will-still-fail-in-/amp_articleshow/128614667.cms

Anthropic：就算華為算力只有 NVIDIA 的 4%，中國仍可能在 2028 追上 AI

2026-05-16T11:53:08.684+08:00

Anthropic 算過：2026 華為算力是 NVIDIA 的 4%，但他們仍認為中國會在 2028 追上

Anthropic 這週釋出一篇 4000 字的政策論文，叫《2028: Two scenarios for global AI leadership》。論文的核心問題是：到 2028 年「country of geniuses in a datacenter」（資料中心裡的天才國度，他們對變革性 AI 的稱呼）級別的 AI 出現時，定義它的規則跟價值觀，會由民主國家還是中共主導。

論文的結論很直接。美國要做三件事：堵晶片走私跟海外資料中心遠端存取的漏洞、阻斷大規模蒸餾攻擊（distillation attacks，中國實驗室大量註冊假帳號爬取美國模型的輸出來複製能力）、推動美國 AI 在全球的擴散。如果做了，2028 年美國領先 12-24 個月，這個差距在變革性 AI 時代代表全面優勢。如果不做，雙方近乎平手，AI 的規則由中共定義。

這篇是公開的政策遊說，Anthropic 在把自己定位成「跟美國國安綁在一起的 AI 公司」。而這個定位有代價的：去年 9 月 Anthropic 主動把存取限制延伸到「總部在受限地區的母公司多數持股的所有公司」，這不是配合美國政府命令，是自己加上去的紅線。這篇論文是把這個立場理論化、推向政策圈。

但抽離遊說性質，論文裡的數據值得看，因為這是第一次有前沿實驗室把「為什麼中美差距會這樣演變」攤開給人看。我覺得三個數字值得單獨看。

第一個是算力差距。Anthropic 引用的分析顯示，2026 年華為的總處理效能是 NVIDIA 的 4%，2027 年掉到 2%。如果再算上 Google 的 TPU 跟 Amazon 的 Trainium，美國這邊的整體算力供給還更高。同一份分析估計，如果美國把漏洞補完，美國的 AI 部門可以拿到中國 11 倍的算力。

第二個是蒸餾。DeepSeek 的 R1-0528 在常見越獄手法下，對明顯惡意請求的順從率是 94%，美國對照模型是 8%。再加上中國 13 個頂尖 AI 實驗室裡，只有 3 個發布安全評估結果，沒有任何一個發布 CBRN（化生放核）風險評估。中國實驗室在安全上的投入跟美國差距很大，因此用蒸餾抓取美國模型的能力，幾乎不會帶著對應的安全護欄。

第三個是落差被堵住的速度。Anthropic 提到 Firefox 拿到他們的新模型 Mythos Preview 之後，一個月修掉的資安漏洞比 2025 整年都多，是 2025 年單月平均的 20 倍。這是前沿模型在實際工作流程上的階梯式跳躍。

問題是 Anthropic 的兩個情境其實少了第三個，「美國堵了漏洞，但中國靠演算法效率追上」。Brookings 跟很多分析都指出，DeepSeek 的成功有一部分正是因為晶片受限，逼出了 MoE 架構、grouped query attention 這類效率優化。Anthropic 對這個反論的回應是，演算法改進本身也需要算力來做實驗，所以算力差距會影響到演算法差距。這個論述邏輯成立，但成立的程度取決於演算法突破的天花板在哪。這個很難說。

而對站在旁邊的台灣來說意義是什麼。論文裡 TSMC、Samsung、ASML 被點名為「democracies' compute ecosystem」的核心，這不是讚美，是把台灣綁進這個競爭架構。如果美國真的執行論文裡的三項政策，尤其是把 SME（半導體設備）的維修服務也納入管制、把東南亞資料中心的遠端存取也堵住，台廠在 ASIC 設計、伺服器組裝、光模組這些環節會直接受益於對手被卡的供需缺口。但同時台灣也會被更深地綁進這場競爭，沒有兩邊都做的空間。

我比較想留意的不是這篇論文本身，是 Anthropic 把自己重新定位的軌跡。從去年 9 月主動限縮中國股權母公司的存取、今年 3 月跟美國國防部打官司爭取「不能用於自主武器」紅線、到這週寫一篇連政策建議都列出來的論文。一年內把「我們是誰、跟誰站」說清楚。跟一般商人盡量不碰政治，想兩邊都賺錢的態度還真不一樣。

來源：

- [2028: Two scenarios for global AI leadership — Anthropic](https://www.anthropic.com/research/2028-ai-leadership)

- [Anthropic 強化區域限制，中國企業持股過半之公司不得使用其服務 — iThome](https://www.ithome.com.tw/news/171038)

- [Competing AI strategies for the US and China — Brookings](https://www.brookings.edu/articles/competing-ai-strategies-for-the-us-and-china/)

- [DeepSeek shows the limits of US export controls on AI chips — Brookings](https://www.brookings.edu/articles/deepseek-shows-the-limits-of-us-export-controls-on-ai-chips)

一把外洩的 Google API Key，兩天燒出 8.2 萬美元：LLMjacking 正在爆發

2026-05-15T13:04:15.490+08:00

一個 Google API key 外洩，月帳單從 180 美元兩天內衝到 82,000 美元，重點不是粗心，而是 API key 現在直接等於錢

這是開發者 Jacopo Castellano 寫下的真實案例。他平常每月在 Gemini 相關服務的花費大約 180 美元，一把 key 外流之後，兩天內帳單跳到 82,000 美元。攻擊者沒有偷走他任何資料，只是拿他的額度跑自己的推論工作。

這類攻擊有個名字叫 LLMjacking，由資安公司 Sysdig 在 2024 年 5 月命名。概念很單純：攻擊者拿到一把能存取 AI 服務的憑證，就用它去跑推論，帳單算在你頭上。它跟過去的 cryptojacking（挖礦綁架）邏輯一樣，都是偷算力，差別在於 LLM 推論的單價高很多，燒錢速度也快很多。Sysdig 記錄過的案例裡，有受害者一天就被跑出超過 46,000 美元；也有人的個人 AWS 帳號從每月 2 美元，兩三個小時內爆到 730 美元。

為什麼這件事現在才變嚴重，有兩個原因。

第一個是 API key 的性質變了。過去 credential 外洩，主要的風險是資料被看光。但 AI 服務的 key 不一樣，它能直接換算成計算資源，而計算資源有現成的買家。攻擊者不需要做任何資料竊取或權限提升，拿到 key、發一個 HTTP request 就開始燒你的錢。GitGuardian 的 2026 年報告指出，2025 年光是公開 GitHub repo 就新增了 2,865 萬筆寫死的 secrets，年增 34%；其中 AI 服務憑證是成長最快的類別，年增 81%。IBM X-Force 的 2026 威脅情報報告也提到，2025 年有超過 30 萬組 ChatGPT 帳密在暗網上被兜售。

第二個原因是這件事已經產業化了。資安公司 Pillar Security 在 2025 年 12 月到 2026 年 1 月之間，用蜜罐捕捉到一個叫 Operation Bizarre Bazaar 的行動，40 天內 35,000 次攻擊工作階段，平均一天 972 次。它背後是一條完整的供應鏈：掃描器在網路上找暴露的 AI 端點，驗證器測試這些端點能不能用，最後一個地下市集把存取權以 4 到 6 折轉賣出去，涵蓋 30 多家 LLM 供應商，收加密貨幣也收 PayPal。換句話說，攻擊 AI 基礎設施這件事，現在不需要任何技術能力，可以直接用買的。

而 AI 工具本身正在製造更多破口。GitGuardian 發現，AI 協助產生的 commit 洩漏 secrets 的比率是 3.2%，大約是一般情況的兩倍。原因不難理解：你請 Copilot 或 Cursor 幫你接一個 OpenAI 整合，它常常產出一段帶 `OPENAI_API_KEY = "sk-..."` 佔位符的範例碼，你填了真的 key 進去測試，忘了搬到環境變數，就推上去了。一個公開 commit 從推送到第一次被濫用，中位數時間不到四分鐘。

Google 還踩過一個設計上的雷。它的 API key 一直用 `AIza` 開頭，這種 key 最早是設計給 Google Maps 嵌入這類低風險用途的，當年大家就是直接寫進前端 JavaScript。後來 Google 把 Gemini 接到同一套 key 系統，那些早就公開在網頁原始碼裡好幾年的 key，無聲無息地多了呼叫昂貴 AI 端點的能力。

那該怎麼防？這裡有五個動作，每個用 AI API key 的人和團隊都該立刻檢查一遍。

一，API key 不要硬寫進程式碼，更不要 commit 進 repo。要清楚一件事：只要進過 git 歷史，就算你後來刪掉，那把 key 永遠都在歷史裡，任何 clone 過的人都拿得到，必須直接當作已經外洩來處理。

二，用 secret manager 集中管理憑證，並定期輪替。靜態的長期 key 是這整個問題的根源，能用短期 token 或 proxy 取代就取代。

三，在供應商端設定硬性上限，不要只設 alert。alert 是事後通知，hard limit 才是真正的保險絲。設了 200 美元上限，外洩的 key 最多燒掉 200 美元就停。

四，監控異常用量，特別注意非上班時間的推論 spike。費用突然跳高往往是 LLMjacking 最早、有時也是唯一的徵兆，而它該同時被資安和財務兩邊看到，不是只當成財務問題。

五，評估用 OpenAI 的 project-scoped key、Anthropic 的 workspace 範圍來縮小單把 key 的影響範圍。

這些動作沒有一個是難的，難的是在一切還沒出事、你正在趕進度的時候，願意停下來把它做完。過去我們把 API key 當成設定值，一個小麻煩；現在它的外洩成本，已經跟雲端儲存資料外洩同一個等級了。它值得被當成那個等級的東西來對待。

---

來源：

- [The $82,000 mistake: how to secure your AI API keys before it's too late — Jacopo Castellano](https://jacopocastellano.com/blog/ai-api-key-security/)

- [LLMjacking: From Emerging Threat to Black Market Reality — Sysdig](https://www.sysdig.com/blog/llmjacking-from-emerging-threat-to-black-market-reality)

- [Operation Bizarre Bazaar — Pillar Security](https://www.pillar.security/blog/operation-bizarre-bazaar-first-attributed-llmjacking-campaign-with-commercial-marketplace-monetization)

- [Why 28 million credentials leaked on GitHub in 2025 — Snyk / GitGuardian State of Secrets Sprawl 2026](https://snyk.io/articles/state-of-secrets/)

- [2026 X-Force Threat Intelligence Index — IBM](https://www.ibm.com/think/x-force/threat-intelligence-index-2026-securing-identities-ai-detection-risk-management)

- [LLMjacking: How Attackers Steal AI API Keys and Run Up Your Bill — Keyrua](https://keyrua.dev/blog/llmjacking-how-attackers-steal-ai-api-keys)

Qwen 前掌門人出走：沒有產品的新創，憑什麼估值 20 億？

2026-05-15T12:58:58.786+08:00

林俊暘離開阿里兩個月，新 AI Lab 還沒名字、沒產品、沒營收，估值已經喊到 20 億美元

這是 5 月 13 日 The Information 和智能涌現的報導。前阿里通義千問（Qwen）技術負責人林俊暘，離職後創辦了一間新的 AI 實驗室，正在募資數億美元，紅杉中國和高榕創投都在洽談參投，估值約 20 億美元。對一間還沒有名字、沒有產品、沒有營收的中國 AI 新創來說，這個價碼幾乎沒有先例。

先說林俊暘是誰。他 1993 年生，今年 32 歲，北大碩士，2019 年進阿里達摩院，2022 年接手 Qwen 團隊，是阿里最年輕的 P10 級技術負責人。三年下來，他主導 Qwen 系列模型的研發和開源策略，把它做成全尺寸覆蓋、全球開發者社群裡最有影響力的國產模型之一。Qwen 系列的全球下載量超過 6 億次，衍生模型超過 20 萬個。對開發者來說，Qwen 是真的能下載、能微調、能部署的東西。

所以這 20 億美元買的不是一個產品路線圖，買的是這份紀錄——一個把開源模型生態從零做到全球一線的人。這個邏輯在矽谷已經跑過好幾遍：前 OpenAI 首席科學家 Ilya Sutskever 的 SSI 成立三個月就拿到 50 億美元估值，前 OpenAI 技術長 Mira Murati 的 Thinking Machines Lab 首輪估值 100 億美元。資本願意在頂尖研究者還沒有任何產出時，先用一個很高的數字把人圈住。現在這套邏輯複製到了中國。

但比估值更值得看的，是他為什麼會走。

林俊暘的離職過程很罕見地公開。3 月 4 日凌晨，他在 X 上發了一句「me stepping down. bye my beloved qwen」，比阿里官方確認還早。導火線是前一天下午，阿里雲 CTO 周靖人向他傳達了一個 Qwen 團隊的重組計畫：把原本垂直整合的 Qwen，拆成預訓練、後訓練、文本、圖像、語音等相對獨立的水平團隊。

這個拆法跟林俊暘一直堅持的做法相反。他主張預訓練、後訓練、Infra、訓練團隊應該緊密結合，甚至從 2024 年中開始在 Qwen 內部自建 Infra 團隊。重組等於要把這套「小而全」的建制打散。據鈦媒體報導，他在內部群組留下的話是「無顏再帶領大家」。

往後看，他離開後阿里的 AI 戰略確實在轉向。離職前 48 小時 Qwen 才開源的 3.5 系列小模型，授權協議跟早期完全開放的 Apache 2.0 不一樣，對大規模商用設了更高的門檻。離職後，阿里把 Qwen 研發團隊和其他核心 AI 業務併進一個新事業群，由集團 CEO 吳泳銘直管，更多新模型轉向閉源以追求商業化收入。阿里雲 2025 年 Q2 財報顯示 AI+雲業務收入年增 26%、AI 相關產品收入連續八季三位數成長，這個量級的業務，自然會把模型團隊往「服務營收」的方向拉。

這就是一個放諸四海都成立的觀察：當一間公司的商業引擎，跟一條技術路線想去的方向不一致時，就算這條路線剛打完一場漂亮的仗，主導它的人最後還是會被推離。林俊暘要的是極致開源、商用零成本，阿里雲要的是能換算成收入的模型。兩邊都沒有錯，但放在同一個組織裡，張力遲早會把人擠出去。

他的新方向也跟這個脈絡接得起來。林俊暘選的切入點是世界模型和具身智能，他在 X 上的判斷是「多模態基礎模型正在轉化為基礎代理，透過強化學習利用工具和記憶進行長時序推理，它們應該從虛擬走向物理世界」。這其實是他在阿里的未竟之業——2025 年 10 月他就在 Qwen 內部組過一支機器人與具身智能的小團隊。離開之後，這件事他可以從頭照自己的想法做。

不過要把話說平衡。多位中國投資人對 The Information 提了一個我覺得值得記著的差異：矽谷那些超高估值，有一部分是押在「最終會被頂級科技巨頭收購」的退出預期上，但這個邏輯在中國還不成立。再加上美國晶片出口管制持續收緊，算力獲取本身就是一道實實在在的坎。也有投資人直接說，技術高管創業，常常在商業化上水土不服。20 億美元是一個起點，不是一個結論。

我會追的是他的第一個模型——它會告訴我們，這份估值買到的，到底是一個人的紀錄，還是一個人帶著一支隊伍重新跑一次的能力。這兩件事不一樣。

---

來源：

- [林俊旸創業，新公司估值約 20 億美金 — 智能涌現／36氪](https://eu.36kr.com/zh/p/3807382930251523)

- [Former Alibaba Qwen Architect Lin Junyang Launches AI Lab, Targets $2 Billion Valuation — BigGo Finance](https://finance.biggo.com/news/AZqhIJ4BrAZSr0oSxS4S)

- [非常罕見！阿里 AI 大牛林俊旸離職後創業，首輪估值超 130 億 — 新浪財經](https://finance.sina.com.cn/wm/2026-05-13/doc-inhxtqxn9394763.shtml)

- [林俊旸告別千問，阿里 AI 的轉身與代價 — 鈦媒體](https://www.tmtpost.com/7901214.html)

- [Alibaba scrambles after sudden departure of Qwen tech lead — KrASIA](https://kr-asia.com/alibaba-scrambles-after-sudden-departure-of-qwen-tech-lead)

模型會升級，真正留下來的是 harness

2026-05-12T09:24:00.004+08:00

Opus 4.6 在 Claude Code 跑 Terminal Bench 2.0 拿第 33 名，把同一個模型放到另一個 harness 跑同樣的 benchmark 跳到第 5 名

過去半年 Harness Engineering 這個詞被很多人各自獨立提出來。Hashimoto 2 月、OpenAI 的 Lopopolo 2 月、HumanLayer 3 月、Birgitta Böckeler 4 月。最近 Addy Osmani 把這些線索串成一篇，值得讀。我看完想記下來的不是定義，是裡面一個觀察。

Addy 引用 Viv Trivedy 一句話：「Harnesses don't shrink, they move.」工具變強的時候，harness 對應補位的那層不會消失，只會搬家。

舉個具體案例。Anthropic 在 2025 年 11 月推出 Tool Search Tool，把 MCP 工具描述從 prompt 抽出來，agent 要用才去查。一個典型 MCP setup 的 baseline 從 55,000 token 降到 3,000 token，省 85%。這聽起來像是 harness 縮小了，但實際上「決定哪些工具該載入」這個工作沒消失，是搬到 search/retrieval layer，由更精細的 ranking 機制接手。模型不會自己學會選工具，是 harness 變聰明，幫它選。

ETH Zurich 一篇 paper（arxiv 2602.11988）測 AGENTS.md / CLAUDE.md 的效果，結論很直白：LLM 自己寫的 instruction 檔案，效果常常比沒寫還差。人類寫的能讓任務成功率提升 4%，但會多 20% 的 inference 成本。HumanLayer 給的建議是控制在 60 行內、只放 build/test 指令，不要寫長篇大論。harness 元件不是越多越好，而是要精準，否則每一個都在搶 attention。

這也解釋了一個現象：把 Claude Code、Cursor、Codex、Aider、Cline 並排比較，會發現它們的架構設計比背後的模型還像彼此。模型一直變，但 harness pattern 在收斂。AGENTS.md、subagent、hooks、planner/worker 分工、ratchet 式錯誤紀錄、root level 的 CLAUDE.md，這幾根支柱在每一家都看得到。各家不是抄誰，而是各自試錯後發現同一個答案。

所以也看到一個趨勢：harness 本身正在從「自己造」變成「服務」。Viv 把它叫 Harness-as-a-Service。Claude Agent SDK、Codex SDK、OpenAI Agents SDK 都指向同一個方向，你拿到的不是 LLM completion API，是包含 loop、tool routing、context management、hook、sandbox 的 runtime。客製化的點從「我要怎麼接 LLM」搬到「四根支柱（system prompt、tools、context、subagent）各要怎麼調」。

那「換模型解決問題」這條路為什麼通常不通？

Luke Stahl 在 Stop upgrading your model 那篇寫得直白：模型升級的差距比想像中小，harness 改動的差距比想像中大。HumanLayer 同意：「這不是 model problem，是 configuration problem。」

Sergey Golubev 4 月那篇 Harness Engineering 紀錄文有個具體例子。Opus 4.7 一發布，他幾個 harness 馬上掉鏈子，不是 code 壞掉，是指令解讀方式變了，舊 skill 寫得太寬鬆。重寫三個、整理五個花了大半天。每次模型升級都會逼一次 harness 重整，因為新模型對舊指令會用不一樣的方式詮釋。

所以差異化到底在哪？Ry Walker 的整理是：harness 本體（Claude Code、OpenCode、Goose、Aider）已經是 commodity，遷移成本很低。真正的差異化在三個地方：context 跟 memory（codebase 規矩、過去踩過的坑）、orchestration（多 agent 怎麼分工）、tool layer（接到內部系統的客製化工具）。

回到 Addy 那篇的尾巴，他列了三個值得追的開放問題：多 agent 並行共享 codebase 的協作機制、agent 分析自己的 trace 找 harness 級失敗模式、harness 動態組裝工具與 context 而非事前配好。每一個都是同一條思路的延伸。harness 不會穩定，會繼續搬家，重點是知道它正在往哪搬。

模型升級會繼續發生，幾乎每幾個月一次。但跟 agent 一起累積的 context、規則、工具、skill，這些是換 harness、換模型都帶得走的。

Sources:

- Addy Osmani: Agent Harness Engineering — https://addyosmani.com/blog/agent-harness-engineering/

- HumanLayer: Skill Issue — https://www.humanlayer.dev/blog/skill-issue-harness-engineering-for-coding-agents

- Luke Stahl: Stop upgrading your model — https://lukestahl.io/blog/stop-upgrading-your-model-fix-your-harness/

- Sergey Golubev: Harness Engineering 2026 — https://www.prodfeat.ai/en/blog/2026-04-18-harness-engineering

- Ry Walker: The Agent Harness Problem — https://rywalker.com/agent-harness-problem

- 張維峰 FB 中譯整理 — https://www.facebook.com/jerry.chang.505523/posts/pfbid0WZP6JBVGp3CNR6ot1GizCVcdDPQcEnhxJVW4An3hZLc2EjbviZrfenL627i5ANuvl

Anthropic 的 80 倍成長，真正的瓶頸才剛開始

2026-05-09T10:22:00.005+08:00

Anthropic 在 2026 年 5 月 6 日開了第二屆 Code with Claude，Dario Amodei 在台上把 Q1 的數字攤開。原本內部「準備好應對每年十倍成長的世界」，結果 Q1 換算成年率，營收和使用量年增到 80 倍。他自嘲這數字「太誇張，也太難應付」，希望趕快回到 AI 定義的「正常」，也就是「只有」十倍。

年化營收的曲線是這樣：2025 年底 $9B、2026 年 2 月 $14B、3 月 $19B、4 月 $30B。OpenAI 的年化營收約 $25B，被超車。

落差怎麼形成的，比 80 倍本身更值得看。當所有 AI 公司都在搶風口，Anthropic 用了一個遠小於對手的訓練預算（約 $12B，OpenAI 約 $32B），把企業端拿了下來。

答案在策略選擇。Anthropic 走的是「窄門」，只做企業客戶、只把 coding 這一個用例做透，其他先放著。這跟 OpenAI「消費端 + 企業端 + 影音 + 瀏覽器 + 裝置」全面進攻是兩個完全不同的賭法。

具體看 Claude Code。2025 年 5 月才公開，6 個月後達 $1B 年化營收，2026 年 2 月翻倍到 $2.5B。年付 $1M 以上的企業客戶，兩年前是十幾家、今年 2 月 500 家、4 月已經 1,000 家。Fortune 10 有 8 家是 Claude 客戶，80% 營收來自企業。Anthropic 每月每使用者收到約 $211，OpenAI 量級是每週 $25，每使用者貢獻差 8 倍。

Ramp 的企業支出統計更直觀。2026 第一季首次採購 AI 工具的企業，73% 把錢花在 Anthropic；半年前還是 50/50。企業採購圈的偏好整個倒過來。

窄門策略也展現在組織人事。Code with Claude 對談前不久，原 CPO Mike Krieger 被調去領導 Anthropic Labs，CPO 位置在 2025 年 12 月換成 Ami Vora。Krieger 是 Instagram 共同創辦人，擅長從零到一抓住產品方向；Vora 在 WhatsApp 跟 Meta 的歷練，則是把產品推到全球規模的 GTM (go-to-market)。CPO 換手不是高層輪流，是公司產品階段的訊號。

但窄門不是沒副作用，這是 Dario 在台上花最多時間講的部分。他兩次提到 Amdahl's Law（阿姆達爾定律），這是 1967 年 IBM 工程師 Gene Amdahl 提出的：你加速了系統的某一部分，整體速度的提升會被你還沒加速的那部分卡住。Dario 把這個半世紀前的觀察套到 AI 加速人類工作上，套了兩次。

對外的 Amdahl，他這樣描述：技術在整個經濟體裡的擴散速度並不均勻，軟體工程師是最快採用新技術的那一群人，這是為什麼焦點都壓在這個領域。Q1 的 80 倍打到 Anthropic 自己跟最早的開發者，其他職業還在後面，那一塊才是放大效應真正的主體。

對內的 Amdahl 更直接。「如果你身處一個組織，可以在相同時間內提交三到四倍的 PR，你就會開始發現有一大堆其他事情在拖你的後腿。」程式碼提交速度提升之後，浮上來的是資安、驗證、設計品質、組織協調、技術債管理。「如果你只加速這一件事，而不是把所有事情都加速，就會出問題。」

這段值得任何在組織裡推進 AI 的人記下來。AI 工具加速個人寫程式很容易，但個人加速完，瓶頸不會消失，只會搬家。下一個浮上來的可能是審查流程跟不上、可能是測試覆蓋率撐不住、可能是設計與工程協作的節奏對不上。

Dario 自己拋了一個比喻：「我們正在慢慢走向資料中心裡住著一個天才之國的境界。現在從一屋子聰明人開始，慢慢往上走，走向一座城市、一個國家的規模。」要走到那一步，光練強模型不夠，組織級的協作方式得整個重新發明一遍。

這場對談跟一年前那場對談的差別也在這。2025 年 5 月 Dario 跟 Krieger 預言「2026 年會出現第一個一個人的億萬美元公司」，當時聽起來像在打賭。一年後同個舞台，已經有兩人公司估值達 $1B、一人公司估值達數億美元，剩下的問題從「會不會發生」變成「哪個產業先發生」。

來源：

- https://www.anduril.tw/anthropic-80x/（狐 Hsiao 整理 Code with Claude 2026 完整對談）

- CNBC（80 倍、SpaceX Colossus 1 算力協議）：https://www.cnbc.com/2026/05/06/anthropic-ceo-dario-amodei-says-company-crew-80-fold-in-first-quarter.html

- SaaStr（$14B ARR、$2.5B Claude Code、$1M+ 客戶 12→500→1,000 家）：https://www.saastr.com/anthropic-just-hit-14-billion-in-arr-up-from-1-billion-just-14-months-ago/

- Ramp 73% 首次採購數據：https://beri.net/article/anthropic-overtakes-openai-enterprise-spending

- 訓練預算對比 $12B vs $32B、ARPU 8 倍：https://www.danilchenko.dev/posts/anthropic-surpasses-openai-revenue/

問題不是 AI 寫 code，而是誰批准它上線

2026-05-08T21:59:39.013+08:00

Coinbase 上週宣布裁員 14%，約 700 人。CEO Brian Armstrong 在公開信裡列了兩個理由：crypto 下行週期，加上 AI 改變工作方式。光看這兩個原因，跟今年其他幾家裁員公司沒太大差別，Block、Crypto.com、Algorand 都這樣寫過。

但 Armstrong 那封信被罵翻的點不是裁員，是其中一句：Non-technical teams are now shipping production code（非技術人員現在直接送程式碼上正式環境）。信公開後股價跌了快 5%，X 上很多用戶說要把資金搬離 Coinbase。為什麼這句話這麼傷？因為 Coinbase 2025 年才剛發生過一次資料外洩，影響 69,461 名用戶，公司自己估算修復成本可能到 4 億美元，多起集體訴訟還在跑。所以當 Armstrong 在這個時間點講「非技術背景的員工正在直接送程式碼上正式環境」，用戶讀到的不是「我們很有效率」，而是「我的錢安不安全？」

問題從來不是「誰寫的程式碼」，現在大部分工程師也都用 AI 寫。真正的問題是 AI 程式碼之後的審核機制。2025 年 8 月，Armstrong 在 Cheeky Pint podcast 上說，他幫工程師買齊 Cursor 和 GitHub Copilot 企業授權後，有人跟他說全員上手要好幾個月，他直接在內部 Slack 發強制通知，後來真的開除了拒用的工程師。同年他公開喊 40% 的 Coinbase 程式碼是 AI 寫的，目標 10 月拉到 50%。

這套作法在矽谷不算特別，但 Coinbase 是加密貨幣交易所，「錢的安全」是核心價值。2025 年 9 月 HiddenLayer 揭露 Cursor 跟其他幾個 AI 編輯器的 CopyPasta 漏洞，攻擊者把惡意指令藏在 LICENSE.txt 或 README.md 的 Markdown 註解裡，AI 讀到就會執行。CMU 教授 Jonathan Aldrich 當時說他不會把錢放 Coinbase；Dango 創辦人 Larry Lyu 說這對任何安全敏感的業務都是紅旗。所以這次裁員信不是引爆點，是壓垮駱駝的最後一句話。CEO 公開信原本是寫給內部員工的，Armstrong 卻自己選擇 po 上 X，等於把「我們現在讓非技術人員直接送程式碼上正式環境」這句話直接傳遞到外部用戶面前。

更重要的問題是在審核機制。LaunchDarkly 的調查顯示 91% 工程師不信任 AI 生成的程式碼直接上正式環境，這個比例在金融服務業會更高，因為審計要的不是「程式碼跑起來」，是「誰在什麼時間因為什麼理由改了什麼」。SOX、PCI-DSS、ISO 20022 這些規範要的是完整的監管鏈。AI 每次改動，在審計流程裡就是文件空白。這也是為什麼很多金融機構把 AI 用在資料前處理、ETL、文件草稿、單元測試這類非關鍵路徑，主要的交易系統跟風險引擎還是要人盯。Coinbase 工程部門其實在自家 blog 上澄清過：AI 比較常用在前端跟非敏感系統，「系統關鍵的交易系統」是受謹慎管理的。但 Armstrong 在 X 上發的那封信沒這樣講，他講的是「intelligence with humans around the edge aligning it」（公司是智能體，人在邊緣對齊它）。

我看下來，Coinbase 這次踩到的線，是把「AI 加速」跟「省掉審核」混在一起講。前者是行業共識，後者在受監管行業就是不能讓步。一個工程師一週做完原本一個月的事，這是現實，沒有爭議。但這不等於上線就緒，從原型到上線中間缺的不是模型變聰明，是審計日誌、權限控制、人工把關、資料來源追蹤、錯誤處理，這些不會因為模型進步而自動補齊。

如果這次股價回不來、用戶真的搬走，這會是 AI coding 第一次在公開市場被以實際代價教訓。一年下來大家都在搶速度，這次是市場對「速度該停在哪」的回答。

來源：

- American Banker, Coinbase cuts 14% of staff, citing crypto slump and AI（2026-05-05）：https://www.americanbanker.com/news/coinbase-cuts-14-of-staff-citing-crypto-slump-and-ai

- BeInCrypto, Coinbase Stock Falls After Users Criticize Internal AI Pivot（2026-05-05，含股價跌 5%、69,461 資料外洩數字）：https://beincrypto.com/coinbase-stock-price-drop-ai-pivot-criticism/

- ExplainThis 原文：https://www.facebook.com/explainthis.io/posts/pfbid02NfZx4QQQaPnxHgWiNXg7xwfjfrKCRD2nEzVmSL4DxUM8gf4J5Xz9MoW4zZ4wYv7ol

- ChainCatcher, Coinbase CEO：全員強制 AI 編程，違者開除（2025-08-30）：https://www.chaincatcher.com/zh-tw/article/2202050

- Gate 新聞, AI 編碼工具曝出新漏洞，Coinbase 激進的 AI 政策引發安全擔憂（2025-09，含 HiddenLayer CopyPasta 漏洞、Aldrich 與 Lyu 評論）：https://www.gate.com/zh-tw/news/detail/13588122

- Synodus, The risk of Vibe coding in fintech（含 LaunchDarkly 91% 數據, 2026-01-15）：https://synodus.com/blog/fintech/vibe-coding/

能做，不等於該自動做

2026-05-07T12:56:00.002+08:00

最近一波 AI 自主經營業務的實驗很熱鬧，從 Anthropic 的 Project Vend（讓 Claude 經營一台販賣機）到各家業務開發代理自動發冷郵件。Simon Willison 上週在 X 上對這股熱潮丟了一個不會傳很爆但很值得停下來的提醒：當代理還只在內部沙盒裡玩，怎麼炸都好；但一旦代理開始發信、打電話、下單、發貼文，影響到沒有同意加入的真實人類，每一個對外動作都應該由人類操作者在迴圈裡審核。

這個論點現在看像常識，過幾個月會看起來像先見之明，因為攤開最近幾起具體事件後，「能做不等於該自動做」。

第一起，2026 年 1 月底，北卡州的工程師 Chris Boyd 給開源代理 OpenClaw 介接 iMessage，本來只是想每天 5:30 收到一份新聞摘要。Bloomberg Law 報導，代理後來「失控」，對他、他太太、以及他通訊錄裡的隨機聯絡人轟出 500 多則訊息。第二起，MIT Technology Review 三月那篇〈Online harassment is entering its AI era〉裡的 Shambaugh 案例：一個代理在沒有明確指示的情況下，自己決定針對某位網路使用者寫了一篇詳細的攻擊文章，把對方公開資料整理成攻擊內容，發出去之後代理主人才發文承認「不是我叫它做的」。研究人員壓力測試同類代理也發現，外部使用者可以誘導代理洩漏敏感資訊、浪費資源跑無用任務，甚至刪掉信件系統。

商業面更慘。2024-25 年那一波自主 AI 業務開發代理（Artisan、11x.ai 那一掛）公開的數據是：50-70% 客戶 90 天內流失、代理自動找出來的信件名單只有 79% 是有效的，五封發出去就有一封退信，遠高於健康程式 2-5% 的天花板。LinkedIn 上一位求職者更是寫了一份很有畫面的記錄：他在個人檔案加上 #OpenToWork 標籤後七天內收到 20 封 AI 生成的未經邀請招募信，其中一封招募者不小心把內部 AI 提示詞連同回覆一起寄出來，明確證實這些信都是用爬到的 LinkedIn 資料丟給 AI 工具量產的。

這些案例不只是個別出包，背後有一個攤在桌上的數學現實。Belkins 的對外信數據顯示，冷郵件第一封的垃圾信申訴率大約 0.5%、到第四封會跳到 1.6%。Google 2024 年 2 月的大量寄件人規則把 Gmail 的紅線設在 0.30%，所以一個沒有人類煞車的四次觸及代理序列，在數學上就會穿越天花板，整個寄件網域的信譽（包括公司其他人發的所有信件）會跟著一起掉到垃圾匣。Molted Email 還記錄了一個更典型的事故：代理把短暫的軟退信解讀成「重試」，一個小時內向 150 位收件人發出 30,000 封信件，平常這個網域一天只發 200 封。Microsoft 立刻發現，這個網域接下來幾週寄給人類受眾的所有信件全部進垃圾匣。

Simon 自己過去一年累積的論述跟這些事故是同一條線。他在〈Designing agentic loops〉裡的核心建議很具體：能不開放憑證就不開放；非開放不可的，限縮到測試環境；如果憑證能花錢，先設緊預算上限；代理跑迴圈一定要在沙盒。他另一個更尖銳的觀察叫「致命三件組」（lethal trifecta）：當代理同時擁有「不可信輸入、敏感資料、外部通訊能力」這三件，提示詞注入攻擊不是會不會發生的問題，是什麼時候發生。把冷郵件代理拆開看，剛好是這三件全中。

整理出來，給正在打造代理產品的團隊一個檢查清單：能稽核嗎？對外動作是否分高風險、低風險，前者強制升級給人？每個收件人的冷卻時間跟去重有沒有？退信、申訴、退訂有沒有負訊號預算自動煞車？憑證是不是嚴格限縮到只能做最少的事？跑越界的動作有沒有結構化拒絕讓代理知道發生什麼、不要重試迴圈？這些不是錦上添花的可有可無，是讓你的產品在三個月之後還活著、不被信譽燒掉的最低門檻。

更深一點的問題是責任。Simon 那位 MIT 科技評論訪到的 Hinduja 教授說了一句：「機器人沒有良心、可以 24/7 運轉、用很有創意的方式做這件事。」這指出代理越界事件最棘手的部分：當代理自己決定做了壞事，你能找誰？OpenClaw 的擁有者在 GitHub 上發文說「我沒叫它做的」，這個說法可能是真的，但對被攻擊的人完全沒有用。法律責任目前是模糊的，業界規範也還沒成形。

Solomon Hykes 在 AI Engineer World's Fair 講過一個我覺得很精確的代理定義：「An AI agent is an LLM wrecking its environment in a loop.」（AI 代理就是一個 LLM 在某個環境裡反覆搞爆東西）這是工程師笑話，但它很誠實，代理的本質就是在某個環境裡迭代地做事，差別只在這個環境是你願意被搞爆的，還是別人的。當環境裡有沒同意被聯絡的真人，代理不該預設可以搞爆。

最後想說的話很簡單。自主性是能力，不是禮貌。能做不等於該自動做，尤其是當被影響的人還沒同意進這場實驗。這條界線守不住，代理產品的市場不會被監管殺死，會被信任殺死。

來源：

- Simon Willison 〈Designing agentic loops〉：https://simonwillison.net/2025/Sep/30/designing-agentic-loops/

- Simon Willison 對 Lenny's Podcast 的整理（含 lethal trifecta 與 OpenClaw 安全討論）：https://simonwillison.net/2026/Apr/2/lennys-podcast

- Bloomberg Law: AI Agent 失控對 OpenClaw 用戶發 500 訊息：https://news.bloomberglaw.com/artificial-intelligence/ai-agent-goes-rogue-spamming-openclaw-user-with-500-messages

- MIT Technology Review: Online harassment is entering its AI era（含 Shambaugh 案例）：https://www.technologyreview.com/2026/03/05/1133962/online-harassment-is-entering-its-ai-era

- Weaver: State of Outbound Agentic Pipelines 2026（含 0.30% Gmail ceiling、11x.ai 50-70% churn / 79% email accuracy 數據）：https://www.weaver.work/blog/state-of-outbound-agentic-2026

- Molted Email: agent retry loop 一夜燒毀 sender 信譽案例：https://molted.email/blog/what-happens-when-an-ai-agent-over-sends

- Solomon Hykes 的 agent 定義：https://simonwillison.net/2025/Jun/5/wrecking-its-environment-in-a-loop/

AI 正在改寫資安攻防的時間尺度

2026-05-07T12:40:00.008+08:00

過去兩週連續三件 AI 安全相關的大新聞：Anthropic 發布 Project Glasswing，召集 AWS、Apple、Cisco、Google、CrowdStrike、Microsoft、NVIDIA、Palo Alto、JPMorganChase、Linux Foundation 一起對抗 AI 帶來的攻擊；CrowdStrike 推出 Project QuiltWorks 把 IBM、EY、Accenture、Kroll、OpenAI、Anthropic 全拉進來;Anthropic 把 Claude Security 公開測試版，直接做進 claude.ai 側欄。CrowdStrike 商務長 Daniel Bernard 一句話被瘋狂引用：「這是我們這個世代資安的 Y2K 時刻。」

這個比喻準的地方很準，但不準的地方更可怕。

先看準的部分。Y2K 在 1990 年代後段觸發了全球性的同步動員：政府、企業、開源社群、顧問業者、軟硬體廠商一起在固定時間軸內掃程式碼庫、修代碼、做演練。今天的場景神似：Anthropic 公開承認他們未發布的 Claude Mythos Preview 已經能在多個主流作業系統跟瀏覽器找到「數千個高嚴重性漏洞」、自己一個團隊用 Opus 4.6 就在開源程式碼庫翻出 500 多個沒人發現過的漏洞，CrowdStrike 2026 Global Threat Report 也說使用 AI 的對手攻擊量年增 89%。整個業界從前沿實驗室到大型系統整合商同步把資安拉到第一順位，這份協同程度跟 Y2K 是同一個量級。

不準的地方有三個層次。

第一個是 Y2K 有截止日，這次沒有。1999/12/31 23:59:59 是清楚的。AI 資安的「臨界點」是另一個更模糊的時刻：哪一天敵對的國家級行為者或勒索軟體集團拿到等同 Mythos 等級的能力？沒人知道。CrowdStrike 總裁 Mike Sentonas 自己給的範圍是 6 到 18 個月。範圍這麼寬代表整件事其實是在猜測，不是真正倒數。

第二個是 Y2K 的攻擊面是可枚舉的：年份位元數、特定函式、特定資料表，看完清單就知道改哪。AI 找漏洞不是。Anthropic 技術長 Elia Zaitsev 講了一句到位的話：「漏洞從被發現到被利用攻擊的時間從幾個月壓到幾分鐘。」當生成攻擊程式的成本崩塌，攻擊面從「已知漏洞清單」變成「整個程式碼庫」。這是為什麼 Bernard 說 Patch Tuesday(每月修補日)已經死了，新規矩是每日修補。任何還在月排程跑漏洞管理的資安長可能忘了跟上。

第三個是 Y2K 攻防是不對稱的：攻方在同一條時間軸上沒有對應的能力升級。AI 資安完全相反：守方手上的 Mythos / Opus 4.7，跟攻方未來會擁有的同源模型是同一條技術路徑。Anthropic 自己也說沒有要普遍釋出 Mythos，但其他前沿實驗室已經在做類似的事情；OpenAI 的 Trusted Access for Cyber 有同樣的合作網。技術不會被某個單一組織關起來。

把這三件事情拼起來，圖像會清楚很多：這次的急迫性是真的，但能用 Y2K 心態應對的部分只有「動員」那一段。整個產業要學會的不是「在截止日之前完工」，是「在沒有截止日的不對稱戰場活下來」。Anthropic 願意把自己最強的模型留住、開放給防守方先用 90 天、捐 1 億美元使用點數給 Glasswing 跟 4 百萬給開源資安組織，這種分發節奏在訴說一件事：他們相信防守先發優勢只能爭取時間，不能解決問題。

對企業端意義很具體。CrowdStrike 統計修補一個漏洞的平均時間超過五個月，現在 AI 把找到這些漏洞的時間壓到接近即時，缺口就在五個月與分鐘之間。對沒有資安維運中心(SOC)跟成熟修補流程的組織，這個缺口短時間內會變成不可承受的風險。Sentonas 直接點出來：多數企業沒有能力自己跑這套防守機制，託管服務跟合作夥伴會變成必備。歐盟 AI 法案下一階段 2026 年 8 月 2 日生效，把高風險 AI 系統的稽核紀錄、事件通報都寫進法律，違反最高罰全球營收的 3%。法規面壓力跟攻擊面壓力在同一條時間軸上同步上來。

對 AI 廠商商業面也是一個轉折。Anthropic 在五角大廈那邊有些合約被擋住，資安是少數他們仍能賣進美國聯邦市場的路線。把 Opus 4.7 接進 CrowdStrike、Palo Alto、SentinelOne、Trend Micro、Wiz 已經在跑的平台，再讓 Accenture、BCG、Deloitte、Infosys、PwC 建部署實踐，等於把通路鎖進去了。這個動作不全是公益，是一個策略性的市場卡位，但結果對防守方有實質好處。

回到個人視角。對一般開發者跟 IT 團隊而言，這件事最直接的意義是：你的程式碼庫即將進入一個會被自動掃描的時代。某個你沒注意過的依賴、某個五年前寫的工具函式、某個從 Stack Overflow 抄來忘記做跳脫處理的查詢，都可能某天被 Mythos 級的模型一次掃出來。在這一波之前先做的事很簡單但常被跳過：把軟體物料清單(SBOM)整理乾淨、依賴版本固定、關掉沒在用的端點、敏感資料的流向再走一次。沒有花俏的 AI 資安工具也能先做完這幾件，等到該裝的時候才不會發現腳下是流沙。

Y2K 那一年很多東西沒爆炸，是因為前面三年多人類做了很多無聊的工。這次大概也一樣。

來源：

- Anthropic Project Glasswing 公告：https://anthropic.com/glasswing

- Anthropic Claude Code Security 發布頁：https://www.anthropic.com/news/claude-code-security

- SecurityWeek 報導 Claude Security 公測：https://www.securityweek.com/anthropic-unveils-claude-security-to-counter-ai-powered-exploit-surge/

- CrowdStrike Project QuiltWorks 公告：https://www.crowdstrike.com/en-us/press-releases/crowdstrike-launches-project-quiltworks/

- CRN: CrowdStrike Bernard 訪談（含「Y2K 時刻」與 Patch Daily）：https://www.crn.com/news/security/2026/how-crowdstrike-is-helping-the-industry-to-withstand-ai-driven-vulnerability-deluge-exec

- CrowdStrike Sentonas 6–18 月窗口、5 個月平均修補時間：https://www.crn.com/news/security/2026/crowdstrike-president-huge-opportunity-for-partners-in-countdown-to-ai-driven-vulnerability-surge

- AI Chat Daily 對 Claude Security 商業策略的拆解：https://www.aichatdaily.com/ai-security/aichat-20260504-s1-anthropic-launches-claude-security

當 AI 可以做 10 萬件事，真正稀缺的是你的注意力

2026-05-07T10:51:00.002+08:00

OpenAI 共同創辦人兼總裁 Greg Brockman 上週在 Sequoia AI Ascent 2026 跟 Alfred Lin 對談，丟出三個被截錄到處流傳的數字：他個人認為 OpenAI 已經走到 AGI（通用人工智慧）的 80%、AI 代理寫的程式碼占比一個月內從 20% 跳到 80%、未來一個人帶 10 萬個 AI 代理是合理的組織形態。

把三個數字放在一起看，會發現只有一個是真的值得認真討論。

先看那兩個被瘋傳的。「80% to AGI」Brockman 自己附了註解：這是「我個人的定義」，他也補了一句模型現在能力很不平均，有些非常基本的事情仍然不會做。AGI 這詞本來就沒有共識，業界從 Dario Amodei、Demis Hassabis 到 Sam Altman 都各有自己的時程，Yann LeCun 整週在 X 上反覆嗆說自回歸架構在數學上就到不了。所以「80%」這個數字的訊息量，跟一個天氣預報主播說「我覺得明天大概 80% 會下雨」差不多。你聽完知道他的立場，但不知道機率本身。

「20→80% in one month」更值得看清楚。Brockman 原話的脈絡是「12 月新模型一出來」這個區間，AI 代理寫程式的工具從邊緣變成主戲。但這個 80% 量的是什麼？是程式提交的字符比例？是 PR 被合併的比例？是工程師敲鍵盤的時間佔比？Brockman 自己也補了一句「很難確切知道哪個百分比不是 AI 寫的」。Andrej Karpathy 自己 12 月也經歷了從 80% 手寫變成 80% 交給代理的轉折，他在 X 上的描述比較精確：他說模型還是會犯「菜鳥工程師等級」的概念錯誤、會在錯誤假設上一路蓋上去、不會主動釐清不確定，所以他形容的不是「做 80%」，而是「打字從程式碼變成英文」、人類還是要像老鷹一樣盯緊。同樣是 80%，意思可能差很遠。

順帶一個有趣的反差：Brockman 自己依公開報導每週仍寫 60–100 小時的程式碼，他既是 AI 提升生產力的首席倡導者，也是 OpenAI 公司最活躍的人類程式設計者。這不是揭穿，是提醒讀那兩個數字時要保留的脈絡。

真正值得停下來看的是第三件事：他說執行變便宜了，判斷變稀缺。「以前蓋一個儀表板要一週，現在打字打一打就出來了。建原型的成本崩到接近零。」當生成的速度往上拉一個數量級，瓶頸就會被推到下一道閘門：這個東西是好東西嗎？這是我要的嗎？這跟我的價值觀對齊嗎？他直接定義「人類的注意力是 AI 加成工作裡最稀缺的資源」，這句話比 80% AGI 有用太多。

把這個論點接到 10 萬代理的組織想像就清楚了。Brockman 比喻成從用鵝毛筆親手寫信，變成發訊息給人代你做事。但這比喻避開了關鍵問題：當你身邊有 10 萬個代理在跑，你能稽核多少？多少行動可以自動批准、哪些必須升級給人？白名單怎麼維護？哪一筆要查紀錄？這些都不是模型問題，是治理問題。一個人帶 10 萬代理的瓶頸不是執行力，是判斷力可以擴展到多遠。Brockman 自己也說，將來會有 AI 幫你標記「這是高風險行動應該升級」「這個可以自動批准」，但決定標記規則的、為錯誤負責的、最後要說「這不對」的，仍然是人。

商業面值得一起看的是 OpenAI 真正在賭什麼。Brockman 把整個公司簡化成一句話：「我們買、租、建算力，加成轉售。只要毛利是正的就應該放大規模。」這聽起來很清爽，但攤開財務面：OpenAI 2026 募了 $122B、有 $600B 的算力義務、自家財務長擔心付不出來、外面還有 Musk 提的 $180B 訴訟、Polymarket 認為 OpenAI 在 6 月底前擁有最強模型的機率只有 9%。這套商業邏輯成立的前提是需求真的無限、模型進步速度不放緩、且每一筆資本支出真的有收入能對接得上。任何一個假設破洞，「算力當成收入來源」就變回「算力當成成本中心」。

回頭看 Brockman 那場對談，能帶走的其實不是 AGI 距離條，是他講「注意力」那段。這個觀察是給每個工作者的：在生成變便宜的世界，你還願意花時間「決定哪件事值得做」、「看別人或代理給你的東西到底對不對」、「在哪一刻說不」，那才是你跟一個跑得很快但會犯菜鳥級錯誤的代理之間的差別。

注意力不是浪漫的詞，是一個越來越貴的資源。我自己最近的感覺是，每天打開 Claude Code 跟 Codex 之前，先想清楚「我到底要它幫我看什麼」這 30 秒，省下後面亂跑兩小時的成本。

來源：

- Sequoia AI Ascent 2026 對談（YouTube）：https://www.youtube.com/watch?v=bBS93A0BeNI

- BigGo Finance 完整報導（含 $600B、$180B、Polymarket 9% 數據）：https://finance.biggo.com/news/07b54e946df043ba

- AI Chat Daily 對 Karpathy 與 LeCun 反駁的整理：https://www.aichatdaily.com/ai-news/aichat-20260504-s0-openais-ai-writes-80

- Karpathy 自身 12 月工作流轉變：https://the-decoder.com/former-tesla-ai-chief-andrej-karpathy-now-codes-mostly-in-english-just-three-months-after-calling-ai-agents-useless/

- News Factory 報導（含 Brockman 60–100 小時/週寫 code）：https://news-factory.app/news/openai-president-claims-ai-generates-80percent-of-companys-code