背景
做企业 AI 项目，选型阶段被问得比较多的一个问题不是“用哪个模型”，而是“这套东西到底该自己搭、买现成的，还是找团队做”。
先给结论：这个选择不是三选一，通常是分层的——非敏感、标准化的能力买现成的；核心数据相关的放在自己可控的环境里；与业务强绑定的部分做定制。判断依据是四个可量化的问题：数据敏感度、使用频率、业务耦合度、自有维护能力。下面按项目里实际用的方式展开。
一、三种路径分别在什么情况下成立
| 路径 | 成立条件 | 典型代价 |
|---|---|---|
| 买现成（SaaS） | 场景标准、数据不敏感、要快 | 定制空间小，长期按量付费 |
| 自建 | 有机器、有人运维、业务量大 | 初期投入高，要养人 |
| 找团队定制 | 业务耦合深、没有内部开发 | 依赖外部团队，要选对人 |
多数公司的实际情况是三种混用，而不是单选。把混用当默认，选型讨论会理性很多。
二、四个判断维度
一、数据敏感度。 客户名单、图纸、成本、单价属于核心资产；产品手册、公开话术属于一般资料。前者决定能不能放到公共云，后者决定能不能走标准产品。
二、使用频率。 一个岗位每天重复几十次的动作，值得做成系统；一年做几次的判断，做成文档和流程就够。频率是 ROI 的分母。
三、业务耦合度。 如果流程里带着行业特有的规则（比如非标报价、按工序排产），通用产品通常差一口气，改造成本可能高于定制。
四、自有维护能力。 有没有人能接住上线后的运行、补知识、看日志。没有人的话，自建反而更容易烂尾。
三、一个可以照着走的决策顺序
不要一上来就比产品。按这个顺序走：
- 先划边界：列出要交给系统的具体动作，写清触发条件和输出；
- 再定数据落点：哪些数据可以出内网，哪些必须留在里面；
- 再定验收口径：独立解决率、人工时长变化这类可测的指标；
- 才进入选型：拿着前三步去看方案，判断谁能答得上。
顺序反了，容易出现“方案都很像，选谁都行”的局面，决策就退回凭感觉。
四、自建的真实成本不止服务器
很多团队低估了自建的成本。显存只是第 0 项。
- 硬件：推理卡、内存、存储，以及为留出并发余量而多买的配置；
- 人力：至少要有人管部署、管模型版本、管知识库更新；
- 工程：权限、审计、兜底机制这些不会因为自建而自动出现，仍然要写；
- 运维：监控、告警、故障恢复、容量规划。
业务量不够的时候，独享实例往往是比全量自建更划算的中间方案：数据隔离度接近自建，但不需要自己养运维。
五、买现成产品的三个检查点
买现成不等于省事，重点看三条：
- 数据条款：是否明确不用于模型训练，能不能提供可抽查的日志；
- 导出与退出：数据能不能完整导出，停了服务之后还能不能用；
- 扩展接口：有没有 API 或 webhook，能不能接进现有系统。
第三条容易被忽略。没有扩展能力的产品，用半年就会变成新的数据孤岛。
六、定制的边界怎么谈
定制项目翻车，通常不是技术问题，是范围和验收没说清。建议在合同里写明三件事：
- 交付物清单：具体到模块、接口、文档；
- 验收口径：用哪几个指标、怎么取数、谁来判定；
- 变更机制：需求变更走什么流程、怎么计价。
没有这三条，项目中途难免因为“这算不算范围内”产生分歧。
七、上线之后的维护协议
系统上线是起点。维护期要约定：
- 每周谁负责补未命中的问题；
- 多久重跑一次评测集；
- 出现新问题多久响应。
这一条比选型本身更容易被忽略，也是不少项目在半年后失效的直接原因。
小结
企业 AI 选型，判断顺序是：先划业务边界，再定数据落点，再定验收口径，之后才比产品。自建、买现成、定制不是互斥选项，多数场景是分层混用。
落地参考：数据落点、权限分级、审计日志、兜底机制这几项在千视科技的项目里都是标配件，深圳地区可以约面聊，公司在宝安西乡。有问题欢迎评论区交流。
