Gstack AI虚拟工程团队

Gstack式AI工程团队开发模式。基于Y Combinator CEO Garry Tan开源的gstack方法论， 将单一AI助手转化为虚拟工程团队。适用场景：新项目启动、功能开发、代码重构、Bug修复、 技术方案评审、部署上线、团队Sprint规划、代码审查、E2E测试。 触发词：gstack、用gstac...

Security Scan

技能描述、阶段与工具总体上与把单一助手变成“虚拟工程团队”的目的相符，但文档鼓励“全自动”流水线并包含对生产部署/数据库/文件修改等高风险操作的自动化能力，且没有在所有关键点强制人类确认或声明所需凭据——这让自动执行时存在明显的安全/权限风险，需要在安装前确认运行环境和控制措施。

Purpose & Capability

技能名称与描述（Gstack 虚拟工程团队）与 SKILL.md 中列出的分阶段流程、角色、工具（think/plan/build/review/test/ship/reflect）高度一致；所需二进制、环境变量、配置路径都未被声明，且技能是说明文档型，没有外部安装要求，因此就功能而言内部一致。

Instruction Scope

说明文档明确允许并指导执行端到端流程，包括在 Phase5 打开真实浏览器进行 E2E、在 Phase6 对 ECS 等环境做 dry-run 与正式部署、以及运行可能影响生产的数据/配置变更。技能包含良好的防护建议（/careful、/freeze、/guard）和确认流程示例，但并没有强制这些保护在所有自动化路径下启用；且“全自动 Sprint（推荐）”与示例场景暗示可以在无需逐步人工批准的情况下执行高风险操作，存在误触或越权执行的风险。

Install Mechanism

这是纯文档/提示词技能（无 install spec、无代码可执行文件），因此不会写入磁盘或下载外部执行包；这降低了供应链安装风险。

Credentials

技能声明不需要任何环境变量或凭据，但在描述中期望访问浏览器、CI/CD、ECS、数据库、回滚操作等外部系统。缺少明确定义需要哪些外部凭据（如 AWS/GCP 凭证、CI token、数据库凭证）是可理解的（技能可能依赖宿主平台已配置的工具/凭据），但也意味着安装者必须明确平台上哪些凭据会被用于该技能，以及这些凭据的权限范围是否最小化。

Persistence & Privilege

技能未请求始终加载（always:false）且默认允许模型调用（平台默认）。按规则这本身不是问题，但结合文档中对“全自动”流水线和自动修复/部署的建议，建议在启用自动运行前确认有人类审批点、审计日志和凭据权限边界，以降低自动化带来的放大风险。

What to consider before installing

这项技能在设计上与把 AI 组织成虚拟工程团队一致，但它可以自动执行高风险操作（例如在 ECS/生产环境部署、修改数据库、删除文件等）。在安装或启用前请考虑并执行以下步骤： - 确认运行上下文：弄清楚该技能将在什么 agent/环境中运行（本地、云端、平台托管），谁能接触到 agent 的凭据。 - 最小化凭据权限：如果允许该技能调用云服务或 CI/CD，确保使用最小权限的服务账号（只允许部署到测试/staging 而非生产，除非另有审批流程）。 - 强制人类审批点：要求在任何 DROP/TRUNCATE、force-push、生产数据库迁移或正式部署之前必须有明确的人类确认（即强制启用 /careful 模式或在配置里将 ship 操作设为手动）。 - 在非生产环境先试跑：先在 staging 或 sandbox 以 quick/full 模式测试整个流水线，验证 freeze/careful/xcheck 行为与日志记录。 - 审计与日志：确保所有自动化的危险操作都有可导出的审计日志（who/when/what/reason），并能追溯到用户确认记录。 - 配置默认安全策略：如果你是平台管理员/项目负责人，要求该 skill 的默认配置禁止自动 Ship 到 production，或要求在 gstack.config.yaml 明确开启 production-deploy=true 并由管理员批准。 如果你不确定 agent 环境中是否存在云或 CI 凭据，或无法强制审批与审计，请先不要在生产项目中启用“全自动”模式；改为仅用 Think/Plan/Review/Test 的只读/建议模式来获取价值。

gstack-dev — AI 虚拟工程团队技能

核心理念（来自 YC CEO Garry Tan）： 1人 = 20人工程团队。通过专业化角色 + Sprint流水线 + 安全工具层， 让每次开发都经过完整的企业级工程流程。

---

一、架构总览

┌─────────────────────────────────────────────────┐
│                  gstack-dev                      │
├──────────┬──────────┬───────────────────────────┤
│ 角色层   │ 流水线层  │ 工具层                     │
│(Roles)   │(Sprint)  │(Tools)                    │
├──────────┼──────────┼───────────────────────────┤
│ /think   │ Phase 1  │ /freeze   编辑锁定        │
│ /plan    │ Phase 2  │ /careful  危险操作警告     │
│ /build   │ Phase 3  │ /guard    锁定+警告       │
│ /review  │ Phase 4  │ /xcheck   多模型交叉验证   │
│ /test    │ Phase 5  │ /browse   真实浏览器验证   │
│ /ship    │ Phase 6  │                            │
│ /reflect │ Phase 7  │                            │
└──────────┴──────────┴───────────────────────────┘

---

二、7阶段 Sprint 流水线（核心）

完整流程图

Phase 1: THINK ──→ Phase 2: PLAN ──→ Phase 3: BUILD
     ↓ 需求定义            ↓ 架构设计          ↓ 编码实现
  挑战需求框架         CEO+Eng+Design Review  代码生成
     
Phase 4: REVIEW ──→ Phase 5: TEST ──→ Phase 6: SHIP
     ↓ 生产级审查         ↓ E2E测试           ↓ 部署上线  
  找隐含bug          浏览器真实验证        CI/CD+监控
  
     ↓
Phase 7: REFLECT
     ↓ 回顾改进
  统计+优化建议

各阶段详解

Phase 1: THINK — 需求思考（对应 /office-hours）

• 触发: 用户提出新需求或功能想法
• 角色: 产品顾问（PM视角）
• 输出: 经过挑战的需求定义文档
• 核心动作:
  • 问 6 个强迫性问题（见 roles/think.md）
  • 不执行，只重新定义问题
  • 产出：需求规格 + 成功指标 + MVP范围

Phase 2: PLAN — 方案规划（对应 /plan-* 三连审）

• 输入: Phase 1 的需求定义
• 角色: CEO Review → Eng Review → Design Review（三轮）
• 输出: 技术方案 + 架构决策 + 测试计划
• 核心动作:
  • /plan-ceo-review: 重新思考问题，找10星产品
  • /plan-eng-review: 锁架构、数据流、边界情况
  • /plan-design-review: 每维度0-10分打分

Phase 3: BUILD — 构建实现

• 输入: Phase 2 的技术方案
• 角色: 工程师（Staff Engineer级别）
• 输出: 可运行的代码 + 单元测试
• 核心动作:
  • 按方案逐步实现
  • 每个函数/模块写测试
  • 遵循项目既有代码风格

Phase 4: REVIEW — 生产级审查（对应 /review）

• 输入: Phase 3 的代码
• 角色: 资深工程师（非编写者本人）
• 输出: Bug清单 + 修复后的代码
• 核心动作（不做风格检查，专注生产级问题）:
  • 竞态条件检测
  • 资源泄漏检查
  • 边界情况覆盖
  • 错误处理完整性
  • 安全漏洞扫描
  • 简单问题自动修复，复杂问题标 [ASK] 等用户确认

Phase 5: TEST — 端到端测试（对应 /qa + /browse）

• 输入: Phase 4 的修复后代码
• 角色: QA负责人 + 真实浏览器
• 输出: 测试报告 + 回归测试套件
• 核心动作:
  • 打开真实浏览器（Chromium）
  • 按测试计划走完主流程
  • 记录控制台错误和网络异常
  • 发现bug → 自动修复 → 写回归测试
  • 重新验证通过

Phase 6: SHIP — 发布上线（对应 /ship → /land-and-deploy → /canary）

• 输入: Phase 5 通过的代码
• 角色: 发布工程师 + SRE
• 输出: 已上线且监控中的版本
• 核心动作:
  • 同步 main，跑全量测试
  • 审计覆盖率（目标 >80%）
  • 推 PR，合并，等 CI
  • 部署，健康检查
  • canary 监控循环

Phase 7: REFLECT — 回顾反思（对应 /retro）

• 输入: 全程数据和结果
• 角色: 工程经理
• 输出: 改进报告 + 下次Sprint优化点
• 核心动作:
  • 统计各阶段耗时
  • 哪些地方卡住了？为什么？
  • 产出可复用的经验
  • 更新项目知识库

---

三、使用方式

方式一：全自动 Sprint（推荐）

用户说"用gstack模式做XXX"，自动跑完全部7个阶段。

示例:

• "用gstack模式给IPO项目加支付功能"
• "gstack sprint: 重构前端搜索页"
• "用团队模式修这个bug: XXX"

流程:

1. 自动识别任务类型和复杂度
2. 判断需要的阶段（简单bug可能跳过Think/Plan）
3. 按顺序执行每个阶段
4. 每个阶段完成后汇报进度
5. 全部完成后生成 Reflect 报告

方式二：单阶段调用

用户明确指定某个阶段：

命令	作用	示例
/think 或 "office-hours"	需求咨询	"帮我 think 一下这个功能"
/plan	方案规划（三连审）	"plan一下登录模块"
/review	代码审查	"review 这段代码"
/test	E2E测试	"test 一下首页"
/ship	部署上线	"ship 这个PR"
/reflect	Sprint回顾	"做个 retro"

方式三：工具层单独调用

命令	作用
/freeze <path>	锁定编辑范围，只允许修改指定目录
/careful	开启危险操作警告模式
/guard	freeze + careful 同时开启
/unfreeze	解除锁定
/xcheck	用另一个模型交叉验证当前方案
/browse <url>	打开真实浏览器验证页面

---

四、不可妥协的核心原则（来自 gstack 原版）

⚠️ 以下原则在任何项目中都不可违反：

1. 绝不编造数据 — 不知道就说不知道，不编造API返回值、不编造测试结果
2. 绝不使用过时信息 — 先确认当前状态再行动（进程是否在跑、文件是否存在）
3. 绝不跳过 Think Aloud — 复杂操作前必须说明思路和假设
4. 绝不在没调查的情况下修复 bug — 先根因分析（/investigate），再动手修
5. 绝不在重要决策上跳过用户确认 — 删数据、改生产配置、force-push 等

---

五、快速开始

第一次使用

用户: 用gstack模式帮我把IPO项目的入库脚本部署到ECS

系统自动执行：

1. THINK: 确认入库脚本的用途、依赖、风险点
2. PLAN: 制定部署步骤、回滚方案
3. BUILD: 准备部署命令和环境检查
4. REVIEW: 审查命令安全性（有没有rm -rf之类的危险操作）
5. TEST: 在ECS上试跑 dry-run 模式
6. SHIP: 正式部署并验证
7. REFLECT: 记录部署经验和耗时

---

六、角色 Prompt 文件索引

文件	对应角色/Sprint阶段
roles/think.md	Phase 1: 产品顾问 / Office Hours
roles/plan-ceo.md	Phase 2a: CEO/创始人 Review
roles/plan-eng.md	Phase 2b: 工程经理 Review
roles/plan-design.md	Phase 2c: 设计师 Review
roles/build.md	Phase 3: Staff Engineer 构建
roles/review.md	Phase 4: 资深工程师 Review
roles/test.md	Phase 5: QA负责人 测试
roles/ship.md	Phase 6: 发布工程师 + SRE
roles/reflect.md	Phase 7: 工程经理 回顾
tools/freeze.md	编辑锁定规则
tools/careful.md	危险操作警告
tools/xcheck.md	多模型交叉验证

---

七、与原始 gstack 的差异（适配说明）

原始 gstack (Claude Code)	本适配版 (WorkBuddy)
基于 Claude Code Slash Command	基于 WorkBuddy Skill + Task Agent
固定用 Claude 模型	支持多模型切换（Kimi/Qwen/DeepSeek/GLM）
/browse 用内置 Chromium	用 ClawBrowser skill 或 preview_url
/codex 用 OpenAI Codex	/xcheck 用已配置的其他国产模型
单机单用户	支持多Agent并行（Task team mode）
无持久化记忆	结合 Working Memory 跨会话积累经验

---

基于 Garry Tan's gstack 开源项目适配