夜雨聆风
朋友，当你打开 gstack 的仓库，我猜，你的第一反应大概率和我一样：头大（big head）。
50 多个 slash 命令。/office-hours、/plan-ceo-review、/plan-eng-review、/design-consultation、/review、/qa、/cso、/ship、/canary、/benchmark……一个 CEO 角色、一个工程经理角色、一个设计师角色、一个安全官角色、一个发布工程师角色，二十多个"虚拟专家"加八个"power tool"，全是 Markdown，全是命令。文档列出来密密麻麻一整屏，看得人焦虑，是的，我和我的同事聊的时候，他看到这个东西虽然很牛逼，但是他也很焦虑，焦虑的是，这么多，特么的老子学不动啊。嗯，先不扯远了。说点正事
作者是 Garry Tan，Y Combinator 的总裁兼 CEO，投过 Coinbase、Instacart、Rippling。他说这是他每天在用的"个人开源软件工厂"，靠它一个人兼职 60 天里上线了 3 个生产服务、40 多个功能。
但如果你冲着"我要把这 50 个工具学会"去读它，你就上当了，就像我同事一样，他就上当了。
因为这 50 个工具是鱼。gstack 真正值钱的东西，是渔。而那个"渔"，是一份只有一页纸的文档，叫 ETHOS.md。 我把整个仓库扒了一遍之后最大的感受是：这不是一个工具集，这是一套被"编译"进了可执行约束里的世界观。今天这篇文章，我就想带你把这个内功心法挖出来。授人以鱼不如授人以渔，搞懂了这套思想，你不光能驾驭 gstack，你自己都能造一个出来。
先说一个反直觉的事实：50 个工具共享同一个大脑
我们正常理解一个工具库，是这样的：每个工具各管一摊，互相独立，你按需取用。
gstack 不是这样。它的 50 多个 skill 文件，开头全都共享同一段东西。
你随便打开一个 skill 的源码模板，第一行业务逻辑之前，永远站着一个占位符：{{PREAMBLE}}。这个 preamble 在构建的时候会被同一套生成器填进去，内容包含什么呢，包含三件事的浓缩版：把湖煮干（Boil the Lake）、先搜再造（Search Before Building）、用户主权（User Sovereignty）。
这三条原则的完整版，就写在仓库根目录的 ETHOS.md 里。文件开头有一句话，我第一次读到的时候愣了一下：
"These are the principles that shape how gstack thinks, recommends, and builds. They are injected into every workflow skill's preamble automatically."
翻译过来：这些原则塑造 gstack 如何思考、推荐、构建。它们被自动注入每一个工作流 skill 的开头。
你品一下"injected"和"automatically"这两个词。它没说"我们希望 AI 读一读这份哲学文档"。它说的是：这份哲学被机械地、自动地、强制地塞进每一次工具调用的最前面。AI 在执行 /review 之前要先过一遍它，执行 /qa 之前也要先过一遍它，执行 /ship 之前还要再过一遍。
这就是我说的"编译"。方法论不再是一篇等着被阅读的文章，而是变成了一段每次都会运行的前置代码。 这是 gstack 整个设计的第一性原理，后面所有的东西都是从这里长出来的。
渔之一：Boil the Lake，把湖煮干
我们先来看这三条心法本身，它们才是这库里最金贵的部分。
第一条叫 Boil the Lake，把湖煮干。这是个反成语——英文里 "boil the ocean"（把海洋煮沸）是贬义，指好高骛远、想一口吃成胖子。Garry 把它改了一个字：海洋别煮，但湖，要给我煮干。
什么意思？ETHOS.md 里给了一张我觉得整篇文档最值钱的表：
这张表想说的核心只有一句：在 AI 时代，"做完整"的边际成本趋近于零。
过去我们为什么总是"先上 80%，剩下的边界情况、错误处理、测试覆盖以后再说"？因为人的工程时间是瓶颈。补全那最后 20%，可能要多花两天人力，不划算，于是大家都学会了走捷径。
但 AI 把这个算式彻底改了。那多写的 70 行完整实现，现在只多花几秒钟。所以 gstack 的态度极其鲜明，它的反模式清单里直接点名：
• "选 B 吧，它用更少的代码覆盖了 90%"——错。如果 A 只多 70 行，选 A。 • "测试放到后续 PR 补"——错。测试是最便宜的那片湖,先煮干它。 • "这个要做两周"——错。说法应该是"人类两周，AI 辅助约一小时"。
这里它还划了一条特别清醒的线：湖（lake）要煮干，海（ocean）要标记为超纲。一个模块做到 100% 测试覆盖、把所有边界情况和错误路径都补上，这是湖，可煮。把整个系统推倒重写、做跨季度的平台迁移，这是海，老老实实标记出来别碰。
我特别欣赏这个区分。因为"完整主义"最大的风险就是滑向"完美主义",然后陷进无底洞。gstack 用"湖 vs 海"这个朴素的比喻,把"该较真的完整"和"会失控的贪大"切得清清楚楚。
渔之二：Search Before Building，先搜再造
第二条心法,我认为是最见功底的一条。
它说,1000 倍工程师遇到问题的第一反应不是"我来设计一个",恰恰是"是不是已经有人解决过了"。在动手造任何涉及陌生模式、基础设施、运行时能力的东西之前,停下来,先搜。检查的成本趋近于零,不检查的代价是你重新发明了一个更烂的轮子。
但如果只到这一层,那也就是句正确的废话。gstack 高明在它把"知识"切成了三层,这个分层我觉得值得每个做技术的人抄进自己脑子里:
第一层:久经考验的(Tried and true)。 标准模式、被验证过的老办法,深深在分布之内的东西。你大概率已经知道。这层的风险不是你不懂,相反，是你默认那个显而易见的答案一定对——可它偶尔就是不对。检查成本几乎为零。而且偶尔去质疑一下天经地义的东西,恰恰是天才闪现的地方。
第二层:新潮流行的(New and popular)。 当下最佳实践、技术选型、生态趋势。要搜,但要带着审视去搜。人是会发癫的,市场先生不是太贪婪就是太恐惧。人群在"新东西"上犯错,和在"老东西"上犯错一样容易。搜索结果是你思考的输入,不是你思考的答案。
第三层:第一性原理(First principles)。 针对手头这个具体问题、靠推理得出的原创观察。这是最珍贵的,要把它置于一切之上。
然后是我读完全篇最受触动的一段,它叫"The Eureka Moment"(顿悟时刻):
搜索最有价值的产出,不是找到一个可以抄的方案。而是:理解所有人在做什么以及为什么(第一、二层)→ 用第一性原理审视他们的假设(第三层)→ 发现一个清晰的理由,证明传统做法是错的。
这就是那个"满分十分里的第十一分"。真正卓越的项目,充满了这种"别人往左我往右"的时刻。当你撞见一个,给它命名,庆祝它,在它之上继续盖楼。
gstack 甚至为这个"顿悟"做了工程化的支持。它的 preamble 注入里有一段 bash,专门用来记录顿悟:当第一性原理的推理和传统智慧相悖时,AI 被要求把这个洞察一行总结,追加写进 ~/.gstack/analytics/eureka.jsonl。
你看,它连"灵光一现"都要落盘存档。它不只是让 AI 干活,它在刻意培养 AI"先理解全局、再独立思考"的习惯,并把这个习惯产生的火花攒起来。 这一手,格局就不一样了。
渔之三:User Sovereignty,用户主权
第三条最短,但 ETHOS.md 给它的定性最重:这是唯一一条凌驾于其他所有规则之上的规则。
原文写得斩钉截铁:AI 模型负责推荐,用户负责决定。两个 AI 模型对某个改动达成一致,是一个很强的信号,但它不是命令。当 Claude 和 Codex 都说"把这两个东西合并",而用户说"不,分开",用户永远是对的。永远。哪怕模型能为合并构造出一套天衣无缝的论证。
为什么?因为用户永远握有模型缺失的上下文:领域知识、商业关系、战略时机、个人品味、还没说出口的未来计划。
它在这里引了两个人的话,都很有意思。一个是 Karpathy 的"钢铁侠战衣"哲学:好的 AI 产品是增强人,不是取代人,人始终在中心。另一个是 Simon Willison 那句很扎心的话:"agents are merchants of complexity"——智能体是复杂性的商贩,当人把自己移出循环,他就不知道到底发生了什么。还提到 Anthropic 自己的研究:越是有经验的用户,打断 Claude 的次数越多,而不是越少。专业让你更亲力亲为,而不是更撒手。
它推崇的模式叫"生成-验证循环":AI 生成推荐,用户验证并决定,AI 绝不因为自己很自信就跳过验证这一步。
反模式清单里有一条我印象很深:
"把你的评估写成一个'我的评估'栏目里的既定事实。"——错。要把正反两面都摆出来,让用户自己去填那个评估。
说实话,在所有人都在卷"全自动 Agent""无人值守""一句话造 App"的 2026 年,一个 YC 总裁开源的工具,把"用户说了算"刻进每一个工具的开头当成最高律法,我觉得这是一种相当清醒、甚至有点逆流的克制。
心法之间怎么咬合:它们不是三条平行的标语
这三条如果只是并列写在那,价值要打个对折。ETHOS.md 专门有一节讲它们怎么协同,这才是真正的设计。
把湖煮干说的是:做完整的事。先搜再造说的是:动手之前先搞清楚已经存在什么。
合起来就是:先搜,然后把"对的那个东西"的完整版本造出来。
它点出了最坏和最好的两种结局:最坏的结局,是你把一个其实只要一行就能搞定的东西,完整地、漂亮地重新造了一遍。最好的结局,是你造出了一个完整版本的、之前没人想到过的东西——因为你搜过了,理解了全局,看见了所有人都漏掉的那个点。
你看,Boil the Lake 单独拎出来会让人冲动地"什么都做完整",Search Before Building 正好给它套了个缰绳:先确认这事值不值得做、有没有现成的。两条心法互为补丁。这种"原则之间互相约束"的设计,比任何单条原则都高级。
光有心法不够,关键是"怎么让 AI 每次都照做"
好,假设你也认同这三条心法。那么核心问题来了:
你怎么保证 AI 在每一次干活的时候,都真的按这套来?
这才是 gstack 真正的工程含量所在,也是大多数人会忽略的地方。心法是思想,而思想如果不能被强制执行,就只是一份满满阿里味的 PPT而已。gstack 用了三个机制,把思想焊死成了约束。
机制一:模板系统,让文档永远不撒谎
gstack 的每个 skill 其实有两个文件:SKILL.md.tmpl(人写的模板,带占位符)和 SKILL.md(构建生成的、提交进 git 的成品)。
中间隔着一个生成器 gen-skill-docs.ts。它干的事是:把模板里的占位符,用从源码里读出来的真实信息填进去。
SKILL.md.tmpl (人写的散文 + 占位符) ↓gen-skill-docs.ts (读取源码元数据) ↓SKILL.md (提交进库,自动生成的章节)比如 {{COMMAND_REFERENCE}} 这个占位符,是从 commands.ts 这个源文件里现读现生成的命令表。{{PREAMBLE}} 是那段哲学注入。{{SNAPSHOT_FLAGS}} 是从 snapshot.ts 里读出来的参数说明。
为什么要这么折腾?ARCHITECTURE.md 里一句话点破了:
"Hand-maintained docs always drift from code."(手工维护的文档永远会和代码漂移。)
我们都吃过这个亏:文档里写着某个参数,代码早改了,AI 照着文档调用,直接报错。gstack 的解法是结构性的——如果一个命令存在于代码里,它就会出现在文档里;如果它不存在,它就不可能出现在文档里。 文档和代码的一致性,不靠人的自觉,靠生成机制保证。
这就是把"文档要及时更新"这条永远做不到的纪律,变成了一条不可能违反的物理定律。
机制二:preamble 注入,让心法每次都先跑一遍
前面说过,每个 skill 开头都有 {{PREAMBLE}}。它具体注入了什么?ARCHITECTURE.md 列了五件事,一条 bash 命令搞定:
1. 更新检查——顺手看看 gstack 有没有新版本。 2. 会话追踪——记录当前有几个 session 在跑。这里有个很妙的细节:当检测到同时有 3 个以上 session 在跑(说明你正在多窗口疯狂并行干活、脑子是乱的),所有 skill 自动进入"ELI16 模式",每个问题都会重新帮你交代一遍上下文,因为它判断你此刻顾不过来。 3. 操作性自我改进——每次 skill 跑完,AI 反思这次踩了哪些坑(CLI 报错、走错路、项目的怪癖),写进项目的 JSONL 文件,给以后的 session 看。 4. AskUserQuestion 统一格式——所有提问长一个样:上下文、问题、 RECOMMENDATION: 选 X,因为___、带字母的选项。5. 先搜再造——就是上面那条心法的浓缩版,带顿悟时刻的记录逻辑。
你发现没有,这五件事里,有哲学(第 5 条)、有纪律(第 4 条统一交互)、有自我进化(第 3 条记录踩坑)、甚至有对用户状态的体察(第 2 条 ELI16 模式)。 它们被打包成一个 preamble,塞进每一次调用的最前面。
这就是"编译"的真正含义:你不需要祈祷 AI 记得这些原则,因为这些原则是它每次开工前必须执行的第一段指令。 对人来说,方法论靠自律;对 Agent 来说,方法论可以直接加载,而且执行得比人更不打折扣。
机制三:HARD GATE,硬门禁
光注入还不够,有些地方需要的是"红线",是"你敢越界我就拦住你"。
我打开 /office-hours(产品头脑风暴)这个 skill,开头就有一行刺眼的标记:
HARD GATE: Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action. Your only output is a design document.
翻译:硬门禁。禁止调用任何实现类 skill,禁止写任何代码,禁止搭任何脚手架,禁止做任何落地动作。你唯一的产出是一份设计文档。
这是什么?这是把"想清楚再动手"这条所有资深工程师都懂、但 AI(和大多数人)总忍不住违反的纪律,变成了一道 AI 跨不过去的门。在产品还没想明白之前,代码这条路被物理封死了。
把三个机制连起来看:模板系统保证文档不撒谎,preamble 注入保证心法每次都跑,HARD GATE 保证关键红线碰不得。心法是软的思想,这三个机制是硬的牙齿。没有牙齿的心法,在 AI 身上和在人身上一样,该跳过还是会跳过。
这些工具为什么要串成一条流水线
回到最开始那个让人头大的工具列表。现在你应该能看懂它们为什么长这样了。
README 里有一句话:"gstack is a process, not a collection of tools."(gstack 是一个流程,不是一堆工具的集合。)
它的 50 个 skill,是按一次软件冲刺(sprint)的顺序排的:
Think → Plan → Build → Review → Test → Ship → Reflect
/office-hours 想清楚要做什么(产出设计文档) ↓/plan-ceo-review CEO 视角挑战范围:这是不是该做的事/plan-eng-review 工程经理锁定架构、数据流、边界情况/plan-design-review 设计师给每个维度打分 ↓ (写代码) ↓/review 资深工程师找那些过了 CI 却会在生产炸的 bug/cso 安全官跑 OWASP Top 10 + STRIDE 威胁建模 ↓/qa QA 开真浏览器点一遍流程,找到 bug 当场修 ↓/ship 发布工程师同步主干、跑测试、开 PR/canary SRE 盯生产监控 ↓/retro 复盘这周做了什么关键在于每个 skill 的产出,是下一个 skill 的输入。/office-hours 写的设计文档,/plan-ceo-review 会读。/plan-eng-review 写的测试计划,/qa 会接手。/review 抓到的 bug,/ship 会去验证修没修。
README 里那句话我很喜欢:"Nothing falls through the cracks because every step knows what came before it."(没有东西会从缝里漏掉,因为每一步都知道它前面发生了什么。)
这跟我之前拆解 Superpowers 时讲的"硬性流水线"是同一种思想:把资深工程师脑子里那条"需求→设计→计划→实现→审查→测试→发布→复盘"的隐性循环,外化成一条显式的、每一环都有交接的流水线。 大神不需要这条线,因为它已经长在他脑子里了。普通人需要,因为这条线替他执行了"懂行的人才会做的那些决定"。
我的一点保留意见
夸了这么多,我得说点不一样的。
我对 gstack 这套"重流程"打法,有一个真实的担心:它可能不适合所有阶段的项目,甚至会反噬。
你想,/office-hours → /plan-ceo-review → /plan-eng-review → /plan-design-review → /review → /cso → /qa → /ship → /canary,一个改动走完整套,中间还各种 AskUserQuestion 等你拍板。对于一个要上线、要扛流量、Garry 那种"40 个生产功能"的正经项目,这套重甲是值的。
但如果我只是想周末写个小脚本、验证个想法、做个一次性的 demo 呢?这套流程的"完整主义"会变成沉重的仪式感。Boil the Lake 那张表里其实埋了答案——压缩比最低的是"调研"和"架构设计"(3x、5x),这些恰恰是流程最重的环节。也就是说,流程越重的地方,AI 帮你省的时间反而越少,人要参与的判断反而越多。
所以我的判断是:gstack 的心法(那三条)是普适的,值得每个人内化;但它的流水线(那 50 个工具),是为"严肃的、要长期维护的、要上生产的"项目量身定做的。拿它去套一个玩具项目,你会被流程拖死。Garry 自己也在 ETHOS 里留了后手:湖才煮,海要标记出来别碰。而判断眼前这摊水是湖还是海,这个判断本身,恰恰是它交还给用户的、最不能自动化的那部分。
工具能帮你执行方法论,但"此刻该不该上这套方法论",还得你自己说了算。这又绕回了它的第三条心法:用户主权。挺自洽的。
写在最后:方法论正在变成可以编译的东西
我扒完 gstack 最大的收获,不是学会了那 50 个命令怎么用——说实话我一个都没背。我收获的是这个认知:
在 AI 时代,方法论第一次变成了一种"可编译、可注入、可强制执行"的东西。
过去几十年,软件方法论一直是"人学":敏捷、Scrum、TDD、SOLID,全是写给人看的,靠人的自律去执行。一个团队的工程文化好不好,取决于多少人真的把这些内化进了肌肉记忆。这个过程要好多年,而且会随着人员流动不断流失。
gstack 给我看到的是另一条路。它把一个二十年经验的工程领袖脑子里的世界观,压缩成一页 ETHOS.md,再通过 preamble 注入、模板生成、硬门禁这套机制,编译进每一次 AI 的工作流里。AI 不需要"学"这套方法论,它每次开工自动"加载"这套方法论,而且执行得比任何人都严格、都不偷懒。
这意味着什么?意味着如果你想造一个属于你自己的 gstack,你真正要做的,根本不是去写 50 个工具。你要做的是,把你自己对"什么是好软件、该怎么造"的世界观,先想清楚、写成一页纸,然后设计一套机制,让这页纸在每一次执行时都被强制运行。 工具有多少个不重要,那是鱼。那页纸 + 那套注入机制,才是渔。
这也是为什么我说,gstack 这个 50 个工具的库,真正值钱的只有一页纸。
你的方法论,值得被编译进每一次执行,最不应该的是，仅仅就躺在某个没人读的 wiki 里。（ps，我很讨厌文档，尤其是 AI 时代）
GitHub: https://github.com/garrytan/gstack
