QDKT：Skills 设计开发精讲：场景识别&重复流程封装

m0_73724698

316人浏览 · 2026-07-09 07:05:23

m0_73724698 · 2026-07-09 07:05:23 发布

一、先对齐认知：Skill 不是"提示词封装"，而是 Agent 的"文件化能力单元"

如果你认为 Skill 就是写一段高级提示词（Prompt），然后让 Agent 去执行，那你的理解还差了一层。

在当前的 Agent 产品形态下（无论是 Workbody、Claude Code、Codex 还是 OpenClou），Skill 必须依赖文件系统。它不是一个悬浮在后端的配置，而是一套存放在 Agent 可访问路径下的文件组合：

Skill.md：核心指令文档，包含 name 和 description；
References/：参考资料、模板、知识库；
Scripts/：可执行的脚本文件。

当你"安装"一个 Skill 时，本质上并不是上传到云端服务器，而是在 Agent 的根目录或项目目录下创建了一个文件副本。Agent 在启动时，会读取 Skill.md 前端的元数据（name + description）注入到系统提示词（System Prompt）中；当任务需要时，Agent 再通过文件读取工具（如 read_file、bash）去加载完整内容并执行脚本。

核心结论：Skill 的本质，是利用大模型"能读文件"的能力，给 Agent 增加可渐进式加载的上下文约束和可复用的执行策略。它不是提示词的简单延伸，而是一个完整的、文件化的能力单元。

二、重新定义 Skill：从"它是什么"到"它怎么做"

市面上很多定义只告诉你 Skill 是"封装标准化流程，让 Agent 更可控地完成任务"。这个定义只能用来聊天，不能用来干活。

真正对产品经理和开发者有价值的定义是：

Skill 是将 Agent 在某个垂直场景中需要的知识经验、执行流程和环境约束，封装成可复用的文件化能力单元。

这个定义里包含了 Skill 开发的三个核心维度：

维度	解决的问题	本质
知识经验	大模型不知道什么	补齐模型认知，让 Agent 更懂行
执行流程	大模型怎么干才靠谱	约束 Agent 按固定步骤执行，降低随机性
环境约束	大模型在什么边界内干活	限定专属场景（如公司内部数据库 Schema、特定报告格式）

这三个维度不是割裂的。一个复杂的 Skill 往往是"特定知识 + 固定流程 + 环境限定"的融合体。

三、Skill 设计的四层方法论：用 IPO 模型拆解一切

做 Skill 设计和做产品设计的逻辑完全一样，都是 IPO（输入-处理-输出）。但 Skill 的特殊之处在于，每一层都包含两个视角：用户视角 和 Agent 视角。

第一层：输入层（Input）——解决"用户该给什么"

很多任务做不好，不是因为 Agent 不行，而是因为用户输入的信息不完整、不清晰。

Skill 在输入层的价值，是帮助用户完成需求澄清和上下文构建。

典型案例是 PMMake Skill：它通过一系列结构化提问（意图识别、场景分流、材料判断、信息确认），把一个产品小白也能回答的问题，转化为足够让 Agent 开发完整产品的 PRD。

两个设计思路：

输入约束型 Skill：约定好启动任务所需的必填信息，Agent 在信息不足时主动追问，而不是瞎猜。
输入辅助型 Skill：把专家经验转化为提问清单，让非专业用户也能给出专业级输入。

第二层：上下文层（Context）——解决"Agent 该拿什么"

用户给了输入，不代表 Agent 拥有完成任务所需的全部上下文。Skill 需要明确告知 Agent：

哪些数据是有用的（避免 Agent 在无关文件上浪费 Token）；
哪些数据需要主动获取（如读取本地数据库、调用 API、查询特定 Reference）；
哪些数据是环境自带的（如系统信息、用户偏好、历史 Memory）。

关键认知：Skill 不只是用户给 Agent 的输入，也是产品经理替用户预设的"信息包"。

第三层：执行流程层（Process）——解决"Agent 该怎么干"

这是 Skill 最显性的价值。大模型最大的毛病是自由发挥——你以为它会按 1-2-3 执行，它可能给你 1-3-2，甚至漏掉第 4 步。

流程封装的三种手段：

文档约束：在 Skill.md 中写明步骤 1/2/3/4/5，让 Agent 按顺序执行；
脚本固化：把确定性流程写成脚本（Python/Shell），让 Agent 调用脚本而非自主规划。脚本是传统软件，规则清晰、输出 100% 稳定；
输出驱动：让脚本一次性生成多个中间文档，再让 Agent 逐个处理，通过"产物"控制"流程"。

两种流程型 Skill：

全自动型：封装完整流程，Agent 一键执行到底；
人机协作型：Agent 每完成一个阶段就停下来询问用户，把决策权交还给人（如"这一步是否继续？"、"方案 A 还是 B？"）。

第四层：输出层（Output）——解决"交付什么"和"怎么保证质量"

输出层同样包含两个维度：

1. 产物结构（用户不知道要什么） 用户知道要"爆款文案"，但不知道爆款文案长什么样。Skill 需要内置专家模板和格式规范，约束 Agent 稳定产出达标内容。

2. 产物填充（用户知道要什么但不知道怎么生成） 用户知道最终要一张 Excel 报表，也知道表头结构，但不会从 SQL 数据库提数。Skill 需要接收用户的"空模板"，自动完成数据填充和加工。

3. 质量控制（Agent 怎么知道自己做对了） 大多数人干完活需要等老板反馈才敢下班，因为他们没有判断标准。Skill 必须给 Agent 内置交付标准和自测机制：

Checklist 校验；
脚本自动验证（如代码 Lint、数据对账）；
同级评审标准（如技术评审 + 产品评审 + 用户视角评审）。

四、从模型缺陷反推：你的 Skill 到底该补哪块？

Skill 设计的底层逻辑永远不变：弥补大模型的缺陷。以下是开发 Skill 时必须对照的"缺陷清单"：

缺陷类型	具体表现	Skill 的应对策略
自由发挥	不按约定步骤执行，1-2-3 变成 1-3-2	流程文档 + 脚本固化
知识盲区	不知道公司制度、内部 Schema、行业黑话	复制经验，加载 Reference
概率性输出	每次结果不一样，标准漂移	固定模板 + 强制 Schema + 脚本校验
长链路漏步骤	任务链越长，越容易丢环节	分阶段交付，每阶段设置 Checkpoint
格式不稳定	YAML 写错、JSON 漏括号、SQL 表关系混乱	脚本生成 + 格式校验
工具调用顺序混乱	先调了 A 再调 B，但 B 依赖 A 的输出格式	在 Skill 中明确工具依赖关系
幻觉与假设	信息不足时自己编造数据、Mock 新闻	输入层强制信息确认，禁止假设
批量处理衰减	一次生成 10 个文档，越往后质量越差	拆分为脚本批处理，而非让模型一次性生成
单一视角	评审时只看技术，不看产品/用户体验	在 Skill 中约定多维度评审标准
过度解决	模型为了"表现好"多干了很多不该干的活	明确边界，限定"不要做什么"
过程不可审计	拍出一个数字，但给不出推导过程	强制输出思维链（Chain of Thought）
能力不迭代	公司规范变了，Agent 还在按老规矩干活	通过更新 Skill 文件实现能力迭代

核心建议：做 Skill 之前，先不要想"我要做什么功能"，而是先对照上表问："这个场景下，大模型最可能在哪翻车？" 你的 Skill 就是针对翻车点的补丁。

五、最高频的场景：把复杂能力"产品化"给非专业用户

在几十个 Skill 应用场景中，未来半年你最可能落地的是这一类：

把原本需要专家经验、多步骤协作的复杂任务，封装成一键可用的 Skill，让非专业用户也能产出专业结果。

这正是 PMMake 等 Skill 的核心逻辑：

原来需要一个资深产品经理花 2 小时梳理的 PRD 框架；
现在通过一个 Skill，把框架拆解成 10 个选择题和填空题；
非产品经理用户回答完后，Agent 自动生成了符合规范的 PRD。

这种 Skill 的设计要点：

输入层做得足够重：把专家的知识转化为用户能回答的问题；
流程层做得足够隐形：用户不需要知道背后有 7 个步骤；
输出层做得足够标准：确保产物直接可用，不需要二次加工。

六、给从业者的行动建议

如果你还在做 Workflow：开始关注 Skill。Skill 不是 Workflow 的升级版，而是面向 Agent 原生能力的新范式。当行业从"搭工作流"转向"装 Skill"时，先懂的人先占坑。
如果你是产品经理：Skill 开发能力将成为 AI 产品领域的标配。它考验的不是写代码，而是对大模型能力边界的理解 + 把业务经验结构化的能力。
如果你要设计 Skill：不要从"我想让 Agent 做什么"出发，要从"大模型在这个场景下会犯什么错"出发。Skill 的价值不是增强 Agent，而是约束 Agent。