AI編程 on KnightLi的博客

RTK：給 AI 編程代理省 token 的命令列代理工具

Wed, 27 May 2026 13:52:01 +0800

rtk-ai/rtk 是一個面向 AI 編程代理的命令列代理工具。它的思路很直接：很多 agent 在開發過程中會頻繁呼叫 ls、cat、grep、git status、git diff、測試命令和建置命令，而這些命令的原始輸出經常又長又重複。RTK 會在命令輸出進入 LLM 上下文之前先做過濾和壓縮，讓模型看到更短、更有用的結果。

專案地址：rtk-ai/rtk

它解決的是什麼問題

AI 編程工具真正貴的不只是模型呼叫次數，還有上下文裡被塞進去的無效資訊。

例如：

ls -la 可能輸出大量權限、時間和無關檔案。
git diff 可能夾雜很多重複上下文。
pytest、cargo test、npm test 失敗時，最重要的是失敗用例和錯誤堆疊，而不是所有通過項。
docker ps、kubectl pods、aws 命令往往欄位很多，但 agent 只需要少數關鍵資訊。

這些輸出如果原樣進入模型上下文，會快速消耗 token。RTK 的目標不是替代這些命令，而是在它們和 AI 編程代理之間加一層「壓縮代理」。

RTK 的基本工作方式

RTK README 裡給出的定位是：它會在命令輸出到達 LLM context 之前，對結果做過濾和壓縮。它是一個 Rust 單檔二進位程式，支援大量常見開發命令，並強調低額外開銷。

它主要做四類處理：

Smart Filtering：去掉註解、空白、樣板內容和低價值雜訊。
Grouping：把相似項目聚合起來，例如按目錄、錯誤類型或狀態分組。
Truncation：保留關鍵上下文，截斷重複或不重要的部分。
Deduplication：把重複日誌折疊成更短的計數表達。

從 agent 的角度看，命令仍然是熟悉的開發命令；變化在於返回給模型的結果更短。

支援哪些命令

RTK 覆蓋的命令範圍比較偏「日常開發現場」：

檔案查看：rtk ls、rtk read、rtk find、rtk grep
Git：rtk git status、rtk git log、rtk git diff
GitHub CLI：rtk gh pr list、rtk gh pr view、rtk gh issue list
測試命令：rtk pytest、rtk go test、rtk cargo test、rtk vitest、rtk playwright test
建置和 lint：rtk lint、rtk tsc、rtk next build、rtk cargo clippy
容器和雲命令：rtk docker ps、rtk docker logs、rtk kubectl pods、rtk aws sts get-caller-identity
資料和日誌：rtk json、rtk deps、rtk env、rtk log

這類工具最適合 agent 高頻讀命令輸出的場景。它不負責替你寫程式碼，而是讓 agent 少讀雜訊。

安裝和接入方式

README 給了幾種安裝方式。

Homebrew：

`1`	`brew install rtk`

Linux/macOS 快速安裝：

`1`	`curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh \| sh`

Cargo：

`1`	`cargo install --git https://github.com/rtk-ai/rtk`

安裝後可以先檢查版本和統計資訊：

1
2

rtk --version
rtk gain

接入 AI 編程工具時，可以用初始化命令：

rtk init -g
rtk init -g --gemini
rtk init -g --codex
rtk init -g --agent cursor
rtk init --agent windsurf
rtk init --agent cline

初始化後需要重啟對應的 AI 工具。對於支援 hook 的 agent，Bash 命令會在執行前被重寫，例如把 git status 變成 rtk git status，讓 agent 收到壓縮後的輸出。

使用時要注意什麼

RTK 的收益取決於 agent 是否真的透過 shell 命令讀取資訊。

README 裡特別提醒：像 Claude Code 的內建 Read、Grep、Glob 這類工具不經過 Bash hook，因此不會自動被 RTK 改寫。要讓 RTK 介入，需要使用 shell 命令，例如 cat、head、tail、rg、grep、find，或者直接呼叫 rtk read、rtk grep、rtk find。

這點很關鍵。RTK 不是全域透明地壓縮所有 agent I/O，它更像是 shell 命令層面的代理。

Windows 使用者也要注意，README 建議不要直接雙擊 rtk.exe，而是把它放到 PATH 裡，透過 Command Prompt、PowerShell 或 Windows Terminal 使用。它也提到，如果想獲得完整 hook 體驗，WSL 會更自然。

適合誰用

RTK 適合三類人：

重度 AI 編程使用者：每天讓 agent 跑很多 git、rg、測試和建置命令。
大倉庫使用者：命令輸出動輒幾百行，agent 經常被無關上下文淹沒。
關心 token 成本和上下文窗口的人：希望模型把注意力放在失敗、變更和關鍵檔案上。

如果你的專案很小，或者 agent 主要透過 IDE 內建工具讀取檔案，RTK 的體感收益可能沒那麼明顯。它真正發力的地方，是命令列輸出又長又頻繁的開發流。

我的判斷

RTK 的方向很實用。現在很多 AI 編程工作流都在強調更強的模型、更大的上下文、更長的任務，但開發現場還有一個樸素問題：agent 經常讀了太多沒必要讀的東西。

把命令輸出先壓縮，再交給模型，能減少 token 消耗，也能降低模型被雜訊帶偏的機率。

不過它不是魔法開關。要用好 RTK，需要把 agent 的工作方式往 shell 命令靠一靠，並確認目前工具的 hook 是否真的生效。對 Codex、Claude Code、Gemini CLI、Cursor、Windsurf 這類場景來說，它更像一個值得測試的「上下文節流器」：不改變開發命令本身，但讓 agent 讀到更乾淨的結果。

Codex 官方文章解讀：如何把 Codex 用到極致

Wed, 27 May 2026 08:21:18 +0800

多數開發者第一次使用 Codex，通常是從程式碼任務開始：閱讀倉庫、修改 diff、執行測試、打開 pull request。

這仍然是 Codex 的核心場景。但電腦上的很多工作本來就被程式碼和工具包圍：執行 shell 命令、瀏覽網頁、呼叫 API、匯出文件、回應訊息、觸發自動化。隨著這些能力逐漸接入 Codex，它就不再只是狹義的程式碼助手，而更像一個幫你完成電腦工作的系統。

Codex app 讓這種變化變得更具體。一個 thread 可以保留上下文、呼叫工具、展示產物，並在多輪提示之間持續推進，而不是每次對話都重新開始。

想更充分地使用 Codex，關鍵是把這些能力組合起來：

持久執行緒，用來保存長期上下文
語音輸入、steering 和 queuing，讓使用者仍然掌控過程
browser、computer use、MCP servers 和 connectors，讓 Codex 走出倉庫
thread automations 和 Goals，讓任務在使用者離開後繼續推進
側邊欄，用來審閱程式碼、文件、投影片、網頁和其他產物
共享記憶，把重要上下文寫到執行緒之外

持久執行緒

Durable threads 指的是能在多次會話之間保留工作上下文的長執行緒。

Pinned threads 是一種很實用的入口。它適合放那些會反覆回來的工作流程，例如：

Chief of Staff 執行緒
發布執行緒
文件審閱執行緒
外部監控執行緒

這些不是臨時聊天，而是持續存在的工作空間。Codex 可以在後續繼續回到同一個執行緒，沿用之前的決策、偏好和背景資訊，避免每次都從零重建上下文。

快捷鍵也讓它更順手。Command-1 到 Command-9 可以直接跳轉到已保存的執行緒。

語音輸入

語音輸入的價值在於，它能捕捉還沒有被整理成正式文字的想法。

Codex 內建語音輸入。它特別適合那些說起來很自然、打字時卻很彆扭的模糊起點：

1
2
3

我记得 Slack 里好像有个叫 Ben 的人提过这个。
具体细节我不记得了。
帮我去找一下。

對於一個能搜尋、整理上下文並彙報結果的 agent 來說，這通常已經足夠開始。

語音也適合兩三分鐘的想法傾倒。會議轉錄、口述規劃筆記、未整理的原始記錄，往往比一句摘要更有用，因為它們保留了不確定性、重點和沒說完的思路。

Steering 和 queuing

語音和顯式控制結合起來時，會更有用。

Steering 指的是在 Codex 任務執行過程中插入新的方向，讓它在當前步驟結束前改道。

例如在審閱網頁時，使用者可以一邊在側邊欄標註，一邊打斷當前任務：

1
2
3

这里再小一点。
这两个元素之间的间距不对。
这句文案写错了。

Queuing 則不同。它不打斷當前任務，而是把下一步工作排到佇列裡：

`1`	`这项工作完成后，把预览链接发给 Slack 里的 reviewer。`

Steering 改變 Codex 現在正在做什麼。Queuing 改變它接下來應該做什麼。兩者都讓使用者在任務展開時仍然靠近現場。

工具和可觸達範圍

執行緒有了連續性之後，下一個問題就是：它能操作什麼？

Codex 可以一層層向外擴展：

$browser：適合側邊欄裡的網頁檢查、標註和 review
@chrome：適合依賴使用者 Chrome 登入狀態的瀏覽器工作流程
@computer：適合只能透過桌面 GUI 完成的任務

MCP servers 和 connectors 把同樣的思路擴展到更多工作流程中。Slack、Gmail、Calendar 很重要，因為很多任務最初不是以程式碼形式出現，而是以訊息、郵件和日程問題出現。

Skills 則適合固化重複工作。當某個流程已經被證明有用，就可以把它打包成 skill，讓 Codex 下次不必重新學習這套步驟。

從任何地方繼續工作

Codex mobile app 改變了使用者必須坐在電腦前的時間。

一個任務可以在 Mac 上開始，因為檔案、權限和本機環境都在那裡；隨後使用者離開桌面，只用手機繼續確認、補充或改方向。

這在很多小場景裡很有價值：Codex 跑長任務時，使用者可以離開座位；如果它需要確認，可以在外面回覆；如果方向錯了，也能及時 redirect。真正留在原地的是本機環境，而不是使用者本人。

自動化

Automations 可以按計劃執行 Codex 工作。

如果一個週期任務應該從某個 workspace 重新開始，例如日報或常規結庫檢查，可以用 scheduled automation。如果調度應該回到一個已有對話，並沿用它的上下文，就更適合 thread automation。

Thread automations 更像心跳式喚醒：按固定節奏回到同一個 Codex thread。

Pinned threads 需要使用者主動回來，而 thread automation 可以每幾分鐘或每幾小時檢查一次，持續執行到滿足條件為止，並隨時間調整節奏。

例如，一個 Chief of Staff 執行緒可以每 30 分鐘執行一次：

1
2
3

每 30 分钟检查 Slack 和 Gmail，找出需要我注意但还没有回复的消息。
帮我判断哪些最重要。
如果有人问我问题，尽可能深入研究答案，并替我起草回复，但不要发送。

使用者回來時，最耗時的上下文收集往往已經完成。真正要不要發送，仍然由人決定。

Thread automations 也適合反饋循環。它可以定期查看 pull request 評論、Google Docs 評論或 Slack 回覆，在使用者離開時繼續推進周邊工作。

比如一個動畫工作流程，reviewer 在 Slack 裡發來影片反饋，thread automation 定時檢查執行緒；如果有新評論，就重新渲染版本，並在同一個 Slack thread 裡回覆 reviewer。如果某個整合無法完成最終上傳，桌面自動化還可以透過 GUI 補上最後一步。

這個循環會跨過 Slack、程式碼庫和桌面應用，但對使用者來說仍然留在同一個工作流程裡。

Goals

Goals 最適合那些有明確終點、並且 agent 可以持續推進的任務。

一個較弱的 goal 可能是：

`1`	`实现这个 Markdown 文件里的计划。`

更強的 goal 會有可衡量的完成標準。

例如，把一個內部工具從 Python 遷移到 Rust 時，可以先建好新目錄，再把目標說清楚：新實作只有在單元測試通過後才算完成。

Goal 本質上是持續執行加驗證器。使用者需要定義結果、停止條件，以及判斷 Codex 是否更接近目標的訊號。

常見的驗證器包括：

測試套件
benchmark
bug reproduction
validation matrix
必須持續通過的端到端工作流程

任務可以有野心，但沒有驗證條件時，它更像願望，而不是 goal。

側邊欄

側邊欄把工作產物放在生成它的對話旁邊。使用者不必匯出檔案、切換上下文，再回頭描述問題。產物可能是程式碼，也可能是 deck、PDF、網頁、表格，或者工作過程中生成的其他 artifact。

它特別適合四類工作：

檢查 artifact
標註需要修改的地方
操作網頁介面
審閱變更

Markdown、表格、資料表、文件和投影片都可以直接在側邊欄裡看。使用者可以檢查、標註、修改，而不用把這個過程變成另一輪交接。

如果是 deck 或 PDF，它可以一直停在產生它的 thread 旁邊，隨時接受 review 和修復。

瀏覽器也是類似的工作面。Codex 可以打開渲染後的頁面，檢查它，回應使用者在頁面上的標註，並繼續修復同一個對象。網頁既是輸出結果，也是控制表面。

這些表面尤其適合放在側邊欄裡：

index.html 這種輕量靜態 artifact
Storybook
Remotion Studio
瀏覽器投影片
資料分析應用

一個單獨的 index.html 檔案就可以成為長期存在的互動 artifact，不一定需要伺服器。Thread automations 也可以定期刷新靜態 artifact，讓使用者回來時看到新的結果。

共享記憶

長執行緒很有用，但重要上下文不應該只存在於對話記錄裡。

Shared memory 指的是把持久上下文存放在執行緒之外，讓未來的工作可以從明確、可審閱的地方繼續。

一種穩定做法是把持久執行緒錨定在 Obsidian vault 裡。實際形態可以很簡單：一組普通檔案，方便檢查、編輯、移動和長期保存。團隊可以把它放在 cloud storage、Git、Dropbox、Google Drive 或其他同步層裡。

一個 vault 可能長這樣：

vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/

頂層的 AGENTS.md 可以說明 Codex 應該如何維護這個工作空間：什麼資訊要寫下來，寫到哪裡，什麼時候不要製造噪音。

一個實用的 AGENTS.md 可以這樣寫：

- Treat ~/vault as durable work memory.
- Prefer canonical notes over note sprawl.
- Route TODOs, people, projects, daily summaries, and scratch notes explicitly.
- Preserve decisions, blockers, owners, dates, and useful links.
- If nothing meaningful changed, do not churn the vault.

不要照抄某個 vault 結構。更重要的是教會 agent：長期上下文應該放在哪裡，哪些資訊值得保留，什麼時候不應該反覆改動檔案。

倉庫存放程式碼。Vault 存放滾動上下文：相關人員、發生了什麼、哪裡卡住、誰負責、下一步是什麼，以及那些如果不寫下來就會在會話之間消失的細節。

Codex 也有第一方記憶能力，可以在 Settings > Personalization > Memories 中配置。它適合記錄偏好、重複工作流程和常見卡點，但它更適合作為顯式 written context 的補充，而不是替代品。Chronicle 也在同一個方向上推進：從最近的螢幕上下文中幫助 Codex 建立記憶。

從程式碼向外擴展

Codex 仍然從程式碼開始。但程式碼周圍的更多工作，現在也能被同一個系統觸達：MCP servers、瀏覽器介面、桌面控制、thread automations 和可審閱 artifact。

這改變了使用 Codex 的控制方式。Steering 用來打斷正在進行的工作。Queuing 用來排下一步。Thread automations 讓執行緒在使用者離開後繼續活動。Goals 給長期任務加上明確終點和驗證訊號。

當這些能力連起來時，Codex 就能把一個工作流程從指令推進到執行，再推進到 artifact review。即使任務已經離開程式碼倉庫，它仍然可以留在同一個系統裡完成。

原文連結：Getting the most out of Codex

Codex Goal 設定目標失敗：Failed to set goal 怎麼處理

Wed, 27 May 2026 08:17:57 +0800

最近有使用者回饋，使用 Codex Goal 時會立刻出現 Failed to set goal 或「設定目標失敗」的錯誤。這個錯誤和 prompt 長短無關，在 Codex 應用程式和 VS Code 擴充套件裡都可能出現。

從討論裡的回饋來看，這個問題更像是本機功能開關或設定狀態異常，而不是目標內容本身寫錯了。

先檢查 goals 功能開關

最直接的處理方法，是檢查 Codex 的設定檔：

`1`	`~/.codex/config.toml`

確認裡面有 [features] 段，並開啟 goals：

1
2

[features]
goals = true

如果已經有 [features]，只需要在該段下面補上 goals = true。如果沒有這個段，就新建一個。

改完以後，重新啟動 Codex 應用程式或 VS Code 擴充套件，再重新嘗試設定 Goal。

如果還有問題，檢查設定目錄

討論裡也有人提到，.codex 目錄裡的快取或暫存檔異常時，也可能觸發類似問題。

比較穩妥的處理順序是：

先備份 ~/.codex/config.toml。
關閉 Codex 相關應用程式。
暫時移走或重新命名 ~/.codex 目錄。
重新打開 Codex，讓它重建設定目錄。
再把原來的 config.toml 裡需要的設定合併回來。

不要直接刪除設定目錄，尤其是裡面可能有你手動維護的設定、技能、會話或其他本機狀態。

Windows 上還要留意安全軟體

也有回饋提到，Windows Defender 可能會把 config.toml 當成可疑檔案。這不一定是所有人的原因，但如果你在 Windows 上遇到同樣問題，可以順手檢查一下安全軟體的隔離記錄。

如果設定檔被隔離、改名或阻止存取，Codex 讀取不到功能開關，也可能表現為 Goal 無法啟用。

判斷是不是 prompt 的問題

一個簡單判斷方法是：用極短目標測試。

例如：

`1`	`修復一個測試失敗`

如果極短目標也立刻報 Failed to set goal，基本就不是 prompt 寫法問題，而是本機設定、功能開關、擴充套件狀態或快取目錄問題。

如果只有很長、很複雜的目標會失敗，再考慮是否是目標內容太複雜、包含特殊連結、欄位格式不被 UI 接受。

小結

Codex Goal 的 Failed to set goal 可以按這個順序排查：

檢查 ~/.codex/config.toml。
在 [features] 下加入 goals = true。
重新啟動 Codex 應用程式或 VS Code 擴充套件。
仍失敗時，備份設定後重建 ~/.codex。
Windows 使用者額外檢查 Defender 或安全軟體是否誤攔截設定檔。

這個問題的重點不是「目標怎麼寫」，而是先確認 Goal 功能本身是否在本機設定裡正常啟用。

Codex Goal 深度解析：讓 AI Agent 連續工作數小時的目標驅動工作流

Tue, 26 May 2026 23:44:37 +0800

瀏覽器、終端和 IDE 裡的 AI Agent 已經越來越會寫程式了，但很多人真正遇到的問題不是「它不會做」，而是「它做一半就說完成了」。

簡單 ticket 很適合交給 coding agent：修一個按鈕、補一個介面、改一段文案、加一個測試。目標清楚，邊界很小，驗證方式也直接。但一旦任務變成大型遷移、跨模組重構、測試套件修復、依賴升級、prompt eval 優化，Agent 就很容易出現一種典型問題：

它完成了一個看起來合理的中間狀態，然後過早停下。

Codex Goal / Persistent Goals 這類能力要解決的，正是這個「提前收工」問題。它的重點不是讓 Agent 多跑幾輪，而是讓 Agent 圍繞一個明確目標持續推進，直到滿足可驗證的完成標準。

Codex Goal 解決的不是循環，而是停止條件

很多長任務自動化會從一個粗糙方案開始：

`1`	`繼續檢查程式碼，修復問題，直到沒有錯誤。`

或者更機械一點：

循環 10 次：
1. 執行測試
2. 讓模型修復失敗
3. 再執行測試

這類 rough loop 看起來能讓 Agent 工作更久，但它有兩個硬傷：

它不知道什麼時候真的該停。
它也不知道「沒有繼續報錯」是否等於「任務完成」。

Codex Goal 的關鍵不是循環次數，而是 goal、state、judge stop condition 三件事。也就是說，Agent 需要知道這次工作的目標是什麼，目前已經完成到哪裡，以及什麼證據能證明任務真的結束了。

這也是長任務 Agent 的核心分水嶺：不是「多執行幾步」，而是「能不能判斷自己還差什麼」。

Goal 和普通 prompt 的區別

普通 prompt 更像一次性指令：

`1`	`把這個專案的測試修好。`

Goal prompt 則更像一份小型任務合約：

目標：修復目前倉庫中失敗的測試。
範圍：只修改 src/ 和 tests/，不要改建置腳本。
完成標準：npm test 全部通過，且新增修改不引入 lint 錯誤。
驗證命令：npm test && npm run lint。
失敗處理：如果超過 3 次仍無法修復，輸出剩餘失敗用例、已嘗試方案和阻塞點。
輸出：總結修改檔案、修復原因、驗證結果。

兩者最大的差別在於，Goal prompt 把「完成」定義清楚了。

如果沒有 definition of done，Agent 很容易把「我改了程式碼」誤判成「我完成了任務」。如果有清晰的完成標準，Agent 就必須圍繞測試、日誌、diff、建置結果、eval 分數這些外部證據繼續推進。

為什麼 LLM judge stop condition 很關鍵

長任務裡最難的不是讓 Agent 執行命令，而是讓它判斷：

現在是否真的完成了？
是否只是通過了局部測試？
是否修了一個問題，卻引入了另一個問題？
是否需要繼續搜尋、繼續執行驗證、繼續回滾某個方向？

這就是 LLM judge stop condition 的價值。

理想狀態下，Agent 不應該只看「最後一個命令是否退出碼為 0」。它還應該綜合判斷：

使用者給出的完成標準是否全部滿足；
修改是否限定在允許範圍內；
測試、lint、build、eval 是否都跑過；
失敗日誌是否還有未處理項；
是否存在明顯的副作用和風險；
最終輸出是否能讓人類快速複核。

換句話說，judge 不只是「判定成功」，還要防止 Agent 自我安慰式收尾。

哪些任務適合交給 Goal

Codex Goal / Persistent Goals 更適合那些需要多輪探索和驗證的複雜 coding work，例如：

程式碼遷移：從舊框架遷到新框架，從 CommonJS 遷到 ESM，從舊 API 遷到新 API。
大型重構：拆分模組、整理邊界、替換重複實作、降低複雜度。
測試修復：連續分析失敗用例，定位原因，修復後反覆驗證。
依賴升級：升級框架、SDK、建置工具，同時處理 breaking changes。
Prompt eval 優化：執行評測，分析失敗樣本，調整 prompt 或工具呼叫策略。
技術債清理：圍繞明確規則逐步替換舊寫法，並保持行為不變。

這些任務的共同點是：中間狀態很多，失敗原因不一定一次能看清，完成標準必須依賴驗證結果。

哪些任務不適合只靠 Goal

Goal 並不是萬能的。下面這些任務如果只靠一個長 prompt，風險會很高：

目標非常模糊，例如「把產品增長做好」。
週期很長，例如連續幾週的 SEO、GEO、廣告投放優化。
需要跨系統調度，例如同時處理內容、資料、投放、客服和業務指標。
涉及生產風險，例如資料庫變更、線上配置、財務操作、帳號權限調整。
缺少驗證手段，例如沒有測試、沒有指標、沒有日誌、沒有人工作收標準。

這類任務更像 Mission，而不是 Goal。

Goal 適合小時級到一兩天的深度執行。Mission 則需要狀態、歷史、調度、人類審批、階段性複盤和長期指標。比如 SEO / GEO / Ads 優化，不只是讓 Agent 循環寫內容或調參數，而是要持續記錄策略、實驗、資料變化和下一步計畫。

寫好 Goal Prompt 的模板

一個好用的 Goal prompt，至少應該包含下面幾塊：

目標：
用一句話說明最終要達成什麼結果。

背景：
說明目前問題、相關檔案、業務約束、已有嘗試。

範圍：
允許修改哪些目錄、檔案、模組；哪些地方不要碰。

完成標準：
列出可驗證的 definition of done。

驗證命令：
寫清楚需要執行的測試、lint、build、eval 或腳本。

失敗策略：
如果無法完成，要求 Agent 輸出失敗原因、已嘗試方案、剩餘阻塞點。

風險邊界：
禁止破壞性操作，生產配置、密鑰、資料庫、外部服務需要人工確認。

交付格式：
要求總結修改點、驗證結果、風險和後續建議。

真正決定長任務效果的，往往不是 prompt 寫得多漂亮，而是完成標準夠不夠硬。

Goal Buddy 的價值：先幫你把任務說清楚

很多長任務失敗，不是 Agent 能力不夠，而是人類一開始就沒有把任務拆清楚。

Goal Buddy 這類輔助工具的價值在於：在正式把任務交給 Agent 之前，先幫你準備目標、邊界、完成標準和驗證方式。它像一個任務預檢器，會追問：

這個任務的最終可見結果是什麼？
哪些目錄可以改，哪些不能改？
成功後跑什麼命令證明？
失敗時要不要繼續嘗試，最多嘗試到什麼程度？
是否需要分階段提交？
哪些操作必須讓人類確認？

這一步看似囉嗦，但它能顯著減少 Agent 中途跑偏、過早停止或改出一堆難以複核程式碼的概率。

給 Codex、Claude Code、OpenCode 使用者的實踐建議

如果你正在用 Codex、Claude Code、OpenCode、OpenClaw 或類似 coding agent，可以按下面方式使用長任務：

先提交目前工作區，保證有乾淨回滾點。
把任務寫成 Goal，而不是一句泛泛的需求。
明確允許修改的範圍和禁止修改的範圍。
給出驗證命令，最好讓 Agent 每輪都能自己執行。
要求 Agent 在無法完成時報告阻塞點，而不是硬編一個「完成」。
對高風險操作設定人工確認，例如刪除檔案、改資料庫、改部署配置。
最後只接受帶有測試結果和修改總結的交付。

長任務 Agent 的正確使用方式，不是「讓它自己隨便幹一晚上」，而是給它一個清楚的目標、堅實的護欄和可驗證的出口。

小結

Codex Goal / Persistent Goals 的意義在於，把 coding agent 從「執行一句指令」推進到「圍繞一個目標持續工作」。

它最適合複雜但邊界明確的工程任務：遷移、重構、測試修復、依賴升級、eval 優化。它不適合完全模糊、週期很長、缺少驗證標準的業務任務；那些更應該設計成 Mission 系統。

未來 AI Agent 的競爭點，很可能不只是模型會不會寫程式，而是能不能圍繞目標持續推進、正確判斷停止時機，並把過程留給人類複核。

參考：

Ollama 接入 Codex App：本地大模型如何變成 AI 編程 Agent

Tue, 26 May 2026 23:35:01 +0800

Ollama 最近把本地大模型和 AI 編程工具之間的距離又拉近了一步：透過 ollama launch codex-app，使用者可以把 Codex App 接到 Ollama 管理的本地或雲端模型上。

這件事的意義不只是「換一個模型後端」。它更像是把本地大模型從聊天視窗推到開發工作流裡：模型不再只是回答問題，而是可以進入程式碼專案、理解檔案結構、輔助修改程式碼、執行任務，成為 AI 編程 Agent 的一部分。

先釐清：這不是 OpenAI 全功能永久免費

網上很多說法會把這件事概括成「Codex 免費了」。這個說法容易誤解。

更準確的理解是：

Codex App 是 OpenAI 的 AI 編程工具；
Ollama Launch 可以幫助 Codex App 使用 Ollama 模型；
模型可以是本地模型，也可以是 Ollama 的雲端模型；
如果使用本地模型，推理成本主要變成自己的硬體、電費和時間，而不是按 API token 計費；
Codex App、OpenAI 帳號權益、不同模型可用性和官方限制，仍然要以 OpenAI 與 Ollama 的當前規則為準。

所以它不是「所有 Codex 能力都永久免費」，而是多了一條本地化路線：讓 AI 編程 Agent 可以不完全依賴 OpenAI API、Claude API 或 Gemini API。

`ollama launch codex-app` 做了什麼？

Ollama 官方文件裡，Codex App 的接入命令很簡單：

`1`	`ollama launch codex-app`

如果想指定模型，可以寫成：

`1`	`ollama launch codex-app --model gpt-oss:120b`

也可以只生成配置，不馬上啟動：

`1`	`ollama launch codex-app --config`

如果想恢復原本的 Codex 配置：

`1`	`ollama launch codex-app --restore`

它的價值在於減少手動配置成本。過去要讓一個 AI 編程工具接入本地模型，經常要自己改環境變數、OpenAI-compatible endpoint、config.toml、模型名和 profile。現在 Ollama Launch 把這些步驟包裝成一個更直接的流程。

為什麼本地模型接入 Agent 很重要？

以前本地大模型最常見的用法是聊天：

寫一段文案；
回答一個問題；
解釋一段程式碼；
做簡單補全；
總結文件。

這些都很有用，但還停留在「問答工具」的層面。

AI 編程 Agent 的區別在於，它面對的是一個真實專案。它需要讀目錄、看檔案、理解報錯、修改程式碼、執行命令、檢查結果，再繼續迭代。也就是說，它不是只輸出答案，而是參與執行任務。

當本地模型接入 Codex App、Claude Code、OpenCode、Aider、OpenHands 這類工具時，本地 AI 的角色就變了：

可以掃描專案結構；
可以定位 Bug；
可以改檔案；
可以生成新頁面或小遊戲；
可以解釋和重構程式碼；
可以在開發循環裡反覆執行、驗證、修正。

這也是本地大模型從「能聊」走向「能幹活」的關鍵一步。

本地 Agent 的優勢

1. 成本更可控

大型專案很容易消耗大量 token。一次專案掃描、長上下文分析、多輪修復，放在雲端模型上可能很快累積費用。

本地模型雖然也有成本，比如顯卡、記憶體、電費和時間，但它不會按 token 直接收費。對於大量試錯、個人專案、離線實驗，本地路線更適合慢慢折騰。

2. 可以離線工作

如果模型、工具和依賴都已經在本機準備好，本地 Agent 在很多場景下可以斷網繼續工作。它可以讀本地程式碼、分析專案、修改檔案、生成頁面或腳本。

當然，涉及聯網搜尋、下載依賴、存取線上 API 的任務仍然需要網路。但基礎程式碼分析和本地專案修改，不一定非要依賴雲端模型。

3. 隱私邊界更清楚

很多程式碼庫、內部文件、實驗專案並不適合直接發給雲端模型。把模型放在本地，可以減少程式碼內容離開機器的機會。

這不代表本地路線天然安全。Agent 仍然可能執行命令、改檔案、存取敏感路徑，所以權限、沙箱、Git diff review 仍然很重要。但至少在模型推理層面，本地化給了使用者更多控制權。

模型怎麼選？

Ollama 的官方 ollama launch 文件建議，程式碼類工具最好使用較大的上下文視窗，推薦至少 64K tokens。原因很簡單：AI 編程任務經常需要同時讀專案結構、多個檔案、報錯日誌、需求說明和歷史修改。

本地模型可以從這些方向嘗試：

qwen3-coder：偏程式碼任務；
gpt-oss:20b：適合本地嘗試；
glm-4.7-flash：Ollama 官方推薦的 coding 模型之一；
更大的雲端模型：如果本地硬體不夠，可以用 Ollama cloud 模型換取更完整上下文。

中文場景下，Qwen 系列仍然值得優先嘗試。它在中文理解、程式碼生成、推理和本地生態適配上都比較成熟。

硬體門檻沒有想像中那麼高

很多人一提到 AI Agent，就預設需要 RTX 4090、24GB 顯存、甚至企業級 GPU。

實際情況更靈活。小模型、量化模型、MoE 模型、KV cache 量化和 CPU/GPU 混合 offload 讓 6GB、8GB、12GB 顯存機器也能做不少事情。

當然，低顯存機器不適合追求極致體驗：

速度會慢；
上下文不能太大；
大專案掃描會吃力；
多併發基本不現實；
模型品質和 100B+ 雲端模型仍有差距。

但如果目標是個人專案、腳本修復、簡單前端頁面、小遊戲、程式碼解釋、離線實驗，本地模型已經足夠進入「可用」階段。

也可以用 llama.cpp 接 OpenAI-compatible 介面

除了 Ollama，另一條常見路線是用 llama.cpp 的 llama-server 提供本地 OpenAI-compatible API，再讓 AI 編程工具連接到本地連接埠。

一個典型的 llama.cpp 啟動命令類似這樣：

llama-server.exe ^
 -m "models\Qwen3.6-27B-UD-Q5_K_XL.gguf" ^
 -ngl 999 ^
 -c 16384 ^
 -n 2048 ^
 -fa on ^
 --jinja ^
 --host 127.0.0.1 ^
 --port 8080

然後在工具配置裡把模型 provider 指向：

[model_providers.llamacpp]
name = "llama.cpp"
base_url = "http://127.0.0.1:8080/v1/"
wire_api = "responses"

這條路線更靈活，但也更折騰。Ollama Launch 的優勢是簡單；llama.cpp 的優勢是可控參數更多，適合想細調顯存、上下文、量化和推理後端的使用者。

使用本地 AI Agent 時要注意什麼？

本地不等於無風險。Agent 能改檔案、跑命令、建立專案，就意味著它也可能誤刪檔案、改錯程式碼、執行不該執行的操作。

建議：

在 Git 倉庫裡操作，確保隨時能看 diff 和回滾。
不要給 Agent 過大的系統權限。
先在測試專案裡試，不要直接丟生產程式碼庫。
重要檔案修改前後都要人工 review。
不要把密鑰、帳號、生產環境配置暴露給 Agent。
本地模型能力有限，複雜架構決策不要完全交給它。

把本地 Agent 當成「會執行任務的助手」，而不是「完全可靠的工程師」，體驗會更健康。

我的理解

Ollama 接入 Codex App 的意義在於，它把本地模型真正接進了 AI 編程工作流。

過去，本地模型更多是一個聊天框；現在，它開始能進入專案、讀程式碼、改檔案、跑任務。這個變化會讓很多普通開發者重新評估手裡的電腦：也許不需要最貴的顯卡，也能先搭起一個低成本、可離線、可控的 AI 編程環境。

雲端模型仍然強，特別是在複雜推理、大上下文、多模態和長任務穩定性上。但本地模型正在補上「執行工具」這一塊。

未來的 AI 編程，很可能不是純雲端或純本地，而是混合形態：

小任務、本地程式碼、隱私專案交給本地模型；
高難推理、大上下文、跨系統任務交給雲端模型；
Ollama、Codex App、Claude Code、OpenCode 這類工具負責把兩邊接到同一個工作流裡。

這才是本地 AI Agent 真正值得關注的地方。

參考連結

oh-my-codex：給 Codex CLI 加上工作流、技能和執行時護欄

Mon, 25 May 2026 07:41:45 +0800

Yeachan-Heo/oh-my-codex，簡稱 OMX，是一個圍繞 OpenAI Codex CLI 的工作流層。

專案地址：https://github.com/Yeachan-Heo/oh-my-codex

它想解決的不是「再做一個新的 coding agent」，而是讓已經在使用 Codex CLI 的人，有一套更穩定的日常工作方式：啟動時帶上專案指令，任務變複雜時先釐清再規劃，執行時有 durable goal 和狀態記錄，收尾時用 review 和 QA 把結果壓住。

截至寫作時，GitHub 頁面顯示倉庫約有 29.4k star，最新 release 是 v0.18.1，發布時間為 2026 年 5 月 21 日。README 也明確說，官方專案是 Yeachan-Heo/oh-my-codex，官方 npm 套件是 oh-my-codex，不要把第三方 “OMX v2” 專案誤認為這個倉庫的官方延續。

它到底是什麼

OMX 不替代 Codex。

它保留 Codex CLI 作為實際執行引擎，自己主要補三類東西：

更固定的任務流程。
可複用的 prompts、skills 和 specialist agents。
.omx/ 目錄下的計劃、日誌、狀態和執行時記錄。

換句話說，Codex 負責「動手幹活」，OMX 負責「讓幹活過程更像工程流程」。這也是它和普通 prompt 包最大的差別：它不是只往系統提示詞裡塞規則，而是把釐清、規劃、執行、檢查、團隊協作和執行時診斷拆成一組可呼叫的工作面。

預設工作流

OMX 的主線工作流大致是：

$deep-interview "clarify the authentication change"
$ralplan "approve the auth plan and review tradeoffs"
$prometheus-strict "stress-test the plan before durable execution"
$ultragoal "turn the approved plan into durable Codex goals"

其中最常用的是三步：

$deep-interview：在需求還不清楚時追問邊界、目標和非目標。
$ralplan：把需求整理成計劃，並經過架構與批判視角確認。
$ultragoal：把批准後的計劃轉成更耐跑的目標和檢查點。

如果任務需要並行協作，可以在 Ultragoal story 裡用 $team；如果只需要一個持續推進的單人循環，可以用 $ralph。這套命名看起來有點重，但背後的想法很清楚：不要讓 agent 一聽到需求就急著改文件，而是先把「要做什麼、怎麼做、怎麼驗收、什麼時候停」寫清楚。

skills 和 agents 提供了什麼

OMX 文件把技能分成幾類。

Canonical Workflow 裡有 $deep-interview、$ralplan、$prometheus-strict、$ultragoal、$code-review 和 $ultraqa。這些面向的是完整工程任務：先釐清，再規劃，再執行，再審查，再 QA。

Execution Modes 裡有 $team、$ralph、$autopilot、$ultrawork 等。它們決定任務是單線推進、團隊並行，還是更強的自動循環。

Agent Catalog 則更像角色庫，包括 analyst、planner、architect、debugger、executor、verifier、security-reviewer、performance-reviewer、code-reviewer、test-engineer、designer、researcher 等。你不一定每天都要手動點名這些角色，但它們說明 OMX 的定位不是「萬能大 prompt」，而是把工程過程拆成可複用的角色和階段。

這對長期專案有意義。AI 編程裡很多失敗不是模型完全不會寫程式碼，而是它太快進入執行，跳過需求確認、架構邊界、測試基線和收尾審查。OMX 試圖用技能和角色把這些步驟固化下來。

插件形態和執行時狀態

README 提到，倉庫裡也包含官方 Codex plugin layout，路徑是 plugins/oh-my-codex，並帶有 marketplace metadata。

但文件也強調：這個插件形態不是 npm install -g oh-my-codex 加 omx setup 的替代品。插件作用更像是把 hooks、skill surface 和 Codex 生命週期整合包裝起來，真正執行時仍然依賴已安裝的 omx CLI。

最新 v0.18.1 release 的重點也集中在這條線上：插件安裝會使用 pinned OMX launcher，hook 失敗時更保守，Ultragoal 狀態變更會序列化，release packaging 會排除 crate-local .omx runtime cache，並同步 npm、Cargo workspace、lockfile 和插件 manifest 的版本號。

這些變化說明 OMX 已經不只是 prompt 倉庫，它開始認真處理安裝形態、hook 安全、狀態寫入、release 包內容和跨執行時一致性。對工具鏈來說，這些都屬於「不炫但很要命」的工程細節。

適合誰

OMX 比較適合已經在認真使用 Codex CLI 的開發者，尤其是這些場景：

經常讓 Codex 處理多文件、多步驟任務。
希望 agent 先釐清需求，而不是直接改程式碼。
想把計劃、執行、檢查、review 和 QA 分開管理。
需要在專案裡保留 .omx/ 狀態、計劃和日誌。
想嘗試 tmux/team runtime 或更強的長任務推進方式。
團隊願意把自己的工程習慣沉澱成 skills 和 prompts。

如果你只是偶爾讓 Codex 改一行設定、生成一個腳本、解釋一段程式碼，OMX 可能會顯得偏重。它更像是給高頻 AI 編程使用者準備的工具腰帶，而不是新手必須安裝的第一層入口。

使用時要注意什麼

第一，不要把 OMX 當成「無人值守自動完成一切」的保證。它能強化流程，但不能替你判斷需求是否合理、架構是否該改、風險是否可接受。

第二，平台邊界要看清楚。README 現在明確推薦 macOS/Linux + Codex CLI。Windows 原生路徑存在，但不是預設最佳體驗。如果你在 Windows 上使用，WSL2 通常比原生終端更穩。

第三，omx doctor 不是最終驗收。真正能證明環境可用的是 codex login status 加 omx exec 這種實際模型呼叫測試。

第四，流程越強，越需要你寫清楚任務邊界。$ultragoal、$team、$autopilot 這類能力適合有驗收標準的任務。如果需求本身還很含糊，應該先用 $deep-interview 或普通對話把邊界拉清楚。

小結

oh-my-codex 的價值不在於讓 Codex「變成另一個工具」，而在於給 Codex CLI 加了一層更工程化的工作方式。

它把 AI 編程從「我說一句，你改一輪」往「釐清、規劃、執行、檢查、記錄狀態」推進了一步。對輕量任務來說，這可能有點重；但對經常用 Codex 做真實專案的人來說，穩定流程、可複用技能、執行時診斷和 durable goal 反而是省心的關鍵。

如果你已經把 Codex CLI 當成日常開發工具，OMX 值得試一下。即使不直接安裝，它對 skills、agents、計劃和驗收流程的拆法，也很適合拿來改造自己的 AI 編程工作流。

參考資料

Yeachan-Heo/oh-my-codex：https://github.com/Yeachan-Heo/oh-my-codex
Getting Started：https://github.com/Yeachan-Heo/oh-my-codex/blob/main/docs/getting-started.html
Agent Catalog：https://github.com/Yeachan-Heo/oh-my-codex/blob/main/docs/agents.html
Skills Reference：https://github.com/Yeachan-Heo/oh-my-codex/blob/main/docs/skills.html
v0.18.1 release：https://github.com/Yeachan-Heo/oh-my-codex/releases/tag/v0.18.1

OpenAI Symphony 是什麼？Codex 編排、Issue 驅動與 AI Agent 開發工作流

Mon, 25 May 2026 00:17:32 +0800

OpenAI 最近開源了一個很有意思的 Codex 編排規範：Symphony。

它不是另一個聊天式編程助手，也不是一個完整的新 IDE。更準確地說，Symphony 是一套面向 Codex 的「工作編排方式」：把類似 Linear 的 issue tracker 變成編程智能體的控制平面，讓每一個未關閉的任務都能對應一個持續運行的 Agent。

官方文章裡有一句話很能概括它的方向：過去工程師要同時盯著多個 Codex 會話，不斷分配任務、審查輸出、糾偏和重啟；Symphony 想解決的，正是這個上下文切換瓶頸。

Symphony 解決的不是寫代碼，而是管理 Agent

單個 Codex 會話適合互動式開發：你給它一個任務，它修改代碼，你 review，再繼續追問。但當團隊開始同時使用多個 Agent 時，問題會從「代碼能不能寫出來」變成「誰在做哪件事、做到哪一步、失敗後誰來接手」。

OpenAI 的做法是把工作重心從「會話」切到「任務」：

issue 是真正的工作單元；
每個未關閉 issue 都可以映射到一個獨立 Agent 工作空間；
Symphony 負責持續輪詢任務看板，決定哪些任務需要啟動、重試、停止或回收；
Codex 在工作空間裡執行實作、測試、提交、建立 PR、更新狀態等動作；
人類不再微操每個會話，而是審查結果、調整目標和維護邊界。

這背後的變化很關鍵：Agent 不再只是一個被人類臨時喚起的工具，而是開發流程裡持續運行的一類執行者。

為什麼是 issue tracker？

因為團隊已經用 issue tracker 管理真實工作。

需求、bug、重構、遷移、調研、優先級、阻塞關係、負責人、里程碑，這些資訊本來就沉澱在 Linear、GitHub Issues 或類似系統裡。Symphony 沒有重新發明一個龐大的控制台，而是把這些現有系統當作 Agent 的任務入口。

這樣做有幾個好處：

工作不必從 issue 複製到聊天視窗裡。
人類可以繼續按熟悉的方式建立、拆分、排期和關閉任務。
Agent 的狀態變化能回寫到同一個工作系統裡，方便團隊非同步協作。
任務依賴可以自然形成 DAG，讓未阻塞的任務並行推進。

如果把傳統 CI 看成「代碼提交後的自動化」，Symphony 更像是「issue 建立後的自動化」。

它的核心工作流

一個典型的 Symphony 流程可以理解為：

创建 issue
  -> Symphony 轮询到可执行任务
  -> 为该 issue 创建独立 workspace
  -> 启动 Codex agent session
  -> Agent 阅读任务、修改代码、运行测试
  -> 创建或更新 PR
  -> 写回任务状态、评论、证据和交付物
  -> 人类 review、合并或要求修改

官方規範裡還強調了幾個工程化點：

每個 issue 使用獨立工作空間，降低相互污染；
編排器維護重試、並發和恢復狀態；
工作流策略放在倉庫內的 WORKFLOW.md，讓團隊把 Agent 應該如何處理任務寫成可版本化的規則；
實作需要保留可觀測性，至少要有結構化日誌；
成功狀態不一定是 Done，也可以是交給人類 review 的中間狀態。

這說明 Symphony 不是簡單地「讓 AI 自動寫代碼」，而是在定義一套可運行、可恢復、可審計的 Agent 工作系統。

目標驅動，而不是死板狀態機

OpenAI 在文章裡提到一個重要轉變：早期他們嘗試把很多動作寫死在外層 harness 裡，例如提交代碼、跑測試、處理 GitHub 流程。但隨著 Codex 能力增強，這種方式反而限制了 Agent。

後來的方向是給 Agent 設定目標，而不是把每一步都寫成固定狀態轉換。

比如，一個任務的目標可以是「完成 Vite 遷移並確保 CI 通過」。Agent 可以自己判斷是否需要改配置、修測試、讀 CI 日誌、處理 review feedback，甚至拆出新的後續 issue。Symphony 負責提供邊界、上下文和運行框架，而不是替 Agent 規定每一個動作。

這也是它和傳統自動化腳本的區別：腳本擅長重複確定流程；Symphony 面向的是帶有不確定性的工程任務。

和普通 Codex 使用方式有什麼不同？

普通 Codex 會話更像「人帶著 AI 寫代碼」：

人類打開會話；
人類描述任務；
人類觀察輸出；
人類隨時糾偏；
任務結束後再開下一個會話。

Symphony 更像「團隊把任務池交給一組 Agent 執行」：

人類寫清楚 issue；
系統持續發現可執行任務；
Agent 在獨立環境裡推進；
結果以 PR、評論、測試狀態、影片或分析報告的形式返回；
人類在關鍵節點做 review。

這不是替代工程師，而是把工程師從「同時照看多個會話」的負擔裡解放出來。OpenAI 在官方文章中提到，在部分團隊中，合併到主分支的 PR 數量有明顯提升；但更值得注意的是工作方式的變化：試驗一個想法、發起一次重構、驗證一個假設的啟動成本變低了。

適合哪些場景？

Symphony 更適合這些任務：

常規功能實作；
已有代碼庫裡的小型重構；
基礎設施遷移；
依賴升級；
測試補齊；
CI 修復；
調研後生成實作計劃；
根據 review feedback 繼續修改 PR。

它不一定適合高度模糊、需要強業務判斷或架構拍板的任務。對這類問題，互動式 Codex 會話仍然更自然，因為人類需要在過程中持續參與。

風險和邊界

Symphony 的吸引力很強，但真正落地時不能只看「自動化」這一面。

幾個邊界要提前想清楚：

issue 必須寫清楚，否則 Agent 會把模糊需求放大成錯誤實作；
Agent 的權限要收斂，尤其是倉庫、密鑰、生產環境和第三方服務訪問；
每個工作空間要隔離，避免多個任務相互污染；
CI、測試、lint 和 review 仍然是必須的質量門；
任務狀態、PR 連結、日誌和失敗原因要可追蹤；
人類 review 不能省，尤其是涉及安全、計費、資料遷移和權限邏輯的改動。

官方倉庫也把 Symphony 定位為 trusted environment 裡的工程預覽和參考實作，而不是一個拿來就能無腦替代研發流程的成品平台。

我對 Symphony 的理解

Symphony 最有價值的地方，不在於它用了 Linear，也不在於參考實作選擇了 Elixir，而在於它重新定義了編程 Agent 的入口。

過去我們習慣從聊天視窗啟動 AI 編程：這很靈活，但規模一大，人類注意力就成了瓶頸。Symphony 把入口放回 issue tracker，讓 Agent 圍繞真實任務持續工作。這樣一來，AI 編程從「個人效率工具」開始向「團隊工作流基礎設施」靠近。

如果你已經在使用 Codex、Claude Code、Cursor Agent 或類似工具，Symphony 值得關注的不是某個具體實作，而是它背後的模式：

不要只管理 Agent 會話，要管理需要完成的工作。

這可能會成為下一階段 AI 編程工具的關鍵分水嶺。

參考連結

CLIProxyAPI Management Center：給 CLIProxyAPI 配一個視覺化管理後台

Sun, 24 May 2026 10:05:15 +0800

Cli-Proxy-API-Management-Center 可以理解成 CLIProxyAPI 的「駕駛艙」。

前一篇提到的 CLIProxyAPI 負責把 Gemini CLI、Codex、Claude Code、OpenRouter 等能力代理成統一 API；而這個 Management Center 解決的是另一個問題：

代理服務跑起來之後，設定、帳號、OAuth、日誌、配額和憑證，總不能全靠手改檔案和翻終端機吧？

所以它提供了一個 Web 管理介面，讓你可以用瀏覽器管理 CLIProxyAPI 的設定與執行狀態。

它是什麼

從專案說明看，Cli-Proxy-API-Management-Center 是 CLIProxyAPI 的獨立管理前端，核心功能包括：

視覺化編輯 CLIProxyAPI 設定。
上傳和管理 auth.json 一類認證檔案。
查看請求日誌和模型回應日誌。
管理 OAuth 認證流程。
檢查 Gemini CLI 帳號配額。
提供帳號、設定、日誌等日常維護入口。

另外，官方倉庫也提示：新版 CLIProxyAPI 已經內建了這個管理介面，可以直接透過 /management.html 存取；獨立倉庫仍然保留給需要單獨部署或二次開發的人使用。

這點很重要。也就是說，大多數普通使用者未必需要額外部署這個倉庫；先確認你的 CLIProxyAPI 版本是否已經自帶管理頁。

它解決的不是「呼叫模型」，而是「管理模型入口」

CLIProxyAPI 的難點不只是能不能把請求轉到模型。

真正麻煩的是這些東西：

多個 Gemini、OpenAI、Claude、Codex 帳號如何放進池子裡。
哪個帳號已經失效，哪個帳號配額快用完。
OAuth 登入狀態怎麼匯入、刷新和排查。
設定檔怎麼改才不會漏逗號、漏欄位。
請求到底打到了哪個 provider、哪個模型、哪個帳號。
失敗請求是上游問題、協議問題，還是本機設定問題。

Management Center 的價值就在這裡：它把「代理基礎設施」的日常維護變成視覺化操作。

如果你只是本機跑一個帳號、偶爾調幾次 API，它不一定是剛需；但只要你開始做多帳號、多模型、多客戶端接入，一個後台介面就會明顯省事。

典型使用場景

第一，管理帳號池。

CLIProxyAPI 支援多帳號輪詢和負載均衡，但帳號越多，越不適合靠手工翻設定檔維護。管理中心可以幫助你查看帳號狀態、匯入憑證、排查異常帳號。

第二，排查請求失敗。

當客戶端報錯時，你需要知道請求有沒有進代理、走了哪個 provider、返回了什麼錯誤。日誌介面比在終端機裡滾屏找錯誤舒服很多。

第三，處理 OAuth。

Codex、Claude Code、Gemini CLI 這類工具經常涉及 OAuth 登入狀態。管理中心提供 OAuth 相關操作入口，能減少重複命令列操作。

第四，給團隊內部使用。

如果 CLIProxyAPI 變成團隊共享閘道，那管理者需要一個能快速查看設定和狀態的介面。否則每次變更都要登入伺服器改檔案，效率很低，也容易誤操作。

和 CLIProxyAPI 的關係

可以把兩者分成前後兩層：

客戶端 / IDE / 腳本
        |
        v
CLIProxyAPI：負責協議代理、帳號池、模型路由
        |
        v
Gemini CLI / Codex / Claude Code / OpenRouter / 上游模型

Management Center 不在這條推理請求鏈路的核心位置。它更像維運面板：

瀏覽器
  |
  v
Management Center：編輯設定、看日誌、管帳號、查配額
  |
  v
CLIProxyAPI 管理介面 / 設定 / 日誌 / 憑證

所以不要把它理解成另一個模型代理。它是管理 CLIProxyAPI 的工具，不是替代 CLIProxyAPI 的工具。

為什麼新版內建後仍然值得單獨看

既然 CLIProxyAPI 已經內建了 /management.html，為什麼還要關注這個獨立倉庫？

主要有三個原因。

第一，獨立倉庫能讓你看清管理中心本身的功能邊界。哪些是前端負責的，哪些必須由 CLIProxyAPI 後端提供介面，一眼更清楚。

第二，如果你要二次開發，比如改 UI、加鑑權、接自己的監控系統，獨立倉庫更適合作為入口。

第三，如果你的部署環境比較特殊，比如前後端分開部署、管理頁走單獨網域、靜態資源由內網閘道託管，獨立版本更靈活。

對普通個人使用者來說，優先用 CLIProxyAPI 內建版就夠了；對團隊或深度定制使用者，獨立倉庫更有意義。

部署時最該注意什麼

管理後台接觸的是敏感東西：帳號、OAuth、API Key、日誌、請求內容、上游配額。

所以第一條原則是：不要把管理頁面裸露到公網。

比較穩的做法是：

只允許本機存取，比如綁定 127.0.0.1。
如果必須遠端存取，放到 VPN、Tailscale、內網跳板機或反向代理鑑權後面。
給管理介面加認證，不要只靠「地址沒人知道」。
日誌裡盡量避免暴露完整 Key、Cookie、OAuth token 和使用者原始請求。
團隊環境裡要分清「呼叫 API 的人」和「能改設定的人」。

很多代理工具真正出問題，不是模型呼叫失敗，而是管理口、日誌和憑證檔案沒保護好。

它適合和哪些東西一起用

如果你只部署 CLIProxyAPI，一個管理中心已經能解決基礎維護問題。

如果你進一步關心統計和可觀測性，還可以搭配 CLIProxyAPI 生態裡的其他工具：

CPA Usage Keeper：偏用量同步和 SQLite 儲存。
CLIProxyAPI Usage Dashboard：偏本機優先的用量、配額和圖表展示。
CPA-Manager：偏完整管理中心，關注請求監控、費用估算、帳號池巡檢和異常帳號清理建議。

可以簡單理解：

Management Center 管「設定和日常維護」。
Usage Dashboard 管「看用量和配額」。
CPA-Manager 管「更重的營運和巡檢」。

實際用哪個，要看你的部署規模。個人本機用不需要把全家桶都裝上。

使用建議

如果你剛開始折騰 CLIProxyAPI，可以按這個順序來：

先讓 CLIProxyAPI 本體跑通，確認 API 能正常回應。
打開內建的 /management.html，看看設定和日誌是否能正常讀取。
再匯入一個帳號或一個 provider，確認管理介面能反映狀態變化。
有公網存取需求時，先做認證和網路隔離，再考慮開放入口。
等帳號和請求量變多，再補用量統計和更完整的管理工具。

不要一開始就把所有帳號、所有 provider、所有管理元件一次性接上。越是代理和帳號池類專案，越適合小步驗證。

總結

Cli-Proxy-API-Management-Center 的定位很清楚：它不是模型、不是聊天客戶端，也不是新的 API 閘道；它是 CLIProxyAPI 的視覺化管理層。

當 CLIProxyAPI 只是一個本機小工具時，你可以不用它；當 CLIProxyAPI 開始承載多帳號、多模型、多客戶端呼叫時，它就會變成很實用的「控制台」。

真正要注意的是安全邊界。管理後台能改設定、看日誌、碰憑證，一旦暴露不當，風險比普通 API 呼叫口還高。把它放在可信網路裡，用認證保護好，再去享受視覺化管理帶來的省心。

參考資料：

讓 Codex 使用 DeepSeek 模型的兩種方法：本機閘道和 OpenRouter BYOK

Sun, 24 May 2026 09:52:55 +0800

想讓 Codex 使用 DeepSeek，第一反應通常是改 ~/.codex/config.toml：

1
2

model = "deepseek-chat"
base_url = "https://api.deepseek.com"

這個思路在一些舊版本或普通 OpenAI SDK 場景裡確實成立，但放到目前的 Codex CLI 上，很容易撞到一個底層問題：Codex 的自訂模型供應商走的是 OpenAI Responses 協議，而 DeepSeek 官方介面主要提供 OpenAI 相容的 Chat Completions 呼叫方式。

我本機目前是 codex-cli 0.111.0。codex --help 裡可以看到它支援 --config、--model、--profile 這些設定入口；OpenAI 官方 Codex 設定參考也寫得很明確：model_providers.<id>.wire_api 目前只支援 responses，省略時也預設是 responses。

DeepSeek 官方文件則給出的呼叫路徑是 https://api.deepseek.com/chat/completions，範例也是 client.chat.completions.create(...)。所以問題不在於 DeepSeek 不能被 OpenAI SDK 呼叫，而在於 Codex 發出的請求語義，和 DeepSeek 原生介面能理解的語義不完全是同一套東西。

這就是為什麼直接把 base_url 改成 https://api.deepseek.com 後，可能出現下面這些現象：

請求路徑不匹配，直接 404 或回傳格式不對。
多輪對話、工具呼叫、補丁產生時解析失敗。
tool_calls 順序、訊息結構、串流事件格式對不上。
看起來模型能回一句話，但一到 Codex 真正幹活就開始報錯。

更穩的辦法，是在 Codex 和 DeepSeek 之間放一個「翻譯層」。常見有兩種路線。

方法一：用本機閘道橋接 DeepSeek

本機閘道的作用不是簡單轉發，而是把 Codex 側的 Responses 風格請求，轉換成 DeepSeek 能處理的 Chat Completions 風格請求，再把 DeepSeek 的結果轉換回 Codex 能吃的格式。

如果你用的是 ccx 這類本機閘道，設定思路大致是這樣：

[profiles.deepseek-ccx]
model = "deepseek-v4-flash"
model_provider = "ccx-bridge"

[model_providers.ccx-bridge]
name = "Local CCX Gateway"
base_url = "http://localhost:3000/v1"
env_key = "DEEPSEEK_API_KEY"

然後在終端機裡設定 DeepSeek Key，再用這個 profile 啟動：

1
2

export DEEPSEEK_API_KEY="your-deepseek-key"
codex --profile deepseek-ccx

PowerShell 裡是：

1
2

$env:DEEPSEEK_API_KEY="your-deepseek-key"
codex --profile deepseek-ccx

這裡有兩個細節要注意。

第一，base_url 要指向閘道暴露給 Codex 的位址，不是 DeepSeek 官方位址。閘道背後再去呼叫 DeepSeek。

第二，env_key 寫什麼取決於閘道怎麼鑑權。有的閘道直接讀取 DeepSeek 官方 Key，有的閘道會要求你給它一個本機代理 Key，再由閘道自己的後台保存 DeepSeek Key。遇到這種情況，env_key 就應該改成閘道要求的環境變數名。

這條路的優點是本機可控，延遲和成本也更容易算清楚。缺點是你必須確認閘道真的支援 Codex 目前使用的 Responses 語義，而不是只做了普通 Chat Completions 代理。

方法二：用 OpenRouter BYOK 做線上橋接

如果不想在本機部署閘道，可以考慮 OpenRouter 的 BYOK。BYOK 的意思是把你自己的上游供應商 Key 綁定到 OpenRouter，由 OpenRouter 負責路由和轉發。

這裡最容易寫錯的是環境變數。Codex 存取的是 OpenRouter，所以 env_key 通常應該是 OPENROUTER_API_KEY，不是 DEEPSEEK_API_KEY。DeepSeek Key 要在 OpenRouter 的 BYOK 或 provider key 設定裡新增。

設定範例：

[profiles.deepseek-openrouter]
model = "deepseek/deepseek-chat"
model_provider = "openrouter"

[model_providers.openrouter]
name = "OpenRouter"
base_url = "https://openrouter.ai/api/v1"
env_key = "OPENROUTER_API_KEY"

啟動方式：

1
2

export OPENROUTER_API_KEY="your-openrouter-key"
codex --profile deepseek-openrouter

PowerShell：

1
2

$env:OPENROUTER_API_KEY="your-openrouter-key"
codex --profile deepseek-openrouter

然後在 OpenRouter 後台把 DeepSeek 的 provider key 加進去。OpenRouter 的 BYOK 文件說明，綁定的 provider key 會被加密保存，並用於路由到對應供應商。

這條路的優點是省掉本機閘道維護成本，設定起來更像普通第三方 API 代理。缺點是中間多了一層線上服務，排障時要同時看 Codex、OpenRouter、DeepSeek 三邊的錯誤訊息。

要不要繼續用 deepseek-chat 這個模型名？

DeepSeek 官方文件在 2026 年 5 月的說明裡，推薦模型名已經出現 deepseek-v4-flash 和 deepseek-v4-pro，並提示 deepseek-chat、deepseek-reasoner 相容別名會在 2026-07-24 之後廢棄。

所以新設定裡更建議優先測試：

`1`	`model = "deepseek-v4-flash"`

如果走 OpenRouter，則要按 OpenRouter 的模型命名來寫，例如：

`1`	`model = "deepseek/deepseek-chat"`

實際可用名稱以你所用閘道或 OpenRouter 模型頁為準。模型名不對時，錯誤通常會表現為 model not found、404，或者 provider 找不到對應 endpoint。

直接改 DeepSeek 官方 base_url 為什麼不推薦

你當然可以試著寫：

[profiles.deepseek-direct]
model = "deepseek-v4-flash"
model_provider = "deepseek"

[model_providers.deepseek]
name = "DeepSeek"
base_url = "https://api.deepseek.com"
env_key = "DEEPSEEK_API_KEY"

但這更像排錯實驗，不適合作為穩定方案。因為 Codex 會按 Responses 協議去和自訂 provider 說話，而 DeepSeek 官方範例走的是 /chat/completions。如果 DeepSeek 或 Codex 未來補齊了相容層，這種直連才可能變得簡單；在此之前，橋接層更可靠。

改完設定後還是走 OpenAI 怎麼辦

先確認設定檔位置。全域設定應該在：

`1`	`~/.codex/config.toml`

專案裡的 .codex/config.toml 不適合放 model_provider、model_providers 這類機器級 provider 設定。OpenAI 官方文件也提醒，專案級設定不會覆蓋這些本機 provider 和認證相關欄位。

如果 Codex 仍然要求網頁登入，或者看起來還在走預設 OpenAI 模型，可以先退出目前登入狀態：

`1`	`codex logout`

有些舊教學會寫成交互介面裡的 /logout。在目前 CLI 裡，更穩的是直接在終端機執行 codex logout。

還可以用臨時參數做一次快速驗證：

`1`	`codex --profile deepseek-ccx`

或者：

`1`	`codex -c model_provider=ccx-bridge -c model=deepseek-v4-flash`

如果這樣能生效，說明設定本身可讀；如果不生效，優先檢查 profile 名稱、TOML 語法、環境變數是否只在目前 shell 裡有效。

排障清單

401：Key 不對，或者 env_key 指向了錯誤的環境變數。
404：base_url 或模型名不對，也可能是把 Responses 請求打到了只支援 Chat Completions 的位址。
tool_calls、patch、串流解析報錯：大機率是協議橋接不完整。
仍然提示登入 OpenAI：執行 codex logout，再確認是否用了正確 profile。
PowerShell 設定環境變數後新開視窗失效：$env:... 只對目前會話生效，需要長期保存就改使用者環境變數。
OpenRouter BYOK 沒走自己的 DeepSeek Key：檢查 OpenRouter 後台 provider key 是否綁定、是否允許目前 OpenRouter API Key 使用，以及是否開啟了 fallback。

結論

讓 Codex 使用 DeepSeek，不是不能改 config.toml，而是不能只改 base_url 就指望一切自動相容。

目前更穩的兩條路是：

用本機閘道做協議橋接，Codex 連本機閘道，閘道再連 DeepSeek。
用 OpenRouter BYOK 做線上轉發，Codex 連 OpenRouter，DeepSeek Key 綁定在 OpenRouter 後台。

如果只是想快速試用，OpenRouter 路線更省事；如果你希望 Key、成本、日誌都盡量掌握在自己手裡，本機閘道更適合長期折騰。

參考資料：

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

Gemini 3.5 正式發布：Flash 先行，Google 把重點放在 Agent 和長任務執行

Wed, 20 May 2026 22:51:31 +0800

Google 在 2026 年 5 月 20 日正式發布 Gemini 3.5 系列。第一款開放使用的是 Gemini 3.5 Flash，定位不是單純的聊天模型，而是面向 Agent、程式碼生成和長時間複雜任務執行的模型。

從這次公告看，Google 對 Gemini 3.5 的敘事很明確：模型不只要回答問題，還要能規劃、執行、檢查，並在多步驟任務中持續推進工作。

Gemini 3.5 Flash 先行

Gemini 3.5 Flash 已經面向多類使用者開放：

一般使用者可以透過 Gemini 應用程式和 Google 搜尋中的 AI 模式體驗。
開發者可以透過 Google Antigravity、Google AI Studio、Android Studio 中的 Gemini API 使用。
企業使用者可以透過 Gemini Enterprise Agent Platform 和 Gemini Enterprise 使用。

Google 同時提到，Gemini 3.5 Pro 仍在開發中，已經在 Google 內部使用，計畫在下個月推出。

這說明 3.5 系列會繼續保留 Flash 與 Pro 的分層：Flash 更強調速度、成本和可規模化執行，Pro 則更可能面向更複雜、更高能力需求的場景。

重點是 Agent 和程式碼任務

Google 把 Gemini 3.5 Flash 稱為目前最強的 Agent 與程式碼編寫模型之一。公告中提到，它在多項程式碼和 Agent 基準測試中超過 Gemini 3.1 Pro 的部分成績，例如 Terminal-Bench 2.1、GDPval-AA、MCP Atlas 和 CharXiv Reasoning。

這些指標本身不是一般使用者最需要關心的內容。更重要的是，Google 正在把模型能力往「可執行工作流」上集中：不僅能寫程式碼，還能處理舊專案遷移、複雜應用開發、財務報表整理、資料分析和持續測試。

在 Antigravity 開發架構中，Gemini 3.5 Flash 可以透過多個協作子代理處理大型任務。Google 展示的例子包括解析 AlphaZero 論文並實作可玩的遊戲、把舊版程式碼轉換為 Next.js、並行生成城市景觀和 UI 方案。

這類能力的方向很清楚：AI 編程工具正在從「生成一段程式碼」走向「組織多個 Agent 完成一個專案」。

多模態 UI 與圖形能力增強

Gemini 3.5 Flash 繼承了 Gemini 3 的多模態基礎。Google 強調它可以生成更豐富的網頁 UI、互動動畫和圖形內容。

公告中給出的應用場景包括：

為研究論文生成互動式動畫。
根據文字描述生成互動式硬體模型。
為學校募款活動生成完整品牌概念。
在短時間內為結帳流程生成多種 UX 方案。

這部分對開發者和產品團隊很有意義。模型不再只是輸出文字說明，而是能參與前端原型、互動設計和視覺化內容生成。

企業場景：把耗時流程自動化

Google 在公告中列舉了多個合作夥伴案例。Shopify 使用子代理分析複雜資料並預測商家成長；Macquarie Bank 測試用 3.5 Flash 閱讀超過 100 頁的複雜文件，加速開戶流程；Salesforce 將其整合到 Agentforce；Ramp 用它改進複雜發票 OCR；Xero 用 AI 代理處理行政流程；Databricks 用自動化工作流監控資料異常並給出修復建議。

這些案例共同指向一個趨勢：企業採用大模型時，關注點正在從單次問答轉向流程自動化。模型是否便宜、快、能長時間穩定執行，會比單次回答是否驚豔更重要。

Gemini Spark：個人 AI 代理

Google 還公布了 Gemini Spark。它是由 Gemini 3.5 Flash 驅動的個人 AI 代理，目標是在使用者引導下長期運行並主動執行任務。

Gemini Spark 已經開始面向受信任測試人員推出，Google 計畫在下週向美國 Google AI Ultra 訂閱使用者開放 Beta 測試。

這部分值得關注。Google 搜尋、Gemini 應用程式、Android、Workspace 和瀏覽器生態本來就覆蓋大量個人數位生活場景。如果個人 Agent 能與這些入口結合，影響可能比單獨的聊天機器人更大。

安全機制繼續前移

Google 表示 Gemini 3.5 按照 Frontier Safety Framework 開發，並強化了資訊安全和 CBRN 相關防護。公告還提到使用可解釋性工具，在模型給出回答前協助檢查和理解推理過程。

這說明前沿模型的發布已經不只是能力競賽。越是強調 Agent、自動執行和長任務，安全控制、誤拒率、有害輸出防護和可解釋性就越重要。

怎麼看 Gemini 3.5

Gemini 3.5 Flash 的意義不只是「又一個新模型發布」。它更像是 Google 對下一階段 AI 產品形態的集中押注：模型要能調用工具、拆分任務、協作執行、生成 UI，並進入個人和企業工作流。

對開發者來說，值得關注的是 Google Antigravity、AI Studio、Gemini API 和 Android Studio 中的實際體驗。對企業來說，重點是它能否在真實流程中穩定減少人工操作，而不是只看 benchmark。

Gemini 3.5 Pro 還沒有正式開放。等 Pro 發布後，Flash 與 Pro 在能力、價格、速度和上下文處理上的差異，才會決定它們各自更適合哪些生產場景。

參考來源：

Google Blog：Gemini 3.5 正式登場

agentmemory 項目解析：給 Claude Code、Codex 和 Cursor 加持久記憶

Tue, 19 May 2026 10:56:50 +0800

rohitg00/agentmemory 是一個面向 AI 編程 Agent 的持久記憶系統。它的目標很明確：讓 Claude Code、Codex CLI、Cursor、Gemini CLI、OpenCode 等工具不必每次都重新理解項目背景、架構決策和歷史問題。

項目地址：https://github.com/rohitg00/agentmemory

截至寫作時，GitHub API 顯示這個倉庫已有約 1.3 萬 star，主要語言是 TypeScript，許可證爲 Apache-2.0。README 的描述是“Persistent memory for AI coding agents”。

它解決什麼問題

AI 編程 Agent 的常見痛點是記憶斷裂。今天讓 Agent 修了一個認證問題，明天再開新會話，它可能又不知道：

認證中間件在哪個文件。
項目爲什麼選擇某個庫。
哪些測試已經覆蓋。
哪些 bug 曾經修過。
團隊偏好的實現方式是什麼。

傳統做法是寫 CLAUDE.md、.cursorrules 或項目說明。但這類靜態文件需要人工維護，而且越寫越長，最後容易變成“所有內容都塞進上下文”。

agentmemory 的思路是：後臺記錄 Agent 的觀察、工具調用和會話內容，壓縮成可搜索記憶，再在後續會話中按需取回相關上下文。

支持哪些 Agent

README 中列出的支持範圍很廣，包括：

Claude Code
Codex CLI
Cursor
Gemini CLI
OpenClaw
Hermes
OpenCode
Cline
Goose
Roo Code
Windsurf
Aider

它的連接方式主要包括 hooks、MCP 和 REST API。只要客戶端支持 MCP 或 HTTP，就有機會接入同一個 memory server。

快速啓動

README 給出的基本安裝方式：

npm install -g @agentmemory/agentmemory
agentmemory
agentmemory demo
agentmemory connect claude-code

也可以直接用 npx：

`1`	`npx @agentmemory/agentmemory`

默認服務端口包括：

API：3111
實時 viewer：3113

打開：

`1`	`http://localhost:3113`

可以看到 memory 構建過程、session、知識圖譜、健康狀態等信息。

和靜態記憶文件有什麼不同

靜態記憶文件適合保存規則，比如編碼風格、命令、目錄說明。agentmemory 更偏運行時記憶，適合保存 Agent 實際做過什麼、查過什麼、修過什麼。

README 中強調了幾類能力：

自動捕獲會話和工具調用。
BM25 + Vector + Graph 混合搜索。
MCP 工具暴露。
實時 viewer。
session replay。
本地運行，不依賴外部數據庫。
支持多個 Agent 共享同一套記憶服務。

它不是替代所有項目文檔，而是補上“會話歷史和工作流記憶”這一層。

典型場景

第一，長期維護同一個代碼庫。Agent 可以記住以前修過的模塊、測試策略和關鍵文件。

第二，多工具混用。比如平時用 Claude Code，有時用 Codex CLI 或 Cursor。如果這些工具都接入同一個 memory server，就能共享部分上下文。

第三，複雜任務拆分。長任務中間被壓縮或換會話時，記憶系統可以幫助恢復關鍵狀態。

第四，團隊內沉澱經驗。重複出現的 bug、架構取捨和操作步驟可以沉澱成可檢索信息。

使用時要注意什麼

第一，自動記憶不是越多越好。需要關注隱私、密鑰、客戶數據和敏感代碼，不要把不該記錄的內容放進長期記憶。

第二，記憶召回有誤差。即使 README 給出了基準測試結果，實際項目裏仍然要把召回內容當作參考，而不是事實來源。

第三，多個 Agent 共用記憶時，要設計好隔離邊界。個人項目、公司項目、客戶項目不應該混在同一個無隔離 memory 空間裏。

第四，MCP 工具數量很多時，要注意工具暴露面。只開放實際需要的能力，避免讓 Agent 獲得過寬的寫入、刪除或導出權限。

適合誰

agentmemory 適合已經重度使用 AI 編程 Agent 的用戶。尤其是：

長期維護一個項目的獨立開發者。
經常切換 Claude Code、Codex、Cursor 的用戶。
想研究 MCP、hooks 和 Agent 工作流的開發者。
希望把會話歷史變成可檢索資產的小團隊。

如果只是偶爾讓 AI 改一個小腳本，靜態說明文件就夠了。如果已經把 AI Agent 當作日常開發搭檔，持久記憶系統會更有意義。

小結

agentmemory 解決的是 AI 編程中的“重新解釋成本”。它把會話、工具調用和項目經驗沉澱爲可搜索記憶，讓後續 Agent 更容易接上上下文。

這類工具的方向很重要，但也要謹慎使用。記憶系統越強，越需要重視數據邊界、權限控制和清理機制。真正落地時，建議先在個人項目或非敏感代碼庫裏試用，再逐步擴大範圍。

參考項目：https://github.com/rohitg00/agentmemory

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 成本和回應速度都會更可控。

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

參考資料

OpenClaw 作者 Peter Steinberger 如何看 AI 軟體開發？從 OpenClaw 到閉環編程

Sun, 17 May 2026 20:02:26 +0800

Peter Steinberger 的經歷很適合用來觀察 AI 軟體開發正在發生什麼變化。

他不是「突然被 AI 帶火的新人」。在 OpenClaw 之前，他已經是 PSPDFKit 的創辦人，長期做 PDF 渲染、文件處理和開發者工具。這類產品很難靠概念包裝取勝，必須面對效能、相容性、API 設計、企業客戶和長期維護。

所以，當 Steinberger 後來用 AI 工具做出 OpenClaw，並圍繞 AI Agent、個人自動化和 AI 編程發表觀點時，重點不只是「一個人寫了很多程式碼」。更值得看的，是他把多年軟體工程經驗和新一代 AI coding agent 結合後，對開發流程的重新理解。

AI 編程不是魔法按鈕

很多人討論 AI 編程時，會把它簡化成兩個極端。

一種說法是：AI 已經能寫程式碼，程式設計師快沒用了。

另一種說法是：AI 寫的程式碼不可靠，真正工程還是得靠人手寫。

Steinberger 的經驗更接近第三種：AI 讓軟體開發的操作單位變了，但沒有取消工程判斷。

過去，開發者主要以「編輯程式碼」為中心工作。需求拆解、架構判斷、寫實作、跑測試、修 bug，都圍繞人工修改程式碼展開。

AI coding agent 介入後，開發者越來越像在管理一個執行系統：

說明目標。
提供上下文。
約束邊界。
讓 agent 修改程式碼。
執行測試和檢查。
根據結果繼續迭代。

這不是簡單把鍵盤交給模型，而是把人從「每一行都親手敲」轉到「定義方向、設計回饋、判斷結果」。

為什麼他不喜歡把這叫 vibe coding

圍繞 Steinberger 的討論裡，一個高頻詞是 vibe coding。

這個詞原本用來形容一種新開發方式：開發者用自然語言描述想法，讓 AI 生成大量程式碼，再透過執行結果和回饋不斷調整。

但 Steinberger 對這個詞並不完全買帳。公開報導中提到，他認為 vibe coding 容易變成一種貶義表達，暗示 AI 輔助開發只是「憑感覺亂生成」，忽視了背後的技能、判斷和經驗。

這個批評有道理。

真正有效的 AI 編程並不是隨便輸入一句話，然後相信模型輸出。它需要：

能把模糊需求拆成可執行任務。
能識別模型是否誤解了目標。
能設計測試和驗收標準。
能判斷程式碼結構是否會影響長期維護。
能知道什麼時候應該停止生成、轉向人工審查。

換句話說，AI 降低了寫程式碼的摩擦，但沒有降低理解系統的責任。

閉環才是關鍵

Steinberger 相關訪談和文章裡，經常被總結出的一個核心思路是「閉環」。

只讓 AI 生成程式碼，是開環。

讓 AI 生成程式碼、執行程式碼、讀取錯誤、修復問題、再執行測試，才更接近閉環。

這個差別非常重要。

開環生成很容易製造表面可用的軟體。頁面能打開，功能看起來有，程式碼也不少，但一旦進入真實場景，就會暴露狀態管理、權限、異常處理、邊界條件和部署問題。

閉環開發要求輸出必須被回饋約束。最簡單的閉環是：

寫清楚目標。
讓 AI 修改程式碼。
自動執行測試、型別檢查、lint 或構建。
把錯誤回饋給 AI。
重複直到通過。
最後由人審查關鍵路徑。

這也是 AI 軟體開發真正能提高效率的地方。不是因為模型一次就寫對，而是因為它可以快速參與「生成、驗證、修復」的循環。

經驗越多，越能用好 AI

AI 編程最容易產生的誤解之一，是「經驗不重要了」。

Steinberger 的案例反而說明，經驗會變得更重要，只是作用方式變了。

一個有經驗的工程師更容易判斷：

哪些任務適合交給 agent。
哪些模組需要先寫測試。
哪些改動風險太高，不該讓 AI 大範圍重構。
哪些生成程式碼只是看起來合理。
哪些問題應該透過架構調整解決，而不是繼續補丁式修復。

AI 可以生成大量候選方案，但候選方案越多，越需要判斷力。沒有經驗的人可能會被「能跑起來」迷惑，有經驗的人更會追問：能不能維護？能不能擴展？會不會破壞安全邊界？出了問題能不能定位？

這也是為什麼 AI coding agent 並沒有讓軟體工程變成純聊天。它更像把一部分執行勞動外包出去，同時放大了規劃、審查、驗證和取捨的重要性。

OpenClaw 的意義不只是專案本身

OpenClaw 被關注，不只是因為它是一個開源 AI agent，也不只是因為它的增長速度快。

它更像一個信號：開發者開始希望 AI 不只回答問題，而是能接入真實工具，完成真實動作。

傳統聊天機器人停留在對話框裡。它可以解釋程式碼、寫草稿、給建議，但很多時候還需要人複製、貼上、打開軟體、執行命令。

Agent 的方向是把模型接到工具上：

檔案系統。
瀏覽器。
終端。
郵件。
日曆。
第三方服務。
專案倉庫。

一旦模型能使用這些工具，軟體開發的邊界就會變化。AI 不再只是「程式碼補全」，而會參與專案閱讀、任務拆解、檔案修改、測試執行、PR 整理和工作流自動化。

這也是 Steinberger 加入 OpenAI 後被關注的原因。他代表的不是單個開發者故事，而是一種產品方向：個人 agent 會從演示玩具走向日常工作層。

這對普通開發者意味著什麼

對普通開發者來說，Steinberger 的經驗不一定能直接複製。

不是每個人都能同時管理多個 agent，不是每個專案都適合高強度 AI 生成，也不是每個團隊都能接受「先生成再快速迭代」的節奏。

但有幾件事值得學。

第一，先把任務寫清楚。

AI 對含糊目標很敏感。你說「優化一下」，它可能改風格、改結構、加功能、刪邏輯。你說「把登入失敗時的錯誤提示從英文改成中文，不改變認證流程」，結果通常更可控。

第二，把驗證命令固定下來。

如果一個專案沒有測試、沒有構建命令、沒有 lint，AI 就很難形成閉環。哪怕只是最基礎的 npm test、go test ./...、pytest、hugo，也比完全靠肉眼檢查強。

第三，控制改動範圍。

一次只讓 AI 處理一個模組、一個 bug、一個頁面，通常比讓它「重構整個專案」更可靠。

第四，保留人工審查。

尤其是認證、支付、權限、資料刪除、部署腳本、資料庫遷移、安全配置這些地方，不要因為程式碼是 AI 生成的就降低審查標準。

第五，復盤 prompt 和失敗模式。

如果 AI 經常誤解某類任務，就把約束寫進專案規則、agent instructions 或技能檔案。AI 編程能力不是只來自模型，也來自你給它搭建的工作環境。

AI 軟體開發會走向哪裡

Steinberger 的故事說明，AI 軟體開發正在從「輔助寫程式碼」走向「組織軟體生產流程」。

早期 AI 編程工具的價值主要是補全函式、解釋報錯、生成模板。現在的變化是，agent 可以跨檔案工作，可以呼叫工具，可以執行檢查，可以根據回饋繼續修復。

這會帶來幾個趨勢：

第一，個人開發者的產能上限會提高。

一個人可以同時推進更多原型、腳本、內部工具和小型產品。但產能提高不等於品質自動提高。越快生成，越需要驗證。

第二，專案結構會更重要。

程式碼越清晰，測試越明確，文件越完整，AI 越容易正確修改。混亂專案對人難，對 AI 也難。

第三，軟體工程師會更像工作流設計者。

未來重要的不只是會不會寫某門語言，而是能否把需求、上下文、工具、測試、部署和權限組織成一個可控循環。

第四，安全邊界會更敏感。

Agent 能做事，就可能做錯事。它能讀檔案、執行命令、存取服務，也意味著權限、審計和回滾會成為 AI 開發環境的基礎設施。

小結

Peter Steinberger 的 AI 軟體開發觀，最有價值的地方不是「AI 生成了多少程式碼」，而是他展示了一種新的開發姿勢。

人不再只是在編輯器裡逐行輸入，而是在設計目標、管理 agent、構造回饋迴路、審查結果和調整系統。程式碼仍然重要，但程式碼不再是唯一的勞動中心。

如果說傳統軟體開發強調「把程式碼寫對」，AI 軟體開發會更強調「讓系統持續產出可驗證的正確結果」。

這不是降低工程門檻那麼簡單。它是在改變工程能力的形態：從手工實作，轉向任務分解、上下文管理、工具編排、自動驗證和最終判斷。

參考資料

Gemini 3.5 Pro 曝光：代號 Cappuccino，Google 想在編程和 Agent 上追回節奏

Sun, 17 May 2026 11:47:27 +0800

Google 還沒有正式發布 Gemini 3.5 Pro。

目前能看到的資訊，主要來自開發者社群截圖、匿名跑分、爆料人消息和媒體轉述。36Kr / 新智元在 2026 年 5 月 15 日整理稱，新一代 Gemini 檢查點內部代號可能是 Cappuccino，相關模型已經在社群和評測平台中提前曝光。

這類資訊還不能等同於官方發布，但它透露出一個清晰方向：Google 正在試圖同時補上兩塊短板，一塊是編程和推理能力，另一塊是全天候 AI Agent。

先說結論

這次爆料可以拆成三層來看：

Gemini 3.5 Pro 尚未正式發布，Cappuccino 更像是內部檢查點或候選版本代號。
曝光資訊顯示，新 Gemini 在程式碼生成、SVG / 互動式 Web 生成、多模態輸出上有明顯提升。
Google 同步測試的 Gemini Spark，可能比模型本身更關鍵，因為它指向 24 小時運行的個人 AI Agent。

換句話說，這不是一條簡單的「模型跑分新聞」。它更像是 Google 在 I/O 前釋放出的產品路線訊號：模型要追趕 GPT-5.5，Agent 要搶占使用者工作流入口。

Cappuccino 是什麼

36Kr 文章提到，網友 Lentils 放出的消息顯示，代號 Cappuccino 的 Gemini 3.5 Pro 檢查點已經開始產出。此前社群還在討論 Gemini 3.2，但最新曝光直接跳到了 3.5。

如果這個命名最終屬實，說明 Google 可能希望把下一代 Gemini 包裝成一次更大的版本躍遷，而不是普通小版本更新。

需要注意的是，Cappuccino 現在仍應被視為爆料中的內部代號。它不等於 Google 已經公開上線的正式模型，也不代表最終發布名一定就是 Gemini 3.5 Pro。

編程能力為什麼是焦點

這次爆料裡最受關注的點，是新 Gemini 的編程能力。

36Kr 引述的社群截圖和跑分資訊顯示，新模型在以下任務上表現更強：

生成 SVG 與視覺元件。
生成互動式 Web 應用。
處理動畫、3D、可調參數面板等複雜前端輸出。
邏輯推理和程式碼生成能力有所提升。

文章還提到，Abacus.AI CEO Bindu Reddy 轉述的說法是，3.2 Flash 在編碼和推理上接近 GPT-5.5 的水準，同時成本更低。另有媒體信源則認為，新款 Gemini 的整體性能大致追平 GPT-5.5，但未必能帶來質變。

這也是為什麼要謹慎看待「追平 GPT-5.5」這句話。它更像是不同爆料源和匿名評測中的相對判斷，而不是 Google 官方給出的基準測試結論。

為什麼 Google 急著補編程

AI 編程已經從開發者工具變成了大模型競爭的核心戰場。

OpenAI 有 Codex，Anthropic 有 Claude Code。它們不只服務工程師，也在把產品經理、設計師、營運人員帶進「自然語言生成可運行產品」的工作流裡。

相比之下，Google 雖然有 Gemini 和 Antigravity，但在開發者心智裡一直沒有形成同等強度的預設入口。36Kr 文章也提到，Antigravity 在外部市場還沒有真正突圍，定價、額度提醒和體驗穩定性都曾引發社群討論。

所以新 Gemini 如果要證明自己，編程會是最直接的戰場。它不一定只比拼「會不會寫程式碼」，還要比拼能不能穩定產出完整介面、理解複雜需求、調用工具、修復錯誤並融入真實開發流程。

Spark 可能比 3.5 Pro 更重要

同一波爆料裡，Gemini Spark BETA 也被扒出。

根據 TestingCatalog 等資訊源的說法，Spark 的定位接近「全天候 AI Agent」：它可以處理收件匣、執行線上任務、管理多步驟工作流，並連接 Google 應用、技能模組、聊天記錄、定時任務、登入網站、位置資訊等上下文。

這意味著 Spark 不是一個普通聊天入口，而是一個可能長期在線、持續讀取上下文並替使用者執行任務的系統。

它的吸引力很明顯：如果 Google 能把 Gmail、Calendar、Chrome、Android、Workspace 和 Gemini 串起來，Spark 會天然擁有 OpenAI 和 Anthropic 很難複製的分發優勢。

但風險也同樣明顯。36Kr 文章提到，Spark 相關說明中出現了「可能在未經詢問的情況下分享資訊或完成購買」的表述。哪怕系統設計上會在敏感操作前徵求許可，這類 Agent 仍然會帶來隱私、授權邊界和誤操作風險。

這對普通使用者意味著什麼

如果你只是普通 Gemini 使用者，這次爆料真正值得關注的不是模型名，而是三個變化：

第一，Google 可能會繼續強化「生成完整結果」的能力。以前使用者經常吐槽 Gemini 在視覺生成、SVG、前端頁面上容易偷懶，如果新模型能一次給出多個完整方案，體驗會明顯改善。

第二，編程能力會繼續下放到更輕量的模型。爆料裡反覆提到 Flash 版本在編碼、推理和互動式生成上的提升，這意味著未來不一定只有 Pro 模型才能處理複雜任務。

第三，Agent 會變得更主動。Spark 如果發布，Gemini 可能不再只是回答問題，而是開始長期接管郵件、網頁、購買、日程和跨應用任務。

這對效率是好消息，對權限管理則是新挑戰。

這對開發者意味著什麼

開發者更應該關注兩個問題。

第一個問題是工具生態。36Kr 文章提到，社群從模型選擇器裡看到了 MCP Tool Testing 這類未公開入口。如果 Gemini 原生支援 MCP 或第三方工具測試，那麼它會更容易接入開發者自己的工具鏈。

第二個問題是成本和穩定性。即便新 Gemini 在某些基準上追平 GPT-5.5，開發者最終還是會看三件事：實際程式碼品質、上下文穩定性、價格和額度是否可預期。

過去一年，AI 編程工具競爭已經證明，模型能力只是門票。真正讓開發者留下來的，是能不能在日常專案裡持續可靠地改程式碼、跑測試、讀上下文、處理邊界條件。

現在應該如何看待這條消息

這條消息適合用「強訊號、弱確認」來理解。

強訊號在於：多個社群線索都指向 Google 正在準備更強的新 Gemini，以及更主動的 Gemini Spark Agent。

弱確認在於：Gemini 3.5 Pro 還沒有官方發布，Cappuccino 仍是爆料代號，所謂「追平 GPT-5.5」的說法也需要等 Google 官方基準、第三方評測和真實使用者測試來驗證。

所以現在最穩妥的判斷是：

不要把它當成已發布產品。
可以把它當成 Google 下一階段 Gemini 路線的提前預告。
重點關注 I/O 或後續官方活動中是否會確認模型命名、API 可用性、價格、上下文窗口、工具調用和 Agent 權限邊界。

總結

Gemini 3.5 Pro / Cappuccino 的曝光說明，Google 可能正在為下一代 Gemini 做一次更強勢的版本推進。它要補的不是單一能力，而是整個 AI 工作流：模型要更會寫程式碼、生成介面和處理複雜推理，Spark 則要把 Gemini 推向全天候 Agent。

但在官方發布前，所有跑分和截圖都只能作為線索。真正決定 Gemini 3.5 Pro 能否翻身的，不是代號是否好聽，而是它能否在真實開發、真實辦公和真實多步驟任務裡穩定勝出。

參考連結：

Codex 支援 ChatGPT 移動端遠端存取，Enterprise 工作區可用 Access Tokens

Sun, 17 May 2026 09:12:07 +0800

OpenAI 在 2026 年 5 月 14 日更新了 ChatGPT Enterprise & Edu Release Notes，重點只有兩件事：Codex 支援透過 ChatGPT 移動端遠端存取，Enterprise 工作區可以使用 Codex access tokens 做受控自動化。

這不是一次模型能力發布，而是 Codex 產品形態的變化。Codex 正在從「本地或網頁裡的編程助手」，變成可以長時間執行、可以遠端接管、可以接入企業自動化流程的 coding agent。

這次更新是什麼

根據 OpenAI Help Center 的說明，Codex 現在支援從 ChatGPT mobile app 遠端存取。使用者可以在手機上連接正在執行的 Codex 環境，持續跟進長時間任務，並在需要時介入。

同時，ChatGPT Enterprise 工作區新增 Codex access tokens。它們面向可信的非互動式本地工作流，讓自動化流程可以使用 ChatGPT workspace identity 和企業控制，而不需要每次透過瀏覽器登入。

可以把這次更新理解成兩個入口：

移動端遠端存取：解決「Codex 跑長任務時，人不在電腦前怎麼辦」。
Access Tokens：解決「企業自動化腳本如何以受控身份呼叫 Codex 工作流」。

移動端遠端存取解決什麼問題

Codex 的典型任務並不總是幾秒鐘完成。真實開發裡，它可能要閱讀程式碼庫、修改多個檔案、執行測試、等待命令輸出、根據錯誤繼續修復，甚至需要使用者中途批准某些操作。

過去這類任務往往要求使用者守在本地 Mac、桌面端、CLI 或 IDE 旁邊。現在，ChatGPT 移動端可以變成一個遠端控制台，讓使用者離開電腦後仍能跟進 Codex。

OpenAI 提到，移動端可以展示底層環境的即時狀態，包括：

專案上下文。
approvals。
screenshots。
terminal output。
diffs。
test results。

使用者也可以在手機上回答 Codex 的問題、重定向執行、批准操作、查看輸出，並在不同 connected hosts 之間切換。底層任務仍然運行在 Mac host 或連接的遠端環境中，手機端負責查看和控制。

這對開發者有什麼價值

這項能力最適合長時間、需要中途確認的開發任務。

例如：

Codex 正在跑一組耗時測試，你出門後仍想看結果。
Codex 修改了多個檔案，需要你在手機上看 diff 後批准下一步。
Codex 執行到某個危險操作前等待確認，你可以遠端處理。
本地 Mac 上有多個 connected hosts，需要在手機上切換查看狀態。

它的價值不是讓你在手機上寫程式，而是讓你不用一直守著電腦。Codex 繼續在原環境裡工作，你只在關鍵節點介入。

這也說明 Codex 的使用方式正在接近「後台 Agent」：任務可以持續執行，使用者不必全程在線，但仍要保留審批和控制權。

Access Tokens 解決什麼問題

Codex access tokens 面向 ChatGPT Enterprise 工作區。它們的重點不是普通個人使用者登入，而是企業內部可信自動化。

企業裡經常有一些本地或內部流程需要非互動式執行，例如：

定時執行程式碼檢查。
在受控機器上觸發 Codex 工作流。
將 Codex 接入內部開發工具鏈。
在不開啟瀏覽器的情況下使用工作區身份。

Access tokens 讓這些流程可以帶著 ChatGPT workspace identity 執行，同時繼續受企業策略約束。相比臨時人工登入，它更適合自動化；相比隨便共享個人憑據，它也更容易納入治理。

它不是普通 API key

這點很重要。Codex access tokens 不應該被理解成一個簡單的「萬能 API key」。

OpenAI 的說明裡提到，access tokens 可用於 ChatGPT Enterprise 工作區，管理員可以管理工作區級可用性，擁有允許角色的成員可以建立自己的 tokens。治理介面在可用情況下也會反映 access token 活動。

也就是說，access tokens 被放在企業權限、角色和審計框架裡：

管理員可以決定工作區是否開放。
不是所有成員都天然可以建立。
token 活動可以進入治理視圖。
它繼承 ChatGPT workspace identity 和企業控制。

這和個人隨手產生一個長期密鑰不是一回事。

安全預設值：Remote Control 預設關閉

Codex mobile remote access 涉及程式碼環境、終端輸出、diff、測試結果和操作審批。如果預設開放，會帶來明顯企業安全風險。

因此 OpenAI 的預設策略是：remote control 預設關閉，管理員或 owner 需要在 Workspace settings 中啟用。

啟用移動端遠端存取時，還可能涉及：

workspace-enabled Remote Control access。
SSO。
多因素認證。
passkey。

這說明它是需要企業 IT 和安全團隊參與配置的能力，而不是「更新 App 後所有人自動可用」。

使用前需要更新什麼

OpenAI 提到，要使用移動端遠端存取，需要更新兩端：

ChatGPT mobile app。
macOS 上的 Codex app。

如果工作區啟用了相關要求，移動端設定過程還可能觸發 SSO、多因素認證或 passkey 流程。

實際落地時，企業管理員還需要先確認 Workspace settings 裡的 remote control 設定，以及哪些成員或角色可以使用相關能力。

對企業 Codex 使用方式的影響

這次更新把 Codex 往兩個方向推進。

第一，Codex 更適合長任務。以前長任務最大的問題是使用者要一直盯著，現在手機可以查看狀態和批准操作，Codex 可以更自然地跑在後台。

第二，Codex 更適合企業自動化。Access tokens 讓非互動式工作流有了更正式的身份方式，後續更容易接入內部 CI、程式碼審查、腳本和開發平台。

這兩個方向結合起來，意味著 Codex 不再只是「開發者手邊的 AI 助手」，而是在變成企業開發流程裡的一個可管理 agent。

仍然需要注意的邊界

這次更新很有用，但並不意味著 Codex 可以完全無人看管。

企業使用時仍然要注意：

哪些專案允許遠端控制。
哪些命令需要審批。
token 如何建立、輪換和撤銷。
mobile remote access 是否符合公司設備管理策略。
終端輸出、截圖和 diff 是否可能包含敏感資訊。
審計日誌和治理介面是否能滿足內部合規要求。

尤其是 access tokens，一旦進入自動化流程，就要像其他企業憑據一樣管理：最小權限、定期輪換、避免硬編碼、及時撤銷不用的 token。

總結

OpenAI 這次 Codex 更新的重點很集中：ChatGPT 移動端可以遠端存取 Codex 長任務，Enterprise 工作區可以用 Codex access tokens 支援受控自動化。

前者讓開發者不必一直守在電腦前，後者讓企業可以把 Codex 更正式地接入內部工作流。兩者合在一起，說明 Codex 正在從互動式編程助手，進一步走向可遠端管理、可審計、可自動化接入的企業 coding agent。

參考連結：

OpenAI Help Center：ChatGPT Enterprise & Edu - Release Notes

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 是一個值得收藏的起點。

DeepSeek-TUI：把 DeepSeek V4 變成終端裡的編程智能體

Sat, 16 May 2026 22:41:41 +0800

DeepSeek-TUI 是一個把 DeepSeek V4 接入終端開發流程的開源專案。它不是普通聊天外殼，而是更接近 Claude Code、Codex CLI 這類「命令列編程智能體」：能看檔案、改程式碼、執行命令、調用工具，並在終端裡用 TUI 方式持續推進任務。

如果你已經習慣在編輯器和終端之間切換，這類工具的價值很直接：不用把程式碼來回複製到網頁對話框裡，也不用手動描述完整專案結構。你把任務交給它，它可以在目前工作區裡讀取上下文、規劃步驟、執行修改，再把結果交還給你審查。

它解決的是 DeepSeek 的使用入口問題

DeepSeek 模型本身提供了很強的推理和程式能力，但模型能力要落到真實開發流程裡，還需要一層工程化外殼。

網頁聊天適合問問題，不適合長時間改專案。API 適合接入系統，但一般開發者還要自己寫工具調用、上下文管理、檔案讀寫和權限控制。DeepSeek-TUI 想補上的正是這一層：把 DeepSeek V4 包成一個可以在終端裡工作的 Agent。

從專案介紹看，它的重點能力包括：

終端 TUI 介面；
面向 DeepSeek V4 的對話與任務執行；
工具調用和檔案操作；
1M 上下文支援；
Auto 模式；
子智能體；
沙箱執行；
持久化任務佇列。

這些功能組合起來，目標不是「讓模型回答得更像人」，而是讓模型更容易進入開發現場。

TUI 比純命令列更適合長任務

很多 AI CLI 工具一開始都是純文字互動：輸入提示詞，等待輸出，再複製命令或補充上下文。這種方式簡單，但任務一長就容易混亂。

TUI 的好處是能把會話、檔案、執行結果、任務狀態放在一個更穩定的介面裡。對編程 Agent 來說，這很重要。因為一次程式任務往往不是一問一答，而是包含：

理解專案結構；
查找相關檔案；
修改程式碼；
執行測試或命令；
根據錯誤繼續修復；
總結變更。

如果介面只是一串日誌，使用者很難快速判斷 Agent 走到了哪一步。TUI 至少給了一個更適合觀察和接管的入口。

Auto 模式適合明確邊界的任務

DeepSeek-TUI 提到的 Auto 模式，適合用在邊界比較清楚的工作裡。例如修一個小 bug、補一個腳本、改一段配置、整理一組文件、實作一個局部功能。

這類任務的共同點是：目標清楚，檢查方式明確，影響範圍可控。Agent 可以自己查檔案、改檔案、跑命令，然後把結果交給使用者確認。

但 Auto 模式不適合無限放權。尤其是在真實專案裡，刪除檔案、批量重構、資料庫遷移、部署命令都應該有明確確認。編程 Agent 的效率來自自動化，但風險也來自自動化。越是能執行命令的工具，越需要沙箱、權限邊界和人工審查。

子智能體的意義在於拆任務

子智能體不是新概念，但放在程式場景裡很有用。

一個稍複雜的任務，通常會同時需要幾類工作：有人負責讀程式碼，有人負責改實作，有人負責檢查測試，有人負責整理文件。傳統多 Agent 系統經常顯得花俏，是因為它們沒有真實工具和真實工作區，只是在對話裡互相討論。

如果子智能體能結合檔案系統、命令執行和任務佇列，它就更像一種任務拆分機制。比如一個子智能體專門分析依賴關係，另一個負責修改某個模組，主智能體再整合結果。這樣可以減少單一上下文裡堆太多無關資訊的問題。

當然，子智能體也會帶來額外成本：更多 token、更複雜的狀態、更難追蹤的責任邊界。所以它適合中等複雜度以上的任務，不一定適合每一次小修改。

1M 上下文不是萬能，但很適合讀專案

1M 上下文聽起來很誇張，但在編程場景裡並不只是行銷數字。

真實程式庫的上下文很碎：README、設定檔、型別定義、測試、調用鏈、歷史約定、錯誤日誌，都可能影響一次修改。更長上下文能減少「只看局部就動手」的問題，也能讓模型保留更多專案約束。

不過，上下文長不等於判斷一定更準。程式任務仍然需要檢索、篩選和驗證。把整個專案塞進上下文並不一定比精準讀取相關檔案更好。好的編程 Agent 應該把長上下文當作緩衝區，而不是把它當成替代工程判斷的捷徑。

更適合哪些使用者

DeepSeek-TUI 更適合幾類人：

想在終端裡使用 DeepSeek 做程式任務的開發者；
不想自己搭工具調用和檔案操作框架的人；
已經熟悉 Claude Code、Codex CLI，但想嘗試 DeepSeek 模型入口的人；
需要本地專案上下文，而不是只在網頁裡問程式片段的人；
想把 AI 編程流程放進命令列環境的人。

如果你只是偶爾問一個函式怎麼寫，網頁聊天已經夠用。如果你希望模型直接參與專案修改，終端 Agent 才更有意義。

需要關注的風險

這類工具最需要關注三件事。

第一是權限。只要工具能讀寫檔案、執行命令，就要確認它預設能存取哪裡、能不能刪除檔案、能不能連網、危險命令是否需要確認。

第二是可回滾。使用前最好保持 Git 工作區乾淨，讓每次 Agent 修改都能被 git diff 清楚看到。不要在一堆未提交改動裡讓 Agent 自動改專案。

第三是驗證。Agent 寫完程式不代表任務完成。測試、構建、lint、人工 review 仍然要保留。AI 編程工具可以提高推進速度，但不能替代最後的工程確認。

總結

DeepSeek-TUI 的意義不在於又多了一個聊天客戶端，而在於它把 DeepSeek V4 放進了更接近真實開發工作的終端環境裡。

對開發者來說，模型能力只是第一步。真正影響體驗的是：它能不能讀專案、能不能安全改檔案、能不能執行驗證命令、能不能在長任務裡保持狀態、能不能讓使用者隨時接管。

如果你想把 DeepSeek 用在日常程式修改、專案閱讀和自動化開發任務裡，DeepSeek-TUI 值得關注。它代表的方向也很清楚：AI 編程工具正在從「回答程式問題」轉向「參與專案執行」。

Codex 手機遠端存取來了：用 ChatGPT App 跟進 Mac 上的編程任務

Sat, 16 May 2026 17:42:40 +0800

OpenAI 在 2026 年 5 月中旬把 Codex remote access 帶進 ChatGPT 手機 App。這個功能的重點不是「在手機上寫程式」，而是讓你用手機遠端跟進 Mac 上正在執行的 Codex。

它更像一個行動審批和監控入口：Codex 繼續在電腦上讀專案、跑命令、改檔案、看測試結果；手機端負責查看進度、回答問題、補充指令和批准操作。

對經常讓 Codex 跑長任務的人來說，這個變化很實用。你不必一直坐在電腦前等它卡在哪裡，離開工位後也能從 ChatGPT App 接上現場。

它能做什麼

根據 OpenAI Codex remote connections 文件，手機端遠端存取可以：

在 Mac 主機上的專案裡開啟新 thread，或繼續已有 thread；
發送後續指令，回答 Codex 的問題，調整任務方向；
批准命令和其他操作；
查看輸出、diff、測試結果、終端輸出和截圖；
在 Codex 完成任務或需要你注意時收到通知；
在多個已連接主機和 thread 之間切換。

也就是說，手機端不是簡化版聊天視窗，而是接入了 Codex 目前的工作現場。

使用前需要什麼

第一，你需要有可用的 Codex 權限，並且手機和 Mac 使用同一個 ChatGPT 帳號與 workspace。

第二，手機上要安裝最新版 ChatGPT App，iOS 或 Android 都可以。如果 App 裡看不到 Codex，先更新 ChatGPT。

第三，主機目前要求是 Mac，並且需要保持在線、喚醒、正在執行 Codex App。OpenAI 文件明確寫到，行動端設定和裝置控制目前需要主機上執行 Codex App for macOS，不能從 Codex CLI 或 IDE Extension 完成設定。

第四，如果帳號或 workspace 要求 MFA、SSO 或 passkey，需要先完成對應認證。團隊 workspace 還可能需要管理員開啟 Remote Control access。

Codex 手機遠端存取的限制

第一，當前需要 macOS host。手機端連接的是 Mac 上執行的 Codex App，不是直接連接 Codex CLI、IDE Extension，也不是任意 Linux / Windows 開發機。

第二，主機必須在線。Mac 需要保持喚醒、連網，並持續執行 Codex App。如果電腦睡眠、斷網或 Codex 關閉，手機端遠端會話就可能斷開。

第三，連線依賴掃碼流程。你需要先在 Mac 端開啟 Set up Codex mobile，再用手機掃描 QR code 進入 ChatGPT 完成綁定。

第四，遠端操作仍然要經過審批流程。手機端可以批准命令和其他操作，但你仍然要看清 Codex 請求做什麼，再決定是否繼續。

所以它適合「人離開電腦後繼續跟進任務」，不適合替代完整開發環境，也不適合把主機長期無人值守地開放給遠端操作。

怎麼連接

設定流程從 Mac 上的 Codex App 開始。

在 Mac 上開啟 Codex。
在側邊欄選擇 Set up Codex mobile。
Codex 會為這台主機開啟遠端存取，並顯示 QR code。
用手機掃描 QR code，進入 ChatGPT 裡的 Codex mobile setup 流程。
確認同一個 ChatGPT 帳號和 workspace。
完成必要的 MFA、SSO 或 passkey 驗證。
設定成功後，這台 Mac 會出現在手機端 Codex 裡。

連接完成後，可以在 Mac 端 Codex 的 Settings > Connections 管理已連接裝置，也可以設定是否讓電腦保持喚醒、是否啟用 Computer Use、是否安裝 Chrome extension。

手機端適合做什麼

手機端最適合三類操作：審批、糾偏和查看結果。

Codex 需要執行命令、存取檔案或繼續某個動作時，你可以在手機上看清請求，再決定是否批准。當 Codex 誤解需求、測試失敗或需要方向判斷時，也可以直接補充一句說明。最後，你可以查看 diff、測試輸出、終端日誌和截圖，不必回到電腦前才知道任務進度。

真正有價值的不是手機寫程式，而是把手機變成工程任務的隨身控制台。

常見問題

如果手機上看不到主機，先確認 Mac 上 Codex App 仍在執行，並且開啟了 Allow other devices to connect。手機和主機也必須使用同一個 ChatGPT 帳號與 workspace。

如果審批請求沒有出現，可以打開 ChatGPT 手機 App，進入 Codex，再重新掃碼或從主機重新開始設定。團隊帳號還要確認管理員是否已允許 Remote Control access。

如果遠端會話斷開，通常要檢查 Mac 是否睡眠、網路是否斷開、Codex App 是否關閉。

如果認證卡住，就先完成 MFA、SSO、passkey 流程。企業環境裡，權限問題往往要管理員介入。

適合哪些場景

它適合經常讓 Codex 跑較長程式修改任務、需要離開工位後繼續審批和跟進、同時管理多個專案或 thread，並且以 Mac 作為主力開發機的人。

不太適合主要使用 Windows 或 Linux、只用 Codex CLI 或 IDE Extension、希望手機端獨立完成完整開發環境，或網路不穩定的人。

我的判斷

Codex 手機遠端存取的意義，不是把開發工作搬到手機螢幕上，而是讓「等待 Codex 跑完」的時間更可控。

以前 Codex 長任務經常卡在審批、追問、測試失敗或方向確認上。現在這些節點可以透過 ChatGPT 手機 App 處理，Mac 繼續做真正的工程執行，手機負責輕量決策。

如果你已經在 Mac 上重度使用 Codex，這個功能值得開啟。如果你只是偶爾問幾句程式問題，它的價值可能沒那麼明顯。

參考資料

別把 API Key 推上 GitHub：AI 寫程式時代的密鑰外洩防坑指南

Sat, 16 May 2026 16:26:50 +0800

AI 寫程式降低了動手門檻，也把很多原本只會發生在工程團隊裡的安全問題，帶到了新手和非工程使用者面前。

最常見的一類事故，是把 API Key、Secret、Token、資料庫連線字串或 .env 設定檔一起推到公開倉庫。對本機專案來說，這些檔案只是「能讓程式跑起來的設定」；一旦進了 GitHub 公開倉庫，它們就變成了可以被自動掃描、自動呼叫、自動濫用的憑證。

密鑰外洩不是小機率事件。GitGuardian 的 2026 年度報告提到，2025 年公共 GitHub 提交裡出現了約 2865 萬個新增硬編碼憑證，AI 服務相關憑證外洩同比成長 81%。這說明問題不只是「有人粗心」，而是 AI 編程、快速原型和公開託管疊加後，外洩規模正在被放大。

為什麼新手更容易外洩 Key

很多 AI Agent 或小工具都有兩套「倉庫」：一套在本機硬碟裡，另一套在 GitHub 上。問題在於，新手經常沒有意識到兩者的邊界。

本機執行時，config.json、.env、settings.yaml 裡放著 API Key，好像只是開發習慣；執行 git add .、git commit、git push 之後，這些檔案就可能被完整上傳。倉庫一旦公開，掃描機器人不需要理解你的業務，只要匹配到密鑰格式，就能把它抓走。

AI 編程還會放大這個問題：

AI 生成範例程式碼時，可能直接把 OPENAI_API_KEY = "sk-..." 這類寫法放進原始碼。
新手為了「先跑起來」，容易把密鑰硬編碼在前端、腳本或設定檔裡。
很多 vibe coding 平台可以直接部署應用，不一定經過 GitHub 的推送保護流程。
使用者可能不知道 AI 生成的專案裡到底有哪些檔案、哪些介面、哪些預設權限。

換句話說，AI 可以幫你更快寫出能跑的東西，但不會自動替你承擔安全責任。

`.gitignore` 不是裝飾

Git 負責版本管理，GitHub 負責託管程式碼，.gitignore 則是告訴 Git 哪些檔案不要納入版本歷史。

一個最基本的 AI 專案，至少應該把這些內容排除掉：

.env
.env.*
*.key
*.pem
config.local.*
secrets.*
credentials.*

但只寫 .gitignore 還不夠。它只能阻止「尚未被 Git 追蹤」的檔案繼續進入提交。如果某個密鑰檔案已經被提交過，後來再把它寫進 .gitignore，並不能把歷史記錄裡的密鑰抹掉。

更穩妥的習慣是：

新專案一開始就建立 .gitignore。
API Key 只放在環境變數或本機設定裡。
範例檔案只提供 .env.example，裡面寫佔位符，不寫真實密鑰。
提交前執行一次密鑰掃描工具，比如 gitleaks、trufflehog 或 GitHub Secret Scanning。

Key 推上去以後，刪除檔案不等於安全

如果密鑰已經推到公開倉庫，第一反應不應該是「刪掉檔案再提交一次」，而應該是立刻吊銷或輪換密鑰。

原因很簡單：Git 記錄的是歷史。即使你在最新提交裡刪除了檔案，舊提交、fork、clone、快取和掃描系統裡仍可能保留那段內容。GitHub 官方文件也明確建議：如果外洩的是密碼、Token 或憑證，第一步應該撤銷或輪換。

處理順序建議這樣做：

立即去服務商後台吊銷舊 Key，生成新 Key。
檢查帳單、呼叫日誌、異常 IP 和異常用量。
從程式碼中移除硬編碼密鑰，改用環境變數或密鑰管理服務。
用 git filter-repo 或 BFG 清理倉庫歷史中的敏感檔案。
開啟 GitHub Secret Scanning 和 Push Protection。
檢查 CI/CD、部署平台、雲函式、前端建置產物裡是否也包含舊 Key。

對於 OpenAI、Anthropic、DeepSeek、雲廠商、支付、郵件、資料庫等服務，外洩 Key 的後果可能不只是被刷額度，還可能包含資料讀取、服務濫用、供應鏈污染或業務帳號封禁。

前端程式碼裡不能放真正的密鑰

很多新手以為「只要頁面能跑就行」，於是把 API Key 寫進前端 JavaScript：

`1`	`const apiKey = "sk-xxxxxxxx";`

這基本等於公開。瀏覽器裡的程式碼、網路請求、Source Map、建置產物都可以被查看。只要是真正需要保密的 Key，就不應該出現在客戶端。

正確做法是讓前端請求自己的後端介面，由後端讀取環境變數並呼叫第三方 API：

// frontend
await fetch("/api/chat", {
  method: "POST",
  body: JSON.stringify({ message })
});

後端再使用環境變數：

1
2

// server
const apiKey = process.env.OPENAI_API_KEY;

這樣做不是為了形式好看，而是為了把密鑰留在伺服器環境裡，避免直接暴露給所有訪問頁面的人。

Vibe Coding 的安全責任不會自動消失

vibe coding 的問題不只是 GitHub 外洩。很多應用直接從 AI 編程平台發布到公網，跳過傳統程式碼審查、倉庫掃描和安全測試。

RedAccess 近期披露的研究顯示，公開網路上可以找到大量由 AI 編程工具生成或託管的應用資產，其中一部分暴露了企業資料、個人資訊或內部檔案。它提醒的是同一件事：當「能上線」變得太容易，「是否應該上線」「是否只該內網訪問」「是否有權限控制」就更容易被忽略。

如果你用 AI 生成應用，至少要在發布前問自己幾個問題：

這個應用是否真的需要公開訪問？
是否有登入、鑑權和權限隔離？
是否把資料庫、API Key、Token、Webhook 地址暴露在前端？
是否限制了第三方 API 的額度、網域、權限和有效期？
是否能在發現異常後快速停用密鑰和回滾部署？

AI 寫出來的程式碼也需要安全審查。越是「我一行程式碼都沒寫」，越不能假設它天然安全。

現在就該做的檢查

可以先從自己的 GitHub 帳號查起。搜尋使用者名稱加上這些關鍵字：

API_KEY
SECRET
TOKEN
OPENAI_API_KEY
ANTHROPIC_API_KEY
DEEPSEEK_API_KEY
.env
config
credentials

如果發現真實密鑰，不要猶豫：先輪換，再清理。只要它進過公開倉庫，就按已經外洩處理。

以後新建 AI 專案時，也建議固定一套流程：

先寫 .gitignore，再寫業務程式碼。
用 .env.example 說明需要哪些變數。
所有密鑰放環境變數，不寫進原始碼。
給 API Key 設定最小權限、額度限制和過期時間。
開啟 GitHub Secret Scanning 和 Push Protection。
發布前讓 AI 再幫你做一次安全檢查，但不要只相信 AI 的結論。

AI 編程真正危險的地方，不是它會寫錯程式碼，而是它讓很多人第一次擁有了把不安全應用快速發布到公網的能力。寫得快不是問題，把密鑰、資料和權限一起交出去才是問題。

參考資料

Gemini 3.5 Pro 提前曝光：Google 想用 Spark Agent 搶回 AI 編程入口

Fri, 15 May 2026 23:45:34 +0800

Gemini 3.5 Pro 還沒正式發布，相關爆料已經開始升溫。

這輪資訊裡有幾個關鍵詞：Gemini 3.5 Pro、代號 Cappuccino、Gemini Spark、AI 編程、MCP 工具接入。它們指向同一個方向：Google 不只是想更新一個聊天模型，而是想把模型、工具、Agent 和 Google 生態入口重新綁在一起。

不過，在正式發布前，這些資訊都應該按「爆料」看待。真正值得關注的不是某一張截圖或某一個跑分，而是 Google 接下來可能要補的幾塊短板。

Gemini 3.5 Pro 為什麼值得關注

從曝光資訊看，Gemini 3.5 Pro 可能是一次跳級命名。

此前外界還在討論 Gemini 3.2，隨後又出現 Gemini 3.5 Pro 的說法。如果命名屬實，說明 Google 想在新一輪發布裡講一個更大的版本故事，而不是只做常規小更新。

目前流出的重點主要集中在三方面：

編程和推理能力繼續提升；
SVG、互動式頁面、動畫和 3D 生成能力增強；
新的 Agent 產品 Gemini Spark 可能進入前台。

這些方向並不意外。Gemini 系列一直強調多模態，Google 也有足夠強的分發渠道。真正的問題是，它能不能在開發者工具和 Agent 工作流上趕上 OpenAI、Anthropic 的節奏。

編程能力是 Google 最需要補的課

大模型競爭進入 2026 年後，編程已經不只是「模型能力測試項」，而是最直接的產品入口。

原因很簡單：AI 編程工具有高頻使用場景，也能產生大量可回饋的資料。開發者每天讓模型讀程式碼、改程式碼、跑測試、修 bug，這些互動天然會推動下一代模型和工具鏈繼續進化。

過去一年，Claude Code 在開發者群體裡聲量很高，OpenAI 也持續強化 Codex 與 ChatGPT 的協同。相比之下，Google 雖然有 Antigravity 等產品，但外部存在感並不算強。

這也是 Gemini 3.5 Pro 被重點觀察的原因。如果它只是聊天更強、回答更快，意義有限；如果它能真正改善程式碼理解、跨檔案修改、工具呼叫和長任務執行，才可能改變開發者工作流。

Gemini Spark 可能是更大的變數

比模型本身更激進的，是傳聞中的 Gemini Spark。

按照曝光描述，Spark 的定位不是普通聊天助手，而是全天候運行的 AI Agent。它可能接入郵件、日程、網頁、任務、帳號狀態和個人上下文，幫助使用者處理多步驟工作流。

這類產品的想像空間很大。比如：

自動整理收件箱；
幫使用者跟進任務；
在網頁上執行操作；
處理跨應用流程；
根據個人偏好安排日常事務。

但風險也同樣明顯。一個全天候 Agent 如果能存取登入狀態、瀏覽器資料、檔案、位置和第三方服務，就必須回答幾個問題：什麼時候需要使用者確認？哪些操作必須禁止自動執行？資料會不會被分享給第三方？遠端瀏覽器和憑證如何隔離？

所以 Spark 真正的看點，不只是「能不能幫你幹活」，而是 Google 能否把權限、稽核、確認機制和使用者控制做得足夠清楚。

MCP 工具接入說明什麼

爆料裡還提到，新的 Gemini 選擇器可能出現 MCP 相關模型或測試入口。

如果這部分最終落地，說明 Google 也在把模型從「問答系統」推向「工具操作系統」。模型不再只是生成文字，而是要能呼叫外部工具、存取業務系統、讀寫檔案、執行命令，並在多個步驟之間保持任務狀態。

這和 OpenAI、Anthropic 的方向是一致的。誰能讓模型更穩定地呼叫工具，誰就更容易把 AI 嵌進真實工作流。

不過，MCP 接入本身不是終點。真正難的是穩定性：

模型能否正確選擇工具；
參數是否可靠；
失敗後能不能恢復；
權限邊界是否明確；
使用者能不能追蹤每一步操作。

如果這些問題沒解決，工具越多，出錯面也越大。

多模態仍然是 Google 的優勢牌

Google 最有機會打出差異化的地方，仍然是多模態。

從曝光的 SVG、互動式頁面、動畫和視覺生成案例看，Gemini 可能繼續強化「從提示詞生成可互動內容」的能力。相比單純寫一段程式碼，這更接近產品原型生成：使用者描述一個想法，模型直接給出可操作、可調節、可預覽的介面。

這條路線很適合 Google。它既能承接 Gemini 的多模態能力，也能和 Android、Chrome、Workspace、搜尋、廣告、雲服務等入口結合。

如果 Google 想避免只在「誰的程式碼模型更強」上硬拼，它很可能會把重點放到更完整的多模態 Agent 系統上。

三家公司的打法正在分化

現在的大模型競爭已經不是單一模型排行榜競爭。

OpenAI 的優勢在產品迭代和分發節奏，Codex、ChatGPT、企業工具和 API 之間的聯動越來越緊。

Anthropic 的優勢在開發者心智和程式碼模型品質，Claude Code 已經成了很多人預設的 AI 編程入口。

Google 的優勢則是生態入口。Gmail、Docs、Chrome、Android、搜尋、YouTube、地圖和雲服務構成了一個巨大的個人與企業資料網路。只要 Agent 能安全接入這些入口，Google 就有機會從「模型追趕者」變成「工作流入口控制者」。

這也是 Gemini Spark 值得關注的原因。它不一定需要在所有基準測試上第一，但只要能進入日常工作流，就可能形成自己的護城河。

普通使用者該怎麼看

對普通使用者來說，短期不必被每一次爆料牽著走。

更實用的觀察點有三個：

Gemini 3.5 Pro 的編程能力是否真的改善，尤其是複雜倉庫、長上下文和工具呼叫。
Gemini Spark 是否預設安全，敏感操作前是否有明確確認和可追蹤記錄。
Google 是否給出清晰價格、額度和企業權限管理，而不是只展示演示效果。

如果只是生成幾張漂亮截圖，價值有限。能不能穩定接入真實工作流，才是這一輪 AI Agent 產品的分水嶺。

對開發者意味著什麼

開發者最應該關注的不是「哪個模型贏了」，而是自己的工作流是否可遷移。

現在 Claude Code、Codex、Gemini、Antigravity、Cursor、Windsurf 等工具都在搶入口。如果把所有流程都綁死在某一個平台上，未來成本、額度、模型策略或權限規則一變，遷移會很痛。

更穩妥的做法是：

重要專案保留標準 Git 工作流；
自動修改後必須看 diff；
關鍵任務用測試和 CI 兜底；
不把生產憑證交給不透明 Agent；
能用開放協議接工具時，優先選擇可替換方案。

模型會繼續變強，但工程紀律不會過時。

小結

Gemini 3.5 Pro 的爆料說明，Google 正在加速補齊 AI 編程和 Agent 入口。模型能力提升是一部分，Gemini Spark 這類全天候 Agent 可能才是更大的戰略動作。

但越是能幫使用者「自動幹活」的系統，越需要嚴格的權限邊界和可驗證流程。對 Google 來說，真正的挑戰不只是追上 GPT-5.5 或 Claude，而是把強模型、安全機制和生態入口組合成一個可信的日常工作流。

如果這一步做成，Gemini 不一定要在每個榜單上第一，也可能重新拿回一部分 AI 入口主動權。

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 編程流程，這個方案值得試試。只是要記住：先從小任務開始，每次改動都要驗證，把本地模型當助手，而不是自動工程師。

Prompt-Vault：一個適合測試 AI 程式設計能力的 Prompt 規格庫

Fri, 15 May 2026 09:00:52 +0800

w512/Prompt-Vault 是一個很小但有用的 prompt 倉庫。它不是收集“萬能咒語”，而是把一組可執行的 coding prompt 按難度整理成規格文件，用來測試 LLM 或 coding agent 能不能真正完成一個小專案。

專案地址：https://github.com/w512/Prompt-Vault

截至寫作時，這個倉庫只有少量檔案和提交，但結構很清楚：Easy、Medium、Hard 三個目錄，每個 Markdown 檔案都是一個獨立任務。README 裡也寫得很直接：這些 prompt 適合測試大語言模型，或者給開發者當練手專案。

它不是 prompt 收藏夾

很多 prompt 倉庫的問題，是內容看起來很多，但很難判斷質量。標題很吸引人，真正拿去用時卻缺少驗收標準。

Prompt-Vault 更像一個小型規格庫。每個任務都儘量寫清楚：

要做什麼應用
必須有哪些功能
UI 應該是什麼風格
技術約束是什麼
是否必須單檔案執行
是否允許外部依賴
資料是否需要持久化

這種結構比“請幫我做一個好看的看板”更適合測試模型。因為它能看出模型是否真的理解需求，而不是隻生成一份看似完整的頁面。

Easy：測試基礎互動

Easy 目錄裡有兩個任務。

第一個是 Bubble_Sort_Visualizer.md，要求做一個單檔案 index.html，用柱狀條實時展示氣泡排序。它要求有開始按鈕、重置按鈕、速度滑塊、比較次數統計和深色主題。

這個任務適合測試模型的基礎前端能力：

能不能把演算法狀態對映到 UI
能不能做動畫節奏控制
能不能正確處理重置和執行狀態
能不能保持程式碼簡單可讀

第二個是 ToDo_List.md，從靜態 HTML 開始，一步步增加新增任務、完成狀態、刪除按鈕、計數器、Active / Completed 統計和 localStorage 持久化。

這個任務看起來普通，但很適合測試模型是否會按步驟演進，而不是一口氣堆出一份混亂程式碼。

Medium：測試複雜狀態和動畫

Medium/Sorting_Visualization.md 把排序視覺化升級了一檔。

它要求同一個頁面支援 6 種排序演算法：

Bubble Sort
Insertion Sort
Selection Sort
Merge Sort
Quick Sort
Heap Sort

同時還要有演算法選擇、速度滑塊、陣列大小滑塊、重置按鈕、開始 / 暫停切換，以及實時統計面板。

這個任務能測出不少問題。很多模型可以寫出一個氣泡排序動畫，但一旦要支援多個演算法、暫停恢復、統計比較次數和交換次數，就容易出現狀態混亂。

如果用它做評測，可以重點看這些點：

每種演算法是否真的按預期排序
動畫是否和演算法步驟一致
暫停後能否繼續
重置是否會停止舊動畫
陣列大小變化是否會破壞狀態
統計資料是否可信

這類 prompt 很適合作為前端 coding agent 的中等難度 smoke test。

Hard：測試完整產品感

Hard 目錄目前有兩個任務。

一個是 Kanban_Board.md。它要求做一個完整的看板應用：預設四列、可新增列、雙擊重新命名、空列刪除、卡片標題和描述、優先順序、截止日期、拖拽、搜尋、優先順序過濾、localStorage 持久化、底部統計欄、深色玻璃擬態風格和響應式橫向滾動。

這個 prompt 的價值在於它不是隻測單點能力，而是測“產品完整度”：

原生 Drag & Drop 是否可靠
新增列和卡片後狀態是否持久化
搜尋和過濾是否影響佈局
overdue 邏輯是否正確
Done 列是否觸發視覺狀態變化
刪除、重新命名、取消、儲存這些邊界是否完整

另一個是 Markdown_Editor_Desktop.md，要求用 Tauri 2 做跨平臺 Markdown 編輯器。它包含分欄編輯與預覽、同步滾動、實時渲染、預覽模式、專注模式、開啟檔案、儲存、另存為、視窗標題未儲存標記、格式化工具欄、快捷鍵、主題、字型設定、Vue 3、Pinia、marked.js、prism.js 和 Tauri 外掛。

這已經不是普通網頁 prompt，而是一個能測試桌面應用工程能力的規格。模型需要理解前端狀態、Tauri 外掛、檔案系統許可權、IPC 邊界和跨平臺打包。

為什麼這種倉庫有價值

Prompt-Vault 的價值不在於任務數量，而在於它給了可複用的評測樣本。

如果你在比較不同模型或 coding agent，可以用同一個 prompt 反覆測試：

哪個模型更能遵守約束
哪個模型更少漏功能
哪個模型更會處理邊界狀態
哪個模型生成的程式碼更容易維護
哪個模型更擅長 UI 細節
哪個模型在單檔案約束下更穩定

這比“我感覺這個模型更聰明”可靠得多。

尤其是前端任務，很多失敗不是語法錯誤，而是體驗細節缺失。比如按鈕能不能禁用、動畫是否卡住、重新整理後資料是否還在、拖拽目標是否高亮、統計是否同步更新。這些都需要具體 prompt 才能測出來。

可以怎麼擴充套件

如果要把 Prompt-Vault 變成更完整的評測庫，可以繼續補幾類任務。

第一類是驗收清單。每個 prompt 後面加一組 checklist，比如“重新整理後任務仍存在”“刪除空列成功，非空列不能刪除”“暫停排序後陣列狀態不變”。這樣人和 agent 都更容易驗收。

第二類是失敗用例。比如給排序視覺化任務補充“快速連續點選 Start / Reset 不應產生多個動畫迴圈”。這能測出狀態管理是否紮實。

第三類是評分維度。可以按功能完整度、程式碼可維護性、UI 質量、可訪問性、效能、邊界處理打分。

第四類是參考實現。不是為了讓模型抄答案，而是給評測者一個基準，方便判斷輸出是不是合理。

第五類是跨模型記錄。把不同模型在同一 prompt 下的結果、失敗點和 token 成本記錄下來，就能形成真正的 coding benchmark。

使用建議

如果你想用這個倉庫測試 AI 程式設計工具，建議不要只看“能不能生成頁面”。

更好的做法是：

選一個 prompt，原樣交給模型。
不做額外提示，看第一次輸出能完成多少。
開啟生成結果，按功能逐項驗收。
記錄漏掉的功能和明顯 bug。
再給一次修復機會。
比較總耗時、token 成本和最終程式碼質量。

這樣測出來的結果更接近真實開發。因為真正的 coding agent 不只是生成程式碼，還要理解規格、處理反饋、修復缺陷，並保持程式碼可維護。

小結

Prompt-Vault 是一個輕量級 prompt 規格庫。它適合拿來做 AI 程式設計測試，也適合前端開發者練習小專案。

它提醒我們：好的 prompt 不只是描述願望，而是寫清需求、約束、互動、狀態、驗收和執行方式。越是想測試模型能力，越不能只給一句模糊指令。

如果你正在比較 Codex、Claude Code、Cursor、Gemini CLI 或其他 coding agent，這類分級 prompt 很值得收藏。它們能幫你把“感覺好用”變成“具體哪裡做對了，哪裡漏了，修一次能不能補回來”。

Token Efficiency 是什麼？從 DeepSeek V4 看大模型規劃、小模型執行

Fri, 15 May 2026 08:59:33 +0800

AI 程式設計接下來真正重要的指標，可能不是“誰的模型最強”，而是誰能用更少的 token、更低的成本、更穩定的流程，完成更多可驗收的工作。

這就是 Token Efficiency 的價值。

很多人理解 Token Efficiency，只會想到模型便宜、上下文變長、快取命中更低價。但這些只是底層條件。真正能把它變成生產力的，是模型分工、任務編排、上下文預算和評估體系。

換句話說，Token Efficiency 不是省錢技巧，而是一套把 token 轉換成產出的工程方法。

DeepSeek V4 的定位：把大小模型分工產品化

這篇文章最應該先補上的背景，是 DeepSeek V4 的定位。

DeepSeek V4 不是單純釋出一個更強模型，而是把 Token Efficiency 需要的兩層能力直接拆成了 V4 Pro 和 V4 Flash：Pro 更適合做規劃、推理、架構判斷和關鍵審查，Flash 更適合做高頻執行、批次改寫、程式碼補全、資料整理和 agent 迴圈裡的普通節點。

這正好對應 AI 程式設計裡的兩個角色：

V4 Pro：當作 planner / consultant，用在需求拆解、技術方案、複雜 bug 根因、架構審查和最終驗收。
V4 Flash：當作 executor，用在檔案掃描、簡單實現、測試補齊、文件整理、候選方案生成和重複性任務。

DeepSeek 官方 API 文件顯示，V4 Flash 和 V4 Pro 都支援 1M 上下文、JSON Output、Tool Calls、Chat Prefix Completion 和 FIM Completion；價格頁也把快取命中輸入單獨計價，並說明全模型 input cache hit 價格已降到釋出價的十分之一。這幾個點組合起來，才是它和 Token Efficiency 關係最密的地方。

1M 上下文解決的是複雜 agent 任務容易被壓縮的問題；低快取命中價格解決的是長系統 prompt、專案文件、程式碼片段和歷史狀態反覆進入上下文的成本問題；Flash / Pro 雙模型形態解決的是“每一步都用旗艦模型太貴、每一步都用小模型又不穩”的分工問題。

所以 DeepSeek V4 的優勢不應該只寫成“便宜”或“上下文長”，而應該理解成三件事：

執行層便宜：大量 agent 節點可以交給 V4 Flash，讓 token 消耗落在低成本模型上。
判斷層可用：關鍵步驟仍然可以呼叫 V4 Pro，避免為了省錢犧牲複雜推理質量。
長鏈路友好：1M 上下文和快取價格讓程式碼庫、文件、工具呼叫歷史更容易留在可用視窗裡。

這就是為什麼 DeepSeek V4 對 AI 程式設計的意義，不只是又多了一個模型選項，而是給“顧問模型 + 執行模型 + harness 編排”的模式提供了更現實的成本結構。

不要讓最強模型幹所有活

過去使用 AI，常見做法是找一個最聰明的模型，讓它從需求分析、程式碼實現、測試、總結一路幹到底。

這個方式簡單，但不一定高效。因為很多工並不需要最高階別的推理能力。真正貴的模型，應該更像顧問、架構師或規劃員：只在關鍵決策點介入。

更合理的結構是：

大模型負責拆問題、定方向、做關鍵判斷。
小模型負責執行、批次處理、重複修改。
工具和 harness 負責流程、狀態、上下文和驗證。
人負責定義產品、驗收結果和決定取捨。

這樣做的好處是，前沿推理能力不會被浪費在機械執行上。大部分 token 消耗可以落到便宜模型和快取輸入裡，貴模型只處理真正需要“腦力”的部分。

上下文不是越大越好

長上下文很重要，尤其是 coding agent。程式碼、文件、歷史對話、測試輸出、錯誤日誌都會吃掉上下文。上下文一旦接近上限，模型就容易觸發壓縮、遺忘或誤判。

但長上下文不等於可以無限塞資料。

Token Efficiency 的關鍵，是讓每個任務都能在一個清晰、可控的上下文視窗內完成。最理想的狀態不是“把整個倉庫塞進去”，而是：

當前任務只帶必要檔案。
背景文件只帶決策相關部分。
歷史資訊只保留當前階段需要的狀態。
每個節點有明確輸入和輸出。
完成後把結果壓縮成結構化摘要，交給下一個節點。

上下文越便宜，越要警惕浪費。便宜 token 會誘導人把無關資訊全塞進去，最後模型不是更聰明，而是更容易被噪聲拖慢。

Harness 比單個模型更重要

如果只是把 Claude Code、Codex 或其他 coding agent 接到便宜模型上，效果未必好。小模型容易在長鏈路任務裡跑偏，需要更強的流程控制。

真正讓小模型發揮價值的，是 harness。

這裡的 harness 可以理解為一套排程系統：它知道任務怎麼拆、節點怎麼跑、模型怎麼選、結果怎麼驗收、失敗怎麼重試、上下文怎麼傳遞。

一個可用的編排系統，至少要回答幾個問題：

哪些任務需要規劃？
哪些任務可以直接執行？
哪些節點可以並行？
哪些節點必須序列？
哪個節點用大模型，哪個節點用小模型？
每個節點最多允許多少上下文？
每個節點完成後輸出什麼結構？
誰來 review，誰來決定是否繼續？

沒有這層軟體，小模型只是便宜；有了這層軟體，小模型才可能變成槓桿。

用 DAG 拆任務

一個有效的思路，是把複雜任務拆成有向無環圖，也就是 DAG。

比如一個功能開發任務，可以拆成：

需求澄清
方案設計
任務拆分
編碼實現
測試補齊
Code Review
修復問題
提交 PR

每個節點都可以是一個獨立 agent。它們執行在獨立環境裡，有自己的角色、prompt、工具許可權和輸出格式。節點之間不靠長篇聊天傳遞資訊，而是靠預先定義好的結構化結果。

這會帶來兩個直接收益。

第一，單個節點更短。任務越小，越容易被小模型完成，也越不容易撐爆上下文。

第二，流程更可測。你可以單獨觀察“編碼節點失敗率高”還是“review 節點漏問題多”，然後針對性最佳化。

任務可以跑多個副本

當 token 足夠便宜時，一個有趣的變化會出現：同一個任務不一定只跑一次。

你可以讓同一個任務用不同模型、不同 prompt、不同編排跑多個副本，再從結果裡選最好的，或者把多個結果合併。這個思路有點像“抽卡式任務解決”，但前提是必須有評估和驗收。

適合多副本的任務包括：

方案設計
文案生成
測試用例補全
Bug 根因假設
重構方案比較
Code Review

不適合盲目多副本的任務，是那些會直接修改共享狀態、會產生外部副作用、或者驗收標準不清楚的任務。

多跑幾次不是為了碰運氣，而是為了獲得可比較樣本。樣本越多，越能反過來最佳化編排、模型選擇和節點技能。

必須建立評估體系

Token Efficiency 不能只看價格。便宜但失敗率高，最後會吞掉人的時間，反而更貴。

所以每個團隊都應該逐步建立自己的評估體系。它不需要一開始就很複雜，但要能量化。

可以先記錄這些指標：

任務完成率
人工介入次數
工具呼叫失敗率
測試透過率
Review 發現的問題數量
單任務 token 成本
單任務耗時
返工次數
不同模型組合的差異

有了這些資料，才能知道哪些任務適合小模型，哪些任務必須上大模型，哪些任務應該交給人判斷。

真正的最佳化不是“所有地方都換便宜模型”，而是把每類任務放到最合適的模型和流程裡。

業務流程要原子化

普通使用者不一定要自己寫完整 harness。未來這類工具會越來越多，也會越來越成熟。

但現在就可以做一件事：把自己的業務流程拆成原子節點。

比如內容生產可以拆成：

選題
資料收集
提綱
初稿
事實核查
風格改寫
SEO 標題
多語言翻譯
釋出檢查

軟體開發可以拆成：

需求確認
技術方案
資料結構
介面變更
單元測試
實現
遷移指令碼
文件
Review

每個節點都要儘量做到輸入明確、輸出明確、驗收明確、上下文可控。這樣等 harness 工具成熟時，你的業務流程可以直接接進去。

硬體不是第一優先順序

很多人聊 Token Efficiency，很快就會聊到本地部署和顯示卡。但對大多數人來說，第一選擇仍然應該是 API。

原因很簡單：在沒有跑通經濟模型之前，本地硬體只是成本前置。你還不知道 token 怎麼轉化成收入或生產力，就先買昂貴裝置，很容易變成玩具。

更穩的順序是：

先用 API 跑通業務流程。
建立任務評估和成本統計。
找到穩定高頻的執行節點。
再考慮哪些節點值得本地化。
最後再計算硬體、電費、維護和折舊。

如果只是個人提效，API 往往已經夠用。如果是創業團隊，要驗證模型邊界和推理框架，本地 CUDA 平臺才更有學習價值。如果已經有明確生產場景和經濟模型，多卡部署才有討論空間。

小結

Token Efficiency 的本質，不是“用便宜模型替代貴模型”，而是重新設計 AI 工作流。

大模型負責關鍵判斷，小模型負責批次執行，harness 負責排程和驗證，人負責定義目標和驗收結果。只有這四層配合起來，token 才能穩定變成生產力。

接下來真正有價值的能力，不只是會用最新模型，而是能把任務拆小、把上下文控住、把結果量化、把流程編排起來。

模型會繼續降價，上下文會繼續變長，小模型會繼續變強。越是這樣，越應該早點理解 Token Efficiency。因為未來的差距，很可能不在誰呼叫了最強模型，而在誰能用同樣的 token 撬動更多真實產出。

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 編程工具才真的會變成生產力，而不是一個漂亮但昂貴的玩具。

ProgramBench 原始榜單資料：模型成績、成本與 200 個任務記錄

Sun, 10 May 2026 12:42:41 +0800

ProgramBench 是一個面向 AI 編程能力的新基準。它評估的不是「在現有倉庫裡修一個 bug」，而是讓模型根據已編譯的可執行檔和使用文件，從零重建一個行為一致的程式。

這篇文章只做資料整理和簡要說明。下面表格保留 ProgramBench 官網公開頁面中的原始記錄資料，方便後續引用和對比。資料來源包括 ProgramBench 首頁、Extended Results 和 Task Instances，抓取時間為 2026-05-10T12:42:41+08:00。

資料口徑

Resolved：完全通過隱藏行為測試的任務比例。
Almost resolved：通過不少於 95% 行為測試的任務比例。
Cost：每個任務實例的平均 API 成本，單位為美元。
Calls：每個任務實例平均呼叫 LLM 的次數。
所有模型都使用 mini-SWE-agent 評測，任務總數為 200。

主榜單

#	Model	Provider	Agent	Resolved	Almost resolved	Run
1	Claude Opus 4.7	Anthropic	mini-SWE-agent	0%	3.0%	https://programbench.com/run/claude-opus-4-7/
2	Claude Opus 4.6	Anthropic	mini-SWE-agent	0%	2.5%	https://programbench.com/run/claude-opus-4-6/
3	Claude Sonnet 4.6	Anthropic	mini-SWE-agent	0%	1.0%	https://programbench.com/run/claude-sonnet-4-6/
4	GPT 5.4	OpenAI	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gpt-5-4/
5	Gemini 3.1 Pro	Google	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gemini-3-1-pro/
6	Gemini 3 Flash	Google	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gemini-3-flash/
7	Claude Haiku 4.5	Anthropic	mini-SWE-agent	0%	0.0%	https://programbench.com/run/claude-haiku-4-5/
8	GPT 5.4 mini	OpenAI	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gpt-5-4-mini/
9	GPT 5 mini	OpenAI	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gpt-5-mini/

擴展結果

#	Model	Provider	Agent	Resolved	Almost resolved	Cost	Calls	Run
1	Claude Opus 4.7	Anthropic	mini-SWE-agent	0%	3.0%	$3.81	93	https://programbench.com/run/claude-opus-4-7/
2	Claude Opus 4.6	Anthropic	mini-SWE-agent	0%	2.5%	$11.38	260	https://programbench.com/run/claude-opus-4-6/
3	Claude Sonnet 4.6	Anthropic	mini-SWE-agent	0%	1.0%	$26.73	472	https://programbench.com/run/claude-sonnet-4-6/
4	GPT 5.4	OpenAI	mini-SWE-agent	0%	0.0%	$0.33	16	https://programbench.com/run/gpt-5-4/
5	Gemini 3.1 Pro	Google	mini-SWE-agent	0%	0.0%	$1.51	94	https://programbench.com/run/gemini-3-1-pro/
6	Gemini 3 Flash	Google	mini-SWE-agent	0%	0.0%	$0.30	85	https://programbench.com/run/gemini-3-flash/
7	Claude Haiku 4.5	Anthropic	mini-SWE-agent	0%	0.0%	$0.80	124	https://programbench.com/run/claude-haiku-4-5/
8	GPT 5.4 mini	OpenAI	mini-SWE-agent	0%	0.0%	$0.04	18	https://programbench.com/run/gpt-5-4-mini/
9	GPT 5 mini	OpenAI	mini-SWE-agent	0%	0.0%	$0.03	15	https://programbench.com/run/gpt-5-mini/

200 個任務實例原始記錄

#	Repository	Description	Lang	Stars	Tests	Best Score	Task
1	junegunn/fzf	:cherry_blossom: A command-line fuzzy finder	go	79,721	1,874	81.9%	https://programbench.com/task/junegunn__fzf.b56d614/
2	jesseduffield/lazygit	simple terminal UI for git commands	go	76,901	855	56.4%	https://programbench.com/task/jesseduffield__lazygit.1d0db51/
3	BurntSushi/ripgrep	ripgrep recursively searches directories for a regex pattern while respecting your gitignore	rs	62,855	1,994	79.7%	https://programbench.com/task/burntsushi__ripgrep.3b7fd44/
4	FFmpeg/FFmpeg	Mirror of https://git.ffmpeg.org/ffmpeg.git	c	59,217	3,050	5.3%	https://programbench.com/task/ffmpeg__ffmpeg.360a402/
5	sharkdp/bat	A cat(1) clone with wings.	rs	58,487	801	33.2%	https://programbench.com/task/sharkdp__bat.f822bd0/
6	typst/typst	A markup-based typesetting system that is powerful and easy to learn.	rs	52,957	1,724	28.0%	https://programbench.com/task/typst__typst.88356d0/
7	jgm/pandoc	Universal markup converter	hs	43,632	5,228	14.1%	https://programbench.com/task/jgm__pandoc.5caad90/
8	sharkdp/fd	A simple, fast and user-friendly alternative to ‘find’	rs	42,668	1,235	78.1%	https://programbench.com/task/sharkdp__fd.40d8eb3/
9	php/php-src	The PHP Interpreter	c	40,030	14,288	4.8%	https://programbench.com/task/php__php-src.c891263/
10	duckdb/duckdb	DuckDB is an analytical in-process SQL database management system	cpp	37,657	5,650	12.4%	https://programbench.com/task/duckdb__duckdb.bdb65ec/
11	ajeetdsouza/zoxide	A smarter cd command. Supports all major shells.	rs	35,994	531	76.5%	https://programbench.com/task/ajeetdsouza__zoxide.67ca1bc/
12	jqlang/jq	Command-line JSON processor	c	34,541	6,072	89.9%	https://programbench.com/task/jqlang__jq.b33a763/
13	dandavison/delta	A syntax-highlighting pager for git, diff, grep, rg –json, and blame output	rs	30,445	950	37.3%	https://programbench.com/task/dandavison__delta.acd758f/
14	sharkdp/hyperfine	A command-line benchmarking tool	rs	27,960	291	54.3%	https://programbench.com/task/sharkdp__hyperfine.327d5f4/
15	ggreer/the_silver_searcher	A code-searching tool similar to ack, but faster.	c	27,080	1,006	59.3%	https://programbench.com/task/ggreer__the_silver_searcher.a61f178/
16	facebook/zstd	Zstandard - Fast real-time compression algorithm	c	27,013	2,038	68.8%	https://programbench.com/task/facebook__zstd.1168da0/
17	facebookresearch/fastText	Library for fast text representation and classification.	cpp	26,511	312	75.6%	https://programbench.com/task/facebookresearch__fasttext.1142dc4/
18	robertdavidgraham/masscan	TCP port scanner, spews SYN packets asynchronously, scanning entire Internet in under 5 minutes.	c	25,544	2,549	57.0%	https://programbench.com/task/robertdavidgraham__masscan.b99d433/
19	tree-sitter/tree-sitter	An incremental parsing system for programming tools	rs	24,953	1,232	37.2%	https://programbench.com/task/tree-sitter__tree-sitter.5e23cca/
20	FiloSottile/age	A simple, modern and secure encryption tool (and Go library) with small explicit keys, no config options, and UNIX-style composability.	go	22,077	676	63.5%	https://programbench.com/task/filosottile__age.706dfc1/
21	rust-lang/mdBook	Create book from markdown files. Like Gitbook but implemented in Rust	rs	21,541	1,114	55.5%	https://programbench.com/task/rust-lang__mdbook.37273ba/
22	jarun/nnn	n³ The unorthodox terminal file manager	c	21,506	477	98.1%	https://programbench.com/task/jarun__nnn.cb2c535/
23	antonmedv/fx	Terminal JSON viewer & processor	go	20,433	2,047	75.7%	https://programbench.com/task/antonmedv__fx.86d0d34/
24	mikefarah/yq	yq is a portable command-line YAML, JSON, XML, CSV, TOML, HCL and properties processor	go	15,281	2,000	39.5%	https://programbench.com/task/mikefarah__yq.602586d/
25	Y2Z/monolith	⬛️ CLI tool and library for saving complete web pages as a single HTML file	rs	15,024	713	51.2%	https://programbench.com/task/y2z__monolith.8702e66/
26	direnv/direnv	unclutter your .profile	go	14,998	849	62.0%	https://programbench.com/task/direnv__direnv.02040c7/
27	google/brotli	Brotli compression format	c	14,673	441	90.7%	https://programbench.com/task/google__brotli.b3dc9cc/
28	tomnomnom/gron	Make JSON greppable!	go	14,424	224	90.2%	https://programbench.com/task/tomnomnom__gron.88a6234/
29	XAMPPRocky/tokei	Count your code, quickly.	rs	14,300	732	69.5%	https://programbench.com/task/xampprocky__tokei.505d648/
30	ast-grep/ast-grep	⚡A CLI tool for code structural search, lint and rewriting. Written in Rust	rs	13,541	882	11.9%	https://programbench.com/task/ast-grep__ast-grep.dde0fe0/
31	cheat/cheat	cheat allows you to create and view interactive cheatsheets on the command-line. It was designed to help remind *nix system administrators of options for commands that they use frequently, but not frequently enough to remember.	go	13,278	297	59.9%	https://programbench.com/task/cheat__cheat.b8098dc/
32	jonas/tig	Text-mode interface for git	c	13,200	1,586	83.9%	https://programbench.com/task/jonas__tig.8334123/
33	ninja-build/ninja	a small build system with a focus on speed	cpp	12,895	1,438	72.3%	https://programbench.com/task/ninja-build__ninja.cc60300/
34	Canop/broot	A new way to see and navigate directory trees : https://dystroy.org/broot	rs	12,619	539	67.0%	https://programbench.com/task/canop__broot.d6c798e/
35	orf/gping	Ping, but with a graph	rs	12,433	339	78.5%	https://programbench.com/task/orf__gping.26eb5b9/
36	svenstaro/genact	🌀 A nonsense activity generator	rs	11,995	232	59.1%	https://programbench.com/task/svenstaro__genact.16f96e3/
37	lz4/lz4	Extremely Fast Compression algorithm	c	11,781	1,496	82.7%	https://programbench.com/task/lz4__lz4.1519f46/
38	o2sh/onefetch	Command-line Git information tool	rs	11,745	1,166	81.7%	https://programbench.com/task/o2sh__onefetch.e5958ce/
39	bootandy/dust	A more intuitive version of du in rust	rs	11,609	584	70.9%	https://programbench.com/task/bootandy__dust.62bf1e1/
40	ekzhang/bore	🕳 bore is a simple CLI tool for making tunnels to localhost	rs	11,075	406	68.7%	https://programbench.com/task/ekzhang__bore.8e059cd/
41	BurntSushi/xsv	A fast CSV command line toolkit written in Rust.	rs	10,757	1,182	82.7%	https://programbench.com/task/burntsushi__xsv.f430466/
42	bellard/quickjs	Public repository of the QuickJS Javascript Engine.	c	10,565	3,034	3.6%	https://programbench.com/task/bellard__quickjs.d7ae12a/
43	hatoo/oha	Ohayou(おはよう), HTTP load generator, inspired by rakyll/hey with tui animation.	rs	10,201	899	72.5%	https://programbench.com/task/hatoo__oha.8dc6349/
44	tstack/lnav	Log file navigator	cpp	10,200	990	13.4%	https://programbench.com/task/tstack__lnav.ee34494/
45	sharkdp/hexyl	A command-line hex viewer	rs	10,086	906	82.8%	https://programbench.com/task/sharkdp__hexyl.2e26437/
46	lua/lua	A copy of the Lua development repository, as seen by the Lua team. Mirrored irregularly. All communication should be through the Lua mailing list https://www.lua.org/lua-l.html	c	9,908	1,338	43.1%	https://programbench.com/task/lua__lua.c6b4848/
47	johnkerl/miller	Miller is like awk, sed, cut, join, and sort for name-indexed data such as CSV, TSV, and tabular JSON	go	9,842	14,637	22.9%	https://programbench.com/task/johnkerl__miller.8d85b46/
48	sqlite/sqlite	Official Git mirror of the SQLite source tree	c	9,434	13,514	67.0%	https://programbench.com/task/sqlite__sqlite.839433d/
49	boyter/scc	Sloc, Cloc and Code: scc is a very fast accurate code counter with complexity calculations and COCOMO estimates written in pure Go	go	8,320	464	37.7%	https://programbench.com/task/boyter__scc.515f91c/
50	ariga/atlas	Declarative schema migrations with schema-as-code workflows	go	8,311	1,318	54.8%	https://programbench.com/task/ariga__atlas.6d81150/
51	pemistahl/grex	A command-line tool and Rust library with Python bindings for generating regular expressions from user-provided test cases	rs	8,103	1,312	73.9%	https://programbench.com/task/pemistahl__grex.fa3e8ed/
52	htop-dev/htop	htop - an interactive process viewer	c	8,021	693	85.1%	https://programbench.com/task/htop-dev__htop.523600b/
53	peco/peco	Simplistic interactive filtering tool	go	7,881	1,224	76.7%	https://programbench.com/task/peco__peco.4e58dad/
54	bensadeh/tailspin	🌀 A log file highlighter	rs	7,793	615	75.8%	https://programbench.com/task/bensadeh__tailspin.6278437/
55	ducaale/xh	Friendly and fast tool for sending HTTP requests	rs	7,754	1,171	50.0%	https://programbench.com/task/ducaale__xh.4a6e44f/
56	svenstaro/miniserve	🌟 For when you really just want to serve some files over HTTP right now!	rs	7,561	304	78.6%	https://programbench.com/task/svenstaro__miniserve.8449e8b/
57	mgdm/htmlq	Like jq, but for HTML.	rs	7,520	1,455	93.9%	https://programbench.com/task/mgdm__htmlq.6e31bc8/
58	parcel-bundler/lightningcss	An extremely fast CSS parser, transformer, bundler, and minifier written in Rust.	rs	7,515	2,828	53.6%	https://programbench.com/task/parcel-bundler__lightningcss.aa2ed1e/
59	universal-ctags/ctags	A maintained ctags implementation	c	7,149	2,258	13.3%	https://programbench.com/task/universal-ctags__ctags.243595e/
60	chmln/sd	Intuitive find & replace CLI (sed alternative)	rs	7,072	810	90.9%	https://programbench.com/task/chmln__sd.87d1ba5/
61	ogham/dog	A command-line DNS client.	rs	6,640	1,300	84.2%	https://programbench.com/task/ogham__dog.721440b/
62	danmar/cppcheck	static analysis of C/C++ code	cpp	6,599	2,126	14.6%	https://programbench.com/task/danmar__cppcheck.0a5b103/
63	doxygen/doxygen	Official doxygen git repository	c	6,422	229	34.5%	https://programbench.com/task/doxygen__doxygen.966d98e/
64	sharkdp/pastel	A command-line tool to generate, analyze, convert and manipulate colors	rs	6,334	1,114	77.2%	https://programbench.com/task/sharkdp__pastel.b60e899/
65	BLAKE3-team/BLAKE3	the official Rust and C implementations of the BLAKE3 cryptographic hash function	rs	6,178	647	97.5%	https://programbench.com/task/blake3-team__blake3.15e83a5/
66	Nukesor/pueue	:stars: Manage your shell commands.	rs	6,154	638	15.4%	https://programbench.com/task/nukesor__pueue.8b9d6fe/
67	OSGeo/gdal	GDAL is an open source MIT licensed translator library for raster and vector geospatial data formats.	cpp	5,875	657	25.4%	https://programbench.com/task/osgeo__gdal.0847f12/
68	Byron/dua-cli	View disk space usage and delete unwanted data, fast.	rs	5,794	709	86.9%	https://programbench.com/task/byron__dua-cli.8570c15/
69	dundee/gdu	Fast disk usage analyzer with console interface written in Go	go	5,578	1,161	70.1%	https://programbench.com/task/dundee__gdu.ede21d2/
70	eradman/entr	Run arbitrary commands when files change	c	5,551	586	88.6%	https://programbench.com/task/eradman__entr.8e2e8b4/
71	LuaJIT/LuaJIT	Mirror of the LuaJIT git repository	c	5,518	2,967	71.5%	https://programbench.com/task/luajit__luajit.a553b3d/
72	mgechev/revive	🔥 ~6x faster, stricter, configurable, extensible, and beautiful drop-in replacement for golint	go	5,486	727	46.4%	https://programbench.com/task/mgechev__revive.201451e/
73	cweill/gotests	Automatically generate Go test boilerplate from your source code.	go	5,294	603	61.9%	https://programbench.com/task/cweill__gotests.2a672c5/
74	cordx56/rustowl	Visualize Ownership and Lifetimes in Rust	rs	5,113	589	75.2%	https://programbench.com/task/cordx56__rustowl.655bc5c/
75	abishekvashok/cmatrix	Terminal based “The Matrix” like implementation	c	5,042	508	97.0%	https://programbench.com/task/abishekvashok__cmatrix.5c082c6/
76	quinn-rs/quinn	Async-friendly QUIC implementation in Rust	rs	5,041	522	61.7%	https://programbench.com/task/quinn-rs__quinn.bb359cc/
77	alecthomas/chroma	A general purpose syntax highlighter in pure Go	go	4,910	515	15.9%	https://programbench.com/task/alecthomas__chroma.8d04def/
78	anordal/shellharden	The corrective bash syntax highlighter	rs	4,778	1,095	81.7%	https://programbench.com/task/anordal__shellharden.6a6ffd4/
79	yoav-lavi/melody	Melody is a language that compiles to regular expressions and aims to be more readable and maintainable	rs	4,748	1,205	78.9%	https://programbench.com/task/yoav-lavi__melody.f4af9b4/
80	sayanarijit/xplr	A hackable, minimal, fast TUI file explorer	rs	4,735	463	60.5%	https://programbench.com/task/sayanarijit__xplr.1751065/
81	hpjansson/chafa	📺🗿 Terminal graphics for the 21st century.	c	4,648	1,931	58.4%	https://programbench.com/task/hpjansson__chafa.dd4d4c1/
82	jhspetersson/fselect	Find files with SQL-like queries	rs	4,420	3,115	44.0%	https://programbench.com/task/jhspetersson__fselect.c3559ca/
83	ivanceras/svgbob	Convert your ascii diagram scribbles into happy little SVG	rs	4,182	472	41.3%	https://programbench.com/task/ivanceras__svgbob.6d00ad9/
84	multiprocessio/dsq	Commandline tool for running SQL queries against JSON, CSV, Excel, Parquet, and more.	go	3,867	542	80.3%	https://programbench.com/task/multiprocessio__dsq.c3ae0ba/
85	rcoh/angle-grinder	Slice and dice logs on the command line	rs	3,727	1,130	38.0%	https://programbench.com/task/rcoh__angle-grinder.9c2fc88/
86	rs/curlie	The power of curl, the ease of use of httpie.	go	3,637	701	89.3%	https://programbench.com/task/rs__curlie.5dfcbb1/
87	antonmedv/walk	Terminal file manager	go	3,598	470	74.3%	https://programbench.com/task/antonmedv__walk.bf802ef/
88	JohannesKaufmann/html-to-markdown	⚙️ Convert HTML to Markdown. Even works with entire websites and can be extended through rules.	go	3,586	885	85.5%	https://programbench.com/task/johanneskaufmann__html-to-markdown.3006818/
89	TheZoraiz/ascii-image-converter	A cross-platform command-line tool to convert images into ascii art and print them on the console. Now supports braille art!	go	3,284	465	64.1%	https://programbench.com/task/thezoraiz__ascii-image-converter.d05a757/
90	hairyhenderson/gomplate	A flexible commandline tool for template rendering. Supports lots of local and remote datasources.	go	3,135	2,926	74.7%	https://programbench.com/task/hairyhenderson__gomplate.05eb3aa/
91	ip7z/7zip	7-Zip	cpp	2,967	1,043	33.9%	https://programbench.com/task/ip7z__7zip.839151e/
92	madler/pigz	A parallel implementation of gzip for modern multi-processor, multi-core machines.	c	2,924	831	83.2%	https://programbench.com/task/madler__pigz.fe4894f/
93	tinycc/tinycc	Unofficial mirror of mob development branch	c	2,843	1,978	12.8%	https://programbench.com/task/tinycc__tinycc.9b8765d/
94	raviqqe/muffet	Fast website link checker in Go	go	2,597	293	88.1%	https://programbench.com/task/raviqqe__muffet.a882908/
95	segmentio/chamber	CLI for managing secrets	go	2,588	1,748	82.0%	https://programbench.com/task/segmentio__chamber.5f93f5f/
96	astaxie/bat	Go implement CLI, cURL-like tool for humans	go	2,563	1,091	71.8%	https://programbench.com/task/astaxie__bat.17d1080/
97	zk-org/zk	Plain text note-taking assistant	go	2,542	1,108	43.1%	https://programbench.com/task/zk-org__zk.10d93d5/
98	kisielk/errcheck	errcheck checks that you checked errors.	go	2,480	341	80.4%	https://programbench.com/task/kisielk__errcheck.dacab89/
99	mkj/dropbear	Dropbear SSH	c	2,231	682	58.1%	https://programbench.com/task/mkj__dropbear.75f699b/
100	noborus/trdsql	CLI tool that can execute SQL queries on CSV, LTSV, JSON, YAML and TBLN. Can output to various formats.	go	2,159	1,312	66.8%	https://programbench.com/task/noborus__trdsql.d8c5ff6/
101	sheepla/pingu	🐧ping command but with pingu	go	2,087	383	96.6%	https://programbench.com/task/sheepla__pingu.926d475/
102	go-critic/go-critic	The most opinionated Go source code linter for code audit.	go	2,041	493	41.6%	https://programbench.com/task/go-critic__go-critic.9aea378/
103	OSGeo/PROJ	PROJ - Cartographic Projections and Coordinate Transformations Library	cpp	1,974	5,319	73.8%	https://programbench.com/task/osgeo__proj.75d455c/
104	noborus/ov	🎑Feature-rich terminal-based text viewer. It is a so-called terminal pager.	go	1,935	1,854	87.6%	https://programbench.com/task/noborus__ov.b96c2ba/
105	samtools/samtools	Tools (written in C using htslib) for manipulating next-generation sequencing data	c	1,886	1,425	14.2%	https://programbench.com/task/samtools__samtools.aa823b5/
106	gabotechs/dep-tree	Tool for helping developers keep their code bases clean and decoupled. It allows visualising a code base complexity using a 3d force-directed graph of files and the dependencies between them.	go	1,706	865	65.2%	https://programbench.com/task/gabotechs__dep-tree.60a95a2/
107	cmatsuoka/figlet	Claudio’s FIGlet tree	c	1,606	872	77.5%	https://programbench.com/task/cmatsuoka__figlet.202a0a8/
108	lh3/seqtk	Toolkit for processing sequences in FASTA/Q formats	c	1,537	429	67.4%	https://programbench.com/task/lh3__seqtk.94e7070/
109	tukaani-project/xz	XZ Utils	c	1,522	1,410	36.0%	https://programbench.com/task/tukaani-project__xz.1007bf0/
110	skeema/skeema	Declarative pure-SQL schema management for MySQL and MariaDB	go	1,361	1,708	76.5%	https://programbench.com/task/skeema__skeema.6a76243/
111	mfridman/tparse	CLI tool for summarizing go test output. Pipe friendly. CI/CD friendly.	go	1,246	425	77.6%	https://programbench.com/task/mfridman__tparse.2416b4b/
112	lfos/calcurse	A text-based calendar and scheduling application	c	1,243	666	53.8%	https://programbench.com/task/lfos__calcurse.49180d5/
113	hooklift/gowsdl	WSDL2Go code generation as well as its SOAP proxy	go	1,219	391	86.4%	https://programbench.com/task/hooklift__gowsdl.2a06cec/
114	guumaster/hostctl	Your dev tool to manage /etc/hosts like a pro!	go	1,216	1,051	82.8%	https://programbench.com/task/guumaster__hostctl.d6d9699/
115	rs/jplot	iTerm2 expvar/JSON monitoring tool	go	1,178	583	89.0%	https://programbench.com/task/rs__jplot.2a54bcc/
116	naggie/dstask	Git powered terminal-based todo/note manager – markdown note page per task. Single binary!	go	1,157	1,278	58.8%	https://programbench.com/task/naggie__dstask.ff57396/
117	sigoden/argc	A Bash CLI framework, also a Bash command runner.	rs	1,135	995	44.1%	https://programbench.com/task/sigoden__argc.04a08f1/
118	sibprogrammer/xq	Command-line XML and HTML beautifier and content extractor	go	1,109	792	75.9%	https://programbench.com/task/sibprogrammer__xq.b89f681/
119	xorg62/tty-clock	Clock using lib ncurses	c	1,105	281	84.0%	https://programbench.com/task/xorg62__tty-clock.f2f847c/
120	unhappychoice/gittype	A CLI code-typing game that turns your source code into typing challenges	rs	1,075	741	91.3%	https://programbench.com/task/unhappychoice__gittype.34b72d0/
121	eudoxia0/hashcards	A plain text-based spaced repetition system.	rs	1,071	1,151	56.3%	https://programbench.com/task/eudoxia0__hashcards.48aa136/
122	rvben/rumdl	Fast Markdown linter and formatter written in Rust	rs	1,051	3,322	40.7%	https://programbench.com/task/rvben__rumdl.2d75c4d/
123	sclevine/yj	CLI - Convert between YAML, TOML, JSON, and HCL. Preserves map order.	go	1,041	767	74.4%	https://programbench.com/task/sclevine__yj.8016400/
124	arq5x/bedtools2	bedtools - the swiss army knife for genome arithmetic	c	1,029	1,053	38.9%	https://programbench.com/task/arq5x__bedtools2.dd57059/
125	cslarsen/jp2a	Converts jpg images to ASCII	c	1,021	631	56.1%	https://programbench.com/task/cslarsen__jp2a.61d205f/
126	blacknon/hwatch	A modern alternative to the watch command, records the differences in execution results and can check this differences at after.	rs	1,016	1,016	81.1%	https://programbench.com/task/blacknon__hwatch.edfcb62/
127	eliukblau/pixterm	Draw images in your ANSI terminal with true color	go	1,014	430	74.9%	https://programbench.com/task/eliukblau__pixterm.1a93fd5/
128	Canop/rhit	A nginx log explorer	rs	1,006	817	53.2%	https://programbench.com/task/canop__rhit.ae90bcb/
129	stathissideris/ditaa	ditaa is a small command-line utility that can convert diagrams drawn using ascii art (‘drawings’ that contain characters that resemble lines like \| / - ), into proper bitmap graphics.	java	1,005	609	20.4%	https://programbench.com/task/stathissideris__ditaa.f2286c4/
130	rbakbashev/elfcat	ELF visualizer. Generates HTML files from ELF binaries.	rs	990	564	98.2%	https://programbench.com/task/rbakbashev__elfcat.52f8cc7/
131	nuta/nsh	A command-line shell like fish, but POSIX compatible.	rs	966	1,963	83.7%	https://programbench.com/task/nuta__nsh.bdd0702/
132	dalance/amber	A code search / replace tool	rs	941	567	71.1%	https://programbench.com/task/dalance__amber.69a0f52/
133	pls-rs/pls	pls is a prettier and powerful ls(1) for the pros.	rs	932	332	62.3%	https://programbench.com/task/pls-rs__pls.4e1ae50/
134	Esubaalew/run	Universal multi-language runner and smart REPL written in Rust.	rs	919	1,212	85.2%	https://programbench.com/task/esubaalew__run.0fb9dec/
135	chirlu/sox	SoX, Swiss Army knife of sound processing	c	913	1,202	37.9%	https://programbench.com/task/chirlu__sox.42b3557/
136	clog-tool/clog-cli	Generate beautiful changelogs from your Git commit history	rs	912	575	93.0%	https://programbench.com/task/clog-tool__clog-cli.7066cba/
137	tarka/xcp	An extended `cp`	rs	911	1,184	92.6%	https://programbench.com/task/tarka__xcp.5e5b448/
138	oppiliappan/eva	a calculator REPL, similar to bc(1)	rs	907	913	88.7%	https://programbench.com/task/oppiliappan__eva.41ae245/
139	git-bahn/git-graph	Command line tool to show clear git graphs arranged for your branching model	rs	904	568	79.6%	https://programbench.com/task/git-bahn__git-graph.87b4473/
140	gromacs/gromacs	Public/backup repository of the GROMACS molecular simulation toolkit. Please do not mine the metadata blindly; we use https://gitlab.com/gromacs/gromacs for code review and issue tracking.	cpp	901	1,245	9.3%	https://programbench.com/task/gromacs__gromacs.665ea4c/
141	sirwart/ripsecrets	A command-line tool to prevent committing secret keys into your source code	rs	901	611	72.8%	https://programbench.com/task/sirwart__ripsecrets.34c9e03/
142	Drew-Alleman/DataSurgeon	Quickly Extracts IP’s, Email Addresses, Hashes, Files, Credit Cards, Social Security Numbers and a lot More From Text	rs	890	502	74.3%	https://programbench.com/task/drew-alleman__datasurgeon.d257cee/
143	alexpovel/srgn	A grep-like tool which understands source code syntax and allows for manipulation in addition to search	rs	889	1,852	69.5%	https://programbench.com/task/alexpovel__srgn.89f943b/
144	kyoheiu/felix	tui file manager with vim-like key mapping	rs	888	502	49.2%	https://programbench.com/task/kyoheiu__felix.95df390/
145	oppiliappan/statix	lints and suggestions for the nix programming language	rs	882	815	42.8%	https://programbench.com/task/oppiliappan__statix.e9df54c/
146	nachoparker/dutree	a tool to analyze file system usage written in Rust	rs	871	641	89.5%	https://programbench.com/task/nachoparker__dutree.44e877d/
147	simeg/eureka	💡 CLI tool to input and store your ideas without leaving the terminal	rs	867	344	78.8%	https://programbench.com/task/simeg__eureka.df3796c/
148	kyoh86/richgo	Enrich `go test` outputs with text decorations.	go	863	546	85.0%	https://programbench.com/task/kyoh86__richgo.313114f/
149	rochacbruno/marmite	Markdown makes sites - A Static Site Generator for Blogs	rs	837	668	45.4%	https://programbench.com/task/rochacbruno__marmite.7d4bc2d/
150	rust-embedded/svd2rust	Generate Rust register maps (`struct`s) from SVD files	rs	835	920	72.9%	https://programbench.com/task/rust-embedded__svd2rust.1760b5e/
151	konradsz/igrep	Interactive Grep	rs	827	385	73.5%	https://programbench.com/task/konradsz__igrep.aa75630/
152	nikolassv/bartib	A simple timetracker for the command line. It saves a log of all tracked activities as a plaintext file and allows you to create flexible reports.	rs	827	722	87.3%	https://programbench.com/task/nikolassv__bartib.6b9b5ce/
153	yassinebridi/serpl	A simple terminal UI for search and replace, ala VS Code.	rs	824	446	61.0%	https://programbench.com/task/yassinebridi__serpl.c48a9d7/
154	riquito/tuc	When cut doesn’t cut it	rs	820	1,196	92.7%	https://programbench.com/task/riquito__tuc.16fb471/
155	ecumene/rust-sloth	A 3D software rasterizer… for the terminal!	rs	818	380	52.6%	https://programbench.com/task/ecumene__rust-sloth.051c559/
156	crowdagger/crowbook	Converts books written in Markdown to HTML, LaTeX/PDF and EPUB	rs	813	807	60.3%	https://programbench.com/task/crowdagger__crowbook.ea214d7/
157	WGUNDERWOOD/tex-fmt	An extremely fast LaTeX formatter written in Rust	rs	789	455	80.7%	https://programbench.com/task/wgunderwood__tex-fmt.3f1aef6/
158	Stranger6667/jsonschema	A high-performance JSON Schema validator for Rust	rs	770	2,933	51.7%	https://programbench.com/task/stranger6667__jsonschema.d52e881/
159	rhysd/kiro-editor	A small terminal UTF-8 text editor written in Rust 📝🦀	rs	761	595	93.3%	https://programbench.com/task/rhysd__kiro-editor.4157485/
160	astro/deadnix	Scan Nix files for dead code	rs	745	602	85.5%	https://programbench.com/task/astro__deadnix.d590041/
161	sstadick/hck	A sharp cut(1) clone.	rs	738	855	95.7%	https://programbench.com/task/sstadick__hck.b66c751/
162	trasta298/keifu	Git genealogy, untangled. A TUI for navigating commit graphs with color and clarity.	rs	729	262	67.2%	https://programbench.com/task/trasta298__keifu.3331426/
163	AmmarAbouZor/tui-journal	Your journal app if you live in a terminal	rs	722	1,402	70.8%	https://programbench.com/task/ammarabouzor__tui-journal.2b4540d/
164	incu6us/goimports-reviser	Right imports sorting & code formatting tool (goimports alternative)	go	715	513	86.4%	https://programbench.com/task/incu6us__goimports-reviser.81bd549/
165	yaa110/nomino	Batch rename utility for developers	rs	710	313	79.9%	https://programbench.com/task/yaa110__nomino.f892499/
166	wfxr/csview	📠 Pretty and fast csv viewer for cli with cjk/emoji support.	rs	694	335	96.1%	https://programbench.com/task/wfxr__csview.8ac4de0/
167	chmln/handlr	A better xdg-utils	rs	693	722	90.7%	https://programbench.com/task/chmln__handlr.90e78ba/
168	Miserlou/Loop	UNIX’s missing `loop` command	rs	692	710	94.6%	https://programbench.com/task/miserlou__loop.209927c/
169	KSXGitHub/parallel-disk-usage	Highly parallelized, blazing fast directory tree analyzer	rs	689	531	86.1%	https://programbench.com/task/ksxgithub__parallel-disk-usage.96978ed/
170	hush-shell/hush	Hush is a unix shell based on the Lua programming language	rs	688	1,201	83.3%	https://programbench.com/task/hush-shell__hush.560c33a/
171	zevv/duc	Dude, where are my bytes: Duc, a library and suite of tools for inspecting disk usage	c	682	874	83.4%	https://programbench.com/task/zevv__duc.a58fa4e/
172	altdesktop/i3-style	🎨 Make your i3 config a little more stylish.	rs	678	539	80.0%	https://programbench.com/task/altdesktop__i3-style.f93821b/
173	wintermute-cell/ngrrram	A TUI tool to help you type faster and learn new layouts. Includes a free cat.	rs	674	303	84.5%	https://programbench.com/task/wintermute-cell__ngrrram.8ea13c3/
174	psampaz/go-mod-outdated	Find outdated dependencies of your Go projects. go-mod-outdated provides a table view of the go list -u -m -json all command which lists all dependencies of a Go project and their available minor and patch updates. It also provides a way to filter indirect dependencies and dependencies without updates.	go	669	285	98.2%	https://programbench.com/task/psampaz__go-mod-outdated.bb79367/
175	wfxr/code-minimap	🛰 A high performance code minimap render.	rs	660	313	88.8%	https://programbench.com/task/wfxr__code-minimap.0ddeea5/
176	kaushiksrini/parqeye	Peek inside Parquet files right from your terminal	rs	654	479	58.9%	https://programbench.com/task/kaushiksrini__parqeye.8072121/
177	stacked-git/stgit	Stacked Git	rs	652	1,488	20.0%	https://programbench.com/task/stacked-git__stgit.430027d/
178	Isona/dirble	Fast directory scanning and scraping tool	rs	632	718	66.7%	https://programbench.com/task/isona__dirble.e2dea9f/
179	YS-L/flamelens	Flamegraph viewer in the terminal	rs	622	224	59.4%	https://programbench.com/task/ys-l__flamelens.0b4dc33/
180	mookid/diffr	Yet another diff highlighting tool	rs	612	606	84.7%	https://programbench.com/task/mookid__diffr.2152742/
181	shashwatah/jot	⚡Rapid note management for the terminal.	rs	609	752	84.6%	https://programbench.com/task/shashwatah__jot.a92aad8/
182	Epistates/treemd	A (TUI/CLI) markdown navigator with tree-based structural navigation.	rs	603	1,569	55.1%	https://programbench.com/task/epistates__treemd.825c6dd/
183	pier-cli/pier	A CLI to organize and run short Unix shell scripts	rs	596	692	83.7%	https://programbench.com/task/pier-cli__pier.5e1bde9/
184	jrnxf/thokr	✨ sleek typing tui with visualized results and historical logging	rs	595	445	82.2%	https://programbench.com/task/jrnxf__thokr.09375ef/
185	ismaelgv/rnr	A command-line tool to batch rename files and directories	rs	581	683	82.1%	https://programbench.com/task/ismaelgv__rnr.fc0733b/
186	sitkevij/hex	🔮 Futuristic take on hexdump, made in Rust.	rs	563	823	91.7%	https://programbench.com/task/sitkevij__hex.61ae69b/
187	brocode/fblog	Small command-line JSON Log viewer	rs	561	978	86.0%	https://programbench.com/task/brocode__fblog.3b54330/
188	codesnap-rs/codesnap	🦀️📸 Pure Rust tool to generate beautiful code snapshots, provide CLI and Library	rs	557	730	59.2%	https://programbench.com/task/codesnap-rs__codesnap.f81e4f3/
189	foriequal0/git-trim	Automatically trims your branches whose tracking remote refs are merged or stray	rs	548	509	64.6%	https://programbench.com/task/foriequal0__git-trim.07c2f50/
190	axodotdev/oranda	🎁 generate beautiful landing pages for your developer tools	rs	542	767	53.6%	https://programbench.com/task/axodotdev__oranda.27d60c7/
191	elkowar/pipr	A tool to interactively write shell pipelines.	rs	541	525	57.1%	https://programbench.com/task/elkowar__pipr.fae0b17/
192	paradigmxyz/solar	Blazingly fast, modular and contributor friendly Solidity compiler, written in Rust	rs	539	1,978	43.3%	https://programbench.com/task/paradigmxyz__solar.5190d0e/
193	Lymphatus/caesium-clt	Caesium Command Line Tools - Lossy/lossless image compression tool	rs	537	575	92.3%	https://programbench.com/task/lymphatus__caesium-clt.a529b2e/
194	agourlay/zip-password-finder	Find the password of protected ZIP files.	rs	534	680	97.9%	https://programbench.com/task/agourlay__zip-password-finder.704700d/
195	rust-ethereum/ethabi	Encode and decode smart contract invocations	rs	525	997	90.9%	https://programbench.com/task/rust-ethereum__ethabi.b1710ad/
196	ArthurSonzogni/json-tui	A JSON terminal UI made in C++	cpp	438	755	71.0%	https://programbench.com/task/arthursonzogni__json-tui.17a22b6/
197	tomarrell/wrapcheck	A Go linter to check that errors from external packages are wrapped	go	374	480	80.8%	https://programbench.com/task/tomarrell__wrapcheck.c058da1/
198	NikolaDucak/caps-log	A small TUI journaling tool. 📖	cpp	370	551	61.7%	https://programbench.com/task/nikoladucak__caps-log.2cf2d1e/
199	mibk/dupl	a tool for code clone detection	go	367	373	85.0%	https://programbench.com/task/mibk__dupl.1bf052b/
200	HaliteChallenge/Halite	@twosigma’s first artificial intelligence programming challenge	cpp	202	275	80.4%	https://programbench.com/task/halitechallenge__halite.822cfb6/

怎麼看這組資料

ProgramBench 的主榜單裡，9 個模型的 Resolved 都是 0%。這說明在統一的輕量級 agent 設定下，目前模型還不能穩定從黑箱行為和文件中重建完整軟體。

但 Almost resolved 仍然有區分度。Claude Opus 4.7 達到 3.0%，Claude Opus 4.6 為 2.5%，Claude Sonnet 4.6 為 1.0%，其餘模型為 0.0%。這類指標更適合觀察「接近完成」的能力，而不是只看是否完全通關。

任務實例表也很關鍵。它把每個開源專案的語言、星標數、測試數量和目前最佳得分列出來，可以看出 ProgramBench 覆蓋了壓縮、搜尋、資料庫、編譯器、命令列工具、媒體處理等不同類型的軟體。對 AI Coding 來說，這比單純演算法題更接近真實工程壓力。

ProgramBench 0% 解讀：AI 編程真正可怕的不是失敗，而是路線圖清楚了

Sun, 10 May 2026 12:32:39 +0800

AI 編程圈最近出現了一個新的基準測試：ProgramBench。表面上看，它給出的結果很讓程式設計師安心：九個主流模型在 fully resolved 指標上全部是 0%，沒有任何模型能完整通過一個任務。

但這件事真正值得緊張的地方，不是今天的大模型還做不到，而是完整軟體工程第一次被清楚地做成了一套可評測、可排名、可反覆優化的題。

一旦任務被定義清楚，AI 行業最擅長的事情就會發生：刷題、迭代、追榜，然後把原來做不到的事情一點點推到可用邊緣。

ProgramBench 到底在測什麼

很多編程基準測試，測的是補函式、改 bug、通過單元測試，或者在已有專案裡完成一個小功能。ProgramBench 更狠，它不給原始碼，也不給專案結構，更不給現成測試用例。

它給模型的材料主要只有兩類：

一個已經編譯好的可執行檔。
這個程式的使用文件。

模型需要自己執行可執行檔，觀察輸入輸出行為，理解命令列參數、邊界情況、錯誤訊息、資料儲存方式，然後重新實作一個行為一致的程式。

這已經不是「寫一段程式碼」，而是一個簡化但完整的軟體工程任務：要理解需求、探索行為、選擇語言、設計結構、寫原始碼、提供建置方式，並盡量通過隱藏測試。

根據 ProgramBench 官方介紹，它目前包含 200 個任務，覆蓋從小型命令列工具到 PHP、FFmpeg、SQLite 等大型真實專案。測試集由 agent-driven fuzzing 生成，總量超過 248,000 個行為測試。

如果把測試流程拆開，ProgramBench 大致是在考四件事：

讀懂文件：理解程式應該提供哪些命令、參數和輸出。
探索行為：反覆執行二進位程式，觀察正常輸入、異常輸入和邊界情況。
重建實作：自己選擇語言和專案結構，寫出一個行為接近的替代程式。
通過隱藏測試：不只常規行為要對，錯誤處理、輸出格式和邊界條件也要盡量一致。

所以它的搜尋價值不只是「又一個跑分」，而是回答一個更具體的問題：大模型能不能在沒有原始碼的情況下，只靠文件和黑箱行為，從零復刻一個真實軟體。

為什麼結果是 0%

ProgramBench 的主要指標是 fully resolved，也就是一個任務裡的測試全部通過才算完成。當前 leaderboard 上，九個模型在這個指標上都是 0%。

參與測試的模型包括 Claude、GPT、Gemini 等系列，統一使用 mini-SWE-agent 作為基線 agent。Claude Opus 4.7 在 almost resolved 指標上表現最好，大約有 3.0% 的任務通過了至少 95% 的測試；Claude Opus 4.6 是 2.5%，Claude Sonnet 4.6 是 1.0%。GPT 5.4、GPT 5.4 mini、Gemini 3.1 Pro、Gemini 3 Flash 等在 almost resolved 上都是 0.0%。

這說明今天的大模型加一個輕量級 agent，還無法從零重建完整軟體。即使是最簡單的任務，也很難做到所有細節都完全對齊。

但也要注意：這次測試用的是 mini-SWE-agent，不是 Claude Code，也不是 Codex。換成更強的 coding agent、更多工具鏈支援、更長時間的探索流程，結果可能會提高。所以這個結果更準確的說法是：當前模型加輕量 agent，還不足以穩定完成完整軟體重建。

fully resolved 和 almost resolved 是什麼意思

讀 ProgramBench 的結果時，最容易誤解的是這兩個指標。

fully resolved 是最嚴格的指標：一個任務裡的所有隱藏測試都通過，才算完整解決。只要還漏掉一個邊界條件、一個報錯格式、一個命令參數行為，就不能算 fully resolved。

almost resolved 則更像「接近完成」：如果一個任務至少通過了 95% 的測試，就算進入 almost resolved。它能反映模型有沒有把大部分行為做出來，但還不能代表程式已經可以替代原軟體。

這也是為什麼 0% 要分開看。fully resolved 的 0% 說明模型還無法完整交付；almost resolved 的差距則能看出哪些模型已經在部分任務上接近復刻成功。比如 Claude Opus 4.7 的 almost resolved 約為 3.0%，說明它確實在少量相對簡單的任務上更接近完成，但距離穩定重建完整軟體仍然很遠。

為什麼 mini-SWE-agent 會影響測試結果

這次測試使用統一的 mini-SWE-agent，好處是公平：不同模型都跑在同一套輕量 agent 框架裡，結果更容易橫向比較。

但它也會限制上限。完整軟體重建不只取決於模型本身，還取決於 agent 是否會規劃探索策略、是否能管理長期任務、是否會自動生成測試、是否能反覆定位失敗原因、是否能整理專案結構。

mini-SWE-agent 更像一個統一基線，而不是最強工程環境。

Claude Code、Codex 這類更完整的 coding agent，通常會提供更強的工具呼叫、上下文組織、任務拆解和多輪修復能力。如果換成這些工具，結果可能會更好。

所以 ProgramBench 這次結果更適合理解為：當前模型在輕量 agent 環境下還做不到完整軟體重建。它不是在證明「模型永遠做不到」，也不是在完整評估所有商業 coding agent 的上限。

它和 SWE-bench 的差別

SWE-bench 已經是 AI 編程領域裡很重要的基準。它讓模型在真實 GitHub 倉庫裡讀 issue、改程式碼、提交補丁，用來測試模型解決真實 bug 的能力。

但 SWE-bench 本質上仍然是在已有專案上修車：車還在，技術棧、目錄結構、程式碼組織、架構設計都已經有人完成了。模型只需要找到問題，把壞掉的零件修好。

ProgramBench 更接近重新造車：你只知道這台車應該有什麼行為，看到紅燈會停、遇到行人會鳴笛，剩下的結構、語言、模組、建置方式，全都要自己決定。

這就是為什麼它難得多。它不再只考局部補丁能力，而是在考軟體架構、系統推理、行為探索、自動測試、多輪糾錯和長期工程設計。

可以用一張表來理解兩者差別：

維度	SWE-bench	ProgramBench
起點	已有 GitHub 倉庫和 issue	已編譯可執行檔和使用文件
是否給原始碼	給原始碼	不給原始碼
主要任務	修復已有專案裡的 bug	從行為重新實作一個完整程式
技術棧	原專案已經確定	模型自己選擇
專案結構	原專案已經存在	模型自己設計
測試方式	提交補丁後跑測試	用隱藏行為測試驗證復刻程度
主要考點	讀程式碼、定位問題、補丁修復	行為探索、系統抽象、架構設計、完整實作

這也是為什麼 ProgramBench 更適合被看作下一階段 AI Coding 的目標：它把「修現有程式碼」推進到了「重建完整軟體」。

0% 並不等於安全

看到 0%，很多人的第一反應可能是：程式設計師飯碗暫時保住了。

短期看，這句話沒錯。今天的大模型還不能穩定完成完整軟體工程，尤其是在沒有原始碼、沒有測試用例、沒有專案結構的情況下。需求釐清、架構設計、長期維護、安全控制、團隊協作、業務理解，仍然是人類軟體工程師的重要優勢。

但如果把 0% 理解成「AI 編程到頭了」，就太樂觀了。

ProgramBench 真正改變的是問題定義。以前大家知道 AI 可以補程式碼，也知道 AI 可以修 bug，但「從一個可執行檔和文件重建完整軟體」這件事沒有被清楚地放到統一賽道裡。現在它被做成了 200 道題、統一評測、統一排名。

這意味著模型公司、agent 公司、開發工具公司都知道下一步該往哪裡發力：讓 AI 從寫程式碼片段，進化到維護、重建和交付完整軟體系統。

為什麼要斷網和防作弊

ProgramBench 的設計裡有一個細節很重要：它要防止模型作弊。

早期測試中，模型會嘗試直接從 GitHub 找原始碼，或者通過套件管理器下載包含原始碼的套件，甚至去系統快取目錄裡翻找已經下載過的軟體包。這樣當然會破壞測試目的，因為問題就不再是「能不能從行為重建軟體」，而是「能不能找到原始原始碼」。

所以 ProgramBench 使用了沙箱和斷網環境，不允許存取網際網路，也不允許反編譯、反組譯或讀取可執行檔內容。模型只能執行程式，觀察行為，再自己實作。

這個限制讓測試更乾淨，也更接近它真正想回答的問題：大語言模型能不能從程式行為和文件出發，自己構建一個可執行的軟體專案。

更值得警惕的是程式碼形態變化

ProgramBench 還有一個比 0% 更值得軟體工程師思考的發現：模型生成的程式碼往往不像人類工程師會寫的專案。

公開材料裡提到，模型傾向於生成更少的檔案、更淺的目錄、更少的函式，以及更長的單個函式。也就是說，它可能寫出一個巨大的、能跑的腳本，而不是一個結構清晰、便於人類維護的軟體工程專案。

從傳統軟體工程角度看，這通常是很差的程式碼。檔案太少、函式太長、抽象不足、模組邊界不清，都會讓人類難以維護。

但問題在於，AI 未必需要按照人類維護程式碼的方式寫程式碼。

人類強調抽象、命名、目錄結構和模組邊界，主要是因為人類記憶有限、團隊需要協作、程式碼需要長期復用。AI 如果可以用更長上下文、檢索系統和自動測試反覆重寫程式碼，它可能並不那麼需要人類熟悉的這些工程規範。

這會帶來一個很現實的風險：未來 AI 寫出的軟體也許能跑、甚至很快，但人類越來越難插手維護。

程式設計師真正要升級什麼

ProgramBench 的結果對程式設計師不是簡單的好消息，也不是簡單的壞消息。

短期看，完整軟體工程仍然很難，程式設計師不會因為這次 benchmark 立刻失業。尤其是架構判斷、需求釐清、安全把控、品質驗收和業務理解，仍然需要人類負責。

長期看，程式設計師的工作會繼續上移。真正危險的不是「不會寫程式碼」的人，而是只會寫程式碼、但不會定義問題、驗證結果、組織工具鏈和控制風險的人。

未來的軟體工程師可能更像：

需求定義者：把模糊業務問題變成可執行目標。
系統驗收者：判斷 AI 生成結果是否真的滿足需求。
工具鏈組織者：組合模型、agent、測試、部署和監控。
品質負責人：控制安全、可維護性、邊界條件和長期風險。
業務和技術之間的翻譯者：把真實問題轉成工程系統能處理的約束。

如果 AI 真的從程式碼助手變成完整軟體工程師，人類程式設計師的價值就不再只是親手寫每一行程式碼，而是定義什麼值得寫、怎樣算寫對、哪裡不能出錯。

小結

ProgramBench 的 0% 不是終點，而是新階段的起點。

它說明今天的大模型還不能從零穩定重建完整軟體系統；但它也把下一代 AI Coding agent 的目標定義得非常清楚：從局部補丁走向完整專案，從程式碼片段走向系統交付。

對程式設計師來說，短期可以鬆一口氣，但長期不能只盯著「AI 現在還不行」。更重要的是盡快把自己從程式碼執行者升級為問題定義者、結果驗收者和風險控制者。

真正值得緊張的不是 AI 今天考了 0%，而是題目已經擺出來了。

GPT-5.5、GPT-5.4 與 GPT-5.3-Codex 如何取捨

Sun, 10 May 2026 08:43:17 +0800

如果只看一句話，結論其實很直接：預設選 GPT-5.5，預算更敏感或任務難度中等時選 GPT-5.4，只有在 Codex 環境裡做更長時間的軟體工程任務，或需要 Cloud Tasks、Code Review 這類能力時，再重點看 GPT-5.3-Codex。

這個判斷不只是主觀體驗，OpenAI 在 Codex 官方文件裡的推薦也已經很明確。到 2026-05-10 為止，Codex 文件仍然寫著：大多數任務優先從 gpt-5.5 開始；如果還沒有開放 gpt-5.5，就繼續用 gpt-5.4；輕量任務或子任務則更適合 gpt-5.4-mini。

三個模型的定位差異

先看官方定位。

GPT-5.5 是 Codex 裡最新的前沿模型，面向複雜編程、電腦操作、知識工作與研究型工作流。它更像是「預設主力模型」，適合複雜分析、多步任務、跨檔案修改、方案設計與較重的文件工作。

GPT-5.4 則是一個更穩的全能型選擇。官方描述是：它把 GPT-5.3-Codex 的強程式能力帶到了更強的推理、工具使用與 agentic workflow 裡。換句話說，它不是「弱化版 5.5」，而是一個更均衡、更容易長期當主力的模型。

GPT-5.3-Codex 仍然是很強的程式模型，但它的核心優勢更集中在真實軟體工程與 Codex 原生工作流裡。官方文件也特別說明：它是針對 agentic coding tasks 最佳化的模型，而且 GPT-5.4 的編碼能力本身就已經繼承了它的長處。

所以今天再選模型，不太適合把 GPT-5.3-Codex 直接理解成「最強編程模型」。在大部分日常開發場景裡，更推薦先看 GPT-5.5 和 GPT-5.4。

按使用場景怎麼選

如果你的任務是日常問答、複雜解釋、資料整理、檔案分析、長文資訊綜合，GPT-5.5 最合適。它不只適合寫程式，也更適合處理「程式之外但又很費腦力」的知識工作。

如果你的任務是複雜編程、重構、排錯、架構設計、多檔案修改，仍然優先 GPT-5.5。Codex 官方推薦也是這樣寫的：在能用 gpt-5.5 的地方，大多數任務先從它開始。

如果你更在意額度與消耗，希望在品質很高的前提下把成本壓下來，GPT-5.4 往往是更合理的預設值。對很多常規開發、普通改寫、一般翻譯、腳本生成與 bug 修復任務來說，GPT-5.4 已經足夠強，而且更省額度。

如果你是在 Codex CLI、IDE 擴充套件或 App 裡做更像「工程代理」的事情，例如長時間讀倉庫、持續改程式、排隊跑任務、做 Cloud Tasks 或 Code Review，GPT-5.3-Codex 仍然有存在感。原因不是它比 GPT-5.5 更先進，而是目前 Codex 的 Cloud Tasks 和 Code Review 仍然執行在 GPT-5.3-Codex 上。

消耗額度差多少

在 Codex 的 credits 計費表裡，這三個模型的差異非常清楚。

按 Business / New Enterprise 的 token 計費口徑看：

GPT-5.5：輸入 125 credits / 1M tokens，快取輸入 12.5 credits，輸出 750 credits
GPT-5.4：輸入 62.5 credits / 1M tokens，快取輸入 6.25 credits，輸出 375 credits
GPT-5.3-Codex：輸入 43.75 credits / 1M tokens，快取輸入 4.375 credits，輸出 350 credits

這代表如果只看名義費率，GPT-5.4 大約是 GPT-5.5 的一半。做同樣長度的輸入輸出時，通常能省接近 50% 的額度。GPT-5.3-Codex 的輸入更便宜，但輸出已經和 GPT-5.4 很接近，所以它並不是那種「明顯便宜很多」的選項。

還有一個容易忽略的點：Codex 官方又特別寫了一句，GPT-5.5 uses significantly fewer tokens to achieve results comparable to GPT-5.4。也就是說，雖然它的單價更高，但在某些複雜任務裡，可能會靠更少的 token 和更少返工把差距拉回來。

不過對固定模板文章改寫、翻譯、SEO 描述生成這種輸入輸出長度都比較穩定的任務來說，這種「少走彎路」的優勢通常沒有複雜工程任務那麼明顯。實際消耗上，GPT-5.4 大多還是更省，通常可以理解成省掉大約 45% 到 50%。

Codex 使用限制上的差異

除了單價，Codex 裡的可用方式也不一樣。

截至 2026-05-10，GPT-5.5 在 Codex 裡是推薦模型，但目前只在使用 ChatGPT 登入的 Codex 中提供，不支援 API key 驗證。GPT-5.4 和 GPT-5.3-Codex 則支援 API 存取。

另外，GPT-5.5 和 GPT-5.4 目前都不支援 Codex Cloud Tasks 和 Code Review；這兩項仍然是 GPT-5.3-Codex 的主場。也就是說，如果你說的是「在 Codex 裡長時間跑工程任務」，那就不能只看模型本身強不強，還要看對應功能是不是只有 GPT-5.3-Codex 才能跑。

如果你只是本地訊息使用，Plus 方案下官方給出的 5 小時窗口大致是：

GPT-5.5：15-80
GPT-5.4：20-100
GPT-5.3-Codex：30-150

從這裡也能看出一個現實差異：GPT-5.5 最強，但在固定額度下可用次數通常更少；GPT-5.4 更均衡；GPT-5.3-Codex 在本地訊息上反而看起來更耐用一些。

常用場景怎麼選

日常使用裡有不少高頻任務。更實用的看法，不是抽象地說「哪個更強」，而是按場景一個一個拆開看。

1. 日常問答、資料整理、長文總結

GPT-5.5：最適合。它更擅長處理模糊問題、補齊上下文，把零散資訊整理成結構化結果。

GPT-5.4：適合普通總結與批量整理。難度不高、數量很多時，通常更划算。

GPT-5.3-Codex：不太適合當主力。能做，但這不是它最有優勢的場景。

2. 技術概念解釋、程式講解、讀舊專案

GPT-5.5：適合複雜專案。跨檔案關係多、呼叫鏈長、歷史包袱重時更穩。

GPT-5.4：適合常規閱讀理解。看函式、看模組、解釋設定、幫你快速接手專案都很好用。

GPT-5.3-Codex：更偏工程執行，不是最優先的「講解型模型」。

3. 寫腳本、小工具、SQL、Shell、正則

GPT-5.5：適合腳本背後還有系統設計、聯動多個服務、涉及複雜約束的情況。

GPT-5.4：最適合當預設主力。大多數腳本、小工具、SQL 與命令列任務都夠用，而且更省額度。

GPT-5.3-Codex：如果腳本只是整個工程代理鏈條的一部分，可以考慮；單獨寫小腳本時不必優先選它。

4. 改 bug、改小功能、補測試、普通開發

GPT-5.5：適合稍複雜的修復，例如需要先分析原因，再跨檔案修改，最後補測試。

GPT-5.4：最適合日常開發主力。普通 bug、小功能、測試樣板、重新命名、格式整理這類任務，性價比最好。

GPT-5.3-Codex：能做，但如果沒有 Cloud Tasks 或工程代理需求，通常不是第一選擇。

5. 複雜重構、架構設計、疑難排錯

GPT-5.5：最適合。複雜任務裡最貴的是返工，不是單次輸出；GPT-5.5 更適合做主解題模型。

GPT-5.4：適合中等複雜度任務。可以做方案和重構，但在特別長的上下文、多步推理與高不確定性問題上通常不如 GPT-5.5 穩。

GPT-5.3-Codex：偏執行，不是這類高難決策任務的預設優先級。

6. 批量輕任務、重複任務、拆子任務

GPT-5.5：能做，但通常不划算。

GPT-5.4：最適合。批量改註釋、批量改格式、批量生成樣板程式碼、批量改內容時，最平衡。

GPT-5.3-Codex：如果任務已經放進 Codex 的工程流程裡，可以考慮；單看性價比，仍然通常不如 GPT-5.4。

7. 自動化流水線、代理執行、持續讀寫倉庫

GPT-5.5：適合做前期方案設計、規則制定與複雜任務拆分。

GPT-5.4：適合寫自動化腳本、補中等複雜度流程邏輯，尤其是在 API 可接入的情況下。

GPT-5.3-Codex：最值得關注。因為 Codex 的 Cloud Tasks 和 Code Review 還執行在它上面，所以它更適合「讓系統自己跑」的工程場景。

8. 重要頁面文案、品牌介紹、最終潤飾

GPT-5.5：最適合。自然度、風格控制與上下文一致性最好。

GPT-5.4：適合大多數普通頁面和日常更新，重要頁面可以先寫初稿再交給 GPT-5.5 精修。

GPT-5.3-Codex：不適合當主要文案模型。

9. 網站固定模板文章改寫、翻譯、SEO 描述

GPT-5.5：適合做模板設計、最終潤飾、重要頁面定稿，以及把中文翻成更自然的英文。

GPT-5.4：最適合批量生產。普通文章改寫、固定結構翻譯、商品文案重寫、Meta 描述批量生成，通常品質和成本最平衡。

GPT-5.3-Codex：不適合當主要文案模型，更適合寫批次處理腳本、清洗 HTML、保留標籤結構、改自動發布流程。

10. 電商商品文案、分類頁、批量內容營運

GPT-5.5：適合定規則、做抽檢、做高價值頁面的最終潤飾。

GPT-5.4：最適合批量生產。商品標題、分類頁說明、批量活動文案、長尾 SEO 內容這類任務上，品質和成本更平衡。

GPT-5.3-Codex：適合寫抓取、清洗、批次處理、自動發布腳本，不適合負責主要文案。

如果把這些場景再壓縮成一句話：

複雜腦力活、複雜分析、複雜文案：優先 GPT-5.5
日常開發、批量生產、重複任務：優先 GPT-5.4
Codex 工程代理、Cloud Tasks、Code Review：重點看 GPT-5.3-Codex

最後怎麼取捨

如果你只是平時寫程式、改 bug、問技術問題、順手做一些文件工作，GPT-5.4 是很穩的主力選擇。

如果你要做的是更複雜的專案分析、多檔案修改、架構方案、深度排錯，或希望一個模型同時覆蓋編程與複雜知識工作，直接優先 GPT-5.5。

如果你在 Codex 環境裡看重的是工程工作流本身，例如 Cloud Tasks、Code Review、長時間代理執行，那麼 GPT-5.3-Codex 仍然值得保留，但它已經不太適合被當成「預設第一選擇」。

對固定模板內容站來說，更實用的搭配通常是：

GPT-5.4 負責批量生產
GPT-5.5 負責定模板、做抽檢、做最終潤飾
GPT-5.3-Codex 負責寫自動化工具，而不是負責主要內容

小結

現在更合理的預設順序是：GPT-5.5 第一，GPT-5.4 第二，GPT-5.3-Codex 放到更偏工程代理與 Codex 特定能力的場景裡使用。

如果你問的是「同樣一篇模板文章改寫，GPT-5.4 比 GPT-5.5 能省多少」，按官方 credits 表和這類任務的典型 token 結構看，通常可以按「省接近一半」來理解。對批量站內容來說，這個差距已經夠大，所以最常見的做法不是全程上 GPT-5.5，而是先用 GPT-5.5 把規則與風格定好，再把大批量任務交給 GPT-5.4。

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 工具時最重要的成本控制。

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。

參考資料

DeepSeek-TUI：在終端裡執行 DeepSeek 編程 Agent

Fri, 08 May 2026 13:41:15 +0800

DeepSeek-TUI 是一個執行在終端裡的 AI 編程 Agent。它圍繞 DeepSeek V4 模型設計，透過 deepseek 命令啟動，可以在 TUI 介面裡讀寫檔案、執行 shell 命令、搜尋網頁、管理 git、呼叫 MCP server，並支援子 Agent 協作。

它比普通聊天 CLI 更像一個終端工作台。它不只是把問題發給模型，而是把看程式碼、改檔案、跑命令、檢查診斷、保存會話、恢復狀態整合在一起。

專案主要使用 Rust 編寫，授權為 MIT。GitHub 描述是「Coding agent for DeepSeek models that runs in your terminal」。

適合誰

DeepSeek-TUI 適合喜歡終端工作流，並想用 DeepSeek 模型處理本地開發任務的開發者。

用 DeepSeek 做程式碼修改和專案分析。
不想打開完整 IDE。
希望 AI 工具能讀寫本地 workspace。
需要 Plan、Agent、YOLO 模式。
想保存會話、恢復長任務、回滾改動。
想接入 MCP、LSP 診斷、HTTP/SSE runtime API 和 skills。

如果只是簡單問答，Web 端或輕量 CLI 已足夠。DeepSeek-TUI 更適合把模型放進本地開發流程。

安裝方式

npm：

1
2
3

npm install -g deepseek-tui
deepseek --version
deepseek --model auto

npm 包是安裝器和 wrapper，會下載預編譯 Rust 二進位，要求 Node.js >=18。

Cargo：

1
2

cargo install deepseek-tui-cli --locked
cargo install deepseek-tui --locked

Homebrew：

1
2

brew tap Hmbown/deepseek-tui
brew install deepseek-tui

也可以從 GitHub Releases 下載 Linux x64/ARM64、macOS x64/ARM64、Windows x64 的預編譯版本。

Docker：

docker run --rm -it \
  -e DEEPSEEK_API_KEY \
  -v "$PWD:/workspace" \
  ghcr.io/hmbown/deepseek-tui:latest

配置 API Key

首次啟動會提示輸入 DeepSeek API key，並保存到：

`1`	`~/.deepseek/config.toml`

也可以手動配置：

1
2

deepseek auth set --provider deepseek
deepseek auth status

或使用環境變數：

1
2

export DEEPSEEK_API_KEY="YOUR_KEY"
deepseek

檢查環境：

`1`	`deepseek doctor`

清除已保存的 key：

`1`	`deepseek auth clear --provider deepseek`

Auto mode

`1`	`deepseek --model auto`

TUI 中也可使用：

`1`	`/model auto`

Auto mode 同時選擇模型和 thinking：

模型：deepseek-v4-flash 或 deepseek-v4-pro
Thinking：off、high 或 max

真正請求前，TUI 會做一次小型路由呼叫，分析最新請求和上下文，再決定本輪模型和思考級別。auto 是本地功能，上游 API 收到的是具體模型和設定。

需要基準測試、成本上限或固定行為時，建議直接指定模型。

三種模式

模式	用途
Plan	只讀探索和計畫
Agent	預設互動模式，工具呼叫有 approval gate
YOLO	在可信 workspace 中自動批准工具

Plan 適合分析，Agent 適合日常編程，YOLO 風險最高，只適合可信分支或測試目錄。

工具能力

DeepSeek-TUI 支援檔案讀寫、apply patch、shell、git、web search/browse、子 Agent、MCP、LSP 診斷、會話恢復、工作區回滾、持久化任務隊列、HTTP/SSE runtime API 和 skills。

LSP 診斷可把 rust-analyzer、pyright、typescript-language-server、gopls、clangd 等錯誤回饋給模型。工作區回滾使用 side-git 快照，提供 /restore 和 revert_turn，但正常 git 提交習慣仍然重要。

常用命令

deepseek
deepseek "explain this function"
deepseek --model deepseek-v4-flash "summarize"
deepseek --model auto "fix this bug"
deepseek --yolo
deepseek auth set --provider deepseek
deepseek doctor
deepseek doctor --json
deepseek models
deepseek sessions
deepseek resume --last
deepseek resume <SESSION_ID>
deepseek fork <SESSION_ID>
deepseek serve --http
deepseek serve --acp
deepseek pr <N>
deepseek mcp list
deepseek mcp validate
deepseek update

Zed 和 ACP

{
  "agent_servers": {
    "DeepSeek": {
      "type": "custom",
      "command": "deepseek",
      "args": ["serve", "--acp"],
      "env": {}
    }
  }
}

目前 ACP 支援新會話和 prompt response，但工具驅動編輯和 checkpoint replay 尚未透過 ACP 暴露。

配置和 provider

使用者配置：

`1`	`~/.deepseek/config.toml`

專案 overlay：

`1`	`<workspace>/.deepseek/config.toml`

api_key、base_url、provider、mcp_config_path 等敏感欄位不能放入專案 overlay。

OpenAI-compatible 示例：

1
2

deepseek auth set --provider openai --api-key "YOUR_OPENAI_COMPATIBLE_API_KEY"
OPENAI_BASE_URL="https://openai-compatible.example/v4" deepseek --provider openai --model glm-5

Ollama：

1
2

ollama pull deepseek-coder:1.3b
deepseek --provider ollama --model deepseek-coder:1.3b

小結

DeepSeek-TUI 是一個完整的終端 AI 編程 Agent，把 DeepSeek V4、TUI、工具呼叫、LSP 診斷、會話恢復、回滾、MCP 和 skills 放進同一套 Rust 工具鏈。它不一定最輕，但適合把 AI 從聊天推進到可執行的本地開發流程。

參考資料

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

Codex App 保姆級上手：安裝、沙箱、並行任務、Skills 與 MCP

Wed, 06 May 2026 08:41:17 +0800

Codex App 可以理解成一個面向 AI 編程的任務工作台。它不是傳統 IDE，也不是單純聊天視窗，而是把多任務、專案管理、沙箱權限、Git、雲端執行、外掛、Skills、MCP 和自動化集中到一個介面裡。

如果你已經在用 Codex CLI、Claude Code、Cursor 或其他 coding agent，Codex App 最值得關注的地方，是它把「多個 agent 並行幹活」做成了更清楚的桌面工作流。

Codex App 適合做什麼

Codex App 的核心價值不是讓 AI 回答問題，而是讓 AI 在專案目錄裡持續執行任務：

修改程式碼、執行命令、啟動開發服務。
管理多個專案和多個任務。
在本地或雲端執行長任務。
呼叫外掛、Skills 和 MCP 擴展能力。
透過 Git、worktree 和 PR 管理改動。

OpenAI 官方也把 Codex App 定位成一個用於管理多個 coding agent 的介面。它適合需要同時推進多個程式碼任務的人，尤其適合前端頁面、腳本工具、小型應用、文件整理和自動化工作流。

安裝前準備

使用 Codex App 前，建議先準備好三個基礎工具：

Git
Node.js
VS Code 或你常用的 IDE

Codex App 支援 macOS 和 Windows。安裝後使用 ChatGPT 帳號登入，首次進入時可以選擇主要使用場景，例如編程或日常工作。Codex 會根據選擇預裝一部分外掛和 Skills，後續也可以在設定和外掛市場裡調整。

Windows 和 macOS 的主要功能大體一致，但部分電腦自動化能力可能依賴具體平台和外掛支援，實際以你目前版本顯示為準。

介面結構：專案、任務和對話

Codex App 是典型的三欄布局：

左側：專案、任務、歷史對話、外掛和自動化入口。
中間：目前對話視窗。
右側：檔案、瀏覽器、終端機、執行結果等多功能區域。

一個專案通常對應一個本地資料夾。你可以在同一個專案裡開多個對話，也可以同時打開多個專案，讓不同 agent 並行執行任務。

任務列表會顯示不同狀態：

正在執行：agent 仍在執行。
等待批准：需要你確認權限、連網、安裝依賴或執行高風險操作。
已完成：任務已經結束，可以查看結果或繼續追問。

這比在多個終端視窗裡來回切換更直觀，也更適合同時管理多個 AI 任務。

沙箱與權限控制

Codex App 的權限體系圍繞沙箱展開。預設情況下，目前專案資料夾會成為 agent 的主要工作範圍。

常見權限邊界包括：

可以讀取和修改專案目錄內的檔案。
預設不能隨意修改專案外檔案。
預設會限制連網或高風險命令。
需要越權時，會向使用者申請批准。

比較實用的模式是「自動審查」：低風險操作由系統自動放行，高風險操作再交給使用者確認。這樣既能減少頻繁彈窗，又能避免 agent 在不知情的情況下執行危險操作。

「完全存取」要謹慎開啟。它適合你明確知道 agent 要做什麼，並且專案已經有 Git 備份、重要檔案也有額外備份的場景。日常使用不建議長期保持完全存取。

上下文、模型和額度

Codex App 會顯示目前對話的上下文使用情況。對話越長，歷史內容越多，模型需要處理的上下文也越大。

實用建議是：

一個任務完成後，優先開新對話。
長對話可以手動壓縮，但不要把壓縮當成萬能記憶。
複雜任務先寫清楚目標、邊界和驗收標準。
不要把大量無關日誌、報錯和檔案一次性塞進對話。

模型選擇上，可以根據任務複雜度調整思考強度。簡單修改、文案整理、重複任務不一定需要最高規格模型；架構遷移、疑難 bug、跨檔案重構則更適合使用更強模型。

如果介面裡有快速模式，也要注意它通常會帶來更高的額度消耗。趕時間時可以開，日常不必預設開啟。

圖片生成與多模態輸入

Codex App 可以接收圖片和檔案作為上下文，也可以在合適場景中呼叫圖像生成能力。

這對前端和內容類專案很有用。例如你可以讓 Codex：

根據截圖修正頁面樣式。
替換網頁中的不合適配圖。
生成產品圖、輪播圖或頁面素材。
根據 UI 截圖指出需要修改的位置。

更高效的用法是：不要只說「改好看一點」，而是結合截圖指出具體問題，例如「這個卡片間距太大」「這裡的圖和服務場景不匹配」「把地圖區域做得更清楚」。

Steer：任務執行中及時糾偏

Steer 可以理解成「執行中接管方向」。當 agent 已經開始執行，但你發現它理解錯了方向，不應該等它全部跑完再改。

這時可以使用引導功能，把新的指令插入目前執行流程，讓 Codex 及時修正路線。

適合使用 Steer 的場景包括：

agent 誤解了需求。
生成的頁面風格明顯不對。
正在執行的方案成本太高。
你臨時補充了關鍵約束。

一般建議保留預設排隊行為，只在確實需要干預時手動使用 Steer。這樣既不會打亂正常任務，也能在關鍵時刻把方向拉回來。

計劃模式和內建瀏覽器

複雜任務建議先開計劃模式。計劃模式下，Codex 不會馬上改程式碼，而是先輸出方案，必要時還會用卡片形式追問關鍵選擇。

適合開計劃模式的任務：

框架遷移，例如從普通 React 專案遷到 Next.js。
大範圍重構。
涉及資料庫、認證、部署的功能。
你還沒想清楚技術路線的需求。

Codex App 的右側區域可以打開內建瀏覽器，用來預覽本地開發服務。你可以在頁面上做批註，讓 Codex 按具體 UI 位置修改問題。這種「看頁面、點位置、讓 AI 改」的流程，比純文字描述更適合前端除錯。

Git、IDE 和程式碼回滾

Codex App 不是完整 IDE。它可以查看程式碼、批註程式碼，但真正的手寫編輯仍然更適合交給 VS Code、Cursor、Windsurf 等 IDE。

建議每個 Codex 專案都盡早初始化 Git：

讓 Codex 建立或檢查 .gitignore。
在完成一個可用狀態後提交一次。
每次大改前確保有乾淨提交點。
不滿意時用 Git 回滾程式碼。

如果只回滾對話歷史，程式碼不會自動跟著回滾。比較穩的做法是：對話層面回到合適節點，程式碼層面用 Git commit hash 回到對應狀態。

Worktree：並行開發多個方向

git worktree 是 Codex App 裡非常適合並行 agent 的能力。

它的本質是：基於同一個倉庫建立多個獨立工作目錄，每個目錄對應不同分支。這樣你可以讓不同 agent 在不同資料夾裡同時開發，不互相覆蓋。

典型用法：

一個 worktree 優化客戶評價元件。
一個 worktree 調整門店資訊和地圖布局。
兩個任務完成後分別合併回主幹。
合併完成後刪除臨時 worktree。

這比在同一個目錄裡讓多個 agent 同時改程式碼穩得多。遇到衝突時，也可以按正常 Git 流程 review 和合併。

雲端執行環境

Codex 不只能在本機工作，也可以把任務委託到雲端環境執行。

雲端執行適合這些場景：

出門在外，手邊只有手機。
希望 agent 在背景跑長任務。
程式碼已經同步到 GitHub，需要讓 Codex 基於遠端倉庫修改。
希望透過 PR 形式審查和合併改動。

典型流程是：先把本地程式碼推到 GitHub，再讓 Codex 在雲端環境中拉取倉庫、執行任務、生成改動，最後以 PR 或 diff 的方式交給你審核。

本地繼續開發時，要記得把遠端最新改動同步回來。

記憶系統：寫好 AGENTS.md

新對話預設沒有完整歷史記憶。專案一複雜，如果每次都重新解釋背景，會很浪費。

最通用的做法，是在專案根目錄維護 AGENTS.md。這個檔案可以記錄：

專案目標和主要技術棧。
常用命令。
目錄結構說明。
程式碼風格和命名約定。
禁止事項，例如不要批量刪除檔案。
測試、建置和部署規則。

你也可以讓 Codex 先通讀專案，再生成一版 AGENTS.md，然後人工審一遍。複雜專案裡，這個檔案非常值得維護。

全域規則也要謹慎。適合寫入所有專案都通用的安全約束，例如「不要遞迴刪除目錄」「執行破壞性操作前必須確認」。不要把某個專案的細節寫進全域規則，否則會污染其他專案。

外掛和自動化

外掛用於把外部服務接入 Codex，例如 GitHub、Gmail、Google Drive、資料庫、部署平台等。

外掛的價值在於減少複製貼上。比如你可以讓 Codex：

查看某個 GitHub 倉庫的 star 趨勢。
整理郵件內容並發給自己。
定期執行某個檢查任務。
把結果寫成摘要。

自動化則適合重複任務。例如每週五下午檢查一次倉庫資料，並發送郵件報告。簡單自動化任務通常不需要最高規格模型，選擇較輕量的模型即可。

Skills：把工作流變成可複用能力

Skills 是 Codex 的「專業說明書」。它不是單次提示詞，而是把某類任務的流程、規範、腳本和注意事項沉澱下來，讓 Codex 後續穩定複用。

常見來源有三類：

官方 Skills。
第三方 Skills。
自己編寫的 Skills。

適合做成 Skill 的工作：

把字幕整理成圖文筆記。
按公司規範寫週報。
批量處理圖片或文件。
固定格式的程式碼審查。
特定框架的專案初始化。

如果某個提示詞你已經複製貼上了很多次，就值得考慮把它做成 Skill。

MCP：接入外部工具和資料庫

MCP 可以理解成給大模型使用的標準化工具協議。透過 MCP，Codex 可以呼叫外部服務完成更具體的任務。

例如接入 Supabase 後，可以讓 Codex：

建立資料表。
讀取資料庫結構。
修改後端接口。
把前端表單提交到資料庫。
根據資料庫狀態除錯問題。

這類能力很強，但也要注意權限邊界。資料庫、生產環境、部署平台、郵件帳號都屬於高風險資源。第一次接入時，最好使用測試專案和低權限帳號。

部署外掛

部署平台外掛可以讓 Codex 直接完成建置和發布，例如把前端專案部署到 Netlify 一類平台。

這類外掛適合小型網站、原型頁面、內部工具和展示專案。實際使用時建議注意：

部署前先跑本地建置。
環境變數不要直接寫進程式碼。
發布後檢查頁面是否能正常訪問。
生產專案要保留人工 review。

AI 可以幫你打通發布流程，但發布權限仍然要謹慎管理。

電腦自動化

在支援的平台和外掛環境裡，Codex 還可以操作瀏覽器或桌面應用，完成更接近 RPA 的任務。

例如：

打開聊天軟體並準備一條訊息。
瀏覽專案看板，彙總任務狀態。
生成英文簡報。
在你確認後發送給指定對象。
把這套流程做成定時自動化。

這類功能很有想像力，但也最需要安全邊界。凡是涉及發訊息、發郵件、提交表單、付款、刪除資料的操作，都應該保留人工確認。

使用建議

Codex App 的正確打開方式，不是讓它一次性全自動接管一切，而是把任務拆清楚，讓它在受控環境裡高效執行。

推薦習慣：

每個專案先初始化 Git。
複雜任務先開計劃模式。
並行任務優先用 worktree。
專案規則寫進 AGENTS.md。
高風險操作保留人工確認。
重複流程沉澱成 Skill 或自動化。
外掛和 MCP 先在測試環境驗證。

參考資料

小結

Codex App 的重點不是「多一個 AI 聊天視窗」，而是把 AI 編程變成一個可管理的工作台：本地專案、雲端任務、Git、worktree、外掛、Skills、MCP 和自動化都能串起來。

真正用好它的關鍵，是在「放權」和「控制」之間找到平衡。小任務可以大膽交給 Codex，複雜任務先讓它計劃，高風險動作必須確認。這樣它才會從一個會寫程式碼的助手，變成可以長期協作的工程工具。

Claude.md 不是越長越好：AI 編程全域記憶文件該怎麼寫

Wed, 29 Apr 2026 21:07:37 +0800

最近看到一個關於 AI 編程全域記憶文件的討論：專案裡使用 Claude.md、AGENTS.md 這類文件之後，效果不一定會變好，甚至可能讓成功率下降，同時推理成本還會上升。

這件事乍看有點反直覺。我們通常會覺得，給 AI 更多專案背景、更多規則、更多說明，它應該更容易寫對程式碼。
但實際問題在於：Claude.md 不是普通文件，而是每次對話都會被塞進上下文的全域記憶。它寫得越多，模型每次都要讀得越多；它寫得越含糊，模型每次都要多做判斷；它寫進了不該寫的流程，模型還可能在不相關的任務裡觸發多餘動作。

所以，Claude.md 真正難寫的地方，不是怎麼把內容寫全，而是怎麼判斷哪些內容值得長期佔用上下文。

Claude.md 到底是什麼

在 AI 編程工具裡，Claude.md、AGENTS.md 這類文件本質上都是全域記憶文件。

普通對話會進入上下文，但上下文長度有限。對話長了以後，歷史內容會被壓縮，部分細節會丟失。全域記憶文件的作用，是把一些重要規則固定下來，讓模型在每次任務開始時都能看到。

這意味著兩件事：

寫進去的內容更不容易被遺忘
寫進去的內容也會在每次任務裡產生成本

它不像一份 README，只在需要時被閱讀。它更像一套長期有效的工作約束。只要放進去，就預設每次都會影響模型的判斷。

因此，Claude.md 不是專案介紹，也不是經驗合集，更不是把所有開發流程都塞進去的地方。它應該只存放那些模型如果不知道，就容易反覆犯錯的規則。

為什麼寫了反而可能變差

全域記憶文件寫得不好，主要會帶來三類問題。

第一，它會佔用上下文。

如果 Claude.md 有一千行，那麼這些內容會長期進入模型上下文。真正與當前任務有關的程式碼、錯誤資訊、需求說明，反而會被擠壓。上下文不是免費的空間，越大的全域規則，越容易稀釋當前任務的重點。

第二，它會觸發多餘行為。

比如在全域文件裡寫：

1
2

每次開始任務前，都要完整閱讀專案目錄。
每次修改後，都要執行完整鏈路測試。

這些話看起來很負責，但放在全域記憶裡就會變成「所有任務都預設執行」。哪怕只是改一行文案，模型也可能因為這條規則去做不必要的探索和測試。結果就是任務變慢、成本變高，甚至引入新的干擾。

第三，它會增加判斷負擔。

像「保持程式碼優雅、簡潔、可維護、可擴展」這類話，聽起來正確，但實際約束很弱。模型每次生成程式碼時都要判斷什麼叫優雅、什麼叫可擴展，卻沒有得到明確邊界。

更好的寫法不是堆抽象美德，而是寫具體禁令或反例。比如：

1
2
3

不要為了單個調用點新增通用抽象。
不要在沒有測試覆蓋的情況下改動共享解析邏輯。
不要把臨時腳本放進業務源碼目錄。

這些規則更具體，也更容易被執行。

應該寫什麼

判斷一條內容要不要寫進 Claude.md，可以用一個簡單標準：

如果不寫，AI 就會反覆犯同一種錯誤，那它值得寫進去。

適合寫進全域記憶文件的內容，通常有這些特點：

長期有效
與當前倉庫強相關
無法從程式碼結構自然推斷
能明確改變模型行為
最好是約束、禁令、路徑規則或固定命令

比如：

所有 Hugo 文章只改 index.zh-cn.md，不自動生成其他語言版本。
文章 front matter 必須包含 title/date/draft/tags/categories/slug/description。
不要修改 public/ 目錄裡的構建產物。
PowerShell 下執行部署時使用 scripts/deploy.ps1。

這些內容不是泛泛而談，而是和倉庫的真實工作方式綁定。模型如果不知道，就可能做錯；模型知道以後，確實能減少誤操作。

不該寫什麼

很多人容易把 Claude.md 寫成專案說明書，這通常沒有必要。

不太適合寫進去的內容包括：

專案願景和背景介紹
大段目錄結構說明
臨時任務計畫
一次性的除錯步驟
抽象的程式碼審美要求
只在少數情況下才需要執行的長流程

比如「這是一個電商專案，包含商品、訂單、使用者模組」這種描述，對模型完成具體編程任務幫助有限。真正開發時，模型應該根據當前需求、規格文件、程式碼結構和測試來判斷，而不是靠全域記憶裡的粗略介紹。

目錄結構也是類似。除非某個目錄有特殊約定，比如「共享元件只能從這個目錄引用」，否則沒必要把整個樹狀結構都寫進去。模型可以自己讀取專案目錄，硬塞一份靜態目錄說明反而容易過期。

流程更適合做成技能或命令

如果一段內容是「第一步做什麼、第二步做什麼、第三步做什麼」，它未必適合放進 Claude.md。

長期流程可以沉澱成技能、腳本或命令。這樣做的好處是：全域記憶裡只需要保留名稱和觸發條件，真正的詳細步驟只在需要時載入。

比如：

1
2

當使用者要求翻譯 Hugo 文章時，使用 post-translate 技能。
當使用者要求部署站點時，執行 hugo-rsync-deploy 流程。

這比把完整翻譯流程、部署流程都寫進 Claude.md 更輕。全域記憶保持短，具體流程交給可觸發的工具。

Claude 最近的初始化流程也在往這個方向走：不只是生成一個 Claude.md，還會嘗試把可複用流程拆成 skills，把固定事件拆成 hooks。這個變化背後的思路很清楚：全域記憶只做入口，細節按需載入。

Claude.md 需要持續迭代

Claude.md 不應該一次寫完就不管。

更合理的方式是先保持簡短，讓模型在真實任務裡暴露問題。某個錯誤出現一次，可以先人工處理；如果同類錯誤出現兩次以上，就說明它可能值得沉澱為全域規則。

這類迭代比一開始寫一大堆規則更有效。因為一開始你不知道哪些規則真的有用，也不知道哪些內容會變成噪音。隨著專案變大、協作變多、模型行為逐漸穩定，再慢慢把高頻問題寫進去。

還有一個重要趨勢：模型越強，全域記憶文件反而應該越短。

以前很多需要寫進提示詞的要求，現在模型已經能自然做到。繼續把這些基礎要求塞進 Claude.md，只會增加上下文負擔。全域記憶應該隨著模型能力提升而收縮，只保留這個倉庫獨有、模型無法自動推斷的部分。

一個更實用的寫法

寫 Claude.md 時，可以按這個順序思考：

這個倉庫有什麼特殊約定？
哪些錯誤模型已經犯過不止一次？
哪些目錄、文件或命令絕對不能誤用？
哪些流程應該改成技能、腳本或命令，而不是常駐上下文？
哪些內容只是介紹，可以刪掉？

最後得到的文件，可能只有幾十行。它不需要完整解釋專案，而是要精確約束行為。

一個好的 Claude.md，應該像這樣：

# 工作規則

- 只改與當前任務相關的文件。
- 不要修改 public/、resources/ 這類構建產物目錄。
- Hugo 文章改寫只處理 index.zh-cn.md，不生成其他語言版本。
- 如果涉及部署，先執行 hugo 構建，再執行既有 rsync 腳本。
- 遇到已有使用者改動時，不要回滾，必須基於現狀繼續修改。

它短，但每一條都能影響實際行為。這樣的內容才值得長期佔用上下文。

最後一句

Claude.md 的價值不在於讓 AI「知道更多」，而在於讓 AI「少犯固定錯誤」。

它不是知識庫，也不是專案百科，而是 AI 編程過程裡的長期約束文件。
寫得越具體、越短、越貼近真實錯誤，它越有用；寫得越泛、越長、越像專案介紹，它越可能拖慢模型，甚至讓結果變差。

把全域記憶當成稀缺資源，而不是無限草稿紙。這大概就是寫好 Claude.md 最重要的一條原則。

GPT 5.5、Claude Opus 4.7、DeepSeek V4、Qwen 3.6 Max 怎麼選

Tue, 28 Apr 2026 22:18:00 +0800

如果你現在只想知道一句話答案，那可以先記這個版本：

要最穩、最省時間，優先看 GPT 5.5
要頁面觀感、創意和展示感，Claude Opus 4.7 還是強
要看國產模型裡誰最接近第一梯隊，Qwen 3.6 Max 現在很有競爭力
DeepSeek V4 不是不能打，但波動比前面幾家更明顯

很多人問「現在最強編程 AI 到底是誰」，其實問到最後，通常不是在問排行榜，而是在問一件更實際的事：
我現在要寫頁面、做 demo、生成小工具、補互動，哪一個最容易一次就給我能用的東西。

從這個角度看，這幾家模型的差別已經很清楚了。

先說總判斷

如果把 GPT 5.5、Claude Opus 4.7、DeepSeek V4、Qwen 3.6 Max 放在一起看，綜合能力最穩的還是 GPT 5.5。

它不一定每次都是最花俏的那個，但它很少讓你明顯失望。速度快，第一次生成的完成度高，邏輯、互動、動效、小遊戲這一類綜合任務通常都比較順。

Claude Opus 4.7 的特點很不一樣。它最強的地方不是「最穩」，而是頁面氣質、UI 組織和展示感。很多時候你一打開它寫的東西，會先覺得「這個看起來像回事」。如果你更在意頁面呈現，它還是很值得看。

Qwen 3.6 Max 是這幾家裡最值得重新看的一個。它已經不是「國產裡能用」這個級別了，而是有些場景下真的能和 GPT 5.5 直接拼效果。尤其是前端頁面、視覺完成度、擬真感這些部分，它已經開始有明顯存在感。

DeepSeek V4 的問題不是完全不行，而是不夠穩。它能寫出來的時候並不弱，甚至有些場景還不錯，但上下限差得比另外幾家更明顯。你有時候會覺得它挺能打，有時候又會覺得怎麼突然掉下去了。

`GPT 5.5` 強在哪

如果你平時最常做的是這些事：

直接生成一個完整網頁
做帶動效的小 demo
寫有一點邏輯的互動頁面
生成小遊戲或多狀態互動
想盡量少返工

那 GPT 5.5 基本還是最穩的答案。

它的優勢主要有幾個：

出代碼速度快
第一次成品可用度高
邏輯和互動比較少出硬傷
綜合題表現穩定

說得更直接一點，GPT 5.5 最像一個「你把需求丟過去，它大概率能先把地基搭對」的模型。
很多人真正缺的不是某一項最驚艷，而是第一版別翻車。這件事上它現在還是最讓人省心。

當然，它也不是完全沒有短板。

某些偏視覺表現的頁面，不一定是最有驚喜的
有時候太穩了，反而少一點設計感上的記憶點

所以如果你問「要一個預設推薦」，那還是 GPT 5.5。
但如果你問「要不要只看它」，答案也不是。

`Claude Opus 4.7` 適合什麼人

Claude Opus 4.7 這類模型的吸引力，更多來自頁面觀感。

它的長處通常是：

UI 結構更順
視覺表現更完整
某些頁面更有展示感
在可視化和創意感上更容易出彩

如果你讓模型去做的是這些東西：

演示頁面
數據展示頁面
強調觀感的小網頁
想要一打開就「看起來比較高級」的結果

那 Claude 依然值得進前排。

不過它的問題也一直比較明顯：

穩定性不如 GPT 5.5
有時看著不錯，但細節邏輯會偏掉
個別場景裡會出現功能能跑，但核心體驗不夠準的情況

所以 Claude 更像一個有審美加成的前端型選手。
你要是更看重頁面「長得好不好」，它很有優勢；你要是最怕第一次輸出就出邏輯問題，那還是得更謹慎一點。

`Qwen 3.6 Max` 為什麼值得認真看

這幾家裡，Qwen 3.6 Max 給人的最大變化感最明顯。

以前很多人看國產編程 AI，更多是抱著「能不能跟上」的心態。現在看 Qwen 3.6 Max，已經是另一種問題了：
它在一些前端直出場景裡，到底能不能直接和國外頭部模型打。

它現在比較突出的地方有這些：

頁面觀感不錯
某些動效和擬真效果做得挺好
生成結果比較有完成感
有些題目裡，效果已經能接近甚至咬住 GPT 5.5

這說明一件事：
如果你的使用場景偏網頁、偏前端、偏展示結果，那 Qwen 3.6 Max 已經不是「備用選項」，而是可以認真放進主選名單的模型。

當然，它還沒有穩到完全沒有短板。

互動邏輯題上，偶爾還是會掉一點完成度
有些頁面很好看，但有些任務又會突然平一點
起伏比 GPT 5.5 還是大一些

但整體上，它現在的存在感已經非常強了。
如果你想知道「國產模型裡現在最該重點看誰」，那 Qwen 3.6 Max 很難繞開。

`DeepSeek V4` 現在處在什麼位置

DeepSeek V4 的情況稍微複雜一點。

它的問題不是完全做不好，而是你不太容易預判它這次會落在哪個區間。
有時候它能把事情做出來，觀感和功能都不算差；有時候遇到稍微複雜一點、同時要求動畫、邏輯、數據表現的任務，它又容易掉鏈子。

它目前給人的感覺更像這樣：

能力有
不算弱
某些題目可以交卷
但穩定性還不夠讓人完全放心

這就決定了它現在更適合什麼樣的人。

如果你願意多試幾次、能接受偶爾需要重來、或者你本來就會自己檢查和修代碼，那 DeepSeek V4 還是可以繼續用。
但如果你就是想少折騰、想把第一次生成成功率放在前面，那它現在還不是最穩的答案。

普通用戶到底該怎麼選

如果你不是做模型評測，而是真的想拿來幹活，那其實可以直接按用途選。

1. 想少折騰，想提高第一次成功率

選 GPT 5.5。

它最適合的就是「我給需求，你先給我一版能用的」。
尤其是你沒有太多時間來回調、反覆修的時候，它的綜合穩定性最有價值。

2. 更看重頁面展示感和視覺完成度

選 Claude Opus 4.7。

如果你想要的是一個看起來更像成品的頁面，或者你做的是偏演示型、展示型的東西，Claude 的優勢會更容易體現出來。

3. 想重點看國產裡最強的前端直出能力

優先看 Qwen 3.6 Max。

它現在已經不是「將就用」，而是真的可以拿來正面比較。
如果你的任務偏網頁、偏動效、偏展示，Qwen 的競爭力已經很實際了。

4. 能接受波動，想繼續觀察國產綜合能力

可以繼續看 DeepSeek V4。

它的問題不是沒實力，而是發揮不夠整齊。
如果後面穩定性繼續補上，它的存在感還會更強。

最後一句話

現在這幾家主流編程 AI，差距已經不再是「誰能寫、誰不能寫」，而是「誰更穩、誰更好看、誰更適合你的任務」。

如果你就想要一個最省事的答案，GPT 5.5 還是第一選擇。
如果你想要更強的展示感，Claude Opus 4.7 仍然很有味道。
如果你關心國產模型裡誰最值得認真看，Qwen 3.6 Max 現在已經站到很靠前的位置。
DeepSeek V4 則更像一個還在繼續補穩定性的強力選手。

真要壓成一句最短結論，就是：

最穩看 GPT 5.5，最有觀感看 Claude，國產裡最值得重點看的是 Qwen 3.6 Max。

為什麼馬斯克和 SpaceX 要拿下 Cursor 的 600 億美元收購期權

Tue, 28 Apr 2026 21:45:47 +0800

如果只看標題，這件事最容易讓人誤解成一句話：馬斯克要讓 SpaceX 花 600 億美元買 Cursor。

但真正值得注意的地方恰恰不是「600 億美元」這個數字本身，而是它拿到的是 收購期權，不是立刻完成的併購。

這兩者差別很大。

簡單說，SpaceX 現在鎖定的是一個未來選擇權：今年晚些時候，它可以選擇以 600 億美元 買下 Cursor，也可以選擇支付 100 億美元，繼續把雙方合作推進下去。這個設計本身就說明，馬斯克和 SpaceX 要的不是一筆單純的財務交易，而是一種 先合作、再觀察、最後決定是否完全併表 的安排。

01 為什麼不是現在就直接買

如果馬斯克和 SpaceX 真只是想把 Cursor 買下來，最簡單的方式當然是直接談收購。

之所以沒有一步到位，通常就意味著現在還有幾件事沒有完全確定：

Cursor 作為產品，到底能不能繼續保持高速增長
SpaceX 和 xAI 提供的算力，能不能真的把 Cursor 推到下一階段
兩邊整合之後，協同效應到底有多大
現在就拍板 600 億美元，是不是對任何一方都太早

所以這份期權的意義很清楚：先把最關鍵的權利拿到手，但不急著今天就把所有錢打出去。

對馬斯克和 SpaceX 來說，這樣更靈活；對 Cursor 來說，這也比「現在就被完全吞進去」保留了更多空間。

02 馬斯克和 SpaceX 真正在意的，不只是 Cursor 本身

從公開資訊看，Cursor 最吸引馬斯克和 SpaceX 的，不只是它是個熱門 AI 編程產品，而是它同時踩中了幾件很關鍵的事：

它已經有成熟的開發者用戶入口
它在 AI 編程這個最熱的賽道上站住了位置
它可以把最真實的工程場景回饋給模型和基礎設施

說得更直接一點，馬斯克和 SpaceX 看中的不是一個單獨的編輯器外殼，而是：

開發者分發渠道
高價值用戶群
AI 編程場景裡的真實使用資料

對 xAI 這種還在追趕 Anthropic 和 OpenAI 的體系來說，這種入口非常貴。

因為大模型競爭走到現在，拼的已經不只是「誰模型分數更高」，還包括：

誰更貼近真實工作流
誰更容易進入開發者日常
誰能拿到更多高品質互動資料

Cursor 恰好就是這樣一個入口。

03 為什麼用「期權」而不是「協議合作」就夠了

如果只是想合作，其實簽一份普通合作協議也行。那為什麼還要加一個 600 億美元 的收購期權？

因為普通合作協議解決不了兩個問題。

1. 防止別人截胡

Cursor 這種公司，最貴的不只是今天的收入，而是它在未來幾年裡可能長成的平台價值。

如果 SpaceX 只是先合作、不鎖權利，那一旦合作跑順了，最後最難受的反而可能是馬斯克這一邊：

產品被合作帶起來了
增長被合作推高了
估值被合作抬上去了
最後卻可能被別的巨頭接走

收購期權解決的就是這個問題。
先不買，但先把優先選擇權握住。

2. 給估值爭議留緩衝區

如果現在直接談併購，最大難點之一就是：600 億美元 到底貴不貴？

這件事現在其實很難下定論，因為 Cursor 還處在極快變化的階段：

今天看，600 億美元很貴
但如果算力補上、模型能力補上、用戶繼續爆發，幾個月後可能又像是另一回事

所以期權是一種很典型的折中辦法：

今天先把價格框架鎖住
明天再根據合作結果決定要不要執行

這比現在就賭死，更像資本和產業結合時會用的打法。

04 為什麼 Cursor 自己也願意

這件事如果只從 Cursor 的角度看，也並不難理解。

Cursor 現在最缺的，不一定是錢本身，而更可能是 更大的算力、更多訓練資源，以及更強的戰略護城河。

公開資訊裡已經明確提到，Cursor 想把訓練往前推，但受限於 compute。和馬斯克體系裡的 SpaceX / xAI 合作，能直接把它接到更大的基礎設施上。

這對 Cursor 的意義非常現實：

模型訓練可以繼續往上拉
產品能力有機會更快升級
不必繼續完全受制於外部大模型供應商

這點尤其關鍵。

因為 Cursor 雖然是熱門 AI 編程產品，但它長期也面臨一個很現實的問題：
它既要和 Anthropic、OpenAI 這類公司合作，又在產品層面和它們直接競爭。

這種關係天然不穩。

而馬斯克的 SpaceX / xAI 提供的是另一條路：把上游模型和下游產品更深地綁在一起。

所以 Cursor 願意給出這份期權，不只是因為價格誘人，也因為它本身確實需要更重的算力和更深的戰略綁定。

05 那為什麼還留了一個 100 億美元的選項

這裡其實最有意思。

公開說法不是「要麼收購，要麼沒下文」，而是「要麼 600 億美元 收購，要麼 100 億美元 繼續合作」。

這意味著雙方從一開始就默認了一件事：
合作本身就是有價值的，即使最後不收購，也不是白做。

這個 100 億美元 選項，本質上像是一個中間態：

如果合作特別順，直接執行收購
如果合作有效，但還沒到併購時機，就用更重的戰略合作繼續綁定

也就是說，馬斯克和 SpaceX 並沒有把問題壓成「買或不買」兩個極端，而是故意留了一條緩衝路線。

這通常說明兩邊都知道，AI 賽道變化太快，今天就做不可逆決定，未必是最優解。

06 從馬斯克和 SpaceX 視角看，這更像一筆「上市前布局」

從外部看，這個動作還有一層非常明顯的資本市場意味。

公開報導裡已經提到，SpaceX 在潛在上市前，正試圖把自己講成一個更強的 AI 故事，而不只是火箭和衛星公司。對馬斯克來說，這也很符合他這幾年一貫的方向：盡量把火箭、算力、模型、分發入口和開發者工作流連成一張更大的技術版圖。

這時候，Cursor 的作用就不只是業務協同，而是敘事協同：

SpaceX 有大規模基礎設施和算力
xAI 有模型和 AI 平台故事
Cursor 有開發者入口和熱門應用層場景

把這三層連起來，講出來的故事會比「單獨做模型」更完整。

所以這份期權也可以理解為一種 先把未來故事線鎖住 的動作。對馬斯克而言，這不只是一次交易條款設計，更像是在提前卡位 AI 編程入口。

它一方面給內部整合留時間，另一方面也給外部市場一個信號：SpaceX 不只是想做 AI 基礎設施，還想往 AI 應用層和開發者工作流裡繼續伸手。

07 一句話總結

馬斯克和 SpaceX 想拿 Cursor 的 600 億美元 收購期權，本質上不是因為他們今天就一定要把 Cursor 整個吞下，而是因為 他們既想先拿到開發者入口和未來收購權，又不想現在就把併購風險、估值風險和整合風險全部一次性吃下去。

所以「期權」這兩個字，反而比「600 億美元」更重要。
這說明 SpaceX 要的不是一錘子買賣，而是一種先鎖位置、再看協同、最後決定是否完全收編的打法。

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

你和模型之間的協作品質，通常會有非常明顯的提升。

因為你終於不是每次都從零開始解釋自己是誰、怎麼工作、哪些事不能做，而是把這些真正沉澱成了環境的一部分。

這才是把一個強模型，真正用成成熟工具的關鍵一步。

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

在 VS Code 裡接入 Claude：從 API 設定到網頁生成

Thu, 16 Apr 2026 17:47:17 +0800

如果你已經開始把大模型帶進日常開發，最直接的感受通常不是「會不會寫程式」，而是「能不能把很多零碎工作一次推進起來」。

這類工具真正有價值的地方，不只是補全幾行程式碼，而是能在編輯器裡同時完成對話、改檔案、預覽結果和繼續迭代。對於簡單頁面、原型驗證、樣式調整和功能補齊，這種工作方式往往比傳統的手動來回切換更順手。

這篇就整理一下，一個比較實用的思路：在 VS Code 裡接入 Claude 一類模型之後，怎麼把它用在真實的頁面生成和小功能迭代上。

一、先把工具鏈接通

這類 AI 編程外掛的核心流程其實都差不多：

在 VS Code 裡安裝支援對話式改程式碼的外掛
在外掛設定裡填入模型服務的 Base URL
設定自己的 API Key
選擇要使用的模型名稱

完成這幾步之後，編輯器裡的 AI 能力才算真正可用。後面的體驗差異，大多不在「能不能用」，而在「模型品質怎麼樣、外掛互動是否順手、生成結果是否穩定」。

如果你之前沒有配過這類外掛，可以把它理解成這樣：

外掛負責把你的自然語言請求變成編輯器裡的操作流程
API 負責把請求送到模型服務
模型負責理解你的需求並回傳程式碼、修改建議或結構化結果

所以真正要配對的，其實就是三件事：外掛、介面位址、模型名稱。

二、適合先從小任務開始

很多人第一次上手，會希望它直接幫自己「做一個完整專案」。這不是不行，但對新手來說，最容易建立正確預期的方式，反而是先從非常小的任務開始。

比如：

生成一個簡單的前端頁面
給現有頁面補一個公告區塊
增加註冊表單
調整介面，讓樣式更正式一些

這種任務有幾個好處：

指令足夠清楚，模型更容易理解
結果可以立刻預覽，回饋很快
你能明顯看到「對話」和「改程式碼」是如何連動的

當需求比較明確時，外掛通常會一邊在側邊欄裡和你對話，一邊直接修改右側檔案。等到任務完成之後，你再看生成結果、預覽頁面、決定要不要繼續追加需求，這個節奏會比純聊天自然很多。

三、真正提效的不是一次生成，而是連續迭代

AI 編程最容易被誤解的一點，是大家總把注意力放在「第一次生成得像不像」。

但在實際使用裡，更重要的往往是第二輪、第三輪還能不能順著改下去。

一個比較常見的過程是：

先讓它快速生成一個能跑的頁面骨架
再追加一兩個明確功能
然後觀察程式碼和介面是否一起變得更完整

如果工具體驗比較順，整個過程會很像你在帶一個執行速度很快的初級開發同事：

你提需求
它先做出一版
你指出哪裡不夠
它繼續修改

這種「連續對話式迭代」比單次生成更接近日常開發場景，也是它最容易拉開效率差距的地方。

四、要學會區分「適合交給 AI 的部分」和「自己順手改更快的部分」

這也是非常關鍵的一點。

像頁面佈局、元件初稿、表單骨架、樣式潤飾、文案占位、重複性程式碼補齊，這些通常都很適合交給 AI 先做。

但如果只是：

改一行按鈕文字
調整一個頁腳說明
換一個很小的樣式細節

很多時候自己直接改會更快。因為這種修改的成本已經低到，不值得再發起一次完整的模型互動。

真正高效的使用方式，不是「什麼都交給 AI」，而是知道什麼時候該讓它一口氣做完大塊工作，什麼時候自己收尾更省時間。

五、API 設定是門檻，但不是難點

不少人卡住，其實不是卡在寫程式，而是卡在外掛設定。

常見需要確認的內容通常包括：

介面位址是不是填對了
密鑰是不是有效
模型名稱是不是和服務端一致
外掛是否要求特定格式的 Base URL

只要這幾項有一項不對，外掛表面上可能還能打開，但真正發請求時就會失敗。

所以如果你發現外掛沒有正常工作，排查順序通常可以很簡單：

先看介面位址
再看密鑰
最後看模型名稱和外掛要求的格式

把這三項核對清楚，大多數接入問題都能快速定位。

六、怎麼看生成結果值不值得繼續用

一個比較實用的判斷標準，不是看它「驚不驚艷」，而是看下面這幾件事：

生成出來的頁面能不能直接跑起來
結構是不是基本清楚
追加需求後有沒有明顯跑偏
改動量變大時，是否還能保持一致性

如果一兩輪對話之後，它已經能把頁面從空白推進到一個可繼續修改的狀態，那這個工具基本就有實用價值了。

反過來說，如果每次生成都需要你大面積返工，那它帶來的就不是提效，而只是把「寫程式」換成了「審程式」。

結語

在 VS Code 裡接入 Claude 一類模型，最值得期待的不是「從此不寫程式了」，而是很多原本零散、重複、容易打斷思路的工作，可以被一次性打包推進。

更現實的用法是：

讓它先搭頁面和功能骨架
用連續對話完成兩三輪迭代
自己處理最後那些細小但確定的修改

這樣配合下來，AI 更像一個加速器，而不是一個必須完全接管開發流程的替代者。

AI編程 on KnightLi的博客

RTK：給 AI 編程代理省 token 的命令列代理工具

它解決的是什麼問題

RTK 的基本工作方式

支援哪些命令

安裝和接入方式

使用時要注意什麼

適合誰用

我的判斷

Codex 官方文章解讀：如何把 Codex 用到極致

持久執行緒

語音輸入

Steering 和 queuing

工具和可觸達範圍

從任何地方繼續工作

自動化

Goals

側邊欄

共享記憶

從程式碼向外擴展

Codex Goal 設定目標失敗：Failed to set goal 怎麼處理

先檢查 goals 功能開關

如果還有問題，檢查設定目錄

Windows 上還要留意安全軟體

判斷是不是 prompt 的問題

小結

Codex Goal 深度解析：讓 AI Agent 連續工作數小時的目標驅動工作流

Codex Goal 解決的不是循環，而是停止條件

Goal 和普通 prompt 的區別

為什麼 LLM judge stop condition 很關鍵

哪些任務適合交給 Goal

哪些任務不適合只靠 Goal

寫好 Goal Prompt 的模板

Goal Buddy 的價值：先幫你把任務說清楚

給 Codex、Claude Code、OpenCode 使用者的實踐建議

小結

Ollama 接入 Codex App：本地大模型如何變成 AI 編程 Agent

先釐清：這不是 OpenAI 全功能永久免費

ollama launch codex-app 做了什麼？

為什麼本地模型接入 Agent 很重要？

本地 Agent 的優勢

1. 成本更可控

2. 可以離線工作

3. 隱私邊界更清楚

模型怎麼選？

硬體門檻沒有想像中那麼高

也可以用 llama.cpp 接 OpenAI-compatible 介面

使用本地 AI Agent 時要注意什麼？

我的理解

參考連結

oh-my-codex：給 Codex CLI 加上工作流、技能和執行時護欄

它到底是什麼

推薦安裝方式

預設工作流

skills 和 agents 提供了什麼

插件形態和執行時狀態

適合誰

使用時要注意什麼

小結

參考資料

OpenAI Symphony 是什麼？Codex 編排、Issue 驅動與 AI Agent 開發工作流

Symphony 解決的不是寫代碼，而是管理 Agent

為什麼是 issue tracker？

它的核心工作流

目標驅動，而不是死板狀態機

和普通 Codex 使用方式有什麼不同？

適合哪些場景？

風險和邊界

我對 Symphony 的理解

參考連結

CLIProxyAPI Management Center：給 CLIProxyAPI 配一個視覺化管理後台

它是什麼

它解決的不是「呼叫模型」，而是「管理模型入口」

典型使用場景

和 CLIProxyAPI 的關係

為什麼新版內建後仍然值得單獨看

部署時最該注意什麼

它適合和哪些東西一起用

使用建議

總結

`ollama launch codex-app` 做了什麼？