AI 项目的钱，花在哪最容易超支？
📖 摘要：AI 项目超支几乎是常态，但原因通常不是有人贪心——而是有四个环节的工作量在开工前根本估不准。本文用真实交付数据拆开这四个高发区：语料工程（最容易被低估）、系统集成（等的是人不是技术）、需求变更（看到实物后想法变了）、上线后维护（常不在原始报价里），讲清它们为什么都属「做不到一半看不出来」的类型，以及三个能在报价阶段就防住超支的动作。适合：正在评估 AI 项目预算的企业决策者、被「报价外还要加钱」困扰过的项目负责人。
先给一个不绕弯的判断：AI 项目超支，多数不是执行方贪心，是有一块工作量在开工前看不见。
传统软件项目能按功能点报价——几个模块、多少页面、多少接口，大致能估。AI 项目不行：它的工作量藏在你的数据里和你的协作流程里，而这两样在报出价格的那一刻，通常谁都没看全。
下面这四块，是我在真实交付里见过最容易超的地方。它们的共同点是——都是"做到一半才发现"的类型。
一、语料工程：最容易被低估的一块
这一块排在第一位，因为它超起来最猛。
很多人以为"把文档喂给 AI"是一个技术动作：上传、解析、入库，跑个脚本的事。实际不是。
我们用 4277 页设备手册建知识库的实际情况：
| 环节 | 开工前的预期 | 实际发生 |
|---|---|---|
| 格式转换 | 转成文本 | 双栏排版需拆分（不拆会文字串行）、扫描件缺文字层需额外处理 |
| 图文保留 | 顺带处理 | 需要处理图文对应关系，否则答案引不到图 |
| 质量核验 | 大致看看 | 必须做到内容层核对——我们踩过一个坑：流程图提取只覆盖了一个文本区域，输出是"四分之一高度"的图，不逐项核查看不出来 |
为什么它一定会超？ 因为语料的全貌只有清洗到一定深度才看得见。开工前看几十页样本，只能判断"大概要花多少工夫"，判断不了"里面藏着多少种要单独处理的情况"。
这一类超支的防法：开工前拿样本跑一遍真实流程（不是看，是跑），把发现的问题写成一份《语料处理说明》——之后的工作量按它算，而不是按"文档页数"算。
二、系统集成：超的不是技术，是等
第二块容易超的地方是接内部系统——但注意，超支的量通常不来自开发难度，来自等待。
真实形态是这样的：要接一个内部工单系统，技术方案两天就定好了，接口联调实际花了两小时——但从"要接"到"能接"，中间隔了三周：等技术对接人排期、等权限审批、等对方确认测试环境。
为什么它一定会超？ 因为排期不由你控制。你的项目计划里，这一环的工期取决于别人什么时候有空。
这一类超支的防法：报价前先确认一件事——对接人和权限审批的路径是否已经明确。如果连"该找谁"都还不知道，这一块的时间就不能按开发量估。
三、需求变更：看到实物后，想法变了
这一块不算"超支"，更像"追加"——但它同样会让项目总花费超出最初预期。
变更的原因很正常：看到第一版实物之后，人的想法会更清楚。「原来是这样，那我们能不能再加一个……」——这在 AI 项目里几乎是必然发生的，因为 AI 应用不像传统软件，它能做什么、做不到什么，不看到实物很难想象。
真正的问题不是"要不要许变"，而是变更怎么被处理：
| 处理方式 | 后果 |
|---|---|
| 口头应下、顺手做了 | 范围悄悄扩大，工作量堆积到后期一次性暴露 |
| 显式化：写清改什么、为什么改、影响哪些已完成部分、重新评估工期与费用后确认执行 | 双方对排期和预算始终有共同预期 |
这一类超支的防法：不是禁止变更，是让每次变更都留下记录和代价。小调整可以顺手做，大改动必须走一遍显式流程——这不是设障碍，是防止"最后加起来发现多做了半个项目"。
四、上线后维护：最常被漏在报价外的一块
第四块最隐蔽——它不在原始报价里，所以不算"超支"，但会实实在在产生持续投入。
维护分两层（这一点常被混淆）：
| 层 | 管什么 | 通常谁负责 |
|---|---|---|
| 基础设施层 | 服务器、备份、扩容、宕机恢复 | 云厂商 / 客户 IT——成熟行业、有标准 SLA |
| 业务运营层 | 知识更新入库、规则调优、质量体检 | 需要懂业务又懂 AI 的人 |
真正影响"半年后还好不好用"的是业务运营层：手册改版了谁重新入库？答案悄悄跑偏了谁发现？
这一层的动作是周期性的（定期跑固定问题集做回归），不是一次性的。如果报价时没有把它算进去，那么它迟早会以"另外一笔费用"的形式出现——这就是很多客户感觉"说好的钱之外还要再加"的来源之一。
五、为什么恰恰是这四块容易超
把四块放在一起看，共性很清楚：
| 环节 | 能否在开工前准确估 |
|---|---|
| 应用编排与开发 | 能——功能边界一旦定下，工作量大致可估 |
| 部署环境搭建 | 能——形态确定后相对固定 |
| 语料工程 | 不能——全貌要看清洗深度 |
| 系统集成 | 不能——取决于外部排期 |
| 需求变更 | 不能——取决于看到实物后的判断 |
| 上线后维护 | 不能——取决于上线后的运行状况 |
规律是：能准确估的部分，恰恰不是超支高发区。 这也解释了为什么"按功能点报价"在 AI 项目上总是失灵——能被功能点描述的部分，本来就不贵。
六、三个能在报价阶段防住超支的动作
不给具体金额（每个项目的数据条件差太多，给了反而误导），给三个动作：
① 开工前要样本，并且真跑一遍
不是"发几份文档看看"，是用几十页真实资料跑完整流程：转换、清洗、入库、检索、回答。跑完你就知道语料里藏着什么问题，对方也知道这块要花多少工夫。
② 边界写成"不做什么"清单
"做什么"通常写得很顺，但真正防超支的是**"不做什么"**：这个版本不接内部系统、不处理扫描件、不做多轮对话、不带权限分级。
写"不做什么"的约束力比"做什么"强——因为范围蔓延正是从"这个应该也算吧"开始的。
③ 变更显式化，代价当场结算
每次变更都写清四件事：改什么、为什么改、影响哪些已完成的部分、工期和费用怎么变。
这不是苛刻，是让双方都不被"最后加起来吓一跳"。
七、一个提醒：压价防不住超支，只会把风险推到执行期
如果你把费用压到很低才成交，会发生什么？
大概率不是"便宜买到了好服务"，而是：执行方为了控制成本，把语料清洗做浅一点、把边界场景少测一点、把上线后的维护环节省掉。
这些省下来的部分，不会消失，只是变成了上线后你才发现的问题——那时候再补，往往比一开始就做贵得多。
超支真正该防的不是"钱花多了"，是"钱花在返工上"。 判断一个报价合不合理，比起看总价，更该看它有没有把那四块的工作量算进去、有没有写清楚不做什么。
常见问题
为什么 AI 项目比传统软件更难准确报价？
因为传统软件的工作量主要由"功能点数量"决定，而功能点是在需求阶段就能数清的；AI 项目的工作量主要由数据状态和协作排期决定，这两样在报价那一刻往往还没暴露。
具体说：语料里有多少双栏排版、多少扫描件、多少需要单独处理的图表，要看清洗到一定深度才知道；集成要等多久，取决于对方部门的排期。这两类变量恰恰是成本大头。
所以更现实的报价方式不是给一个"一口价"，而是先给范围和阶段节点，再在拿到样本、跑出第一版之后确认完整工期与费用。
语料工程的工作量，有没有办法在开工前估得更准？
有，但只能靠"跑"不能靠"看"。
做法是：让对方提供几十页有代表性的真实资料（不是脱敏美化过的样例），在你自己的环境里跑完整流程——转换、清洗、入库、检索、回答一轮。跑完能暴露大部分结构性问题（双栏串行、图表截断、扫描件无文字层、分段切断了代码块等）。
这个动作的价值不在于精确算出工时，而在于把"不知道会碰到什么"变成"已经知道会碰到哪几类问题"。
需求变更是不可避免的吗？要不要在合同里禁止？
变更在 AI 项目里是常态而不是意外——因为 AI 应用的能力边界不看到实物很难想象，客户看到第一版后想法变化是完全正常的。
不建议禁止，建议显式化：小调整顺手做，大改动走一遍"改什么 / 为什么 / 影响什么 / 工期费用怎么变"的确认流程。
禁止变更的结果通常不是没有变更，而是变更转入地下——口头提、顺手做、没人记录，最后集中爆发。显式化反而让双方都不吃亏。
相关文章：企业做一个 AI 智能体，到底要花多少钱？（成本结构与量级判断）｜RAG 知识库交付实战（下）：18 条用例与成本测算（真实的语料工程与成本数据）｜AI 项目从开工到上线，一般要多久？（同样四个变量对工期的影响）
本文基于真实交付项目经验撰写（2026-08），语料工程数据来自 4277 页设备手册知识库交付实测记录。文中不含具体报价建议——每个项目的数据条件差异过大，绝对数字会误导。AI 参与创作声明：本文由 AI 辅助写作，内容基于作者真实交付记录。
