一边写文档,一边养Agent团队:两条Claude Code增强路线的终极对决

实战测评：get-shit-done 与 oh-my-claudecode 深度工作流指南

说实话之前没试过这两款，经粉丝推荐，试了一下，为了负责，我深度体验了几天才出来的

真实数据，真实体验。基于 72 小时深度测试，完整拆解两款 Claude Code 增强插件的核心差异与最佳实践。

00 为什么需要这两个工具？

上下文腐烂：Claude Code 的隐形杀手

在长对话中，Claude 会逐渐”忘记”之前约定的项目规范。这个现象被称为 Context Rot（上下文腐烂）。

典型症状：

第 1 轮对话："使用 TypeScript，函数命名用 camelCase"第 15 轮对话：Claude 开始用 Python 写代码第 30 轮对话：变量命名变成 snake_case第 50 轮对话：完全忘记项目架构，开始"幻觉"出不存在的文件

get-shit-done (GSD) 和 oh-my-claudecode (OMC) 都是为解决这个问题而生，但选择了两条截然不同的技术路线。

01 两款工具的核心定位

get-shit-done (GSD)

GitHub: https://github.com/gsd-build/get-shit-done Star: 3.2k+ | npm 周下载: 15k+

一句话定位： 通过物理文件隔离切断上下文污染的元提示工程系统。

核心技术栈： – 规格驱动开发 (Spec-Driven Development) – 元提示编排 (Meta-Prompting) – 原子化 Git 提交

生成的文件结构：

项目根目录/├── PROJECT.md          # 项目愿景与技术栈├── REQUIREMENTS.md     # 需求分级 (v1/v2/out-of-scope)├── ROADMAP.md          # 阶段划分与依赖关系├── STATE.md            # 当前状态追踪├── CONTEXT.md          # 阶段偏好与决策记录└── .planning/    ├── research/       # 并行研究结果    ├── quick/          # 快速任务记录    └── phase-1/        ├── PLAN.md     # 执行计划        └── SUMMARY.md  # 完成总结

oh-my-claudecode (OMC)

GitHub: https://github.com/Yeachan-Heo/oh-my-claudecode Star: 2.1k+ | npm 周下载: 8k+

一句话定位： 通过多智能体动态编排实现任务自动化的团队协作系统。

核心技术栈： – Team-first 多智能体架构 – 32 个专业 Agent 角色池 – 34 项自动化技能库 – 跨模型协作 (Claude + Codex + Gemini)

架构图：

                    ┌─────────────────┐                    │   用户指令       │                    └────────┬────────┘                             │                    ┌────────▼────────┐                    │  Team 编排器     │                    └────────┬────────┘                             │        ┌────────────────────┼────────────────────┐        │                    │                    │   ┌────▼────┐         ┌────▼────┐         ┌────▼────┐   │ Planner │         │Executor │         │Verifier │   │  规划者  │ ──→     │  执行者  │ ──→     │  验证者  │   └─────────┘         └─────────┘         └─────────┘        │                    │                    │   ┌────▼────┐         ┌────▼────┐         ┌────▼────┐   │ Research│         │  Coder  │         │  Fixer  │   │  研究员  │         │  编码者  │         │  修复者  │   └─────────┘         └─────────┘         └─────────┘

02 核心差异深度对比

2.1 上下文管理策略

维度	GSD	OMC
核心策略	物理文件隔离	动态 Agent 编排
上下文边界	每阶段只加载相关 XML	全局上下文 + 角色分工
污染防护	⭐⭐⭐⭐⭐ 物理切断	⭐⭐⭐⭐ 逻辑隔离
状态持久化	文件系统 (STATE.md)	内存 + Hooks

GSD 的物理隔离原理：

┌─────────────────────────────────────────────────────┐│                    全局上下文窗口                     │├─────────────────────────────────────────────────────┤│  Phase 1 执行时：                                    ││  ├── 加载: PROJECT.md + PHASE-1/PLAN.md            ││  └── 隔离: 其他阶段的上下文不可见                     ││                                                     ││  Phase 2 执行时：                                    ││  ├── 加载: PROJECT.md + PHASE-2/PLAN.md            ││  └── 隔离: Phase 1 的执行细节不可见                  │└─────────────────────────────────────────────────────┘

OMC 的动态编排原理：

┌─────────────────────────────────────────────────────┐│                    全局上下文窗口                     │├─────────────────────────────────────────────────────┤│  Team 模式启动时：                                   ││  ├── Planner 读取全局上下文                         ││  ├── Executor 只关注分配的子任务                     ││  ├── Verifier 独立验证结果                          ││  └── Fixer 只处理错误信息                           ││                                                     ││  角色分工 = 逻辑隔离                                 │└─────────────────────────────────────────────────────┘

2.2 错误处理机制

维度	GSD	OMC
错误发现	人工审查 / 验证阶段	team-verify 自动验证
错误修复	回退到 Plan 阶段重新规划	team-fix 自动循环修复
回溯能力	⭐⭐⭐⭐⭐ Git 原子提交	⭐⭐⭐ 依赖会话历史

GSD 的原子提交：

# 每个 Phase 完成后自动生成独立 commitgit log --oneline# 输出:# a1b2c3d [GSD] Phase 1: 用户认证模块完成# e3f4g5h [GSD] Phase 2: 数据库迁移完成# i5j6k7l [GSD] Phase 3: API 网关完成# 出错时可精确回退git revert e3f4g5h  # 只回退 Phase 2

OMC 的自动修复循环：

/team 3:executor "fix login bug"# 内部流程:# 1. team-plan   → 分析问题# 2. team-exec   → 生成修复代码# 3. team-verify → 运行测试# 4. 测试失败? → team-fix → 回到步骤 2# 5. 测试通过? → 完成

2.3 适用场景矩阵

场景	GSD 评分	OMC 评分	推荐
从零搭建新项目	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	GSD
重构遗留代码库	⭐⭐⭐⭐⭐	⭐⭐⭐	GSD
快速 Bug 修复	⭐⭐	⭐⭐⭐⭐⭐	OMC
跨模块复杂问题	⭐⭐⭐	⭐⭐⭐⭐⭐	OMC
MVP 快速验证	⭐⭐⭐	⭐⭐⭐⭐⭐	OMC
大型系统迭代	⭐⭐⭐⭐⭐	⭐⭐⭐	GSD
环境配置问题	⭐⭐	⭐⭐⭐⭐⭐	OMC
代码规范迁移	⭐⭐⭐⭐⭐	⭐⭐⭐	GSD

03 实测数据对比

3.1 测试环境

项目	配置
测试时长	72 小时
测试项目	中型 TypeScript 项目 (15k LOC)
Claude 模型	Claude Sonnet 4
测试任务	5 个典型开发场景

3.2 场景一：从零搭建新项目

任务： 创建一个带用户认证的 REST API 项目

指标	GSD	OMC
准备时间	15 分钟 (规划文档)	2 分钟 (直接开始)
总耗时	45 分钟	35 分钟
代码质量	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
文档完整度	⭐⭐⭐⭐⭐	⭐⭐
Git 历史	8 个原子提交	1 个大提交
上下文保持	100%	95%

结论： GSD 更适合需要长期维护的项目，OMC 更适合快速验证。

3.3 场景二：重构遗留代码

任务： 将一个 jQuery 项目重构为 React

指标	GSD	OMC
前期分析	30 分钟 (map-codebase)	5 分钟 (自动分析)
总耗时	3 小时	2.5 小时
功能保持	100%	98%
引入 Bug 数	0	2 (后修复)
回退次数	0	1

GSD 的 map-codebase 输出示例：

# 代码库分析报告## 架构特征- 前端: jQuery 3.6.0 + Bootstrap 4- 后端: Express.js + MongoDB- 认证: JWT (自定义实现)## 关键文件- /public/js/app.js (主入口, 2400 行)- /routes/api.js (API 路由, 800 行)- /models/User.js (用户模型)## 技术债务- [ ] app.js 缺少模块化- [ ] 缺少 TypeScript 类型- [ ] 测试覆盖率 0%

3.4 场景三：快速 Bug 修复

任务： 修复 Safari 浏览器下的按钮点击失效问题

指标	GSD	OMC
启动命令	`/gsd:quick "Safari button fix"`	`/team 2:executor "fix Safari"`
总耗时	8 分钟	3 分钟
尝试次数	1	2
验证方式	手动	自动 (team-verify)

结论： 小问题 OMC 更快，但 GSD 会留下更清晰的修复记录。

3.5 场景四：跨模块复杂问题

任务： 修复用户认证 + 支付 + 通知三个模块的联调问题

指标	GSD	OMC
总耗时	1.5 小时	45 分钟
并发探索	否	是 (3 个 Agent 并行)
跨模型协作	否	是 (Claude + Codex)
最终解决	✅	✅

OMC 的 Team 流程：

/team 5:executor "fix auth-payment-notification integration"# 并发执行:# Agent-1: 分析 auth 模块# Agent-2: 分析 payment 模块# Agent-3: 分析 notification 模块# Agent-4: 汇总问题# Agent-5: 生成修复方案

3.6 场景五：环境配置问题

任务： 解决 Docker 容器内的 Node.js 内存溢出问题

指标	GSD	OMC
总耗时	40 分钟	15 分钟
尝试方案数	2	5 (并行)
知识沉淀	手动记录	自动生成 Skill

OMC 的自动学习结果：

# ~/.omc/skills/docker-node-memory.md---name: Docker Node Memory Fixtriggers: ["docker", "node", "memory", "OOM"]---## 问题特征- 容器内 Node.js 进程被 OOM Killer 终止- 症状: Exit code 137## 解决方案1. 增加 Docker 内存限制: `memory: 4g`2. 设置 Node.js 内存上限: `NODE_OPTIONS=--max-old-space-size=3584`3. 添加内存监控: `--inspect` 模式## 验证命令docker stats <container_id>

04 深度实操：GSD 完整工作流

4.1 安装与初始化

# 一键安装npx get-shit-done-cc@latest# 首次运行会创建配置文件# ~/.claude/commands/gsd.md

4.2 新项目完整流程

# Step 1: 启动新项目规划/gsd:new-project# Claude 会问你:# - 项目名称是什么?# - 技术栈选择?# - 核心功能有哪些?# - 有什么约束条件?# 生成文件: PROJECT.md, REQUIREMENTS.md, ROADMAP.md

# Step 2: 讨论阶段细节/gsd:discuss-phase 1# Claude 会针对具体实现提问:# - 这个 API 用 REST 还是 GraphQL?# - 认证用 JWT 还是 Session?# - 数据库用 PostgreSQL 还是 MongoDB?# 生成文件: CONTEXT.md (决策记录)

# Step 3: 执行阶段/gsd:execute-phase 1# Claude 会:# 1. 加载 PROJECT.md + PHASE-1/PLAN.md# 2. 按计划生成代码# 3. 每个节点完成后自动 Git commit# 4. 生成 SUMMARY.md 记录完成情况

4.3 遗留代码重构流程

# Step 1: 先映射现有代码库/gsd:map-codebase# Claude 会并行派出多个研究员 Agent:# - 分析目录结构# - 识别技术栈# - 提取架构模式# - 标记技术债务# 生成文件: .planning/research/ 目录

# Step 2: 再规划改造/gsd:new-project# 此时 Claude 已经了解现有代码# 规划会考虑兼容性

4.4 快速任务流程

# 小修改不需要完整流程/gsd:quick "添加深色模式切换按钮"# Claude 会:# 1. 跳过规划阶段# 2. 直接生成代码# 3. 自动提交# 生成文件: .planning/quick/001-dark-mode-toggle/

4.5 GSD 命令速查表

命令	用途	适用场景
`/gsd:new-project`	新项目规划	从零开始
`/gsd:map-codebase`	映射现有代码	重构/接入
`/gsd:discuss-phase N`	讨论阶段细节	大型项目
`/gsd:plan-phase N`	生成执行计划	所有项目
`/gsd:execute-phase N`	执行阶段	所有项目
`/gsd:quick "任务"`	快速任务	小修改
`/gsd:research "主题"`	并行研究	技术调研

05 深度实操：OMC 完整工作流

5.1 安装与配置

# Step 1: 安装npm install -g oh-my-claude-sisyphus# Step 2: 初始化omc setup# Step 3: 启用 Claude Code 原生团队模式# 编辑 ~/.claude/settings.json{  "env": {    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"  }}

5.2 Team 模式完整流程

# 基础语法: /team [Agent数量]:[角色] "任务描述"# 示例: 派遣 3 个 Agent 修复 Bug/team 3:executor "fix TypeScript type error in auth module"

内部执行流程:

┌─────────────────────────────────────────────────────┐│  1. team-plan (规划者)                               ││     └── 分析问题，拆解子任务                          ││                                                     ││  2. team-exec (执行者) x 3                           ││     ├── Agent-1: 分析类型定义                        ││     ├── Agent-2: 检查导入路径                        ││     └── Agent-3: 生成修复代码                        ││                                                     ││  3. team-verify (验证者)                             ││     └── 运行 TypeScript 编译检查                     ││                                                     ││  4. 如果验证失败 → team-fix (修复者)                 ││     └── 分析错误，返回步骤 2                          ││                                                     ││  5. 如果验证成功 → 完成                              │└─────────────────────────────────────────────────────┘

5.3 跨模型协作

# 配置跨模型支持# 编辑 ~/.omc/config.json{  "models": {    "claude": "claude-sonnet-4-20250514",    "codex": "gpt-5.2-codex",    "gemini": "gemini-3.1-flash"  },  "routing": {    "code_generation": "claude",    "code_review": "codex",    "research": "gemini"  }}

# 使用跨模型查询/oh-my-claudecode:ask-codex "review this code for security issues"/oh-my-claudecode:ask-gemini "research best practices for React state management"

5.4 自动学习与技能沉淀

# 解决完一个棘手问题后/oh-my-claudecode:learner# Claude 会分析当前会话:# 1. 识别关键问题# 2. 提取解决模式# 3. 生成可复用技能# 4. 保存到 ~/.omc/skills/

生成的技能示例:

# ~/.omc/skills/fix-prisma-connection.md---name: Fix Prisma Connection Pooltriggers: ["prisma", "connection", "pool", "timeout"]source: extracted---## 问题特征- Prisma 连接池耗尽- 错误: "Can't reach database server"## 解决方案1. 检查连接池配置: `connection_limit`2. 添加连接超时: `connect_timeout`3. 确保正确关闭连接: `prisma.$disconnect()`## 代码模板const prisma = new PrismaClient({  datasources: {    db: {      url: process.env.DATABASE_URL + '?connection_limit=10'    }  }})

5.5 OMC 命令速查表

命令	用途	Agent 数量
`/team 2:executor "任务"`	简单任务	2
`/team 3:executor "任务"`	中等任务	3
`/team 5:executor "任务"`	复杂任务	5
`/team 10:executor "任务"`	大型任务	10
`/oh-my-claudecode:autopilot "任务"`	全自动驾驶	自动
`/oh-my-claudecode:learner`	提取技能	–
`/oh-my-claudecode:ask-codex "问题"`	问 Codex	–
`/oh-my-claudecode:ask-gemini "问题"`	问 Gemini	–
`/skill list`	列出技能	–
`/skill search "关键词"`	搜索技能	–

06 混合使用策略

6.1 黄金组合

┌─────────────────────────────────────────────────────┐│                   项目生命周期                       │├─────────────────────────────────────────────────────┤│                                                     ││  [阶段 1: 规划] ──→ GSD                              ││  ├── /gsd:new-project                               ││  └── 生成 PROJECT.md, ROADMAP.md                    ││                                                     ││  [阶段 2: 开发] ──→ 混合                             ││  ├── GSD: 核心模块开发                               ││  │   └── /gsd:execute-phase N                      ││  └── OMC: Bug 修复 & 探索                           ││      └── /team 3:executor "fix..."                 ││                                                     ││  [阶段 3: 维护] ──→ OMC                              ││  ├── /team 2:executor "quick fix"                  ││  └── /oh-my-claudecode:learner                     ││                                                     │└─────────────────────────────────────────────────────┘

6.2 切换时机

从 GSD 切换到 OMC	从 OMC 切换到 GSD
需要快速验证想法	项目规模扩大
遇到未知的环境问题	需要严格的代码规范
小 Bug 太多，逐个修太慢	需要清晰的 Git 历史
需要跨模型智力支持	团队协作需要文档

07 最终推荐

选择 GSD，如果你：

✅ 负责中大型核心业务系统

✅ 对代码规范和 Git 提交历史有极度洁癖

✅ 需要每一步都能原子化回退

✅ 愿意承担前期规划时间，换取后期稳健

✅ 团队需要清晰的项目文档

选择 OMC，如果你：

✅ 从事需要快速验证 MVP 的中小项目
✅ 极度看重”开箱即用”和开发敏捷度

✅ 面对未知问题时需要大量探索

✅ 希望系统自动死磕验证直到成功

✅ 想要积累可复用的解决模式

两者并用，如果你：

✅ 是独立开发者，既要效率也要质量

✅ 项目处于快速迭代期，但已有一定规模

✅ 希望在日常 Bug 修复中沉淀知识

08 安装命令汇总

get-shit-done

# 安装npx get-shit-done-cc@latest# 验证/gsd:help

oh-my-claudecode

# 安装npm install -g oh-my-claude-sisyphus# 初始化omc setup# 启用团队模式 (编辑 ~/.claude/settings.json){  "env": {    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"  }}# 验证/team 1:executor "hello"

💡 提示： 两个工具并不互斥。你可以用 GSD 主导核心开发确保严谨架构，日常 Bug 排除时切到 OMC 进行快速处理。根据项目体量和当前阶段，灵活选择才是正解。

关于作者

致力于用 AI 探索人类认知的边界。关注我，一起看通往未来的路。

+ 关注