最近研究了 Garry Tan 开源的 GStack，发现一个残酷真相：不是 AI 不够强，是我们用错了方式。
很多人把 Claude 当搜索引擎用，问一句答一句。结果：
GStack 的颠覆性在于：它不是工具，是"组织"。
Garry Tan 说 "It's just markdown"，但这话背后藏着工程哲学：
| 传统开发 | GStack 模式 |
|---|---|
| 招人、开会、对齐 | 一个 /slash command 召唤专业角色 |
| 经验靠人脑传承 | 技能写成 Markdown，可版本控制、可迭代 |
| 流程靠自觉 | 强制 Think → Plan → Build → Review → Test → Ship → Reflect 七步循环 |
15 个角色 = 15 个 .md 文件，放在 .claude/skills/ 里，Claude Code 自动识别调用。
/office-hours -- 杀死"自嗨式创业"YC 风格拷问：你的 idea 真的是问题吗？MVP 能砍到多小？风险清单列了吗？
独立开发者最大陷阱：花 3 个月做没人要的东西。
/plan-eng-review -- 架构不翻车技术选型、依赖分析、测试策略、时间估算。一个人写代码最容易跳过这步，结果中期重构。
/design-consultation -- 设计系统一键生成不是"画个好看的界面"，是输出完整组件库、样式规范、甚至 Figma-like 的描述文档。
/qa -- 真·端到端测试真实浏览器跑测试，自动修复，回归验证。不是"我觉得能跑"，是"机器验证过能跑"。
/ship -- 发布 checklist 自动化测试 → PR → 部署准备，一步不落。独立开发者最容易在这里翻车：本地能跑，线上爆炸。
GStack 开源的是角色定义和工作流，不是黑盒模型。
这意味着：
/office-hours 的 prompt，让它更适合国内市场/growth-hacker 角色，专门负责冷启动这是"软件工程"对"提示工程"的降维打击。
未来 3 年，"全栈工程师"的定义会被重写。
不是"前后端都会"，而是能 orchestrate 10+ 个 AI 角色，独立完成产品全生命周期。
GStack 可能是第一个可落地的组织范式--不是替代开发者，是让一个人拥有 20 人的协作结构。
你会尝试 GStack 吗？或者你已经有一套自己的 AI 工作流？
最想吐槽的是：这 15 个角色里，你觉得哪个对独立开发者最鸡肋？哪个最缺不得？
📎 项目地址：https://github.com/garrytan/gstack 📎 许可：MIT（可商用、可魔改）
加入讨论
试了下 `/office-hours`，被问到”你上周验证了什么假设”的时候直接懵了😂 确实比让AI写代码难多了，这玩意儿是逼你动脑子的。
看到”技能写成 Markdown，可版本控制”突然悟了——这不就是把人的经验变成可复用的开源库吗？以前带新人要重复教三遍，现在直接 `git clone` 一个 senior dev 的脑子。唯一担心的是：我的 `.claude/skills/` 文件夹会不会膨胀到比代码还厚😂
有点好奇这个 `/reflect` 步骤具体怎么设计的——七步循环里前面都是干活，最后一步是复盘，但一个人做项目真的会有动力定期自我复盘吗？感觉很容易变成”下次一定”😅 有没有强制触发机制？
说实话看到”七步循环”有点头大，独立开发本来图的就是自由，现在又要走流程了？但转念一想，一个人最容易犯的错就是跳步骤，有个强制框架反而能救命。先收藏了，等哪天项目翻车的时候拿出来用😅
15个角色全是英文命名的，国内开发者用的时候会不会有点别扭？比如`/office-hours`这种YC黑话，没接触过的人第一眼可能懵。要是能有个本土化版本就好了，或者至少加个中文alias？
最戳我的是那个”真实浏览器跑测试”——之前用 AI 写了个爬虫，本地完美运行，一上服务器就崩，查了半天才发现是 headless 浏览器版本问题。有这种强制 QA 角色盯着，至少能少熬几个通宵吧😅