夜雨聆风经营分析 AI 系统要落地，业务规则、版本边界和开发成本必须被确认
>
摘要
这篇文章只讲一个判断：
> 经营分析 AI 系统要真正落地，不是有了数据、模型和程序就够了。它要承接经营判断，就必须先把业务经验变成可确认的规则，把规则变成有边界的开发任务。否则业务不确定性会被层层转嫁，最后变成开发返工、项目延期和组织争议，造成比项目价值本身更高的开发成本。
前两篇文章，我分别讲了两个问题。
第一篇讲的是：AI 时代，陪跑顾问的价值，不应该停留在替企业做事，而是把真实经营问题沉淀成方法、规则、工具和组织能力。
第二篇讲的是：AI 落地不能一开始就只讲宏大组织变革，而应该先从一个真实经营场景跑通。因为企业只有先看到可验证结果，才会愿意持续投入。
到了第三篇，问题就进一步具体了：
当企业真的开始开发一个经营分析 AI 系统，希望借助 AI 与程序化规则，帮助管理层更高效地完成“发现问题—分析问题—解决问题”的管理闭环时，项目最先卡住的，往往不是模型，也不是代码，而是业务规则确认。
因为这个系统不是普通报表，也不是传统 BI。
它要做的不只是展示数据，而是识别异常、判断状态、进入归因路径、整理证据、输出会议问题清单。
这就意味着：系统必须承接一部分经营判断。
而经营判断一旦进入系统，就必须回答几个问题：
哪些判断规则由谁定义？哪些业务口径由谁确认？哪些归因可以自动提示？哪些只能作为会议讨论方向？哪些进入当前版本？哪些放到后续版本？如果规则变化导致返工，开发成本如何处理？
如果这些问题没有确认清楚，项目就会看起来卡在沟通上，实际上卡在责任边界上。
01一个真实困境：业务说的是方向，开发需要的是规则
> 沟通卡住，不是因为业务没有表达，而是因为业务表达还没有转成系统可以执行、开发可以落地、组织可以确认的规则。
所以，企业开始基于 AI 开发经营分析系统，希望把经营分析从“看数据”，推进到“发现问题—分析问题—解决问题”。
这个系统不是再做一张报表，而是希望在经营分析会前，先输出异常清单、归因提示、证据边界和重点会议问题。
图2 从 BI 到经营分析 AI，项目要解决什么
也正因为它不只是展示数据，而是要承接一部分经营判断，项目推进时，沟通问题很快出现。
业务侧可能会说：
“不要搞这么复杂。”“业务可以按人、货、场来看。”“简单一点，人怎么做举几个例子，货怎么做举几个例子，场怎么做举几个例子。”
甚至有时候，会发一张图，让项目方理解方向、整理框架，然后说先做一版再迭代。
这些都可以作为需求输入。
但它们还不是开发依据。
一张图可以帮助理解方向，但开发不能只靠看图猜规则。开发必须知道：
这张图是参考样式，还是业务逻辑？哪些内容本期必须实现？哪些只是后续方向？每个模块背后对应哪些字段？什么情况下触发某个结论？如果理解偏差，谁来确认和修正？
“先做一版再迭代”也不是问题。
真正的问题是：这“一版”到底是样板验证、规则草案，还是正式开发任务？
如果它只是样板，就要明确本轮验证什么、哪些结论不作为正式判断。
如果它是开发任务，就必须明确字段、规则、触发条件和输出边界。
如果它是规则草案，就必须有人确认哪些成立、哪些不成立、哪些进入后续版本。
所以，这类项目真正卡住的地方，不是业务没有表达，也不是开发不能理解业务，而是中间缺少一个把业务方向转换成开发依据的确认机制。
业务可以先讲方向，但方向不能直接进入开发。方向必须先转成字段、规则、触发条件、输出边界和版本范围。
02表面是沟通问题，实质是规则没有确认
> 系统开始承接经营判断时，真正要确认的不是“大家有没有表达”，而是“表达之后谁来定规则”。
业务觉得项目方没有理解业务；技术觉得业务没有讲清需求；顾问觉得自己一直在中间翻译；管理层觉得项目推进太慢。
这些感受都可能是真实的。
但经营分析 AI 系统的难点，不只是“讲清楚”。
因为这个系统如果要自动识别异常、自动提示归因，就必须明确一整套规则：
什么指标算异常；什么状态算风险；什么数据可以支持归因；什么数据缺失时不能下结论；输出给经营会时，是正式判断，还是待讨论提示；规则冲突时，谁来裁决。
如果这些没有确认，项目就很容易进入一种循环：
业务说方向；项目方补规则；开发按理解实现；业务觉得不符合实际；技术返工；顾问继续兜底。
这个循环最麻烦的地方，不是大家没有沟通，而是每一轮沟通之后，都没有形成可以进入开发的确认结果。
看起来大家都参与了。
业务提了意见，顾问整理了方案，技术做了实现，管理层也在关注进度。
但如果没有人确认关键规则，系统就会在“做一版—被否定—再做一版—再被否定”之间反复摇摆。
这不是正常迭代，而是规则确认缺失。
正常迭代，应该是在明确边界内验证和优化。
规则缺失下的迭代，则是让开发和项目方不断替未确认的业务判断试错。
AI 项目最怕的不是没人提意见，而是系统已经开始承接经营判断，但规则确认责任还没有落下来。
03业务说得可能对，但不能直接进入开发
> 业务意见正确，不等于它已经是系统规则；经验可以启发方向，但程序需要字段、规则、触发条件和输出边界。
业务说经营分析要按人、货、场来看，这句话很有业务常识。
人，可能涉及员工能力、销售转化、培训、排班、执行力。货，可能涉及产品结构、库存、重点机型、高毛利商品、缺货。场，可能涉及门店位置、客流、商场活动、竞品、陈列环境。
这些方向都对。
但系统必须继续追问：
人有哪些可用数据？员工销售额、转化率、排班、培训数据有没有？货有哪些可用数据？库存、机型结构、毛利结构、缺货数据有没有？场有哪些可用数据？客流、商场活动、竞品数据有没有？哪些可以自动判断？哪些只能提示业务确认？哪些进入当前 MVP？哪些需要后续补数据？
如果这些问题没有回答，“人货场”就只是一个业务分析方向，还不是可以直接写进系统的规则。
更进一步说，如果没有员工转化率、客流、库存结构、竞品数据，却要求系统自动判断“人货场”原因，开发就会被迫把经验判断写成确定结论。
这不只是技术问题，而是责任问题。
系统输出之后，业务会不会认可？管理层会不会拿它追责？误判之后谁来修正？没有数据支撑的结论，应该写成“归因”，还是“待讨论方向”？
这些问题如果没有提前讲清楚，开发不是简单“改一改”。
可能要改数据结构、指标计算、归因树、页面展示、报告逻辑、测试规则。
对全职开发来说，这会消耗团队产能；对外部外包来说，这会直接变成延期、加价和合作风险。
所以，开发不是不能迭代，而是不能无限吸收未确认业务规则带来的返工成本。
全职开发不是免费成本，只是成本经常被隐藏在工资里。
外部外包也不是无限试错池，需求边界不清，最后都会变成时间、预算和信任成本。
业务语言可以是经验、场景和例子；系统语言必须是指标、字段、规则和边界。中间缺的不是沟通热情，而是规则确认机制。
04解决办法不是争对错，而是设置三道闸门
> 业务意见可以进入讨论，但未经分拣、定版和确认，不能直接进入开发。
但很多业务意见，本来就不是简单的对错问题。
同一句“这个不符合业务实际”，可能是指标口径错了，也可能是页面表达不清，也可能是业务经验需要补充，还可能是新增了一个规则扩展需求。
这些情况处理方式完全不同。
所以更有效的方式，不是先争对错，而是先过三道闸门。
第一道闸门，是业务意见分拣。
口径错误，比如指标、分类、预算、门店归属错误，本期必须修正。
展示优化，比如页面复杂、标签太多、表达不清，可以本期优化，也可以进入优化池。
业务补充，比如人货场、活动、竞品、现场情况，可以作为会议标签或待确认项。
规则扩展，比如新增数据、新增归因、新增复盘台账，应该进入后续版本。
第二道闸门，是版本边界。
当前 MVP 负责让会议分析得清楚：异常清单、数据层归因、会议问题清单、会前底稿。
V2.0 再负责让会议闭环得起来：问题台账、责任追踪、行动计划、下月复盘、更多业务数据接入。
很多想法是正确的，但正确不等于必须进入当前版本。
比如“增加下月复盘区”很有价值，但它已经涉及问题台账、责任人、动作跟踪和跨月复盘。它不是简单加一个页面，而是一个管理闭环系统。
如果当前 MVP 还在验证异常识别和归因提示，就不应该把所有闭环功能都塞进去。
第三道闸门，是开发确认。
也就是在进入开发之前，必须确认：
字段是否存在？规则是否确认？触发条件是否清楚？输出边界是否明确？测试依据是否可验证？是否超出本期范围？
如果这些问题没有确认，就不应该直接进入开发。
不是所有正确意见，都应该进入当前版本；不是所有方向性意见，都能直接进入开发
05结尾：AI 落地不是让模型替企业判断，而是让企业学会确认规则
> 越是希望经营分析 AI 系统自动识别异常、自动提示归因，越需要企业先把业务规则讲清楚、确认清楚、分版本落地。
但它不是替企业承担经营判断责任。
越是希望系统自动识别异常、自动提示归因、自动生成会议问题清单，越需要企业先确认：
哪些分析规则成立；哪些结论可以进入会议；哪些原因只能作为待讨论方向；哪些数据缺失时必须停止判断；哪些需求进入当前版本；哪些变化需要重新评估开发成本。
否则，AI 系统不是降低沟通成本，而是把未确认的业务不确定性更快推向开发，最后形成更快的返工、更大的争议和更高的组织成本。
所以，AI 落地真正困难的，不是让系统“看起来会分析”。
真正困难的是，让企业愿意确认：哪些分析规则成立，哪些结论可以进入会议，哪些责任必须由组织自己承担。
有效的经营分析 AI，不是让模型替企业判断，也不是让开发无限返工，而是帮助企业把业务经验、规则边界、开发成本和管理责任变得更清楚、更可确认、更可复盘。
