苦勞德報 — 2026-08-04

2026-08-04

1. [頭版/科學] OpenAI 未發布模型「Astra」宣稱解出十大數學與理論電腦科學難題，並以 Lean 形式驗證佐證

• 作者：u/etherd0t｜370↑｜245 則留言
• 輔助來源：
  • 官方公告：OpenAI — Ten advances in mathematics and theoretical computer science
  • r/OpenAI 1vch4jr（703↑／88 則）
  • r/OpenAI 1vdrwt1（385↑／126 則）

報導

（本報賈新聞／科學組報導）OpenAI 昨日公布一份長達 249 頁的研究文件，宣稱旗下一個尚未對外發布、內部代號「Astra」的下世代模型，已針對高維幾何、群論、量子複雜度理論、編碼理論與格子密碼學等十個數學與理論電腦科學領域的公開難題，提出新證明或更強的數學界限。官方說法強調，這些問題有些已「原地踏步」超過十年、甚至更久，過去長期缺乏實質進展。

值得注意的是，OpenAI 這次不是單純宣稱模型「考試分數變高」，而是描述了一套完整的研究流程：模型自行探索開放問題、生成新論證或更強的數學結論，接著協助整理成正式論文格式，最後把每一項結果轉譯成 Lean 形式化證明（formal proof），讓邏輯正確性能被機器逐步檢查，而非全憑人工信任背書。這種「機器可驗證」的設計，是本次討論中最常被拿出來稱讚的技術亮點，不少網友認為 Lean 生態系統可能因此迎來一波新的基礎建設需求。

不過，熱度背後質疑聲浪同樣不小。首先是「自證其說」的疑慮：這些數學難題本身正因為懸而未決，外界根本沒有既有答案可供比對，於是「AI 給出的證明是否真的正確」只能仰賴數學社群事後逐項審查，而非立即可驗證。其次，也有人質疑 OpenAI 選在模型尚未正式發布前就搶先公布研究成果，形同「用解題能力來為即將上市的產品做行銷鋪陳」，這種「先講故事、後出貨」的操作在 AI 圈已非首次，卻仍引發部分使用者的警覺。← 藏鏡人批：產品都還沒上市就先搬出十道世紀難題壯膽，這劇本比證明本身還眼熟。此外，也有聲音提醒，數學與演算法是一個高度形式化、規則清晰的「乾淨」領域，AI 在此表現亮眼不代表能直接類推到充滿雜訊與不確定性的現實世界問題。

社群反應

本報觀點

Lean 形式化驗證確實是這次公告最實在的部分——至少邏輯正確性可以機器檢查，而非光憑一份公關稿自說自話。但「機器可驗證」跟「數學界公認具有原創性與重要性」是兩回事，後者仍需要專業社群逐篇審閱、確認假設是否合理、結論是否真的填補了空白，這個過程不會比模型跑出結果快。在正式論文接受同行檢視之前，本報建議讀者把這次公告當成「值得追蹤的訊號」，而非「AI 已經全面超越數學家」的定論。

2. [資安/工具] 花錢訂閱又被扣款？Claude Code 環境變數陷阱讓 Max 用戶悶虧

• 作者：u/gzoomedia｜679↑｜80 則留言

報導

（本報賈新聞／工具組報導）一名 Reddit 使用者在 r/ClaudeAI 貼文示警，付了每月 200 美元的 Claude Max 訂閱，理當享有固定額度可用，結果 Claude Code 卻悄悄改走 API 計費，等於訂閱與 API 兩頭燒錢。問題根源是系統環境變數裡設了 ANTHROPIC_API_KEY——只要這個變數存在，Claude Code 就會優先讀取它、以 API key 身分計費，完全跳過訂閱帳號的登入額度，而且過程中沒有任何提示視窗或警告訊息。原 po 直到收到自己預先設定的花費警示（花費逼近 20 美元）才驚覺不對勁，回頭檢查才發現罪魁禍首是那行環境變數。貼文一出立刻引來大量迴響，不少人留言表示自己也曾中招，只是金額或大或小、發現的時間點不同。多數留言的共識是：這不完全是 bug，而是 Claude Code 的既定行為——只要偵測到 API key 就會用它，但問題在於「切換計費模式」這件事對使用者完全不透明，沒有二次確認、沒有警示，等到帳單出來才知道已經被扣款。← 藏鏡人批：訂閱費照收、又悄悄改走按量計費，這不是灰色地帶，是設計上該補的洞。

社群反應

本報觀點

訂閱制與 API 計費本來就該壁壘分明，使用者付了 Max 月費，理應預期額度用完就是用完、頂多被擋下來，而不是背後默默改道走按量計費、荷包在不知不覺中被掏空。環境變數的優先順序設計或許有其技術上的理由，但既然牽涉到真金白銀，切換計費模式這種關鍵行為理當有明確提示或至少一次性警告，而不是靠使用者自己設花費上限來當最後一道防線。在真正修正之前，開發者能做的自保方法很簡單——測試用的 API key 就該是拋棄式、上限抓低一點，別跟正式或高額度用途共用同一把鑰匙。

3. [產品/人物] Anthropic 駭客松奪社會影響力獎！開發者靠觸覺阻力逼你「三思而後滑」

• 作者：u/Manfredev｜1065↑｜111 則留言

報導

（本報賈新聞／人物組報導）一場開放給任何人參加、不需邀請函的 Anthropic 駭客松，捧出了一款專治滑手機成癮的新工具。開發者 Manfredev 在 r/ClaudeCode 貼出得獎喜訊：他打造的 app「Fluid Friction」拿下本屆「Societal Impact Prize」（社會影響力獎），iOS 與 Android 版本已雙雙上架，完全免費。

Fluid Friction 的核心設計很直白：把每一次滑動都變成一個「選擇」。使用者往下滑時要先拖過一段觸覺阻力波，才能真正觸發捲動，藉此在下意識滑手機的瞬間硬生生插入一個停頓，逼使用者多花一點力氣、多一秒思考，卻不會真的封鎖任何社群 app 的使用。Manfredev 透露這款作品其實是「在暗處默默做了 7 個月」才端上檯面，開發工具則是用 Claude Code——他在留言區被問到工作流時輕描淡寫回應：「我的 Claude 設定沒什麼花俏的，就是在一個叫 Architect 的自訂終端機裡跑 Claude Code，僅此而已。」被追問駭客松怎麼報名，他也澄清活動對外開放，靠朋友在 Instagram 限動分享才得知消息，並非 Anthropic 員工才有的內部門票。← 藏鏡人批：不靠內部門票、也不靠花俏配置，靠的是把痛點想清楚——這句話對所有做展示型 side project 的人都是提醒。

貼文發布後湧入大量祝賀留言，也有使用者實測回報 bug（例如 Instagram 留言區手勢衝突、Android 通知氣泡被蓋住），Manfredev 幾乎逐一在留言串回覆並隨即推出修正版本，展現出獨立開發者少見的即時互動節奏。

社群反應

本報觀點

「7 個月暗處開發＋一場開放報名的駭客松」，是本篇最值得記一筆的組合——得獎不靠內部門票，靠的是把一個自己真的會用的產品做到底。更值得玩味的是，作者自曝開發工具「沒什麼花俏」，就是 Claude Code 加一個自訂終端機，卻能在賽場上打贏眾多對手，也難怪留言區有人酸溜溜地說「你的 prompt 顯然比其他參賽者強太多」。技術門檻降低之後，真正拉開差距的，恐怕還是「有沒有把使用者真正的痛點想清楚」這件事。

4. [產業] 「Opus 5 根本沒法用」——用戶實測一週半，直呼退步基準測試量不出來

• 作者：u/Deep-Palpitation8315｜482↑｜345 則留言

報導

（本報賈新聞／產業組報導）r/ClaudeCode 版上一篇標題直白的貼文「Opus 5 is a practically unusable model」，短時間內衝上 482 個讚、逼近 350 則留言，戰況不輸前幾天「Fable 5 加碼到期」那波降智疑雲——差別在於，這次矛頭不是用量額度，而是模型本身的執行品質。

原 po 帳號 Deep-Palpitation8315 表示，自己用 Opus 5 大約一週半，發現犯錯量「多到嚇人」。問題不是零星小錯，而是在交付完整計畫、讓模型自主執行一連串任務時才真正現形——這正是他過去用 Opus 4.6 到 4.8 都能穩定完成的工作。他直言「4.6 到 4.8 明顯更好」，Opus 5 常常忘記上下文裡的指令與內容，一犯錯就繼續錯下去，除非自己發現或被使用者點出來，「我已經數不清糾正它幾次了」。更讓他在意的是，這些狀況在 context window 還不大（十萬到十五萬 token 左右）時就已經出現，反觀 Opus 4.8 一路撐到 35 萬 token 才開始失常。文末他補了一句無奈的結論：目前唯一堪用的只剩 Fable 5，但他的週用量早就刷完了。

留言區迅速分成兩派。附和陣營裡，高讚留言 KrayeBaby（270↑）形容 Opus 5「解決一個問題、順手留下另一個」，感覺像是刻意留缺口好讓對話無限延續下去；Ambitious_Injury_783（80↑）說自己原本保留判斷，但親身用過後只能承認「它會很有自信地講錯」；也有人（johnnydotexe，48↑）陰謀論式解讀，認為這是 Anthropic 逼 Pro 用戶升 Max 或加購額度的手段，並觀察到不少人已經改跳去用 Codex 或退回 4.6／4.8。但反對聲音同樣不小：Key_Instruction3373（32↑）只丟一句「我這邊完全沒問題」；lurkingtonbear 則說用 Fable 帶 Opus／Sonnet／Haiku 的組合跑得很順；The-Fictionist 態度較細緻，認為稱不上「完全不能用」，甚至遇過 Opus 表現贏過 Sonnet 的情況，但也承認「還有一件事沒做完」這種強迫症式停不下來的毛病確實存在。

社群反應

本報觀點

← 藏鏡人批：正反雙方吵的根本不是同一件事——一個講「日常任務跑得動」，一個講「長計畫累積性失誤」，吵到最後只是各自對著空氣喊話。從額度到品質，這波降智疑雲換了個角度但陣營沒變——一邊咬定親身體感的退步，一邊拿基準測試與個人經驗反駁。有意思的是，正反雙方吵的其實不是同一件事：反對者多半講的是「一般任務跑得動」，附和者講的卻是「長計畫執行時的累積性失誤」，兩種情境本來就難用同一把尺量。基準測試抓不到的東西，往往正是這種需要長時間、多步驟才會顯現的疲乏症狀，這大概才是這串留言真正戳中的痛點。

5. [展示/科技] GTA 6 初次嘗試：遠稱不上完美，但看得出「對的 harness + agentic loop」能做到什麼程度

• 作者：u/smith2008 | 1082↑ | 355 則留言

報導

（本報賈新聞／科技組報導）原 po 先前用 Matt Shumer 的 Gauntlet Loop（一個由單一 prompt 啟動、持續自我迭代的 agentic loop 方法論）做過一個 Worms Armageddon 瀏覽器版 demo，玩過就收手，因為原版早有更成熟的移植可玩。這次他把野心拉高，直接挑戰用同一套方法論做出 GTA 6 的雛形。

第一次嘗試以失敗收場，agent 卡在只生出一個陽春的 3D 世界就走不下去。原 po 沒有放棄，接著又跑了好幾輪 loop 與工作流程調整，最終產出影片中展示的粗糙但可運作的原型——累計花了 22 小時、86 個 agent。

他認為卡關的關鍵在「回饋品質」：Claude Code 沒辦法直接看懂遊戲畫面影片，只能抽幀之後逐張推理，效果普通；反而是讓 agent 輸出結構化 JSON 來描述遊戲狀態（例如角色位置、物件互動），Claude 可以直接讀懂世界正在發生什麼，除錯效率好上不少。原 po 打算繼續推進這個實驗，並考慮把底層引擎從 Three.js 換成 Babylon.js。文章衝上當日 r/ClaudeAI 熱門第一名，社群反應兩極。

社群反應

本報觀點

這篇很適合拿來當「agentic loop 現況」的溫度計看：22 小時、86 個 agent，換到的是一個能跑但遠談不上遊戲的雛形，效率與成品落差本身就是最誠實的資訊。← 藏鏡人批：86 個 agent 才換來一個「能跑」，這數字本身就是給「vibe coding 萬能論」的一記提醒。正反兩派其實沒有真的在吵同一件事——讚賞的人看的是「這套方法論本身走不走得通」，批評的人看的是「花這些成本重造一個沒人需要的山寨版有沒有意義」。兩種評價都對，只是評分標準不同。真正值得記住的是原 po 那句關於回饋迴圈的觀察：讓 agent 讀結構化 JSON 而非解讀影片畫面，除錯效果明顯更好——這比「有沒有做出 GTA 6」更接近一個可複製的工程結論，也是這類 agentic loop 實驗未來能不能規模化的關鍵瓶頸所在。

6. [工具] 刪光 CLAUDE.md 會怎樣？Anthropic 工程主管一句話炸出社群大整理潮

• 作者：u/cmogpt｜265↑｜111 則留言

報導

（本報賈新聞／工具組報導）事情起於 Anthropic 旗下 Claude Code 團隊工程主管 Boris Cherny 在一支訪談影片中丟出的建議：試著把 CLAUDE.md 整個刪掉。原 po u/cmogpt 半信半疑照做，在測試帳號上把設定檔清空後觀察一段時間，發現 Claude 的推理表現「沒有明顯變差」，於是發文詢問社群是否也有類似經驗，貼文迅速累積 265 個讚、111 則留言。

討論延燒之後，一則系統自動生成的長文摘要替爭論定了調：Cherny 的本意並非要人把 CLAUDE.md 全數歸零，而是提醒許多人的設定檔是替舊、較笨的模型量身打造，如今塞在裡頭的規則反而在跟 Opus 5 這類新模型自身的推理與規劃能力打架，該做的是像日式「怦然心動整理術」那樣斷捨離，而非整批刪除。社群普遍建議把「寫乾淨程式碼、加註解、寫測試」這類通用寫作建議直接砍掉——新模型本來就懂；但「monorepo 結構、部署眉角、沒人敢動的遺留表、API endpoint」這類模型無法從程式碼本身推得的專案事實，必須留下來。← 藏鏡人批：問題從來不是「要不要 CLAUDE.md」，是裡面那些規則到底是替現在的模型寫的，還是替兩年前那個還會亂編函式庫的模型寫的。

正反立場在留言區明顯分裂。高分留言 u/tr14l 主張根本不必糾結刪不刪，把 CLAUDE.md 當一般文件維護、定期更新即可；但擁有 20 個 package 的大型 monorepo 使用者 u/abandonplanetearth 與 u/loose_fruits 強烈反對整份刪除，指出拿掉設定檔後 Claude 立刻開始在不同套件間重複造輪子，落差非常明顯。也有網友提醒，Cherny 真正想表達的重點其實是別讓龐大的設定檔跟模型自身的規劃能力互相打架，而非鼓勵無腦清空。工具面，社群普遍推薦跑內建的 /doctor skill 自動分析並建議該砍哪些規則，減少人工整理的猜測成本。

社群反應

本報觀點

CLAUDE.md 會不會拖累模型，說到底不是「有沒有」的問題，是「裡面裝的東西還新不新鮮」的問題。舊模型時代寫下的護欄規則，放到推理能力更強的新模型面前，很可能從助力變成雜訊；但跨套件的專案事實、部署眉角這種模型永遠推不出來的「記憶」，刪了才是真的自找麻煩。與其跟風整份清空或整份留著，不如定期拿 /doctor 之類的工具照照鏡子，該斷就斷、該捨就捨，這才是這場討論真正想講的整理術。

社群溫度計