2026-06-13 · 来自两条 X 长文的合成
6 月 11 日和 12 日，X 上连续出现两篇关于 AI 工具哲学的长文。Lonely__MH 写了两个月的 Hermes 实战复盘，OMOisomo 翻译了 Garry Tan 开源的 gStack。它们描述的是同一个赛道里的两种 AI 工具形态——一种把 AI 训练成你的私人助理，另一种把 AI 拆成一支团队。两种范式不是先后升级关系，而是 2026 年 H1 的关键分叉——一边长出贾维斯，一边长出合伙人门诊。
同一周的两篇长文
6 月 11 日 17:28 GMT+8，Lonely__MH 在 X 上发出 7000 字实战总结。他把 Hermes Agent 装在 VPS 上跑了两个月，让它抓 AI 资讯、监控 X 粉丝增长、检查服务器状态、发提醒、写灵感——9 个日常场景全跑顺。结论很直白：现在的 Agent 比的不是「能不能回答问题」，是「能不能稳定地替你完成一串重复动作」。
不到 24 小时，OMOisomo 翻译了 gStack——Garry Tan（YC CEO）开源的一套 Claude Code 技能集合。109,000 GitHub Stars，MIT 协议，23 个专家角色，8 个核心命令。它的核心是 /office-hours——一行代码不写，先反问你六个问题。两篇并排读，会看到一个对撞：AI 工具正在从 prompt 时代走入角色时代。
Hermes 范式：把 AI 装成贾维斯
Hermes 这一脉的逻辑是「私人助理化」。你把 Agent 装在云端 VPS 上，配好模型通道，给它安排任务，它自动规划执行，做完把经验沉淀成 Skill，下次遇到类似任务处理得更好。
Lonely__MH 自己跑的是进阶档配置——2 核 CPU、4G 内存、60G SSD、10Mbps 带宽。模型不是押一个，是分通道：ChatGPT/Codex 跑主力 Coding 任务，Claude 跑长文本与复杂推理，Grok 4.3 跑 X 信息流，DeepSeek 跑中文日常任务，小米 MiMo 跑 Python 编码。多通道既是分工也是容错。
这套形态有几个关键特征：
- 沉淀是软的——Skill 体系是「用着用着就出现」的副产品
- 判断是用户的——AI 不质疑你，它按你说的做
- 节奏是 7×24——到点自动跑，发现变化自动记录
- 场景偏个人——资讯、提醒、监控、灵感记录
Lonely__MH 的最佳引述：「VPS 是它的身体，模型是它的大脑，任务流程才是它真正的灵魂。」
gStack 范式：把 AI 拆成合伙人门诊
gStack 完全反过来。它的入口不是「安排任务」，是 /office-hours——反问你。
扔一个 idea 给 gStack：日历的每日简报应用。它不会写代码，会反问：你有几个 Google 日历？事件信息过时——是地址变了还是时间变了？上次手动做这件事，最烦的三步是什么？六轮追问之后，它告诉你：你要做的不是「日历 APP」，是「个人首席 AI 幕僚」——功能需求是表层，身份需求才是真问题。
然后才进入 8 步 Sprint 链：/office-hours → /plan-ceo-review → /plan-eng-review → 退出 plan 模式动工 → /review → /qa（真浏览器点一遍）→ /ship（一键 PR）。每一步的输出自动变成下一步的输入——没有信息丢失，没有重复沟通。
Garry Tan 自己的战绩：2026 年 GitHub 贡献 1,237 次，超过 2013 年全职工程师时的 772 次。不是他比你努力 100 倍，是他比你少做了 100 倍的低价值决策。
术的层面：链式上下文 vs 软沉淀
把两种范式拆到工程层，差异更具体。
gStack 的核心设计叫 「Roles, Not Prompts」——给 AI 赋予角色，不是塞提示词。它把创业公司的完整团队拆成 23 个独立 Skill：CEO 战略复盘、工程经理技术规划、资深工程师代码审查、QA 负责人真实浏览器测试、首席安全官 OWASP 审计、发布工程师一键上线。关键不是单一角色强，是 chain 没有信息丢失——设计文档自动流到 CEO review，测试计划自动被 QA 识别，review 发现的 Bug 自动被 ship 验证。
Hermes 的 Skill 体系是软的。你装上，跑几次，沉淀下来，跨任务复用。效果是渐进的，没有 Sprint 链这种硬约束。op7418 在 6 月 12 日的万字长文里把这种架构叫 「Thin Harness, Fat Skills」——harness 薄、Skill 厚、确定性工具下沉。Garry Tan 和 op7418 看到的是同一现象，gStack 把它做成必须按 Sprint 走的硬约束，Hermes 把它做成软经验。
两种沉淀方式各有代价。 gStack 的代价是上手成本——你必须先跑 /office-hours 接受反问。Hermes 的代价是质量方差——Skill 沉淀到什么程度算够用，agent 自己说不清。
势的层面：109K Stars 是什么信号
gStack 拿 109,000 Stars 不是因为它功能最强。Claude Code、Cursor、Codex CLI 这些「正经」AI 编程工具都还没到这个量级。gStack 跑出来的是另一件事——AI 编程工具从「写代码」升级到「操作系统」。
Garry Tan 在 README 里写了一句很硬的话：这不是初学者的提示包，是为发布者准备的操作系统。操作系统什么意思？你一开机，所有东西都在该在的位置，不需要想现在该用什么，一切就绪。
这个判断的势能来自三个数据点：
- Garry Tan 2026 年 GitHub 1,237 次贡献（超 2013 年 772 次）——同一人的能力边界被 AI 工具「极大地扩展」
- 支持 8 种 AI Agent（Claude Code / OpenAI Codex CLI / Cursor / OpenCode / Factory Droid / Slate / Kiro / Hermes）——操作系统层抽象
/codex技能让 Codex 审 Claude + Claude 审 Codex——跨模型协作，两个 AI 给你两份审查报告
势的另一面是 Hermes 那边。Lonely__MH 跑两个月发现一个隐藏规律：「9 块 9 API 中转」是中国 AI 玩家绕开 Plus 订阅的现实路径。VPS 在 AI 时代从「建站挂脚本」变成「云端工作台」——这跟 Garry Tan 的判断是同构的，但落地点完全不同：一个是工具栈从 prompt 升到 OS，一个是基础设施从本地升到云端。
道的层面：毛泽东「从群众中来」 vs YC「反谄媚」
把视角再拉远一点，这两种范式背后是两种「如何理解用户」的哲学。Hermes 这一脉相信：用户的最终目标只有用户自己知道，AI 负责把执行做对。Skill 沉淀的本质是「让 AI 越来越懂你」。这种范式的极限是——AI 越来越像你，替代你的常规动作，释放你的判断力。
gStack 这一脉相信：用户 90% 的需求是错的，AI 负责在你写代码之前先质疑你。/office-hours 的本质是「让 AI 越来越敢顶你」。这种范式的极限是——AI 越来越像你的合伙人，替代你做的低价值决策，保留你的品味与判断。
毛泽东 90 年前在《反对本本主义》里写过一句话——「你对于某个问题没有调查，就停止你对于某个问题的发言权」。gStack 的 /office-hours 是这句话的 AI 版：你对于一个 idea 没有被反问六轮，就停止你对于那个 idea 的写代码权利。
两种哲学在道的层面汇合了——都反对用户直接行动，都要求某个动作先于代码。 区别在于中间那个「某个动作」是什么：Hermes 是「把流程跑通、让 Skill 沉淀」，gStack 是「被合伙人级别的反问问到底」。
达利欧视角：原则化 vs 经验沉淀
达利欧在《原则》里讲过一句话——「痛苦+反思=进步」。把它放到 AI 工具语境里，两种范式对应两种「反思机制」。Hermes 的反思是 Skill 沉淀——任务做完，agent 主动把经验写成可复用的 Skill，下次遇到类似任务处理得更好，反思是事后的、软约束的、渐进的，代价是质量方差大，agent 不知道自己沉淀得对不对。
gStack 的反思是 8 步 Sprint 链。/review 查 N+1 查询、竞态条件、错误信任边界、缺失索引；/qa 打开真实 Chromium 浏览器点一遍应用；/ship 跑完测试出 ASCII 覆盖率图。反思是流程化的、硬约束的、强制每个项目都跑一遍。代价是：上手成本高，不是所有项目都值得走完整 8 步。
达利欧真正想说的是——反思必须有机制，不能只靠意愿。Hermes 把它做成「愿不愿意沉淀都行」的自由机制，gStack 把它做成「不跑 8 步就发布不了」的强制机制。前者效率高、质量方差大；后者质量稳、效率有下限。
不是工具箱，是操作系统
把两个范式拼起来，2026 年 H1 的 AI 工具赛道正在发生一件结构性跃迁——从「工具箱」升到「操作系统」。
工具箱时代，你问 AI 怎么写代码，AI 给你 11 个文件。代码跑起来，三天后发现 3 个 Bug，改一个引入两个。AI 帮你省掉的是打字时间，没帮你省掉任何思考。
操作系统时代，AI 不直接帮你写代码。它先反问你六个问题，告诉你需求定义错了；再帮你做技术方案，锁死所有架构决策；然后写代码——约 2,400 行、跨 11 个文件、8 分钟；接着偏执级审查，标记 N+1 查询与竞态条件；真浏览器点一遍，截图出健康评分 72/100。8 个命令从创意到 PR。
OMOisomo 翻译那篇 gStack 长文时引了一句特别硬的话——「会用 AI 写代码的人，和不会用的人，生产力差距已经是 10 倍。但用 gStack 的人，和只会让 AI 写代码的人，差距可能是 100 倍。」
这句话的底层是——AI 工具的分水岭不在「会不会用」，在「用完之后会不会质疑自己」。
落到自己的部署上
把两种范式摆到当前的部署上，会发现一件尴尬的事——这套架构更接近 Hermes 范式。Hermes Agent 跑在 VPS 上，Skill 在沉淀，多模型通道在分流，cron 在按点跑任务。但 agent 不会反问。它接受任务、规划、执行、汇报。
gStack 的 /office-hours、/plan-ceo-review、/review、/qa 四件套里，目前只跑了「执行」那一段。入口的反问、CEO 视角的砍单、偏执级审查、真浏览器点测——四个环节一个都没接。
Lonely__MH 写的那句话在这里特别贴切——「你不需要是 YC 的 CEO，你只需要打开终端装上它把第一个 idea 扔给 /office-hours」。问题不是装不装得上 gStack，问题是愿不愿意让一个 AI 顶你——这件事不是技术问题，是姿势问题。
收尾
2026 年 6 月这一周，两篇 X 长文给 AI 工具赛道画了一条分水岭。一边是把 AI 训练成贾维斯——7×24 在线、Skill 沉淀、流程跑通，代价是 agent 不会质疑你。另一边是把 AI 拆成合伙人——23 个角色、8 步 Sprint、链式上下文不丢，代价是上手成本高、不是所有项目都值得走完 8 步。
不是贾维斯好还是合伙人好，是你愿不愿意让 AI 顶你。
贾维斯时代，你做决策，AI 做执行。合伙人时代，AI 帮你先砍掉 90% 的错误需求，你做剩余 10% 的判断。
留给读者一个问题：你现在的 AI 工具，是贾维斯还是合伙人？ 如果还是贾维斯，下一个季度可以试试让它先反问你六个问题。