TaiyiForge：把 AI 寫程式碼變成工程流水線

解決什麼

TaiyiForge 針對 AI 輔助編碼的工程化痛點：Agent 跳過設計直接寫程式碼、長會話上下文丟失、不同 AI 工具各一套流程、缺乏可審計的決策鏈。它通過九階段狀態機（change → requirement → design → ui-design → task → dev → test → review → integration）強制每個變更按固定順序產出工件，關鍵節點設定人工門控，防止 AI 自行放行。同時提供統一命令集（如 /taiyi:new、/taiyi:plan），在 Claude Code、Cursor、Codex、OpenCode 四個終端保持一致行為。

為何火

該專案在 GitHub 獲得 815 stars，主要因為：1) 把散裝 AI 對話變成可追溯的工程流水線，每階段產出 Markdown 工件存檔；2) 強制 TDD（dev 階段先紅後綠）和 evidence 驗證（每個驗收標準配可執行命令），避免假過門；3) /taiyi:plan 命令可從 README/PRD 一鍵生成全棧骨架（後端 FastAPI + 前端 + 測試套件，79 檔案），實測通過 48 個單測；4) 跨工具統一詞彙，切換 AI 終端無需重新學習流程。

核心功能

• 九階段流水線：每次變更順序走 change（方案）→ requirement（驗收標準）→ design（≥2 方案對比）→ ui-design（UI 契約）→ task（拆分 PR）→ dev（TDD 實現）→ test（測試證據）→ review（跨 AI 評審）→ integration（交付門控），三個節點需人類審批
• 統一命令集：29 條 slash 命令（如 /taiyi:new 建立變更、/taiyi:status 查進度、/taiyi:apply 進入實現），在 Claude/Cursor/Codex/OpenCode 行為完全一致
• 專案級規劃：/taiyi:plan 讀取需求檔案（支援 Markdown/PDF/URL），自動拆分模組、推薦 profile（full/lite/nano），auto 模式一鍵生成全棧程式碼骨架（含後端 controllers/services/repositories、前端、遷移指令碼、三層測試）
• 上下文壓縮：長會話自動產出 CONTEXT-COMPACT.md，跨天續接無需重新描述背景
• ChangeGraph：自動追蹤變更間依賴，改動一處可知全域性影響

安裝

# 全域性安裝
npm install oh-my-taiyiforge

# 同步 Skill 到所有 AI 終端
npx taiyi-forge-install --all

# 僅安裝特定終端
npx taiyi-forge-install --cursor
npx taiyi-forge-install --claude --opencode

# 原始碼安裝
git clone https://github.com/Dong90/oh-my-taiyiforge.git
cd oh-my-taiyiforge && npm install && npm run build
node scripts/taiyi-forge.sh install --all

需配置 .env 檔案填入 TAIYI_OPENAI_API_KEY（或相容服務的 base URL），預設呼叫 gpt-4o-mini 模型。Docker 部署可直接 docker-compose up，預設埠 8000。

適合誰

• 需要規範 AI 編碼流程的團隊：多人協作時統一 AI 使用規範，每個變更留下完整工件鏈（需求、設計、測試證據）便於交接和審計
• 追求 TDD 紀律的開發者：強制先寫測試再實現，dev 階段必須先紅後綠才能推進
• 跨 AI 工具使用者：在 Claude、Cursor、Codex 間切換時保持一致的命令和流程，無需重複學習
• 快速原型搭建：/taiyi:plan --auto 可從需求文件一鍵生成可執行的全棧骨架（含 FastAPI 後端、前端、測試），適合 MVP 階段

中國大陸使用者需自備 OpenAI API Key 或國內相容服務（專案支援自定義 TAIYI_OPENAI_BASE_URL），無梯子可用中轉 API。

社群評價

暫無足量社群公開討論，以下為基於專案本身的中立評估：該專案通過狀態機引擎解決了 AI 輔助編碼的工程化問題，核心創新在於把隱性的 AI 對話流程顯性化為九階段工件鏈，並強制人工門控。從技術實現看，專案提供了完整的 TypeScript 實現和 Docker 部署方案，示例程式碼（translation-assistant）展示了 auto 模式產出的全棧骨架質量（79 檔案、48 個測試全綠）。潛在爭議點在於：1) 九階段流水線對小改動可能過重（專案提供 lite/nano profile 緩解）；2) 依賴外部 LLM 服務，token 成本和響應速度受限於 API 提供商；3) 跨工具統一需要各 AI 終端支援自定義 Skill/外掛機制。

選型對比

vs 直接用 Claude/Cursor 對話：原生對話靈活但無流程約束，容易跳過設計直接寫程式碼，長會話上下文丟失後需重新描述。TaiyiForge 犧牲部分靈活性換取可審計性，每階段產出固定工件，適合團隊協作和需要留檔的場景。

vs GitHub Copilot：Copilot 側重單行/函式級補全，TaiyiForge 側重模組級工作流編排，兩者可互補（TaiyiForge 生成骨架，Copilot 輔助填充細節）。

vs Cursor Composer：Composer 提供多檔案編輯能力但無強制流程，TaiyiForge 通過狀態機約束推進順序，適合需要 TDD 紀律和人工審批的團隊。

vs 自建 prompt 工程：自建需維護大量 prompt 模板和上下文管理邏輯，TaiyiForge 提供開箱即用的九階段模板和 token 壓縮機制，減少重複造輪子。

已知坑

1. 外部依賴必需：必須配置 OpenAI API Key 或相容服務，無 Key 無法啟動。中國大陸使用者需自備梯子或中轉 API，官方未提供國內 LLM 適配（如文心一言、通義千問）
2. 九階段對小改動偏重：修改一個 typo 也要走完整流程，雖然提供 nano profile 但仍需建立 change。適合中大型功能開發，不適合緊急熱修復
3. 學習曲線：29 條命令和九階段概念需要團隊統一培訓，初次使用需閱讀文件理解 change/requirement/design 等工件含義
4. token 成本：/taiyi:plan --auto 生成全棧骨架會消耗大量 token（實測單次可能數萬 token），需評估 API 成本
5. 多工具同步：需手動執行 npx taiyi-forge-install 同步 Skill 到各 AI 終端，工具更新後需重新同步
6. 人工門控依賴：三個審批節點需人類介入，自動化流程會在此阻塞，不適合完全無人值守場景