苦勞德報 — 2026-07-06

2026-07-06

1. [頭版] 「我一開始看走眼了」— 開發者實測後才懂 Fable 的真本事不是更聰明，是一次看懂全局

• 作者：u/Spooknik | 1198↑ | 110 則留言

報導

（本報賈新聞／科技組報導）一則標題坦承「我一開始誤會了 Fable，現在總算懂了」的貼文，本週在 r/ClaudeAI 衝上 1198 個讚、引來 110 則留言，成為社群近期討論度最高的實戰心得。原 po 一開頭就先潑冷水：若你期待 Fable 用天才級的表現嚇到你，恐怕會失望，論 raw intelligence（原始智力），它只比 Opus 好那麼一點點。他自承剛上手時相當無感，直到燒掉至少 500 萬個 token、實際操練一陣子後，才摸清 Fable 的價值到底藏在哪。

真正讓他改觀的是一個 PCB 設計案子。那份 PCB schematics 極為複雜，分散在好幾張電路圖上，工程師得一張一張對照才能拼出全貌。他指出，Opus 表現算是及格，但只要跨超過兩張圖，就會開始漏東西、甚至憑空亂猜，鬧出一些低級誤判。Fable 則能一口氣把八張圖全部納入視野、抓到完整的來龍去脈。原 po 的結論很清楚：Fable 的強項不在「更聰明」，而在「腦子裡能同時裝下更多東西」，並且在大 context 下把品質維持得更久。

這番話戳中了不少人的實戰痛點。多位開發者補充，程式碼品質未必真的變好，關鍵是「不會做到後面就走鐘」。更值得注意的是留言區浮現出一套實用 pattern：把 Fable 當成 orchestrator，先讓它通盤分析 codebase 與文件、產出一份建議文件，再切換到 Opus 逐項落實。有人形容 Fable 帶著一種「有智慧的常識」，眼看方向不對時會直接吐槽「這樣搞下去，根本像在磨磚頭」，而不是埋頭硬幹到撞牆。

本報觀點：這篇心得替 Fable 補上了一塊過去被忽略的評價維度。當各家模型還在比誰的單題推理更漂亮時，實務現場真正稀缺的，往往是那種「看得夠遠、記得夠久」的全局判斷力。← 藏鏡人批：說穿了 Fable 記性好、Opus 手比較巧，分工就好，別叫一個模型校長兼撞鐘。

社群反應

2. [工具] Claude 愛自創術語把人逼瘋！fan out、blast radius 講得又臭又長，該怎麼治？

• 作者：u/beholdtoehold | 471↑ | 291 則留言

報導

（本報賈新聞／工具組報導）一則抱怨 Claude 講話「又臭又長」的貼文，在 r/ClaudeAI 引爆廣泛共鳴，短短時間衝上 471 讚、累積近 300 則留言。原 po beholdtoehold 表示，Claude 大概是為了求精簡，反而寫出密度高得嚇人的句子，還自創一堆沒定義過的複合詞，讀起來吃力又累人；更麻煩的是，它會把這些沒交代清楚的自創概念直接塞進 spec 和 plan 裡。原 po 感嘆，自己只想要它好好講人話，就像 Codex 開箱就辦得到那樣。

留言區立刻變成大型吐槽現場。有人形容，明明是當天才一起建好的專案，Claude 講起來卻像「已經在大學地下室做了 50 年」，每個流程、每份文件、每套 workflow 都自己發明了縮寫。也有人點名它的「greatest hits」愛用詞：非同步的東西一律叫 fan out、明明是一個 group 偏要說 clique，還特別鍾情 blast radius（影響波及範圍）。這些詞若只是拿來聊天倒也罷了，問題在於它會反過來污染使用者 app 本身的領域詞彙——有位開發者的程式裡本來有個 initialVerification，Claude 自作主張全改寫成「IV」，讓人一頭霧水到底是點滴（intravenous）還是羅馬數字 4。

好在災情之外也有解方。多數留言的共識是：直接把話講白。有人固定回一句「你這段寫得太密了，改成清楚、精簡、不重複的散文」；有人乾脆把「不准用縮寫、不准自創複合詞、必要時講到像對五歲小孩解釋」寫進 system prompt。要根治，把這類指示放進 CLAUDE.md 或 system prompt 是最省事的一步；重度使用者甚至用 ast-grep 寫死規則自動攔截，或做成開源 skill 分享出來。本報觀點：模型想顯得聰明，結果聰明反被聰明誤——把話講清楚，本來就比發明術語更難。← 藏鏡人批：一個把 group 講成 clique 的東西，最需要讀一遍的大概是它自己的 CLAUDE.md。

社群反應

3. [產業] 寫了 11 年，卻要問 Claude 怎麼寫 debounce：資深工程師的手感正在流失

• 作者：u/Downtown-Function-10 | 187↑ | 60 則留言

報導

（本報賈新聞／產業組報導）一名入行 11 年的資深工程師在 r/ClaudeCode 貼出一段自白，意外引爆同溫層共鳴。他說上週竟然開口問 Claude「怎麼寫一個 debounce function」——這個東西他從 2015 年起手刻過大概 30 次，如今卻得回頭查。

這位工程師描述的是一種正在發生的職務位移。他回憶半年前，code review 大約只佔一天工作的五分之一；現在幾乎整天都在 review。原因是 junior 們用 Cursor 或 Claude Code 一路 prompt 出功能，coderabbit 先掃過一遍，那些吹毛求疵的小問題在他打開 PR 之前就被清光，他只剩下坐在那裡當「程式碼海關」，專門查架構與商業邏輯。

矛盾的地方就在這裡。他坦言自己的 review 能力其實變強了——能跨多個 PR 抓到以前抓不到的問題，像是兩個人在 repo 不同角落默默造同一個 helper、或某次 refactor 動到了沒人要求它動的行為。這是真本事，而且比以往更銳利。但另一頭，他能清楚感覺到「手寫的肌肉」正在退化：週末想給自己做個小東西，沒有 deadline、沒人等他交付，他卻不斷伸手要 agent 幫忙搭骨架；逼自己純手工做，過程又慢又笨拙，甚至有點難堪。他說自己明白工作的重點是交付能動的軟體、不是為了工藝去自討苦吃，但「還是覺得像是失去了什麼」。

這篇貼文之所以熱，在於它精準命中一個尚未有定論的問題：這究竟是能力退化，還是單純的技能轉移？本報觀點是，答案恐怕兩者皆是——手感確實在流失，但流失的同時也長出了新的、更難被取代的判斷力，關鍵是別讓天平在無意識中整個倒向一邊。← 藏鏡人批：review 變強是紅利，但哪天面試官抽掉 AI，白板前的沉默就是帳單。

社群反應

4. [科技] OpenAI 傳搶跑「AI agent 手機」，2027 上半年量產對打 iPhone

• 作者：u/Sea-Opening-4573 | 227↑ | 123 則留言

報導

（本報賈新聞／科技組報導）OpenAI 造手機的傳聞再添一筆。據以蘋果供應鏈爆料聞名的分析師郭明錤（Ming-Chi Kuo）放話，OpenAI 正加速自研硬體，量產目標訂在 2027 上半年，直接把矛頭指向 iPhone。

與市面上以 app 為中心的手機不同，這台裝置的賣點是「無 app、agent-first」——整台機器原生跑常駐 AI agent，在背景自動執行多步驟任務，使用者不再一個個點開應用程式，而是把意圖交給 agent 代勞。外流規格同樣搶眼：客製化 MediaTek Dimensity 9600 晶片（採 TSMC 2nm N2P 製程）、雙 NPU 異質架構同時吃下視覺與語言運算，並以 LPDDR6 記憶體搭配 UFS 5.0 儲存，來緩解本地模型推論的頻寬瓶頸。郭明錤預估 2027 至 2028 年出貨量約 3000 萬台。

須先聲明的是，這整套說法目前仍停留在分析師爆料與供應鏈傳聞層級，OpenAI 官方並未證實任何規格或時程。社群的第一反應多半是唱衰：有人翻出「不是說要轉向獲利嗎，怎麼又跳進硬體火坑」的舊帳，也有人質疑一家軟體公司要在手機硬體上正面對打 Apple、Samsung，勝算實在難尋。至於「拿掉所有 app」這個核心賣點，反對者更直言那是「在解一個根本不存在的問題」。本報觀點：把整個作業系統賭在 agent 能不能聽懂人話上，方向大膽，但在官方點頭之前，這仍是一張畫在餐巾紙上的藍圖。← 藏鏡人批：郭明錤的餐巾紙藍圖年年有，能不能出貨是另一回事——先把手機做到不跟 OS 打架再說。

社群反應

社群溫度計