post cover

从 Prompt 文件到 Agent 技能：如何统一我的内容自动化流程（2026-07-11）

本文为翻译/转载，原文使用 CC BY (dev.to 衍生) 协议发布。 原文作者：Debbie O’Brien 原文标题：From Prompt Files to Agent Skills: How I Unified My Content Automation 原文链接：https://dev.to/debs_obrien/from-prompt-files-to-agent-skills-how-i-unified-my-content-automation-3h9k 原文发布：2026-07-10 本博客不参与任何商业变现（含 ads / 付费 / affiliate），本译文遵循 CC BY 条款发布。

【译者按】

2026 年，AI 编码 Agent 已经成为开发者日常工具箱的一部分，但绝大多数团队仍然在用”零散的 prompt txt 文件”指挥 Agent，导致指令重复、无法跨工具复用、缺乏错误恢复机制。这篇文章的作者 Debbie O’Brien 分享了她如何从三份简陋的 VS Code Copilot prompt 文件，逐步演进为一套结构化的跨平台 Agent 技能（Skills）体系——涵盖 Hermes Agent、Claude Code 等兼容标准。

这篇文章对中文 AI 开发者社区有独特价值：国内在 Agent 技能（Skills）标准化方面讨论甚少，大多数实践仍停留在”写 prompt → 复制粘贴 → 手动补坑”的阶段。而本文提出的渐进披露模式（Progressive Disclosure）、引用文件（Reference Files）架构、以及”技能积累操作知识（operational knowledge）“的迭代闭环，恰好填补了这一空白。虽然文章以内容自动化为场景，但其核心方法论——如何设计可复用、跨工具的 Agent 技能——适用于任何 Agent 工作流。

文中涉及 Hermes Agent 的技能标准（.agents/skills/ 目录结构、SKILL.md 格式），与本博客常用的架构一脉相承，中文圈读者可以无缝对照实践。

【正文】

从 Prompt 文件到 Agent 技能：如何统一我的内容自动化流程

几周前，我写过一篇关于如何利用 AI Agent 和 MCP 来自动化我的网站内容的文章。那篇博客介绍了我的初始方案——我创建了大量的内容，保持网站更新是一件相当繁琐的事。而本文是关于接下来发生的故事：我如何将那些初始的 prompt 文件演进为更强大的能力。

我的起点：三个 Prompt 文件

我的初始设置非常简单——三个独立的 Markdown 文件，每个对应一种内容类型：

├── playwright-add-video.prompt.md
├── playwright-add-podcast.prompt.md
└── playwright-add-blog.prompt.md

每个文件都相当简短。下面是视频 prompt 的内容：

使用 MCP 服务器导航至 URL 获取所需信息。
如果未提供 URL，询问用户。
不要编造标题和描述。
不要添加额外的标签——只使用已有视频文件中存在的标签。
确保视频的日期正确。
确保添加 host。
完成时关闭浏览器。

大约 15 行松散的指令。播客和博客的 prompt 几乎完全相同——相同的结构、相同的规则，只是字段稍有差异。它们确实能用！我打开 VS Code，运行 prompt，AI 就会帮我创建文件。

但随着时间的推移，我开始注意到问题所在。

什么是有效的，什么是无效的

核心思路是好的：给 AI 一个 URL，让它浏览页面、提取元数据、创建文件。这部分很棒。

但问题同样明显：

指令重复到处都是。 所有三个 prompt 都有相同的规则：“不要编造内容”、“只使用已有标签”、“验证日期”。如果我想修改标签的验证方式，就得更新三个文件。而且它们已经开始出现差异——播客 prompt 引用了 microsoft/playwright-mcp/*，而视频 prompt 引用的是不同的 MCP 配置。

没有验证步骤。 prompt 创建完文件就结束了。我无法知道内容是否真的能在网站上正确渲染——除非手动启动开发服务器检查。

创建文件后仍需要手动操作。 创建完文件，我还得手动创建分支、提交、推送、打开 PR。这正是我最想自动化但又最无聊的部分。

锁定在 VS Code + Copilot。 frontmatter 是 VS Code 的 Copilot Agent 模式特有的。我无法将这些 prompt 与 Goose、Claude Code 或其他 AI Agent 一起使用。

对于可靠性来说太模糊了。 “使用 MCP 服务器导航至 URL”对于人类阅读来说没问题，但 AI Agent 需要更具体的指导。当 YouTube 显示 Cookie 同意对话框时会发生什么？如何提取日期？浏览器关闭后怎么提交和推送？

迁移：构建第一个 Skill

我决定将这些 prompt 转化为技能（Skills）——可在不同 AI 编码 Agent 之间移植的指令集。技能存放在 .agents/skills/ 目录中，遵循标准格式，包含一份 SKILL.md 文件，任何兼容 Agent 都能发现并使用它。

我从视频 prompt 开始——这是我用得最多的一个。我没有使用 Playwright MCP 服务器（它需要特定的 MCP 配置），而是使用了 playwright-cli——一个通过常规 shell 命令进行浏览器自动化的独立 CLI 工具。这意味着任何具有 shell 访问权限的 Agent 都能使用它。

第一个版本很简单——将 15 行的 prompt 翻译成详细的技能，包含实际步骤：

# 不再是"使用 MCP 服务器导航到"
playwright-cli open "https://www.youtube.com/watch?v=VIDEO_ID"
playwright-cli snapshot

# 读取快照 YAML 提取元数据

然后我用实际添加一个真实视频来测试它。就在这一步，事情变得有趣了。

测试揭示的真实世界问题

用真实的 YouTube 视频测试立刻暴露出原始 prompt 从未考虑过的一整套问题：

Cookie 同意对话框。 YouTube 显示了一个全屏的 Cookie 同意对话框，遮挡了所有内容。技能需要检测并接受它，然后才能提取任何元数据。

日期不在表面上。 YouTube 最初显示的是”7 天前”而非实际日期。你必须点击”…更多”按钮展开描述，才能看到确切的发布日期（如”2026 年 2 月 11 日”）。

快照文件需要读取。 playwright-cli snapshot 命令将 YAML 文件保存到磁盘。你无法只看命令输出——你需要实际读取文件并解析标题、描述、频道名称和日期。

Shell 环境问题。 Node.js 是通过 nvm 安装的，不在默认的 shell PATH 上。每个 shell 命令都需要先 source nvm。GitHub CLI 在 ~/go/bin/gh 上，也不在 PATH 中。通过 HTTPS 推送到 GitHub 需要运行 git credential 配置。

原始 prompt 完全没提到这些。 而且它也不需要提——因为人类会在现场处理这些边界情况。但对于一个完全自主的工作流——Agent 需要创建分支、提交代码、推送到远程且不出错——这些细节就变得至关重要。

我把所有这些经验教训直接记录到了技能中。每次出错，我就更新指令。这正是使技能如此强大的迭代循环——它们能积累操作知识（operational knowledge）。

架构决策：一个技能，不是三个

当视频技能端到端工作后，我审视了播客和博客的 prompt，发现约 70% 的指令在三个内容类型之间完全相同：

  • Shell 环境设置（nvm、gh 路径）
  • 浏览器自动化工作流（打开、快照、提取、关闭）
  • 标签验证（只使用已有标签）
  • Git 工作流（分支、提交、推送）
  • 开发服务器验证（启动、截图、确认）

每个内容类型的独特部分只有：

  • YouTube 特有提取（视频 ID、缩略图 URL、展开描述）
  • 播客平台提取、图片上传到 Cloudinary
  • 完整文章正文提取、规范 URL 处理

如果创建三个独立的技能，意味着共享指令会被重复三倍，而且元数据会被反复加载到 Agent 的上下文中。

遵循 Anthropic 技能创建者指南中的渐进披露（Progressive Disclosure）模式，我将其结构化为一个技能加多个引用文件：

.agents/skills/add-content/
├── SKILL.md                  # 核心工作流 + 路由（75 行）
├── environment.md            # Shell 环境、git、开发服务器、PR 创建
├── video.md                  # YouTube 特有提取 + frontmatter
├── podcast.md                # 播客提取 + Cloudinary 上传
└── blog.md                   # 博客内容提取 + 规范 URL

SKILL.md 非常精简——仅 75 行。它根据 URL 判断内容类型，指向正确的引用文件，并定义核心工作流。Agent 只加载它实际需要的引用文件。

当我说”添加这个 YouTube 视频”时，Agent 加载：

  • SKILL.md（75 行）——核心工作流
  • references/environment.md（126 行）——Shell/git/PR 设置
  • references/video.md（79 行）——YouTube 特有步骤

总共 280 行的上下文，而不是加载三个独立的 275 行技能所需的元数据。

前后对比

特性Prompt 文件（之前）1 个技能 + 4 个引用文件（之后）
指令行数每个 ~15 行（共 45 行）480 行总计（但渐进加载）
代码重用~70% 重复零重复——共享逻辑在 environment.md
可移植性VS Code + Copilot 专属Goose、Claude Code、任何支持技能的 Agent
浏览器工具Playwright MCP 服务器（需 MCP 配置）playwright-cli（独立 CLI，仅需 shell）
验证无自动：启动开发服务器，用 playwright-cli 截图
Git 工作流手动自动：分支、提交、推送、PR
Cookie 处理无检测并处理 Cookie 对话框
日期提取”确保日期正确”具体方案：点击”…更多”，读取展开的描述
错误恢复知识无nvm source、gh 路径、git auth、URL 引号处理
图片处理（播客）手动自动：从页面提取 → 通过 Cloudinary MCP 上传
端到端自动化URL → 文件（然后手动补坑）URL → 文件 → 验证 → PR（完全自主）

最大的转变不是任何单一功能——而是技能捕获了操作知识。我在测试中遇到的每一个边界情况现在都被编码在指令中。下次 Agent 运行这个工作流时，它不会再遇到同样的问题。

现在的运行流程

当我说”把这段视频加到网站”并粘贴一个 URL 时，实际上发生的是：

  1. Agent 检测到它是 YouTube URL，加载视频引用文件
  2. 用 playwright-cli 导航到视频
  3. 如果出现，处理 Cookie 同意对话框
  4. 展开描述以获取精确的发布日期
  5. 提取标题、描述、日期、频道名称和视频 ID
  6. 检查已有标签，只选择有效的标签
  7. 使用正确的 frontmatter 创建 Markdown 文件
  8. 启动开发服务器，验证视频出现在网站上
  9. 提交、推送、打开 PR

我只需要合并 PR。这是我唯一的手动步骤。

它变得更好了

因为技能遵循标准格式，它们可以在不同 AI 编码 Agent 之间移植。我现在用的是 Claude Code，但同一个技能也适用于任何支持该标准的 Agent。

播客工作流现在会自动将图片上传到 Cloudinary，而不是让我手动操作。博客工作流会提取完整的文章内容，并处理跨平台发布内容的规范 URL。

因为技能通过迭代积累知识，它们会不断变得更好。 每次发生意外情况时，我都会更新引用文件，下一次运行就会更顺畅。

给我的启示

如果你现在使用 prompt 文件，并且发现自己不断重复指令，或者在 AI 创建文件后还要手动处理后续步骤，考虑迁移到技能。编写详细的引用文件的初始投入是值得的——尤其是当工作流跨越多个内容类型、涉及多种工具、而且你希望 Agent 能在无人值守的情况下可靠运行时。

最有价值的收获：一个技能的价值不只是它的指令——还有它捕获的每一条操作知识。 每一条”当 X 发生时做 Y”的规则、每一个被核实过的路径、每一种错误恢复——这些都是你（或你的团队成员）不需要再次手动处理的问题。

这就是从 prompt 文件到技能的最终迁移：不仅仅是更好的指令，而是累积的经验，封装成可重用的形式。

【译者注】

  • Skills（技能）：这是 Hermes Agent / Claude Code / Goose 等 AI Agent 工具支持的可复用指令集格式。技能存放在 .agents/skills/<name>/SKILL.md 中，Agent 在启动时自动发现并加载匹配的技能。其核心理念是”编写一次，到处使用，不断迭代”。
  • Progressive Disclosure（渐进披露）：一种信息设计模式——先展示核心工作流，仅在需要时才加载细节引用文件。这减少了 Agent 每次运行的上下文开销。与”把所有指令塞进一个文件”的方案相比，更能控制 token 消耗。
  • playwright-cli：Playwright 的命令行接口，无需编写 Node.js 代码即可通过 shell 命令进行浏览器自动化（打开页面、截图、获取快照）。相比 Playwright MCP 服务器，它的优势是纯 shell 依赖，任何 Agent 只要有 shell 访问就能使用。
  • MCP（Model Context Protocol）：Anthropic 提出的标准化协议，用于连接 AI 模型与外部工具和数据源。本文作者早期使用 Playwright MCP 服务器，后来转向更轻量的 playwright-cli。
  • nvm（Node Version Manager）：Node.js 版本管理工具，默认不会将 Node 添加到全局 PATH，因此 shell 命令中需要 source nvm 才能使用 Node/npm。
  • Cloudinary：云端的图片和视频管理平台，提供上传、转换、优化等功能。本文中用于自动上传播客封面图片。
  • Hermes Agent：与本文 Skills 标准兼容的 AI Agent 框架，支持 .agents/skills/ 目录结构。本博客的读者可以无缝对接本文实践。

【延伸阅读】