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个放入backlog5个进入详细规划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的输入形成高效的价值流。