用 Claude Code 写代码的时候，总觉得底部空空的，缺点什么。看到别人的终端底部有 Git 分支、文件变更、模型名，一整条信息栏，既实用又好看。研究了一下，其实就是 tmux 状态栏，配置不复杂，记录一下完整过程。

GSD 不是脚手架，而是一套给 AI 编程工具用的规格驱动工作流。它的目标很明确：把长任务拆成多个短上下文，降低 context rot，让规划、执行、验证都可追踪。

GSD 解决什么问题

典型 AI 编程失效路径是：

• 一个会话里同时做需求澄清、方案设计、编码、验收
• 上下文越滚越大，后半段质量下降
• 计划过大，执行不可验证
• 写完代码，但没有可靠验收闭环

GSD 的做法是把流程拆成阶段，并把状态落盘到 .planning/。核心文件包括：

• PROJECT.md
• REQUIREMENTS.md
• ROADMAP.md
• STATE.md
• config.json
• phases/

适合需要跨会话推进、分阶段交付、保留验收记录的项目。

支持的运行时

• Claude Code
• Codex
• Gemini CLI
• OpenCode

命令前缀不同：

• Claude Code / Gemini: /gsd:help
• OpenCode: /gsd-help
• Codex: $gsd-help

安装

最简单的方式：

npx get-shit-done-cc@latest

非交互安装：

npx get-shit-done-cc --claude --global
npx get-shit-done-cc --codex --global
npx get-shit-done-cc --gemini --global
npx get-shit-done-cc --opencode --global

只装当前项目，把 --global 换成 --local。

安装完成后验证：

# Claude Code / Gemini
/gsd:help

# OpenCode
/gsd-help

# Codex
$gsd-help

标准工作流

完整链路如下：

/gsd:new-project
/clear
/gsd:discuss-phase 1
/gsd:ui-phase 1
/gsd:plan-phase 1
/gsd:execute-phase 1
/gsd:verify-work 1
/gsd:ui-review 1

非前端阶段可跳过 ui-phase 和 ui-review。

工作流流程图

flowchart TD
    A["/gsd:new-project
初始化项目上下文"] --> B["/gsd:discuss-phase N
锁定实现偏好"]
    B --> C{"是否包含前端/UI?"}
    C -->|是| D["/gsd:ui-phase N
生成 UI-SPEC"]
    C -->|否| E["/gsd:plan-phase N
研究 + 规划 + 校验"]
    D --> E
    E --> F["/gsd:execute-phase N
按 wave 执行计划"]
    F --> G["/gsd:verify-work N
人工验收"]
    G --> H{"验收是否通过?"}
    H -->|否| I["生成修复计划"]
    I --> F
    H -->|是| J{"是否还有下一阶段?"}
    J -->|是| B
    J -->|否| K["/gsd:audit-milestone"]
    K --> L["/gsd:complete-milestone"]

核心命令表

补充命令表

阶段职责表

Demo 1：新建 Todo Web App

目标：

• Next.js + TypeScript + SQLite
• 单用户
• 支持新增、完成、删除

执行顺序：

/gsd:new-project
/gsd:discuss-phase 1
/gsd:ui-phase 1
/gsd:plan-phase 1
/gsd:execute-phase 1
/gsd:verify-work 1

new-project 输入示例：

做一个 Todo Web App。
技术栈是 Next.js + TypeScript + SQLite。
第一版不做登录，只做单用户。
目标是完成增删改查闭环，移动端可用。

discuss-phase 1 输入示例：

页面保持高信息密度，不做营销风格设计。
列表项支持快速完成和删除。
空状态必须给明确操作提示。
移动端点击区域要足够大。

plan-phase 1 之后检查：

• 每个 plan 范围足够小
• 每个 plan 都有明确 verify 步骤

verify-work 1 检查项：

1. 新建待办是否成功
2. 状态切换是否即时生效
3. 删除是否可恢复或至少行为一致
4. 刷新后数据是否存在
5. 移动端交互是否误触

Demo 2：在现有项目中追加功能

/gsd:map-codebase
/gsd:new-project
/gsd:discuss-phase 1
/gsd:plan-phase 1
/gsd:execute-phase 1
/gsd:verify-work 1

map-codebase 会生成：

• STACK.md
• ARCHITECTURE.md
• STRUCTURE.md
• CONVENTIONS.md
• TESTING.md
• INTEGRATIONS.md
• CONCERNS.md

后续规划会直接基于现有结构。

小需求可直接用：

/gsd:quick

例如：

为博客新增文章搜索页，支持标题和摘要匹配，保持现有站点风格。

适用场景：

• 小功能
• bug 修复
• 配置改动
• 一次性维护任务

最值得先掌握的命令

• /gsd:help
• /gsd:new-project
• /gsd:discuss-phase
• /gsd:plan-phase
• /gsd:execute-phase
• /gsd:verify-work
• /gsd:map-codebase
• /gsd:quick

命令体系思维导图

mindmap
  root((GSD))
    初始化
      /gsd:new-project
      /gsd:map-codebase
    阶段推进
      /gsd:discuss-phase
      /gsd:ui-phase
      /gsd:plan-phase
      /gsd:execute-phase
      /gsd:verify-work
      /gsd:ui-review
    导航恢复
      /gsd:progress
      /gsd:resume-work
      /gsd:pause-work
    快速任务
      /gsd:quick
    路线图调整
      /gsd:add-phase
      /gsd:insert-phase
      /gsd:remove-phase
    配置
      /gsd:settings
      /gsd:set-profile
    收尾发布
      /gsd:audit-milestone
      /gsd:complete-milestone

配置建议

配置文件是 .planning/config.json。

mode

• interactive: 默认，适合大多数项目
• yolo: 自动化更强，适合熟练用户

granularity

• coarse
• standard
• fine

阶段越复杂，越适合 fine。

model_profile

• quality
• balanced
• budget
• inherit

建议：

• 原型期：budget
• 常规开发：balanced
• 关键阶段：quality

workflow 开关

• workflow.research
• workflow.plan_check
• workflow.verifier
• workflow.nyquist_validation
• workflow.ui_phase
• workflow.ui_safety_gate

不熟悉领域时，建议保持默认；只做快速原型时再酌情关闭。

典型误区

跳过 discuss-phase

常见结果不是功能错误，而是实现风格偏离预期。AI 会用默认判断填满灰区。

phase 切太大

如果一个阶段同时覆盖数据库、API、前端、权限、测试、部署，plan 往往会失真。GSD 不是拿来吞掉模糊范围的。

不做 verify-work

测试通过不等于功能完成。尤其是交互、空状态、错误流程、移动端兼容这类问题，必须人工验收。

老项目不跑 map-codebase

这会增加“风格不一致”和“破坏现有结构”的概率。

结论

GSD 的价值在于把 AI 编程从单轮 prompt 提升为阶段化工作流，更适合多阶段任务和持续交付。

如果你的项目已经开始出现需求拆分、阶段推进、跨会话恢复、验收闭环这些问题，GSD 值得直接上手。

OpenClaw 社区先做到了多会话协作，Anthropic 直接把它做成了官方功能。 这不是一个小更新，而是 Claude Code 的工作方式从“单兵作战”升级为“团队协作”。这篇文章带你快速上手 Agent Teams：什么时候值得用、怎么开、怎么配、怎么管、哪里会踩坑。

先说结论：这不是“更强的 Sub-agent”，而是“真正的团队”

以前你只有一个会话，所有事情顺序完成：先研究、再改代码、再写测试。Agent Teams 出现后，一个 lead 负责拆解任务，多个 teammate 并行协作，还能互相交流、共享任务列表。

更直观的对比：

• Sub-agents：像派一个助理去拿答案，回来报告。
• Agent Teams：像把一群专家放进同一个项目里协作。

如果任务需要互相沟通、互相校验，Agent Teams 才真正发挥价值。

什么时候该用？什么时候是过度设计？

适合用的场景（并行能带来明显收益）：

• 研究/评审：不同队友分别看代码、查资料、提风险点。
• 跨层开发：一个队友做前端，一个队友做后端，一个队友写测试。
• 调试：多条假设并行验证，避免单一路径走歪。

不适合用的场景：

• 强顺序依赖（第二步必须等第一步完成）。
• 同文件高频编辑（容易覆盖冲突）。
• 很小的任务（协调成本比收益更高）。

一句话：能拆成独立任务的，用团队；必须串行的，用单人或 sub-agent。

如何启用 Agent Teams（30 秒完成）

Agent Teams 目前是实验功能，默认关闭。你有两种方式开启：

方式 1：修改 settings.json（推荐，持久化）

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

方式 2：环境变量（临时）

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

启用后，Claude Code 会识别团队指令。官方文档可参考：
Agent Teams 文档

启动团队：最重要的是“清晰的角色分工”

你不需要特殊语法，只要给 lead 一个清晰任务和分工提示。

示例（高质量提示）：

我在设计一个 CLI 工具，扫描代码里的 TODO 并生成报告。创建一个 agent team：

• teammate A：从用户体验角度给出功能优先级
• teammate B：提出技术架构与实现路径
• teammate C：以“反对者”视角挑出风险与替代方案

好的 prompt = 明确角色 + 独立任务 + 预期输出。这一步越清楚，成本越低。

运行中如何控制团队

当团队跑起来后，必须知道 3 个关键操作：

1. 直接和任意队友对话

• In-process 模式：Shift + 上/下 切换队友
• Split-pane 模式：点击对应 pane（需要 tmux 或 iTerm2）

2. Delegate mode（防止 lead 抢活）
   有时候 lead 会“忍不住自己干”。开启 delegate mode 后，lead 只能协调：分配任务、发消息、管理列表。

• 切换快捷键：Shift + Tab

3. 任务分配与回收

• 可由 lead 指派，也可被队友自动领取
• 队友完成后建议主动“汇报 + 标记完成”

Agent Teams vs Sub-agents：如何选？

决策问题就一个：是否需要队友之间的沟通？

• 不需要互相沟通，只要结果 → Sub-agents（便宜、快、适合单点任务）
• 需要协作、互相对齐 → Agent Teams（贵、但能处理复杂系统）

成本提醒：Agent Teams 可能是 sub-agent 成本的数倍，请在“收益明显”时使用。

最佳实践：少走弯路的 7 条经验

1. Spawn prompt 要细：不要假设队友知道你的历史上下文。清楚写清目标、范围、输入/输出。
2. 任务粒度适中：能在 15–40 分钟内完成并交付。
3. 避免同文件编辑：同一文件交给一个队友，减少合并冲突。
4. 定期 check-in：每 15–20 分钟主动询问进展，避免跑偏太久。
5. 先做“研究/评审”试水：最容易看到并行价值。
6. 任务列表清晰：拆成可验收的子任务，完成后立刻标记。
7. 用角色命名：如 frontend, backend, test, review，便于协作。

当前已知限制（避免误踩）

• 会话恢复不支持：/resume 或 /rewind 不会恢复队友。
• 任务状态偶尔延迟：完成了但未标记，需手动更新或提醒。
• 一个会话只能有一个团队：不能创建多个团队或转移 lead。
• Split-pane 有终端限制：仅支持 tmux 或 iTerm2。

Key Takeaways

• Agent Teams 适合并行协作，不适合顺序强依赖任务。
• 清晰的角色与任务拆解是效率与成本的关键。
• Delegate mode 可以让 lead 专注管理，不再自己动手。

这是一位名为 Boris 的作者在推文中整理的使用心得。他表示这些技巧来自 Claude Code 团队的内部实践，同时也强调：没有唯一正确的用法，每个人都应该根据自己的工作流不断试验与调整。

原文地址：https://x.com/bcherny/status/2017742741636321619

1) 并行：3–5 个 worktree 同时跑

团队的 No.1 技巧：同时开 3–5 个 git worktree，每个 worktree 对应一个 Claude 会话。上下文更干净、并行更高效。

实践建议：

• 给 worktree 起名并设 alias（如 za/zb/zc）
• 单独开一个“分析 worktree”用于日志/查询

2) 复杂任务先进入 Plan Mode

先把计划做扎实，再执行才容易一枪到位。

一些团队成员会：

• 让一个 Claude 写计划
• 再让另一个 Claude 以“资深工程师视角”审核

一旦走偏就回到 Plan Mode 重规划，不要硬推。

3) 把 CLAUDE.md 当成自我修正系统

每次纠正 Claude 后，都补一句：

“更新 CLAUDE.md，避免下次再犯。”

持续迭代后，Claude 的错误率会明显下降。

4) 把重复劳动写成 Skill / Slash Command

做超过一天的事，就值得自动化。

团队建议：

• /techdebt：会话末尾清理重复代码
• 自动同步 Slack / Asana / GDrive / GitHub 上下文
• 构建“数据工程师风格”的 agent 写 dbt / review / 测试

5) 让 Claude 自己修 Bug

不要过度指导，把问题喂给它即可：

• 贴 Slack bug 线程说 “fix”
• 或直接说 “修复 failing CI tests”
• 把 Docker logs 直接贴进去

6) Prompt 进阶技巧

• 让 Claude 审你：
  “Grill me on these changes, don’t PR until I pass.”
• 不满意就推翻：
  “Knowing everything you know now, scrap this and implement the elegant solution.”
• 先写清楚 spec：越具体越少返工

7) 终端与环境配置

团队喜欢 Ghostty（同步渲染、24-bit 色彩、完整 Unicode）。

提升效率的小习惯：

• /statusline 显示上下文与分支
• 终端 tab 颜色区分任务
• tmux 一任务一 tab
• 语音输入（Mac 双击 fn）提示词更完整

8) Use Subagents

在需求结尾加一句 “use subagents”，Claude 会开多个子任务并行。

优点：主上下文更干净、并行探索更快。

9) 用 Claude 做数据分析

团队把 BigQuery CLI 直接接到 Claude Code，6 个月没写 SQL。

只要有 CLI / MCP / API 的数据库都能用同样方法接入。

10) 用 Claude 学习新知识

• 在 /config 开启 Learning / Explanatory 模式
• 让 Claude 生成 HTML 讲义
• 让 Claude 画 ASCII 架构图
• 做“间隔复习”学习 skill：你讲理解，Claude 追问补全

总结：Claude Code 的价值不在单次对话，而在于工作流的长期迭代。并行化、计划驱动、规则沉淀与技能化工具，是提升效率的核心。