很多人用 Claude Code，习惯是把需求直接扔进去，然后盯着它改。能跑，效率也有，但问题很快出现：产品判断没人做，设计味道没人看，安全审计靠运气，最后发布时再补文档和测试。AI 写代码变快了，工程流程反而容易被省掉。
gstack 值得看的地方，不在“Garry Tan 的同款配置”这个噱头，而在它把 Claude Code 拆成一支虚拟产品小队：CEO 重新审视方向，工程经理卡架构，设计师挑 AI 味，QA 进真实浏览器，安全角色跑 OWASP/STRIDE，发布工程师收尾。这不是让模型更会说话，而是让一次 coding session 更像一次 sprint。
先别全装，先跑一条小闭环
gstack 对 Claude Code 的默认安装路径很直接。新手不要一上来就把所有角色都拉满，先在一个低风险项目里跑通“计划—实现—评审—QA—发布说明”这条线。
git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack
./setup装完后可以从 /office-hours 开始，让它先问清楚你到底在做什么；再用 /autoplan 生成计划；实现之后让 /review 和 /qa 分别检查代码和浏览器行为。别急着追求全自动，先确认这些角色能真的发现问题。
/office-hours → 产品问题先问明白
/autoplan → CEO / design / engineering review 后再定方案
/review → 看 diff、风险和测试缺口
/qa https://staging.example.com → 用真实浏览器走关键流程
/ship → 收敛发布说明和合并前检查团队模式真正有用，但要慢一点上
gstack 支持 team mode，把仓库里的 Claude Code 会话自动接到同一套技能版本。这对团队很诱人，但也最容易乱。建议先只在一个内部工具或 side project 上启用，等大家习惯了角色分工，再放进主仓库。
(cd ~/.claude/skills/gstack && ./setup --team)
~/.claude/skills/gstack/bin/gstack-team-init required
git add .claude/ CLAUDE.md
git commit -m "require gstack for AI-assisted work"团队模式的重点不是“所有人都用同一个 prompt”，而是同一类任务走同一套评审口径。比如安全改动必须跑 /cso，前端页面必须过 /design-review，发布前必须由 /document-release 更新说明。规则写进流程，比写在群公告里靠谱。
边界：别把角色库当组织能力
gstack 很适合个人开发者、技术创始人和小团队，把原来容易漏掉的 review、QA、设计和发布动作补起来。但它不能替代真实的业务判断，也不能保证每个角色都比团队里的专家强。
最稳的用法是把它当“默认检查框架”：小需求可以少跑几个角色，大需求必须跑完整链路；模型给出的结论要留下任务记录和测试证据；涉及权限、支付、用户数据的改动，仍然要人工拍板。AI 小队再能干，也得有人当真正的负责人。