最近在网上看到一个观点。在 AI 大模型时代，做一个产品，功能实现的边际成本很低，所以人会倾向于把产品功能做得很全，什么都想放进去。
但功能一多，核心功能就容易被淹没。而真正厉害的不是“什么都做”，而是“什么不做”。真正解决用户的核心问题，才是最重要的。
这和我最近的体验很一致。我觉得在 AI 时代，我们更要学会做减法。下面我用几个实际经历，讲讲怎么做减法，以及它的好处。
产品的减法
最近我做了一个 Hexo 博客插件，用来把博客里的原始图片复制到发布目录。一开始我的思路其实挺乱的。
作为程序员，我们习惯性的要很全面的思考问题。在产品边界已经比较明确时，全面考虑边界是必要的。但如果一开始就用“尽可能覆盖所有可能性”的思路做产品，就会像开头说的那样，什么都往里塞。
最后自己也分不清什么重要、什么不重要，逻辑还可能互相冲突，用户也看不懂这个产品到底解决什么问题。
后来我思考了一下，决定先规定这个项目解决什么问题，不解决什么问题。换成这种方式后，问题一下就清晰了，Spec 文档也明确很多。
我知道哪些不用考虑，哪些要认真处理边界情况。思考负担小了很多，最后做出来的东西也比一开始清晰得多。
Hexo 博客无法复制 Markdown 本地图片？我写了一个插件 | 搬砖的小明
Hermes Skill 的减法
前阵子我在用 Hermes，发现它会根据我的聊天记录自动创建技能，记录一些偏好。这个设计我一开始觉得挺好，但我实际去看技能文件的内容时，发现和我想的不太一样。
比如我一开始让 Hermes 去做内容收集。我会和 AI 聊一些通用的东西，比如内容收集一般放哪个目录，也会讨论某个具体的收集任务的要求。
但后来我看 AI 总结出来的技能，发现它把某个任务特有的信息也写进去了。也就是说，AI 在这个上下文里分不清哪些重要，哪些不重要。
于是我写了一个“创建技能的技能”。每次 Hermes 要创建新技能时，先调用它。这个技能除了规定基本格式，最重要的一条是先定义“做什么”和“不做什么”。
关键点就是“不做什么”。我在里面列了一些常见边界，比如不要把具体任务、项目经验沉淀到技能里，而是沉淀通用能力，后面用起来确实挺管用。
这样最直接的好处是，AI 调用技能时上下文更精确，不会夹杂太多没用的信息。任务完成得更稳，也更省 token。
OpenClaw 与 Hermes中的减法
把范围再放大一点，对比 OpenClaw 和 Hermes，我觉得两者最大的区别也在这里。
在 OpenClaw 里，默认会把用户各种偏好保存到 MEMORY.md 文件。我也按这个思路维护过，里面记了很多规则，每条规则还有很多细节，最后 MEMORY.md 很快就几百行了。
但实际效果是，AI 并不能一直准确按我的要求做事。
用了 Hermes 以后我发现，它说的“自进化”是后台跑任务，把最近聊天记录发给大模型，让它提炼出重要内容，再沉淀成一个 Skill。并且 Hermes 明确规定 Memory 不能太长，大部分内容要放到 Skills 里。
在用 Hermes 之前，我以为 Skills 必须是“放之四海而皆准”的通用技能，发到网上谁都能用。后来发现这个理解不准确。
Skills 不只可以是公共通用技能，也可以是对我个人“相对通用”的技能。比如我希望每次发一个链接给 Hermes，它都帮我提取原文并保存到 Wiki 目录。这个就是个人通用技能，也可以做成 Skills。
虽然 Memory 和 Skills 看起来都是 Markdown 文件，但运作原理完全不一样。
在 Memory 的设计下，每次 Agent 调用大模型时，都会把完整 Memory 文档发给大模型。比如 Memory 里有很多条规则，其中一条是收到链接就保存到 Wiki 目录并按某种命名规则执行，另一条是记 ToDo 时保存到 ToDo 目录并按另一套命名规则执行。
每次模型会看到完整的 MEMORY.md 文件，同时看到这些规则。于是当我真的发一个链接时，它有可能把信息搞混，没保存到 Wiki，反而存进 ToDo。
Skills 是一种渐进式加载策略。每次系统先把所有 Skills 的一句话描述 组成列表发给大模型，不会把每个 Skill 的详细步骤都一起塞进去。
当我发一个链接时，模型会在列表里匹配到“收到链接要保存到 Wiki”这个 Skill，再读取这个 Skill 的具体步骤，知道该放哪个目录、怎么命名。这个时候它不会读取 ToDo Skill 的细节，所以就不容易把文件误放到 ToDo 目录。
这本质上也是减法思维，把原本全部塞在 Memory 里的内容拆掉，最后变成一组清晰的 Skills。
我在“创建 Skills 的 Skill”里还明确了一条，如果一个技能要调用别的技能，就在文档里写明引用哪个技能处理哪个步骤，不要把别的技能内容再复制一遍。
还以“链接保存到 Wiki 目录”这个技能为例，它有可能收到微信公众号链接。微信公众号链接用常规加载逻辑拿不到正文，必须调用浏览器，再区分标题和正文，这本身又是一组步骤。
所以“提取微信公众号内容”本身就是独立技能。系统收到链接后，先加载“保存到 Wiki”的技能，再按里面的引用加载“提取公众号内容”的技能。这样每个技能都更专一、更简洁。
信息的减法
自从进入互联网时代，信息就一直很多。每天网上都有无穷无尽的信息，而人的信息处理能力是有限的，很容易焦虑。
到了 AI 时代，这个问题更重了，因为 AI 可以更快地产生更多内容。再加上 AI 自身发展很快，每天都能看到新模型、新工具、新进展，总之就是一直处在信息过载状态。
很多人看到这些信息，会担心自己落后，想第一时间了解每个工具，怕跟不上。但学习能力本来就有限，人就会越来越焦虑。
所以在 AI 时代，我觉得很有必要在“摄取信息”这件事上做减法。以我的经验，一个很关键的做法就是少看二手信息，多看一手信息。
Follow Builders
我最近找到一个 Skill，它每天会给我一篇汇总，整理社交媒体上国内外核心创作者的动态。
https://github.com/zarazhangrui/follow-builders/blob/main/README.zh-CN.md
它给我的信息不多，每天生成一个文档，大概十几条内容，每条内容用几句话总结观点。我快速浏览一遍，有兴趣的再点原版链接深入看。
这篇文章开头说的“产品要做减法”，我就是从这里看到后觉得有启发的。
它强调关注 AI 领域的 Builders（创造者），而不是网红。因为 Builders 真的在一线创造和做事，对问题理解更深，也更接近一手信息。
而那些流量很好的网红和自媒体，往往并没有深入做技术，更像是把别人的观点包装成流量故事，甚至会夸大、制造焦虑。结果是你看到大量二手信息，还会产生本不该有的焦虑。
比如一个 AI 工具确实有进步，能解决一些问题，Builders 通常更实在，会讲这个工具还有什么问题、在哪些场景下能做好任务。
但被低质量自媒体夸大后，就变成了 你还在用XXX吗？XX工具非常强，马上取代某个行业，你还不会用就要被淘汰了 之类贩卖焦虑的言论。
还有一点，这些 Builders 很多都是用英文发布。我英文勉强能看懂，但看中文还是更轻松。现在借助 AI 大模型，这个 Skill 给我整理的文档就直接是中文，语言压力也小很多。
Vibe Coding
Vibe Coding 这个词很多做 AI 编程的人都知道。我大概是去年五六月才知道，但这个概念其实在去年 2 月就被 OpenAI 联合创始人、前特斯拉 AI 负责人 Andrej Karpathy 提出来了。
有些人今年才第一次听说 Vibe Coding，开始学相关方法时，社区讨论都已经转向 Harness 编程、OpenSpec 等新概念了。
也就是说，一手信息早就出现了，但可能过了几个月才传到国内，再过几个月被中文自媒体和视频反复转述。等你终于看到时，常常已经是 N 手信息。
Harness 编程
前阵子 Harness 编程概念火起来时，我看到一些技术群里有人说，他们其实早就这么做了，而且已经做了一年。那一年里，很多同行还不知道这个概念或类似方法。
先把这件事做起来的人，往往能更高效完成产品开发，也更容易拿到领先优势。
模型排行榜
再举一个例子，大模型能力排行榜。
我一开始想看模型强弱，就去网上找榜单，先看到了 Open Router 的排行榜。可大家都说 Claude 很强，它却不在最前面，我当时很疑惑，还专门去和 GPT 聊了一下。
后来才明白，Open Router 这个榜是它自己平台的使用量排行。免费模型更容易冲到前面，但这不等于能力就更强。
相对更可靠的参考之一是 Arena。我在一些比较靠谱的公众号里，也经常看到他们引用这个网站。它看的不是单纯跑分，而是人类实际使用时的盲测结果，也就是测试者不知道自己用的是哪个模型。
后来我还是经常看到有人和我当初一样，对 Open Router 的排行不理解。也会看到有人转发来路不明的排行榜图片，然后问，某某模型不是不行吗，为什么还能排这么靠前。
这类困惑，很多时候就是一手信息没找准。有人发的图可能只是某类题目的跑分，定向刷题就能把分数做高。还有些榜单可能来自模型利益相关方，为了宣传效果，专挑有利角度测试，甚至直接编结论。
尤其现在的图片模型，已经能生成以假乱真的图片了，筛选信息、学会做减法的能力变得越来越重要。
这段不只是讲信息减法，也是在讲一手信息的重要性。两件事其实是密切相关的。
一个有价值的一手信息，常常会被改写成成千上万条相似、甚至添油加醋的二手信息。如果多关注高质量一手信息，不仅准确性更高，要处理的信息量反而更少，焦虑也会少很多。
如果觉得文章有帮助，欢迎分享转发，也欢迎关注我的公众号“搬砖的小明”，及时获取更新
