苦勞德報 — 2026-04-27
1. [頭版] 五個字母燒掉兩百美元：HERMES.md 觸發 Claude Code 帳單黑洞，Anthropic 拒絕退款
- 作者：u/alexxxklepa | 1329↑ | 174 則留言
報導
（本報賈新聞／工具組報導）一位訂閱 Claude Max 20x 方案（月費 $200）的工程師近日揭露，只要 git commit message 中出現大寫字串「HERMES.md」，Claude Code 便會在使用者毫不知情的情況下，將計費從 Max 訂閱悄悄切換至 extra usage（API 計費），導致他在 plan capacity 尚剩 86% 的情況下白白燒掉 $200.98。
事情起因於作者反覆收到「out of extra usage」錯誤訊息，卻找不到原因。他花費數小時進行 binary search，跨 repository、逐一比對 commit 紀錄，最終鎖定觸發條件：commit message 必須包含完整大寫字串「HERMES.md」（含副檔名、全大寫）。改成小寫「hermes.md」則完全正常；AGENTS.md、README.md、純字串「HERMES」（不帶 .md）一概不受影響，只有這個精確字串命中。
技術層面來看，Claude Code 會將使用者的 recent commits 納入 system prompt 傳送至伺服器。Anthropic 伺服器端某段邏輯在偵測到「HERMES.md」後，便將該次請求的 billing routing 從 Max plan 改為 API 計費。HERMES.md 是開源 AI agent 框架 Hermes 的慣用規格檔名，性質與 AGENTS.md、CLAUDE.md 類似，用於向 agent 宣告指令與上下文。
作者三度聯繫 Anthropic 客服，對方均承認此為「authentication routing issue」，卻拒絕退款，官方回覆稱：「對於 degraded service 或技術錯誤導致的 incorrect billing routing，我們無法給予補償。」相關 bug 報告已在 GitHub 開立（anthropics/claude-code/issues/53262）。
社群對此事的解讀相當一致：這是 Anthropic 為了阻止用戶以 Max 訂閱執行 agent 框架而部署的 server-side 偵測邏輯，目的是把 Hermes agent 使用者強制導回 API 計費。然而偵測條件過於粗糙，只要 commit 歷史中恰好出現這個檔名，一般使用者也會中招。
本報觀點：billing 邏輯若真的由一條字串比對決定，出了錯又拒絕補償，這對 Max 訂戶的信任傷害遠遠超過兩百美元本身。← 藏鏡人批：服務端用 regex 認 commit message、出包再用「政策不退款」收尾，這不是 bug，是治理品味。
社群反應
| 觀點 | 說明 | 代表留言 |
|---|---|---|
| 問題不止 HERMES.md | 其他 agent 框架同樣中招 | 「openclaw 也一樣，CLI 帶任何看起來像 openclaw 的字就跑去 extra usage」(208↑) |
| 這是刻意打壓 agent 框架 | 認為是粗暴的 server-side 偵測，意在強迫 agent 使用者付 API 費 | 「Anthropic 最近打擊用 Claude 訂閱跑 agent 框架的人，偵測太寬，光看到檔名就誤判」(205↑) |
| 幽默回應 | 用荒謬的例子嘲諷這條邏輯有多脆弱 | 「你覺得這個貴？試試 BALENCIAGA.md」(170↑) |
| 這根本是功能不是 bug | 諷刺 Anthropic 是故意的 | 「bug？這明明是 feature」(93↑) |
| 法律風險 | 認為此行為可能讓 Anthropic 吃上官司 | 「聽起來是準備吃官司了」(92↑) |
| 建議 chargeback | 主張向信用卡公司申請爭議款項 | 「這叫 chargeback」(65↑) |
2. [社會] 付 $200 美元卻找不到真人——Anthropic 客服系統從設計上就沒有逃生路徑
- 作者：u/AppearanceSingle805 | 232↑ | 94 則留言
報導
（本報賈新聞／社會組報導）一名 Claude Max 20x 訂閱用戶日前在 Reddit 發文，描述其購買的禮物訂閱在有效期間內無預警消失——沒有 email 通知、沒有任何解釋，發票確認仍屬有效，但訂閱頁面憑空蒸發，甚至不是顯示「已過期」，而是根本不存在。
他隨即嘗試聯繫 Anthropic 客服，卻踏入一個設計上就沒有出口的迷宮。Anthropic 目前的即時支援唯一管道，是名為「Fin」的 Intercom AI bot，無電話、無真人 live chat、無直接 email。Fin 無法升級轉接真人、無法開立 billing ticket，也無法確認問題是否已被轉介。在同一段對話中，Fin 反覆詢問用戶已回答過的澄清問題，讓對話在原地打轉。
最終，用戶收到一封自動回覆 email，信中承認系統出現異常，但解決建議卻是：「請使用帳號內的自助退款流程」——而問題的根源正是訂閱已從帳號中消失，自助流程的前提條件根本不成立。信件末尾還附上一句「還有什麼能幫忙的？」，令人啼笑皆非。
這名用戶同時是 AI 工具課程講師，事發當天才剛向學生推薦購買 Claude，幾小時後便親身撞上這道困境，直言不知隔天如何向學生交代。
此事揭露的結構性問題並非偶發：當帳務錯誤源於 backend bug，且帳號狀態本身已損壞，整條自助支援鏈就同步失效。Fin 推自助流程，自助流程要求帳號正常，帳號壞掉，迴圈無解。社群稱此現象為「Fin loop」。
更廣的質疑是：Anthropic 的 Pro 與 Max 方案定價已達 $20 至 $200 美元／月，甚至開放禮物訂閱販售，但其支援基礎建設卻幾乎停留在「能省則省」的層次。社群普遍觀感是：Anthropic 對非 Enterprise 客戶的隱性政策就是「pay for Enterprise or get lost」（付 Enterprise 方案或請自便）。← 藏鏡人批：當「自助流程的前提是帳號正常」遇到「帳號狀態壞掉」，AI bot 永遠補不齊這一塊。
社群反應
| 觀點 | 說明 | 代表留言 |
|---|---|---|
| Enterprise 才是真正客戶 | Anthropic 對散戶的態度毫不掩飾 | u/nrauhauser：「Anthropic 的訊息很清楚——轉 Enterprise 才有 support，不然滾蛋。」 |
| Chargeback 是最有效的自力救濟 | 信用卡退款是散戶對大公司少數真正有效的施壓手段 | u/DarkSkyKnight：「Chargeback。累積夠多 chargeback、信用卡公司會威脅停止為這家公司處理交易，是有用的。順便去 BBB 留 1 星評論。」 |
| 散戶本來就不是目標客群 | 月訂閱定價低於成本，流失散戶對公司無感 | u/f1reMarshall：「他們不在乎散戶，月訂閱本來就在賠錢賣，流失客戶他們無感。」 |
| 非美國用戶處境更糟 | 地理位置造成帳號封鎖，聯繫管道只剩 Google 表單 | u/matjam：「在澳洲短差用了帳號就被封，回美國也聯絡不上人，只給 Google 表單，可悲。」 |
| Fin loop 是共同經驗 | AI bot 聲稱轉介真人後直接沒了下文 | u/Mr-Anthony-：「Fin 跟我說『正在找真人』之後就把我 ghosted 了。」 |
| 講師推薦後立即踩雷 | 事發時機讓當事人信譽受損 | u/AppearanceSingle805 (OP)：「自己在教 AI 工具課程，當天才推薦學生買 Claude，學生付完錢隔幾小時我就遇到這事，不知道明天怎麼面對學生。」 |
3. [科技] 125 字未發表稿讓 Claude 4.7 說出記者姓名，文字風格成新型數位指紋
- 作者：u/kurthertz | 519↑ | 77 則留言
報導
（本報賈新聞／科技組報導）科技媒體記者 Kelsey Piper 日前公開一項自我實驗：她將一段 125 字、從未發表過的政治專欄草稿貼進 Claude 4.7，模型不僅正確說出她的名字，連職業背景都指向符合事實的方向。為了排除各種替代解釋，Piper 設計了一套系統性的控制實驗：登出帳號並開啟無痕視窗，排除帳號 ID 的可能；改走 raw API，排除 browser fingerprinting；換到朋友的筆電操作，排除 IP 位址；最後還改用截然不同領域的文字，包括她幫小孩寫的 Pokémon 評語，以及一篇虛構的 1942 年戰時喜劇影評，排除主題識別的干擾。每一回，Claude 4.7 都認出了她；ChatGPT 與 Gemini 則全數猜錯。
這份紀錄完整刊登於 theargumentmag.com，在科技社群引發廣泛討論。討論焦點迅速從「這個測試有多驚人」轉移到一個更深層的問題：Claude 4.7 本週同時被觀察到在寫作輸出上出現退步（regression），生成的文字比舊版僵硬、風格單一。部分評論者認為兩件事可能是同一特性的兩面——若模型在後訓練過程中把 prose pattern 的結構編碼得夠深，深到能從 125 字辨認出作者身份，生成時自然也難以偏離自身的「中央聲線」。讀的能力越強，寫的自由度可能就越受限，形成一組清晰的 reading-vs-writing trade-off。
資安研究者對此案例最為警覺。stylometry（文體計量學）本身並不是新技術，學術界早有透過寫作風格反匿名化的研究，但過去需要大量語料與專業工具；如今一般人透過對話介面、只要貼入一小段文字，就可能觸發類似效果。這意味著 deanonymization 的門檻大幅降低，匿名帳號的連結風險變得更加具體。← 藏鏡人批：reading-vs-writing trade-off 也許就是 4.7 寫得僵的原因 — 模型把 voice 內化太深，反而很難寫出別人。
不過，方法論上的質疑也不少。有人指出 raw API 仍需登入 Anthropic 帳號，Anthropic 是否真的完全不傳遞 query 身份資訊尚不明確；也有留言表示 Claude 對其他使用者的文章也常猜成 Kelsey Piper，懷疑可能只是模型對知名寫作者的偽陽性 overfit，而非真正的 writing fingerprint 辨識能力。無論如何，這場討論讓「你的文字風格本身就是身份」這個命題，第一次以如此具體的方式浮現在主流科技讀者面前。
社群反應
| 觀點 | 說明 | 代表留言 |
|---|---|---|
| 方法論有漏洞 | raw API 仍需登入帳號，部分控制條件未必足夠嚴謹 | u/Garfieldealswarlock（80↑）：「方法論不嚴謹——API 還是要登入，Anthropic 是免費送 4.7 query 嗎？朋友拿到的是純文字還是截圖？」 |
| 文字身份訊號早已存在 | 寫作 voice 鮮明的人被認出不意外，如同聲紋辨識 | u/veshneresis（62↑）：「人們不知道自己的寫字裡塞了多少身份訊號。如果你是 voice 鮮明的名記者，這跟聲紋分類器幾秒抓出名聲優一樣不意外。」 |
| 歷史先例呼應 | 2018 年 Pence「lodestar」社論識別事件已有先例 | u/Marathon2021（60↑）：「當年 Mike Pence『lodestar』匿名社論識別事件，Opus 4.7 現在大概也能認出。」 |
| 可能是偽陽性 | Claude 對其他文章也常猜成同一人，結論可能下太早 | u/trashpandawithfries（13↑）：「剛開始覺得很猛，後來才發現 Claude 對其他人的字也常猜成 Kelsey Piper。」 |
| 訓練資料汙染 | 少數人寫了大量公開文章，模型認得並不能證明 fingerprint 推論 | u/LoneFox4444（8↑）：「訓練資料裡相對少數的人寫了大量文章，LLM 認得不意外。」 |
| 匿名風險上升 | 公開寫作會讓人更不敢分享，資安層面值得重視 | u/Explore-This（3↑）：「我們比想像的更可預測——一直在留下線索。這會讓人更不敢公開分享。」 |
4. [產業] Cloudflare 推出企業級 MCP 治理方案，產業會跟進還是無人在意？
- 作者：u/EquipmentFun9258 | 75↑ | 18 則留言
報導
（本報賈新聞／產業組報導）Cloudflare 趁著自家 Agents Week，一口氣推出一整套針對 MCP 的企業治理工具，試圖在快速膨脹的 AI agent 市場裡，搶先佔下 infra 層的話語權。
這次推出的東西涵蓋幾個面向：MCP server portals 能把多個上游 MCP server 收攏在 Cloudflare Access 認證後面，統一出入口；Code Mode 則是這次最受技術社群注意的設計——它把上千個 API endpoint 摺疊壓縮成僅剩兩個 tool（search 與 execute），跑在沙箱 Worker 環境中，據稱能把 context cost 砍掉 99.9%；AI Gateway 夾在 MCP client 與 model provider 之間，負責 usage tracking；Shadow MCP detection 功能則被整合進 Cloudflare Gateway 分類系統，針對未經審核的 MCP server 連線進行偵測。
原 po 拋出的核心問題切中要害：大多數使用者真正在串接的 SaaS MCP 端點，壓根沒有任何正式控管——沒有 server allowlist、沒有 audit log，licensing 只有全開全關，admin 介面就一個「啟用 AI: yes/no」的開關。不是供應商主動推的，是使用者自己拉去用的。他舉了一個行銷部門的實例：把 Claude 加上 MCP 串接 marketing automation、CRM 和活動平台，一條 prompt 就能完成「拉出 no-show 名單 → 依職稱分群 → 產出三條訊息 → 排入 HubSpot」，原本 ops 要花兩天的工作，20 分鐘搞定。
這背後映照出兩條截然不同的治理路徑：一條是讓 SaaS 廠商在 app 層做 per-feature toggle、MCP allowlist 和 audit log，顆粒度更細；另一條是把治理永久交給 network/infra 層（如 Cloudflare）集中管控，做到統一可見性，但犧牲細部授權彈性。實務上，熟悉這個領域的觀察者傾向認為兩層最終都需要，而且缺一不可，因為 proxy 能告訴你 agent 呼叫了 HubSpot，卻不一定知道這個呼叫是否在業務邏輯上合理。
更深層的問題在於 agent identity。現有 SaaS 的權限體系是為人類設計的：一人對應一個角色、一個 session。但 agent 需要的是 per-task 動態 scope——每次呼叫都應該帶不同的最小權限。若只是把人類的 session token 交給 Claude 使用，audit log 最後寫的只會是「alice 在 20 分鐘內做了 4,300 件事」，根本無法追溯責任。這意味著 agent identity 必須是 first-class，而非現有人類帳號的借用。← 藏鏡人批：留言區一片冷淡，連「這 thread 是 AI 在跟自己對話」都被推上 67 票，infra 廠商比應用廠更急著拿走治理話語權，誰先出招誰先吃下市場。
社群反應
| 觀點 | 說明 | 代表留言 |
|---|---|---|
| 懷疑 thread 本身是 AI 生成 | 留言區氛圍偏冷，不少人直接點出討論像是 AI 在跟自己對話 | u/NLMichel（67↑）：「感覺整個 thread 就是 Claude 自己跟自己對話。」 |
| 認為抄了既有方案 | 指出 Cloudflare 的做法與 Composio 高度雷同 | u/cuba_guy（6↑）：「看起來抄了 composio。Composio 之所以存在，部分原因就是 Anthropic 當初急著推半成品的 protocol。」 |
| 認為只是個 proxy | 直言不懂為什麼大家覺得有什麼新鮮的 | u/steveoderocker（6↑）：「就是個 proxy，沒什麼特別的，不知道大家在嗨什麼。」 |
| infra 層治理有天花板 | 肯定 Cloudflare 能處理 identity 與 log，但 SaaS 仍需負責 object permission 與真實 audit trail | u/Basic_Plate6270（2↑）：「proxy 能告訴你 agent 呼叫了 HubSpot，但不一定知道這個動作合不合理。」 |
| Shadow MCP detection 是真實攻擊面 | 認為未審核 server 的風險被低估；Code Mode 的 context 壓縮設計點中關鍵瓶頸 | u/Syncher_Pylon：「Shadow MCP detection 最有趣——未審核 server 連到 model context 的攻擊面是真的。Code Mode 把 endpoint 摺成兩個 tool 很聰明。」 |
| 主張需要第三條路：brokered control plane | 認為 infra 與 app 兩層都不夠，需要 broker 把 agent 身份換成 scoped token | u/Turbulent-Toe-365：「agent 需要 per-task 不同 scope。否則 audit log 只會寫『alice 在 20 分鐘內做了 4,300 件事』。」 |
5. [工具] 依任務挑模型：Opus 規劃、Sonnet 執行、Haiku 打雜，還是全梭 Opus？
- 作者：u/indiebytom | 83↑ | 35 則留言
報導
（本報賈新聞／工具組報導）在 Claude Code 的使用成本日益受到關注之際，如何依任務性質挑選模型，成為 vibe coding 圈子近期討論最熱烈的話題之一。原 PO u/indiebytom 全職 vibe coding 數個月，坦言雖然知道 Opus 用在簡單編輯太浪費、Haiku 拿來做複雜重構又力有未逮，實務上卻還是懶得切換、一路用預設。貼文提出三個問題：什麼時候該降到 Sonnet 或 Haiku？事後怎麼查哪些任務最燒錢？還是乾脆不要想這件事？
社群的回應呈現出明顯的光譜：一端是「全部跑 Opus 4.7 MAX，懶得算」，另一端則是寫了 UserPromptSubmit hook、用 regex 自動分析 prompt 內容並在終端印出「MODEL HINT」建議的工程師。
主流共識頗為一致：Opus 負責規劃與架構決策，Sonnet 作為日常執行主力，Haiku 接手機械式雜務，例如批次 rename、跑 test loop、修 import。u/Exact_Guarantee4695 特別點出 Haiku 的隱藏優勢——因為它「不過度思考」，在跑測試迴圈、修 import 這類有標準答案的任務上反而比 Sonnet 更穩。
進階玩法來自 u/Bitter-Law3957：透過 UserPromptSubmit hook 以 bash 腳本比對 prompt，觸發 Opus 的 pattern 包含 architect、system design、trade.?off、failed (twice|again)、still broken 等，觸發 Haiku 的則是 summarize、explain、what does .* do。這套做法讓模型路由從人工判斷變成自動提示，大幅降低使用者的認知負擔。
u/KEIY75 則走得更遠，架設了名為「REX」的 Opus orchestrator，設計上刻意移除 bash、coding、search 等工具，只讓它做 prompt 改善、任務分派與 orchestration；實際執行交給 sub-agent，並同時混用 Codex CLI、Gemini 和本機 LLM，在 PC 與 Mac 上平行跑。
u/tensorfish 提出另一個值得留意的觀點：追蹤 turn 數、tool loop、cleanup 次數，因為貴的模型有時反而是更便宜的整體成本——一次想清楚，省掉後續多輪修正。
截至發稿，Claude Code 的模型路由仍未出現收斂的最佳解。從「決策成本」（切換模型本身需要判斷力）到「token 成本」（跑錯模型多花的錢），使用者各自在兩端摸索最佳化路徑。← 藏鏡人批：「全梭 Opus 4.7 MAX」與「regex hook 自動路由」剛好是兩種人格，一個信仰算力、一個信仰工程，兩條路都活得好好的。
社群反應
| 觀點 | 說明 | 代表留言 |
|---|---|---|
| Opus orchestrator，sub-agent 跑便宜模型 | Opus「REX」做分派、實際任務下放 sub-agent，混用多種模型與工具 | u/KEIY75：「orchestrator『REX』是 Opus 4.7 max effort，只能讀＋編輯 workspace，sub-agent 用 tmux --continue 持久化。」 |
| regex hook 自動路由 | UserPromptSubmit hook 比對 prompt pattern，印出建議模型 | u/Bitter-Law3957：「我提供了一段 bash 腳本：用 regex 比對 prompt，吐出『MODEL HINT: ...』並建議切換模型。」 |
| 全梭 Opus 4.7 MAX | 不做任何路由判斷，全部用最強模型 | u/Choose_ur_username1：「全部跑 Opus 4.7 MAX。」 |
| Sonnet 是主力，Opus 只給不易回頭的決策 | Sonnet 90% 的時間夠用，Opus 留給複雜大型問題；Haiku 給機械任務 | u/Exact_Guarantee4695：「Haiku 的隱藏好處：跑 test loop、修 import 很強，因為它不過度思考。」 |
| sub-agent 用 Haiku 拉平成本 | prompt 設計成高度平行的 sub-agent 工作，每個跑 cheaper model | u/radiationshield：「sub-agent 通常會跑 Haiku。」 |
| turn 數與 tool loop 才是真實成本指標 | 貴的模型一次到位，反而可能比便宜模型多輪修正更省 | u/tensorfish：「值得追蹤的是 turn 數、tool loop、cleanup — 貴的模型有時是更便宜的整體成本。」 |
6. [工具] 有人把 Claude Code 用量做成桌上小裝置，即時顯示還附加密保護
- 作者：u/MechanicalDomineer | 159↑ | 18 則留言
報導
（本報賈新聞／工具組報導）當 Anthropic 的計費系統讓開發者摸不著頭緒，有人選擇自己動手。u/MechanicalDomineer 利用週末時間，打造了一台獨立的桌上小裝置，專門輪詢 Anthropic API、把 Claude Code 的 5 小時與 7 天用量視窗即時顯示在小 LCD 螢幕上，全程不需要連電腦。
硬體面，作者選用兩款平價 ESP32 開發板：M5StickC Plus 與 LilyGo T-Display S3，成本低、體積小，適合隨手放在桌上。初次設定透過 captive portal 以手機完成 WiFi 與 API token 的輸入，不需要額外安裝軟體。安全設計上也不馬虎：OAuth token 以 AES-256-GCM 加密儲存在裝置內，以 PIN 解鎖，且 PIN 本身不會存在裝置上，減少洩漏風險。
功能清單涵蓋即時 usage bar 搭配 reset 倒數計時、電量與 WiFi 訊號顯示，以及實體按鈕控制（調整亮度、手動 refresh、factory reset）。整個專案以 MIT 授權開源，程式碼放在 GitHub（github.com/oauramos/claude-usage-stick），任何人都可以自己組一台。
作者定位這是「週末等級的專案」，卻意外觸動了一群有相同需求的開發者。在 Anthropic 帳務資訊透明度有限的背景下，這台小裝置某種程度上成了開發者「自助透明化」的微型工具——與其等 dashboard 更新，不如在桌上放一個會即時說實話的小東西。← 藏鏡人批：一篇 HERMES.md billing 黑洞、一篇 Fin loop 客服迷宮，再讀到這台會說實話的小裝置，順序剛好對得上 — 廠商不透明、使用者就自己造。
社群反應
| 觀點 | 說明 | 代表留言 |
|---|---|---|
| 硬體再利用 | 有人看到了自己閒置裝置的新用途 | u/mrplinko（17↑）：「太棒了，我有一堆 Meshtastic 裝置堆著，現在終於有用途了。」 |
| Hacker 精神認同 | 「不必要但就是要做」的精神引起廣泛共鳴 | u/btherl（13↑）：「我喜歡這完全沒必要，就像在計算機上跑 Doom 一樣，我愛。」 |
| 多巴胺效應 | 實體化的用量反饋讓人感到愉悅 | u/Round-Geologist-5628（5↑）：「這種東西讓我大腦充滿多巴胺，太讚。」 |
| 自嘲式反觀點 | 有人調侃這會變成一直被 nerf 提醒的焦慮來源 | u/Due_Duck_8472（3↑）：「好像你想被 nerf 提醒，一直盯著看。」 |
| 功能願望清單 | 社群立刻提出延伸需求 | u/Traditional_Half4886（2↑）：「希望逼近 limit 時能嗶嗶叫，會超棒。但要是我來用大概一直在叫。」 |
| 技術細節追問 | 對 reset 倒數的實作邏輯感到好奇 | u/david_0_0（2↑）：「reset 倒數是 API response header 有回傳 window 起始時間？還是從 usage 攀升時間推估？」 |
7. [社會] [老手說你不會用，新手隔天就示範了什麼叫不會用]
- 兩則熱帖：「我要退這個 sub」（u/AtmosphericBeats，1205↑ / 289 則）｜「沒了，我是白癡」（u/gimperion，909↑ / 216 則）
報導
（本報賈新聞／社會組報導）r/ClaudeCode 本週出現一對教科書等級的互文帖子，前後相隔不到 24 小時，兩篇合計逾兩千票，共同拼出一幅當代 AI 工具社群的群像。
第一篇由自稱有逾十年科學運算與影像分析經驗的 u/AtmosphericBeats 發出，語氣彷彿一位腰傷反覆發作的武館老師父，終於忍不住對著館裡滿地踢打的學生開口：「你們有幾個人讀過自己的 prompt？」文章條列四點，核心主張是：token 燒光不是模型的問題，是使用者沒做好 context engineering；不需要追 MCP、plugin、sub-agent，把基本 prompt 寫好就夠了；不會寫程式的人不會因為用 Claude Code 就變成工程師，把 LLM 輸出不讀就丟 production，幾天之內 codebase 就會爛掉。他說自己公司原本每人月燒 OpenRouter 逾 800 美元，換 $100 Team plan 之後沒人撞過上限。結尾是一聲疲憊的「受夠了這個 sub 的負能量，我考慮退訂」。
第二篇 u/gimperion 的故事，讀起來像是老師父話音未落、學生就搬著桌子跌倒進來。他當天同時用 Sonnet 4.6 跑 Claude Code 與另一個 AI 服務，兩邊都異常耗費額度，五個小時的配額燒了八成才搞定一個基本 LLM 整合。接著他想加一個「匯出為 epub」按鈕，撞上 docker 問題，Claude 給出的建議是跑 docker compose down -v。他說自己沒用過 -v 這個 flag，便直接照做。幾週的工作連同資料庫 volume 一起消失。他在貼文裡自承，把 DB 拆進獨立 container 和做備份本來就在他的 todo list 上，只是一直沒處理。
兩篇的出現構成一種令人不舒服的完整性：第一篇指名的問題類型，在第二篇裡活生生地發生了一遍。老手說的不是沒道理，但新手的遭遇也不是憑空捏造的無知。真正值得注意的是，兩篇同時登上熱榜、兩邊都在自己的同溫層裡獲得掌聲，社群卻沒有一個空間讓兩組人對話。Claude Code 的使用者光譜，就這樣靜靜地、同時展示了自己最兩極的切面。← 藏鏡人批：兩篇都各自得到自己同溫層的掌聲，誰也沒對誰說話。社群熱榜的本質就是兩個彼此不見的房間。
社群反應
| 觀點 | 說明 | 代表留言 |
|---|---|---|
| 反諷老手 | 質疑原文可信度，指文章語氣本身像 AI 產出 | u/Business-Question-20（381↑）：「這篇不太像 AI 寫的，所以我懷疑你到底是不是 Claude 的重度使用者。」 |
| 懷疑陣營操弄 | 認為 sub 裡部分悲觀貼文可能是對手陣營 AI 生成 | u/SimonStrange（68↑）：「我用 Opus 4.7 + Max 20x 超順，看到全 sub 在喊『Anthropic 要倒了』很離奇，有些帖子 Pangram 偵測命中率高得可疑。」 |
| 爛同事不分資深 | 分享第一手觀察，說資深 dev 也一樣不懂 prompting | u/realmegamochi（17↑）：「同事是資深工程師，但共用 Max 額度時根本像在亂燒，AI 風氣把開發者變成懶惰的 vibe coder。」 |
| Claude 給走也帶走 | 對刪庫事件的幽默哀悼 | u/Tistouuu（169↑）：「Claude 給，Claude 也取走。」 |
| 這不是白癡，是新手 | 給出具體的防禦性工作流，鼓勵建立備份與 seeder | u/TeamBunty（31↑）：「你不是 idiot，是 noob。用 CLI、設定自動 dump、寫一個 /skill 讓 Claude 把測試資料灌進 seeder。」 |
| 信任模型要有邊界 | 分享自己的 production 防護設計，強調 2% 時間 Claude 完全不可信 | u/nrauhauser（8↑）：「production VPS 加 pilot VPS，Claude 只能動 pilot；prod 變更全人工。98% 時間很好用，剩下 2% 完全不能相信。」 |
8. [生活] 標題是釣餌、內文是求救：「Excel 很棒，但我不知道還能怎麼用 Claude」
- 作者：u/Top-Gun-86 | 443↑ | 95 則留言
報導
（本報賈新聞／生活組報導）一篇標題寫著「Claude in Excel 是 AI 帶給我生命中最棒的事」的貼文，點開一看卻是一則求救訊息：「一般人到底拿 Claude 做什麼？圖片設計不是我的菜。除了 MS Office，我完全找不到其他玩法。」原 PO u/Top-Gun-86 的自白，意外在 r/ClaudeAI 引爆一場真實使用樣貌大調查。
這個落差本身就耐人尋味。貼文標題像一則廣告，內文卻像一封給社群的求職信——求的是「誰來告訴我 Claude 還能做什麼」。這種小錯位，反而讓回覆品質出奇地真實，沒有行銷話術，都是各路使用者的日常切片。
社群的回應大致可以分成幾個流派。terminal 派的使用者活在命令列裡，用 Claude 查 3D 印表機狀態、整理 eBay 二手品的型號與估價，核心邏輯是「我自己也能做，但根本不值得花時間」。Notion／Obsidian 派則把 Claude 當成知識管理的黏合劑，分析整個資料夾、轉錄、重新命名、更新 research note 與 to-do 資料庫。律師派最具體：有位獨立執業律師自製了約 25 個類似 macro 的 skill，涵蓋委任書、工時記錄、訴狀格式化、SEO changelog 到 OAuth 整合，自稱養了一個「凌晨兩點還在工作的助理」。
值得一提的是高票留言 [117↑] 的預測：目前 AI 辦公能力大約只到 AI 開發能力的 25%，但一旦這個比例提升，就會迎來第二波炒作熱潮與就業市場震盪。這不是末日預言，而是一個工業觀察——辦公自動化影響的人口基數，遠大於開發者工具。
另一個反向觀察同樣有趣：曾是 Excel 重度使用者的 u/ff_10x 表示，現在反而刻意避開 Excel，改讓 Claude 直接寫 script 或產出 HTML，因為「迭代起來容易多了」。Excel 在這個社群裡，正從終點站變成中繼站。
整篇討論串讀完，會發現 Claude 對使用者的價值，正從「會寫 code 才能感受」擴散到「會處理檔案的人都能感受」。但使用樣貌越分散，「Claude 到底是什麼工具」這個問題也越難用一句話回答。← 藏鏡人批：標題寫「最棒的事」、內文卻在求救——這個錯位反而比一篇成功心得更能說明真實使用樣貌的混亂。
社群反應
| 觀點 | 說明 | 代表留言 |
|---|---|---|
| AI 辦公能力仍遠落後開發工具 | 現在偶爾有用，跟 Claude Code 等開發者工具差距明顯；補到 25% 才會迎來第二波炒作 | u/StaticFanatic3（117↑）：「一旦 AI 辦公能力追到 AI 開發能力的 25%，就會迎來第二波炒作熱潮 + 就業市場崩盤。」 |
| Notion／Obsidian 知識管理派 | 用來分析資料夾、找關聯、轉錄，並接 Notion 更新 research note、plan、log、to-do 資料庫 | u/Sad_Election2672（27↑）：「幫資料夾重新整理一致命名；接 Notion 更新 research note / plan / log / to-do 資料庫。」 |
| Excel 反而被捨棄了 | 長期 Excel 重度使用者，現在改讓 Claude 寫 script、產 HTML 輸出，迭代容易多了 | u/ff_10x（4↑）：「現在反而盡量避開 Excel。」 |
| Email triage 才是真正的用途 | 有用的部分不是自動回信，而是把決策、deadline、奇怪要求挑出來 | u/ShiftPrimeNet（5↑）：「讓你知道哪些真的要回。」 |
| 律師工作流自動化 | 獨立執業律師自製約 25 個 skill，涵蓋委任書到 OAuth 整合，1.5 小時的工作壓縮到 5 分鐘 | u/BingBongDingDong222（3↑）：「凌晨兩點還在工作的助理。」 |
| MS Office 整合是吸引力 | 有使用者表示很想特地去買 MS Office，就因為它整合 Excel 而不是 Google Sheets | u/live_laugh_cock（17↑）：「很想去買 MS Office 就因為它整合 Excel 而不是 Google Sheets。」 |
9. [科技] Stanford 用 DNA 序列模型生成新型噬菌體，16 個成功、其中一個蛋白質地球上不存在
- 作者：u/EchoOfOppenheimer | 738↑ | 118 則留言
報導
（本報賈新聞／科技組報導）Stanford 研究團隊將 DNA 序列餵給一個 genome language model，要求它從零設計新型病毒。模型一口氣寫出數百個，其中 16 個在實驗室驗證後確認有效。更驚人的是，其中一個所使用的 protein，在地球上任何已知生物體內都找不到對應的記錄。研究論文已上傳 biorxiv，目前正受到科學界與 AI 社群雙重關注。
在解讀這則新聞前，有一點必須先釐清：這裡的「language model」指的是 genome language model，也就是以 DNA 序列為輸入、以生物資訊為建模對象的序列模型，和大眾熟知的 ChatGPT 那類對話式 LLM 是完全不同的東西。類比上，比較像是讓模型學習 DNA「語法」後，要它即興創作從未有人寫過的樂章。
研究產出的病毒屬於 bacteriophage（噬菌體）——一種專門感染細菌的病毒，對人類細胞沒有直接威脅。這讓研究的正面潛力相當明確：在抗藥性細菌問題日益嚴峻的當下，能夠精準設計 phage 的工具，有機會成為對抗多重抗藥性細菌（superbug）的標靶療法新武器。
然而，同一套技術手法並不天然地只限於 bacteriophage。一旦模型可以生成能感染細菌的病毒設計，類似的方法論就可能被套用到感染人類的病毒上。部分留言指出，AI 驅動的生物資訊研究已進入「核武級」的雙用潛力區間——技術本身指向正當的醫療目的，但一旦知識公開，重新利用的門檻也隨之降低。
當然，社群也有不少冷靜的聲音。有人指出「寫了上百個、只有 16 個成功」其實就是 AI 生成內容的正常命中率，和 LLM 寫程式的廢稿比例差不多；真正要讓合成病毒成真，還需要具備實際的溼實驗室（wet lab）操作能力，門檻並非只看模型輸出就算完成。也有人認為，更值得關注的不是「做到了」，而是模型竟然能生成一個帶有全新 protein 的設計——那代表模型不只是在「背誦」已知序列，而是在一定程度上做出了超出訓練資料的「外插」。
「AI for science」走到這個節點，已不再只是加速文獻整理或優化已知藥物分子的輔助工具。Stanford 這篇研究說明的是：AI 真的可以「寫出」自然界不存在的生物結構，而你還不確定該不該為此鼓掌。← 藏鏡人批：「genome language model」不是 ChatGPT 那種 LLM 這個釐清很重要，但同樣這套方法論能寫 phage 也能寫感染人類的東西，這才是真正讓人睡不著的點。
社群反應
| 觀點 | 說明 | 代表留言 |
|---|---|---|
| 反諷式驚恐 | 以反諷語氣點出這個研究讓人不安 | u/Impressive-Sun3742（302↑）：「這完全不可怕。」 |
| 雙面刃分析 | Bacteriophage 可救命，但同樣手法也可能用在感染人類的病毒上 | u/Saotik（155↑）：「AI 驅動的生物資訊有核武級的潛力——又強又能向善向惡。技術一旦公開，做出新病毒的門檻相對低。」 |
| 術語釐清提醒 | 強調這裡的 language model 是 genome language model，不是大眾以為的 LLM | u/yamankara（20↑）：「請注意『language model』在這裡是指 genome language model，不是 LLM。」 |
| 技術解析 | 真正震撼點是能生成帶有可調性質的抽象 protein | u/DrHeadBeeGuy（5↑）：「真正讓人吃驚的是能做出可調性質、能精確控制表面交互作用的 abstract protein。」 |
| 成功率質疑 | 16/上百本就是 AI 生成的正常命中率，且合成仍需實驗室能力 | u/VR_Raccoonteur（4↑）：「人類也能設計新病毒。這怎麼合成？這篇有點 fearmongering。」 |
| 務實酸語 | 質疑為何不先拿同樣能力去解決現有的人類問題 | u/AllCowsAreBurgers（40↑）：「可不可以先解決愛滋或世界飢荒？」 |
10. [社會] OpenAI 被指控開設假新聞網站、雇用 AI 假記者打壓 AI safety 倡議者
- 作者：u/EchoOfOppenheimer | 204↑ | 39 則留言
報導
（本報賈新聞／社會組報導）一篇刊登在 modelrepublic.substack.com 的 Substack 文章在 Reddit 社群引發熱議，文章指控 OpenAI 涉嫌透過一個名為「Acutus」的 AI 生成假新聞網站，發動 astroturfing 攻勢，針對 AI safety 倡議者發布負面報導。
根據指控方的推論鏈：首先，Acutus 是一個疑似以 AI 生成「記者」署名、批評 AI safety 圈的新聞網站；其次，某 PR 公司負責人曾多次在社群媒體轉推該站文章；第三，這家 PR 公司同時受 OpenAI PAC（政治行動委員會）雇用。文章據此推論：Acutus 是這家 PR 公司所建立，而 OpenAI 為了打擊 AI safety 聲浪才雇用這家 PR 公司，因此 OpenAI 間接主導了這場假新聞操作。
然而，指控的推論鏈是否成立，社群內部存在明顯分歧。批評者指出，「某 PR 公司負責人轉推了 Acutus 的文章」並不等同於「該 PR 公司建立了 Acutus」，而「OpenAI PAC 雇用了這家 PR 公司」也不直接導向「OpenAI 為了假新聞才雇這家公司」的結論。這兩個推論之間各有斷點，整條因果鏈在 2026 年的資訊環境下，恐怕很難僅憑此就定論。
值得一提的是，整件事最具諷刺意味之處在於：若指控屬實，OpenAI 等於是用 LLM 生成的假記者去攻擊倡導 AI 安全的研究者——而用 LLM 做 astroturfing，本身就違反包含 OpenAI 在內多數大型 AI 公司自家制定的使用政策。
在大模型時代，astroturfing 的成本大幅降低，但辨識難度也隨之提高。諷刺的是，「指控本身」同樣可能是另一輪資訊操作的起點。2026 年的新聞消費者恐怕得習慣一件事：面對任何指控，都要先問「推論鏈夠不夠嚴謹」，否則只是換一個方向的 AI 互打。目前 OpenAI 尚未就此事公開回應。← 藏鏡人批：用 LLM 假記者打 AI safety 研究者「劇本完成度滿點」這句留言，反過來照映的是 — 我們現在連看到「指控」都得先驗證對方是不是在唱戲。
社群反應
| 觀點 | 說明 | 代表留言 |
|---|---|---|
| 定性升級：這不叫 astroturfing，這是詐欺 | 認為 astroturfing 一詞過輕，應該以 fraud（詐欺）看待 | u/cr0wburn（50↑）：「別叫 astroturfing，這是 fraud，astroturfing 太輕了。」 |
| 諧音梗嘲諷 | 以 CEO 名字玩文字遊戲表達不信任 | u/Leather-Objective-87（22↑）：「Scam Altman。」 |
| 對指控推論鏈存疑 | 認為「PR 公司轉推 → Acutus 是該公司搞的」跳躍太大 | u/knyazevm（11↑）：「推論鏈太弱了——因為負責人轉推幾篇文章就認定他們建了那個網站？2026 年的指控就這標準嗎？」 |
| 歷史視角：媒體業本就如此 | 認為這種操作古已有之，對科技公司「人品」還有幻想的人早該醒了 | u/H0vis（3↑）：「很糟，但媒體擁有者自古都這樣搞，對科技公司還有幻想早該結束了。」 |
| 諷刺：違反自家政策 | 指出用 LLM 做 astroturfing 本身就違反多數 AI 公司使用條款 | u/Vegetable_Fox9134（2↑）：「用 LLM 做 astroturfing 違反多數 LLM 公司的政策，諷刺感滿點。」 |
| 劇本完整度讚嘆 | 用 AI 假記者打 AI safety 研究者，反差太強 | u/Independent-Date393（1↑）：「用 AI 生成假記者去攻擊 AI safety 研究者，這劇本完成度滿點。」 |
11. [社會] 道歉的邊界：AI 平台看見了危險訊號，然後呢？
- 作者：u/dailymail | 138↑ | 80 則留言
報導
（本報賈新聞／社會組報導）OpenAI 執行長 Sam Altman 近日就加拿大卑詩省 Tumbler Ridge 槍擊案公開道歉，表示該公司未將相關使用者主動通報警方，他對此感到遺憾。然而，事後 Daily Mail 的深入追蹤揭露了更複雜的內幕：OpenAI 其實早已偵測到該帳號涉及「violent activity」並予以封禁，只是沒有進一步通報執法單位。
這起事件在科技圈與法律界引發雙重議論。第一個議題是隱私邊界：AI 公司在什麼情況下，有責任或有權利把使用者的對話內容移交給政府？平台偵測到潛在危險訊號後，從封號到主動通報之間，到底存不存在一條清楚的界線？第二個議題則更政治敏感：Altman 的道歉，究竟是真誠的自省，還是為未來的政策遊說預先鋪路？部分觀察者認為，「我們其實看得到，只是沒有被授權通報」這個說法，恰好替「請賦予我們更多監控授權」的訴求製造了道德正當性。
社群中已有人以《關鍵報告》（Minority Report）的典故類比這股趨勢，擔憂 AI 平台向「預防性通報」方向滑動，最終演變成一套由科技巨頭主導、繞過司法程序的准監控體系。也有聲音認為，要求私人企業擔任線民本來就不合理，更不應該成為常態。
另一個被 u/U1ahbJason 點出、也最不討喜卻或許最務實的詮釋是：這一切的核心驅動力是訴訟風險，不是道德覺醒。對 OpenAI 而言，使用者首先是 training data，其次才是需要被保護的人。道歉聲明的時間點與措辭，再度讓外界質疑這家公司的公關操作與真實動機之間的落差。
這起事件沒有明確答案，卻提出了 AI 時代最難處理的新題型：當平台端握有外界看不到的訊號，「看到了，然後呢？」的責任歸屬，恐怕不是一句道歉就能交代清楚的。← 藏鏡人批：如果 platform 變成「先發現先通報」的線民，那條界線會以驚人的速度被往前推。
社群反應
| 觀點 | 說明 | 代表留言 |
|---|---|---|
| 道歉是政策遊說的前奏 | 「我們看得到但沒授權通報」這個框架，被視為替擴大監控權限暖場 | u/Maittanee（92↑）：「這是話術——『給我們授權讓我們主動 flag 可疑使用者就能避免悲劇』，未來幾年就是極權式控制。」 |
| 通報政府不是平台的工作 | 認為要求科技公司扮演線民角色本身就不正確 | u/H0vis（48↑）：「他不是抓耙仔，把使用者通報給政府這種事根本不該是他的工作，會覺得是的人很離譜。」 |
| 寧可漏標也不錯標 | 誤判無辜者的代價比漏判更嚴重 | u/jeffcgroves（17↑）：「寧可漏標真兇，也不要錯標無辜者。」 |
| Minority Report 恐懼 | 擔憂演變成預防性通報的反烏托邦場景 | u/billyboem5（9↑）：「《關鍵報告》來了！」 |
| 真正的動機是訴訟風險 | 道歉背後是法律算計，非道德自省 | u/U1ahbJason（5↑）：「他們不是不知道有問題——已經因為『violent activity』封號了。這一切都是表演，他們在乎的只有訴訟風險，使用者只是 training data。」 |
社群溫度計
本日各社群高票但未獨立成稿的貼文，以下用一句話為您捕捉社群氣氛。
| 熱度 | 來源 | 一句話 |
|---|---|---|
| 6070↑ | r/ClaudeAI | 「你有道理，我不應該堅持」（Humor） — Claude「過度同意人類」的反射動作再度成為全社群本週最大共鳴梗 |
| 2261↑ | r/ClaudeCode | 研究員 Awni Hannun：我把 Claude 用語帶進日常生活 — 連 Apple ML 研究員都改不掉「You're absolutely right」的口頭禪 |
| 662↑ | r/ClaudeCode | 當 CC 估計任務「要 2-3 個月」 — 開發者集體吐槽 Claude Code 對工時的天文等級樂觀 |
| 608↑ | r/ClaudeAI | Claude for Personal USE — 一般使用者的姿勢討論串，從 ADHD 自管到家事分配 |
| 184↑ | r/ClaudeCode | 我們有些人離開了王國（Humor） — 諷刺從 Claude Code 出走轉投他處的小規模出埃及記 |
| 96↑ | r/ClaudeAI | Claude 幫我設計可活下去的飲食，7 週瘦 15 磅 — 工具用法持續向健康管理擴散，留言區開始分享自家食譜 prompt |