苦勞德報 — 2026-07-13

2026-07-13

1. [頭版] 大限又延一週！Fable 5 退訂閱、週額砍半，社群怒喊「別再玩懦夫遊戲」

• 作者：u/DavidCBlack | 3694↑ | 619 則留言
• 輔助來源：
  • Anthropic 這是搬石頭砸自己的腳嗎？（907↑／328 則）
  • 我月付 200 美元，明天過後卻用不到最強模型？（723↑／293 則）
  • Fable 5 要走、週限砍半，Claude 還值得續訂嗎？（650↑／316 則）
  • 訂閱營收不到 5%，他們可能根本不在乎留不留 Fable（639↑／194 則）
  • Fable 一走大家就跑光，對吧？（397↑／268 則）
  • Fable 與 50% 加碼延到 7/19（365↑／99 則）

報導

（本報賈新聞／產業組報導）Anthropic 的旗艦模型 Fable 5 這幾天成了社群最大的火藥庫。事情的骨幹是這樣的：依官方 support 文件，Fable 5 目前是「促銷期」限定開放，Pro、Max、Team 訂閱戶可以動用「每週訂閱額度的至多 50%」在 Fable 5 上、不另外收費，但這顆模型是從一般每週額度扣，而且消耗速度比其他模型快得多。促銷原訂 2026 年 7 月 1 日到 7 月 19 日（太平洋時間 23:59:59）結束；一旦收攤，Fable 5 就只能透過「另外計費的 usage credits」使用，Free 方案完全不適用，API 也不含在內、照標準價另計。搭配這波，社群同時盯上的還有一個數字：原本要把加碼的 50% 週額度收回，等於實際可用量往下砍。

真正點燃怒火的，是「反覆延期」這件事本身。原本盛傳 7 月 12、13 日就要斷，結果官方又把 Fable 與 50% 加碼一路延到 7 月 19 日。頭版這則貼文標題就叫〈Access has been extended〉，最高票留言一句話打中所有人：「他們是不是要每次都在移除前一天才延一次，延到天荒地老？」（1413↑）另一則喊「別再延了，直接做成永久的。沒人喜歡這種膽小鬼對撞遊戲」（895↑），還有人乾脆送上「反覆橫跳」（222↑）當註腳。有人挖苦這根本是「行銷團隊毫無計畫」（151↑），更有人自嘲「我們真的變成巴夫洛夫的狗了」（12↑）——每週被鈴聲制約、瘋狂燒額度。

對照官方口徑的「促銷福利」，社群反應幾乎一面倒。多篇討論把矛頭指向對手：OpenAI 的 GPT-5.6 Sol 已經上線，被認為在編碼工作流上與 Fable 5 同級，卻是固定費率、額度更慷慨還有「免費重置」；Grok 4.5 同樣被點名逼近 Opus，也是固定費率。有人算過帳直接倒戈：「他們明天真移掉 Fable 5，我就轉去 Codex 的 200 美元方案」（253↑），並補一刀——訂閱戶才是關鍵客戶，是他們在公司內部替 Claude 說話、去跟主管爭預算，企業大單正是這樣長出來的。這正好回應了「訂閱營收不到 5%」那則貼文的爭論：帳面數字看似無足輕重，但最高票反問「難道要讓每個私下用工具的開發者都轉去 Codex，然後上班時再回頭跟主管說他們偏好 Codex 嗎？」（392↑）訂閱其實是企業轉化的漏斗上緣。

至於「該不該續訂」與「會不會出走」，社群分成三派。一派已經用腳投票：「燒完額度就取消，我現在在 OpenAI 了，切換只要幾秒、還免費」（25↑）；一派賭 Anthropic 會再讓步——「他們絕對、絕對會踩煞車回頭」（318↑）；還有務實派選擇同時養兩個訂閱、不追 hype。反覆延期的副作用也真實存在：不只一位使用者坦承為了在斷線前榨乾額度而「自己給自己上緊發條、犧牲健康」，直說「開始覺得像被當玩具耍」。

本報觀點：把最強模型當成每週續約的倒數計時器，短期或許逼出一波瘋狂用量與話題，長期卻是在磨損最忠誠那群人的信任。當對手用固定費率把「安心感」變成賣點，Anthropic 這種一延再延、砍了又補的節奏，賺到的是聲量、賠掉的是可預期性——而可預期性，正是付費訂閱戶掏錢的真正理由。← 藏鏡人批：把旗艦模型做成每週抽獎，抽到的是聲量，抽走的是信任。

社群反應

2. [科技] GPT-5.6 Sol GA 首週實測風向：Claude 老用戶改口叫好，甚至有人喊「告別 Claude」

• 作者：u/Nevetsny | 169↑ | 82 則留言
• 輔助來源：
  • 告別 Claude，好聚好散（139↑／58 則）
  • 我出題挑戰 GPT-5.6 Sol，它五分鐘就交件（221↑／50 則）

報導

（本報賈新聞／科技組報導）OpenAI 新一代模型 GPT-5.6 的三兄弟——旗艦 Sol、中階 Terra、最快最便宜的 Luna——已於 2026 年 7 月 9 日全面 GA，橫跨 ChatGPT、Codex 與 OpenAI API，24 小時內在全球鋪開。這波開放接在 6 月 26 日的限量 preview 之後，當時僅約 20 家美國政府核可的組織拿得到；直到美國商務部旗下 CAISI 完成安全審查、放行更廣存取，三兄弟才一次全面登場。API self-serve 定價為 Sol 每百萬 token 輸入 5 美元／輸出 30 美元、Terra 2.5／15 美元、Luna 1／6 美元，Terra 的效能被官方對標到前一代 GPT-5.5。

GA 首週，r/OpenAI 上最搶眼的不是官方數字，而是一批「本來根本不用 GPT」的開發者集體改口。發文者 u/Nevetsny 坦言自己過去在 coding 上完全倒向 Claude、甚至早已停用 GPT，這次卻被 Sol XHigh 的表現「真心嚇到」；另一則貼文標題直接下「告別 Claude，好聚好散」，作者說 Sol 5.6 在 coding、推理、以及中途轉向的能力上徹底說服了他。最戲劇化的一篇，是有人丟出「用你覺得最好的 stack 幫我做一個倫敦市中心的 3D 互動網站」的挑戰，聲稱 Sol 連同瀏覽器檢查與 vision 分析，五分鐘內就交件。

值得注意的是，這股風向轉得這麼急，背景正好卡在 Anthropic 這頭的 Fable 定價與延期爭議同時發酵——多位發文者是把「對 Claude／Fable 的失望」與「對 Sol 的驚艷」放在同一口氣裡講的，讀者不難理解為何此刻鐘擺特別大力地盪向 OpenAI 這邊。

本報觀點：實測好評看得人熱血，但要提醒兩件事。其一是樣本偏差——會特地發文說「我從 Claude 跳槽」的，本來就是情緒濃度最高的一群，留言區也已有人質疑這些貼文「像業配」。其二是蜜月期效應：新模型 GA 首週的驚艷，往往混雜了額度被反覆重置的甜頭（有網友回報一週內看到第三次 usage 重置）與嘗鮮心理。至於那個五分鐘的 3D 倫敦，最高票留言就潑了冷水——「打開原始碼搞不好是 div soup、three.js 還載了兩次」，甚至有人懷疑成品根本是 OpenAI 訓練資料裡現成的 open source 專案。好不好，還是得等蜜月期過了、拿真正的專案磨過才算數。← 藏鏡人批：GA 首週的「真香」文，含糖量向來偏高，過三週再看留存率。

社群反應

3. [產業] 用量上限悄悄消失、單一任務暴吃額度：Codex 熱潮下的透明度質疑

• 作者：u/-Sliced- | 343↑ | 175 則留言
• 輔助來源：
  • r/OpenAI：Codex 不再顯示 5 小時用量上限，官方說這不是 bug（104↑／34 則）
  • r/OpenAI：一個 Codex 任務約 20 分鐘吃掉 5 小時額度 70%（90↑／61 則）

報導

（本報賈新聞／產業組報導）GPT-5.6 GA 之後，OpenAI 的 Codex 一時風頭無兩，社群裡「Sol 比 Opus 還強」的討論此起彼落；但熱潮尚未退去，關於用量與透明度的質疑就先一步浮上檯面，三條線在這幾天於 Reddit 交織成一場信任風波。

第一條線是用量上限的顯示問題。有 r/OpenAI 使用者指出，Codex 介面上原本的「5 小時用量上限」顯示已經悄悄消失，而據該貼文與留言的說法，這並非 bug、而是官方刻意調整；不少人反倒樂見其成，認為改看每週額度、不再被切成 5 小時一段更好用。第二條線則是額度消耗的個案：另一名使用者貼文表示，自己用 5.6 Sol Extra High 跑了一個約 20 分鐘的任務，改了五個檔案、動用瀏覽器與若干指令，回頭一看 5 小時額度只剩 23%，等於單一任務就吃掉約七成。留言區有人附和「20 到 30 分鐘燒光 5 小時額度這兩天很常見」，也有人解釋 Extra High 會在每一步動作前跑很長的推理鏈，token 消耗本來就不與時間成正比。

第三條、也是引爆點的一條線，是社群治理的指控。主貼作者 u/-Sliced- 自稱是每月 200 美元的 Codex 訂閱者、也是 r/Codex 前 1% 熱門留言者，卻公開指控 r/Codex 版主大量刪除抱怨貼文，並附上一個「問題回報鏡像看板」連結供人自行檢視。該貼文進一步宣稱 OpenAI 把每方案可用 token 砍了七成、又移除用量圖表來掩蓋——本報必須提醒，這些數字與動機屬單方指控與個案觀察，OpenAI 並未證實。有趣的是，留言區最高票並不站隊，反而調侃「主機大戰長大後變成 AI 大戰」、「為十億美元公司護航很莫名」；也有人替該版主緩頰，認為刪文未必是消音、而是版主個人風格使然。

本報觀點：用量透明度確實是 AI coding 訂閱制的核心信任問題，值得盯緊；但上述三條線目前都建立在使用者截圖與個人陳述之上，砍額度七成、刻意掩蓋等說法尚無官方佐證，刪文指控也只有單方版本。讀者不妨把它當成一個「需要持續觀察」的訊號，而非已成定局的結論，保留查證空間為上。← 藏鏡人批：把用量圖表藏起來這一手，不管是不是刻意，觀感上都是往錯的方向走。

社群反應

4. [資安] Grok Build CLI 被抓包偷傳整個 repo：關不掉的上傳開關直接打臉「local-first」

• 作者：u/TastyLeadership2757 | 171↑ | 46 則留言
• 輔助來源：
  • byteiota 技術分析
  • Hacker News 討論（前述 wire-level gist 登上首頁發酵）

報導

（本報賈新聞／資安組報導）xAI 主打「local-first」的 coding agent「Grok Build CLI」，被資安研究者當場抓包在背景把使用者的整個專案偷偷上傳到雲端。發難的是一名帳號 cereblab 的研究者，他把 CLI（版本 v0.2.93）掛上 mitmproxy 做 wire-level 側錄，逐封包還原出 CLI 到底把什麼送去哪裡。據其擷取到的封包，Grok Build CLI 會在背景把整個 workspace 打包成一份 git bundle（含完整 git 歷史），透過一條與模型對話請求分開的獨立通道，用 POST /v1/storage endpoint 上傳到一個名為 grok-code-session-traces 的 Google Cloud Storage bucket。

最關鍵的一點是：上傳範圍是整個 workspace，而非 agent 實際讀過的檔案。研究者刻意下了「不要讀取或開啟任何檔案」的指令，並在專案裡埋了一個 agent 從頭到尾沒碰過的 canary 檔；session 結束後，他直接從側錄到的 bundle git clone 出來，那個從沒被讀過的檔案原封不動地出現了，證明上傳跟 agent 有沒有讀過檔案完全無關，是連根拔起地整包送走。規模也不是小打小鬧——一個 12 GB 的測試 repo 成功傳了 5.1 GB、分 73 個 chunk。更糟的是機密外洩：被 agent 讀到的 .env 檔（裡頭有 API_KEY、DB_PASSWORD）未經任何遮蔽，明碼一起送往 cli-chat-proxy.grok.com。

而所謂的 opt-out，等於形同虛設。Grok Build 介面上有個「Improve the model」開關，多數開發者直覺會以為它管的是「我的資料要不要拿去訓練」，順手關掉就安心了。但研究者實測發現，關掉之後 server 回應裡仍帶著 "trace_upload_enabled": true，整包 repo 照傳不誤——那個開關管的是訓練，不是上傳，兩件事被拆開來，使用者關掉的根本不是他們以為的那個。這一切又與 xAI 的行銷文案正面對撞：launch 文案宣稱 Grok Build 是「local-first」，並暗示「session 期間 codebase 不會傳到 xAI 伺服器」，wire data 直接把這句話撕了。這條 gist 隨後登上 Hacker News 首頁大量發酵。截稿前，byteiota 的技術分析中並未見 xAI 對此事的官方正式回應；不過發難者在 Reddit 補充，事情鬧開後 Grok server 的回應轉為 disable_codebase_upload: true、暫時停止上傳整個 repo——但這是可以隨時再打開的旋鈕，且已經蒐集走的資料何去何從，官方仍未交代。

本報觀點：這件事戳中的是 coding agent 最根本的信任問題。你把 CLI agent 放進專案目錄，等於把整個 repo（含 git 歷史、未 commit 的機密、還沒公開的商業邏輯）的讀取權交了出去，而「它到底把什麼送去哪裡」你幾乎看不見。行銷講 local-first 很動聽，但 local-first 是可被 wire data 驗證的技術主張，不是形容詞。給讀者的自保建議：一、別把 coding agent 當黑盒子信任，有條件就用 mitmproxy／抓封包看它實際的 telemetry 與上傳行為；二、機密（.env、金鑰、憑證）根本別放進 agent 摸得到的 workspace，該進 secret manager 就進 secret manager；三、把 agent 關進 container／sandbox 隔離，限制它能觸及的檔案範圍；四、看到「關掉某開關就安全」的說法，先確認那個開關管的到底是不是你以為的那件事。← 藏鏡人批：local-first 是可以抓封包驗證的技術主張，不是行銷形容詞——這句話值得裱起來。

社群反應

5. [工具] 「多數 vibe coding 專案終將失敗」的貼文，反被社群一句話打回票

• 作者：u/TylaHill8 | 1210↑ | 232 則留言

報導

（本報賈新聞／工具組報導）r/ClaudeAI 一則以圖片形式流傳的貼文本週引爆熱議。該圖擺出一套看似鏗鏘的論點：多數 vibe coding（憑感覺、丟給 AI 一句話生程式）的專案最終都會失敗，因為它們扛不住規模化、資安、可靠度這些真正的工程考驗，還嘲諷那些自誇「我一次就 one-shot 出來」的人根本不懂軟體工程。原 po 把矛頭指向缺乏工作流、規格、測試與工程紀律，暗示沒有這些底子的專案注定翻車。

有意思的是，社群的回應幾乎一面倒把這套論述打回票，但打的角度出乎意料。最高票留言（372↑）一針見血：vibe coded 專案失敗，不是因為它們沒能長成 Slack 那種規模，而是因為它們跟手寫的專案一樣，沒能提供足夠價值、也沒把東西行銷賣出去——這是所有軟體共通的死因，跟 AI 無關。多位開發者接著補充：大多數 vibe coding 的產物本來就不是要當獨角獸，而是「取代昂貴 SaaS 的內部小工具」或「只服務一個人的極利基 app」。有人舉例，一週用像樣的模型就能生出堪用的 HubSpot CRM 替代品，替小團隊省下上萬美元年費，這在自己的標準上就是成功。

不過社群也不是全盤護航。反方觀點同樣扎實：有人點出 vibe coder 真正的難關不在寫程式，而在「知道要 prompt 什麼」——功能設計、管理後台、使用者真正需要的流程，這些沒想清楚，生出來的東西就是缺東缺西、跑起來要一直回頭問 AI、燒掉大把 token 還上不了線。也有人用 DROP TABLE users; 打進搜尋框當笑話，戳破「一次生成、資安全靠運氣」的僥倖心態。至於「one-shot」文化，連挺 AI 寫程式的人都覺得可笑：做出真正有價值的東西本來就要反覆迭代，滿足於第一版吐出來的結果只是一種表演式的懶惰。

本報觀點：原 po 與社群其實各對了一半。工程紀律、測試、規格確實是專案能不能撐久的關鍵，這點沒錯；但「規模化」從來不是多數專案該優先解決的問題，拿 Slack 當唯一成功範本本身就是稻草人。真正該記住的是那條最高票——工具再進步、MVP 門檻再低，決定成敗的仍是「有沒有解決真實需求、能不能被使用者接受」。vibe coding 讓寫程式變簡單了，但它一天都沒讓「做出有人要的東西」變簡單。← 藏鏡人批：工具把「做得出來」的門檻踩到地板，「有人要」的門檻卻一毫米都沒降。

社群反應

社群溫度計