当你的AI助手缺少某个能力，是每次都让它自己想办法，还是花半小时构建一个可重复调用的技能？

我遇到了一个典型场景：自己维护了一个小规模链上服务，需要检查钱包余额、提交交易、监听链上事件。可每次让 OpenClaw 帮忙处理这类任务，它要么凭空编造结果，要么反过来让我自己去敲命令。两种体验都不好。

正方逻辑是——反正助手可以试着理解需求，临时调用外部接口，何必再封装一层？省时间，也保持对话的灵活性。但实际效果是，每次都得重新描述上下文，推理链路一长，它就容易在中间步骤“遗忘”真实的 API 结构。也许能偶尔撞对，却不可靠。

反方主张建一个技能。技能在 OpenClaw 里就是一个 SKILL.md 文件，没有额外的配置文件，不需要注册指令，也不跑 npm install。写完 markdown，系统就能学会在合适的时候启用它。这相当于把一次性理解固化成可信的工具调用路径。

我从反对者的视角下手，花 30 分钟搭了个钱包检查技能。骨架很简单：YAML 前置信息里，名称和 description 最关键，尤其是 description——它决定了系统何时该用这个技能。我把它写成决策树：当用户想要查询余额、验证地址、或获取代币持仓时，就调用此技能。下面再补充快速开始示例和环境配置。

技能还能挂接真正可执行的工具。格式是声明参数，后接沙箱内运行的脚本。例如我做的 check-balance 工具，接收地址和可选代币种类，脚本用 curl 请求链上服务 API，把真实数据拉回来。调用它时，不再猜测，直接拿到可靠结果，再转成自然语言返回。没有幻觉，也不需要人工干预。

构建了几个技能之后，我筛出三条真正管用的规则。第一条，description 必须精确到动作，像“当用户想查余额时使用”，而不是宽泛的“与钱包相关”。第二条，工具脚本跑在沙箱里，所以哪怕在脚本里写死 API 密钥，也不会污染宿主系统——但这也意味着脚本需要独立完成所有网络请求，不能依赖外部状态。第三条，每次新增工具后，用简单提问验证助手会不会自动调用它，如果不会，回头改 description 的措辞，这是调试成本最低的闭环。

经过这些实践，我对技能路线的态度更明确了。如果你的需求是单次、临时、不太在乎准确率，那每次都让助手自己想办法也许就够。但若任务需要反复执行，或者你无法忍受任何一次错误，那么花半小时沉淀一个 SKILL.md 就是效率最高的投资。

因为这半小时写完的东西，会变成可重用的资产，让 AI 助手更像可编程的工具链，而不是一个时灵时不灵的对话窗口。下次再碰到类似需求，你连半小时都不用再花。