最近我对一件事感触特别深。
一个真正好用的 Skill，不是写出来的，而是在实战里一点点磨出来的。
这段时间我一直在折腾自己用 Rust 写的工具 apifire，以及基于它封装的一套 apifire-skills。
项目放在这里：
https://github.com/lispking/apifire-skills
一开始我也想得很简单：
Skill 这东西，把能力封装好、调用链路打通、参数设计清楚，差不多就算完成了。
但真把它丢到实际场景里去用，我才发现，事情远没有这么简单。
很多时候，“能用”只是起点，“好用”才是真正困难的部分。
Skill 不是你写完了就结束，而是你用起来才真正开始
程序员很容易有一种错觉：
“这个功能我已经实现了，说明它已经完成了。”
这句话在很多场景下没问题，但放到 Skill 上，往往是不成立的。
因为 Skill 和普通代码不太一样。
普通代码更关注的是逻辑是否正确、性能是否达标、边界是否覆盖；
但 Skill 作为一种更接近“使用体验”的东西，它除了要正确，还得顺手。
顺手这件事，光看代码是看不出来的。
你写的时候觉得设计很优雅，参数很合理，结构也很漂亮；
但真到自己每天去调用、在真实工作流里反复使用时，各种问题就会自己冒出来：
- 参数是不是太多了？
- 默认行为是不是不符合直觉？
- 报错信息是不是看起来很专业，但其实没法指导下一步？
- 返回结果是不是“技术上完整”，但“使用上没用”？
- 有些本该自动处理的事情，是不是还在让用户手动判断？
这些问题，只有在实战里才会暴露。
也就是说，Skill 不是写完之后再看效果，而是必须在使用中反过来定义它该长成什么样。
真正难的不是封装能力，而是降低使用成本
最近在做 apifire-skills 的过程中，我越来越明显地感觉到：
Skill 最难的地方，从来不是“把功能包起来”，而是“把使用成本打下去”。
很多 Skill 刚写完时，看上去其实都挺像那么回事：
但一到实际使用阶段，你就会发现，很多设计虽然“合理”，却并不“好用”。
比如有些 Skill，表面上只做一件事，实际上却要求用户提供很多上下文。
用户本来只是想完成一个动作，结果却要先理解你的参数设计、你的前置假设、你的输入边界。
这时候你就会意识到：
你虽然封装了能力，但并没有真正封装掉复杂度。
对作者来说，这个 Skill 已经很清晰了；
但对使用者来说，它可能依然很重。
而真正好用的 Skill，不是让用户觉得“这个设计挺完整”，
而是让用户觉得：
“我几乎不用思考，它就帮我把这件事处理掉了。”
这其实是在逼着开发者不断问自己一个问题：
现在这个 Skill，到底是在帮用户省事，还是只是把原本的代码接口换了一层皮？
这个问题很扎心，但特别重要。
很多问题，只有在实战里才配被发现
我现在越来越相信一件事：
纸面上设计出来的 Skill，和真实环境里跑出来的 Skill，往往不是同一个东西。
因为你在写的时候，脑子里默认的往往是理想路径。
你会假设：
- 输入是规范的
- 上下文是完整的
- 用户知道自己要什么
- 调用链路不会出意外
- 返回结果只要“正确”就够了
但真实环境从来不按这个剧本走。
一旦上实战，问题会变得非常具体：
- 输入不完整怎么办？
- 用户表达得很模糊怎么办？
- 多步骤调用中某一步失败了怎么办？
- 返回了很多结果，但用户其实只关心结论怎么办？
- 一个 Skill 的边界划得太细，导致用户得连着调用好几个 Skill 才能把事办完，怎么办？
这些问题不是代码层面的问题，至少不只是代码层面的问题。
它们更像是“产品体验问题”。
而这也正是 Skill 最有意思、也最折磨人的地方：
你以为自己在写工具，最后你会发现，你其实是在做产品。
好用，是一轮一轮返工出来的
如果让我总结最近做 apifire-skills 最大的感受，那就是一句话：
好用这件事，没有一次到位，只有反复返工。
流程通常都是这样的：
先写出来。
然后拿去实际使用。
接着发现这里别扭、那里不顺。
再回来改参数、改提示、改默认行为、改边界设计。
改完继续用。
继续被真实场景教育。
然后再改。
这个循环听上去很朴素，但真正做起来特别消耗耐心。
因为它意味着你必须不断推翻自己之前“已经差不多了”的判断。
有时候你优化的不是核心逻辑，而是一些看起来很小的细节：
- 一个参数名是不是足够直观
- 一个默认值是不是符合大多数场景
- 一段错误提示是不是能让人马上知道该怎么补救
- 一个步骤是不是根本不该暴露给用户
- 几个 Skill 之间的职责是不是拆得太碎了
这些细节单独看都不大，
但真正的“好用”，往往就是这些地方一层层堆出来的。
半小时能写出来的，通常只是功能，不是产品
这也是我最近特别强烈的一个感受。
很多东西，半小时确实能搞出来。
尤其对熟悉某个领域、熟悉某套框架的人来说，
封装一个能力、补一层接口、做一个能调用的原型，其实并不难。
难的是后面那部分。
难的是你愿不愿意承认：
第一版往往只是“能跑”，离“能长期使用”还很远。
半小时能完成的，大概率只是这些东西：
- 一个 demo
- 一个原型
- 一个 proof of concept
- 一个对作者自己友好的工具
但一个真正能放进工作流里、能反复复用、能让人愿意长期依赖的 Skill，
一定不是这样长出来的。
它需要你在真实使用里不断问：
- 这个地方为什么会卡？
- 用户为什么会犹豫？
- 这个输入为什么总是不自然？
- 这个输出为什么看着完整，但没有行动价值？
- 是不是还有一步可以继续替用户做掉？
这些问题没有标准答案。
只能靠一次次使用、一次次失败、一次次重构，把感觉慢慢磨出来。
工程师最容易高估“实现”，低估“打磨”
我觉得这是一个特别普遍的问题。
工程师天然喜欢“实现”这件事。
因为实现是明确的、可验证的、可展示的，也是最容易带来成就感的。
你写完一段代码，跑通一个流程，接上一个系统，马上就会觉得：
这件事完成了。
但“打磨”不是这样的。
打磨没有那么强的完成感，甚至很多时候是反过来的。
它会让你意识到，原来你以为已经完成的东西，其实只是刚开始。
而且打磨往往很琐碎：
- 改一个命名
- 补一个默认值
- 删一个不该暴露的参数
- 调整一次返回结构
- 重写一段失败提示
- 合并两个本来分开的步骤
这些事不炫，也不好拿出来讲。
但最后决定一个 Skill 到底是“有人愿意一直用”，还是“写完就躺在仓库里吃灰”的，恰恰就是这些事。
Skill 的终点，不是交付，而是融入真实工作流
所以现在我对 apifire-skills 的看法，已经不太像“我写了一个项目”，
更像是“我在慢慢养一个产品”。
先把它做出来，当然重要。
但真正有价值的是后面的过程：
把它放进真实世界里，接受真实使用的拷打。
因为只有经过这个过程，你才会慢慢知道：
- 什么地方该自动化
- 什么地方该收口
- 什么地方该放权给用户
- 什么地方该更激进地帮用户做决定
- 什么地方其实根本不需要存在
到最后，一个 Skill 是否好用，标准并不是“代码有多漂亮”，
而是它能不能自然地融入真实工作流，成为用户愿意反复调用的一部分。
而这件事，最近让我感触特别深。
写在最后
现在回头看，我越来越觉得：
好用的 Skill，从来不是设计出来的，而是打磨出来的。
先做出来，再放进实战；
在实战里发现问题，再反过来改；
改完继续用，继续暴露问题，继续优化。
这中间没有捷径。
更不是半小时就能完成的事。
半小时，也许足够你写出一个“能用的东西”；
但一个真正顺手、稳定、能长期复用的 Skill，
一定要经历更长时间的实战、返工和打磨。
这也是我最近做 apifire-skills 时，最大的感受。
