AI助手协同作战：别人比你快3倍的秘诀

⚠️ 90% 的 AI 助手使用者，都输在了「工作流」上

🔧 使用Superpowers + GStack 组合进行单个或多个并行任务进行开

🔍 先做个小测试

以下场景对号入座：

如果中了任何一条，这篇文章就是为你写的。

一、协同原则与角色分工

Superpowers 与 GStack 的互补关系

协作模式

Superpowers (流程铁律) + GStack (专业角色)

1. /brainstorming + /office-hours双重挑战假设（设计审批铁律 + 重新框架问题）

2. /writing-plans + /plan-eng-review工程化计划（规范计划 + 架构锁定）

3. /subagent-driven-development + /cso安全开发（隔离执行 + OWASP 审查）

4. /test-driven-development + /qa双重测试（TDD 铁律 + Playwright）

5. /verification-before-completion + /review深度审查（证据验证 + 多模型对抗）

6. /finishing-a-development-branch + /ship自动化发布（收尾流程 + 一键发布）

GStack 特有铁律

🔒 每一条铁律背后都是一个血泪坑。别省。

二、核心优化：Planning 阶段顺序

⚡ 这一部分是全文最重要的地方，没有之一。

大多数人的顺序 ❌

1. 用户提需求
2. 直接写代码
3. 做到一半发现不对
4. 重来

正确顺序 ✅

1. /office-hours（最先：挑战假设，重新框架问题）
2. /brainstorming（设计审批：想法 → 批准设计）
3. /plan-design-review（设计评审：UI/UX 评分）
4. /plan-eng-review（架构评审：锁定架构）
5. /writing-plans（写可执行计划）
6. /using-git-worktrees（创建隔离分支）

为什么 /office-hours 最先？

职责区分

• **/office-hours**：理解真正要解决什么问题（Pain vs Feature Request）
• **/brainstorming**：设计如何解决这个问题（方案 → 批准设计）

🎯 无论用户说得多么模糊或具体，/office-hours 都应该最先介入——确保我们在解决正确的问题，而不是错误地实现一个不存在的需求。

三、场景化技能组合

📌 怎么用这一段

先看「场景 0」找到你的场景类型，然后对号入座。

🔀 场景 0：你是哪种情况？

任务开始

需要规划？还是保留原来的 需要规划？

├── Yes → 安全敏感吗？

│   ├── Yes → 场景 11（安全功能）

│   └── No → 继续

│       ↓

│       UI 相关吗？

│       ├── Yes → 场景 8/9（UI 开发）

│       └── No → 继续

│           ↓

│           架构复杂吗？

│           ├── Yes → 场景 4/5（架构重构）

│           └── No → 新功能 → 场景 1/2/3

│

└── No → 是调试吗？

├── Yes → 场景 6/7（调试）

└── No → 是发布吗？

    ├── Yes → 场景 13/14（发布）

    └── No → 快速修复 → 场景 12

🚀 新功能开发：场景 1-3

如果你要做新功能，看这里。根据复杂度选重量级/精简版/极简版。

场景 1：新功能开发（完整流程）

适用场景：重要功能，需要设计+实现+审查+发布全流程

核心原则：Superpowers 铁律保证流程，GStack 专业角色保证质量

技能流程（重量级 12 步）：

步骤详解（按阶段分组）：

场景 2：新功能开发（精简版）

适用场景：中等复杂度，平衡效率

技能流程（8 步）：

哪些步骤省了？

场景 3：新功能开发（极简版）

适用场景：简单功能，快速迭代

技能流程（5 步）：

省了什么：

• /office-hours — 简单功能不需要挑战假设
• /writing-plans — 1-2 步的简单任务不需要详细计划
• /verification-before-completion — /qa 通过即证据
• /review — 小团队信任足够

🏗️ 架构重构：场景 4-5

系统级改动看这里。安全优先，11 步重量级，8 步精简版。

场景 4：架构重构（安全优先）

适用场景：系统级重构，涉及认证/支付等安全敏感代码，多团队协调

核心原则：安全从设计开始，持续审查，完整验证

技能流程（重量级 14 步）：

🔒 铁律：/ship 需在分支执行

步骤详解（按阶段分组）：

场景 5：架构重构（精简版）

适用场景：中等复杂度重构，不需要完整评审流程

技能流程（10 步）：

🐛 复杂 Bug 调试：场景 6-7

Bug 修不好看这里。根因分析优先，系统性排查。

场景 6：复杂 Bug 调试（系统性）

适用场景：Bug 根因不明确，涉及多个系统，之前的快速修复没起作用核心原则：根因分析优先于修复

技能流程（9 步）：

步骤详解（按阶段分组）：

场景 7：复杂 Bug 调试（精简版）

适用场景：Bug 根因相对明确，可以快速定位

技能流程（6 步）：

🎨 UI 功能开发：场景 8-9

做 UI 看这里。设计驱动，80 项审计防 AI slop。

场景 8：UI 功能开发（设计驱动）

适用场景：新 UI 功能，需要设计系统支持，需要检测 AI slop

技能流程（12 步）：

场景 9：UI 功能开发（精简版）

适用场景：简单 UI 修改，不需要完整设计系统

技能流程（6 步）：

📚 SDK/API 开发：场景 10

对外 API/SDK 看这里。开发者体验（DX）优先。

唯一原则：如果你的 API 用起来不舒服，没有人会用它。

适用场景：对外 API/SDK，需要优秀开发者体验核心原则：DX 从设计开始，实际测试验证

技能流程（11 步）：

💳 安全敏感功能：场景 11

支付/认证看这里。安全从设计开始，早期介入。

适用场景：支付系统、认证/授权、用户数据处理核心原则：安全从设计开始，早期介入，持续审查

技能流程（12 步）：

关键优化：/cso 在 /brainstorming 后立即介入，不是实现后

⚡ 快速 Bug 修复：场景 12

简单 Bug 看这里。根因明确，快速修复，5 步搞定。

适用场景：简单 Bug，根因明确，需要快速修复核心原则：简化流程但保持铁律

技能流程（5 步）：

为什么省略验证：/qa 通过即证据

🚢 版本发布：场景 13-14

发版看这里。/ship 必须在特性分支执行。

场景 13：重要版本发布（全面监控）

适用场景：重要版本发布，需要完整的发布流程和 post-deploy 监控

铁律注意：/ship 必须在特性分支执行，完成后需手动合并

技能流程（9 步）：

场景 14：快速版本发布（精简）

适用场景：小版本发布，不需要完整监控

铁律注意：/ship 必须在特性分支执行，完成后需手动合并

技能流程（4 步）：

⚡ 并行开发：场景 15

多任务并行看这里。独立任务并行处理，汇总后统一发布。

适用场景：多个独立功能同时开发，需要并行执行核心原则：独立任务并行处理，汇总后统一发布

技能流程（9 步大纲，内部包含子步骤）：

1. /office-hours：全局需求挑战
2. /brainstorming：全局设计
3. /writing-plans：全局计划
4. /dispatching-parallel-agents：并行分发 —— 仅限独立任务，防止隐藏依赖
5. 每个 agent 独立执行： 5a. /using-git-worktrees：每个任务创建独立分支 5b. /subagent-driven-development：独立执行 5c. /test-driven-development：TDD 铁律 5d. /cso（如涉及安全）：安全审查 5e. /review + /qa：审查 + 测试 5f. /verification-before-completion：验证 5g. /finishing-a-development-branch：各分支收尾
6. 汇总后：
7. /ship：分别在特性分支执行
8. /canary：金丝雀监控
9. /benchmark：性能基线

铁律注意：/ship 必须在特性分支执行，汇总各分支后分别执行 /ship，再合并

四、四大优化总结

优化 1：Planning 阶段顺序

优化 2：安全介入时机

优化 3：版本分级

优化 4：审查精简

五、铁律总结

六、常见错误与正确做法

📌 记住：流程不是束缚，而是让你更快到达目的地的地图。每一条铁律背后都是一个血泪坑，别省。