企业AI化落地：先技术，还是先业务？

业务负责人说AI项目没有改变结果，技术负责人说系统已经按需求完成。双方可能都没有说谎。前者关心客户和经营，后者交付的是已约定功能，中间缺少共同承担的验证过程。

“先业务”如果只被理解为业务部门先写需求、技术部门随后实施，这种矛盾仍然会出现。企业真正需要的是让经营判断与技术检查尽早相互修正，并给项目建立一个双方都能理解的结果目标。

业务症状，需要经过共同诊断

成交下降可以来自客户结构变化、产品不匹配、价值表达不足，也可能是销售交接丢失信息。给技术团队一个“提高成交率”的目标，并不能说明应该开发什么。

业务人员熟悉现场，却未必能区分自己的解释与事实。技术人员可以检验信息和流程，却未必知道一个客户信号的商业意义。双方需要回到同一批真实材料，确认问题出现在哪类客户、哪个阶段，以及企业目前在为它付出什么代价。

例如，销售认为跟进效率低，准备建设沟通助手。查看记录以后，可能发现需要反复请主管确认的是服务边界。如果只优化沟通摘要，销售还是要等待。真正需要改的，可能同时包括产品说明和内部决策方式。

传统功能开发可以围绕明确输入和输出讨论。AI项目里，业务方法本身可能尚待验证，技术也未必能稳定完成全部判断。把这两种不确定性藏进需求书，容易在交付时变成争议。

业务希望系统理解客户真实顾虑，技术需要知道用什么信息判断、哪些情况容易混淆、怎样识别错误。业务如果只提供一个理想答案，研发容易优化成复述答案；研发如果只展示一次成功输出，业务又容易把它当成稳定能力。

更好的合作，是一起检验边界。选择有代表性的案例和新情况，观察系统在哪些条件下可靠，在哪些条件下需要补充信息或转给专业人员。技术结果反过来帮助业务把隐含方法讲清楚，业务反馈也帮助技术确定改进方向。

在同一项任务中共同验证

内容部门希望产量增加，销售部门担心承接无效客户；技术团队希望统一流程，业务现场又需要保留例外。企业AI化不是每个部门分别增加一个工具，就能自然得到整体改善。

项目负责人需要明确优先取舍。更快回复是否值得增加审核成本，更多线索是否值得增加销售负担，统一方法是否会忽略重要客户差异？这些问题需要业务与技术共同提供依据，再由有经营责任的人决定。

若无人协调，部门会按照自己的标准优化，最后出现多个局部成功、整体价值不清的项目。一号位参与的意义，在于确定值得追求的结果和可以接受的代价，而不是亲自讨论每一个模型参数。

一次分析准确，员工却不采用，可能是呈现太长、出现太晚，也可能是系统建议不符合他拥有的权限。试点需要让实际使用者完成一轮工作，才能发现这些条件。

业务负责人检查成果是否帮助判断，员工反馈采用过程，研发定位资料、检索和执行问题。客户后续回应再帮助团队分辨原来的业务假设是否成立。这样才能把“模型不够好”“员工不会用”拆成具体可处理的问题。

指标也要围绕原来的损失来选。若问题是等待，就看整项任务的响应周期；若问题是错误判断，就看相似案例中的偏差；若问题是客户不适配，就追踪后续推进。不能只验收一个界面，也不能要求短期试点解释全部业绩变化。

业务负责人不能把专业判断全部外包，技术负责人也不能只等待完美需求。项目需要有人把客户、流程和经营目标翻译成可以检验的任务，又能把技术限制解释为业务选择。

燊林管理层15年A股上市公司业务与管理经历，包含逆风、翻盘和竞争项目。团队长期做营销执行、咨询与带队，关注的正是现场判断与方法落实。专门的AI研发人员让这些业务问题可以与应用配置同时推进，而不是停在咨询报告里。

涉及专业系统和复杂集成，可以引入相应技术伙伴；业务负责人仍需协调目标与取舍。分工清楚以后，各方才知道应该交付什么、怎样验证，以及出现偏差时由谁推动改变。

先业务，确定的是投资理由和经营优先级；技术早参与，检验的是路径与代价。两者在同一项真实任务里不断修正，企业才有机会获得可以继续维护、继续改善的能力。“十倍速增长”的主张，也需要这样的共同工作来支撑。