前几天看到宝玉分享 baoyu-design Skill 的迭代日志，第一感觉不是“这个 Skill 多强”，而是很久没见到这么真实的工具演进过程了。
它不是那种发布页上写满能力清单的 Demo，也不是“输入一句话生成完整 PPT”的爽文。真实情况更接近工程现场：导出的 PPTX 样式铺不满整页，渐变色丢了，打开文件一看，能用，但不够能交付。
很多工具都死在这个阶段。Demo 能跑，自己用着别扭；能解决 70% 的问题，但剩下 30% 靠人肉修。最后用户嘴上说“挺有潜力”，手上还是回到老流程。宝玉这次有意思的地方在于，他没有把问题绕过去，而是把问题喂回给 Agent：复现、分析、修复、补测试，再更新 Skill。
这个动作看起来不大，但它把 Skill 从“提示词资产”推向了“可演进的工程资产”。
一、好工具不是一次设计出来的
宝玉做的这个 Skill 叫 baoyu-design，运行在 Claude Code 里，主要用来做 PPT、动画视频和网站。它可以调用 AI 生成配图，也能导出 PPTX，方便在 PowerPoint 或 Keynote 里继续编辑。
听起来已经挺完整了。
但一进入真实使用，问题马上冒出来：
- 导出的 PPTX 样式表没有铺满整页；
- CSS 渐变色在导出后丢失；
- 原本在网页预览里正常的视觉效果，到了 PPTX 里就变形。
这类问题在工程里很常见。单点看都不像大故障，甚至可以手动修一下。但如果你的目标是“让 Skill 真的承担生产力流程”，这些小问题就会变成硬伤。
PPT 这种东西尤其典型。它不是代码编译通过就算成功，最终交付物要给人看。版式偏一点、颜色错一点、比例不对一点，都会让结果显得廉价。很多 AI 工具在这里容易翻车：生成阶段很惊艳，落地到可编辑文件时细节崩掉。
宝玉的处理方式是把问题原样丢给 Agent，让它分析原因、给方案、修代码，并且加测试。
这背后其实有一个很关键的工程判断：不要把一次手工修复当成结束，要把它变成工具能力的一部分。
手动调 PPT 当然最快。今天改完，今天交付。但下次还会遇到。 修 Skill 慢一点，但修完以后，这类问题会被系统吸收。
这就是工具迭代和临时补救的区别。
二、真实场景会暴露隐藏边界
很多人做 Skill、写自定义指令、写 Agent 工作流时，会掉进一个很隐蔽的坑：在脑子里把流程设计得很完整，但很少把它放进真实任务里撞。
真实任务和测试任务的差异很大。
测试任务通常边界清晰：
- 输入是什么；
- 输出是什么；
- 成功标准是什么；
- 中间不太会发生奇怪分支。
真实任务刚好相反。它有各种非标准输入、隐含预期和边缘格式。比如这次 PPTX 导出问题，本质上不是“生成一页 PPT”这么简单，而是跨了好几层技术边界：
每一层都可能引入偏差。
页面里看着没问题，不代表 PPTX 里没问题。浏览器支持的 CSS 特性，不代表 PPTX 转换库也能完整表达。PowerPoint 对渐变、字体、透明度、背景铺满的处理，也可能和 Web 渲染模型不一致。
这就是前端工程师非常熟悉的痛点：“看起来一样”和“底层表示一样”是两回事。
在网页里，一个渐变背景可能只是几行 CSS：
.slide {
width: 100vw;
height: 100vh;
background: linear-gradient(135deg, #111827 0%, #6366f1 100%);
}
但导出到 PPTX 时，它要被转换成 PowerPoint 能理解的形状、填充、渐变节点和尺寸约束。只要转换层没有完整处理，效果就会丢。
样式表铺不满整页也是同类问题。Web 里的布局基于视口、盒模型和 CSS 规则；PPTX 里的页面基于固定画布、坐标、形状和母版。二者不是天然同构。
所以这类问题靠“多写几句提示词”很难彻底解决。它需要进入实现层：
- 外部样式表是否被完整内联；
- 背景是否被转换为 PPTX 原生对象；
- 渐变语法是否需要降级；
- 页面尺寸和 PPT 尺寸是否一致；
- 导出结果是否有回归测试保护。
这也是 Skill 生态里一个容易被忽视的点：越靠近交付物，越需要工程化。
Prompt 可以解决表达问题，但解决不了所有格式转换问题。 Agent 可以帮你写代码，但前提是你愿意把问题定位到代码层。
三、Agent 的价值在问题出现之后
很多人理解 Agent，还是把它当成“自动干活的实习生”：给一个任务，它把事情做完。这个理解不算错，但有点窄。
宝玉这次的用法更接近一种工程协作：
- 人在真实使用中发现异常；
- 人把现象描述给 Agent；
- Agent 结合代码仓库上下文定位原因；
- Agent 给出修复方案；
- 人确认方向；
- Agent 修改代码并补测试；
- 人继续使用验证。
这里面最关键的起点不是 Agent，而是人的判断力。
Agent 不会天然知道“这个 PPT 不够好”。它不知道你心里期待的版式是什么，也不知道这个交付物要拿去给谁看。它只能处理你明确交给它的问题。
所以，Agent 协作的第一能力其实是：你能不能准确说出哪里不对劲。
比如下面两种描述，效果完全不一样。
低质量 高质量 后者不是因为字多，而是它把现象、对比、可能范围和期望动作都交代清楚了。Agent 在这种上下文里，才更像一个能干活的工程伙伴。
这也解释了为什么 Arvind Narayanan 会说 Coding Agent 是“正常技术”。它不是魔法，也不是替代软件工程师的按钮。它更像一次生产力工具升级：写代码、查上下文、改文件、补测试的速度变快了，但问题定义仍然依赖人。
很多团队做到这里会卡住。他们期待 Agent 自动发现所有问题，自动判断方案好坏，自动完成验收。这个期待太高了。至少在当前阶段，比较可靠的模式还是：
| 环节 | 更适合人做 | 更适合 Agent 做 |
|---|---|---|
| 判断哪里不对 | 是 | 否 |
| 描述现象和目标 | 是 | 辅助 |
| 搜索代码上下文 | 辅助 | 是 |
| 分析可能根因 | 共同完成 | 是 |
| 实现修复 | 审核 | 是 |
| 设计验收标准 | 是 | 辅助 |
| 补充测试用例 | 审核 | 是 |
| 最终质量判断 | 是 | 否 |
这张表看起来有点朴素，但生产环境里经常就是这些朴素边界决定成败。
人定义“好不好”，Agent 负责“怎么改得更快”。 这个分工比“让 AI 接管一切”靠谱得多。
四、Skill 的本质是可复用经验
很多人听到 Skill，会下意识觉得它是 Claude Code 里的某种高级功能。但换个更工程化的说法，Skill 其实是把一组经验固化成可复用执行单元。
它可能很复杂，比如 baoyu-design 这种可以生成 PPT、动画和网站的设计助手。 也可能很简单，比如一个项目里的自定义 slash command：
/commit-review
/release-note
/refactor-plan
/write-test
在 Claude Code 里，你可以把常用流程写成 Markdown 文件，放到类似 .claude/commands/ 的目录里。团队成员都能复用。它不像传统脚本那样只能处理确定输入，也不像纯 Prompt 那样完全漂在上下文里。它介于两者之间：
- 有固定流程；
- 有项目上下文；
- 能调用 Agent 能力；
- 可以随着真实问题不断修改。
一个很小的例子，比如团队经常需要让 Agent 帮忙写测试，可以把命令设计成这样：
# write-test
请为当前变更补充测试。
要求：
- 先阅读相关实现和已有测试风格；
- 不要为了覆盖率写无意义断言；
- 优先覆盖本次修改涉及的边界条件；
- 如果发现代码不可测试，先说明原因，再给出重构建议；
- 输出修改文件列表和测试运行方式。
这就是一个 Skill 的雏形。
它真正的价值不在于第一次写得多完整，而在于你每次使用后继续修它。
比如第一次发现 Agent 总喜欢写过度 mock，就加一条约束。 第二次发现它漏掉异常分支，就补一个检查项。 第三次发现它不知道项目测试命令，就把命令写进去。 第四次发现它改了无关文件，就要求输出 diff 范围并解释原因。
这不是“调提示词”的小游戏，而是在沉淀团队工程习惯。
对个人来说，它是工作流资产。 对团队来说，它是轻量级工程规范。 对长期项目来说，它是经验的低成本复用。
五、加测试是分水岭
宝玉这次迭代里，有一个细节很关键：让 Agent 加测试。
修 bug 不难，难的是让同类问题以后别回来。
很多工具类项目早期都会经历这个阶段：功能越加越多，边界越来越碎，靠手动验证已经扛不住。尤其是像 PPTX 导出、HTML 转换、样式渲染这类功能，天然就容易回归。
如果只是修代码，下一次改导出逻辑时，渐变色可能又丢一次。 如果把这次问题固化成测试，工具就获得了一层记忆。
可以把这个过程理解成：
这条闭环里，测试是最容易被忽略、也最能拉开质量差距的一步。
当然，给 PPTX 这种视觉交付物写测试并不总是简单。这里有明显的 trade-off：
| 测试方式 | 优点 | 问题 | 适用场景 |
|---|---|---|---|
| 单元测试 | 快、稳定、定位准 | 只能覆盖转换逻辑局部 | CSS 解析、尺寸计算、配置生成 |
| 快照测试 | 容易发现结构变化 | 快照可能变成噪音 | PPTX XML 结构、导出元数据 |
| 视觉回归测试 | 接近真实体验 | 成本高，易受环境影响 | 关键模板、核心页面 |
| 人工验收 | 判断最准确 | 不可规模化，容易遗漏 | 发布前最终确认 |
工程上通常不会一开始就把所有测试拉满。比较现实的做法是：先覆盖最容易回归、最影响交付的点。
比如这次：
- 外部样式表是否被嵌入；
- 页面尺寸是否正确映射到 PPTX；
- 渐变背景是否保留或被合理降级；
- 导出的 PPTX 是否能被目标软件打开。
这里的关键不是追求测试体系多完美，而是让每一次 bug 都能留下痕迹。否则工具永远停留在“今天修好了”的状态。
一个不会积累失败经验的 Skill，很难长大。
六、Demo 里的能力不等于真实可靠
Narayanan 团队关于 AI Agent 的研究里，有一个判断很值得放到 Skill 场景里看：Agent 在标准测试里表现不错，但在真实、长期、混乱的任务里，可靠性会明显下降。
这个结论不意外。标准测试通常像考场，真实任务更像工地。
考场题目有明确答案，工地上会遇到材料不齐、图纸变更、天气影响、沟通偏差。Agent 在 Demo 里表现好，说明它具备能力；到了真实工作流里还能稳定，才说明它具备可用性。
Skill 也是这样。
一个 PPT Skill 在演示里生成三页漂亮幻灯片，不代表它能支撑日常工作。真正要看的是：
- 能不能处理不同主题和内容密度；
- 能不能导出可编辑文件；
- 能不能保持样式一致；
- 能不能在失败时给出可诊断信息；
- 能不能通过测试避免反复踩坑；
- 能不能被别人复用，而不是只适合作者本人。
这就是技术成熟度的问题。
很多 AI 工具现在处于“能力已经出现，可靠性还在补课”的阶段。它们能做出令人惊喜的结果，但要进入稳定生产流程，还需要大量边界修复和工程包装。
这里有个现实取舍：你不能指望一开始就做出完美 Skill。
如果一开始就追求完整能力，很容易陷入过度设计：
- 想支持所有 PPT 风格；
- 想兼容所有导出格式；
- 想覆盖所有用户场景；
- 想把异常处理一次写完。
最后大概率是迟迟用不起来。
更好的路径是从自己的高频场景切进去。先让它服务一个真实任务，然后用问题反推演进方向。这个策略不够宏大，但有效。
工具的边界不是靠想象画出来的，是靠使用撞出来的。
七、个人 Skill 会走向团队资产
Claude Code 的 Skill、自定义指令、slash commands 这些东西，早期看起来像个人效率工具。但它们很容易自然长成团队资产。
原因很简单：团队里的很多问题是重复的。
比如：
- 新人不知道项目代码风格；
- 每次发版都漏写 release note；
- Code Review 总是重复指出同类问题；
- 测试用例写法不统一；
- 数据库变更缺少回滚方案；
- 前端组件改动没有检查可访问性；
- API 修改忘记同步文档。
这些都适合沉淀成 Skill 或命令。
传统做法是写规范文档。但规范文档有个老问题：写的人很认真，看的人很少，执行的时候更容易忘。
Skill 的优势在于，它可以进入工作流。不是把规范挂在墙上，而是在你执行任务时直接参与。
比如团队可以有一个 /api-change-check：
# api-change-check
当本次变更涉及 API 接口时，请检查：
- 是否修改了 OpenAPI / 接口文档；
- 是否影响前端调用方；
- 是否涉及兼容性破坏；
- 是否需要数据库迁移；
- 是否需要灰度或开关；
- 是否补充了接口测试；
- 是否需要更新 release note。
请基于当前 diff 输出检查结果，不要泛泛而谈。
这类命令不复杂，但很实用。
它的价值不在于“AI 多聪明”，而在于把团队已经知道、但经常忘记执行的经验，放进了每一次开发动作里。
当然，这里也有边界。Skill 不能替代工程治理。
如果团队没有基本的代码规范、测试体系、发布流程，Skill 也只是把混乱包装得更自动化。Agent 能提高执行效率，但它无法替你定义组织里的质量标准。
所以更合理的使用方式是：先从确定性较高、重复性较强、反馈链路较短的流程开始。
优先做这些：
- 代码变更检查；
- 测试生成辅助；
- 文档同步；
- 提交信息整理；
- 发版说明生成；
- 常见故障排查模板。
谨慎做这些：
- 大规模架构重构；
- 无人审核的自动发布；
- 涉及资金、安全、权限的自动决策；
- 长链路、多系统、低可观测任务。
这不是保守，是工程现实。
Agent 越强，越要给它清晰边界。否则效率提升会变成风险放大。
八、Skill 生态最接地气的一层
现在 AI 生态里的大词很多：模型、推理、上下文窗口、多模态、Agent、MCP、工具调用。每个词都重要，但对大多数开发者来说，真正能马上改变工作方式的，往往是 Skill 这种更贴近日常任务的东西。
它不要求你训练模型，也不要求你维护复杂基础设施。你需要的是：
- 一个具体问题；
- 一个可运行环境；
- 一段可复用指令或代码；
- 持续使用和修正的耐心。
这也是为什么 baoyu-design 的迭代日志值得看。它没有停留在“AI 可以做 PPT”这种表层叙事，而是暴露了工具从能跑到好用之间的真实缝隙。
这些缝隙包括：
- 视觉效果和文件格式之间的差异；
- Prompt 生成和工程实现之间的差异；
- Demo 成功和长期可靠之间的差异；
- 一次修复和持续演进之间的差异。
很多 AI 工具的价值，最终都会落到这些缝隙里。
谁能把缝隙补上，谁的工具就更接近生产力。 谁只停留在演示层，谁就很容易被下一个更酷的 Demo 盖过去。
九、把第一个不对劲说出来
做 Skill 最难的地方，可能不是技术，而是心态。
很多人会等。等自己想清楚全部功能，等提示词写得足够漂亮，等流程设计得足够完整，等有时间系统研究一下。等着等着，这件事就没了。
更现实的路径是先做一个粗糙版本，然后把它用在真实任务里。
它一定会出问题。 输出不稳定，格式不对，漏掉上下文，改错文件，测试写得别扭。 这些都正常。
关键是别把这些问题当成失败。它们是工具开始进入真实世界的证据。
宝玉做 baoyu-design Skill 的七次修复，真正有价值的地方不只是修好了几个 bug，而是展示了一条很朴素的路线：
使用它
发现它的问题
描述问题
让 Agent 分析和修复
补测试
继续使用
这条路线没有多神秘，但它足够扎实。
未来一段时间，很多人的工作流都会被 Skill、Agent、自定义命令慢慢改造。差别可能不在于谁一开始写得更高级，而在于谁更愿意把真实问题持续喂回工具里。
好工具不是憋出来的。 它是在一次次“不对劲”里长出来的。
