W
AI-Wiki
SOURCE

Skills驱动的AI工作流设计 摘要

文档概览

这篇来源页的核心判断很鲜明：很多 AI 工作流之所以“第一次跑得很好，第二次就失稳”，不是因为提示词还不够长、不够细，而是因为流程知识仍然依附在一次性对话里，没有被沉淀为可复用、可组合、可按需加载的能力组织系统。

作者把问题拆成两部分：

  • 第一部分是 一次性提示词不稳定。用户即使花半小时打磨出“完美提示词”，第二次复用时仍可能出现格式变化、风格变化、关键步骤被跳过等偏差。
  • 第二部分是 人工逐环节审查太慢。当模型产出速度和数量都上升后，“每一步都等人看”的流程会成为整个系统里最慢、最贵的环节。

在此基础上，原文提出一套升级方向：

关键事实

1. 原文把“跑一次就失效”的根因指向一次性提示词结构

文中给出的典型场景是：

  • 第一天用精心打磨的提示词生成出一篇很满意的文章；
  • 第二天使用同样提示词时，输出却出现格式变化、风格变化、关键环节缺失；
  • 用户容易怀疑是模型更新或自己记错了提示词，但作者认为真正缺失的是“能让 AI 记住工作流的系统”。

这一定义非常重要，因为它把问题从“如何写出更完美的 prompt”转向“如何把流程外置为稳定能力”。也就是说，原文主张工作流稳定性的主要来源不应是单轮提示工程，而应是可复用的能力封装与规则沉淀。

2. Anthropic Skills 的核心被概括为三级渐进式披露

原文认为 Anthropic 教程最值得学习的，不只是 Skill 文件格式，而是其背后的信息组织哲学：渐进式披露（Progressive Disclosure）。

文中给出了非常具体的三级加载机制：

级别加载时机包含内容目的
第一级：YAML 头部始终加载Skill 名称、简短描述、触发条件让 AI 先判断“要不要用这个能力”
第二级：SKILL.md 正文当 AI 判断相关时才加载完整指令、工作流步骤、最佳实践提供执行细节
第三级：关联文件按需查阅参考文档、模板、示例提供深度上下文

原文强调，这种三级结构不是排版技巧，而是工作流稳定性的关键：

  • 省 token：不会每次无差别加载全部细节；
  • 省时间：无需每轮都重新解释一次流程；
  • 更稳定：步骤、规范和补充材料被固定在文件体系中，不再依赖临时对话记忆。

这实际上对应了 渐进式披露式能力组织 的典型实现方式：先用最小元信息做路由，再按任务相关性展开规则，最后在必要时进入示例与参考层。

3. YAML 头部不仅要写“做什么”，还必须写“什么时候用”

原文把这一点列为第一个最实用的设计原则，并给出正反示例。

错误写法只写能力用途：

description: 生成新闻文章

正确写法则同时给出触发条件：

description: 根据新闻素材生成深度解读文章。当用户说“写稿”“二创”、提供新闻链接或上传 markdown 文件时使用。

文中解释其必要性在于：AI 需要靠这一层来判断是否应该加载该能力。若没有触发条件，可能出现两个极端问题：

  • 每次都加载，导致 token 浪费和上下文噪声增加；
  • 永远不加载，能力文件形同虚设。

因此，这里的描述字段不是普通简介，而是“用途 + 调用条件”的路由元信息。这一点与 可组合能力单元设计 高度相关，因为能力只有在边界明确、触发条件明确时，才容易被系统正确调度与组合。

4. 原文明确强调：用自检替代逐环节人工审查

这是该来源最核心的工程观点之一。文中引用 OpenAI 最近博客中的判断：随着模型能力提升，Agent 的产出持续增加，人类审查反而成了系统中最慢的环节。

原文据此给出的方向非常直接：

  1. 移除 human-in-the-loop，不再要求每个环节都等待人工审查；
  2. 改用“渐进式披露的文件系统”，由一个约 100 行 的 AGENTS.md 作为目录入口，指向结构化设计文档、架构规范和执行计划；
  3. 让 AI 自己持续运行：失败了就读日志、修改后再跑，单次任务可以执行很久。

作者把这一思路迁移到内容生产工作流，给出的结论是：如果流程仍然是“AI 生成 → 人审查 → AI 修改 → 人再审查”，那么真正的瓶颈不是模型，而是流程设计本身。

与之相对，原文建议把审核要求写入规则文件，让 AI 执行：

  • 按规范生成；
  • 按规范自检；
  • 自检不通过时自行修正；
  • 人只在最终发布前做一次“发 / 不发”的决策。

这与已有条目 HITL Agent双反馈闭环 的语境不同：本文并不是强调把人工反馈纳入双闭环演进，而是强调在低风险、可规则化环节里，尽量不要把人工放在每一步中间做同步审查。

5. 自检清单是原文给出的具体替代机制

原文没有停留在“减少人工审核”的抽象层面，而是给出可以直接写进能力文件的自检清单示例：

## 自检清单（生成完成后自动执行）

- [ ] 标题是否在 30 字以内？
- [ ] 导语是否在 100 字以内？
- [ ] 是否包含 3-5 个小节？
- [ ] 每个小节是否有小标题？
- [ ] 结尾是否有行动建议？

**如果有任何一项不符合，自动修正后再输出。不要询问用户，直接改。**

这里有几个关键约束不能忽略：

  • 这是“生成完成后自动执行”的检查，而不是额外等待用户触发；
  • 自检项都是可操作、可判定的具体规则，不是模糊要求；
  • 如果不符合，默认动作是“自动修正后再输出”；
  • 明确要求“不要询问用户，直接改”，即把修正规则前置授权给系统。

原文甚至给出一个效果判断：采用这种方式后，效率可提升 至少 3 倍。这一数字出自作者总结性表述，虽然不是实验报告中的严格统计，但在文章内部属于明确的性能主张。

6. 能力单元必须支持独立运行与组合运行

原文把“可组合”列为第三个设计原则，并强调一个 Skill 不应假设自己是系统中唯一可用的能力。

文中给出了一组典型能力：

  • news-fetcher：抓取新闻；
  • news-writer：写稿。

然后指出两种不同的调用路径都必须被支持：

  • 用户直接说“帮我写今天的新闻稿”，此时需要同时调用抓取与写作两类能力；
  • 用户已经手动准备好新闻素材，再说“根据这个写稿”，此时只需调用写作能力。

因此，好的能力设计必须同时满足：

  • 独立运行：用户直接提供输入时，该能力可单独完成任务；
  • 组合运行：该能力可以作为链路中的一环，与其他能力配合使用。

这正是 可组合能力单元设计 的典型边界定义方式：能力不依附于某一条固定链路，而是围绕输入、输出、触发条件与约束形成模块化接口。

重要细节

新闻写作 Skill 的三级拆分示例

原文通过“新闻写作”能力示例，具体展示了三级渐进式披露如何落地：

第一层 YAML 头部写成：

---
name: news-writing
description: 根据新闻素材生成深度解读文章。当用户说“写稿”、“二创”或提供新闻链接时使用。
---

第二层正文则包含：

  • 完整写作流程：提炼观点 → 构建结构 → 撰写正文 → 自检；
  • 风格指南：语气、长度、段落要求；
  • 自检清单。

第三层关联文件进一步放入：

  • 优质案例示例文件；
  • 段落结构模板文件。

这个案例说明，Skill 不是一句 prompt，也不是一份冗长总说明，而是一个带目录、带触发条件、带执行正文、带补充引用的层级化能力包。

文件驱动工作流的组织方式