企业第一次落地 AI，为什么不应该从购买平台开始？

THE PLATFORM TRAP / 01

平台解决“怎么搭”，但不解决“为什么做”。

知识库、工作流、Agent 和模型接入已经成为成熟平台的标准能力。企业可以很快做出一个演示，但演示通常回避真实资料缺口、权限差异、异常输入和业务责任。

如果项目从购买平台开始，团队容易围绕功能寻找场景：先建知识库，再要求所有部门上传资料，最后却没有一项工作因为系统而明显变快或变好。

更可靠的顺序是先确认具体任务和验收指标，再用这些约束选择最简单的技术组合。平台是实现手段，不是项目目标。

• 错误问题：我们应该购买哪个 AI 平台？
• 正确问题：哪项重复工作最值得改变，当前基线是什么？
• 技术决策：什么组合能以最低复杂度满足这项任务的边界？

FIRST WORKFLOW / 02

第一条流程应该同时满足五个条件。

首次项目的目标是验证企业使用 AI 的方法，而不是覆盖全部业务。范围越清楚，越容易识别资料、规则、接口和人员协作中的真实问题。

例如 B2B 询盘回复、产品选型辅助、客服知识检索、交付文档检查，通常都比“全公司智能助手”更容易建立任务边界和验收基线。

• 高频：每周反复发生，而不是一年处理几次。
• 有价值：改善速度或一致性后，影响客户、收入、成本或交付。
• 有依据：存在资料、规则、案例或历史结果可供系统使用。
• 可复核：业务人员能判断输出是否正确，能提供参考答案。
• 可拦截：错误结果不会直接造成不可逆损失，关键动作可以人工确认。

MINIMUM SYSTEM / 03

首个可用系统需要六类能力，而不是更多功能。

首个版本不追求功能数量，而要保证一条任务从输入到结果能够稳定完成。模型只是其中一层；资料、权限、人工责任和评测通常更决定业务能否接受。

如果一项能力不能帮助真实任务更准确、更快或更安全，就不应在首次项目中优先建设。

• 输入：明确接收什么信息，缺少什么时如何追问。
• 依据：可管理的知识来源、业务规则和版本。
• 生成：针对任务选择模型、提示和输出格式。
• 控制：身份、权限、敏感数据、拒答和人工审核。
• 动作：把确认后的结果发送、记录或写回现有系统。
• 评测：固定真实任务集、失败分类和上线门槛。

REAL ACCEPTANCE / 04

用同一组真实任务做前后对比。

没有上线前基线，就无法判断 AI 是否创造价值。项目开始时应选取有代表性的真实任务，记录人工处理时间、结果质量、修改次数和常见错误。

上线验收使用同一批任务，比较最终可用结果，而不是只看模型第一次输出。人工修改、等待系统和异常处理都属于真实成本。

• 效率：完成可用结果的总时间，而不是模型响应时间。
• 质量：事实、依据、格式、规则和客户承诺是否正确。
• 风险：错误是否被发现，失败是否安全回退。
• 采用：目标用户是否愿意持续使用，为什么回到旧流程。
• 经济性：节省时间和提高质量是否覆盖建设与持续运营成本。

DEPLOYMENT / 05

私有化的重点是控制权，不是盲目自建模型。

对大多数首次落地的企业，客户自有云账户、客户自有模型 API Key 和独立数据存储，已经能建立清晰的账号、数据和退出边界。它比购买 GPU、部署大模型和组建模型运维团队更轻。

只有当资料不能离开内网、调用量足够支撑硬件、模型必须深度定制或合规明确要求离线时，才需要评估本地推理。技术强度应与真实风险匹配。

• 默认：客户云账户 + 客户模型凭据 + CapaLayer 远程实施运维。
• 进阶：客户本地服务器 + 内网知识与身份系统。
• 严格隔离：全离线模型、硬件和运维体系，单独评估成本。

AFTER LAUNCH / 06

上线后，企业真正需要的是持续运营能力。

企业资料会更新，业务规则会变化，模型会迭代，用户也会提出新问题。没有持续运营的 AI 系统，即使服务器一直在线，业务质量也会逐步下降。

应固定知识更新责任、评测频率、故障响应、模型切换流程和成本阈值。首个闭环稳定后，再把方法复制到相邻流程，而不是一次扩展到所有部门。

• 每次知识或模型变更先运行固定回归评测。
• 按失败原因改资料、规则或流程，不只反复修改提示词。
• 记录用户采用、人工修改和旧流程回退的原因。
• 定期验证备份能够恢复，而不是只确认备份文件存在。