前几天，宝玉在群里分享了一个他的 Skill 迭代日志。我点进去看完，最打动我的不是技术细节本身，而是那种“用着用着就发现了不对劲”的真实感。
他做的 baoyu-design Skill，在帮他做 PPT 的时候，样式表总是铺不满整页，渐变色也莫名其妙丢了。换作我们很多人，第一反应大概是“算了，手动调一下吧”。但他没有，他把问题直接丢给 Agent，让 Agent 分析原因、给方案、加测试，然后一键更新。
这个循环，自己用 → 发现问题 → 让 Agent 分析 → 确认 → 更新，听起来平平无奇，但它恰恰是我们很多人和好工具之间，就差的那一步。
我们总觉得，做一个好用的 Skill 得先把所有功能想周全。可事实是，最好的工具从来不是“设计”出来的，而是在一次次真实的磕碰里“长”出来的。
我把 Skill 用到了真实场景里宝玉做的这个 Skill 叫 baoyu-design，简单说就是一个在 Claude Code 里帮你做 PPT、动画视频、网站的助手。你可以让它调用 AI 画图来配图，最后还能导出成 PPTX 文件，在 PowerPoint 或者 Keynote 里二次编辑。
听起来已经很完整了对吧。
可他自己一用，问题就来了。导出的 PPTX 样式表没铺满整页，渐变色也丢了。这两个问题单独看都不大，但合在一起，导出来的文件根本没法直接用。你满怀期待地点开导出的文件，发现排版全歪了，颜色也不对了，那种感觉就像烤了半天的蛋糕，打开烤箱一看塌了。
换作我们大多数人，大概率的做法是手动调一下，然后叹口气，下回注意。
但宝玉选了另一条路。他把问题原原本本丢给了 Agent，让它去分析为什么会这样，给出具体的修复方案，顺便把测试也加上。
我看到这段日志的第一反应，是他真”敢”。
敢把问题暴露出来，敢让 Agent 帮忙解决，敢在公开群里分享这个“翻车”的过程。这种“敢”，比任何 Skill 的功能本身都重要。
因为大部分人做 Skill 的心态是”做完就算了”，觉得能跑就行。可真正好用的工具，都是在一次次”不对劲”里磨出来的。
迭代是一种生活方式
我们一听到“迭代”这个词，脑子里浮现的大概是程序员改 bug 的画面。一堆报错日志，一个红叉，然后啪啪啪敲键盘修好。
但宝玉做的事情不太一样。他的迭代循环很简单：自己用 → 发现问题 → 让 Agent 分析 → 出方案 → 确认 → 更新。
翻译成大白话就是：先拿去用，用着不对劲了，再想办法改。
这跟我们小时候学骑自行车很像。没有人是看了一本《自行车骑行手册》然后就学会的。你得骑上去，摔几次，知道哪里会翻车，然后慢慢找到平衡。
技能是摔出来的，好的工具也是磕出来的。
他在本地把问题复现了一遍，确认是导出模块在处理外部样式表引用时没有完整嵌入，导致 PPTX 打开后样式丢失。渐变色的问题更隐蔽，是不同渲染引擎对 CSS gradient 语法的解析差异。这些细节，如果不去真实导出一次，根本不会发现。
Sebastian Raschka 在他的文章里分析过 Coding Agent 的组成：工具使用、记忆管理、代码仓库上下文。他说得很对，但我觉得漏了一个最重要的：迭代能力。一个不会迭代的 Agent，就像一个只会照菜谱炒菜的厨师，菜谱上没写的，他就不会了。
而宝玉做的事情恰恰相反。他在和 Agent 一起把一个”能用”的工具变成”好用”的工具。
这里面的区别，就像“会做饭”和“会根据冰箱里有什么来调整菜式”。前者是照做，后者是真正懂。
Agent 陪你发现问题这里有一个很多人会搞混的概念。
我们总以为 Agent 的价值在于“帮你把事情做完”。你告诉它做什么，它就做，做完你验收。像一个听话的实习生。
但宝玉的迭代日志展示的是另一种模式。他更像是在”邀请”Agent 一起分析问题。他把导出异常的现象描述清楚，Agent 帮他定位根因，然后一起决定怎么修。
这个过程里，宝玉自己的判断力是起点。他得先知道“哪里不对劲”，才能把问题描述清楚。Agent 不会替你感受那个“不对劲”，它只能在你发现问题之后帮你分析为什么不对劲。
Arvind Narayanan 写过一篇文章，讲 AI 还没取代软件工程师，也不会取代。他的核心论点是：coding agents 是”正常技术”，说白了就是增强工具。你还是得知道你要做什么，只是做的过程变快了。
我特别认同这个判断。
翻译成我们能理解的场景就是：宝玉知道他的 Skill 导出有问题，这是他作为使用者的经验。Agent 帮他快速定位了 CSS 样式表和渐变色渲染的差异，这是 Agent 作为分析工具的能力。两者结合，问题才能被高效地解决。
人的判断力加上 Agent 的执行力，这才是真正有价值的组合。
如果宝玉自己不知道导出有问题，Agent 不会主动告诉他。如果 Agent 不会分析代码，宝玉也很难自己快速定位到样式表的根因。
这是一种新型的协作关系，我把它叫做”人加 Agent 的手艺人模式”。
在这种模式里，人是产品经理加品控总监，Agent 是工程师加测试员。你定义好坏，它把活干好。你发现问题，它解决问题。
你的 Skill 正在等你去发现它的毛病
可能有人会说：我又不是宝玉，我又不会做 Skill。
其实你已经在做了，只是你没意识到。
你在 Claude Code 里写了一段自定义指令，那就是一个 Skill 的雏形。你在 CLAUDE.md 里加了几条项目规范，那也是一种 Skill。你把自己的工作习惯整理成一个可复用的模板，那就是 Skill。
问题不在于你“会不会做”，而在于你“用不用起来”。
Claude Code 的 Skill 生态现在支持自定义 slash commands，你可以把常用的提示词封装成一个个命令，随时调用。还可以在项目的 .claude/commands/ 目录下放 Markdown 文件，团队里其他人也能用。这意味着你今天踩的坑，明天你的同事就不用再踩一遍。
Narayanan 的团队还做过一个研究，量化了 AI Agent 的能力与可靠性之间的差距。他发现，Agent 在标准测试里表现很好，但在真实、混乱的长期任务里，可靠性会大幅下降。
这个发现翻译成我们的经验就是：Skill 在 demo 里跑得很顺，一到真实场景就各种小毛病。
但这些小毛病恰恰是金矿。
每发现一个 bug，你就比昨天更了解这个工具的边界在哪里。每修一个问题，你的 Skill 就比上一版更贴合你的真实需求。修完之后你还会发现，你对这个工具的理解又深了一层。
这就是为什么我说，好的工具是“长”出来的，不是“设计”出来的。
设计是坐在桌前想“用户可能遇到什么问题”。长出来是拿到真实场景里去撞，撞出了问题再修。前者靠想，后者靠干。经验这东西，只能自己攒。
你想想，一个好的厨师是怎么练出来的。看菜谱是学不会的，你得在厨房里被油溅过、被刀切过、被火烤过，然后慢慢知道火候在哪里、味道在哪里、手感在哪里。做 Skill 也是一样的道理。
每一次翻车都是进步的证据
宝玉的迭代日志里有一句话让我印象很深。他说他把问题在本地复现后，让 Agent 分析原因、给方案、加测试。
“加测试”这三个字，看起来不起眼，但意义重大。
很多人改完一个 bug 就算了，下次遇到同样的问题再改一次。但宝玉多走了一步：把这次的经验固化成了测试用例。下次如果再出现同样的问题，测试会自动拦住。
这个习惯叫“用 bug 来喂养工具”。
我自己的经验也是这样。刚开始用自定义指令的时候，写得很粗糙，跑起来到处漏风。但每遇到一个“不对劲”的地方，我就记下来，想一想为什么会这样，然后改掉。改着改着，那个指令就越来越贴合我真正的需求了。
回头看，最初那版和最终那版之间的距离，就是这些“不对劲”堆出来的。没有它们，你永远不知道边界在哪里。
Guizang 也在做类似的探索。他做的 PPT Skill 配合 Codex 和 HyperFrames，走的是另一条技术路线，但核心逻辑是一样的：先拿去用，用出问题了再改。
他们的共同点是，都在用真实场景去检验自己的工具，而不是坐在那里空想“用户可能会遇到什么”。
整个 Claude Code 的 Skill 生态，正在从“个人工具”走向“社区共享”。你做的 Skill，别人也能用。别人发现的 bug，修完之后你也能受益。这是一个正向循环。
Anthropic 今年在韩国开了新办公室，和韩国的 AI 生态建立了合作。Claude 的新模型 Fable 也刚发布。整个生态在快速扩展，而 Skill 是这个生态里最接地气的一层。它不需要昂贵的显卡，不需要庞大的数据集，甚至不需要你懂机器学习。你只需要一个 Claude Code，一个你想解决的问题，然后动手去做。
它不要求你是研究员，不要求你看得懂论文，不要求你有博士学位。它只要求你一件事：敢用，敢发现问题，敢把问题修掉。
我们很多人在 AI 面前会觉得“我不够格”，觉得自己技术不行、英文不好、不是专业人士。但宝玉的迭代日志告诉我们，最核心的能力其实就是”用起来”这一个动作。
你用起来了，问题自然会出现。问题出现了，你自然会想办法去解决。解决了，你的 Skill 就变好了，你的能力也跟着变好了。这是一个正向循环。
这个过程不需要任何人来教你，它会自然而然地发生。就像种子遇到水就会发芽，你只需要把第一步迈出去。
愿你也有勇气把第一个“不对劲”说出来我们很多时候不敢用新工具，说到底是因为怕出错。怕导出来的东西不对，怕在别人面前露怯，怕自己折腾半天还是不行。
但宝玉的迭代日志让我看到的是另一面。他不但不怕出错，还主动在群里分享自己出错的过程，连修复的方案也一并公开。这种开放和坦诚，反而让他走得比谁都快。
因为每一次公开分享“我翻车了，我是这样修的”，都会有人告诉你“我也遇到过这个问题”，或者“你这个方案可以这样优化”。
