为什么我不建议小团队一上来做 AI 平台

先说结论。

小团队第一轮 AI 建设，应该交付一个能被业务验收的应用，而不是一套假设未来都会复用的平台。平台只有在重复需求已经出现、维护责任已经明确、治理成本能够承担时，才是合理的下一步。

这篇文章用“销售跟进助手”这个具体场景，拆清应用怎样长成公共能力，以及团队什么时候应该停在应用层。我的判断是：诉求相似还不等于平台值得建设。

背景：平台冲动通常早于真实复用

一个五六人的团队同时收到销售摘要、客服问答和内容生成需求，很容易把三张需求单合并成“统一 AI 平台”。架构图里会出现模型网关、知识库、工作流、权限和运营后台，看起来每项都能复用。

问题是，销售摘要的输入来自 CRM，客服问答依赖知识权限，内容生成又需要发布审批。它们都调用模型，却不代表它们共享同一种数据、责任和失败处理。共同使用一个 API，不足以证明需要共同平台。

第一个应用只解决销售交接

先把目标缩成一件事：销售提交会议记录后，系统提取客户目标、已确认事项、待办和风险，生成一份待确认的跟进草稿，再由销售写回 CRM。

第一版只需要六个部分：

• 固定输入字段；
• 结构化提取；
• 草稿生成；
• 人工确认；
• CRM 写回；
• 失败日志。

这里不建设通用工作流市场，也不让其他部门配置模板。验收只看销售能否找到原始记录、修正提取结果、确认草稿并完成写回。

第二个应用开始暴露真假共性

如果随后建设客服工单归类，团队会发现模型调用、日志追踪和人工确认可以复用，但 CRM 字段映射不能复用，销售话术也不能成为客服规则。真正变化不是“又多了一个 AI 应用”，而是团队开始承担跨应用的接口兼容、故障处理和治理责任。

这时更合适的做法，是把复用点列成候选模块，而不是马上独立成平台。候选模块至少要写清调用方、输入契约、错误出口、维护人和版本变化影响。

一次重复只能说明“可能共用”。只有不同应用都愿意按同一契约接入，公共能力才真正存在。

第三个场景才验证抽象是否站得住

第三个场景可以是内部知识问答。它会继续复用身份、日志和模型路由，却会新增文档版本、检索权限与引用追踪。

如果三个应用都需要统一身份、调用审计和成本记录，可以先抽出这三项；如果只有知识问答需要文档治理，就把它留在知识应用内部。平台不是把所有方框搬到一起，而是把稳定重复的责任收口。

是否平台化要过四道门

我建议用四项条件做立项门槛：

1. 复用证据：同一能力已在多个独立场景出现，而不是路线图里预计会出现。
2. 契约稳定：输入、输出、错误与版本策略已被实际应用接受。
3. 责任明确：有人负责兼容、告警、文档和故障响应。
4. 治理可承受：权限、审计、成本分摊与升级流程不会压垮小团队。

只满足“代码看起来相似”，最多做内部共享库；满足前两项，可以做公共服务；四项都满足，才值得讨论平台。评审时再核对三个观察信号：信号一，第二个独立应用是否稳定调用同一契约；信号二，共享故障是否已有明确所有者；信号三，新应用接入是否真的减少总工时。它们不是附加指标，而是四道门是否成立的运行记录。

平台会新增一份不该被忽略的成本

公共能力一旦被多个应用依赖，就必须处理兼容、配额、监控、故障通知和接入文档。应用团队不再能随意改接口，平台维护者也不能只对“服务在线”负责。

小团队最容易低估的是治理成本。谁能创建密钥，谁能查看日志，哪个应用可以使用高成本模型，升级失败由谁回滚，这些都不是一张架构图能自动解决的。

还要把“公共能力故障”单独推演一次。假设共享模型路由升级后，销售摘要和客服归类同时失败，团队必须知道哪个应用先降级、谁通知使用者、旧版本保留多久，以及恢复后由谁重跑积压任务。如果这些决定仍由两个应用各自临时处理，共享服务只是集中了一处故障，并没有形成平台能力。

成本评审也不能只比较代码行数。应用内部重复一段稳定逻辑，可能比维护跨团队接口更便宜；只有重复开发、重复审计和重复故障处理的总成本持续高于公共服务的维护成本，抽象才有经济意义。

常见失败是抽象了代码却没有抽象责任

一种失败是把三个复制粘贴的模型调用封装成 SDK，就宣布平台完成。另一种失败是做了配置后台，却没有首个稳定用户。还有一种失败更隐蔽：每个业务都能接入，但出了问题仍由原开发者逐个排查。

这些情况说明团队只完成了技术抽象，没有完成服务承诺。平台的边界应由支持什么、拒绝什么、如何升级和谁来维护共同定义。

什么时候可以直接建设底座

如果组织已经有多个稳定 AI 应用，并且安全审计要求统一，那么身份、模型网关、日志和敏感数据策略可以先行。监管场景也可能要求所有试点先经过统一治理入口。

这不是“小团队永远不要做平台”。真正的边界是：治理需求是否已经真实存在，维护角色是否已经被组织承认。

用复用证据表做一次平台评审

列出未来一个季度内最可能落地的三个应用，把每项能力标为“应用专属、可能复用、已验证复用”，再补一列“若不共享会付出什么成本”。证据只取调用记录、故障处置和接入工时，不把路线图里的想象需求算作复用。

受监管团队可能必须先统一密钥、审计和数据出口，这是可以提前建设底座的反例，但范围应限定在已经存在的合规共性。评审结束只做一个决定：继续留在应用层、抽出一个公共服务，或为已经被验证的责任建立平台。