夜雨聆风
Y Combinator CEO Garry Tan 从2025年底开始每天写到凌晨2点。不是因为焦虑，也不是因为失眠，是因为他搭了一套个人 AI 系统，好用到停不下来。
这套系统不是某个超级提示词。是一个 runtime（OpenClaw/Hermes Agent）做路由，100多个 markdown 技能文件做业务逻辑，10万页结构化知识库（GBrain）做记忆。全部开源。GStack 在 GitHub 上 87k+ stars。
但更重要的是他怎么用这套系统——以及这些用法里哪些是真的有用，哪些只是听起来很酷。这是一个值得深入拆解的问题。
先说一个容易被忽略的前提：Garry Tan 的这套系统能跑起来，不是因为他技术多强，是因为他的信息密度极高。作为 YC CEO，他每天接触大量创始人、投资决策、行业趋势。普通开发者的日常信息量可能只有他的十分之一，这意味着知识库的增长速度会慢得多。这不是说普通人不该搭，而是要调整预期——你的系统不需要10万页也能很有用。
架构：Thin Harness, Fat Skills, Fat Data
Garry 把系统拆成三层：
Thin Harness。 OpenClaw/Hermes Agent 只做路由——收到消息，判断该调哪个 skill，分发。几千行代码，不承载任何业务概念。它不知道什么是"书"，什么是"会议"，这些语义全在 skill 文件里。Runtime 就是路由器，不多不少。
Fat Skills。 100多个技能文件，每个专注一件事。book-mirror 做读书镜像、meeting-prep 做会议准备、enrich 做信息补全。技能之间可以互相调用——改进一个子技能，依赖它的所有流程自动变好。这个设计跟 Unix 哲学一脉相承：每个工具做好一件事，组合起来解决复杂问题。
Fat Data。 10万页知识库，每个人、每家公司、每次会议都有独立页面，互相链接、自动更新。这是整套系统最重的资产——也是最耗精力维护的部分。
模型层完全解耦：Opus 4.7 做精度任务，GPT-5.5 做召回，DeepSeek V4-Pro 做创意，Groq Llama 做速度。Skill 决定调哪个模型，runtime 不关心。就像你不会问"哪种编程语言最好"——不同的任务用不同的工具，这才是工程思维。
这个架构真正厉害的地方在于每一层可以独立迭代。改 skill 不碰 runtime，丰富数据不改代码，换模型不动逻辑。你可以从任意一层开始，不用一口气搭完。
Book Mirror：从翻车到靠谱
Book Mirror 是整套系统里最能说明问题的案例——不是因为它有多惊艳，而是因为它的迭代过程暴露了个人 AI 系统最核心的挑战：信任。
Garry Tan 让系统读完一本书后，逐章把作者观点映射到自己的真实生活。系统能做到这一点，是因为 GBrain 里存着他的完整上下文——家庭背景、职业经历、读过什么书、和谁聊过什么。第一次跑出来的结果很酷，但出了 3 个事实错误：说他父母离过婚（没有），说他出生在香港（在加拿大）。这些错误不大，但足以摧毁信任——如果你的 AI 连你家有几口人都搞不清，你怎么敢把投资决策交给它？
他的解决方案不是换更好的模型，是在 skill 里加了一步交叉验证：生成前先查证知识库里的已知事实。错误消失了，模型没换。
这个教训比 Book Mirror 本身更有价值：个人 AI 系统的第一优先级不是生成质量，是事实准确性。 一个偶尔输出平庸但从不造假的系统，远比一个文采飞扬但经常胡说八道的系统有用。因为你会信任前者，把越来越多的事情交给它——信任才是复合增长的前提。
Skillify：让系统自己长出新的能力
Skillify 是整套架构里最有野心的设计。遇到重复的工作流，Garry Tan 说一句"skillify this"，系统自动提取模式、生成技能文件、注册到路由器里去。下次遇到类似的任务，直接调度。
这听起来像元编程——用代码生成代码。但本质上它解决的是知识管理问题：你手动做了三遍的事情，第四次不该再手动。Skillify 就是把隐性知识显性化的工具。
技能之间可以组合。book-mirror 内部调用 brain-ops（知识库操作）、enrich（信息补全）、cross-modal-eval（跨模型评估）、pdf-generation（文档生成）。改进 enrich，所有依赖它的流程自动受益。这和软件工程里的模块化没有区别——高内聚、低耦合、可组合。
但 Garry Tan 没细说的一件事是：100多个 skill 的维护成本。每个 skill 本质上是一个精心设计的 prompt，当底层模型升级时，这些 prompt 的行为可能漂移。这不是一次性工程，是持续运营。想想你维护过的大型配置文件——当它增长到一定规模，改一处怕牵连其他地方。Skill 文件也有这个问题，只是 Garry 还没到那个痛点。
Cron Job 才是真正的引擎
100多个定时任务在后台跑：会议录音自动转写、邮件每10分钟分类、社交媒体自动归档、知识图谱定时丰富。
这些 cron job 才是让10万页知识库"活"起来的东西。没有它们，知识库就是一堆静态 markdown 文件。有了它们，你睡觉的时候系统在整理信息，你醒来的时候准备工作已经做好了。
其中最精巧的机制是实体传播：每次会议结束后，系统不只保存会议记录，它会遍历会议中提到的每个人和每家公司，自动更新他们各自的知识页。一次对话，多个实体页面同时更新，知识网络自动扩张。你不需要手动"归类"信息——系统自己把该连的点连上了。
这才是"第二大脑"和"文件柜"的本质区别：文件柜存东西，第二大脑让东西之间产生连接。
冷静看：三件 Garry 没说的事
Garry Tan 是 YC CEO，他写文章有传播目的。读的时候需要过滤。
第一，信息密度不等于系统价值。 Garry 每天10+小时在高密度信息环境里（见创始人、看项目、聊行业），知识库的增长是自然的。普通开发者每天的有效信息输入可能只有他的十分之一。10万页的知识库对他来说是资源，对你来说可能是噪音——因为大量页面可能是空的或者过时的。
第二，97.6% 召回率是自测数据。 GBrain evals 是 Garry 自己的 benchmark。LongMemEval 是公开测试集没错，但"在自己设计的系统上跑公开测试集"和"第三方独立验证"之间有很大距离。AI 领域的 benchmark 和真实体验之间的鸿沟，这个领域的人心知肚明。
第三，Skillify 的门槛比听起来高。 "提取可复用模式"需要你对工作流有足够清晰的认知。大多数开发者第一次 skillify 出来的东西，大概率像第一次写单元测试一样——形式对了，但 captured 的不是真正重要的 invariant。需要多次迭代，而迭代的前提是频繁使用，频繁使用的前提是养成了习惯。这不是工具问题，是习惯问题。
从哪里开始
Garry Tan 的系统最值得学的不是任何具体工具，而是一个信念：今天的投入会让明天更强，而 AI 是放大这个效应的杠杆。
不用一上来就搭100个 cron job。从这个循环开始：做一件事 → 发现重复了 → 提取成 skill → 改进 skill → 用 skill 做更多事。这个循环转起来之后，系统自然会长成你需要的形状。
从"一个 skill + 一个数据文件"开始，就已经比99%的人走得远了。系统不在大小，在于它是否每天都在替你积累。
GStack 开源地址：github.com/garrytan/gstackGBrain 开源地址：github.com/garrytan/gbrain
