開發工具 on KnightLi的博客

Jimmy：把 Evernote、Notion、Google Keep 等筆記匯出轉換成 Markdown

Sat, 30 May 2026 11:55:56 +0800

Jimmy 是一個筆記轉換工具，目標是把不同筆記應用或文件格式裡的內容轉換成 Markdown。它適合想把筆記從封閉應用裡遷出來、放進 Obsidian、Joplin，或者只想長期保存為純文字的人。

專案文件裡的定位很直接：匯出或備份原筆記應用的資料，運行 jimmy 轉換，再把結果匯入 Joplin、Obsidian，或者直接用 VSCode 等文字編輯器查看。

Jimmy 解決什麼問題

很多筆記應用都有自己的匯出格式。換應用時，最麻煩的往往不是文字內容，而是圖片、附件、標籤、內部連結和 front matter 這些結構化資訊。

Jimmy 做的事情就是把這些匯出資料盡量整理成更通用的 Markdown 目錄：

筆記正文轉換為 Markdown。
盡量保留圖片、資源和附件。
盡量保留標籤、外部連結和筆記內部連結。
輸出 Markdown + front matter。
結果可以匯入 Joplin、Obsidian 等工具，也可以直接用文字編輯器查看。

這類工具的意義在於降低遷移成本。筆記一旦變成 Markdown，就不再強綁定某個應用，後續備份、搜尋、版本管理和 LLM 處理都會簡單很多。

支援的筆記應用很多

Jimmy 支援的來源覆蓋面很廣，包括 Anki、Anytype、Bear、CherryTree、ColorNote、Day One、Diaro、Drafts、Dynalist、Evernote、Google Docs、Google Keep、Joplin、Notion、Obsidian、OneNote、QOwnNotes、RedNotebook、Reflect、Roam Research、Signal、Simplenote、Standard Notes、Synology Note Station、Telegram、Tiddlywiki、Turtl、UpNote、Wordpress、Zim、Zoho Notebook 等。

並不是所有來源的保真度都完全一樣。實際遷移時，仍然要先用一小批筆記試跑，重點檢查圖片、附件、標籤、內部連結和日期欄位是否符合預期。

也能轉換普通文件

除了筆記應用匯出，Jimmy 也能處理一些常見文件格式。文件中提到可以轉換單一檔案，也可以遞迴轉換整個資料夾，適合把雜亂的資料目錄整理成 Markdown。

常見支援格式包括：

類型	例子
辦公文件	DOCX、ODT、RTF
標記語言	Asciidoc、DocBook、Markdown、MediaWiki、reStructuredText
網頁與電子書	HTML、MHTML、EPUB
資料與結構化檔案	CSV、OPML、Jupyter Notebook
其他	PDF、EML、Fountain、txt2tags

如果只是把 DOCX、PDF 或 HTML 批量轉成 Markdown，Jimmy 也可以作為一個離線批次處理工具來用。

兩種使用方式

Jimmy 提供 CLI 和 TUI 兩種介面。

介面	適合場景	說明
CLI	批次處理、腳本、完整功能	適合一次性轉換資料夾、寫遷移腳本、指定來源格式
TUI	互動式轉換	適合手動操作，目前功能子集仍處於 beta 狀態

官方 README 給出的 Linux 示例命令如下：

# 使用互動式 TUI 轉換
jimmy-linux tui

# 轉換一個 pandoc 支援的單檔案
jimmy-linux cli libre_office_document.odt

# 轉換整個資料夾
jimmy-linux cli path/to/folder

# 轉換 Google Keep 匯出
jimmy-linux cli takeout-20240401T160516Z-001.zip --format google_keep

這些命令說明它不是只面向某一個筆記應用，而是把「筆記匯出包」和「普通文件目錄」都納入了同一套轉換流程。

它的幾個特點

特點	說明
離線運行	轉換過程不依賴雲服務，適合處理私人筆記
開源	倉庫採用 GPL-3.0 license
跨平台	官方提供 Linux、Windows、macOS 下載
獨立二進位檔	不要求使用者額外安裝 Docker、Python 或 Node.js
不使用 AI	轉換過程不調用 AI，結果更可控，也減少隱私顧慮
Markdown + front matter	方便匯入筆記軟體，也方便後續用 Git 管理

其中「離線」和「不使用 AI」很適合筆記遷移場景。筆記裡經常有私人資訊、工作資料和歷史附件，把轉換放在本地完成，會讓風險邊界更清楚。

適合誰使用

Jimmy 適合幾類人：

想從 Evernote、Notion、OneNote、Google Keep 等工具遷移到 Markdown 的使用者。
想把筆記匯入 Obsidian、Joplin 或其他純文字工作流的人。
想把長期資料保存為未來更容易讀取格式的人。
想把筆記或文件準備成 LLM 可處理文字的人。
需要遞迴轉換 DOCX、PDF、HTML、ODT 等資料夾內容的人。

它不一定適合追求「一鍵完美遷移」的使用者。不同筆記應用匯出格式差異很大，複雜頁面、資料庫、嵌入內容和內部連結都可能需要人工複查。

使用前的檢查建議

真正遷移前，建議按這個順序做：

先從原筆記應用匯出一小批樣本。
用 Jimmy 轉換樣本，而不是一上來轉換全部筆記。
檢查 Markdown 正文、圖片、附件、標籤、建立時間、內部連結。
確認目標應用，例如 Obsidian 或 Joplin，能正確識別目錄結構和 front matter。
再對完整匯出包執行轉換。
保留原始匯出包和轉換結果，至少等確認無誤後再清理。

這個流程雖然慢一點，但能避免遷移後才發現附件遺失、連結斷掉或標籤結構不對。

我的判斷

Jimmy 的價值在於把筆記遷移從「依賴某個應用的匯入器」變成「先轉成通用 Markdown」。它支援的來源很多，輸出也足夠通用，適合把個人知識庫從封閉格式裡釋放出來。

如果你只是偶爾匯出一兩篇筆記，可能用不到它。但如果你有多年積累的筆記、附件和文件目錄，想遷移到 Obsidian、Joplin 或 Git 管理的 Markdown 工作流，Jimmy 很值得試。它最適合做遷移中間層：先把資料變成可讀、可備份、可批次處理的文字，再決定放進哪個筆記系統。

專案連結：marph91/jimmy
文件連結：Jimmy - Note Conversion Tool

Google Pay 與 Wallet 推出 Developer MCP Server：把支付整合接入 AI 助手

Fri, 29 May 2026 15:24:18 +0800

Google Developers 發布了 Google Pay 與 Wallet Developer MCP Server。它面向正在整合 Google Pay API 和 Google Wallet API 的開發者，把官方文件、帳號狀態、整合校驗和部分業務指標接入 MCP 相容的 AI 開發工具。

這類更新看起來不像模型發布那麼熱鬧，但對開發者很實用。支付和錢包整合往往不是「會不會寫程式碼」的問題，而是文件細節多、設定項多、審核要求多、錯誤回饋分散。MCP Server 的價值就在於讓 AI 助手可以在更接近真實上下文的位置幫開發者排查問題。

它解決什麼問題

開發者在接入 Google Pay 或 Google Wallet 時，通常要在多個地方來回切換：

查官方文件和範例程式碼
確認帳號與商戶設定
檢查請求參數和返回錯誤
驗證整合是否符合要求
觀察呼叫表現和關鍵指標

如果只把這些內容當成網頁文件，AI 助手最多只能解釋概念或生成範例。接入 MCP Server 後，助手可以透過工具存取更具體的資訊，從而給出更貼近目前專案狀態的建議。

MCP 在這裡為什麼合適

MCP 的作用是給 AI 應用提供標準化工具介面。對 Google Pay 和 Wallet 這樣的開發者產品來說，它非常適合處理「文件加狀態加校驗」的組合任務。

例如，開發者可以讓支援 MCP 的 AI 工具幫助回答：

目前整合缺了哪些設定
某個 Google Pay 請求為什麼失敗
Wallet pass 定義裡哪些欄位可能不符合要求
程式碼範例應該如何改成目前業務需要的形態
整合上線前還需要檢查哪些項目

這些問題如果只靠大模型記憶，風險很高；如果能結合官方工具和目前帳號資訊，回答就更可操作。

對 AI 程式設計工作流的意義

這次發布也說明一個趨勢：AI 程式設計助手正在從「讀程式碼」走向「讀產品系統」。

過去，開發者讓 AI 幫忙整合支付能力，通常只能把文件片段、錯誤日誌和程式碼貼進去。AI 可以解釋，但不一定知道目前整合的真實狀態。MCP Server 把這部分能力向前推進了一步，讓 AI 助手有機會直接圍繞產品整合環境工作。

這對幾類場景尤其有價值：

新專案首次接入 Google Pay 或 Wallet。
舊專案遷移到新的 API 或設定方式。
上線前做整合檢查。
遇到錯誤碼、審核問題或設定不一致時快速定位。

對團隊來說，收益不只是少查幾頁文件，而是減少「文件理解正確，但設定現場不一致」的摩擦。

它不會替代開發者判斷

支付和錢包相關整合有安全、合規和使用者體驗要求。MCP Server 可以幫助 AI 助手更快找到資訊、檢查狀態、生成建議，但最終仍需要開發者確認程式碼、安全策略、商戶設定和上線流程。

尤其是支付鏈路，不能因為 AI 給出一個看似合理的建議就直接上線。更穩妥的方式是把 MCP 工具當成檢查員和導航員：它能縮短定位時間，但不能替代審核、測試和業務責任。

我的判斷

Google Pay 與 Wallet Developer MCP Server 的意義不在於「又多了一個 MCP 範例」，而在於它把 MCP 放進了一個真實、複雜、強約束的開發者場景。

如果 MCP 只連接文件，它的價值有限；如果它能連接帳號狀態、整合校驗、指標和產品後台，AI 助手就能承擔更多實際開發工作。Google 這次發布正好展示了這個方向。

未來類似能力很可能會出現在更多雲端服務、廣告平台、支付系統和企業 SaaS 裡。開發者要適應的不是「AI 會寫程式碼」，而是「AI 可以透過標準工具介面參與整個整合流程」。

原文連結：Supercharge your integration workflow with the Google Pay & Wallet Developer MCP Server

Remotion：用 React 以程式化方式生成影片

Wed, 27 May 2026 14:39:22 +0800

remotion-dev/remotion 是一個用 React 以程式化方式建立影片的框架。它把影片製作從傳統時間軸工具裡抽離出來，變成可以用元件、狀態、資料、API、CSS、Canvas、SVG、WebGL 和演算法控制的前端工程問題。

專案地址：remotion-dev/remotion

這類工具很適合今天的 AI 編程工作流程：如果一個 agent 能生成網頁、圖表和資料視圖，它也可以繼續生成影片腳本、動畫元件和可渲染的短片。

Remotion 解決的是什麼問題

傳統影片工具擅長人工剪輯，但不擅長規模化、參數化和自動化。

例如這些任務：

為每個使用者生成一支個人化年度回顧影片
根據資料庫自動生成產品示範影片
把圖表、程式碼片段和講解字幕組合成技術短片
批次生成行銷素材、社群媒體短影片或課程片段
用 CI/CD 或後端服務按需渲染影片

如果使用傳統剪輯軟體，這些任務很難完全自動化。Remotion 的做法是把影片當成 React 應用來寫：每一幀都是元件和資料在某個時間點的結果。

為什麼是 React

Remotion README 裡給出的理由很清楚：React 可以複用 Web 技術和元件化能力。

它讓你可以使用：

CSS 做版面配置和動畫
SVG 做向量圖形
Canvas 和 WebGL 做複雜繪製
JavaScript / TypeScript 做變數、函式、API 呼叫、數學和演算法
React 元件做複用、組合和快速迭代

這意味著前端開發者不需要重新學習一套完全陌生的影片 DSL。許多既有的 UI、圖表、設計系統和資料邏輯，都可以遷移到影片生成場景裡。

快速開始

如果已經安裝 Node.js，README 給出的入口命令是：

`1`	`npx create-video@latest`

建立專案後，你通常會撰寫 React 元件來描述畫面，再讓 Remotion 逐幀渲染輸出影片。

更完整的文件可以看：

文件：remotion.dev/docs
API Reference：remotion.dev/api

它適合哪些場景

Remotion 最適合「影片內容由資料或程式碼驅動」的場景。

個人化影片

例如年度回顧、使用者成就、訂單總結、學習報告。每個使用者的資料不同，但視覺結構相同。用 React 元件加資料驅動，會比手工剪輯更自然。

技術示範影片

如果影片裡包含程式碼、圖表、產品介面、步驟動畫和說明文字，Remotion 很適合把這些元素組織成可重複渲染的模板。

資料影片和圖表動畫

資料視覺化本來就是前端強項。Remotion 讓圖表不僅可以出現在網頁裡，也可以沿著時間軸進入影片。

AI 生成影片工作流程

AI agent 可以先生成腳本和素材結構，再生成 Remotion 元件，最後渲染影片。這比讓模型直接生成最終影片更可控，因為中間產物是程式碼，可以檢查、修改、版本管理和複用。

對 AI 編程工具的意義

Remotion 對 Codex、Claude Code、Cursor、Gemini CLI 這類 AI 編程工具特別有意思。

原因是影片生成被拆成了開發任務：

生成 React 元件。
調整樣式和版面。
接入資料。
預覽畫面。
根據回饋修改。
渲染輸出。

這套流程非常適合 agent：每一步都有檔案、有程式碼、有預覽、有明確回饋。相較於「直接生成一個影片檔」，程式碼化影片更容易被審閱和迭代。

如果再結合瀏覽器側邊欄、截圖檢查、自動化渲染和評論回饋，Remotion 可以成為 AI 工作流程裡的影片產物層。

使用前要注意授權

Remotion README 特別提醒：Remotion 有特殊授權，在某些公司使用場景下需要取得 company license。

所以不要只把它當成普通 MIT 小工具來用。個人專案、開源專案、商業專案、企業內部工具，授權要求可能不同。正式用於公司生產前，應該先閱讀它的 LICENSE 頁面和官方授權說明。

這點很重要，尤其是把 Remotion 接進自動化內容生成、行銷素材生成或企業內部影片流水線時。

我的判斷

Remotion 的價值不只是「用 React 做影片」，而是把影片變成可程式化、可複用、可自動化的產物。

對普通前端團隊來說，它適合做資料驅動的影片模板。對 AI 工具來說，它更像一個穩定的輸出目標：模型不需要一次性生成黑盒影片，而是生成可讀、可改、可渲染的 React 程式碼。

如果你的內容需要批次生成、個人化生成、根據資料更新，或者需要讓 agent 反覆調整視覺細節，Remotion 值得放進工具箱裡。它不是傳統剪輯軟體的替代品，而是把影片生產接入軟體工程流程的一種方式。

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 功能本身是否在本機設定裡正常啟用。

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

CLI-Anything：把軟體變成 Agent 可用的命令列

Mon, 25 May 2026 00:24:36 +0800

CLI-Anything 是 HKUDS 開源的 Agent 工具化專案，目標是把原本面向人類 GUI 操作的軟體，轉成 AI Agent 更容易呼叫的命令列介面。它不是重新實作一個簡化版軟體，而是圍繞既有程式碼庫和真實後端生成 CLI harness，讓 Agent 可以透過穩定命令、狀態會話和結構化輸出來完成任務。

這個方向解決的是 Agent 使用軟體時最常見的斷層：GUI 自動化依賴截圖、點擊和座標，容易受介面變化影響；單一 API 又經常覆蓋不完整，Agent 需要自己拼接大量上下文。CLI-Anything 選擇把軟體能力收斂成命令列，因為命令天然適合被模型讀取、組合、驗證，也便於接入腳本和自動化流程。

它怎麼工作

官方倉庫把 CLI-Anything 描述為一套自動生成 CLI 的流水線。給它一個本機軟體原始碼路徑或 GitHub 倉庫地址後，流程會分析程式碼結構、識別後端和資料模型，設計命令分組，再實作 CLI、測試和文件。

生成出來的 CLI 通常包含兩種使用方式：一種是面向連續工作的 REPL，會保留專案狀態；另一種是子命令模式，適合腳本和流水線。命令還會提供 JSON 輸出，方便 Agent 直接解析結果，同時保留人類可讀的格式用於除錯。

官方範例裡，Claude Code 外掛可以這樣使用：

1
2
3

/plugin marketplace add HKUDS/CLI-Anything
/plugin install cli-anything
/cli-anything <software-path-or-repo>

如果已經生成某個軟體的 harness，後續使用方式會更接近普通 Python CLI：

cd <software>/agent-harness
pip install -e .
cli-anything-<software> --help
cli-anything-<software>
cli-anything-<software> --json <command>

適合什麼場景

CLI-Anything 更適合那些「能力在真實軟體裡，但 Agent 不好穩定操作」的場景。例如影像、影片、音訊、辦公文件、3D 建模、資料分析或 AI/ML 工具鏈，只要專案有可分析的程式碼庫、可呼叫的後端或清晰的資料模型，就有機會被包裝成 Agent 可用的命令集。

它的價值不只是在命令列裡多一層封裝，而是把軟體的關鍵操作變成可發現、可組合、可測試的介面。Agent 可以先透過 --help 理解能力，再用 JSON 輸出接收結果，並把多個命令串成工作流。對於需要批次處理、自動驗證和持續迭代的任務，這比臨時讓 Agent 點擊介面更可控。

需要注意的邊界

CLI-Anything 並不等於任何軟體都能立刻無成本接入。它依賴目標軟體的原始碼、後端能力、檔案格式和可測試性；如果一個軟體高度封閉、關鍵邏輯只存在於 GUI 層，生成高品質 CLI 的難度會明顯上升。

官方方法論也強調真實後端和測試驗證，這意味著生成 harness 不是只寫幾個命令包裝腳本就結束。要讓它用於嚴肅工作，還需要確認命令覆蓋範圍、輸出格式、依賴安裝、真實軟體呼叫和端到端測試是否可靠。更現實的用法，是先為一個明確工作流生成 CLI，再透過 refine、test、validate 等命令逐步補齊能力。

小結

CLI-Anything 的思路很直接：不要讓 Agent 去適應脆弱的人類介面，而是為現有軟體補上一層穩定、結構化、可測試的命令列入口。它適合想把專業軟體納入 Agent 工作流的人，也適合研究「Agent 原生軟體」形態的開發者。真正落地時，重點不在於一句命令生成了多少程式碼，而在於生成的 CLI 是否能呼叫真實能力、保持狀態、輸出結構化結果，並經得起測試。

GitHub Spec Kit 是什麼？用規格驅動開發約束 AI 編程

Mon, 25 May 2026 00:19:14 +0800

GitHub 的 Spec Kit 是一個面向 AI 編程的新工具包，目標是幫助開發者實踐 Spec-Driven Development，也就是規格驅動開發。

它解決的問題很直接：現在很多 AI 編程工作流太像「邊聊邊寫」。人類給一個大概想法，Agent 立刻開始改代碼，短期看很快，但需求邊界、驗收標準、技術取捨和任務拆分往往沒有沉澱下來。項目稍微複雜一點，就容易變成一次性的 vibe coding。

Spec Kit 的思路是反過來：先把規格寫清楚，再進入計劃、任務和實作。代碼不再是第一步，規格才是第一步。

Spec Kit 是什麼？

Spec Kit 是 GitHub 開源的規格驅動開發工具包。它提供 specify CLI、模板、腳本和面向 AI coding agent 的命令，讓團隊可以圍繞同一套結構化產物推進開發。

它強調的不是「讓 AI 少問問題」，而是讓 AI 在寫代碼前先生成並完善這些內容：

項目原則：團隊對品質、測試、體驗、性能等方面的約束；
功能規格：要做什麼、為什麼做、使用者故事和功能需求；
技術計劃：使用什麼技術棧、如何落地、有哪些架構決策；
任務清單：把計劃拆成可執行步驟；
實作過程：按任務逐步修改代碼，而不是一次性亂改。

這套流程讓 AI 編程更像工程協作，而不是一次提示詞表演。

基本使用流程

官方 README 給出的入門流程大致是這樣：

1
2
3

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z
specify init my-project --integration copilot
cd my-project

初始化後，項目裡會生成 .specify 目錄、模板、腳本和與 Agent 整合的命令。隨後在支援的 AI coding agent 中使用 /speckit.* 命令推進開發。

典型順序是：

/speckit.constitution
/speckit.specify
/speckit.clarify
/speckit.plan
/speckit.tasks
/speckit.implement

其中 /speckit.constitution 用來建立項目原則，/speckit.specify 描述產品需求，/speckit.clarify 補齊模糊點，/speckit.plan 生成技術計劃，/speckit.tasks 拆任務，最後由 /speckit.implement 執行實作。

這和直接對 Agent 說「幫我做一個應用」差別很大。Spec Kit 要求你把「做什麼」和「怎麼驗收」先說清楚，再讓 Agent 動手。

它改變了 AI 編程的入口

傳統 AI 編程經常從代碼開始：

`1`	`我想做一個任務管理應用，幫我寫出來。`

Spec Kit 更像這樣：

先定義這個任務管理應用的使用者、場景、功能邊界、驗收標準和非目標；
再根據這些規格選擇技術方案；
然後拆成任務；
最後逐步實作。

這個變化很重要。因為 AI 最擅長根據上下文執行，但如果上下文本身是鬆散的，執行速度越快，偏離方向也可能越快。Spec Kit 把上下文變成文件和模板，讓需求、計劃和任務都能被 review、修改和版本管理。

換句話說，它不是讓 AI 更「自由」，而是讓 AI 在更清晰的工程軌道上自由發揮。

核心命令怎麼理解？

`/speckit.constitution`

這是項目的「憲法」。它會生成或更新 .specify/memory/constitution.md，用於記錄項目長期遵守的原則，例如代碼品質、測試標準、使用者體驗一致性、性能要求和技術決策規則。

這一步適合寫團隊共識，而不是單個功能需求。

`/speckit.specify`

這是功能規格階段。你需要描述要構建什麼、使用者是誰、解決什麼問題、有哪些核心流程。

官方特別強調：這一階段不要過早關注技術棧。先把 what 和 why 寫清楚，再討論 how。

`/speckit.clarify`

這是補問題的階段。很多需求第一次寫出來都會有空洞：權限怎麼處理？異常狀態是什麼？數據是否持久化？邊界條件如何驗收？

/speckit.clarify 的價值，是讓 Agent 主動發現規格中的不確定點，並把回答記錄回規格文件，減少後面返工。

`/speckit.plan`

這是技術計劃階段。到了這裡，才開始明確框架、數據庫、架構、API、測試策略和約束。

如果說 /speckit.specify 是產品語言，/speckit.plan 就是工程語言。

`/speckit.tasks`

這一步把計劃拆成可執行任務。好的任務清單應該能讓 Agent 逐步推進，也能讓人類看懂每一步的目的。

`/speckit.implement`

最後才進入實作。Agent 根據前面沉澱的規格、計劃和任務修改代碼。這時它不再是憑一段大 prompt 猜需求，而是在一組結構化文件裡執行。

為什麼它適合 AI 編程？

Spec Kit 的價值不在於某個神奇命令，而在於它把 AI 編程中最容易缺失的東西補了回來：

需求可審查；
計劃可討論；
任務可追蹤；
決策有上下文；
產物可以進入 Git 歷史；
團隊可以複用模板和原則；
Agent 的實作不再只依賴一次性聊天記錄。

這對複雜項目尤其有用。越是多人協作、長期維護、品質要求高的項目，越不能只靠臨時 prompt 驅動開發。

擴展和 Preset

Spec Kit 還提供了兩類自訂能力：

Extensions：增加新命令、新模板或外部工具整合；
Presets：改變現有規格、計劃、任務模板的格式和術語。

簡單理解：如果要新增能力，用 Extension；如果要改造工作流風格，用 Preset。

例如，團隊可以透過 Preset 強制加入安全審查、合規追蹤、領域術語或測試優先規則；也可以透過 Extension 增加 Jira 整合、代碼審查、項目健康檢查等新階段。

這說明 Spec Kit 並不想把所有團隊鎖進同一種流程，而是提供一個可擴展的規格驅動骨架。

適合誰用？

Spec Kit 適合這些場景：

用 AI coding agent 做新項目原型；
想把 vibe coding 變成可複盤流程；
團隊希望統一 AI 生成代碼前的需求和計劃格式；
項目需要明確驗收標準和測試要求；
希望把需求、計劃、任務和實作過程都納入版本管理；
正在探索 GitHub Copilot、Claude Code、Codex CLI 等工具的團隊化用法。

它不一定適合非常小的一次性腳本。對於幾行代碼能解決的問題，完整規格流程可能顯得重。但只要任務開始涉及多個頁面、多個模組、狀態管理、權限、數據模型或長期維護，Spec Kit 的結構化收益就會變明顯。

我的理解

Spec Kit 代表的是 AI 編程工具的一種重要轉向：從「讓 Agent 更快寫代碼」，轉向「讓 Agent 更可靠地參與軟件工程」。

過去的 AI 編程關注提示詞和模型能力，Spec Kit 更關注流程、產物和約束。它提醒我們：AI 寫代碼越快，規格、計劃和驗收就越不能省。

如果你已經習慣讓 AI 直接實作功能，可以嘗試用 Spec Kit 改變起手式：

先讓 AI 幫你把需求寫成規格，再讓它寫代碼。

這一步看似變慢，實際是在減少後面「代碼寫完了，但不是我想要的」的返工。

參考連結

github/spec-kit

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 編程工具的關鍵分水嶺。

參考連結

browser-harness 是什麼？讓 AI Agent 接管真實 Chrome 的瀏覽器自動化工具

Sun, 24 May 2026 17:19:54 +0800

browser-use/browser-harness 是一個面向 AI Agent 的瀏覽器控制工具。它的目標不是再做一層複雜的自動化框架，而是把大模型直接連到真實 Chrome，透過 CDP 完成瀏覽、點擊、截圖、下載、上傳和表單操作。

專案 README 對自己的定位很明確：用一層很薄、可編輯的 CDP harness，讓 LLM 直接連接真實瀏覽器；當任務中缺少 helper 時，Agent 可以在執行過程中補上程式碼，並把可重用經驗沉澱成 domain skills。

這類工具值得關注，是因為瀏覽器仍然是很多真實工作的入口：後台系統、SaaS 面板、電商頁面、招聘網站、CRM、報銷系統、雲控制台、文件平台，往往沒有穩定 API，或者 API 權限比網頁權限更難拿到。讓 Agent 能可靠操作瀏覽器，本質上是在補齊自動化的最後一段距離。

browser-harness 是什麼

從結構看，browser-harness 更像一個給 Agent 用的瀏覽器執行環境，而不是普通使用者手動點擊的瀏覽器外掛。

它的核心思路有幾個：

直接連接 Chrome 或 Chromium。
透過 CDP WebSocket 操作頁面。
讓 Agent 組合截圖、座標點擊、DOM、網路請求和原始 CDP 完成任務。
把任務相關 helper 放在 agent-workspace/agent_helpers.py。
把站點相關經驗沉澱到 agent-workspace/domain-skills/。
保持核心很薄，避免做成龐大的自動化平台。

README 提到，專案核心架構大約是 4 個核心檔案、約 1000 行程式碼，主要包括 install.md、SKILL.md、src/browser_harness/、agent-workspace/agent_helpers.py 和 agent-workspace/domain-skills/。

這種設計的重點不是內建所有網站能力，而是給 Agent 一個足夠貼近真實瀏覽器的操作層，讓它在具體任務裡補齊缺失能力。

它和傳統瀏覽器自動化有什麼不同

傳統瀏覽器自動化通常圍繞測試框架展開，例如 Playwright、Selenium 或 Puppeteer。它們適合寫確定性的測試腳本：打開頁面、定位元素、點擊、斷言結果。

browser-harness 面向的是另一類任務：使用者說一句目標，Agent 自己探索頁面、判斷狀態、處理彈窗、補 helper、複用站點經驗。它強調的是互動過程中的適應性。

差異可以這樣理解：

Playwright 更適合人寫腳本，Agent 執行腳本。
browser-harness 更適合 Agent 邊看頁面邊行動。
傳統自動化偏固定流程。
browser-harness 偏開放任務。
傳統腳本常依賴選擇器。
browser-harness 鼓勵先截圖、再按可見介面行動，必要時再回到 DOM 或 CDP。

這不表示它要取代 Playwright。對穩定測試來說，Playwright 仍然更成熟。browser-harness 的價值在於把真實網頁變成 Agent 可操作的環境，尤其適合頁面結構複雜、步驟不固定、需要臨場判斷的任務。

為什麼強調真實 Chrome

很多瀏覽器 Agent 工具會使用隔離的無頭瀏覽器。這樣部署簡單，也適合批量任務，但它有一個現實問題：使用者真實工作裡的登入狀態、擴充功能、歷史記錄、書籤和日常瀏覽器環境，不一定能直接複用。

browser-harness 支援連接本機 Chrome，也支援 Browser Use cloud browser。對本機瀏覽器，它提供兩種方式：

透過 chrome://inspect/#remote-debugging 允許目前 Chrome 實例被連接。
用 --remote-debugging-port=9222 --user-data-dir=... 啟動一個隔離 profile。

如果要讓 Agent 幫你處理真實帳號裡的任務，專案文件更傾向第一種方式，因為它能複用日常 Chrome 的登入狀態、擴充功能和書籤。如果要做無人值守自動化，或者不希望被彈窗打斷，則更適合使用隔離 profile 或雲瀏覽器。

這裡的取捨很清楚：真實瀏覽器更貼近使用者工作流，但安全邊界也更敏感；隔離瀏覽器更適合自動化，但需要重新處理登入和環境。

可編輯 helper 與 domain skills

browser-harness 最有意思的地方，是它把「Agent 會學到什麼」設計進了專案結構。

agent-workspace/agent_helpers.py 用來放任務中臨時補出的 helper。比如 Agent 做檔案上傳時發現現有能力不夠，可以補一個穩定的上傳函式；下次再遇到類似頁面，就不用從零開始。

agent-workspace/domain-skills/ 則用來放站點級經驗。README 裡舉的方向包括 LinkedIn outreach、Amazon 下單、報銷系統等。專案建議不要手寫這些 skill，而是讓 Agent 在真實任務中發現可重用流程後再生成，這樣更貼近實際頁面行為。

這個思路很適合瀏覽器自動化。因為網頁自動化的難點往往不是「怎麼點擊按鈕」，而是：

某個網站的登入後頁面怎麼跳轉。
哪些彈窗會擋住主流程。
哪些 selector 穩定，哪些只是臨時樣式名。
上傳、下載、iframe、shadow DOM、跨域元件怎麼處理。
某個後台系統有哪些隱藏等待和非同步狀態。

這些知識如果只留在一次執行日誌裡，很快就會丟掉。把它們沉澱成 domain skills，才可能讓 Agent 越用越順。

適合哪些場景

browser-harness 更適合以下任務：

幫使用者操作真實網頁後台。
在沒有 API 的系統裡完成重複流程。
登入狀態依賴強的個人或企業網頁任務。
需要截圖判斷頁面狀態的複雜互動。
Agent 需要在執行中補工具、補站點經驗。
多個子 Agent 各自使用獨立瀏覽器執行任務。
研究瀏覽器 Agent 的執行環境設計。

具體例子包括：整理網頁表格、提交內部系統表單、下載帳單、上傳檔案、處理報銷流程、檢查訂單狀態、在 SaaS 控制台裡配置資源、從登入後的網頁提取資訊。

如果任務只是抓取靜態網頁，未必需要瀏覽器。專案自己的 SKILL.md 也提到，靜態頁面可以直接用 HTTP 批量取得；瀏覽器應該留給真正需要頁面狀態、登入狀態和互動的場景。

需要注意的風險

讓 AI Agent 接管真實 Chrome，很強，也很危險。

第一，權限邊界要清楚。真實 Chrome 裡可能有信箱、支付後台、雲控制台、公司系統和個人帳號。Agent 一旦能操作瀏覽器，就等於獲得了這些網頁權限的一部分。

第二，不要把憑證交給模型。遇到登入頁、支付驗證、二次確認等敏感步驟，應該讓使用者自己處理。Agent 可以等待登入完成，但不應該從截圖裡讀取或輸入密碼、驗證碼、支付資訊。

第三，自動化不等於可託管。很多網頁任務看似簡單，但中間可能出現風控、誤點擊、資料刪除、批量提交、不可逆操作。適合先從唯讀、低風險、可回復的流程開始。

第四，domain skills 需要避免洩露隱私。站點經驗可以公開，但不要把帳號、內部 URL、客戶資料、座標流水或一次性任務細節寫進去。

第五，真實瀏覽器連接方式要謹慎選擇。如果要複用日常登入狀態，使用目前 Chrome 很方便；如果要跑長時間自動化，隔離 profile 或雲瀏覽器更可控。

對 AI Agent 工具的意義

browser-harness 代表了一種很務實的 Agent 工具路線：少做平台，多給模型一個可以直接觸達真實環境的介面。

過去很多 Agent 失敗在兩端。一端是模型會推理，但摸不到真實頁面；另一端是自動化框架很強，但需要人先把流程寫死。browser-harness 試圖把這兩端接起來：瀏覽器負責真實世界的狀態，Agent 負責觀察、判斷和補工具。

這也是「自我改進 harness」的意義。它不是說 Agent 會神奇地變聰明，而是把可重用的操作經驗放到專案結構裡，讓下一次任務少走彎路。

對開發者來說，browser-harness 的價值主要在三個層面：

作為個人 Agent 的瀏覽器控制層。
作為研究瀏覽器自動化和 Agent 工作流的樣本。
作為把網頁流程變成可重用技能的實驗框架。

它不是所有瀏覽器自動化問題的答案，但它給出了一個清晰方向：當 Agent 真正要幫人做事時，工具層不只要能呼叫 API，也要能理解和操作人類每天使用的網頁介面。

簡單結論

browser-use/browser-harness 值得關注，不是因為它包裝了多少高階功能，而是因為它把瀏覽器 Agent 的幾個關鍵問題擺在了台面上：真實 Chrome、CDP、截圖驅動、可編輯 helper、站點技能沉澱，以及使用者權限邊界。

如果你只是寫穩定端到端測試，繼續用 Playwright 或 Selenium 就很好。如果你想讓 Codex、Claude Code 這類 Agent 直接幫你處理真實網頁任務，browser-harness 提供了一個更貼近 Agent 工作方式的入口。

真正使用時，建議從低風險任務開始：先讓它讀頁面、截圖、提取資訊，再逐步嘗試點擊和提交。等你確認它能穩定識別頁面狀態，再考慮讓它接管更長的流程。

參考資料：

GitHub 專案：https://github.com/browser-use/browser-harness
README：https://github.com/browser-use/browser-harness/blob/main/README.md
安裝文件：https://github.com/browser-use/browser-harness/blob/main/install.md
使用說明：https://github.com/browser-use/browser-harness/blob/main/SKILL.md

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 呼叫口還高。把它放在可信網路裡，用認證保護好，再去享受視覺化管理帶來的省心。

參考資料：

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

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

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

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

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

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

它真正解決的痛點

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

比如：

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

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

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

能力概覽

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

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

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

它適合誰用

CLIProxyAPI 更適合下面幾類人。

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

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

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

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

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

和普通 API 中轉有什麼不同

普通 API 中轉服務一般是：

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

CLIProxyAPI 的鏈路更像：

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

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

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

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

使用時最容易誤解的地方

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

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

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

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

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

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

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

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

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

管理和監控怎麼辦

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

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

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

一個比較合理的使用姿勢

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

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

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

安全邊界也要想清楚

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

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

總結

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

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

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

參考資料：

讓 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、成本、日誌都盡量掌握在自己手裡，本機閘道更適合長期折騰。

參考資料：

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

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

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

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

它主要解決什麼痛點

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

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

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

安裝方式

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

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

Windows PowerShell 可以使用：

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

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

`1`	`npx @colbymchenry/codegraph`

或者全域安裝：

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

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

初始化專案

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

1
2

cd your-project
codegraph init -i

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

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

`1`	`codegraph uninstall`

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

為什麼它對 Agent 有用

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

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

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

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

核心能力

1. 智慧上下文構建

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

2. 全文搜尋

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

3. 影響分析

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

4. 自動保持新鮮

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

5. 多語言支援

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

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

6. Web 路由感知

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

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

本地優先的設計

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

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

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

適合哪些場景

CodeGraph 更適合這些場景：

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

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

使用時要注意什麼

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

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

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

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

小結

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

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

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

參考資料：

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

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

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

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

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

這個倉庫是什麼

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

目錄主要分成兩塊：

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

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

如何安裝插件

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

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

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

`1`	`/plugin > Discover`

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

插件長什麼樣

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

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

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

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

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

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

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

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

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

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

為什麼插件系統重要

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

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

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

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

對開發者有什麼用

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

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

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

安全邊界不能忽略

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

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

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

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

和社群 marketplace 的關係

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

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

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

小結

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

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

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

參考資料：

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

oh-my-pi 是什麼？一個把終端機、IDE 和除錯器打通的 AI 程式設計助手

Sat, 23 May 2026 19:02:20 +0800

oh-my-pi 是一個面向終端機和編輯器的 AI Coding Agent。它來自 Mario Zechner 的 Pi 專案分支，由 can1357 繼續擴展，目標不是只做一個命令列聊天介面，而是把檔案讀取、程式碼搜尋、結構化編輯、LSP、除錯器、瀏覽器、子代理和多模型提供商接到同一個編程工作流裡。

從專案 README 來看，它更像一套 AI 編程工具底座：終端機裡可以直接互動，編輯器可以透過 ACP 接入，Node 專案也可以透過 SDK 嵌入。對已經在用 Claude Code、Codex CLI、Cline、Cursor 或其他 Agent 工具的人來說，oh-my-pi 值得關注的地方在於它把很多原本分散在外部工具裡的能力做成了內建工具面。

它主要解決什麼問題

很多 AI 編程工具的短板不在模型本身，而在工具介面。模型想改程式碼時，如果只能拿到粗糙的全文、脆弱的字串替換和一次性的 shell，失敗率就會被工具鏈放大。

oh-my-pi 的思路是把這些常見摩擦點壓低：

讀取檔案時優先給結構化摘要，而不是把整份檔案塞進上下文。
搜尋、glob、find、語法高亮、token 計數等能力盡量放進原生實作，減少對外部命令的依賴。
寫程式碼時接入 LSP，讓重新命名、引用查找、檔案移動更接近 IDE 行為。
除錯時接入 lldb、dlv、debugpy 等 DAP 工具，而不是只靠日誌和猜測。
複雜任務可以拆給子代理，並用結構化結果返回。
對編輯操作使用內容錨點和預覽機制，降低錯誤 patch 直接落盤的機率。

這些設計說明它關注的不是「模型會不會回答」，而是「模型能不能穩定完成一次真實程式碼修改」。

安裝方式

專案提供了幾種安裝入口。macOS 和 Linux 可以使用安裝腳本：

`1`	`curl -fsSL https://omp.sh/install \| sh`

如果使用 Bun，官方推薦全域安裝 npm 套件：

`1`	`bun install -g @oh-my-pi/pi-coding-agent`

Windows PowerShell 可以使用：

`1`	`irm https://omp.sh/install.ps1 \| iex`

專案 README 還提到可以透過 mise 固定版本：

`1`	`mise use -g github:can1357/oh-my-pi`

安裝前要注意 Bun 版本要求。README 中標註的平台範圍包括 macOS、Linux、Windows，並要求 bun >= 1.3.14。

值得關注的能力

1. 工具呼叫不只停留在 shell

oh-my-pi 內建了檔案讀取、搜尋、寫入、編輯、AST 編輯、瀏覽器、任務拆分、除錯、LSP 等工具。README 中提到它有 32 個內建工具、13 個 LSP 操作和 27 個 DAP 操作。

這意味著 Agent 不必把所有事情都包裝成命令列輸出。比如查引用可以走 LSP，讀 PR 或 issue 可以走統一的檔案式介面，網頁和 PDF 可以被轉換成帶連結結構的 Markdown，再交給模型處理。

2. LSP 接入更適合真實程式碼庫

對大型專案來說，重新命名和移動檔案最怕漏掉 re-export、別名匯入、barrel file 或跨目錄引用。oh-my-pi 的 README 特別強調寫入路徑會接入 LSP，例如檔案重新命名會經過 workspace/willRenameFiles，讓編輯更接近 IDE 的語意操作。

這類能力適合 TypeScript、Rust、Go、Python 等專案裡的日常重構，尤其是那些「手動改能改，但很容易漏一個引用」的場景。

3. 除錯器是一級工具

很多 AI 編程流程遇到崩潰時，仍然停留在加日誌、重新執行、再讀輸出。oh-my-pi 把 DAP 除錯器接入工具面，README 裡舉了 C 程式用 lldb、Go 服務用 dlv、Python 行程用 debugpy 的例子。

這會改變 Agent 處理 bug 的方式：它可以暫停行程、查看堆疊框架、讀局部變數，再決定下一步，而不是只靠錯誤文字猜測。

4. Hashline 編輯降低 patch 失敗率

專案強調的 Hashline 是一種基於內容錨點的編輯方式。它的目標是讓模型指向要修改的內容錨點，而不是反覆輸出大段 diff。這樣做的好處是減少空格、上下文過期、字串匹配失敗造成的編輯錯誤。

對 Agent 工具來說，這類機制很重要。模型能力再強，如果寫入介面經常失敗，最終體驗仍然會變成反覆重試。

5. 子代理和工作區隔離

README 中介紹了 task 子代理能力：一個任務可以拆給多個隔離 worker，結果再以結構化物件返回。專案還包含工作區隔離相關實作，用來支援並行任務、分支探索和避免互相覆蓋。

這適合程式碼審查、遷移、批量修復、測試定位等任務。真正的價值不只是「並行更快」，而是讓不同探索路徑之間的上下文和檔案改動更清楚。

6. 相容已有規則和配置

oh-my-pi 首次執行時會讀取已有工具留下的規則和配置，包括 .claude、.cursor、.windsurf、.gemini、.codex、.cline、.github/copilot 和 .vscode 等目錄。

這點很實用。很多團隊已經為不同 AI 工具寫過規則，如果每換一個工具都要遷移一遍，成本會很高。oh-my-pi 的做法是盡量直接繼承已有上下文。

四種入口

專案提供了四類使用入口：

互動式 TUI：在終端機裡直接執行 omp。
一次性命令：用 omp -p 發送單次 prompt。
Node SDK：透過 @oh-my-pi/pi-coding-agent 嵌入到 Node 或 TypeScript 專案。
RPC / ACP：透過 stdio 或 Agent Client Protocol 接入其他程式和編輯器。

這說明它不只面向個人終端使用者，也給 IDE、插件、自動化平台和內部工具留了整合空間。

適合誰嘗試

oh-my-pi 比較適合這幾類使用者：

經常在終端機裡做程式碼修改、除錯和審查的人。
已經在使用 AI Coding Agent，但覺得檔案讀取、patch、搜尋或除錯鏈路不夠穩的人。
想把 Agent 接入編輯器、RPC 或 Node 服務的開發者。
需要在一個工具裡切換多模型和多提供商的人。
對 LSP、DAP、AST 編輯和子代理這些底層能力感興趣的工具開發者。

如果只是想要一個開箱即用的聊天式程式碼助手，學習成本可能會偏高。它更適合願意理解工具鏈，並把 Agent 當成可配置開發環境的人。

使用時要注意什麼

第一，oh-my-pi 仍然是快速演進中的開源專案。倉庫提交頻繁，issue 和 PR 數量也不少，安裝和使用時要預期到變化。

第二，它的能力邊界和本地環境強相關。LSP、除錯器、Bun、模型提供商認證、終端環境、Windows 或 Unix 差異都會影響體驗。

第三，內建工具多不等於每個場景都應該全開。實際使用時更適合按任務啟用需要的工具，把規則、權限和工作區邊界配置清楚。

第四，AI Agent 能寫程式碼，也能誤改程式碼。即使有預覽和錨點編輯機制，重要專案仍然要保留版本控制、測試和人工審查。

小結

oh-my-pi 的亮點不在於又做了一個 AI 終端殼，而在於它把 AI 編程中最容易拖後腿的工具層重新整理了一遍：檔案讀取、搜尋、編輯、LSP、除錯、瀏覽器、子代理和 SDK 都被放進同一個 Agent 工作流。

它適合關注 AI 編程基礎設施的人，也適合想比較不同 Coding Agent 路線的開發者。當前 AI 編程工具的競爭，已經不只是模型回答品質的競爭，也是在比誰能把模型穩定接入真實程式碼庫、真實除錯流程和真實團隊規則。oh-my-pi 正是在這個方向上給出了一套很激進的開源實作。

參考資料：

GitHub 專案：https://github.com/can1357/oh-my-pi
官方站點：https://omp.sh/
SDK 文件：https://omp.sh/docs/sdk

Bun：把 JavaScript 執行時、套件管理器、測試和打包合在一起

Sun, 17 May 2026 17:42:25 +0800

Bun 是 oven-sh 開源的 JavaScript / TypeScript 一體化工具鏈。

它不是只想做一個更快的 Node.js 替代品，而是把執行時、套件管理器、腳本執行器、測試執行器和打包器都放進同一個 bun 命令裡。對前端和 Node.js 開發者來說，Bun 的吸引力在於：少裝一堆工具，少等一堆安裝和建置流程，很多常見任務可以直接用一個命令完成。

專案地址：https://github.com/oven-sh/bun

先說結論

Bun 最適合想簡化 JavaScript 工具鏈的人。

它能做這些事：

執行 JavaScript、TypeScript、JSX 和 TSX。
作為 Node.js 相容執行時。
替代 npm / yarn / pnpm 做套件管理。
執行 package.json 裡的 scripts。
執行測試。
打包前端或後端程式碼。
用 bunx 執行 npm 套件裡的命令。
提供 Bun.serve、bun:sqlite、Bun.sql、Bun.redis、Bun.s3 等內建 API。

它最明顯的價值是開發體驗：安裝依賴快、啟動快、命令統一、TypeScript 和 JSX 開箱即用。

但 Bun 也不是所有專案都應該立刻切換。大型 Node.js 專案、依賴大量原生擴充的專案、生產穩定性要求極高的服務，仍然需要逐項驗證相容性、建置行為、測試行為和部署方式。

Bun 是什麼

按照官方 README 的描述，Bun 是一個面向 JavaScript 和 TypeScript 應用的一體化工具包。它以單一可執行檔 bun 發布。

它的核心是 Bun runtime：一個快速 JavaScript 執行時，目標是作為 Node.js 的 drop-in replacement。Bun 使用 Zig 編寫，底層基於 JavaScriptCore，重點優化啟動時間和記憶體占用。

這意味著你可以直接執行：

`1`	`bun run index.tsx`

TypeScript 和 JSX 不需要額外設定就能跑。

同一個 bun 命令還包含：

test runner
script runner
Node.js 相容套件管理器
bundler
package runner

常見命令包括：

bun test
bun run start
bun install <pkg>
bunx cowsay 'Hello, world!'

過去一個專案裡可能同時出現 node、npm、pnpm、tsx、jest、vitest、webpack、esbuild、ts-node 等工具。Bun 的路線是盡量把高頻路徑收進一個工具裡。

安裝方式

Bun 支援 Linux、macOS 和 Windows，覆蓋 x64 與 arm64。

官方推薦安裝腳本：

`1`	`curl -fsSL https://bun.com/install \| bash`

Windows：

`1`	`powershell -c "irm bun.sh/install.ps1 \| iex"`

也可以透過 npm 安裝：

`1`	`npm install -g bun`

macOS Homebrew：

1
2

brew tap oven-sh/bun
brew install bun

Docker：

1
2

docker pull oven/bun
docker run --rm --init --ulimit memlock=-1:-1 oven/bun

Linux 使用者要注意核心版本。README 提到強烈建議 Linux kernel 5.6 或更高，最低要求是 5.1。

升級到最新版：

`1`	`bun upgrade`

升級到 canary：

`1`	`bun upgrade --canary`

生產環境一般不建議直接用 canary，除非你是在驗證新特性或排查特定 bug。

為什麼 Bun 會快

Bun 的「快」主要來自幾個層面。

第一，執行時啟動快。很多 CLI 工具和開發腳本的瓶頸不是長期 CPU 運算，而是程序啟動、模組載入、TypeScript 轉譯和依賴解析。Bun 針對這些路徑做了很多優化。

第二，套件管理快。bun install 的目標是替代 npm / yarn / pnpm 的依賴安裝流程。它使用全域快取和自己的 lockfile，安裝大量依賴時通常能明顯減少等待。

第三，TypeScript / JSX 開箱即用。很多專案只是想執行一個 .ts 或 .tsx 腳本，傳統 Node.js 工具鏈需要額外加 tsx、ts-node、Babel 或建置步驟。Bun 可以直接跑，減少了膠水工具。

第四，內建工具減少程序和設定切換。測試、腳本、打包、執行都在同一個工具裡，很多場景不用再在多個 CLI 之間切換。

但要注意，「Bun 很快」不等於每個專案都一定更快。真實效果取決於依賴類型、腳本邏輯、測試框架、建置設定、Node.js API 使用情況和 CI 快取策略。

套件管理：替代 npm / yarn / pnpm

Bun 可以直接安裝依賴：

`1`	`bun install`

新增依賴：

`1`	`bun add react`

新增開發依賴：

`1`	`bun add -d typescript`

移除依賴：

`1`	`bun remove react`

查看依賴原因：

`1`	`bun why react`

安全檢查：

`1`	`bun audit`

如果你從 npm 或 pnpm 遷移，重點要看：

bun.lock 是否進入版本控制。
CI 是否使用 bun install --frozen-lockfile。
私有 registry 和 .npmrc 是否相容。
workspace 行為是否符合預期。
lifecycle scripts 是否會帶來安全風險。
原本依賴 pnpm 特性的 monorepo 是否能平順遷移。

小專案可以直接試。大型 monorepo 不建議一次性全切，可以先在單個 package 或 CI 的非關鍵任務裡試。

執行腳本和 TypeScript

Bun 可以執行 package.json 裡的腳本：

`1`	`bun run start`

也可以直接執行檔案：

1
2

bun run index.ts
bun run index.tsx

這對工具腳本很方便，例如：

scripts/build.ts
scripts/seed.ts
scripts/migrate.ts
scripts/check.ts

如果用 Node.js，通常要處理 TypeScript loader 或預編譯問題。Bun 的直接執行能力可以讓這些腳本更輕。

不過，如果腳本依賴 Node.js 特定行為，尤其是 loader、ESM/CJS 邊界、原生模組、child process、檔案監聽和某些邊緣 API，仍然要測試。

測試執行器

Bun 內建測試執行器：

`1`	`bun test`

它適合想減少 Jest / Vitest 設定的小專案，也適合把一些單元測試、工具測試、庫測試遷移到更輕的執行方式。

遷移測試時重點關注：

expect 行為差異。
mock API 差異。
snapshot 行為。
DOM 測試環境。
測試發現規則。
覆蓋率輸出。
CI reporter 支援。

如果專案已經深度依賴 Jest 生態，例如大量自訂 matcher、複雜 mock、jsdom、babel-jest、ts-jest，遷移就不要太急。可以先讓新模組用 bun test，舊測試繼續保留原框架。

打包和建置

Bun 也提供 bundler，常見用法是：

`1`	`bun build ./src/index.ts --outdir ./dist`

它可以用於前端包、後端腳本、CLI 工具和庫建置。Bun 文件還覆蓋 loaders、plugins、macros、CSS、HTML、HMR、minifier、single-file executable 等方向。

適合優先嘗試的場景：

小型前端工具。
Node.js CLI。
內部腳本。
單檔服務。
不依賴複雜 webpack loader 的專案。

謹慎遷移的場景：

複雜 webpack 外掛鏈。
大量 Vite 外掛。
深度依賴 Babel 轉換。
特殊 CSS / asset pipeline。
微前端和模組聯邦。
對建置產物 hash、chunk、相容性要求很細的專案。

Bun bundler 很有吸引力，但建置工具遷移的風險通常比套件管理更高，最好單獨驗證。

執行 HTTP 服務

Bun 提供 Bun.serve 來寫 HTTP 服務：

Bun.serve({
  port: 3000,
  fetch(req) {
    return new Response("Hello from Bun")
  },
})

這對小型 API、內部服務、Webhook receiver、邊緣風格服務很方便。Bun 還提供 WebSockets、Workers、Streams、SQLite、PostgreSQL、Redis、S3、TCP/UDP sockets 等 API。

如果你已有 Express、Fastify、NestJS、Next.js、Hono、Elysia 等框架，也可以先看它們在 Bun 上的相容程度，不必為了用 Bun 就重寫服務。

更現實的路徑是：

先用 Bun 做開發腳本和套件管理。
再用 Bun 跑測試。
最後評估是否把執行時切到 Bun。

執行時遷移最需要謹慎，因為它直接影響生產服務行為。

和 Node.js 的關係

Bun 的目標之一是作為 Node.js 的 drop-in replacement，但「相容」不是「完全等同」。

Node.js 生態已經累積很多年，很多套件依賴細微行為：

CJS / ESM 互操作。
Node 內建模組。
原生擴充。
npm lifecycle scripts。
檔案系統邊緣行為。
stream 和 Buffer 細節。
worker / child_process。
除錯和 profiling。

Bun 在相容性上進步很快，但生產遷移仍要以測試結果為準。

比較穩妥的判斷方式：

你的測試能否在 Bun 下通過。
關鍵依賴是否支援 Bun。
建置產物是否一致。
CI 和本地表現是否一致。
線上執行是否有監控和回滾。
Docker 映像和部署腳本是否穩定。

如果只是替換套件管理器，風險較低；如果替換生產執行時，風險高很多。

適合哪些專案

Bun 很適合這些場景：

新的 JavaScript / TypeScript 小專案。
內部工具和腳本。
CLI 專案。
需要快速安裝依賴的 CI。
希望減少工具鏈複雜度的前端專案。
對啟動速度敏感的腳本和服務。
想用 TypeScript 開箱即跑的開發者。

暫時要謹慎的場景：

超大型 monorepo。
深度綁定 pnpm workspace 行為的專案。
依賴大量 Node.js 原生擴充的服務。
建置鏈路高度客製的前端工程。
對生產執行時一致性要求極高的後端。
依賴 Jest 複雜生態的測試套件。

一個保守但實用的策略是：先把 Bun 當作開發工具，而不是馬上替代全部生產執行時。

遷移建議

如果想在現有專案試 Bun，可以按這個順序：

在本地安裝 Bun。
執行 bun install，觀察依賴安裝結果。
提交或暫存 bun.lock，避免和舊 lockfile 混用造成混亂。
嘗試 bun run <script> 跑常用腳本。
用 bun test 遷移少量測試。
在 CI 加一個非阻塞 Bun job。
確認沒有相容問題後，再考慮替換主安裝流程。
最後再評估生產執行時是否切換。

對團隊專案，最好保留回滾路徑：

遷移前保留原 npm / pnpm / yarn 流程。
CI 裡同時跑一段時間。
不要在同一次改動裡同時換執行時、套件管理器、測試框架和打包器。
把遷移拆成小步驟，每一步都有可驗證收益。

這樣做雖然慢一點，但不容易把問題混在一起。

常見命令速查

安裝：

`1`	`curl -fsSL https://bun.com/install \| bash`

升級：

`1`	`bun upgrade`

安裝依賴：

`1`	`bun install`

新增依賴：

`1`	`bun add lodash`

執行腳本：

`1`	`bun run dev`

直接執行 TypeScript：

`1`	`bun run scripts/build.ts`

測試：

`1`	`bun test`

打包：

`1`	`bun build ./src/index.ts --outdir ./dist`

執行套件命令：

`1`	`bunx cowsay 'Hello, world!'`

總結

Bun 的價值不只是「比 Node.js 快」。更重要的是，它把 JavaScript / TypeScript 開發裡一堆分散工具收進一個 bun 命令：執行時、套件管理器、腳本執行器、測試執行器和打包器。

對新專案和內部工具來說，這種一體化體驗很舒服：安裝快、啟動快、設定少，TypeScript 和 JSX 也能直接跑。對已有大型專案來說，Bun 更適合先從低風險環節切入，例如套件安裝、腳本和部分測試，再逐步驗證建置和執行時。

如果你經常被 Node.js 工具鏈裡的安裝速度、設定碎片和測試啟動時間折磨，Bun 值得認真試一下。但真正遷移生產服務時，還是要回到最樸素的工程判斷：測試能不能過、依賴是否相容、CI 是否穩定、線上有沒有回滾。

參考連結：

Godot 遊戲開發入門：從節點、場景到第一個 2D 小遊戲

Sun, 17 May 2026 12:37:30 +0800

Godot 是一款開源遊戲引擎，適合從 2D 小遊戲、獨立遊戲原型，到中等規模的 3D 專案開發。

它最大的特點是輕量、開源、啟動快，節點和場景系統非常清晰。對新手來說，Godot 的門檻通常比 Unity 低；對獨立開發者來說，它不繫結商業授權模式，也更容易做出可控的小專案。

這篇文章用最少概念把 Godot 的入門路線講清楚：你先理解節點和場景，再學 GDScript，最後用一個 2D 小遊戲把輸入、物理、碰撞、UI、音效和匯出串起來。

先說結論

Godot 入門不要一上來就學大而全的引擎功能。

更合理的路線是：

先做 2D，不急著做 3D。
先理解節點和場景，不急著寫複雜架構。
先學 GDScript，不急著上 C#。
先做一個能跑、能失敗、能重開的小遊戲。
再逐步補動畫、音效、UI、關卡和匯出。

只要做完一個完整小專案，你對 Godot 的理解會比刷十幾個零散教程更穩。

Godot 適合什麼人

Godot 很適合這幾類人：

想從零開始學遊戲開發。
想做 2D 獨立遊戲。
想快速做玩法原型。
不想被複雜商業引擎工具鏈壓住。
想理解遊戲引擎底層組織方式。
有一點 Python / JavaScript 經驗，想快速上手指令碼。

如果你的目標是大型 3A 畫面、複雜商業團隊管線、現成資產商店生態，Unity 或 Unreal 可能仍然更成熟。但如果目標是學習和做自己的遊戲，Godot 非常適合起步。

安裝和專案建立

Godot 的安裝很簡單。

到官網下載安裝包，解壓後直接執行即可。它不像很多大型引擎那樣必須先裝完整啟動器，也不需要複雜賬號流程。

新建專案時，建議先選：

Renderer：預設即可。
Project Name：用英文短橫線或下劃線。
路徑：不要放在中文或空格特別多的目錄裡。
版本管理：建議從一開始就用 Git。

第一個專案可以叫：

`1`	`first-godot-game`

專案建立後，Godot 會進入編輯器。你需要先熟悉幾個區域：

Scene：當前場景的節點樹。
FileSystem：專案資源目錄。
Inspector：選中節點的屬性面板。
Script：指令碼編輯區。
2D / 3D 檢視：編輯畫面和物件位置。

Godot 的核心：節點和場景

Godot 最重要的概念只有兩個：節點和場景。

節點是功能單元。比如：

Node2D：2D 物件基礎節點。
Sprite2D：顯示圖片。
CollisionShape2D：碰撞形狀。
CharacterBody2D：可移動角色。
Camera2D：2D 攝像機。
AudioStreamPlayer：播放音訊。
Label：顯示文字。

場景是一組節點的組合。一個角色可以是一個場景，一個敵人可以是一個場景，一個關卡也可以是一個場景。

比如一個玩家角色場景可能長這樣：

Player (CharacterBody2D)
├── Sprite2D
├── CollisionShape2D
└── Camera2D

這棵樹的意思是：玩家本體負責移動，Sprite2D 負責顯示角色圖片，CollisionShape2D 負責碰撞，Camera2D 跟隨玩家。

Godot 的思路就是：把遊戲拆成很多可複用場景，再把場景組合成完整遊戲。

第一個 2D 專案做什麼

新手第一個專案不要做 RPG、開放世界、聯機遊戲或複雜平臺跳躍。

建議做一個最小 2D 閃避遊戲：

玩家可以上下左右移動。
敵人從螢幕邊緣出現。
玩家碰到敵人就失敗。
存活時間越長分數越高。
有開始按鈕、失敗介面和重新開始。

這個專案很小，但能覆蓋 Godot 入門最重要的東西：

角色移動。
輸入系統。
碰撞檢測。
敵人生成。
UI 顯示。
定時器。
音效。
場景切換。

做完它，你就已經跨過了“只會看教程，不知道怎麼組織專案”的第一道坎。

玩家移動怎麼寫

在 Godot 裡，玩家角色通常用 CharacterBody2D。

給 Player 節點掛一個指令碼：

extends CharacterBody2D

@export var speed := 300.0

func _physics_process(delta):
    var direction := Vector2.ZERO

    direction.x = Input.get_axis("move_left", "move_right")
    direction.y = Input.get_axis("move_up", "move_down")
    direction = direction.normalized()

    velocity = direction * speed
    move_and_slide()

這段程式碼做了幾件事：

讀取水平和垂直方向輸入。
把方向向量歸一化，避免斜向移動更快。
把方向乘以速度，得到 velocity。
用 move_and_slide() 讓角色移動並處理碰撞。

還需要在 Project Settings 裡設定輸入：

move_left  -> A / Left
move_right -> D / Right
move_up    -> W / Up
move_down  -> S / Down

Godot 的輸入系統建議一開始就用 action，不要在程式碼裡直接寫死鍵盤按鍵。這樣以後支援手柄、觸屏或改鍵會方便很多。

碰撞和物理怎麼理解

Godot 的碰撞不是隻靠圖片大小判斷，而是靠碰撞形狀。

常用節點有：

CollisionShape2D：給角色或敵人定義碰撞範圍。
Area2D：檢測進入、離開、重疊，適合觸發器。
CharacterBody2D：適合玩家和會移動的角色。
RigidBody2D：適合受物理力影響的物體。
StaticBody2D：適合牆、地面、固定障礙。

入門階段記住一個原則：

如果你要自己控制角色移動，用 CharacterBody2D。

如果你只想檢測“玩家碰到敵人”，敵人可以用 Area2D，再監聽訊號：

1
2
3

func _on_body_entered(body):
    if body.name == "Player":
        get_tree().reload_current_scene()

後面專案變複雜時，可以改成傳送 game_over 訊號，而不是直接過載場景。新手階段先跑通邏輯更重要。

場景例項化：讓敵人不斷出現

Godot 的場景可以當成“預製體”使用。

假設你有一個 Enemy.tscn，可以在主場景裡用指令碼生成它：

@export var enemy_scene: PackedScene

func spawn_enemy():
    var enemy = enemy_scene.instantiate()
    enemy.position = Vector2(800, randf_range(50, 550))
    add_child(enemy)

再配合 Timer 節點，每隔一段時間呼叫一次 spawn_enemy()，敵人就會不斷生成。

這就是 Godot 專案常見組織方式：

一個場景負責一種物件。
主場景負責排程和組合。
需要時動態例項化子場景。

UI 和分數

Godot 的 UI 使用 Control 系列節點。

常用節點包括：

CanvasLayer：讓 UI 固定在螢幕上，不跟隨相機移動。
Label：顯示文字。
Button：按鈕。
Panel：面板背景。
VBoxContainer / HBoxContainer：自動排版。

分數可以先用存活時間來做：

var score := 0.0

func _process(delta):
    score += delta
    $CanvasLayer/ScoreLabel.text = str(int(score))

這樣每秒增加 1 分。後面可以改成擊敗敵人、收集金幣或完成關卡加分。

音效和反饋

小遊戲好不好玩，很大一部分來自反饋。

即使畫面很簡單，也要加：

移動或點選音效。
碰撞音效。
得分音效。
失敗音效。
螢幕震動或閃爍。
按鈕 hover / pressed 狀態。

Godot 裡可以用 AudioStreamPlayer 播放音效：

`1`	`$HitSound.play()`

新手常犯的錯誤是隻做功能，不做反饋。功能能跑只是第一步，玩家能不能感到“我做了一個動作，遊戲回應了我”，才是遊戲體驗的開始。

檔案怎麼組織

專案一開始就建議整理目錄：

res://
├── scenes/
│   ├── Main.tscn
│   ├── Player.tscn
│   └── Enemy.tscn
├── scripts/
│   ├── player.gd
│   └── enemy.gd
├── assets/
│   ├── sprites/
│   └── audio/
└── ui/
    └── GameOver.tscn

不要把所有資源都丟在根目錄。小遊戲階段無所謂，專案稍微大一點就會混亂。

一個簡單原則是：

場景放 scenes/。
指令碼放 scripts/。
圖片和音訊放 assets/。
UI 單獨放 ui/。

Godot 新手常見坑

第一個坑：節點選錯。

能自己控制移動的角色用 CharacterBody2D，不是隨便用 Node2D。觸發檢測用 Area2D，固定障礙用 StaticBody2D。

第二個坑：忘記碰撞形狀。

只有圖片沒有碰撞體，遊戲不會知道它們撞上了。

第三個坑：把按鍵寫死。

不要直接判斷 KEY_A，用輸入 action。

第四個坑：場景職責混亂。

不要讓一個指令碼同時管玩家、敵人、UI、音效和關卡。新手可以簡單，但不要所有東西都堆在 Main.gd。

第五個坑：一開始就做大專案。

第一個專案越小越好。只要完整，有開始、有失敗、有重新開始，就比半途而廢的大專案更有價值。

Godot 和 Unity 怎麼選

如果你主要做 2D 獨立遊戲、教學專案、個人原型，Godot 非常舒服。

如果你需要龐大的資產商店、成熟商業外掛、移動廣告和商業化 SDK、成熟團隊經驗，Unity 生態仍然更強。

如果你要做高規格 3D、複雜渲染、影視級畫面，Unreal 更適合。

對新手來說，不要把選引擎變成拖延。Godot 足夠你做出大量完整小遊戲。你真正需要先學會的是：

遊戲迴圈。
輸入響應。
碰撞和反饋。
場景組織。
狀態管理。
資源和版本管理。

這些能力換到其他引擎也能用。

第一個專案的完成標準

你可以用這個清單判斷自己是否真的入門：

玩家能移動。
有敵人或障礙。
有碰撞失敗。
有分數或目標。
有開始介面。
有失敗介面。
能重新開始。
有至少兩個音效。
有簡單動畫或視覺反饋。
能匯出一個可執行版本。

做到這裡，你就不是“開啟過 Godot”，而是真的完成了一個遊戲閉環。

總結

Godot 入門的關鍵，不是把所有功能看一遍，而是先理解它的組織方式：節點組成場景，場景組成遊戲，指令碼驅動行為，訊號連線事件，資源透過目錄管理。

第一個專案建議從 2D 小遊戲開始。玩家移動、敵人生成、碰撞失敗、UI 分數、音效反饋、重新開始，這幾個環節跑通之後，再去學動畫樹、TileMap、存檔、狀態機、3D、Shader 和匯出最佳化。

遊戲開發不是先學完引擎再開始做，而是在做小專案的過程中反覆補概念。Godot 的優勢正好在這裡：它足夠輕，能讓你很快從“想做遊戲”走到“真的跑起來”。

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，這個功能值得開啟。如果你只是偶爾問幾句程式問題，它的價值可能沒那麼明顯。

參考資料

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

Ghostty 文件速讀：安裝、設定與日常使用要點

Fri, 15 May 2026 14:50:11 +0800

Ghostty 是一個新的終端模擬器，但它不只是「又一個更快的終端」。按照官方文件的說法，它想同時兼顧三個方向：速度、功能和原生桌面體驗。也就是說，它既希望有 GPU 加速和較好的渲染效能，也希望在 macOS 和 Linux 上盡量像一個真正的本機應用，而不是把所有互動都塞進自繪介面裡。

如果你正在用 iTerm2、Kitty、Alacritty、WezTerm 或系統內建終端，Ghostty 最值得關注的地方不是某一個單點功能，而是它把「開箱即用」和「深度可設定」放在了一起。預設設定已經能直接使用；想繼續折騰時，文件又給了設定檔、主題、快捷鍵、字型、Shell 整合和終端控制序列等完整入口。

先看定位

Ghostty 的核心定位可以概括為三句話：

它是跨平台終端模擬器，目前重點覆蓋 macOS 和 Linux。
它使用平台原生 UI：macOS 端使用 Swift、AppKit 和 SwiftUI，Linux 端使用 Zig 和 GTK4。
它的終端核心是 libghostty，GUI 應用圍繞這個共享核心構建。

這個設計會影響日常體驗。比如分頁、分割視窗、錯誤提示、視窗狀態恢復、系統快捷鍵等能力，不是簡單做成「看起來像桌面應用」的元件，而是盡量貼近所在系統的互動習慣。macOS 和 Linux 預設快捷鍵也會按各自平台約定區分。

安裝方式：macOS 最直接，Linux 看發行版

官方預構建二進位主要面向 macOS。最普通的安裝方式是下載 .dmg，打開後把 Ghostty 拖到 Applications 目錄。Homebrew 使用者也可以用社群維護的 cask：

`1`	`brew install --cask ghostty`

Linux 的情況更分散。Ghostty 文件把不同發行版的套件管理器、社群二進位和原始碼構建分開說明。Arch、Alpine、Gentoo、NixOS、Snap、Solus、Void 等都有對應路徑；如果發行版沒有官方或可信倉庫，文件更傾向於讓使用者從原始碼構建，而不是隨意安裝第三方二進位。

這點對伺服器和工作機尤其重要：終端模擬器會處理大量輸入輸出、剪貼簿、連結、SSH 工作階段和本機檔案路徑。安裝來源最好保守一點，優先選官方 macOS 套件、發行版倉庫或自己能審計來源的構建流程。

設定：先別急著複製一大份 dotfiles

Ghostty 的設定哲學是「零設定可用」。預設字型內建 JetBrains Mono，也帶有 Nerd Font 支援；多數使用者第一次打開就能正常工作。文件甚至建議，如果你發現必須設定某個非主觀選項才舒服，可以先考慮它是不是應該成為預設行為。

真正需要定製時，Ghostty 使用文字設定檔。當前設定檔名是 config.ghostty，舊版本也支援 config。常見路徑包括：

$XDG_CONFIG_HOME/ghostty/config.ghostty
$XDG_CONFIG_HOME/ghostty/config
$HOME/.config/ghostty/config.ghostty
$HOME/.config/ghostty/config

macOS 還會讀取：

1
2

$HOME/Library/Application Support/com.mitchellh.ghostty/config.ghostty
$HOME/Library/Application Support/com.mitchellh.ghostty/config

設定語法非常直接，就是 key = value。例如：

font-family = JetBrains Mono
font-size = 14
theme = light:Rose Pine Dawn,dark:Rose Pine
keybind = ctrl+shift+t=new_tab

一個實用建議是：不要一開始就找別人的完整設定照抄。更穩的方式是先裸跑幾天，只改三類東西：字型、字號和主題。等你真的發現快捷鍵、分割視窗、視窗、Shell 整合有摩擦，再逐項加設定。

文件查詢：本機也能查完整設定

Ghostty 的設定項很多，官方文件把它們集中在 Option Reference。除了網頁，安裝後也可以從本機查設定參考：

`1`	`ghostty +show-config --default --docs`

這個命令會把預設設定和文件輸出到標準輸出，適合接到分頁器裡慢慢搜尋：

`1`	`ghostty +show-config --default --docs \| less`

查看可用字型時可以用：

`1`	`ghostty +list-fonts`

查看內建和可用主題時可以用：

`1`	`ghostty +list-themes`

查看預設快捷鍵時可以用：

`1`	`ghostty +list-keybinds --default`

這些命令比在網路上複製片段更可靠，因為它們來自你當前安裝的 Ghostty 版本。

快捷鍵：把「動作」當成核心概念

Ghostty 的快捷鍵設定格式是：

`1`	`keybind = trigger=action`

trigger 是按鍵觸發方式，action 是 Ghostty 執行的動作。比如新建分頁、關閉當前 surface、重新載入設定、跳轉到提示符等，都屬於 action。這個模型的好處是清晰：你不是在「改某個選單項」，而是在把一個輸入序列綁定到一個動作。

設定改完後，可以在執行時重新載入。預設快捷鍵是：

Linux：ctrl+shift+,
macOS：cmd+shift+,

不過並不是所有設定都能即時生效。有些選項只影響新建終端，有些需要完整重啟。遇到「設定寫了但沒變化」時，先查對應選項說明，比反覆懷疑語法更省時間。

主題和字型：先用內建，再做細調

Ghostty 自帶大量主題，並支援按系統淺色、深色模式切換不同主題：

`1`	`theme = light:Rose Pine Dawn,dark:Rose Pine`

主題也可以來自自訂檔案。文件提醒得很明確：主題檔案本質上也是 Ghostty 設定檔，可以設定很多設定項，所以不要隨便使用不可信來源的主題。

字型方面，font-family 可以重複多次，用來指定 fallback 字型。對多語言環境很實用，比如主字型負責英文和符號，後續字型補中文、日文或其他字元。遇到 emoji、粗體、斜體、連字等顯示細節時，再去 Option Reference 裡查對應選項即可。

Shell 整合：SSH 使用者尤其應該看

Ghostty 支援自動注入 shell integration，覆蓋 bash、elvish、fish、nushell 和 zsh。啟用後，一些體驗會更自然，比如：

新終端從前一個終端的工作目錄打開。
複雜提示符 resize 時可以重繪，而不是被錯誤回流。
可以透過提示符標記在命令輸出之間跳轉。
在提示符處支援更符合編輯習慣的游標行為。

如果不想自動注入，可以在設定裡關閉：

`1`	`shell-integration = none`

更值得注意的是 SSH。Ghostty 使用 xterm-ghostty 作為 TERM，但很多遠端主機還沒有對應的 terminfo。文件提供了 ssh-env 和 ssh-terminfo 兩個 shell integration 功能，預設關閉，可以按需啟用：

`1`	`shell-integration-features = ssh-env,ssh-terminfo`

如果你經常連接舊伺服器、容器、跳板機或嚴格管理的生產環境，建議先讀完官方的 Terminfo 和 Shell Integration 文件，再決定是否啟用這些功能。終端能力協商看起來不起眼，但一旦出問題，表現可能是顏色異常、快捷鍵失靈、全螢幕程式顯示錯亂。

我的上手順序

如果只是想判斷 Ghostty 是否適合自己，可以按這個順序試：

安裝後不寫設定，直接用一天。
只調整 font-family、font-size 和 theme。
用 ghostty +list-keybinds --default 看預設快捷鍵，而不是先搬運別人的快捷鍵表。
如果常用 SSH，優先檢查遠端主機的 terminfo 相容問題。
最後再處理分割視窗、視窗、透明度、標題列、背景圖等視覺和工作流偏好。

Ghostty 文件寫得比較工程化，適合把它當成「設定參考手冊」而不是「宣傳頁」閱讀。對多數使用者來說，真正的判斷標準也很簡單：預設體驗是否已經舒服，日常編輯器、Shell、SSH、tmux 或 Zellij 是否穩定。如果這幾件事都順，Ghostty 就值得進入你的長期終端候選列表。

參考連結

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

Codex 怎麼接入國產大模型？OpenAI 相容介面與 CodexBridge 使用思路

Wed, 13 May 2026 23:08:28 +0800

CodexBridge 是一個本地橋接工具，目標很直接：把 Codex CLI/SDK 封裝成 OpenAI 相容的 HTTP 服務。這樣一來，原本只能在終端機裡使用的 Codex，可以被 OpenWebUI、Cherry Studio、腳本、自動化系統，或任何相容 OpenAI Chat Completions 的客戶端呼叫。

它提供的核心介面是 /v1/chat/completions 和 /v1/models。前者負責對話，支援一般同步回傳和 SSE 串流輸出；後者讓客戶端能像讀取模型清單一樣發現可用模型。對已經接過 OpenAI API 的工具來說，這種設計的好處是改動小，通常只需要改 base URL、API key 和模型名稱。

專案地址：https://github.com/begonia599/CodexBridge

適合什麼場景

CodexBridge 適合想把 Codex 接入現有 AI 客戶端或工作流程的人。例如：

想在 OpenWebUI、Cherry Studio 裡直接選擇 Codex 模型。
想用 curl、Python、Node.js 等腳本呼叫本機 Codex。
想讓同一個前端同時接 OpenAI、Ollama、其他相容介面和 Codex。
想保留 Codex 的本地執行緒、沙箱、工作目錄和核准能力。
想給內部工具提供一個統一的 /v1/chat/completions 入口。

它不是一個新的大模型，也不是替代 Codex CLI 的完整前端。更準確地說，它是一個轉接層：上游仍然是 Codex，本地橋接器負責把 OpenAI 風格的請求轉換成 Codex 能理解的會話輸入。

基本環境

執行前需要準備：

Node.js 18 或更高版本。
已安裝並登入的 Codex CLI。
npm，或依照自己的習慣換成 pnpm / yarn。

原始碼部署的基本步驟如下：

git clone https://github.com/begonia599/CodexBridge
cd codexbridge
npm install
cp .env.example .env
cp .env .env.local

然後編輯 .env 或 .env.local，設定 API key、預設模型、工作目錄、沙箱模式、網路權限等配置。

啟動 HTTP 服務：

`1`	`npm run codex:server`

預設連接埠是 8080，可以透過 PORT 修改。服務啟動後，可以存取：

1
2
3

GET /health
POST /v1/chat/completions
GET /v1/models

CLI 對話模式

除了 HTTP 服務，CodexBridge 也保留了一個輕量 CLI：

`1`	`npm run codex:chat`

CLI 裡可以直接輸入自然語言與 Codex 對話。常用命令有兩個：

/reset：建立新的 Codex 執行緒。
/exit：離開 CLI。

目前執行緒 ID 會保存在 .codex_thread.json。下次啟動 CLI 時，如果這個檔案還在，就能繼續之前的對話。

HTTP 呼叫範例

最基本的請求可以這樣寫：

curl http://localhost:8080/v1/chat/completions \
  -H "content-type: application/json" \
  -H "authorization: Bearer 123321" \
  -d '{"model":"gpt-5-codex:medium","session_id":"demo","messages":[{"role":"user","content":"ls"}]}'

這裡有幾個點需要注意：

authorization 裡的 token 要和 CODEX_BRIDGE_API_KEY 一致。
model 可以帶推理等級，例如 gpt-5-codex:medium 或 gpt-5-codex:high。
session_id 用來綁定會話，方便複用同一個 Codex 執行緒。

如果需要串流輸出，加上 stream: true：

curl -N http://localhost:8080/v1/chat/completions \
  -H "content-type: application/json" \
  -H "authorization: Bearer 123321" \
  -d '{"model":"gpt-5-codex:high","session_id":"stream","stream":true,"messages":[{"role":"user","content":"一步步介紹如何建立 Node.js 專案"}]}'

對支援 OpenAI 串流回應的客戶端來說，這種回傳方式更接近正常聊天體驗。

會話持久化怎麼做

CodexBridge 的一個重點是會話映射。請求裡可以透過這些欄位傳入會話 ID：

session_id
conversation_id
thread_id
user

也可以從請求標頭傳：

x-session-id
session-id
x-conversation-id
x-thread-id
x-user-id

生產環境建議開啟：

`1`	`CODEX_REQUIRE_SESSION_ID=true`

這樣所有請求都必須帶會話 ID，避免不同使用者或不同聊天視窗混到同一個臨時上下文裡。會話映射保存在 .codex_threads.json，刪除這個檔案可以重設橋接層的映射關係；Codex 自身執行緒仍然保存在 ~/.codex/sessions。

如果 CODEX_REQUIRE_SESSION_ID=false 且請求沒有提供會話 ID，橋接器會把目前 messages 展開成一次性輸入發給 Codex。這種方式適合臨時呼叫，但不適合長期對話。

多模態輸入

CodexBridge 支援 OpenAI 風格的內容區塊，並會把圖片轉換成 Codex 可用的 local_image 輸入。

遠端圖片可以寫成：

{
  "type": "image_url",
  "image_url": {
    "url": "https://example.com/demo.png"
  }
}

本地圖片可以寫成：

{
  "type": "local_image",
  "path": "./images/demo.png"
}

遠端資源會先下載到暫存目錄，回合結束後清理。實際使用時要注意請求體大小，尤其是把圖片轉成 base64 傳送時，可能需要增大 CODEX_JSON_LIMIT。

結構化輸出

如果客戶端支援 response_format，可以讓 CodexBridge 映射到 Codex 的 outputSchema。這適合讓 Codex 回傳固定 JSON 結構，例如檢查結果、摘要、分類結果或自動化任務報告。

最小思路是：

{
  "model": "gpt-5-codex",
  "session_id": "lint",
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "lint_report",
      "schema": {
        "type": "object",
        "properties": {
          "summary": { "type": "string" },
          "status": {
            "type": "string",
            "enum": ["ok", "action_required"]
          }
        },
        "required": ["summary", "status"],
        "additionalProperties": false
      }
    }
  },
  "messages": [
    {
      "role": "user",
      "content": "檢查 src/ 的 lint 問題，並以 JSON 回傳結果"
    }
  ]
}

需要注意，type: "json_schema" 必須提供 schema，否則服務會直接回傳 400。

關鍵環境變數

常用配置可以分成幾類。

服務與鑑權：

1
2
3

PORT=8080
CODEX_BRIDGE_API_KEY=123321
CODEX_JSON_LIMIT=10mb

預設模型：

1
2

CODEX_MODEL=gpt-5-codex
CODEX_REASONING=medium

Codex 執行環境：

CODEX_WORKDIR=
CODEX_SANDBOX_MODE=read-only
CODEX_APPROVAL_POLICY=never
CODEX_SKIP_GIT_CHECK=true

網路能力：

1
2

CODEX_NETWORK_ACCESS=false
CODEX_WEB_SEARCH=false

如果只是給前端聊天用，預設關閉網路更穩。只有明確需要讓 Codex 執行 curl、git clone 或使用 Web 搜尋時，再單獨打開對應開關。

Docker 和一鍵腳本

專案也提供 Docker 方式，適合想把服務常駐起來的場景：

1
2

docker compose up -d
docker compose logs -f codexbridge

也可以用專案提供的 Linux 安裝腳本：

`1`	`curl -fsSL https://raw.githubusercontent.com/begonia599/CodexBridge/master/scripts/install.sh \| bash`

腳本會安裝依賴、clone 或更新倉庫、複製 .env.example，並透過 Docker Compose 啟動服務。它需要 sudo 權限，適合在乾淨伺服器上快速部署。已經有複雜 Node.js、Docker 或 Codex 環境的機器，建議先讀腳本內容再執行。

常見問題

請求回傳 413

通常是請求體太大，常見於 base64 圖片。可以增大：

`1`	`CODEX_JSON_LIMIT=20mb`

提示 API key 無效

檢查請求標頭是否帶了：

`1`	`Authorization: Bearer <你的 CODEX_BRIDGE_API_KEY>`

或者使用 x-api-key。

Codex 回報 Git 倉庫限制

如果執行目錄不是可信倉庫，可能會觸發 Codex 的檢查。只在確認安全的環境中使用：

`1`	`CODEX_SKIP_GIT_CHECK=true`

想清空會話

橋接層會話映射在 .codex_threads.json，Codex 自身執行緒在 ~/.codex/sessions。停掉服務後刪除對應檔案或目錄即可重設。

使用建議

本地試用時，可以先用預設 API key 和 read-only 沙箱跑通流程。確認 OpenWebUI、Cherry Studio 或腳本能正常呼叫後，再逐步調整 CODEX_WORKDIR、CODEX_SANDBOX_MODE、CODEX_NETWORK_ACCESS 和 CODEX_APPROVAL_POLICY。

如果要給多人使用，建議至少做三件事：

強制要求 session_id。
修改預設 API key。
明確限制工作目錄和沙箱權限。

CodexBridge 的價值不在於功能複雜，而在於把 Codex 放進了現有 OpenAI 相容生態裡。只要客戶端能改 base URL，它就有機會把 Codex 當成一個普通聊天模型來接入，同時保留本地執行緒、沙箱和工具呼叫這些 Codex 自身的能力。

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

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

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

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

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

Agent 工具為什麼特別費 token

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

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

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

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

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

Superpowers 的好處是按需觸發

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

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

這對成本很重要。

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

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

DeepSeek 的關鍵優勢是快取便宜

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

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

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

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

長上下文讓 Claude Code 更好用

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

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

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

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

V4 Pro 和 V4 Flash 怎麼分工

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

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

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

複雜任務再考慮 DeepSeek V4 Pro：

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

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

MiniMax、豆包和 DeepSeek 的位置不同

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

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

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

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

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

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

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

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

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

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

DeepSeek 適合哪類 AI 編程工作流

DeepSeek 最適合這些任務：

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

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

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

小結

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

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

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

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

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

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

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

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

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

選套餐先看四件事

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

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

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

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

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

海外套餐正在收緊

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

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

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

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

國產套餐的優點和短板

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

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

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

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

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

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

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

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

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

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

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

選擇時可以重點看三點：

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

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

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

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

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

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

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

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

一個更穩的組合思路

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

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

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

小結

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

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

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。

參考資料

goose：桌面端、CLI 和 API 一體的開源 AI Agent

Fri, 08 May 2026 13:41:15 +0800

goose 是一個執行在本機的開源 AI Agent。它不只面向程式碼補全，而是希望覆蓋程式碼、研究、寫作、自動化、資料分析等更廣的任務。README 的定位很清楚：提供桌面端、CLI 和 API，既可給普通使用者使用，也可嵌入自訂工作流。

專案已從 block/goose 遷移到 Linux Foundation 旗下的 Agentic AI Foundation（AAIF）。目前倉庫是：

`1`	`https://github.com/aaif-goose/goose`

goose 主要由 Rust 和 TypeScript 編寫，授權為 Apache-2.0。GitHub 描述稱它是一個開源、可擴展的 AI agent，不只給出程式碼建議，還能安裝、執行、編輯和測試，並可接入任意 LLM。

解決什麼問題

許多 AI 編程工具只停留在建議或局部改碼。goose 的目標更廣：讓 AI agent 直接在你的機器上完成任務。

它可用於：

程式碼修改和測試。
本地自動化。
資料研究和寫作。
資料分析。
多步驟工作流。
透過 API 嵌入其他系統。
透過 MCP 擴展工具能力。

如果只是 IDE 補全，Copilot 類工具已足夠。goose 更適合把 AI 放進本機任務執行鏈。

桌面端、CLI、API

goose 提供三種入口。

桌面端支援 macOS、Linux 和 Windows，適合偏好可視化互動的使用者。

CLI 適合終端工作流和本地開發自動化。

API 可作為可嵌入的 agent runtime，供其他系統或內部工具呼叫。

個人使用可先從桌面端或 CLI 開始；團隊內部工具和 agent 平台則應關注 API 與自訂分發。

安裝方式

桌面端：

`1`	`https://goose-docs.ai/docs/getting-started/installation`

CLI：

`1`	`curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh \| bash`

GitHub Releases 提供多平台構建。這裡查到的 latest release 是 v1.33.1，發布於 2026-04-29，包含 macOS、Linux、Windows、deb、rpm、Flatpak 等資產。

安裝後建議先按官方 Quickstart 配置 provider，並從低風險目錄開始測試。

Provider

goose 支援 15+ provider，包括 Anthropic、OpenAI、Google、Ollama、OpenRouter、Azure、Bedrock 和其他雲端或 OpenAI-compatible provider。

它可使用 API key，也可透過 ACP 使用已有的 Claude、ChatGPT 或 Gemini 訂閱。

ACP 值得關注，因為很多使用者已有訂閱，但工具未必能直接復用。goose 透過 ACP provider 把訂閱接入 agent 工作流。

使用前仍要確認 provider 條款、額度限制，以及是否適合公司程式碼或敏感資料。

MCP 擴展

goose 支援 Model Context Protocol 擴展。README 提到可連接 70+ extensions。

MCP 的價值在於讓 agent 不只聊天和改檔案，還能透過標準協議接入文件、資料庫、瀏覽器、內部系統、搜尋服務、設計工具或專案管理工具。

對團隊來說，MCP 也可作為更安全的整合層，把內部能力包成明確介面。

和程式碼助手的區別

goose 不只是補全工具，而更像本機 agent runtime。

程式碼助手通常聚焦補全、解釋、生成函式和編輯器局部修改。goose 更強調本地任務執行、多步驟工作流、provider 切換、擴展、桌面端和 CLI、可嵌入 API，以及非程式碼任務。

這也意味著你需要認真處理模型配置、權限、擴展、工作目錄、日誌和憑據管理。

自訂分發

倉庫提供 CUSTOM_DISTROS.md，可構建自己的 goose distro，預配置 provider、extensions 和 branding。

團隊可用它預置允許的 provider、連接內部 MCP server、設定安全策略、限制外部服務，並加入自己的品牌和引導。

使用建議

先安裝桌面端或 CLI。
配置一個確定可用的 provider。
在測試目錄執行簡單任務。
觀察它讀取哪些檔案、執行哪些動作。
再接入 MCP extension。
最後嘗試複雜倉庫或自動化流程。

保持幾個習慣：重要改動前先提交 git，不把 API key 寫進專案檔案，高權限模式只用於可信 workspace，公司資料先確認合規與 provider 政策，自動化結果保留人工 review。

小結

goose 是 AAIF/Linux Foundation 旗下的開源 AI Agent，提供桌面端、CLI 和 API，支援 15+ provider、ACP 訂閱接入和 70+ MCP extensions。

它的價值不只是能寫程式碼，而是把模型、工具、擴展和本機執行環境放進同一個 agent 框架。

參考資料

VS Code 切換介面語言的方法：中文、英文和其他語言

Fri, 08 May 2026 13:18:57 +0800

VS Code 支援多種介面語言。常見做法是先安裝對應語言套件，再透過命令面板選擇顯示語言；如果需要固定某種語言，也可以手動修改 argv.json 中的 locale。

這套方法不只適用於簡體中文，也適用於英文、繁體中文、日文、韓文、法文、德文、西班牙文等語言。

安裝對應語言套件

如果要切換到非英文介面，通常需要先安裝語言套件。

開啟 VS Code 左側擴充功能面板，也可以使用快捷鍵 Ctrl+Shift+X。
在搜尋框中輸入目標語言，例如 Chinese、Japanese、Korean、French。
選擇對應語言套件，點擊 Install。
安裝完成後，依提示重新啟動 VS Code。

簡體中文常用語言套件是 Chinese (Simplified)，繁體中文常用語言套件是 Chinese (Traditional)。

透過命令面板切換語言

這是最推薦的切換方式，適合大多數使用者。

開啟命令面板：Ctrl+Shift+P。
輸入 Configure Display Language。
選擇 Configure Display Language 命令。
在列表中選擇要使用的語言。
依提示重新啟動 VS Code。

重新啟動後，選單、設定頁和常見提示會切換到所選語言。如果列表裡沒有目標語言，先到擴充功能面板安裝對應語言套件。

透過 argv.json 手動指定語言

如果命令面板切換失敗，或者想明確固定顯示語言，可以直接修改 VS Code 的執行階段參數檔案。

開啟命令面板：Ctrl+Shift+P。
輸入並選擇 Preferences: Configure Runtime Arguments。
找到或新增 locale 設定項。
將它改成目標語言代碼。
儲存後重新啟動 VS Code。

例如切換為英文：

1
2
3

{
  "locale": "en"
}

切換為簡體中文：

1
2
3

{
  "locale": "zh-cn"
}

切換為日文：

1
2
3

{
  "locale": "ja"
}

argv.json 是 JSON 檔案，修改時要注意逗號和引號。設定寫錯時，VS Code 可能無法正確讀取語言設定。

常用介面語言代碼

顯示語言	locale
English (US)	`en`
簡體中文	`zh-cn`
繁體中文	`zh-tw`
French	`fr`
German	`de`
Italian	`it`
Spanish	`es`
Japanese	`ja`
Korean	`ko`
Russian	`ru`
Portuguese (Brazil)	`pt-br`
Turkish	`tr`
Bulgarian	`bg`
Hungarian	`hu`

語言沒有生效怎麼辦

可以按下面順序排查：

確認目標語言套件已經安裝。
確認 locale 寫的是正確語言代碼，例如簡體中文是 zh-cn，不是 zh-CN。
修改語言後完整關閉並重新開啟 VS Code。
如果手動改過 argv.json，檢查 JSON 語法是否正確。
如果設定混亂，可以刪除 locale 項，再透過 Configure Display Language 重新選擇。

一般來說，透過 Configure Display Language 切換最省事；只有在需要強制指定語言或命令面板切換不生效時，才建議手動修改 argv.json。

參考資料

VScode：將VScode界面的顯示語言改為簡體中文，切換VScode界面的顯示語言

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

uv 安裝指南：macOS、Linux、Windows、pipx、Homebrew 和 WinGet 怎麼選

Thu, 07 May 2026 23:23:58 +0800

uv 是 Astral 推出的 Python 工具鏈管理器，可以用來管理 Python 版本、虛擬環境、依賴、腳本、專案和工具。它的安裝方式很多，官方文件提供了獨立安裝腳本，也支援 PyPI、Homebrew、WinGet、Scoop、Docker、GitHub Releases 和 Cargo。

如果只是想快速安裝，優先使用官方獨立安裝腳本。如果你希望透過系統套件管理器維護版本，就用 Homebrew、WinGet 或 Scoop。如果你已經習慣用隔離方式安裝 Python 工具，可以用 pipx。

快速選擇

場景	推薦方式	命令
macOS / Linux 快速安裝	官方獨立安裝腳本	`curl -LsSf https://astral.sh/uv/install.sh \| sh`
macOS / Linux 沒有 curl	官方腳本 + wget	`wget -qO- https://astral.sh/uv/install.sh \| sh`
Windows 快速安裝	PowerShell 安裝腳本	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 \| iex"`
Python 工具隔離安裝	pipx	`pipx install uv`
臨時或傳統 Python 安裝	pip	`pip install uv`
macOS 套件管理	Homebrew	`brew install uv`
macOS MacPorts 使用者	MacPorts	`sudo port install uv`
Windows 套件管理	WinGet	`winget install --id=astral-sh.uv -e`
Windows Scoop 使用者	Scoop	`scoop install main/uv`
Rust 使用者	Cargo	`cargo install --locked uv`

最推薦的通用方案：

macOS / Linux：官方獨立安裝腳本；
Windows：官方 PowerShell 安裝腳本或 WinGet；
已經使用 pipx 管理 Python CLI 工具：pipx install uv。

macOS 和 Linux：官方安裝腳本

官方最直接的安裝方式，是用 curl 下載腳本並交給 sh 執行：

`1`	`curl -LsSf https://astral.sh/uv/install.sh \| sh`

如果系統沒有 curl，可以用 wget：

`1`	`wget -qO- https://astral.sh/uv/install.sh \| sh`

如果想安裝指定版本，可以把版本號放進 URL。比如官方範例中的 0.11.11：

`1`	`curl -LsSf https://astral.sh/uv/0.11.11/install.sh \| sh`

這個方式適合絕大多數個人開發環境。它的優點是簡單、跨平台，並且和 uv 官方更新機制配合最好。

安裝腳本會把 uv、uvx 等二進位檔安裝到使用者目錄下，並可能修改 shell profile，讓命令可以直接在終端機中使用。如果你不希望安裝器修改 PATH，可以參考官方 installer 選項，例如設定 UV_NO_MODIFY_PATH=1。

Windows：PowerShell 安裝腳本

Windows 官方安裝方式是用 PowerShell 執行安裝腳本：

`1`	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 \| iex"`

如果要安裝指定版本，也可以把版本號放進 URL：

`1`	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/0.11.11/install.ps1 \| iex"`

這裡的 ExecutionPolicy ByPass 是為了允許從網際網路取得並執行安裝腳本。從安全習慣來看，執行前可以先查看腳本內容：

`1`	`powershell -c "irm https://astral.sh/uv/install.ps1 \| more"`

如果你習慣 Windows 套件管理器，也可以優先用 WinGet 或 Scoop。

用 pipx 安裝

官方文件提到，uv 發布到了 PyPI。如果從 PyPI 安裝，建議放進隔離環境，例如用 pipx：

`1`	`pipx install uv`

這個方式適合已經把 pipx 當作 Python CLI 工具管理器的人。它可以避免把 uv 和目前專案環境混在一起。

如果沒有 pipx，也可以直接用 pip：

`1`	`pip install uv`

但要注意：uv 在許多平台上提供預建 wheel。如果某個平台沒有對應 wheel，就會從原始碼建置，這時需要 Rust 工具鏈。

我的建議是：個人機器上，pipx install uv 比 pip install uv 更乾淨；專案環境裡，不建議把 uv 當作專案依賴安裝。

Homebrew、MacPorts、WinGet 和 Scoop

如果你更喜歡系統套件管理器，uv 也支援常見渠道。

macOS 上用 Homebrew：

`1`	`brew install uv`

MacPorts 使用者可以用：

`1`	`sudo port install uv`

Windows 上用 WinGet：

`1`	`winget install --id=astral-sh.uv -e`

Scoop 使用者可以用：

`1`	`scoop install main/uv`

這些方式的好處是統一交給系統套件管理器維護。缺點是升級節奏取決於對應套件來源，而不是 uv 官方安裝腳本。

Docker、GitHub Releases 和 Cargo

uv 還提供 Docker 映像，地址在 GitHub Container Registry：

`1`	`ghcr.io/astral-sh/uv`

這適合 CI、Dockerfile、建置映像和臨時執行環境。實際使用時，建議再看官方 Docker 整合文件。

如果你想手動下載二進位檔，可以從 GitHub Releases 取得。每個 release 頁面通常包含支援平台的二進位檔，也會說明如何用 GitHub 地址呼叫獨立安裝器。

Rust 使用者也可以從 crates.io 安裝：

`1`	`cargo install --locked uv`

但這個方式會從原始碼建置，需要相容的 Rust 工具鏈。除非你明確需要從 Rust 生態安裝，否則一般使用者不必優先選 Cargo。

升級 uv

如果 uv 是透過官方獨立安裝腳本安裝的，可以用自我更新命令：

`1`	`uv self update`

官方提示說，更新 uv 會重新執行安裝器，並可能修改 shell profile。如果不希望更新時修改 PATH，可以設定：

`1`	`UV_NO_MODIFY_PATH=1`

如果你是透過其他方式安裝的，就應該用對應套件管理器升級。比如用 pip 安裝，就用：

`1`	`pip install --upgrade uv`

Homebrew、WinGet、Scoop、MacPorts 也應該走各自的升級命令。

啟用 shell 自動補全

uv 支援 shell 自動補全。官方文件建議先用下面命令確認目前 shell：

`1`	`echo $SHELL`

Bash：

`1`	`echo 'eval "$(uv generate-shell-completion bash)"' >> ~/.bashrc`

Zsh：

`1`	`echo 'eval "$(uv generate-shell-completion zsh)"' >> ~/.zshrc`

fish：

`1`	`echo 'uv generate-shell-completion fish \| source' > ~/.config/fish/completions/uv.fish`

PowerShell：

if (!(Test-Path -Path $PROFILE)) {
  New-Item -ItemType File -Path $PROFILE -Force
}
Add-Content -Path $PROFILE -Value '(& uv generate-shell-completion powershell) | Out-String | Invoke-Expression'

如果你也經常用 uvx，可以單獨啟用 uvx 補全。

Bash：

`1`	`echo 'eval "$(uvx --generate-shell-completion bash)"' >> ~/.bashrc`

Zsh：

`1`	`echo 'eval "$(uvx --generate-shell-completion zsh)"' >> ~/.zshrc`

fish：

`1`	`echo 'uvx --generate-shell-completion fish \| source' > ~/.config/fish/completions/uvx.fish`

PowerShell：

if (!(Test-Path -Path $PROFILE)) {
  New-Item -ItemType File -Path $PROFILE -Force
}
Add-Content -Path $PROFILE -Value '(& uvx --generate-shell-completion powershell) | Out-String | Invoke-Expression'

設定後需要重新啟動 shell，或重新載入對應設定檔。

解除安裝 uv

如果要解除安裝 uv，可以先清理快取和 uv 儲存的資料：

1
2
3

uv cache clean
rm -r "$(uv python dir)"
rm -r "$(uv tool dir)"

然後刪除二進位檔。

macOS / Linux：

`1`	`rm ~/.local/bin/uv ~/.local/bin/uvx`

Windows：

1
2
3

rm $HOME\.local\bin\uv.exe
rm $HOME\.local\bin\uvx.exe
rm $HOME\.local\bin\uvw.exe

官方文件還提醒：0.5.0 之前，uv 會安裝到 ~/.cargo/bin。如果你從早期版本升級過，舊二進位檔可能仍然留在那裡，需要手動刪除。

安裝後先做什麼

安裝完成後，建議先確認版本：

`1`	`uv --version`

然後可以從幾個常見任務開始：

uv python install
uv venv
uv pip install requests
uvx ruff --version

如果你是新專案，可以進一步學習：

uv init：初始化專案；
uv add：新增依賴；
uv sync：同步環境；
uv run：在專案環境中執行命令；
uvx：臨時執行 Python CLI 工具。

我的建議

個人開發機上，優先使用官方獨立安裝腳本，因為它最貼近 uv 官方文件，也支援 uv self update。

Windows 使用者如果不想執行遠端腳本，可以用 WinGet 或 Scoop。macOS 使用者如果習慣所有工具都交給 Homebrew 管理，可以直接 brew install uv。

已經使用 pipx 管理 Python CLI 工具的人，可以用 pipx install uv。但不建議在具體專案虛擬環境裡用 pip install uv，這樣容易把工具鏈和專案依賴混在一起。

如果是 CI 或容器建置，優先看 Docker 和 GitHub Releases，根據映像建置流程固定版本。

Awesome Codex Skills：給 Codex CLI 擴充技能的社群清單

Thu, 07 May 2026 20:19:15 +0800

ComposioHQ 的 awesome-codex-skills 是一個面向 Codex CLI 的社群技能清單。它的價值不在於再寫一堆提示詞模板，而是把一類可重複的工作流程整理成可安裝、可重複使用、可維護的 Skill。

如果你已經把 Codex 當成日常開發搭檔，這類倉庫的意義會很直接：把經常重複說明的規則、命令、資料入口和操作步驟沉澱下來，下次只要呼叫對應技能，Codex 就能依同一套上下文繼續工作。

這個倉庫解決什麼問題

Codex Skills 可以理解成給 Codex CLI 增加「專門工作模式」的方式。普通提示詞適合臨時說明一次需求，Skill 更適合長期重複使用。

比如你經常需要：

依固定格式生成提交訊息；
查閱某類 API 文件；
執行特定專案的測試和部署命令；
依團隊規範重寫文章、翻譯文件或整理資料；
呼叫外部工具完成重複性的開發輔助任務。

這些內容如果每次都重新輸入，很快就會變成負擔。Skill 的思路是把這些規則放進一個獨立目錄裡，核心通常是一份 SKILL.md，必要時再配合腳本、模板、參考資料或素材檔。Codex 被觸發時會讀取這份說明，然後依照裡面定義的流程執行。

和普通提示詞有什麼不同

普通提示詞更像一次性指令，適合告訴模型「這次怎麼做」。Skill 更像一份小型操作手冊，適合告訴 Codex「以後遇到這類任務都照這個方式做」。

它的優勢主要有三個：

可重複使用：常用工作流不用反覆複製貼上。
可審查：技能檔案通常是本地 Markdown，可以直接打開、修改和版本管理。
可擴充：複雜技能可以帶腳本、模板和參考資料，不只是自然語言說明。

這也是 awesome-codex-skills 這類清單的價值所在：它幫你集中發現已經寫好的技能，再依自己的工作習慣挑選、安裝和改造。

如何安裝和使用

倉庫提供了安裝腳本，也支援手動安裝。典型流程是先 clone 倉庫，再執行安裝腳本：

1
2
3

git clone https://github.com/ComposioHQ/awesome-codex-skills.git
cd awesome-codex-skills
python install.py

如果你只想試用少數技能，建議先看清每個技能目錄裡的 SKILL.md，確認它會讀取哪些資料、執行哪些腳本、修改哪些檔案，再安裝到本地 Codex skills 目錄。

安裝之後，Codex 可以在合適的任務中自動匹配技能，也可以透過明確點名的方式呼叫。對長期使用者來說，更實用的方式往往是：先安裝一個社群技能，再把裡面的說明改成自己的專案規範。

適合關注哪些技能

這類倉庫裡最值得優先看的，不一定是名字最酷的技能，而是能穩定減少重複勞動的技能。

我會優先關注幾類：

開發流程類：程式碼審查、測試、提交、發布、依賴檢查。
文件處理類：重寫、翻譯、摘要、結構化整理。
工具整合類：把 Codex 和外部服務、API、命令列工具連接起來。
專案規範類：把團隊約定、目錄結構、命名規則、部署步驟寫進固定流程。

如果一個技能只是把一句提示詞包裝了一下，價值有限；如果它能把「查資料、判斷、執行、驗證、輸出」串成穩定流程，就值得長期保留。

使用時要注意什麼

社群技能雖然方便，但不要把它當成黑盒直接執行。尤其是帶腳本的 Skill，安裝前最好先檢查三件事：

SKILL.md 裡要求 Codex 做什麼；
是否包含會存取網路、讀寫檔案或呼叫外部服務的腳本；
預設路徑、命令和權限是否適合你的本地環境。

Skill 本質上是在擴大 Codex 的行動邊界。寫得好，它會讓 Codex 更像熟悉你專案的同事；寫得粗糙，它也可能把不適合你的規則帶進工作流。所以最理想的用法不是「裝很多」，而是「裝少數、改到順手、長期維護」。

我的判斷

awesome-codex-skills 值得收藏，尤其適合已經開始用 Codex CLI 做真實開發、文件或自動化任務的人。它不是官方能力本身，而是一個社群整理的技能入口：你可以從裡面找靈感，也可以把常用流程改造成自己的本地技能庫。

對重度使用者來說，Codex Skills 的重點不是讓 AI 多記一點東西，而是讓 AI 在同類任務中少走彎路。把規則寫成 Skill，等於把一次次臨時溝通沉澱成可重複使用的工作基礎設施。

Warp 開源：從終端到 Agentic Development Environment

Thu, 07 May 2026 20:15:08 +0800

warpdotdev/warp 是 Warp 的開源客戶端倉庫。Warp 官方現在把它定位為一個「從終端生長出來的 agentic development environment」，也就是以終端為基礎，但把 AI coding agent、程式碼庫索引、任務管理和開發工作流放進同一個環境裡。

這不是一個普通的終端模擬器開源倉庫。它更像是在回答一個問題：當 Claude Code、Codex、Gemini CLI 這類 agent 越來越常見時，終端本身要不要變成一個能調度、觀察和管理 agent 的開發環境？

Warp 的答案是：要。

這個倉庫現在是什麼狀態

截至 2026 年 5 月 7 日查看，warpdotdev/warp 是公開倉庫，GitHub 頁面顯示約 56k stars、4.1k forks。倉庫 README 說明，Warp 的客戶端程式碼已經開源，並歡迎社群貢獻。

倉庫的主語言是 Rust。GitHub 語言統計裡，Rust 占比超過 98%。這和 Warp 的定位一致：它不是網頁殼，而是一個跨平台的原生開發工具。

README 中有幾個資訊點很重要：

Warp 是一個 agentic development environment, born out of the terminal。
它可以使用內建 coding agent，也可以接入 Claude Code、Codex、Gemini CLI 等外部 CLI agent。
OpenAI 是新開源 Warp 倉庫的 founding sponsor。
倉庫中的 agentic management workflows 由 GPT models 驅動。
Warp UI framework 相關 crate 使用 MIT license，其餘程式碼使用 AGPL v3。

這些資訊說明，Warp 開源不是單純把一個終端放出來，而是把它作為「agent 工作流實驗場」來營運。

Warp 不只是終端

傳統終端主要解決三個問題：

啟動 shell。
執行命令。
顯示輸出。

Warp 早期的差異化，是讓終端更現代：命令區塊、補全、歷史、協作、UI 化互動、跨平台體驗。現在它的重心繼續往前走，開始圍繞 AI agent 組織開發流程。

從 README 看，Warp 不再只強調「更好用的 terminal」，而是強調：

內建 coding agent。
支援外部 CLI agent。
issue triage。
spec 編寫。
PR review。
contributor coordination。
可觀察的 agent sessions。

也就是說，Warp 想把終端從「你輸入命令的地方」，變成「你和多個 agent 一起工作的地方」。

Oz 和開源專案管理

README 裡多次提到 Oz。

Warp 的貢獻概覽頁面可以看到成千上萬個 Oz agents 在做 issue triage、寫 specs、實作改動、review PR。這個設計很有意思，因為它把 AI agent 從「幫個人寫程式碼」擴展到了「幫開源專案管理協作」。

傳統開源專案最難的不是寫程式碼，而是維護：

issue 太多，沒人分類。
bug 和 feature request 混在一起。
新貢獻者不知道哪些任務能做。
PR review 壓力大。
維護者很難持續跟進社群討論。

Warp 的思路是，讓 agent 先承擔一部分專案管理和協作工作。README 中還提到 Oz for OSS，這是面向維護者的合作計畫，用於把類似 agentic open-source management workflows 帶到其他開源倉庫。

這說明 Warp 的野心不只是終端產品本身，也包括探索 AI 時代開源維護的新模式。

倉庫結構和技術棧

從倉庫結構看，Warp 是一個大型 Rust 專案。

根目錄裡能看到：

app/：主應用相關程式碼。
crates/：核心 Rust crates。
assets/：資源檔案。
command-signatures-v2/：命令簽名相關內容。
docker/、script/、resources/、specs/ 等工程目錄。
.claude/、.warp/、.agents/skills 等 agent 相關配置。

WARP.md 裡給出了更詳細的工程說明。它提到 Warp 是 Rust-based terminal emulator，並使用一個自研 UI framework WarpUI。

主要模組可以粗略理解為：

app/：終端模擬、shell 管理、AI 整合、Drive、認證、設定、workspace 和 session。
crates/warp_core/：核心工具和平台抽象。
crates/editor/：文字編輯功能。
crates/warpui/ 和 crates/warpui_core/：自研 UI framework。
crates/ipc/：行程間通訊。
crates/graphql/：GraphQL client 和 schema。

WARP.md 還提到幾個架構特點：

Entity-Handle system。
模組化 workspace 結構。
macOS、Windows、Linux 跨平台，以及 WASM target。
AI integration，包含 Agent Mode、上下文感知和程式碼庫索引。
Warp Drive 雲端同步。

這說明 Warp 的複雜度已經接近一個完整 IDE，而不是傳統意義上的輕量 terminal。

本地建置方式

README 給出的本地建置方式很簡潔：

1
2
3

./script/bootstrap
./script/run
./script/presubmit

其中：

./script/bootstrap：執行平台相關初始化。
./script/run：建置並執行 Warp。
./script/presubmit：執行格式化、clippy 和測試等提交前檢查。

WARP.md 裡還列出了更細的命令：

cargo run
cargo bundle --bin warp
cargo nextest run --no-fail-fast --workspace --exclude command-signatures-v2
cargo fmt
cargo clippy --workspace --all-targets --all-features --tests -- -D warnings

如果要給 Warp 提交程式碼，./script/presubmit 基本是必須跑的。

貢獻流程

Warp 的貢獻流程不是簡單「發 PR 就行」。

README 描述了一個從 issue 到 PR 的輕量流程：

先搜尋已有 issue。
沒有重複再提交 bug 或 feature request。
維護者會 review issue，並可能打上 readiness label。
ready-to-spec 表示設計可以被貢獻者展開成 spec。
ready-to-implement 表示設計已相對明確，可以開始寫程式碼 PR。
貢獻者可以認領帶標籤的 issue。

這個流程適合大型開源專案。它把「想法」「設計」「實作」拆開，減少貢獻者一上來就寫錯方向的風險。

對 AI agent 來說，這也很適合。agent 可以先整理 issue、寫 spec、補測試，再進入實作。Warp 自己也在用這種方式展示 agentic project management。

授權：MIT + AGPL v3

Warp 採用雙授權結構。

README 說明：

Warp UI framework，也就是 warpui_core 和 warpui crates，使用 MIT license。
倉庫其餘程式碼使用 AGPL v3。

這點很重要。AGPL v3 對網路服務和分發有更強的開源要求。如果你只是學習、研究、貢獻程式碼，問題不大；但如果想把 Warp 程式碼用於商業產品或閉源衍生專案，就必須認真讀 license，必要時諮詢法律意見。

簡單說，Warp 是開源了，但不是「隨便拿去閉源商用」的寬鬆授權。

值得關注的地方

第一，Warp 把終端、agent、專案管理放在一起。

很多 AI coding 工具仍然是 CLI 或編輯器外掛。Warp 試圖從終端入口出發，把 agent 任務、程式碼執行、命令輸出、PR 工作流和團隊協作整合起來。

第二，Warp 的開源方式很適合觀察 agent 工作流。

它不只是發布程式碼，還把貢獻概覽、agent session、issue triage 和 spec 流程公開出來。對於想研究 AI 如何參與開源協作的人，這個倉庫本身就是樣本。

第三，Warp 是一個複雜 Rust 桌面應用。

如果你想學習 Rust GUI、終端模擬器、跨平台應用、GraphQL client、雲端同步和 AI 整合，Warp 倉庫有不少可看的結構。但它不是小專案，新貢獻者需要先讀文件和 issue 流程。

第四，Warp 支援「自帶 agent」和「bring your own CLI agent」兩條線。

這點很現實。開發者不會只用一個 agent。Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw 等工具會長期共存。Warp 如果能成為它們的工作台，就比單一終端更有價值。

適合誰關注

如果你是普通終端使用者，關注 Warp 的意義在於：終端可能正在從命令列工具變成 AI 工作台。

如果你是 AI coding agent 重度使用者，Warp 值得關注，因為它試圖管理多個 agent，而不是只做一個聊天入口。

如果你是開源維護者，可以關注 Oz for OSS 這條線。它試圖用 agent 做 issue triage、PR review、社群協作和貢獻者引導。

如果你是 Rust 開發者，Warp 是一個大型真實桌面應用樣本，可以研究它如何組織 UI、終端、雲端同步、AI 整合和跨平台程式碼。

如果你只是想找一個能馬上替代傳統終端的工具，建議先下載正式版使用，再決定是否研究源碼。直接從源碼建置更適合貢獻者和深度玩家。

簡短判斷

Warp 開源的重點，不只是「一個現代終端開源了」。

更準確地說，Warp 正在把終端升級成 agentic development environment：終端負責連接 shell、程式碼庫、命令執行、agent、issue、PR 和協作流程。

在 AI coding agent 持續增長的背景下，開發環境的入口可能會發生變化。過去是 IDE 統治開發體驗，終端負責命令執行；現在終端可能反過來成為 agent 協作的中心。Warp 這個倉庫，正是在探索這種可能性。

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，複雜任務先讓它計劃，高風險動作必須確認。這樣它才會從一個會寫程式碼的助手，變成可以長期協作的工程工具。

如何在 Cline 中呼叫 DeepSeek V4 Pro

Fri, 01 May 2026 20:59:06 +0800

Cline 本身已經支援 OpenAI Compatible Provider。 DeepSeek API 也相容 OpenAI SDK 風格的呼叫方式，所以把 deepseek-v4-pro 接到 Cline 裡並不複雜：選 OpenAI Compatible，填 DeepSeek 的 Base URL、API Key 和模型名即可。

下面按 VS Code 外掛介面和 Cline CLI 兩種方式整理。

準備 DeepSeek API Key

先到 DeepSeek 開放平台建立 API Key。

需要準備三個值：

項目	填寫內容
Provider	`OpenAI Compatible`
Base URL	`https://api.deepseek.com`
Model ID	`deepseek-v4-pro`

DeepSeek 官方文件說明，V4 系列使用既有 OpenAI 相容介面，base_url 保持為 https://api.deepseek.com，呼叫時把 model 設定為 deepseek-v4-pro 或 deepseek-v4-flash。

在 Cline 外掛裡設定

如果你用的是 VS Code 裡的 Cline 外掛，可以按這個路徑設定：

打開 VS Code 側邊欄裡的 Cline。
進入 Cline 的設定或模型設定頁面。
Provider 選擇 OpenAI Compatible。
API Key 填入 DeepSeek API Key。
Base URL 填：

`1`	`https://api.deepseek.com`

Model ID 填：

`1`	`deepseek-v4-pro`

儲存設定，回到 Cline 對話框測試一次簡單任務。

可以先讓 Cline 做一個低風險測試：

`1`	`請讀取目前專案目錄結構，並總結這個專案是什麼類型，不要修改任何檔案。`

如果能正常讀取和回答，說明模型鏈路已經通了。

在 Cline CLI 中設定

如果你使用 Cline CLI，可以用 cline provider configure openai-compatible 進入互動式設定。

範例：

`1`	`cline provider configure openai-compatible`

互動時填寫：

1
2
3

API Key: sk-...
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-pro

設定完成後，可以用一個只讀任務測試：

`1`	`cline "Summarize this repository structure without changing files."`

如果你希望先降低成本，也可以把 Model ID 臨時改成：

`1`	`deepseek-v4-flash`

等遇到複雜規劃、事實核查、多工具協作或高風險程式碼修改時，再切回 deepseek-v4-pro。

上下文長度怎麼填

DeepSeek V4 Pro 和 Flash 都支援很長上下文。在 Cline 裡如果需要手動填寫 context window，可以按 DeepSeek 官方模型頁給出的 1M 上下文來理解。

實際使用時不建議一開始就把所有檔案都塞進上下文。 Cline 會按任務讀取檔案，通常更好的方式是：

先讓它看目錄結構；
再讓它定位相關檔案；
最後只圍繞目標檔案執行修改。

這樣更省 Token，也更容易保持任務邊界清晰。

常見問題

1. 提示模型不存在

先檢查 Model ID 是否寫成：

`1`	`deepseek-v4-pro`

不要寫成 DeepSeek V4 Pro、deepseek-v4 或其他顯示名稱。

2. 提示 401 或認證失敗

檢查 API Key：

是否複製完整；
是否帶了多餘空格；
是否填到了 Cline 目前正在使用的 provider 設定裡；
DeepSeek 帳戶是否有可用額度。

3. 提示連線失敗

檢查 Base URL：

`1`	`https://api.deepseek.com`

不要在末尾額外拼 /v1/chat/completions。 Cline 的 OpenAI Compatible Provider 會自己按相容介面組織請求。

4. Cline 呼叫很貴怎麼辦

可以先把日常任務切到 deepseek-v4-flash，只在複雜任務裡使用 deepseek-v4-pro。

另外，盡量把任務描述寫清楚：

`1`	`只修改登入頁相關檔案，不要重構無關模組。先給出計畫，確認後再改程式碼。`

Agent 任務最怕邊界不清。邊界越清楚，讀檔案越少，工具呼叫越少，成本也越可控。

5. 報錯 reasoning_content must be passed back

如果你看到類似錯誤：

{
  "message": "400 The `reasoning_content` in the thinking mode must be passed back to the API.",
  "code": "invalid_request_error",
  "modelId": "deepseek-v4-pro"
}

這通常不是 Key、額度或 Base URL 的問題，而是 DeepSeek V4 Pro 的 thinking mode 和目前客戶端的多輪工具呼叫記錄沒有對齊。

DeepSeek 官方文件說明：

thinking mode 預設是 enabled；
thinking mode 下會返回 reasoning_content；
如果某一輪發生了 tool call，後續請求必須把該輪 assistant message 裡的 reasoning_content 一起傳回 API；
如果客戶端沒有正確回傳，就會返回 400。

Cline 透過 OpenAI Compatible Provider 接入時，如果目前版本沒有完整保留並回傳 DeepSeek 的 reasoning_content，就可能在第二輪或工具呼叫後觸發這個錯誤。

可嘗試的處理順序：

先升級 Cline 到最新版；
確認使用的是 OpenAI Compatible，而不是普通 OpenAI provider；
如果 Cline 支援自訂 request body，嘗試關閉 thinking mode：

{
  "thinking": {
    "type": "disabled"
  }
}

如果 Cline 不支援額外 body 參數，暫時改用不觸發該問題的模型或服務中轉；
等 Cline 適配 DeepSeek V4 的 reasoning_content 回傳後，再切回 deepseek-v4-pro。

需要注意：關閉 thinking mode 會犧牲一部分複雜推理能力，但可以繞開客戶端沒有回傳 reasoning_content 的相容性問題。

一個可直接複製的設定清單

Provider: OpenAI Compatible
API Key: sk-你的 DeepSeek API Key
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-pro

如果要低成本模式：

Provider: OpenAI Compatible
API Key: sk-你的 DeepSeek API Key
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-flash

小結

在 Cline 中呼叫 DeepSeek V4 Pro 的關鍵只有三步：

Provider 選擇 OpenAI Compatible；
Base URL 填 https://api.deepseek.com；
Model ID 填 deepseek-v4-pro。

設定完成後，建議先用只讀任務測試，再逐步交給它執行真實程式碼修改。如果你經常跑 Agent 任務，可以把 Flash 和 Pro 分開用：Flash 負責高頻輕量任務，Pro 負責複雜判斷和兜底。

參考來源：

mattpocock/skills：給 AI 編程 Agent 準備的實用技能集合

Fri, 01 May 2026 03:43:20 +0800

mattpocock/skills 是 Matt Pocock 公開的一組 AI 編程 agent skills。

它不是一個完整的應用，也不是一個新的聊天客戶端，而是一套可以給 AI 編程助手使用的工作技能。它的思路很實用：把 AI 編程裡經常出現的問題拆成一個個小技能，讓 Agent 在合適的任務裡呼叫，而不是每次都靠一大段提示詞硬撐。

如果你經常使用 Claude Code、Codex、Cursor 或類似的 AI 編程工具，這類 skills 很值得關注。因為真正影響 AI 編程體驗的，往往不是「模型會不會寫程式碼」，而是它能不能按你的工作方式推進任務。

它解決什麼問題

AI 編程助手很強，但也很容易出問題。

常見情況包括：

還沒理解需求就開始改程式碼
一次性改太多檔案
輸出解釋很多，真正有用的行動很少
遇到錯誤後盲目嘗試
沒有及時執行測試或檢查
忽略專案裡已有模式
為了完成任務引入不必要的抽象
寫完程式碼後沒有真正 review 風險

這些問題不一定是模型能力不夠，而是工作流沒有被約束好。

mattpocock/skills 的價值在於，把這些常見失敗模式拆成可以複用的操作方式，讓 Agent 在不同場景下更像一個有經驗的工程協作者。

Skills 是什麼

在 AI Agent 語境裡，skill 可以理解成一段可複用的任務說明、工作方法或專業流程。

它不一定是程式碼插件，也不一定必須呼叫外部服務。很多時候，一個 skill 就是一套明確規則：

什麼時候使用
先做什麼
不要做什麼
需要輸出什麼
怎麼判斷任務完成

這和普通提示詞模板有點像，但粒度更接近「任務能力」。

普通提示詞模板通常是使用者每次臨時複製貼上；skills 則更適合作為 agent 工具箱的一部分，讓 Agent 根據任務選擇合適流程。

為什麼要小而可組合

README 中強調這些 skills 是小而可組合的。

這個方向很重要。

如果一個 skill 試圖包辦所有事情，它很快就會變成新的大提示詞：又長、又模糊、又難維護。小技能的優勢是邊界清楚。

比如一個 skill 專門負責：

先做計劃
修復 TypeScript 錯誤
執行測試並根據結果修復
做程式碼 review
總結專案約定
改進提示詞
清理無用抽象

這些技能可以按任務組合使用。簡單任務只用一個技能，複雜任務再串起來。

這更接近真實工程工作：你不會用同一套流程處理所有問題，而是根據問題選擇工具。

保留工程師控制權

這個倉庫的一個重要取向，是讓工程師仍然掌握控制權。

AI 編程很容易滑向兩種極端：

第一種是完全手動。AI 只是幫你寫幾行程式碼，所有上下文、計劃、驗證都靠你自己盯。

第二種是完全放手。你把任務丟給 Agent，讓它自己大改一通，最後再面對一堆難以審查的 diff。

skills 的作用是在中間找一個更穩的位置。

它讓 AI 承擔更多重複流程，但仍然用規則限制它：

先理解任務再動手
先閱讀相關檔案再改
修改範圍要可控
出現不確定時要回報
改完要驗證
不能為了炫技重構無關程式碼

這不是削弱 AI，而是讓 AI 的行動更容易被人類審查和接管。

對齊問題

AI 編程失敗的第一類問題通常是對齊失敗。

使用者想要的是一個很具體的改動，但 Agent 可能理解成一個更大的重構；使用者只想修 Bug，它卻順手改了樣式；使用者希望遵守現有架構，它卻引入新模式。

Skills 可以在任務開始階段幫助 Agent 做幾件事：

重述目標
找出影響範圍
識別已有實現模式
給出計劃
明確不做哪些事情

這一步很像工程師開工前的自檢。

如果 Agent 連任務邊界都沒說清楚，就直接寫程式碼，後面很容易越走越偏。

回饋循環問題

AI 寫程式碼不能只靠一次生成。

真實開發裡，回饋循環很重要：

改一小步
跑測試或型別檢查
看錯誤
修正
再驗證

很多 Agent 失敗，是因為它跳過了中間回饋。它一次性改很多內容，然後憑感覺總結「應該可以工作」。

Skills 可以把回饋循環顯式寫進流程裡。比如要求 Agent：

修改後執行相關檢查
如果檢查失敗，先讀錯誤訊息
不要盲目改無關檔案
每輪修復後重新驗證
最後報告驗證結果

這會讓 AI 編程更像真實除錯，而不是一次性作文。

架構控制問題

AI 很擅長生成抽象，也很擅長過度生成抽象。

為了完成一個小需求，它可能新建服務層、工具函式、配置物件、型別包裝、適配器，最後讓程式碼比需求本身複雜得多。

這類問題在大型專案裡尤其危險。因為 AI 生成的抽象看起來很「專業」，但它可能不符合專案已有風格，也可能增加維護成本。

好的 skills 會提醒 Agent：

優先沿用現有模式
不引入沒有必要的新抽象
不順手重構無關區域
修改要和任務規模匹配
先理解程式碼再設計結構

這能減少「看起來很工程化，實際上更難維護」的輸出。

Review 技能為什麼重要

寫程式碼和 review 程式碼是兩種不同狀態。

Agent 在寫程式碼時，通常會傾向於證明自己的實現成立。它會解釋為什麼這樣改可以工作，但不一定主動找風險。

Review skill 的意義，是讓 Agent 切換角色：

找潛在 Bug
找行為回歸
找遺漏測試
找邊界條件
找複雜度上升
找和現有約定不一致的地方

這對 AI 編程很重要。因為 AI 生成程式碼的速度很快，如果沒有 review，使用者很容易被大量 diff 淹沒。

一個好的 review 輸出應該優先列問題，而不是先誇實現。它要幫助工程師判斷這次改動能不能合併。

和普通 rules 檔案有什麼區別

很多 AI 編程工具都支援 rules、instructions 或 memory。

這些檔案通常記錄長期規則，比如：

專案技術棧
命名規範
測試命令
不要修改哪些目錄
回答風格偏好

Skills 更偏任務流程。

rules 告訴 Agent「長期應該怎麼做」，skills 告訴 Agent「面對某類任務時應該怎麼執行」。

兩者最好一起用。

比如 rules 裡寫專案用 pnpm test，review skill 裡要求改完後檢查測試覆蓋。這樣 Agent 不僅知道命令，也知道什麼時候該用。

適合什麼場景

mattpocock/skills 這類倉庫適合這些場景：

高頻使用 AI 編程工具
經常讓 Agent 處理真實程式碼庫
想減少 AI 越界修改
想讓 Agent 更主動地驗證結果
想把自己的工程習慣沉澱成技能
想學習別人如何設計 agent workflows
想把一堆臨時提示詞整理成可維護的技能集合

如果你只是偶爾讓 AI 寫一個小函式，可能不需要專門維護 skills。

但如果你已經把 AI 當成長期開發夥伴，skills 會逐漸變得重要。它們相當於給 Agent 配了一套可複用的工作方法。

怎麼借鑑這個倉庫

即使你不直接使用其中的每個 skill，也可以從這個倉庫學到幾件事。

第一，把失敗模式寫下來。

不要只在 AI 出錯時臨時抱怨。把它經常出錯的模式整理成規則，下一次讓 skill 提前防住。

第二，技能要短。

一個 skill 最好解決一個明確問題。越短越容易被正確呼叫，也越容易維護。

第三，輸出格式要清楚。

如果你希望 Agent 先列計劃、再執行、最後總結驗證結果，就把輸出結構寫清楚。模糊要求通常會得到模糊結果。

第四，保留人工接管點。

好的 skill 不應該讓 AI 獨自跑到很遠。遇到不確定、影響範圍擴大、測試失敗或需要產品判斷時，應該讓它停下來說明情況。

使用時要注意

第一，不要把所有事情都技能化。

太多 skills 會讓系統變複雜，Agent 也可能不知道該選哪個。先從最高頻、最痛的幾個場景開始。

第二，skills 需要迭代。

第一次寫出來的 skill 不一定好。看 AI 實際執行效果，再逐步刪減、補充和改寫。

第三，不要讓 skill 替代工程判斷。

Skill 可以改善流程，但不能保證實現正確。測試、review、構建檢查和人類判斷仍然重要。

第四，注意不同 Agent 的差異。

Claude Code、Codex、Cursor、Copilot 對 instructions、skills、rules 的支援方式不同。同一套思想可以複用，但具體格式要按工具調整。

參考

mattpocock/skills

最後一句

mattpocock/skills 值得關注的地方，不是裡面某一個神奇提示詞，而是它展示了一種更實用的 AI 編程思路：把工程經驗拆成小技能，再讓 Agent 按場景組合使用。

當 AI 編程從偶爾輔助變成日常工作流，skills 會成為約束 Agent、保留工程師控制權和提升回饋品質的重要工具。

Compound Engineering Plugin：把 AI 編程變成計劃、執行、評審的工程循環

Fri, 01 May 2026 03:15:39 +0800

Compound Engineering Plugin 是 Every Inc 開源的一個 AI 編程工作流插件。

它關注的不是「讓 AI 更快寫一段程式碼」，而是把 AI 編程放進一個更像工程團隊的循環裡：先計劃，再實現，再評審，再把經驗沉澱下來。對經常使用 Claude Code、Codex、Cursor、Copilot 這類工具的人來說，這類插件解決的是工作流問題，而不只是提示詞問題。

AI 編程工具越來越強，但真實專案裡最難的往往不是生成程式碼，而是讓它持續按專案規則做事、理解任務邊界、避免重複犯錯，並在多輪迭代中積累上下文。

它解決什麼問題

很多人使用 AI 編程助手時，流程大概是這樣：

直接描述需求
讓 AI 改程式碼
看結果是否能跑
出錯後繼續補充說明
下次新任務再從頭解釋一遍

這種方式能完成小任務，但在複雜專案裡很容易遇到問題：

需求沒有先拆清楚，AI 直接開始改
改完程式碼後缺少系統性 review
專案規範靠使用者反覆提醒
同類錯誤下次仍然出現
多個 Agent 工具之間缺少統一工作方法
經驗沒有沉澱成可複用規則

Compound Engineering Plugin 想解決的就是這類問題。它把 AI 編程拆成多個階段，讓 Agent 不只是執行命令，而是參與一個更完整的工程流程。

什麼是 Compound Engineering

從專案 README 的描述看，Compound Engineering 可以理解為一種 AI 輔助軟體開發方法。

它強調一個循環：

計劃：先理解目標、拆分任務、確認路徑
執行：按計劃修改程式碼、執行命令、處理問題
評審：檢查實現品質、風險和測試覆蓋
學習：把經驗沉澱成後續可複用的規則

這個循環很像真實工程團隊的工作方式。

一個可靠的工程師不會拿到需求就立刻亂改，也不會改完就直接交差。他會先判斷影響範圍，再動手實現，之後檢查風險和測試結果，最後把踩過的坑記錄下來。AI Agent 也需要類似約束。

為什麼需要插件

提示詞可以告訴 AI「請先計劃再執行」，但提示詞本身不一定穩定。

一旦會話變長、上下文變複雜，模型可能會跳過計劃、忽略規則，或者為了完成任務而過度自信。插件的價值在於把流程固化下來，讓不同 Agent 環境都能遵循類似方法。

這類插件通常會把工作流拆成命令、規則、模板或子流程。使用者不需要每次手寫完整提示詞，而是透過固定入口觸發某個階段。

比如：

先讓 Agent 生成計劃
再按計劃逐步實現
改完後觸發 review
發現問題後返回修正
把值得保留的經驗寫入記憶或規則

這會讓 AI 編程更像「受控協作」，而不是一次性聊天。

支援哪些 Agent 環境

README 中提到，專案支援多個 AI 編程環境，包括：

Claude Code
Codex
Cursor
GitHub Copilot
Amp
Factory
Qwen Code

這點值得注意。

很多工作流工具只綁定一個客戶端，換工具後規則就不能複用。Compound Engineering Plugin 更像一套跨 Agent 的工程方法，把類似的計劃、執行、評審流程帶到不同工具裡。

如果你同時使用多個 AI 編程助手，這類統一工作流會更有價值。不同工具能力不同，但專案規範、評審習慣和任務拆解方法應該盡量一致。

計劃階段有什麼用

計劃階段的價值，是防止 AI 過早動手。

複雜任務裡，真正重要的問題通常是：

要改哪些檔案
哪些模組可能受影響
現有模式是什麼
有沒有測試
風險點在哪裡
是否需要先閱讀文件
能不能拆成更小步驟

如果 Agent 沒有先想清楚這些問題，就直接開始寫程式碼，很容易做出看似完成、實際偏離專案結構的實現。

計劃並不一定要很長。好的計劃應該短、具體、可執行。它的目的不是製造文件，而是讓後續實現有邊界。

執行階段要避免什麼

AI 執行程式碼任務時，最容易出現幾類問題：

順手重構無關程式碼
覆蓋使用者已有修改
只改 happy path
忽略錯誤處理
不按專案已有風格寫
沒有執行必要驗證
遇到錯誤後盲目嘗試

工作流插件無法保證這些問題完全消失，但可以透過規則和階段約束減少發生機率。

比如，執行階段可以要求 Agent 按計劃逐步推進；遇到超出計劃範圍的發現時，先說明風險；修改共享模組時，補充測試或至少執行相關驗證。

這種約束對大型程式碼庫尤其重要。AI 寫程式碼越快，越需要流程來限制它的慣性。

評審階段為什麼重要

很多 AI 編程失敗，不是因為程式碼完全不能執行，而是因為細節有問題：

邊界條件沒處理
狀態更新不一致
API 合約被悄悄改了
測試覆蓋不到關鍵路徑
錯誤提示不清楚
效能或安全風險沒有被提到

評審階段就是把 Agent 從「作者模式」切換到「審查模式」。

作者模式容易為自己的實現找理由；審查模式則要主動找漏洞、回歸風險和遺漏測試。把這兩個階段分開，會比讓同一個回覆裡同時完成實現和自我審查更可靠。

對使用者來說，評審輸出也更有價值。它能幫助你快速判斷這次修改是否值得合併，還是需要繼續返工。

學習和記憶的意義

專案名字裡的 “Compound” 暗示了一個重要想法：工程經驗應該複利增長。

如果 AI 每次犯錯後只是當場修好，下次又犯同樣錯誤，效率提升就很有限。更好的方式是把有價值的經驗沉澱下來：

這個專案的目錄約定
某類錯誤的排查方法
測試命令和注意事項
不要觸碰的生成檔案
程式碼風格偏好
常見實現模式

這些經驗可以變成規則、記憶、文件或模板。後續任務中，Agent 先讀取這些沉澱，再開始工作。

這就是 AI 編程從「單次問答」走向「長期協作」的關鍵。

適合什麼場景

Compound Engineering Plugin 適合這些場景：

長期使用 AI Agent 寫程式碼
一個專案會被多次、多輪修改
希望 AI 先計劃再實現
希望改完後自動進入 review 思維
團隊想統一 AI 編程流程
同時使用 Claude Code、Codex、Cursor 等多個工具
希望把專案經驗沉澱成可複用規則

如果只是偶爾讓 AI 寫一個小腳本，完整流程可能顯得偏重。

但如果你正在把 AI 編程助手當成日常開發夥伴，計劃、執行、評審、學習這套循環就會明顯有用。

和普通提示詞模板有什麼區別

普通提示詞模板通常解決的是「怎麼說清楚任務」。

比如：

請一步步思考
請先閱讀檔案
請保持程式碼風格一致
請執行測試
請總結修改內容

這些提示當然有用，但它們還是依賴使用者每次正確使用。

Compound Engineering Plugin 更偏工作流層。它把這些要求組織成可重複的過程，並適配不同 Agent 工具。這樣你不是每次從零寫提示詞，而是在一套流程裡推進任務。

簡單說，提示詞模板像提醒，工作流插件像制度。

使用時要注意

第一，不要把流程變成負擔。

小任務不一定需要完整計劃和長篇評審。好的工作流應該能根據任務複雜度調整，簡單問題快速處理，複雜問題再走完整循環。

第二，評審不能替代測試。

Agent review 能發現很多問題，但它仍然可能漏掉真實執行時錯誤。最終判斷還要看測試、型別檢查、構建結果和人工審查。

第三，規則要持續清理。

沉澱經驗很重要，但規則越積越多也會變成噪音。過時規則、重複規則、只適合某次任務的臨時經驗，都應該定期整理。

第四，跨工具一致不等於完全相同。

Claude Code、Codex、Cursor、Copilot 等工具能力和互動方式不同。統一的是工作方法，不一定是每個命令、每個配置細節都完全一樣。

適合怎樣的團隊

如果一個團隊已經允許 AI Agent 修改真實程式碼，那麼只討論「哪個模型更強」是不夠的。

更應該關心：

AI 修改前是否理解任務
AI 修改中是否遵守專案邊界
AI 修改後是否主動審查風險
AI 是否能從歷史錯誤中學習
團隊是否有統一的 Agent 使用規範

Compound Engineering Plugin 這類專案的意義就在這裡。它把 AI 編程從個人技巧，往團隊可複用流程推進了一步。

參考

EveryInc/compound-engineering-plugin

最後一句

Compound Engineering Plugin 值得關注的地方，不是多一個 AI 編程命令，而是把 AI 編程組織成可循環改進的工程流程。

當 AI Agent 開始參與真實專案，計劃、執行、評審和經驗沉澱會比單次生成程式碼更重要。

Claude Code Hooks Mastery：13 個 Hooks 生命週期與自動化控制入門

Fri, 01 May 2026 03:11:27 +0800

claude-code-hooks-mastery 是一個圍繞 Claude Code Hooks 的學習專案。

它不是只給幾個零散腳本，而是把 Claude Code 的 hooks 生命週期、配置方式、腳本寫法和常見自動化場景放在一起講清楚。對想讓 Claude Code 更可控、更像工程化助手的人來說，這類資料很值得看。

Claude Code 預設已經能讀程式碼、改檔案、跑命令。但如果你想讓它在特定時機自動檢查權限、攔截危險操作、注入專案規範、執行測試、提醒團隊規則，單靠聊天指令就不夠穩定。Hooks 的價值就在這裡：把「每次都要提醒 AI 的規則」變成可執行的流程。

Hooks 解決什麼問題

使用 Claude Code 一段時間後，常見痛點大概有這些：

每次新會話都要重複告訴它專案規則
擔心它執行不該執行的命令
希望檔案修改前後自動做檢查
想在提交前自動跑格式化、測試或安全掃描
想把團隊規範寫成固定流程，而不是靠口頭提醒
想在工具呼叫前後拿到上下文，做記錄或攔截
希望複雜任務可以觸發子代理或專門腳本處理

Hooks 就是為這些「固定時機的自動動作」準備的。

你可以把它理解成 Claude Code 工作流裡的事件鉤子：當會話開始、使用者提交提示詞、模型準備呼叫工具、工具呼叫完成、代理即將結束等節點發生時，Claude Code 可以執行你配置的腳本。

13 個 Hooks 生命週期

專案 README 的重點之一，是系統整理了 Claude Code 的 13 個 hook 事件。

這些事件覆蓋了從會話開始到工具呼叫、從使用者輸入到代理結束的多個節點。按用途可以粗略分成幾類：

會話啟動相關：用於初始化環境、注入專案上下文
使用者輸入相關：用於檢查提示詞、補充規則、做稽核
工具呼叫前相關：用於權限判斷、命令攔截、安全檢查
工具呼叫後相關：用於記錄結果、觸發格式化、執行驗證
任務結束相關：用於總結、清理、通知或保存狀態

這種生命週期設計讓你不必把所有規則都寫進一個超長提示詞裡。

比如，權限控制應該發生在工具呼叫前；格式化檢查更適合發生在檔案修改後；專案規範注入適合發生在會話開始或使用者輸入後。把規則放到正確的 hook 節點，通常比把所有內容塞進 system prompt 更可靠。

配置檔案在哪裡

Claude Code 的 hooks 通常透過設定檔配置。

常見位置包括：

使用者級配置：~/.claude/settings.json
專案級配置：.claude/settings.json

使用者級配置適合放個人偏好，比如通用安全規則、命令攔截、日誌路徑。

專案級配置適合放倉庫相關規則，比如這個專案必須跑什麼測試、哪些目錄不能改、生成檔案怎麼處理、提交前要做哪些檢查。

如果你在團隊裡使用 Claude Code，更推薦把專案級配置放進倉庫。這樣每個人打開專案時，拿到的是同一套 AI 協作約束，而不是各自憑記憶提醒。

單檔案腳本為什麼重要

專案裡強調了 UV 單檔案腳本的寫法。

這類腳本的好處是部署簡單。一個 Python 檔案就可以宣告依賴並執行，不必為了一個 hook 單獨維護複雜環境。對 hooks 來說，這很合適，因為很多 hook 只是做一件小事：

檢查命令是否允許執行
判斷檔案路徑是否安全
讀取專案規範並返回給 Claude
掃描輸出中是否包含敏感資訊
在修改後執行格式化或測試
把事件寫入日誌

Hook 腳本越小，越容易維護，也越不容易變成新的複雜系統。

可以做哪些自動化

claude-code-hooks-mastery 展示的方向比較多，實際工作中最常見的是下面幾類。

1. 權限和安全控制

這是 hooks 最直接的用途。

比如在 Claude Code 準備執行命令之前，先檢查命令內容。如果命令包含刪除、重置、清空、覆蓋等高風險動作，就阻止執行或要求人工確認。

類似規則還可以用於檔案路徑：

不允許修改生產配置
不允許寫入金鑰檔案
不允許刪除遷移腳本
不允許觸碰指定目錄
不允許執行未批准的網路命令

這類保護放在工具呼叫前，比寫一句「不要做危險操作」更可靠。

2. 上下文注入

很多專案都有固定背景：

技術棧
編碼規範
測試命令
分支策略
目錄結構
禁止事項
生成檔案處理規則

這些內容每次手動告訴 Claude Code 很麻煩，也容易漏。Hooks 可以在會話開始或使用者提交提示詞後，把必要上下文自動注入進去。

這相當於給 Claude Code 配一個專案級的工作說明書。它不會替代 README 或開發文件，但能讓 AI 在執行任務前更快進入正確狀態。

3. 修改後的驗證

當 Claude Code 修改檔案後，可以透過 hook 自動觸發檢查。

常見動作包括：

執行格式化
執行 lint
執行單元測試
檢查型別錯誤
掃描生成檔案
校驗 Markdown 或 JSON 格式

這對減少低級錯誤很有幫助。尤其是 AI 改動多個檔案時，修改後自動跑一輪輕量驗證，可以更早發現問題。

不過也要注意，hook 裡不適合預設塞太重的任務。每次檔案改動都跑完整測試套件，可能會讓體驗變得很慢。更實用的做法是按檔案類型、目錄和任務風險選擇檢查範圍。

4. 團隊規則驗證

如果團隊已經有明確約定，可以把一部分約定放進 hooks。

比如：

提交訊息格式
程式碼風格規則
禁止直接修改某些生成檔案
文件必須同步更新
API 變更必須改測試
某些目錄只能用指定工具生成

這會讓 Claude Code 更像團隊流程的一部分，而不是一個不受約束的外部助手。

當然，hooks 不應該替代 CI。它更適合做本地快速提醒和前置攔截，真正的最終驗證仍然應該交給 CI、review 和測試系統。

5. 子代理和專門任務

README 裡還提到子代理相關內容。

這類用法適合把複雜任務拆給更專門的流程處理。比如主會話負責理解需求，hook 或配置觸發專門的檢查、稽核、總結、文件整理任務。

對個人使用者來說，最先值得做的不是複雜代理編排，而是把重複、明確、低風險的動作交給 hooks。等規則穩定後，再考慮更複雜的自動化。

Statusline 和輸出樣式

專案還覆蓋了狀態列和輸出樣式。

這部分看起來像體驗細節，但對長期使用 Claude Code 很有意義。狀態列可以展示當前上下文、任務狀態、環境資訊或提示資訊；輸出樣式則可以讓 Claude Code 的回答更符合你的工作習慣。

如果你每天都在同一個終端裡和 AI 協作，這些細節會影響效率。好的狀態提示能減少誤操作，也能讓你更快判斷當前會話是否處在正確專案、正確分支、正確環境裡。

不要把 hooks 寫得過重

Hooks 很強，但不適合什麼都往裡面塞。

比較好的規則是：

高頻動作要快
安全攔截要明確
輸出要短
失敗原因要可讀
腳本盡量單一職責
重型檢查交給顯式命令或 CI

如果一個 hook 每次都執行十幾秒，使用者很快就會想關掉它。如果一個 hook 攔截規則含糊不清，Claude Code 和使用者都會難以理解下一步該怎麼做。

Hooks 最適合處理那些邊界清楚的事情：允許或拒絕、補充上下文、記錄日誌、執行輕量檢查、提示下一步。

適合怎樣的使用者

如果你只是偶爾讓 Claude Code 改一小段程式碼，可能暫時不需要深入 hooks。

但如果你符合下面幾種情況，就很適合研究這個專案：

高頻使用 Claude Code
經常讓 AI 修改真實專案程式碼
擔心 AI 執行危險命令
想把團隊規範自動注入 AI 工作流
希望修改後自動跑檢查
想把重複提醒變成配置
正在搭建更穩定的 AI 編程流程

尤其是多人協作專案，hooks 的意義會更明顯。它可以把一部分團隊經驗沉澱成腳本，而不是靠每個人臨時提醒 AI。

使用時要注意

第一，先從安全類 hook 開始。

相比複雜自動化，命令攔截、路徑保護、敏感檔案檢查更容易落地，也更能立刻降低風險。

第二，專案級規則要謹慎提交。

.claude/settings.json 會影響所有使用這個倉庫的人。把規則提交前，最好確認它不會過度限制正常開發，也不會依賴只有你本機才存在的路徑。

第三，hook 輸出要簡潔。

Claude Code 會消費這些輸出。輸出太長，會污染上下文；輸出太模糊，又起不到指導作用。最好只返回必要判斷和下一步建議。

第四，保持可除錯。

Hooks 一旦變多，問題可能出在配置、腳本、權限、路徑、依賴或 Claude Code 本身。給腳本留下清楚日誌，會讓後續排查輕鬆很多。

參考

disler/claude-code-hooks-mastery

最後一句

Claude Code Hooks 的價值，是把「希望 AI 每次都記住的規矩」變成真正會執行的流程。

如果你已經開始把 Claude Code 用在真實專案裡，hooks 會是從「會聊天的編程助手」走向「可約束的工程協作者」的關鍵一步。

Claude-Mem：給 Claude Code 加上跨會話長期記憶

Fri, 01 May 2026 03:01:02 +0800

Claude-Mem 是一個給 Claude Code 使用的持久化記憶系統。

它想解決的問題很具體：AI 編程助手每次開新會話時，往往會忘記之前討論過的架構決策、踩過的坑、專案偏好和實作背景。
如果一個專案做得久，每次都重新解釋上下文，非常浪費時間。

Claude-Mem 的思路是：把 Claude Code 的會話內容壓縮成記憶，存進本地資料庫和向量庫，之後再透過搜尋工具找回來。

它解決什麼問題

Claude Code 很適合處理程式碼任務，但會話上下文畢竟有限。

常見痛點包括：

新會話不知道舊會話做過什麼
專案裡的設計決策需要反覆解釋
曾經排查過的問題容易重複踩
長期任務缺少連續記憶
多次對話之間很難沉澱專案知識

Claude-Mem 就是圍繞這些問題設計的。

它不是簡單保存聊天記錄，而是把會話壓縮成更容易檢索的記憶片段。這樣後續需要時，可以透過語義搜尋把相關上下文找回來。

工作方式

從 README 的設計看，Claude-Mem 主要由幾部分組成。

第一部分是 hooks。

它會接入 Claude Code 的會話流程，在合適的時機捕獲會話資料。

第二部分是後台 worker。

worker 負責把原始會話內容處理成更短、更可檢索的記憶。

第三部分是本地儲存。

專案使用 SQLite 保存結構化元資料，用 Chroma 保存向量索引。這樣既能保留會話記錄的基本資訊，也能支援語義檢索。

第四部分是 mem-search。

這是給 Claude Code 使用的查詢入口。需要找回舊上下文時，可以透過它搜尋相關記憶。

整體流程可以理解為：

Claude Code 會話產生內容
hooks 捕獲會話資料
worker 非同步壓縮和整理
記憶寫入 SQLite 與 Chroma
後續透過 mem-search 檢索

適合什麼場景

Claude-Mem 適合長期專案，而不是一次性小任務。

比如：

一個倉庫持續開發很多天
程式碼結構複雜，背景說明很多
需要記住專案約定、命名習慣和架構選擇
經常讓 Claude Code 修 Bug、寫功能、整理文件
希望 AI 能記住「之前為什麼這麼改」

如果你只是臨時讓 Claude Code 改一行程式碼，長期記憶意義不大。
但如果你把 Claude Code 當作長期協作者，它就會變得有用。

安裝和啟動

README 中給出的安裝方式很直接：

1
2

npm install -g claude-mem
claude-mem install

啟動時可以使用：

`1`	`claude-mem start`

查看狀態：

`1`	`claude-mem status`

如果需要停止：

`1`	`claude-mem stop`

這些命令背後的目標，是把記憶系統作為一個長期執行的本地服務接到 Claude Code 工作流裡。

`mem-search` 怎麼用

mem-search 是找回記憶的關鍵入口。

它的用途不是替代普通搜尋，而是讓 Claude Code 能按語義查詢過去會話中的內容。

比如你可以讓 Claude Code 查詢：

某個模組之前為什麼這樣設計
某個 Bug 當時怎麼排查
專案裡約定的命名規則
之前討論過的技術取捨
某次重構的背景原因

這種查詢和簡單關鍵字搜尋不同。
如果記憶壓縮和向量索引做得好，即使你不記得原話，也能找回相近語義的內容。

和普通專案文件有什麼區別

專案文件適合記錄穩定結論。

比如：

架構說明
部署流程
API 約定
資料庫結構
開發規範

Claude-Mem 更適合記錄會話過程中產生的上下文。

比如：

為什麼某個方案被放棄
某個臨時問題怎麼繞過
某個實作背後的討論過程
還沒來得及寫進文件的專案偏好
多次對話裡積累出的任務背景

兩者不是互相替代。
比較好的方式是：穩定知識寫進專案文件，過程性上下文交給記憶系統輔助檢索。

使用時要注意什麼

第一，長期記憶不是越多越好。

如果所有對話都無差別保存，後續檢索可能會變得嘈雜。真正有價值的是專案決策、實作背景、問題排查和長期偏好。

第二，記憶不能替代程式碼和文件。

AI 搜到的舊上下文只能作為參考。最終判斷仍然要看目前程式碼、測試結果和最新需求。

第三，隱私和本地資料要注意。

既然它會保存會話內容，就要清楚哪些專案適合接入，哪些敏感資訊不應該進入對話。

第四，記憶系統需要維護。

隨著專案推進，舊記憶可能過時。過時的上下文如果被誤用，反而會誤導後續任務。

為什麼這類工具值得關注

AI 編程工具正在從「單次問答」走向「長期協作」。

單次問答裡，模型只要回答目前問題就夠了。
長期協作裡，它需要知道專案歷史、之前的決策、團隊偏好和已經踩過的坑。

Claude-Mem 這類工具的意義就在這裡：它把「記住上下文」從臨時聊天能力，變成一個可以安裝、執行、檢索的本地系統。

對真實工程專案來說，這比單純讓模型上下文窗口變長更實用。
因為很多資訊不是一次性塞進上下文就好，而是需要在合適的時候被找回來。

適合誰嘗試

如果你符合下面幾種情況，可以考慮試試：

高頻使用 Claude Code
經常跨天處理同一個專案
專案上下文比較複雜
經常需要向 AI 重複解釋背景
想把會話裡的經驗沉澱下來

如果你只是偶爾使用 Claude Code，或者專案很小，暫時不一定需要這類系統。

參考

thedotmack/claude-mem

最後一句

Claude-Mem 的重點不是「保存聊天記錄」，而是讓 Claude Code 能在後續任務裡找回有用上下文。

當 AI 編程從一次性任務變成長期專案協作，記憶系統會越來越重要。
它不能替代文件和測試，但可以減少重複解釋，讓 AI 更像一個了解專案歷史的助手。

編譯 UEFI 程式入門：從 uefi-simple 到第一個 .EFI

Thu, 30 Apr 2026 19:53:08 +0800

編譯第一個 UEFI 程式並不輕鬆：環境安裝耗時，連結器錯誤很多，.EFI 程式也不像普通桌面程式那樣有成熟直觀的編輯和執行體驗。

這篇就按入門角度整理一下：如果只是想先編譯出自己的第一個 UEFI 程式，應該從哪裡開始，哪些概念要先搞清楚，哪些坑最容易遇到。

UEFI 程式是什麼

UEFI 程式通常是一個 .EFI 檔案。

它不是 Windows 下雙擊執行的普通 .exe，而是執行在 UEFI 韌體環境裡的 PE/COFF 可執行檔。常見場景包括：

啟動管理器
硬體初始化工具
韌體更新工具
開機前診斷工具
自訂啟動流程

你在系統啟動早期看到的很多功能，本質上都可能和 UEFI 應用程式、驅動或韌體服務有關。

對初學者來說，先不用急著理解完整韌體開發。第一步只要完成一個目標：編譯出一個能被 UEFI Shell 或模擬器載入的 .EFI 檔案。

為什麼不建議一開始就上 EDK II

UEFI 正式開發經常會遇到 EDK II。

EDK II 功能完整，也更接近真實韌體工程，但它對新手不太友好：

工程結構複雜
建構系統有學習成本
環境變數和工具鏈配置比較多
編譯錯誤不容易看懂
很容易還沒寫程式碼，就先卡在環境上

如果目標只是「先跑起來一個最小 UEFI 程式」，更適合從輕量範例開始。

pbatard/uefi-simple 就是這類專案。它的定位很直接：提供一個簡單的 UEFI Hello World 範例，讓你先把 .EFI 編譯出來。

`uefi-simple` 適合用來做什麼

uefi-simple 適合做 UEFI 入門的第一塊踏板。

它主要解決三個問題：

給你一個最小可編譯的 UEFI 應用結構
幫你避開一開始就接觸大型韌體工程的複雜度
讓你能先驗證編譯、連結、執行鏈路是否通

這個專案支援不同建構方式，包括 Visual Studio 2022 和 MinGW/gcc，也可以配合 QEMU 與 OVMF 做測試。

也就是說，你不一定非要準備真實機器反覆重開機測試。先用模擬器把程式跑起來，會安全很多。

入門前要準備哪些東西

最少需要準備幾類工具。

第一類是編譯工具鏈。

如果你在 Windows 上，可以優先考慮：

Visual Studio 2022
或 MinGW/gcc

第二類是 UEFI 執行環境。

可以有兩種選擇：

用真實機器的 UEFI Shell 執行 .EFI
用 QEMU + OVMF 在虛擬環境裡測試

第三類是範例專案。

新手不建議從空目錄開始手寫建構腳本。直接使用 uefi-simple 這類最小範例，可以少踩很多建構系統的坑。

大致流程

一個最小 UEFI 程式的入門流程可以這樣理解。

第一步，取得範例專案。

`1`	`git clone https://github.com/pbatard/uefi-simple.git`

第二步，選擇建構工具鏈。

如果用 Visual Studio，就按專案裡的 Visual Studio 方案建構。
如果用 MinGW/gcc，就按專案提供的 Makefile 或說明走。

第三步，產生 .EFI 檔案。

這裡最關鍵的是確認目標架構。常見 PC 一般是 x86_64，也就是 64 位元 UEFI 環境。

第四步，把 .EFI 放到可以被 UEFI Shell 存取的位置。

如果用真實機器，通常會準備一個 FAT32 分割區或 USB 隨身碟。
如果用 QEMU，可以把目錄或映像檔掛載進去。

第五步，在 UEFI Shell 裡執行。

執行效果通常就是一個最小輸出，比如印出類似 Hello World 的內容。

最容易卡住的地方

編譯 UEFI 程式最容易卡的不是 C 語言本身，而是環境和連結。

常見問題包括：

編譯器架構不對
目標格式不對
連結參數不完整
缺少 UEFI 進入點
產生的是普通可執行檔，不是 UEFI 能載入的 .EFI
QEMU 或 OVMF 沒配置好
真實機器 Secure Boot 阻止執行未簽署程式

尤其是連結器錯誤，經常會讓新手誤以為程式碼寫錯了。
實際上，很多時候是進入函式、子系統、目標架構或連結腳本配置不對。

所以第一階段不要急著改複雜邏輯。先確保原始範例能編譯、能執行，再一點點改輸出內容。

測試時為什麼推薦 QEMU + OVMF

真實機器測試 UEFI 程式並不是不行，但新手階段不太方便。

因為你可能需要反覆：

編譯
複製到 USB 隨身碟
重開機
進入 UEFI Shell
執行
記錄錯誤
回到系統修改

這個循環很慢。

QEMU + OVMF 的好處是可以在作業系統裡直接模擬 UEFI 環境。你可以更快地驗證 .EFI 是否能被載入，也不容易影響真實機器啟動項。

等程式基本跑通，再放到真實機器上測試，會更穩。

新手應該先改哪裡

如果你已經用範例專案編譯出了第一個 .EFI，下一步不要馬上寫複雜功能。

建議按這個順序改：

先改輸出文字，確認重新編譯後的程式確實生效。
再嘗試讀取 UEFI 提供的簡單資訊。
再理解進入函式、輸出協定和基本服務。
最後再考慮檔案系統、圖形輸出、啟動項管理等複雜功能。

這樣做的好處是每一步都能驗證。
如果一上來就改很多東西，出錯時很難判斷到底是程式碼問題、編譯問題，還是執行環境問題。

和普通 C 程式有什麼不同

UEFI 程式雖然可以用 C 寫，但它和普通 C 程式的執行環境完全不同。

普通 C 程式通常執行在作業系統裡，可以依賴標準函式庫、檔案系統、程序模型和系統呼叫。

UEFI 程式執行在作業系統啟動之前，它依賴的是 UEFI 韌體提供的服務。很多你在普通程式裡習慣使用的東西，在這裡並不是天然可用。

所以寫 UEFI 程式時，要先適應幾個變化：

進入函式不一樣
輸出方式不一樣
可用函式庫不一樣
記憶體和檔案存取方式不一樣
除錯方式不一樣

這也是為什麼推薦先從最小範例開始，而不是直接照普通 C 程式的習慣寫。

一個比較現實的學習路線

如果只是入門，可以按這個路線走：

第一步：編譯 uefi-simple
第二步：用 QEMU + OVMF 跑起來
第三步：修改 Hello World 輸出
第四步：理解 UEFI Shell 怎麼載入 .EFI
第五步：學習 UEFI 的進入函式和基本輸出協定
第六步：再看 EDK II 或更完整的 UEFI 開發資料

這條路線的重點是先讓回饋閉環跑起來。

只要你能從原始碼產生 .EFI，再在 UEFI 環境裡看到輸出，就已經跨過了最難的第一道門檻。

參考

最後一句

編譯第一個 UEFI 程式，難點通常不在「寫出一段 C 程式碼」，而在把工具鏈、連結格式和執行環境串起來。

先別急著做複雜功能。
從 uefi-simple 這種最小範例開始，先得到一個能執行的 .EFI，再逐步理解 UEFI 的進入點、協定和建構方式，會輕鬆很多。

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 最重要的一條原則。

Codex 開始控制電腦，對以後意味著什麼？

Wed, 29 Apr 2026 11:28:25 +0800

Codex 這次最值得關注的變化，不是又多了一個普通按鈕，而是它開始往「控制電腦」這個方向走。

以前我們使用 AI，更多是在聊天框裡提問、複製、貼上、再手動操作軟體。
現在這個邊界開始往外擴：AI 不只是回答你，而是可以根據你的目標去操作桌面應用。

這件事短期看是一個新功能，長期看可能會改變很多人使用電腦的方式。

這個功能是什麼

簡單說，Codex 的電腦使用能力，就是讓它能接觸並操作桌面環境。

它可以做的事包括：

可以選擇並控制某個應用
可以用自然語言下達任務
可以打開瀏覽器、AI 工具、本地文件或其他軟體
可以輸入內容、點擊按鈕、等待結果
可以把多個步驟串成一個任務
可以在後台繼續執行，不需要使用者每一步都手動跟著

它的定位不是單純替你寫一段文字，而是替你完成一段操作流程。

這就是 Agent 和普通聊天機器人的關鍵差別：
聊天機器人主要給答案，Agent 更接近「拿到目標後去執行」。

為什麼這件事重要

過去很多自動化都要求你會寫腳本。

比如你想完成一個跨軟體流程：

打開網頁
找資料
複製內容
交給另一個 AI 工具處理
保存文件
再打開本地目錄檢查結果

如果要自動化這件事，傳統做法可能是寫瀏覽器腳本、調用 API、寫本地程序，甚至還要處理各種軟體窗口。

但很多普通使用者不會寫這些東西。
就算會寫，也未必值得為一個臨時任務專門寫腳本。

電腦使用能力的意義就在這裡：它把「腳本能力」往自然語言方向推了一步。

你不一定要告訴它每一步怎麼點。
你可以告訴它你要什麼結果，讓它自己去嘗試完成。

它能改變哪些工作流

我覺得最先被改變的，不會是特別嚴肅、特別高風險的工作，而是那些「煩、雜、重複、但又不值得專門寫程序」的流程。

1. 跨軟體搬運

最典型的就是在多個軟體之間搬資訊。

以前你可能要在瀏覽器、文檔、聊天窗口、本地資料夾之間來回切。
以後可以把這類任務交給 Agent：

去找某類資料
匯總成文檔
保存到指定目錄
打開結果給你確認

這類工作不難，但很耗注意力。
Agent 的價值就是把這些碎操作吃掉。

2. 多個 AI 工具協同

現在很多人的真實工作流已經不是只用一個 AI。

可能是：

一個工具寫程式碼
一個工具查資料
一個工具生成圖片
一個工具整理文檔

以前這些工具之間靠人手複製貼上。
以後 Agent 可以成為中間層：它負責打開工具、傳遞上下文、等待輸出、整理結果。

這會讓「多個 AI 協同」從手工流程變成半自動流程。

3. 辦公軟體自動化

表格、PPT、文檔、郵件，這些軟體都有一個共同特點：功能很強，但很多操作很碎。

如果 Agent 能穩定控制這些軟體，以後的辦公自動化門檻會明顯下降。

你不用記選單在哪裡，也不用學複雜快捷鍵。
你只需要說清楚目標，比如：

把這份表格整理成月報
根據這份文檔做一頁總結
把這些資料合併成一個結構清楚的說明

真正麻煩的按鈕操作，會逐漸被隱藏到自然語言後面。

對普通使用者意味著什麼

對普通使用者來說，這類功能的影響可能比「模型又聰明了一點」更直接。

因為它降低的不是知識門檻，而是操作門檻。

很多人不是不會表達需求，而是不知道軟體裡該點哪裡、怎麼組合功能。
Agent 如果能接管這部分，人使用電腦的方式就會變成：

1
2
3

我描述目標
Agent 操作軟體
我檢查結果

這比單純聊天更接近真實生產力。

對軟體形態的影響

如果這類 Agent 能力繼續成熟，軟體本身也會被反向影響。

過去軟體設計主要服務人類點擊。
以後軟體可能還要服務 Agent 操作。

這意味著：

介面元素需要更清晰
操作回饋需要更穩定
本地權限需要更細
軟體可能會提供更適合 Agent 調用的介面
使用者會更在意「能不能被 AI 順利操作」

長期看，應用之間的邊界可能會變薄。
使用者關心的不再是「我打開哪個軟體」，而是「我要完成什麼任務」。

現在還不能過度樂觀

當然，現在還不到完全放手的時候。

這類能力目前還有幾個明顯限制：

穩定性還需要觀察
複雜任務可能中途出錯
權限邊界必須謹慎
涉及帳號、支付、刪除文件等操作不能隨便放權
額度消耗也不是完全可以忽略

所以現階段最合適的用法，不是讓它完全接管電腦，而是讓它處理低風險、可檢查、步驟繁瑣的任務。

比如：

整理資料
生成草稿
跨工具搬運內容
打開和檢查文件
做一些可以人工複核的半自動流程

最後一句

Codex 這次更新真正重要的地方，是它把 AI 從「回答問題」推向了「操作環境」。

短期看，它是一個電腦使用功能。
長期看，它可能是個人電腦互動方式的一次轉向。

以後我們使用電腦，可能會越來越少地記按鈕、找選單、切窗口。
更多時候，我們只需要說清楚目標，然後讓 Agent 去執行，再由人做最後判斷。

Codex Skill 明明在目錄裡，為什麼就是不顯示？

Wed, 29 Apr 2026 11:18:00 +0800

這次遇到的問題很隱蔽：~/.codex/skills 裡明明已經放好了多個 skill，新開 Codex 執行緒之後，側邊欄卻還是只能看到少數幾個。

一開始看起來像是快取或索引問題，但實際原因更具體：幾個 SKILL.md 文件開頭帶了 UTF-8 BOM，Codex 0.111.0 的 skill loader 沒有跳過這個位元組，於是誤判文件沒有合法的 YAML front matter。

現象

本地目錄裡有這些 skill：

~/.codex/skills/git-commit-push/SKILL.md
~/.codex/skills/hugo-rsync-deploy/SKILL.md
~/.codex/skills/bilibili-speech-transcriber/SKILL.md
~/.codex/skills/product-cutout-normalize/SKILL.md

但新開執行緒時，實際暴露出來的只有：

1
2

bilibili-speech-transcriber
product-cutout-normalize

也就是說，文件存在不等於當前會話一定能載入成功。Codex 會先解析每個 SKILL.md 的 front matter，解析失敗的 skill 會直接被排除。

排查

用 codex exec 啟動一個新會話時，可以看到更直接的錯誤。在 VS Code 等 IDE 中，可能看不到這些 log：

1
2

failed to load skill C:\Users\knightli\.codex\skills\git-commit-push\SKILL.md: missing YAML frontmatter delimited by ---
failed to load skill C:\Users\knightli\.codex\skills\hugo-rsync-deploy\SKILL.md: missing YAML frontmatter delimited by ---

這些文件肉眼看起來都有正常的開頭：

---
name: post-rewrite
description: ...
---

真正的問題在位元組層面。

失敗文件的開頭是：

`1`	`EF-BB-BF-2D-2D-2D`

能正常載入的文件開頭是：

`1`	`2D-2D-2D`

2D-2D-2D 就是 ---。前面的 EF-BB-BF 是 UTF-8 BOM。

原因

Codex 0.111.0 的 skill loader 目前要求 SKILL.md 文件第一個位元組就是 --- 的第一個 -。

如果文件前面帶了 UTF-8 BOM，那麼文件實際開頭就不再是 ---，而是：

`1`	`BOM + ---`

於是 loader 會認為它沒有以前置資料分隔符開頭，最後報：

`1`	`missing YAML frontmatter delimited by ---`

這不是 skill 內容寫錯了，也不是目錄放錯了，而是編碼細節讓解析器沒認出來。

修復

把出問題的 SKILL.md 轉成無 BOM 的 UTF-8 即可。

PowerShell 可以這樣處理：

$paths = @(
  'C:\Users\knightli\.codex\skills\git-commit-push\SKILL.md',
  'C:\Users\knightli\.codex\skills\hugo-rsync-deploy\SKILL.md',
)

$utf8NoBom = New-Object System.Text.UTF8Encoding($false)

foreach ($p in $paths) {
  $text = [IO.File]::ReadAllText($p, [Text.Encoding]::UTF8)
  [IO.File]::WriteAllText($p, $text, $utf8NoBom)
}

處理後再檢查文件頭，應該從：

`1`	`EF-BB-BF-2D-2D-2D`

變成：

`1`	`2D-2D-2D`

驗證

重新啟動一個 Codex 會話後，可見 skill 恢復為：

git-commit-push-zh
hugo-rsync-deploy
bilibili-speech-transcriber
product-cutout-normalize

如果側邊欄仍然只顯示舊的列表，可以退出當前 Codex sidebar 或窗口，再重新打開專案。skill 列表通常在會話啟動時載入，中途改文件不一定會立刻刷新到當前執行緒。

最後一句

這類問題最容易誤判成「Codex 沒重新索引」或「skill 沒安裝好」。

實際排查時可以先看三件事：

SKILL.md 是否真的在正確目錄
文件頭部是否有合法的 --- front matter
文件是否是無 BOM 的 UTF-8

這次的關鍵就是第三點：文件看起來沒問題，但第一個位元組不是 -，Codex 就沒有把它當作一個有效 skill。

Codex 裡的 ~/.codex/skills 和專案/.codex/skills 有什麼差別

Wed, 29 Apr 2026 11:08:00 +0800

很多人整理 Codex skills 時，最容易卡住的問題就兩個：

~/.codex/skills 和 專案/.codex/skills 有什麼差別
為什麼 skill 明明在目錄裡，當前會話裡卻不一定顯示

這篇就直接說結論。

兩者的差別

先記最短版本：

~/.codex/skills 是你的全域技能庫
專案/.codex/skills 是這個倉庫的本地技能庫

`~/.codex/skills`

適合放：

你自己跨專案反覆會用的 skill
跟具體倉庫無關的通用流程
很明顯屬於你個人習慣的工作流

比如：

post-rewrite
post-translate
git-commit-push
hugo-rsync-deploy
bilibili-speech-transcriber

這類 skill 的特點就是：離開當前專案也還能用。

`專案/.codex/skills`

適合放：

只對這個倉庫成立的流程
跟當前專案目錄結構、腳本、模板綁定很深的規則
需要讓團隊一起共享的 skill

比如：

這個倉庫特有的發布流程
只能在這個專案裡用的生成模板
跟專案私有腳本強綁定的自動化步驟

這類 skill 的特點是：離開這個倉庫就沒意義。

什麼時候放全域，什麼時候放專案裡

直接這樣判斷就夠了：

跟你個人習慣有關，放 ~/.codex/skills
跟倉庫規則有關，放 專案/.codex/skills
能跨專案複用，優先放全域
要多人共享、跟倉庫一起演進，優先放專案裡

當前這個倉庫是什麼情況

按我現在看到的實際狀態：

你的本機裡有 ~/.codex/skills
當前倉庫裡沒有 .codex/skills

所以你現在主要依賴的是全域 skills。

也就是說，像 post-rewrite、post-translate、git-commit-push 這些流程，現在更多是你個人工作流的一部分，不是這個倉庫顯式自帶的一部分。

為什麼磁碟裡有，當前會話裡卻不一定顯示

這裡要分清兩件事：

磁碟存在：說明 skill 文件在本地目錄裡
會話暴露：說明當前會話把它註冊進了可用 skill 列表

這兩者不是一回事。

所以會出現這種情況：

~/.codex/skills 裡已經有 skill
但 / 後面的列表裡沒有顯示

這通常不代表 skill 壞了，更常見的原因是：當前會話沒有把它重新索引進去。

怎樣讓 skill 被當前會話暴露

最實用的步驟就這幾條：

1. 目錄放對

全域：

`1`	`~/.codex/skills/<skill-name>/SKILL.md`

專案級：

`1`	`專案/.codex/skills/<skill-name>/SKILL.md`

2. `SKILL.md` 頭部可識別

最少要有：

---
name: your-skill-name
description: 這個 skill 是做什麼的
---

3. 新建或修改後，開新會話

很多時候 skill 沒顯示，不是文件有問題，而是當前會話啟動時就已經把可用 skill 列表定下來了。

所以你中途新建 skill，磁碟裡雖然已經有了，這次會話也未必會重新認。

最穩的做法就是：

放好 skill
結束當前會話
重新進入專案
開一個新會話
再看 / 裡有沒有出現

4. 專案 skill 最好提前放好

如果你想讓 專案/.codex/skills 更穩定地被識別，最好在進入倉庫、啟動會話之前，就把這些 skill 放進專案裡。

最後一句

最短結論就是：

~/.codex/skills 是你的個人技能庫
專案/.codex/skills 是倉庫的本地規則庫
skill 在目錄裡，不等於當前會話一定會顯示
想讓它顯示，最常見的辦法就是放對目錄、寫好 SKILL.md，然後開新會話

GoAccess 最新版自編譯與使用記錄：從原始碼安裝到即時 HTML 報表

Wed, 29 Apr 2026 00:08:00 +0800

時間點按 2026-04-29 整理。
目前官方 README 裡給出的最新穩定版是 1.10.2。

1. 先裝編譯依賴

1
2
3

sudo apt-get update
sudo apt-get install -y build-essential wget tar \
  libncurses-dev libmaxminddb-dev libssl-dev zlib1g-dev

2. 下載最新版原始碼包

cd /usr/local/src
sudo wget https://tar.goaccess.io/goaccess-1.10.2.tar.gz
sudo tar -xzvf goaccess-1.10.2.tar.gz
cd goaccess-1.10.2

3. 配置編譯參數

`1`	`sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib`

如果你還想給即時 HTML 報表配 TLS，也可以改成：

`1`	`sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib --with-openssl`

4. 編譯並安裝

1
2

sudo make
sudo make install

5. 確認版本

1
2

goaccess --version
which goaccess

6. 直接看終端報表

Nginx 或 Apache 常見 combined 日誌可以先這樣跑：

`1`	`goaccess /var/log/nginx/access.log --log-format=COMBINED`

如果日誌路徑是 Apache：

`1`	`goaccess /var/log/apache2/access.log --log-format=COMBINED`

7. 生成靜態 HTML 報表

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html

輸出到目前目錄也可以：

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o report.html

8. 生成即時 HTML 報表

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html

如果要改埠號：

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html \
  --port=7891

如果只綁定本機：

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html \
  --addr=127.0.0.1

9. 持續追日誌

`1`	`tail -f /var/log/nginx/access.log \| goaccess --log-format=COMBINED -`

從檔案開頭開始並保持即時：

tail -f -n +0 /var/log/nginx/access.log | goaccess \
  --log-format=COMBINED \
  -o report.html \
  --real-time-html -

10. 只看某類請求

例如只看帶 firefox 的請求：

1
2

tail -f /var/log/nginx/access.log | grep -i --line-buffered 'firefox' | goaccess \
  --log-format=COMBINED -

例如只看 5xx 和 3xx：

1
2
3

tail -f -n +0 /var/log/nginx/access.log | awk '$9~/3[0-9]{2}|5[0-9]{2}/' | goaccess \
  --log-format=COMBINED \
  -o out.html -

11. 多個日誌一起分析

`1`	`goaccess /var/log/nginx/access.log /var/log/nginx/access.log.1 --log-format=COMBINED`

壓縮和未壓縮一起讀：

`1`	`zcat --force /var/log/nginx/access.log* \| goaccess --log-format=COMBINED -`

12. 開多執行緒

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -o report.html \
  -j 4

加大 chunk：

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -o report.html \
  -j 4 \
  --chunk-size=8192

13. 增量處理

先持久化一份舊日誌：

`1`	`goaccess /var/log/nginx/access.log.1 --log-format=COMBINED --persist`

再追加目前日誌：

`1`	`goaccess /var/log/nginx/access.log --log-format=COMBINED --restore --persist`

只讀取已持久化資料：

`1`	`goaccess --restore`

14. 我自己會先跑的一組命令

sudo apt-get update
sudo apt-get install -y build-essential wget tar \
  libncurses-dev libmaxminddb-dev libssl-dev zlib1g-dev

cd /usr/local/src
sudo wget https://tar.goaccess.io/goaccess-1.10.2.tar.gz
sudo tar -xzvf goaccess-1.10.2.tar.gz
cd goaccess-1.10.2
sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib --with-openssl
sudo make
sudo make install

goaccess --version

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html

就這樣。
如果你的目標很明確，其實只要把最新版原始碼編譯好，再把 --log-format=COMBINED 和 --real-time-html 這兩個參數先跑通，後面基本就是圍著日誌路徑、輸出檔案和埠號在改。

模型	適合場景
`deepseek-v4-flash`	日常程式碼閱讀、批量改小問題、生成腳本、整理上下文、低風險前端修改
`deepseek-v4-pro`	架構規劃、複雜 bug、跨檔案重構、事實核查、多工具呼叫、高風險改動

開發工具 on KnightLi的博客

Jimmy：把 Evernote、Notion、Google Keep 等筆記匯出轉換成 Markdown

Jimmy 解決什麼問題

支援的筆記應用很多

也能轉換普通文件

兩種使用方式

它的幾個特點

適合誰使用

使用前的檢查建議

我的判斷

Google Pay 與 Wallet 推出 Developer MCP Server：把支付整合接入 AI 助手

它解決什麼問題

MCP 在這裡為什麼合適

對 AI 程式設計工作流的意義

它不會替代開發者判斷

我的判斷

Remotion：用 React 以程式化方式生成影片

Remotion 解決的是什麼問題

為什麼是 React

快速開始

它適合哪些場景

個人化影片

技術示範影片

資料影片和圖表動畫

AI 生成影片工作流程

對 AI 編程工具的意義

使用前要注意授權

我的判斷

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

它解決的是什麼問題

RTK 的基本工作方式

支援哪些命令

安裝和接入方式

使用時要注意什麼

適合誰用

我的判斷

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

持久執行緒

語音輸入

Steering 和 queuing

工具和可觸達範圍

從任何地方繼續工作

自動化

Goals

側邊欄

共享記憶

從程式碼向外擴展

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

先檢查 goals 功能開關

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

Windows 上還要留意安全軟體

判斷是不是 prompt 的問題

小結

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

它到底是什麼

推薦安裝方式

預設工作流

skills 和 agents 提供了什麼

插件形態和執行時狀態

適合誰

使用時要注意什麼

小結

參考資料

CLI-Anything：把軟體變成 Agent 可用的命令列

它怎麼工作

適合什麼場景

需要注意的邊界

小結

GitHub Spec Kit 是什麼？用規格驅動開發約束 AI 編程

Spec Kit 是什麼？

基本使用流程

它改變了 AI 編程的入口

核心命令怎麼理解？

/speckit.constitution

/speckit.specify

/speckit.clarify

/speckit.plan

/speckit.tasks

/speckit.implement

為什麼它適合 AI 編程？

`/speckit.constitution`

`/speckit.specify`

`/speckit.clarify`

`/speckit.plan`

`/speckit.tasks`

`/speckit.implement`