企业 AI，选大厂标品还是找团队定制？

先给一条对做定制的一方不利、但确实正确的结论：

多数情况下，应该先用标准产品试，不要一上来就定制。

理由不复杂：定制的前提是你已经知道要什么。而在没用过之前，绝大多数企业对"我们到底需要 AI 做什么"的判断都是不准的——这个判断只能通过真实使用来校准，不能靠讨论。

用标准产品跑 4–8 周，得到的信息比开 10 次需求会更有用。这段时间的花费通常是几千到几万元，而一次方向错误的定制，代价是它的几十倍。

什么时候标准产品就够

下面这几种情况，定制带来的边际价值很低：

需求是通用的。 会议纪要、文档问答、文案初稿、翻译、代码辅助——这些能力在标准产品里已经做得很成熟，而且更新速度比任何定制团队都快。

用的人少于 20 个。 定制的固定成本要被使用量摊薄。人少的时候，把钱花在标准产品的订阅上更划算。

流程还在变。 业务规则每月都在调整的阶段，定制出来的东西会持续处于"刚做完就过时"的状态。

没有需要保护的数据边界。 如果处理的资料本来就是公开或半公开的，那么私有化带来的成本增加换不到对应的收益。

标准产品的边界很清晰，撞墙的位置也很固定，通常是这 4 个：

一、它读不到你的数据。 标准产品能读你上传的文档，但读不到 ERP 里的实时库存、业务库里的客户状态、审批系统里的流程节点。凡是需要"结合当前业务数据回答"的问题，标准产品都只能给通用答案。

二、它写不回你的系统。 只能给建议，不能真正下单、建工单、改状态。任务止步于"给了个答案"，后面那一半还是人做。

三、它没有你的权限模型。 谁能看哪些资料、哪些回答需要谁确认、什么情况必须转人工——标准产品通常只有粗粒度的空间隔离，做不到按岗位、按数据行的权限。这一条在金融、法律、医疗、政务场景里是硬约束，不是偏好。

四、你无法验证它的质量。 标准产品会给一个整体的准确率印象，但不会告诉你在你的业务问题上表现如何。而这两者可以差很远。

第 4 条值得展开：检索类系统的质量不是一个数字。以开源评测框架 RAGAS（docs.ragas.io）的口径，至少要分开看上下文召回率、上下文精确率、答案忠实度、答案相关性 4 项——答错了到底是"没找到资料"还是"找到了但答歪了"，处方完全不同。

幻觉率这类指标有公开的横向评测可以参考（如 Vectara 的 HHEM 榜单），但那测的是通用场景。企业自己的问题，必须用自己的测试集重新量。

中间那一行常被忽略，但它是很多企业的正解：不推翻标准产品，只在它和业务系统之间补一段。成本通常远低于全定制，而解决的正是"读不到数据、写不回系统"这两堵墙。

通用的直接买标品，不要讨论。

两个都不需要——标品加上传资料通常够。有一个需要——考虑轻定制。

不能出，形态就被限定了，这一条优先级高于所有偏好。

这个问题的答案如果是"到时候看效果"，那么无论选哪种形态，最后都会变成一场关于感受的争论。

采购中经常出现"大厂方案更稳"的说法。这句话对一半：

对的部分——基础模型能力、可用性、更新速度，规模确实带来优势，这些方面自建或小团队很难追上。

不对的部分——"大厂方案"在多数采购场景里指的是平台产品，而平台产品面向的是所有行业的共同需求。你的业务里那些特有的规则、权限、异常处理，恰恰是平台不会为单一客户去做的部分。

所以更准确的问法不是"选大厂还是小公司"，而是：这件事里，哪一部分该用规模化的能力，哪一部分必须贴着你的业务做。

绝大多数真正跑起来的项目，底层用的是大厂的模型能力，上面那层业务逻辑是贴着自己流程做的。这两者不冲突。

MIT 的 NANDA 项目 2025 年那份《The GenAI Divide》里有个被反复引用的数字：约 95% 的企业生成式 AI 试点没有产生可测量的损益影响。

值得注意的是，这个比例和选了标品还是定制关系不大。项目失效的原因通常出现在更早的地方——场景没选对、责任边界没划清、没人负责持续运营。

先把这几件事想清楚，再讨论买什么。顺序反过来，选哪种形态都一样。