最近我对一件事感触特别深。
一个真正好用的 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 时，最大的感受。
你是否也在 GitHub 上打造过自己的小工具？对于工具或 Skill 的开发，你有什么实战打磨的心得？欢迎在 云栈社区 一起聊聊。
发表于 2 小时前
|
查看: 1|
回复: 0
