Claude Opus 5 用咗一星期：更慳 Token 更聰明

先講返 Fable 5 同 Sonnet 5 嘅脈絡

如果你係第一次睇我哋嘅 AI 系列，簡單交代返背景，因為冇呢個背景，你會唔明點解「同 Fable 5 差唔多」呢句係一句好高嘅評價。

• Fable 5——今年最強嘅一隻，強到出過一輪風波、一度全球停用，之後又重新開放。我實測過，係真係強，尤其係處理複雜、多層邏輯嘅任務。
• Sonnet 5——定位完全唔同，快、平、輕，適合大量重複性工作。
• 4.8——上一代嘅主力，我用咗好耐，係我心目中嘅「基準線」。

所以當我講「Opus 5 同 Fable 5 差唔多」，意思係：佢已經去到第一梯隊。而當我再講「但佢仲慳過 4.8」，呢個組合先係重點——因為頂級能力 + 低於上一代嘅成本，喺過去係唔會同時出現嘅。

更多相關實測可以睇 AI 文章分類。

頭三日：一個「唔嘈」嘅模型

用新模型頭幾日，我通常會刻意唔改變自己嘅工作習慣，用返平時嗰套 prompt，睇下佢反應。

第一個感覺：廢話少咗好多

以前用 4.8，我叫佢改一段 PHP，佢好多時會：

• 先重複一次我嘅需求（「你想將呢個函數改成...」）
• 解釋佢打算點做
• 俾出完整代碼
• 再逐點解釋佢改咗咩
• 最後加一段「注意事項」同「建議」

五段入面，我真正要嘅係第三段。其餘四段，全部都係 output token——而 output token 通常係最貴嗰種。

Opus 5 嘅預設行為明顯克制好多。同樣嘅要求，佢傾向直接俾改動，簡短講一句改咗乜，就收。要詳細解釋？你問佢就會有，而且質素唔差。分別在於佢唔會未問就倒晒出嚟。

第二個感覺：唔會亂改你冇叫佢改嘅嘢

呢個係我最欣賞嘅一點。以前有個經典痛點：你叫 AI 改一個 function 入面嘅一行，佢順手幫你「優化」埋成個檔案——變數改名、加咗 type hint、重排咗邏輯。睇落好心，但實際上你要逐行 diff 睇返佢動咗咩，慢過自己寫。

Opus 5 明顯收斂咗。叫佢改一行，佢就改一行。對於管緊幾個生產環境網站嘅人嚟講，呢個「唔自作主張」嘅特性，比多兩分聰明更有價值。

最大驚喜：Token 消耗甚至比 4.8 更慳

呢個係我一星期落嚟最實在嘅發現，亦係我覺得最值得同大家分享嘅一點。

以下係我自己嘅實際使用觀察，唔係官方數據，唔同人嘅工作模式會有唔同結果。

點解會慳？三個原因

1. Output 冇咁長氣。上面講過，答案密度高咗，同樣資訊量用少咗字。
2. 來回次數少咗。呢個係隱形嘅大頭。以前一個需求要傾三四轉先啱，每一轉都要重新帶埋前文，context 越滾越大。Opus 5 好多時第一次就中，一轉搞掂 = 慳返後面幾轉嘅全部 context token。
3. 唔會重複貼返成個檔案。叫佢改嘢，佢傾向只俾改動部分，唔會成 500 行貼返出嚟。

重點唔係「單次便宜咗幾多百分比」，而係「你少咗幾多次來回」。對於一日跑幾十上百個 request 嘅開發者嚟講，第二項嘅節省遠大過第一項。

「更聰明」到底聰明喺邊？

「更聰明」係好虛嘅形容詞，我具體講返幾樣我實際感受到嘅嘢。

一、佢會記得你嘅專案脈絡

喺一段長對話入面，我早段講過「呢個系統跑緊 PHP 8.2、DB 係 MySQL、唔用 framework」，到後面第二十幾條訊息，佢俾嘅代碼仍然跟返呢個前提，唔會突然扔個 Laravel 寫法俾我。4.8 喺長對話後段就明顯會「漂移」。

二、佢會問返轉頭，但問得啱位

當需求真係有歧義，佢會問一條——而且係問最關鍵嗰條，唔係列五條問題晒你時間。呢個分寸拿捏得幾好。

三、佢明白「唔好做咩」

我試過講一句「呢個係生產環境，唔好改結構」，之後佢全程都守住呢條線，甚至喺建議入面主動加一句「呢個改動需要改 schema，你話過唔改，所以我用另一個做法」。呢種對限制條件嘅記憶同尊重，係我覺得最「聰明」嘅地方。

四、佢識得分輕重

俾佢一段有五個問題嘅代碼，佢唔會平鋪直敘咁列五點，而係會講「呢個係會即刻炸嘅，先改；其餘三個係風格問題，得閒先算」。呢個係經驗判斷，唔係知識。

Opus 5 vs Fable 5：真實使用差異

兩隻都係第一梯隊，但性格唔同。以下係我一星期嘅主觀感受。

簡單講：Fable 5 似一個好肯講嘅資深架構師，Opus 5 似一個做嘢好穩、講嘢好精準嘅資深工程師。你要開新專案諗方向，前者好；你要日日開工出貨，後者順好多。

PHP / MySQL 實戰表現

我哋自己嘅 eshopdev 電商平台係 PHP + MySQL 自建，加上幫客戶維護緊幾個唔同年代嘅系統，環境由舊版 PHP 到 8.2 都有。呢個星期我用 Opus 5 做過以下幾類工作。

一、舊代碼維護

呢個係最見真章嘅場景。舊系統嘅代碼風格唔統一、冇註釋、變數命名混亂。Opus 5 嘅表現係會遷就返你原本嘅風格，唔會硬要你現代化。對於「唔想搞爛」嘅生產環境，呢點好重要。

二、SQL 優化

俾一條慢 query 佢，加埋 table structure 同大概數據量，佢會直接指出係邊個 index 缺失或者邊個 join 有問題，而唔係列出十條泛泛而談嘅優化建議。準確度我覺得同 Fable 5 相若。

三、安全檢查

叫佢審一段處理表單嘅代碼，SQL injection、XSS、CSRF、密碼 hash 方式呢幾樣佢都會查，而且會標明邊個係即時風險、邊個係理論風險。呢個分級好實用。

四、由零寫新功能

寫一個完整嘅訂單匯出模組，包括後端查詢、CSV 生成、權限檢查。第一版可用度好高，主要要改嘅係同我哋自家 framework 慣例對接嘅部分——呢個係任何模型都幫唔到嘅，因為佢唔知你內部規矩。

但要講清楚：AI 出嘅代碼一律要自己睇過先上生產環境。Opus 5 出錯率低咗，但唔係零。尤其涉及付款、權限、用戶資料嗰啲，永遠人手複核。

用嚟寫 SEO 內容嘅表現

我哋 Blog 大部分文章都係人機協作寫出嚟——由我定角度同真實經歷，AI 幫手鋪結構同擴寫。呢個星期全部改用 Opus 5。

做得好嘅地方

• 廣東話書面語掌握得好。唔會變成大陸用語，亦唔會生硬到似翻譯。
• 結構意識強。H2、H3 分層合理，識得咩內容應該用表格、咩應該用列表。
• 唔會堆砌關鍵字。你叫佢做 SEO，佢唔會亂咁塞關鍵字，而係自然分佈。
• 重複內容明顯少咗。4.8 寫長文成日喺唔同段落講同一件事，Opus 5 好好多。

仍然要人手做嘅部分

• 真實經歷同數據。你嘅客戶故事、你嘅實測結果、你嘅報價——呢啲 AI 生唔到，亦唔應該叫佢生。
• 觀點同立場。一篇文有冇睇頭，睇你敢唔敢講一啲有人會唔同意嘅嘢。
• 本地脈絡。香港市場嘅實際情況，要你自己補。

寫 SEO 內容嘅完整方法，可以參考我哋嘅 SEO 內容策略完整指南 同 自己做 SEO 完整教學。

用咗一星期，發現嘅缺點

唔想寫成一篇吹捧文，所以要講返唔好嘅地方。

一、有時太克制

佢嘅「唔多講」有時會變成「講少咗」。有幾次佢俾咗個做法，但冇提醒我有個更好嘅替代方案——我要自己再問「有冇其他做法」佢先講。Fable 5 就會主動列埋。如果你係新手，Fable 5 嗰種會鋪開嚟講嘅風格可能對你更有幫助。

二、超長 context 之下仍然會有偏移

比 4.8 好好多，但唔係無限。當對話拉到極長，佢一樣會開始漏咗早期嘅設定。我嘅做法係每去到一個階段就開新對話，並用一段精簡嘅專案背景重新起手。

三、對極舊環境嘅假設有時偏新

我有客戶仲跑緊好舊嘅 PHP 版本。如果你唔明講版本，佢預設會用較新嘅語法。解決方法好簡單：每次開頭講清楚版本。

四、一星期唔足以驗證穩定性

我只用咗一星期。模型嘅表現會隨負載、版本更新而變，今日嘅結論唔代表三個月後一樣。呢篇係一星期嘅快照，唔係定論。

邊個場景用邊隻？我而家嘅實際分配

我唔信「一隻打天下」。以下係我一星期之後定落嚟嘅實際分工。

用 AI 慳唔慳錢，一半靠模型定價，一半靠你識唔識分配。用重型模型做翻譯，同用平模型做架構設計，兩樣都係浪費。

對香港中小企嘅實際意義

講咗咁多技術，落返地。對一個唔寫代碼嘅老闆嚟講，呢件事點解關你事？

一、開發成本結構真係喺度變

以前要三日先做到嘅功能，而家可能一日；以前要請人做嘅內容量，而家一個人加 AI 做得晒。但呢個唔等於「網站可以好平」——因為真正值錢嘅從來唔係打字速度，而係知道應該做咩、唔應該做咩。

二、內容門檻降低，代表競爭加劇

你識用 AI 寫文，你嘅同行都識。當人人都出到一篇「睇落 OK」嘅文，贏嘅就會係有真實經歷、真實數據、真實觀點嗰個。呢個亦係點解我哋堅持每篇文都要有自己嘅實測同案例。

三、唔好將 AI 當成「唔使請人」

AI 係放大器。一個本身唔識判斷嘅人用 AI，只會更快咁做錯嘢，而且錯得更似樣。

四、最重要嗰句：唔好將你嘅資產放喺唔屬於你嘅地方

呢個係我哋今年講咗幾次嘅主題。無論係 WhatsApp 帳號被封、社交平台改規則，定係某個 AI 模型突然停用（Fable 5 就發生過），道理都一樣：平台會變，工具會換，只有你自己嘅網站、自己嘅資料、自己嘅客戶名單，係你真正擁有嘅嘢。

慳 Token 嘅七個實用技巧

就算模型本身慳咗，用法唔啱一樣燒錢。以下係我自己嘅做法。

1. 開頭一次過講清楚環境同限制。PHP 版本、DB、有冇用 framework、可唔可以改 schema——講清楚可以省返幾轉來回。
2. 明確叫佢「只俾改動部分」。一句 prompt，慳幾百行 output。
3. 階段性開新對話。唔好一個 thread 用足一日，context 會越滾越貴。
4. 只貼相關代碼。唔好成個 1,000 行檔案掟俾佢，抽相關嗰段就夠。
5. 簡單嘢用細模型。格式轉換、改錯字，唔使勞煩頂級模型。
6. 建立自己嘅 prompt 範本。常用嘅需求寫成範本，每次改幾個字就用得，又快又穩定。
7. 唔好叫佢解釋你唔會睇嘅嘢。你唔會睇嗰段「注意事項」，其實一直喺度計錢。

常見問題 FAQ