过去这一年,AI浪潮席卷了每一个行业。我们公司也顺应趋势,在最近成立了AI办公室(AIO),肩负起推动全公司AI战略落地的重任。
随着公司上下对AI转型的决心越来越大,预算也逐渐到位,我们预想到:在这样强劲的起势下,一定会有大量来自各业务线的AI项目源源不断地涌入。
为了迎接即将到来的项目潮,我们迫切需要提前建立一套统一的评审标准。
坦白说,在推进这项工作时,我们AIO内部存在着极大的顾虑:
一方面,如果管得太死,完全照搬传统IT项目那套确定性财务逻辑,极易扼杀掉那些仍处于萌芽期、但极具爆发潜力的脆弱创新,甚至会让业务部门觉得AIO是“拦路虎”;
另一方面,如果放任不管,为了所谓“鼓励创新”而大开绿灯,宝贵的算力、研发资源和预算就会被迅速耗费在毫无壁垒的“套壳玩具”和跟风做秀的伪需求上。
原文配图 1
我们需要在这两者之间寻找平衡,借这把“筛子”来精准判断——哪些是真需求,哪些是伪创新?哪些该重金投入、哪些先暂缓观望、哪些需要直接打回重造?
因此,这套标准的目的,绝不是为了设置审批门槛去“拦截”业务部门的创新热情,而是为了在资源投入前,切实保证每一个立项的项目都真正具备落地的成功要素。
在公司AI转型的号召下,我能理解到大家心里其实都没底——并非怀疑大方向,而是不知道具体该如何评判一个AI项目的可行性。
一个很现实的背景是:绝大多数业务部门里并没有真正懂AI应用的专家。很多项目提案的诞生,仅仅是因为业务负责人在外面听了一场讲座、看了一篇爆款文章,凭着这些碎片化的“见闻”和直觉,就感觉自己的业务也能马上套用大模型做出来。
这恰恰是很多企业推AI转型时都会遇到的深水区问题:
真正的卡点往往不在技术,甚至不在预算,而在于缺少一套上下对齐、大家都认的评判标准。没有标准,就会导致资源被大量极其平庸的跟风项目消耗殆尽。
前阵子,面对这种建立标准的迫切需求,我们的CFO龙哥把一份他和AI深度推演的对话记录丢进了AIO内部群,基于那次长篇推演,他为我们梳理出了一套极具杀伤力的评审框架——“三层五维度”AI决策漏斗。
看完这份带着浓浓“首席投资官(CIO)”视角的推演记录,作为业务落地的角色,我是深度认可的,认可的关键在于五个维度过完,一个AI项目成功要素基本具备了。
今天,我想借着这套硬核框架,聊聊我作为落地执行者,在实际操盘过程中的一些深度思考、踩过的坑,以及这套框架背后的底层逻辑。

一、宣贯前提:为什么要建这套制度?评审绝不是来“卡”你的

前阵子在我内部开会解读这套“三层五维度”框架时,我特意给大家强调了一些前提:
因为我深知,当业务部门看到这密密麻麻的五大维度、三层Gate时,第一反应大概率是:“这么多要求,太难了,AIO是不是专门来卡我们项目的?”
首先要明确:为什么要建这套评审制度?
公司AI转型全面铺开,项目数量快速增长。但算力、资金和研发资源是有限的,我们必须确保每一份投入都流向真正有价值、能落地的项目。回顾过去,我们见过太多失败的教训:
立项时“拍脑袋”:全凭直觉和外面的爆款文章,缺少真实业务数据支撑。
技术与业务脱节:技术方案看起来无懈可击,但上线后业务没人用,效果远低于预期。
刻舟求剑:项目做完了,系统上线了,但业务流程没变、组织考核没调整,等于白做。
重复造轮子:产出的数据和模型无法复用,每个项目都在从零开始。
“三层五维度”的核心目的,就是为了在立项阶段将这些风险前置暴露,避免高昂的试错成本。
我们的核心理念是:AI转型绝不只是上线一套IT系统,而是要把公司最核心的业务经验逐步沉淀为数据资产,让AI能够辅助甚至替代部分重复性决策。
因此,我澄清了一个极其重要的事情:评审的本质是帮你把项目想清楚,绝不是给你设障碍。
五个维度对应的,其实就是做任何一个成功项目都必须回答的五个最基本的问题:现状清不清楚?值不值得做?技术行不行?能不能留下资产?组织跟不跟得上?
这些问题,不管有没有这套评审制度,在做项目之前都应该想透。区别只在于:以前大家往往是项目做完了、失败了,才发现没想清楚;现在,我们是在立项的最初阶段,就强制帮你查漏补缺。
而且,为了呼应我前面提到的顾虑,扼杀掉萌芽期的创新,我特意做了以下补充:
不通过 ≠ 被否决:绝大多数情况只是“信息不够,请补充一下数据”,重新来过即可。
还没准备好?没关系,项目进储备池,AIO会协调资源,手把手帮你一起准备。
是轻量级小项目?直接走快速通道,AIO帮你快速评估,根本不需要走繁琐的完整流程。
有困难不知道怎么写PPT?AIO会提供标准的样板案例,你也可以随时找我们沟通。
说白了,我铺垫这么多,就为了表达一个观点:AIO的定位从来都不是居高临下的“审批部门”,而是“陪跑教练”。我们的终极目标,是帮更多优秀的AI项目跑出来,而不是把大家的创新热情挡在门外。
原文配图 2

二、底层共识:我们在防范“低级错误”,还是预防“战略平庸”?

要建立评审标准,首先要扭转管理层的认知惯性。传统IT项目(如上一个ERP或CRM系统)的评审,核心往往只看两个问题:能不能做(技术可行性)?值不值得做(财务ROI)?
但AI项目截然不同,它天然具备三个传统IT项目所没有的特征:
原文配图 3
第一,产出结果从“确定性”演变为“高度不确定”。
传统的软件工程是确定性的逻辑(If-Else),投入多少人力开发,就能产出确定的功能。
但大模型是概率模型。同样是"做一个智能审单系统",传统IT可以精确评估工作量和最终表现,但AI项目连最终效果都说不准——模型准确率做到80%算是成功还是失败?这完全取决于业务场景能容忍多大误差。在医疗辅助诊断中,99%的准确率可能都不够;但在营销文案生成中,70%的合格率就已经能大幅提升效率了。
第二,它会从根本上改变人的工作方式,而非仅仅是个工具。
这一点常被业务负责人低估。以前引入一套SaaS系统,表面上看只是增加了一个工具,员工依然是“操作者”。但引入AI Agent(智能体)后,员工的角色会从“执行者”转变为“审核者”。实际上,考核指标、工作流程、甚至岗位定义都得跟着发生剧变。如果组织阵型不跟着动,系统上了也只会沦为没人用的摆设。
第三,它不是买来的“静态资产”,而是越用越聪明的“活系统”。
传统软件上线那天,就是它生命周期的巅峰,此后只会慢慢折旧。但AI项目如果上线后就是"静态"的,那和买了一个普通软件没有本质区别。真正有价值的AI项目,应该在使用过程中持续沉淀人和业务的交互数据,形成企业自己的知识护城河。
龙哥在推演中尖锐地指出:如果我们沿用传统的评审思路,很容易陷入只看表面汇报的陷阱。一套优秀的AI评审框架,不仅要能防范“低级错误”(如技术不达标),更要能预防“战略平庸”(如做了一堆毫无壁垒的玩具)。基于这个共识,我们提炼出了以下五个核心的评审维度。

三、五个维度是怎么来的:防范三种致命陷阱

这五个维度不是平铺直叙的检查清单,而是一套带有强逻辑先后顺序的质询体系。

维度一:基线摸底——防范“管理谎言”与“假性痛点”

这是我们设为第一道门槛的绝对红线。
举个例子:当业务团队兴奋地提出"想用AI优化简历筛选流程"时,他们往往会描述一个美好的未来。此时,我们必须踩一脚刹车,要求他们回答:现在有几个HR在做?每人每天看多少份?每份平均耗时多久?目前漏看优秀候选人的概率大概是多少?

💡 龙哥金句:如果业务方不能清晰描述当前状态(As-Is)的真实数据,就不具备谈未来状态(To-Be)的资格。”

原文配图 4
在实际评审时,我们发现大量团队拿不出基线数据。一句泛泛的“筛选效率低下”与“5个HR日均处理800份、单份耗时3分钟、优才漏斗率15%”的量化指标,参考价值有天壤之别。
很多时候,业务方为了立项,会夸大痛点。主观感受固然重要,但决策需要客观数据,核心原则是:无数据,不评审;说不清现状,就别谈未来。
当然,有些项目确实是新业务探索,没有历史数据。这种情况我们也想到了:可以用行业基准、相似场景的参考数据、或者小范围试点的初步结果来替代。关键不是必须有精确数字,而是有据可依。

维度二:价值判断——防范“闭门造车”与“虚荣指标”

有了基线,下一步是判断价值的真实性。很多团队会汇报“我们的AI工具每天能帮每个员工节省1小时”,听起来很棒,但这往往是“虚假繁荣”。节省下来的这1小时,如果员工只是用来喝咖啡或者提早下班,对企业而言并没有产生增量价值。
因此,我们要求业务方明确区分两类项目,并接受极为苛刻的深度质询:
内部效率型(降本增效):如果你说是降本增效,那么省下的钱、挤出来的时间,最终落到了哪里?最核心的质询是:这个项目上线后,明年是否能从你们部门的预算中直接扣除相应的HC(人力编制)或外包费用?如果不敢承诺扣减,说明这个“效率提升”不够痛。
外部价值型(业务增长):如果你说是提升客户体验,客户是否能清晰感知到竞争力的差异?最核心的质询是:他们会为了这个变化买单吗?留存率会因此提升多少个百分点?
原文配图 5
如果做不到这两点,项目很可能只是业务部门在内部“自嗨”,为了做AI而做AI。

维度三:技术与风险边界——看透“规模化成本”与“战略脆弱性”

传统评审里,技术可行性靠架构师写一份方案文档就能通过。但在AI时代,除了强制要求用真实的业务数据跑出一个Demo来辅助说明(坚决避免纸上谈兵)之外,我们更关注其背后的隐性风险:规模化成本与战略脆弱性。
原文配图 6
这里有一个巨大的认知盲区:用大模型做POC(概念验证)是非常便宜的,花几十块钱买个API key就能跑通一个惊艳的Demo。但当这个项目推广到全公司,业务量放大100倍、1000倍时,Token的调用成本会不会急剧攀升,甚至吃掉这项业务所有的毛利?
另一方面是战略安全:我们是否过度依赖了某一家特定的闭源模型(如GPT-4或Claude)?一旦API断供或大幅涨价,我们的系统是不是就瘫痪了?有没有能力平滑迁移到开源模型(如Llama或Qwen)?技术上的“能跑通”绝不等于商业上的“可落地”。

维度四:数据资产——防范“重复造轮子”,寻找“生长型资产”

这个维度在目前市面上90%的企业的AI评审框架里是完全缺失的,但在我们的体系里,它是决定一个项目能否获得最高优先级和海量资源的战略加权项。
背后的逻辑很简单:我们要厘清这笔投资买来的究竟是一次性的“消耗品”,还是能持续增值的“生长型资产”。如果只是单纯调用大模型生成一段文案,那就是典型的消耗品。

💡 核心质询:项目上线一年后,它是变旧了,还是通过数据反馈飞轮变得更聪明了?

原文配图 7
真正的壁垒在于:它是否能将公司里最资深的老法务、老销售脑子里的隐性经验,通过他们对AI生成结果的修改和打分(类似RLHF机制),沉淀为公司私有的、竞争对手不可复制的微调模型或逻辑资产?谁能积累资产,谁就拥有免死金牌。

维度五:组织承接——解决“隐性冲突”与“跨部门依赖”

AI的引入往往伴随着权力的重新分配和流程的颠覆。如果岗位职责没更新、利益分配没调整,系统即使技术再完美,上线后也注定是一个摆设。因为没有人愿意主动使用一个可能取代自己,或者会增加自己工作量的工具。
除了常规的配套考核调整(例如将AI工具的使用率纳入KPI),龙哥还特别提醒我们关注一个极易被忽视的深水区维度:跨部门依赖。
很多技术评分极高的项目最后死得很难看,根本不是因为自身团队不行,而是因为它依赖的下游数据部门或IT基础架构部门,根本没有配合它的动力。比如,营销团队想做一个AI精准触达系统,但数据安全部门以合规为由拒绝开放底层API。
因此,在这一维度的评审中,我们不光看申报方(业务部门)的雄心壮志,更要审查相关配合方(IT、合规、财务)是否达成了“协同契约”。没有相关方的签字画押,项目直接拦截。
原文配图 8

四、评审的“三层过滤漏斗”:从听汇报到“首席投资官”

五个维度定了,接下来是怎么评的问题。为了避免评审变成过去那种"流程冗长、拖泥带水、扼杀创新"的官僚模式,我们设计了一个带有优先级过滤机制的“AITO决策漏斗”。
如果你认同这套漏斗结构,那么在评审会上,你就不再是一个被动“听汇报的人”,而是一个在关键断裂点发起强力质询的“首席投资官(CIO)”。你不需要去审查每一行Prompt是怎么写的,你只需要扼守住这三道关卡:

Gate 1(准入门槛层 - 非黑即白):只看基线。

逻辑极其简单:没有清晰的As-Is数据,直接打回。过了这关才能往下谈。在推行初期,会有高达40%的项目在第一层就被直接挡在门外,这一项在内部还引发了不小的反弹,但这正是倒逼整个组织走向务实和数据驱动的第一场博弈。

Gate 2(一票否决与战略加权层 - 决定生/死与优先级):

这一层分为两步:首先,看“价值真实性”和“技术风险边界”(一票否决),这两项如果算不清楚账或存在致命风险,后面的讨论就是浪费时间。通过后再看“资产积累性”和“变革深度”( 战略加权),这决定了谁排在前面,谁能拿到更多的算力、预算和高级工程师支持。通过Gate 1的项目,才会获得种子资金去做2-4周的POC试点验证。

Gate 3(执行策略层 - 决定怎么落地):

当前面的漏斗已经用POC数据证明了“该做、能做”之后,最后一关只看“组织承接力”。确认被冲击的岗位有没有安置方案?业务部门有没有拿出真金白银的激励措施来推广?确认“做了之后组织接得住”,才能全量上线。

五、AI-Native的实践:我们特意训练了一个“AI评审助手”

在AIO内部,龙哥一直强调的一句话:“一定要搞成 AI-native 的 AIO!”
如果我们天天喊着推动全公司的AI转型,自己办公室的评审流程和工作方式却还停留在传统的开大会、写Word、拍脑袋上,那还有什么说服力?
原文配图 9
所以以上说了这么多要求和维度,为了真正打消业务部门的顾虑,让他们在正式上会前有一个无压力的“模拟演练”机会,我们还把这套“三层五维度”的标准喂给了大模型,特意训练了一个专属的“AIO项目评审助手”。
它的定位非常明确:它是一个懂业务、务实、绝对中立的“协作同事”。它仅提供评审参考意见,绝不做最终的立项决策。
这个AI助手的核心价值在于:
结构化梳理项目:业务负责人只需要用大白话跟它聊自己的想法,AI会像教练一样主动追问:“现在的基线数据是什么?”、“省下的人力打算怎么安置?”
补齐评审材料:在多轮对话中,AI会敏锐地发现申报逻辑中的漏洞,并引导业务部门一步步补齐缺失的信息。
输出标准化报告:当对话完成,AI会自动生成一份符合AIO标准的标准化《模拟评审报告》,甚至会预测真实评审会上委员们可能发起的“犀利质询”。
业务部门可以在系统里和这个助手反复进行“模拟答辩”,直到五个维度都打磨得清晰透彻,再正式提交立项。这样不仅极大地缓解了大家对“评审”的恐惧感,也让每一次正式的评审会变得极其高效。

六、深水区洞察:为什么AI试点80%死于“组织”而非“技术”?

结合这套框架在内部的推演与业界的广泛调查,我们越发清晰地认识到了一个残酷的真相:
企业AI试点的成功与否,大约80%取决于组织层面的结构性问题,仅有20%是技术本身的问题。
原文配图 10
AI作为一种通用和放大性技术,其发挥作用的前提是企业具备适配的底层系统、数据基础和管理文化。以下是最核心、最致命的组织痛点:
流程未重塑,陷于“隐性知识”的黑盒
很多人把AI当成了旧版RPA(机器人流程自动化)的升级版,以为只要把大模型套在现有的工作流上就能提效。这是一种典型的认知误区。AI的真正价值在于端到端的流程重塑——它的目的是消灭原来的马车,而不是让旧马车跑得快一点。
现实是,企业中大量的工作流并没有清晰的文档记录(SOP),而是作为“部落知识”存在于老员工的脑海或非正式的沟通群里。如果不投入精力把这些隐性流程清晰化、文档化,AI就无法理解业务上下文,自然无法接管工作。很多试点项目没有明确要解决的具体痛点,纯粹是为了“搞点创新”而立项,最后只能凭“感觉”来评估成败。
数据碎片化,AI缺乏关键的“企业上下文”
大模型本身再强大,智商再高,如果缺乏企业内部的专属背景信息(Context),其实际效用就会大打折扣,甚至胡说八道(幻觉)。
今天企业AI的核心竞争力,已经不再是去纠结选哪家大模型公司的底层模型,而是组织能否突破内部的数据孤岛、打通不兼容的系统、理顺极其复杂的数据访问权限。组织是否搭建了内部的“上下文工程”平台(如MCP协议或数据湖),将正确的数据在正确的时机无缝喂给AI?没有这个基建,AI就是个聪明的瞎子。
上下认知脱节,员工被困在“没时间学习”的怪圈里
企业高管往往极力在台上呼吁推动AI,但在台下,却没有在日常工作中为员工留出哪怕一点点学习新工具的时间和容错空间。员工普遍的抱怨是:“我们每天都在救火,根本没有时间去学那些号称能帮我们省时间的工具。”
结果,原本旨在提效减负的AI,在落地初期反而成了压在员工身上的额外负担。研究显示,企业从早期AI工具中节省下来的时间,有53%被重新投入到了系统维护和建设中,而仅有不到29%真正用于员工技能提升。这种投资错位,加上员工担心“AI是不是来抢我饭碗的”防备心理,导致了严重的上下同欲脱节。

写在最后

回顾这三周艰难的框架落地与宣贯过程,最大的收获正如 Google Cloud 在最新的 DORA 报告中所总结的那样:
“最大的AI投资回报并非来自工具本身,而是来自对底层组织系统的战略性关注——包括内部平台的质量、工作流的清晰度以及团队的协同一致。”
AI转型的评审,本质上根本不是在评阅一份技术方案,而是在借此机会,逼迫一个组织想清楚——我为什么要变?我准备怎么变?旧的利益格局打破后,组织怎么接得住?在AI时代,技术从来都不是最大的挑战,人和组织的准备度才是。
如果你的企业也正处于推动AI转型的深水区,面对着满天飞的项目申请单不知道如何排兵布阵,希望我们的这些思考能给你带来一些实用的启发,也欢迎你借用这套“CIO视角的决策漏斗”,去打好内部的第一场组织博弈。