夜雨聆风你以为雇了个助手，其实请了一整支团队。
前两天的一个读者群里，有人问了个很有意思的问题：
"朋友说装了个叫 gstack 的东西，送的 1000 额度，没用几天就见底了。gstack 到底是干嘛的？为什么 token 用得比别人快那么多？"
这个问题好。今天我们就来拆开看看，这个让无数人又爱又钱包疼的 gstack，到底是什么，以及它的 token 消耗速度为什么跟坐了火箭一样。
01 gstack 到底是什么？
先说背景。gstack 是 Y Combinator（硅谷最顶级的创业孵化器）CEO Garry Tan 开源的一个项目，挂到 GitHub 上之后，短短时间内就拿到了超过 68,000 颗星，热度非常高。
一句话概括，gstack 是一套给 AI 编程助手 Claude Code 用的「技能包」。
它做的事情很有意思：把一个通用的 AI 助手，拆成了一支专业的软件开发团队。装了 gstack 之后，你不再是对着一个"什么都能干"的 AI 说话，而是可以像老板一样，召唤不同岗位的"员工"来干活：
整整 23 个角色，从产品经理到设计师到架构师到安全官到测试到发布，一条龙全包了。
Garry Tan 自己给出的数据也很夸张：用 gstack 在 60 天内写了 60 万行生产代码，其中 35% 带测试，平均每天 1 万到 2 万行。
听起来像是 AI 时代的银弹对吧？
但银弹的背面，是账单。
02 先搞懂一个概念：token 是什么
在解释"为什么烧得快"之前，得先弄明白"烧的是什么"。
token 是 AI 模型处理文本的基本单位。你可以把它理解为 AI 的"注意力单位"或者"计费单位"。一段文字发给 AI，会被拆成一个个 token 来计算费用。
简单换算：大约 1000 个英文 token ≈ 750 个英文单词 ≈ 500-700 个中文字。
计费方式也很直接：你发给 AI 的内容（输入 token）+ AI 回复你的内容（输出 token），加起来就是这一轮对话的总消耗。
这跟手机流量包有点像。你看文字新闻，流量用得少。你刷高清视频，流量用得快。区别在于，AI 的这个"流量"消耗更加隐蔽，不太容易实时看到自己用了多少，等注意到的时候，往往已经见底了。
03 为什么 gstack 特别费 token？
这才是今天的主角。gstack 消耗 token 的速度之所以让人咋舌，根源不在"AI 变贵了"，而在它的设计架构本身。
原因一：每个角色都自带"超长简历"
gstack 里的每一个角色，都对应一个详细的 SKILL.md 文件，里面写满了这个角色的行为准则、工作流程、注意事项、输出格式要求。
每次你调用一个角色，这份完整的提示词就会被加载到对话上下文中。一份 SKILL.md 少则上千 token，多则数千 token。你同时激活三四个角色，光这些"系统开销"就已经上万 token 了。
打个比方： 就好比公司开会，每个人发言之前都要先念一遍自己的简历和岗位职责。会还没开始，时间已经花掉一半了。
原因二：多步骤流程导致"上下文膨胀"
gstack 的核心工作流是一条完整的开发链路：
需求梳理 → CEO 审查 → 设计审查 → 工程审查 → 编码实现 → 代码审查 → 自动化测试 → 安全审计 → 发布上线
问题在于，每一步都会把前面所有步骤的对话内容，一起带到下一步的上下文里。
到了最后一步 /ship 的时候，AI 需要处理的上下文，是前面所有步骤的对话总和。这在大语言模型领域有一个专门的术语：上下文膨胀（Context Bloat）。
打个比方： 你发了一封邮件只有一句话。对方回复你，这封邮件就包含了原始内容加回复。你再回复，又包含了前两轮的所有内容。邮件来回十几次，光看邮件头就要翻半天。
gstack 的多步骤流程就是这个逻辑。每一步都在往上下文里塞东西，而且不清理前面的。到最后，光"维持记忆"就是一笔巨大的 token 开销。
有社区用户在 GitHub 上提的 Issue 里说得很直白：
"每个新版本消耗 token 的速度越来越快。协议开销远超有用信息。"
这已经不是个别人的感受了，是一个普遍现象。
原因三：并行任务成倍消耗
gstack 不仅支持多步骤，还支持多任务并行。官方文档鼓励用户同时跑 10 到 15 个并行 sprint（冲刺周期），每个 sprint 都在独立消耗 token。
15 个任务一起跑，那就是 15 倍的速度在烧。
原因四：反复的自我审查和修正
gstack 的角色设计里，有很多"自我审查"的机制。比如 /review 会做结构级代码审计并自动修复，/qa 会在真实浏览器中反复测试直到通过，/cso 会做 OWASP Top 10 和 STRIDE 威胁建模。
这些角色不是跑一次就完事了。它们发现问题后会要求重新修改，然后再次审查，如此循环，直到通过标准。
每一次循环，都是新一轮的 token 消耗。
04 所以，gstack 到底值不值？
坦率地讲，这个问题没有标准答案，取决于你用它来做什么。
适合用的场景：
独立开发者或小团队，需要模拟完整开发流程 项目规模中等，需要多人角色协同把关 有充足的 token 预算或 API 额度 想要体验标准化的 AI 辅助开发流程
不太适合的场景：
只是写个小脚本、修个简单的 bug token 额度有限，想精打细算 项目很简单，不需要 23 个角色一起上
gstack 的价值在于把 AI 辅助开发的流程标准化了。从想法到上线，每一步都有角色把关，这个思路本身是非常有价值的。
但你要为这种价值买单。而且这个账单，可能比你想象的要贵。
05 想用的话，怎么省着点花？
如果你已经装了 gstack，或者正准备装，下面这几条建议应该能帮你省下不少 token：
1. 别一上来就全开
gstack 的设计是按需使用的，用哪个命令就加载哪个角色。刚开始挑最需要的两三个就行，比如 /review 和 /ship，够用了再加。
2. 精简流程，别步步走满
方向已经很清晰了，就没必要走完三轮评审再动手。省下来的 token，比省下来的时间更值钱，至少在额度有限的时候是这样。
3. 适时开新会话
如果发现对话已经很长了，可以考虑开一个新会话重新开始。每次新会话上下文从零开始，token 开销也从头算。别在一个会话里无限制地往下走。
4. 关注官方优化动态
社区对 token 消耗的讨论已经很多了，开发者也在关注这个问题。后续的 gstack 版本可能会有上下文压缩和编译策略方面的优化。
06 写在最后
聊到这里，其实有一个更大的问题值得想想。
我们现在用 AI，很容易陷入一种心态：越多越好，越全越好。能同时处理十个任务，为什么要只做一个？能调用二十三个角色，为什么要只用三个？
但资源从来都是有限的。你的 token 额度有限，你的注意力有限，你的时间也有限。
gstack 最大的价值，可能不是它能让你同时跑多少个角色，而是它让你看到了 AI 辅助开发的完整图景。知道有哪些环节可以做，然后根据自己的实际情况，选择性地去做。
知道「可以做什么」，和知道「应该做什么」，是两回事。
后者才是真正值钱的。
工具越来越强，但怎么用工具，这件事永远得靠人自己来想。
你觉得 AI 工具的 token 消耗，是越来越能接受了，还是越来越让人头疼？欢迎在评论区聊聊。
如果觉得这篇文章有帮助，欢迎点赞、在看、转发三连。如果想第一时间收到推送，可以给我加个星标。
谢谢阅读，我们下期见。
