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. 人工门控依赖：三个审批节点需人类介入，自动化流程会在此阻塞，不适合完全无人值守场景