AI 项目立项前，业务方与技术方必须对齐的 5 个核心共识

过去两年，我们参与了不少 AI 集成项目，从营销内容生成到客服自动化，再到内部流程优化。一个反复出现的现象是：项目启动时双方都很兴奋，但几周后业务方觉得“AI 不听话”，技术方觉得“需求模糊”，最后项目要么延期，要么交付物与预期相差甚远。

问题通常不在技术本身，而在立项阶段忽略了几个关键共识。以下是我们从项目中提炼出的 5 个必达共识，供业务决策者在启动前与开发团队（无论是内部还是外部）彻底对齐。

共识 1：业务问题 vs. 技术方案——先定义“为什么做”

很多项目从一开始就跳到了“用什么模型”“搭什么架构”上，却没人清楚业务上到底要解决什么具体问题。是降低客服人力成本？还是提升网站转化率？还是减少重复性数据录入？

当业务方说“我们要上一个 AI 客服”，技术方直接开始讨论 GPT 还是开源模型时，风险已经发生了。我们建议立项前必须写一份不超过一页的“问题陈述”，包含：当前痛点是什么、不解决的成本有多大、用什么指标衡量成功。

关键动作：业务方提供 3-5 个真实业务场景及期望的输入输出示例。技术方基于这些示例评估可行性，而不是凭空假设。

共识 2：准确率与“够用”的边界——AI 不是 100% 正确

这是最容易产生误解的地方。业务方常常期待 AI 像人一样精准，甚至更好。但现实是，即使在最成熟的自然语言处理任务中，100% 准确率几乎不存在。一个客户意图分类模型能做到 90% 准确，但剩下 10% 的误判对业务流程有多大影响？

我们经手的项目中，有一个客户坚持要求“AI 必须完全替代人工审核”，但经过两个月的测试发现，某些边缘案例的错误率始终在 5% 左右。最终我们共同设计了一个“人机协作”流程：AI 处理低风险案例，高风险案例转人工。这个共识一旦在立项时达成，后续调整会少很多。

建议双方在立项阶段就定义好“可接受的最低准确率”以及错误发生时的回退机制。

共识 3：数据是燃料，但燃料需要预处理

很多业务方认为 AI 项目启动后，技术方可以直接用现有数据“训练”出结果。但实际中，数据格式不统一、标签缺失、历史数据分散在不同系统里是常态。我们曾接手一个项目，业务方声称“有十万条对话记录”，但提取后发现其中 70% 是无关的问候语和重复内容，真正有用的训练样本不到一万条。

业务方需要承诺：提供足够量级的、经过初步清洗的数据样本，并指派一位熟悉业务逻辑的人协助标注。技术方则需要坦诚评估数据质量，并在预算中预留数据清洗和标注的时间成本。

共识 4：集成不是“插上去就行”——边界成本必须算清楚

AI 模型本身只是项目的一部分。如何将模型输出接入现有 CRM、ERP、官网或客服系统，往往比模型训练更耗时。一个典型的例子是：模型返回了客户意图标签，但业务系统需要特定格式的 JSON 才能触发后续流程，这中间通常需要写适配器或修改 API 逻辑。

我们在多个项目中发现，集成环节占总开发时间的 40% 以上。如果业务方以为“模型跑通了就上线了”，大概率会面临预算超支。建议立项时双方共同绘制一张“集成流程图”，标出数据流向、系统对接点和异常处理逻辑。

共识 5：维护不是一次性的——持续校准是常态

AI 模型上线后不是终点。业务数据在变，用户行为在变，模型会逐渐漂移。一个去年表现良好的推荐模型，今年可能因为产品目录更新而效果下降。很多企业没有在立项阶段规划模型的持续监控和定期重训，导致上线三个月后业务方抱怨“AI 越来越不准”。

我们建议：在项目启动时明确第一阶段的“维护窗口”——比如上线后第一个月每周评估一次，之后每月一次。同时预留 15-20% 的预算用于后续校准。如果业务方希望自建维护能力，技术方可以协助培训团队；如果希望外包，则需要签订长期服务协议。

这五个共识听起来简单，但在实际项目中，每一条都曾导致过团队之间的摩擦和项目延误。如果你的团队正在筹备一个 AI 项目，不妨在立项会议上把这五个议题过一遍。如果发现某个领域存在明显的信息不对称，说明需要更多前置沟通。AUMCREATE 在过往项目中积累了一套“AI 项目共识检查清单”，如果你需要参考，我们愿意分享。