Claude Code on KnightLi的博客

Claude Opus 4.8 發布：Anthropic 繼續強化程式設計與代理任務

Fri, 29 May 2026 15:22:47 +0800

Anthropic 於 2026 年 5 月 28 日發布 Claude Opus 4.8。這是 Opus 系列的新版本，官方定位很明確：不是一次換代式命名，而是在 Opus 4.7 基礎上繼續強化程式設計、代理任務、推理和專業知識工作能力。

這次更新對一般聊天使用者當然有意義，但更值得關注的是 Claude Code 和長任務 agent 場景。Anthropic 將 Opus 4.8 描述成更可靠的協作者：在複雜任務中，更能判斷何時提問、何時推進、何時保守處理。

這次更新的重點

Claude Opus 4.8 已經上線，價格維持不變。官方同時強調了幾項配套變化：

Opus 4.8 在程式碼、代理能力、推理和知識工作評測上，相比前代繼續提升。
claude.ai 使用者可以控制 Claude 在任務上投入的 effort。
Claude Code 新增 dynamic workflows，用來處理更大規模的問題。
Opus 4.8 的 fast mode 可以以約 2.5 倍速度工作，並且比此前模型的 fast mode 便宜三倍。

把這些變化放在一起看，Anthropic 不是只在模型分數上做小幅升級，而是在圍繞「長時間執行複雜任務」改造產品形態。模型更強只是其中一部分，任務控制、工作流拆解和成本結構同樣重要。

為什麼 Claude Code 使用者更應該關注

Claude Code 這類程式設計 agent 最怕的不是單個函式不會寫，而是在真實倉庫裡迷路。它需要讀檔、理解依賴、跑測試、看錯誤、修改方案，再把修改控制在合理範圍內。

Opus 4.8 的賣點正好貼近這些問題：

更適合 agentic tasks，也就是需要模型持續規劃、呼叫工具、觀察結果並調整策略的任務。
更強調 judgement，能在不確定時停下來確認，而不是一路自信地寫錯。
dynamic workflows 讓 Claude Code 更適合處理大規模、多步驟的問題。

如果這些能力在真實專案裡穩定，Claude Code 的使用方式會更接近「把一個明確目標交給它推進」，而不是只讓它補一段程式碼。

effort 控制意味著什麼

Anthropic 這次給 claude.ai 加入 effort 控制，含義很直接：使用者可以調節模型在任務上花多少力氣。

這對日常使用很實用。簡單問題不需要深推理，複雜任務則值得讓模型多想一會兒。過去很多使用者只能靠提示詞表達「認真一點」或「快速回答」，現在這種控制開始進入產品層。

對開發者來說，這也是一個信號：未來 agent 產品不會只暴露「選哪個模型」，還會暴露更多執行策略，比如速度、成本、推理深度、工具呼叫積極程度和風險偏好。

fast mode 的成本變化很關鍵

官方提到，Opus 4.8 的 fast mode 可以達到約 2.5 倍速度，同時成本比此前模型的 fast mode 低很多。

這件事容易被模型能力新聞蓋過去，但它對實際工作流很重要。很多 agent 任務不是只跑一次，而是會反覆執行：

產生初稿
跑測試
修復失敗
再跑測試
根據 review 繼續修改

如果 fast mode 足夠便宜，團隊就更願意把它放進高頻流程裡，而不是只在關鍵任務上偶爾使用頂級模型。速度和成本一旦下降，agent 才更容易從「展示效果」進入「日常工具」。

和 Opus 4.7 的關係

Opus 4.8 更像是一次面向可用性的增強版。它繼承 Opus 4.7 的定位，但把重點繼續推向程式設計、代理任務和專業工作。

從 Anthropic 的表述看，Opus 4.8 不只是回答更好，而是更會協作。它在任務中應該更清楚什麼時候需要資訊、什麼時候方案不穩、什麼時候應該先建立信心再做大改動。

這類能力很難只靠單一 benchmark 判斷。真正的驗證要看它在大型倉庫、複雜業務規則、長上下文任務和多輪修復裡的表現。

對 AI 編程競爭的影響

2026 年的模型競爭已經明顯從「聊天能力」轉向「能不能做事」。OpenAI、Anthropic、Google、xAI 都在把模型和工具鏈綁得更緊：模型負責推理，工具負責執行，產品層負責把任務保持在可控範圍內。

Claude Opus 4.8 的發布延續了這個趨勢。它的重點不是炫耀一個單點能力，而是強化三個環節：

模型本身更適合程式碼和代理任務。
Claude Code 能拆更大的工作流。
產品層開始提供 effort 和 fast mode 這類執行控制。

這對開發者的實際意義是，選擇模型時不能只看「哪個最聰明」。還要看它是否適合所在工具、能否穩定呼叫工具、長任務成本是否可接受、失敗時是否容易被糾正。

我的判斷

Claude Opus 4.8 是一次偏務實的更新。它沒有把敘事放在一個誇張的新參數上，而是繼續補 agent 工作流最需要的東西：判斷力、穩定性、速度、成本和任務控制。

如果你已經在使用 Claude Code，這次更新值得盡快試。尤其適合拿真實倉庫裡的長任務做對比，比如跨模組重構、測試修復、文件同步、複雜 bug 定位。

如果你只是一般聊天使用者，Opus 4.8 的變化可能不會像新一代模型發布那樣立刻震撼。但從產品方向看，它說明 Anthropic 仍在把 Claude 往「可靠執行複雜工作」的方向推。

原文連結：Introducing Claude Opus 4.8

CLIProxyAPI：把 Codex、Claude Code、Gemini CLI 統一封裝成 API

Sun, 24 May 2026 10:03:33 +0800

CLIProxyAPI 是一個很有「民間工程味」的專案：它不是再造一個大模型，也不是單純做 API 轉發，而是把一堆原本偏互動式、偏 CLI、偏 OAuth 登入的 AI 工具，重新包成統一 API 服務。

它支援的對象包括 Gemini CLI、OpenAI Codex、Claude Code、Amp CLI、AI Studio Build，以及上游 OpenAI 相容服務。換句話說，它想解決的問題是：

我手上有 CLI 工具、有訂閱帳號、有 OAuth 登入狀態，能不能像呼叫普通 API 一樣，把這些能力接到自己的客戶端、腳本、IDE 或內部服務裡？

CLIProxyAPI 給出的答案是：可以，中間加一層代理，把不同來源的 CLI 能力轉換成 OpenAI、Gemini、Claude、Codex 相容介面。

它真正解決的痛點

很多 AI 編程工具的能力本來很強，但預設使用方式並不適合自動化。

比如：

Gemini CLI 能登入帳號使用，但你的程式更習慣呼叫 HTTP API。
Claude Code 很適合互動式編碼，但接入其他客戶端時會遇到協議不一致。
Codex CLI 支援 OAuth 登入和 Responses 風格能力，但不是所有上層工具都知道怎麼和它說話。
一個團隊可能有多個帳號，需要輪詢、負載均衡、異常帳號剔除和配額觀察。
你想讓某些工具只認 OpenAI 格式，但後端實際可能是 Gemini、Claude 或 Codex。

CLIProxyAPI 的定位，就是做這些工具和客戶端之間的「協議適配層」。

它把複雜的一側藏在後面：OAuth、CLI 登入、多帳號、不同協議、不同 provider。前面則暴露相對熟悉的介面，比如 OpenAI Chat Completions、OpenAI Responses、Gemini、Claude Messages、Codex 相關端點。

能力概覽

從官方 README 和文件看，CLIProxyAPI 目前的核心能力包括：

為 CLI 模型提供 OpenAI、Gemini、Claude、Codex 相容 API 端點。
透過 OAuth 登入接入 OpenAI Codex 和 Claude Code。
支援串流、非串流回應，以及部分場景下的 WebSocket。
支援函式呼叫、工具呼叫和多模態輸入。
支援 Gemini、OpenAI、Claude 多帳號輪詢與負載均衡。
支援 Gemini AI Studio API Key。
支援 AI Studio Build、Gemini CLI、Claude Code、OpenAI Codex 的多帳號池。
可以透過設定接入 OpenAI 相容上游，比如 OpenRouter。
提供 Go SDK，方便把代理能力嵌入到自己的服務裡。

這類專案最有價值的地方，不是「多支援幾個模型名」，而是把帳號登入、協議轉換和請求路由這些瑣碎工作打包起來。

它適合誰用

CLIProxyAPI 更適合下面幾類人。

第一類是重度 AI 編程使用者。你已經在用 Codex、Claude Code、Gemini CLI，但想把它們接到 Cursor、Cline、RooCode、Amp、內部腳本或自建工作流裡。

第二類是有多帳號池的人。比如你有多個 Gemini、OpenAI、Claude 登入狀態，不想手工切換，希望自動輪詢、均衡使用、遇到異常帳號時能快速排查。

第三類是做團隊內部閘道的人。團隊不希望每個客戶端都分別適配 Gemini、Claude、Codex，而是想透過一個中間層統一暴露 API。

第四類是喜歡折騰協議的人。你可能關心 Responses、Chat Completions、Claude Messages、Gemini v1beta 這些介面如何互相轉換，也可能希望在同一套客戶端裡切換不同後端。

如果只是個人偶爾問幾句 AI，或者只用官方 App 聊天，那 CLIProxyAPI 的部署和維護成本就顯得重了。

和普通 API 中轉有什麼不同

普通 API 中轉服務一般是：

`1`	`客戶端 -> 中轉 API -> 上游模型 API`

CLIProxyAPI 的鏈路更像：

`1`	`客戶端 -> CLIProxyAPI -> CLI / OAuth 登入狀態 / 多帳號池 -> 模型服務`

區別在於，它處理的不只是 API Key 轉發，還包括 CLI 工具、OAuth 帳號、協議表面和模型別名。

比如 Codex 和 Claude Code 這類工具，本身就不是傳統意義上「拿一個 API Key 就能穩定呼叫」的模式。CLIProxyAPI 把這些登入狀態和呼叫邏輯包裝起來，讓外部客戶端像呼叫 API 一樣存取它們。

這也是它吸引人的地方，同時也是它複雜的地方。

使用時最容易誤解的地方

第一，不要以為統一 /v1/... 就能解決所有協議差異。

CLIProxyAPI 文件裡專門提醒過：當你需要某一類後端的請求和回應形態時，優先使用 provider-specific 路徑。例如 messages 風格用 /api/provider/{provider}/v1/messages，Gemini 模型路徑用 /api/provider/{provider}/v1beta/models/...，chat-completions 風格用 /api/provider/{provider}/v1/chat/completions。

統一入口方便，但不同協議的語義並不會憑空消失。工具呼叫、串流回傳、多模態輸入、系統訊息處理，都可能因為後端不同而有細節差異。

第二，模型名不等於唯一後端。

如果多個後端暴露了相同的客戶端可見模型名，僅靠路徑不一定能鎖定真正執行推理的那個後端。要嚴格固定後端，最好使用唯一 alias、前綴，或者避免讓多個後端暴露同名模型。

第三，多帳號輪詢不是無限額度。

輪詢只能更均勻地使用帳號池，不能繞過上游服務的真實限制。帳號異常、配額耗盡、風控、OAuth 失效，都需要單獨監控。

第四，它不是免維護魔法盒。

一旦你把它放進日常工作流，就要關心設定、日誌、上游帳號狀態、版本升級、客戶端相容性和安全邊界。

管理和監控怎麼辦

官方 README 提到，從 v6.10.0 開始，CLIProxyAPI 和 CPAMC 不再預置資料統計功能。如果需要使用量統計，可以配合獨立專案：

CPA Usage Keeper：同步 CLIProxyAPI 資料，存到 SQLite，並提供聚合 API 和儀表板。
CLIProxyAPI Usage Dashboard：本機優先的用量與配額看板，可展示帳號、模型、時間窗口和 Codex 配額餘量。
CPA-Manager：更完整的管理中心，面向請求監控、費用估算、帳號池巡檢、異常帳號定位和清理建議。

這說明 CLIProxyAPI 的核心更偏「代理和協議層」，而不是一站式商業管理後台。如果是團隊使用，最好一開始就把日誌、監控和帳號池管理考慮進去。

一個比較合理的使用姿勢

如果要試用，可以按這個順序來：

先用官方文件的 Quick Start 跑起來。
只接一個 provider，比如 Gemini CLI 或 Codex，確認基本請求能通。
再測試串流回應、工具呼叫、多模態輸入這些高風險能力。
確認客戶端實際使用的是哪個 endpoint，不要混用協議路徑。
最後再加入多帳號輪詢、管理面板和用量統計。

不要一上來就把 Gemini、Codex、Claude、OpenRouter、多帳號和所有客戶端全接進去。這樣出錯時很難判斷是認證問題、協議問題、模型名問題，還是上游帳號問題。

安全邊界也要想清楚

CLIProxyAPI 會接觸到帳號登入狀態、API Key、OAuth 相關憑據和請求內容。它如果只跑在自己機器上，風險相對可控；如果暴露到公網或團隊內網，就必須認真處理認證、存取控制、日誌脫敏和網路隔離。

尤其是管理端點，最好只允許本機或可信內網存取。不要為了省事直接把管理介面裸露出去。

總結

CLIProxyAPI 的價值在於，它把原本散落在多個 CLI、多個帳號、多個協議裡的 AI 能力，收攏成一個可編程的 API 層。

它適合重度 AI 編程使用者、多帳號使用者和團隊內部閘道場景；不太適合只想「開箱即用、完全無維護」的輕量使用者。

如果你正在折騰 Codex、Claude Code、Gemini CLI 這些工具，並且希望把它們接進自己的客戶端或自動化工作流裡，CLIProxyAPI 值得認真看一眼。但要把它當基礎設施來用，而不是當一次性小工具來用。

參考資料：

CodeGraph 是什麼？給 Claude Code、Codex 和 Cursor 加一張本地程式碼地圖

Sat, 23 May 2026 21:09:46 +0800

CodeGraph 是一個給 AI 編程工具使用的本地程式碼知識圖譜。它會提前給專案建立索引，把符號關係、呼叫圖、程式碼結構、路由關係等資訊整理成可查詢的圖，讓 Claude Code、Codex CLI、Cursor、OpenCode、Hermes Agent 這類工具不用每次都靠 grep、glob、Read 和子代理到處翻檔案。

它解決的是一個很實際的問題：AI Agent 看大型程式碼庫時，很多成本不是花在真正修改程式碼上，而是花在「找程式碼在哪裡」。如果每次都重新搜尋、讀取、篩選，token、時間和工具呼叫都會被消耗掉。CodeGraph 的思路是先把程式碼庫變成一張本地地圖，讓 Agent 先問地圖，再決定要不要讀具體檔案。

它主要解決什麼痛點

AI 編程工具在小專案裡通常還好，檔案少，搜尋快，讀一遍也不貴。但專案一大，常見問題就會出現：

Agent 為了理解一個模組，反覆呼叫 grep、find、ls、Read。
探索子代理讀了很多無關檔案，主任務上下文卻沒有變清楚。
問一個架構問題時，token 大量花在定位檔案上。
改一個函式前，不知道誰在呼叫它、它又呼叫了誰。
Web 專案裡，URL 路由和實際處理函式之間的關係不夠直觀。

CodeGraph 試圖把這些「先找路」的工作前置。專案索引建好後，Agent 可以直接查詢相關符號、呼叫方、被呼叫方、影響範圍和程式碼片段。

安裝方式

專案提供跨平台安裝腳本，不要求使用者自己準備 Node.js：

`1`	`curl -fsSL https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.sh \| sh`

Windows PowerShell 可以使用：

`1`	`irm https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.ps1 \| iex`

如果已經有 Node 環境，也可以直接用 npm：

`1`	`npx @colbymchenry/codegraph`

或者全域安裝：

`1`	`npm i -g @colbymchenry/codegraph`

安裝器會自動偵測並配置已安裝的 Agent，例如 Claude Code、Cursor、Codex CLI、opencode 和 Hermes Agent。它會寫入對應的 MCP server 配置和指令檔案，讓這些工具知道什麼時候呼叫 CodeGraph。

初始化專案

安裝完成後，需要在目標專案裡建立索引：

1
2

cd your-project
codegraph init -i

這個命令會產生專案級知識圖譜索引。README 中提到，只要專案裡存在 .codegraph/ 目錄，Agent 就可以自動使用 CodeGraph 工具。

如果不想繼續使用，也可以卸載全域配置：

`1`	`codegraph uninstall`

它會移除安裝器寫入的 MCP server 配置、指令和權限。專案中的 .codegraph/ 索引不會被自動刪除，如果要移除專案索引，需要使用 codegraph uninit。

為什麼它對 Agent 有用

Claude Code、Codex CLI、Cursor 這類工具在理解程式碼庫時，常常會先做探索：找檔案、讀入口、查引用、再追呼叫鏈。這個過程對人來說像「翻專案」，對模型來說就是一串工具呼叫和上下文消耗。

CodeGraph 把這一步變成索引查詢。Agent 可以先用 codegraph_context 找到相關入口、符號和片段，再用 codegraph_explore 或其他工具讀取必要內容。這樣做的好處是：

少讀無關檔案。
少呼叫搜尋工具。
更快找到真正相關的程式碼。
改動前更容易看清影響範圍。
大型倉庫裡的架構問題更容易回答。

專案 README 給出的基準測試顯示，在 7 個真實開源程式碼庫上，對比啟用 CodeGraph 和不啟用 CodeGraph，平均結果是成本更低、token 更少、速度更快、工具呼叫更少。具體數字會受專案規模、語言、問題類型和 Agent 使用方式影響，但方向很清楚：越大的倉庫，預索引的價值越明顯。

核心能力

1. 智慧上下文構建

一個工具呼叫可以返回入口點、相關符號和程式碼片段，減少 Agent 先派一堆探索任務再慢慢篩選的情況。對架構理解、模組定位、功能入口分析很有用。

2. 全文搜尋

CodeGraph 使用 FTS5 做全文搜尋，可以在整個程式碼庫裡快速按名稱和文字查找程式碼。這不是替代所有 grep 場景，而是讓 Agent 有一個更結構化的第一站。

3. 影響分析

在改函式、類別、方法或路由前，可以查詢 callers、callees 和影響半徑。對重構、修 bug、刪除舊程式碼尤其有用，因為最怕的就是只改了當前檔案，卻漏掉上游或下游呼叫。

4. 自動保持新鮮

README 中提到，CodeGraph 使用原生檔案系統事件，例如 FSEvents、inotify、ReadDirectoryChangesW，並帶有 debounce auto-sync。意思是索引會隨著本地程式碼變化自動更新，不需要每改一個檔案都手動重建。

5. 多語言支援

專案列出的支援範圍超過 19 種語言，包括 TypeScript、JavaScript、Python、Go、Rust、Java、C#、PHP、Ruby、C、C++、Swift、Kotlin、Dart、Lua、Luau、Svelte、Liquid、Pascal / Delphi 等。

這讓它更適合多語言倉庫和全棧專案，而不是只服務某一種語言。

6. Web 路由感知

CodeGraph 還會識別多種 Web 框架裡的路由檔案和路由宣告，把 URL pattern 和處理函式連接起來。README 中提到的框架包括 Django、Flask、FastAPI、Express、NestJS、Laravel、Rails、Spring、Gin、Axum、ASP.NET、Vapor、React Router、SvelteKit 等。

這點很實用。很多 Web 專案的真實入口不是某個明顯的 main 函式，而是路由、controller、handler、view 或 resolver。Agent 如果能先知道 URL 到處理函式的關係，理解業務流程會快很多。

本地優先的設計

CodeGraph 強調 100% local。它不需要 API key，不依賴外部服務，索引資料保存在本地 SQLite 資料庫裡。

對企業專案、私有倉庫或敏感程式碼來說，這個設計很重要。AI 工具接入程式碼庫時，大家最擔心的往往不是「能不能查到程式碼」，而是「程式碼結構和索引會不會被發出去」。CodeGraph 的定位是本地構建、本地查詢、本地服務 Agent。

當然，本地也意味著要考慮磁碟空間、索引時間、檔案監聽和專案規模。如果倉庫特別大，第一次初始化和後續同步仍然需要資源。

適合哪些場景

CodeGraph 更適合這些場景：

大型程式碼庫，經常需要問架構和呼叫鏈問題。
使用 Claude Code、Codex CLI、Cursor 等 Agent 做程式碼理解和修改。
希望減少 Agent 到處讀檔案、亂搜、反覆探索。
需要在改動前分析影響範圍。
Web 專案路由複雜，需要快速從 URL 找到處理函式。
團隊希望給 AI Agent 一個更穩定的本地專案索引。

如果只是幾十個檔案的小專案，普通搜尋已經夠快，CodeGraph 的優勢可能不明顯。它最有價值的地方，是中大型程式碼庫和經常讓 Agent 做探索的場景。

使用時要注意什麼

第一，CodeGraph 不是替代程式碼審查和測試的工具。它能幫助 Agent 更快找到相關程式碼，但不能保證 Agent 的修改一定正確。

第二，索引品質會影響使用效果。專案結構複雜、生成程式碼很多、語言混雜或 build 產物沒有排除時，索引可能會變得臃腫。使用前最好確認 .gitignore、專案目錄和索引範圍是否合理。

第三，MCP 配置和 Agent 指令很關鍵。README 裡也提醒，CodeGraph 只有在被正確查詢時才有幫助。如果 Agent 仍然繞開它去大量讀檔案，預索引就會變成額外開銷。

第四，雖然它是本地工具，也要注意權限。安裝器會寫入 Agent 配置和權限列表，團隊環境中最好統一審查這些配置。

小結

CodeGraph 的價值可以簡單理解為：給 AI Agent 一張本地程式碼地圖。它不是讓模型更聰明，而是讓模型少迷路。

當 Claude Code、Codex CLI、Cursor 這類工具面對大型倉庫時，最耗費上下文的往往是探索過程。CodeGraph 用預索引的符號關係、呼叫圖、路由圖和全文搜尋，把「找程式碼」這一步提前做好，讓 Agent 把更多預算花在理解和修改上。

如果你已經在真實專案裡使用 AI 編程工具，並且經常遇到「它讀了一堆檔案還是沒找到重點」的情況，CodeGraph 值得試一下。它代表了 AI 編程工具的一個重要方向：不只是換更強的模型，也要給模型更好的本地程式碼上下文。

參考資料：

GitHub 專案：https://github.com/colbymchenry/codegraph

Claude Code 也有插件市場了：能裝什麼、怎麼裝、要注意什麼

Sat, 23 May 2026 19:03:30 +0800

anthropics/claude-plugins-official 是 Anthropic 管理的 Claude Code 官方插件目錄。它不是一個普通程式碼庫，而是一個可被 Claude Code 插件系統直接使用的 marketplace，集中放置由 Anthropic 維護或篩選的 Claude Code 插件。

這個倉庫值得關注，是因為 Claude Code 正在從「一個 AI 編程命令列工具」變成「可擴展的開發環境」。插件可以把 Skills、Agents、Hooks、MCP servers、LSP servers、後台監控和預設設定打包起來，讓團隊或社群用統一方式分發。

這個倉庫是什麼

倉庫 README 對它的定位很直接：這是一個高品質 Claude Code 插件的 curated directory。

目錄主要分成兩塊：

/plugins：Anthropic 內部開發和維護的插件。
/external_plugins：來自合作夥伴和社群的第三方插件。

也就是說，它既包含官方能力，也包含經過收錄的外部生態入口。對普通使用者來說，最直接的意義是可以透過 Claude Code 的 /plugin 系統發現和安裝插件；對開發者來說，它提供了觀察 Claude Code 插件格式和生態方向的窗口。

如何安裝插件

README 給出的安裝方式很簡單。可以直接透過 Claude Code 的插件系統安裝：

`1`	`/plugin install {plugin-name}@claude-plugins-official`

也可以在 Claude Code 裡打開插件發現入口：

`1`	`/plugin > Discover`

這裡的關鍵點是 @claude-plugins-official。它代表官方插件目錄這個 marketplace。根據 Claude Code 文件，claude-plugins-official 是 Anthropic 維護的官方 marketplace，並且會在 Claude Code 安裝中預設可用。

插件長什麼樣

倉庫 README 給出了標準插件結構：

plugin-name/
├── .claude-plugin/
│   └── plugin.json
├── .mcp.json
├── commands/
├── agents/
├── skills/
└── README.md

其中 .claude-plugin/plugin.json 是插件元資料檔案，通常用來宣告插件名、描述、版本、作者等資訊。其他目錄則按需存在：

skills/：放 Claude 可自動呼叫的技能說明。
commands/：放 slash commands。
agents/：放自訂 agent 定義。
hooks/：放事件觸發邏輯。
.mcp.json：配置 MCP server。
.lsp.json：配置語言伺服器。
monitors/：配置後台監控。
settings.json：給插件附帶預設設定。

這說明 Claude Code 插件不是單一類型擴展，而是一種打包格式。它可以只是一個小命令，也可以是一整套面向某個技術棧的工作流。

官方目錄裡已經有哪些方向

從 /plugins 目錄看，官方維護插件覆蓋了不少開發場景，包括：

LSP 類插件：typescript-lsp、pyright-lsp、rust-analyzer-lsp、gopls-lsp、clangd-lsp、csharp-lsp、jdtls-lsp、kotlin-lsp、lua-lsp、php-lsp、ruby-lsp、swift-lsp。
編程工作流：code-review、feature-dev、code-modernization、code-simplifier、commit-commands、pr-review-toolkit。
Claude Code 配置和插件開發：claude-code-setup、claude-md-management、plugin-dev、skill-creator、mcp-server-dev。
輸出風格和專項能力：explanatory-output-style、learning-output-style、security-guidance、session-report、math-olympiad。

/external_plugins 裡則能看到更多第三方工具和服務方向，例如 github、gitlab、linear、asana、firebase、playwright、terraform、context7、serena、telegram、discord 等。

這組插件透露出一個趨勢：Claude Code 不只是想幫你改檔案，還想接入程式碼智能、專案管理、雲服務、測試、基礎設施和團隊協作工具。

為什麼插件系統重要

過去很多 Claude Code 自訂能力都可能散落在專案裡的 .claude/ 目錄中，比如 commands、agents、skills 或 hooks。這種方式適合個人或單一專案，但不方便跨專案複用，也不方便團隊統一分發和更新。

插件解決的是可複用和可分發問題：

同一套配置可以跨多個專案安裝。
命令和技能有命名空間，減少衝突。
插件可以透過 marketplace 發布和更新。
團隊可以把內部最佳實踐打包成標準插件。
社群可以圍繞某個框架、語言或服務維護專門擴展。

這和 VS Code 插件、JetBrains 插件、瀏覽器擴展的思路類似：當一個工具開始有穩定插件生態，它就不再只是單一產品，而是在形成平台。

對開發者有什麼用

如果你只是 Claude Code 使用者，這個倉庫最實用的地方是找插件。比如需要 TypeScript、Python、Rust 或 Go 的 LSP 能力，可以先看官方目錄裡是否已有對應插件；需要 PR review、commit、程式碼現代化等工作流，也可以從官方插件開始試。

如果你是插件開發者，這個倉庫更像樣板庫。你可以參考它的目錄組織、plugin.json 寫法、README 說明方式，以及 Anthropic 如何把 skills、agents、MCP、LSP 和 hooks 組合起來。

Claude Code 文件也明確建議：如果只是單專案自訂，可以先用 .claude/；如果需要分享給團隊、跨專案複用、版本化發布，或者進入 marketplace，就應該做成插件。

安全邊界不能忽略

倉庫 README 在開頭就提醒：安裝、更新或使用插件前必須信任該插件。原因很簡單，插件可能包含 MCP server、檔案、腳本或其他軟體。Anthropic 維護目錄，不等於能保證每個插件在你的本地環境中都按你預期執行。

實際使用時建議至少做幾件事：

安裝前看插件主頁和 README。
檢查是否包含 .mcp.json、hooks、可執行腳本或後台監控。
對需要存取帳號、程式碼倉庫、聊天工具、雲服務的插件格外謹慎。
在重要專案中啟用插件前，先在測試倉庫驗證。
團隊環境最好統一審核插件來源和版本。

AI 編程插件的權限往往比普通編輯器主題高得多。它可能能讀專案檔案、呼叫外部服務、啟動本地命令，甚至影響提交和部署流程，所以信任邊界要比「裝一個小工具」更嚴格。

和社群 marketplace 的關係

Claude Code 文件提到，Anthropic 維護兩個公開插件 marketplace：

claude-plugins-official：Anthropic 維護的 curated 插件集合。
claude-community：第三方提交後進入審查流程的社群插件目錄。

這兩者的定位不同。社群插件可以透過提交表單進入 review；官方目錄則由 Anthropic 自行決定是否收錄，沒有普通申請流程。換句話說，claude-plugins-official 更像官方精選目錄，claude-community 更像開放社群目錄。

小結

anthropics/claude-plugins-official 的意義不只是「多了一個 GitHub 倉庫」。它說明 Claude Code 的擴展機制正在平台化：Skills、Agents、Hooks、MCP、LSP、後台監控和預設設定都可以被打包、安裝、更新和分發。

對個人開發者來說，官方插件目錄能降低配置 Claude Code 的門檻。對團隊來說，它提供了把內部流程標準化的路徑。對插件開發者來說，它給出了 Anthropic 認可的插件結構和生態方向。

接下來值得關注的不是某一個插件本身，而是 Claude Code 插件生態會不會形成穩定分層：官方精選、社群插件、團隊私有 marketplace，以及圍繞主流語言、框架和 SaaS 服務的專門擴展。如果這條路線走通，Claude Code 會越來越像一個可編排的 AI 開發平台，而不只是一個命令列助手。

參考資料：

GitHub 專案：https://github.com/anthropics/claude-plugins-official
Claude Code 插件文件：https://code.claude.com/docs/en/plugins

Graphify 解決 Claude Code 最大局限：把程式碼庫變成 AI 可查詢知識圖譜

Thu, 21 May 2026 08:02:32 +0800

safishamsi/graphify 是一個面向 AI 編程助手的知識圖譜工具。它的目標很直接：把一個專案目錄裡的程式碼、文件、SQL schema、腳本、論文、圖片、影片和音訊，整理成可查詢的知識圖譜，讓 AI 助手不再只靠 grep、全文閱讀或臨時搜尋來理解專案。

專案地址：safishamsi/graphify

截至本文整理時，GitHub 頁面顯示專案約有 50.2k stars、5.4k forks，授權為 MIT。README 對它的描述是：在 AI 編程助手裡輸入 /graphify，它就會把整個專案映射成一個可以查詢的知識圖譜。

它解決的核心問題

AI 編程助手越來越強，但在真實程式碼庫裡仍然經常遇到幾個問題：

不知道關鍵模組之間怎麼連接。
讀了很多檔案，但沒形成整體架構地圖。
搜尋命中了文字，卻不知道上下游依賴。
程式碼、資料庫 schema、文件和基礎設施設定分散在不同地方。
多人協作時，每個人對專案結構的理解不一致。

Graphify 想做的是給專案生成一層「記憶層」。它把程式碼實體、文件概念、資料庫表、設定、設計說明和跨檔案關係連接起來，讓 AI 助手可以按圖譜查詢，而不是每次從零開始掃檔案。

最小使用方式

Graphify 的最小用法非常簡單。安裝後，在 AI 編程助手裡輸入：

`1`	`/graphify .`

在 PowerShell 裡要注意，前導 / 會被當成路徑分隔符，所以 Windows PowerShell 下應使用：

`1`	`graphify .`

執行後會生成 graphify-out/ 目錄，核心檔案包括：

graphify-out/
├── graph.html
├── GRAPH_REPORT.md
└── graph.json

這三個檔案分工不同：

graph.html：瀏覽器裡打開的互動式圖譜，可以點擊節點、過濾和搜尋。
GRAPH_REPORT.md：專案亮點、關鍵概念、意外連接和推薦問題。
graph.json：完整圖譜，後續可以直接查詢，不必重新讀所有檔案。

如果想生成更可讀的架構頁面和 Mermaid 呼叫流程圖，可以執行：

`1`	`graphify export callflow-html`

安裝和平台支援

Graphify 的 PyPI 包名是 graphifyy，注意是雙 y。README 特別提醒，PyPI 上其他 graphify* 包並不屬於該專案，但 CLI 命令仍然叫 graphify。

推薦安裝方式是：

`1`	`uv tool install graphifyy`

也可以使用：

1
2

pipx install graphifyy
pip install graphifyy

安裝後註冊到 AI 助手：

`1`	`graphify install`

專案支援的平台很多，包括 Claude Code、Codex、OpenCode、GitHub Copilot CLI、VS Code Copilot Chat、Aider、Cursor、Gemini CLI、Kimi Code、Kiro、Google Antigravity 等。不同平台可以用不同安裝命令，例如：

graphify install --platform codex
graphify install --platform gemini
graphify cursor install
graphify antigravity install

Codex 使用者還需要在 ~/.codex/config.toml 的 [features] 下加入：

`1`	`multi_agent = true`

README 也說明，Codex 使用 $graphify，不是 /graphify。

它能處理哪些檔案

Graphify 覆蓋的輸入類型很廣。

程式碼方面，它支援 31 種語言，包括 Python、TypeScript、JavaScript、Go、Rust、Java、C/C++、Ruby、C#、Kotlin、Scala、PHP、Swift、Lua、Zig、PowerShell、SQL、Shell、JSON 等。

文件方面，它支援：

.md
.mdx
.qmd
.html
.txt
.rst
.yaml
.yml

還可以透過可選依賴擴展更多類型：

pip install "graphifyy[pdf]"
pip install "graphifyy[office]"
pip install "graphifyy[video]"
pip install "graphifyy[mcp]"
pip install "graphifyy[neo4j]"
pip install "graphifyy[sql]"
pip install "graphifyy[all]"

其中，pdf 用於 PDF 提取，office 用於 .docx 和 .xlsx，video 用於影片和音訊轉寫，mcp 用於 MCP stdio server，neo4j 用於推送到 Neo4j，sql 用於 SQL schema 提取。

生成的報告有什麼價值

GRAPH_REPORT.md 不是普通摘要，它會把專案裡更值得 AI 助手關注的關係挑出來。

README 裡提到的報告內容包括：

God nodes：專案裡連接最多的核心概念。
Surprising connections：跨檔案、跨模組的意外連接。
The why：從註解、docstring、設計文件裡提取出的設計理由。
Suggested questions：圖譜特別適合回答的問題。
Confidence tags：關係會標記為 EXTRACTED、INFERRED 或 AMBIGUOUS。

這點很關鍵。普通搜尋只能告訴你「哪裡出現了這個詞」，而圖譜可以回答「這個概念和哪些模組、設定、表、文件有關」。對大型程式碼庫來說，這比單純全文檢索更接近架構理解。

常用命令

Graphify 的常見命令包括：

/graphify .
/graphify ./docs --update
/graphify . --cluster-only
/graphify . --no-viz
/graphify . --wiki
graphify export callflow-html
/graphify query "what connects auth to the database?"
/graphify path "UserService" "DatabasePool"
/graphify explain "RateLimiter"

也可以把論文或影片加入圖譜：

1
2

/graphify add https://arxiv.org/abs/1706.03762
/graphify add <youtube-url>

如果要做 PR 輔助分析，還可以使用：

graphify prs
graphify prs 42
graphify prs --triage
graphify prs --conflicts

這類命令適合程式碼評審場景：看 PR 影響了哪些圖譜社群、是否和其他 PR 有衝突風險、哪些 review queue 更值得優先處理。

和 MCP、Neo4j、CI 的關係

Graphify 不只是生成 HTML 圖。它也可以把圖譜暴露給 AI 助手反覆呼叫。

例如可以啟動 MCP server：

`1`	`python -m graphify.serve graphify-out/graph.json`

MCP server 提供的能力包括 query_graph、get_node、get_neighbors、shortest_path、list_prs、get_pr_impact、triage_prs 等。

它也支援 Neo4j 匯出或推送：

1
2

/graphify ./raw --neo4j
/graphify ./raw --neo4j-push bolt://localhost:7687

團隊協作上，README 建議可以提交 graphify-out/，讓團隊每個人拉取後都能共享同一份專案地圖。還可以執行：

`1`	`graphify hook install`

這樣每次 git commit 後自動重建圖譜，並設定 merge driver，避免 graph.json 在多人並行提交時留下衝突標記。

隱私和成本要怎麼看

Graphify 的 README 對隱私邊界寫得比較清楚。

程式碼檔案會透過 tree-sitter 在本地解析，不會發出 API 呼叫。影片和音訊可以透過 faster-whisper 本地轉寫。文件、PDF、圖片這類語義提取內容，則會透過你的 AI 助手模型 API 處理。

如果用 headless graphify extract，可能需要設定這些環境變數：

ANTHROPIC_API_KEY
GEMINI_API_KEY
GOOGLE_API_KEY
OPENAI_API_KEY
DEEPSEEK_API_KEY
MOONSHOT_API_KEY
OLLAMA_BASE_URL

本地 Ollama、AWS Bedrock、Claude Code CLI 等也可以作為 backend。README 還寫明專案沒有 telemetry、usage tracking 和 analytics。

實際使用時要注意：程式碼本地解析不等於所有內容都不出網。涉及文件、PDF、圖片或雲端模型時，仍然要看 backend、API key、企業合規和資料邊界。

適合哪些場景

Graphify 適合幾類使用者：

想讓 Claude Code、Codex、Cursor、Gemini CLI 更懂專案結構的開發者。
需要快速理解大型陌生程式碼庫的人。
需要把程式碼、SQL schema、文件、設定放在一起分析的團隊。
做架構審查、PR review、重構影響分析的人。
希望把專案知識暴露成 MCP 工具給 Agent 使用的人。
想為團隊保留「專案地圖」的技術負責人。

它不一定適合所有專案。小型腳本、一次性 demo、結構非常簡單的倉庫，用普通搜尋和 README 可能已經夠用。Graphify 的價值更容易出現在模組多、文件多、團隊協作多、AI 助手頻繁參與開發的大專案裡。

小結

Graphify 的意義在於，它把 AI 編程助手的上下文從「臨時讀取檔案」推進到「長期可查詢的專案知識圖譜」。

對開發者來說，它不是替代 IDE、搜尋或 LSP，而是給 AI 助手補一層結構化記憶：哪些模組重要、哪些概念連接緊密、哪些文件解釋了設計理由、某個 PR 會影響哪些社群。隨著 Codex、Claude Code、Gemini CLI、Antigravity 這類 Agent 工具繼續普及，這類「專案圖譜層」會越來越有用。

參考來源：

GitHub：safishamsi/graphify

Open Design 專案解析：把 Claude Code、Codex 變成 AI 設計工具

Mon, 18 May 2026 18:57:16 +0800

Open Design 是 nexu-io 推出的開源 AI 設計專案，定位是 local-first、open-source 的 Claude Design / Figma 替代方案。

它想解決的問題很明確：Claude Design 證明了大模型可以直接生成設計製品，但這類能力如果只存在於閉源、雲端、單一模型的產品裡，使用者就很難自託管、接入自己的 Agent、替換模型、沉澱私有設計系統，或者把產物放進本地工作流。

Open Design 的思路不是重新造一個大模型，而是把你電腦上已有的 coding-agent CLI 接進一個設計工作台。Claude Code、Codex、Cursor Agent、Gemini CLI、OpenCode、Qwen、Copilot CLI、Kimi、DeepSeek TUI 等工具，都可以成為它的「設計引擎」。

Open Design 是什麼

Open Design 可以理解為三個部分的組合：

一個 Web UI，用來對話、預覽、管理專案和匯出產物。
一個本地 daemon，負責調度 Agent、管理文件、保存專案和提供 API。
一組 Skills、Design Systems 和模板，用來約束 Agent 生成更像設計作品，而不是隨手拼出來的 AI 頁面。

使用者輸入需求後，Open Design 不只是把一句話丟給模型。它會先讓使用者補充設計簡報，選擇場景和方向，再把專案元資料、目前設計系統、Skill 文件、模板、檢查清單等上下文注入給 Agent。Agent 在真實文件夾裡讀寫文件，最後生成可在沙盒 iframe 中預覽的 artifact。

這讓它更接近「AI 設計工作流」，而不是單次網頁生成器。

為什麼它和普通 AI 生成網頁不一樣

很多 AI 工具都能生成一個 HTML 頁面，但 Open Design 的重點不是「讓模型寫頁面」，而是「讓模型按設計流程交付可預覽、可匯出、可迭代的製品」。

它強調幾個設計：

先問問題，再生成。新設計 brief 會先出現互動式 question form，用來鎖定受眾、語氣、品牌上下文、約束和視覺方向。
Skills 是文件，不是黑盒外掛。每個 Skill 由 SKILL.md、assets/、references/ 組成，可以被閱讀、替換和擴展。
Design Systems 是 Markdown，不是固定主題 JSON。顏色、字體、間距、元件、動效、品牌語氣和反模式都可以寫進 DESIGN.md。
Agent 在真實專案目錄裡工作。它能讀模板、寫文件、生成圖片、輸出 .pptx、.pdf、.zip 等文件。
產物在沙盒 iframe 中預覽，減少直接執行不受控程式碼的風險。

這套結構的目標，是讓 AI 更像一個有規範、有素材、有檢查清單的設計協作者。

它支援哪些 Agent

Open Design 的一個亮點是「把 Agent 當運行時」，而不是綁定某一家模型。

README 中列出的支援對象包括 Claude Code、Codex CLI、Devin for Terminal、Cursor Agent、Gemini CLI、OpenCode、Qwen Code、Qoder CLI、GitHub Copilot CLI、Hermes、Kimi、Pi、Kiro、Kilo、Mistral Vibe、DeepSeek TUI 等。它會從 PATH 中自動檢測這些 CLI，並允許使用者切換。

如果本地沒有合適的 CLI，也可以走 OpenAI-compatible 的 BYOK proxy，把自己的 baseUrl、apiKey 和模型填進去，讓 daemon 把串流輸出規範化成同一套聊天流。

這種設計的好處是：

不鎖定單一模型。
可以複用使用者已經安裝和配置好的 Agent。
本地文件讀寫由 daemon 管理，權限邊界更清楚。
對企業或重度使用者來說，更容易接入自己的模型和 API 供應商。

Skills 和 Design Systems 是它的核心資產

Open Design 內建了大量 Skills 和 Design Systems。README 中提到，專案內建的 Skills 覆蓋網頁原型、SaaS landing page、dashboard、mobile app、gamified app、社群輪播圖、雜誌海報、PPT、週報、財務報告、HR onboarding、invoice、kanban、OKR 等場景。

Design Systems 則用於給 Agent 提供品牌級視覺約束。倉庫介紹中列出了 Linear、Stripe、Vercel、Airbnb、Tesla、Notion、Apple、Anthropic、Cursor、Supabase、Figma、小紅書等設計系統來源。

這兩者的關係可以這樣理解：

Skill 決定「這次要交付什麼類型的作品」。
Design System 決定「作品應該長成什麼品牌風格」。

如果沒有這兩層約束，AI 很容易生成那種看起來熟悉但缺少判斷的通用頁面。有了 Skill 和 Design System，模型至少有了清楚的任務邊界、視覺參考和檢查規則。

它能生成什麼

Open Design 不是只做網頁原型。

按 README 的描述，它覆蓋 web、desktop、mobile prototypes、slides、images、videos、HyperFrames 等方向，並支援 HTML、PDF、PPTX、ZIP、Markdown 等匯出形式。媒體生成方面，它把圖片、影片、音訊也放在同一個設計循環裡，例如海報、頭像、資訊圖、地圖插畫、短影片和 HTML 轉 MP4 動效。

這意味著它的使用場景可以很寬：

創業團隊快速做 pitch deck。
產品團隊生成 landing page 或功能原型。
營運團隊做活動頁、社群圖、週報。
設計師用它做 moodboard、視覺方向和第一版 layout。
開發者把需求轉成可運行的前端 artifact。

它的價值不只是「生成一個頁面」，而是把多個內容形態放進同一套 Agent 工作流。

本地優先是什麼意思

Open Design 強調 local-first。它不是把所有東西都交給一個遠端 SaaS 後端，而是在本地跑 daemon 和專案工作區。

倉庫 README 裡描述的架構大致是：

前端是 Next.js / React / TypeScript。
本地 daemon 使用 Node、Express、SQLite 和 SSE。
專案、會話、訊息、tab、模板等資料保存在本地 SQLite 和 .od/projects/<id>/ 目錄。
Agent 透過 child_process.spawn 啟動，並在專案 artifact 文件夾中讀寫。
預覽透過沙盒 iframe 渲染。
匯出包括 HTML、PDF、PPTX、ZIP、Markdown。

這種結構更適合希望把設計產物留在本機、接入本地 Agent、控制 API key、維護私有工作區的使用者。

不過 local-first 不等於完全離線。實際生成仍然取決於你使用的 Agent 和模型。如果你用的是雲端模型 API，內容仍然會發往對應供應商。Open Design 更準確的定位，是把工作區、調度、文件和預覽放回本地，把模型層交給使用者自己選擇。

和 Claude Design / Figma 的關係

Open Design 在 README 中明確把自己稱為 Claude Design / Figma 的開源替代方向，但它並不是傳統意義上的 Figma 複刻。

Figma 是設計師手動編輯、協作和交付設計稿的專業工具；Open Design 更偏 Agent-native：使用者透過自然語言、表單、Skills 和設計系統驅動 Agent 產出可運行 artifact。

它更像是把幾個東西合在一起：

Claude Design 的 artifact-first 體驗。
Figma 的設計系統意識。
Claude Code / Codex 這類 Agent 的文件讀寫和執行能力。
本地 daemon 的專案管理和沙盒預覽。

所以它未必會替代專業設計師的全流程工具，但很適合做「從想法到可預覽原型」的快速通道。

適合誰使用

Open Design 更適合這些人：

已經在使用 Claude Code、Codex、Cursor、Gemini CLI 等 Agent 的開發者。
想把 AI 設計產物放到本地專案目錄裡管理的人。
需要快速生成網頁原型、PPT、海報、營運素材的創業團隊。
希望自定義 Skills、Design Systems、提示詞棧的進階使用者。
不想被單一模型或單一雲端產品鎖住的團隊。

不太適合這些人：

只想打開網頁、輸入一句話、立刻下載圖片的輕量使用者。
完全不想碰 Node、pnpm、daemon、CLI 和本地配置的人。
需要成熟多人協作、設計評審和向量編輯能力的專業 Figma 流程。

換句話說，Open Design 更像給 Agent 使用者和技術型設計團隊準備的工具，而不是面向所有人的輕量設計 SaaS。

需要注意的地方

Open Design 的 README 標註了 0.8.0-preview，並說明專案仍在快速迭代。這類專案的活力很強，但也意味著 API、資料目錄、桌面版遷移、Skills 結構和匯出流程可能還會變化。

使用前最好注意幾點：

不要把它當成穩定企業級設計平台。
先用測試專案體驗工作流，再匯入重要資料。
如果要遷移 .od/ 資料，先備份，確保 daemon 和桌面應用都已停止。
BYOK 時注意 API key、代理地址和本地私有網路存取風險。
生成的設計仍需要人工審查，尤其是品牌、版權、文案和視覺一致性。

開源專案最大的好處是可檢查、可改、可貢獻；代價是你需要接受一定的工程摩擦。

小結

Open Design 的看點，不只是「開源版 Claude Design」。它真正有意思的地方，是把 Agent CLI、Skills、Design Systems、本地 daemon 和沙盒預覽組織成一個設計工作流。

它把設計生成從單次 prompt 推向了更結構化的流程：先問問題，選方向，載入設計系統，讀取 Skill，寫入真實文件，預覽 artifact，再匯出結果。

如果你已經習慣用 Claude Code、Codex 或 Cursor 處理程式碼，那麼 Open Design 值得關注。它代表了一種新的產品形態：不是 AI 幫你畫一張圖，而是 AI 在本地專案空間裡，按設計系統和任務技能，生成一組可以繼續迭代的設計製品。

參考資料

nexu-io/open-design GitHub 倉庫

Claude Code 省 Token 指南：模型、MCP、CLAUDE.md 和 Skills 怎麼影響快取

Mon, 18 May 2026 18:30:24 +0800

Claude Code 長任務裡，Prompt Cache 命中率會直接影響成本和速度。很多人只知道「快取能省 Token」，但不清楚哪些操作會讓快取突然失效。

理解它並不難：每次請求都可以看成一條從左到右的上下文鏈條：

`1`	`tools -> system -> CLAUDE.md / skills -> messages`

越靠左的內容越穩定，快取收益越大；越靠左的內容一變，後面的快取也更容易跟著失效。反過來，越靠右的內容變化，影響範圍越小。

所以優化 Claude Code 的 Prompt Cache，不是靠玄學，而是靠一個原則：任務開始前把模型、MCP、Skills、CLAUDE.md 等基礎上下文準備好，任務中途盡量不要改。

Prompt Cache 快取的不是文字本身

Prompt Cache 不是簡單地把提示詞字串存起來。對 Transformer 模型來說，更關鍵的是前綴上下文經過注意力層計算後的 Key/Value 狀態，也就是常說的 KV cache。

這意味著兩個事實：

同一段上下文，只要前綴保持穩定，就可以在後續請求中複用一部分計算結果。
如果模型、工具定義、系統提示詞或前綴訊息發生變化，之前的快取就可能無法複用。

Anthropic 官方文件也把失效層級概括為 tools -> system -> messages。工具定義變化會影響整段快取，系統層變化會影響 system 和 messages，messages 層變化則主要影響訊息快取。

Claude Code 裡還會額外涉及 CLAUDE.md、Skills、MCP、外掛和子代理等上下文，所以實際使用時更容易踩到快取失效點。

快取殺手一：中途切換模型

切模型是影響最大的操作。

Prompt Cache 是按模型隔離的。Opus、Sonnet、Haiku 這類模型的結構和權重不同，同一段文字算出來的 KV cache 也不同。你在 Opus 裡跑了很長上下文，再切到 Sonnet，並不能讓 Sonnet 複用 Opus 的快取。

這會帶來一個反直覺結果：中途為了省錢切模型，可能反而讓前面已經累積的快取全部失效。原本可以按 cache read 價格讀取的上下文，需要重新寫入和計算。

更穩妥的做法是：

主對話盡量固定一個模型。
需要便宜模型處理支線任務時，用 subagent 隔離出去。
讓支線代理完成搜尋、探索、整理，再把結果摘要交回主對話。

這樣主對話的長上下文盡量不動，快取命中率更穩定。

快取殺手二：中途新增 MCP 或重載外掛

MCP 會向 Claude Code 提供工具。新增 MCP 伺服器後，工具列表會變化，而工具定義處在上下文鏈條最左側。

從 Prompt Cache 的角度看，工具列表一變，後面的 system 和 messages 都可能需要重新計算。尤其是 MCP 很多時，工具定義本身就可能占用大量 Token，快取失效的代價會很明顯。

不過有一個細節：Claude Code 通常在會話啟動時讀取 MCP 配置。你中途改了配置，當前 session 不一定立刻受影響。真正需要小心的是觸發重新載入的動作，例如重啟、恢復會話、重新載入外掛或讓工具列表重新組裝。

建議是：

開始長任務前，一次性裝好需要的 MCP。
不要做一半才發現缺工具，再安裝並重載。
對大型 MCP 工具集，優先考慮按需載入或減少預設啟用數量。
不常用的 MCP 不要長期掛在預設配置裡。

如果工具定義穩定，Prompt Cache 才有長期命中的基礎。

快取殺手三：中途修改 CLAUDE.md

CLAUDE.md 是 Claude Code 的專案記憶文件，適合放構建命令、測試命令、架構約定、程式碼風格和專案注意事項。

它對 Claude Code 很有用，但也會進入上下文。官方說明指出，CLAUDE.md 會在 session 開始時讀取，並作為使用者訊息提供給 Claude；它也會使用 Anthropic 的 Prompt Cache。首次請求會按完整輸入計費，後續請求如果在快取有效期內命中，就按更低的 cache read 成本處理。

問題在於：CLAUDE.md 是內容定址的。你一改文件內容，舊快取就對不上了。

所以不要在長任務中途頻繁改 CLAUDE.md。更好的方式是：

任務開始前先檢查 CLAUDE.md 是否夠用。
把穩定規則寫進去，把臨時指令放在目前對話裡。
如果只是一次性任務，不要為了臨時需求修改長期記憶文件。
如果必須改，最好在一個階段結束後再開始新 session。

CLAUDE.md 應該是穩定的專案說明，而不是每輪任務都改的便條。

快取殺手四：中途安裝或更新 Skills

Skills 也是上下文的一部分。安裝新 Skill、更新 Skill，或者讓 Skill 列表發生變化，都會讓注入到會話裡的上下文不同。

這類變化通常不會在目前 session 裡立刻完整生效，而是在重新載入、恢復會話或新開會話時體現出來。問題是，一旦重新組裝 messages，舊快取就可能命中不了。

建議和 MCP 類似：

開始任務前先確認需要哪些 Skills。
同一類任務盡量固定 Skill 集合。
不要在一個長任務中途邊做邊裝 Skill。
如果安裝了新 Skill，最好把它當成新階段的開始。

對經常做內容生產、程式碼審查、部署、翻譯的工作流，可以把常用 Skills 固定下來，讓上下文結構盡量穩定。

快取殺手五：空閒時間超過 TTL

Prompt Cache 不是永久保存。常見預設有效期是幾分鐘級別，Anthropic 文件和 Claude Code 相關說明裡都提到過 5 分鐘左右的快取窗口。超過 TTL 後，即使你發送完全一樣的請求，服務端也可能已經清掉快取。

這也是很多長任務使用者的體感來源：剛才還很省，去喝杯咖啡回來，再發下一步，Token 又突然漲上去了。

長任務尤其容易遇到這個問題。你可能要看 Claude Code 的輸出、檢查文件、跑測試、思考下一步，這些操作一不小心就超過 5 分鐘。

如果你的使用環境支援，可以在長任務前啟用 1 小時 Prompt Cache TTL：

`1`	`export ENABLE_PROMPT_CACHING_1H=1`

在 Windows PowerShell 裡可以寫成：

`1`	`$env:ENABLE_PROMPT_CACHING_1H="1"`

需要注意的是，1 小時快取寫入成本通常會高於 5 分鐘快取寫入成本。它不適合所有短任務，但對大型程式碼庫、長對話、複雜多步驟開發任務，往往比頻繁快取過期更划算。

怎麼安排一次更省 Token 的 Claude Code 長任務

比較穩的流程可以這樣做：

任務開始前選定模型，不要中途頻繁切換。
提前啟用需要的 MCP，不用的 MCP 先關掉。
檢查 CLAUDE.md，只保留穩定、關鍵、長期有效的規則。
提前準備好本次任務需要的 Skills。
如果是複雜任務，考慮啟用 1 小時 TTL。
把大任務拆成幾個階段，但每個階段內部盡量保持上下文結構穩定。
需要探索支線問題時，用 subagent 或單獨 session，不要污染主對話。

這套做法的目標不是絕對不讓快取失效，而是避免那些代價最高、最容易被忽略的失效。

一個簡單判斷標準

你可以用一句話判斷某個操作是否危險：

這個操作會不會改變模型、工具定義、系統上下文或會話開頭的固定訊息？

如果答案是會，那它大概率會影響 Prompt Cache。越靠近上下文鏈條左側，影響越大。

常見操作可以這樣理解：

切模型：高風險，模型快取隔離。
新增 MCP 或重載外掛：高風險，工具列表變化。
修改 CLAUDE.md：中高風險，專案記憶變化。
安裝 Skills：中高風險，注入上下文變化。
普通對話繼續追問：低風險，主要追加 messages。
空閒超過 TTL：高風險，服務端快取過期。

小結

Claude Code 的 Prompt Cache 優化，關鍵不是背參數，而是讓會話前綴穩定。

模型不要隨便切，MCP 和 Skills 不要邊做邊裝，CLAUDE.md 不要當臨時草稿頻繁改，複雜任務盡量延長 TTL。只要這些基礎動作穩定下來，Claude Code 在長任務裡的 Token 成本和回應速度都會更可控。

最實用的一句話是：開始前配好，開始後少動。

參考資料

Anthropic Founder’s Playbook 解讀：Claude 如何幫助創業團隊提速

Mon, 18 May 2026 18:02:58 +0800

Anthropic 在 Claude 官方部落格發布了面向創業者的 The Founder’s Playbook，核心問題很直接：一家 AI-native startup 如何更快從洞察走到產品、發布和規模化？

這份 playbook 並不是單純介紹 Claude 的功能清單，而是把創業過程拆成四個階段：Idea、MVP、Launch 和 Scale。它強調的不是「讓 AI 代替創辦人做判斷」，而是把市場調研、文案初稿、程式碼腳手架、營運流程、銷售材料等重複性工作先交給 Claude，讓創辦人把更多時間留給判斷、品味、取捨和信任建設。

這份 playbook 在講什麼

AI 創業公司面臨的壓力越來越像一場壓縮比賽：產品週期更短，競爭者更多，使用者對速度和品質的要求同時提高。過去需要多人團隊分工完成的事情，現在可以用 AI 先做出第一版，再由創辦團隊審閱、修正和推進。

Anthropic 給出的框架很清楚：不要一開始就試圖把公司完全「AI 化」，而是先找一個耗時、重複、低創造密度的流程，讓 Claude 生成初稿、腳本、調研結果或執行清單。創辦人負責定義目標、校準方向、判斷品質，並把可行結果接入真實業務。

第一階段：Idea

Idea 階段的重點不是「想一個酷點子」，而是驗證這個點子是否值得繼續投入。

Claude 適合在這個階段幫助創辦人做幾件事：整理市場地圖、歸納使用者痛點、比較競品定位、提出潛在切入點，並把模糊想法壓縮成更具體的價值主張。

但這一步最重要的仍然是人的判斷。AI 可以幫助你更快看到一批可能性，卻不能替你承擔「這個市場是否真的存在強需求」的責任。創辦人仍然需要和真實使用者交流，觀察他們願不願意改變現有工作流，甚至願不願意付費。

第二階段：MVP

MVP 階段是 Claude Code 最容易發揮作用的地方。

對小團隊來說，最稀缺的往往不是想法，而是把想法變成可試用產品的速度。Claude Code 可以參與生成腳手架、寫腳本、補元件、檢查邊界條件、產出技術方案說明，幫助團隊更快做出可驗證的版本。

這裡的關鍵不是讓 AI 一次性寫出完美產品，而是把「從 0 到第一版」的摩擦降下來。創辦人和工程師仍然需要審查架構、安全性、資料處理和使用者體驗，但他們不必把時間浪費在大量機械性的初稿工作上。

第三階段：Launch

Launch 階段考驗的是敘事、分發和回饋速度。

很多創業團隊會低估發布的複雜度：官網文案、產品演示、郵件、社群媒體內容、使用者訪談、銷售話術、投資人更新，每一項都需要清楚表達「為什麼現在需要這個產品」。

Claude 在這裡可以充當一個高頻協作對象：幫團隊生成不同版本的定位表達，改寫面向不同使用者群體的介紹，模擬使用者疑問，整理發布節奏，並把早期回饋轉成下一輪產品和市場動作。

第四階段：Scale

Scale 階段的主題從「做出來」轉向「可重複地成長」。

當公司開始有穩定使用者和收入，創辦團隊會被營運、銷售、客服、資料分析和內部協作拉扯。Claude Cowork 這類 agent 化能力適合處理更完整的任務：例如做市場研究、設計活動方案、整理募資策略、彙總成長指標，或者把一套營運流程拆成可以反覆執行的步驟。

這也是 AI-native 公司和傳統軟體公司的差異開始顯現的地方。真正的變化不只是「員工使用 AI 工具」，而是公司流程從一開始就圍繞 AI 協作來設計：哪些任務由人定義標準，哪些任務由 AI 先跑一遍，哪些結果必須進入審查，哪些流程可以沉澱成可複用模板。

Claude Code、Claude Cowork 和 Chat 各自適合做什麼

從這篇官方部落格的描述看，Anthropic 想讓創業者把 Claude 分成三類使用場景。

Claude Code 更偏工程協作，適合寫程式、生成腳本、分析邊界情況、產出元件規格和技術文件。它解決的是「把想法推進成可運行東西」的問題。

Claude Cowork 更像可委派的工作代理，適合市場研究、活動設計、募資策略、營運分析這類需要連續執行的任務。它解決的是「把一件較完整的業務工作先推進一輪」的問題。

Claude Chat 則更適合創辦人的判斷時刻：推敲 go-to-market 策略、壓力測試產品定位、比較路線圖優先級、打磨關鍵敘事。它不是執行機器，而是一個可以快速反覆討論的思考搭檔。

對創業團隊真正有用的地方

這份 playbook 的價值，不在於告訴創業者「AI 很重要」。這一點已經不新鮮了。

它更有用的地方，是把 AI 使用方式從零散工具呼叫，推進到公司建設方法論：每個階段都有不同的瓶頸，每個瓶頸都可以拆出適合 AI 參與的部分。

Idea 階段，AI 幫你擴大搜尋空間。MVP 階段，AI 幫你壓縮實作週期。Launch 階段，AI 幫你加快表達和分發實驗。Scale 階段，AI 幫你沉澱可重複流程。

這套邏輯對小團隊尤其重要。因為小團隊沒有足夠的人手覆蓋所有職能，但可以用 AI 先補上「第一版能力」，再把有限的人力投入到最需要判斷和關係建設的部分。

需要警惕的誤區

第一個誤區是把 AI 生成的內容直接當結論。市場調研、競品分析、使用者畫像、成長策略都必須回到真實資料和使用者回饋裡驗證。

第二個誤區是低估審查成本。AI 能顯著降低初稿成本，但程式碼品質、法律風險、品牌表達、商業承諾和安全問題仍然需要人負責。

第三個誤區是過早自動化。對還沒有跑通的流程，不應該急著交給 agent 自動執行。更穩妥的方式是先讓 AI 參與其中一小段流程，觀察輸出品質，再逐步擴大範圍。

小結

Anthropic 這篇 The Founder’s Playbook 傳遞的信號很明確：AI-native startup 的優勢，不只是「會用 AI 寫程式」，而是從公司第一天開始，就把 AI 作為產品、工程、市場、銷售和營運裡的協作層。

對創業者來說，最現實的起點不是搭建宏大的 AI 工作流，而是選出一個最耗時、最重複、最拖慢推進速度的任務，讓 Claude 先做第一版。真正的競爭力，來自人類創辦人對方向、品質和信任的把關，以及團隊能否把這種協作方式穩定地嵌入日常工作。

參考資料

The founder’s playbook for the age of AI

easy-vibe：給 Vibe Coding 初學者的一張學習地圖

Sat, 16 May 2026 22:44:43 +0800

easy-vibe 是 Datawhale 開源的 Vibe Coding 學習專案。它面向的不是已經熟練使用 AI 編程工具的開發者，而是剛開始接觸 Vibe Coding 的學生、產品經理、設計師、營運、獨立開發者和普通技術愛好者。

這個專案的價值不在於又列出一批 AI 工具，而是把「怎麼開始用 AI 做專案」拆成了更容易理解的學習路徑。對很多新手來說，真正困難的不是不知道有 Claude Code、Cursor、MCP 或 Agent，而是不知道應該先學什麼、怎麼練、什麼時候進入進階工具。

Vibe Coding 新手最缺的是路徑

Vibe Coding 這幾年很紅，但它對新手並不友好。

表面上看，只要會描述需求，就可以讓 AI 寫程式。實際上，只要任務稍微複雜一點，問題就會出現：需求說不清，模型改錯檔案，專案結構看不懂，錯誤不會處理，依賴裝不上，提示詞越寫越亂，最後只能回到「複製程式碼到聊天框」的狀態。

所以 Vibe Coding 入門不能只教「怎麼寫提示詞」。它至少要解決幾件事：

如何把想法拆成可執行任務；
如何讓 AI 理解專案結構；
如何看懂模型生成的程式碼；
如何處理錯誤和迭代；
如何使用終端和本地開發環境；
如何從網頁聊天過渡到真正的 AI 編程工具。

easy-vibe 的意義就在這裡：它試圖把這些內容整理成一條學習路線，而不是讓新手自己在工具、教程和術語裡迷路。

它不是單點教程，而是路線圖

從專案介紹看，easy-vibe 覆蓋了基礎教程、互動式練習、視覺化內容、RAG、終端工具、AI 編程工具，以及更進階的 Claude Code、MCP、Skills、Agent Teams 等主題。

這類組織方式比較適合初學者。因為 AI 編程不是一個單獨技能，而是一組能力的組合：

會描述需求；
會拆任務；
會讀專案；
會讓模型改程式碼；
會執行和驗證；
會根據錯誤繼續迭代；
會把常用流程沉澱成工具或技能。

如果只學某一個工具，很容易被工具介面限制住。換一個模型、換一個編輯器、換一個 CLI，就又不知道怎麼做。路線圖的好處是先建立工作方式，再把工具放到合適的位置。

對非程式設計師尤其有用

Vibe Coding 最大的吸引力，是讓非專業程式設計師也能做出原型。

產品經理可以把產品想法變成可互動 demo，設計師可以驗證互動邏輯，營運可以寫內部工具，學生可以快速做課程專案，創業者可以在早期驗證需求。這些人不一定要成為傳統意義上的全職工程師，但需要掌握一套「讓 AI 幫我把想法落地」的方法。

這也是 easy-vibe 適合中文社群的原因。很多中文使用者已經知道 AI 能寫程式，但還缺少系統入門材料：從開發環境、提示詞、專案結構、除錯方法到 Agent 工具使用，最好能用中文解釋清楚，並配合練習逐步推進。

對這類使用者來說，最重要的不是一上來學複雜框架，而是先跑通完整閉環：提出需求、生成專案、執行起來、發現問題、繼續修改、最終得到一個可用版本。

進階部分開始靠近真實 AI 開發工作流

easy-vibe 裡提到的 Claude Code、MCP、Skills、Agent Teams，已經不只是入門概念。

Claude Code 代表的是終端編程 Agent：模型可以進入本地專案，讀取檔案、修改程式碼、執行命令。MCP 解決的是工具和資料來源接入，讓模型不只停留在聊天框裡。Skills 則把可複用流程沉澱下來，例如固定的專案生成、文件整理、測試檢查或內容生產流程。Agent Teams 進一步把任務拆給多個智能體協作。

這些內容對新手來說可能有點遠，但它們值得提前了解。因為 Vibe Coding 的發展方向已經很清楚：從「讓 AI 寫一段程式碼」，走向「讓 AI 參與一個完整專案流程」。

如果學習路線只停留在提示詞層面，很快就會跟不上工具演進。反過來，如果一開始就把所有高階概念塞給新手，又會讓人無從下手。easy-vibe 的合理價值，是把這些內容放在一條逐步升級的路徑裡。

學習時要避免兩個誤區

第一個誤區，是以為 Vibe Coding 等於不會程式也能完全不管程式。

AI 可以生成很多內容，但使用者仍然需要判斷結果是否正確。至少要能看懂專案結構、知道怎麼執行、知道錯誤大概發生在哪裡。即使不寫複雜程式，也要具備基本的工程常識。

第二個誤區，是以為工具越高階越好。

新手不一定一開始就需要 Claude Code、MCP 或多 Agent。更好的順序是先用簡單專案建立回饋循環，再逐步引入終端、版本管理、測試、工具調用和自動化流程。工具要跟任務複雜度匹配，否則很容易變成「看起來很強，但不知道用來做什麼」。

適合怎麼用

如果你剛接觸 Vibe Coding，可以把 easy-vibe 當作學習清單來用。

先從基礎概念和簡單練習開始，不急著追所有工具。做一個小專案，例如個人首頁、資料看板、表單工具、自動化腳本或知識庫 demo。過程中重點觀察 AI 在哪些地方幫得上忙，哪些地方需要你自己確認。

等你能穩定完成小專案，再開始學習更複雜的內容：

用終端工具處理本地專案；
用 Git 管理每次修改；
用 RAG 接入自己的資料；
用 MCP 連接外部工具；
用 Skills 固化重複流程；
用 Agent Teams 拆分複雜任務。

這樣學出來的 Vibe Coding 才不只是會問 AI，而是能把 AI 放進自己的工作流程裡。

總結

easy-vibe 適合被看作 Vibe Coding 的中文入門地圖。它把零散的 AI 編程概念、工具和練習組織成一條路徑，讓新手更容易從「聽說 AI 能寫程式」走到「我能用 AI 做出一個專案」。

Vibe Coding 真正有價值的地方，不是讓人跳過所有學習，而是降低從想法到原型的門檻。你仍然需要理解需求、組織任務、驗證結果和控制風險，但很多重複、枯燥、容易卡住的步驟，可以交給 AI 協助完成。

如果你想系統入門 AI 編程，又不想一開始就陷入工具名詞和複雜工程配置，easy-vibe 是一個值得收藏的起點。

Claude Code + Ollama 本地部署教學：用 CC Switch 打造免費 AI 編程助手

Fri, 15 May 2026 23:27:50 +0800

最近 Claude Code 這類 AI 編程助手很受關注。它的吸引力不只是能聊天寫程式碼，而是可以讀取專案、修改檔案、執行命令、安裝依賴，甚至根據錯誤反覆修正，接近一個可操作的 Agent。

問題在於成本。專案一大，上下文變長，多輪 Agent 操作很容易消耗大量 API 額度。對於只是想試用、改小工具、寫腳本、處理本地私有專案的使用者來說，大家自然會想到：能不能保留 Claude Code 的操作體驗，但把模型換成本地執行？

這套方案的關鍵工具是 CC Switch。它可以讓 Claude Code 透過 OpenAI 相容 API 連接本地 Ollama 服務，從而把請求轉發到本地模型，而不是直接走官方 Claude API。

這套方案解決什麼問題

可以把整個流程理解為：

1
2
3

Claude Code 桌面端
+ CC Switch API 轉發層
+ Ollama 本地模型

Claude Code 仍然負責編程工作流和專案操作，CC Switch 負責模型供應商配置與 API 相容，Ollama 則負責在本機執行模型。

這並不代表本地模型會突然變成 Claude。它真正有價值的地方，是讓 Claude Code 的 Agent 工作流可以用在低成本、離線、私有化的本地場景。

基本準備

開始之前，需要先準備幾個元件：

安裝 Git。
安裝 Ollama。
拉取一個適合編程的本地模型。
安裝 CC Switch。
本機可以使用 Claude Code。

模型方面，可以先從偏程式碼能力的模型開始，例如 Qwen Coder、DeepSeek Coder，或其他具備較好工具呼叫和程式碼生成能力的模型。模型越大，效果可能越好，但記憶體與 GPU 壓力也會同步上升。

如果電腦記憶體有限，建議先用較小模型跑通流程，再逐步嘗試更大的模型。

CC Switch 關鍵配置

Ollama 啟動後，預設本地 API 位址通常是：

`1`	`http://127.0.0.1:11434/v1`

在 CC Switch 中選擇 OpenAI 相容的供應商類型，常見選項是：

`1`	`OpenAI Chat Completions`

然後把 base URL 指向 Ollama 的本地位址。

API key 欄位對本地 Ollama 來說通常不需要真實金鑰，但很多工具仍會要求環境變數或佔位值。可以使用：

`1`	`ANTHROPIC_API_KEY`

或其他本地配置可接受的佔位變數。

有一個配置項需要特別注意：

`1`	`"inferenceModels"="[\"haiku\",\"sonnet\",\"opus\"]"`

它表示把 Claude Code 預期的模型角色映射到本地供應商。實際使用時，需要把 haiku、sonnet、opus 對應到 Ollama 或 CC Switch 中可用的模型名稱。映射錯了，Claude Code 可能無法呼叫模型，或者一直回落到非預期配置。

Claude Code 強在哪裡

Claude Code 最有價值的地方不是單次補全，而是整套編程工作流：

讀取並理解專案結構；
根據任務定位相關檔案；
直接修改程式碼；
執行命令與測試；
觀察錯誤後繼續迭代；
在一個會話中完成多步任務。

這也是很多人想把 Claude Code 保留下來的原因。普通聊天介面可以生成程式碼片段，但不會自然地在倉庫裡操作。Claude Code 更像是一個能執行任務的開發助手。

Ollama 在這裡扮演什麼角色

Ollama 負責本地模型的執行與管理。它處理模型下載、載入和本地推理。

它的優點很明確：請求留在本機，反覆使用不會產生 API 帳單，在網路受限時也能使用。對私有程式碼來說，這也比把每一輪上下文都送到雲端模型更容易接受。

代價同樣明確。本地模型高度依賴硬體和模型品質。較小模型能處理簡單修改、解釋、腳本生成，但遇到大型跨檔案重構或細節很多的架構判斷時，能力會明顯下降。

體驗邊界在哪裡

這套方案不適合被理解成對 Claude 雲端強模型的完整替代。

你可能遇到這些問題：

長上下文理解能力較弱；
複雜任務中的工具呼叫不穩定；
純 CPU 機器推理速度較慢；
更容易幻覺出不存在的檔案路徑或 API；
多輪規劃可靠性不足；
大型專案重構成功率較低。

所以更合理的期待是：把它當成免費本地開發助手，而不是頂級雲端模型的完美替身。

多模態相容性還不穩定

有些使用者希望 Claude Code 處理截圖、UI 圖片、流程圖或其他多模態輸入。這一部分取決於本地模型和轉發層的支援情況。

如果選用的 Ollama 模型不支援視覺，或者 CC Switch 沒有正確轉換請求格式，多模態功能就可能失效。即使用了視覺模型，行為也可能和 Claude 官方 API 不完全一致。

因此目前更建議把這套方案用在文字與程式碼工作流上，多模態能力暫時按實驗功能看待。

適合誰嘗試

這套方案適合：

想低成本體驗 Claude Code 工作流的開發者；
經常寫腳本、小工具、自動化流程的使用者；
希望程式碼盡量留在本機的團隊；
想學習 AI 編程助手但不想持續消耗 API 的新手；
正在測試不同本地程式碼模型的人。

如果你高度依賴長上下文、大型 monorepo、嚴格程式碼審查品質，或複雜全專案重構，它可能還不夠穩。

使用建議

建議先從小任務開始。

例如：

解釋單個檔案；
重構一個小函式；
生成一段 shell 腳本；
修復一個簡單錯誤；
增加一個小功能；
為局部模組補單元測試。

每次修改後，最好自己跑測試，或至少檢查 diff。本地模型可以提高效率，但不應該盲目接受所有修改。

如果模型經常丟失上下文，就縮小任務範圍。不要讓它「重構整個專案」，而是改成「重構這個函式」或「為這個檔案增加校驗」。

小結

Claude Code + CC Switch + Ollama 是一個很有意思的組合。它把 Claude Code 的 Agent 式開發體驗保留下來，同時把模型推理搬到本地。

它最大的優勢是成本低、資料更私有、工作流順手；限制也很明顯，模型品質、硬體性能、長上下文和工具呼叫穩定性都會影響最終體驗。

如果你已經在用 Ollama，又想要一套更接近實戰的本地 AI 編程流程，這個方案值得試試。只是要記住：先從小任務開始，每次改動都要驗證，把本地模型當助手，而不是自動工程師。

Superpowers：把 Coding Agent 拉回工程流程的技能框架

Fri, 15 May 2026 08:53:17 +0800

obra/superpowers 是一個給 coding agent 使用的技能框架，也是一套軟體開發方法論。它的目標不是再寫一個萬能 prompt，而是把 agent 的工作流程固定下來：先澄清目標，再產出設計，再拆計畫，再按測試驅動開發推進，最後做 review 和收尾。

專案地址：https://github.com/obra/superpowers

寫作時，GitHub API 顯示這個倉庫已有超過 19 萬 star，授權為 MIT，最近仍在更新。README 對它的描述很直接：An agentic skills framework & software development methodology that works.

它想解決什麼問題

現在很多 AI 編程工具的問題，不是「不會寫程式碼」，而是太容易直接寫程式碼。

使用者剛說一個模糊需求，agent 就開始改檔案；改完看似完成，其實邊界沒對齊、測試沒補、架構沒想清楚。短任務可能沒事，複雜專案裡就會變成返工和技術債。

Superpowers 的思路是：讓 agent 在動手前先進入流程。

README 描述的核心路徑大致是：

發現使用者要做東西時，先追問目標。
從對話中整理規格，分段給使用者確認。
設計通過後，生成清楚的實施計畫。
使用者說 “go” 之後，再進入實作。
實作時強調 TDD、YAGNI、DRY，並透過 review 檢查結果。

這套流程不新，但放到 coding agent 裡很關鍵。AI 的執行速度越快，前置澄清和中途驗證越重要。

支援哪些工具

Superpowers 不是只面向一個 agent。README 列出的安裝入口包括 Claude Code、Codex CLI、Codex App、Factory Droid、Gemini CLI、OpenCode、Cursor 和 GitHub Copilot CLI。

這說明它更像跨 harness 的工作流層，而不是綁定某一家模型或某一個命令列工具。

基礎工作流

第一步是 brainstorming。它會在寫程式碼前觸發，透過問題把粗糙想法整理成可執行設計，並分段確認。

第二步是 using-git-worktrees。設計確認後建立隔離工作區和新分支，先確認安裝和測試基線乾淨。

第三步是 writing-plans。把設計拆成短小任務，每個任務有明確檔案路徑、程式碼範圍和驗證步驟。

第四步是實作。可以用 subagent-driven-development 派發子任務，也可以用 executing-plans 分批執行。重點是每個任務都能檢查、review、繼續推進。

第五步是 test-driven-development。它強調真正的 RED-GREEN-REFACTOR：先寫失敗測試，確認失敗，再寫最小實作，確認通過，然後重構。

第六步是 requesting-code-review。任務之間做 review，Critical 問題會阻塞繼續推進。

最後是 finishing-a-development-branch。任務結束後驗證測試，給出合併、發 PR、保留或丟棄 worktree 的選擇。

Skills Library 裡有什麼

測試類主要是 test-driven-development。

除錯類包括 systematic-debugging 和 verification-before-completion，要求先復現、最小化、提出假設、驗證，再修復；也要求沒有驗證前不要宣布完成。

協作類包括：

brainstorming
writing-plans
executing-plans
dispatching-parallel-agents
requesting-code-review
receiving-code-review
using-git-worktrees
finishing-a-development-branch
subagent-driven-development

元技能包括 writing-skills 和 using-superpowers。這些技能組合起來，像是給 agent 裝上一套工程習慣。

和普通 prompt 最大的區別

普通 prompt 往往把規則堆在一段 system prompt 裡：不要亂改、先思考、要測試、要簡潔。規則越堆越多，複雜任務裡模型越容易選擇性遺忘。

Superpowers 更像把規則拆成可觸發的流程模組。不同任務階段使用不同技能，每個技能只負責一段工作。這讓規則更短、目標更集中，也讓複雜流程能被檢查。

它最值得參考的地方是：不要只追求更聰明的模型，還要給模型一套可重複的工作方式。

適合誰用

Superpowers 更適合已經在真實專案裡使用 coding agent 的開發者，尤其是任務不只單檔修改、希望 agent 先設計再實作、需要 TDD 或驗證、常常並行多個分支、想把團隊流程寫成可重用技能的場景。

如果只是改一行設定，它可能偏重。但一旦任務涉及多檔案、多階段、多輪確認，流程約束就會變得有價值。

使用時要注意什麼

不要把它理解成自動駕駛。Superpowers 能讓 agent 更有流程感，但需求邊界、設計取捨和最終驗收仍然需要人負責。

TDD 和 review 會增加前期成本。小任務可能變慢，但複雜任務通常能減少返工。

子代理並行不是越多越好。它適合邊界清楚、寫入範圍不重疊的任務；如果需求還沒想清楚，並行只會放大混亂。

團隊也要維護自己的技能品質。過時流程、模糊指令和互相衝突的規則，都會拖累 agent。

小結

Superpowers 的價值，不在於某個單獨技能多神奇，而在於它把 coding agent 從「接到需求就寫程式碼」拉回軟體工程流程。

AI 編程真正缺的往往不是生成速度，而是澄清、計畫、驗證、review 和收尾。模型越強，這些流程越不能省。

如果你已經在用 Codex、Claude Code、Cursor 或 Gemini CLI 做真實專案，Superpowers 值得看一眼。即使不直接安裝，它的技能拆分方式也很適合拿來改造自己的 agent 工作流。

拒絕 Vibe Coding：Matt Pocock 的 skills 倉庫給 AI 編程補上工程約束

Fri, 15 May 2026 08:46:23 +0800

AI 寫程式碼越快，專案失控也可能越快。真正的問題不是模型會不會生成函式，而是它是否理解需求、是否遵守團隊語言、是否能在既有架構裡小步推進。

Matt Pocock 開源的 mattpocock/skills 倉庫，給了一個和 vibe coding 相反的方向：不要讓 AI 接管整個開發流程，而是把 AI 放進成熟的軟體工程約束裡。

專案地址：https://github.com/mattpocock/skills

這套方法的重點不是某個神奇 prompt，而是一組可以組合的 agent skills。它們把需求澄清、領域建模、測試驅動、問題診斷、架構審查這些工程實踐，重新包裝成適合 AI 編程工具調用的工作流。

先解決對齊失敗

AI 編程最常見的失敗，是你以為它懂了，其實它只是順著你的模糊描述開始猜。

grill-me 的思路是反過來：寫程式碼之前，先讓 AI 變成會追問的審稿人。它不會立刻開始實作，而是持續追問計畫裡的分支、邊界和未決問題。

例如你說「做一個登入頁」，它應該先問：

忘記密碼怎麼處理？
是否支援第三方登入？
登入失敗時要顯示什麼錯誤？
帳號鎖定、驗證碼、風控是否在本期範圍內？
成功後跳轉到哪裡？

這一步看起來慢，但它減少的是後面返工的時間。AI 生成程式碼的成本越低，需求沒想清楚帶來的浪費就越大。

把領域語言寫進上下文

第二個問題是 AI 的通用詞彙病。它不了解團隊內部的業務叫法，只能用常見詞來猜，於是變數名、函式名、文件描述都開始漂移。

grill-with-docs 不只是追問需求，還會結合專案裡的 CONTEXT.md、ADR 或領域文件，檢查使用者表達是否和既有術語衝突。確認後的術語、邊界和決策，可以繼續沉澱回上下文文件。

這和領域驅動設計裡的「統一語言」很接近。假設團隊把 user 稱為 customer，把 order 稱為 transaction，AI 在寫程式碼時也應該繼承這些叫法。

上下文文件的價值不在於堆資料，而在於讓 AI 少猜一點。

用 TDD 限制生成速度

AI 的危險之處在於它太快了。過去寫出一大段壞程式碼需要時間，現在幾秒鐘就能生成幾百行。速度本身不是問題，缺少回饋循環才是問題。

tdd skill 把經典的紅綠重構流程放回 AI 編程裡：

先為一個行為寫失敗測試。
再實作剛好讓測試通過的程式碼。
然後重構。
按垂直切片繼續推進。

重點是「一次一個行為」，而不是讓 AI 一口氣寫完所有測試和所有實作。AI 負責執行，人類負責確認方向和邊界。

用診斷循環處理複雜問題

遇到 bug 時，很多 AI 會直接猜答案，然後連續改幾輪，把問題越修越亂。

diagnose 的價值在於要求 AI 先建立回饋循環：

重現問題
最小化場景
提出假設
增加觀測或日誌
修復
補回歸測試

這套流程不新，但在 AI 編程裡尤其重要。AI 很擅長快速嘗試，但不一定擅長判斷哪次嘗試真正接近根因。診斷流程相當於給它加了一條軌道。

定期審查架構

單次任務跑通，不代表程式碼庫變好了。AI 反覆提交小改動後，最容易出現模組邊界模糊、介面越來越複雜、測試越來越難寫。

improve-codebase-architecture 這類 skill 的意義，是讓 AI 定期跳出當前任務，從更高層看程式碼庫：

哪些模組職責開始混在一起？
哪些介面太複雜？
哪些路徑難以測試？
哪些命名和領域語言不一致？
哪些重複邏輯應該收斂？

這不是讓 AI 自動大重構，而是讓它先給出結構化觀察和改進方向。真正要不要改、改到什麼程度，仍然需要開發者判斷。

真正該限制的是自由度

這套方法論的核心可以壓縮成一句話：AI 編程不是放任模型自由發揮，而是給它清楚的目標、上下文、測試和停止條件。

人類更適合負責問題定義、架構邊界、業務取捨和驗收標準；AI 更適合負責程式碼生成、測試補全、重複修改和局部重構。

所以，軟體工程基礎沒有因為 AI 變強而過時。需求澄清、領域語言、TDD、診斷、架構審查這些能力，在 AI 時代反而更關鍵。

會寫程式碼的人會越來越多。真正拉開差距的，是誰能把 AI 放進可維護、可驗證、可長期演進的工程體系裡。

cc-haha 是什麼？一個把 Claude Code 做成桌面工作台的專案

Thu, 14 May 2026 22:38:04 +0800

cc-haha 是一個圍繞 Claude Code 工作流改造出來的專案。它的完整倉庫名是 NanmiCoder/cc-haha，專案頁面寫得很直接：它基於 2026-03-31 從 Anthropic npm registry 洩露的 Claude Code 原始碼修復而來，現在主要形態是一個桌面端 Claude Code 工作台。

專案地址：https://github.com/NanmiCoder/cc-haha

這句話裡有兩個重點。

第一，它不是 Anthropic 官方 Claude Code。專案 README 也明確寫了原始碼版權歸 Anthropic 所有，僅供學習和研究用途。

第二，它現在的重點已經不只是「本地跑一個 Claude Code CLI」。從 README 和最新 release 看，cc-haha 更像一個把 Claude Code 的會話、專案、權限、Diff、Computer Use、遠端訪問和模型提供商配置集中起來的桌面應用。

它想解決什麼問題

Claude Code 原本是偏終端的工具。會話、命令執行、權限確認、檔案修改、上下文切換都在終端裡完成。對熟悉 CLI 的人來說沒問題，但長期使用時會遇到幾個不方便的地方：

多個專案和多個會話不好同時管理。
AI 改了哪些檔案，需要自己切到 Git 或編輯器裡看。
權限審批、命令執行、檔案 Diff 分散在不同介面。
想在手機或其他裝置上遠端看目前會話，需要額外方案。
想接入非 Anthropic 模型，需要自己處理協議相容。

cc-haha 的方向就是把這些東西做成一個圖形化工作台。它並不是只給 Claude Code 換皮，而是把「會話管理」和「本地開發流程控制」放到了桌面端裡。

桌面端工作台：從終端變成控制台

根據 README，cc-haha 桌面端把這些能力集中到 macOS / Windows App 裡：

多會話工作台：用標籤頁、專案切換、終端入口和歷史記錄管理不同任務。
分支 / Worktree 啟動：新會話可以選擇倉庫分支，也可以選擇使用目前工作樹或隔離 Worktree。
右側程式碼改動面板：聊天時直接查看修改過的檔案、增刪行和工作區狀態。
程式碼修改視覺化：查看 AI 對檔案的編輯、Diff 和執行過程。
權限與確認流：把危險命令、工具呼叫和 AI 反問集中到桌面端審批。
多模型提供商：支援 Anthropic 相容 API、第三方模型、WebSearch fallback 和本地配置。
H5 遠端訪問：用一次性 token 在手機或其他裝置上接入目前桌面會話。
IM 接入：透過 Telegram、飛書、微信、釘釘遠端對話、切換專案和審批權限。
定時任務與 token 用量統計：在桌面端建立計畫任務，並查看本機 token 使用趨勢。

這類功能說明它更接近「AI 編程工作台」，而不是單純的命令列替代品。它想把 AI 寫程式時最常見的幾個介面放到同一個地方：聊天、檔案改動、權限、專案、遠端入口、模型配置。

安裝和啟動方式

普通使用者更適合從 Releases 下載桌面端安裝包。

專案 README 給出的桌面端安裝流程是：

前往 GitHub Releases 下載 macOS 或 Windows 安裝包。
首次啟動後，在桌面端設定裡配置模型提供商、API Key 和預設模型。
如果 macOS 提示應用無法打開，按安裝指南處理 Gatekeeper 權限。

最新 release 頁面顯示，v0.2.6 發布於 2026-05-13。這個版本主要圍繞 H5 手機訪問安全恢復、桌面會話管理、檔案提及搜尋和桌面體驗細節。

如果想從原始碼啟動 CLI，README 給出的命令是：

1
2
3

bun install
cp .env.example .env
./bin/claude-haha

這個路徑更適合想調試底層 CLI、服務端或自行開發的人。普通使用還是桌面端更直接。

v0.2.6 更新了什麼

v0.2.6 的重點是把 H5/LAN 訪問從臨時放行收回到顯式開啟和 token 配對模型。

幾個值得注意的變化：

H5/LAN 訪問需要本地顯式開啟。
QR 連結會攜帶一次性顯示的 token。
遠端 API、proxy 和 WebSocket 不再裸露。
Settings 新增獨立 H5 Access 頁面。
桌面側邊欄增加批量管理模式，支援多選和刪除會話。
桌面檔案提及搜尋改為 git-first，遵守 ignore 規則，減少 node_modules 和建置產物噪聲。
新增純白主題，修復長 URL 撐破聊天布局、多 tab 草稿串台等問題。

這說明專案已經不只是「能跑」，而是在補桌面產品需要的安全邊界和日常體驗。

尤其是 H5 訪問這一塊，作者在 release 裡明確提醒：H5 是給個人或可信團隊使用的瀏覽器訪問入口，不是公開多租戶登入系統。實際使用時，不應該把它當成公網開放的 SaaS 登入後台。

Computer Use：讓 Agent 操作桌面

cc-haha 另一個重要賣點是 Computer Use。

專案文件說明，這個功能基於 Claude Code 洩露原始碼中的 Computer Use 內部實作改造而來。官方實作依賴 Anthropic 內部私有原生模組，例如 @ant/computer-use-swift 和 @ant/computer-use-input，無法公開取得。cc-haha 用 Python bridge 替換底層操作層，透過 pyautogui、mss、pyobjc 等公開函式庫實作系統互動。

Computer Use 支援的操作包括：

截圖：screenshot、zoom
滑鼠：點擊、拖曳、移動、滾動、讀取游標位置
鍵盤：輸入文字、按鍵、按住按鍵
應用：打開應用、切換顯示器
權限：請求應用授權、列出已授權應用
剪貼簿：讀取和寫入剪貼簿
其他：等待、批量操作

它的工作方式是一個「截圖 - 分析 - 操作」的閉環：

模型收到使用者請求。
呼叫 screenshot 取得螢幕畫面。
模型根據視覺能力識別按鈕、輸入框和座標。
呼叫點擊、輸入或應用操作工具。
再次截圖確認結果，再繼續下一步。

從文件看，完整支援的平台主要是 macOS，包括 Apple Silicon 和 Intel。Windows / Linux 在理論上可行，但涉及 pyobjc 的應用管理部分需要替換為對應平台方案，目前並不是完整適配狀態。

執行要求包括：

Bun >= 1.1.0
Python >= 3.8
macOS Accessibility 輔助功能權限
macOS Screen Recording 螢幕錄製權限

這類功能很強，但也意味著權限風險更高。讓 AI 操作桌面應用時，最好只授權明確需要的應用，不要在無關視窗裡打開敏感內容。

多模型接入：透過 Anthropic 協議相容層

cc-haha 的通信基礎仍然是 Anthropic Messages API 協議。專案文件給出的推薦方案是用 LiteLLM 做協議轉換代理。

基本結構是：

`1`	`claude-code-haha ──Anthropic协议──▶ LiteLLM Proxy ──OpenAI协议──▶ 目标模型 API`

也就是說，cc-haha 發出 Anthropic Messages API 請求，LiteLLM 把它轉換成 OpenAI Chat Completions 等格式，再轉發給 OpenAI、DeepSeek、Ollama 或其他模型服務。

文件給出的 LiteLLM 安裝方式是：

`1`	`pip install 'litellm[proxy]'`

然後可以在 litellm_config.yaml 裡配置 OpenAI、DeepSeek、Ollama 等模型。啟動代理後，在 .env 或 ~/.claude/settings.json 裡設定：

ANTHROPIC_AUTH_TOKEN=sk-anything
ANTHROPIC_BASE_URL=http://localhost:4000
ANTHROPIC_MODEL=gpt-4o
ANTHROPIC_DEFAULT_SONNET_MODEL=gpt-4o
ANTHROPIC_DEFAULT_HAIKU_MODEL=gpt-4o
ANTHROPIC_DEFAULT_OPUS_MODEL=gpt-4o
API_TIMEOUT_MS=3000000
DISABLE_TELEMETRY=1
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1

這裡有幾個實際注意點：

drop_params: true 很重要，因為 Anthropic 的 thinking、cache_control 等參數在 OpenAI API 中不存在。
Extended Thinking 屬於 Anthropic 專有能力，使用第三方模型時不可用。
Prompt Caching 也不會按 Anthropic 原生方式生效。
工具呼叫會經過 Anthropic tool_use 到 OpenAI function calling 的轉換，複雜工具呼叫可能存在相容性問題。
本地 Ollama 小模型未必能穩定處理這套工具呼叫流程。

所以多模型接入能跑，不等於所有模型體驗一樣。cc-haha 對模型的工具呼叫、程式碼理解和長上下文能力要求仍然不低。

適合什麼人

cc-haha 更適合這幾類使用者：

已經熟悉 Claude Code，但想要桌面端會話管理的人。
經常同時處理多個倉庫、分支和 AI 會話的人。
希望在右側直接看 AI 檔案改動、Diff 和工作區狀態的人。
想嘗試 Computer Use，讓 Agent 操作桌面應用的人。
想用 Anthropic 協議接入 OpenAI、DeepSeek、Ollama 或其他模型的人。
需要手機或 IM 遠端查看會話、審批權限的人。

不太適合：

只想穩定使用官方 Claude Code 的使用者。
不能接受洩露原始碼背景和版權不確定性的人。
不願意給本地工具較高系統權限的人。
需要企業合規、審計和官方支援的人。
不熟悉 API key、代理、模型相容和本地服務配置的人。

風險和邊界

這篇文章不能只講功能，也必須講風險。

cc-haha 的來源決定了它不是一個普通的社群重寫專案。README 明確寫到它基於洩露的 Claude Code 原始碼，且原始碼版權歸 Anthropic 所有。這會帶來版權、合規和長期維護上的不確定性。

另外，Computer Use、H5 遠端訪問、IM 接入和本地權限審批都屬於高權限能力。它們越方便，越需要清楚邊界：

不要在不可信網路下開放 H5 訪問。
不要把 token 當作長期公開登入憑證。
不要給 Agent 操作不相關的敏感應用。
不要在生產環境或公司合規環境裡隨意接入。
不要把第三方模型代理和 API key 配置暴露到公開倉庫。

如果只是學習 AI 編程工具架構、桌面端工作流和 Computer Use 實作，它很有參考價值。如果要放進長期生產工作流，就要先評估法律、權限、安全和維護風險。

總結

cc-haha 最值得關注的地方，不是「它能不能復刻 Claude Code」，而是它把 Claude Code 類型的 AI 編程工具推向了桌面工作台形態。

會話、專案、Worktree、Diff、權限、遠端訪問、Computer Use、多模型提供商、定時任務和 token 用量統計都被放進同一個桌面體驗裡。這說明 AI 編程工具的下一步，不只是模型更強，也包括工作流介面更完整。

不過它的邊界也很清楚：這不是 Anthropic 官方產品，來源存在敏感背景，高權限能力需要謹慎使用。更合適的態度是把它當成一個觀察 AI 編程工具演化方向的專案，而不是無腦替代官方 Claude Code。

參考資料

GitHub 倉庫：https://github.com/NanmiCoder/cc-haha
最新 Release：https://github.com/NanmiCoder/cc-haha/releases/tag/v0.2.6
Computer Use 文件：https://github.com/NanmiCoder/cc-haha/blob/main/docs/computer-use.md
第三方模型文件：https://github.com/NanmiCoder/cc-haha/blob/main/docs/guide/third-party-models.md

Codex /goal vs Claude Code /goal：讓長任務自動跑到完成

Thu, 14 May 2026 22:25:31 +0800

/goal 正在變成 AI 編程工具裡的一個重要命令。

它解決的不是「讓模型多寫幾行程式碼」，而是另一個更實際的問題：當任務有明確完成條件時，能不能讓 Agent 持續推進，直到條件滿足，而不是每完成一輪就停下來等使用者繼續催。

Codex CLI 已經在官方文件裡加入了實驗性的 /goal。Claude Code 也上線了自己的 /goal 文件，而且把它描述成一種可以跨多輪持續工作的自動化能力。兩者名字一樣，但產品取向並不完全一樣。

`/goal` 到底解決什麼問題

普通 AI 編程對話通常是「一問一答」：

使用者提出任務。
Agent 分析、改程式碼、跑測試。
Agent 回報結果。
使用者再決定下一步。

這個流程適合短任務，但遇到遷移、重構、測試修復、issue backlog 清理時，就會變得很碎。Agent 可能每次只推進一小段，然後停下來等你輸入「繼續」。

/goal 的思路是把任務從「下一步做什麼」改成「最終什麼狀態算完成」。例如：

`1`	`/goal 完成登录模块迁移，所有 auth 测试通过，lint 无报错`

這類目標天然適合長任務，因為它有清楚的終點：測試通過、建置成功、檔案拆分完成、佇列清空、驗收條件滿足。

Codex 的 `/goal`：實驗功能，綁定目前執行緒

OpenAI 的 Codex CLI 文件把 /goal 標為實驗功能。它不是預設穩定能力，需要先開啟 features.goals。

開啟方式有兩種：

`1`	`/experimental`

或者在 config.toml 裡加入：

1
2

[features]
goals = true

啟用後，可以這樣使用：

`1`	`/goal Finish the migration and keep tests green`

常用命令包括：

/goal
/goal pause
/goal resume
/goal clear

按照 OpenAI 文件的說法，Codex 會把 goal 附著在目前 active thread 上，在更大的任務執行過程中持續追蹤這個目標。

這裡要注意一個細節：官方文件對 Codex /goal 的措辭比較克制。它強調「給長任務設定實驗性目標」「把目標附著到目前執行緒」，但沒有像 Claude Code 文件那樣展開說明每一輪結束後由獨立 evaluator 自動判斷並繼續下一輪。所以現在使用 Codex /goal 時，最好仍把它看作實驗中的長任務目標機制，而不是完全穩定的無人值守執行模式。

Claude Code 的 `/goal`：完成條件驅動的多輪執行

Claude Code 的 /goal 文件寫得更明確：使用者設定 completion condition 後，Claude 會跨 turn 持續工作，直到條件滿足。

示例：

`1`	`/goal all tests in test/auth pass and the lint step is clean`

Claude Code 的機制大致是：

目前 turn 完成後，不直接把控制權還給使用者。
一個小型快速模型會檢查目標條件是否已經滿足。
如果沒有滿足，Claude 自動開始下一輪。
如果滿足，goal 自動清除，並在 transcript 裡記錄完成狀態。

這意味著 Claude Code 的 /goal 更像「按完成條件自動續跑」。它不只是把目標掛在會話裡，而是把「是否繼續下一輪」交給一個獨立評估步驟。

Claude Code 還支援直接查看狀態：

/goal

狀態裡會顯示目標條件、執行時間、已評估 turn 數、token 消耗，以及 evaluator 最近一次給出的原因。

如果要提前停止，可以使用：

`1`	`/goal clear`

stop、off、reset、none、cancel 也可以作為清除別名。開啟目標後，如果會話中斷，之後透過 --resume 或 --continue 恢復時，仍然 active 的 goal 可以被帶回來；但計時、turn 數和 token 基線會重新計算。

兩者最大的差異

Codex 和 Claude Code 都在把 AI 編程從「單輪回答」推向「長任務執行」，但 /goal 的定位有差異。

對比項	Codex CLI `/goal`	Claude Code `/goal`
狀態	experimental	官方文件單獨成頁說明
啟用方式	需要開啟 `features.goals`	可直接在受信任 workspace 使用
目標作用域	目前 active thread	目前 session
常用操作	set / view / pause / resume / clear	set / view / clear
自動判斷	文件強調目標附著與追蹤	明確說明每輪後由 evaluator 判斷
自動續跑	文件表述較克制	條件未滿足時自動下一輪
適合場景	想在 Codex 長任務裡保持目標上下文	想按完成條件讓 Claude Code 持續推進

簡單說，Codex 的 /goal 更像「給目前執行緒掛一個實驗性的長期目標」；Claude Code 的 /goal 更像「給目前會話設定一個可驗證的停止條件，讓它自動做到滿足為止」。

寫好 `/goal` 的關鍵

不管使用哪一個工具，/goal 都不適合寫成模糊願望。

不太好的寫法：

`1`	`/goal 把项目优化一下`

更好的寫法：

`1`	`/goal 将 payment 模块迁移到新 API，npm test -- payment 退出码为 0，git diff 只包含 payment 相关文件`

一個好目標通常包含三點：

明確的完成狀態。
可執行的驗證方式。
必須遵守的邊界。

如果目標太大，還應該加上停止條件：

`1`	`/goal 修复 eslint 报错，npm run lint 退出码为 0；如果超过 20 轮仍未完成，停止并总结剩余问题`

這很重要。/goal 越強，越需要邊界。否則 Agent 可能會為了追求「完成」而改動過多檔案、跑太久、消耗太多 token，甚至把原本該停下來詢問的問題繼續往前推。

什麼時候適合用 `/goal`

適合：

測試修復：直到指定測試通過。
程式碼遷移：直到所有呼叫點改完並編譯成功。
批量清理：直到某類 lint 或型別錯誤清零。
文件補齊：直到所有指定模組都有說明。
issue 佇列處理：直到某個標籤下的問題都被處理或明確分類。

不適合：

需求本身還沒想清楚。
需要頻繁產品判斷。
涉及高風險刪除、資料遷移或權限變更。
驗收條件只能靠主觀判斷。
任務會跨越大量無關模組。

一個實用原則是：如果你能寫出「跑哪個命令、看到什麼結果、哪些檔案不能碰」，就適合用 /goal。如果只能寫「幫我做得更好」，那還是先用普通對話、計畫模式或人工評審更穩。

對 AI 編程工具的影響

/goal 代表一個很明顯的方向：AI 編程工具正在從「互動式助手」變成「可持續執行的工作單元」。

過去我們讓 Agent 做任務，經常要在旁邊守著。它卡住了要提示，測完了要繼續，報錯了要再下命令。/goal 把這部分互動壓縮成一個完成條件，讓 Agent 自己決定下一輪該做什麼。

但這也帶來新的要求。以後寫 prompt 不只是描述任務，還要寫驗收條件、驗證命令、修改邊界和停止規則。換句話說，使用者的工作從「催它繼續」變成「定義什麼叫完成」。

Codex 和 Claude Code 走到 /goal 這一步，說明長任務 Agent 已經不再只是背景任務或雲端佇列的專利。終端裡的本地編程工具，也開始需要更強的自主推進能力。

總結

Codex CLI 和 Claude Code 都有了 /goal，但現階段不要把它們簡單看成同一個功能。

Codex 的 /goal 仍是實驗能力，需要開啟 features.goals，更適合在 Codex 目前執行緒裡維持長期目標。Claude Code 的 /goal 則更明確地把「完成條件」和「自動續跑」連在一起，透過獨立 evaluator 判斷是否繼續。

對日常開發來說，這類命令最適合處理有明確驗收標準的工程任務。它不會替代需求判斷，也不會消除程式碼審查，但能減少長任務裡大量重複的「繼續」「再跑一次」「修到測試通過」。

真正要學會的不是某個命令本身，而是如何把任務寫成清楚、可驗證、可停止的目標。

參考資料

OpenAI Codex CLI Slash Commands：https://developers.openai.com/codex/cli/slash-commands
Claude Code Goal 文件：https://code.claude.com/docs/en/goal

AI 編程工具這一輪，DeepSeek 為何成了省錢關鍵？

Mon, 11 May 2026 04:59:00 +0800

這一輪 AI 編程工具的競爭，表面上是在比模型能力、插件生態和 agent 自動化程度，真正用起來以後，最先撞上的問題卻是成本。

Claude Code、Codex、OpenClaw、Superpowers 這類工具都很好用，但它們有一個共同特點：一旦進入複雜任務，就會非常吃 token。它們要讀項目、建計劃、調用工具、總結上下文、反覆檢查結果，還可能拉起多個子任務。模型越聰明，工作流越自動化，帳單也越容易悄悄變大。

所以 DeepSeek 在這一輪裡變得很關鍵，不只是因為它能寫程式碼，而是因為它在長上下文和快取成本上，剛好打中了 AI 編程工具最燒錢的地方。

Agent 工具為什麼特別費 token

傳統聊天式編程助手，通常是一問一答。你問一個函式怎麼寫，它回答一段程式碼。這個模式消耗不小，但還算可控。

Agent 工具不一樣。它不是只回答問題，而是要像一個臨時工程師一樣進入項目：

先掃描目錄和關鍵檔案；
再理解需求和現有架構；
然後制定計劃；
修改檔案；
執行命令或測試；
根據報錯繼續修；
最後總結改了什麼。

這個過程裡，模型反覆讀取同一批上下文。項目說明、程式碼片段、工具結果、歷史對話、計劃和錯誤日誌都會被塞回上下文。任務稍微複雜一點，幾十萬 token 很快就出去了。

如果再裝一些更激進的插件，成本會更明顯。比如有些 OpenCode 或 Claude Code 增強工具，會預設組織一整套 agent 團隊。你只是想改一個小功能，它也可能啟動規劃、審查、執行、復盤等多個環節。任務當然顯得更「智慧」，但 token 也會一路往上跑。

Superpowers 的好處是按需觸發

Superpowers 這類工具的一個優點，是它不會在所有任務裡都強行拉起完整 agent 流程。

平時你還是可以讓 Claude Code、OpenCode 或 Codex 按原來的方式工作。只有當你明確調用某個 skill，比如頭腦風暴、寫計劃、執行計劃、做復盤時，它才進入更重的自動化流程。

這對成本很重要。

AI 編程不應該所有任務都用重武器。改一行設定、查一個報錯、寫一個小腳本，用普通對話就夠了；只有複雜重構、跨檔案修改、長文件處理、多輪驗證，才值得上完整 agent 流程。

工具越強，越要學會控制觸發條件。否則自動化越多，浪費越多。

DeepSeek 的關鍵優勢是快取便宜

DeepSeek 適合接這類 agent 工具，一個很重要的原因是快取命中成本低。

AI 編程任務裡有大量重複前綴。比如專案背景、系統提示詞、工具說明、檔案內容、前幾輪對話，經常會在後續請求裡反覆出現。如果模型服務支援 prompt cache，這些重複內容命中快取後，成本會明顯下降。

很多模型的快取命中價只是比未命中便宜一些，比如便宜到三分之一左右。DeepSeek 的優勢在於，命中快取後的價格差距可以大很多。對長上下文、多輪調用、重複讀取項目的 agent 工作流來說，這個差距會直接反映到帳單上。

也就是說，DeepSeek 不是每一次回答都一定最強，而是在「長任務、多輪任務、反覆讀上下文」的場景裡，成本結構特別適合 AI 編程。

長上下文讓 Claude Code 更好用

把 Claude Code 或類似工具接到 DeepSeek V4 時，另一個明顯優勢是長上下文。

AI 編程工具最怕上下文不夠。上下文一不夠，就要頻繁壓縮；壓縮一多，前面讀過的細節就可能丟失。模型開始忘記專案結構、忘記約束、忘記某個檔案為什麼這麼改，後續品質就會下降。

DeepSeek V4 系列的長上下文能力，讓它更適合處理程式碼倉庫、文檔批處理、字幕翻譯、站點文章整理這類任務。特別是接入 Claude Code、OpenClaw 這類工具時，如果配置得當，可以讓它盡量晚一點進入上下文壓縮，讓模型保留更多專案細節。

這也是為什麼有些任務用 DeepSeek 會顯得「很耐用」：它不一定每一步都驚艷，但能承受長時間、低成本、反覆調用。

V4 Pro 和 V4 Flash 怎麼分工

DeepSeek V4 Pro 和 V4 Flash 不應該混著用。

簡單任務用 DeepSeek V4 Flash 更合適。它速度快、成本低，用在下面這些場景通常足夠：

翻譯字幕；
整理文檔；
生成普通腳本；
修改小範圍程式碼；
跑 OpenClaw 裡的輕量任務；
做簡單的站點內容處理。

複雜任務再考慮 DeepSeek V4 Pro：

大規模重構；
多模組程式碼理解；
複雜推理；
長鏈路 agent 任務；
高風險程式碼修改；
需要更強規劃能力的工程任務。

很多人一上來就想掛最強模型，這反而不划算。AI 編程工具最現實的玩法，是把任務分層：便宜模型吃掉大量常規工作，貴模型只處理關鍵節點。

MiniMax、豆包和 DeepSeek 的位置不同

國產模型和套餐裡，MiniMax、豆包、Kimi、DeepSeek 各有位置。

MiniMax 的優勢是量大、便宜、功能全。它未必是最聰明的編程模型，但拿來做翻譯、輕量整理、批處理，很划算。比如批量處理字幕、改格式、做簡單校對，MiniMax 這類套餐很耐用。

豆包的優勢是生態工具比較全，圖片、影片、搜尋、TTS、可能的 STT 和 embedding 都能接在一起。它更像綜合型工具箱。

DeepSeek 的位置更明確：文本、程式碼、長上下文、低成本快取。它沒有完整的圖像生成、語音、影片生態，短板很明顯；但在 AI 編程和長文本 agent 工作流裡，它的長板足夠長。

所以不是誰替代誰，而是任務拆開以後各用各的。

省錢的關鍵不是只找便宜模型

AI 編程想省錢，不是簡單把所有請求都換成便宜模型。

真正有效的省錢方式有幾條：

簡單任務不要啟動重 agent。
能用 Flash 的任務不要上 Pro。
長任務盡量利用快取。
重複上下文要穩定，避免無意義改動導致快取失效。
大任務先讓便宜模型做草稿和批處理，再讓強模型做關鍵審查。
明確告訴 agent 不要重複描述事實，不要反覆總結同一件事。

尤其是最後一點很重要。AI 工具很容易囉嗦，囉嗦不只是閱讀體驗問題，也是成本問題。提示詞裡明確要求「事實只描述一次，觀點只表達一次」，能同時改善文章品質和 token 消耗。

DeepSeek 適合哪類 AI 編程工作流

DeepSeek 最適合這些任務：

長程式碼倉庫閱讀；
多檔案輕量修改；
批量文檔整理；
批量字幕翻譯；
Hugo 文章整理；
agent 計劃執行；
大量重複上下文的低成本自動化。

它不一定適合所有任務。如果要做特別強的前端審美、複雜產品判斷、跨模態創作，可能還要搭配 Claude、GPT、Gemini、豆包或其他工具。

但只要任務是「長文本、長上下文、反覆調用、成本敏感」，DeepSeek 就很容易變成首選。

小結

AI 編程工具這一輪，DeepSeek 的價值不只是「國產模型能寫程式碼」，而是它解決了 agent 工具最現實的痛點：長任務太燒錢。

Claude Code、OpenClaw、Superpowers 這類工具會讓開發流程越來越自動化，但自動化的背後是大量上下文讀寫和多輪調用。誰能把這部分成本壓下來，誰就能讓 AI 編程從「偶爾爽一下」變成「天天用得起」。

DeepSeek 的長上下文、低快取成本和 V4 Flash / V4 Pro 分層使用，正好讓它站在這個位置上。

這一輪真正省錢的關鍵，不是不用好模型，而是把好模型、便宜模型、快取和 agent 流程搭配好。能把這套帳算明白，AI 編程工具才真的會變成生產力，而不是一個漂亮但昂貴的玩具。

AI Coding 套餐怎麼選：輕度看順手，重度看靈活性

Sun, 10 May 2026 08:20:58 +0800

AI Coding 套餐這半年變化很快。很多工具從「按次」轉向「按量」，免費或低價套餐的額度被收緊，部分海外服務還增加了身份驗證、地區限制和更嚴格的使用規則。

對開發者來說，問題已經不只是「哪個模型最強」，而是：每個月要花多少錢、額度夠不夠、工具是否順手，以及當某個套餐突然漲價或改規則時，能不能平滑切換。

一個比較實用的結論是：輕度使用者買順手的工具，中度使用者買性價比，重度使用者買靈活性。使用越重，越不要把模型和工具綁死在同一個套餐裡。

選套餐先看四件事

過去選 AI Coding 套餐，通常看三點：

模型能力是否足夠強。
回應速度是否穩定。
套餐額度是否夠用。

現在還要加上第四點：模型和工具能不能分開。

模型負責推理能力，工具負責上下文管理、檔案編輯、Agent 編排和工作流體驗。兩者都重要，但最好不要完全綁定。例如如果你喜歡 Claude 模型，可以買官方套餐，也可以透過 API 接到其他工具裡；如果你喜歡某個編輯器或 Agent 工具，也最好確認它能接入不同模型，而不是只能使用自家套餐。

這樣做的好處不是折騰，而是降低風險。AI Coding 是變化最快的賽道之一，今天額度寬鬆的套餐，過兩個月可能就改計費；今天好用的工具，下一版也可能因為模型介面變化而體驗下降。把模型和工具分開，等於給自己留了遷移空間。

海外套餐正在收緊

GitHub Copilot、Cursor、Windsurf、Claude Code 這類工具仍然是很多人的主力選擇，但整體趨勢已經很明確：低價高額度越來越難維持，按量計費越來越常見。

GitHub Copilot 這類服務開始更強調按量計費之後，套餐本身的「套利空間」會明顯減少。對輕度使用者來說，它仍然方便；但對高頻使用 Agent、長上下文與複雜程式任務的人來說，實際消耗會更接近真實 API 成本。

Cursor 和 Windsurf 本質上是把模型能力包進 IDE 體驗裡。它們的優勢是開箱即用、編輯器體驗成熟，缺點是工具綁定較深。一旦你依賴其中的專屬 Agent、索引與自動化流程，後續遷移成本就會越來越高。

Claude Code 的體驗和生態熱度很高，但海外訂閱、身份驗證、地區限制、中轉服務安全性，都會成為國內使用者需要額外評估的風險。尤其是第三方中轉服務，可能存在模型摻雜、穩定性不足、資料安全和跑路風險，不適合作為重要專案的長期基礎設施。

國產套餐的優點和短板

國產 AI Coding 套餐的一個優點，是很多服務以 API 形式提供，天然不太鎖定工具。你可以把模型接入 OpenCode、Cline、Continue、自己的腳本或內部 Agent。

短板也很明顯：如果同時要求模型強、速度快、額度足，很少有一個套餐能全部滿足。

GLM 系列在國產模型裡能力較強，但高峰期吞吐可能不穩定，重度任務容易被速度卡住。Kimi 的能力不錯，但價格和額度規則需要持續關注，尤其要看後台額度是否透明。MiniMax 這類模型速度和額度較友好，適合日常輕任務、批次處理和不太複雜的程式輔助，但在複雜工程推理上可能略低一檔。DeepSeek 新模型如果處在活動價或優惠期，性價比會很高；活動結束後，就要重新按官方價格和套餐規則評估。

所以國產方案更適合作為「模型池」使用：不同任務用不同模型，而不是押注一個模型包打天下。

輕度使用者：選順手的，不必折騰 API

如果一週只是讓 AI 改腳本、補文件、解釋報錯、寫一點小工具，不需要複雜配置。

這類使用者優先選順手的產品。Cursor、Windsurf、Trae、CodeBuddy、通義靈碼、GitHub Copilot 之類都可以嘗試。重點不是追求最低單價，而是降低使用門檻：能在你常用的編輯器裡穩定工作、補全品質不錯、出錯時容易回退，就已經足夠。

輕度使用者不建議為了省一點錢去折騰多層 API、中轉站和複雜代理。時間成本、帳號風險和排錯成本，往往高於省下來的訂閱費。

中度使用者：看性價比，也看可遷移性

如果每天都會用 AI 寫程式、改專案、生成測試、整理文件，就要開始關注額度和實際消耗。

這類使用者可以把主力工具和備用模型分開安排。例如一個順手的 IDE 套餐負責日常編輯，再配一個可接入多工具的 API 或聚合套餐，處理更長上下文、更複雜的 Agent 任務。

選擇時可以重點看三點：

是否支援接入第三方工具。
是否能清楚看到 token 或額度消耗。
超額後是限速、降級、停止服務，還是按量付費。

如果一個套餐看起來便宜，但只允許在自家工具裡使用，就要把遷移成本算進去。如果一個套餐貴一點，但能接入多種工具，反而可能更適合作為長期主力。

重度使用者：不要把模型和工具綁死

重度使用者的核心訴求是靈活性。

當一個人或團隊每天大量使用 AI Agent，消耗會非常快。複雜程式庫檢索、長上下文修改、多輪調試、自動化測試修復，都會讓 token 消耗成倍增長。此時再依賴單一套餐，很容易遇到三個問題：

額度突然不夠。
計費規則突然改變。
某個工具或模型臨時不可用。

更穩妥的做法是準備多層組合：一個主力 Agent 工具，一個或多個可替換模型介面，一個低成本模型處理簡單任務，一個高能力模型處理複雜任務。日常小任務不要都交給最貴模型，關鍵任務也不要只依賴最便宜模型。

對重度使用者來說，「工具能接任意模型，模型能接入任意工具」比單月便宜幾十美元更重要。因為真正貴的不是訂閱費，而是工作流被某個生態綁死後，遷移和重建習慣的成本。

一個更穩的組合思路

比較穩妥的組合可以這樣安排：

輕任務用低成本模型：解釋程式、寫小腳本、改格式、生成簡單文件。
中等任務用性價比模型：常規功能開發、測試補全、重構建議。
難任務用強模型：複雜架構調整、跨檔案修復、疑難 bug、長上下文推理。
工具層保持開放：盡量選擇能接 API、能匯出設定、能切換模型的工具。
保留備用方案：主力套餐改規則時，可以快速切到另一個模型或工具。

這樣不一定最省錢，但更抗波動。AI Coding 套餐的價格和額度還會繼續變化，真正值得長期投入的是可遷移的工作流，而不是某個短期看起來特別划算的套餐。

小結

AI Coding 套餐不適合只看單月價格。輕度使用者應該少折騰，選一個順手的工具；中度使用者要開始看額度、消耗和可遷移性；重度使用者則要把模型和工具解耦，避免被單一生態綁定。

現在最值得記住的一點是：套餐會變，模型會變，工具也會變。把選擇權留在自己手裡，才是長期使用 AI Coding 工具時最重要的成本控制。

Claude Code 限額翻倍：Anthropic 借 SpaceX 算力擴容緩解使用限制

Sat, 09 May 2026 10:59:48 +0800

Anthropic 在 2026 年 5 月 6 日宣布，將提高 Claude Code 和 Claude API 的使用限額，並與 SpaceX 達成新的算力合作。對普通使用者來說，最直接的變化是 Claude Code 可用額度變多；對開發者和企業來說，重點是 Claude 的推理容量正在繼續擴張。

這次公告可以拆成兩部分看：

Claude Code 與 Claude API 的限額提升。
Anthropic 透過 SpaceX 資料中心獲得新的算力容量。

Claude Code 限額有哪些變化

Anthropic 表示，下面三項變化從公告當天開始生效：

Claude Code 的五小時 rate limit 對 Pro、Max、Team 和 seat-based Enterprise 計畫翻倍。
Pro 和 Max 帳號的 Claude Code 高峰時段限額降低被取消。
Claude Opus 模型的 API rate limits 明顯提高。

也就是說，如果你經常用 Claude Code 做長時間程式任務、倉庫分析、重構、除錯或 Agent 工作流，這次變化可能會直接減少「還沒做完就到限額」的情況。

不過需要注意，限額提高不等於無限使用。Claude Code 仍然會受訂閱計畫、使用方式、模型、任務長度、上下文大小和平台策略影響。只是相比之前，Anthropic 明確給出了更大的使用空間。

為什麼算力會影響 Claude Code 體驗

Claude Code 這類工具比普通聊天更吃資源。一次程式任務可能會包含：

讀取大量檔案。
長上下文分析。
多輪工具呼叫。
生成、修改和檢查程式碼。
反覆執行測試或解釋錯誤。
使用 Opus 模型處理複雜推理。

這些操作背後消耗的不只是 token，還有模型推理容量、並發能力和調度資源。使用者看到的是「限額」「排隊」「高峰時段變慢」，平台看到的是算力供給和需求之間的壓力。

所以這次 Anthropic 把限額提升和算力合作放在同一篇公告裡，本質上是在說明：Claude Code 體驗的改善不是單純改一個套餐規則，而是依賴後端推理容量擴張。

SpaceX 合作帶來什麼

Anthropic 表示，已經與 SpaceX 簽署協議，將使用 SpaceX Colossus 1 資料中心的全部算力容量。官方提到，這部分容量超過 300 兆瓦，對應 22 萬塊以上 NVIDIA GPU，並將在一個月內提供給 Anthropic 使用。

這部分新增容量會直接改善 Claude Pro 和 Claude Max 訂閱使用者的可用容量。

公告中還提到，Anthropic 對未來與 SpaceX 合作開發軌道 AI 算力表示興趣。不過這更像長期方向，和目前使用者馬上能感受到的 Claude Code 限額提升不是同一層面的事情。

Anthropic 的算力布局正在變大

SpaceX 只是 Anthropic 近期算力擴張的一部分。官方同時列出了其他合作：

與 Amazon 的最高 5GW 合作，其中接近 1GW 新容量計畫在 2026 年底前上線。
與 Google 和 Broadcom 的 5GW 合作，預計從 2027 年開始上線。
與 Microsoft 和 NVIDIA 的戰略合作，包含 300 億美元 Azure 容量。
與 Fluidstack 的 500 億美元美國 AI 基礎設施投資。

Anthropic 還強調，Claude 的訓練和運行會使用多種 AI 硬體，包括 AWS Trainium、Google TPU 和 NVIDIA GPU。

這說明一個趨勢：頭部模型公司的競爭不只在模型參數、榜單成績和產品形態，也在電力、資料中心、GPU、TPU、網路和全球部署能力。

對 Claude Code 使用者的實際影響

對開發者來說，這次最值得關注的是 Claude Code 的五小時限額翻倍。它會影響這些場景：

大型倉庫程式碼閱讀。
多檔案重構。
Bug 排查和測試修復。
程式碼遷移與依賴升級。
長時間 Agent 編程任務。
Team 或 Enterprise 中多人同時使用 Claude Code。

過去使用 Claude Code 時，一個常見問題是任務還在推進，但額度已經到頂。限額提升後，開發者更容易讓 Agent 把一個完整任務走完，而不是中途停下。

如果你是 Pro 或 Max 使用者，取消高峰時段限額降低也很關鍵。它意味著晚高峰或使用高峰期的體驗可能更穩定，不會因為平台臨時收緊額度而明顯影響 Claude Code 工作流。

對 API 使用者的意義

公告中還提到，Claude Opus 模型的 API rate limits 得到明顯提升。對於使用 Opus 做複雜任務的團隊，這通常意味著：

更高並發。
更少 429 限流。
更容易支撐批量任務。
更適合長上下文、複雜推理和 Agent 工作流。

不過具體限額會因帳戶、組織、模型和計畫不同而變化。實際部署前，仍然需要看自己的 Anthropic Console、rate limits 文件和錯誤日誌。

企業和區域部署也在變重要

Anthropic 在公告裡還提到，金融、醫療、政府等受監管行業越來越需要區域內基礎設施，以滿足合規和資料駐留要求。因此，部分容量擴張會放在美國以外地區，尤其是亞洲和歐洲的推理能力。

這對企業客戶很重要。大模型應用進入核心業務後，問題不只是「模型好不好用」，還包括：

資料是否留在指定區域。
是否滿足行業合規要求。
高峰期是否有穩定容量。
是否能支撐團隊級和組織級並發。
是否有審計、權限和安全控制。

從這個角度看，算力擴容不只是性能新聞，也會影響企業採購和部署決策。

總結

Anthropic 這次公告的核心資訊很直接：Claude Code 和 Claude API 的使用限制正在放寬，背後原因是新的算力容量正在上線。

對普通 Claude Code 使用者來說，最重要的是五小時限額翻倍，以及 Pro、Max 高峰期限額降低取消。對 API 和企業使用者來說，更值得關注的是 Opus rate limits 提升，以及 Anthropic 在 SpaceX、Amazon、Google、Microsoft、NVIDIA、Fluidstack 等合作中的長期算力布局。

AI 工具越來越像基礎設施服務。模型能力是一部分，穩定容量、區域合規、限額策略和成本控制，同樣會決定使用者體驗。

參考連結：

Anthropic：Higher usage limits for Claude and a compute deal with SpaceX

Claude 帳號被封怎麼辦？Claude Code 受限原因與申訴指南

Sat, 09 May 2026 10:32:12 +0800

Claude 或 Claude Code 帳號突然被限制、剛充值後被封、Pro 權限異常、用量突然變少，這類問題近來被很多使用者反覆討論。真正需要注意的是：不要把它簡單理解成「換個節點」「換個帳號」就能解決的技術問題。帳號風控通常和地區、支付、裝置、登入行為、使用內容、自動化呼叫、共享方式等多種訊號有關。

更穩妥的處理方式，是先判斷自己遇到的是哪類問題：是普通用量限制、支付訂閱異常、Claude Code 授權問題，還是 Anthropic 認為帳號違反了使用政策或服務條款。

先區分三類情況

第一類是正常限額。Claude Pro、Max、Team、API 和 Claude Code 的額度機制不同，高峰期、長上下文、程式碼任務、Agent 任務都會更快消耗額度。看到「limit reached」不一定是封號，可能只是當前週期的使用量耗盡。

第二類是訂閱或授權異常。比如剛充值但權限沒刷新、行動端訂閱和網頁帳號不同步、Claude Code 沒有正確登入、環境變數裡還殘留舊的 ANTHROPIC_API_KEY。這類問題通常應該從帳單、登入狀態和客戶端設定排查。

第三類才是帳號暫停或封禁。常見表現是收到 suspension、disabled、terminated 一類郵件，或者登入時直接提示帳號不可用。這時就不要繼續反覆換裝置、換網路、換帳號嘗試登入，因為這可能讓風控訊號更複雜。

常見觸發因素

Anthropic 官方幫助文件和隱私說明裡提到過幾類常見風險訊號：違反 Usage Policy、從不支援地區建立或使用帳號、違反服務條款、重複違規、異常存取或濫用行為。

實際使用中，容易觸發風險的場景包括：

帳號註冊、登入和支付地區不一致。
長期使用資料中心代理、共享代理或頻繁切換 IP。
多人共用一個個人帳號。
短時間內在多台裝置、多地區頻繁登入。
使用自動化腳本高頻存取 Claude.ai。
把 Claude Code 當作共享服務或轉售入口。
請求明顯違反 Anthropic 使用政策的內容。
支付方式、帳單地址、帳號地區互相衝突。

這裡的關鍵不是「某一個訊號必封」，而是多個異常訊號疊加後，系統更容易把帳號判斷為高風險。

不建議用「規避風控」的思路解決

網上經常會出現所謂「穩定使用方案」，例如指紋瀏覽器、裝置指紋重置、清空本地目錄、換環境、固定時區語言、換信箱繼續註冊等。這類說法裡有些只是普通環境排查，有些則明顯是在規避平台風控。

不建議把「繞過風控」當成解決方案。原因很簡單：

它可能違反服務條款。
它可能讓帳號風險訊號進一步增加。
它不能解決支付、地區、政策違規等根本問題。
一旦涉及團隊或商業使用，後續申訴會更難解釋。

如果你的目標是長期穩定使用 Claude，正確方向不是偽裝，而是讓帳號、地區、支付、裝置和用途都盡量真實、一致、可解釋。

Claude Code 受限怎麼排查

Claude Code 使用者遇到問題時，可以先按下面順序檢查：

1
2

claude --version
claude auth status

如果使用 API key，也要確認環境變數是否指向了正確帳號：

`1`	`echo $ANTHROPIC_API_KEY`

在 Windows PowerShell 中可檢查：

`1`	`echo $env:ANTHROPIC_API_KEY`

如果你同時用過網頁登入、OAuth、API key、第三方客戶端或不同終端，建議先統一認證方式，避免一個工具還在使用舊憑據。

還要區分兩種情況：

Claude Code 用量到達上限：通常是額度或訂閱限制。
帳號或組織被 disabled：通常是帳號、組織、支付或政策層面的風險。

前者可以等額度刷新或調整訂閱；後者應保留提示截圖和郵件，走官方支援或申訴流程。

穩定使用的合規建議

想降低帳號異常機率，建議從這些基礎做起：

使用受支援國家或地區的正常帳號。
盡量保持登入地區、支付方式和帳單資訊一致。
避免多人共享個人帳號。
不要把個人 Pro/Max 當作團隊 API 池。
不要頻繁切換 IP、裝置和瀏覽器環境。
不要使用來源不明的第三方 Claude 客戶端。
避免高頻自動化存取 Claude.ai 網頁端。
商業或團隊場景優先使用 Team、Enterprise 或 API。
熟悉 Anthropic Usage Policy，不把帳號用於受限用途。

如果你確實需要在多裝置上使用，保持正常登入即可，不要頻繁清環境、換指紋、換代理。過度「折騰環境」本身就可能看起來像異常行為。

被封後該怎麼做

如果帳號已經被暫停，建議按這個順序處理：

查收 Anthropic 或 Claude 發來的郵件，確認封禁原因或提示類型。
停止繼續建立新帳號、換網路、換裝置反覆嘗試。
整理帳號信箱、訂閱訂單、支付憑證、近期使用場景。
如果認為是誤判，按官方入口提交 appeal 或聯絡支援。
說明真實使用場景，避免編造地區、身份或用途。
如果涉及訂閱扣費，單獨詢問退款或訂閱處理。

申訴時越具體越好，例如說明是否使用 Claude Code、是否切換過裝置、是否使用過 VPN、是否有團隊共用、是否接入過第三方工具。平台需要判斷風險來源，模糊說「我什麼都沒做」通常幫助有限。

哪些說法要謹慎看待

有些文章或影片會聲稱「只要固定指紋就不會封」「某瀏覽器能徹底防封」「清理某目錄就能重置裝置身份」「IP 對齊時區就能解決所有問題」。這些說法不宜照單全收。

原因是平台風控通常是多維模型，不只看瀏覽器指紋或 IP。帳號歷史、支付資訊、地區政策、使用內容、存取頻率、自動化特徵、客戶端版本、API 呼叫方式，都可能參與判斷。單點偽裝不等於長期穩定，反而可能製造更多不一致訊號。

更重要的是，很多所謂「防封方案」本質上是賣工具或賣服務。使用者真正需要的是判斷風險來源、合規使用和保留申訴證據，而不是把帳號安全寄託在第三方環境包裝上。

總結

Claude 帳號被封或 Claude Code 受限，不一定是單一原因造成的。它可能是額度問題、訂閱問題、授權問題，也可能是地區、支付、裝置、共享、自動化或內容政策觸發的綜合風控。

長期穩定使用 Claude 的關鍵不是繞過風控，而是讓使用方式合規、帳號資訊一致、存取環境穩定、團隊使用走正式方案。遇到封禁時，先停止折騰環境，保存證據，走官方申訴和支援流程，才是最穩妥的處理方式。

參考連結：

從 PPT 到原型設計：歸藏 PPT Skill 與 Huashu Design 使用場景解析

Sat, 09 May 2026 08:34:23 +0800

最近兩個中文開發者做的設計類 Agent Skill 很值得放在一起看：一個是歸藏的 guizang-ppt-skill，另一個是花叔的 huashu-design。

它們都不是傳統意義上的「設計工具」，而是把一套設計流程、審美偏好、檢查清單和工程模板寫成 Agent 可以執行的 Skill。你不是打開一個 UI 慢慢拖元素，而是把需求交給 Claude Code、Codex、Cursor 這類 Agent，讓它按固定流程生成 HTML、PPT、動畫或原型。

這類專案的價值，不在於讓 AI 隨機發揮，而在於把「怎麼做才不難看」這件事流程化。

guizang-ppt-skill：專注雜誌風網頁 PPT

歸藏的 guizang-ppt-skill 定位很清楚：生成單檔 HTML 橫向翻頁 PPT，視覺基調是「電子雜誌 x 電子墨水」。它更像一套為演講準備的版式系統，而不是通用設計框架。

倉庫 README 裡列出的核心能力包括：

單檔 HTML 輸出，不需要建置和伺服器，瀏覽器直接打開。
橫向左右翻頁，支援鍵盤、滾輪、觸控滑動、底部圓點和 ESC 索引。
5 套主題色預設，包括墨水經典、靛藍瓷、森林墨、牛皮紙和沙丘。
10 種頁面版面，包括開場封面、章節幕封、資料大字報、左文右圖、圖片網格、Pipeline、懸念問題、大引用、Before/After 對比和圖文混排。
內建模板、元件說明、版面骨架、主題設定和品質檢查清單。

它適合做線下分享、產業內部講話、私享會、AI 產品發表、demo day，以及帶有強烈個人風格的演講稿。不太適合大段表格資料、培訓課件和多人協作編輯。

這個專案有一個很好的取捨：它沒有試圖覆蓋所有設計場景，而是把「雜誌風 PPT」這個場景做窄。主題色只能從預設裡選，版面也有明確骨架，這反而降低了 Agent 跑偏的機率。

如果你經常要把觀點、產業觀察、產品發表內容做成演講 deck，它的實用性會很高。

安裝命令也很直接：

`1`	`npx skills add https://github.com/op7418/guizang-ppt-skill --skill guizang-ppt-skill`

huashu-design：更完整的 HTML 原生設計工作流

花叔的 huashu-design 覆蓋面更大。它的目標不是只做 PPT，而是把 HTML 當成原生設計畫布，用 Agent 生成可交付的設計資產。

倉庫 README 裡列出的能力包括：

可點擊 App 或 Web 原型。
HTML 投影片，以及可編輯 PPTX 匯出。
產品發表動畫、MP4、GIF 和配樂版本。
多方向設計方案並排對比。
資訊圖、資料視覺化、PDF、PNG、SVG 匯出。
5 維專家評審，包括哲學一致性、視覺層級、執行工藝、功能性和創新性。

它的核心思路是：讓 Agent 先理解品牌和素材，再產出高保真設計。專案裡強調了 Core Asset Protocol，也就是遇到具體品牌時，要先確認 logo、產品圖、UI 截圖、配色、字體和品牌指南，而不是憑記憶猜。

這點很重要。很多 AI 生成設計看起來「像設計」，但不像某個真實產品或品牌。huashu-design 試圖把這個問題前置解決：先找真實資產，再做設計。

安裝命令是：

`1`	`npx skills add alchaincyf/huashu-design`

它更適合那些希望在終端裡完成較完整設計交付的人：產品原型、發表動畫、簡報、資訊圖、設計評審都可以放在一個 Agent 工作流裡處理。

兩者最大的區別

簡單說，guizang-ppt-skill 是一個更窄、更穩的演講 deck 生成器；huashu-design 是一個更寬、更完整的 HTML 原生設計系統。

如果只看 PPT：

guizang-ppt-skill 更強調雜誌感、節奏、版式和單檔瀏覽器演示。
huashu-design 更強調通用設計能力、可編輯 PPTX、品牌素材、匯出鏈路和評審流程。

如果看整體設計能力：

guizang-ppt-skill 的邊界更清晰，適合快速做一份有風格的橫向演講。
huashu-design 的能力更綜合，適合把一個產品或品牌設計任務拆成原型、動畫、投影片和資訊圖。

這兩個專案也代表了兩種不同的 Skill 寫法。前者像一套高度收斂的模板和審美約束，後者像一個小型設計團隊的工作流說明書。

為什麼這類 Skill 重要

Agent 的一個常見問題是「會做，但不穩定」。同樣一句需求，有時輸出很好，有時就會滑向紫色漸層、圓角卡片、假圖標和一堆看似高級的空話。

Skill 的意義就是把穩定性補上。它把下面這些東西固化下來：

可複用的模板。
可執行的檢查清單。
明確的審美偏好。
常見錯誤的規避規則。
輸出格式和驗證流程。
什麼時候該問問題，什麼時候該直接開始做。

這比單純寫一句「請做得高級一點」可靠得多。

尤其是設計任務，審美並不是一句 prompt 就能穩定復現的。真正有用的是流程：先確認素材，再定方向，再搭結構，再做視覺，再檢查輸出。把這個流程寫成 Skill，Agent 才更像一個可協作的執行者，而不是一次性圖片生成器。

使用建議

如果你只是想把一個主題做成線下演講或分享 deck，可以優先試 guizang-ppt-skill。它的輸出邊界窄，單檔 HTML 也方便分發和預覽。

如果你想讓 Agent 承擔更完整的設計任務，比如 App 原型、發表動畫、品牌化投影片、可匯出 PPTX 或資訊圖，可以優先看 huashu-design。它的鏈路更長，適合需要多輪迭代和交付物匯出的任務。

如果你已經在寫自己的 Codex 或 Claude Code Skill，這兩個專案也都值得參考：

想學「如何把一個窄場景做穩」，看 guizang-ppt-skill。
想學「如何把複雜工作流拆成可執行協議」，看 huashu-design。

總結

歸藏和花叔這兩個專案的共同點，是都把「設計能力」從一次 prompt 變成了可重複執行的流程。

guizang-ppt-skill 的重點是雜誌風 HTML PPT，適合高風格化演講；huashu-design 的重點是 HTML 原生設計系統，覆蓋原型、動畫、投影片、資訊圖和評審。它們解決的不是「AI 能不能生成設計」，而是「AI 能不能按一套穩定方法生成可交付的設計」。

這可能會成為 Agent 工具生態裡很重要的一類開源專案：不只是程式碼模板，而是把人的經驗、審美和工作方法打包成 Skill。

參考連結：

Codex vs Claude Code：兩套 Subagent 機制怎麼選

Fri, 08 May 2026 14:14:01 +0800

現在的 AI 編程工具越來越重視 Subagent。這不是功能跟風，而是單個 Agent 處理真實工程任務時，很快會碰到邊界。

如果一個 Agent 同時負責讀程式碼、查日誌、改實作、跑測試、分析錯誤、總結結果，主上下文很快會變髒。搜尋結果、命令輸出、測試日誌和中間推理混在一起，後續判斷就會被噪音干擾。任務也很難並行：探索、實作、驗證和審查都塞在同一條主線上。

Subagent 的本質，是替 Agent 減壓。主會話不再從頭到尾做完所有事，而是更像協調者：判斷目標、安排任務、接收結果，再把結果合成最終答案。子 Agent 處理某一段局部工作，例如探索、實作、驗證或審查，最後只帶回壓縮後的結論。

所以 Subagent 不是「再開一個同款自己」，而是把原本糊成一團的工程工作拆成邊界更清楚的角色。

底層共識

成熟的 Subagent 系統通常繞不開四件事：

上下文隔離。
角色專用化。
專案和使用者級配置。
工具與權限邊界。

上下文隔離是前提。真實倉庫裡的中間結果很多：搜尋結果、測試日誌、命令輸出都可能很吵。如果全部塞進主會話，主線很快會混亂。Subagent 的價值之一，就是讓局部過程先在局部被消化，主會話只看到有決策價值的結論。

角色專用化也很重要。多 Agent 不是多開幾個一樣的模型。探索型角色要擅長搜尋、閱讀和總結；實作型角色要專注改碼；驗證型角色要跑檢查、識別風險，並清楚回報。

工具和權限邊界決定系統能否安全落地。子 Agent 不應預設擁有主會話的全部能力。探索角色未必需要寫檔案，驗證角色未必需要改實作，背景任務和 worktree 隔離也應保持可見。

在這些共識之上，Codex 和 Claude Code 走出了不同路線。

Codex：顯式派工

Codex 的 Subagent 設計更克制。

它提供一套受控、輕量、圍繞當前主會話展開的分工機制。什麼時候派活、派給誰、什麼時候收結果，都由主會話明確決定。控制流始終留在當前任務裡。

它的特點是：

主會話明確發起委託。
角色集保持輕量。
主會話知道哪個 Agent 在做什麼。
結果回到主線後再統一判斷。
協作邊界透明。

這種方式適合重視手動編排、可預期性和執行確定性的團隊。可以先派探索角色查清調用鏈，再派工作角色做小範圍修改，最後由主會話整合結果並決定是否繼續測試。

缺點是編排壓力仍在主會話身上。主會話要判斷何時拆分、怎麼拆、交給誰、怎麼合併結果。輕量協作很舒服，但長期複雜工程流可能會變累。

Claude Code：正式工位

Claude Code 的取向更平台化。

它不是只提供幾個臨時幫手，而是把 Agent 做成可描述、可選擇、可配置、可記憶、可隔離、可背景執行的正式物件。子 Agent 不只是會話裡的工具，更像工程系統裡的一個工位。

系統可以把 Agent 列表、適用場景、描述資訊和工具邊界交給模型，讓模型判斷本輪該呼叫哪個角色。這類模型驅動的委託帶來更強自動化。

它的關鍵能力包括：

第一，角色體系。探索、規劃、通用處理、驗證等角色可以帶用途說明、工具限制、預設模型和執行條件。探索型角色可以只讀，規劃型角色負責方案，驗證型角色專注檢查。

第二，繼承和覆蓋。子 Agent 預設繼承主會話的大邊界，但可在規則允許範圍內做局部調整。主會話定義大邊界，Agent 在邊界內局部裝配。

第三，記憶。記憶可以有作用域：使用者級記憶像長期偏好，專案級記憶像倉庫背景，本地級記憶像當前環境狀態。某些 Agent 不必每次從零理解專案。

第四，背景和 worktree 隔離。某些驗證任務可以在背景持續執行，主線不用原地等待。需要強隔離時，Agent 可進入獨立 worktree，同一專案內操作空間被明確隔開。

第五，插件生態。當 Agent 是正式物件時，就需要考慮分發、安裝、覆蓋、排序和安全。插件 Agent 可以進入系統，但高風險欄位如 permission mode、hooks、MCP servers 應被收口。

這讓 Claude Code 更像 Agent runtime，而不是單次會話裡的協作工具。

怎麼選

Codex 更像受控分工工具：顯式派工、角色輕量、控制流清晰、子任務圍繞當前會話，適合強調確定性和人工編排的工作方式。

Claude Code 更像工程工位系統：Agent 被正式建模，角色更體系化，記憶、背景執行、隔離和插件都屬於 runtime，適合長期專案和平台化工作流。

真正的問題不是誰功能更多，而是你希望 Subagent 是「我明確叫來的助手」，還是「系統裡長期存在的工位」。

可以問兩個問題：

你能不能接受模型自己選擇該派誰幹活？
你是否需要更完整的 Agent runtime？

如果第一個問題讓你不舒服，顯式派工更合適。若第二個答案是肯定的，平台化工位系統更值得考慮。

使用建議

不要把 Subagent 當作「多開幾個模型就更強」。更有效的做法是：

給每個角色明確任務邊界。
控制每個角色可用工具。
讓子 Agent 回傳結論，而不是原始日誌。
主會話保留最終決策權。
讓背景任務和 worktree 隔離保持可見。
對插件 Agent 設定清楚安全邊界。

Subagent 的價值不在數量，而在分工品質。角色越清楚，上下文越乾淨，主線判斷越穩。

小結

Codex 和 Claude Code 都在解決同一個問題：單個 Agent 很難承載真實工程任務。它們都承認上下文隔離、角色專用、權限邊界和局部匯總的重要性。

差異在於取向。Codex 更克制，強調顯式派工和主會話控制；Claude Code 更體系化，把 Agent 做成可配置、可記憶、可隔離、可背景執行、可進入插件生態的正式工位。

選哪個，不是看哪個品牌贏，而是看你的工作方式需要受控協作工具，還是完整 Agent runtime。

9Router：把 Claude Code、Codex、Cursor 接到同一個 AI 路由器

Fri, 08 May 2026 13:41:15 +0800

9Router 是一個面向 AI 編程工具的本地路由器。它把 Claude Code、Codex、Cursor、Cline、Copilot、OpenCode、OpenClaw 等工具統一接到一個 OpenAI-compatible endpoint，再由 9Router 轉發到不同模型和服務商。

它不是另一個聊天客戶端，而是放在 AI 編程工具與模型服務之間，處理 API 格式、provider 切換、工具輸出耗 token、限流中斷、多帳號管理等問題。

根據專案說明，9Router 支援 40+ provider 和 100+ 模型，提供 RTK Token Saver、自動 fallback、額度追蹤、多帳號輪詢、格式轉換與請求日誌。專案使用 JavaScript 編寫，技術棧包括 Node.js、Next.js、React、Tailwind CSS 和 LowDB，授權為 MIT。

適合解決什麼問題

9Router 最適合你同時使用多個 AI 編程工具和多個模型來源的情況。

例如：

Claude Code 使用訂閱帳號。
Codex 或 Cursor 需要自訂 OpenAI endpoint。
Cline、Continue、RooCode 需要 OpenAI-compatible API。
免費 provider 用來日常嘗試。
GLM、MiniMax、Kimi 等便宜 API 作為備用。
高品質模型只在複雜任務時使用。

沒有 9Router 時，這些配置會分散在不同工具裡。9Router 的思路是讓工具都訪問同一個本地地址，再在路由器中配置 provider、combo 和優先級。

預設本地地址：

`1`	`http://localhost:20128/v1`

Dashboard：

`1`	`http://localhost:20128/dashboard`

快速安裝

本機使用可以直接透過 npm：

1
2

npm install -g 9router
9router

從原始碼執行：

git clone https://github.com/decolua/9router.git
cd 9router
cp .env.example .env
npm install
PORT=20128 NEXT_PUBLIC_BASE_URL=http://localhost:20128 npm run dev

生產模式：

1
2

npm run build
PORT=20128 HOSTNAME=0.0.0.0 NEXT_PUBLIC_BASE_URL=http://localhost:20128 npm run start

npm 包要求 Node.js >=18.0.0。部署到 VPS 或 Docker 時，建議配置 JWT_SECRET、INITIAL_PASSWORD、DATA_DIR、API_KEY_SECRET 等環境變數。

接入 AI 編程工具

常見配置如下：

1
2
3

Base URL: http://localhost:20128/v1
API Key: 從 9Router Dashboard 複製
Model: 在 9Router 中配置的模型名或 combo 名

Codex CLI：

export OPENAI_BASE_URL="http://localhost:20128"
export OPENAI_API_KEY="your-9router-api-key"

codex "your prompt"

Cline、Continue、RooCode 可選 OpenAI Compatible：

1
2
3

Base URL: http://localhost:20128/v1
API Key: your-9router-api-key
Model: cc/claude-opus-4-7

模型名前綴取決於已連接的 provider，例如 cc/、cx/、gh/、glm/、minimax/、kr/、vertex/。

RTK Token Saver

AI 編程工具最耗 token 的地方常常是工具輸出，例如：

git diff
git status
grep
find
ls
tree
日誌
大段檔案列表

9Router 內建 RTK Token Saver，會在請求送到模型前壓縮這類內容。專案說明稱很多請求可節省 20%-40% input tokens。

這個功能不要求更換模型，也不改變上層工具使用方式。不過遇到關鍵日誌、完整檔案內容或高風險任務時，仍建議先測試壓縮後的回答品質。

自動 fallback

9Router 可以按優先級組合模型：

1
2
3

1. 訂閱模型
2. 便宜 API
3. 免費 provider

當第一層額度用完、限流或出錯時，自動切到下一層。

1
2
3

1. cc/claude-opus-4-7
2. glm/glm-5.1
3. kr/claude-sonnet-4.5

fallback 會影響輸出一致性。大型重構、協議實作、資料庫遷移等任務，最好固定主模型，失敗時再手動切換。

免費 provider 要謹慎

README 提到 Kiro、OpenCode Free、Vertex 等免費路徑，也提醒部分舊免費層已變化或不再推薦。使用前要確認服務條款、區域限制、第三方工具接入政策、封號風險與額度期限。

9Router 管理的是路由，不會改變上游 provider 的規則。

本地與部署建議

個人使用時，最簡單是只監聽 localhost。如果部署到 VPS 或局域網，建議修改預設密碼、設定強 JWT_SECRET、設定 API_KEY_SECRET、不要把 Dashboard 裸露到公網，並對 /v1/* 啟用 Bearer API key。

Docker 示例：

docker run -d \
  --name 9router \
  -p 20128:20128 \
  --env-file ./.env \
  -v 9router-data:/app/data \
  -v 9router-usage:/root/.9router \
  9router

先在本機跑通 provider、combo、工具接入和日誌，再決定是否遷移到伺服器。

適合誰用

9Router 適合同時使用多個 AI 編程工具、多個 provider、多個價格層，並希望統一 fallback 策略的重度使用者。如果你只用一個工具和一個模型，它可能反而增加複雜度。

小結

9Router 可以理解為 AI 編程工具的本地閘道。Claude Code、Codex、Cursor、Cline 等工具連到 http://localhost:20128/v1，由它處理模型選擇、格式轉換、token 壓縮、額度追蹤和 fallback。

參考資料

Claude Code 24 個使用技巧：計劃模式、回滾、CLAUDE.md、Skills、Agents 和插件

Fri, 08 May 2026 08:54:14 +0800

Claude Code 不只是一個聊天框。它更像一個能進入專案目錄、讀寫檔案、執行命令、維護上下文的編程 Agent。

如果只是把需求丟進去讓它生成程式碼，很快會遇到幾個問題：計劃不夠清楚、權限反覆確認、上下文越來越長、生成結果不滿意、不知道怎麼回滾，也不知道怎麼把專案規則長期保存下來。

下面整理一組常用操作，適合剛開始使用 Claude Code 的開發者快速建立工作流。

先在專案目錄啟動

Claude Code 最好在專案目錄裡啟動，而不是隨便打開一個終端就開始用。

可以先建立一個資料夾作為專案目錄，進入目錄後打開命令列，再啟動 Claude Code：

claude

首次進入專案時，如果 Claude Code 詢問是否信任目前資料夾，確認後再繼續。這樣它才能圍繞目前專案讀取檔案、建立檔案和執行後續操作。

一個簡單的練習方式是讓它建立一個攝影師個人網站。這個任務足夠直觀：能看到頁面效果，也能練習檔案生成、命令執行、回滾和後續重構。

計劃模式先把方向想清楚

Claude Code 在面對較複雜任務時會進入計劃模式。計劃模式的作用是先討論需求、拆解步驟，再讓使用者決定是否批准執行。

當它給出計劃後，通常會出現幾類選擇：

批准計劃，並允許後續自動使用編輯工具。
批准計劃，但後續編輯仍然需要手動確認。
暫停執行，繼續和 Claude Code 討論計劃。

如果任務比較明確，可以批准計劃並繼續。如果任務還不清楚，建議先讓它繼續補充方案，比如頁面風格、技術棧、目錄結構、互動效果和驗收標準。

計劃模式的好處是減少返工。直接讓 Agent 動手，可能很快生成一堆檔案；但如果方向錯了，後面越改越亂。

用 Shift + Tab 切換模式

在 Claude Code 中，可以用 Shift + Tab 在不同工作模式之間切換。常見用途是進入計劃模式，或者切換到自動同意編輯工具的模式。

建議的習慣是：

新專案、新功能、大改動：先進入計劃模式。
小改動、明確修復：可以直接執行。
涉及刪除、批量替換、安裝依賴：保持人工確認。

計劃模式下，Claude Code 可能會主動詢問專案細節。可以用方向鍵選擇選項，用回車確認。提交回饋後，它會根據你的選擇更新計劃。

權限確認不要一律放開

Claude Code 執行命令、編輯檔案或啟動程式時，可能會申請權限。

常見選擇包括：

只同意本次使用。
在目前會話中以後都同意同類命令。
拒絕或暫停。

如果只是啟動本地頁面、運行開發伺服器、查看檔案，可以根據需要允許。但不要為了省事長期使用「自動同意所有權限」的啟動方式。

全自動權限適合非常確定、風險很低、專案已經有 Git 備份的場景。日常使用中，涉及刪除檔案、覆蓋目錄、安裝依賴、聯網、提交程式碼、執行腳本時，最好保留人工確認。

用終端模式執行本地命令

Claude Code 裡可以進入終端命令模式，直接執行一些本地命令。

例如頁面生成後，可以用系統命令打開 HTML 檔案：

`1`	`start index.html`

這裡的 start 是 Windows 下打開檔案的命令，後面接檔名。這樣可以快速查看生成頁面，而不用手動去資源管理器裡找檔案。

終端模式適合執行這些輕量操作：

打開生成的頁面。
查看目錄內容。
啟動本地開發伺服器。
運行測試或構建命令。

但高風險命令仍然要謹慎，比如遞歸刪除、移動目錄、批量覆蓋和修改系統環境。

回滾：結果不滿意時及時退回

如果 Claude Code 做出的頁面或程式碼不是你想要的，而且越改越亂，就應該及時回滾。

回滾功能可以把對話或程式碼退回到某個節點。常見選項包括：

同時回滾程式碼和對話。
只回滾對話。
只回滾程式碼。
把某個節點之前的內容壓縮成摘要。
取消操作。

更推薦在明顯走偏時選擇「同時回滾程式碼和對話」。這樣可以讓上下文和檔案狀態一起回到較乾淨的位置。

需要注意：Claude Code 的回滾通常只能覆蓋它透過內建工具建立或修改的檔案。如果檔案是透過外部命令生成的，未必能完整回滾。因此重要專案仍然要配合 Git 使用。

長提示詞用編輯器寫

複雜需求不要全擠在一行輸入框裡。

如果系統支援在文字編輯器中編輯長提示詞，可以打開編輯器，把需求寫完整後保存，再發送給 Claude Code。

長提示詞裡建議寫清楚：

目標是什麼。
使用什麼技術棧。
不要做什麼。
需要保留哪些檔案。
完成後如何驗證。
頁面或功能的驗收標準。

例如讓 Claude Code 把一個普通 HTML 頁面重構成更現代的技術棧時，不要只寫「重構一下」。可以說明希望使用元件化結構、保留視覺內容、增加響應式布局，並要求它運行構建檢查。

退出後用歷史恢復會話

如果中途需要退出 Claude Code，可以正常退出。之後回到同一個專案目錄，再次啟動：

claude

如果發現前面的記錄沒有直接顯示，可以使用歷史相關命令查看最近會話，並載入之前的會話。

這個功能適合中斷後繼續工作。不過不要把會話歷史當成唯一記憶。專案規則、技術棧、常用命令和注意事項，最好寫進專案檔案裡。

用 CLAUDE.md 保存專案規則

CLAUDE.md 是 Claude Code 很重要的記憶檔案。它通常放在專案根目錄，用來告訴 Claude Code 專案規則、技術棧、目錄結構和協作約束。

可以讓 Claude Code 初始化這個檔案：

/init

CLAUDE.md 適合記錄：

專案目標。
技術棧。
常用啟動、測試、構建命令。
目錄說明。
程式碼風格。
不允許執行的操作。
提交和部署規則。

每次對話時，Claude Code 會把這類規則作為上下文的一部分使用。你可以把它理解成「專案說明書」。

一個簡單驗證方式是：在 CLAUDE.md 裡加入一條明顯規則，然後再向 Claude Code 提問。如果回答遵循了這條規則，就說明它確實讀到了專案記憶。

用 @ 引用檔案

在輸入框中使用 @，可以選擇檔案或 Agent，把指定內容加入目前對話上下文。

這適合幾類場景：

讓 Claude Code 閱讀某個配置檔案。
讓它修改某個指定頁面。
讓它根據 CLAUDE.md 或其他文件繼續工作。
明確告訴它「只看這個檔案，不要猜專案結構」。

相比把檔案內容複製到輸入框裡，@ 引用更清楚，也更不容易漏內容。

查看和壓縮上下文

長時間對話後，上下文會越來越大。上下文太長時，模型可能變慢，也可能開始忽略早期細節。

可以使用上下文查看命令了解目前占用情況：

`1`	`/context`

如果上下文已經很長，可以壓縮歷史：

`1`	`/compact`

如果壓縮後效果仍然不好，可以考慮清空目前上下文：

/clear

清空上下文後，Claude Code 仍然可以透過專案檔案、CLAUDE.md 和目前目錄重新理解一部分專案情況，但不會保留完整對話歷史。

實用建議是：一個任務完成後就開新會話；專案級規則寫進 CLAUDE.md；臨時討論不要無限堆在一個聊天裡。

Skills：把固定流程做成說明書

Skills 可以理解為 Claude Code 的工作說明書。它不是一次性提示詞，而是一套可複用的任務流程。

例如你經常要生成週報，就可以建立一個週報 Skill，裡面寫清楚：

輸入需要哪些資訊。
輸出格式是什麼。
語氣和結構怎麼控制。
哪些內容必須保留。
哪些內容不能編造。

Skills 通常由 name、description 和具體指令組成。安裝到全域 Skills 目錄後，Claude Code 在遇到相關任務時可以識別並載入。

這適合處理重複工作：

週報。
程式碼審查模板。
文件整理。
圖片批次處理。
固定格式文章。
專案初始化流程。

如果你發現自己反覆複製同一段提示詞，就可以考慮把它做成 Skill。

Agents：把子任務交給獨立助手

Agents 和 Skills 不一樣。

Skill 更像說明書，告訴 Claude Code 怎麼做某類任務；Agent 更像一個獨立助手，可以在目前主會話之外執行任務，完成後把結果返回。

Agents 的價值在於隔離上下文。比如做程式碼巡檢時，可以建立一個唯讀 Agent，讓它只讀取專案並輸出報告，不直接修改檔案。這樣不會污染主會話，也能降低誤操作風險。

建立 Agent 時通常要考慮：

是專案級 Agent，還是使用者級 Agent。
是否需要 Claude Code 幫你生成配置。
允許哪些工具權限。
使用哪個模型。
是否保存記憶。
Agent 的提示詞是否足夠明確。

對於程式碼巡檢類 Agent，建議只給讀取權限，不給寫入權限。先讓它輸出報告，再由主會話決定是否修改程式碼。

插件：打包 Skills、Agents、MCP 和 Hooks

插件可以理解為更完整的能力包。它可能同時包含：

Skills
Agents
MCP
Hooks

相比單獨安裝一個 Skill，插件更適合成套能力。例如前端設計插件可能會把頁面審美、布局規則、元件習慣和相關 Agent 一起打包。

安裝插件時通常會有幾個位置選項：

如果是個人常用能力，可以放在使用者目錄；如果是團隊專案約定，可以放進專案目錄；如果只是臨時測試，放本地專案目錄更穩。

插件能明顯改善特定任務效果

在前端頁面生成這類任務裡，插件往往比裸提示詞更穩定。

例如同樣是「製作一個攝影師個人網頁」，只用普通提示詞可能生成一個能看的頁面；如果明確使用前端設計插件，頁面結構、視覺層次、間距、配色和整體完成度通常會更好。

這並不意味著插件能替代人工審美。更合理的用法是：先讓插件生成一個更好的初稿，再由人做細節微調。

一套更穩的 Claude Code 工作流

把上面這些技巧組合起來，可以形成一套比較穩的流程：

在專案目錄啟動 claude。
先用計劃模式討論需求。
批准計劃前確認技術棧和驗收標準。
涉及高風險操作時保留手動確認。
用終端模式執行本地預覽和測試。
結果走偏時及時回滾。
把專案規則寫進 CLAUDE.md。
長對話定期查看和壓縮上下文。
重複流程沉澱成 Skills。
巡檢、研究、分析類任務交給唯讀 Agents。
特定領域任務優先用插件。
重要專案始終配合 Git 提交點。

這樣使用 Claude Code，會比單純「發一句需求等它生成」穩定得多。

小結

Claude Code 的效率不只來自模型能力，也來自工作流控制。

計劃模式決定方向，權限確認控制風險，回滾減少返工，CLAUDE.md 保存專案規則，/context、/compact 和 /clear 管理上下文，Skills 複用固定流程，Agents 隔離複雜子任務，插件則把成套能力打包進專案。

真正好用的 Claude Code 工作方式，是讓它在清楚邊界內持續推進任務，而不是把整個專案一次性交給它自由發揮。

opencode、Claude Code、Codex 有什麼區別？開源 AI 編程工具使用指南

Fri, 08 May 2026 08:33:37 +0800

opencode 是 anomalyco 開源的 AI Coding Agent。它的定位很直接：讓開發者在終端裡使用一個可程式化、可擴充、可接入多家模型的程式碼助手。

如果把它和 Claude Code、Codex 放在一起看，三者解決的是同一類問題：讓 AI 進入真實程式碼庫，理解上下文，修改檔案，執行命令和測試。但它們的產品取向不一樣。

opencode 更強調開源、多模型和終端 TUI；Claude Code 更強調 Anthropic 模型生態和本地工程協作；Codex 則是 OpenAI 的 AI coding agent，可以在終端、IDE、Codex app 和雲端任務裡使用。

opencode 適合誰

opencode 更適合這幾類開發者：

想在終端裡完成程式碼修改、專案分析和工程任務的人。
希望 AI Coding Agent 不綁定單一模型提供商的人。
偏好開源工具，想自己審計、擴充或二次開發的人。
已經習慣 Neovim、TUI、命令列工作流的人。
希望以後用桌面端、行動端或其他客戶端遠端驅動同一個編碼代理的人。

它的重點不是做一個聊天視窗，而是把 AI 編程能力放進開發者原本使用的終端和專案目錄裡。

安裝方式

官方 README 提供了多種安裝方式。

# 直接安裝
curl -fsSL https://opencode.ai/install | bash

# npm
npm i -g opencode-ai@latest

# Windows
scoop install opencode
choco install opencode

# macOS 和 Linux
brew install anomalyco/tap/opencode
brew install opencode

# Arch Linux
sudo pacman -S opencode
paru -S opencode-bin

# 其他方式
mise use -g opencode
nix run nixpkgs#opencode

官方也提醒，安裝前最好先移除 0.1.x 之前的舊版本，避免舊版本殘留造成問題。

安裝腳本會按優先級選擇安裝目錄：

$OPENCODE_INSTALL_DIR
$XDG_BIN_DIR
$HOME/bin
$HOME/.opencode/bin

如果需要指定路徑，可以這樣寫：

1
2

OPENCODE_INSTALL_DIR=/usr/local/bin curl -fsSL https://opencode.ai/install | bash
XDG_BIN_DIR=$HOME/.local/bin curl -fsSL https://opencode.ai/install | bash

桌面應用還在 Beta

除了命令列工具，opencode 也提供桌面應用，目前仍處於 Beta。可以從 GitHub Releases 或 opencode.ai/download 下載。

桌面端覆蓋這些平台：

平台	檔案
macOS Apple Silicon	`opencode-desktop-mac-arm64.dmg`
macOS Intel	`opencode-desktop-mac-x64.dmg`
Windows	`opencode-desktop-windows-x64.exe`
Linux	`.deb`、`.rpm` 或 `.AppImage`

macOS 和 Windows 也可以透過套件管理器安裝桌面端。

# macOS
brew install --cask opencode-desktop

# Windows
scoop bucket add extras
scoop install extras/opencode-desktop

兩種內建 Agent 模式

opencode 內建兩種 Agent，可以透過 Tab 鍵切換。

build 是預設模式，擁有完整開發權限，適合直接修改程式碼、執行命令和推進工程任務。

plan 是唯讀模式，更適合分析陌生程式碼庫、理解專案結構、制定修改方案。它預設拒絕檔案編輯，並且在執行 bash 命令前會詢問。

另外，opencode 還帶有一個 general 子 Agent，用於複雜搜尋和多步驟任務。使用者可以在訊息中輸入 @general 呼叫。

這個設計比較實用：真正動手前先用 plan 看清楚專案，需要改程式碼時再切到 build。對於大型倉庫，讀寫權限分開能減少誤操作。

Codex 是什麼

Codex 是 OpenAI 的 AI coding agent，用來幫助開發者寫程式碼、審查程式碼、修復 bug 和交付工程任務。

和單純的程式碼補全工具不同，Codex 更接近一個可以操作程式碼庫的 Agent。它可以在本地工具裡和你結對，也可以把任務委託到雲端執行。OpenAI 官方資料裡提到，Codex 可以透過 CLI、IDE、Codex app、ChatGPT/Codex 雲端等不同入口使用。

對開發者來說，Codex 的重點有幾處：

可以讀取程式碼庫、編輯檔案、執行命令和測試。
支援終端、IDE、應用和雲端等多種使用介面。
適合修 bug、寫功能、重構、遷移、程式碼審查和測試補齊。
更偏 OpenAI 帳號、模型和 Codex 產品體系。
雲端任務適合並行處理多個相對清晰的工程任務。

如果 opencode 更像一個開放的終端代理框架，Codex 更像 OpenAI 提供的一整套 AI 編程工作台：本地可以結對，雲端可以委託，團隊可以把它接入更長的工程流程。

三者核心區別

opencode、Claude Code、Codex 都是 AI 編程工具，但選擇時可以先看這幾個維度。

工具	核心定位	主要優勢	更適合
`opencode`	開源 AI Coding Agent	開源、多模型、TUI、客戶端/伺服器架構	想要開放工具鏈、可替換模型、偏終端工作流的開發者
`Claude Code`	Anthropic 的命令列編程工具	Claude 模型體驗、程式碼理解、長上下文、工程任務協作	已經使用 Claude/Anthropic 生態，希望本地推進程式碼任務的開發者
`Codex`	OpenAI 的 AI coding agent	CLI、IDE、Codex app、雲端任務、多 Agent 工作流	已經使用 ChatGPT/OpenAI，希望本地結對和雲端委託並用的團隊

簡單說，opencode 的關鍵詞是「開源和可替換」，Claude Code 的關鍵詞是「Claude 生態和本地工程代理」，Codex 的關鍵詞是「OpenAI 生態和多入口協作」。

和 Claude Code 的區別

opencode 的官方 FAQ 直接把 Claude Code 拿來對比。兩者能力上很接近，但差異主要在這幾處。

第一，opencode 是 100% 開源專案，程式碼託管在 GitHub，並使用 MIT license。

第二，opencode 不綁定單一模型提供商。它推薦 OpenCode Zen 提供的模型，但也可以搭配 Claude、OpenAI、Google 或本地模型。對開發者來說，這意味著模型成本、能力和可用性變化時，不必被某一個平台鎖住。

第三，opencode 內建可選的 LSP 支援。對程式碼補全、跳轉、診斷和專案理解來說，LSP 是非常關鍵的基礎能力。

第四，opencode 更強調 TUI。它由 Neovim 使用者和 terminal.shop 的建立者打造，產品重心明顯放在終端體驗上。

第五，opencode 採用客戶端/伺服器架構。也就是說，opencode 可以在你的電腦上執行，未來由 TUI、桌面端、行動端或其他客戶端來控制。TUI 只是其中一種前端形態。

什麼時候選 opencode、Claude Code 或 Codex

如果你已經在使用 Claude Code 或 Codex，opencode 不一定是立刻替換它們的工具。更合理的看法是：它提供了一個開源、可替換模型、偏終端的選擇。

可以優先考慮 opencode 的場景包括：

你希望 AI 編程工具盡量開源。
你不想把工作流綁定在某個模型供應商上。
你希望用同一個工具測試 Claude、OpenAI、Google 或本地模型。
你喜歡 TUI，不希望主要工作流被桌面應用或網頁應用打斷。
你關注客戶端/伺服器架構帶來的遠端控制能力。

可以優先考慮 Claude Code 的場景包括：

你主要使用 Claude 模型。
你重視長上下文、程式碼理解和複雜工程任務協作。
你希望在本地倉庫中持續推進修改、測試和重構。
你更信任 Anthropic 對 Claude Code 的預設產品體驗。

可以優先考慮 Codex 的場景包括：

你已經在使用 ChatGPT 或 OpenAI 帳號體系。
你希望同一個 coding agent 覆蓋終端、IDE、桌面應用和雲端任務。
你想把較清晰的 bug 修復、功能開發、遷移、測試補齊交給雲端並行處理。
你需要程式碼審查、背景任務、團隊協作和多 Agent 工作流。

如果你更看重官方閉環體驗、模型預設配置、企業管理和現成整合，Claude Code 或 Codex 可能更省心；如果你更看重可控性、開放性和 provider-agnostic，opencode 更值得關注。

需要注意的地方

opencode、Claude Code 和 Codex 都發展很快，GitHub release、安裝命令、桌面端檔名、模型可用性和方案權限都可能變化。實際安裝和選型前，最好直接查看各自官方 README、文件和發布頁面。

另外，它的桌面應用仍然標註為 Beta，不適合預設當作穩定生產工具。對於日常工程任務，終端版仍然是更主要的入口。

從工具趨勢看，opencode 代表的是 AI Coding Agent 的開放工具鏈方向：模型可以替換，客戶端可以替換，核心代理能力盡量開放。Codex 和 Claude Code 則更像模型公司把 coding agent 做成完整產品入口。對開發者來說，這兩條路線會長期並存。

參考連結

opencode GitHub：https://github.com/anomalyco/opencode
opencode 官網：https://opencode.ai
opencode 文件：https://opencode.ai/docs
opencode Releases：https://github.com/anomalyco/opencode/releases
OpenAI Codex：https://openai.com/codex/
Using Codex with your ChatGPT plan：https://help.openai.com/en/articles/11369540-codex-in-chatgpt
OpenAI Codex CLI Getting Started：https://help.openai.com/en/articles/11096431-openai-codex-ci-getting-started

Claude Opus 4.7、Sonnet 4.6、Haiku 4.5 有什麼區別？Claude 模型選擇指南

Fri, 08 May 2026 08:19:03 +0800

Anthropic 的核心大模型主要透過 Claude 系列迭代。到 2026 年 5 月，Claude 的主流產品線已經進入 4.x 階段，整體仍然延續三檔定位：Opus 負責最高能力，Sonnet 負責效能與成本平衡，Haiku 負責速度和性價比。

如果只想快速選型，可以先記住一句話：

最複雜、最重的推理和 agentic coding：優先看 Claude Opus 4.7。
大多數開發、寫作、分析和企業 API 場景：從 Claude Sonnet 4.6 開始最穩。
高併發、低延遲、成本敏感任務：考慮 Claude Haiku 4.5。

當前主流模型

根據 Anthropic 官方模型文件，當前 Claude 主流模型可以這樣理解。

模型	定位	適合場景
`Claude Opus 4.7`	當前最強的通用可用模型，面向複雜推理和 agentic coding	大型程式碼庫重構、多步驟任務、複雜策略分析、要求更高一致性的工作
`Claude Sonnet 4.6`	速度、能力和成本的平衡點，支援 100 萬 token 上下文視窗	程式碼生成、長文件分析、企業知識工作、Agent 開發、日常高品質生產任務
`Claude Haiku 4.5`	速度最快、成本更低的小模型，但仍有接近前沿模型的能力	即時對話、客服、批次分類、簡單程式碼協作、高併發 API 呼叫

這裡需要注意兩個命名細節。

第一，官方名稱是 Claude Haiku 4.5，不是 Claude 4.5 Haiku。第二，Claude Mythos Preview 不是普通使用者或開發者的主流可用模型，它是 Project Glasswing 相關的受控研究預覽，主要面向防禦性網路安全工作流，不應和常規 Claude 模型混在一起選型。

Opus：處理最難的問題

Opus 是 Anthropic 給最強模型使用的檔位。Claude Opus 4.7 的重點不是便宜，也不是最快，而是更適合處理複雜、多步驟、需要反覆校驗的任務。

它更適合這些情況：

跨很多檔案的大型程式碼修改。
複雜系統重構和架構推理。
長鏈路 Agent 任務。
需要更強視覺理解、文件理解和多輪規劃的工作。
對錯誤成本比較敏感的企業分析任務。

如果一個任務失敗一次的代價很高，或者你希望模型在開始動手前花更多時間理解上下文，Opus 通常更值得嘗試。

Sonnet：多數人的預設起點

Claude Sonnet 4.6 是更適合作為預設入口的模型。它的定位不是「低配 Opus」，而是把足夠強的推理、程式設計、視覺理解、長上下文和 agent planning 放在更可控的成本與速度裡。

對開發者來說，Sonnet 4.6 的價值主要在三點：

能處理很長的上下文，適合放入程式碼庫、合約、報告或多篇資料。
在 Claude Code、API 和企業場景中更容易作為常用模型。
成本低於 Opus，更適合高頻使用。

如果你不知道該從哪個 Claude 模型開始，通常可以從 Claude Sonnet 4.6 開始。只有在任務明顯需要更強能力時，再切到 Opus。

Haiku：快和便宜更重要時

Claude Haiku 4.5 是小模型檔位，但不能簡單理解成「弱模型」。Anthropic 對它的定位是快速、低成本，同時保留接近前沿模型的能力。

它適合這些場景：

即時聊天和客服機器人。
大量短文字分類。
低延遲 API 呼叫。
簡單程式碼修改和快速原型。
多 Agent 工作流中的子任務執行。

如果任務本身很清楚、上下文不複雜、需要吞吐量，Haiku 往往比盲目使用更大的模型更合理。

Claude 的工具能力

Claude 系列不只是聊天模型。Anthropic 現在把模型能力放進了多種產品和開發工具裡。

Claude Code 是面向開發者的命令列程式設計工具，可以讀取程式碼庫、編輯檔案、執行命令和測試，適合持續推進工程任務。它的體驗很依賴模型本身的程式碼理解、上下文管理和工具呼叫穩定性。

Computer Use 是讓模型透過截圖、滑鼠和鍵盤操作桌面環境的能力。它仍然需要謹慎使用，官方文件也強調要放在隔離環境中執行，避免誤操作或安全風險。

Artifacts 更偏向 Claude 應用側體驗，可以把程式碼、頁面原型、圖表或文件結果放在介面中預覽和迭代。它不是一個單獨模型，而是 Claude 產品形態的一部分。

至於「Managed Agents」或「自我進化 Agent」這類說法，寫文章時要謹慎。Anthropic 確實在強化 Agent SDK、Claude Code、長上下文、工具呼叫和企業工作流，但不要把它描述成已經具備不受控自我進化能力。

存取方式

普通使用者可以透過 Claude.ai 網頁端或行動端使用 Claude，不同方案會影響可用模型、額度和功能。

開發者通常有幾種接入方式：

Anthropic Console 和 Claude API。
Amazon Bedrock。
Google Cloud Vertex AI。
Microsoft Foundry。

具體可用模型、上下文視窗、價格和地區支援會變化，開發前最好以 Anthropic 官方模型文件和對應雲平台頁面為準。

怎麼選

實際使用時，不需要一開始就追求最強模型。更好的方式是按任務成本分層。

如果是日常寫作、程式碼生成、長文件分析、知識整理和大多數 Agent 原型，先用 Claude Sonnet 4.6。它通常是性價比和通用能力的最佳起點。

如果任務需要更強的複雜推理、跨檔案工程修改、長鏈路規劃或更高可靠性，再切到 Claude Opus 4.7。

如果任務簡單、數量大、對延遲敏感，例如分類、摘要、客服、批次處理，就把 Claude Haiku 4.5 放進候選。

Claude 的模型線不是單純的「新版本替代舊版本」，而是一套按任務難度、速度和成本分層的工具箱。選對模型，比盲目使用最貴模型更重要。

參考連結

Anthropic Models Overview：https://platform.claude.com/docs/en/about-claude/models/overview
Introducing Claude Opus 4.7：https://www.anthropic.com/news/claude-opus-4-7
Introducing Claude Sonnet 4.6：https://www.anthropic.com/news/claude-sonnet-4-6
Introducing Claude Haiku 4.5：https://www.anthropic.com/news/claude-haiku-4-5
Anthropic Computer Use Tool：https://docs.anthropic.com/en/docs/build-with-claude/computer-use

ChatGPT、Claude Code 和 Gemini 的記憶機制有什麼不同？

Thu, 07 May 2026 14:47:17 +0800

AI 產品裡的「記憶」正在變得越來越重要。它標誌著 AI 從「單次對話工具」走向「長期協作夥伴」：不用每次重新介紹背景，不用反覆解釋偏好，也不用讓模型一次次重新理解項目。

但不同產品裡的記憶並不是一回事。ChatGPT、Claude Code 和 Gemini 都在解決「AI 如何記得更久」的問題，但它們的設計目標、儲存位置、透明度和適用場景差異很大。

截至 2026 年 5 月 7 日，可以把它們粗略理解成三類：

ChatGPT 更像「個人助理記憶」。
Claude Code 更像「工程項目記憶」。
Gemini 更像「Google 生態上下文」。

ChatGPT：圍繞人的長期偏好

ChatGPT 的記憶機制主要面向個人協作。它關心的是「你是誰」「你偏好什麼」「你長期在做什麼」。

OpenAI 目前把 ChatGPT 的記憶分成兩類：saved memories 和 chat history。

saved memories 是 ChatGPT 保存下來的重要資訊，比如你的名字、偏好、目標、常用技術棧、寫作習慣等。你可以直接要求它記住某件事，它也可能在對話中自動保存它認為未來有用的資訊。

chat history 則是讓 ChatGPT 在回答時參考過去聊天。它不等於把每一段聊天都完整變成記憶，而是在需要時從過往對話裡找相關上下文。

所以 ChatGPT 的核心邏輯是：跨會話理解同一個使用者。

典型例子包括：

「以後給我程式碼示例時盡量簡潔。」
「我主要使用 Python 和 TypeScript。」
「我正在寫一個關於 AI 工具的 Hugo 部落格。」
「我喜歡先看結論，再看細節。」

這些記憶不是綁定某個單獨項目，而是跟隨帳號和個人使用習慣。

Memory Sources：讓個性化來源更可見

OpenAI 在 2026 年 5 月的更新中強調了 Memory sources。

它的作用不是新增另一種記憶，而是讓使用者看到 ChatGPT 在個性化回答時參考了哪些來源。根據 OpenAI 幫助文件，Memory Sources 可能顯示：

過去聊天。
保存記憶。
自定義指令。
文件庫中的文件。
已連接 Gmail 中的郵件。

其中，文件和 Gmail 的可見範圍會受到計畫、地區和連接狀態限制。OpenAI 也明確說明，Memory sources 不一定展示影響回答的所有因素，而是幫助使用者理解和管理個性化。

這一步很重要。因為 AI 越會「記住你」，使用者越需要知道它到底根據什麼在回答。否則個性化很容易變成黑箱：你感覺它好像知道你，但不知道它為什麼知道。

ChatGPT 的優勢是跨會話、跨主題持續理解個人偏好；風險是記憶容易過期，或者使用者忘了某條舊記憶還在影響回答。因此，適合定期清理 saved memories 和舊聊天。

Claude Code：圍繞程式碼庫和工程規則

Claude Code 的記憶機制更偏工程協作。它關心的不是「使用者平時愛喝什麼咖啡」，而是「這個程式碼庫應該怎麼改」。

Claude Code 有兩類容易混在一起的記憶：

顯式項目記憶：CLAUDE.md。
自動項目記憶：Auto Memory。

CLAUDE.md 是最基礎、最穩定的項目記憶文件。它可以放在項目根目錄，也可以在子目錄中存在。Claude Code 會讀取這些文件，把它們作為項目說明和操作規則。

適合寫進 CLAUDE.md 的內容包括：

常用構建、測試、lint 命令。
程式碼風格和命名規則。
項目架構說明。
模組邊界和危險區域。
團隊約定和提交流程。

如果 CLAUDE.md 放在程式碼庫裡，它可以提交到 Git，成為團隊共享的 agent 說明書。這一點和 ChatGPT 的雲端個人記憶完全不同。

Claude Code Auto Memory：自動累積項目經驗

Claude Code 現在也有 Auto Memory。它的目標是讓 Claude 在多個會話之間自動累積項目經驗，而不要求使用者每次手寫說明。

根據 Claude Code 文件，Auto Memory 會讓 Claude 在工作過程中為自己保存筆記，例如構建命令、調試發現、架構說明、程式碼風格偏好和工作流習慣。它不會每個會話都保存，而是判斷哪些資訊未來可能有用。

這裡有一個容易誤解的點：Auto Memory 預設不是把內容寫到項目根目錄的 .claude/memory.md。官方文件說明，每個項目會在使用者目錄下擁有自己的 memory 目錄，路徑類似：

`1`	`~/.claude/projects/<project>/memory/`

其中 MEMORY.md 會在每次對話開始時載入前 200 行或前 25KB，詳細內容則可能被拆到其他主題文件裡。Auto Memory 文件是本機本地的 Markdown 文件，使用者可以透過 /memory 查看、編輯或刪除。

這讓 Claude Code 的記憶更像「本機上的項目經驗庫」。它比 ChatGPT 的個人記憶更貼近程式碼庫，也比單純的 CLAUDE.md 更動態。

但要注意，Auto Memory 是機器本地的，不會天然跟隨程式碼庫同步到其他機器或雲環境。如果要團隊共享穩定規則，仍然應該優先寫進項目中的 CLAUDE.md。

Gemini：圍繞 Google 生態上下文

Gemini 的記憶邏輯又不同。

Gemini 也有保存資訊和參考過去聊天的能力。Google 幫助文件提到，使用者可以保存關於生活、工作或偏好的資訊，也可以讓 Gemini 在回答前參考過去聊天。Gemini 使用這些資訊時，可能會在回答底部的來源區域顯示 Your saved info 或 Previous chats。

但 Gemini 的差異化不只在「保存幾條偏好」，而在 Google 生態整合。

在使用者授權和功能可用的前提下，Gemini 可以透過連接的 Google 應用獲取上下文，例如 Gmail、Google Drive、Docs、Sheets 等。它的優勢不是讓使用者一條條教它記住什麼，而是把已有的 Google 帳號資料變成可檢索的工作上下文。

典型區別是：

ChatGPT 記得：「我最近在做 LTO 磁帶機修復。」
Gemini 可能可以從 Gmail 找到購買確認郵件，或從 Drive 裡讀取相關維修筆記。

當然，這不代表 Gemini 可以無條件讀取你所有 Google 資料。它取決於帳號類型、地區、權限、連接應用、Keep Activity 設定和具體產品可用性。對企業或學校帳號，還可能受 Google Workspace 管理員控制。

所以更準確地說，Gemini 的記憶不是一個單純的「備忘錄」，而是「保存資訊 + 過去聊天 + Google 生態連接」的組合。

三者核心差異

維度	ChatGPT	Claude Code	Gemini
核心對象	人和偏好	項目和程式碼庫	Google 帳號與生態資料
典型記憶	偏好、背景、長期目標	架構、命令、規範、調試經驗	saved info、過去聊天、Gmail/Drive/Docs 上下文
儲存形態	OpenAI 帳戶內的記憶和聊天上下文	`CLAUDE.md`、`MEMORY.md`、本地 Markdown 文件	Google 帳號活動、保存資訊、連接應用資料
透明度	Memory sources 可見一部分來源	Markdown 文件可直接查看和編輯	透過來源提示、Gemini Apps Activity 和 Google 設定管理
跨項目能力	強，跟隨使用者帳號	弱，主要跟隨項目或本機項目 memory	強，取決於 Google 生態資料和權限
團隊共享	不適合直接共享	`CLAUDE.md` 可隨 Git 共享	主要依賴 Workspace 和權限體系
最適合	個人偏好和長期助理	長期程式碼項目和 agent 協作	Google Workspace 資料檢索和跨工具工作

該怎麼選擇和使用

如果你想讓 AI 記住「我是誰、我喜歡什麼風格、我長期怎麼工作」，ChatGPT 的記憶更合適。

它適合保存個人偏好，例如寫作風格、常用技術棧、回答格式、職業背景、長期項目方向。它的重點是減少自我介紹成本，讓每次新對話更快進入狀態。

如果你想讓 AI 記住「這個程式碼庫怎麼改、哪些命令能跑、哪些坑不能踩」，Claude Code 更合適。

穩定規則寫進 CLAUDE.md，團隊共享；動態經驗交給 Auto Memory 輔助累積；關鍵決策最好仍然整理進文件或 CLAUDE.md，避免只停留在本機自動記憶裡。

如果你的資料大量存在 Gmail、Drive、Docs、Sheets 裡，Gemini 的生態上下文更有優勢。

它適合查找過去郵件、整理 Google Drive 文件、聯動日曆和辦公資料。使用 Gemini 的關鍵，不是反覆在聊天裡提醒它，而是確保相關應用連接、權限和活動設定正確。

一個實用分工

可以把三者這樣分工：

ChatGPT 記住「我的通用偏好」。
Claude Code 記住「這個倉庫的工程知識」。
Gemini 檢索「我在 Google 生態裡的資料」。

也就是說，ChatGPT 更像私人秘書，Claude Code 更像項目裡的資深工程同事，Gemini 更像 Google 帳號裡的資料索引員。

這三種記憶沒有絕對高低，只是目標不同。

最需要警惕的是把它們混為一談。個人偏好不一定適合寫進項目記憶；項目架構不一定適合存在雲端個人記憶；Google 生態檢索也不等於模型真正「長期理解」了你。

簡短判斷

AI 記憶的下一階段，不是簡單地「記得越多越好」，而是記憶要分層、可見、可控。

ChatGPT 的重點是跨會話個人化，Claude Code 的重點是程式碼項目連續性，Gemini 的重點是 Google 生態上下文。真正好用的長期 AI 協作，不是把所有資訊塞進一個黑箱，而是讓不同類型的記憶待在合適的位置。

個人偏好放在個人記憶裡，工程規則放在程式碼庫裡，歷史資料放在原本的文件和郵件系統裡。AI 要做的，是在需要時準確呼叫這些上下文，而不是把所有東西混成一團。

Anthropic 提高 Claude 使用額度，並與 SpaceX 擴充算力

Thu, 07 May 2026 14:26:14 +0800

Anthropic 在 2026 年 5 月 6 日宣布，提高 Claude Code 和 Claude API 的部分使用額度，同時披露與 SpaceX 達成新的算力合作。

這條消息表面上是「額度變多了」，但真正值得看的，是模型公司正在把產品體驗、訂閱價格、API 限流和基礎設施供應綁在一起。對重度使用者來說，算力不是抽象概念，而是能不能跑更多 Claude Code 任務、能不能少排隊、能不能穩定呼叫 Opus 模型。

Claude Code 和 API 額度怎麼變

Anthropic 這次公布了三項變化，並表示都從公告當天開始生效。

第一，Claude Code 面向 Pro、Max、Team 和按席位計費的 Enterprise 方案，把五小時視窗內的使用限制提高到原來的兩倍。

這對 Claude Code 的重度使用者很直接。過去如果在短時間內讓 Claude Code 連續讀程式碼、改程式碼、跑任務，很容易碰到五小時額度限制。額度翻倍後，同一段工作時間內能承載更多連續開發任務。

第二，Pro 和 Max 帳戶不再受 Claude Code 高峰時段額度下調影響。

這點比數字本身更重要。很多 AI 工具最影響體驗的，不是平時額度，而是高峰期突然變慢、變少、變不穩定。取消高峰時段的限制下調，說明 Anthropic 想讓付費使用者在忙時也有更可預期的體驗。

第三，Anthropic 提高了 Claude Opus 模型的 API rate limits。原文中相關數值以表格圖片展示，核心結論是 Opus API 的呼叫上限被明顯上調。

從開發者角度看，Opus 一直是更貴、更重、能力也更強的模型。提高 Opus API 限額，意味著 Anthropic 不只想讓使用者在聊天介面裡多用 Claude，也希望更多企業和開發者把 Opus 放進真實業務流程。

SpaceX 算力合作的分量

額度提高背後，是新的算力供給。

Anthropic 表示，已經與 SpaceX 簽署協議，將使用 SpaceX 的 Colossus 1 資料中心全部算力容量。這項合作會在一個月內帶來超過 300 兆瓦的新容量，對應超過 22 萬塊 NVIDIA GPU。

這組數字說明兩件事。

第一，前沿模型公司的瓶頸仍然是算力。模型能力、上下文長度、工具呼叫、程式碼代理、多模態和企業場景都會消耗大量推理資源。使用者越多、任務越複雜，平台越需要穩定的大規模 GPU 供給。

第二，AI 基礎設施競爭已經進入超大規模階段。過去大家更關注模型榜單、產品功能和價格；現在，誰能更快拿到電力、機房、網路和 GPU，誰就更有機會把模型能力變成穩定產品。

Anthropic 還提到，這次 SpaceX 合作會直接改善 Claude Pro 和 Claude Max 訂閱使用者的容量體驗。也就是說，它不是只服務訓練叢集，也會進入面向使用者的推理供給。

Anthropic 的算力版圖

SpaceX 不是 Anthropic 唯一的算力合作。

Anthropic 在公告中同時回顧了幾項已經公布的基礎設施安排：

與 Amazon 的最高 5GW 協議，其中包括到 2026 年底前接近 1GW 的新增容量。
與 Google 和 Broadcom 的 5GW 協議，預計從 2027 年開始逐步上線。
與 Microsoft 和 NVIDIA 的戰略合作，其中包括 300 億美元 Azure 容量。
透過 Fluidstack 在美國 AI 基礎設施上投入 500 億美元。

這些合作的共同點，是 Anthropic 不把自己綁定在單一硬體或單一雲平台上。原文明確提到，Claude 的訓練和執行會使用 AWS Trainium、Google TPU 和 NVIDIA GPU。

這種多供應商路線有現實意義。單靠一家雲廠商，很難長期滿足前沿模型訓練和大規模推理的峰值需求。多平台布局雖然會增加工程複雜度，但能降低供應鏈和容量風險。

為什麼額度提升本質上是算力問題

AI 產品的「額度」不是普通網路產品裡的會員權益文案，它背後對應真實成本。

Claude Code 每次讀取倉庫、生成補丁、執行長任務，都會消耗推理資源。API 使用者如果把 Opus 接入客服、金融分析、程式碼審查、文件處理或 agent 工作流，也會產生持續呼叫。對平台來說，放寬限額就意味著要有更多穩定算力兜底。

所以這次公告的邏輯很清楚：先說明使用者能獲得更高限制，再解釋這些限制為什麼現在可以提高。新增的 SpaceX 容量，以及此前和 Amazon、Google、Microsoft、NVIDIA、Fluidstack 的合作，都是為了支撐更重的使用場景。

這也解釋了為什麼 AI 產品會越來越強調不同方案之間的分層。免費使用者、Pro 使用者、Max 使用者、Team 使用者、Enterprise 使用者，對算力的消耗和付費能力不同。模型公司必須把額度、優先級、模型存取和基礎設施成本重新匹配起來。

軌道 AI 算力的信號

公告裡還有一個很有未來感的細節：Anthropic 表示，作為這項協議的一部分，它也表達了與 SpaceX 合作開發多吉瓦級軌道 AI 算力容量的興趣。

這不等於軌道資料中心馬上會成為現實產品。更穩妥的理解是，前沿 AI 公司已經開始把未來算力供給想像到地面資料中心之外。

AI 資料中心受電力、土地、冷卻、網路和監管限制。隨著訓練和推理需求繼續擴大，產業會探索更多基礎設施形態。軌道算力現在聽起來很遠，但它出現在 Anthropic 的正式公告裡，本身就是一個信號：算力競爭的想像空間正在被拉大。

國際化和合規需求

Anthropic 還提到，企業客戶，尤其是金融、醫療和政府等受監管產業，越來越需要本地化基礎設施來滿足合規和資料駐留要求。

這意味著模型公司不能只在美國集中建設資料中心。企業 AI 要進入真實業務，就必須處理區域合規、資料駐留、供應鏈安全、電力成本和當地社群關係。Anthropic 表示，與 Amazon 的合作中已經包括亞洲和歐洲的新增推理能力。

它還強調，會優先選擇法律和監管框架支持大規模投資、供應鏈安全的民主國家，並探索把美國資料中心電價承諾擴展到其他司法轄區。

這部分內容說明，AI 基礎設施不只是技術問題，也會越來越像能源、製造業和地緣經濟問題。

簡短判斷

Anthropic 這次公告可以概括為一句話：Claude 的額度提高，是因為背後有新的大規模算力供給。

對使用者來說，短期影響是 Claude Code 五小時限制提高、Pro 和 Max 高峰期限制減少、Opus API 呼叫空間變大。對產業來說，更重要的是模型公司競爭正在從「誰的模型更強」擴展到「誰能持續拿到足夠多、足夠穩定、足夠合規的算力」。

未來 AI 產品的體驗差距，很可能不只來自模型參數和產品設計，也來自基礎設施能力。誰能把電力、GPU、資料中心、雲合作和區域合規組織起來，誰就更有機會把前沿模型變成可長期使用的服務。

CC Switch：一個桌面工具統一管理 Claude Code、Codex、Gemini CLI 和 OpenClaw

Wed, 06 May 2026 09:03:08 +0800

CC Switch 是一個面向 AI 程式設計重度使用者的桌面管理工具。它要解決的問題很直接：現在很多人同時使用 Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw，但每個工具都有自己的設定格式、Provider 寫法、MCP 設定和 Skills 管理方式。

當你只用一個工具時，手動改設定還能忍；一旦多個工具混用，再加上官方帳號、第三方 API、中轉服務、本地模型和團隊共享設定，手動編輯 JSON、TOML、.env 很快就會變成一件很煩的事。

CC Switch 的定位，就是把這些分散設定收進一個跨平台桌面應用裡。

它解決什麼問題

現代 AI 程式設計工具越來越像「命令列裡的開發同事」，但每個工具的生態還沒有完全統一。

常見痛點包括：

Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw 設定格式不同。
切換 API Provider 時，要反覆改設定檔。
MCP server 在不同工具之間重複設定。
CLAUDE.md、AGENTS.md、GEMINI.md 這類提示檔案難以統一維護。
Skills 安裝、同步、備份和解除安裝缺少一個集中入口。
多個帳號、多個 relay、多個模型服務切換很容易搞混。
設定檔手動修改出錯後，排查成本很高。

CC Switch 的思路是：不要讓使用者記住每個工具的設定細節，而是用一個統一介面管理 Provider、MCP、Prompts、Skills、Sessions 和代理。

支援哪些工具

README 中列出的核心支援對象包括五類：

Claude Code
Codex
Gemini CLI
OpenCode
OpenClaw

這幾個工具本身定位相近，都是圍繞 AI 程式設計、Agent 工作流和命令列協作展開。但它們的設定體系不同，CC Switch 的價值就在於把這些差異包裝起來。

對經常比較不同 AI 程式設計工具的人來說，這比每次手動翻設定檔省心很多。

Provider 管理

CC Switch 的第一層能力是 Provider 管理。

它內建了 50 多個 Provider 預設，README 中提到的方向包括 AWS Bedrock、NVIDIA NIM，以及各種社群 relay。使用者可以複製 API key，一鍵匯入，然後在介面中切換。

實用點主要有幾個：

一鍵新增 Provider。
Provider 拖曳排序。
系統匣快速切換。
Provider 匯入和匯出。
部分通用 Provider 可同步到多個應用。

對很多人來說，這個功能已經足夠有吸引力。因為 AI 程式設計工具的日常使用，經常不是「模型不會用」，而是「今天這個 key 用哪個工具、哪個 endpoint、哪個帳號」容易亂。

本地代理與故障切換

除了寫設定檔，CC Switch 還提供本地代理模式。

這個能力的重點是：

熱切換 Provider。
格式轉換。
自動故障轉移。
熔斷器。
Provider 健康檢查。
請求修正。

簡單說，它不只是把設定寫進目標工具，還可以在中間加一層本地代理，讓不同工具透過代理存取模型服務。

這對多 Provider 使用者很有用：一個服務掛了，可以切到另一個；一個模型貴，可以換成更便宜的；某個請求格式不相容，也可以透過代理層做適配。

MCP、Prompts 和 Skills

CC Switch 比較重要的第二層能力，是統一管理 MCP、Prompts 和 Skills。

MCP

它提供統一 MCP 面板，可以在多個應用之間管理 MCP server，並支援雙向同步和 Deep Link 匯入。

這對正在用 MCP 的使用者很實用。因為 MCP server 一多，設定很容易分散在不同客戶端裡。統一面板可以減少重複設定，也方便遷移。

Prompts

Prompts 部分支援 Markdown 編輯，並且可以在不同工具之間同步對應檔案，例如：

CLAUDE.md
AGENTS.md
GEMINI.md

這些檔案本質上都是給 Agent 的專案說明書。統一管理後，可以更容易維護團隊規則、專案約定和全域提示。

Skills

Skills 支援從 GitHub 倉庫或 ZIP 檔案一鍵安裝，也支援自訂倉庫管理、符號連結和檔案複製。

如果你同時使用 Claude Code、Codex、OpenClaw 這類工具，Skills 很容易變成一堆散落在不同目錄的檔案。CC Switch 把它們集中起來，能降低維護成本。

會話與工作區

README 還提到 Session Manager 和 Workspace 相關能力。

它可以瀏覽、搜尋和恢復多個應用裡的會話歷史。對長期使用 AI 程式設計工具的人來說，會話管理其實很重要：很多有價值的上下文、除錯過程、方案比較，都埋在舊對話裡。

此外，它還為 OpenClaw 提供 Workspace editor，可以編輯 AGENTS.md、SOUL.md 等 agent 檔案，並帶 Markdown 預覽。

這說明 CC Switch 不只是一個「切換 key 的小工具」，而是在往 AI Agent 工作台方向擴展。

雲同步與資料儲存

CC Switch 支援透過 Dropbox、OneDrive、iCloud、NAS 或 WebDAV 同步 Provider 資料。

本地資料儲存方式也比較清楚：

資料庫：~/.cc-switch/cc-switch.db
本地設定：~/.cc-switch/settings.json
自動備份：~/.cc-switch/backups/
Skills：~/.cc-switch/skills/
Skill 備份：~/.cc-switch/skill-backups/

它使用 SQLite 作為主要資料源，並強調原子寫入和自動備份，目標是避免設定檔在切換或寫入時損壞。

這個設計對重度使用者很關鍵。因為一旦設定管理工具本身把設定寫壞，影響的是所有 AI 程式設計工具。

安裝方式

CC Switch 是跨平台桌面應用，基於 Tauri 2 建構。

系統要求大致如下：

Windows：Windows 10 及以上
macOS：macOS 12 Monterey 及以上
Linux：Ubuntu 22.04+、Debian 11+、Fedora 34+ 等主流發行版

Windows 使用者可以下載 .msi 安裝包或可攜版壓縮包。

macOS 使用者可以用 Homebrew：

1
2

brew tap farion1231/ccswitch
brew install --cask cc-switch

更新：

`1`	`brew upgrade --cask cc-switch`

Linux 使用者可以選擇 .deb、.rpm 或 AppImage。Arch Linux 使用者也可以透過 paru -S cc-switch-bin 安裝。

截至 2026 年 5 月 6 日，倉庫頁面顯示最新 release 為 CC Switch v3.14.1，發布時間是 2026 年 4 月 23 日。

技術棧

從倉庫結構看，CC Switch 是典型的 Tauri 桌面應用：

前端：React 18、TypeScript、Vite、TailwindCSS、TanStack Query、shadcn/ui
後端：Tauri 2、Rust、SQLite、Tokio
測試：Vitest、MSW、Testing Library

核心設計模式包括：

SQLite 作為 Single Source of Truth。
JSON 保存裝置級本地設定。
切換時寫入目標工具的 live config。
編輯當前 Provider 時從 live config 回填。
使用臨時檔案加 rename 的方式做原子寫入。
資料庫連線加鎖，避免並發寫入問題。

這類架構說明專案並不是簡單腳本，而是按長期桌面工具來設計的。

適合誰用

CC Switch 適合下面幾類使用者：

同時使用 Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw。
經常切換官方帳號、第三方 relay、本地模型或團隊 Provider。
已經開始大量使用 MCP。
想統一維護 CLAUDE.md、AGENTS.md、GEMINI.md。
經常安裝、測試和遷移 Skills。
想看不同工具的會話歷史和使用情況。

如果你只用一個 AI 程式設計工具，而且一直走官方登入，不怎麼折騰 Provider、MCP 和 Skills，那它的價值可能沒那麼明顯。

但如果你已經進入「多工具、多帳號、多 Provider、多專案」的狀態，它能省掉很多瑣碎設定工作。

需要注意什麼

這類工具很方便，但也要注意邊界。

第一，它會管理多個 AI CLI 的設定，因此要確認自己信任這個工具和它的寫入邏輯。

第二，API key、relay endpoint、MCP server 都屬於敏感設定。開啟雲同步前，要確認同步目錄和 WebDAV 服務本身安全可靠。

第三，切換 Provider 後，多數工具仍然需要重啟終端或 CLI 才能生效。README 中提到，Claude Code 對 Provider 資料支援熱切換，但其他工具通常仍需要重啟。

第四，切回官方登入時，最好按專案說明新增 official provider，再重新走對應工具的登入流程。

小結

CC Switch 的價值不在於又做了一個 AI 程式設計工具，而在於它承認了一個現實：AI 程式設計生態已經進入多工具並存階段。

Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw 各有自己的設定系統，MCP、Skills、Prompts、Provider 又在快速擴展。繼續靠手動改設定，遲早會變成負擔。

CC Switch 把這些東西收進一個桌面應用裡，讓使用者可以更輕鬆地切換 Provider、同步 MCP、管理 Skills、維護提示檔案和查看會話。對重度 AI 程式設計使用者來說，這類工具很可能會從「可選小工具」變成「日常基礎設施」。

參考資料

farion1231/cc-switch

Claude Code 的 HERMES.md 計費故障是怎麼回事

Sat, 02 May 2026 11:19:23 +0800

Claude Code 最近有一次很典型的計費故障：使用者只是啟動 CLI，還沒有正式發出請求，就因為本機 HERMES.md 檔案被讀取而產生了大額費用。

這件事值得單獨看，不是因為某個使用者損失了多少錢，而是因為它暴露了 AI 程式設計工具的一個新風險：只要工具會自動讀取上下文，本機檔案就可能變成真實 token 成本。

發生了什麼

公開 issue 顯示，使用者在工作目錄裡放了一個很大的 HERMES.md 檔案。啟動 Claude Code 後，CLI 會掃描並載入專案上下文。問題在於，這個檔案被自動納入上下文，並被計入 API 使用量。

使用者並沒有明確要求模型處理這份檔案，但計費已經發生。更麻煩的是，這類行為發生在工具初始化或上下文準備階段，使用者不一定能第一時間意識到費用正在產生。

Anthropic 後續在 issue 中回覆，表示會退還異常費用，並額外提供額度補償。這個回應說明問題至少已被官方確認和處理，但它仍然提醒使用者：AI CLI 的「自動上下文」不是免費的。

HERMES.md 為什麼會觸發問題

HERMES.md 本身不是重點。它可以換成任何大檔案：長日誌、匯出的文件、測試資料、資料庫 dump、生成報告，都可能造成類似問題。

真正的問題在於三件事疊加：

Claude Code 會自動讀取專案上下文。
被讀取的檔案可能很大。
上下文 token 會進入計費鏈路。

如果一個檔案足夠大，哪怕只是被工具「順手帶上」，也可能產生明顯費用。對按 token 計費的模型來說，自動化越強，越需要明確邊界。

這不是普通 bug

普通 CLI bug 可能只是命令失敗、輸出錯誤或功能不可用。計費 bug 更敏感，因為它直接影響使用者帳單。

對 AI 程式設計工具來說，計費邊界很容易變模糊：

系統提示會消耗 token。
專案規則會消耗 token。
自動讀取的檔案會消耗 token。
工具調用結果會消耗 token。
重試、壓縮、摘要也可能繼續消耗 token。

使用者看到的是一次「啟動工具」或「一次對話」，後臺實際可能已經發生多次請求和大量上下文傳輸。

使用者應該怎麼防

如果你使用 Claude Code、Codex、Cline 這類 AI 程式設計工具，可以先做幾件事：

不要把大檔案直接放在專案根目錄。
把日誌、匯出資料、構建產物、臨時檔案加入忽略規則。
檢查工具是否支援類似 .ignore、上下文排除、檔案白名單的配置。
開啟預算提醒或用量限制。
第一次在大型倉庫執行前，先用小目錄測試。

如果倉庫裡必須保留大檔案，最好明確告訴工具不要讀取它們。專案規則裡也可以寫清楚：不要主動讀取日誌、dump、資料集、歸檔檔案和大體積 Markdown。

工具廠商該怎麼改

這類問題不能只靠使用者小心。工具本身也應該給出硬邊界。

更合理的設計包括：

初始化階段不應隱式計入大檔案。
自動讀取超大檔案前要提示使用者確認。
CLI 應顯示本次請求預估 token 和費用區間。
預設忽略常見大檔案和生成目錄。
對異常 token 激增設定保護閾值。

AI 程式設計工具越像「自動代理」，越需要把成本透明化。否則使用者很難判斷一次操作到底會產生多少費用。

小結

Claude Code 的 HERMES.md 計費故障，本質上是自動上下文和按量計費之間的衝突。

對使用者來說，最重要的是把專案上下文管住：大檔案不要預設暴露給 AI 工具，預算和用量也要設上限。對工具廠商來說，自動讀取檔案必須配套可見的成本提示和保護機制。

參考：

DeepSeek V4 降價如何改寫 AI Agent 的成本模型

Fri, 01 May 2026 19:47:47 +0800

DeepSeek V4 發布時沒有製造出特別誇張的聲量。沒有大型發布會，也沒有一眼碾壓所有對手的跑分敘事。但幾天之後，它真正影響行業的地方開始顯現：連續降價。

這次變化的重點不是「模型強了一點」，而是「使用成本被打到另一個層級」。當 Token 價格低到普通 Agent 任務幾毛錢、一兩塊錢就能跑完時，很多 Coding Plan、Token Plan 的商業邏輯都會被重新審視。

發布當天沒有炸場

DeepSeek V4 的第一波反饋並不算熱烈。很多人期待它像 R1 那樣帶來強烈衝擊：跑分全面領先、國產算力驗證、多模態和 Agent 能力一起爆發。但真正發布後，大家發現它更像一次穩健升級。

V4 Pro 確實是強模型，尤其在程式碼、數學、長上下文和 agentic coding 上表現不錯。但它不是那種讓所有同類模型瞬間失色的產品。所以發布當天，輿論一度有些尷尬：想誇，但很難找到一個足夠爆炸的角度。

真正的轉折點不是發布當天，而是後續價格調整。

連續降價才是關鍵

DeepSeek V4 發布後，價格開始連續下探。按照 DeepSeek 官方價格頁和原文整理的資訊，當時的大致價格是：

DeepSeek V4 Flash：輸入 100 萬 Token 約 1 元；快取命中後 100 萬 Token 約 2 分錢；
DeepSeek V4 Pro：輸入 100 萬 Token 約 3 元；快取命中後 100 萬 Token 約 2.5 分；
全系列模型輸入快取命中價格降到首發價格的 1/10；
V4 Pro 曾處在 2.5 折優惠期，優惠延長到 2026 年 5 月 31 日 23:59。

如果按美元 API 價格看，會更直觀：

模型	快取命中輸入	非快取輸入	輸出	上下文
`deepseek-v4-flash`	$0.0028 / 100萬 Token	$0.14 / 100萬 Token	$0.28 / 100萬 Token	1M
`deepseek-v4-pro` 促銷價	$0.003625 / 100萬 Token	$0.435 / 100萬 Token	$0.87 / 100萬 Token	1M
`deepseek-v4-pro` 原價	$0.0145 / 100萬 Token	$1.74 / 100萬 Token	$3.48 / 100萬 Token	1M

這裡要注意兩個點。

第一，V4 Pro 的 $0.435 / $0.87 是促銷價，不是長期原價。 DeepSeek 官方說明裡，這個 75% 折扣延長到 2026 年 5 月 31 日 15:59 UTC。

第二，快取命中價格才是 Agent 成本模型裡的關鍵。 Flash 的快取命中輸入低到 $0.0028 / 100萬 Token，Pro 促銷期快取命中輸入是 $0.003625 / 100萬 Token。這意味著大量重複專案上下文、工具定義、系統提示詞和歷史摘要，不再按完整輸入價格計費。

這個價格最重要的地方，是它讓很多任務的 Token 成本變得「不敏感」。過去開發者會擔心一次 Agent 任務吃掉大量上下文、反覆讀寫程式碼、頻繁呼叫工具。現在只要快取命中率足夠高，成本會被壓得很低。

和 GPT、Claude 的價格對比

只看 DeepSeek 自己的價格，還不容易感受到差距。把它和同期常見的閉源模型放在一起，對比會更明顯。

模型	輸入	快取輸入	輸出	適合場景
`deepseek-v4-flash`	$0.14 / M	$0.0028 / M	$0.28 / M	高頻 Agent、常規 coding、批量任務
`deepseek-v4-pro` 促銷價	$0.435 / M	$0.003625 / M	$0.87 / M	複雜 coding、規劃、事實核查
`deepseek-v4-pro` 原價	$1.74 / M	$0.0145 / M	$3.48 / M	促銷結束後的 Pro 成本基準
GPT-5.5	$5 / M	$0.50 / M	$30 / M	高品質複雜任務、通用推理
GPT-5.4	$2.50 / M	$0.25 / M	$15 / M	程式設計和專業任務的中檔選擇
GPT-5.4 mini	$0.75 / M	$0.075 / M	$4.50 / M	成本更低的通用/子任務模型
Claude Opus 4.7	$5 / M	$0.50 / M	$25 / M	高品質寫作、複雜推理、長任務
Claude Sonnet 4.6	$3 / M	$0.30 / M	$15 / M	程式設計、Agent、綜合任務
Claude Haiku 4.5	$1 / M	$0.10 / M	$5 / M	輕量任務、摘要、分類

這張表裡最刺眼的是輸出價格。 Agent 不只讀上下文，還會不斷生成計畫、補丁、解釋、日誌和下一步動作。如果輸出很多，DeepSeek V4 Pro 促銷價的 $0.87 / M 和 GPT-5.5 的 $30 / M、Claude Sonnet 4.6 的 $15 / M 相比，差距會被不斷放大。

即使按 V4 Pro 原價 $3.48 / M 輸出算，它也明顯低於 GPT-5.4、GPT-5.5 和 Claude Sonnet / Opus。如果任務可以用 Flash 承擔，輸出價會進一步降到 $0.28 / M。

快取輸入差距更誇張。 DeepSeek V4 Flash 的快取輸入是 $0.0028 / M，而 GPT-5.5 和 Claude Opus 4.7 的快取輸入都是 $0.50 / M。這不是同一個數量級。對反覆讀取同一程式碼倉庫的 Agent 來說，這個差距比普通聊天更重要。

Agent 任務為什麼特別受影響

AI Agent 和普通聊天不一樣。普通聊天通常是一問一答，輸入上下文相對有限。 Agent 任務會反覆讀取專案檔案、生成計畫、呼叫工具、檢查結果、再修改程式碼。

這類任務有兩個特點：

Token 消耗大；
重複上下文多。

第二點很關鍵。在程式碼專案裡，模型會反覆讀取同一批檔案、目錄結構、錯誤日誌和修改結果。如果平台支援快取命中，重複輸入的成本會大幅下降。

原文裡提到一次實際體驗：把 DeepSeek V4 Pro 和 Flash 接到 Claude Code 一類工具中，讓它拉取一個提示詞倉庫並做成本地搜尋網站。任務最終完成，總成本大約 8 毛多，其中 Pro 快取命中率達到 98.7%。

這個例子說明了一個現實問題：Agent 任務越像「圍繞同一個專案反覆工作」，快取命中越有價值。如果一次生成網站、修 bug、改前端只花幾毛錢到幾塊錢，訂閱套餐的吸引力就會下降。

可以用一個簡化任務估算差距。假設一次 coding agent 任務包含：

50 萬 Token 輸入，其中 80% 能命中快取；
5 萬 Token 輸出；
不計算工具呼叫、搜尋和平台加價，只看模型 Token 成本。

大致成本如下：

模型	估算成本
DeepSeek V4 Flash	約 $0.03
DeepSeek V4 Pro 促銷價	約 $0.09
DeepSeek V4 Pro 原價	約 $0.36
GPT-5.4 mini	約 $0.30
GPT-5.4	約 $1.01
GPT-5.5	約 $1.75
Claude Sonnet 4.6	約 $1.11
Claude Opus 4.7	約 $1.65

這個估算不是說 DeepSeek 在所有任務上都更好。模型品質、工具呼叫穩定性、長上下文檢索能力、程式碼風格和事實可靠性都要單獨評估。但從成本上看，DeepSeek V4 把「讓 Agent 多跑幾輪」的邊際成本壓得很低。這會鼓勵開發者設計更長流程、更頻繁的自檢和更多候選方案，而不是每次都擔心 Token 帳單。

Coding Plan 和 Token Plan 的差別

很多 AI 產品現在會提供兩類套餐：Coding Plan 和 Token Plan。

它們的差別大致是：

Coding Plan 通常主要面向程式設計；
Token Plan 通常覆蓋更多能力，例如 STT、TTS、繪圖、搜尋、embedding、RAG；
STT 是語音轉文字；
TTS 是文字轉語音；
Coding Plan 往往把使用者限制在程式設計場景裡，其他能力還需要另買。

從商業角度看，Coding Plan 更像自助餐。使用者預先付一筆固定費用，廠商賭的是大多數人不會把額度用滿。有人用得多，有人用得少，平均下來平台仍然能賺錢。

但如果按量 Token 價格足夠低，使用者就會開始計算：我為什麼一定要買套餐？如果一個月真實使用成本只有幾塊錢、十幾塊錢，買 40 元、200 元的套餐就不一定划算。

降價為什麼會衝擊套餐模式

訂閱套餐的成立，需要一個前提：使用者覺得單次使用很貴，或者不想計算每次呼叫成本。當 Token 價格高時，套餐看起來更安心。當 Token 價格低到幾乎無感時，按量付費反而更自然。

DeepSeek V4 的降價相當於把底牌亮出來：

Agent 任務可以很便宜；
長上下文不一定貴到不能用；
快取命中可以顯著降低成本；
普通開發者不一定需要固定訂閱；
模型入口可以從「套餐平台」轉向「低價 API」。

這會讓做 Coding Plan 的平台不舒服。如果使用者發現按量呼叫更便宜、更自由，就沒必要為了一個平台的套餐被綁定。

Flash 和 Pro 怎麼選

DeepSeek V4 的一個實用思路，是把 Flash 和 Pro 分工使用。

Flash 適合高頻、輕量、可重複的任務：

改 bug；
寫前端；
寫腳本；
做常規程式碼理解；
處理較長上下文裡的普通資訊整理；
跑大量子任務。

Flash 便宜，速度快，而且同樣支援很長上下文。對日常 coding agent 來說，很多任務不需要一上來就用 Pro。

Pro 更適合複雜判斷和兜底任務：

多輪規劃；
複雜 Agent 流程；
多次 function call；
事實核查；
財經研究；
需要更強知識和判斷力的內容生產；
高風險程式碼修改。

一個合理配置是：Flash 負責跑量，Pro 負責兜底。普通任務先用 Flash，遇到長程規劃、複雜判斷、事實核查或多工具協作時再切 Pro。這樣既能控制成本，也能保留模型品質。

DeepSeek 為什麼可以這麼定價

DeepSeek 和很多大廠的業務結構不同。它沒有電商、社交、短影片、雲計算、手機、汽車、辦公套件、作業系統、瀏覽器或大規模企業 SaaS 生態。

這意味著它不需要把使用者鎖在一個完整平台裡。它可以只賣文字模型能力：你在這裡用便宜的文字模型，其他能力要呼叫誰都可以。

大廠的邏輯通常不同。如果你買了它的 Coding Plan 或 Token Plan，就會被拉進它的雲、搜尋、繪圖、語音、資料庫和開發工具生態。套餐不是單純賣模型，而是在爭奪使用者入口。

DeepSeek 的打法更直接：把文字模型價格壓低，爭取成為 Agent 的預設模型入口。只要預設入口被占住，很多開發者和工具鏈就會自然圍繞它適配。

開源模型和預設入口

DeepSeek V4 如果保持開放模型路線，第三方雲廠商和平台很可能會自行部署並提供服務。這對 DeepSeek 來說既是傳播，也可能是分流。

低價官方 API 的意義就在這裡。如果官方價格已經足夠低，其他平台即使能部署，也很難在價格上明顯更有優勢。使用者會傾向於直接使用預設、便宜、穩定的入口。

對 Agent 工具尤其如此。 Agent 任務依賴長上下文、快取、工具呼叫和穩定吞吐。一旦某個模型在這些場景裡成本足夠低，它就有機會成為預設選項。

Coding Plan 仍然不是完全沒用

這並不意味著 Coding Plan 會馬上消失。它仍然有適合的人群。

如果某些使用者真的是高強度使用者，每天把套餐額度打滿，那麼固定訂閱可能仍然划算。就像自助餐，如果完全沒有人能吃回本，使用者也不會願意買。

但問題在於，絕大多數使用者不是這種極端高頻使用者。低頻使用者、輕量開發者、偶爾寫腳本或改專案的人，更適合按量付費。當 DeepSeek 把按量成本壓低後，套餐的吸引力會被削弱。

未來更可能出現的是分層選擇：

高頻重度使用者繼續買 Coding Plan；
普通使用者轉向低價 API；
Agent 工具根據任務自動選擇 Flash / Pro；
平台套餐需要提供更多非模型價值，例如工作流、IDE 整合、部署、團隊管理和安全稽核。

小結

DeepSeek V4 的發布並沒有靠跑分製造最大衝擊。真正改變行業預期的是後續降價。

當輸入 Token 和快取命中價格被壓到很低時，AI Agent 的使用成本會發生變化。過去看起來昂貴的長上下文、程式碼專案分析、多輪工具呼叫，現在可能變成幾毛錢到幾塊錢的日常消耗。

這會直接衝擊 Coding Plan 和 Token Plan 的商業邏輯。如果使用者可以按量付費、自由組合模型和工具，而且成本足夠低，就不一定願意被綁定在某個平台套餐裡。

DeepSeek V4 這次真正動到的，不只是模型能力排名，而是 AI Agent 的成本結構和預設入口之爭。

參考來源：

mattpocock/skills：給 AI 編程 Agent 準備的實用技能集合

Fri, 01 May 2026 03:43:20 +0800

mattpocock/skills 是 Matt Pocock 公開的一組 AI 編程 agent skills。

它不是一個完整的應用，也不是一個新的聊天客戶端，而是一套可以給 AI 編程助手使用的工作技能。它的思路很實用：把 AI 編程裡經常出現的問題拆成一個個小技能，讓 Agent 在合適的任務裡呼叫，而不是每次都靠一大段提示詞硬撐。

如果你經常使用 Claude Code、Codex、Cursor 或類似的 AI 編程工具，這類 skills 很值得關注。因為真正影響 AI 編程體驗的，往往不是「模型會不會寫程式碼」，而是它能不能按你的工作方式推進任務。

它解決什麼問題

AI 編程助手很強，但也很容易出問題。

常見情況包括：

還沒理解需求就開始改程式碼
一次性改太多檔案
輸出解釋很多，真正有用的行動很少
遇到錯誤後盲目嘗試
沒有及時執行測試或檢查
忽略專案裡已有模式
為了完成任務引入不必要的抽象
寫完程式碼後沒有真正 review 風險

這些問題不一定是模型能力不夠，而是工作流沒有被約束好。

mattpocock/skills 的價值在於，把這些常見失敗模式拆成可以複用的操作方式，讓 Agent 在不同場景下更像一個有經驗的工程協作者。

Skills 是什麼

在 AI Agent 語境裡，skill 可以理解成一段可複用的任務說明、工作方法或專業流程。

它不一定是程式碼插件，也不一定必須呼叫外部服務。很多時候，一個 skill 就是一套明確規則：

什麼時候使用
先做什麼
不要做什麼
需要輸出什麼
怎麼判斷任務完成

這和普通提示詞模板有點像，但粒度更接近「任務能力」。

普通提示詞模板通常是使用者每次臨時複製貼上；skills 則更適合作為 agent 工具箱的一部分，讓 Agent 根據任務選擇合適流程。

為什麼要小而可組合

README 中強調這些 skills 是小而可組合的。

這個方向很重要。

如果一個 skill 試圖包辦所有事情，它很快就會變成新的大提示詞：又長、又模糊、又難維護。小技能的優勢是邊界清楚。

比如一個 skill 專門負責：

先做計劃
修復 TypeScript 錯誤
執行測試並根據結果修復
做程式碼 review
總結專案約定
改進提示詞
清理無用抽象

這些技能可以按任務組合使用。簡單任務只用一個技能，複雜任務再串起來。

這更接近真實工程工作：你不會用同一套流程處理所有問題，而是根據問題選擇工具。

保留工程師控制權

這個倉庫的一個重要取向，是讓工程師仍然掌握控制權。

AI 編程很容易滑向兩種極端：

第一種是完全手動。AI 只是幫你寫幾行程式碼，所有上下文、計劃、驗證都靠你自己盯。

第二種是完全放手。你把任務丟給 Agent，讓它自己大改一通，最後再面對一堆難以審查的 diff。

skills 的作用是在中間找一個更穩的位置。

它讓 AI 承擔更多重複流程，但仍然用規則限制它：

先理解任務再動手
先閱讀相關檔案再改
修改範圍要可控
出現不確定時要回報
改完要驗證
不能為了炫技重構無關程式碼

這不是削弱 AI，而是讓 AI 的行動更容易被人類審查和接管。

對齊問題

AI 編程失敗的第一類問題通常是對齊失敗。

使用者想要的是一個很具體的改動，但 Agent 可能理解成一個更大的重構；使用者只想修 Bug，它卻順手改了樣式；使用者希望遵守現有架構，它卻引入新模式。

Skills 可以在任務開始階段幫助 Agent 做幾件事：

重述目標
找出影響範圍
識別已有實現模式
給出計劃
明確不做哪些事情

這一步很像工程師開工前的自檢。

如果 Agent 連任務邊界都沒說清楚，就直接寫程式碼，後面很容易越走越偏。

回饋循環問題

AI 寫程式碼不能只靠一次生成。

真實開發裡，回饋循環很重要：

改一小步
跑測試或型別檢查
看錯誤
修正
再驗證

很多 Agent 失敗，是因為它跳過了中間回饋。它一次性改很多內容，然後憑感覺總結「應該可以工作」。

Skills 可以把回饋循環顯式寫進流程裡。比如要求 Agent：

修改後執行相關檢查
如果檢查失敗，先讀錯誤訊息
不要盲目改無關檔案
每輪修復後重新驗證
最後報告驗證結果

這會讓 AI 編程更像真實除錯，而不是一次性作文。

架構控制問題

AI 很擅長生成抽象，也很擅長過度生成抽象。

為了完成一個小需求，它可能新建服務層、工具函式、配置物件、型別包裝、適配器，最後讓程式碼比需求本身複雜得多。

這類問題在大型專案裡尤其危險。因為 AI 生成的抽象看起來很「專業」，但它可能不符合專案已有風格，也可能增加維護成本。

好的 skills 會提醒 Agent：

優先沿用現有模式
不引入沒有必要的新抽象
不順手重構無關區域
修改要和任務規模匹配
先理解程式碼再設計結構

這能減少「看起來很工程化，實際上更難維護」的輸出。

Review 技能為什麼重要

寫程式碼和 review 程式碼是兩種不同狀態。

Agent 在寫程式碼時，通常會傾向於證明自己的實現成立。它會解釋為什麼這樣改可以工作，但不一定主動找風險。

Review skill 的意義，是讓 Agent 切換角色：

找潛在 Bug
找行為回歸
找遺漏測試
找邊界條件
找複雜度上升
找和現有約定不一致的地方

這對 AI 編程很重要。因為 AI 生成程式碼的速度很快，如果沒有 review，使用者很容易被大量 diff 淹沒。

一個好的 review 輸出應該優先列問題，而不是先誇實現。它要幫助工程師判斷這次改動能不能合併。

和普通 rules 檔案有什麼區別

很多 AI 編程工具都支援 rules、instructions 或 memory。

這些檔案通常記錄長期規則，比如：

專案技術棧
命名規範
測試命令
不要修改哪些目錄
回答風格偏好

Skills 更偏任務流程。

rules 告訴 Agent「長期應該怎麼做」，skills 告訴 Agent「面對某類任務時應該怎麼執行」。

兩者最好一起用。

比如 rules 裡寫專案用 pnpm test，review skill 裡要求改完後檢查測試覆蓋。這樣 Agent 不僅知道命令，也知道什麼時候該用。

適合什麼場景

mattpocock/skills 這類倉庫適合這些場景：

高頻使用 AI 編程工具
經常讓 Agent 處理真實程式碼庫
想減少 AI 越界修改
想讓 Agent 更主動地驗證結果
想把自己的工程習慣沉澱成技能
想學習別人如何設計 agent workflows
想把一堆臨時提示詞整理成可維護的技能集合

如果你只是偶爾讓 AI 寫一個小函式，可能不需要專門維護 skills。

但如果你已經把 AI 當成長期開發夥伴，skills 會逐漸變得重要。它們相當於給 Agent 配了一套可複用的工作方法。

怎麼借鑑這個倉庫

即使你不直接使用其中的每個 skill，也可以從這個倉庫學到幾件事。

第一，把失敗模式寫下來。

不要只在 AI 出錯時臨時抱怨。把它經常出錯的模式整理成規則，下一次讓 skill 提前防住。

第二，技能要短。

一個 skill 最好解決一個明確問題。越短越容易被正確呼叫，也越容易維護。

第三，輸出格式要清楚。

如果你希望 Agent 先列計劃、再執行、最後總結驗證結果，就把輸出結構寫清楚。模糊要求通常會得到模糊結果。

第四，保留人工接管點。

好的 skill 不應該讓 AI 獨自跑到很遠。遇到不確定、影響範圍擴大、測試失敗或需要產品判斷時，應該讓它停下來說明情況。

使用時要注意

第一，不要把所有事情都技能化。

太多 skills 會讓系統變複雜，Agent 也可能不知道該選哪個。先從最高頻、最痛的幾個場景開始。

第二，skills 需要迭代。

第一次寫出來的 skill 不一定好。看 AI 實際執行效果，再逐步刪減、補充和改寫。

第三，不要讓 skill 替代工程判斷。

Skill 可以改善流程，但不能保證實現正確。測試、review、構建檢查和人類判斷仍然重要。

第四，注意不同 Agent 的差異。

Claude Code、Codex、Cursor、Copilot 對 instructions、skills、rules 的支援方式不同。同一套思想可以複用，但具體格式要按工具調整。

參考

mattpocock/skills

最後一句

mattpocock/skills 值得關注的地方，不是裡面某一個神奇提示詞，而是它展示了一種更實用的 AI 編程思路：把工程經驗拆成小技能，再讓 Agent 按場景組合使用。

當 AI 編程從偶爾輔助變成日常工作流，skills 會成為約束 Agent、保留工程師控制權和提升回饋品質的重要工具。

free-claude-code：用代理把 Claude Code 接到 OpenRouter、DeepSeek 和本地模型

Fri, 01 May 2026 03:41:49 +0800

free-claude-code 是一個給 Claude Code 使用的 Anthropic-compatible proxy。

它的思路不是破解 Claude Code，也不是提供官方免費的 Claude 服務，而是在本地啟動一個相容 Anthropic API 形狀的代理服務，把 Claude Code 發出的請求轉發到其他模型後端。README 中提到的後端包括 NVIDIA NIM、OpenRouter、DeepSeek、LM Studio、llama.cpp 和 Ollama。

簡單說，它想解決的是：你喜歡 Claude Code 的終端體驗，但希望把模型請求接到別的 provider 或本地模型上。

它解決什麼問題

Claude Code 的互動體驗很適合開發任務。

它可以在終端裡閱讀程式碼、修改檔案、執行命令、根據專案上下文推進任務。問題是，很多使用者並不一定想始終使用同一個模型後端：

想試試 OpenRouter 上的不同模型
想用 DeepSeek 這類模型降低成本
想把請求接到本地 Ollama
想用 LM Studio 或 llama.cpp 跑本地模型
想在開發環境裡統一走一個代理入口
想比較不同模型在 Claude Code 工作流裡的表現

free-claude-code 的定位，就是在 Claude Code 和這些模型服務之間加一層相容代理。

這樣 Claude Code 仍然按 Anthropic 風格發請求，代理負責把請求適配到不同後端。

工作方式

可以把它理解成三層：

前端是 Claude Code
中間是 free-claude-code 代理
後端是 OpenRouter、DeepSeek、本地模型或其他模型服務

Claude Code 以為自己在存取一個 Anthropic-compatible API。

代理收到請求後，根據配置選擇目標 provider，轉換必要欄位，再把回應返回給 Claude Code。

這類結構的好處是，你不用改 Claude Code 本身，也不用讓每個模型服務都原生支援 Claude Code。只要代理能把介面對齊，就能把更多模型接進同一個工作流。

支援哪些後端

README 中列出的方向包括：

NVIDIA NIM
OpenRouter
DeepSeek
LM Studio
llama.cpp
Ollama

這些後端代表了幾類不同使用方式。

OpenRouter 更像模型聚合入口，可以測試不同商業和開源模型。

DeepSeek 適合關注中文能力、程式碼能力和成本的人。

LM Studio、llama.cpp、Ollama 則偏本地模型路線。它們適合在自己的機器或內網環境裡執行模型，減少外部 API 依賴，也方便做離線實驗。

NVIDIA NIM 則更偏企業和 GPU 推理部署場景。

為什麼是 Anthropic-compatible proxy

Claude Code 本來圍繞 Anthropic 的介面和模型習慣設計。

如果你想讓它接入其他模型，最直接的問題就是介面不一致：

請求欄位不同
模型名稱不同
streaming 格式不同
tool use 表達不同
錯誤返回格式不同
token 和上下文限制不同

代理層的價值就在這裡。

它把 Claude Code 這邊看到的介面維持在接近 Anthropic 的形狀，再在後端做適配。對使用者來說，配置一次代理後，就可以在相同 Claude Code 工作流裡測試不同模型。

適合什麼場景

free-claude-code 適合這些場景：

想用 Claude Code 的終端工作流
想測試非 Anthropic 模型在 Claude Code 裡的表現
想降低模型呼叫成本
想把 Claude Code 接到 OpenRouter
想接入 DeepSeek 等相容模型服務
想用 Ollama、LM Studio、llama.cpp 跑本地模型
想為團隊統一配置一個模型代理入口

如果你只是正常使用官方 Claude Code，並且對模型提供方、成本和本地部署沒有特殊需求，那不一定需要這類代理。

但如果你經常比較模型，或者希望讓 Claude Code 接入本地和第三方模型，這類工具會很有用。

和直接用 OpenRouter 或 Ollama 有什麼區別

直接用 OpenRouter、Ollama 或 LM Studio，通常只是和模型聊天，或者透過 API 呼叫模型。

free-claude-code 的重點不是替代這些服務，而是把它們接到 Claude Code 這個開發工作流裡。

區別在於：

你仍然使用 Claude Code 的終端體驗
AI 可以圍繞程式碼倉庫執行任務
模型後端可以換成其他 provider
本地模型也有機會進入 Claude Code 工作流
配置集中在代理層，而不是每個工具單獨改

所以它更像橋接器，而不是新的聊天客戶端。

本地模型要注意什麼

把 Claude Code 接到本地模型很有吸引力，但也要注意現實限制。

第一，模型能力差距。

Claude Code 的任務通常不只是聊天，還包括理解程式碼、規劃修改、編輯檔案、處理命令輸出。本地小模型不一定能穩定完成這些任務。

第二，上下文視窗。

程式碼任務很吃上下文。模型上下文太小，會導致它讀不全檔案、漏掉約束，或者在多輪任務裡丟失背景。

第三，tool use 相容性。

Claude Code 工作流依賴工具呼叫和結構化行為。後端模型即使能聊天，也未必擅長遵循工具呼叫協議。

第四，速度和硬體。

本地模型的速度取決於機器配置、量化方式和模型大小。程式碼任務如果回應太慢，體驗會明顯下降。

所以，本地模型更適合實驗、低風險任務和特定場景。真正複雜的程式碼任務，仍然要根據模型能力謹慎選擇。

使用邊界

這類專案很容易被標題誤解，所以邊界要說清楚。

第一，它不是官方 Claude Code 免費額度。

它只是把 Claude Code 的請求轉發到其他模型後端。你使用 OpenRouter、DeepSeek、NVIDIA NIM 或其他 API 時，仍然需要遵守對應服務的價格、額度和使用條款。

第二，它不是繞過授權的工具。

使用任何代理工具時，都應該遵守 Claude Code、模型服務商和專案本身的授權協議。不要把它理解成規避官方限制的方式。

第三，代理會處理你的請求內容。

程式碼、命令輸出、專案上下文可能會經過代理和後端服務。部署時要考慮日誌、金鑰、網路和隱私邊界。涉及公司程式碼或敏感專案時，最好使用受控環境。

第四，不同模型表現差異會很大。

同樣的 Claude Code 操作，換一個模型後可能出現完全不同的行為。不要預設所有模型都能替代 Claude。

和 LiteLLM 這類代理有什麼關係

從思路上看，free-claude-code 屬於「相容介面代理」這一類工具。

這類工具的共同目標是減少上層應用和底層模型服務之間的耦合。上層應用只需要面對一個相對統一的介面，底層 provider 可以按配置切換。

不同專案的側重點不同。有的更偏通用模型閘道，有的更偏 OpenAI-compatible API，有的專門為 Claude Code 這類工具做適配。

free-claude-code 值得關注的地方，是它把目標場景直接放在 Claude Code 上，而不是做一個泛泛的聊天代理。

適合怎樣的使用者

它更適合有一定折騰能力的使用者：

熟悉 Claude Code
知道 API key 和模型 provider 怎麼配置
能理解代理服務的啟動和環境變數
能排查網路、連接埠、模型名稱和 streaming 問題
願意比較不同模型在程式碼任務裡的表現

如果你只想開箱即用，官方配置通常更省心。

如果你願意搭代理、換模型、調參數，並且想讓 Claude Code 進入更多模型環境，這個專案就值得研究。

參考

Alishahryar1/free-claude-code

最後一句

free-claude-code 的價值，不在於「免費」這個詞，而在於它把 Claude Code 和更多模型後端之間接了一座橋。

當你想保留 Claude Code 的開發體驗，同時測試 OpenRouter、DeepSeek、本地模型或企業推理服務時，這類 Anthropic-compatible proxy 就有了用武之地。

Compound Engineering Plugin：把 AI 編程變成計劃、執行、評審的工程循環

Fri, 01 May 2026 03:15:39 +0800

Compound Engineering Plugin 是 Every Inc 開源的一個 AI 編程工作流插件。

它關注的不是「讓 AI 更快寫一段程式碼」，而是把 AI 編程放進一個更像工程團隊的循環裡：先計劃，再實現，再評審，再把經驗沉澱下來。對經常使用 Claude Code、Codex、Cursor、Copilot 這類工具的人來說，這類插件解決的是工作流問題，而不只是提示詞問題。

AI 編程工具越來越強，但真實專案裡最難的往往不是生成程式碼，而是讓它持續按專案規則做事、理解任務邊界、避免重複犯錯，並在多輪迭代中積累上下文。

它解決什麼問題

很多人使用 AI 編程助手時，流程大概是這樣：

直接描述需求
讓 AI 改程式碼
看結果是否能跑
出錯後繼續補充說明
下次新任務再從頭解釋一遍

這種方式能完成小任務，但在複雜專案裡很容易遇到問題：

需求沒有先拆清楚，AI 直接開始改
改完程式碼後缺少系統性 review
專案規範靠使用者反覆提醒
同類錯誤下次仍然出現
多個 Agent 工具之間缺少統一工作方法
經驗沒有沉澱成可複用規則

Compound Engineering Plugin 想解決的就是這類問題。它把 AI 編程拆成多個階段，讓 Agent 不只是執行命令，而是參與一個更完整的工程流程。

什麼是 Compound Engineering

從專案 README 的描述看，Compound Engineering 可以理解為一種 AI 輔助軟體開發方法。

它強調一個循環：

計劃：先理解目標、拆分任務、確認路徑
執行：按計劃修改程式碼、執行命令、處理問題
評審：檢查實現品質、風險和測試覆蓋
學習：把經驗沉澱成後續可複用的規則

這個循環很像真實工程團隊的工作方式。

一個可靠的工程師不會拿到需求就立刻亂改，也不會改完就直接交差。他會先判斷影響範圍，再動手實現，之後檢查風險和測試結果，最後把踩過的坑記錄下來。AI Agent 也需要類似約束。

為什麼需要插件

提示詞可以告訴 AI「請先計劃再執行」，但提示詞本身不一定穩定。

一旦會話變長、上下文變複雜，模型可能會跳過計劃、忽略規則，或者為了完成任務而過度自信。插件的價值在於把流程固化下來，讓不同 Agent 環境都能遵循類似方法。

這類插件通常會把工作流拆成命令、規則、模板或子流程。使用者不需要每次手寫完整提示詞，而是透過固定入口觸發某個階段。

比如：

先讓 Agent 生成計劃
再按計劃逐步實現
改完後觸發 review
發現問題後返回修正
把值得保留的經驗寫入記憶或規則

這會讓 AI 編程更像「受控協作」，而不是一次性聊天。

支援哪些 Agent 環境

README 中提到，專案支援多個 AI 編程環境，包括：

Claude Code
Codex
Cursor
GitHub Copilot
Amp
Factory
Qwen Code

這點值得注意。

很多工作流工具只綁定一個客戶端，換工具後規則就不能複用。Compound Engineering Plugin 更像一套跨 Agent 的工程方法，把類似的計劃、執行、評審流程帶到不同工具裡。

如果你同時使用多個 AI 編程助手，這類統一工作流會更有價值。不同工具能力不同，但專案規範、評審習慣和任務拆解方法應該盡量一致。

計劃階段有什麼用

計劃階段的價值，是防止 AI 過早動手。

複雜任務裡，真正重要的問題通常是：

要改哪些檔案
哪些模組可能受影響
現有模式是什麼
有沒有測試
風險點在哪裡
是否需要先閱讀文件
能不能拆成更小步驟

如果 Agent 沒有先想清楚這些問題，就直接開始寫程式碼，很容易做出看似完成、實際偏離專案結構的實現。

計劃並不一定要很長。好的計劃應該短、具體、可執行。它的目的不是製造文件，而是讓後續實現有邊界。

執行階段要避免什麼

AI 執行程式碼任務時，最容易出現幾類問題：

順手重構無關程式碼
覆蓋使用者已有修改
只改 happy path
忽略錯誤處理
不按專案已有風格寫
沒有執行必要驗證
遇到錯誤後盲目嘗試

工作流插件無法保證這些問題完全消失，但可以透過規則和階段約束減少發生機率。

比如，執行階段可以要求 Agent 按計劃逐步推進；遇到超出計劃範圍的發現時，先說明風險；修改共享模組時，補充測試或至少執行相關驗證。

這種約束對大型程式碼庫尤其重要。AI 寫程式碼越快，越需要流程來限制它的慣性。

評審階段為什麼重要

很多 AI 編程失敗，不是因為程式碼完全不能執行，而是因為細節有問題：

邊界條件沒處理
狀態更新不一致
API 合約被悄悄改了
測試覆蓋不到關鍵路徑
錯誤提示不清楚
效能或安全風險沒有被提到

評審階段就是把 Agent 從「作者模式」切換到「審查模式」。

作者模式容易為自己的實現找理由；審查模式則要主動找漏洞、回歸風險和遺漏測試。把這兩個階段分開，會比讓同一個回覆裡同時完成實現和自我審查更可靠。

對使用者來說，評審輸出也更有價值。它能幫助你快速判斷這次修改是否值得合併，還是需要繼續返工。

學習和記憶的意義

專案名字裡的 “Compound” 暗示了一個重要想法：工程經驗應該複利增長。

如果 AI 每次犯錯後只是當場修好，下次又犯同樣錯誤，效率提升就很有限。更好的方式是把有價值的經驗沉澱下來：

這個專案的目錄約定
某類錯誤的排查方法
測試命令和注意事項
不要觸碰的生成檔案
程式碼風格偏好
常見實現模式

這些經驗可以變成規則、記憶、文件或模板。後續任務中，Agent 先讀取這些沉澱，再開始工作。

這就是 AI 編程從「單次問答」走向「長期協作」的關鍵。

適合什麼場景

Compound Engineering Plugin 適合這些場景：

長期使用 AI Agent 寫程式碼
一個專案會被多次、多輪修改
希望 AI 先計劃再實現
希望改完後自動進入 review 思維
團隊想統一 AI 編程流程
同時使用 Claude Code、Codex、Cursor 等多個工具
希望把專案經驗沉澱成可複用規則

如果只是偶爾讓 AI 寫一個小腳本，完整流程可能顯得偏重。

但如果你正在把 AI 編程助手當成日常開發夥伴，計劃、執行、評審、學習這套循環就會明顯有用。

和普通提示詞模板有什麼區別

普通提示詞模板通常解決的是「怎麼說清楚任務」。

比如：

請一步步思考
請先閱讀檔案
請保持程式碼風格一致
請執行測試
請總結修改內容

這些提示當然有用，但它們還是依賴使用者每次正確使用。

Compound Engineering Plugin 更偏工作流層。它把這些要求組織成可重複的過程，並適配不同 Agent 工具。這樣你不是每次從零寫提示詞，而是在一套流程裡推進任務。

簡單說，提示詞模板像提醒，工作流插件像制度。

使用時要注意

第一，不要把流程變成負擔。

小任務不一定需要完整計劃和長篇評審。好的工作流應該能根據任務複雜度調整，簡單問題快速處理，複雜問題再走完整循環。

第二，評審不能替代測試。

Agent review 能發現很多問題，但它仍然可能漏掉真實執行時錯誤。最終判斷還要看測試、型別檢查、構建結果和人工審查。

第三，規則要持續清理。

沉澱經驗很重要，但規則越積越多也會變成噪音。過時規則、重複規則、只適合某次任務的臨時經驗，都應該定期整理。

第四，跨工具一致不等於完全相同。

Claude Code、Codex、Cursor、Copilot 等工具能力和互動方式不同。統一的是工作方法，不一定是每個命令、每個配置細節都完全一樣。

適合怎樣的團隊

如果一個團隊已經允許 AI Agent 修改真實程式碼，那麼只討論「哪個模型更強」是不夠的。

更應該關心：

AI 修改前是否理解任務
AI 修改中是否遵守專案邊界
AI 修改後是否主動審查風險
AI 是否能從歷史錯誤中學習
團隊是否有統一的 Agent 使用規範

Compound Engineering Plugin 這類專案的意義就在這裡。它把 AI 編程從個人技巧，往團隊可複用流程推進了一步。

參考

EveryInc/compound-engineering-plugin

最後一句

Compound Engineering Plugin 值得關注的地方，不是多一個 AI 編程命令，而是把 AI 編程組織成可循環改進的工程流程。

當 AI Agent 開始參與真實專案，計劃、執行、評審和經驗沉澱會比單次生成程式碼更重要。

Claude Code Hooks Mastery：13 個 Hooks 生命週期與自動化控制入門

Fri, 01 May 2026 03:11:27 +0800

claude-code-hooks-mastery 是一個圍繞 Claude Code Hooks 的學習專案。

它不是只給幾個零散腳本，而是把 Claude Code 的 hooks 生命週期、配置方式、腳本寫法和常見自動化場景放在一起講清楚。對想讓 Claude Code 更可控、更像工程化助手的人來說，這類資料很值得看。

Claude Code 預設已經能讀程式碼、改檔案、跑命令。但如果你想讓它在特定時機自動檢查權限、攔截危險操作、注入專案規範、執行測試、提醒團隊規則，單靠聊天指令就不夠穩定。Hooks 的價值就在這裡：把「每次都要提醒 AI 的規則」變成可執行的流程。

Hooks 解決什麼問題

使用 Claude Code 一段時間後，常見痛點大概有這些：

每次新會話都要重複告訴它專案規則
擔心它執行不該執行的命令
希望檔案修改前後自動做檢查
想在提交前自動跑格式化、測試或安全掃描
想把團隊規範寫成固定流程，而不是靠口頭提醒
想在工具呼叫前後拿到上下文，做記錄或攔截
希望複雜任務可以觸發子代理或專門腳本處理

Hooks 就是為這些「固定時機的自動動作」準備的。

你可以把它理解成 Claude Code 工作流裡的事件鉤子：當會話開始、使用者提交提示詞、模型準備呼叫工具、工具呼叫完成、代理即將結束等節點發生時，Claude Code 可以執行你配置的腳本。

13 個 Hooks 生命週期

專案 README 的重點之一，是系統整理了 Claude Code 的 13 個 hook 事件。

這些事件覆蓋了從會話開始到工具呼叫、從使用者輸入到代理結束的多個節點。按用途可以粗略分成幾類：

會話啟動相關：用於初始化環境、注入專案上下文
使用者輸入相關：用於檢查提示詞、補充規則、做稽核
工具呼叫前相關：用於權限判斷、命令攔截、安全檢查
工具呼叫後相關：用於記錄結果、觸發格式化、執行驗證
任務結束相關：用於總結、清理、通知或保存狀態

這種生命週期設計讓你不必把所有規則都寫進一個超長提示詞裡。

比如，權限控制應該發生在工具呼叫前；格式化檢查更適合發生在檔案修改後；專案規範注入適合發生在會話開始或使用者輸入後。把規則放到正確的 hook 節點，通常比把所有內容塞進 system prompt 更可靠。

配置檔案在哪裡

Claude Code 的 hooks 通常透過設定檔配置。

常見位置包括：

使用者級配置：~/.claude/settings.json
專案級配置：.claude/settings.json

使用者級配置適合放個人偏好，比如通用安全規則、命令攔截、日誌路徑。

專案級配置適合放倉庫相關規則，比如這個專案必須跑什麼測試、哪些目錄不能改、生成檔案怎麼處理、提交前要做哪些檢查。

如果你在團隊裡使用 Claude Code，更推薦把專案級配置放進倉庫。這樣每個人打開專案時，拿到的是同一套 AI 協作約束，而不是各自憑記憶提醒。

單檔案腳本為什麼重要

專案裡強調了 UV 單檔案腳本的寫法。

這類腳本的好處是部署簡單。一個 Python 檔案就可以宣告依賴並執行，不必為了一個 hook 單獨維護複雜環境。對 hooks 來說，這很合適，因為很多 hook 只是做一件小事：

檢查命令是否允許執行
判斷檔案路徑是否安全
讀取專案規範並返回給 Claude
掃描輸出中是否包含敏感資訊
在修改後執行格式化或測試
把事件寫入日誌

Hook 腳本越小，越容易維護，也越不容易變成新的複雜系統。

可以做哪些自動化

claude-code-hooks-mastery 展示的方向比較多，實際工作中最常見的是下面幾類。

1. 權限和安全控制

這是 hooks 最直接的用途。

比如在 Claude Code 準備執行命令之前，先檢查命令內容。如果命令包含刪除、重置、清空、覆蓋等高風險動作，就阻止執行或要求人工確認。

類似規則還可以用於檔案路徑：

不允許修改生產配置
不允許寫入金鑰檔案
不允許刪除遷移腳本
不允許觸碰指定目錄
不允許執行未批准的網路命令

這類保護放在工具呼叫前，比寫一句「不要做危險操作」更可靠。

2. 上下文注入

很多專案都有固定背景：

技術棧
編碼規範
測試命令
分支策略
目錄結構
禁止事項
生成檔案處理規則

這些內容每次手動告訴 Claude Code 很麻煩，也容易漏。Hooks 可以在會話開始或使用者提交提示詞後，把必要上下文自動注入進去。

這相當於給 Claude Code 配一個專案級的工作說明書。它不會替代 README 或開發文件，但能讓 AI 在執行任務前更快進入正確狀態。

3. 修改後的驗證

當 Claude Code 修改檔案後，可以透過 hook 自動觸發檢查。

常見動作包括：

執行格式化
執行 lint
執行單元測試
檢查型別錯誤
掃描生成檔案
校驗 Markdown 或 JSON 格式

這對減少低級錯誤很有幫助。尤其是 AI 改動多個檔案時，修改後自動跑一輪輕量驗證，可以更早發現問題。

不過也要注意，hook 裡不適合預設塞太重的任務。每次檔案改動都跑完整測試套件，可能會讓體驗變得很慢。更實用的做法是按檔案類型、目錄和任務風險選擇檢查範圍。

4. 團隊規則驗證

如果團隊已經有明確約定，可以把一部分約定放進 hooks。

比如：

提交訊息格式
程式碼風格規則
禁止直接修改某些生成檔案
文件必須同步更新
API 變更必須改測試
某些目錄只能用指定工具生成

這會讓 Claude Code 更像團隊流程的一部分，而不是一個不受約束的外部助手。

當然，hooks 不應該替代 CI。它更適合做本地快速提醒和前置攔截，真正的最終驗證仍然應該交給 CI、review 和測試系統。

5. 子代理和專門任務

README 裡還提到子代理相關內容。

這類用法適合把複雜任務拆給更專門的流程處理。比如主會話負責理解需求，hook 或配置觸發專門的檢查、稽核、總結、文件整理任務。

對個人使用者來說，最先值得做的不是複雜代理編排，而是把重複、明確、低風險的動作交給 hooks。等規則穩定後，再考慮更複雜的自動化。

Statusline 和輸出樣式

專案還覆蓋了狀態列和輸出樣式。

這部分看起來像體驗細節，但對長期使用 Claude Code 很有意義。狀態列可以展示當前上下文、任務狀態、環境資訊或提示資訊；輸出樣式則可以讓 Claude Code 的回答更符合你的工作習慣。

如果你每天都在同一個終端裡和 AI 協作，這些細節會影響效率。好的狀態提示能減少誤操作，也能讓你更快判斷當前會話是否處在正確專案、正確分支、正確環境裡。

不要把 hooks 寫得過重

Hooks 很強，但不適合什麼都往裡面塞。

比較好的規則是：

高頻動作要快
安全攔截要明確
輸出要短
失敗原因要可讀
腳本盡量單一職責
重型檢查交給顯式命令或 CI

如果一個 hook 每次都執行十幾秒，使用者很快就會想關掉它。如果一個 hook 攔截規則含糊不清，Claude Code 和使用者都會難以理解下一步該怎麼做。

Hooks 最適合處理那些邊界清楚的事情：允許或拒絕、補充上下文、記錄日誌、執行輕量檢查、提示下一步。

適合怎樣的使用者

如果你只是偶爾讓 Claude Code 改一小段程式碼，可能暫時不需要深入 hooks。

但如果你符合下面幾種情況，就很適合研究這個專案：

高頻使用 Claude Code
經常讓 AI 修改真實專案程式碼
擔心 AI 執行危險命令
想把團隊規範自動注入 AI 工作流
希望修改後自動跑檢查
想把重複提醒變成配置
正在搭建更穩定的 AI 編程流程

尤其是多人協作專案，hooks 的意義會更明顯。它可以把一部分團隊經驗沉澱成腳本，而不是靠每個人臨時提醒 AI。

使用時要注意

第一，先從安全類 hook 開始。

相比複雜自動化，命令攔截、路徑保護、敏感檔案檢查更容易落地，也更能立刻降低風險。

第二，專案級規則要謹慎提交。

.claude/settings.json 會影響所有使用這個倉庫的人。把規則提交前，最好確認它不會過度限制正常開發，也不會依賴只有你本機才存在的路徑。

第三，hook 輸出要簡潔。

Claude Code 會消費這些輸出。輸出太長，會污染上下文；輸出太模糊，又起不到指導作用。最好只返回必要判斷和下一步建議。

第四，保持可除錯。

Hooks 一旦變多，問題可能出在配置、腳本、權限、路徑、依賴或 Claude Code 本身。給腳本留下清楚日誌，會讓後續排查輕鬆很多。

參考

disler/claude-code-hooks-mastery

最後一句

Claude Code Hooks 的價值，是把「希望 AI 每次都記住的規矩」變成真正會執行的流程。

如果你已經開始把 Claude Code 用在真實專案裡，hooks 會是從「會聊天的編程助手」走向「可約束的工程協作者」的關鍵一步。

Claude-Mem：給 Claude Code 加上跨會話長期記憶

Fri, 01 May 2026 03:01:02 +0800

Claude-Mem 是一個給 Claude Code 使用的持久化記憶系統。

它想解決的問題很具體：AI 編程助手每次開新會話時，往往會忘記之前討論過的架構決策、踩過的坑、專案偏好和實作背景。
如果一個專案做得久，每次都重新解釋上下文，非常浪費時間。

Claude-Mem 的思路是：把 Claude Code 的會話內容壓縮成記憶，存進本地資料庫和向量庫，之後再透過搜尋工具找回來。

它解決什麼問題

Claude Code 很適合處理程式碼任務，但會話上下文畢竟有限。

常見痛點包括：

新會話不知道舊會話做過什麼
專案裡的設計決策需要反覆解釋
曾經排查過的問題容易重複踩
長期任務缺少連續記憶
多次對話之間很難沉澱專案知識

Claude-Mem 就是圍繞這些問題設計的。

它不是簡單保存聊天記錄，而是把會話壓縮成更容易檢索的記憶片段。這樣後續需要時，可以透過語義搜尋把相關上下文找回來。

工作方式

從 README 的設計看，Claude-Mem 主要由幾部分組成。

第一部分是 hooks。

它會接入 Claude Code 的會話流程，在合適的時機捕獲會話資料。

第二部分是後台 worker。

worker 負責把原始會話內容處理成更短、更可檢索的記憶。

第三部分是本地儲存。

專案使用 SQLite 保存結構化元資料，用 Chroma 保存向量索引。這樣既能保留會話記錄的基本資訊，也能支援語義檢索。

第四部分是 mem-search。

這是給 Claude Code 使用的查詢入口。需要找回舊上下文時，可以透過它搜尋相關記憶。

整體流程可以理解為：

Claude Code 會話產生內容
hooks 捕獲會話資料
worker 非同步壓縮和整理
記憶寫入 SQLite 與 Chroma
後續透過 mem-search 檢索

適合什麼場景

Claude-Mem 適合長期專案，而不是一次性小任務。

比如：

一個倉庫持續開發很多天
程式碼結構複雜，背景說明很多
需要記住專案約定、命名習慣和架構選擇
經常讓 Claude Code 修 Bug、寫功能、整理文件
希望 AI 能記住「之前為什麼這麼改」

如果你只是臨時讓 Claude Code 改一行程式碼，長期記憶意義不大。
但如果你把 Claude Code 當作長期協作者，它就會變得有用。

安裝和啟動

README 中給出的安裝方式很直接：

1
2

npm install -g claude-mem
claude-mem install

啟動時可以使用：

`1`	`claude-mem start`

查看狀態：

`1`	`claude-mem status`

如果需要停止：

`1`	`claude-mem stop`

這些命令背後的目標，是把記憶系統作為一個長期執行的本地服務接到 Claude Code 工作流裡。

`mem-search` 怎麼用

mem-search 是找回記憶的關鍵入口。

它的用途不是替代普通搜尋，而是讓 Claude Code 能按語義查詢過去會話中的內容。

比如你可以讓 Claude Code 查詢：

某個模組之前為什麼這樣設計
某個 Bug 當時怎麼排查
專案裡約定的命名規則
之前討論過的技術取捨
某次重構的背景原因

這種查詢和簡單關鍵字搜尋不同。
如果記憶壓縮和向量索引做得好，即使你不記得原話，也能找回相近語義的內容。

和普通專案文件有什麼區別

專案文件適合記錄穩定結論。

比如：

架構說明
部署流程
API 約定
資料庫結構
開發規範

Claude-Mem 更適合記錄會話過程中產生的上下文。

比如：

為什麼某個方案被放棄
某個臨時問題怎麼繞過
某個實作背後的討論過程
還沒來得及寫進文件的專案偏好
多次對話裡積累出的任務背景

兩者不是互相替代。
比較好的方式是：穩定知識寫進專案文件，過程性上下文交給記憶系統輔助檢索。

使用時要注意什麼

第一，長期記憶不是越多越好。

如果所有對話都無差別保存，後續檢索可能會變得嘈雜。真正有價值的是專案決策、實作背景、問題排查和長期偏好。

第二，記憶不能替代程式碼和文件。

AI 搜到的舊上下文只能作為參考。最終判斷仍然要看目前程式碼、測試結果和最新需求。

第三，隱私和本地資料要注意。

既然它會保存會話內容，就要清楚哪些專案適合接入，哪些敏感資訊不應該進入對話。

第四，記憶系統需要維護。

隨著專案推進，舊記憶可能過時。過時的上下文如果被誤用，反而會誤導後續任務。

為什麼這類工具值得關注

AI 編程工具正在從「單次問答」走向「長期協作」。

單次問答裡，模型只要回答目前問題就夠了。
長期協作裡，它需要知道專案歷史、之前的決策、團隊偏好和已經踩過的坑。

Claude-Mem 這類工具的意義就在這裡：它把「記住上下文」從臨時聊天能力，變成一個可以安裝、執行、檢索的本地系統。

對真實工程專案來說，這比單純讓模型上下文窗口變長更實用。
因為很多資訊不是一次性塞進上下文就好，而是需要在合適的時候被找回來。

適合誰嘗試

如果你符合下面幾種情況，可以考慮試試：

高頻使用 Claude Code
經常跨天處理同一個專案
專案上下文比較複雜
經常需要向 AI 重複解釋背景
想把會話裡的經驗沉澱下來

如果你只是偶爾使用 Claude Code，或者專案很小，暫時不一定需要這類系統。

參考

thedotmack/claude-mem

最後一句

Claude-Mem 的重點不是「保存聊天記錄」，而是讓 Claude Code 能在後續任務裡找回有用上下文。

當 AI 編程從一次性任務變成長期專案協作，記憶系統會越來越重要。
它不能替代文件和測試，但可以減少重複解釋，讓 AI 更像一個了解專案歷史的助手。

Ralph 和多智能體協同：怎麼讓 AI 長時間穩定工作

Mon, 27 Apr 2026 08:19:02 +0800

如果你最近在折騰 coding agent，很快就會遇到一個現實問題：AI 當然能幹活，但怎麼讓它連續幹幾個小時，還不在中途跑偏、忘要求、返工一堆？

圍繞 Ralph 和多智能體協同的這類討論，真正值得看的也正是這個問題。它不是單純比較某個模型有多強，而是把重點放在一層更實際的東西上：怎麼設計工作流，才能讓 AI 在長任務裡保持穩定輸出。

把這個問題拆開看，常見的路線主要有兩條：

Ralph 方案：不斷啟動新會話，透過檔案系統銜接上下文
多智能體方案：主 Agent 做協調，子 Agent 分工執行

如果把它壓成一句更好理解的話，這裡討論的其實不是「哪個模型更厲害」，而是「怎麼把 AI 組織起來，讓它更像一個能持續交付的小團隊」。

01 為什麼長時任務容易失控

短任務裡，很多問題不明顯。你給一句指令，模型讀幾份檔案，改幾行程式碼，事情也就結束了。

但任務一旦拉長，問題會集中冒出來：

會話越來越長，上下文開始膨脹
早先的要求被新資訊擠掉
一個 Agent 既要想方案，又要寫程式碼，還要自己測，容易顧不過來
沒有明確驗收環節時，看起來「做完了」，其實只是「說自己做完了」

所以長時間運行 AI，真正考驗的往往不是模型單次輸出能力，而是 任務拆分、狀態銜接、角色分工和回饋回路。

02 Ralph 方案：把長任務拆成很多短回合

Ralph 的思路很適合先解決「上下文越跑越髒」這個問題。

它的核心做法是：

用循環不斷啟動新的 agent 會話
每輪只處理一個足夠小的任務
把跨輪狀態放到檔案裡，而不是全壓在同一個對話上下文裡

這樣做的好處很直接：每次都是 fresh context，單輪會更聚焦，也更不容易被歷史訊息拖慢。

如果你已經看過 Ralph 相關專案，會發現這套方法背後的邏輯很一致：

當前任務寫在結構化檔案裡
中間經驗寫到進度檔案裡
程式碼變化留在 git 歷史裡

換句話說，Ralph 不是試圖讓一個 Agent「永遠記住所有事」，而是主動把記憶外置，讓會話本身保持輕一點。

這類方案特別適合下面幾種情況：

任務已經能拆成一組小 story
每個 story 都能在單個上下文視窗裡完成
專案裡已經有測試、typecheck 或其他檢查機制

它解決的是「如何讓 AI 一輪一輪穩定推進」。

03 多智能體方案：把一個人做不完的事分出去

另一條路線是多智能體協同。

從這類工作流設計思路來看，更值得推薦的通常是這種方式：主 Agent 不直接埋頭幹活，而是負責協調；子 Agent 各自處理開發、測試、檢查、驗收等不同任務。

這和 Ralph 的區別在於：

Ralph 更像串行迭代
多智能體更像並行分工

如果任務裡天然有不同角色，多智能體會更順手。比如：

一個 Agent 負責拆任務和寫執行計畫
一個 Agent 負責具體實作
一個 Agent 負責測試和驗證
一個 Agent 負責回看結果是不是符合最初需求

這樣做的價值不是「多開幾個視窗顯得很高級」，而是讓不同工作職責分離開。原來塞在一個 Agent 身上的幾件事，現在可以拆成幾個更明確的環節。

一旦角色邊界清楚，很多問題都會變輕：

寫的人不必同時當審的人
跑測試的人不必重新推導整套需求
主 Agent 不會被實作細節淹沒

它解決的是「如何讓 AI 像一個小團隊那樣配合」。

04 真正關鍵的，不是多開，而是怎麼拆

無論是 Ralph 還是多智能體，最容易被忽略的一點都是：流程設計比多開幾個 Agent 更重要。

如果任務拆分不對，就算開再多 Agent，也只是把混亂並行化。

比較穩的拆法通常有幾個特點：

一個任務只對應一個明確目標
一個角色只負責一類輸出
每輪都有清楚的完成標準
上一輪的結果能被下一輪直接消費

比如比起給 AI 一個「把整個功能做完」的大指令，更穩的方式往往是：

先拆出需求和邊界
再拆實作
再拆測試
最後單獨做驗收

這類拆法的好處是，問題一旦出現，更容易知道是出在理解、實作、測試，還是交付標準上。

05 為什麼驗收環節特別重要

很多 AI 工作流失敗，不是因為前面完全沒做事，而是因為最後缺了一個真正獨立的確認動作。

在長任務裡，「已經生成結果」和「結果真的可用」之間，經常隔著一整層差距。

這裡有個很值得重視的方向，就是把開發和驗收拆開看。哪怕不做到特別複雜，至少也應該把這些問題單獨問一遍：

它真的完成了最初那條任務嗎
有沒有只改表面、沒解決根因
測試是不是只驗證了最順利的路徑
有沒有把上游要求悄悄改掉

只要這層檢查缺位，AI 很容易在長流程裡不斷「自我宣布成功」。

06 兩條路線怎麼選

如果只是想快速判斷，可以先這麼理解：

你最痛的是上下文膨脹和長會話失焦，先看 Ralph
你最痛的是一個 Agent 身兼多職、任務之間互相打架，先看多智能體

再具體一點：

Ralph 更適合流程清楚、任務細碎、可以按回合推進的工作
多智能體更適合角色明顯、需要並行和交叉驗證的工作

很多時候，這兩條路也不是非此即彼。比較成熟的做法，反而可能是把它們組合起來：

外層用 Ralph 這種迭代循環推進大任務
內層在單輪裡再用多智能體處理研究、實作、測試和驗收

這樣既能控制長上下文，又能提高單輪內部的協作效率。

07 一句話總結

這類方法最值得看的地方，不是單獨推薦了 Ralph 或多智能體，而是把一個很現實的問題講清楚了：讓 AI 長時間穩定工作，關鍵從來不只是模型本身，而是你有沒有把上下文、任務、角色和驗收設計好。

如果你已經開始讓 Claude Code、Codex 或其他 coding agent 處理更長的真實任務，這類工作流思路會比「再換一個更強模型」更值得優先補課。

Ralph 是什麼：把 Claude Code 和 Amp 變成可循環執行的自主開發流程

Mon, 27 Apr 2026 08:08:55 +0800

如果你最近在關注 coding agent 的長流程執行，snarktank/ralph 是個很值得看一眼的小專案。它不是再做一個新的模型外殼，也不是再包一層聊天介面，而是把 Claude Code 或 Amp 組織成一個可以反覆運行的 autonomous loop，讓 AI 按 PRD 裡的 story 一項一項往前做，直到全部完成。

它的核心思路其實很直接：不要讓同一個 agent 在一個越來越長、越來越髒的上下文裡硬撐，而是每輪都重新啟動一個全新的 AI coding session。 這樣做的好處是，上下文不會一路膨脹，任務邊界也更清楚。

01 Ralph 是什麼

Ralph 的官方定位很明確：它是一個 autonomous AI agent loop，會反覆呼叫 AI coding tool，直到 PRD 裡的項目都做完。

目前倉庫支援兩種工具：

Amp CLI
Claude Code

每一輪迭代都會啟動一個 fresh instance。也就是說，它不依賴「同一個會話一直聊下去」，而是依賴這些外部狀態來保存記憶：

git 歷史
progress.txt
prd.json

這點非常關鍵。很多人讓 agent 跑長任務時，最大的痛點不是模型不會寫，而是會話越跑越重，最後開始漏掉上下文、忘記要求、反覆返工。Ralph 的設計，基本就是衝著這個問題去的。

02 它怎麼工作

Ralph 的工作流分成三步：

1. 先寫 PRD

README 建議先用配套的 prd skill 生成需求文件，把功能拆成比較細的 story。

2. 再把 PRD 轉成 `prd.json`

然後用 ralph skill，把 Markdown 版 PRD 轉成結構化的 prd.json。這個檔案裡會保存 user stories，以及每一項是不是已經通過。

3. 執行循環腳本

真正執行的是 ralph.sh。命令大致是：

1
2

./scripts/ralph/ralph.sh [max_iterations]
./scripts/ralph/ralph.sh --tool claude [max_iterations]

預設是 10 輪。每一輪大致會做這些事：

從 branchName 建立分支
選擇優先級最高、passes: false 的 story
只實作這一項
跑品質檢查，比如 typecheck 和 tests
檢查通過後提交程式碼
更新 prd.json
把經驗追加到 progress.txt
繼續下一輪

也就是說，Ralph 並不追求「一口氣把整件事做完」，而是把任務壓縮成很多個能在單個上下文視窗裡完成的小閉環。

03 Ralph 最有意思的地方

1. 每輪都是 fresh context

這是 Ralph 最核心的設計點。README 強調，每次迭代都是一個新的 AI instance，跨輪記憶只靠 git、progress.txt 和 prd.json。

這和很多人平常直接在一個長對話裡讓 Claude Code 或其他工具連續工作很不一樣。後者在任務變大後，很容易被歷史訊息拖慢，還會逐漸失去焦點。Ralph 則是主動接受「單輪記不住全部」，然後把記憶放到外部檔案裡。

2. 強制把任務拆小

倉庫文件特別強調，單個 PRD item 必須小到能在一個 context window 裡完成。像「加一個篩選器」「改一個 server action」「補一欄資料庫欄位」這種粒度比較合適；而「重構整個 API」「做完整 dashboard」這種就太大了。

這個約束其實很現實。很多 autonomous agent 跑崩，不是 loop 本身有問題，而是任務切分太粗，讓模型一輪裡就背了過量目標。

3. 不只是程式碼，連經驗也要沉澱

除了 progress.txt，README 還特別強調要更新 AGENTS.md。原因也很實際：未來迭代和未來開發者都會讀這些說明，所以每輪發現的模式、坑點、約定，最好都落到專案文件裡。

換句話說，Ralph 不只是讓 agent 連續寫程式，也想讓它連續累積對程式碼庫的工作記憶。

04 它適合什麼場景

如果你的任務具備這些特徵，Ralph 會比較對路：

已經能拆成一組明確的 user stories
程式碼庫裡有比較可靠的回饋回路，比如測試、typecheck、CI
你希望 agent 持續推進，但不想把所有事壓在單個長對話裡
你接受它按迭代方式一點點完成，而不是一次性全做完

反過來說，如果你的需求還很模糊，或者任務本身高度依賴來回討論、頻繁改方向，那 Ralph 可能還不是第一選擇。它更適合「需求已經整理好，現在需要穩定推進執行」的階段。

05 它和一般 Claude Code 用法有什麼不同

如果平常直接用 Claude Code，常見模式是你開一個會話，讓它持續讀程式碼、改程式碼、跑命令。這個方式在中小任務上很好用，但在大任務上容易碰到兩個問題：

上下文越來越長
中間決策不容易結構化沉澱

Ralph 的做法更像把 Claude Code 或 Amp 變成一個「批次執行器」：

任務來源不是臨時聊天，而是 prd.json
每輪只認一個 story
完成狀態寫回檔案
經驗寫進 progress.txt
程式碼提交進 git

所以它更像是「給 coding agent 加了一層迭代控制器」，而不是換了一個新的 AI assistant。

06 一個值得注意的前提

Ralph 能不能跑順，關鍵不在 loop 本身，而在回饋回路夠不夠好。README 寫得很直接：如果沒有 typecheck、tests、CI 這些機制，錯誤會在後續迭代裡不斷累積。

對前端任務來說，倉庫甚至明確建議把「用瀏覽器驗證」寫進 acceptance criteria。因為如果沒有實際驗證，agent 很容易把「看起來寫完了」和「真的可用」混在一起。

這點很重要。Ralph 不是 magical automation，它更像是把你現有的工程紀律放大。如果你的專案本來就有清晰任務拆分和可靠檢查，它會更有價值；如果這些基礎還沒有，loop 只會把混亂重複很多次。

07 一句話總結

Ralph 最值得看的地方，不是它寫了多少新基礎設施，而是它把一個樸素但很有用的思路落成了現成流程：讓 Claude Code 或 Amp 每輪只做一個足夠小的 story，用 fresh context 保持專注，再靠 git、prd.json 和 progress.txt 維持跨輪連續性。

如果你已經開始把 coding agent 用到真實專案裡，並且正被「長任務怎麼穩定推進」這個問題困住，Ralph 這套方法很值得參考。

參考連結

GitHub 倉庫：https://github.com/snarktank/ralph
互動式流程圖：https://snarktank.github.io

Claude Code 環境配置四件套：CLAUDE.md、Rules、Memory、Hooks 一次講清

Thu, 23 Apr 2026 10:43:40 +0800

如果你用了 Claude Code 一段時間，很快就會發現一件事：模型本身當然重要，但你給它什麼環境、什麼邊界、什麼規則，同樣重要。

很多人一開始會把注意力放在「這次 prompt 要怎麼寫」，但真正把 Claude Code 用成熟之後，你會更在意另一件事：

它知不知道你是誰
它知不知道你怎麼工作
它知不知道哪些規則不能違反
它知不知道哪些事情必須先確認
它能不能長期記住這些邊界

Claude Code 之所以能變成一個成熟工具，不只是因為模型強，而是因為它有一整套機制，幫你把這些工作方式沉澱下來。核心上可以拆成四層：

CLAUDE.md
Rules
Memory
Hooks

這篇文章就把這四個部分一次講清楚。

為什麼環境配置比單次提示詞更重要

你可以把 Claude Code 想成你請來的一位助理。

第一天上工時，你不會只跟他說一句「幫我做事」，而是會給他一份說明書，告訴他：

你的身份是什麼
你的溝通語氣偏好是什麼
哪些操作必須先確認
哪些錯誤以前犯過、之後不能再犯
這個專案最重要的文件放在哪裡

這就是為什麼，長期來看，環境配置往往比單次 prompt 更重要。

因為 prompt 解決的是「這一次要做什麼」，而環境配置解決的是「以後每次都要怎麼做」。

第一層：`CLAUDE.md`

先從最基礎的開始。CLAUDE.md 本質上就是一個文字檔。

你可以在裡面寫給 Claude 的說明，例如：

你是誰
你在做什麼
你的溝通偏好
需要遵守的規則
當前專案的特殊背景
重要文件或目錄的位置

每次 Claude Code 啟動時，這份文件都會自動被送進上下文，所以模型一定會讀到。

我通常把它叫做「默契檔」，因為它本質上就是你和模型之間長期協作的默契。

`CLAUDE.md` 適合寫什麼

最適合寫進 CLAUDE.md 的，大致有這幾類：

身份與工作背景
溝通語氣與輸出偏好
全域性的行為規則
常會用到的重要專案背景
常見錯誤與避免方式

例如：

你的時區
你是否接受模型直接發送郵件或訊息
哪些操作屬於不可逆行為
你處理文件與檔案的習慣
安全規範與敏感資訊邊界

一個很重要的原則：盡量精簡

CLAUDE.md 有一個很重要的原則，就是一定要盡量精簡。

原因很簡單：它每次都會被強制注入上下文。

如果你寫得太長，就會佔掉大量上下文空間，導致真正重要的資訊被稀釋。模型不是不讀，而是注意力會分散，最後更容易漏掉你最在意的規則。

官方建議通常是最好不要超過 400 行。

我自己的習慣會更保守一些，盡量控制在 200 行以內。

`CLAUDE.md` 的常見作用範圍

CLAUDE.md 實際上有不同的放置層級，對應不同的作用範圍。最常用的是兩個：

1. User Level

這是全域層級。

它放在你的電腦環境裡，對你本機操作的所有專案都有效。

這個位置適合放：

你的身份資訊
通用的溝通偏好
你跨專案都適用的做事習慣
全域性的安全規則

例如，如果你的時區不是常見的預設值，而是曼谷時間，那這類資訊就很適合放在 user level，這樣模型之後幫你安排時間時就不容易出錯。

2. Project Level

這是專案層級。

它放在具體專案目錄下面，只對那個專案有效。

這個位置適合放：

專案專屬背景
只在這個專案裡成立的規則
專案目錄結構說明
這個專案的重要文件入口

舉例來說，如果一個專案處理財務，另一個專案處理人事，那兩邊的背景和限制顯然不同，就不應該混在同一個全域說明裡。

怎麼判斷該放哪一層

判斷方式其實很簡單：

你寫進去的東西，如果換到另一個專案裡還成立，那就放 user level。

如果一換專案就不成立，那就放 project level。

怎麼開始寫第一版

最常見的起手方式有兩種：

1. 用 `/init`

你可以直接在終端執行斜線命令 /init，讓 Claude 掃描目前專案，自動幫你生成一份基礎版 CLAUDE.md。

2. 讓 Claude 幫你整理

你也可以直接讓 Claude 去搜尋別人怎麼寫 CLAUDE.md，再結合你的情況問你問題，最後幫你整理成適合你自己的版本。

很多時候，這會比自己從零開始寫輕鬆得多。

一個很實用的習慣

在你和 Claude 長期協作的過程中，只要你發現某件事情屬於「以後一定要記住、不要再犯」的內容，就可以直接讓它寫進 CLAUDE.md。

不過寫之前，還是要先判斷：

這是全域規則
還是目前專案規則

不要把所有東西都塞進同一個檔案裡。

第二層：`Rules`

接下來是 Rules。

它和 CLAUDE.md 最大的差別，不是檔案形式，而是載入方式。

CLAUDE.md 是無論你做什麼，模型都會讀到。

而 Rules 的優勢在於：可以條件載入。

也就是說，只有在某些路徑、某些檔案、某些工具或某些場景下，這條規則才會被讀到。

為什麼條件載入很重要

因為上下文空間永遠是稀缺資源。

如果所有規則都無差別塞進上下文裡，就會發生兩件事：

模型負擔變重
真正關鍵的規則反而被淹沒

按需載入的價值就在這裡：讓模型在剛好的時候讀到剛好的資訊。

什麼時候該把規則從 `CLAUDE.md` 挪到 `Rules`

通常有兩種情況：

1. `CLAUDE.md` 太長了

如果你的 CLAUDE.md 開始超過 200 行，規則越來越多，重要內容被稀釋，那就該考慮把一部分規則拆出去。

2. 某些規則只和特定路徑相關

如果你已經很明確知道某些規則只在某些類型的檔案裡才有意義，例如：

只對 Python 腳本有效
只對某個 hooks 目錄有效
只對某個子專案有效

那這些規則就更適合移到 Rules。

`Rules` 最適合的場景

最典型的就是「特定情境、特定路徑、特定檔案類型」。

例如：

只在處理 hook 檔案時觸發的規範
只在某類腳本中要遵守的編碼規則
只在某個目錄下適用的工作方式

這些內容如果繼續塞在 CLAUDE.md 裡，其實不太划算。

第三層：`Memory`

第三個層面是 Memory。

它和 CLAUDE.md、Rules 一樣，也會進入模型上下文，但它最核心的差別是：

CLAUDE.md 是你主動設定的。

Memory 更像是 Claude 在協作過程中，寫給自己的筆記。

`Memory` 記的是什麼

當 Claude 判斷某件事值得記住，或需要短期保留，它就會把這些內容寫進 Memory。

常見內容包括：

你糾正過它的某種做法
你最近新增的偏好
當前專案的暫時狀態
你今天沒做完、明天還要繼續的事
你最近在跟哪些人合作
某些最近才提到的個人資訊或上下文

換句話說，Memory 更像動態知識，而不是長期制度。

`Memory` 和前兩者的差別

一個簡單的區分方式是：

CLAUDE.md / Rules：偏長期、偏制度、偏明確規則
Memory：偏暫時、偏動態、偏工作過程中的新理解

如果某件事只是在最近幾天有效，或專案狀態持續在變，那它通常更適合放進 Memory，而不是寫成長期規則。

`Memory` 也可以手動寫

雖然 Memory 有自動整理能力，但你也可以主動告訴 Claude：

請記下來我明天要做什麼
請記下來我要追蹤誰的狀態
請記下來這個月某個專案的關鍵節點

它也可以幫你寫進 Memory。

你也可以透過斜線命令 /memory 查看目前有哪些記憶，並手動編輯或刪除。

不過很多時候，我自己不會太頻繁手動維護，因為 Claude 本身也會定期整理這些記憶，把已經過時的部分清掉。

第四層：`Hooks`

最後也是最重要、最進階的一層，就是 Hooks。

前面講到的 CLAUDE.md、Rules、Memory，本質上都還是自然語言說明。

你寫了規則，模型通常會遵守，但它本質上仍然是在「理解之後再執行」。

只要還停留在自然語言，就會存在幾個問題：

模型偶爾會漏掉
規則太多時，注意力會分散
某些情境下，它會自己判斷這條規則不重要

這不是你寫得不夠認真，而是自然語言規則本來就很難做到 100% 強制。

`Hooks` 的本質是什麼

Hooks 不再是自然語言說明，而是一段腳本。

它是事件觸發的、程式層級的強制邏輯。

只要某個事件發生，這段邏輯就一定會執行，不會被模型「自己判斷後略過」。

這就是 Hooks 最關鍵的價值：

把「建議遵守」變成「必須執行」。

什麼時候該上 `Hooks`

當你發現某條規則已經寫進 CLAUDE.md 或 Rules，但 Claude 偶爾還是不執行，而且這件事一旦漏掉，風險又很大，那就應該考慮把它改成 Hooks。

簡單說：

低風險的，用規則
高風險的，用 Hooks

最典型的 `Hooks` 場景

最典型的，就是那些你絕對不希望出錯的動作，例如：

發郵件前必須確認
發 Slack、Outlook、Gmail 訊息前必須確認
刪除危險檔案前必須攔截
偵測到要外發密碼或 API Key 時必須阻止

如果這些要求只是寫成一句自然語言規則，模型有可能哪天真的忙中出錯，就送出去了。

但如果寫成 Hooks，只要事件發生，就會被強制攔截。

這才是程式層面的硬防線。

`Hooks` 常見的觸發時機

Hooks 可以設定在很多不同階段，例如：

對話剛開始時注入提醒
某個工具執行前先做檢查
某個工具執行後做結果校驗

你不一定需要自己知道那些專業術語。

很多時候，只要你能清楚描述需求，再讓 Claude 幫你判斷這條規則適不適合改成 hook，它就能幫你一起設計。

你也可以透過斜線命令 /hook 查看系統目前已經設定了哪些 hooks。

一套更實用的上手順序

如果你想把這四層串起來，我自己更推薦下面這條路徑：

第一步：先用 `/init` 生成基礎版 `CLAUDE.md`

不要一開始就手寫一份特別完整的規則文件。

先讓 Claude 幫你掃描專案，生成一個起點版本，再慢慢迭代。

第二步：邊用邊補

在協作過程中，只要你發現：

這件事以後一定要記得
這個錯誤以後不能再犯
這個偏好以後每次都適用

就讓 Claude 幫你寫進 CLAUDE.md。

第三步：當 `CLAUDE.md` 變長時，拆到 `Rules`

一旦你發現 CLAUDE.md 越來越長，模型開始不一定遵守每一條規則，就該考慮拆分：

哪些是全域規則
哪些只和某些路徑相關

把後者移到 Rules，改成條件載入。

第四步：再把高風險規則升級成 `Hooks`

如果某些規則即使寫了，模型還是偶爾會漏，而且漏掉代價很高，那就不要再停留在自然語言層面，直接升級成 Hooks。

也就是把「提醒」變成「強制」。

第五步：把暫時狀態交給 `Memory`

對於那些會過期、會變化、不是長期制度的內容，不要一股腦全寫進 CLAUDE.md。

更合適的做法是交給 Memory：

當前專案進度
最近合作對象
最近新增偏好
近期計畫和待辦

這樣上下文會更清爽，模型也更容易保持穩定表現。

這四層分別該記什麼

如果你想快速記住，可以直接用下面這個區分：

CLAUDE.md：長期默契、全域說明、專案基礎背景
Rules：按路徑或場景載入的專項規則
Memory：動態知識、暫時狀態、最近學到的東西
Hooks：高風險操作的程式級強制攔截

結語

很多人把 Claude Code 當成「會寫程式的聊天介面」，但真正用深之後，你會發現它更像一個長期協作的智慧工作台。

關鍵不只是你每次怎麼下指令，而是你有沒有給它一套穩定、清楚、能長期累積的環境。

一旦你把這四層搭起來：

CLAUDE.md
Rules
Memory
Hooks

你和模型之間的協作品質，通常會有非常明顯的提升。

因為你終於不是每次都從零開始解釋自己是誰、怎麼工作、哪些事不能做，而是把這些真正沉澱成了環境的一部分。

這才是把一個強模型，真正用成成熟工具的關鍵一步。

Claude Code 多 Agent 協作：Subagents 和 Agent Teams 怎麼選

Wed, 22 Apr 2026 21:35:52 +0800

在 Claude Code 裡，和多 Agent 協作最容易混淆的兩個概念，就是 Subagents 和 Agent Teams。它們看起來都像是「開幾個 Agent 一起做事」，但定位其實不一樣。簡單說，前者更適合把獨立任務分出去做，後者更適合讓多個 Agent 圍繞同一件事持續協作、彼此驗證。

如果你之前用過 Skill，也可以先這樣理解：

Skill 負責定義流程和規則
Subagent 或 Agent teammate 負責實際執行任務

所以真正的問題不是哪個「更高級」，而是你要處理的是哪一類協作問題。

Subagents：把支線任務分出去

Subagents 更像是在目前會話裡臨時派出去的分身。每個分身都有自己的上下文視窗，做完之後只把結果摘要帶回來，主對話不會被大量中間輸出塞滿。

這類能力有幾個很直接的優點：

主線對話更乾淨，不容易被測試日誌、搜尋結果或長輸出污染
可以把彼此獨立的研究或執行任務並行化
很適合「把結果帶回來就好」的任務

原文提到，Claude Code 內建了三類 Subagent：

Explore：唯讀，適合快速搜尋程式碼庫
Plan：唯讀，適合在 plan mode 裡於背景收集資訊
General-purpose：可讀可寫，適合同時探索與修改的任務

自訂 Subagent

如果內建能力不夠，可以自己定義一個 Subagent。做法不複雜，本質上就是寫一個 Markdown 檔案：

.claude/agents/：只在目前專案生效
~/.claude/agents/：對所有專案生效

檔案格式類似這樣：

---
name: code-reviewer
description: Expert code review specialist. Proactively reviews code for quality, security, and maintainability. Use immediately after writing or modifying code.
tools: Read, Grep, Glob, Bash
model: inherit
---
You are a senior code reviewer ensuring high standards of code quality and security.

When invoked:

1. Run git diff to see recent changes
2. Focus on modified files
3. Begin review immediately

Review checklist:

- Code is clear and readable
- Functions and variables are well-named
- No duplicated code
- Proper error handling
- No exposed secrets or API keys
- Input validation implemented
- Good test coverage
- Performance considerations addressed
Provide feedback organized by priority:

- Critical issues (must fix)
- Warnings (should fix)
- Suggestions (consider improving)

Include specific examples of how to fix issues.

這裡最關鍵的是 description。Claude 會根據這段描述判斷什麼時候該呼叫這個 Subagent，所以寫得越精準，觸發通常越準。

另外幾個常見設定欄位也很實用：

tools：限制它可以使用哪些工具
model：決定使用 sonnet、opus、haiku 或 inherit
permissionMode：控制編輯權限與權限提示行為
memory：給 Subagent 一個跨對話記憶目錄

如果只是暫時要用一次，也可以直接透過 CLI 注入：

claude --agents '{
  "code-reviewer": {
    "description": "Expert code reviewer. Use proactively after code changes.",
    "prompt": "You are a senior code reviewer. Focus on code quality, security, and best practices.",
    "tools": ["Read", "Grep", "Glob", "Bash"],
    "model": "sonnet"
  }
}'

Subagents 適合什麼場景

Subagents 最適合的，通常是這幾類任務：

跑測試並只回傳失敗摘要，而不是把幾千行日誌全塞回主會話
並行調查幾個互不依賴的模組
把「找問題」和「修問題」拆成簡單的流水線

例如：

`1`	`Research the authentication, database, and API modules in parallel using separate subagents`

`1`	`Use the code-reviewer subagent to find performance issues, then use the optimizer subagent to fix them`

但如果任務需要頻繁來回調整、不同階段共享大量上下文，或者改動高度集中在一兩個檔案裡，那麼直接在主對話中處理，往往比另外派一個 Subagent 更省事。

Agent Teams：多個獨立會話一起協作

Agent Teams 是另一個層級的能力。它不是在同一個會話裡派出分身，而是啟動多個彼此獨立的 Claude Code 實例，讓它們圍繞共享任務清單協作，還可以彼此直接傳訊。

這也讓它更像是一個真正的小團隊，而不只是「把支線任務分出去」。

原文提到，這項功能目前仍然是實驗功能，需要先開啟：

{
    "env": {
        "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
    }
}

把它加到 settings.json 後，就可以讓 Claude 依照你的需求組成一個 team。比如：

1
2
3

I'm designing a CLI tool that helps developers track TODO comments across
their codebase. Create an agent team to explore this from different angles: one
teammate on UX, one on technical architecture, one playing devil's advocate.

Agent Teams 的組成

一個 Agent Team 主要由三部分組成：

Team lead：你目前使用的主會話，負責組隊、分派與彙總
Teammates：多個彼此獨立的 Claude Code 實例
Task list 和 Mailbox：共享任務清單與訊息通道

和 Subagents 最大的差別在於，teammates 之間可以直接溝通，不需要每次都透過 lead 中轉。任務狀態通常會在 pending、in progress、completed 之間流轉，而成員完成一項任務後，也可以繼續認領下一項。

Agent Teams 適合什麼場景

當任務需要多角度討論、互相挑戰結論，或者拆成多個模組並行推進時，Agent Teams 會更合適。

原文舉了幾個很典型的場景：

多位 reviewer 並行審查同一個 PR，但各自關注不同面向
多個 Agent 針對同一個 bug 提出不同假設，並互相反駁
前端、後端、測試分別推進不同模組

例如並行程式碼審查：

Create an agent team to review PR #142. Spawn three reviewers:
- One focused on security implications
- One checking performance impact
- One validating test coverage
Have them each review and report findings.

再比如辯論式偵錯：

Users report the app exits after one message instead of staying connected.
Spawn 5 agent teammates to investigate different hypotheses. Have them talk to
each other to try to disprove each other's theories, like a scientific
debate. Update the findings doc with whatever consensus emerges.

這類任務的共同點是：你不是只要一個答案，而是需要多個 Agent 彼此交換判斷、質疑假設，最後收斂出更可靠的結論。

兩者怎麼選

如果想快速區分，可以直接記這條：

做完把結果帶回來，用 Subagents
需要討論與交叉驗證，用 Agent Teams

再展開一點，主要差異可以從這幾個面向來看：

通訊方式：Subagents 主要把結果回報給主會話；Agent Teams 的成員之間可以直接互相溝通
協調模式：Subagents 更依賴主對話統一調度；Agent Teams 有共享任務清單，成員可以自行認領
Token 成本：Subagents 較省；Agent Teams 較高，因為每個 teammate 都是獨立實例
適用任務：Subagents 更適合獨立、結果導向的工作；Agent Teams 更適合需要討論與交叉驗證的工作

使用時要注意什麼

Agent Teams 雖然更強，但不代表每個任務都值得直接開 team。原文特別提醒了幾個實際問題：

token 消耗明顯更高
若多個 teammate 同時編輯同一個檔案，很容易互相覆蓋
teammate 太多會增加協調成本，不一定帶來更好效果

因此，通常比較穩妥的做法是：

先從 3 到 5 個 teammate 開始
依模組或檔案拆任務，避免寫入衝突
如果 lead 太早接手了 teammate 的工作，要明確要求它先等隊友完成

另外，目前的實驗功能也還有一些限制，例如：

不支援 /resume 和 /rewind 恢復 in-process teammates
任務狀態有時會延遲，需要手動提醒更新
一個 lead 一次只能管理一個 team
teammate 不能再派出子 team

簡單結論

這兩種能力並不是互相替代，而是分別解決不同的協作問題。

如果你的需求是「把支線任務並行做掉，保持主上下文乾淨」，那就先用 Subagents。如果你的需求是「讓幾個 Agent 像小團隊一樣協作、討論、交叉驗證」，那麼 Agent Teams 會更適合。

實際拿一個任務試一次，通常很快就能感受到差別：一個強調上下文隔離與結果回收，另一個強調多視角協作與持續互動。

nuwa-skill：把「蒸餾一個人」從靈感變成可執行流程

Wed, 22 Apr 2026 16:20:00 +0800

[alchaincyf/nuwa-skill](https://github.com/alchaincyf/nuwa-skill) 很容易先讓人想到一件事：用 AI 模仿名人的口吻回答問題。但它真正有意思的地方，不在於「像不像」，而在於它試圖把「蒸餾一個人的思維方式」做成一條可重複執行的流程。

這件事一旦成立，價值就不只是做幾個好玩的角色 prompt，而是把某個人的判斷框架、關注重點、常見啟發式與表達習慣，沉澱成一個可以反覆調用的 skill。你要的不是一句像某人會說出的話，而是一個更接近「如果他來分析這件事，會先看哪裡、怎麼取捨、會質疑什麼」的工作介面。

它解決的不是「模仿」，而是「建模」

很多所謂的人物 prompt，本質上只是風格貼皮。

它們通常會要求模型：

用某個人的語氣說話
多引用這個人的經典句式
盡量模仿他公開表達裡的措辭

這樣做在展示裡很吸睛，但一到真實任務就很容易露餡。原因也很簡單：語氣是表層，判斷結構才是核心。一個人物之所以有辨識度，不是因為他愛說哪幾個詞，而是因為他在面對問題時，總會用某些穩定的方法切入。

nuwa-skill 的方向更像是把這種「穩定的方法」提取出來。換句話說，它在意的不是「怎麼說得像」，而是「怎麼想得像」。

一個更完整的工作流

從倉庫說明來看，nuwa-skill 想做的是一套端到端流程：輸入一個人名，然後自動完成調研、提煉、驗證，再把結果組織成能在 Claude Code 裡調用的 skill。

這背後有幾個很關鍵的變化。

第一，它預設蒸餾對象可以不是你團隊裡的同事。很多人第一次接觸這類能力，會先想到「把優秀同事的方法論沉澱下來」。這當然有價值，但邊界也很明顯：可學習樣本有限，而且往往只覆蓋團隊內部經驗。nuwa-skill 直接把對象擴展到更廣的人群，例如創業者、投資人、科學家、產品經理、寫作者。

第二，它強調的是「自動完成」，而不是讓使用者手工拼 prompt。真正讓這類能力能落地的，不是 prompt 文案寫得多華麗，而是你能不能穩定完成資料蒐集、觀點歸納、模式抽取與結果校驗。只要其中某一步完全依賴手工，重用成本就會迅速上升。

第三，它試圖把產物變成一個 skill，而不是一段一次性的對話。前者可以被多次調用、組合、迭代；後者往往只在當前上下文裡有效，過幾輪就散掉了。

為什麼這個方向值得關注

如果把 AI 當成問答機，最自然的用法是「給我一個答案」。但如果把 AI 當成工作台，問題就會變成「給我一種看問題的方法」。

nuwa-skill 的價值，更偏向後者。

例如你面對一個產品決策，想要的未必是一個標準答案，而是幾種截然不同的分析框架：

有人會先看長期複利
有人會先看資源約束
有人會先看使用者體驗的一致性
有人會先看市場進入時機

如果這些框架能被穩定封裝出來，AI 的角色就會從「替你寫一段話」變成「幫你快速切換視角」。這比單純模仿名人語錄有用得多，因為它直接作用在決策品質上。

它最打動人的地方：把隱性知識變成可調用資產

很多高價值能力，本來就很難寫成 SOP。

一個人為什麼判斷比別人準，往往不是因為他掌握了更多顯性規則，而是因為他在長期實踐裡形成了一套隱性的篩選機制：

什麼訊號值得優先關注
什麼噪音應該直接忽略
哪些問題要拆開看
哪些問題要反過來問
哪些結論必須等待更多證據

這類能力平時很難沉澱，因為它不一定總能被本人完整說清楚。也正因如此，一旦能被結構化提取，價值會很高。nuwa-skill 吸引人的地方就在這裡：它想處理的不是表面知識搬運，而是認知習慣的再組織。

適合什麼場景

我覺得這類 skill 最適合以下幾種場景。

1. 決策前的多視角審視

當你已經有一個方案，但擔心自己只是在沿著熟悉的路徑思考時，切換到不同「人物視角」去審視同一個問題，會比讓模型繼續順著你的原話擴寫更有價值。

2. 學習某類高手的判斷框架

很多人學習高手，習慣收藏語錄、看訪談、抄摘要，但最後往往只記住幾句漂亮話。把思維模式做成 skill 之後，學習方式會更接近「帶著問題反覆調用」，而不是「做一堆靜態摘抄」。

3. 讓團隊共享一種分析方式

團隊裡真正稀缺的，不只是知識文件，而是「我們遇到問題時通常怎麼想」。如果未來這套流程成熟，它也可以反過來用於沉澱組織內部高手的方法論，只是它顯然不打算把這個能力局限在組織內部。

這類專案真正難的地方

當然，方向有吸引力，不代表問題已經解決。

這類專案最難的，從來不是安裝一個 skill，而是下面幾件事：

資料來源是否足夠可靠
提煉出的模式是不是穩定，而不是偶然語料帶來的錯覺
模型是在使用人物框架分析，還是只是在重複常見印象
不同人物之間的邊界會不會被模型自動抹平

也就是說，最關鍵的不是「能不能生成一段像樣的話」，而是「這個 skill 產出的認知框架是否經得起多任務重用」。如果未來它在驗證環節繼續做深，這類專案的可信度會明顯提高。

為什麼它比「提示詞模板庫」更進一步

過去不少專案會把這類能力做成模板庫：一個人物對應一段 prompt，使用者複製進去就能用。問題是模板庫本質上還是靜態資產，更新慢、驗證弱，而且很難形成完整的生產流程。

nuwa-skill 更進一步的地方，是它把「人物蒸餾」從一個模板問題，推進成一個流程問題。

一旦工作重心從「寫一段 prompt」轉到「如何系統生成、校驗、迭代一個人物 skill」，這件事就更像工程，而不是靈感。對真正想長期使用的人來說，後者顯然更重要。

結語

nuwa-skill 有意思，不是因為它把 AI 變成了名人模仿秀，而是因為它把「如何學習一個人的思考方式」這件事，往可執行、可重用、可迭代的方向推進了一步。

如果說很多人物 prompt 解決的是「像誰說話」，那它想解決的，是「像誰那樣看問題」。前者適合展示，後者才更接近生產力工具。

參考連結

GitHub 倉庫：https://github.com/alchaincyf/nuwa-skill
專案說明：https://github.com/alchaincyf/nuwa-skill/blob/main/README.md
Skill 定義：https://github.com/alchaincyf/nuwa-skill/blob/main/SKILL.md

Karpathy 的 65 行 CLAUDE.md：讓 AI 編程少犯三類錯誤

Sun, 19 Apr 2026 18:27:23 +0800

最近 GitHub 上有一個圍繞 AI 編程的專案很火，核心其實只是一個大約 65 行的 CLAUDE.md 文件。它之所以能拿到大量 star，不是因為技術實作複雜，而是因為它抓住了很多人使用 AI 寫程式時反覆遇到的問題。

這個專案的背景，要從 Andrej Karpathy 對 AI 編程的觀察說起。Karpathy 是 AI 領域很有影響力的教育者和工程師：史丹佛博士，參與過 OpenAI 早期工作，也曾在 Tesla 負責 Autopilot 視覺系統。後來他持續分享對大模型、教育和 AI 工具的理解，所以他對編程方式變化的判斷，總會引起很多開發者關注。

他在一次分享中提到，自己使用 Claude Code 幾週後，編程方式發生了明顯變化：過去大概是 80% 手寫程式、20% AI 輔助，現在更接近 80% 讓 AI 寫程式，自己做 20% 修改。他形容這像是「用英語編程」，透過自然語言告訴 LLM 要寫什麼。

但他也指出了 AI 編程的幾個典型問題。

01 錯誤假設

第一個問題是模型很容易替使用者做假設，然後沿著這個假設一路寫下去。它不一定會主動管理自己的困惑，也不一定會在需求含糊時停下來追問。

比如使用者只說「新增使用者匯出功能」，模型可能會預設匯出全部使用者，預設輸出 JSON，預設寫成本地文件，預設權限和欄位都不需要再確認。等程式寫完，使用者才發現它理解的需求和真實場景並不一致。

更好的做法應該是先把不確定點列出來：匯出全部使用者還是篩選結果？是瀏覽器下載還是後台任務？需要哪些欄位？資料量大不大？是否有權限限制？這些問題不問清楚，後面寫得越快，偏得也越遠。

02 過度複雜化

第二個問題是模型很容易把簡單問題寫複雜。一個函式能解決的問題，它可能加上抽象類、策略模式、工廠模式、配置層和一堆「未來可能有用」的擴充點。

這類程式看起來很工程化，實際卻增加了維護負擔。AI 尤其擅長快速生成大量結構，但並不總能判斷這些結構是否真的必要。結果就是一百行能解決的任務，被膨脹成一千行。

判斷標準其實很直接：一個資深工程師看到這段改動，會不會覺得它過度設計？如果答案是會，就應該刪掉多餘層次，用最少的程式碼解決當前問題。

03 附帶傷害

第三個問題是模型有時會修改或刪除自己沒有充分理解的程式碼。它可能在修一個小 bug 的時候順手改註釋、重排格式、清理看似無用的 import，甚至動到和當前任務無關的邏輯。

這類「順手優化」很危險，因為它擴大了變更範圍，也讓 review 變得更困難。使用者本來只想修復一個空 email 導致驗證器崩潰的問題，結果模型順便增強了 email 驗證、加了使用者名稱校驗、改了文件字串，最後很難判斷到底哪一行影響了行為。

更穩妥的原則是：只動必須動的程式碼，只清理自己造成的問題。原本就存在的死程式碼、格式問題或歷史包袱，除非任務明確要求處理，否則最多提醒一句，不要直接改。

04 把吐槽變成 CLAUDE.md

在 Karpathy 的觀點被大量傳播後，開發者 Forrest Cheung 做了一件很聰明的事：他把這些吐槽整理成可以執行的行為準則，寫進一個 CLAUDE.md 文件。

這個專案沒有複雜程式碼，關鍵就是把 AI 編程中最容易出問題的地方，轉成明確的工作規則。大致可以概括為四條。

第一條是先想再寫。不要默默假設，不要隱藏困惑；如果需求有多種理解，就把它們列出來；如果存在更簡單的方案，也要說出來；該追問時追問，該反駁時反駁。

第二條是簡單優先。不新增沒被要求的功能，不為一次性程式碼做抽象，不加入多餘配置，也不為極小機率場景寫大量防禦程式碼。如果 50 行能解決，就不要寫成 200 行。

第三條是精準修改。每一行改動都應該能直接追溯到使用者請求。不要順手改善鄰近程式碼，不要重構沒壞的東西，盡量匹配專案既有風格。

第四條是目標驅動。不要只給模型一個模糊指令，而是給它可驗證的成功標準。比如「修復 bug」可以變成「先寫一個能復現 bug 的測試，再讓測試通過」；「新增校驗」可以變成「寫無效輸入測試並通過」。成功標準越清楚，模型越容易自己循環到完成。

05 為什麼它會火

這個專案能火，不是因為內容很玄，而是因為它足夠貼近真實開發。

很多人用 AI 編程時都經歷過類似場景：模型自信地誤解需求，程式越寫越複雜，或者在不該動的地方動手。CLAUDE.md 的價值，是把這些經驗變成可以放進專案裡的協作規則。

它的門檻也很低：一個文件就能開始生效，不需要複雜接入。再加上 Karpathy 本人的影響力，以及專案裡有實戰對比案例，它很自然會在 Claude Code 使用者和 AI 編程社群裡傳播開來。

更重要的是，這類規則不是只適用於 Claude Code。無論使用哪種 AI 編程工具，本質問題都很相似：模型需要知道什麼時候該問、什麼時候該簡化、什麼時候該停手、怎樣判斷任務已經完成。

06 對普通開發者的啟發

這件事給普通開發者的啟發很簡單：AI 編程不是把一句需求丟給模型，然後等待奇蹟發生。真正有效的方式，是給模型建立邊界。

需求不清楚時，讓它先暴露假設。實作方案變複雜時，讓它主動回到最小可行解。修改程式碼時，讓它只圍繞任務目標行動。完成任務時，用測試、命令或明確檢查點來驗證結果。

AI 寫程式的能力已經很強，但它仍然需要好的協作約束。一個短小的 CLAUDE.md 能獲得大量關注，說明開發者真正需要的並不只是更聰明的模型，也包括更可靠的工作方式。

簡單總結：

先想再寫，減少錯誤假設。
簡單優先，避免過度設計。
精準修改，控制變更範圍。
目標驅動，用可驗證標準推動完成。

這四條並不複雜，卻很實用。AI 編程真正提升效率的前提，不是讓模型寫得更多，而是讓它寫得更準、更少、更可控。

Claude Code 額度省著用：模型選擇、上下文、快取與 /compact

Sun, 19 Apr 2026 15:29:06 +0800

最近很多人在用 Claude Code 或 Claude Max 時會遇到一個問題：明明買了 Pro、Max 5x，甚至 Max 20x，結果沒跑多久就提示額度快滿，或者直接需要等重置。尤其是在大專案裡讓 Claude Code 讀很多檔案、修複雜 bug、跑長任務時，這種感覺會更明顯。

這裡先說結論：額度不是按「時間」線性扣的，而是和模型、上下文長度、附件、程式碼庫規模、對話歷史、工具呼叫和目前容量都有關係。同樣 5 小時視窗，有的人能用很久，有的人十幾分鐘就耗盡，通常不是帳號壞了，而是每次請求都太重。

這篇整理一套比較實用的省額度習慣。

01 先理解 Claude 的用量視窗

Claude Pro 和 Max 都有使用限制，Claude Code 的使用量會和 Claude 網頁、桌面、行動端共享同一套訂閱額度。官方說明裡提到，訊息數量會受到訊息長度、附件大小、目前對話長度、所用模型或功能影響；Claude Code 還會受到專案複雜度、程式碼庫大小、自動接受設定等影響。

大致可以這樣理解：

Pro：適合輕量使用和小專案。
Max 5x：適合更頻繁使用和較大的程式碼庫。
Max 20x：適合更重度、日常高頻協作。
用量視窗按 5 小時會話重置。
長訊息、長對話、大檔案、複雜任務會更快消耗額度。
Opus 這類更強模型會比 Sonnet 更快觸發限制。

所以「我只用了 20 分鐘」這個說法不一定能說明問題。真正重要的是這 20 分鐘裡 Claude 讀了多少上下文、用了什麼模型、是否反覆處理大檔案、是否在同一個長對話裡繼續加任務。

02 第一件事：不要預設一直用最貴模型

Claude 系列裡常見的定位是：

Opus：能力最強，適合複雜推理、架構決策、疑難 bug。
Sonnet：能力和成本比較均衡，適合大部分日常編碼任務。
Haiku：更輕量，適合簡單分類、摘要、格式轉換等任務。

日常寫腳本、改小 bug、整理文件、解釋程式碼，大多數時候 Sonnet 已經夠用。Opus 更適合留給這些場景：

複雜架構設計。
多檔案深度重構。
難復現的 bug。
需要長鏈路推理的排障。
普通模型明顯卡住的任務。

Claude Code 裡可以用 /model 切換模型，也可以在 /config 裡設定預設模型。比較穩的習慣是：預設 Sonnet，關鍵節點再切 Opus，而不是整場任務都用 Opus 扛。

03 第二件事：控制上下文，不要讓舊任務拖著走

上下文越長，Claude 每次處理要看的內容越多，額度消耗也越高。Claude Code 官方文件明確建議主動管理上下文：

換到不相關任務時，用 /clear 清空歷史。
目前任務做完一個階段但還要保留重點時，用 /compact 壓縮。
想知道上下文裡什麼佔空間，用 /context。
想持續看到狀態，可以設定 status line。

一個好用的節奏是：

小階段完成：/compact
大任務結束：/clear
切換無關專案：/clear
上下文接近很高佔用：提前 /compact

/compact 會把前面的對話壓成摘要，保留關鍵任務狀態、結論、檔案路徑、待辦事項，但減少後續每次請求要攜帶的歷史。你也可以給它補一句重點：

`1`	`/compact 保留已修改檔案、測試結果、剩餘待辦和關鍵設計決策`

不要等自動壓縮才處理。官方文件提到，Claude Code 會在上下文接近容量上限時自動壓縮，但手動在階段邊界壓縮，通常更可控。

04 第三件事：長對話和大檔案會讓每次請求變貴

很多人以為「我只是繼續問一句」，應該很便宜。但在長對話裡，這一句背後可能帶著大量歷史、檔案摘要、工具定義和系統規則。

特別容易漲上下文的東西包括：

一直不清理的長對話。
讓 Claude 讀完整大檔案。
貼很長日誌、建置輸出、測試輸出。
一次性塞很多截圖或圖片。
讓它反覆掃描整個倉庫。
過長的 CLAUDE.md。
開了很多 MCP server。

比較省的做法是：日誌只貼關鍵報錯，測試輸出只給失敗部分，大檔案讓它先用 rg、head、tail、符號搜尋定位，再讀必要片段。能用命令列過濾的內容，不要整包塞進上下文。

05 第四件事：理解快取，但不要迷信快取

Anthropic 的 Prompt Caching 會快取重複的 prompt 前綴。預設快取生命週期是 5 分鐘，也支援 1 小時快取。快取命中時，重複的大段上下文不需要完整重新處理，有助於降低成本和改善額度利用。

但快取有幾個限制：

需要內容完全匹配，文字和圖片都要一致。
預設快取是短生命週期。
改模型、改工具、改系統提示、改上下文結構，都可能降低命中。
輸出 token 不會因為快取而消失，該生成的回答仍然要生成。
Claude Code 具體如何利用快取，是產品層實作細節，不要把它當成永遠穩定的「免費記憶」。

實際使用裡，最重要的不是研究快取細節，而是保持會話穩定：

同一階段盡量別頻繁切模型。
不要中途反覆改大量規則。
不要在同一任務裡不停貼新圖片。
長任務中間不要閒置太久後又繼續塞大請求。
階段結束主動 /compact。

這樣更容易讓重複上下文保持可複用，也能降低後續請求負擔。

06 關於尖峰時段：能避開就避開，但不要當固定公式

網路上常有人說某些時段額度會更緊。官方幫助中心的表述更謹慎：可發送數量會受到 Claude 目前容量、對話長度、附件、模型和功能影響。也就是說，尖峰容量確實可能影響體驗，但不要把某個地區的某個時間段當成永久固定規則。

實用建議是：

大重構、大批次分析盡量放到自己網路和服務都穩定的時段。
不要在快到休息時開啟一個超長任務。
預計會離開很久時，先 /compact 或 /clear。
如果只是小改動，不要開 Opus 加長上下文硬跑。

這比記一個固定「幾點到幾點不能用」的規則更可靠。

07 精簡 CLAUDE.md、rules、MCP 和 skills

Claude Code 會在會話中載入專案規則、工具資訊和一部分環境上下文。官方文件也建議把通用規則和專用規則分開，避免每次啟動都帶著一大包不相關內容。

比較推薦的拆法：

CLAUDE.md：只放全域都適用的核心規則。
rules：放特定路徑、特定檔案類型才需要的規則。
skills：放特定工作流，例如發文章、部署、生成圖片、提交程式碼。
MCP：只啟用目前任務真的會用到的 server。

如果 CLAUDE.md 寫了幾百上千行，每次會話都要帶進去。更好的方式是把「偶爾才用」的流程移到 skill 裡，需要時再呼叫。

MCP 也是一樣。工具多不等於效率高。Claude Code 文件提到可以用 /mcp 查看並停用不需要的 server，也可以用 /context 看是什麼佔用了上下文空間。

08 實用指令清單

日常最常用的是這幾個：

/model

切換模型。預設建議用 Sonnet，複雜推理再用 Opus。

/clear

清空目前上下文。換無關任務時用，最省。

`1`	`/compact`

壓縮歷史上下文。一個階段完成但還要繼續同一任務時用。

`1`	`/context`

查看上下文佔用，排查是什麼吃掉空間。

/status

查看目前訂閱或額度相關狀態。官方幫助中心也建議用它監控剩餘額度。

/mcp

查看和管理 MCP server，關閉目前不用的工具。

如果你用 API 計費模式，還可以關注 /cost；但如果是 Pro/Max 訂閱，官方文件說明 /cost 的美元估算不適合作為訂閱帳單依據，訂閱使用者更應該看 /stats 和 /status 這類使用資訊。

09 一套省額度工作流

比較順手的流程可以是這樣：

新任務開始前先 /clear。
預設用 Sonnet。
先讓 Claude 讀專案結構和關鍵檔案，不要一口氣讀全倉庫。
每做完一個小階段就 /compact。
複雜卡點再切 Opus。
日誌、報錯、測試輸出先過濾再給。
任務完成後 /clear，不要拖著舊上下文開新活。
定期檢查 CLAUDE.md、MCP 和 skills，把常駐上下文壓小。

這個流程的核心是：讓 Claude 每次只看目前真正需要看的東西。

10 小結

Claude Code 額度快速耗盡，通常不是單一原因，而是幾個因素疊加：用了高成本模型、長對話一直不清、檔案和日誌塞太多、MCP 和規則常駐過重、快取命中變差，再加上尖峰容量波動。

省額度的核心也很簡單：

日常任務優先 Sonnet。
Opus 留給真正複雜的問題。
階段完成用 /compact。
換任務用 /clear。
用 /context 找上下文佔用來源。
精簡 CLAUDE.md、rules、MCP 和 skills。
不要把整倉庫、整日誌、整圖片包都丟進去。

同樣的 Pro 或 Max 方案，能做多少事，很大程度取決於你怎麼管理上下文。把上下文變小、任務邊界變清楚，Claude Code 的可用時間和穩定性都會明顯好很多。

參考連結

Claude Help Center：Using Claude Code with your Pro or Max plan：https://support.claude.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan
Claude Help Center：About Claude’s Max Plan Usage：https://support.anthropic.com/en/articles/11014257-about-claude-s-max-plan-usage/
Claude Code Docs：Manage costs effectively：https://code.claude.com/docs/en/costs
Anthropic Docs：Prompt caching：https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching