gstack：虚拟工程团队方法论
gstack是一个源自Y Combinator CEO Garry Tan的工程管理框架，将AI Agent从通用助手重构为结构化工程团队。核心创新在于角色切换机制——每个开发阶段调用特定专家角色（CEO、工程经理、设计评审师、安全官等），模拟真实团队协作流程。
核心用法
通过@gstack:<role>指令切换12种专业角色，覆盖产品全生命周期：
- 规划阶段：
ceo做产品规划，eng做架构设计，design做设计评审与AI Slop检测 - 开发阶段：
investigate负责根因分析（3次失败自动停止），review执行代码审查 - 交付阶段：
qa制定测试策略，land完成PR合并+部署+健康验证（v2.5.3新增），ship执行发布检查 - 治理阶段：
security做STRIDE威胁建模，retro做项目复盘，office提供需求澄清
需配合GSTACK.md项目上下文文件使用，确保角色切换时保持认知连贯。
显著优点
1. 方法论背书强：融合Google Staff Engineer（Jeff Dean）、Martin Fowler/Kent Beck的工程思维，Paul Graham/Sam Altman创业思维，以及Stripe/Airbnb的设计实践
2. 生产验证：原创作者Garry Tan用Claude Code + gstack在60天内产出60万行代码
3. 流程闭环完整：从需求澄清到部署验证的端到端覆盖，新增land技能解决"最后一公里"问题
4. 风险控制设计：investigate的3次失败停止机制、security的OWASP Top 10检查提供工程纪律
潜在局限
- 上下文依赖重：需维护
GSTACK.md文件，小型项目可能 overhead 过高 - 角色认知切换成本：频繁切换12个角色需要用户熟悉各角色职责边界
- OpenClaw生态绑定：当前版本专为OpenClaw设计，跨平台迁移需适配
- AI幻觉风险：设计评审、安全审计等判断型任务仍存在模型幻觉可能，关键决策需人工复核
适合人群
- 独立开发者/小团队：以1人成本获得8人工程团队的能力覆盖
- 技术负责人：需要标准化代码审查、发布流程的团队
- 创业公司：追求YC级别工程纪律但缺乏资深工程师储备
常规风险
- 过度依赖风险：可能弱化开发者自身架构判断力
- 安全审计盲区：STRIDE建模依赖模型知识边界，新型攻击面可能遗漏
- 部署自动化风险：
land技能的PR合并+部署链需配合CI/CD权限管控，避免误操作