教学笔记

企业做 AI 创新项目，为什么总在路演现场卡住？

Gary Yang

过去几年，我陪不少企业团队走完了 AI 创新项目的全程：从业务部门出题，到项目组攻关，再到面向高管的商业路演，最后是落地。

我看到过惊艳的成果，也见过不少“路演很热闹，之后悄无声息”的项目。两类项目的技术水平往往差得不多，拉开差距的常是一件事：问题定义得准不准。

台上常见的毛病，比如讲成系统说明书、铺垫冗长、满屏技术术语，看起来是表达问题，追根溯源，大都出在问题定义上。

下面是我在辅导中反复遇到的几类情况，以及我的处理方式。

一、命题的尺寸，往往不是问题的尺寸

项目最初的命题，或者业务部门给出的命题，常常直接是“解法加指标”，比如“建一个某某中台”。它多半来自对现状的模糊体感，并没有说清“为什么非解决不可”。

项目组如果照单全收，到了台上只能讲“我们做了什么”，讲不清“帮业务解决了什么”。

Gary 老师建议：把命题当作起跑线，先在项目内部重新校准尺寸。看是照单全收，还是切出最关键的一节，抑或升维成更根本的结构性问题。多数时候，把切口收窄更合理。切口收窄后，问题变得可解、可验证，解法、证据和业务价值才能咬合在一起。

二、重新定义问题，是一场话语权的博弈

项目组推演时，常会发现卡住全局的瓶颈在原命题的边界之外。这时需要拿着事实回头，推动业务部门重新定义问题。

这一步很难，因为它牵动出题方的既有立场。谁握有定义权，问题往往就被限定在谁能承受的权责范围之内。但被搁置的问题不会凭空消失，到了评审现场，高管和评委照样会连环追问。

Gary 老师的建议：遇到这种卡点，光在表达上帮团队修饰没有用。我会把诊断结果客观呈现给真正有权重新划定问题边界的人。

三、评委评的，不是算法本身

问题定义的层次，决定评委用什么尺度审视项目：

触及决策者痛点的问题，会被当作战略事项来评估，评委关心的是资源、代价和组织风险；缩在局部细节里的问题，评委只会反复盘问“增量价值到底在哪”。

拿出业务闭环和实测数据的团队，会被追问激励与协同；拿不出硬证据、只跑通流程的团队，精力只能消耗在“到底有没有效果”的基础质询上。

技术实现再复杂，在商业评审中也很难加分。评委真正在意的是：这套方案放进组织机体里，会重构谁的权责？协同部门凭什么配合？收益是实测出来的，还是推演出来的？

四、短期项目与长期建设之间，要有锋利的接口

不少项目容易贪大求全，动辄宣称“构建底层平台”，这是长期建设该做的事，不是突击项目的尺寸。

划定边界为了给后续落地预留标准接口：哪些议题赛后需要进入专题决策？需要什么具体资源？哪些模块平滑并入现有业务？

接口理清了，路演就不再是单向汇报，而是一份递交给决策层的资源置换清单和下一阶段提案。

五、路演散场后，项目是沉寂还是起步？

项目的后续走向，在问题定义时就已经埋下了伏笔：

启动时没定清验收指标，收尾时就没人说得清做成了什么、还欠什么；台上讲不出“需要公司批准什么”，路演一结束，跟进就立刻陷入真空；而评委现场追问的阻力、利益冲突和责任归属，往往就是落地路上最现成的排雷清单。

六、表达是认知的显影液

在日常文档和组内汇报里，逻辑漏洞容易被专业术语掩盖。但路演要求团队在几分钟内，向苛刻的决策者讲清“为什么值得做”，漏洞就会直接暴露出来。

辅导时我常抓表达上的断点，顺着它往回找认知的卡点：

• 讲成系统说明书：没想清对面坐的是谁，对方凭什么支持你。
• 问题铺垫过长：把决策层早已知道的常识当成了新发现。
• 从问题直接跳到成果：没有提炼核心难点，解法的壁垒没想透。
• 通篇技术黑话：讲的是对自己费劲的事，而不是对客户关键的事。
• 频繁加免责声明：手头的证据撑不起论点，只能靠声明兜底。
• 说不出“需要公司批准什么”：项目与主业务之间缺少接口定义。

遇到卡顿，我通常问三个问题：台下的决策者听到这里会听懂还是卡住？如果是卡住，是没说清楚，还是自己没想清楚？没想清楚的，是问题本身、验证证据，还是两难权衡？

七、一个好问题，是团队长跑的心力来源

参与创新项目的骨干，往往要顶着本职的业绩压力，抽时间摸黑做原型、清洗数据、反复试错。在这种压力下，单纯喊口号没有用。

能撑住团队的，是一个定义精准、做成后有明确业务价值的好问题。它让大家知道自己在解决一个棘手的难题，而不是又被摊派了一项额外杂务。

同一个原始命题，往浅了定是个单点工具，往深了定是流程重塑，往远了定则是长期的组织基建。每一次定义，都在决定项目能走多远，以及谁来买单。

如果你的企业正在推进 AI 创新项目，或者团队正要准备一场面向高管的路演，欢迎找我聊聊。我的辅导和培训从“问题”出发，帮团队把项目想清楚，再讲清楚。