AI程式設計 on KnightLi的博客

GitHub AI 開源專案分類整理：從 Coding Agent 到 RAG 知識庫

Thu, 21 May 2026 08:53:13 +0800

這裡按應用方向列出 GitHub AI 專案，覆蓋 AI 程式設計與 Coding Agent、Agent 技能與工作流、RAG 與知識庫、多模態創作、本地模型與推理、垂直應用與自動化、AI 應用開發基礎設施等方向。後續新增專案時，也可以繼續按這個結構補充。

分類合計

分類	專案數	適合先看的人
AI程式設計與 Coding Agent	22	經常使用 Claude Code、Codex、Cursor、終端 Agent 或程式碼庫自動化的人
Agent 技能與工作流	7	想把 AI 程式設計、科研、創作流程標準化的人
RAG、知識庫與記憶	7	需要文件檢索、知識庫、長期記憶、網頁抓取和結構化抽取的人
垂直應用與自動化	7	想看金融、交易、閒魚監控、桌面操作、瀏覽器自動化等落地場景的人
多模態與內容創作	5	做圖片、影片、語音轉寫、提示詞庫和內容分發的人
AI 應用開發基礎設施	5	構建 AI 應用、瀏覽器自動化、Prompt/MCP 工具鏈的人
本地模型與推理	1	關心本地 DeepSeek、推理引擎和硬體適配的人

這個分佈可以看出當前 AI 開源專案的幾個高頻方向：AI 程式設計工具明顯最多，其次是 Agent 工作流、RAG 知識庫和具體應用場景。純模型推理專案數量不多，因為很多本地部署內容並不是單獨介紹某個 GitHub 專案，而是圍繞模型、顯示卡或部署方案展開。

AI程式設計與 Coding Agent

這一類聚焦程式碼理解、程式碼修改、工程流程和終端 Agent，是數量最多的一組。共 22 個專案。

專案	文章	GitHub	核心用途	適合人群
Ralph	Ralph 是什麼：把 Claude Code 和 Amp 變成可迴圈執行的自主開發流程	snarktank/ralph	讓 Claude Code / Amp 按 PRD、計劃、執行、評審迴圈推進任務	想把 Agent 程式設計流程拉直的人
Claude-Mem	Claude-Mem：給 Claude Code 加上跨會話長期記憶	thedotmack/claude-mem	為 Claude Code 增加跨會話記憶	高頻使用 Claude Code 的開發者
Claude Code Hooks Mastery	Claude Code Hooks Mastery：13 個 Hooks 生命週期與自動化控制入門	disler/claude-code-hooks-mastery	學習 Claude Code Hooks 生命週期和自動化控制	想定製 Claude Code 流程的人
Compound Engineering Plugin	Compound Engineering Plugin：把 AI 程式設計變成計劃、執行、評審的工程迴圈	EveryInc/compound-engineering-plugin	把 AI 程式設計拆成計劃、執行、評審迴圈	關注工程化 AI 程式設計的人
free-claude-code	free-claude-code：用代理把 Claude Code 接到 OpenRouter、DeepSeek 和本地模型	Alishahryar1/free-claude-code	透過代理把 Claude Code 接到不同模型後端	想降低 Claude Code 使用成本的人
Hermes Agent	Hermes Agent 是什麼：簡介、優點、快速上手與 OpenClaw 對比	NousResearch/hermes-agent	本地 Agent 框架，支援工具呼叫和任務執行	想跑本地 Agent 的使用者
OpenHarness	OpenHarness 是什麼：這個開源 Agent Harness 能做什麼	HKUDS/OpenHarness	Agent Harness 與多 Agent 執行框架	研究 Agent 編排的人
CodexBridge	Codex 怎麼接入國產大模型？OpenAI 相容介面與 CodexBridge 使用思路	begonia599/CodexBridge	幫 Codex 接入 OpenAI 相容模型介面	想把 Codex 接到國產模型的人
ccx	Codex 怎麼接入國產大模型？用 CCX 統一管理 OpenAI 相容 API	BenedictKing/ccx	統一管理 Claude、Codex、Gemini 等 API 代理	多模型切換使用者
cc-haha	cc-haha 是什麼？一個把 Claude Code 做成桌面工作臺的專案	NanmiCoder/cc-haha	Claude Code 桌面工作臺與 Computer Use 入口	喜歡圖形介面的 Claude Code 使用者
DeepSeek-TUI	DeepSeek-TUI：把 DeepSeek V4 變成終端裡的程式設計智慧體	Hmbown/DeepSeek-TUI	在終端裡執行 DeepSeek 程式設計 Agent	DeepSeek 與命令列使用者
Open Design	Open Design 專案解析：把 Claude Code、Codex 變成 AI 設計工具	nexu-io/open-design	讓 Claude Code / Codex 參與設計生成	想用 Agent 做設計原型的人
agentmemory	agentmemory 專案解析：給 Claude Code、Codex 和 Cursor 加持久記憶	rohitg00/agentmemory	給 Coding Agent 增加持久記憶層	長期維護專案的開發者
Graphify	Graphify 解決 Claude Code 最大侷限：把程式碼庫變成 AI 可查詢知識圖譜	safishamsi/graphify	把程式碼庫轉成知識圖譜，降低 Agent 重複讀檔案成本	大型程式碼庫使用者
oh-my-pi	oh-my-pi 是什麼？一個把終端、IDE 和偵錯器打通的 AI 編程助手	can1357/oh-my-pi	把終端、IDE、LSP 和偵錯器連接起來，作為本機 AI 編程控制台	想把命令列和 IDE 工作流打通的開發者
Claude Plugins Official	Claude Code 也有外掛市場了：能裝什麼、怎麼裝、要注意什麼	anthropics/claude-plugins-official	Claude Code 官方外掛目錄和安裝入口	想給 Claude Code 擴展能力的使用者
CodeGraph	CodeGraph 是什麼？給 Claude Code、Codex 和 Cursor 加一個本機程式碼地圖	colbymchenry/codegraph	為程式碼庫生成本機索引和關係圖，幫助 Coding Agent 理解專案	維護中大型程式碼庫的開發者
CC Switch	CC Switch：一個桌面工具統一管理 Claude Code、Codex、Gemini CLI 和 OpenClaw	farion1231/cc-switch	管理多個 AI CLI 工具和賬號/配置切換	同時使用多套 CLI 的人
Warp	Warp 開源：從終端到 Agentic Development Environment	warpdotdev/warp	Agentic 終端與開發環境	終端重度使用者
opencode	opencode、Claude Code、Codex 有什麼區別？開源 AI 程式設計工具使用指南	anomalyco/opencode	開源 AI 程式設計 Agent	想找 Claude Code / Codex 替代品的人
9Router	9Router：把 Claude Code、Codex、Cursor 接到同一個 AI 路由器	decolua/9router	AI 程式設計模型路由與 token 成本控制	多工具、多模型使用者
goose	goose：桌面端、CLI 和 API 一體的開源 AI Agent	aaif-goose/goose	桌面、CLI、API 一體的開源 Agent	想要通用 Agent 工作臺的人

Agent 技能與工作流

這一類更關注把 AI 能力固化成可重複的技能、流程和規格。共 7 個專案。

專案	文章	GitHub	核心用途	適合人群
mattpocock/skills	拒絕 Vibe Coding：Matt Pocock 的 skills 倉庫給 AI 程式設計補上工程約束	mattpocock/skills	用 Skills 約束 AI 程式設計流程	想給 Agent 加工程規範的人
Superpowers	Superpowers：把 Coding Agent 拉回工程流程的技能框架	obra/superpowers	Agentic skills framework 與軟體開發方法論	想系統化使用 Coding Agent 的人
Prompt-Vault	Prompt-Vault：一個適合測試 AI 程式設計能力的 Prompt 規格庫	w512/Prompt-Vault	收集可測試 AI 程式設計能力的 prompt 規格	做模型/工具評測的人
web-video-presentation	web-video-presentation：把文章做成可錄屏網頁影片的 Agent Skill	ConardLi/garden-skills	把文章轉成可錄屏網頁影片的 Skill	內容創作者和自動化製作使用者
nuwa-skill	nuwa-skill：把“蒸餾一個人”從靈感變成可執行流程	alchaincyf/nuwa-skill	用 Skill 復刻人物表達和思維流程	做風格化 Agent 的人
Scientific Agent Skills	Scientific Agent Skills：把科研工作流交給 AI Agent 的技能庫	K-Dense-AI/scientific-agent-skills	科研工作流 Skill 集合	科研、資料分析和技術寫作使用者
easy-vibe	easy-vibe：給 Vibe Coding 初學者的一張學習地圖	datawhalechina/easy-vibe	Vibe Coding 入門學習地圖	AI 程式設計新手

RAG、知識庫與記憶

這一類主要解決文件檢索、知識庫構建、長期記憶和結構化抽取問題。共 7 個專案。

專案	文章	GitHub	核心用途	適合人群
LangExtract	Google LangExtract：用 LLM 從長文字里抽取結構化資料	google/langextract	從長文字中抽取結構化資訊	做資訊抽取和資料處理的人
qmd	qmd：給 AI Agent 使用的本地 Markdown 文件搜尋工具	tobi/qmd	本地 Markdown 文件搜尋	用 Markdown 管理知識庫的人
Firecrawl	Firecrawl 專案整理：給 AI Agent 用的網頁搜尋、抓取與互動 API	firecrawl/firecrawl	網頁抓取、搜尋和結構化資料入口	做 RAG 和 Agent 資料入口的人
RAGFlow	RAGFlow 專案整理：開源 RAG 引擎的功能與使用方法	infiniflow/ragflow	開源 RAG 引擎	企業知識庫和文件問答使用者
OpenHuman	OpenHuman 速讀：開源個人 AI Agent 的桌面化路線	tinyhumansai/openhuman	本地優先的個人 AI Agent 與記憶層	想整合個人資料的人
OpenKB	OpenKB：把文件編譯成可持續更新的 LLM 知識庫	VectifyAI/OpenKB	把文件編譯成可更新知識庫	文件知識庫維護者
PageIndex	PageIndex 是什麼？不用向量庫的推理式 RAG 文件索引解析	VectifyAI/PageIndex	不依賴向量庫的推理式文件索引	關注 RAG 新路線的人

多模態與內容創作

這一類面向圖片、影片、語音轉寫和內容分發等創作場景。共 5 個專案。

專案	文章	GitHub	核心用途	適合人群
rembg	rembg 專案整理：本地圖片背景移除工具	danielgatis/rembg	本地圖片背景移除	電商、美工和圖片處理使用者
awesome-gpt-image-2-prompts	GPT-Image 2 提示詞寶庫：電商、海報、人像、UI 全收錄	EvoLinkAI/awesome-gpt-image-2-prompts	GPT-Image 2 提示詞和案例庫	AI 繪圖和提示詞使用者
faster-whisper	faster-whisper：更快的 Whisper 轉寫引擎	SYSTRAN/faster-whisper	高效能語音轉文字	做字幕、轉寫和語音處理的人
Pixelle-Video	Pixelle-Video：一句主題生成短影片的開源 AI 引擎	AIDC-AI/Pixelle-Video	一句話生成短影片工作流	短影片和 AIGC 內容創作者
AiToEarn	內容發太多平臺太累？AiToEarn 想用 AI Agent 幫創作者省點事	yikart/AiToEarn	多平臺內容分發與創作者自動化	內容運營和創作者

本地模型與推理

這一類關注本地模型執行和推理實驗，當前數量較少。共 1 個專案。

專案	文章	GitHub	核心用途	適合人群
ds4	本地執行 DeepSeek 4：Antirez ds4 在 Apple Silicon Mac 上的嘗試	antirez/ds4	在 Apple Silicon 上嘗試執行 DeepSeek 4	本地模型和推理實驗使用者

垂直應用與自動化

這一類是把 Agent 或 AI 能力落到金融、交易、瀏覽器、桌面和電商監控等具體場景。共 7 個專案。

專案	文章	GitHub	核心用途	適合人群
TradingAgents-CN	TradingAgents-CN：面向中文使用者的多智慧體金融交易研究框架	hsliuping/TradingAgents-CN	多智慧體金融交易研究框架	量化、金融和 Agent 研究者
FinceptTerminal	FinceptTerminal：開源金融終端、量化研究和 AI Agent 工作臺	Fincept-Corporation/FinceptTerminal	金融終端、量化研究和 AI Agent 工作臺	金融分析和量化使用者
Anthropic financial-services	Anthropic financial-services：把金融 Agent 場景做成可複用模板	anthropics/financial-services	金融服務 Agent 模板	做金融 AI 方案的人
ai-goofish-monitor	ai-goofish-monitor：用 AI 自動盯閒魚商品的開源監控系統	Usagi-org/ai-goofish-monitor	AI 商品監控和閒魚自動化	二手交易監控使用者
CloakBrowser	CloakBrowser 是什麼？給 Playwright 和 Puppeteer 換一個更像真實使用者的瀏覽器	CloakHQ/CloakBrowser	更像真實使用者的瀏覽器自動化環境	瀏覽器自動化和 Agent 操作場景
UI-TARS-desktop	讓 AI 自己操作電腦？UI-TARS-desktop 把桌面、瀏覽器和工具都接了起來	bytedance/UI-TARS-desktop	桌面、瀏覽器和工具操作 Agent	想讓 AI 操作電腦的人
AI-Trader	AI-Trader 是什麼？一個讓 AI Agent 釋出交易訊號、做模擬交易的平臺	HKUDS/AI-Trader	AI Agent 交易訊號和模擬交易平臺	金融 Agent 與交易研究使用者

AI 應用開發基礎設施

這一類提供構建 AI 應用和 Agent 工具鏈所需的基礎元件。共 5 個專案。

專案	文章	GitHub	核心用途	適合人群
Prompt Optimizer	Prompt Optimizer：開源提示詞最佳化、測試與 MCP 工具	linshenkx/prompt-optimizer	提示詞最佳化、測試和 MCP 工具	做 prompt 工程和應用調參的人
Playwright CLI	Playwright CLI 使用入門：安裝、Skills、會話管理與常用命令	microsoft/playwright-cli	面向 coding agent 的瀏覽器自動化 CLI	需要瀏覽器操作能力的 Agent 使用者
Vercel AI SDK	Vercel AI SDK 是什麼？TypeScript 開發者構建 AI 應用的統一工具包	vercel/ai	TypeScript AI 應用開發 SDK	前端和全棧開發者
CLIProxyAPI	CLIProxyAPI：把 Codex、Claude Code、Gemini CLI 統一封裝成 API	router-for-me/CLIProxyAPI	把多個 AI CLI 和 OAuth 登入狀態封裝成相容 API	想統一接入 Codex、Claude Code、Gemini CLI 的使用者
CLIProxyAPI Management Center	CLIProxyAPI Management Center：給 CLIProxyAPI 配一個視覺化管理後台	router-for-me/Cli-Proxy-API-Management-Center	CLIProxyAPI 的 Web 管理介面，管理設定、帳號、日誌和 OAuth	把 CLIProxyAPI 當團隊閘道或帳號池使用的人

DeepSeek V4 Flash 做 Godot 遊戲 Demo：幾毛錢能跑通到什麼程度？

Wed, 06 May 2026 09:22:18 +0800

DeepSeek V4 Flash 用來開發 Godot 遊戲 Demo，到底能不能打？

重點很直接：它能不能做出一個可執行、可觀察、帶物理效果的 Godot 小 Demo。

結論先說：可以跑通，效果不算商業級，但已經足夠作為玩法原型和物理互動 Demo 使用。更重要的是，成本非常低，適合快速驗證想法。

Demo 表現

這個 Demo 的重點是物理互動。

幾個比較直觀的效果包括：

繩子可以被切斷。
箱子會掉到地上。
調大質量後，箱子碰撞會更猛烈。
繩子表現出比較明顯的彈性。
調整摩擦力和彈性後，箱子會出現明顯的滑動和反彈。

從呈現效果看，它已經不是「只生成幾段 Godot 腳本」那麼簡單，而是一個能執行、能觀察物理表現的小型原型。

可用程度

這個 Demo 的價值在於「能跑、能看、能改」。它不是完整遊戲，也不是可以直接商業化的工程，但已經能說明幾個問題：

DeepSeek V4 Flash 能理解 Godot Demo 的基本目標。
AI Agent 可以把需求轉成可執行工程。
Godot 物理互動這種非網頁類任務，已經可以進入低成本原型階段。
對個人開發者來說，它能把「想法」快速變成「能看的東西」。

如果目標是做一個正式遊戲，它當然還不夠；但如果目標是驗證「這個玩法有沒有意思」「物理效果大概能不能做出來」，這個 Demo 已經可用。

成本意義

最值得關注的不是畫面有多精緻，而是成本。

如果一個 Godot 物理 Demo 只需要幾毛錢級別的模型成本，就能得到一個可執行版本，那麼它的意義就不是替代專業遊戲開發，而是大幅降低原型試錯成本。

以前想驗證一個小遊戲想法，至少需要自己熟悉 Godot、寫腳本、調場景、調物理參數。現在可以先讓 AI Agent 生成一個可執行版本，再由人判斷方向對不對。

對獨立開發者來說，這類低成本試錯很有用：

快速驗證玩法概念。
生成臨時 Demo 給別人看。
探索 Godot API 和物理系統。
把想法轉成能跑的初版工程。
在不確定方向前減少手寫程式碼成本。

DeepSeek V4 Flash 的表現

比較值得注意的是，使用的是 DeepSeek V4 Flash，而不是更貴、更重的旗艦模型。

它在「低成本原型」這個定位上表現不錯。它不是最強、最穩、最適合交付生產工程的模型，但在預算敏感、想快速試一下方向的場景裡，很有吸引力。

適合什麼場景

DeepSeek V4 Flash + Agent + Godot 更適合下面這些任務：

小型玩法原型。
物理效果 Demo。
UI 或互動概念驗證。
教學示例。
輔助理解 Godot 專案結構。
生成第一版可執行工程。

不太適合直接承擔這些任務：

大型遊戲架構。
複雜角色控制器。
網路同步。
商業專案核心程式碼。
高精度物理模擬。
不經過人工測試的自動提交。

換句話說，它適合做「第一稿」和「試驗場」，不適合當生產工程負責人。

這說明了什麼

這說明，AI 程式設計正在從網頁、腳本、後端介面，繼續向遊戲開發和互動原型擴展。

過去遊戲開發的門檻很高，尤其是引擎、腳本、資源管理和物理系統混在一起時，新手很容易卡住。現在模型加 Agent 工具，可以先把工程搭起來，讓開發者把注意力放在玩法判斷和效果調優上。

它帶來的變化可能有三點：

第一，遊戲原型會更便宜。很多想法不用等到完整開發階段才驗證，可以先得到可執行 Demo。

第二，獨立開發者會更敢嘗試。不會 Godot 的人，也可以借助 AI 先摸到專案結構和基本流程。

第三，模型穩定性會變得更重要。遊戲開發不是只要程式碼能跑，還要效果合理、手感正常、參數可控。未來誰能更好地結合實際畫面和執行狀態，誰就更適合做這類任務。

小結

DeepSeek V4 Flash 做 Godot Demo，可以概括成一句話：效果不完美，但足夠便宜、足夠快，也足夠適合做原型。

它離商業遊戲還很遠，但如果目標是用極低成本驗證一個小遊戲想法，它已經很有價值。

對個人開發者來說，最現實的用法不是把遊戲全交給 AI，而是讓 AI 先給出能跑的工程，再由人負責判斷、取捨和打磨。這樣用，DeepSeek V4 Flash 這類低成本模型反而會很香。

用測試和行為描述約束 AI 寫程式，少堆史山

Tue, 05 May 2026 14:35:38 +0800

用 AI 寫程式時，最容易出現的體驗是：前期很快，後期很亂。功能剛開始能迅速搭起來，但專案一大、修改次數一多，就會出現一個 bug 改完又冒出三個 bug 的情況。

這不完全是 AI 的問題。很多人寫程式也會這樣，只是 AI 寫得更快，問題暴露得也更快。要減少這種失控，關鍵不是讓 AI「更努力」，而是給它更清楚的邊界：先說明什麼結果算對，再讓它寫實作。

TDD 和 BDD 就適合放到 AI 程式設計流程裡。TDD 負責把「對不對」變成自動測試，BDD 負責把「是不是我要的功能」變成人能看懂的行為描述。兩者結合，可以讓 AI 少猜、少自由發揮，也更容易被檢查。

TDD 解決什麼問題

TDD 是 Test Driven Development，也就是測試驅動開發。它的基本順序是：

先寫測試。
執行測試，確認它現在失敗。
再寫功能程式碼。
持續修改實作，直到測試通過。

這和很多人習慣的做法相反。平時寫一個排序函式，直覺上會先寫函式，再隨便輸入幾個數字看看結果對不對。TDD 則要求先把預期寫成測試，例如輸入 [3, 1, 2] 時應該得到 [1, 2, 3]，輸入空陣列時應該回傳空陣列，輸入包含重複數字時結果也應該正確。

這樣做的意義是：開發開始前，正確結果已經被定義清楚了。後面無論誰改程式碼，只要重新跑測試，就能知道有沒有破壞之前約定好的行為。

為什麼 TDD 以前不容易堅持

TDD 聽起來很美，但在真實專案裡並不容易長期執行。

一是它反直覺。面對一個空檔案時，很多人更想先把功能寫出來，而不是先寫測試。尤其需求還不清楚時，測試案例也很難落筆。

二是需求變化快。今天認真寫下的十幾個測試，明天需求一改，可能就要大面積重寫。短期看，它會讓開發節奏變慢。

三是測試本身也需要成本。測試程式碼不是憑空出現的，過去它需要工程師自己寫、自己維護、自己解釋價值。對只看短期交付速度的團隊來說，這件事很容易被壓掉。

但 AI 改變了這個成本結構。把需求轉成測試程式碼，恰好是 AI 很擅長的工作。讓 AI 根據測試去補實作，也比讓它對著一段模糊描述自由發揮可靠得多。

AI 寫程式時怎麼用 TDD

使用 AI 寫功能時，可以把提示方式從「幫我實作這個功能」改成下面這個順序：

讓 AI 先根據需求列出測試案例。
要求每個測試案例都有中文說明。
先 review 測試案例是否符合真實需求。
確認測試後，再讓 AI 寫功能實作。
要求 AI 執行測試，並根據失敗結果繼續修正。

這時，人主要 review 的不是一大段實作程式碼，而是測試是否說清楚了需求。測試案例通常更接近「輸入是什麼、輸出應該是什麼、邊界情況怎麼處理」，比直接讀實作邏輯輕鬆很多。

例如可以這樣要求 AI：

1
2
3

先不要實作功能。
請根據下面的需求編寫測試案例，每個測試案例用中文註解說明覆蓋的業務規則。
測試確認後，再根據測試實作程式碼。

這個流程能減少兩類常見問題：一類是 AI 寫著寫著偏題，另一類是後續修改時把舊功能改壞。

TDD 還不夠

只有 TDD 仍然有兩個缺口。

第一個缺口是：測試都通過，不等於產品真的符合預期。測試只能證明程式碼滿足了測試裡寫下的規則。如果測試本身沒有表達清楚使用者需求，程式碼仍然可能「正確地做錯事」。

第二個缺口是：測試程式碼對非技術使用者仍然不友好。哪怕有中文註解，很多人還是不願意閱讀一堆單元測試。需求越偏產品體驗，越難直接從測試程式碼裡確認「這是不是我要的東西」。

這時就需要 BDD。

BDD 解決什麼問題

BDD 是 Behavior Driven Development，也就是行為驅動開發。它關注的不是程式碼內部怎麼寫，而是系統在某個場景下應該表現出什麼行為。

BDD 常用的描述方式是 Given / When / Then：

Given：給定某個前置狀態。
When：當使用者或系統執行某個動作。
Then：應該得到某個結果。

例如一個帶吸血效果的遊戲角色，可以這樣描述：

Given 棋盤上有一個剩餘 1 點生命、攻擊力為 2、最大生命為 5 的吸血鬼
And 相鄰格子有一個剩餘 10 點生命的敵方單位
When 吸血鬼攻擊這個敵方單位
Then 敵方單位剩餘 8 點生命
And 吸血鬼恢復到 3 點生命

這段話不是程式碼，但它比「攻擊敵人時恢復生命」精確得多。它說明了初始狀態、動作和結果，也暴露出後續需要補充的問題：如果敵人只剩 1 點血，吸血鬼按造成傷害恢復，還是按攻擊力恢復？如果吸血鬼已經滿血，溢出的治療怎麼處理？

這些問題越早被問出來，AI 後面越不容易亂猜。

為什麼 BDD 很適合 AI

BDD 過去推行成本也不低。它要求產品、開發、測試用同一套行為描述溝通，而現實裡很多團隊並沒有這種協作習慣。

但 AI 時代，BDD 的成本下降了。你只需要先寫一句粗略需求，例如：

`1`	`吸血鬼攻擊敵人後，恢復與造成傷害等量的生命值。`

然後讓 AI 生成 Given / When / Then 場景。做得好的 AI 會主動補充邊界情況，並追問不明確的規則。你需要做的是確認這些行為描述，而不是直接讀實作程式碼。

一旦行為描述確認清楚，再讓 AI 把它轉換成測試程式碼，最後根據測試實作功能，路徑就順了很多。

一套更穩的 AI 程式設計流程

實際使用時，可以把 BDD 和 TDD 串起來：

先用自然語言寫需求。
讓 AI 轉成 BDD 行為場景。
人確認 Given / When / Then 是否符合預期。
讓 AI 把行為場景轉換成自動測試。
人快速 review 測試覆蓋範圍。
讓 AI 實作功能。
執行測試，失敗就讓 AI 根據錯誤繼續修正。
最後再做一次人工驗收和程式碼 review。

這裡的關鍵是順序。不要一開始就讓 AI 寫完整實作，而是先讓它把需求變成可確認的行為，再變成可執行的測試。這樣 AI 的自由發揮空間會小很多。

可以直接使用類似這樣的提示詞：

請按 BDD + TDD 的流程處理這個需求。

第一步：先把需求整理成 Given / When / Then 行為場景，不要寫程式碼。
第二步：列出你發現的不明確規則，並向我確認。
第三步：在行為場景確認後，再把它們轉換成測試案例。
第四步：測試確認後，再實作功能。
第五步：執行測試，根據失敗結果修復，直到測試通過。

這類提示詞不複雜，但能明顯改變 AI 的工作方式。它會先收斂需求，再進入實作，而不是一上來就寫一堆看似完整、實際難以驗證的程式碼。

適合優先使用的場景

BDD + TDD 不一定適合所有任務。對於一次性腳本、臨時資料處理、小範圍樣式調整，完整流程可能太重。

它更適合這些場景：

業務規則多，容易理解錯。
邊界條件多，後續還會持續修改。
遊戲、計費、權限、狀態機、表單驗證等邏輯密集功能。
需要多人協作確認需求。
程式碼將長期維護，不只是一次性生成。
已經出現「AI 越改越亂」的專案。

如果只是讓 AI 改一個按鈕文案，不必上完整流程。但如果要做一套角色技能系統、訂單狀態流轉、權限判斷、積分規則，先寫行為場景和測試會更划算。

使用時注意什麼

第一，測試不是越多越好。測試應該覆蓋關鍵規則和高風險邊界，而不是把實作細節全部鎖死。否則需求稍微變化，測試就會變成維護負擔。

第二，BDD 場景要寫具體。不要寫「系統應該正常工作」「體驗應該流暢」這類無法驗證的描述。要寫清楚給定什麼狀態、發生什麼動作、結果應該是什麼。

第三，人仍然要 review。AI 可以生成測試和行為場景，但它不知道你真正想要的產品取捨。尤其是邊界規則，必須由人確認。

第四，測試通過後還要實際執行功能。自動測試能兜住邏輯問題，但介面體驗、效能、互動細節、使用者感受仍然需要人工驗收。

小結

AI 寫程式快，但快不等於穩。越是複雜需求，越不能只靠一句「幫我實作」。更好的方式是先把需求拆成可確認的行為，再把行為變成可執行的測試，最後讓 AI 按測試實作程式碼。

TDD 讓 AI 知道什麼結果算對，BDD 讓人更容易確認這是不是自己想要的功能。兩者合起來，不是為了增加儀式感，而是為了減少 AI 的猜測空間，把「寫得快」變成「改得穩」。

Claude Code 的 HERMES.md 計費故障是怎麼回事

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

Claude Code 最近有一次很典型的計費故障：使用者只是啟動 CLI，還沒有正式發出請求，就因為本機 HERMES.md 檔案被讀取而產生了大額費用。

這件事值得單獨看，不是因為某個使用者損失了多少錢，而是因為它暴露了 AI 程式設計工具的一個新風險：只要工具會自動讀取上下文，本機檔案就可能變成真實 token 成本。

發生了什麼

公開 issue 顯示，使用者在工作目錄裡放了一個很大的 HERMES.md 檔案。啟動 Claude Code 後，CLI 會掃描並載入專案上下文。問題在於，這個檔案被自動納入上下文，並被計入 API 使用量。

使用者並沒有明確要求模型處理這份檔案，但計費已經發生。更麻煩的是，這類行為發生在工具初始化或上下文準備階段，使用者不一定能第一時間意識到費用正在產生。

Anthropic 後續在 issue 中回覆，表示會退還異常費用，並額外提供額度補償。這個回應說明問題至少已被官方確認和處理，但它仍然提醒使用者：AI CLI 的「自動上下文」不是免費的。

HERMES.md 為什麼會觸發問題

HERMES.md 本身不是重點。它可以換成任何大檔案：長日誌、匯出的文件、測試資料、資料庫 dump、生成報告，都可能造成類似問題。

真正的問題在於三件事疊加：

Claude Code 會自動讀取專案上下文。
被讀取的檔案可能很大。
上下文 token 會進入計費鏈路。

如果一個檔案足夠大，哪怕只是被工具「順手帶上」，也可能產生明顯費用。對按 token 計費的模型來說，自動化越強，越需要明確邊界。

這不是普通 bug

普通 CLI bug 可能只是命令失敗、輸出錯誤或功能不可用。計費 bug 更敏感，因為它直接影響使用者帳單。

對 AI 程式設計工具來說，計費邊界很容易變模糊：

系統提示會消耗 token。
專案規則會消耗 token。
自動讀取的檔案會消耗 token。
工具調用結果會消耗 token。
重試、壓縮、摘要也可能繼續消耗 token。

使用者看到的是一次「啟動工具」或「一次對話」，後臺實際可能已經發生多次請求和大量上下文傳輸。

使用者應該怎麼防

如果你使用 Claude Code、Codex、Cline 這類 AI 程式設計工具，可以先做幾件事：

不要把大檔案直接放在專案根目錄。
把日誌、匯出資料、構建產物、臨時檔案加入忽略規則。
檢查工具是否支援類似 .ignore、上下文排除、檔案白名單的配置。
開啟預算提醒或用量限制。
第一次在大型倉庫執行前，先用小目錄測試。

如果倉庫裡必須保留大檔案，最好明確告訴工具不要讀取它們。專案規則裡也可以寫清楚：不要主動讀取日誌、dump、資料集、歸檔檔案和大體積 Markdown。

工具廠商該怎麼改

這類問題不能只靠使用者小心。工具本身也應該給出硬邊界。

更合理的設計包括：

初始化階段不應隱式計入大檔案。
自動讀取超大檔案前要提示使用者確認。
CLI 應顯示本次請求預估 token 和費用區間。
預設忽略常見大檔案和生成目錄。
對異常 token 激增設定保護閾值。

AI 程式設計工具越像「自動代理」，越需要把成本透明化。否則使用者很難判斷一次操作到底會產生多少費用。

小結

Claude Code 的 HERMES.md 計費故障，本質上是自動上下文和按量計費之間的衝突。

對使用者來說，最重要的是把專案上下文管住：大檔案不要預設暴露給 AI 工具，預算和用量也要設上限。對工具廠商來說，自動讀取檔案必須配套可見的成本提示和保護機制。

參考：