我做了一个 OpenClaw Skill,让自己更容易坚持健身

练什么，我大致知道。

真正难的是，忙、累、状态差的时候，还能不能把这次训练记下来。

记录一断，反馈就断。

反馈一断，执行就更容易散。

记录最容易断掉，往往不是因为懒，而是因为太麻烦

练完已经很累，手机拿起又放下。

练完已经很累，不想再打开一个 app 慢慢填。

有时候只想随手说一句”今天练了胸”。

没睡好、出差、身体不舒服的时候，根本不想配合复杂流程。

连续几天没记，后面就更不想补了。

我想解决的不是”健身知识不够”，而是”记录这件事太容易中断”。

我最后没有做一个健身 App，而是做成了 OpenClaw Skill

这类需求天然适合对话式输入。

真实输入不会很标准，往往是：今天练了胸、深蹲 60kg 5×5、今天没睡好随便练了一下、这周可能只能练两次。

它不是表单，也不是固定模板，更像随手一句话。

这类需求很依赖上下文连续性。

用户不只是想”记一条”，还会接着问：今天练了什么、本周练了几次、最近是不是总在跳过某个部位、最近状态是不是不太稳定。

这已经不是单条记录工具，而是连续追踪。

skill 的价值就是降低进入门槛。

不是打开一个新产品，不是学习一套新流程，而是在原有对话里顺手完成记录、查询、反馈。

这个需求更像一个低摩擦的能力层，而不是一个独立工具。

我希望它记录的，不只是”练了什么”，还有”当时是什么状态”

大多数健身记录工具只关心动作、重量、组数。

但真正影响训练执行的很多时候不是动作本身，而是状态。

比如：今天很累、没睡好、在出差、某个部位不太舒服、这周整体频率会下降。

所以这个 skill 不只是记录训练，也记录状态。

对我来说，系统记录的不是”理想中的训练”，而是”真实发生过的训练”。

我最后只保留了四类最关键的输入

四类输入，覆盖了最关键的能力边界。

我一开始想塞进去的东西更多。后来发现，越多越难长期用。最后只剩下这四类。

1）训练记录：今天练了什么、某个动作多少重量、多少组。

2）状态记录：今天很累、没睡好、出差、某个部位不舒服、这周频率受限。

3）报告查询：今天练了什么、本周练了几次、最近状态如何。

4）计划管理：记录计划版本，追踪当前执行的是哪一套方案。

一个 skill 不是功能越多越好，而是边界越清楚越好。

我最在意的设计原则，其实只有一个：低摩擦

我后来发现，真正决定一个工具能不能被长期用下去的，不是功够不够全，而是摩擦够不够低。

能一句话完成，就不要两步。

不要让用户选分类、填表单、手动整理结构。

模糊输入也要能接住。

像”今天随便练了下胸”这种话，不应该因为不够标准就被丢掉。

同一条消息可以混合记录，训练 + 状态，不需要拆开发。

查询要立刻给结果。日报、周报、阶段总结要直接可读，而不是堆一堆原始数据。

真正开始使用后，我才意识到：可用性细节比”能不能做”更重要

旧数据要兼容。历史记录格式变了，不能要求用户从头开始。

训练 session 要自动处理，”开始练”和”练完了”之间，最好由系统自己接住，不要把流程管理丢给用户。

时间判断一定要对。用户问”今天练了什么”，系统对”今天”的理解不能错。

状态和训练要能一起存。现实输入不会那么规整，系统要接得住”训练 + 状态”的混合表达。

demo 能跑，不等于真的能用。真正可用的 skill，最后拼的是这些细节。

这件事让我更确定：很多场景里，skill 不是附加功能，而是系统补丁

skill 不是附加功能，而是把系统补到能用。

Agent 本体擅长理解、生成、对话。但很多真实场景还需要另外几层东西：持续状态、结构化历史、稳定触发规则、长期追踪、低摩擦交互。

skill 不是”多一个功能”，它更像是把 Agent 从”能说”往”能用”推进的一层系统能力。

结尾

做完这个 skill 之后，我对”有用的 AI 系统”这件事反而更清楚了。

真正有价值的，不一定是功能最多的系统，而是那个最愿意顺着人性工作的系统。

这个 skill 现在已经放到 ClawHub 了，名字是 fitness-coach-lite。