一堆 Markdown 文件，凭什么值11万星？

"你知道吗，当我第一次看到 gstack 这个项目时，我的反应和你一样：'这怎么可能值11万星？'"

我打开仓库，看到的是一堆 Markdown 文件。没有编译器，没有运行时，没有 Docker 容器。就是——一堆文本文件。

我想，也许我错过了什么。也许有个隐藏的 Python 脚本，或者某种我看不到的框架。我仔细检查了每一个目录。没有。真的就是一堆文本。

然后我开始阅读它们。然后我开始理解。

让我告诉你发生了什么。

一、先忘掉 "37K 行/天"

Garry Tan 说他一天写 37,000 行代码。Hacker News 上吵翻了。有人说这不可能，有人说这全是配置文件，有人说这是 AI 的功劳。

这些争论都错了。

37K 行这个数字，就像费曼说"那个保险箱的密码是三个数字"一样——有趣，但和本质无关。真正的问题是：他是怎么做到的？

答案不是"他用了什么神奇工具"。答案是：他把工作流程变成了纪律，然后把纪律写成了角色。

让我用费曼的方式解释：想象你是一位厨师。你每天都要做同样的几道菜。有些人靠肌肉记忆，做了十年还是那几道菜。但有个厨师不一样——他每次做菜之前，都会问自己："我今天扮演的角色是什么？是"创意主厨"还是"品控员"？"

如果是"创意主厨"，他就自由地尝试新配料。如果是"品控员"，他就严格检查每一道工序。

gstack 做的就是这件事：给 Claude 一套"角色切换器"。

二、35 个斜杠命令，每个都是一扇门

/qa → 切换到 QA 模式
/office-hours → 切换到创业导师模式
/review → 切换到代码审查模式

每个命令本质上就是一个角色切换器。它告诉 Claude："现在你不是通用助手，你是专门做这件事的人。"

这听起来简单。但让我告诉你为什么这比你想象的更有力量。

你有没有遇到过这种情况：你请 Claude 帮你写代码，它写得不错。然后你说"帮我检查一下有没有 bug"，它检查得很敷衍。然后你又说"帮我写个文档"，它写得很套路。

为什么？因为你没有给它一个角色。它不知道"检查"应该做到什么程度，不知道"写文档"应该像谁的风格。

gstack 的聪明之处在于：它不指望 Claude 自己知道该怎么做，而是明确告诉它"现在你是谁"。

/qa 的 Skill 文件里写满了这样的指令：

• "你是一个 QA 工程师"
• "你的任务是系统性地发现 bug，不是给出建议"
• "发现一个 bug 后，先记录，再修复，再验证，再写报告"
• "不要急着修完，要确保每个修复都经过验证"

这就是纪律。把"流程"变成"角色"，把"角色"变成"本能"。

三、真正值得偷走的三样东西

我翻遍了所有 35 个 Skill。大部分是给特定场景用的——比如 /i18n 是做国际化的，/sql-migrate 是做数据库迁移的。你未必需要这些。

但有三样东西，任何人都可以直接搬走：

1. QA 的闭环思维

gstack 的 /qa 不是"帮我测试一下"，而是**"发现→记录→修复→验证→报告"的完整循环**。

关键洞察：不要让 Claude 同时扮演"发现者"和"修复者"。让它先全力发现，然后你决定修复顺序，然后它修复，然后它验证，然后它写报告。

这解决了 AI 编程最大的陷阱：修了一个 bug，引入了两个新 bug，然后你以为"差不多了"。

2. 写代码前先重构需求

gstack 的 README 里有一个经典例子：不是直接说"帮我写个登录功能"，而是先说"把需求文档重构清楚"。

具体操作：

1. 把模糊的需求文档给 Claude
2. 让它先问 5 个澄清问题
3. 让它用用户故事格式重写需求
4. 然后再开始写代码

这省下的时间，比你省下的多十倍。 因为 AI 写代码很快，但写错方向的代码再重写，比人工写还慢。

3. 角色分离的元认知

这是最重要的，但也是最抽象的。

gstack 的核心理念是：不要让你自己同时是创作者、审查者和决策者。你每次只做一个角色。

/plan 时你是战略家。/code 时你是工程师。/review 时你是审查员。/qa 时你是测试员。/office-hours 时你是创业者。

为什么这有效？因为人类的认知资源有限。你不可能同时保持"创意发散"和"严格审查"两种心态。 AI 也一样。

四、一个类比：为什么这是"费曼式"的解决方案

费曼曾经讲过一个故事：有人问他，你是怎么解决那个那么难的物理问题的？

他说："我没有解决它。我只是把它拆成了足够小的部分，让每一块都简单到不可能出错。"

gstack 做的就是这样的事情。

它没有发明新的编程语言。没有造新的框架。没有训练新的模型。它只是把"软件开发"这个复杂到不可能一次性做好的事情，拆成了 35 个角色，每个角色只负责一小块，让每一块都简单到不可能出错。

这不是技术突破。这是认知突破。

五、那 11 万星到底值不值？

我的判断：10 万是追星，1 万是真的在实践。

如果你属于那 1 万——你已经在用 Claude Code，你想让它更"有纪律"，你想减少"差不多就行"的幻觉——那么 gstack 值得你看。

但不要全盘照搬。35 个 Skill 里，你真正需要的可能是 3-5 个。把它们的精神搬走，写成你自己的 CLAUDE.md。

如果你属于那 10 万——你只是好奇"YC CEO 怎么做到一天 37K 行"——那么答案你已经知道了：不是因为他比别人快，是因为他把别人花在纠结上的时间，花在了执行上。

六、回到那个问题

所以，一堆 Markdown 文件，凭什么值 11 万星？

因为它们证明了一件事：在 AI 时代，最有价值的不是新框架，而是把旧流程变成新纪律的能力。

Garry Tan 没有写一行 Python 来让 Claude 更好用。他只是写了 35 份"工作说明书"，告诉 Claude 在不同场景下应该扮演谁。

这是每个人都能做到的事。但大多数人没有做到。

这就是为什么它值 11 万星。不是因为技术有多难，而是因为做到这件事需要的不只是技术——它需要纪律、品味和把流程写成角色的耐心。

而这，正是 AI 时代最稀缺的东西。

"我没有特殊的才能。我只是充满好奇心。"
—— 理查德·费曼（大概）

好奇心的下一步，永远是行动。

如果你现在想试一件事，不要装整个 gstack。只做一件：在下次让 Claude 写代码之前，先告诉它："现在你是一个需求分析师。在写代码之前，先问我 5 个澄清问题，然后用用户故事格式重写需求。"

看看会发生什么。我赌你会惊讶。

#AI编程 #ClaudeCode #gstack #开发者效率 #提示词工程 #YC #AI工作流 #角色切换