从长Prompt到结构化技能：如何让AI工作流更可控、更可复用。
核心内容：
1. 长Prompt的三大痛点：精确与遵循的矛盾、出错难排查、复用成本高
2. 根因剖析：流程控制缺失与领域知识无法独立维护
3. 解决方案：从“一段话”升级为结构化、可复用的“技能”

一、越来越长的 Prompt

2025 年底，我开始做一个每日 AI 新闻简报系统。第一版是一个 prompt，三四百字，让模型从多个信源中筛出当天值得关注的内容，按重要性排序，输出一份简报。

效果不错。但很快我发现，模型对"重要性"的排序不是我想要的：它把人事变动排在了技术突破前面。于是我加了一段优先级规则。

过了几天，又出现不同来源的同一条新闻重复展现的问题，有时还把两条不同的新闻合并成一条。于是我又加了去重和合并规则。

接着是信源可信度分级、数字标注要求、中英文格式差异……

三个月后，这个 prompt 膨胀到 3000 字。每次一动规则，其他地方就开始漂移。

我开始怀疑：是我提示词工程做得不够好，还是这种形态本身就有天花板？

二、当"一段话"成为天花板

现在回头看，答案是后者。天花板不在某条规则，在形态本身。

那 3000 字，大概和你写过的长 prompt 差不多：开头交代角色和任务；中间是操作顺序，夹着各种判断标准——什么消息算重要、哪些信源更可靠；再往后是格式要求、输出示例；结尾还有一串"不要……"，每一条都是某次翻车后补的。这些内容性质各异：有的是流程，有的是领域知识，有的是格式约定。但扁平文本把它们压成一段话，全量塞进上下文，一次性执行。这就带来三个问题。

越精确，越难遵循。规则要可执行，就得写全定义、示例、边界情况；写得越全，上下文越长。而公开评测显示，上下文拉长后，模型对中间位置信息的利用率明显下降；指令数量增多时，单条指令的遵循率也随之走低。我的简报系统掉进了这个循环：中间规则被"稀释"，模型读了，但执行不严；加规则修补，prompt 更长，遵循更差。

出错无从排查。整个流程一步到底，没有中间产物。简报里冒出一条本该被去重的新闻，你分不清是提取多了、去重漏了，还是生成时编造的，也不能只重跑出错的那一段——能做的只有改 prompt、整体重跑、肉眼比对。

复用就是复制重来。这 3000 字是为"每日 AI 简报"一点点长出来的，但真正值得复用的部分——信源分级、去重逻辑、格式规范——和任务细节缠在一起，拆不出来。想改出一个周报版，只能整段复制再改，改完又是一个同样臃肿的新版本，同样的问题重演一遍。

把三个问题往下挖，会发现根子只有两个。

流程控制缺失。所有步骤塞在一段话里，对模型来说只是建议——它可以跳过、混合、在长上下文中遗忘；而你没有机制在步骤之间插入检查点、持久化中间产物，或按错误类型回退到特定阶段。出错无从排查，正是它的直接后果。

领域知识无法独立维护。领域知识和执行指令混在同一段文本中，无法独立版本化、独立更新、独立复用。规则一变，你得在几千字里找到那几行改掉，同时担心牵动别处。精确与遵循的矛盾、复用之难，都从这里来。

Anthropic 工程博客用 procedural knowledge（流程知识）和 organizational context（组织上下文）概括了同样的观察。

这不是提示词写得不够好，是形态本身的设计边界。Anthropic 给出了自己的解法，就是 Agent Skills。

三、Skill 是什么

2025 年 10 月，Anthropic 发布了 Agent Skills。同年 12 月，它将 Skill 的文件规范作为开放标准发布。此后主流开发工具陆续跟进：OpenAI（Codex CLI）、微软（VS Code）、Google（Gemini CLI）、JetBrains（Junie）、AWS（Kiro）等数十个工具已支持或声明兼容这一规范，不过各家的接入深度、触发方式和目录约定并不完全一致。

Skill 因此不绑定任何特定平台——下文讨论的是这个跨厂商开放规范层面的共性。

先看官方对 Skill 的定义。

官方定义

Anthropic 把 Agent Skills 定义为：

官方还有一个更直观的类比：

——Anthropic 官方文档《Agent Skills Overview》

一句话：Skill 把某类专业流程、领域规则和可复用工作模式封装成一个可维护的能力包。

这跟 prompt 有什么本质区别？基于官方文档和我自己的项目实践梳理如下：

表格概括了结构差异。落到工程实践，四个变化最值得展开。

领域知识独立维护。最直观的例子是领域规则：在 prompt 里你写"按重要性排序"，模型每次都要重新推断什么是"重要性"——同一条 prompt 跑两次，排序结果可能不同。

在 Skill 里，优先级框架是一个 reference 文件，明确定义哪类事件排前面，与执行指令分开存放。规则变了，改一个文件，执行指令不受影响。同理，格式规范、领域术语表、信源分级标准——凡是独立于执行流程、有自己更新节奏的知识，都适合拆入 reference 文件。

确定性任务交给代码。在 prompt 里你让模型"计算两条新闻的内容相似度，超过阈值就标记为疑似重复"。这是确定性计算，不该靠概率模型。

在 Skill 里，这类工作拆到 scripts/，由 Python 代码确定执行。模型只负责语义判断：两条新闻相似度高，但一条讲模型发布、一条讲融资，应该分开。

质量保障从人工到脚本。Prompt 模式下，模型输出后你只能逐条人眼检查。Skill 模式下，可以在关键步骤之间插入验证脚本，检查中间产物和最终输出。

这不是小众玩法：Anthropic 官方 pdf skill 的 scripts/ 里，create_validation_image.py 这类检查脚本就用于表单填写流程中的质量检查。在我的简报系统里，分析记录生成后、简报输出前也各有一道验证：通不过就回退到对应步骤，不是带着错误继续往下走。

上下文按需加载。Prompt 模式下，所有指令全量塞入上下文窗口。Skill 采用 progressive disclosure（渐进式加载）：启动时只加载元数据（约 100 tokens/Skill），触发时才读入指令主体（建议 <5k tokens），参考文件按需读取。这是加载策略层面。执行层面还有一道隔离：脚本通过 bash 执行，代码本身不进入上下文窗口。这意味着你可以安装几十个 Skill，大部分内容留在文件系统里，只在真正需要时才被读取。三层加载的具体机制和文件结构，后续文章会展开。

以上四个变化指向一个更大的收益：可独立迭代。Skill 的构建是一个长期的过程，它需要持续迭代。但和 prompt 不同，迭代的单元是结构化文件：你可以独立更新领域规则而不动执行指令，单独升级验证脚本而不影响参考资料。迭代是靶向的，不是"改一段文本然后祈祷其他部分不受影响"。

Skill 不会孤立存在——它在一个由 Agent、Tool 和 MCP 构成的体系中运行。划清边界，才能看清它的位置。

容易混淆的概念

围绕 Skill 有三个常被混用的概念。核心区分各一句话：

Agent：运行时决策 vs 设计时知识。 Agent 是运行时的决策主体——理解意图、选择工具、动态调整路径；Skill 封装的是设计时固化的决策：领域专家的经验被写成流程与规则，在运行时按需加载进 Agent 的上下文。Agent 执行 Skill 中的指令，但保留跳过或变通的权力——Skill 是指导而非硬约束。

Tool：原子能力 vs 领域规范。 Tool 是原子动作接口——搜索、读写文件、调用 API，每次调用完成一个单一操作；Skill 规定的是如何组合这些原子能力：调用顺序、约束条件、质量标准和异常处理策略；其中确定性强的环节，还可以下沉为 Skill 自带的脚本来执行。Tool 提供能力，Skill 规定如何使用这些能力以达到专业水准。

MCP：连接层 vs 知识层。 MCP 是连接层协议，负责把外部系统能力以标准化 Tool 的形式暴露给 Agent。Skill 不负责连接外部系统，也不直接调用 Tool——调用的主体始终是 Agent。Skill 规定的是 Agent 拿到这些能力之后怎么用：先查哪个源、何时去重、结果不达标时如何回退。

需要说明的是，这四者并非严格的架构堆栈——Skill 不是位于 Agent 和 Tool 之间的中间件，而是被 Agent 按需加载的知识资产。更准确的图景是三个面：MCP 和 Tool 构成能力面，Skill 构成知识面，Agent 构成决策面。

以新闻简报类系统为例：信源经 MCP 接入（连接），Tool 提供获取内容的原子动作（能力），Skill 编码筛选、去重、排序的规则与验证标准（知识），Agent 在运行时决定何时调用、是否变通（决策）。

四、该不该升级

Skill 把领域知识从执行指令中独立出来，把确定性任务交给脚本，用可选的验证机制守住质量底线。但这些收益有对应的成本——文件结构要设计，脚本要写和维护，reference 文件要持续更新。不是所有工作流都值得付出这些成本。

是否值得封装，可以从两个层面四个维度判断。

第一层：值不值得结构化。 这两个维度几乎对所有工作流都适用，优先看。

使用频率：这个流程每周跑几次？偶尔用一次的临时任务，prompt 复制粘贴就够了。每天或每周都在执行同类任务——生成行业简报、整理竞品动态、出合规报告——重复性本身就是结构化的理由。

出错代价：出错的后果是什么类型？格式不对、排序不准这类问题，自己用的话调一调就好。流向客户、投委会或合规部门的输出，错误的代价远不止返工——仅 2024 年，就有数十家 A 股上市公司因年报中数据前后不一致、正负号写反、错误版本上传这类低级错误收到交易所监管函或证监局警示函。后果越严重、且错误可以被规则检测，自动化验证的价值越大。

第二层：Skill 的架构优势能否发挥。 这两个维度视具体场景而定。

领域知识：工作流是否依赖专用领域规则或参考资料？优先级框架、信源可信度分级、合规检查清单、格式规范——这些知识和执行指令纠缠在同一段 prompt 里，每次更新都是整体手术。如果通用常识即可完成判断、规则很少改变，这一层不需要。

协作移交：流程只有你自己用，"只有作者能维护"就不是问题。团队成员需要复用、新人需要接手时文件结构的可读性与长文本相比优势开始凸显。

一个边界：这个框架针对的是有明确流程和可编码规则的重复性任务。探索性、创意性的工作——头脑风暴、开放式调研、概念验证——依赖发散思维和即兴判断，固化流程反而是约束，不在讨论范围内。结构化也不是越早越好：流程开始稳定、错误开始可分类、规则开始复用时，封装才有回报。

拿几个场景验证一下：

• • 法律合规审查：每月执行，有公司内部领域规则，结论进正式报告。使用频率、领域知识、协作移交三维命中，值得封装。
• • 竞品追踪与投研简报：每日执行，有私有评分模型，错误判断代价高。四维全中，强候选。
• • 安全事件响应：固定 runbook、公司特定阈值、审计合规严格。四维全中，属于强 Skill 化候选。

维度命中越多，封装的回报越高。如果你在上面认出了自己的工作流，从命中最多的那个开始。

五、案例复盘：从 3000 字 prompt 到 Skill

本文开头提到的那个 AI 新闻简报系统，最初是一个 prompt，三个月膨胀到 3000 字，后来我把它重构成了 Skill 版。一个文件夹，六步执行协议，三个脚本（一个预处理、两个验证），七个 reference 文件，一个迁移模板。

变化不是一步到位的：先拆出执行协议，明确每步的边界——Step 2 只做源内提取，不去重；Step 3 默认 separate，只有证据充分才 merge；再把确定性计算（相似度、实体提取）搬进预处理脚本；最后加上两道验证，分别在生成前检查分析记录、在生成后检查输出契约。

整个过程花了接近一周，大部分时间花在定义步骤边界和调试验证脚本上。收益不只在输出质量——稳定性和可追溯性的提升更明显：最终输出 → 分析记录 → 原始候选条目 → 源文件，每一层有据可查。代价是七个 reference 文件需要持续维护，但对每日执行的流程来说，这笔成本值得付。

这个项目给我的经验是：当工作流同时需要领域判断（优先级框架）、确定性计算（相似度计算）、质量校验（验证脚本）和多源输入（多个信源交叉验证）时，结构封装从"锦上添花"变成了可靠性的前提。

这套结构不是新闻简报专属——第四章的三个场景（法律合规、投研简报、安全事件响应）的工作流与它同构。这个简报系统只是本文用来观察这种结构的案例，不是唯一模板。

六、三个认识转变

复盘这次重构，输出质量和效率的提升只是表面。更持久的是三个思维方式的转变。

第一个：从"写指令"到"设计流程"。Prompt 模式下，思维是"告诉模型做什么"。Skill 模式下，思维变成"这个工作流分几步、每步的输入输出是什么、什么该由代码做、什么该由模型判断"。

在简报系统里，这意味着把"帮我从这些信源中整理一份简报"拆成六步协议——提取、去重、分析、排序、验证、生成——每步有明确的边界和交接物。

很像从口头交代任务到编写操作手册的转变：口头交代把所有要点一次说完就行，操作手册需要把流程步骤、领域规则、检查清单、参考资料分开放，各管各的。

第二个：从"看最终输出"到"中间产物更重要"。最终交付物——简报、报告——只是面向读者的呈现，执行过程中固化下来的中间产物（分析记录、候选清单）才承载着审计价值：输出错了，不再需要"改 prompt、重跑、肉眼判断"，而是沿着"最终输出 → 分析记录 → 原始候选 → 源文件"的路径定位到具体步骤。

拿第四章的投研简报场景说：进了投委会材料的一个错误数字，能不能在十分钟内回答出"它是在提取、去重还是生成阶段进来的"，很大程度上决定了这个流程能不能被信任。

第三个：从"个人手艺"到"工程资产"。前两个转变完成后，流程、中间产物、领域知识都变成了文件。文件可以版本管理、测试、审查、迁移到相邻场景、交给团队继续维护。

你可能是一个 prompt 高手，但你的经验很难复制给其他人。Skill 不能自动复制专家判断，但它把经验写进了文件结构——每份经验有名字、有位置、有边界，新人能看出哪些是执行指令、哪些是领域规则、哪些是验证脚本，以及哪些不能随意动。

这三个转变在个体场景下就已经效果显著；等到流程需要交给别人，红利才完全兑现——对方接手的不是你脑子里的手艺，而是一份可以直接上手维护的工程资产。

七、迈出第一小步

读到这里，如果你评估后认为自己的工作流值得封装，先别急着写脚本，也不必一步做出完整的能力包。从现在 ROI 最高的那个 prompt 开始，拆成两个文件：

• • SKILL.md：放 name 和 description（触发条件）、执行步骤、输入输出边界。
• • references/：放领域知识——需要时才查阅的规则、规范或参考资料。比如优先级定义、例外情况、格式要求。

它就变成了一个可被发现、可被触发的 Skill，而且执行指令和领域知识从第一天就分层存放。这一步成本很低，但你的流程已经从"一段复制粘贴的文本"变成了"有入口、有边界、规则可独立更新的结构"。后续再决定要不要加 scripts/、模板和其他资源文件。

如果你用 Claude Code，把这个文件夹放进 .claude/skills/ 即可；用其他支持 SKILL.md 的工具，目录位置和触发方式以对应工具的文档为准——本文讨论的是开放文件规范的共性，不是某一个平台的运行机制。

当你准备好进一步拆分领域规则和验证逻辑，下一篇会展开 Skill 的文件结构与每个文件的角色。

八、下一篇预告

Skill 到底由哪些文件组成？SKILL.md、scripts/、references/、assets/ 各自承担什么角色？下一篇打开这个结构，逐类讲清楚放什么、放哪里、为什么这样分。

——#2《Skill 的解剖学：包结构与文件角色》

本文简报系统案例来自作者自有项目实践，判断仅供参考。

参考资料

• • Anthropic 工程博客 — Equipping agents for the real world with Agent Skills：https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
• • Anthropic 开发者文档 — Agent Skills Overview：https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
• • Anthropic 官方 skills 仓库 — pdf skill：https://github.com/anthropics/skills/tree/main/skills/pdf

系列目录《Agent Skills 技术深潜》

1. 1. 从 Prompt 到 Skill：专业工作流的结构升级（本篇）
2. 2. Skill 的解剖学：包结构与文件角色
3. 3. 一个 Skill 是怎么跑起来的：发现、激活、执行与上下文管理

登录查看剩余 70% 内容