误区一：自研可控
自研能掌控代码，却仍依赖模型接口、框架与云服务。为什么危险：供应商涨价或停服时，自研系统同样要改。怎么识别：画一张依赖图，标出外部接口与版本，若关键路径上有单点依赖，可控就是错觉，必须提前设计备选。
误区二：采购省事
采购省的是开发，不省集成、权限、数据与运营。为什么容易误判：销售演示的是产品能力，落地要接内部系统与流程。怎么做：在采购前把集成清单、数据迁移与培训列出来，估算内部投入，再比较总成本。
误区三：自研省钱
只算开发人力，忽略招聘、流失、升级与文档。怎么算：把三年的人力、管理与机会成本摊开，与采购的订阅、集成与定制费用对照。边界是小团队自研通用能力，往往比采购更贵，还拖慢主业，得不偿失，也难以持续。
误区四：开源免费
开源省许可，不省部署、调优、安全与合规。为什么重要：漏洞响应与版本升级要有人跟，出了事没有厂商兜底。怎么做：评估社区活跃度、许可证条款与自身运维能力，把人力成本计入，再决定是否采用，并写明维护人。
误区五：一定终身
模型能力、业务需求与供应商格局都在变，三年前的结论可能已失效。怎么做：每年复盘一次，检查依赖、成本与替代方案。边界是核心系统不宜频繁更换，但要有可替换的设计与退出预案，避免被单一供应商绑定。
适用与不适用
适合谁
- 正在做自研或采购决策的业务与技术负责人
- 已上线系统、准备复盘依赖与成本的企业
不适合谁
- 需求尚未明确、还在收集信息的团队
典型场景
某企业三年前自研了一套问答系统，当时认为完全可控。今年模型接口涨价、框架停止维护，团队才发现依赖比预想的多。复盘会上，他们把五个误区逐条对照，决定保留业务层自研，把模型调用与检索换成可替换的组件，并设年度复核。
可执行步骤
- 画依赖图，标出模型、框架、云服务与关键第三方接口，注明版本，形成清单并归档
- 列出采购落地要做的集成、迁移与培训工作项，估算内部工时，并排出优先级
- 按三年口径折算自研人力、流失与升级成本，与采购订阅费用对照并列表
- 核对开源许可证、社区活跃度与漏洞响应机制，写进评估报告并附上结论
- 设定年度复盘节点，检查依赖、成本与替代方案是否变化，并指定负责人，形成记录
常见坑
- 把自研等同于可控，忽略模型与框架依赖，供应商一变就只能被动改造，时间与预算都超，团队疲于应付。
- 以为采购省事，集成与数据迁移没人估，上线时间被内部工作拖长，业务部门开始质疑立项的必要性。
- 只算开发人力，忽略招聘与流失，核心成员离职后系统无人维护，只能临时外包救火，风险更高，追责也难。
自检与验收清单
- 依赖图是否覆盖模型、框架与云服务并注明版本，纳入验收清单
- 采购落地的集成与迁移工作是否估算工时并复核
- 三年成本是否含招聘、流失与升级维护费用，并留档
- 开源许可证与漏洞响应机制是否核实并留档备查
常见问题
自研的核心风险是什么？
不是技术难度，而是持续性。人员流动、版本升级与安全补丁都需要长期投入，一旦预算或编制缩减，系统会停在某个版本上，风险随时间累积，最后只能推倒重来，前期投入全部沉没。
采购最容易被忽略什么？
集成与数据迁移。产品演示通常跳过这两步，实际要对接账号、权限、历史数据与业务流程，工作量常超过采购本身。签约前把这些列成清单并估算工时，能避免上线延期与预算追加。
开源方案适合什么团队？
适合有检索或工程能力、能跟进版本与漏洞的团队。若没有专人维护，开源反而更贵：部署、调优与安全响应都要自己承担，出问题时也没有厂商可以追责，风险完全内部化，需提前规划维护人。