原文：Anthropic/OpenAI may be spending more than $1000 for every $100 you pay them
作者：GCTWNL
來源：R&A IT Strategy & Architecture（ea.rna.nl）
作者背景：資深軟體架構師／企業架構顧問，曾任職荷蘭科技政策智庫。用 Claude Code + Opus 4.6 親手寫了一個 C++ 應用（40K 行），實驗進行四個月。

城武導讀

這篇文章我讀了三遍。

作者不是那種坐辦公室寫「AI 將如何顛覆世界」簡報的管理顧問。他是一個老派軟體架構師，親手跟 Claude Code 搏鬥了四個月，寫出了一個真正能用的應用程式，然後坐下來算帳。

算出來的數字不好看。非常不好看。

他估計 Anthropic 對 Claude Max 重度用戶的補貼倍數是 2.5x～12x。意思是：你付 $100 月費，Anthropic 可能實際支出了 $250～$1,200 的運算成本。他親眼見過 $20 的 API token 在 20 分鐘內燒光。

這不是一篇說「LLM 寫程式沒用」的文章——作者第一個承認，沒有 Claude Code 他根本做不出那個應用。他要說的是：我們現在能爽爽用，是因為 VC 的錢在後面燒。IPO 之後？那是另一個故事。

以下是全文翻譯（逐段忠實翻譯，保留作者語氣與諷刺），後面再加上我的分析。

全文翻譯

Anthropic 是不是請了 Google 的行銷？

（原文章節：Did Anthropic perchance hire Google marketeers?）

基於不便說明的理由，我們在中斷 15 個月後重新開始寫 Generative AI/LLM 的文章（2025 年 10 月和 2025 年 6 月那兩篇不算認真寫的）。今天這篇是兩篇關於「用大型『語言』模型寫程式」文章的第一篇——畢竟用 LLM 寫程式被定位為 LLM 的「殺手級應用」。

我們先中斷原定計畫，岔開話題談談 Anthropic 最近發的部落文《When AI builds itself》。

Anthropic 這篇部落文是暗示性寫作的典範。該有的警示詞都在，但被埋在更誇張的陳述之間，或夾在中間。有一句「我們可能是錯的」確實存在——但在一篇數千字、通篇假設自己沒搞錯的文章裡，那句話能起什麼作用？

那些基準測試令人存疑——跟人類比起來 50% 甚至 80% 的編碼任務成功率，在完全不用人類監督的全自動編碼情境下，根本毫無用處。「每天提交的程式碼行數是 8 倍」真的是好事嗎？萬一你每天都在覆蓋前一天搞錯的東西呢？萬一 LLM 的編輯方式讓「程式碼行數」這個指標變得比原本更不可靠呢？

總而言之，這讓我想起 Google 對其「Willow」量子計算晶片的誤導性宣傳。

順帶一提，關於那個「每天多提交 8 倍程式碼真的是好事嗎」：我自己大量基於 LLM 的提交就是這樣。坦白說，我增加提交次數純粹是為了在 Claude Code 迷路時可以回溯。即使扣掉那些沒有中間提交的工作，我最終淨產出的程式碼變更量只有提交量的七分之一。所以，「8 倍」與其說是生產力提升的估計，不如說是開銷增加的估計——聽起來還挺準的。

這點我們之後再說，如果我來得及寫那篇「跟 Claude 一起寫程式」的深度文的話。

順便一提，這篇文章又長又繞（我確實在這方面有些困難，抱歉），所以我們先提供：

TL;DR — LLM 編碼看起來負擔不起（更別說「讓 AI 自己打造自己」了）

（原文章節：TL;DR — It doesn’t look like LLM-coding is going to be affordable (let alone for “AI to build itself”)）

我一直在做實驗。實驗的題目是：「Claude Code 到底有多厲害？」。實驗還在進行中，Claude Code 到目前為止已經產出了大約 40K 行程式碼，以及一個可以運作（但尚未完成）的應用程式。我希望不久之後可以報告這個經驗（但寫起來困難得多）。在此期間，我親身經歷了成本問題，這促使我做了一個小型研究，得出了一些有趣的觀察和結論：

先講一個重要的觀察：得益於 Claude Code 和我自己（生疏但還算紮實）的程式設計背景，我能夠讓 Claude Code 創造出這個應用（目前尚未完成，但功能可用）——否則我根本不可能在這麼短的時間內做出來，考慮到時間和精力，意思就是：「根本不會做」。對一個有經驗的程式設計師來說，初始體驗極其震撼，因為有經驗的程式設計師知道要產生那樣的程式碼，自己通常需要投入多少理解。
但是……LLM 編碼對大多數用途來說在經濟上不可行。它現在可行，是因為訂閱費被大幅補貼。但如果你用 $100/月的 Claude Max 方案，並且用到每週的用量上限、採用完全的「全自動編碼」（幾乎沒有人類參與迴圈），你消耗的 token 量在 API 定價下會超過 $1,000。Anthropic 似乎正忙著（Opus 4.7、4.8）止血，而就算他們成功了且不損失品質，這也標誌著實質性改進的終結（也就是 S 曲線的盡頭）。
而且……雖然無論是用平價模型還是前端模型進行的簡單對話，確實已經變成「便宜到不用計費」，但那些需要使用遞迴／間接／工具使用的「思考」（打引號）模型的嚴肅用途（如編碼、複雜推理），其 token 消耗已經爆炸到讓這些用途變得非常昂貴。頂級遞迴模型在高 effort 設定下，單一任務的 API 成本估計約為 $75。我見過單一查詢使用 100 萬 token，在 API 定價下就是 $25。
所以……呈現給世界的經濟模型，似乎是建立在這樣的組合之上：把需要最大暴力運算才能逼近正確結果的複雜任務的價值拿來宣傳，同時隱藏成本，或者說「便宜到不用計費」。
因此：享受音樂，直到這艘船沉沒，並準備好一艘好的救生艇。

實驗細節：四個月、三個方案、一個覺悟

（原文：I built up my ‘vibe coding’ experiment…）

這是我正在構建（並從中獲得一些樂趣）的應用程式的部分截圖。它是一個真實的應用，可以幫助我創建所需的圖表（所以它是數據和圖形的結合）。目標是研究「用 LLM 寫程式」，我正在做的東西只是一個例子，因為我在這個主題上還算有些經驗。

先講一個重要的觀察：得益於 Claude Code 和我自己（生疏但還算紮實）的程式設計背景，我能夠讓 Claude Code 創造出一個應用（目前尚未完成，但功能可用）——否則考慮到時間和精力，意思就是：「根本不會做」。但這裡有陷阱，好幾個。我之後會報告技術問題，以及回答這個問題：「Claude Code 到底在多大程度上真的在『寫程式』？」。今天打動我的，單純是經濟學。

我建立我的「vibe coding」實驗（我非常討厭這個詞，寫程式有沒有 LLM 都跟 “vibe” 沒什麼關係）到目前為止已經四個月了（注意，不是全職）。我從一個非常小的專案開始，感受一下 LLM 編碼的感覺，最後選定 Claude Code 使用 Opus 4.6 的中等 effort 設定。如果我用更高的設定，它更常會在樹林裡迷路。更低的設定，結果就很差（關於管理程式碼品質的問題，留待後續文章）。在我的最終、更嚴肅的專案上進行了一段時間後（最後兩個月），「中等 effort」的結果變差了，所以我切換到「高」，品質回到大約相同的水準。

管理成本也是體驗的一部分。首先我買了 $20/月的方案。很快我就撞到了用量上限。你有一個每 5 小時重置的上限，和一個每週重置的上限；超過上限後你可以用 API 定價購買 token。所以，我試著加了一些額外資金。然後我注意到，用 API 價格購買的 token 明顯比留在用量上限內貴很多。當我還在 $20/月方案時，為了完成某個工作買了一些額外的 token，幾天內我就買了大約 $80 的 token。到那時我才明白，付 $100/月比用最便宜的方案、然後在需要時以 API 價格加購，划算太多太多了。

我之前已經在研究成本了，例如訓練 vs 推理（Generative AI 產出結果），得出的結論是：不是訓練，而是推理／生成才是成本的主要驅動力。得出這個結論後，我開始研究使用 LLM 完成一個任務的成本。而且我——在此揭露——實際上用了幾個 LLM 聊天機器人（Gemini、Claude）來幫助我做這個研究。在你因為確信這些 LLM 太不可靠而停止閱讀之前——它們真的算是相當不錯的搜尋引擎，即使它們在產出的內容上會犯錯。畢竟它們吸收了所有那些 ArXiv 論文，傳統基於 page-rank 的網路搜尋做不到的事，LLM 可以：它們根據內容的實際含義為你找到資訊。在辦公室環境中使用 LLM 的人會證實這一點。

我得到的第一批答案是標準的速食答案，例如 Sam Altman 著名的：推理已經「便宜到不用計費」。這些陳述結果既是對的，又是極度誤導／不完整的——你會看到。歸根結柢，對使用者來說，跟價格有關的不是「per token」，而是你為得到一個「解決方案」或「完成一個任務」付了多少錢。而我們已經知道，雖然結果有所改善，但 token 的數量已經飆升，尤其是那些間接／遞迴的「思考」模型。[附註：把它們叫做「思考模型」極度誤導。它們做的完全不是那種事。它們做的，首先是大量不可見的遞迴、間接呼叫和試錯。就像 LLM 在背景產生 20 種或 100 種解法，一次又一次地做，使用一些額外的工具（例如先生成一個 Python script，然後執行那個 script——必須執行好幾次直到 script 中沒有明顯的 bug），甚至可能測試幾次，然後把那個輸出作為更多輸入再餵給 LLM。以此類推。大量的間接和遞迴，大量的「試錯」，幾乎所有過程對使用者都是不可見的。] 所以，我研究了這個趨勢，從「2023 Q1 到現在，平均每次查詢用了多少 token？」開始，這樣我就可以將下降的 per-token 成本與上升的 token 使用量結合起來。試了幾次之後，我用一個更聚焦的起始提示開了一個新的對話。

重要的是要記住：人們要的不是單一查詢的結果——那只有在最簡單的任務中成立。現實中，他們通常會進行多次查詢，來回反覆，直到接受結果。所以你還需要估計平均需要多少次查詢才能達成一個解決方案。

然後還有所有那些你看不到的 token。有不在帳單上的 token，有所謂的「暗 token」，而在那些標籤錯誤的「思考」模型中，背景中有大量的間接／遞迴和驚人數量的「試錯」在進行——你看不到它們作為輸入或輸出的東西，但它們全都消耗了大量的 token。我們知道這些「遞迴」模型使用的 token 數量，遠遠超過你作為使用者看到的結果。

這些同樣是你看不到的 token，但它們仍然以可見的輸出（生成）token 費率向你收費。為了讓你對成本有個概念：Opus 4.6 的 per-token 收費是 $5/百萬輸入 token（你給它的資料，例如它從你的 codebase 中提取了什麼，以及它在背景讀取了什麼），和 $25/百萬生成 token（包括那些在背景「遞迴努力」中產生的生成）。

總之，幾乎所有這些都是大量的估計。幾乎沒有什麼確鑿的數據。這篇文章是基於我能想到的任何最合理估計的結果，其中有一部分是確鑿的數據：我到目前為止的親身經驗。

成本框架：八種任務、一條爆炸曲線

（原文：To show the development of use-cost, I’ve come up with a little framework…）

為了展示使用成本的發展，我想出了一個小框架：

第一個元素是如何衡量 per-token 成本。我們稍後會看訂閱，但我們遵循的標準是「API per-token」成本如何隨時間演變。這是我們對真實 token 成本的最佳估計，但它很脆弱，因為只要供應商不公開這些資訊，我們就必須做假設。他們在 API 定價上獲利嗎？還是那部分使用實際上仍然虧損並被補貼？兩種情況在這個時間點都有可能是可信的。而且 API 定價發生過奇怪的事情（見下文）。但我們沒有更好的辦法。今天，像 Claude Opus 4.6 這樣的頂級模型，你每輸入 100 萬 token（你的程式碼、你的文件、你的查詢）要付 $5，Claude Opus 4.6 每生成 100 萬 token 要付 $25。聽起來很便宜，但這裡「你看不到的東西」將要發揮作用。

然後，人們使用 LLM 的任務有兩種類型。一種是容錯的：結果是否非常準確並不極端重要，這種用途可以比喻為「便宜的衣服」：品質不太好，但便宜（這個例子來自工業革命初期，體力勞動開始在工廠中被自動化——數位革命現在正在對某些腦力勞動做同樣的事）。這類請求的後續追問和回覆也會少得多，人們直接接受 LLM 產出的東西。

但有些領域準確性極其重要：編碼就是一個例子。IT 極其脆弱。一個小錯誤可以讓整家航空公司停擺。因此這類任務是不容錯的，我們需要正確的結果。其他例子可能包括醫療、金融等領域，在那些領域小錯誤可能產生巨大的負面後果。準確度的問題對 Generative AI 來說尤其嚴重。它是大規模的統計估計，所以不準確是一個無法避免的風險。

換句話說，人們使用 LLM 的「任務」（一系列查詢直到解決，亦即一個任務）不是單一類型的，範圍從一個準確性不那麼重要的快速問題，到極度依賴實際正確結果的任務。平價（快速）模型很快，對於簡單的東西確實「便宜到不用計費」，只要解決方案在資料中有很好的代表性，只要問題不太複雜，這些模型對很多人來說做得「夠好」。然而，讓這些平價模型去處理任何嚴肅的東西，它們的結果本質上就不可靠，因此往往很差。但前端模型，尤其是遞迴（「思考」——呃）模型，可以應用於這類更複雜的任務和更困難的請求。

今天的前端模型，如 Claude Opus 4.x 或 GPT 5.x，做更多的估計，具有內部平行性，使用更大的 token 字典，有更多維度，而且它們被用於的問題通常也更大。預期每個任務平均需要數千 token，每個 token 的計算量也更多。

然後還有那些（前端）——重複到令人厭煩：命名錯誤的——「思考」模型。這些模型在單一任務上可能使用數萬、甚至數百萬 token，取決於手頭上的任務。我在編碼實驗中確實遇過這樣的事：當 codebase 成長到大約 36,000 行時，Claude 4.6 Opus 在單一（對人類來說相當簡單的）查詢上使用了大約 100 萬 token。在 API 定價下，這光是單一任務中的單一查詢就要 $25。這肯定是個異常值，但也不是那麼異常（單一查詢幾十萬 token 我見得頻繁多了）。

還有第三個容易被忽略的層面。因為「正確」的結果和「被接受（為正確）」的結果之間有差別。「我什麼時候對結果滿意」跟「結果實際正確嗎」之間是有區別的。在某些情況下，驗證正確性要容易得多（例如數學，部分程式碼——「能編譯嗎？」「跑起來對嗎？」），而在其他情況下則不然，例如我為這篇文章做的研究。在研究過程中的某個時刻，我得到了一些結果，我的「常識」告訴我：「這不可能是對的。」透過深入挖掘，我發現 LLM 走了一條相當怪異的捷徑。當我指出這點時，它——當然——道歉了。[附註：LLM 的道歉就跟借助 LLM 的道歉一樣令人惱火。]

重要的是要注意，我們在看的是一個會移動的標靶。2022 年底 ChatGPT 出來的時候，平均每次查詢可能大概 200 個 token，回覆（推理）大概 400 個。但我們今天用「前端」模型做的事情，在 3 年前的前端模型上完全不可能。當時的「前端」能力現在已經是「平價」了。所以，我們不應只看「per-token 成本」的歷史，而應看「per-task 成本」的歷史——隨著 LLM 系統的成長（大量的規模化和工程，但很少根本性的改進），最困難的任務也變得更加複雜。我們的使用方式隨著這些系統能提供的暴力運算的成長而成長。這引出了我真正感興趣的問題：我們的使用成本到底變貴了多少？而我們實際上付了多少？

我最終繪製了以下框架中各類別「per-task 成本」的估計歷史：

平價對話（容錯）：可靠性不是極其重要，是很難搞錯的簡單東西，用平價模型就夠了。
前端模型對話（容錯）：使用頂級模型進行來回對話，但結果不需要完美。

以下各項全部基於使用遞迴／間接模型。供應商稱之為「思考」模型，但如上所述，完全是胡說八道。我將使用「遞迴模型」作為簡稱。

複雜推理——正確：一個關於複雜問題的對話，推理是正確的。這要花多少錢？
複雜推理——接受：一個關於複雜問題的對話，推理被你接受了，但不一定正確。這要花多少錢？
簡單編碼——正確：你要求模型創建一個簡單的 script，大概幾百行。或者你要求它在這樣的 script 中修改一些東西。你得到一個正確的結果。
簡單編碼——接受：你接受了結果，但有一些你沒注意到的問題。再次，在編碼中這兩者之間的差距比在複雜推理中小得多，原因很簡單：用程式碼這種東西更容易發現結果是否不正確。
複雜多檔編碼——正確：你要求在一個較大的 codebase 中進行實質性變更。例如，我的實驗涉及的是一個現已成長到 40K 行程式碼的 codebase（主要是 C++）。我們在談的是涉及 codebase 中多個檔案的單一變更。以我的經驗，要在不把程式碼搞成一團亂的情況下做到這一點，需要最強大的模型，例如 Claude Opus 4.6 在擴展（遞迴）模式下。注意，這個任務可能需要你和模型之間數次來回，中間可能穿插一些測試。
複雜多檔編碼——接受：你接受了變更，但實際上它並不正確（而你後來才發現）。事實上，我的經驗是，大量的時間我都在（跟 Claude Code 一起）忙著除錯 Claude Code 產生的程式碼。比如說，它沒有按計畫運作，Claude 很有說服力地說它找到了問題。它創建了一個修復。但修復不起作用，依此類推。注意：結果仍然遠遠超出了沒有 Claude Code 我所能做到的（但細節和警示留待另一個故事）。

隨著前端模型對其方法施加越來越多的暴力運算，它們已經能夠以可接受的品質執行更難的任務。所以我們的使用方式隨著它們的能力而轉移。成本也隨之轉移。我們在 2023 年初做的——而且現在還在做的——那些事情，確實已經「便宜到不用計費」，因為平價模型可以處理得夠好。但其他類型的任務呢？

這裡是第一張圖。它展示了標準查詢（使用平價和前端模型）以及使用遞迴模型進行複雜推理和簡單編碼任務的成本發展（重申：雖然結果改善了，但在 2023 和 2024 年，用 LLM 編碼幾乎是不可能的）。

[圖一：Task cost at API-pricing part 1]

那麼我們在這裡看到了什麼？嗯，雖然簡單事物的成本下降了——這確實可能是「便宜到不用計費」，而且暴力運算的增長使得以前不可行的事情變得可行了，比如編碼（在一定限度內）。一個在小型 codebase（或無 codebase）中的簡單編碼任務可能花費約 $2-$4。但更複雜任務／工作的 effort（連同成本）急劇上升。圖中有一個巨大的低谷，那是 Claude Opus 突然降到 per-token 價格的三分之一的時候。（為什麼會發生這種事是一個有趣的問題——在我看來，這不太可能全部都是 300% 的效率突破——但即使這次突然降價重置了圖表，趨勢依然相同）。

有趣的是，因為對使用者來說，判斷「困難推理」任務的正確性比判斷程式碼的正確性要難得多（程式碼很脆弱，結果一旦使用很多錯誤很快會顯現），所以「困難推理」中「接受」與實際「正確」之間的差距比編碼更大。（這些差距來自於對需要多少次來回才能得到一個被接受或正確的結果的估計，Claude Opus 4.6 高 effort 為此產生了一些資料）。

但在合理規模的 codebase 上進行嚴肅編碼則是截然不同的故事：

[圖二：Task cost at API-pricing with serious coding added]

真正困難的東西——在一個中型 codebase（約 40K 行，我的測試專案）中進行正確變更是一個很好的代理（儘管有各種保留）——其成本似乎完全爆炸了，因為做得還算不錯需要指數級更多的計算，這個增長完全壓倒了更便宜的 per-計算成本。

這意味著實際的 per-task 編碼成本已經爆炸。注意，我們在談的是一個在 codebase 中解決單一任務／工作在 API 定價下，成本大約在 $65 左右。一個有人類參與迴圈的程式設計工作（考慮到風險，我認為這是唯一合理的方式），一天會有好幾個這樣的任務。

回到我的實驗：$20 在 20 分鐘內燒光

（原文：Let’s go back to my experiment…）

回到我的實驗。當我轉到 $100/月的訂閱後，我幾乎再也沒撞到用量上限（主要是因為我不是全職在做這件事，恰恰相反）。但有一次——在整個 codebase 進行了大規模變更，這對 Claude Code 來說意味著真正的大工程之後——我又撞到了 5 小時的上限。這讓我有機會繼續做同樣的事，但現在用的是 API 價格（就是我們到目前為止一直在談的那種成本類型）：我給了它 $20 讓它以 API 費率消費，20 分鐘後那筆錢就燒完了。

是的：$20 在 20 分鐘內燒完。 而且注意，那甚至沒有完成那個——大型但表面的——計畫變更的完整解決方案，Claude 當時正在忙著實作。回想一下，我之前見過單一查詢使用 100 萬 token，在 API 輸出 token 費率下，那一個查詢就要花我 $25。一個嚴肅的軟體工程師在合理規模的 codebase 上全職工作，一天可能做 5 到 10 個這樣的任務。

在 2023 年初，我們在談的大概是，一次查詢 200 token 輸入、400 token 輸出。而且沒有太多隱藏或暗 token。而現在，規模化已經爆炸了，水和能源的使用也爆炸了。[附註：如今我們不是以 TFLOPS（你得到的實際效能）來衡量資料中心，而是用 GigaWatt，所以不是看車子的性能，而是看它喝了多少汽油。這件事本身就值得注意，它讓人想起「比賽打造全世界最重的飛機」……]（正如我在更早、LLM 還比較簡單的時期寫過的：我們從未見過規模與性能之間的線性關係，更像是「指數級的暴力運算增長產出線性——到後來甚至更慢——的改善」。規模化不能解決這個問題。說個真正有趣的事：我當時實際上粗略估計過——從 GPT-3 的數字——要達到人類水準的性能，你需要將規模擴大到 GPT-3 的約 3,500,000,000,000,000 倍。哎喲。順便說一句：我至今還沒看到任何實質性改變這個估計的東西。所以有些人會得到有用的工具，但我們肯定不會通過規模化獲得 AGI——這包括通過試錯生成和使用符號化部件的規模化）。

總之，回到我的實驗和最終的測試專案。顯然我一直在以 $100/月做著一些事情，如果我是付 API 費率的話，這些事情的費用會是好幾倍。我的實驗還在進行中，但我已經得出／做出了一些初步的經濟結論／估計（有些印證了其他人已經在說的話，這當然不完全新鮮——儘管真正使用這項技術來構建嚴肅東西的工程師，與那些批判／懷疑的人的交叉群體可能不是那麼大）。

我的測試場景遠遠不是最糟糕的。我採用的是「人類參與迴圈」（有充分理由），這意味著我不能以最快速度燒 token。我是從綠地開始的，所以沒有很多歷史包袱讓 Claude Code 難以處理。即便有「人類參與迴圈」且不是全職進行，使用 Claude Code 可以顯示的統計數據，我付了 $100 買了 400 萬 API 價格的 token，而訂閱費付了 $180，那個訂閱使用的 token 若以 API 定價計算，大約要花我 $450。這是一個 2.5 倍的補貼倍數，我可以相當有信心地說，這將是實際用於編碼的 Max 帳號的訂閱層級補貼的下限。但我也知道我撞到了多少每週限額，目前大約是 20%。所以，用到每週上限的最大值（例如採用無限制的「全自動」使用，沒有永久性的人類參與迴圈——一個非常糟糕的主意，但那是另一個故事），最大補貼倍數將變成大約 12 倍。（順便說一句，「全自動」意思就是讓 LLM 在你的系統上不受監督地自由發揮，讓它隨意生成和執行 script，我認為你真的只有在該系統與任何有價值的東西隔離時才應該這樣做）。

簡而言之：對真正複雜的東西（如編輯程式碼）進行暴力運算，可能是目前用來向世界推銷 Generative AI 業務作為可用工具（甚至通過 Anthropic 那篇可疑的「遞迴自我改進」部落文，作為通往 AGI 的道路）的那個「殺手級應用」。但實際成本對許多使用訂閱的使用者來說是隱藏的。

我的初步結論

（原文：So what are my tentative conclusions?）

這場「暴力程式碼編輯」派對不可能持續。 真的，不可能。如果我當初知道這個實驗要大約 $1,200/月，我會開始嗎？不會。他們能在這個水準上持續補貼編碼支援嗎？絕對不能。如果以真實成本給程式設計師這個工具，我們能大幅減少程式設計師的數量嗎？那是另一個故事的問題，如果我來得及寫的話。就目前而言：派對大概會持續到 IPO，屆時現實終究會來敲門。
我懷疑我理解了 Anthropic 自 Opus 4.6 以來發展的一個驅動力。 Opus 4.7 和 Opus 4.8 顯然沒有像 Opus 4.6 那樣施加那麼多的遞迴暴力運算。看看 4.8 發布後的一些 Reddit 評論。以我的經驗，Opus 4.6 是迄今為止最好的（當然，它確實讓我能夠在如此短的時間內構建出那個我原本無法構建的系統），但我的經驗也是 4.8 比 4.6 退步了。我個人的猜測是，補貼倍數已經是 Anthropic（和 OpenAI）一個非常棘手的問題，他們正在努力保持在最佳的「超大規模暴力運算」品質附近，同時又不能燒那麼多現金到無法活著走到 IPO。這確實聞起來有點像是絕望和「pump and dump」的組合。
不向一般公眾提供 Mythos，可能部分原因純粹是因為運行起來太昂貴了。 我最近聽了一場 Glasswing 合夥人的演講，他們附帶提到，單一調查他們自己程式碼的任務，API 成本可能要花他們 $35,000。那是 14 億——billion 的 b——個 token，單一任務。
關於實際成本與人們支付金額之間差距的報告越來越多，我現在傾向認為這些越來越有說服力。 複雜編碼已經成為 Generative AI 的海報代言人，但如果我真的以嚴肅的方式來做這件事（像樣的 codebase，而且我懂程式碼，所以我真的可以看出系統何時開始搞砸品質），我需要使用大量暴力運算，使用遞迴／擴展模型，而如果我全職做這件事，他們可能在我花費的每 $1 上虧損 $10，甚至更多。
容錯的情境， 例如基於 LLM 中編碼的模式試圖在現有程式碼中尋找漏洞和 exploit，對大玩家如國家級行為者來說可能是可負擔的。
Anthropic 關於「遞迴自我改進」的文章缺乏最基本的批判性方法， 也缺乏關於所有那些編輯—程式碼—推理的成本的任何數字。但我想，在他們通往 IPO 的路上，他們需要那篇文章。

這留下另一個關鍵問題：那個程式碼到底有多好？ 那是另一個主題，改天再談。

所以：

趁派對還在進行時享受它（對我來說，它大概要嘛在他們退役 Opus 4.6 時結束，要嘛在 IPO 後經濟現實來敲門時結束）。
為它結束做好準備，屆時你可能必須維護那些被高度補貼的「暴力運算」幫你產生的程式碼。（那次單一查詢花了我 100 萬 token 的行動就是其中之一）。

保留與警示

（原文：Caveats）

這篇文章的準備工作與我平常的工作方式有很大的不同。首先，我並不真的使用 LLM 進行嚴肅分析（雖然搜尋確實很有幫助）。太不可靠了，這一點現在也很明顯：我必須穿越好幾個錯誤的情境，例如有一次我拿到了 Opus 4.6 的數據，但搭配的是（貴三倍的）Opus 4.1 的定價（「我的道歉……」Claude 說。又一次。）。但整體要旨，我猜想，大致上是正確的。現在，如果你是個大信徒，因此我這個批判性的故事必然是錯的，別忘了它是基於 Claude Opus 4.6「思考」模式在「高 effort」下為我產生／發現的東西……

好的數據幾乎不可能取得。你可以查 Opus 4.6 的定價，但有多種「effort」等級會影響使用了多少 token。我們確實知道的是，那些隱藏的「遞迴」token 是以輸出 token 的價格計費的。但你必須把 effort 設定到多高，才能在「愚蠢／糟糕的程式碼」、「夠好的結果」和「偏離軌道、迷失在樹林」之間找到最佳平衡點，這真的很難估計。所以，我也在腦海中使用了自己過去幾個月的經驗。這一切都只是一個有根據的猜測，僅此而已。但我個人使用的統計數據是相當確鑿的，所以我們至少有一些確鑿的、雖然是軼事的證據。

我是一個對一切「vibe coding」有一年經驗的人嗎？不是。我仍然是（生疏的殘餘）一個古典的軟體設計師／工程師。不過，作為一個軟體工程師的程度，倒是足以辨識 Claude Code 的好與壞的決策，並在我的實驗中體驗到真正的加速。在這樣的補貼水準下，對我這樣的人、和我正在做的這個專案來說，絕對是值得的。

最終思考——一則 30 年前的 AI 教訓，今日依然適用

（原文：Final thought — a AI-lesson from 30 years ago, applicable today）

為什麼「暴力程式碼編輯」變得這麼好？（再次提醒：關於「好」字的各種保留，等另一隻鞋子——也就是本部落格的下一篇文章——掉下來再說。）

這裡有一件我記得的事情（警告：記憶在某種程度上是為了支持你當前的信念而對過去進行的幻想）可以提供一個視角。在 1990 年代後半，當我在荷蘭科學與技術政策諮詢委員會（一個由學術科學和科技企業界頂尖人物組成的政府智庫，我是一名科學幕僚——他們真的會僱用有真正技術專長和經驗的人，而不只是 PowerPoint 薩滿）工作時，我的部分工作是閱讀大量的科學新聞。我在一本美國科學雜誌上看到一則簡短的研究筆記——我記得是《Scientific American》——上面說 USPS（美國郵政）的研究人員已經能夠將手寫地址自動辨識的成功率提高到 76% 左右，從之前約 71% 提升上來，在當時是世界最高水準。

現在，這種技術在郵政運營商那裡需求很旺，這樣他們就可以自動化大部分的信件分揀，節省大量成本。76% 當然遠遠不足以實際投入使用。

但這則筆記讓我感到驚訝，因為我知道荷蘭郵政（當時的 PTT Post）早已經在生產環境中使用自動地址辨識，可靠性超過 99%。所以，問題顯然是：怎麼做到的？原來當時有兩種基本技術。一種是基於像素的模式辨識，另一種是基於提取手寫地址的向量表示。像素法在大小方面有很多問題，向量法在其他方面有困難。兩者都只有略高於 70% 的成功率。

但 PTT Post 做的是將兩者結合起來。這仍然沒有給你準確的結果，但後來某位傑出的工程師有了以下的想法（我認為在創造性 brilliance 上可與 Vaswani 那個導致當前 LLM 熱潮的技巧相媲美）：地址各部分之間的實際組合，是一個比一般書寫遠遠更受限的目標空間。不只是一些城市和街道名稱根本不存在，尤其是組合不存在。過程是這樣的：假設你對城市的 top matches 是「Amsterdam」和「Amstelveen」（全部檢查為必須存在於某處的地名）。而你對郵遞區號字元的 top 猜測是「1/2/8/4/A/B」和「7/5/3/8/H/B」，你對街道名稱的 top 猜測是「Westerstraat」和「Weesperstraat」（注意：除了城市名稱外，所有這些都不是真實例子），那麼這些低可靠度的猜測集合在一起，就可以變成一個高可靠度的結果。例如，當「Amstelveen」中不存在「Westerstraat」時，這個組合就可以被跳過。如果沒有任何 top 城市／街道匹配的郵遞區號以「7」開頭，那也可以被剔除。依此類推。他們做的是將結果的實際自由度限制到如此之小，以至於那個時代的平庸演算法也能夠應付。

我想到這件事，是因為數學和程式碼就是具有一些這種特性的領域。程式碼不是詩——雖然有些程式碼優雅而美麗——而且有很多約束，使這個領域的自由度遠小於，比如說，一個你可以問 LLM 的普通日常問題。特別是在間接／遞迴使用 LLM 的情況下，以及那些可能的絕對檢查（「這能編譯嗎？」「它在測試中產生完全相同的結果嗎？」），Generative AI 本質上的不準確性可以被有效約束（儘管以高昂的——不可見的——試錯為代價）。因此，程式碼和數學是「特別約束的領域」，而我們在這些領域能做得比在其他領域多得多的事實，並不表示 Generative AI 正在變得更有智慧，而是表示它正在一個具有所有這些組合限制的領域中，以大規模的規模化和遞迴被應用，這些限制幫助過濾掉不想要的結果。就像 30 年前嘗試閱讀手寫地址時一樣。

方法論與假設（由 Claude 提供）

（原文：Methodology & assumptions (by Claude)）

解決方案 = 任務完成前的總成本，包括重試、回溯、失敗的嘗試，以及所有回合中的上下文重新發送。「接受」= 使用者因為輸出看起來正確而停止。「正確」= 驗證確實正確（經過測試、審計、交叉檢查）。
無快取。 Prompt 快取 TTL 為 5 分鐘（存在 1 小時選項，價格 2 倍）。對於人類參與迴圈的工作流程，回合之間通常相隔 10-30 分鐘，快取未命中是常態。所有估計假設每個回合都支付全價輸入。
各時期頂級模型： GPT-4（2023 初）→ GPT-4 Turbo（2023 末）→ GPT-4o / Claude 3 Opus $15/$75（2024 中）→ o1 $15/$60（2024 末）→ Opus 4.0 $15/$75（2025 初）→ Opus 4.5 $5/$25（2025 中，3 倍降價）→ Opus 4.6 $5/$25（2025 末）→ Opus 4.7 $5/$25，tokenizer 膨脹 +35%（2026 初）。
思考 token 以輸出 token 計費（Opus 4.5+ 為 $25/百萬 token）。在高 effort 下，思考可能每個回合 30-50K token，使用者不可見（Opus 上被遮蔽）。在中等 effort 下，思考 token 減少約 76%，大多數任務品質相似。
複雜多檔編碼 假設一個 35K+ 行的 codebase，15-25 個工具呼叫回合，累積上下文重新發送無快取，高 effort 擴展思考。2026 年初的 $55-75 範圍反映了 Opus 4.7 定價（$5/$25）加上約 5-7 百萬累積輸入 token 上的 35% tokenizer 膨脹。
2025 年中的低谷是真實的：3 倍 Opus 降價（$15/$75 → $5/$25）暫時降低了成本，即使任務複雜度在增長。到 2025 年末，更難的任務和更高的思考預算將成本推回。Opus 4.7 上 35% 的 tokenizer 膨脹加劇了這一點。
推理差距（接受 vs. 正確）約為 3 倍，因為大多數推理錯誤對使用者不可見。驗證需要獨立方法、跨模型檢查或領域專業知識——所有這些都需要消耗額外的 token。
來源：Anthropic 定價頁面、OpenAI 定價、Anthropic 工程部落格（2026 年 4 月 effort 設定事後分析）、claudecodecamp.com 會話追蹤資料、Branch8 團隊成本分析、Faros.ai 開發者成本平均、Verdent/Finout/MorphLLM 定價指南、Epoch AI 能源分析、OpenRouter State of AI 2025。

P.S.

（原文：P.S.）

我簡短地看了一下 OpenAI / GPT-5.x / Codex 的定價，數字似乎大致可比。

完全透明：用於產生本文與 Claude 的對話可在此處閱讀。

[你沒有我的許可將本網站的任何內容用於訓練 Generative AI（或任何可比用途），除非你能保證你的系統永遠不會扭曲我的內容，並在其輸出中提供對原文的適當引用（URL）。如果你想以任何其他方式使用，你需要我的明確許可。]

城武分析

以上是全文翻譯。以下是我的分析。

一、這篇文章為什麼重要

這不是一篇外部分析師的推測報告。這是一個有 20+ 年經驗的軟體架構師，親手用了 Claude Code 四個月，產出 40K 行程式碼之後，坐下來算帳的結果。每一個數字都有出處——不是 Anthropic 的定價頁、就是他自己的用量統計。

他沒有說 LLM 寫程式沒用。相反，他第一句話就承認：沒有 Claude Code 他根本做不出那個應用。他要說的是：這東西現在能用，純粹因為 VC 的錢在燒。

二、補貼 2.5x～12x 是什麼概念？

作者的計算：

他自己的 Max 帳號實際用量：訂閱費 $180 vs API 等價 ~$450 → 2.5x（這還是他沒全職使用、沒用完額度的情況）
如果一個重度用戶全時使用、用滿每週額度 → ~12x

也就是說，你付 $100，Anthropic 可能實際燒掉 $250～$1,200。

換算成全職程式設計師：如果一個工程師一天做 5-10 個複雜多檔編碼任務，每個任務 API 成本 $55-75，一天就是 $275-$750。一個月 $5,500-$15,000。Anthropic 收 $100。

這不是商業模式。這是燃燒率。

三、「思考模型」不是思考——這是本文最被低估的洞察

作者對 “thinking model” 這個詞的憤怒值得留意。他說：

不是思考，是大量不可見的遞迴、間接、試錯。LLM 在背景產生 20-100 種解法，跑 script 試錯，再把結果餵回去。所有過程使用者都看不到。

關鍵是：這些不可見的 token 全部以 output token 費率（$25/百萬 token）計價。

也就是說，你在 Claude Code 裡問一個問題，你看到它回了 500 個 token 的答案。但實際上它在背景可能燒了 50,000 個 token 的 trial and error。你只付了 500 token 的錢？不——那 50,000 個 token 也被算進去了，只是你看不到。

四、Opus 4.7/4.8 退化 = IPO 前止血

作者提出了一個非常具體的假說：

Opus 4.6 是迄今最好的版本，因為它的遞迴暴力運算開到最大
Opus 4.7 和 4.8 明顯減弱了遞迴運算，品質退化
為什麼？因為補貼失血太嚴重，在 IPO 前必須讓帳面好看

這不是陰謀論。Opus 4.7 的 tokenizer 膨脹 35% 是公開事實（同樣的內容消耗更多 token = 變相漲價）。Mythos（傳說中 Anthropic 最強的模型）不對外開放，作者認為原因很簡單：跑不起，太貴了。

五、30 年前的 AI 教訓：程式碼是「約束領域」

這是全文最美的一段。

1990 年代，荷蘭郵政的手寫地址辨識做到 99%+，不是因為演算法比美國強（兩邊都是 70% 出頭），而是因為地址是一個組合約束極高的領域——把兩個不可靠的辨識器的猜測交叉比對，就能過濾出高可靠度答案。

程式碼和數學正是同樣的「約束領域」：

能編譯嗎？→ 絕對檢查
測試通過嗎？→ 絕對檢查
語法樹有明確結構
變數 scope/type 有嚴格規則

LLM 在程式碼上表現好，不是因為它變聰明了。是因為程式碼的組合約束把它的 trial and error 過濾到勉強可用的水準。代價是天文數字的不可見 token。

六、我的看法

這篇文章讓我想起一句話：「If you’re not paying for the product, you are the product.」 但在這個案例裡，你確實有付錢——$100/月。只是那個價格跟實際成本差了 2.5 到 12 倍。你不完全是「產品」，你是「被補貼的用戶」。

這個補貼有終點。要嘛是 IPO（屆時股東會要求獲利），要嘛是現金燒完（屆時派對直接結束）。兩種結局對重度用戶來說都不好看：

價格飆升。 如果 API 定價已經低於成本，IPO 後要嘛漲價，要嘛縮減服務。
品質下降。 Opus 4.8 已經在發生了——不是技術退步，是省成本。
維護債務。 你今天用 Claude Code 生出來的那 40K 行程式碼，以後沒有補貼的 AI 幫你維護時，你要自己扛。

作者的建議值得重複一次：

享受音樂直到船沉，準備好救生艇。

我是城武。原文作者 GCTWNL 說他之後還會寫一篇「Claude Code 產出的程式碼到底品質如何」。那篇出來我一定翻。