惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

MongoDB | Blog
MongoDB | Blog
B
Blog RSS Feed
MyScale Blog
MyScale Blog
M
MIT News - Artificial intelligence
H
Hackread – Cybersecurity News, Data Breaches, AI and More
J
Java Code Geeks
U
Unit 42
Blog — PlanetScale
Blog — PlanetScale
L
LangChain Blog
C
Check Point Blog
WordPress大学
WordPress大学
Last Week in AI
Last Week in AI
人人都是产品经理
人人都是产品经理
T
Tailwind CSS Blog
Vercel News
Vercel News
腾讯CDC
GbyAI
GbyAI
有赞技术团队
有赞技术团队
S
SegmentFault 最新的问题
H
Help Net Security
博客园 - 三生石上(FineUI控件)
D
DataBreaches.Net
Microsoft Security Blog
Microsoft Security Blog
小众软件
小众软件

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
企业AI验收的潜规则:2026年了,为什么90%的项目还在用Demo验...
Zoey · 2026-05-08 · via 人人都是产品经理

企业AI项目验收正在沦为一场心照不宣的表演。本文通过能源行业真实案例,揭示了80%的AI项目在验收后无人问津的残酷现状。从精心挑选的演示案例、38%的尴尬采纳率,到法务人员"敢不敢签字"的灵魂拷问,作者用亲身经历剖析了行业验收标准与真实价值间的巨大鸿沟,并给出了留存率、采纳率、工时对比三大硬核验收指标,为企业AI产品落地提供了破局思路。

去年年底,我参加了一个能源行业的AI项目验收会。

甲方五个人坐一排,乙方项目经理打开系统,挑了一份合同传上去,大屏幕上AI开始逐条审核——风险等级、问题描述、修改建议、法规引用,全出来了。画面很漂亮,逻辑也通顺。法务看了两眼点了点头。项目经理又换了一份设备采购合同,审核结果依旧干净利落。然后是技术服务合同,同样没什么问题。三份合同跑完,甲方分管领导说了句”可以”,会议结束,验收通过。

全程四十分钟。甲方没提一个刁钻的问题。乙方没出任何意外。

我坐在后排看完整场,心情很复杂。因为我知道一些这间会议室里没人会说出来的事情:那三份合同是乙方提前测了十几份之后精心挑出来的。甲方法务其实上个月就跟项目经理打过电话,大概知道今天会演什么。系统上线两个月了,日活不到5人。我看了眼旁边一个乙方的研发,他全程在低头看手机,可能这种场面他也看腻了。

这不是验收。这是一场双方配合默契的表演。

从2024年大模型进入企业到现在快三年了,我亲历或近距离观察过不下十个企业AI项目的交付验收。说个不好听的数字——真正在验收后还被业务部门持续使用的,不超过两成。剩下八成?验收报告写得漂漂亮亮,PPT上的数据都很好看,双方握手合影,然后系统就安静地躺在那儿,再也没人打开。

怎么说呢,这个流程做了几个项目之后你会发现它惊人地相似。验收前一到两周,乙方团队会进入一个内部流程——选Case。拿什么合同来演示?用什么数据来跑?哪个场景效果最好?哪个场景千万不能碰?这个过程极其认真,甚至比做产品本身还认真。有时候为了一个演示效果,技术会临时针对某份合同优化提示词,确保当天那份合同的审核结果”恰好”是完美的。我有一次在项目群里看到研发说了句:”这份合同别用,审出来第三条有幻觉。”然后那份合同就从演示列表上消失了。当时没人觉得这有什么问题。

甲方其实不傻。验收那天坐在会议室里的人,心里大概清楚这是演示不是实战。但他们有自己的压力——项目立项的时候汇报了领导,花了预算,半年过去了总得有个交代。验收不通过,下一轮追加预算批不下来,立项的人脸上也挂不住。所以大家心照不宣地把这场戏演完,各取所需。验收报告签了,款回了,乙方撤了,甲方在下次季度汇报里写上”AI XX项目已完成验收并上线”。至于上线之后有多少人在用——在大部分企业的考核体系里,”项目完成验收”就是终点,后面的事没人管。

这事我见多了之后,倒不觉得讽刺了,更多是一种心酸。不是哪一方在故意糊弄,是整条链上每个人都有自己不说真话的理由。

说说我自己的教训。

入行做AI产品的第一个项目,给一家能源集团做智能写作。内部测试跑了几轮,效果看着不错。第一次给客户正式演示,大屏幕上AI一条一条输出内容,格式漂亮逻辑通顺。我坐在那儿心想稳了。

研究员在安静地看,看到第六条还是第七条的时候手指点了一下屏幕——这个术语不对,”投资总额”和”项目总投资”在他们那差着几千万呢。

会议室一下子安静了。那种安静到现在想起来都不太舒服。

这还不是最扎心的。最扎心的是系统正式上线之后,我去后台拉数据:AI生成的内容,用户实际采纳率只有38%。就是说系统输出100段内容,研究员会把62段扔掉或者改得面目全非。有三个研究员在第二周之后就再也没登录过。

38%。如果按”传统”验收标准,这个项目是”通过”的——功能都实现了,系统能跑,演示效果也凑合。但你想想38%意味着什么?系统产出的东西有六成是废话。研究员宁可自己写,也不想花时间去修AI写的半成品。一套验收标准,能让采纳率只有38%的产品”通过”——那这套标准到底在验收什么?

三份精心挑选的合同和三百份真实业务合同之间,隔着一整个世界。Demo能蒙混过关,日活数据不会。

后来我花了差不多半年把这个数字从38%拉到72%。过程里踩了很多坑,但那些坑不是今天的重点。今天想聊的是——在这个过程中,我逐渐想明白了一件事:为什么整个行业都在”演”。

先说乙方,这个好理解。ToB的AI项目从商务到交付到验收,周期半年到一年,团队绩效、公司现金流全绑在验收节点上。验收不通过,项目经理年终奖没了,公司的应收账款变坏账。你让一个背着回款指标的人去做”客观验收”,这不现实。

甲方呢?甲方也有自己的难处。2024年之后几乎所有大中型企业都把”AI赋能”写进了年度战略,业务部门拿到预算上了AI项目,到年底总得有个交代。至于AI到底帮了多少忙——说实话,很多甲方自己也不知道该怎么衡量这件事。”好用”这个词太主观了,谁来定义?用什么尺子量?没人说得清。

最尴尬的是中间那层人。负责对接的项目经理或者业务骨干,他天天在用系统,最清楚好不好使。但你想想他的处境:跟上面说不好用吧,领导会问”那当初你为什么同意上这个”;跟乙方说不好用吧,关系搞僵了后面维护谁来做。我有次跟一个客户方的对接人喝咖啡,他说了句特别实在的话——”我觉得不好用,但我不知道不好用的标准是什么,万一其实就这样呢?”这句话让我沉默了挺久的。他不是不想说真话,是连衡量真假的尺子都没有。

说白了就是:当”项目验收”和”产品好用”是两个完全脱钩的考核指标时,所有理性人都会选择先确保前者。

那真正的验收应该看什么?

我后来在项目里推了三个指标,写进合同的那种。第一个是采纳率——AI输出的内容,用户不做大幅修改直接用的比例,阈值设在60%,低于这个数字验收不通过。这个指标不能用测试数据算,必须用真实用户的真实行为数据,连续跑两周。第二个是留存率——上线两周后还在用的人占比。第一周20个人用第三周只剩3个,那你系统就是没解决问题。第三个是工时对比——用AI前后完成同类任务的时间差。别笑,用AI反而更慢的情况真不少见,用户得花时间检查AI的输出,有时候还不如自己从头写快。

这三个指标一摆,很多东西”演”不了了。你可以选Demo的Case,但你选不了用户两周内的真实行为。

我第一次跟客户提这套方案的时候,对方的项目经理愣了一下。他大概没见过乙方主动要求用这么狠的标准来验收自己。我当时跟他说:你用功能清单验收,项目是”成功”了,但三个月后没人用,一期的钱白花了二期也不会有了;你用真实数据验收,可能今天数字不好看要返工两周,但你拿到的是一个真正能用的东西。他想了想,同意了。后来那个项目的二期合作确实签了。说实话我自己也没完全想清楚客户为什么续签——可能72%这个数字还行,也可能他们就是觉得这个团队至少不糊弄。

说个插曲。在拉采纳率的过程中我发现了一件反直觉的事——AI产品里特别值钱的一个能力是”能说我不确定”。

有一次试点阶段,系统碰到一条很冷门的知识产权条款。知识库里没有对应的法规,RAG检索勉强返回了一条沾点边的东西,大模型就硬着头皮编了一条审核意见。看着像那么回事——直到法务认真一查,发现引用的法规跟这个条款根本不是一回事。那个场面真的很窘迫。我当时坐在旁边恨不得找个地缝钻进去。

从那天起我定了一条死规矩:检索结果相关度低于阈值的,系统必须标”未找到强相关依据,建议人工重点审核”。不许生成似是而非的东西。

很多做AI产品的人觉得模型说”我不知道”很丢人。但在企业场景里恰恰相反。法务跟我说过一句话:AI告诉我这条它不确定,我顶多觉得这个地方我多看看;但如果AI自信满满给了个错的,我以后再也不会信它了。你想想,信任这东西毁起来比建起来快太多了。一旦用户形成了”标了不确定的我仔细看,没标的我可以信”这个预期,采纳率就会往上走。反过来,那些永远不说不确定的AI产品,用户踩了几次坑之后会对所有输出都打问号——包括那些其实对了的。

还有一个经验。38%那个数字出来之后,我做的第一件事不是调模型,是去客户现场坐了两周。每天搬把椅子坐在研究员旁边,看他们怎么处理AI的输出。

这个方法很笨,但看了两天就发现了后台数据里看不到的东西。

研究员写报告有自己的节奏和习惯。氢能项目他盯技术路线和经济性测算,光伏项目他看并网条件和土地政策。但系统不管什么项目类型,提示词用的都是同一套模板——输出的内容像论文摘要,什么都沾一点,什么都不深入。研究员看一眼就知道这不是内行人写的。

还有个更微妙的问题。AI两分钟生成一整章,研究员打开一看几千字呼啦一下全出来了,他反而不知道从哪看起。他的工作习惯是逐节打磨,一节一节确认。一下给一大坨,他觉得失控了。

更让我想了好几天的是一个研究员说的话:AI引用的数据我没办法确认来源,我不敢直接用——出了问题,报告上签的是我的名字,不是AI的名字。

这三个问题——术语不对、节奏不匹配、来源不可信——都是坐在旁边看出来的。在后台数据里它们长一个样,就是”用户没采纳”,你分不清为什么。但原因完全不一样,解法也完全不一样。后来回来之后把提示词按项目类型拆了三套,生成流程改成分章节确认,每条引用加了溯源标注。三个改动加起来,采纳率从55%跳到了72%。如果验收之前有人愿意花两天时间坐在用户旁边看看,很多问题根本走不到验收那一步。但谁愿意呢?项目经理忙着做PPT,研发忙着修bug。这个事只能产品经理去做。最笨但最有效。

往大了说一句。2024年是大模型进企业的POC之年,所有人在做概念验证。2025年是交付之年,项目开始上线。2026年应该是清算之年——那些”成功验收”的项目到底创造了多少真实价值?但据我观察这场清算还没真正到来。大部分企业还在用功能清单、Demo演示、测试用例通过率来验收AI产品。这些指标对传统软件够用——按钮在不在、流程通不通、数据存没存——但AI产品的输出是概率性的,同一个输入今天输出A明天可能输出B,你没法用打勾的方式验收一个非确定性的系统。

我觉得应该在功能验收之上加一层东西。暂且叫它”价值验收”吧——用户用不用(留存率),用户认不认(采纳率),用户省不省(工时对比)。这三个指标可以根据场景调整阈值,但不能没有。有人可能觉得把这些写进合同对乙方压力太大。我理解这个顾虑。但如果连乙方自己都没信心把这些做到及格线,那这个项目从一开始就不该签。更现实的做法是阶段性验收——不要等项目结束才验收一次,中间设两三个里程碑,每次跑一次真实数据。数字不好看没关系,早发现早调整,总比最后一天发现全完了强。

2026年了,大模型的通用能力已经很强了,主流模型之间差距越来越小。但企业AI项目的实际使用情况好像并没有因此改善。模型变强了,产品没变好用——中间断了什么东西,我到现在也不敢说自己完全想明白了。但有一件事我比较确定:在那间会议室里,甲方研究员看着屏幕上AI生成的内容,心里想的不是”这个模型用的是哪家的”,是”这段话我敢不敢直接放进报告里签字”。

这个问题,benchmark回答不了,Demo回答不了,验收报告回答不了。只有真实的使用数据能回答。

如果你也在做企业AI产品,建议你下周一上班打开后台,看两个数字:过去两周的日活是多少,采纳率是多少。如果你发现你的系统连这两个数字都没有——那问题可能比你想的要大。

本文由 @Zoey 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议