03_gstack技能系统：21个核心Skill与分层架构

03_gstack技能系统：21个核心Skill与分层架构

前言

我见过很多团队把AI助手当"万能钥匙"用——什么问题都问，什么任务都交。结果呢？AI输出的东西要么太泛、要么太浅、要么缺胳膊少腿。

问题不在AI不够聪明，在于没有给它足够的角色设定和上下文。

gstack的核心设计就是解决这个问题：21个专门Skill，每个Skill对应一个明确的开发角色，形成四层金字塔架构。

今天我来拆解这个技能系统，看看它是怎么把一个通用AI变成"虚拟专家团队"的。

一、技能系统的设计哲学

1.1 为什么需要专门Skill

通用AI的问题不是能力不足，是上下文不足。

通用AI的困境： 用户: "帮我看看这个支付模块" | v AI思考: "用户要我审查代码。那我按照审查的套路来..." | v 输出: "发现了一些问题：变量命名不规范、缺少注释..." | v 问题: "这些是代码风格问题，不是真正的业务风险" 资深工程师审查时在想什么： - 这个支付逻辑有没有并发问题？ - 事务回滚是否完整？ - 超时重试机制有没有？ - 幂等性如何保证？ - 异常情况下资金会不会丢失？

gstack的Skill不是简单地说"你现在是代码审查员"，而是加载这个角色所需的全部上下文——审查要点、历史案例、业务逻辑理解。

1.2 Skill vs 通用提示词

通用提示词 vs 专门Skill： 【通用提示词】 "你是一个资深代码审查员，请审查以下代码..." - 每次都要重复背景信息 - 没有项目上下文 - 没有历史经验积累 【gstack Skill】 /review - 自动加载项目架构图 - 自动加载历史审查案例 - 自动识别模块间的依赖关系 - 自动检查安全/性能/并发要点 - 自动关联业务需求文档

这就是为什么同一个命令，在不同项目里能给出完全不同的审查重点——Skill加载的是项目级的上下文，不是通用模板。

二、四层架构全景图

2.1 架构总览

gstack技能系统四层架构： +----------------------------------------------------+ | | | [产品规划层] | | /plan-ceo-review /plan-eng-review | | /plan-design-review /design-consultation | | /office-hours | | | | 定位: "做什么？怎么做？设计对吗？" | | | +----------------------------------------------------+ | v +----------------------------------------------------+ | | | [质量保障层] | | /review /design-review | | /qa /qa-only | | /qa-design-review | | | | 定位: "代码对吗？功能能用吗？设计合理吗？" | | | +----------------------------------------------------+ | v +----------------------------------------------------+ | | | [发布运营层] | | /ship /document-release | | /retro | | | | 定位: "怎么上线？文档同步吗？效果如何？" | | | +----------------------------------------------------+ | v +----------------------------------------------------+ | | | [基础设施层] | | /browse /setup-browser-cookies | | /gstack-upgrade /conductor | | ... | | | | 定位: "工具支撑，能力扩展" | | | +----------------------------------------------------+

2.2 每层职责定义

层级职责矩阵： +------------+------------------------------------------+ | 层级 | 职责 | +------------+------------------------------------------+ | 产品规划层 | • 验证需求是否值得做 | | | • 设计技术方案和架构 | | | • 评估设计质量 | | | • 产品质疑与重构 | +------------+------------------------------------------+ | 质量保障层 | • 代码审查（偏执级别） | | | • 功能测试（真实浏览器） | | | • 设计审查（AI slop检测） | | | • 纯报告模式（不修复） | +------------+------------------------------------------+ | 发布运营层 | • 一键发布（自动化CI/CD） | | | • 文档同步（代码文档一致性） | | | • 工程回顾（数据驱动分析） | +------------+------------------------------------------+ | 基础设施层 | • 浏览器自动化 | | | • 会话管理（Cookie/上下文） | | | • 自我升级 | | | • 并行会话管理 | +------------+------------------------------------------+

三、产品规划层深度解析

3.1 CEO模式：/plan-ceo-review

这是gstack最独特的设计——让AI扮演CEO来审视产品需求。

/plan-ceo-review 核心能力： 角色设定： - 你是一位做过从0到1产品的创始人 - 你见过太多团队在错误的方向上狂奔 - 你擅长问"我们真的应该做这个吗？" 核心问题框架： 1. 用户真正的痛点是什么？ 2. 不做这个功能会怎样？ 3. 这个功能如何衡量成功？ 4. 有什么更简单的解决方案吗？ 10星级产品思考： 案例对比： 用户需求: "用户要能上传照片到商品详情页" 3星方案（仅满足字面需求）: "提供一个上传按钮，让用户选择图片上传" 10星方案（解决根本问题）: "自动识别产品照片，OCR提取规格信息， 拉取竞品数据对比，自动生成优化后的商品描述， 一键发布到多个平台"

CEO模式的工作流程： [输入] 用户描述的功能需求 | v [追问] 这解决了什么用户痛点？ | v [追问] 不做的后果是什么？ | v [生成] 8个扩展提案 | v [用户] 挑选5个核心方案 | v [输出] 3个放入backlog，5个进入详细规划

3.2 工程经理模式：/plan-eng-review

/plan-eng-review 核心能力： 角色设定： - 你是一位有10年经验的工程经理 - 你见过太多过度设计和设计不足的项目 - 你擅长平衡技术理想和业务现实 核心交付物： 1. 数据流图（ASCII格式） 2. 组件关系图 3. 状态机设计 4. 边界定义（同步 vs 异步） 5. 失败场景处理 6. 14-case测试矩阵 14-case测试矩阵示例： +------------------+------------------+------------------+ | 场景 | 输入条件 | 预期结果 | +------------------+------------------+------------------+ | 正常流程 | 有效数据 | 成功处理 | | 空输入 | null/undefined | 友好错误提示 | | 边界值 | 最大/最小值 | 正确处理 | | 超长输入 | 超过限制 | 截断或拒绝 | | 重复提交 | 相同请求两次 | 幂等处理 | | 并发请求 | 多线程同时 | 数据一致性 | | 网络超时 | 请求超时 | 重试或降级 | | 服务不可用 | 下游故障 | 熔断处理 | | ... | ... | ... | +------------------+------------------+------------------+

3.3 设计审查模式：/plan-design-review

/plan-design-review 核心能力： AI slop检测： - 检测是否使用了默认UI框架样式 - 检测缺乏个性的配色方案 - 检测缺乏设计系统支撑的组件 - 检测AI生成痕迹明显的元素 评分体系： - 设计评分：A/B/C/D - AI slop评分：A/B/C/D - 可访问性评分：A/B/C/D 输出DESIGN.md： 包含设计系统推断、80项审计清单、设计改进建议

3.4 产品质疑模式：/office-hours

/office-hours 核心能力： 这是一个"产品诊所"模式： - 挑战现有的产品假设 - 提出重构建议 - 发现潜在的陷阱 适用场景： - 需求不清晰，需要厘清 - 多个方案难以抉择 - 感觉哪里不对但说不出来

四、质量保障层深度解析

4.1 代码审查模式：/review

/review 核心能力： 审查深度： - 不是找语法错误（那是编译器的活） - 而是找"能通过CI但在生产中会爆炸的bug" 三种标注方式： [AUTO-FIXED] 问题已自动修复 - 孤儿资源清理 - 缺失索引添加 - 重复代码消除 [ASK] 需要人工判断 - 竞态条件可能性 - 业务逻辑合理性 - 性能权衡取舍 [REVIEW] 需要关注的潜在问题 - 缺少日志记录 - 异常处理不完整 - 可能有并发问题 枚举追踪： 当发现新的枚举值时，自动检查所有switch语句是否处理了这个值

/review 输出格式： +----------------------------------------------------------+ | 代码审查报告 | +----------------------------------------------------------+ | | | [AUTO-FIXED] 孤儿S3资源清理 | | - 发现未引用的S3对象：profile-pics/temp/* | | - 已清理：127个对象，释放空间：3.2GB | | | | [AUTO-FIXED] 缺失数据库索引 | | - 发现字段：orders.user_id, orders.created_at | | - 已添加复合索引 | | | | [ASK] 支付回调的并发处理 | | - 当前实现：直接更新余额 | | - 潜在风险：幂等性如何保证？ | | - 请确认：是否需要分布式锁？ | | | | [REVIEW] 日志记录不完整 | | - 订单创建成功，但没有记录日志 | | - 建议：添加审计日志 | | | | 总结：发现5个问题 | | - 自动修复：2个 | | - 需要确认：1个 | | - 需关注：2个 | +----------------------------------------------------------+

4.2 QA测试模式：/qa

/qa 核心能力： 真实浏览器测试： - 启动Chromium（通过/browse集成） - 执行真实用户操作 - 截图验证 - 观察控制台错误 差异感知测试： 分析git diff，只测试变更涉及的代码路径 不需要全量回归 健康评分系统： 测试前评分 --> 执行测试 --> 测试后评分 --> 对比提升 健康评分维度： - 功能完整性 - UI正确性 - 控制台错误数 - 网络请求成功率 - 性能指标

/qa 执行流程： [输入] 测试目标URL + git diff | v [分析] 提取变更的代码路径 | v [规划] 生成针对性的测试用例 | v [执行] 真实浏览器操作 | v [验证] 截图 + 断言检查 | v [报告] 健康评分 + 问题列表 + 修复建议

4.3 纯QA报告模式：/qa-only

/qa-only 核心能力： 与/qa的区别： - /qa: 测试 + 自动修复 - /qa-only: 仅测试，从不修复 适用场景： - 代码冻结期，不能改代码 - 外部团队报告的问题 - 需要独立第二意见 - 管理层要求的独立评估

五、发布运营层深度解析

5.1 发布模式：/ship

/ship 核心能力： 一键发布流程： 1. 同步main分支 2. 运行测试套件 3. 解决Greptile审查意见 4. 推送代码到远端 5. 创建PR（带完整描述） 6. 更新相关文档 7. 生成覆盖率报告 PR创建内容： - 变更摘要 - 测试结果 - 覆盖率报告 - 文档变更diff - 审查意见处理

/ship 自动化流水线： +------------------+ +------------------+ | git checkout | --> | git pull main | +------------------+ +------------------+ | | v v +------------------+ +------------------+ | 运行测试套件 | --> | 覆盖率报告 | +------------------+ +------------------+ | | v v +------------------+ +------------------+ | Greptile审查 | --> | 解决意见 | +------------------+ +------------------+ | | v v +------------------+ +------------------+ | git push | --> | 创建PR | +------------------+ +------------------+ | | v v +------------------+ +------------------+ | /document-release| | 更新文档 | +------------------+ +------------------+

5.2 文档同步模式：/document-release

/document-release 核心能力： 自动文档同步： - 读取项目中所有文档文件 - 分析本次代码变更 - 交叉引用变更和文档 - 自动更新需要修改的文档 智能变更检测： 分析21个代码变更文件 --> 发现8个文档需要更新 多文件更新： - README.md: 更新技能计数 - CLAUDE.md: 更新项目结构说明 - CONTRIBUTING.md: 更新开发指南 - TODOS.md: 标记已完成项 - CHANGELOG.md: 优化变更日志语言 变更日志优化： - 原：AI自动生成，机械生硬 - 优化后：像人类编写的，自然流畅

5.3 工程回顾模式：/retro

/retro 核心能力： 团队感知回顾： - 分析团队成员的活动 - 识别模式和趋势 - 生成可操作的改进建议 数据驱动分析： - 代码提交频率 - PR合并时间 - 测试覆盖率变化 - Bug趋势 贡献者分析： - 谁贡献最多 - 哪些文件最活跃 - 哪些模块变更最频繁

六、基础设施层概览

6.1 浏览器自动化：/browse

/browse 核心能力： 集成Playwright，提供： - 页面导航 - 元素交互 - 表单填写 - 截图取证 - JavaScript执行 - 等待条件

6.2 会话管理：/setup-browser-cookies

/setup-browser-cookies 核心能力： Cookie导入： - 支持Chrome/Firefox/Safari - 自动解密浏览器存储 - 保存为可复用配置 会话恢复： - 导入Cookie后可直接访问需要登录的页面 - 无需重新登录

6.3 自我升级：/gstack-upgrade

/gstack-upgrade 核心能力： 自动升级gstack到最新版本 保留用户配置 回滚能力（如果新版本有问题）

6.4 并行会话管理：/conductor

/conductor 核心能力： Conductor是gstack的并行任务管理器： - 同时运行多个Claude Code会话 - 每个会话处理不同的功能开发 - 统一管理进度和结果 这是实现"10-15个sprint并行"的关键

七、实际使用场景

7.1 新功能开发完整流程

新功能开发流程： [Step 1] 产品质疑 > /office-hours "我想做一个用户通知功能" | v [Step 2] CEO审查 > /plan-ceo-review 用户画像 --> 痛点分析 --> 成功指标 | v [Step 3] 工程规划 > /plan-eng-review 数据流 --> 组件图 --> 测试矩阵 | v [Step 4] 设计审查 > /plan-design-review UI评审 --> AI slop检测 | v [Step 5] 实现功能 Claude带着完整上下文编码 | v [Step 6] 代码审查 > /review 偏执审查 --> 自动修复 --> 人工确认 | v [Step 7] QA测试 > /qa 真实浏览器 --> 健康评分 | v [Step 8] 发布 > /ship 一键PR --> 文档同步 | v [完成] 功能上线 + 文档完整

7.2 Bug修复快速流程

Bug修复流程： > /review 发现问题 --> [AUTO-FIXED]自动修复 --> [ASK]人工确认 > /qa 验证修复 --> 确保无回归 > /ship 发布修复 --> 自动更新CHANGELOG

总结

gstack的21个Skill形成了一个完整的开发周期：

技能系统总结： 产品规划层：确保做正确的事 - /plan-ceo-review: 10星产品思考 - /plan-eng-review: 架构锁定 - /plan-design-review: 设计质量 - /office-hours: 产品质疑 质量保障层：确保正确地做事 - /review: 偏执代码审查 - /qa: 真实浏览器测试 - /qa-only: 纯报告模式 - /design-review: 设计走查 发布运营层：确保持续交付价值 - /ship: 一键发布 - /document-release: 文档同步 - /retro: 数据驱动回顾 基础设施层：支撑上层能力 - /browse: 浏览器自动化 - /setup-browser-cookies: 会话管理 - /conductor: 并行管理

这不是21个独立工具，而是一套协同工作的系统。每个Skill的输出都可能成为下一个Skill的输入，形成高效的价值流。