GAAI-framework

背景：一个让 AI「靠谱」的框架

当你把一个 AI 编程助手（Claude Code、Cursor、Windsurf）交给团队，最常听到的抱怨是什么？「AI 写的代码不可控」「它乱改文件」「不知道它在干什么」「上线后发现一堆问题」——这些问题的本质不是 AI 不够强，而是 缺少一套 governance 机制 来约束 AI 的行为边界。

GAAI（Governed Agentic AI Infrastructure）就是为了解决这个问题。它不是一个 AI 模型，不是一个 SDK，而是一套 以文件夹形式嵌入项目的治理框架。在项目中放入一个 .gaai/ 目录，AI 编程助手就获得了「什么可以做、什么不能做」的清晰边界。

图1：GAAI 守护进程监控界面，实时展示并行交付状态

---

核心设计：三权分立

GAAI 的设计哲学深受软件开发生命周期（SDLC）启发，将 AI 的工作流分解为三个职责明确的阶段：

1. Discovery（发现阶段）——回答「做什么」

通过 /gaai-discover 激活。Discovery Agent 会与你对话，澄清需求细节，生成带有验收标准（Acceptance Criteria）的用户故事（Story），并将其加入 backlog 队列。这个过程确保每一个进入执行阶段的任务都经过充分的需求澄清，避免 AI 在模糊指令下「自由发挥」。

Discovery 的独特之处在于它会编译一份 Discovery Session Brief——一份结构化的会话摘要，记录所有决策、观察、权衡、约束边界。交给子 Agent 时，这份 brief 作为不可更改的输入，防止上下文丢失。

2. Delivery（交付阶段）——回答「怎么做」

通过 /gaai-deliver 手动触发单个 Story，或 /gaai-daemon 启动守护进程自动轮询 backlog、并行交付多个 Story。

守护进程模式是 GAAI 最具特色的部分：每个 Story 在独立的 tmux 会话中执行，拥有独立的 Claude Code 实例，实时可见交付进度。如果项目使用 git staging 分支，守护进程还会自动创建分支、提交、发起 PR——整个流程无需人工介入。

关键约束：Delivery 只能执行 backlog 中处于 refined 状态的故事。未经验证的需求，AI 无法擅自行动。

3. Bootstrap（初始化阶段）——让 AI 理解项目

通过 /gaai-bootstrap 激活。扫描现有代码库，提取架构决策，建立项目记忆（memory）和决策日志（decisions log）。这一步让 AI 在介入项目之前，就具备足够的上下文理解能力。

---

技术架构：纯文本的力量

GAAI 的技术选型极为克制：Markdown + YAML + Bash，零依赖，零外部服务。

.gaai/ 目录结构清晰地划分为两层：

• core/：框架引擎，由官方 installer 管理，包含 agents（决策逻辑）、skills（可执行技能）、contexts/rules（治理规则）、workflows（流程编排）、scripts（Shell 工具）。升级框架时直接运行 installer，新文件覆盖，旧文件保留。
• project/：项目自定义层，覆盖或扩展 core 中的任意组件。安装更新不会触碰这一层。

这种 core → project 的覆盖模式，使得框架升级与项目定制完全解耦——开发者可以在 project/ 下添加自定义 agent、skills、rules，而不必担心被框架更新覆盖。

兼容矩阵：

工具	Discovery	Manual Delivery	Daemon Delivery
Claude Code	✓	✓	✓ (必需)
Cursor	✓	✓	✗
Windsurf	✓	✓	✗
Codex CLI	✓	✓	✗
Gemini CLI	✓	✓	✗
OpenCode	✓	✓	✗

---

治理机制：规则即代码

GAAI 的治理能力来源于 .gaai/project/contexts/rules/ 下的 YAML 规则文件。框架预置了 8 条核心规则，涵盖：

• orchestration.rules.md：工作流编排规则，定义各 Agent 之间的协作方式
• scope 定义：明确哪些代码路径、哪些操作在规则允许范围内
• 验收标准校验：Delivery Agent 执行完成后，自动验证 acceptance criteria 是否满足

这套规则的本质是将团队的工程规范、代码风格、安全策略编码为 AI 可读、可执行的约束——而不是靠 prompt 工程「软约束」。

---

上手体验

安装极简（这也是它最令人惊喜的地方）：

bash <(curl -sL https://raw.githubusercontent.com/Fr-e-d/GAAI-framework/main/install.sh)   --target . --tool claude-code --yes

一行命令，在任意 Git 项目的根目录运行，即可在项目内植入 .gaai/ 文件夹。

使用门槛分层：

• 只想让 AI 帮忙澄清需求 → 只需 /gaai-discover，任何 AI 工具均可
• 想让 AI 自动交付 → 需要 Claude Code CLI（守护进程必需依赖）
• 想做项目初始化 → 需要 tmux（守护进程需要独立会话管理）

对于个人开发者或小型团队，GAAI 的 /gaai-discover + /gaai-deliver 组合已经足够强大；对于追求全自动化的团队，守护进程模式提供了完整的 CI/CD 集成路径。

---

局限与争议

1. Daemon 模式依赖 Claude Code CLI：这不是框架设计偏好，而是 Claude Code 提供了完整的 CLI 接口和代码编辑 API。切换到其他工具需要框架做适配工作。
2. 无容器化支持：目前没有 Dockerfile 或 docker-compose，无法在隔离环境中运行。对于追求环境一致性的团队，这是一大遗憾。
3. ELv2 许可证：这是一个较为严格的许可证，允许开源使用但有附加限制（广告/品牌使用受限）。商业项目引入前需仔细审查许可证条款。
4. tmux 强依赖：守护进程模式假设 Linux/macOS 环境，Windows 用户需要 WSL。这限制了其在纯 Windows 团队中的普及。

---

行业意义

GAAI 代表了一个重要的趋势：从「用 AI 写代码」到「用 AI 治理 AI」的范式转移。

2024-2025 年，AI 编程助手大爆发，但大多数团队遇到的问题是：AI 产生的代码质量不稳定、可控性差、与团队规范冲突。GAAI 通过将传统的需求分析 → 任务分解 → 代码审查 → 上线的 SDLC 流程引入 AI 工作流，用 backlog + acceptance criteria + rules 的组合，给 AI 套上了一套「安全带」。

这种思路与 DevOps 中的「Gatekeeping」理念一脉相承：让 AI 自由发挥之前，先建立清晰的检查点。随着 AI Agent 在软件开发中的渗透率提升，这类 governance 框架的价值将愈发显著。

---

总结

GAAI 是一款小而美的 AI 编程治理框架。它不追求功能大而全，而是聚焦在一个明确的痛点：让 AI 编程工具从「不可控的助手」升级为「可信赖的开发者」。纯文本架构（Markdown/YAML/Bash）让它几乎零门槛，核心治理机制（backlog + rules + acceptance criteria）让它真正有效。

如果你在团队中引入 AI 编程工具后遇到了「AI 乱改代码」「上下文丢失」「交付质量不稳定」等问题，GAAI 值得一试。它的极简哲学和清晰边界设计，能在不给团队增加额外认知负担的前提下，显著提升 AI 辅助开发的安全感和效率。