我最近越写越明显地感觉到，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 里，可它们并不是随便写写的说明书，而是一整套被组织好的工作流接口。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】