我最近越写越明显地感觉到，AI 编程工具最麻烦的，已经不是写不出代码，而是需求一复杂，整个过程就开始失控。
小功能还能靠 vibe 往前推，一旦事情跨到产品、架构、实现、审查、测试和交付，链路就很容易散。上下文永远是有限的，目标一多、链路一长、约束一冲突，agent 就容易失焦、返工，最后把问题越做越乱。
所以今天更关键的问题，已经不是“AI 会不会写代码”，而是“怎么让 AI 在复杂工作里稳定地按一套流程工作”。
也正是卡在这里，我开始认真看 gstack。它的作者是 Garry Tan： Y Combinator 的 President & CEO，做过 Palantir 早期的 eng/PM/designer，后来联合创办 Posterous，也搭过 YC 的 Bookface。对我来说，这些经历的意义不只是“履历很强”，而是他确实长期在产品、工程和组织三个层面都做过复杂系统，所以他怎么组织 AI 工作流，本身就值得研究。
更关键的是，他不是在纸上谈 workflow。按 README 里的说法，过去 60 天里，他交付了 60 万+ 行生产代码，其中 35% 是测试；平时一天能写出 1 万到 2 万行；最近一次跨 3 个项目的 /retro，一周内有 140,751 行新增和 362 次提交。
这些数字至少说明：gstack 不是一个随手整理出来的 prompt 包，而是为了支撑高密度交付，被反复打磨出来的一套工作系统。
也正因为它表面上太像一个 skill 仓库，我第一眼把它看浅了。
目录里是一堆 slash commands，文档里是一堆角色，第一眼很像“给 Claude Code 多装几个 prompt”。但我读完 系列总计划 里反复标出来的那几份核心材料之后，越来越觉得这个理解是偏的。
gstack 最有意思的地方，不是它写了多少 skill，而是它根本不相信“一个万能 prompt 可以稳定解决所有问题”这件事。
它真正想做的，是把 AI 的工作方式工程化。
你会先看到：
- •
/office-hours - •
/plan-eng-review - •
/review - •
/qa - •
/ship
再加上一堆其它命令，很容易把它理解成一套 skill 的扩展包。
但我后来发现，作者自己在 README 里的描述，根本不是“这里有很多有用命令”，而是它把 Claude Code 变成一个软件开发团队。这句话其实已经把重心说得很清楚了。
如果重点只是 prompt，作者根本没必要一直讲 CEO、 Eng Manager、 Designer、 QA、 Release Engineer 这些角色。
如果重点只是命令，他也没必要反复讲 Think -> Plan -> Build -> Review -> Test -> Ship -> Reflect 这条 sprint。
这说明 gstack 关心的，不是 AI 会不会做某一步，而是 AI 应不应该按一套明确分工和顺序来工作。
说白了，gstack 的表象是命令集合，本质是工作方式集合。
为什么万能 prompt 不够
一旦把视角从“技能仓库”切到“工作流系统”，第一个问题就会变得很尖锐：
既然模型已经这么强了，为什么不写一个足够大的 prompt，让它既能想产品、又能做架构、还能写代码、测页面、提 PR？
表面看这是最省事的办法，实际上很容易失控。
因为这些任务本来就不是一种认知任务。
比如：
- • 产品重定义，需要不断怀疑“你提的需求到底是不是你真正想要的”
- • 工程规划，需要收敛边界、画出结构、识别失败路径
- • 代码审查，需要挑错，需要不信任已经写出来的东西
- • QA 验证，需要去看真实页面和真实用户路径，而不是停留在代码层
这些任务的思考姿态是冲突的。
把它们全塞进一个 prompt，结果通常会走向两个极端：
- • 要么模型一路发散，永远在继续想法
- • 要么模型一路实现，完全不再质疑问题本身
这也是为什么我现在越来越认同一个判断：
在复杂工作里，问题往往不是 prompt 不够长，而是目标没有被隔离。
gstack 看见的，显然也是这个问题。
角色化不是拟人化，而是认知隔离
读到 skills 时，我开始更明显地感觉到，gstack 不是在做“人格扮演”，而是在做“认知隔离”。
你可以把它理解成一支分工清楚的项目组，而不是让一个人从想需求一路干到发版。不是说一个人绝对做不了，而是这些环节盯的风险点根本不一样。要是全堆到一个人脑子里，最容易发生的事不是“更高效”，而是关键风险没人盯住。
比如：
- •
/office-hours的职责是先把问题问清楚，先重定义产品 - •
/plan-eng-review的职责是锁定架构、数据流、边界、测试 - •
/review的职责是怀疑这份改动会不会在生产里炸掉 - •
/qa的职责是去真实页面里验证用户路径到底成不成立
这些 skill 不是平级按钮，它们其实各自承担一种主要怀疑。
作者借用了公司组织里的角色语言，但目的并不是让 AI 看起来更像人，而是让每一段只优化一种任务目标。
这点特别关键。
因为一旦角色边界清楚：
- • 输出会更稳定
- • handoff 会更自然
- • 不同 skill 更容易串成一条连续流程
所以我现在更愿意这样理解：
作者不是在模仿组织架构，而是在借用组织分工来约束模型注意力。
为什么 prompt 还要被生成
如果 gstack 只是做到角色分工，其实已经比“万能 prompt”更进一步了。
但它没有停在这里。
我觉得这也是这个仓库特别值得学的地方：它连 prompt 本身都不想让它停留在“临场发挥”的状态。
在 ARCHITECTURE 里，作者直接把 SKILL.md 模板系统拿出来讲。大意很明确：
- • 人写的是模板
- • 脚本生成的是技能文档
- • 测试负责检查文档和真实命令有没有漂移
这套 .tmpl -> SKILL.md -> tests 的链条，透露出来的是一种非常强的工程态度：
prompt 不是聊天技巧，而是系统资产。
这就解释了为什么 gstack 会同时出现：
- • 角色分工
- • 模板生成
- • 文档验证
- • 工作流测试
因为在作者看来，角色化解决的是“AI 应该怎么想”，而生成和测试解决的是“这套系统怎样长期不漂”。
这和我原来理解的 prompt engineering 已经不是一回事了。
原来的 prompt engineering，更像是“把一句话磨得更顺”。
gstack 这里的做法，更像是在做 workflow engineering。
这套设计到底换来了什么
如果只是说“更规范”“更工程化”，其实还是太虚。
我现在更愿意把它拆成几个具体收益。
第一，它让 AI 在不同任务里能维持更稳定的思考姿态。
第二，它让每个 skill 的输出都更容易成为下一个 skill 的输入。
这也是为什么 README 一直在强调 sprint，而不是强调单点能力。
第三，它让 prompt 不容易和真实实现脱节。
这点在模板生成和测试机制里已经非常明显。
第四，它让整个系统可以被持续维护，而不是越长越乱。
说白了，gstack 不是把 prompt 写得更花，而是把 AI 从“会答题”推进到了“会接流程”。
这时候再回头看 ARCHITECTURE 里那句很有名的话，意思就更完整了：
浏览器是 hardest part，其他很多只是 Markdown。
这句话表面像是在区分“硬基础设施”和“文档”，但换个角度看，它其实也在说明：
上层这些 skill 虽然很多写在 Markdown 里，可它们并不是随便写写的说明书，而是一整套被组织好的工作流接口。
这对我的启发
我从这一篇学到的，不是“以后我也要写很多 skill”。
我学到的，是以后再设计自己的 AI workflow 时，最好先按下面这个顺序动手：
- • 先把任务拆成几个认知阶段，而不是一股脑交给一个 agent
- • 再决定哪些阶段需要独立角色，哪些可以合并
- • 再把高频、易漂移的部分固化成模板
- • 最后补上测试、校验和 review，防止系统越跑越偏
以前我更容易把 AI 当成一个会回答问题的对话对象。现在我更在意的，是先把它放进流程里，再谈它够不够聪明。
不要只把 AI 当聊天工具，而要把它当成能重组自己工作流的东西。
这也是我想继续写这个系列的原因。
因为 gstack 留给我最强的第一印象，不是“这个 prompt 很强”，而是“这个仓库在认真回答：当实现成本被 AI 压得这么低之后，工作方式应该怎么变”。
下一篇我要追问什么
先收一下这一篇，其实我想讲清楚的只有三件事：
- •
gstack要解决的，不是把 prompt 写长，而是把复杂工作拆成流程 - • 它的角色化设计，不是拟人化，而是隔离不同任务的注意力
- • 它连 prompt 都要模板化、测试化，说明在作者眼里，prompt 不是话术，是资产
如果第一篇回答的是，为什么 gstack 不相信一个万能 prompt，那么下一篇我最想继续追问的问题就是：
当 AI 已经把实现成本压得这么低，为什么作者还会如此执着于“做完整”，甚至把 Boil the Lake 写进整个系统的前言里？
我怀疑，那才是这个仓库另一层更深的设计判断。
