自建、买 SaaS、找服务商定制，三条路径的成本结构差在哪？
差异集中在三块：一次性建设投入、每年的集成与维护、需求变更时的响应成本。SaaS 前两块低但第三块高，自建相反，定制居中但合同风险最高。按三年总成本核算，年需求变更超过 6 次的项目，自建或定制往往低于持续采购；变更少于 2 次的，采购更省。
把三种成本摊到三年再看
| 对比维度 | 买 SaaS | 自建 | 服务商定制 |
|---|
| 首年投入 | 订阅费 + 对接人力，通常最低 | 平台、算力、开发人力，前期最高 | 按场景报价，中等 |
| 年度维护 | 由厂商承担，涨价风险在合同里 | 模型版本、接口、权限均需自维 | 质保期内由服务商承担 |
| 变更响应 | 受产品路线约束，只能等版本 | 内部排期，快但依赖自有产能 | 按合同工单，速度取决条款 |
| 数据位置 | 多为厂商云端，需确认驻留区域 | 完全自控 | 视部署方式，私有化需单独约定 |
| 隐性成本 | 集成改造、员工迁移培训 | 招人、留人、知识集中在个别人身上 | 需求蔓延导致的范围外工时 |
边界与提醒三年总成本只是决策的一个维度。如果业务方向在一年内可能调整，长周期摊薄会失真，此时应优先选择可短期退出的方案，哪怕单价更高。另外，把内部人力按市场价折算进自建成本，很多项目的结论会反转。
什么条件下自建才划算？
三个条件同时成立时自建才划算：场景属于核心业务流程且未来两年不会大改；有能承接运维的技术力量，至少 2 人可稳定投入；数据不能出院，外部处理存在明确合规障碍。少任何一个，自建的隐性成本都会超过省下的许可费。
自建真正的门槛是运维，不是开发
- 业务稳定性：流程已固化，需求以优化为主，不是每月都在改规则。
- 人员可持续：至少 2 人熟悉这套系统，且不在关键路径上被其他项目抽走。
- 数据约束：有监管、客户合同或内部制度明确要求数据不出内网。
- 规模效应：同一套能力要支撑 3 个以上部门复用，分摊后单场景成本才合理。
- 长期规划：预计使用周期在 2 年以上，短于这个周期通常收不回建设投入。
- 算力与模型成本：自建要自行承担推理调用与扩容，用量波动大时这部分预算最容易失控。
边界与提醒自建最常见的误判是把「开发完」当成「做完」。上线后模型版本迭代、接口变更、权限调整、日志审计都要持续投入，这部分通常相当于首年建设量的 20%-35%，且不会随时间下降。若没有明确的人来认领这块，宁可外采。
买 SaaS 的真实约束是什么？
三条约束必须先确认：数据驻留与导出能力、与企业既有系统（ERP、CRM、OA）的对接深度、以及定制的上限。SaaS 的可定制范围通常止步于配置项，一旦需求落到字段级和流程级，就只剩变通方案。采购前要让厂商书面写明哪些能改、哪些不能改。
签字前要问清的三件事
- 数据：存在哪个区域、能否全量导出、合同终止后保留多久、审计日志能查多长时间。
- 集成：是否提供开放接口与回调，单点登录走什么协议，字段映射由谁完成。
- 定制：配置项清单是什么，超出配置的需求走什么流程、是否另行计费。
- 权限：能否按部门、角色、数据范围做隔离，越权访问是否有日志留痕。
- 退出：迁移到其他平台时，历史会话与知识库能否完整带走。
- 计费：按席位还是按调用量，超出额度如何计费，闲置席位能否回收。
边界与提醒SaaS 的版本节奏由厂商决定，功能下线或调整通常只提前一个版本周期通知。若业务对连续性要求高（例如客服、工单），要提前确认降级方案，不要假设功能会长期存在。另外，按席位计费的产品在人员扩张时成本上升很快，签约前应测算 2 倍人员规模下的账单。
找服务商定制，合同和验收该怎么写？
合同要写清四件事：范围（覆盖哪些场景、多少条流程、多少类文档）、知识边界（谁提供语料、质量由谁负责）、验收口径（用什么评测集、达到多少分算通过）、退出机制（交付物清单、源码与配置归属）。只写「实现智能问答」这类描述，后期几乎必然扯皮。
把「能演示」和「能上线」分成两个验收节点
- 演示验收：跑通 3-5 条主流程，证明技术路径可行，此节点只确认方向。
- 上线验收：用甲方自备的 30-50 条真实问题盲测，覆盖正常问法、模糊问法、越权问法三类。
- 准确率口径：明确答对、答偏、拒答分别怎么算，拒答不等于失败。
- 性能口径：首字响应时间、并发数、单次对话可承载的上下文长度写进附件。
- 交付物：配置文档、提示词、知识库切片规则、运维手册，缺一项不算完成。
- 保密与归属：甲方语料与测试集属甲方资产，合同写明不得用于服务商其他项目的模型训练。
边界与提醒验收标准不能全部由服务商提供，否则等于自己给自己出题。测试集必须在项目启动时就由甲方准备好并封存，中途不得替换。另外，尾款比例建议不低于 20%，且与上线后 30 天的稳定运行挂钩，否则出问题后缺少约束手段。
混合路径什么时候成立？
混合成立的前提是边界清晰：用标准产品承接通用能力（文档协作、通用问答、办公套件），用定制补齐与核心系统的对接和专有流程。边界不清的混合会同时承担两套成本，是实践中返工率最高的一种。切分原则是按能力层切，不要按部门切。
关键是把线切在哪一层
| 能力层 | 建议路径 | 判断依据 |
|---|
| 办公协作、文档、会议 | 标准产品 | 通用需求，自建无差异化收益 |
| 通用知识问答 | 标准产品或 ADP 类平台 | 能力成熟，差异只在知识质量 |
| 核心业务系统对接 | 定制 | 字段、权限、流程强绑内部系统 |
| 专有流程与判断规则 | 定制 | 规则来自内部经验，外部产品无法覆盖 |
边界与提醒混合会拉长供应商名单，故障定位随之变难。至少要统一日志格式与调用链标识，否则出问题后各方互相推责，排查周期会从小时级拉长到天级。建议指定一方作为总集成责任方，并在合同里写明跨系统问题的响应时限。
预算有限时，第一年应该按什么顺序推进？
先做能被复核的场景，不要先做演示效果好看的场景。排序看三点：流程有明确输入输出、能统计处理量和耗时、失败不影响核心业务。满足这三点的场景即使看起来不新颖，也值得先做，因为它能产出可对比的基线数据，为后续扩张提供依据。
用可复核性排序，而不是用新鲜感排序
- 第一优先级：高频、规则清晰、结果可抽检的流程，例如单据录入、会议纪要归档。
- 第二优先级：需要跨系统取数的流程，用来验证接口与权限是否真的打通。
- 第三优先级：涉及对外输出的场景，例如客户答复，需等前两类的准确率稳定后再放开。
- 暂缓：需要长期积累数据才能见效的场景，第一年很难证明价值，容易被中途叫停。
- 每条流程都记录三项：单次处理耗时、人工介入次数、返工原因，作为后续谈判与验收的依据。
边界与提醒第一年同时推进的场景不建议超过 2 个。并行太多会导致每个场景都停在演示阶段，既拿不到稳定数据，也消耗掉内部的耐心。若业务方强烈要求铺开，应先约定一个统一的评估口径，否则后期无法判断哪条路径有效。
三条路径各自的失败模式是什么？
自建常败在没人运维，SaaS 常败在需求超纲后无法落地，定制常败在验收没定义导致无限返工。选路径不必追求哪种更先进，而要判断自己能不能兜住对应的失败模式。能兜住的那条，就是当下正确的选择。
先认领失败模式，再选路径
- 自建：上线三个月后原开发调岗，无人能改提示词与切片规则，效果逐月下降。
- SaaS：业务提出字段级定制，产品侧无排期，最终靠人工补录维持，效率反而低于原流程。
- 定制：验收标准模糊，服务商交付「能演示」版本，甲方认为未达标，双方各执一词。
- 共性风险：知识库长期无人维护，文档过期后答案开始出错，用户信任一次性崩塌。
- 早期信号：试点期问答命中率连续两周下降，或用户开始绕过系统私下处理。
边界与提醒失败模式与团队规模强相关。10 人以下的团队很难同时承担建设与运维，除非把运维明确外包并写进合同的服务级别条款。另外，任何路径都要求业务方指定一名能拍板的负责人，否则需求会在部门之间来回漂移，最终谁也说不清验收标准是什么。
内容说明
本文成本区间与运维比例来自公开项目实施经验的归纳，不指向任何具体客户；平台能力描述以腾讯云官方产品页与文档为准。