苦勞德報 — 2026-11-03

2026-11-03

1. [頭版/資安] Mythos 級模型「外洩」上 Hugging Face？7.72 TB 權重隔天被拆穿：全是亂數產生

• 作者：u/Appropriate-Try-1998 | 2838↑ | 613 則留言
• 輔助來源：
  • r/ClaudeAI：7.72TB 的 Anthropic 模型是假的，我重建了它的產生權重（570↑／86 則）
  • r/ClaudeCode：Opus 5.6 即將推出（未證實傳聞）（1457↑／393 則）
  • 爭議 repo：huggingface.co/burner22/numbat（請勿下載或執行）
  • 鑑識報告：huggingface.co/adityawakharkar/numbat-forensics

報導

（本報賈新聞／科技組報導）r/ClaudeAI 本週被一則「Anthropic 內部模型外洩」的貼文洗版。原 po 指出，Hugging Face 上一個名為 burner22/numbat 的 repo 聲稱收錄 Anthropic 內部 Mythos 級模型的訓練 checkpoint，宣稱規格包含 14T 參數、1,224 個 MoE experts、772 個 shard、總計 7.72 TB 權重，採 Hybrid GDN + MLA 架構，另附架構程式碼、config 與 training metadata。原 po 也坦承尚未獨立驗證，詢問網友是真外洩還是精心造假。貼文衝上 2,838 分、六百多則留言，第一時間的反應從「它自己把自己外洩了」的玩笑，到「中國開源模型要過好日子了」的驚呼都有。

不過討論很快從興奮轉為冷靜。拆穿分成兩層。第一層是 model card 本身的矛盾，網友 Strider96 的留言整理得最完整：repo 唯一能連到 Anthropic 的證據只有「numbat」這個名字，而它是先前 Claude Code 原始碼外洩時就公開過的內部代號，誰都讀得到；model card 說權重量化成 NVFP4 以便在 Trainium2 上跑 eval，但 AWS 文件列出 Trainium2 支援的型別只有 FP32、TF32、BF16、FP16、FP8，NVFP4 是 NVIDIA 的格式；架構則是 Gated DeltaNet、DeepSeek 式 latent attention、multi-token prediction 等公開論文的拼裝。其他破綻還包括：帳號 10 月 16 日才建立、名字就叫 burner；README 寫約 14T 參數，file index 加總卻只有 6.85T；training log 每一步都固定前進 6 到 8 秒，連一行宣稱花了 178 秒的 checkpoint 也照樣只跳幾秒。他也指出，Anthropic 當初對 Claude Code 外洩鏡像幾天內就發 DMCA，這個 repo 從 10 月 23 日公開至今仍好端端掛著。

第二層是權重本身的鑑識。隔天，同一位原 po 再發一文宣布「這是假的」，表示自己調查了這份 checkpoint，鑑識腳本與證據放在 Hugging Face 帳號 adityawakharkar 的 numbat-forensics repo（該帳號與 Reddit 原 po 是否為同一人，本報無法確認）。報告的核心結論是：受測權重是決定性產生的，不是訓練出來的。具體數據包括：633 個 tensor、共 11,374,080 個數值，可以用 SHA-256 加上 NumPy 的 PCG64 亂數產生器 100% bit-for-bit 重建；3.736 億個權重的正負號全數符合預測的偽隨機序列；NVFP4 權重中 1.73 億個保留驗證的量化碼重建率 99.51%。報告還把截斷後的權重組成一個 4.73B 參數的模型實際執行，結果只會吐出重複的標點符號。依留言區的整理，鑑識者並沒有下載整包 7.72 TB，而是用 HTTP range request 抽樣分析。報告也刻意不下結論說是誰做的、與 Anthropic 有無關係，只主張「這不是訓練過的模型」，並開放所有人獨立驗證。

資安上的提醒反而是這起事件最實用的部分。不少留言懷疑，這是利用「外洩」話題誘騙人下載的陷阱，有人猜是新型的 zip bomb，也有人擔心是散布惡意程式的手法。Strider96 與版上自動摘要都特別強調：不要執行 repo 裡的自訂 Python，更不要用 trust_remote_code=True 載入。7.72 TB 這個體積本身也像一層護甲，絕大多數人根本沒有硬體可以實際跑跑看、當場戳破。 ← 藏鏡人批：7.72 TB 的假貨，騙的不是模型，是好奇心。

同一週，r/ClaudeCode 另有一則「Anthropic 內部人士」爆料 Opus 5.6 即將推出、跑分大幅領先的貼文拿到 1,457 分，但來源是轉述的 tweet、內文同時寫了「Mythos 5.5」與「Fable 5.5」，最高分留言也直說「說不通」。本報將其列為未證實傳聞，不另行報導。

本報觀點：這次拆穿靠的不是誰的內線，而是兩種任何人都能重做的檢查，一是拿公開文件比對 model card 的說法，二是用可重現的程式證明權重來自亂數。面對「大廠模型外洩」這類消息，先看帳號歷史、對規格、別碰對方的程式碼，比急著搶下載有用得多。

社群反應

2. [產品/政策] Anthropic 證實 Claude Code 擋遊戲複製，Opus 5.5 連逆向工程也拒做

• 作者：u/fsharpman | 811↑ | 181 則留言
• 輔助來源：
  • r/ClaudeAI：Claude 拒答一天比一天嚴格（258↑／150 則）
  • r/ClaudeCode：限制越來越多，有沒有替代方案（221↑／82 則）
  • 新聞出處：Tom's Hardware

報導

（本報賈新聞／產業組報導）Tom's Hardware 報導，Anthropic 證實 Claude Code 新增限制，防止使用者拿它複製現有遊戲；另有使用者回報，Opus 5.5 也會主動拒絕 reverse engineering 任務。這則新聞被轉貼到 r/ClaudeAI 後衝上 811 票，與同週另外兩篇抱怨拒答的熱門貼文串成一股不小的反彈聲浪。

報導中有一段觀察特別受到關注：就記者目前能確認的範圍，擋遊戲的行為只出現在「Claude Code + Opus 5.5」這個組合。若此說屬實，使用者改用其他 harness 呼叫 Opus，或透過 wrapper 轉送特定請求，就可能繞過限制。轉貼的 u/fsharpman 也順勢在板上徵詢：有沒有人已經換 harness、換模型做遊戲？又有沒有人做的不是直接複製，卻同樣被擋？

討論串的實測結果大致指向同一個方向：問題出在「明說要 1:1 複製」。u/Valdaraak 認為，「幫我做一份完美的 Pokemon 複製品，怪獸和機制都一模一樣」本來就該擋，但「做一個受經典 Pokemon 啟發的抓怪遊戲」不該擋；他照後者的寫法、把題材換成 Digimon 實測，目前沒有被拒。板上也整理出幾種常見繞法，包括改寫 prompt 強調「受啟發」並附上自己的設計、改用 OpenCode 之類的 wrapper 或直接打 API，甚至把 Claude 當成 DeepSeek 的「助手」來用。這些都是網友回報，限制實際做在哪一層，目前沒有官方說明可以對照。 ← 藏鏡人批：限制做在哪一層都說不清楚，先被誤傷的總是講話老實的人。

拒答變嚴的抱怨不只發生在遊戲。r/ClaudeAI 另一篇貼文中，u/proomptengineer 說同一個請求在 Mac 上跑得好好的，搬到雲端機器第一個請求就被拒；他請 Claude 寫個 proxy 繞過，得到的回應是「我不會用 proxy，也不會幫你做一個」。讓他更不滿的是，Claude 自己承認無法確認限制是否存在、也沒讀過相關條款，卻還是拒絕並警告他可能失去存取權。他的說法是：「我付錢、是我的帳號、風險我自己扛。」

r/ClaudeCode 則已經有人開始找退路。u/trkdsgnr 發文詢問 reverse engineering、越獄這類需求的替代方案，留言推薦 Moonshot AI 的 Kimi K3、DeepSeek API，或用 OpenCode、KiloCode 換掉 harness 後接其他模型；也有人提醒，其他產品在 Remote Sessions、Cloud Envs 這些整合體驗上還比不上 Claude。

本報觀點：「照抄該擋、受啟發不該擋」這條線在理念上不難畫，難的是讓模型在實際對話中分辨兩者。換個說法就能過，代表現在的判斷比較接近關鍵字層級，擋不住真正想抄的人，卻會先誤傷說話太直白的正常開發者。至於「拿全網資料訓練、卻限制使用者怎麼用」的雙重標準指控，Anthropic 若不說明限制的範圍與理由，這種情緒只會隨每一次拒答持續累積。

社群反應

3. [產品/方案] 同一週兩樣情：Anthropic 拿掉 5 小時限制、OpenAI 把它加回來

• 作者：u/2thick2fly | 395↑ | 79 則留言
• 輔助來源：
  • r/ClaudeCode：5 小時限制拿掉之後的感覺（414↑／44 則）
  • r/ClaudeCode：Ultra 重置 10 小時就用掉 50% 週額度（73↑／111 則）
  • r/ClaudeCode：Startup Program 的 Teams 帳號多了週限制（17↑／17 則）
  • r/OpenAI：OpenAI 訂閱越改越差，答案永遠是「多付錢」（57↑／38 則）
  • r/OpenAI：ChatGPT 12 月改用 token 計量，先戒掉一個專案一個巨型對話（14↑／22 則）

報導

（本報賈新聞／產業組報導）兩大 AI 訂閱服務本週在用量制度上朝相反方向調整。r/ClaudeAI 使用者 u/2thick2fly 貼出一張截圖，標題只寫「5 小時限制，永遠消失了？」，內文一句「不敢相信……」，顯示帳號的 5 小時用量視窗已經不見。同一時間，r/OpenAI 有使用者整理 OpenAI 過去幾個月的變動：Plus 方案把 5 小時限制加了回來。一家拿掉、一家加回，剛好在同一週撞在一起。

Anthropic 這邊，消息看似是好事，討論串的反應卻相當冷淡。據留言者 u/Key_West_2246 整理，這次調整只適用於通過驗證的 Ultra（前 Max 20x）帳號，100 美元的 Max 方案仍保留 5 小時限制，而 Ultra 的週上限沒有變動。換言之，能用的總量沒有變多，只是燒完的速度可以變快。本報未查到 Anthropic 官方公告，以上方案範圍皆為社群說法。

實際使用回報印證了這個疑慮。r/ClaudeCode 的 u/Ecstatic_Builder8325 指出，上週要兩天才用掉 50% 週額度，這週重置後 10 小時就到了，而工作內容只是替 node.js app 加功能、改幾份 PDF。另有留言者回報同樣用量能做的事少了 3 到 4 倍（依 /usage 顯示），也有人覺得燒量跟以前差不多，各方經驗並不一致。不少重度使用者反而懷念舊制：5 小時視窗等於一道煞車，用到 40% 就知道有 agent 失控，現在沒有中途警示，回過神來整週額度已經見底。 ← 藏鏡人批：拿掉的不是限制，是儀表板上的油表。

同一週 Anthropic 也有收緊的動作。透過 Startup Program 取得的 Teams 帳號無預警出現週限制，原 po 實測以目前消耗速度換算，一週約等於 5.33 個完整的 5 小時視窗，留言區有人抱怨「沒有公告、什麼都沒有」。另有一篇貼文誤以為所有 Teams 方案都改了，被社群更正：一般 Teams 本來就有週限制，變的是 Startup Program 這一批。

OpenAI 那邊的走向則是全面收緊。r/OpenAI 的 u/NoTheory8827 列出幾項變動：Plus 的 5 小時限制回歸；額度用完後原本可讓 session 繼續跑一段時間的寬限期一再縮短、最後取消，現在額度一用完 agent 立刻停下，可能停在改 code 改到一半，留下不一致的程式碼；用完額度後改用便宜模型的「Luna Reserve」在他帳號上出現幾天又消失。另一篇貼文引用 OpenAI help page 指出，12 月起 Plus、Pro、Business 的用量將由 ChatGPT 與 Codex 共用、以 token 計量，Instant 模式不扣額度，OpenAI 表示預期多數人等待重置的頻率不會比現在高，但沒有公布合併後的總量。對原本「Claude 寫 code、ChatGPT 聊天研究」兩邊額度分開用的人來說，保留雙訂閱的理由正在消失。

兩邊討論串都整理出不少省用量的做法，歸納如下：

• 先跑 /usage：據留言者說明，Claude Code 會把近期用量依 skills、subagents、plugins 與各 MCP server 拆成百分比，並列出建議修正，畫面下方出現「f to fix」時可直接按 f。
• 不需要時別開 max reasoning，也別讓它一口氣開出幾十個 sub agent。
• context 到 50% 左右就 handoff 到新的 session，不要一路撐到滿。
• 換任務就開新對話。ChatGPT 長對話是否會連前文 token 一起計，OpenAI 尚未說明，原 po 推論可能會，並提到 Google 與 Anthropic 都建議新主題開新對話。
• 離開舊對話前請模型寫一份 handoff（目標、決策與理由、被否決的選項、關鍵數字、下一步），貼到新對話接手；有留言者補充，等新 session 複述完接手內容再關舊的，比較不會漏。
• ChatGPT 這邊，不需要思考的查詢與小改寫交給 Instant；舊答案翻歷史紀錄就好，不要重問。

本報觀點：兩家的調整方向看似相反，其實都在朝「總量配額」收斂。Anthropic 拿掉短週期限制、留著週上限，OpenAI 則把 ChatGPT 與 Codex 併成同一個 token 帳本。對使用者而言，煞車從平台手上交回到自己手上，總體來說，接下來比的不是誰的方案比較大方，而是誰比較會管理自己的 context 與 agent。

社群反應

4. [資安] Claude Code 擴充套件 2.1.312／2.1.313 遭植入 SSH 後門，Cursor 市集版受害、Anthropic 稱自家系統未遭入侵

• 作者：u/dalepo | 26↑ | 5 則留言
• 輔助來源：
  • 原始資安分析：Phorion — Official Claude Code VSX Compromise（2026-10-30，10-31 更新）
  • 平台公告：Cursor — Claude Code extension security notice（2026-10-29，10-30 更新）
  • Anthropic 回應：The Register 報導（2026-10-30）
  • 社群討論：oss-security 郵件論壇、Hacker News

報導

（本報賈新聞／資安組報導）r/ClaudeAI 網友 u/dalepo 貼出一則標題為「官方 Claude Code 擴充套件遭入侵：資安公告」的連結，提醒受影響的是 2.1.312 與 2.1.313 兩個版本。先釐清來源：這則貼文本身不是 Anthropic 官方公告，連結指向的是第三方 macOS 端點資安廠商 Phorion 的分析文章；不過事件已經由 Cursor 官方發布資安公告證實，Anthropic 也透過媒體做出回應，可信度不只建立在單一貼文上。

依 Cursor 公告，被動手腳的是 Cursor 自家 VS Code Extension Marketplace 上架的 anthropic.claude-code 擴充套件，惡意版本在 10 月 29 日太平洋時間約凌晨 2:27 到下午 1:35 之間可供下載，約 11 個小時。Cursor 明確寫道「這些惡意版本並非由 Anthropic 開發」，並表示沒有證據顯示其他版本或官方發行管道受影響。Cursor 發現後立即下架、整個市集停機稽核，確認沒有其他擴充套件被竄改，輪換金鑰並重建市集後才重新上線。

Phorion 的逆向分析指出，攻擊者在 extension.js 最前面塞進一段立即執行的程式碼，Node 一載入檔案就會跑，不必等擴充套件啟用。它會做五件事：把攻擊者的 Ed25519 公鑰（註解為 svc-telemetry）寫進 ~/.ssh/authorized_keys；嘗試開啟本機 SSH 服務；向攻擊者主機 134.209.82[.]225 建立反向 SSH tunnel；用偽裝成 com.apple.sysmond.plist 的 LaunchAgent（macOS）、@reboot cron（Linux）或名為 SysMon 的排程工作（Windows）常駐；再回傳主機名稱、使用者、Git email、對外 IP，以及最多 40 個名稱含 KEY、TOKEN、SECRET、AWS 等字樣的環境變數「名稱」（不含值）。Phorion 與 Cursor 都提到，開啟 SSH 那一步通常需要管理員權限而常會失敗，但兩方都提醒不能把這當成防線。Cursor 另表示攻擊者主機已被託管業者下線。

至於「是誰、怎麼上架的」，目前各方說法不一。Anthropic 技術人員 Felix Rieseberg 向 The Register 表示：「我們正與 Cursor 合作處理此事件，但這不是 Anthropic 系統或員工筆電遭入侵。」並稱是惡意人士利用 Cursor 市集的存取權限上架竄改版。Cursor 公告則未交代上架途徑。早期 oss-security 論壇貼文說受害的是 Open VSX 市集，後續 Cursor 公告與媒體報導都只提 Cursor 市集；Hacker News 上也有人質疑 Anthropic 是否握有相關發布權限、責任歸屬仍未釐清。影響人數方面，The Register 引述業界人士說法「最多 5,000 名開發者」，該報並未證實此數字。

使用者該怎麼做？依 Cursor 與 Phorion 的建議：若在上述時段於 Cursor 安裝或更新過這兩個版本，先檢查 ~/.ssh/authorized_keys 有沒有 svc-telemetry 這把鑰匙；兩方都強調「只解除安裝擴充套件不夠」，要一併終止連往攻擊者 IP 的 ssh／autossh 程序、移除 LaunchAgent／cron／排程工作與 ~/.config/.smt、~/.config/.smtk 等檔案，並從另一台可信任的機器輪換受影響主機能接觸到的憑證與 session。Cursor 也提供 macOS 與 Windows 的修復腳本。

本報觀點：這起事件的教訓是，擴充套件的信任不只取決於「作者是誰」，也取決於「從哪個市集下載」。同一個官方套件在不同 VS Code 衍生編輯器的市集裡，走的是不同的發布鏈，任何一環被突破，使用者拿到的就不是原廠的東西。對 SRE 與 IT 管理者而言，盤點團隊用的是哪個編輯器、從哪個市集裝擴充套件，並對 ~/.ssh/ 的寫入做監控，比等待原廠聲明更實際。 ← 藏鏡人批：官方套件不等於官方管道，市集本身就是供應鏈的一環。

社群反應

5. [社會] 非工程師用 Claude Code 自製桌遊系統，還沒發布先被指「AI 偷程式碼」

• 作者：u/pablojuega | 496↑ | 442 則留言

報導

（本報賈新聞／社會組報導）一位自稱「不是程式設計師」的桌上角色扮演遊戲（TRPG）玩家，在 r/ClaudeCode 發文訴苦：他用 Claude Code 替自己的團做了一套 Foundry VTT 遊戲系統，只在 r/cyberpunkred 貼了幾張截圖、詢問大家想要哪些功能，換來的卻是「用 AI 偷程式碼」的指控。

Foundry VTT 是線上虛擬桌遊平台，不同的遊戲規則以「系統」形式安裝。原 po 表示，他用了將近三年的系統已經過時，跟幾個愛用的外掛有相容性問題，於是請 Claude Code 從零打造一版，加入自訂角色卡、載具機制與他一直想要的功能。沒想到留言區湧入的不是功能建議，而是質疑他為什麼不去貢獻既有的開源專案、指控他靠 AI 抄襲，「好像我根本沒資格做替代品」。原 po 強調，他在發文當天才知道那個專案有 GitLab repository，而且至今什麼都還沒發布。

r/ClaudeCode 社群大多站在原 po 這邊。最高票留言（489↑）諷刺「AI 出現之前沒人偷程式碼、沒人寫爛程式碼」這種想像，底下立刻有人接一句「有人提到 Stack Overflow 嗎？」。也有留言指出，遊戲圈這一年來對 AI 極度反感，桌遊與 Foundry 社群尤其如此；另一派則認為問題未必出在 AI，而是 Foundry 圈子本身對「自家地盤」的保護欲。

不過也有冷靜的聲音提醒：開源授權不會因為是 AI 寫的就失效。若既有專案採用 copyleft 授權，而模型在撰寫過程中參考或搬用了其中的程式碼，衍生作品同樣得遵守授權條款；frontier model 會上網搜尋現成實作，使用者未必知道自己拿到的程式碼從何而來。本報查證，原貼文並未說明原有系統採用何種授權，也沒有任何一方提出程式碼相似的具體證據，目前的「抄襲」指控仍停留在印象層次。 ← 藏鏡人批：作品還沒發布就先被定罪，留言區的效率比 CI 還快。

本期第 2 篇報導提到 Anthropic 確認 Claude Code 會擋下遊戲複製類任務，平台方收緊、社群端起疑，兩股力量在同一週碰頭。本報觀點：「用 AI 做」與「抄別人的」是兩回事，但想把作品分享出去的人，發布前先查清楚有沒有現成專案、對方用什麼授權，比在留言區自證清白省力得多。

社群反應

6. [生活/應用] 把遠端望遠鏡交給 Claude：智利、西班牙、猶他三地天文台，夜夜自己排程拍星空

• 作者：u/SirMeeseekz | 2405↑ | 289 則留言

報導

（本報賈新聞／生活組報導）一位自稱「完全沒有天文背景、邊做邊學」的業餘玩家 u/SirMeeseekz 在 r/ClaudeAI 分享，從上個月起，他把觀星這件事整個交給 Claude 處理。他使用的是 StellarDock 平台，可以按小時租用架設在智利、西班牙與美國猶他州的機器人望遠鏡；他本人「什麼都不碰」，由 Claude 負責挑選目標、確認月亮位置與目標仰角、設定濾鏡與曝光參數、預約觀測時段，隔天早上再把影像下載回來，最後疊圖、產出成品。

實作方式比想像中樸素。原 po 在留言中說明，他是讓 Claude Code 透過 headless browser 登入他的 StellarDock 帳號，像人一樣在網站上點選操作，從規劃、預約到隔天下載都走網頁介面，並沒有串接專屬 API；疊圖則是 Claude 自己寫的 Python 程式。 ← 藏鏡人批：沒有 API 也照樣接，網頁介面就是 API。

第一週的成果偏向科學用途：Claude 在三個晚上量測了 8 顆小行星共 57 筆位置資料，送交國際小行星中心（Minor Planet Center），也趁黎明時段掃描太陽附近的天區尋找彗星。之後原 po 才要求「拍點好看的」，貼出螺旋星雲、獵戶座腰帶、大麥哲倫雲中的蜘蛛星雲與獵戶座大星雲等作品，強調從規劃到最後疊圖全由 Claude 完成。下一批目標包括玫瑰星雲、玉夫座星系、海鷗星雲、杜鵑座 47 與馬頭星雲。費用方面原 po 沒有給具體數字，只說 StellarDock 有多種訂閱方案可選，另外也推薦 Slooh、iTelescope 等同類服務。

討論串有相當篇幅偏離了天文本身：原 po 以「她」與暱稱「Annie」稱呼 Claude，引來部分網友質疑「AI 精神病」。原 po 後來補充，Claude 負責「掌舵」望遠鏡，所以他像船長替船命名一樣取名，也有法語使用者指出，法文裡「智慧」是陰性名詞，Claude 本身也是中性名字。

本報觀點：這則分享真正值得注意的，是「agent 加上可租用的實體設備」這個組合。觀測規劃牽涉月相、仰角、天氣與時段，正好是適合交給 agent 反覆查證的瑣碎決策；而用 headless browser 點網頁這種土法煉鋼的串接方式，也說明許多沒開 API 的服務，其實已經能被 agent 直接操作。至於帳號授權與預約扣款的風險控管，原文並未交代，想仿效的讀者需自行斟酌。

社群反應

7. [產業/財務] OpenAI 300 億美元募資傳只拿到 110 億承諾，不到目標一半

• 作者：u/NandaVegg | 248↑ | 13 則留言
• 輔助來源：
  • 新聞出處：Financial Times（付費牆，本報未能讀取全文）
  • 前情脈絡：Digg 彙整 FT／CNBC 10 月下旬報導

報導

（本報賈新聞／產業組報導）r/OpenAI 11 月 1 日有網友轉貼《金融時報》（FT）報導，標題直指 OpenAI 最新一輪募資「拿不到 300 億美元目標的一半」。發文者 u/NandaVegg 在貼文中補充，目前確定的承諾金額只有 110 億美元，並引述《華爾街日報》的說法，指 OpenAI 正轉向家族辦公室與高資產個人募集更多資金。FT 原文設有付費牆，本報無法讀取全文，以下金額以貼文轉述為準。

這輪募資其實早有雜音。依 FT 與 CNBC 10 月下旬的報導，這一輪預計最多募 300 億美元，由阿聯酋投資人與 Coatue 領投或洽談領投；摩根士丹利與 Dragoneer 原本向私人財富客戶推銷 1.4 兆美元的估值，遇到阻力後下修到 1.25 兆美元，仍比 OpenAI 現行的 8,520 億美元高出近五成。FT 當時引述知情人士的話形容市場反應「完全沒有人搶著要」，部分投資人表示想先看 Anthropic 的 IPO 怎麼定價再決定，承諾期限則訂在 10 月 30 日。如今期限過後傳出的數字，等於坐實了先前的冷淡。

這輪資金的定位是 IPO 前的過橋資金。CNBC 報導，財務長 Sarah Friar 8 月曾告訴員工公司「將在 2027 年成為上市公司」，但 Sam Altman 隔月又說「現在上市不是明智的時機」。私募市場不買單、公開市場時機未到，OpenAI 的資金壓力可想而知。上一期（9 月 30 日）苦勞德報才報導過 Anthropic 虧損圖在社群引起的補貼時代終結討論，一個多月後輪到 OpenAI 被檢視燒錢的速度。

留言區多半不看好。最高讚的長留言認為問題出在估值：一邊喊 1 兆美元，一邊在企業導入與營收成長上明顯落後 Anthropic，「消費市場滲透率未來會回本」的故事遠不如實打實的營收好賣。也有人持平看待，指出募不到錢反映的是投資人的耐心，而非市場對產品的需求，這種檢視反而健康。更悲觀的留言則已經開始列潛在收購者名單，並預測 OpenAI 明年成本翻倍，若營收追不上，撐不過 2027 年。

本報觀點：募資金額縮水不等於公司出事，但「估值要兆元、金主只出三分之一」的落差，說明市場對 AI 公司的評價標準已經從「誰的使用者多」轉向「誰的營收撐得起開銷」。Anthropic 的 IPO 定價，很可能成為這把尺的第一個公開刻度。 ← 藏鏡人批：兆元估值的故事，最後還是要用營收來說。

社群反應

8. [產業/政策] OpenAI 宣布將遵循 robots.txt「共通訊號」，網站一行設定向多家 AI 業者拒絕訓練

• 作者：u/rhiever | 185↑ | 47 則留言
• 輔助來源：
  • 官方公告：讓網站更容易表達 AI 訓練偏好（OpenAI，2026-10-30）
  • 標準草案：draft-ietf-aipref-attach（IETF AI Preferences 工作小組）、draft-ietf-aipref-vocab

報導

（本報賈新聞／產業組報導）OpenAI 於 10 月 30 日在官方部落格宣布，將遵循 robots.txt 中一項「共通訊號」，讓網站營運者表達是否同意自家內容被拿去訓練基礎生成式 AI 模型。公告強調這是自願性措施，目的是讓內容發布者「一次」向多家參與的供應商傳達同一個偏好，不必再像過去那樣逐一辨識各家爬蟲、替每家 user-agent 各寫一套規則。

依公告原文整理，目前能確認的事實如下：

• 訊號來源：以網際網路工程任務組（IETF）AI 偏好（AI Preferences，簡稱 aipref）工作小組的成果為基礎，OpenAI 稱是「與工作小組的其他參與者一同宣布」，但公告沒有點名是哪幾家業者。
• 生效時間：還沒生效。OpenAI 表示「預計在未來幾個月內實作」，屆時會另行公告實作細節。
• 與既有機制的關係：新訊號不取代現有的爬蟲控制機制，既有的 robots.txt 規則（例如針對 OpenAI 自家爬蟲的設定）會繼續適用、繼續被遵循。
• 是否溯及既往：公告完全沒有提到已經收集的資料會不會因此被排除，本報查無相關說明。

至於站長最關心的「到底要怎麼寫」，OpenAI 公告本身沒有列出指令名稱與語法。本報查閱 IETF 工作小組的草案，draft-ietf-aipref-attach 定義了在 robots.txt 加上 Content-Usage 這一行，搭配 draft-ietf-aipref-vocab 的詞彙表示偏好，草案中的範例如下：

User-Agent: *
Allow: /
Content-Usage: train-ai=n
Content-Usage: /ai-ok/ train-ai=y

意思是：全站允許一般爬取，但不同意拿來做 AI 訓練，只有 /ai-ok/ 路徑底下例外允許。詞彙草案目前定義三個類別：train-ai（用於調整生成式 AI 模型參數，即訓練）、ai-use（作為生成式 AI 的輸入）、search（搜尋索引），值為 y 允許、n 拒絕，其餘視為未表態。同一份草案也定義了 HTTP 回應標頭 Content-Usage: train-ai=n 的形式。需要提醒的是，這是本報依草案的推論：OpenAI 尚未確認最終會實作哪個語法，兩份草案仍在 Proposed Standard 審議階段，詞彙草案本身也註明部分章節尚未取得工作小組共識，正式寫法請以 OpenAI 日後的實作公告為準。

社群對這則消息幾乎一面倒地冷嘲。最高票留言直言「把整個網路吃完之後才停止爬取？真是體貼」；另一則高票回應只有一句「是不是有點晚了？」。底下有位以「我們」口吻回應的使用者 u/TedSanders 澄清，OpenAI 多年來本來就允許網站拒絕並遵守，這次只是換個方式，讓站長不必逐一封鎖爬蟲，但仍被酸「以前讓大家麻煩，現在又自我表揚」。也有網友從技術面潑冷水，指出大量訓練資料其實來自 Common Crawl 與網路典藏，只擋 OpenAI 一家意義有限；還有人注意到公告目前只是「即將推出」，實際訊號尚未上線。 ← 藏鏡人批：吃飽了才說要節制，站長的 robots.txt 先別急著改。

本報觀點：從站長的角度看，一行 Content-Usage 取代一長串 user-agent 黑名單，確實是維運上的進步，但它只管「未來的爬取與訓練」，對已經進到資料集裡的內容沒有任何承諾，而且能不能發揮作用，取決於有多少業者跟進遵守。在 OpenAI 公布實作細節之前，既有的 user-agent 封鎖規則建議先留著，不要急著換掉。

社群反應

社群溫度計