判断一：是否差异化
直接产生竞争优势、且同行难以复制的环节值得自建能力；通用办公、客服、审阅等标准化场景，采购成熟产品更划算。自研往往只是把别人已经踩过的坑重走一遍，还要长期承担模型升级与接口适配的维护成本。
判断二：团队能否留住
自研需要算法、工程与产品三类人长期在位，缺一个就会在半年内停摆。评估时看现有团队能否接手运维与迭代，而不只是能否完成第一个版本，后者常常靠外部支援或临时招聘实现，人来人走之后能力并不沉淀。
判断三：数据能否出内网
核心数据不能离场时，私有化部署与本地模型成为前提，选型范围会大幅收窄。此时更应关注部署、运维与升级能力，模型榜单上的排名反而没那么重要，因为可用性最终由运行环境与维护水平决定。
采购平台的真实边界
平台提供的是编排、接入与权限这类通用能力，不包含你的场景知识、流程改造与日常运营。把平台当成交付成果，是采购后长期空转的主要原因，续费时也很难向管理层解释价值，最终变成沉没成本。
混合模式最常见
第一个场景由外部交付，同时要求知识资产与评测方法移交，第二个场景内部主导、外部支持。这样既拿到结果，也把能力留在组织里，退出或更换供应商时不必从零开始重建，议价空间也会更大；也减少单点依赖。
适用与不适用
适合谁
- 在自研与采购之间犹豫的技术负责人
- 首次引入 AI、需要控制试错成本的企业
- 集团层面需要统一技术路线的规划部门
不适合谁
- 已明确要求全部自研且不接受任何外部支持的团队
- 尚未确定场景、只想先比价采购的部门
典型场景
某地产集团的合同审阅需求最初计划自研。评估后发现团队没有长期算法岗位，且合同数据涉及大量敏感条款。最终选择外部交付首版，合同中约定知识库与评测集移交、两轮内部培训，第二版由内部 IT 主导迭代，外部按需支持，预算与责任边界也更清楚。
可执行步骤
- 先判断该能力是否属于核心差异化，并写出理由与至少一个反例供讨论
- 盘点内部团队能否支撑长期运维与迭代，而不只是把第一版做出来，缺哪类人就补哪类
- 确认数据分级、部署边界与网络条件，形成书面结论并在立项会上留档，形成可引用的结论
- 把三条路径的隐性成本、退出方式与锁定风险排成对比表，逐项打分，避免凭印象决策
- 首场景选择外部交付，同时把能力移交写成可验收条款并约定时间点，避免口头承诺
常见坑
- 为追求自主可控而自研通用场景，投入大且质量不如成熟产品，团队还背上长期维护包袱，很难回头。
- 采购平台后才发现场景知识与流程改造无人负责，平台长期空转，续费时难以解释价值，最终被停用。
- 合同未约定知识与方法移交，第二版仍要重新采购，等于同一件事付了两次费用，还浪费半年时间。
- 只看模型榜单选型，忽略部署、权限与运维能力，上线前才发现过不了内审，只能临时改架构；整改周期被拉长。
自检与验收清单
- 是否明确该能力与竞争力的关系及投入边界，并写明投入上限
- 内部是否有能长期维护与迭代的团队，缺人如何补
- 数据分级与部署边界是否已书面确认并留档，是否已进入项目确认单
- 合同是否包含知识资产、评测方法与账号移交，是否逐项列明
- 是否规划了第二阶段的内部接手时间与责任人
常见问题
自研一定更可控吗？
不一定。可控指的是能改、能查、能维护，自研只解决了第一项。若团队留不住、文档不全，自研系统的维护风险反而高于成熟产品，退出成本也更高，且很难在短期内重建一套能接手的人。
采购 SaaS 能满足要求吗？
标准化场景通常可以，尤其是客服问答、文档摘要这类通用任务；涉及核心数据、特殊流程或需要深度集成的场景，SaaS 的权限控制与定制空间往往不够，需要先做小范围验证再决定。
外部交付会不会被锁定？
会，如果合同没有约定源码、知识库、评测集与账号的归属和移交方式。把移交写成验收项，并在项目中期做一次接手演练，可以显著降低锁定风险，也能提前暴露文档与配置上的缺口。