🚀 gstack：让 Claude 变成顶级工程团队的秘密脚本
gstack 是 Y Combinator CEO Garry Tan 的 Claude Code 个人工作流工具集。其核心理念不仅仅是“用 AI 写代码”，而是把 Claude Code 变成一个优秀的虚拟工程团队。
Garry Tan 声称利用这套工具，在兼职运营 YC 的同时，60 天内写了 60 万行生产代码（平均每天 1-2 万行）。这听起来极其夸张，且这些代码是直接上线使用的。那么，为什么这套“Stack”如此有效？
🧠 核心原理：激活 Claude 的“专家人格”
这主要与 Claude 的激活机制（Activation Mechanism）有关。
Claude 的训练数据中包含海量的人类高质量写作：从 Staff Engineer 的代码审查、YC Partner 给创业者的反馈，到设计师的批评报告和 QA 的 Bug 报告。
当你简单地说“帮我写代码”时，模型处于“泛化助手”模式。但当你通过 gstack 指令明确：“你是 Staff Engineer，找生产环境会炸的 Bug”，你实际上在激活一个特定的行为分布。模型会从“资深工程师做 Code Review”的模式中采样。
🎭 分布的巨大差异
- 助手模式：倾向于夸奖、寻找可行方案、以“让用户满意”为目标（容易产生幻觉或妥协）。
- Staff Engineer 模式：倾向于挑刺、寻找边界条件、预测失败（更严谨、更具批判性）。
🛠️ gstack 的五大核心机制
1. 🔍 角色 = 激活不同的注意力
每个角色天然关注不同的维度。你无法同时以 CEO 的视角（扩大产品愿景）和 CSO 的视角（缩小攻击面）思考。gstack 把它们分开，让每个视角都能走到极致。
2. ⛓️ 序列化避免认知干扰
人类专家团队开会往往效率低下：一个人说一半，另一个人岔开话题。
gstack 的流程是：Think → Plan → Build → Review → Test → Ship。每一步完全完成后才进入下一步。每个角色不是从零开始，而是在前人工作的基础上进行批判和迭代。
3. 🛡️ 强制对抗性思维
普通用法中，Claude 往往会给出鼓励性反馈。gstack 通过指令集（Persona）强制改变默认模式：
/review：定位是“找生产会炸的 Bug” —— 将目标从“找优点”切换到“找缺陷”。/plan-ceo-review：主动质疑你的问题定义，而不仅仅是解决你提出的表面问题。/cso：拥有明确的 False Positive 排除清单和置信度门槛 —— 强制精确，不允许模糊。
本质上：把成功的标准从“让用户满意”变成了“找到问题”。
4. 📊 具体评分标准 > 模糊指令
例如 /plan-design-review 会对每个设计维度打 0-10 分，并解释“10 分长什么样”。
- 模糊指令：“帮我优化设计” → Claude 不知道优化的终止条件，容易给泛泛而谈的建议。
- 具体标准：“信息层次 6/10，10 分应该是 X，现在差在 Y” → Claude 有了明确的 Delta，知道优化的方向 and 终点。
评分系统把“主观审美判断”转化为了“有终止条件的工程问题”。
5. 🌐 真实工具打破幻觉
/qa 和 /browse 调用的是真实的 Chromium 浏览器。
这至关重要，因为 LLM 天生倾向于幻觉性地假设代码能运行。让它真的去点击按钮、观察真实错误，强制把“我认为它应该工作”转变为“我看到它实际上坏了”。
真实反馈回路 > 推理幻觉。
🎯 总结：为什么一个人能跑出团队速度？
- 普通用法：一个 Claude，一个视角，试图均衡考虑所有事情。结果：每个维度都走不深，容易妥协。
- gstack 用法：多个专门化的 Claude，串行激活不同分布。结果：每个维度走到极致，强制对抗性检查。
本质上，gstack 把“一个全能助手”拆成了**“多个有偏见的专家”**。
在现实工程团队中，之所以需要专门的 QA、安全工程师和设计师，不是因为一个人不够聪明，而是因为专门化的注意力本身就是一种能力。通过 gstack，这种能力被规模化地赋予了个体开发者。