AI Skill 开发基本流程从灵感到可复用资产的完整复盘最近团队内部在推 AI Skill 标准化我手上正好有几个从零到一落地 Skill 的项目——包括给备课场景做的课程大纲生成 Skill给数学建模竞赛做的建模思路拆解 Skill还有给内部知识库做的问答增强 Skill。跑完几轮之后发现很多人对 AI Skill 的理解还停留在写一段提示词然后封装一下但真正决定一个 Skill 能不能被复用、能不能在不同场景下稳定输出关键在于你有没有一套可复用的开发流程。这篇文章不绕弯子直接把我个人实践下来的 AI Skill 开发流程拆开讲。从需求定义开始到逻辑设计、提示词工程、测试验证、发布迭代每一环节我都会讲清楚为什么这么做、怎么做、以及最容易在哪一步翻车。这套流程我验证过的场景包括AI 备课 Skill需要生成符合教学大纲、有互动环节的教案、数学建模 Skill需要输出可提交的论文框架、建模方案和降 AI 味处理、以及各类去 AI 味需求把大模型生成内容改写得更像真人写的东西。你会发现不管 Skill 的应用领域是什么背后的开发逻辑是共通的。1. 需求定义阶段输入输出边界比你想象的更重要很多人做 Skill 上来就写提示词这是最大的坑。我在接触 AI 备课 Skill 这个项目时第一版就是直接让大模型生成一份教案结果输出的东西四不像——有时候是教学设计有时候是教学反思有时候直接给你写一篇论文。原因很简单我没有定义清楚输入和输出的边界。1.1 先写输入-输出契约再谈功能一个合格的 Skill 需求定义至少要回答这几个问题定义项要回答的问题示例AI 备课 Skill触发条件用户什么时候会用到这个 Skill用户输入课程名称、年级、教材版本输入参数必须提供什么信息才能干活课程主题、适用学段、课时数、教学重点输出格式结果长什么样、什么结构包含教学目标、重难点、教学流程、板书设计、课后作业的结构化教案边界条件什么情况宁可拒绝也不要硬做缺少学段信息时先问清楚而不是猜一个年级我当时给 AI 备课 Skill 写的第一版输入契约是这样的需要用户提供课程名称、适用学段、具体的教材版本比如人教版或北师大版、预估课时。输出则固定为教学目标、教学重难点、教学过程按课时拆解、板书设计、作业设计、教学反思提示这几个模块。这个契约写完之后后续所有开发都变得清晰了。提示词不需要我费劲描述你要生成一份好教案只需要告诉模型将输入信息填入以下结构每个模块输出什么内容、遵循什么规范。这就是把写得好的模糊要求转化为可执行的明确格式。1.2 从真实使用场景反推需求需求定义不只是列参数还要从使用场景反推。比如数学建模 Skill用户最核心的痛点是拿到一道建模题不知道从哪里下手。所以这个 Skill 的输入不只是题目文本还应该包含用户当前所处阶段——是选题阶段、建模阶段还是论文写作阶段。不同阶段Skill 输出的内容完全不同。这个需求是从我和学生交流中发现的问题反推出来的。一开始我设计的数学建模 Skill 只是帮我分析这道题模型输出一大堆泛泛而谈的内容学生看了还是不知道怎么动笔。后来我把输入拆成两个参数一个是题目文本一个是当前阶段选题/建模/代码/写作。然后针对不同阶段分别设计输出模板比如选题阶段输出题目拆解、目标函数定义、可行方法筛选写作阶段输出段落结构、技术路线描述、降 AI 味改写建议。实操心得需求定义阶段多花一天后面能省一周。我的建议是动手写提示词之前先写一个没有任何提示词的输入-输出示例拿这个示例去和目标用户确认你要的是不是这个如果用户看到示例说对就是这个你才真正定义清楚了需求。2. 核心逻辑设计把 Skill 当小产品而不是提示词壳子需求定义完之后进入核心逻辑设计。这一步是区分可复用 Skill和一次性提示词的分水岭。一个真正的 AI Skill应该包含任务分解逻辑、输入校验逻辑、异常处理逻辑而不仅仅是大模型生成文本这一个环节。2.1 任务分解把复杂任务拆成可编排的步骤我在设计 AI 备课 Skill 时把生成教案这个任务拆成了 6 个子步骤补全缺失信息确认学段、课时、教材版本提取课程核心知识点根据输入的课程主题找出关键概念设计教学目标三维目标知识与技能、过程与方法、情感态度价值观编排教学过程导入-新授-巩固-小结按课时拆解生成配套资源板书设计、作业设计、拓展阅读装配输出按教案模板格式组装每个子步骤对应一个独立的 Prompt 片段或一个独立的大模型调用。这样做有个很大的好处当 Skill 输出质量不佳时我可以精确定位是哪个环节出了问题而不是整体推翻重来。比如某次用户反馈备课 Skill 生成的教案教学过程太笼统没有可操作性我看了一下问题出在第 4 步教学过程编排因为那一步的指令只是说设计教学过程没有规定每个教学环节要包含教师活动、学生活动、设计意图三个维度。我只需要单独修改这一步的 Prompt其他步骤不受影响。2.2 输入校验与边界保护Skill 开发经常忽略输入校验。一个设计良好的 Skill应该在入口处判断用户提供的信息是否充分而不是把信息不完整的问题抛给大模型去猜。以 AI 备课 Skill 为例我设置了三条输入校验规则缺少课程名称直接返回请提供课程名称缺少学段信息追问这个课程面向几年级学生课时数不合理比如超过 40 课时提示教案生成支持单课时或单元整体设计请确认课时数这种校验逻辑写起来很简单但它大大提升了 Skill 的用户体验。没有校验的情况下大模型可能会假设一个学段开始输出结果用户发现内容完全不适用——这种体验伤害一次用户可能就再也不用你的 Skill 了。数学建模 Skill 的边界保护更特殊。因为建模题的背景五花八门模型经常遇到完全没见过的领域。我加的规则是如果题目涉及专业领域比如生物医学或金融风控Skill 先输出本题涉及的背景知识假设让用户确认然后再进入分析阶段。这其实是在用交互消解不确定性——让用户参与进来而不是让模型自己硬编。2.3 状态管理与会话连续性另一个容易被忽略的设计点是状态管理。有些 Skill 需要多轮对话才能完成任务。比如数学建模 Skill 的流程是先拆解题目-再确定建模方法-再写代码-再改论文这个流程跨越好几轮对话。如果每轮对话都让用户重新描述一遍题目和背景体验会非常差。我的做法是利用上下文变量把题目文本、拆解结果、建模方法、代码版本等信息存储在一个上下文对象里每轮对话开始时Skill 会先读取这个上下文确认当前进度和下一步动作。这就像开发一个 Web 应用时把用户会话状态存到 Session 里一样本质是同一个思路。实操心得任务分解的粒度以每个子步骤能被单独验证为标准。如果某个子步骤的输出你无法判断好坏说明它拆得还不够细。我自己经历过一次把生成教案拆成 6 步之后依然觉得教学目标设计这一步输出的东西质量不稳后来又把这一步骤细化为先提取核心知识点-再映射到对应学段的课标要求-最后生成三维目标描述质量立刻稳定了。3. 提示词工程让大模型按规则办事而不是自由发挥提示词工程是 AI Skill 开发中占比最大也是大家最熟悉的部分但很多人的写法有问题。你看网上大量 Prompt 教程教的都是你要扮演一个XX角色你要做到XX这种人格化指令这在一次性对话里好用但放到 Skill 里往往是灾难——因为你没办法控制模型在什么条件下输出什么格式。3.1 结构化指令优于角色扮演我在 AI Skill 里几乎不写你是一个资深教师这种角色设定。原因有两个。第一角色设定对输出质量的提升往往是玄学模型在角色扮演状态下确实会改变语气但不会改变输出结构的稳定性。第二角色设定容易导致输出内容过度表演——比如你让 AI 扮演资深教师它可能会在教案里塞一堆体现核心素养这种空话反而降低了实用性。我更倾向于写明确的规则和约束。以备课 Skill 的教学目标生成模块为例我的 Prompt 核心部分长这样请基于以下输入生成教学目标 - 课程名称{course_name} - 学段{grade_level} - 核心知识点{key_points} 要求 1. 按照知识与技能、过程与方法、情感态度价值观三个维度输出 2. 每个维度下目标描述必须以行为动词开头如能够理解运用禁止使用了解一些掌握相关知识等模糊表述 3. 目标必须与输入的核心知识点一一对应不得出现输入中未提到的内容 4. 每个维度最多输出3条总字数控制在200字以内 5. 输出格式使用无序列表每个维度用加粗标题分隔可以看到这份 Prompt 没有任何你要做到最好这种模糊要求全部是可检查的硬性规则。模型输出的内容我可以用规则去验证是否以行为动词开头是否出现了输入之外的知识点是否超过了字数限制这种可验证性是 Skill 能稳定输出的关键。3.2 少样本示例比规则更有说服力规则之外少样本示例few-shot examples是提升输出质量最有效的手段。尤其是在去 AI 味这个需求里规则很难穷尽什么是AI 味什么不是。我在做数学建模 Skill 的降 AI 味模块时踩过很多坑。刚开始我写的规则是避免使用首先其次最后、综上所述、值得注意的是等套话效果很差——模型确实不用这些词了但写出来的东西还是一股 AI 腔。后来我改成给模型看两个版本一个 AI 味很重的版本和一个真人写法的版本告诉它按后者风格改写效果立刻好起来。一个比较典型的对比示例数学建模论文的摘要改写场景AI 味版本本研究针对XX问题提出了一种基于XX模型的解决方案。首先我们对问题进行了深入分析其次我们建立了XX模型最后通过仿真实验验证了模型的有效性。真人版本这道题给了我们 1000 辆共享单车一周的使用数据要求预测下一个月的调度计划。我们发现直接套时间序列模型效果一般因为天气对骑行量的影响太大了所以我们在 ARIMA 的基础上加了一个天气修正项实验下来误差降低了 18%。你看到没有AI 味版本的问题是抽象名词堆叠、动词空洞进行深入分析、建立模型、验证有效性真人版本的特点是具体对象、具体行为、具体结果。这种差异很难用规则去穷尽描述但给模型看对比示例它一次就能领会。所以我在去 AI 味模块里的做法是维护一个AI 味句式黑名单这是规则层负责第一轮过滤然后配上 3 组改写对比示例这是示例层负责风格迁移。两个手段叠加效果才稳定。3.3 输出格式约束结构是稳定性的锚点提示词工程里还有一个经常被忽略的点输出格式约束。我做 Skill 时如果不需要模型自由发挥就一定会在 Prompt 里用 Markdown 模板或 JSON Schema 规定输出结构。例如备课 Skill 的教学过程编排模块我会这样约束输出格式严格遵循以下Markdown结构 ### 课时{number}{课时标题} **导入环节约{time}分钟** - 教师活动 - 学生活动 - 设计意图 **新授环节约{time}分钟** - 教师活动 - 学生活动 - 设计意图 **巩固环节约{time}分钟** - 教师活动 - 学生活动 - 设计意图这个模板的价值在于它把教学过程设计这个开放任务变成了填表任务。模型不需要思考怎么设计一个好教学过程只需要思考每个环节里教师做什么、学生做什么、为什么这样设计。事实证明填表式的输出比自由发挥式的输出质量稳定得多。实操心得写提示词时时刻问自己一句话——模型能不能逐条检查我的要求如果模型输出后你还需要肉眼判断这段写得好不好说明你的 Prompt 还不够结构化。最理想的情况是你可以写一段自动化脚本去验证输出是否满足 Prompt 中的所有硬性要求格式、字数、结构软性要求才需要人工判断。4. 测试验证与迭代没有评测体系的 Skill 都是在裸奔Skill 开发完不能直接发布必须先跑一轮完整的测试。但大多数人的测试方式是自己试几次看着还行就发这种测试方式基本等于裸奔。我的经验是Skill 必须有评测标准而且评测标准要在开发前就定义好和需求定义同步完成。4.1 三个维度的测试用例设计我给 Skill 做测试时会从三个维度设计测试用例维度要测什么用例示例AI 备课 Skill典型场景最常规的输入下输出质量是否达标输入《分数乘法》 五年级 人教版 2课时边界情况输入信息不全、极端参数下是否有合理应对只有课程名没有学段课时数为0课程名为空异常输入完全不相干或恶意输入下是否崩溃输入帮我写一首诗输入乱码文本每个测试用例我还会配上预期效果和验收标准。比如典型场景下教案的教学目标必须覆盖课程核心知识点、教学过程必须包含导入-新授-巩固环节、每个环节必须包含教师活动学生活动设计意图三个子项。这些验收标准是可检查的不通过就是不过没有差不多这个选项。4.2 案例复盘一次数学建模 Skill 的迭代记录我做过一个比较典型的迭代是数学建模 Skill 从 V1 到 V3 的升级过程拿出来分享一下。V1 版本的数学建模 Skill 很简单输入题目 - 输出建模思路分析。测试发现几个问题输出内容太学术化用户学生看不懂对于不同难度层级的题目输出的深度没有区分用户发现自己不知道怎么用这个分析结果去写论文针对这三个问题我做了 V2 迭代。核心改动有两个一是增加目标读者参数让用户选择建模新手/有一定基础/竞赛冲刺三个水平档位不同档位对应不同的输出深度和术语密度二是输出末尾固定增加一段本题的关键难点与应对策略让学生知道看完分析之后下一步该干嘛。V2 上线后我又根据用户反馈发现了新问题学生在拿到建模思路后卡在把这个思路变成代码这一步。所以 V3 版本增加了代码生成模块并且在这个模块里加入逐步提示机制——不一次性输出所有代码而是先让模型输出整体架构然后引导用户逐步完善各个函数。这个迭代过程说明Skill 开发不是一次性写完就结束了。你必须有机制去收集用户反馈、定位问题、单项改进。V1 到 V2 我调整的是输出深度控制V2 到 V3 我调整的是流程编排。每次改动都是精准的局部修改而不是整体重写这得益于前期做好的任务分解。4.3 建立回归测试集防止该退化迭代过程中最容易遇到的问题是修复一个问题导致另一个原本正常的功能退化。我的解决办法是维护一个回归测试集把每轮迭代中发现的问题及其对应输入保存下来作为永久测试用例。每轮修改之后不光跑新用例还要把历史用例全跑一遍。比如备课 Skill 有一轮修改我调整了教学目标生成模块的话术结果导致缺少学段信息时追问用户的功能失效了——模型直接默认是初中不再追问。幸好回归测试集里有这个用例第一时间发现了问题。实操心得测试用例集建议放在 Skill 项目目录下和代码、提示词版本一起管理。我一般用 Markdown 表格维护每行一个用例包含输入、预期输出、实际输出、是否通过、备注。表格本身还可以作为后续文档素材写 Skill 使用说明时直接贴上去。5. 发布与迭代让 Skill 从能用到好用的关键一跳Skill 开发到测试通过只完成了 70%。剩下的 30% 在于发布后的数据回收和持续迭代。很多人做完 Skill 就丢到平台上了然后就没有然后了。真正的 Skill 开发流程必须以发布后持续观测作为闭环。5.1 发布前要准备的三个文档发布不是点一下发布按钮就完了。我在发布前一定会准备三份文档第一份是Skill 说明文档面向用户。要写清楚这个 Skill 是干什么的、需要用户提供什么输入、输出什么结果、有什么限制。文档的价值不只是帮用户上手更重要的是减少无效交互——用户不看说明就乱输入导致输出质量差然后反过来骂你的 Skill 不好用这种冤案我经历过不止一次。第二份是Prompt 版本记录。Skill 里的每一段 Prompt 都要有版本号和修改记录。我见过太多人改 Prompt 改到一半忘了原始版本是什么出了问题想回滚都做不到。本地的版本记录能让你随时回退到上一个能用的版本。第三份是效果基线。就是测试阶段的一组标准输出样例作为后续迭代的对照组。每次修改 Prompt 后把新输出和基线输出对比这样效果有没有变好不再是一个主观感受而是一个可比较的客观事实。5.2 用户反馈驱动的三类迭代发布后我按三类反馈驱动迭代反馈类型典型信号迭代动作输出质量类生成的教案太泛泛而谈细化对应子模块的 Prompt 规则或增加示例流程体验类每次都要重新输入课程信息太麻烦增加会话记忆或上下文存储功能缺失类能不能顺便帮我生成一份课堂练习题评估是否新增子步骤避免过度膨胀三类反馈的处理优先级不一样。我的排序是流程体验类优先于输出质量类输出质量类优先于功能缺失类。原因是流程体验问题比如每次都要重新输入伤害的是用户使用意愿这个伤害是不可逆的——用户嫌麻烦就不用你的 Skill 了后面你再怎么提升输出质量他都看不见。功能缺失类的需求要特别警惕需求膨胀。我遇到过用户提出一个非常好的新功能需求但在 Skill 里做这个新功能会导致现有流程变得复杂、反而影响主流程的稳定性。这种情况下我会选择不开新功能而是把需求记录下来等下一版 Skill 重新设计时再考虑。5.3 性能与成本优化Skill 稳定的底层保障迭代过程中还有个常被忽略的环节性能与成本。Skill 如果每个子步骤都调用一次大模型一次完整任务可能要发 5-6 次请求耗时几十秒甚至更久而且消耗大量 token。我优化过备课 Skill 的调用链路原来生成教学目标和生成教学过程是两个独立调用后来我把这两个子步骤合并成一次调用因为它们的输入上下文高度重叠同样的课程信息和知识点合并后输出质量没有下降但耗时少了将近一半。合并与否的判断标准是两个子步骤的输入是否高度重叠输出之间是否有强依赖如果都满足合并是安全的。反之如果子步骤 A 的输出会被子步骤 B 当成输入那就不适合合并。另一个优化手段是缓存。对于那些与用户输入无关的固定内容比如 Prompt 头部的背景知识说明、格式模板每次调用都重复发送纯属浪费可以提前做好模板拼接只让需要变化的字段走变量模块。实操心得发布后至少要盯一周的数据。我自己的习惯是前三天每天看全部日志记录哪些输入没触发、哪些触发了但用户取消、哪些输出了报错之后一周改为每周抽看。数据里最能暴露问题的是用户取消交互——说明你的 Skill 在第一个问题或第一个输出处就让用户失望了。不要花时间优化后面的步骤先解决用户第一眼看到的那个问题。5.4 关于去 AI 味和特定场景 Skill 的思考聊到 AI 备课和数学建模这两个垂直场景我发现它们对 Skill 有个共同的进阶要求——去 AI 味。备课 Skill 生成的教案如果一股 AI 味老师一眼就能看出来直接弃用。数学建模 Skill 生成的论文如果 AI 味太重参赛直接会被扣分。所以这两个场景的 Skill 在发布后迭代最频繁的模块往往是改写与风格控制。我在这方面的核心经验是去 AI 味不是让模型说人话而是让模型回到具体。AI 味本质上是因为模型倾向于用抽象的、泛化的语言覆盖所有情况而真人写作的特点是具体的细节、具体的动机、具体的转折。所以我在改写模块里不会写请写得自然一点而是写请把分析了数据改为画了三张图发现在周三骑行量有明显峰值。用具体的指令对抗抽象的生成效果立竿见影。这也解释了为什么少样本示例在去 AI 味需求里特别重要——因为具体这件事本身无法用规则描述只能靠示例让模型领会。如果你的场景也有类似的风格控制需求我的建议是建立你自己的风格示例库持续从真实用户或真实文本里收集好的改写案例不断补充到 Prompt 示例中。这条经验比任何一条提示词技巧都值钱。