今天下午微信群里在聊 Hermes 和 OpenClaw。

有个群友说了一句挺有代表性的话：这些工具本质上都是过渡性的炮灰产品。大模型迟早会把这些能力自己集成掉，应用层工具不会有什么位置。

我觉得他说得没错。

但也只对了一半。

这些工具当然是实验性的，甚至很多现在看起来很热闹的东西，过半年可能就没人用了。AI 时代的工具淘汰速度太快了，今天刚搭好的工作流，明天模型一更新，可能就直接原地报废。

但问题是，作为个人，我们参与这些“炮灰产品”的意义，不一定是押注它们能活多久。

真正有价值的是：你在亲手折腾这些工具的过程中，会被迫理解它们到底是怎么工作的。

这几天我在开发 ShareThis.Chat，感受特别明显。

一开始需求很简单：我在用小龙虾和本地各种 Agent 时，想分享一段聊天内容非常麻烦。要么截图，要么一条条复制粘贴。截图不方便检索，复制粘贴又很蠢，尤其是一段对话很长的时候，简直是在折磨自己。

所以我做了 sharethis.chat。

它的核心功能也不复杂：把聊天内容整理成一个可分享的链接，同时支持把完整内容以纯文本复制出来。对别人来说可能只是个小工具，但对我自己来说，这就是每天都会用到的基础设施。

有意思的是，真正让我收获最多的，不是把网页做出来，而是给 Agent 写技能文档。

因为我要让 Agent 学会“怎么正确分享一段聊天”，就必须想清楚很多细节：

哪些内容应该保留？
哪些元数据必须删掉？
工具输出能不能信？
token 应该怎么保存？
语音消息要怎么标记？
代码、日志、JSON、CSV 这种结构化内容要不要原样保留？

最开始的 Skill 文档，其实只有一句话。

后来慢慢写到了百来行。

听起来很夸张，但这些规则只是为了让 Agent 更好地处理“分享聊天内容”这么一个小功能而已。你真正写进去之后才会发现，看似简单的功能，里面全是边界和坑。

也因为这个过程，我顺便理解了 Claude、Codex 这类 Agent 在处理消息、工具输出、本地文件、敏感信息时的一些设计取舍。

这就是我觉得“实验性工具”有价值的地方。

它们可能不是终局，甚至大概率不是。但你亲手做一遍，就会知道哪些东西是模型能力问题，哪些是产品设计问题，哪些是安全边界问题，哪些是纯粹的工作流细节。

等以后更成熟的工具出来，你也不会只是一个被动使用者。

你会更清楚它哪里好，哪里烂，哪里可以改，哪里只是包装得很漂亮。

所以我并不太在意这些工具最后是不是炮灰。

炮灰也没关系。

在炮灰堆里摸爬滚打过的人，至少知道战场长什么样。