核心用法
gstack 是一套角色驱动的工程管理框架，通过15+细分AI角色模拟完整技术团队的工作流程。用户通过 @gstack:[角色名] 指令切换不同专家视角，如 @gstack:ceo 进行产品规划、@gstack:eng 设计技术架构、@gstack:review 审查代码质量。每个角色内置特定领域的最佳实践——从OWASP安全审计到Core Web Vitals性能基准，从金丝雀部署监控到项目复盘方法论。需在项目根目录维护 GSTACK.md 上下文文件，使各角色能基于统一的项目背景协作。
显著优点
1. 权威性思维移植：直接融合Google Staff Engineer、Martin Fowler、Kent Beck等顶级工程师的工程哲学，以及Paul Graham、Sam Altman的创业思维框架，相当于将硅谷顶尖人才的经验模式化复用。
2. 流程标准化价值：完整覆盖软件开发生命周期——从需求澄清（office）、产品设计（ceo/design）、开发实现（eng）、质量保障（qa/review）到发布运维（ship/land/canary），特别适合缺乏成熟流程的中小团队快速建立规范。
3. 降低认知切换成本：开发者无需在"实现者"与"审视者"角色间反复切换心智模式，通过指令调用即可获取独立视角的专业反馈，有效对抗单一视角盲区。
潜在局限
依赖人工上下文维护：GSTACK.md 的有效性直接决定输出质量，若项目文档更新滞后，AI角色可能基于过时信息决策。
非强制执行机制：作为纯提示词框架，gstack 提供建议但不阻止用户忽略关键步骤（如跳过安全审计直接部署），质量控制仍依赖使用者自律。
角色粒度与协作复杂性：15个角色虽覆盖全面，但对简单项目可能过度设计，新手需学习成本判断何时调用何角色。
适合人群
- 独立开发者/全栈工程师：弥补专业角色缺失，获得架构评审、安全审计等通常需团队协作才能获得的反馈
- 早期创业团队：以极低成本模拟YC级别工程团队的协作流程
- 技术负责人：作为标准化模板推动团队流程建设
- AI编程工具重度用户：希望超越"问答式"交互，建立结构化人机协作模式
常规风险
过度依赖风险：可能弱化开发者自主判断能力，尤其在关键架构决策时需保持人类最终决策权。
上下文幻觉风险：若GSTACK.md与代码实际状态不一致，AI角色可能产生"自信的错误建议"。
安全责任边界：security角色提供OWASP/STRIDE框架指导，但非实时漏洞扫描工具，不能替代专业安全审计。