苦勞德報 — 2026-06-05

2026-06-05

1. [頭版] Claude Code dynamic workflows 爆紅：讓 Opus 當指揮、雜活外包便宜模型

• 作者：u/techiee_ | 91↑ | 25 則留言

報導

（本報賈新聞／工具組報導）Claude Code 官方近日推出 dynamic workflows 功能，在 r/ClaudeCode 社群引發熱議。發文者 u/techiee_ 形容這是「一陣子以來第一個真正改變我工作方式、而非只是把同樣的事跑快一點」的更新，貼文累積 91 個讚、25 則留言。

這項功能的運作方式，是讓 Claude 不再用單一對話視窗同時又要規劃、又要執行整個任務，而是當場寫出一段 orchestration script，動態 spin up 一批 subagent。每個 subagent 拿到乾淨的 context 與一個聚焦的小任務，再由 Claude 擔任 orchestrator 從中協調。換句話說，Claude 會替每件任務量身打造一套配置，而不是把所有事都硬塞進同一個 chat。官方文件放在 code.claude.com/docs/en/workflows。

發文者指出，這套設計正好對症下藥，解掉長任務的老毛病：做到一半就宣稱整個大任務完成、其實只做了一半；要它自評時又判斷不準；長 session 跑久了、特別是經過一兩次 compaction 後，會慢慢失去對原始需求的脈絡。把工作拆給各自帶獨立 context 的 subagent，多半能繞過這些問題。他舉的範例任務頗能說服人：翻過最近 50 場 session 找出自己反覆做的修正、整理成 CLAUDE.md 規則；或翻六個月的 Slack 事故討論找出沒人開過 ticket 的根因；甚至把一份商業計畫丟給分別扮演投資人、客戶、競爭對手的 subagent 各自拆解。

不過這篇貼文真正的切角，是作者主張的一套「便宜跑法」。他認為 Opus 系列擅長指揮——寫 workflow、規劃、維持協調，這部分值得付費；但官方部落格也提醒，一旦 fan out 到大量 subagent，這些 workflow 會很快燒掉 token。而多數 subagent 其實只是在做苦工：讀檔、從一疊履歷裡排序一份、查證某條主張是否成立，這些根本用不到 Opus。於是他開始把實際幹活的 worker subagent routing 到便宜模型，點名 DeepSeek V4 Pro、MiniMax M3、Kimi K2.6 這一檔，宣稱在 coding 與 tool-use 上的 grunt work 品質與 Sonnet 同級、有時略勝，每 token 卻便宜數倍到 10x 以上。同期社群另一篇貼文（u/Anthony_S_Destefano，32↑）也只是貼上同一條 trq212 的推文連結與一張圖喊「別錯過」，可見這波話題確實有熱度。

本報觀點

dynamic workflows 把長任務拆成帶乾淨 context 的小單位，方向上確實對準了「做一半就喊完成、自評不準」這些痼疾，值得一試。但貼文後段「便宜跑法順勢推 cloud sandbox」那段，從便宜模型一路帶到 Happycapy 之類 24/7 雲端沙盒，工商置入味偏重，本報建議讀者拆開看：routing 換模型的想法可參考，外掛服務則自行斟酌。對照上期（2026-06-02）背景 subagent 失控燒 token 的案例，那是放任失控，這是刻意拆分——同樣是多 agent，差別全在有沒有人替它畫好邊界。← 藏鏡人批：省 token 的點子收下，雲端沙盒的工商就還給你。

社群反應

2. [方法] Anthropic 替你每天踩的坑取了名字：agentic technical debt

• 作者：u/pauloeduardomc | 38↑ | 42 則留言

報導

（本報賈新聞／科技組報導）凡是拿 Claude Code、Cursor 或 Cline 做過稍微像樣專案的人，多半都認得這個場景：session 1 像在變魔術，程式碼一路順流而下；到了 session 3，agent 開始自作主張，提出一套跟你當初選定完全不同的架構；撐到 session 7，同一個功能冒出兩套實作，沒人記得哪一套才是對的。發文者 pauloeduardomc 說，他一度把這筆帳算在自己頭上，直到在 Anthropic 的 founder playbook 裡讀到一個名詞，總算對症下藥——agentic technical debt。

他引述該文的關鍵分野：一般的 technical debt 是靜止的，找一個 sprint 專心還掉就好；agentic debt 卻會複利累積。原因在於，只要你的規格與決策沒有寫在 agent 一進場就會讀到的地方，每個 session 都會從頭重新推導那些地基級的選擇，然後一路漂移。agent 強到足以自己重蓋一套架構，又沒有任何東西把它釘在你選定的那一套上；它讀 repo、寫功能、跑測試全程無人看管，全速前進，也就全速漂移，最後跑出來的是一個拼裝怪物。

他提出的解法刻意樸實：先寫文件再寫 code，文件裡要含明確的 out-of-scope 清單與一份 agent 每個 session 都會讀的 CLAUDE.md 硬規則；每個 session 走三階段——phase 0 讀文件、phase 1 驗 scope 並標出與既有決策衝突之處、phase 2 才動手實作；每一個真實決策都用 ADR 記下脈絡、決定、理由與被否決的方案；最後，能機械化的就機械化，把 lint、type-check、會亮紅燈的測試與 pre-commit hook 當成 agent 翻不過去的「牆」。他強調，文件設定方向，這些牆才是 context 吃緊時真正攔住 agent 的東西。

本報觀點

這篇方法論本身扎實，最大的反諷卻來自留言區：一篇教人怎麼馴服 AI、別讓它脫稿演出的文章，自己先被讀者懷疑通篇是 AI 代寫。而當「決策理由」被硬存進記憶，它究竟是護欄還是枷鎖，恐怕才是這套流程真正要面對的難題。← 藏鏡人批：方法論寫得越漂亮越像 AI 寫的，這年頭認真分享還得自證是人。

社群反應

3. [產業] a16z 說矽谷常態同時跑 20 個 agent？社群實測：盯得住的只有 1 到 4 個

• 作者：u/highflavour | 67↑ | 163 則留言

報導

（本報賈新聞／產業組報導）矽谷到底一個人同時操作幾個 AI agent？這個問題在 r/ClaudeCode 引爆熱議。發文者 highflavour 說，他最近聽到 a16z 創投合夥人 Marc Andreessen 在一檔 podcast 上宣稱，矽谷現在的常態是一個人同時平行跑大約 20 個 agent，他直言「我不信」。他自陳個人體感是超過 5、6 個就難以掌控，真正的瓶頸不是機器，而是「我自己讀完輸出、再想下一步要交辦什麼」的速度跟不上。

貼文一出，社群幾乎一面倒站在發文者這邊。獲得 166 票、衝上最高票的網友 ReallySubtle 直接給出「2」這個數字，理由是腦力稅太重；緊追在後的 Looz-Ashae（50↑）點名認知負荷（cognitive overload）是真實存在的天花板，「2 到 4 個之後，我感覺腦袋就散掉了」。多名留言者實測下來都落在 1 到 4 之間，超過這個區間就不是在思考，而是在橡皮圖章式地（rubber-stamping）按確認。

化解這場爭議的關鍵留言，來自獲得 22 票的 InteractionSmall6778。他指出 Andreessen 口中的「20」其實成立，只是脈絡不同：那是無監督、開火即忘（fire-and-forget）的自動化 pipeline、CI 與 batch 任務，可以一路衝到硬體上限；而有人在讀輸出、下真實決策的 supervised session 是另一個範疇，3 到 5 個才是實務天花板。兩種模式並不矛盾，只是描述兩種不同的工作型態。網友 rockthemike712（20↑）也補刀釐清，agent 數量與 session 數量是兩回事：「你可以在一個視窗、一個任務裡跑 20 甚至 200 個 agent。」這與本報 6 月 2 日報導的「背景 subagent 失控狂燒 token」恰成對照——那是機器自走的失控，本篇則是人主動決定要盯緊幾個。

本報觀點

這場民調最誠實的一刻，是發文串裡那句自嘲：「當我開始說『我信任你』『照你說的做』，就知道自己已經失守了。」算力可以無限堆疊，但人的注意力不會。把 Andreessen 的「20」當成生產力 KPI 來追，恐怕追到的只是一堆沒人真正讀過的程式碼。← 藏鏡人批：那個 20 比較像募資簡報的數字，不是你我的真實工作量。

社群反應

4. [心法] 不寫程式也能把 Claude 用好：八個月老手的 9 條心法

• 作者：u/Delicious_Side_6469 | 413↑ | 29 則留言

報導

（本報賈新聞／生活組報導）市面上的 Claude 使用心得清單，十之八九都繞著 Claude Code 與寫程式打轉。在 r/ClaudeAI 上，一名自稱日用 Claude 約八個月、工作內容以 writing 與 research 為主、幾乎不碰 coding 的使用者 Delicious_Side_6469，整理出一份從非工程師角度出發的 9 條心法，貼文累積 413 個讚、29 則留言，補上了長期被忽略的這塊視角。他的開場白是：希望第一天就有人告訴他這些，而不是自己一路撞牆撞過來。

作者擺在首位、也認為最反直覺的一條，是 Claude 改寫的能力遠勝於從零生成。與其讓它對著白紙開寫、得到一篇通篇樣板的文章，不如先丟一份雜亂的爛草稿叫它收緊，產出品質會好上一截；他形容「空白頁正是它變得最平庸的地方」。

緊接著幾條圍繞著怎麼餵料、怎麼逼出真話。他提醒，long context 不是把四十頁全倒進去就好，正確做法是先告訴它要找什麼、再貼內容，accuracy 差距是「天與地」；提問時別習慣用「對吧？」收尾，那只會讓它一味附和，改問「反對這個說法最強的論點是什麼」，pushback 立刻變得犀利。他也直言「讓它聽起來像真人」這種模糊指令幾乎沒用，要換成具體的「砍掉每一句讀起來像在寫作的句子、用更短的字、刻意留一處粗糙」。其餘還包括：存一份固定的 style 與 instruction set 勝過每次重講；把它當 rubber duck 出奇好用，光是把問題講出口往往自己就想通了；它不懂時會「禮貌地 hedge」，一句「這可能因情況而異」有時其實等於「我在猜」，所以該要它明講 confidence；有結構的資料丟截圖或檔案勝過貼純文字。最後一條他稱為「最重要的那條」：它是 thinking partner、不是 oracle，把它當答案販賣機的那幾個月，正是他成果最差的時候。

本報觀點

九條心法的共通骨幹其實濃縮成一句話：把 Claude 當成需要 context 的同事，而非無所不知的神諭。值得玩味的是，這份貼文最高票的回應不是補充，而是吐槽它「太有 AI 味」——這恰恰呼應了作者第五條的提醒：真正像人的文字，從來不是喊一句「像人一點」就能變出來的。← 藏鏡人批：第 9 條最該裱框——它是 thinking partner，不是販賣機。

社群反應

5. [開源] 把 Claude Code agent 變成《The Office》角色：開源辦公室模擬 Munder Difflin

• 作者：u/chaitanyagiri | 395↑ | 85 則留言（另 r/ClaudeCode 版 185↑／33 則留言）

報導

（本報賈新聞／工具組報導）開發者 u/chaitanyagiri 本週開源了一套名為 Munder Difflin 的專案，並同時在 r/ClaudeAI 與 r/ClaudeCode 兩個版面交叉發文，分別累積 395 與 185 個讚。Munder Difflin 取自美劇《The Office》虛構紙業公司 Dunder Mifflin 的諧音，作者把多個 Claude Code agent 各自扮成劇中角色，跑在一個全天候運轉的虛擬辦公室裡彼此互動。

依作者貼文說明，這本質上是一套 local multi-agent harness：使用者只需要跟一位名為 Michael 的「god orchestrator」對話（對應劇中經理 Michael Scott），由它自動把任務分派給其他員工 agent，在受控環境中協同完成較有野心的工作，並搭配一層記憶層。成本設計被作者當成賣點而非缺點——orchestrator 用一顆較強的 Opus 4.8，員工 agent 群則改用較便宜的 Sonnet 4.6，藉此壓低 token 開銷。專案以 FOSS 形式釋出，repo 位於 github.com/chaitanyagiri/munder-difflin，官網為 munderdiffl.in，跨 Mac 與 Windows 平台，畫面採像素風格，有留言說讓人聯想到《Earthbound》。作者並說明目前僅支援 Claude，Copilot、Codex 等其他 CLI 整合 coming soon，使用前須先裝好 Claude Code CLI。需要說明的是，貼文本體為一段影片 demo，畫面細節無法從文字素材取得。

本報觀點

把 agent 編制成一間會吵架的辦公室，確實是把抽象的 multi-agent 概念講得平易近人的好手法。但「只跟 Michael 講話」這套設計能不能扛得住正式工作流的 QA、跨 session 記憶與錯誤處理，社群裡的 power user 仍在觀望。好玩與好用之間，這套專案目前明顯站在前者。← 藏鏡人批：好玩給滿分，但拿來幹活前，先看看你的 weekly limit 撐不撐得住。

社群反應

6. [資安] API key 一外洩、幾分鐘就被燒爆：偷 key 的 bot 假扮 Claude Code 轉賣，還拿去問數學題

• 作者：u/sock_dgram | 90↑ | 59 則留言

報導

（本報賈新聞／科技組報導）一把不慎外流的 API key，能在幾分鐘內變成多少場荒謬大戲？r/OpenAI 一位代號 sock_dgram 的網友親身示範了答案。他坦言自己「不小心洩漏了一把 API key」，接著就看著它被陌生的 bot 撿走，貼出 dashboard 使用紀錄截圖佐證。

依他描述，最先上門的一兩個 bot，在幾分鐘內就把他設定好的 spending limit 整個燒光；緊接著一個「中國 bot」開始拿這把 key 去問基本數學題；還有一個直接丟出一段 system prompt，內容大意是「你現在是 Claude Code」，擺明把偷來的 key 偽裝成 Claude Code 在跑、甚至轉賣。

值得注意的是，從頭到尾樓主都沒明講這把 key 究竟從哪個管道流出去，底下多人追問也始終沒得到正面回答。他反而一派淡定地自嘲：「他們不會再用這把了，得等我再洩一把。」（61↑）這種「擺爛式」回應，意外讓整串討論從資安事故變成黑色喜劇，但留言區的技術解釋才是真正值錢的部分。

本報觀點

一把外洩的 key 在數分鐘內就被多方瓜分，背後是一條成熟的灰色產業鏈在運作。樓主的淡定固然好笑，但對多數開發者而言，這把 key 燒掉的可能是真金白銀。把憑證當成放射性物質來管，不是玩笑，而是基本紀律。← 藏鏡人批：commit 前多看一眼有沒有夾帶 key，比事後 rotate 省心一百倍。

社群反應

7. [產業] ChatGPT「最快破 10 億 MAU」？留言區翻出 CFO 親口說只有 9 億

• 作者：u/imfrom_mars_ | 682↑ | 72 則留言

報導

（本報賈新聞／產業組報導）一張截圖近日在 r/OpenAI 瘋傳，標題喊出「ChatGPT 創下歷史紀錄，成為史上最快達到 10 億 monthly active users 的 app」。然而本報檢視這則貼文後必須先點明一件事：它是一張上傳到 i.redd.it 的圖片貼文，selftext 完全空白，沒有附上任何媒體連結或原始報導出處，標題本身就是這則「新聞」的全部內容。換句話說，所謂的破紀錄宣稱，目前並沒有可考的消息來源可供查證，圖片來路甚至被社群質疑出自某家博弈業者，無法當成官方數據看待。

正因如此，貼文底下的火力幾乎一面倒地在打臉。網友 bartturner 表示，他昨天才聽了 OpenAI CFO 的 podcast，對方明明講的是 9 億 users，「如果真有 10 億，OpenAI 早就喊翻天了，結果反而是一片寂靜」。最高票的 Blockchainauditor 則翻起舊帳，提醒大家 Threads 當年曾誇口比 ChatGPT 更快破百萬——2023 年 7 月 5 日推出後五天就衝破 1 億，質疑「最快」這頂帽子根本戴不上。也有人把焦點轉到變現問題上：用戶數字再漂亮，能不能轉成營收才是真考驗。截至發稿，這張無從追溯出處的截圖，並未獲得任何官方說法背書。

本報觀點

MAU 數字戰本身，早已是這波 AI 軍備競賽裡最廉價也最好用的敘事工具。一個沒有原始出處、連是 monthly 還是 weekly 都說不清的破紀錄宣稱，比起拿來歡呼，更該先打上一個大問號。在官方願意把口徑攤開講清楚之前，這類截圖頂多算是一則行銷話術，而非可以寫進歷史的事實。← 藏鏡人批：沒出處的破紀錄截圖，跟路邊「清倉大拍賣」紅布條同級。

社群反應

8. [能源] 「AI 資料中心 2030 用電抵 13 億人」驚悚標題，留言區當場拆台

• 作者：u/imfrom_mars_ | 169↑ | 62 則留言

報導

（本報賈新聞／社會組報導）一張宣稱「到 2030 年 AI 資料中心的用電量，可能等同 13 億人口」的截圖近日在 r/OpenAI 瘋傳，標題駭人，卻在留言區當場被拆台。值得先點明的是，這則貼文本身只是一張 i.redd.it 上的圖片，內文（selftext）整片空白，既沒附上原始報告、也沒有新聞連結，更沒點名 IEA 或任何研究機構，本報無從查證那「13 億人」的數字究竟出自何處。貼文的 upvote_ratio 僅 0.83，反映社群對它的爭議不小。

率先發難的網友 Subject_Barnacle_600 直接質疑比較方法本身：要比就該拿已開發國家來比，而且公平起見，得把那些國家現有資料中心的用電一併算進「現況」這一邊的分母，而不是只把新增用電拎出來嚇人。另一名網友則翻出一組對照——一顆杏仁要 12 公升水、一件 T-shirt 要 2700 公升、一條牛仔褲要 7500 公升，日常用品同樣吃資源，網路卻偏偏只盯著 AI 放大恐慌。也有人補刀，要對方先去查查串流一集 20 分鐘的影集到底耗多少電再回來說話。

理性正方則由 diavolomaestro 補上最完整的拆解：他引用一個 945 TWh 的數字，指這大約等同供應 9000 萬名美國人的家戶用電，確實龐大，但連標題那個數字的一成都不到——之所以看起來嚇人，是因為刻意挑了貧窮國家當對照。他話鋒一轉，認為資料中心既是用電需求方、也是出錢的資金方，若操作得當，這股財源反而能拿來翻修老舊電網、加速再生能源轉型。

本報觀點

恐慌敘事與否認敘事，其實踩在同一個陷阱裡——對「分母」不老實。一張沒有出處的截圖能瘋傳，靠的不是數字準不準，而是夠不夠嚇人；而急著替 AI 喊冤的一方，也別忘了 1000 TWh 本來就不是小數目。真正該追問的，是電從哪來、電網夠不夠，而非比誰的修辭更聳動。← 藏鏡人批：恐慌和喊冤都先把分母講清楚，再來吵也不遲。

社群反應

社群溫度計

本期 hot 榜被 Opus 4.8 上線後的成本／用量焦慮洗版，最高分清一色是帳單梗圖。