循环解决的是“让 Agent 自己跑”，但光会跑还不够。

如果它不知道你的写作习惯、业务规则、判断标准和禁用项，跑得越快，返工可能越多。Skill 解决的就是这个问题：把你反复使用的一套方法写下来，让 Agent 在需要时读取并执行。

视觉能力则解决另一个问题：很多信息本来就不适合用文字描述。网页布局、报表、流程图、截图和 PDF 图表，直接看往往比让人先写一段说明更高效。

这篇只讨论两个问题：怎样做出有用的 Skill，以及怎样把视觉输入纳入工作流。

一、Skill 到底是什么

一句话：Skill 是一套可以被反复调用的工作方法。

它通常包含说明文档、输入要求、执行步骤、输出格式、检查清单，以及必要的参考资料。不同工具对目录名、入口文件和调用方式的要求可能不同，实际结构应以当前工具文档为准，但思想基本一致：

Skill
├── 说明：这个技能解决什么问题
├── 输入：开始工作前需要哪些资料
├── 流程：按什么顺序执行
├── 输出：最后交付什么格式
├── 约束：哪些事情不能做
└── 检查：怎样判断结果合格

Skill 不是把一段很长的提示词永久塞进每次对话，而是按需加载。平时只需要知道它解决什么问题，真正处理相关任务时，再读取完整规则。

二、什么样的工作值得做成 Skill

不是所有工作都值得沉淀。

一次性任务、规则经常变化的任务、完全依赖临场判断的任务，通常不适合马上做成 Skill。真正值得做的是那些你反复做、步骤相似、质量标准可以说清楚的工作。

例如：

判断标准很简单：如果同一件事你已经做过三次以上，而且每次都在重复解释“先做什么、再做什么”，就可以考虑把它沉淀成 Skill。

三、三种制造 Skill 的方式

1. 从过去的对话里提炼

这是最省力的方法。

把你过去做得比较满意的一次对话交给 Fable 5，让它分析：你提供了什么输入，模型执行了哪些步骤，你在哪些地方提出了修改，最后什么结果算满意。

可以这样要求：

请分析这段历史对话，把它提炼成一个可复用的 Skill。

请输出：
1. 这个 Skill 解决什么问题；
2. 适合什么场景，不适合什么场景；
3. 开始前需要的输入；
4. 推荐的执行步骤；
5. 最终输出格式；
6. 我在对话中反复强调的偏好；
7. 常见失败方式；
8. 一份可以直接使用的验收清单。

不要把这次对话里的具体客户、密码和敏感数据写进 Skill。

这样生成的 Skill 往往比凭空写出来的更贴近你的真实习惯。但历史对话里也可能包含临时判断和过时规则，生成后要人工删掉那些只适用于单次任务的内容。

2. 从零开始搭建

如果还没有历史样本，可以拿一张纸或一个表格，把日常工作完整列出来：输入是什么，先做什么，判断什么，最终交付什么。

然后从最小版本开始，不要试图一次把所有经验都塞进去：

Skill 名称：文章事实核查

输入：文章草稿、引用链接、数据日期
步骤：提取事实 -> 找第一方来源 -> 标注日期 -> 标记无法验证项
输出：问题清单、建议改写、引用表
禁止：编造来源、把推断写成事实、删除重要限制
验收：每个数字和版本结论都有来源或明确标记为待验证

第一版 Skill 只要能稳定完成一套最小流程就够了。真正的质量来自后续反馈，而不是初版文件的长度。

3. 从数据和反馈中迭代

如果你在做一个持续产出的账号、栏目或产品，可以把一批历史素材作为样本，让 Agent 总结其中的结构、语气、选题和反馈规律。

但这里要分清“模仿规律”和“复制内容”。可以让它学习：

不要把别人的原文直接当成可复制模板，更不要把无法验证的“爆款规律”写成确定结论。数据只能帮助 Skill 改进，不能自动证明某种写法一定有效。

四、一个合格 Skill 的最小结构

建议至少写清楚以下内容：

适用范围

解决什么问题，不解决什么问题。

输入规范

开始前必须提供哪些文件、数据和背景。

操作流程

按什么顺序处理，每一步产生什么中间结果。

输出规范

最终交付 Markdown、表格、代码、报告还是检查清单。

质量检查

如何发现遗漏、事实错误、格式问题和不符合偏好的结果。

失败处理

找不到资料、输入不完整或步骤无法执行时，应该暂停、标记还是采用替代方案。

如果一个 Skill 只有“请写得专业一点”这种抽象要求，它很难稳定复用。把“专业”拆成标题长度、语气、引用方式、禁用表达和验收条件，模型才知道该怎么做。

五、视觉能力可以用在哪些地方

很多人使用模型时只上传文字，实际上截图和图表也可以成为非常重要的上下文。

文档和数据

可以让它读取 PDF 中的图表、曲线、表格和流程图，再把观察结果整理出来。涉及具体数字时，要求它同时输出“看到了什么”和“哪些地方需要回到原始文件核对”。

设计和界面

把网页截图交给它，让它从布局、间距、文字层级、颜色对比、按钮状态和移动端适配几个方面检查问题。

不要只问“好不好看”，可以要求它输出：问题位置、用户影响、修改建议和验证方式。

开发和排错

一张白屏截图往往不能直接说明根因，但它可以帮助 Agent 识别页面是否加载了错误的资源、是否出现布局溢出、是否有弹窗遮挡或状态没有反馈。真正的错误原因仍然要结合 Console、Network 和服务器日志确认。

内容创作

多张参考图可以帮助它归纳构图、颜色、信息层级和视觉风格，再转成一份可执行的设计规范。这里应该描述抽象规律，不要要求它复制特定作者的原图或品牌素材。

六、不要把视觉判断当成事实

视觉模型很擅长发现明显关系，但在小字号、复杂图表、遮挡区域、相似颜色和精确数字上可能出错。

可以给它加一条固定规则：

先区分“图中直接可见的内容”和“根据图像推断的内容”。
涉及数字、坐标、金额、日期和法律文本时，必须提示我回到原始文件核对。
无法看清的区域标记为“无法确认”，不要根据上下文补全。

某些入口对图片尺寸、格式和数量存在限制，具体能力也会随版本变化。不要把网上流传的单个演示案例写成稳定能力，更不要把一次识别结果当成正式数据录入。

七、让 Skill 自己接受反馈

Skill 的第一版一定不完美。每次使用后，最好记录三件事：

然后让 Fable 5 帮你更新 Skill：

根据本次执行记录，更新这个 Skill。
保留已经验证有效的规则，删除只适用于本次任务的偶然内容。
新增规则必须说明它解决了什么失败案例。
不要改变现有输出格式，除非明确指出兼容影响。
最后列出本次新增、修改和删除的规则。

这样 Skill 才会从一份说明文档变成一套不断改进的方法库。

一个可以直接起步的 Skill 模板

下面是一份“文章事实核查” Skill 的最小模板。它没有绑定具体工具，先把方法写清楚，再按照当前 Skill 规范放入对应目录：

# 文章事实核查

## 适用场景
检查文章中的日期、价格、版本、功能和性能结论。

## 输入
- 文章草稿
- 原始链接或资料
- 信息截止日期

## 执行步骤
1. 提取所有可验证事实。
2. 为每条事实寻找第一方来源。
3. 记录来源、发布日期和访问日期。
4. 区分事实、推断和作者判断。
5. 找不到证据时改写为条件化表述，或列入待验证。

## 输出
- 问题清单
- 建议改写
- 引用表
- 未解决风险

## 禁止事项
- 不编造来源。
- 不把单次体验写成普遍结论。
- 不泄露输入材料中的敏感信息。

## 验收
每个数字、版本和能力结论都有来源，或明确标记为待验证。

这个模板看起来不复杂，但已经包含了适用范围、输入、流程、输出、限制和验收。后面每次遇到真实失败，再只补充解决该失败所需的规则。

Skill 需要版本管理

如果一个 Skill 被长期使用，它就会不断变化。最简单的版本管理方式是每次修改都记录原因：

## 变更记录

### 2026-07-29
- 新增：价格和版本必须记录信息日期。
- 新增：无法找到一手来源时不得继续扩写结论。
- 保持：输出仍然分为问题清单、改写建议和引用表。

不要因为某次任务失败，就把所有限制都塞进去。每条新规则都应该回答一个问题：它解决了哪一次失败？是否会让正常任务变得更慢？是否与旧规则冲突？

如果团队共同使用 Skill，还要记录负责人、适用版本和最近一次验证时间。一个没有维护人、没有样例、没有验收记录的 Skill，最后很容易变成没人信任的旧文档。

用样例测试 Skill

Skill 不能只靠阅读检查。准备三类样例：

  1. 正常样例：资料完整、任务清楚，应该顺利通过。
  2. 边界样例：输入缺失、格式异常或资料互相矛盾，应该暂停或标记。
  3. 失败样例：明确包含错误信息，应该被 Skill 识别出来。

每次修改 Skill 后，让它重新处理这三类样例，观察输出是否符合预期。这样做不需要复杂测试框架，一张表就够了：

样例 预期行为 实际行为 是否通过
完整文章 找出所有事实并附来源
缺少日期 标记待验证
来源矛盾 分开列出，不自行裁决

一套视觉检查流程

拿到截图或图表后，不要马上让它“给建议”。先按四步处理：

第一步：描述可见事实

要求它只描述看得见的内容，例如页面有哪些区域、图表有几条曲线、按钮在哪个位置。不要在这一步解释原因。

第二步：列出可能的问题

让它把布局溢出、文字层级、颜色对比、信息缺失和交互状态分开列出，并标注置信度。

第三步：提出修改建议

每条建议都要对应一个问题，并说明用户影响、修改成本和验证方式。

第四步：回到原始资料验证

数字、坐标、日期和关键文本要回到原始 PDF、网页或数据文件核对。截图只适合做观察入口，不应该自动成为唯一事实来源。

可以使用这样的提示词：

请分析这张页面截图，分四部分输出：
1. 直接可见的事实；
2. 可能存在的问题；
3. 每个问题的用户影响和修改建议；
4. 需要我用浏览器、源码或原始数据进一步验证的内容。

不要把推断写成事实。
看不清的文字、数字和区域标记为无法确认。

视觉能力和 Skill 可以组合

例如做一个“上线前页面检查” Skill：输入桌面端和移动端截图、页面 URL、浏览器控制台日志，输出布局问题、资源错误、可访问性风险和验证步骤。

Skill 负责固定检查顺序，视觉能力负责理解截图，浏览器或测试工具负责验证实际行为。三者各有边界，不能让视觉模型单独替代真实浏览器测试。

结论

Skill 让你的方法可以复用，视觉输入让 Agent 能处理更多原本需要人工描述的信息。二者结合起来，Fable 5 不再只是替你写一段文字，而是可以按照你的标准处理一整类工作。

但 Skill 不是训练数据，也不是永久正确的记忆。它仍然需要版本管理、样本反馈和人工验收。图片里的观察也不能替代原始数据核对，尤其是数字、价格、日期和法律文本。

先把一项重复工作做成最小 Skill，再用真实任务不断修改它，通常比一开始设计一套巨大的技能体系更容易成功。

参考资料