AI 自动化项目的定价，不能围绕“用了什么模型”展开，而应围绕业务结果、交付边界和后续责任展开。客户购买的不是一个会生成内容的系统，而是一段能够稳定运行、可被验收并且出错时有人处理的流程。模型能力只是实现手段，不能直接决定项目价值。

先拆分一次性交付与持续服务

较稳妥的报价结构，通常应至少拆成三部分：实施费、维护费和新增需求费用。

实施费覆盖流程诊断、数据样本分析、方案设计、开发配置、测试、试运行和交付。若需求尚未验证，不宜直接报价完整系统，可以先销售流程诊断或可行性验证。这样既能确认数据是否可用，也能避免在需求模糊时承担无边界开发成本。

维护费则对应上线后的持续工作，包括任务失败排查、账号或权限异常、外部接口变化、提示词和规则调整、知识内容更新，以及必要的运行检查。维护费不是“售后赠送”，而是客户持续获得服务的费用。只要系统依赖外部平台、客户业务规则或持续变化的数据，就不应承诺一次性交付后永久稳定。

新增需求必须单独计费。新增流程、改变输出结构、接入新的数据来源、增加例外规则，都可能改变测试范围和责任边界。合同中应明确原项目包含什么、不包含什么，以及什么情况会触发重新评估，避免“固定价格、无限修改”。

价格应由风险和复杂度共同决定

评估报价时，至少要看四个维度：流程复杂度、数据质量、验收难度和失败后果。

输入稳定、步骤固定、输出容易检查，且错误主要造成返工的项目，适合采用相对明确的固定实施费。若数据格式经常变化、人工复核节点较多，或者客户尚不能提供完整样本，则应先按阶段收费，不宜承诺最终效果。

如果系统涉及敏感数据、复杂权限、关键业务运行，或输出会影响重要决策，价格中必须体现测试、审查、监控和应急处理成本。此类项目不能只按开发工时计算，更不能用演示效果替代生产环境验收。

维护合同要写清责任边界

维护范围至少应明确：哪些故障由服务方处理，哪些内容由客户提供；维护响应时间如何约定；谁负责审核自动化结果；系统异常时如何暂停任务；数据、账号和访问权限在合作结束后如何处理。

最容易被低估的是例外情况。客户不断增加新规则，通常不是“小改动”，而是在扩大业务范围。只有把维护、优化和新增开发分开收费，自动化项目才不会从一次交付变成无期限的隐性值守。

真正可持续的报价，不是把价格压到客户容易接受，而是让客户清楚知道：一次付费买到什么，持续付费获得什么，以及哪些变化需要重新定价。