86 · 日更04

AI工作台 / CONTEXT / SYSTEM DESIGN

AI 最贵的，不是模型，是上下文

——真正强大的系统，不是什么都装，而是知道什么时候调用什么

❯ 2026.06.16　❯ 约 4607 字　❯ 阅读约 15 分钟

今天凌晨，我做了一件很不性感的事。

不是追新模型。

不是测试新工具。

不是写一个更复杂的 Prompt。

而是在清理我的 AI 工作台上下文context。

这件事听起来非常技术，甚至有点无聊。但它给我的触动，比最近很多 AI 热点都大。

因为我突然发现一个很扎心的事实：

我的 AI 不是不聪明，是我让它每天上班前，先背完三百本操作手册。

它还没开始干活，就已经累了。

更准确地说，不是模型不够强，是我把太多东西塞进了它的脑子。

大家看下我这是我自己搭建的AI内容生成工作台，通过hermes搭建一个工作台用三国十二营的方式去操作多个agent一起干活。

一个真正能长期运转的 AI 系统，不能只靠一个聊天框。它必须有身份、有规则、有工具、有知识、有记忆、有复盘。

问题在于，我以前没有认真区分一件事：

什么东西应该成为“资产”，什么东西正在变成“上下文负债”。

这两个东西看起来很像。

比如 Skill。

它当然是资产。

一个写公众号的 Skill，一个做小红书卡片的 Skill，一个抓 AI 热点的 Skill，一个整理 Obsidian 的 Skill，都是能力模块。

但如果这些东西每次对话都挤进上下文，它就不再只是资产了。

它开始变成负债。

就像一个公司请了很多专家，本来是好事。

但如果老板每开一个 10 分钟的小会，都要求全部专家先把自己的简历、工作手册、历史项目、服务边界念一遍，这个公司就完了。

不是专家不行。

是会议系统有病。

今天真正刺到我的，是一个很具体的场景。

我本来只是想输出一篇公众号内容。

结果写着写着，话题变成了：为什么我的 AI 工作台上下文越来越重？为什么一个原本应该很轻的写作任务，会被一堆历史规则、Skill 描述、项目上下文、工具输出裹住？

我开始查。

这一查，就有点尴尬。

我现在的 Hermes 里，一共有 268 个 Skill.md。

这当然很强。

但如果把所有 Skill 全文加起来，字符量大约是 261,405 字符。

用非常粗糙的 token 代理估算，大约是 65,351 到 130,702 tokens。

注意，这不是模型后台精确计费数字，只是基于字符量做的粗略估算。

但这个量级已经足够说明问题。

一个 Skill 可能不大。

但 268 个 Skill 站在一起，就不是工具箱了。

它更像一个仓库。

而 AI 每次干活最怕的，不是没有仓库。

最怕的是你让它把仓库背在身上跑步。

我又看了几个常用 Skill 的大小。

AI HOT 这个 Skill，大约 14,475 字符，粗略估算 3,618 到 7,237 tokens。

Hermes 上下文优化 Skill，大约 8,525 字符，粗略估算 2,131 到 4,262 tokens。

OPC 写作 Skill，大约 4,466 字符，粗略估算 1,116 到 2,233 tokens。

日记写作 Skill，大约 3,949 字符，粗略估算 987 到 1,974 tokens。

度支曹变现判断 Skill，大约 2,463 字符，粗略估算 615 到 1,231 tokens。

Obsidian Skill，大约 1,264 字符，粗略估算 316 到 632 tokens。

单看都不吓人。

但问题是，它们不是孤立存在的。

真正吃掉上下文的，不是某一个大文件。

而是很多“看起来都合理”的东西，同时在场。

这才是最危险的。

❝

真正吃掉上下文的，不是某一个大文件，而是很多“看起来都合理”的东西，同时在场。

❞

我后来把今天的上下文拆了一遍，发现它至少有八类副本。

第一类，是系统规则副本。

比如我是谁，我怎么说话，什么事必须用工具，什么事不能猜，什么时候要读知识库，怎么保护隐私，怎么执行任务。

这些是底层规则，必须存在。

但它也是真实占上下文的。

第二类，是用户记忆副本。

比如我的身份、偏好、目标、常用项目、写作要求、内容标准、Obsidian 路径、AI 工作台设定。

这些很重要。

但如果记忆不分层、不压缩、不清理，它也会越来越像一张塞满便签的桌子。

第三类，是 Project Context 副本。

比如 CLAUDE.md 里的开发习惯、知识库规则、Git 规则、WeChat CLI、opencli、gstack 等。

这些能让 AI 更懂我的工作方式。

但如果今天只是写公众号，它仍然可能背着一整套开发规范进来。

第四类，是 Skill 注册表副本。

这东西更隐蔽。

即使没有真正加载某个 Skill，系统也会展示一长串可用 Skill 的名称和描述。

这当然是为了让 AI 知道自己有什么工具。

但从上下文角度看，它相当于每次开工前先递给 AI 一本“全公司通讯录”。

第五类，是长 Skill 全文副本。

比如今天我加载了辉哥奇谭写作 Skill，它会把完整写作规则放进上下文。

这很有必要，因为我要用它写文章。

但如果一个任务同时加载 AI HOT、度支曹、Obsidian、辉哥、知识秘境，再加上其他写作 Skill，事情就开始变味了。

你以为你在增强能力。

其实你在制造噪音。

第六类，是 Obsidian 文件读取副本。

我读 index.md、log.md，目的是定位资料、遵守知识库规范、留下操作痕迹。

这很正确。

但如果把大段笔记全文搬进对话，而不是只读索引、只取必要片段，知识库就从外部资产变成了上下文负担。

第七类，是工具输出副本。

每次搜索、读取、patch、终端命令，都会产生输出。

这些输出本来是证据。

但它们也会进入对话。

尤其是 patch，最容易制造重复：旧文本一份，新文本一份，diff 再来一份。

第八类，是 Conversation History 副本。

也就是我们前面说过的每一句话。

这类最容易被低估。

因为它不是一次性进来的，而是一轮一轮堆起来的。

就像房间不是一天变乱的。

是每次随手放一点，最后你发现桌面已经看不见了。

这件事真正让我警醒的，不是“token 很贵”。

说实话，单纯从钱上看，很多 token 也没贵到不能承受。

真正贵的是注意力。

是判断质量。

是系统稳定性。

是 AI 在一堆不相关规则里，找到当前任务主线的能力。

一个人开会也是这样。

如果你让一个助理帮你写一篇文章，只需要告诉他今天发生了什么、你想表达什么、读者是谁、用什么风格。

但你偏偏给他塞了：公司制度、十年前的项目复盘、三百个工具说明、全部客户画像、所有内容模板、过去一个月聊天记录。

他不一定会更聪明。

他更可能会失焦。

AI 也是一样。

我们总以为上下文越多，AI 越懂我。

但上下文不是越多越好。

上下文要“对”。

真正好的上下文，不是信息量大，而是当前任务命中率高。

这句话我今天体感特别强。

我以前经常说，AI 时代最重要的是提示词能力。

现在我觉得这句话不够准确。

更底层的能力，是上下文管理能力。

提示词是你临场说什么。

上下文是你让 AI 带着什么进入现场。

如果带错了，再好的提示词也像在垃圾堆上盖别墅。

❝

提示词是你临场说什么。上下文是你让 AI 带着什么进入现场。

❞

我给今天这个问题起了一个名字：上下文资产负债表。

能在正确时刻被调用的，是资产。

每次都强行塞进脑子的，是负债。

Skill 是资产。

但乱加载就是负债。

记忆是资产。

但不分层就是负债。

知识库是资产。

但全文搬进上下文就是负债。

项目规则是资产。

但不分项目隔离就是负债。

工具输出是资产。

但不压缩、不筛选、不复盘，就是负债。

这和个人成长很像。

我们读过很多书，收藏过很多课程，参加过很多训练营，保存过很多金句。

这些东西都叫“知识资产”吗？

未必。

如果它们只是躺在收藏夹里，从来不在正确时刻帮你做出更好的判断，它们只是心理安慰。

如果它们每次都干扰你行动，让你觉得“我还要再学一点、再整理一点、再准备一点”，它们甚至是负债。

AI 工作台也是同理。

强大的系统，不是把所有东西都塞进去。

强大的系统，是知道什么时候该调用什么，什么时候该闭嘴。

这个“闭嘴”，非常重要。

今天我做的清理动作，其实不复杂。

第一，把 reference 副本清零。

以前有些 Skill 或资料，会存在重复 reference 里。

这就像一份文件在桌面、下载、微信、云盘里各存一份。你以为自己很安全，其实你在制造混乱。

现在至少这一项清到了 0。

第二，Skill 按任务加载。

今天写辉哥奇谭，就加载辉哥奇谭。

如果要查热点，再加载 AI HOT。

如果要判断变现，再加载度支曹。

不要为了显得系统很强，开局就把所有营都叫到帐前。

中军帐真正厉害的，不是人多。

是调度准。

第三，Obsidian 只做事实来源，不做上下文垃圾场。

先读 index.md 定位。

再读必要页面。

读完在 log.md 留痕。

不要把 Wiki 当成可以随便全文复制进聊天框的材料库。

知识库的价值，是让 AI 在需要时去查，而不是每次都搬家。

第四，保留压缩机制。

现在 Hermes 的 compression 是开启的。

阈值是 0.45，目标压缩比例是 0.15，保护最近 8 轮上下文，context engine 是 compressor。

这些参数听起来很技术。

但翻译成人话就是：

当对话太胖的时候，让系统自动减肥，但不要把最近真正关键的东西减掉。

第五，项目隔离。

写作、开发、知识管理、抖音素材、公众号风格库，不应该全部混在一个大脑里，这里用worktree来做隔离。

这也是我最近越来越强烈的体感：

AI 工作台不是一个超级聊天框。

它应该是一家公司。

公司一定要分部门、分权限、分档案、分流程。

否则你只是把混乱升级成了自动化混乱。

这件事也改变了我对“AI 一人公司”的理解。

很多人一听 AI 一人公司，就想到：

我要用更多工具。

我要接更多 Agent。

我要搞更多自动化。

我要把自己变成钢铁侠。

但今天我更愿意反过来说：

AI 一人公司真正的起点，不是工具扩张，而是上下文治理。

你能不能让 AI 知道：

现在是什么任务；

这件事属于哪个项目；

哪些记忆必须调用；

哪些规则暂时无关；

哪些资料只需要检索，不需要全文进入；

哪些输出应该沉淀成资产；

哪些历史对话应该被压缩、归档、关闭。

这些听起来不像爆款课标题。

但它决定了系统能不能长期运转。

一个人的精力管理，本质上也是上下文管理。

你每天脑子里同时开着太多窗口，就会累。

你一边想课程交付，一边想短视频涨粉，一边想知识库整理，一边想客户合作，一边想家庭事务，一边想新模型更新。

最后不是你不努力。

是你的内存被打爆了。

AI 只是把这个问题照得更清楚。

它像一面镜子。

你怎么管理自己的注意力，最后就会怎么管理 AI 的上下文。

你自己乱，AI 系统一定乱。

你自己没有分层，记忆也会没有分层。

你自己舍不得删，系统也会越来越胖。

所以我今天最大的收获，不是找到某个配置参数。

而是一个更朴素的判断：

普通人用 AI，最容易犯的错，不是不会提问，而是不会管理上下文。

不会提问，最多是一次回答不好。

不会管理上下文，是整个系统越来越重，越来越慢，越来越贵，越来越失焦。

更可怕的是，它会给你一种错觉：

我已经有很多资产了。

我有很多 Skill。

我有很多笔记。

我有很多提示词。

我有很多自动化。

但你要问一个更残酷的问题：

这些东西有没有让明天的工作更容易？

如果没有，它们可能只是另一种形式的囤积。

我最近越来越觉得，长期主义不是不断增加。

长期主义也包括定期删除。

删除重复的。

删除过期的。

删除每次都被迫进入脑子的。

删除那些看起来很有用、但从来没有在关键任务里发挥作用的。

这不是断舍离。

这是系统投资。

投资不是买一堆资产。

投资是让资产形成回报结构。

AI 工作台也是一样。

真正值钱的，不是你装了多少能力。

而是这些能力能不能在正确时间，以足够低的成本，被正确调用。

这才是护城河。

写到这里，我突然觉得，今天这件事很适合做成一个小检查表。

每个正在搭 AI 工作台的人，都应该问自己五个问题：

第一，我的 AI 每次启动时，默认背了哪些东西？

第二，这些东西里，有多少是当前任务真正需要的？

第三，我的 Skill 是按需调用，还是为了安全感全量堆叠？

第四，我的知识库是在外部被检索，还是被粗暴搬进上下文？

第五，我有没有定期清理记忆、规则、工具输出和历史项目？

如果这五个问题答不上来，说明你的 AI 系统可能已经开始变胖了。

胖不是问题。

不知道自己为什么胖，才是问题。

今天这篇文章，其实不是写给技术人员的。

它写给所有想认真用 AI 改变工作方式的人。

因为未来几年，AI 工具会越来越多，模型会越来越强，Agent 会越来越像一个团队。

但真正拉开差距的，可能不是谁更早用了某个工具。

而是谁更早意识到：

AI 的能力，不在聊天框里。

在上下文系统里。

你管理上下文的能力，就是你管理 AI 团队的能力。

也是你管理自己注意力、知识资产和长期回报的能力。

今天凌晨，我清理的不是几个文件。

我清理的是一种幻觉。

那种“只要不断增加，系统就会越来越强”的幻觉。

现在我更愿意相信另一句话：

能被正确调用的，才叫资产。

不能被正确调用的，都是噪音。

而 AI 最贵的，从来不只是模型。

是上下文。

是你让它带着什么，进入每一次战斗。