AI Skill服务报价指南：按交付边界定价与维护完整框架

AI Skill 服务的价格不应靠模型名称或“自动化程度”包装出来，而应由岗位动作、输入复杂度、测试范围、系统写回、权限和后续维护共同决定。本文把一次交付拆成可验收的基础包、可选工作和明确排除项，帮助双方在报价前确认责任、变更和复测边界。文中只讨论可复现的步骤，不把单次结果扩展成产品承诺；每个结论都标注前提、证据和无法覆盖的边界。读者可以先完成最小验证，再按自己的版本、权限和数据补充实验。

这套东西其实已经不是“顺手帮客户写一条 Prompt”了，而是一项可以收费的交付服务。

客户付费的理由也不应该是：

~~~text
我会调模型。
我能写很长的提示词。
我可以给你搭一个自动化链接。
~~~

更准确的价值是：

~~~text
我把你们一个重复岗位动作整理成一套可交接、可测试、可检查、可维护的 AI Skill，新员工也能照着跑，出错知道怎么停，规则变化知道谁来改。
~~~

一、第一单卖“试运行”，不要一开始承诺大系统

首次交付适合从一个边界清楚的岗位 Skill 试运行开始，费用应根据范围、测试和系统连接逐项核算，而不是用固定数字承诺结果。

基础试运行可以包含：

• 1 份岗位 Brief。
• 1 个输入表单。
• 1 条 Prompt 或工作流配置。
• 1 个输出模板。
• 1 张人工检查表。
• 1 张异常处理卡。
• 3 个正常案例和 2 个异常案例。
• 1 次交接和使用说明。

这不是“按写了多少字收费”，而是按一次可验收的岗位动作收费。客户买到的是从需求澄清到可交接运行的完整闭环。

二、按交付范围划分服务层级

可以把试运行分成三个层级，让客户容易理解价格差异。

这只是试运行的参考区间，实际价格需要根据资料复杂度、系统连接、模型调用次数、权限要求和交付周期调整。

不要为了显得便宜，把无限次修改、无限增加功能和无限期维护都包含进去。低价试运行的目标是验证一个动作能否稳定运行，不是免费承包客户全部 AI 需求。

三、报价前先确认 6 个变量

同样叫“做一个 Skill”，工作量可能完全不同。报价前至少确认：

1. 输入材料有多复杂

纯文本、固定表格和结构化表单比较容易处理；混合 PDF、录音转写、图片、邮件和多个系统资料时，清洗和检索成本会增加。

2. 输出是否需要写回系统

只生成 Markdown 或表格草稿，和写入 CRM、项目管理系统、企业知识库不是一个交付级别。后者需要考虑字段映射、权限、幂等和失败回滚。

3. 是否包含敏感数据

客户资料、合同、财务、人事和内部价格会增加脱敏、权限、日志和审核要求。未经授权的数据不能直接交给外部模型测试。

4. 是否需要多个模型

纯文本整理可能只需要一个文本模型；带知识库检索、图片生成、视觉检查或 Embedding 时，调用链会变长，测试和成本也会增加。

5. 谁负责业务规则

如果客户无法提供成功样例、常见错误和审核人，设计者就无法独立判断“什么结果算合格”。这不是靠加长 Prompt 就能解决的问题，需要客户投入业务负责人。

6. 谁拥有后续更新权限

规则不会永远不变。报价前要确认谁能修改 Prompt、模板、权限、路由和异常卡，谁负责批准新版本。

四、报价单应该写清楚包含和不包含

基础交付包含

~~~text
一个明确的岗位动作
一次岗位 Brief 访谈
一个输入表单
一个 Prompt 或工作流
一个输出模板
一张人工检查表
一张异常处理卡
五个测试案例
一次交接
一次试运行复盘
~~~

明确排除

~~~text
替客户制定公司政策
处理未经授权的敏感数据
无限增加新的岗位流程
无限次修改原需求
保证模型每次零错误
保证完全无人值守
替客户承担最终业务决策
~~~

这些排除项不是为了推卸责任，而是为了把业务责任和技术交付分开。客户负责提供事实、规则、样例和审批人；交付方负责把确认过的规则做成可运行、可检查和可交接的流程。

五、维护费到底卖什么

Skill 上线后，维护费不能只写“有问题找我”。客户愿意续费，是因为你持续帮他处理规则变化和失败样本。

可以按月或按季度提供：

• 规则和输出模板更新。
• 新增失败样本和回归测试。
• 模型切换后的质量复测。
• 新员工上手和交接支持。
• 权限、保存位置和归档规则调整。
• 上游 API 路由、Key、预算和成本报表检查。
• 运行日志、超时、失败和重试分析。
• 季度版本复盘和下一阶段优化建议。

维护工作的核心不是“帮客户多写几条 Prompt”，而是保持岗位动作与业务规则同步。

六、企业级升级点：上游 API 怎么进入报价

个人使用的 Skill 可以直接使用一个模型。客户有多个团队、多个项目和多种模型后，企业会遇到：

~~~text
每个 Skill 都在保存自己的 API Key。
不同团队调用了不同模型，成本无法比较。
模型切换需要修改多套业务代码。
长任务超时后没人知道是否重复执行。
图片、文本和检索调用没有统一预算。
出了问题无法按请求追踪到具体任务。
~~~

这时可以把 上游 API 作为企业模型治理的升级选项，而不是把它写成每一个个人 Skill 的强制依赖：

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

上游 API 可以承接的企业能力包括：

• 统一多模型入口，减少供应商地址散落。
• API Key 按团队、项目和环境分组。
• 根据任务类型做模型路由。
• 记录 request_id、模型、耗时、状态和成本。
• 对高价模型、图片生成和长任务设置预算。
• 对可安全重试的请求做有限重试。
• 通过日志分析失败率、重试率和单任务成本。

比如给客户设计“内容生产 Skill”时，可以把成本分成：

~~~text
资料检索成本
摘要和提纲成本
正文生成成本
图片生成成本
视觉审核成本
重试成本
单篇内容总成本
~~~

这样客户看到的是一套能被管理的企业 API 基础设施，而不是一个永远靠人工维护的黑盒自动化。

边界也必须明确：上游 API 管理模型调用，不替企业处理员工身份、知识库资料权限、客户审批和发布责任；这些仍由业务后端、连接器和人工审核负责。

七、把交付边界写进沟通记录

首次沟通应记录岗位动作、输入材料、输出字段、人工检查点、系统写回和不包含的内容。不要用‘全自动’或‘零错误’描述结果，改用可验收的测试案例和明确的停止条件。

八、用小规模试运行收集证据

先在脱敏或测试数据上运行，保留正常、缺失、冲突和写回失败案例。试运行的目标是验证一个动作是否可重复、谁负责检查以及失败如何回滚；证据不足时，不扩展到更多岗位或更高权限。

九、如何判断一个客户是否适合成交

适合试运行的客户

• 每周反复处理同一类材料。
• 有至少两个成功样例。
• 愿意指定业务负责人和审核人。
• 可以提供脱敏或已授权的测试数据。
• 接受先做一个动作，不要求一开始覆盖全公司。

暂时不适合的客户

• 只说“做一个万能助手”，无法选定动作。
• 不愿提供样例，却要求保证结果符合内部习惯。
• 希望 AI 自动决定价格、合同、招聘和对外承诺。
• 要求把敏感数据直接放进未经授权的模型。
• 期待一次交付后无限新增流程和长期免费维护。

这类客户不是永远不能合作，而是需要先完成范围澄清、数据授权和责任分工。

十、商业化边界和风险控制

不要承诺零错误

模型输出会受到输入质量、模型版本、上下文长度和上游服务状态影响。更稳妥的承诺是：

~~~text
提供明确输入、输出、检查和异常流程。
用约定案例完成回放测试。
保留人工确认和回滚方式。
按版本记录规则更新。
~~~

不要承诺完全无人值守

会议纪要整理、资料分类和草稿生成可以高度自动化；价格、合同、客户承诺、权限修改、数据删除和对外发布仍应根据风险保留审批。

不要替客户决定公司政策

客户没有确认的业务规则，应该标为待确认。你可以帮助客户把规则写清楚，但不应把模型生成的推测包装成公司政策。

不要忽略模型和数据成本

长资料、图片、视觉审核、Embedding 和重复重试都会增加成本。企业接入时，通过 上游 API 统计路由、Key、请求、Token、耗时和预算，才能把维护服务从“出问题再排查”升级成主动治理。

十一、第一单交付验收清单

商业范围

• [ ] 合同或报价单只包含一个明确岗位动作。
• [ ] 写明输入、输出、测试案例和交接内容。
• [ ] 写明修改次数、周期和新增需求的计费方式。
• [ ] 明确不包含政策制定、敏感数据和无人值守承诺。

技能包

• [ ] 岗位 Brief 已确认。
• [ ] 输入表、Prompt、输出模板、检查表和异常卡已交付。
• [ ] 3 个正常案例和 2 个异常案例完成回放。
• [ ] 新员工可以只看文档完成一次任务。
• [ ] 规则拥有者、审核人和回滚版本已明确。

企业治理

• [ ] 生产 Key 没有出现在文档、代码和聊天记录中。
• [ ] 上游 API 或其他企业 API 网关记录模型、路由、耗时、状态和成本。
• [ ] 长任务、图片生成和高价模型有预算边界。
• [ ] 敏感数据、外部模型、知识库和写回权限已确认。
• [ ] 对外发送、价格、合同、删除和权限变更保留人工审批。

总结

AI Skill 可以成为一项服务，但收费的不是“我会调用一个模型”，而是“我能把一个岗位动作交付成可运行、可验收、可交接和可维护的技能包”。

试运行应从一个动作、若干正常与异常案例和一次交接开始；后续维护围绕规则更新、失败样本、版本复测、新员工交接和模型治理展开。

当客户需要多个模型、多个团队和统一成本管理时，可以进一步接入 上游 API，集中处理模型入口、路由、Key、日志、预算和调用成本。但岗位责任、业务审批和数据权限仍要由客户自己确认和管理。

真正能留下来的第一单，不是功能最多的项目，而是下一个人接手时仍然知道什么时候用、输入放哪、结果怎么查、出错怎么办。

结论

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