AI 编码三剑客实战示例集

你的 SaaS 应用收到用户反馈"想要暗黑模式"。你想确认这真的是用户痛点，并在半天内上线。

1. /office-hours      # 挑战需求：是真痛点还是伪需求？
2. /autoplan          # CEO/Design/Eng 三视角联审
3. （Agent 实现代码）
4. /qa https://localhost:3000   # 真实浏览器测试
5. /review            # 自动 lint + 找隐藏 bug
6. /ship              # 跑测试 + 推 PR
7. /land-and-deploy   # 合并 + 部署 + 健康检查

• 1 个 MR，包含 ~600 行代码（CSS 变量 + 1 个 toggle 组件）
• 9 个新增单元测试，2 个 E2E 测试（通过 /qa 自动生成的回归测试）
• 截图证据：明暗两种模式下的 5 个核心页面
• 部署后 30 分钟监控数据（/canary 自动跑）

/office-hours 让你避免做了"用户说要的"而错过"用户真正需要的"。本例中砍掉了 60% 范围（不做主题编辑器），但解决了 90% 痛点。

登录页转化率太低，老板让你"做得更现代一点"。你不知道具体方向，想看几个版本。

1. /design-shotgun      # AI 一次生成 4-6 个 mock，浏览器对比
2. （选 1-2 个喜欢的，让 AI 二次迭代）
3. /design-html         # 把选中 mock 转成生产级 HTML/CSS
4. /design-review       # 设计师视角检测 AI Slop
5. /qa /login           # 真实浏览器测全流程
6. /benchmark           # 对比改版前后 Core Web Vitals
7. /ship

• ~/.gstack/taste/ 下学到的偏好向量（下次自动应用）
• shipping.html 生产级 HTML（30KB，零依赖，Pretext 计算布局）
• 对比 metric：FCP 从 1.8s → 1.2s，转化率监测埋点

/design-shotgun 的 taste memory 跨项目累积。你做 3 个项目后 AI 就懂你"喜欢留白、讨厌渐变、能接受非对称布局"。

客服群里用户报告"支付按钮点了没反应"，发生概率约 5%，无法稳定复现。

1. /investigate                  # 系统化追根因（铁律：未调查不修）
2. /freeze src/payment           # 锁定 Agent 只能改这个目录
3. /careful                      # 危险命令前警告
4. （Agent 提出 3 个假设并验证）
5. /qa https://staging/checkout  # 复现验证
6. /review                       # 修复合规性审查
7. /ship --hotfix
8. /land-and-deploy --skip-canary --priority urgent

火急情况下也千万别跳过 /investigate。它最多花你 5 分钟，但避免你"瞎修"出新 bug 的可能性。3 次失败修复后会自动停止——这就是反"AI 越改越乱"的护栏。

产品要做"应用内通知中心"。后端 API + 前端铃铛 + 列表页 + 已读状态。

• 1 个 PR，~2400 行代码 / 11 文件
• 新增 9 个单元测试 + 5 个 E2E 测试
• OWASP 扫描报告（/cso 输出，0 高危）
• README + ARCHITECTURE.md 自动同步
• Sentry & Datadog 仪表板监控（/canary 部署后 30 分钟）

整套流程里 /autoplan 是最值钱的——它一键完成 CEO/设计/工程三视角联审，把决策点打包到一次 AskUserQuestion，省掉手动串联 60% 时间。

金融工具上线前要做安全审计。预算只够 1 天，不够请第三方。

/cso                              # OWASP Top 10 + STRIDE 威胁建模
/cso --focus "auth,payment"       # 聚焦认证和支付模块
/freeze .                         # 防止扫描中误改任何文件
/codex --mode adversarial         # 第二意见（GPT 视角对抗审查）

/cso 的零噪音设计很重要——传统扫描器一次给你 200 条，开发者直接关掉。这里只给 8/10 以上 + 附带具体利用代码 + 验证步骤。每条都是真问题。

你刚入职，要重构 5 年前写的鉴权模块。代码 2000 行，没文档，原作者已离职。

1. cd legacy-app
2. openspec init                          # 初始化 openspec/ 目录
3. # 编辑 openspec/config.yaml 写明技术栈和约束
4. /opsx:explore "鉴权模块当前是怎样的？"   # AI 先帮你读代码反推 spec
5. /opsx:propose refactor-auth             # 生成 4 件套
6. # 仔细 review proposal/design.md，纠正 AI 的误读
7. /opsx:apply                             # 按 tasks.md 重构
8. /opsx:archive refactor-auth             # 归档进 specs/auth/

• openspec/specs/auth/ 包含完整鉴权规范（重构后的目标态）
• openspec/changes/archive/2026-05-XX-refactor-auth/ 完整变更历史
• 新代码 + 1 个 migration script（兼容旧 cookie 格式）

OpenSpec 在 brownfield 的真正威力：它把"反向工程现有代码"变成了 spec。半年后你或同事再读这个 specs/auth/，能秒懂"这个项目的鉴权约定是什么"。

前端组催你提供"用户消息批量已读"接口。你想先把 contract 敲定，避免后期反复改。

/opsx:propose api-mark-messages-read

# 生成的 specs/messages/spec.md 中明确：
# - 请求方法 POST /api/messages/read
# - 请求体 { ids: string[] }（max 100）
# - 响应 200 { updated: number }
# - 401 未登录、403 无权限他人消息、422 参数错误
# - 幂等性：重复调用不报错
# - 边界：ids 为空返回 200 updated:0

# 把 spec 链接发给前端
# 前端 OK 后再
/opsx:apply

API 设计阶段就把 spec commit 到 repo，前端能在 repo 里看到、commit 历史里看到、CI 中可校验（如果你接 OpenAPI/JSON Schema）。比 Figma/飞书文档"漂浮"在外面强多了。

3 人小队要做支付重构。每人负责一块，但需要保持 API 和数据约定一致。

# 切换到 expanded profile（多人协作模式）
openspec config profile expanded
openspec update

# 产品负责人先开 propose
/opsx:propose payment-v2

# review proposal/design 之后 commit + push
git add openspec/changes/payment-v2 && git commit && git push

# 工程师 A：
/opsx:new sub-task-1-stripe-integration

# 工程师 B（在 A 完成 sub-task-1 后）：
/opsx:continue   # 检查 tasks.md 进度，接着做 sub-task-2

# 工程师 C：
/opsx:ff sub-task-3-refunds  # 快进到自己负责的部分

# 周末整体验收：
/opsx:verify     # 跨 sub-task 一致性校验
/opsx:bulk-archive   # 全部归档

expanded profile 是 OpenSpec 的隐藏强力技能，专为多人协作设计。/opsx:continue 让接手者无需读你的 chat 记录就能精确知道做到哪了。

金融行业项目，每个变更都需要"为什么改、谁批准、改了什么"的完整追溯。审计员可能 6 个月后来抽查。

# 在 openspec/config.yaml 强制规则
rules:
  proposal:
    - 必须包含 "Compliance Impact" 章节
    - 必须列出 affected regulations (SOX, PCI-DSS 等)
    - 必须有 reviewer 签字字段
  archive:
    - 归档时附带 audit trail (谁 review、何时 approve)

# 每个变更：
/opsx:propose update-transaction-limits
# proposal 自动包含合规章节
# CISO 在 proposal.md 中签字注明 approved
git commit  # 留下 git history
/opsx:apply
/opsx:archive  # 归档，永久保留

审计员 6 个月后问"为什么 5 月 12 号改了交易限额？"——你打开 openspec/changes/archive/2026-05-12-update-transaction-limits/，proposal/design/tasks 一目了然，谁批准、什么风险评估都在。这是其他工具完全做不到的。

要把 MySQL 5.7 迁到 PostgreSQL 16。改动会涉及 50+ 文件，可能跨越几周。

# 总 proposal
/opsx:propose migrate-mysql-to-postgres

# 拆 5 个 sub-changes
/opsx:propose migrate-step-1-schema-translation
/opsx:propose migrate-step-2-orm-update
/opsx:propose migrate-step-3-query-rewrite
/opsx:propose migrate-step-4-data-migration
/opsx:propose migrate-step-5-cleanup-mysql

# 每个 step 独立可逆，独立 ship
# 第 1 step:
/opsx:apply migrate-step-1-schema-translation
# 测试通过后归档，但保留总 proposal
/opsx:archive migrate-step-1-schema-translation

大型迁移最怕"做到一半被打断"。OpenSpec 的子提案让每一步都独立成 PR、独立可回滚。即使停 2 周再继续，也能精确回到原点。

你要写一个跨平台 CLI 工具：参数解析 + 子命令 + 配置文件 + 彩色输出 + 单元测试。

You: 我想做一个叫 myctl 的命令行工具，需要支持
     init/add/remove/list 4 个子命令，配置文件读 ~/.myctl.yaml
     用 TypeScript + Bun 写

# 自动触发顺序（你不用手动 /xxx）：
1. brainstorming           — 问 6 个问题挑战需求
2. writing-plans           — 拆成 14 个 2-5 分钟的 task
3. （你说 "go" 后）
4. using-git-worktrees     — 创建 isolated worktree
5. subagent-driven-development — 每个 task 派一个新 subagent
6. test-driven-development — 每个 task 强制先写 test
7. requesting-code-review  — 任务间自动 review
8. finishing-a-development-branch — 完成后选 merge / PR

[22:30] brainstorming: 14 个澄清问题完成
[22:35] writing-plans: 14 个 task 计划已写入 plan.md
[22:36] You: go
[22:36] git worktree add ../myctl-feat feature/init
[22:37] Subagent-1: task-1 (init 子命令)
        TDD RED: 写测试 init creates ~/.myctl.yaml ... ✗ FAIL
        TDD GREEN: 实现 src/commands/init.ts ... ✓ PASS
        review: 通过
[22:42] Subagent-2: task-2 (add 子命令)
[...每个 subagent 4-6 分钟...]
[01:18] task-13 完成
[01:24] task-14 完成（文档）
[01:25] finishing-branch: 测试 47 个全过，提示是否 PR
[早上 8 点]
You: 看见 plan 100% 完成，发个 PR 吧
AI: 已开 PR #42，等你 review

这是 Superpowers 的核心红利。其它工具的 Agent 主流程是"边写边问"，1 小时后会偏离原计划。Superpowers 的 subagent 每个跑完即退出，主 Agent 只负责调度，不会被污染上下文。

测试同事报"系统偶尔会显示空白页面"，每天发生 1-3 次，重启服务就好。你怀疑 race condition 但找不到。

You: 帮我修这个偶发空白页 bug
     测试日志在 logs/2026-05-15-bug.log

自动触发：
1. systematic-debugging   — 4 阶段方法论
2. （reproduce 阶段）condition-based-waiting 找出触发条件
3. （isolate 阶段）root-cause-tracing 反向追踪数据流
4. （fix 阶段）defense-in-depth 多层防御
5. verification-before-completion — 必须证明已修

systematic-debugging 的 4 阶段顺序不可跳跃。新手最爱直接跳到 FIX，结果"修了一处坏了三处"。这个 skill 强制你必须先复现、再隔离、再修。

有个 800 行的 calculatePricing 函数，已经多次改坏过。你想拆成 5 个小函数，但不能改任何行为。

You: 重构 calculatePricing，要求行为完全不变

自动触发：
1. test-driven-development
   先生成 characterization tests（覆盖现有所有行为）
   测试必须 100% 通过 = 拿到"不变量"
2. writing-plans
   拆成 5 个 refactor task
3. subagent-driven-development
   每个 subagent 拆一块，跑特征测试，不通过则回滚

TDD 在重构里是救命稻草。先把现有行为冻结成测试，重构每一步都验证不变。这是手工重构很难做到的纪律。

sprint 还剩 5 个小 feature：邮件模板、导出 CSV、深色 favicon、404 页、健康检查端点。彼此独立。

You: 并行做这 5 个 feature
     [feature 1-5 描述]

自动触发：
1. dispatching-parallel-agents
   - 检测 5 个任务无依赖
   - 用 git worktree 创建 5 个分支
   - 派 5 个 subagent 并行执行
2. 每个 subagent 内部走 brainstorming → writing-plans → TDD
3. 完成后主 Agent 汇总结果，5 个分支独立 PR

串行执行预估 6 小时，并行 4 个 subagent + 主 Agent 汇总：1.8 小时完成。Token 用量增加 4.5 倍但时间省 3.3 倍。

使用前确认任务真的独立。如果 task 2 依赖 task 1 的某个 util 函数，并行会失败。Superpowers 会先做依赖检测，但有时检测不出语义层耦合。

要实现 Levenshtein 距离 + 余弦相似度 + Jaro-Winkler 三种算法，用于文档去重。学术正确性优先。

You: 实现 3 种文本相似度算法，用 TDD

# Superpowers 强制 TDD 流程：
# 对每个算法都跑 RED-GREEN-REFACTOR：

[RED]
- 写测试：levenshtein("kitten", "sitting") === 3
- 跑测试 → ✗ FAIL（函数还不存在）

[GREEN]
- 写最少代码让测试通过（即使是 hardcoded）
- 跑测试 → ✓ PASS

[REFACTOR]
- 把硬编码改成真正的 DP 算法
- 加更多测试用例
- 跑测试 → ✓ PASS

# 三个算法 × 3 个循环 = 9 步骤

算法实现是 TDD 最有价值的领域之一——测试用例就是算法的形式化定义。Superpowers 的硬性 TDD 在这种场景下是优势而非负担。

给 SaaS 加"团队协作工作区"功能。需要：API 设计、UI 设计、可审计文档、代码质量、线上稳定。

这是生产项目最强组合。每个工具发挥自己的强项，互不重复：
① gstack 管"做对的产品"
② OpenSpec 管"对齐到 spec"
③ Superpowers 管"把代码做对"

纯后端服务（消息队列、数据 pipeline、定时任务）。要审计追溯、要 TDD，但用不到浏览器 QA 和产品挑战。

# 1. OpenSpec 设计 spec（合规审计）
/opsx:propose pipeline-v2-data-encryption

# 2. CISO review proposal/design.md，签字
git commit -m "approved by CISO 2026-05-20"

# 3. Superpowers 拆 task + TDD 实现
You: 按 tasks.md 实现

[自动激活]
- writing-plans 把 OpenSpec tasks.md 进一步拆细
- subagent-driven-development 长时执行
- test-driven-development 每个 task 强制 TDD
- verification-before-completion 验证

# 4. 不需要 gstack（无 UI）
# 5. 归档
/opsx:archive pipeline-v2-data-encryption

C2 配方省掉 gstack是合理的——纯后端服务没有视觉、没有浏览器流，gstack 的 /qa /design-* 都用不上。但如果你的后端服务对外暴露了 admin UI 或 metric dashboard，那还是建议加上 gstack。

你一个人做一个小工具或独立项目。需要快速 ship，需要纪律但不需要团队对齐文档。

# 1. 需求挑战（gstack）
/office-hours

# 2. 计划 + 实现（Superpowers）
[自动触发 brainstorming → writing-plans → 
 subagent-driven-development → TDD]

# 3. QA + 发布（gstack）
/qa https://staging
/review
/ship
/land-and-deploy

# 4. 复盘（gstack）
/retro

个人项目里 OpenSpec 的 ROI 偏低：你自己脑子里清楚为什么改、改了什么。spec 文档只是给"未来的你"看，但小项目通常活不到那时候。

这是独立开发者最佳组合。简洁、快速、有质量保证。如果项目从 PoC 变成认真做的产品，再加上 OpenSpec。

给运营做的报表后台。功能简单（CRUD + 图表），但每次改动要让其他运营知情，部署要稳定。

# 1. spec 文档（OpenSpec）让运营了解
/opsx:propose add-monthly-report-export

# 2. 直接让 Agent 实现（不强制 TDD，运营工具改动太频繁）
You: 按 tasks.md 实现，写关键单元测试就行

# 3. UI 用 gstack 改进
/design-shotgun
/design-html

# 4. 测试 + 发布
/qa
/review
/ship
/opsx:archive

内部工具的改动节奏快、需求漂移大。跳过 Superpowers 的 TDD 强制是合理选择——每次都强制 RED-GREEN-REFACTOR 反而拖慢进度。但 spec（让运营了解）和 QA（避免线上卡死）不能省。

支付服务挂了 30 分钟，已恢复但根因不明。要在 1 小时内做出 hotfix，且必须有完整事故记录给老板和合规。

# T+0:00  事故发生 → 已快速回滚

# T+5:00  开 incident spec（OpenSpec）
/opsx:propose incident-2026-05-20-payment-outage

# T+10:00 系统化调查（gstack）
/investigate
[8 分钟后定位到 redis 连接池耗尽]

# T+25:00 Superpowers TDD 实现修复
You: 按 investigate 输出实现 hotfix
[Superpowers: 先写复现 race 的测试 → 修复 → 验证]

# T+45:00 安全审查（gstack）
/review --hotfix
/cso --focus "auth,payment"

# T+50:00 发布
/ship --hotfix
/land-and-deploy --priority urgent

# T+58:00 监控
/canary --duration 30m

# T+次日   归档
/opsx:archive incident-2026-05-20-payment-outage
# 含 RCA、timeline、修复细节、防御措施

• Timeline: 每分钟事件（来自 git commits + monitoring）
• Root Cause: /investigate 输出
• Fix: 实际改动（含 TDD 写的测试）
• Verification: /qa /canary 截图 + 监控数据
• Prevention: 防止再次发生的措施

事故响应中"快"和"稳"必须同时——三件套刚好对应这两个维度：gstack 给你快速调查 + 部署，Superpowers 给你 TDD 验证防止"修出新 bug"，OpenSpec 给你完整事故记录。