AI 项目报价：诊断、原型、交付、维护怎么拆

先说结论。

AI 项目不适合只按页面和功能一次报死。模型效果、数据质量、接口权限和业务标准通常要在项目中逐步确认。更稳妥的结构是诊断、原型、生产交付、维护四阶段，每阶段有独立输入、产出、验收和退出条件。

本文给报价结构，不提供脱离地区、责任和复杂度的价格数字。

适合谁与不适合谁

这套报价页适合已有业务负责人、能安排需求访谈、愿意按阶段验收的团队；不适合要求先报一个永久不变总价、又无法提供数据与接口条件的项目。典型节奏是3天至5天诊断、2周至3周原型、4周至8周生产交付，维护则按月或按约定事项进行。

每个阶段的客户任务也要写入报价：诊断阶段安排访谈并提供流程材料，原型阶段准备去敏样本并参与标注，生产阶段开放测试环境并完成角色验收，维护阶段指定运营责任人。客户任务未完成时，周期应按暂停条款处理。

报价前先分清已知工作和未知风险

页面数量、确定接口和固定规则可以估算；文档是否可用、模型能否达到业务标准、第三方系统是否开放、审核规则是否统一，属于待验证假设。

把未知假设直接写进固定总价，开发方会承担无限返工，客户也看不到风险来自哪里。报价单应把“已确认”“客户需提供”“试点验证”“不包含”分开。

判断能否固定价的标准是：输入、输出、边界和验收是否能在开发前写清。

用六类成本组成报价，而不是先猜总价

完整计算框架可以写成：基础工作量 + 集成复杂度 + 数据治理 + 风险责任 + 维护窗口 + 第三方费用。前五项形成服务方工作包，第三方费用单列实报或设置额度，不混进一个无法解释的总数。

基础工作量来自访谈、设计、开发、测试、文档和项目管理所需的角色与工时。集成复杂度按接口数量、认证方式、环境差异、写操作和外部依赖拆分。数据治理包含收集、去敏、清洗、标注、版本和授权。风险责任覆盖高风险动作审批、安全评审、回滚、审计和额外测试。维护窗口明确服务时段、包含事项、响应级别、版本升级和退出交接。

每一项先估工作量区间，再乘以双方约定的角色单价，或换算成固定工作包。固定价适合范围与依赖已经明确的工作包；按时计费适合探索、故障定位和需求持续变化的阶段；月度维护适合有明确服务窗口与事项上限的运行期。三种方式可以分阶段组合，不能用一种方式覆盖整个项目。

风险缓冲不应是没有解释的统一百分比。报价必须指出缓冲对应哪个不确定项、何时启用、未发生时如何处理。无法说明缓冲保护什么，说明范围还没有拆清，应先进入诊断或设置变更触发器。

一次不含金额的合成报价推演

下面是方法演示，不是真实客户报价，也不代表本站已有交付业绩。假设一个内部知识问答项目已有文档库和登录系统，希望先做受限试点，但文档权限标签不完整，也没有评估集。

诊断阶段按固定工作包报价，包含两类角色访谈、一条现流程、文档抽样、权限缺口和试点 brief，不包含全量清洗。原型阶段拆成“检索与引用主路径”“小规模评估集”“只读身份映射”三个工作包；身份接口在诊断后仍不确定，就先按时计费做技术验证，并设置停止点。生产阶段只有在权限映射和评估口径通过后才报价，另计部署、监控、回滚、安全评审和运行手册。

维护阶段按月购买约定窗口，包含依赖升级检查、失败样本复盘和有限次数的小改动；新增数据源与权限体系重构重新立项。模型调用、向量服务和云资源由客户账户承担，预算上限与停用条件单列。

这份推演没有填金额，但已经能计算：每个阶段有哪些角色、工作包和依赖，哪部分可固定价，哪部分按时计费，风险在哪里停止，第三方费用由谁承担。真实报价只需填入团队自己的工时估算、角色费率和供应商账单，不需要编造行业均价。

诊断阶段卖的是问题边界

诊断输入包括访谈对象、原流程材料、系统清单和去敏样本。产出包括原流程图、问题清单、候选方案、风险、优先级和下一阶段范围。

验收不是“客户满意”，而是关键角色确认流程与边界，明确哪些假设已验证、哪些仍未知。

不包含完整原型、生产代码和长期数据治理。若客户无法提供材料，诊断可以得出“不建议进入开发”的结论。

原型阶段卖的是关键假设验证

原型只验证一到两个最重要问题，例如文档检索是否能支持常见问答，或线索摘要是否可被销售快速审核。

产出包括可运行原型、样本集、评估记录、失败分类、已知限制和继续建议。默认旁路运行，不接高风险自动执行。

验收应基于约定样本和规则，不以演示现场临时问题决定。原型代码是否进入生产也要提前说明，避免把验证脚本误当正式系统。

生产交付报价要补齐看不见的模块

从原型到生产通常要增加账号权限、日志、错误处理、重试幂等、人工审批、监控告警、成本限制、数据备份、部署、测试和运行文档。

报价应按工作包列出，而不是一句“系统上线”。每个工作包写责任方、依赖、验收环境和不包含事项。客户接口延期、数据变化和第三方限制如何处理，也要进入变更条款。

生产阶段的价值是可运营和可恢复，不只是把原型放到服务器。

维护阶段要区分四类工作

缺陷修复是已约定功能不符合验收；需求变更是业务新增或规则改变；第三方变化是模型、API 或平台调整；运营支持是知识更新、样本复盘和权限维护。

四类工作的响应和计费方式可以不同。维护报价至少写服务窗口、响应级别、包含工时或事项、超出范围方式、监控责任和退出交接。

不要写“永久维护”，也不要把所有第三方变化承诺为免费缺陷修复。

第三方费用应该单列

模型调用、云资源、数据库、邮件短信、自动化平台和监控服务可能持续产生费用。账号最好由客户持有，预算和额度由客户批准，开发方负责配置和说明。

若由服务方代付，要写计量口径、结算周期、额度上限和停用条件。价格与条款变化快，应引用供应方当前账单，不在合同中写无法维护的永久单价。

数据跨境、隐私和合规评审也不应被隐藏在“接口费”中。

变更机制比预留百分比更重要

需求变化不可避免，关键是如何确认。变更单应写提出原因、影响模块、增加或减少的交付、工期影响、费用和批准人。

小改动也需要进入列表，定期合并确认。口头说“顺手加一下”最容易积累成范围失控。

若变更触及核心假设，例如从内部草稿改成自动对外发送，应重新做风险与验收评估，而不是只增加一个按钮费用。

常见报价失败有五种

付款节点也应该对应可验收材料，而不是笼统绑定“进度”。诊断阶段可对应访谈与边界确认，原型阶段对应样本运行和评估报告，生产阶段对应测试环境、上线准备与交接。客户延迟提供关键输入时，双方要有暂停和重排机制。

报价单还应写明知识产权与可复用组件边界：客户业务数据、定制配置和项目文档如何归属；服务方已有通用模块是否继续保留；开源依赖按什么许可使用。没有这些说明，交付后容易在源码、模板和再次使用上产生争议。

按模型调用次数估开发费，忽略系统工程；按页面数报价，忽略数据和权限；原型与生产不分，客户默认都可上线；第三方费用不写，后期争议；验收只写“功能完成”，没有效果、稳定性和风险口径。

反例是需求非常明确的标准集成，可以按固定工作包报价。但即使如此，接口权限、测试环境和客户配合仍要写入前提。

一份报价表至少有这些栏目

1. 项目目标与当前流程。
2. 本阶段范围和明确不包含事项。
3. 客户需提供的人员、数据、账号和环境。
4. 交付物、验收方式和验收人。
5. 依赖、风险与暂停条件。
6. 第三方费用和数据责任。
7. 需求变更机制。
8. 付款节点、维护和退出交接。

最终应交付什么

报价阶段的交付不是一个总金额，而是 4 张阶段卡、第三方费用表、客户配合清单、变更单模板和退出交接条款。每张卡都应写明输入、范围、明确不包含、产出、验收人、周期与付款节点。

FAQ

为什么不直接报完整项目总价？ 可以给预算区间，但在数据、效果与接口未验证前锁死总价，会把未知风险藏进争议。先完成诊断，后续报价会更有依据。

诊断后不继续开发，材料能否带走？ 应能带走合同约定的流程图、范围、风险和下一阶段建议。通用方法、既有组件与客户定制材料的权属要在报价中分别写清。

第三方模型涨价算需求变更吗？ 通常不是开发缺陷。报价应约定供应方价格变化、替换评估和客户预算批准机制。

维护费包含新功能吗？ 默认不包含。缺陷、需求变更、第三方变化与运营支持要分开定义。

服务方可信度怎么核验

不要只看成功截图。要求服务方提供脱敏后的范围文档、评估口径、失败分类和交接样例，并说明哪些组件复用、哪些专门开发。无法用材料证明的能力，不应写进固定承诺。

下一步先把当前项目拆成四张独立报价卡。若诊断阶段还无法确定原型范围，就只报价诊断。报价的专业性不在于数字多精确，而在于双方知道这笔钱买到什么，也知道哪些风险尚未被买断。