这是一篇适合发给技术朋友、朋友圈或公众号的分享稿。重点不是替 gstack 做广告，而是解释：为什么这个项目值得认真看一眼。

---

最近我看到一个很有意思的开源项目：Garry Tan 做的 gstack。

Garry Tan 是 Y Combinator 的 CEO。这个身份本身已经很有传播性，但我真正感兴趣的不是“YC CEO 也在写代码”这件事，而是他把 AI coding 的工作方式做成了一个相当完整的工程系统。

很多 AI coding 工具还停留在“帮我写一段代码”“帮我改一个 bug”“帮我解释一下报错”。这些当然有用，但它们解决的是局部问题。

真正难的是另一件事：

当 AI 生成代码越来越便宜，谁来保证方向、架构、质量、测试、发布和复盘没有散掉？

gstack 试图回答这个问题。

它不是一个单纯的 prompt pack，也不是又一个“神奇 AI IDE 插件”。更准确地说，它像一个面向 AI agent 的软件工厂骨架：把一个原本需要多人协作的工程流程，拆成一组可以被 AI 调用的专业角色和流程。

比如：

• /office-hours 像产品/创始人 office hour，先追问痛点，不急着写代码；
• /plan-ceo-review 从 CEO/Founder 角度重新审视需求，判断是不是应该扩 scope，还是砍 scope；
• /plan-eng-review 像工程负责人，逼你把架构、数据流、边界条件和测试说清楚；
• /review 像 staff engineer，专门找那些 CI 可能放过、但线上会出事的问题；
• /qa 会打开真实浏览器，点击页面、截图、验证，而不是在脑子里假装测试过；
• /ship 负责跑测试、整理 PR、推进发布；
• /learn 把项目里沉淀出来的偏好、坑和经验保存下来，留给下一次使用。

这套东西最有意思的地方，不是命令多，而是顺序对。

一个正常的软件项目不是“写代码”四个字。它其实是：

想清楚 → 设计 → 实现 → review → QA → ship → 复盘 → 学习

过去我们把这套流程交给人类团队协作。现在 AI agent 能写很多代码，但如果没有这套流程，它很容易变成“快是快，但越快越乱”。

gstack 的价值就在这里：它没有把 AI 当成一个更聪明的 autocomplete，而是把 AI 放进一个工程组织结构里。

这点很关键。

为什么它值得技术人看

我觉得至少有三个原因。

第一，它把“AI 写代码”从单点能力推进到了流程能力。

很多人评估 AI coding 的时候，喜欢问：“这个模型能不能一次写对？”

这个问题当然重要，但不够。真实工程里，没有哪个人类工程师靠“一次写对”活着。我们靠的是 review、测试、灰度、监控、复盘和团队记忆。

AI 也一样。

一个 agent 如果只会生成代码，它只是一个快手；如果它能在一套工程流程里工作，它才开始接近一个工程成员。

第二，它承认 AI 会犯错，所以把验证放进系统里。

我比较反感那种“AI 马上替代所有程序员”的说法。现实里 AI 生成的东西经常看起来很对，实际上埋了坑。

gstack 不是靠口号解决这个问题。它把浏览器、QA、review、安全审计、发布检查这些东西放进 workflow。尤其是 /qa 和 /browse 这类能力，让 agent 至少能面对真实页面和真实反馈。

这比单纯让模型在 prompt 里自我反省靠谱。

第三，它是 Markdown + slash commands + 脚本组成的，不是黑盒平台。

这点对技术人很重要。

你可以把它理解成一套可读、可改、可 fork 的 agent 工作流协议。很多核心东西就是 SKILL.md 文件。你能看到每个角色怎么想、怎么检查、怎么交付，也可以按自己的团队习惯改。

这和很多封闭 AI 工具不一样。封闭工具给你一个产品界面，gstack 给你的是一个可以拆开的工作系统。

我最喜欢的一点：它像一个“工程团队模拟器”

“模拟器”这个词不是贬义。

一个小团队最缺的经常不是代码，而是那些中间角色：

• 有人帮你 push back 产品方向；
• 有人强迫你写清楚架构；
• 有人盯着设计是不是 AI 味太重；
• 有人找线上可能炸的问题；
• 有人真的去点页面；
• 有人把发布后的经验记下来。

大公司靠组织分工解决这些问题。小团队没有那么多人，只能靠创始人自己脑内多线程。

gstack 的野心是：让一个人或者一个很小的团队，也能临时调用这些“角色”。

它不一定每次都做得完美，但这个方向很对。

AI coding 的下一步，可能不是“模型再聪明 20%”，而是“我们能不能把 AI 组织进正确的工作结构”。

它不适合谁

如果你只是偶尔让 AI 写个脚本，gstack 可能显得重。

如果你的项目没有测试、没有 staging、没有基本工程纪律，你也不应该指望装了 gstack 就自动变专业。

它更适合这些人：

• 已经在用 Claude Code / Codex / Cursor / OpenClaw 之类工具；
• 发现 AI 写代码很快，但项目状态越来越散；
• 想让 agent 不只是执行任务，而是参与 plan、review、QA 和 ship；
• 愿意读 Markdown workflow，并根据自己的项目改造它。

换句话说，它适合认真用 AI 做软件的人，不太适合只想看 demo 的人。

如果你只想快速体验

可以从这几个命令或流程开始看：

/office-hours
/plan-ceo-review
/plan-eng-review
/review
/qa
/ship
/learn

我建议的体验顺序是：

先拿一个你真实想做的功能
→ 用 /office-hours 让它追问和重构需求
→ 用 /plan-eng-review 看它如何逼出架构细节
→ 做完后用 /review 和 /qa 找问题
→ 最后看 /ship 怎么把结果收束成 PR

不要只看 README，也不要只看命令列表。这个项目真正的味道在 workflow 里。

我为什么推荐它

我推荐 gstack，不是因为它已经是最终答案。

恰恰相反，它肯定还会变，也一定有很多地方不适合你的项目。但它已经把一个重要方向讲清楚了：

AI coding 不应该只是“生成代码”。
它应该变成一种新的工程协作结构。

这件事我觉得很值得看。

未来的软件团队可能会越来越小，但小不代表流程可以消失。相反，越小的团队，越需要把方向判断、工程审查、质量验证和组织记忆外化出来。

gstack 是一个很早、很 hacker、但也很具体的尝试。

如果你最近也在思考 AI agent 怎么真正进入工程实践，我建议你花半小时看看这个项目。不要只看它表面上的“23 个技能”或者“slash commands”，重点看它背后的组织方式。

那才是最有价值的部分。

项目地址：

https://github.com/garrytan/gstack

如果你看完只有一个 takeaway，我希望是这个：

AI 时代的软件工程，不只是更快写代码，
而是重新设计“谁来思考、谁来检查、谁来记住、谁来发布”。