AI Skill交付升级：从Prompt到可交接岗位技能包完整指南

客户接手 AI 工作流时，真正需要的不是一条很长的 Prompt，而是一套新员工能够按步骤运行、检查和交接的岗位技能包。本文把 Skill 拆成触发条件、输入、输出、人工检查、异常回滚、权限和版本，说明如何从一次演示升级为可验收的交付物。文中只讨论可复现的步骤，不把单次结果扩展成产品承诺；每个结论都标注前提、证据和无法覆盖的边界。读者可以先完成最小验证，再按自己的版本、权限和数据补充实验。

很多人把 AI 工作流交付给客户时，交的是一份代码、几个提示词，或者一个可以点击的自动化链接。

客户当天确实能跑起来。到了第二周，换一个同事接手，问题就开始出现：

什么时候应该打开这个 Skill？
输入材料放在哪里？
上传什么格式才算完整？
结果错了应该改哪里？
哪些内容必须由人确认？
谁可以修改规则和查看数据？

这说明客户买到的只是一次演示，不是一套可以持续使用的岗位能力。

真正值得收费的 AI Skill，应该交付成一套“新员工打开后能照着完成工作”的岗位技能包。它不只包含模型调用，还包含触发条件、输入材料、输出格式、检查规则、异常处理、权限边界和交接方式。

一、客户买的不是 Skill 代码

代码解决的是“系统能不能运行”，Prompt 解决的是“模型大致应该怎么做”。但岗位交付还要解决另外几件事：

如果这些问题没有答案，客户就会把每一次使用都变成一次“重新问老员工”的过程。模型再聪明，也无法替团队补齐没有写下来的岗位约定。

因此，Skill 的交付单位应该从“一个文件”升级为：

岗位动作
  -> 输入规则
  -> AI 处理流程
  -> 输出模板
  -> 人工检查
  -> 异常回滚
  -> 权限和版本
  -> 新员工交接

二、第一单不要卖万能 AI 助手

“帮企业做一个万能 AI 助手”听起来很大，实际上很难验收。

第一单更适合只处理一个重复岗位动作，例如：

• 销售把客户会议记录整理成跟进表。
• 运营把商品资料整理成上架 Brief。
• 客服把常见咨询分成待回复队列。
• 人事把面试记录整理成候选人评估草稿。
• 内容团队把产品更新整理成待审核文章大纲。

这些动作有几个共同特征：发生频率高，输入大致固定，输出可以检查，而且即使 AI 做完，也仍然需要业务人员确认。

你卖的不是“AI 替代一个岗位”，而是把岗位里最重复、最容易返工的一段工作提取出来，让人从空白页面和机械复制中解放出来。

三、用 5 个问题筛选岗位动作

在写任何 Skill 之前，先对候选动作做筛选。下面 5 个问题至少有 3 个能明确回答，才值得进入试运行：

1. 每周至少发生 3 次吗

如果一个动作一个月只发生一次，节省的时间可能不够覆盖设计、测试和培训成本。

适合第一单的动作通常是：

每天整理会议纪要
每周处理一批商品资料
每天给客户问题分类
每周生成一次运营简报

频率越高，越容易积累失败样本，也越容易看出 Skill 是否真的减少了返工。

2. 输入是否有固定形式

输入不需要完全一致，但至少应当有可以描述的边界。

例如：

会议录音转写、参会人和客户名称
商品名称、规格、卖点和价格
客服原话、客户标签和历史订单号
产品更新说明、发布日期和已确认限制

如果每次输入都完全不同，模型很难稳定处理，交付时也无法写清楚用户该提交什么。

3. 输出能否被检查

好的岗位动作应该有明确的输出字段和检查方法。

例如跟进表可以检查：

客户名称是否正确
每项行动是否有负责人
截止日期是否来自原始资料
风险和待确认项是否单独列出

如果只能凭“读起来很顺”判断质量，验收会变得主观，客户也不容易建立信任。

4. 出错后能否回滚

AI 第一次输出有错误并不可怕，可怕的是错误已经直接写入生产系统、发给客户或覆盖了原文件。

适合自动化的动作，应该允许：

保留原始输入
生成草稿而不是直接发布
保留旧版本
撤回错误写入
重新提交修正后的材料

如果出错后没有办法回滚，第一单不要做全自动写入。

5. 最后是否仍需人判断

岗位 Skill 最适合处理“AI 整理，人做判断”的工作。

例如 AI 可以整理客户会议中的行动项，但不能自动承诺价格、修改合同、向客户发送未经审核的消息。人工判断不是自动化失败，而是岗位责任的一部分。

四、Skill 交付应该长什么样

一个可交付的岗位技能包，至少要能回答下面这张表：

这 6 个部分可以放在飞书文档、Notion、企业知识库、项目目录或客户已有的文档平台里。工具不是重点，重点是任何一位新同事都能理解这条接力链：

使用人提交输入
  -> Skill 整理和生成草稿
  -> 使用人检查格式和完整性
  -> 业务负责人确认事实和决策
  -> 审核人确认对外内容
  -> 按版本规则归档或发布

五、一个岗位 Skill 的最小示例

以“会议记录生成销售跟进表”为例，它的范围可以写成这样：

触发条件

会议结束后，销售已经拿到转写文本，并准备整理客户需求、行动项和下一次沟通安排。

输入材料

客户名称：
会议日期：
参会人：
会议转写或会议纪要：
已知客户阶段：

目标输出

客户概况
已确认需求
客户提出的问题
我方承诺事项
客户承诺事项
负责人和截止时间
待确认信息
下一次沟通建议

不自动处理的内容

不得自行承诺价格和折扣。
不得把推测写成客户已经确认的需求。
不得自动向客户发送消息。
不得删除或覆盖原始会议材料。

验收标准

每条行动项都有来源或明确标记为待确认。
没有负责人和日期时，输出“待确认”，不自行补全。
客户原话和 AI 总结分开呈现。
输出先保存为草稿，经过销售确认后才进入 CRM。

这已经比一句“把会议纪要整理成跟进表”更接近岗位能力。后续无论换模型、换员工，交付边界都不会完全依赖某个人的记忆。

六、上游 API 放在企业模型调用治理的位置

个人使用时，一个岗位 Skill 可以直接调用当前工具里的模型。企业把多个 Skill 推广给多个团队后，模型调用就需要统一管理。

典型链路是：

岗位 Skill / 企业 Agent / SaaS
  -> 企业业务后端
  -> 上游 API 统一模型入口
  -> 文本、检索、视觉或图片模型
  -> 结果校验和人工审批
  -> 业务系统归档

上游 API 可以承接企业多模型接入中的通用治理工作：

• 统一 API 入口，避免每个 Skill 各自保存供应商地址。
• 按团队、项目和环境分组管理 API Key。
• 根据任务类型配置模型路由。
• 记录请求、耗时、错误、重试和成本。
• 对高价模型、图片模型和长任务设置预算。
• 在上游失败时配置有限重试或备用路由。

但边界要说清楚：上游 API 负责模型调用治理，不替客户定义销售政策、审批流程和岗位责任；Skill 负责岗位工作流，也不应该把 API Key 写进 Prompt、Markdown 或前端代码。

七、这类交付为什么比“能跑”更值钱

客户愿意持续付费，通常不是因为第一次演示时模型说了几句漂亮话，而是因为实际工作中出现了这些变化：

新员工不需要反复询问老员工。
同一类材料的输出格式变得一致。
错误被发现得更早，返工范围更小。
业务负责人知道自己需要确认什么。
规则更新后，团队不会继续使用旧版本。
模型调用、权限和成本可以追踪。

这也是岗位技能包和“自动化链接”的区别。自动化链接通常只证明流程可以执行；岗位技能包还要证明团队能够正确使用、检查、接手和维护。

八、边界：哪些事情不要写进第一版

第一版越想做得全面，越容易变成无法验收的项目。下面这些内容建议排除：

• 不要同时覆盖多个岗位和多个结果。
• 不要把公司政策交给模型自行制定。
• 不要把未经授权的客户隐私直接送入外部模型。
• 不要默认允许 AI 修改生产数据、发送消息或发布内容。
• 不要承诺完全无人值守。
• 不要把“模型偶尔答得好”当作稳定质量证明。
• 不要把无限新增需求包含在一次试运行报价里。

任何涉及对外承诺、合同、价格、财务、权限变更和数据删除的动作，都应该保留人工审批或明确的业务授权。

九、第一版交付验收清单

岗位范围

• 只选定一个岗位动作。
• 触发条件可以由使用人判断。
• 输入材料和输出结果都有清晰边界。
• 至少有一个可回滚的失败处理方式。
• 明确最后需要谁做人工判断。

技能包文件

• 有操作说明。
• 有输入表单和填写示例。
• 有 Prompt 或工作流配置。
• 有输出模板和命名规则。
• 有人工检查表。
• 有异常处理卡。

企业模型治理

• 模型调用没有把 Key 写入公开文件。
• 生产和测试调用已经分组。
• 高价模型、图片模型和重试有预算边界。
• 上游 API 或其他企业 API 网关可以记录调用和成本。
• 业务权限、数据权限和模型权限没有混为一谈。

总结

AI Skill 的交付标准，不是“客户能不能在演示现场跑出一次结果”，而是“一个没有参与设计的新员工，能不能按文档稳定完成一次工作”。

当你把岗位动作、输入、输出、检查、异常、权限和交接都写进交付，Skill 才从一条 Prompt 变成了岗位技能包，也才有资格收实施费和后续维护费。

结论

本文给出了问题定位、配置或创作流程的可执行路径。实际结果仍取决于当前版本、权限和运行环境，提交前应按官方文档复核可变字段，并保留失败证据和回滚边界。