Skill 能运行不等于它能交付；真正的验收要覆盖输入缺失、信息冲突、敏感内容、写回失败和换人接手等情况。本文用正常案例、异常案例、人工检查、回滚和交接五个环节建立验收流程，让团队知道什么时候继续、什么时候停止，以及如何留下可复测的证据。文中只讨论可复现的步骤，不把单次结果扩展成产品承诺；每个结论都标注前提、证据和无法覆盖的边界。读者可以先完成最小验证，再按自己的版本、权限和数据补充实验。
但文件齐全，不代表 Skill 已经可以交付。
客户最容易失望的场景是：模型输出了一份看起来很完整的结果，却没人知道它是否能用；第一次运行成功，第二次输入缺一列就完全失控；设计者说“照着用就行”，新员工却不知道失败后该回哪里。
所以 Skill 的验收目标不是“模型回答得像不像”，而是：
一、先画出旧流程，不要只问客户想要什么
很多项目一开始就问：
客户通常会回答一串功能：总结、写邮件、更新表格、发消息、做报表。更有用的问题是：
建议把旧流程完整写下来：
AI Skill 先接管其中一个重复环节，例如“把会议材料整理成待审核跟进表”，而不是一开始就接管从会议到客户发送的全部链路。
二、按 5 步完成一次 Skill 试运行
第 1 步：记录旧流程的每个动作
不要只记录“整理资料”这种抽象词，要具体到：
这些细节往往是老员工多年经验的集合，也是 Skill 最需要被写下来的部分。
第 2 步：删到一个结果
把工作范围压缩成一个可验收的结果：
不要同时做会议预约、纪要、邮件、任务分配和周报。结果越多，失败来源越难定位，客户也无法判断一次试运行到底完成了什么。
第 3 步：固定输入和输出模板
输入越固定，输出越稳定。至少要明确：
输出也不要只返回一段文章。最好把结构化字段、待确认项、冲突项和人工检查栏分开。
第 4 步：用 3 个正常案例和 2 个异常案例测试
测试不能只挑模型容易处理的样例。建议准备：
如果岗位涉及隐私，还要增加敏感内容案例；如果涉及外部系统写入，还要增加写回失败案例。
第 5 步：安排交接和复测
交付时至少留下：
并明确谁拥有更新权限。没有交接的自动化，客户很快会因为一次错误而不敢继续使用。
三、正常案例看稳定性，异常案例看边界
正常案例测试“能不能完成”，异常案例测试“应该在哪里停下来”。
输入缺失
例如会议转写里没有客户名称、负责人和截止时间。错误做法是让模型自行补齐；正确做法是：
信息冲突
如果会议纪要写“周三交付”，项目表写“周五交付”，模型不应该默默选一个。
应该输出：
保留冲突比给出一个漂亮但错误的结论更有价值。
内容敏感
当输入中出现客户身份证号、内部价格、账号密码、合同或未发布产品时，流程应该先阻断：
不要先把原始内容发送给模型，再期待模型自己删除敏感信息。
系统失败
模型超时、格式错误、连接器失效和写回失败要分别处理。
四、人工检查点必须写进输出
“AI 已经生成结果”不等于“结果可以直接使用”。每个输出模板最后建议固定增加人工检查区：
| 检查项 | 谁确认 | 不通过怎么办 |
|---|---|---|
| 事实和数字 | 业务负责人 | 回到输入表补充来源 |
| 负责人和日期 | 项目负责人 | 标记待确认，不自行分配 |
| 对外措辞 | 销售或运营负责人 | 改成草稿，禁止自动发送 |
| 隐私和权限 | 管理员 | 删除敏感字段，重新生成 |
| 格式和归档 | 使用人 | 按版本规则重命名并保存 |
检查项最好直接出现在结果里，而不是藏在另一份培训文档中。这样使用人每次提交时都会看到仍需完成的动作。
可以使用这样的输出尾部：
五、异常处理卡应该怎么写
异常卡不是一份技术错误码手册，而是给使用人的下一步指令。
输入不完整
结果互相矛盾
涉及敏感内容
模型超时或连接失败
结果写回失败
六、版本、日志和失败样本要留下
Skill 会随着业务规则变化而更新。至少保存以下信息：
失败样本不要只在群聊里讨论。可以建立一个失败案例表：
| 字段 | 作用 |
|---|---|
| case_id | 方便定位和复测 |
| 输入摘要 | 描述触发条件，不默认保存敏感原文 |
| 预期结果 | 这次任务本来应当怎样处理 |
| 实际结果 | 模型和流程实际返回什么 |
| 根因 | 输入、规则、模型、权限还是人工遗漏 |
| 修复动作 | 改 Prompt、模板、权限还是流程 |
| 回归状态 | 新版本是否再次通过 |
这样每次规则修改都有依据，也能避免“修了一个案例，破坏另一个案例”。
七、上游 API 如何辅助测试和生产治理
岗位 Skill 的测试案例关注业务质量，上游 API 关注模型调用链路。两者应该在同一次试运行中一起观察。
建议对每次模型调用记录：
这些字段可以帮助定位：
上游 API 适合在企业多模型场景中提供：
- 统一模型入口和供应商切换。
- 按团队、项目和环境管理 Key。
- 记录调用日志、耗时、状态和成本。
- 给长文本、图片和高价模型设置限额。
- 对可安全重试的请求设置有限重试。
- 对连续 5xx、超时和预算异常发出告警。
但要注意，模型网关的日志不等于业务验收。上游 API 可以告诉你请求有没有成功、用了哪个模型、花了多少钱；业务负责人仍然要确认结果是否符合岗位规则，业务后端仍然要控制数据权限和写入副作用。
八、交接时做一次“盲操作”
交接不要采用“我给你讲一遍，你应该会了”的方式。更可靠的是让接手人盲操作：
交接合格的标志不是他能复述功能，而是他能回答：
建议录制一段 10 分钟左右的视频，但视频不能替代文字文档。视频适合展示操作路径，文字适合查字段、查异常和查版本。
九、交付边界：哪些动作必须留下人工确认
下列操作不建议由第一版 Skill 自动完成：
- 修改价格、预算、合同和对外政策。
- 向客户、供应商或公众发送内容。
- 删除原始材料、覆盖生产文件或关闭任务。
- 变更成员权限、API Key 和数据访问范围。
- 在没有来源时补全事实、数字、日期和责任人。
- 把内部内容复制到未授权模型或外部系统。
如果确实要自动执行，至少要有明确授权、可回滚机制、幂等设计、审计记录和异常告警。否则，第一版先输出草稿，把最终动作交给人。
十、上线前验收清单
流程测试
- 已画出旧流程和人工判断点。
- Skill 只完成一个明确结果。
- 3 个正常案例都能产出可检查结果。
- 2 个异常案例能在正确位置停止。
- 输入、输出和保存位置都有固定规则。
人工检查
- 事实、数字和来源有业务负责人确认。
- 负责人、日期和优先级不会由模型擅自补全。
- 对外内容明确标为草稿。
- 隐私、权限和敏感字段有管理员检查。
- 格式、命名和归档由使用人确认。
系统治理
- 每次任务有 task_id，模型请求有 request_id。
- 已区分可重试请求和有副作用请求。
- 上游 API 或企业 API 网关记录模型、路由、耗时、状态和成本。
- 失败、超时、预算异常和备用路由有处理规则。
- Skill 版本、审批人和回滚版本可追踪。
交接
- 新员工可以只看文档完成一次正常案例。
- 新员工可以根据异常卡处理一次失败案例。
- 已有操作视频、检查表和反馈入口。
- 已明确规则更新人和权限所有者。
- 已约定复测周期和失败样本归档方式。
总结
AI Skill 交付的关键，不是把模型调用包装得多复杂，而是让失败可以被发现、责任可以被定位、结果可以被回滚、流程可以被接手。
把 3 个正常案例和 2 个异常案例跑完，把人工检查点写进输出，把版本、日志、失败样本和权限交接留下，再谈规模化推广。上游 API 可以为多模型调用提供统一入口、路由、Key、审计和成本治理，但业务质量和最终责任仍然属于岗位流程和人工审核。
结论
本文给出了问题定位、配置或创作流程的可执行路径。实际结果仍取决于当前版本、权限和运行环境，提交前应按官方文档复核可变字段，并保留失败证据和回滚边界。
