自動化 on KnightLi的博客

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

ai-goofish-monitor：用 AI 自動盯閒魚商品的開源監控系統

Sun, 17 May 2026 17:24:03 +0800

ai-goofish-monitor 是 Usagi-org 開源的閒魚商品監控系統。

它的目標很明確：把閒魚搜尋、篩選、商品分析、結果記錄和通知推送自動化，幫助使用者從大量二手商品裡更快找到符合條件的目標。專案基於 Playwright 做頁面自動化，再接入支援圖片輸入的 AI 模型，對商品資訊做進一步判斷。

專案地址：https://github.com/Usagi-org/ai-goofish-monitor

先說結論

ai-goofish-monitor 更像一個「閒魚採購情報面板」，而不是簡單的關鍵字提醒腳本。

它有幾個明顯特點：

有完整 Web 管理介面，可以管理任務、帳號、AI 標準、日誌和結果。
支援多任務並發，每個任務可以配置關鍵字、價格、篩選條件和 AI Prompt。
使用 Playwright 抓取閒魚頁面，適合處理需要登入態和頁面互動的場景。
使用 AI 判斷商品是否符合需求，不只依賴關鍵字匹配。
支援 ntfy.sh、企業微信、Bark、Telegram、Webhook 等通知渠道。
支援 Cron 定時任務、多帳號管理、代理輪換、失敗重試和 Docker 部署。

它適合經常在閒魚找特定商品的人，比如二手數位產品、攝影器材、顯卡、硬碟、遊戲機、樂器、家電和收藏品。但它也不是「自動撿漏神器」。閒魚搜尋結果本身會變，帳號登入態可能失效，平台風控也會影響自動化穩定性。使用時更應該把它當成輔助篩選工具，而不是完全替代人工判斷。

它解決什麼問題

在閒魚上找二手商品，經常有幾個痛點：

商品太多，手動翻很累。
標題和描述不規範，關鍵字很容易漏掉或誤判。
好價格出現時間短，發現太晚就沒了。
同一個商品可能有多個地區、價格、成色和賣家差異。
低價商品裡混著配件、損壞品、翻新貨和誘導性標題。
想持續盯多個關鍵字時，手動搜尋很難堅持。

普通關鍵字提醒只能解決一部分問題。比如你搜尋「ThinkPad X1」，可能會混入配件、壞屏、空盒、拆機件；你搜尋「索尼 A7C」，又可能遇到鏡頭套裝、租賃資訊、標題黨和價格異常。

ai-goofish-monitor 的思路是：先用自動化把候選商品抓出來，再交給 AI 按你的需求做二次判斷，最後把值得關注的結果推送給你。

核心功能

專案 README 裡列出的核心能力比較完整：

Web 視覺化管理：任務管理、帳號管理、AI 標準編輯、運行日誌、結果瀏覽。
AI 驅動：支援自然語言建立任務，並用多模態模型分析商品。
多任務並發：不同任務可以獨立配置關鍵字、價格、篩選條件和 AI Prompt。
進階篩選：支援包郵、新發布時間範圍、省 / 市 / 區三級區域篩選。
即時通知：支援 ntfy.sh、企業微信、Bark、Telegram、Webhook 等多渠道。
定時調度：支援 Cron 配置週期性任務。
帳號與代理輪換：多帳號管理、任務綁定帳號、代理池輪換與失敗重試。
Docker 部署：支援容器化部署。

這些能力組合起來，覆蓋了從「建立監控任務」到「收到命中提醒」的完整鏈路。

工作流是什麼樣

一個典型流程大概是這樣：

部署服務並打開 Web UI。
匯入閒魚帳號登入態。
建立監控任務。
設定關鍵字、價格區間、地區、新發布範圍等篩選條件。
編寫或讓 AI 生成判斷標準。
任務按即時或定時方式運行。
Playwright 打開頁面並抓取商品資訊。
AI 根據標題、描述、圖片和 Prompt 判斷是否符合需求。
命中結果寫入 SQLite。
系統透過配置的通知渠道推送結果。
使用者在 Web UI 裡查看結果、日誌和價格歷史。

這個流程裡，AI 的價值主要在第 8 步。它可以理解「我想要成色好、價格合理、不要配件、不要維修機、最好同城自取」這類自然語言條件，比單純關鍵字規則靈活。

Docker 部署

專案推薦使用 Docker 部署：

git clone https://github.com/Usagi-org/ai-goofish-monitor && cd ai-goofish-monitor
cp .env.example .env
vim .env
docker compose up -d
docker compose logs -f app
docker compose down

預設 Web UI 地址是：

`1`	`http://127.0.0.1:8000`

官方映像地址是：

`1`	`ghcr.io/usagi-org/ai-goofish:latest`

如果映像存取慢，README 裡也給了加速映像示例：

1
2
3

docker pull ghcr.nju.edu.cn/usagi-org/ai-goofish:latest
docker tag ghcr.nju.edu.cn/usagi-org/ai-goofish:latest ghcr.io/usagi-org/ai-goofish:latest
docker compose up -d

Docker 映像已內建 Chromium，不需要宿主機額外安裝瀏覽器。預設持久化目錄包括：

data/：SQLite 主儲存，保存任務、結果和價格歷史。
state/：登入狀態 cookie 文件。
prompts/：任務提示詞。
logs/：運行日誌。
images/：商品圖片和任務臨時圖片目錄。

如果修改了 .env 裡的 SERVER_PORT，也要同步調整 docker-compose.yaml 的連接埠映射。

最少配置

專案的最少配置主要圍繞 AI 模型和 Web UI 登入：

OPENAI_API_KEY=your_api_key
OPENAI_BASE_URL=your_openai_compatible_base_url
OPENAI_MODEL_NAME=your_multimodal_model
WEB_USERNAME=admin
WEB_PASSWORD=change_me

其中前三項是 AI 模型接入必填項：

OPENAI_API_KEY：模型 API Key。
OPENAI_BASE_URL：OpenAI 相容介面地址。
OPENAI_MODEL_NAME：支援圖片輸入的模型名稱。

WEB_USERNAME 和 WEB_PASSWORD 用於 Web UI 登入。README 提到預設帳號密碼是 admin/admin123，生產環境必須修改。

第一次使用

第一次使用時，流程大致是：

打開 http://127.0.0.1:8000。
登入 Web UI。
進入「閒魚帳號管理」。
使用專案提供的 Chrome 擴充套件匯出閒魚登入態 JSON。
把登入態貼到系統裡。
登入態文件會保存到 state/，例如 state/acc_1.json。
回到「任務管理」，建立任務並綁定帳號。
運行任務並查看結果。

這裡最關鍵的是登入態。由於閒魚並不是開放給第三方隨意抓取的標準 API，專案需要用瀏覽器登入狀態來模擬正常頁面存取。登入態失效、風控、驗證碼、帳號異常都會影響任務運行。

AI 任務和關鍵字任務

專案支援兩類任務建立方式。

第一類是 AI判断。

你可以填寫「詳細需求」，提交後系統會非同步生成分析標準。適合需求比較複雜的場景，例如：

只要主機本體，不要配件。
價格明顯低於市場價才提醒。
成色要好，描述裡不能有進水、維修、暗病。
優先同城，能面交更好。
圖片裡要能看到序列號、包裝或關鍵配件。

第二類是 关键词判断。

它更接近傳統規則監控：根據關鍵字、價格、地區等條件直接建立任務，不經過 AI 生成流程。適合規則簡單、誤報可以接受的場景。

實際使用中可以混合使用：關鍵字負責初篩，AI 負責減少誤報。

Web UI 能做什麼

Web UI 是這個專案區別於普通腳本的重要部分。

任務管理頁可以配置：

AI 建立任務。
關鍵字規則。
價格範圍。
新發布範圍。
區域篩選。
帳號綁定。
定時規則。

帳號管理頁可以：

匯入閒魚帳號登入態。
更新登入態。
刪除帳號。
為任務指定帳號。
讓系統自動選擇帳號。

結果和日誌頁可以：

查看命中商品。
匯出結果。
查詢歷史記錄。
查看任務運行過程。
排查登入態失效、風控和 AI 調用問題。

系統設定頁可以：

查看系統狀態。
編輯 Prompt。
調整代理和輪換配置。

對於長期監控來說，Web UI 很關鍵。否則任務一多，配置、日誌、結果和通知都會變得難維護。

資料儲存

專案目前在線主儲存使用 SQLite，預設路徑是：

`1`	`data/app.sqlite3`

Docker 預設把 SQLite 主庫掛載到：

`1`	`./data:/app/data`

應用啟動時會自動建庫建表，並嘗試從舊的 config.json、jsonl/、price_history/ 匯入一次歷史資料。

需要注意的是，state/、prompts/、logs/、images/ 仍然是檔案系統目錄，不在 SQLite 中。商品圖片會臨時保存到類似下面的目錄：

`1`	`images/task_images_<task_name>/`

任務結束後預設會清理。

這種結構比較適合個人或小團隊部署：SQLite 足夠輕，遷移也簡單；檔案目錄保留登入態、圖片和日誌，排查問題更直觀。

通知渠道

專案支援多種通知渠道，常見配置包括：

NTFY_TOPIC_URL
GOTIFY_URL / GOTIFY_TOKEN
BARK_URL
WX_BOT_URL
TELEGRAM_BOT_TOKEN / TELEGRAM_CHAT_ID / TELEGRAM_API_BASE_URL
WEBHOOK_*

通知是這類工具的核心體驗。監控系統如果只把結果寫進後台，使用者仍然需要反覆打開頁面查看；有推送之後，命中商品才能在第一時間觸達。

更實用的配置方式是按商品價值分層：

普通關鍵字命中只寫入後台。
AI 高置信度結果推送到手機。
高價值商品推送到企業微信或 Telegram。
調試階段開啟更多日誌，穩定後減少噪音。

開發者運行

如果不使用 Docker，本地開發需要：

Python 3.10+
Node.js + npm
Playwright CLI
Chromium 或 Chrome / Edge 瀏覽器

基礎命令：

1
2
3

git clone https://github.com/Usagi-org/ai-goofish-monitor
cd ai-goofish-monitor
cp .env.example .env

一鍵啟動：

1
2

chmod +x start.sh
./start.sh

start.sh 會檢查 Playwright CLI 和瀏覽器條件，自動安裝依賴、建置前端、複製建置產物並啟動後端。

手動啟動後端：

`1`	`python -m src.app`

或者：

`1`	`uvicorn src.app:app --host 0.0.0.0 --port 8000 --reload`

前端開發：

1
2
3

cd web-ui
npm install
npm run dev

測試和建置：

1
2

PYTEST_DISABLE_PLUGIN_AUTOLOAD=1 pytest
cd web-ui && npm run build

適合哪些人

ai-goofish-monitor 適合這些使用者：

經常在閒魚蹲特定型號商品的人。
想監控二手數位產品、攝影器材、遊戲設備、硬體配件的人。
想把「關鍵字搜尋 + 人工篩選」自動化的人。
有 OpenAI 相容模型 API，並願意為 AI 判斷支付調用成本的人。
熟悉 Docker 或基本命令列部署的人。
需要把命中結果推送到手機、企業微信或 Telegram 的使用者。

它不太適合這些情況：

完全不懂部署，只想要一個即開即用 App。
不願意處理登入態、驗證碼和帳號風控。
需要官方授權、強合規的資料介面。
想大規模高頻抓取平台資料。
希望 AI 自動判斷交易風險並替你下單。

使用風險和邊界

這類工具一定要注意邊界。

第一，遵守平台規則。

閒魚有自己的服務條款、風控策略和帳號安全機制。自動化存取可能觸發限制。不要高頻抓取，不要繞過風控，不要把它用於騷擾賣家、批量採集隱私或破壞平台秩序。

第二，保護帳號登入態。

state/ 裡保存的是登入狀態 cookie 文件。它本質上等同於帳號存取憑證，不能提交到 Git 倉庫，也不要放到不可信伺服器上。伺服器如果暴露在公網，Web UI 必須修改預設密碼，並建議放在 VPN、反向代理鑑權或內網之後。

第三，AI 判斷不是事實保證。

AI 可以幫你減少誤報，但不能保證商品真實、賣家可信、價格合理或交易安全。最終仍然要人工看商品詳情、賣家評價、聊天記錄、發貨方式和支付流程。

第四，注意成本。

如果每個候選商品都交給多模態模型分析，調用成本可能很快上升。建議先用關鍵字、價格和區域做強篩選，再把少量候選交給 AI。

第五，注意隱私。

商品截圖、聊天相關內容、帳號狀態和通知內容都可能包含敏感資訊。通知 Webhook、日誌目錄和資料庫都要妥善保護。

和普通腳本的差別

普通閒魚監控腳本通常只做三件事：

搜尋關鍵字。
判斷價格。
發通知。

ai-goofish-monitor 更進一步：

用 Web UI 管理任務和帳號。
用 AI Prompt 表達複雜購買標準。
用多模態模型看商品圖和描述。
用 SQLite 保存結果和價格歷史。
用日誌頁排查任務失敗原因。
用代理輪換和多帳號機制提高穩定性。
用定時任務支援長期運行。

也正因為功能更多，它的部署和維護成本更高。對普通使用者來說，Docker 部署是最省事的方式；對開發者來說，Web UI、FastAPI、Playwright、SQLite 這套結構也比較容易二次開發。

可以怎麼用

比較實用的使用方式是從小任務開始。

比如你想找一台二手相機，可以先建立一個任務：

關鍵字：A7C、索尼 A7C
價格範圍：按市場價設定上限
區域：優先本省或同城
新發布範圍：最近一天或最近幾小時
AI 標準：排除單鏡頭、排除維修機、排除明顯配件、關注快門數和成色
通知：只推送 AI 判斷通過的結果

穩定運行後，再逐步增加任務數量。不要一開始就上幾十個關鍵字、多個帳號和高頻 Cron。先看登入態穩定性、誤報率、AI 成本和通知噪音，再調參數。

總結

ai-goofish-monitor 把閒魚監控從「關鍵字腳本」推進到了「可管理的 AI 監控系統」。它用 Playwright 處理頁面自動化，用 AI 處理複雜判斷，用 Web UI 管理任務和結果，用 SQLite 保存資料，再透過多種通知渠道把結果推送出來。

它最適合個人或小團隊做特定商品監控，尤其是二手數位產品、硬體、攝影器材這類價格波動大、發布時間敏感、描述噪音多的品類。

但它也需要謹慎使用：登入態要保護，預設密碼要改，抓取頻率要克制，AI 結果要人工複核，平台規則和隱私邊界不能忽視。把它當成輔助篩選工具，它會很有價值；把它當成全自動交易系統，就容易高估它的能力。

參考連結：

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 框架。

參考資料

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 會是從「會聊天的編程助手」走向「可約束的工程協作者」的關鍵一步。