夜雨聆风我最近做了一个很小的 OpenClaw skill。
功能很简单：每次回复前，先插一段小说。
第一次用，我觉得挺有意思。
用到第三轮，我就不想用了。
不是小说不好看。
是这个东西，出现的位置不对。
❶ 为什么会想到做这个
OpenClaw 回复本来就要等。
有时候几十秒，有时候更久。
这种等待不长，但足够打断注意力。如果这段时间能顺手看一点东西，理论上会很自然。
看小说是一个很轻的娱乐动作。不需要进入新页面，不需要切换上下文。如果能直接长在聊天里，可能会很好用。
我当时以为，我要解决的是"等待太无聊"。
后来发现，我真正碰到的是"摸鱼这件事应该长在哪里"。
❷ 这个 skill 到底做了什么
每次 OpenClaw 准备回复前，先输出一段小说。小说会和正常回复在同一个聊天流里出现。
安装和使用都很轻。几乎是一个很快就能跑起来的 POC。
从"能不能做出来"的角度看，这个东西几乎没什么阻力。
这个实验的问题，不在"做不出来"，而在"做出来之后，体验对不对"。
小说不是在"等待时出现"，而是"挤进了回答里"
❸ 需求验证：这件事不是完全错的
小说插进聊天里，确实会让等待没那么无聊。
至少"等的时候想看点东西"这个需求，是真的。
❹ 它不是"等待时看"，而是"回答里多了一段"
我原来以为用户会在等待时看小说。
但实际上小说是和回复绑定在一起出来的。它不是独立出现的体验。它只是附着在主回复上的内容。
问了一个问题，想看 OpenClaw 的回答。结果屏幕先出来一段小说。我扫了两眼，又往下拉去找答案。那一刻我就知道，这东西不对。
小说不是在利用等待，而是在放大等待。本来用户只是等一个回答，现在变成"先经过一段内容，再到答案"。
用户要的不是"答案里混进一段小说"，而是在等待答案的时候，有一个可以单独进入的摸鱼时刻。
❺ 这个形态天然不稳定
多聊几轮以后，摸鱼 skill 就不稳定了。体验不是一个稳定的存在，而是偶尔冒出来一下。
摸鱼最怕的不是弱，是不稳定。
skill 适合做一次"出现"，不适合做一个"长期存在的体验"。
❻ 真正的问题是什么：不是功能问题，是载体问题
我后来发现，这不是实现问题，也不是小说内容的问题。是 OpenClaw skill 这个载体本身有局限。
skill 天然附着在主流程上。它跟着回复走。它没有独立入口，没有独立节奏，不能平行存在。
而摸鱼的需求本质上是：独立、随时开始、随时停下、不干扰主任务、最好还能自己控制内容长度和节奏。
摸鱼是一个副线程需求。
但 skill 只能活在主线程里。
❼ 真正留下的，是三个条件
这次实验最后留下来的，不是一个功能，而是三个条件。
它得足够快，不要放大等待。
它得可控，用户要能自己决定什么时候开始、什么时候停。
它还得是一个入口，而不是附在回复上的"一段内容"。
如果它要成立，应该不是"附着在 OpenClaw 里的一个 skill"，而是一个和它平行存在的小入口。类似快捷键触发，类似 hover 弹出，类似独立悬浮层。只是点到为止，不是方案。
❽ 结尾
我现在还是觉得，这个方向是对的。等待回复的时候看点东西，也确实会让人快乐。
但这个版本，我不会继续用。
因为它解决的是"内容有没有"，不是"体验对不对"。
这次实验让我确认了一件事：
让人快乐的不是"聊天里多了一段小说"，
而是"等待这件事本身，被重新设计了"。
本文来自作者亲身经历，数据已脱敏
