当前时间: 2026-05-29 10:41:53
分类:办公文件
评论(0)
AI时代下的《启示录》读后感上面是《启示录》这本书的大概全览,没读过的话,可以大致看一下,然后我讲一下我的一些思考吧之前我用 AI 半天做出了一个产品,上架到应用市场,半天就被下架了。那是一个要处理用户上传私人数据的分析类应用。从想法到能跑起来、能演示、能点下”提交审核”,前后没花到一个工作日。我记得提交那一刻还挺得意的——这要放在三年前,光把功能搭出来就得找人、排期、联调好几周,现在我一个人一个下午就干完了。下架的通知是中午来的。后台那条状态从”审核中”直接跳成了一行红字。我盯着那行字看了好一会儿,手边的外卖都凉了——东西明明都跑起来了,演示视频都录好了,怎么连个上架都不让?我脑子里第一个冒出来的念头,现在想起来都有点脸红:”不就是分析点用户自己传上来的数据吗,至于吗?”正是这个”至于吗”,让我后来愣了很久。愣过之后我才明白,被下架其实算不上最丢人的事。最丢人的,是那个本该在我动手之前就问出口的问题——”这东西合不合规?我有没有权利这么去动用户的私人数据?”——我自己,一次都没认真问过。AI 替我解决了”做不做得出来”,我却顺手把”该不该做”这种底线判断,也一起塞给了它。然后理所当然地以为,能做出来、能提交,就等于能上。平台替我踩了刹车。但刹车本不该由平台来踩。那个该问”该不该”的人,从头到尾就该是我。我把判断外包给了”做得出”,又指望别人替我兜底。这恰恰是后来那本书,逼着我去面对的事。我栽的这一跤,不是个例。它只是一种失败。书里还写着另一种。二十世纪八十年代,《启示录》的作者 Marty Cagan 在惠普带过一个团队。顶尖的工程师,加不完的夜班,做出来的东西拿了一堆专利,连媒体反馈都不错。结果呢?用他自己在前言里的原话说:没人购买我们的产品。四十年后,2024 年,Humane 这家公司推出了 AI Pin——一枚别在胸口的随身 AI 设备,前 Apple 的团队,叙事讲得漂亮,发布会声量拉满。然后用户只问了一句话:我为什么不直接用手机?2025 年 2 月,HP 以 1.16 亿美元收下了它的技术和团队,而那枚 Pin 的大部分云端服务,在 2 月 28 日中午彻底停摆。我的下架和他们的”没人买”,其实还不是一种失败。他们好歹把东西堂堂正正卖到了用户面前,是被人嫌弃的;我连用户的面都没见着,就被平台一纸通知摁死在了门口——说出来更丢人。可不管栽在哪一步,缺的都是同一样东西:在动手之前,没有任何人停下来问一句”该不该”。AI 算得出市场有多大,算不出这东西到底该不该存在。这句话,是我花两天读完《启示录》之后,唯一想截图发出去的话。一、我带着 AI 的眼睛,第一次读这本 2008 年的书说来惭愧。《启示录》这本书我久仰大名很多年,一直没读。是最近我才花两天把它啃完。所以我读它的时候,脑子里装的全是 AI。每读到一处,我的下意识反应都是:”这个,现在 AI 几分钟就能搞定了吧。”读到做原型、快速试错那几章,我是真的有共鸣。Cagan 在书里反复强调:别一上来就写厚厚的需求文档、走那套瀑布流,要尽快做出能让人摸到、能拿去试的东西。我当时心想,这位 2008 年的作者要是看到今天,得多高兴——他推崇的”快速做出一个可试的版本”,AI 算是真给落地了,而且是人人都负担得起地落地了。可读到”评估产品机会””产品探索”这部分,我心里冒出来的第一个念头是:这活儿,AI 不也能干吗?我让 AI 去抓市场数据、估算市场规模、扒竞品的用户评价、定位用户痛点。它半小时就能甩给我一份看起来相当完整、相当量化的机会评估报告。图表、数字、结论,一应俱全。于是我得出一个结论:这本书教的东西,AI 基本上全包了。从”想清楚”到”做出来”,它一条龙全能替我干。AI 给我的那份”看起来很量化”的评估,从头到尾没有替我判断过一件事:这东西到底该不该存在,能不能合规地存在。一份看起来很量化的评估,根本不是判断。它只是把数据排得很好看而已。它告诉我市场有多大、痛点有多痛,却绝口不提”你凭什么去碰用户这些数据”。这本书一多半的篇幅,讲的其实是”克制”——先别急着造,先确认到底该不该造。而”克制”这件事,恰恰是 AI 唯一替不了我的部分。读到这儿我才明白:《启示录》压根不是一本方法手册。它是一本克制之书。我的下架,和书里惠普那个”没人买”的故事,隔着整整四十年,中间还隔着一整个 AI 时代。可我们栽的是同一个缺位:动手之前,没人问”该不该”。从 1980 年代的惠普,到 2024 年的 Humane,再到 2025 年的我——被裁掉的,自始至终是同一个岗位。它不在任何一张组织架构图上。过去,是”造得慢、造得贵”这件事在替它打工。成本和时间像两道闸,逼着你在动手之前先把账算清楚:这玩意儿真有人要吗?真合规吗?出了事谁扛?那个”慢”,本质上是一个不拿工资的产品经理,在你冲动的时候,悄悄替你拦下了一半的烂需求。在 AI 时代,”做得出”不再是一件好消息。它是最危险的信号。我们的直觉是:能力越强越好,做得出当然比做不出强。但你想想,过去”做得慢、做得贵”为什么反而是种保护?因为高昂的成本本身,就是那道逼你三思的闸。当 AI 把这道闸的成本一脚踩到地板、清零,它第一个干掉的,就是那个替你三思的隐形产品经理。于是结论变成了这样:能力越强,刹车越松,你反而越该慢。“做得出”这件事,在过去是要付出代价的,所以它值得高兴;现在它几乎免费,你要是还把它当好消息,就等于亲手拆掉了自己最后一道判断的防线。造得慢,是一个不拿工资的产品经理。AI 第一个裁掉的,就是它。而《启示录》整本书在干的事,说穿了,就是教你怎么把这个被裁掉的隐形产品经理——重新雇回来。二、AI 替我写、替我试、替我算,却把”担”留给了我我把自己这一年和 AI 打交道的过程捋了一遍,发现自己是一步步、心甘情愿地走进坑里的。一开始,我以为”造得出”就等于”能成”。AI 帮我把代码写出来、demo 跑起来,我就觉得这事成了一大半。后来我学乖了一点,知道光做出来不够,得测。于是我用 AI 一口气做了十个版本,反复试。我又以为”试得多”就等于”选得对”——版本越多,我离正确答案就越近。再后来,我连机会评估都交给 AI 了。它给我算市场、算痛点、算竞争,算得头头是道。我于是又以为”数据算清了”就等于”该不该做也清楚了”。三层台阶,我一级一级踩上去,最后一脚踩空——产品被下架,或者更常见的,做出来根本没人用。这三步,可以收成一句话:AI 替你写,替你试,替你算,却把”担”留给了你。写、试、算,分别对应可行性、可用性和价值评估,AI 都替你扛了大头。唯独剩下那个”担”字——该不该做、做错了谁来扛——谁也替不了你。写、试、算,这三刀 AI 都替你挨了。下面三章,我一刀一刀拆开看:哪些被它真便宜了,哪些只是看起来便宜了。AI 让写代码、搭 demo 这件事,几乎变成了免费。这是真的,我不抬杠。但你得分清楚,它便宜掉的,只是可行性里最低阶的那一段。而真正的、生产级的可行性,是另一码事:稳定性、数据质量、权限、合规、安全、成本、性能、组织能不能支撑、上线之后谁来运维、老数据怎么迁移……这一长串,AI 一寸都没替你省。过去,这些坎在立项阶段就会拦住你。你想做一个涉及用户隐私数据的东西,团队里多半有人会在第一次会上就问:”这个合规过得了吗?”成本和流程逼着你早早面对它。现在呢?AI 让你飞快地跑完了从想法到上架的全程,于是你一头撞墙的位置,从”立项第一天”挪到了”上架那一刻”——而这个时候,你的沉没成本已经比过去高得多了。AI 让我半天就把东西做完、提交上去。可”这么处理用户上传的私人数据到底合不合规”这道生产级的坎,AI 一秒钟都没替我趟过。它压根不在它的考虑范围里。上架半天,平台就把我拦了下来。涉及隐私、医疗、金融的应用,这个问题尤其要命。因为这类产品的可行性大头,从来就不是代码,是合规。而合规这东西,恰恰是那份”看起来很量化”的评估报告里,最不会主动提醒你的一栏。这里我得特别说明一句,免得把因果关系讲歪了:我被下架,证明的是”AI 没替我处理合规和责任边界”,不是“这个产品没人要”。后者得等市场投票才知道,而我连市场的门都没摸到。这是两种完全不同的失败,待会儿第五章我还会回来说它。这不是我一个人的倒霉。Gartner 在 2024 年 7 月有过一个预测:到 2025 年底,至少 30% 的生成式 AI 项目,会在 PoC(概念验证)之后被放弃。原因写得清清楚楚——数据质量差、风控不到位、成本失控、商业价值不清。注意,这是一个预测,不是已经审计过的事实,我不替它打包票。但它指向的那个规律,是站得住的:demo 容易,落地难。AI 让”做出一个能演示的东西”变得无比简单,却没让”把它真正落进生产环境”变简单哪怕一点点。所以下次 AI 帮你三下五除二搭好一个 demo,你先别急着高兴。问自己一句:AI 帮我省下来的那两周,是真的省了,还是只是把麻烦,挪到了上架的那一刻?四、AI 让你更快拿到版本,但判断哪一版能交给用户,还是你的事这一章我想先把书里那个最戳我的方法论拎出来。Cagan 在前言和第 22 章里反复讲一件事:做高保真原型,然后尽早地、反复地让真实用户去试用。这事在 2008 年是个奢侈品。你得找设计师做原型,约用户,跑一轮访谈,几周才转得过来一圈。绝大多数团队根本耗不起,所以书里苦口婆心地劝。今天呢?AI 几分钟就能给你一版。”反复试错”这件事,第一次变成了人人都负担得起的日常。AI 替你便宜掉的,是”做出一个可以试的版本”,而不是”替你完成那场真实的用户测试”。谁来试、试出来的信号怎么读、最后哪一版能真正交到用户手里——这些事情的成本,一分钱都没降。2022 年底开始,科技媒体 CNET 偷偷用一个内部的 AI 引擎写稿,发了 77 篇文章。后来东窗事发,他们做了内部审查,结果是:这 77 篇里头,41 篇需要更正——超过一半。有的是事实错误,有的是把别处的句子改得不够干净,踩到了抄袭的线。这件事是科技媒体 Engadget 报出来的。你看,AI 不是写不出文章。它的问题恰恰相反——它太容易写出”看起来很像一篇文章”的东西了。产出的成本被压到极低之后,真正变得稀缺的,是另一样东西:编辑判断。这事实对不对?这篇到底该不该发?读者知不知道这是 AI 写的?这几个问题,AI 一个都不会主动替你回答。CNET 栽的,远不止几个错字那么简单。它栽在:低成本的批量产出,悄悄把发布的门槛压低了,可事实核查、编辑判断、信息披露、读者信任——没有一样,跟着自动降下来。我读这条新闻的时候,后背有点发凉。这不就是我那个下架的应用吗——我也是被”AI 几下就给我生成出来了”冲昏了头,把”这东西到底该不该发出去”这一步,整个跳了过去。CNET 跳过的是事实核查,我跳过的是合规,本质是同一种侥幸。AI 能让我一天做出十个原型。但它定不了哪个原型真正解决了用户的问题,哪个只是看起来很完整、很顺手。做出十个版本,是 AI 的功劳。从十个里挑出那个对的——那是隐形产品经理的活儿,AI 没接这个活。所以每次我用 AI 哗啦啦做出一堆版本的时候,我都会逼自己停一下,问一句:我这是在用 AI 多试几个版本,还是在用”多试几个版本”,来逃避”我到底要哪一版”这个我不敢面对的判断?五、价值与担责:AI 替我算,却不替我判断,更不替我担责到这儿,前面那些被 AI 摊平的成本——低阶可行性、可用性验证——都已经摊平了。剩下唯一摊不平的,是价值。而价值的要害,过去我一直理解错了。我以为价值是”机器算不出来”的东西。错了。AI 能甩给你一份相当漂亮的机会评估,市场多大、痛点在哪、用户怎么评价,它都能给。价值真正的要害是:一份看起来很量化的评估,永远不是判断。它能告诉你市场有多大,可你要是追问它这东西到底该不该存在,它就答不上来了;再往下问一句出了事谁来签字,它躲得比谁都远。价值的核心是另一回事:在一堆不确定里拍下那个取舍,然后为后果负责。算,在这儿帮不上忙。这两件事,AI 都不沾边。Cagan 那个团队,技术越完整,处境越尴尬。因为他们做出来的东西再精致,也没回答那个最朴素的问题:用户为什么要它?这正是开场那个”没人买”的坑。Humane 的 AI Pin 也一样——能力、数据、声量样样不缺,可它没说清楚用户为什么要在手机之外,再多别一个东西在胸口。这里我得把两种失败掰扯清楚,别混成一团。Humane 是真刀真枪上了市,然后被用户判了死刑的。我那个应用连市场的门都没摸到,半路就被合规拦下了。一个倒在终点线后,一个连起跑都没跑成——可你要问他俩到底缺了谁,答案是同一个:那个本该在动手之前,问一句”该不该”的人。如果说 Humane 是价值没立住,那下面这个案例,讲的是价值的另一面:责任。2024 年 2 月,加拿大不列颠哥伦比亚省的民事裁决庭,判了一个案子,叫 Moffatt 诉加拿大航空(Moffatt v. Air Canada,案号 2024 BCCRT 149)。事情是这样的:一位乘客的祖母过世,他上加航官网咨询丧亲机票,网站上的聊天机器人告诉他,可以先买票、事后再补申请丧亲优惠。他照做了。结果加航的人事后告诉他:对不起,我们不接受事后补申。乘客把加航告了。加航在庭上的辩护很有意思——它试图把自己和那个聊天机器人切割开,言下之意是:那是机器人说的,不能算我们的承诺。裁决庭没买账。庭里认定:这个机器人是加航官网的一部分,乘客没有义务去判断官网上哪一块信息更可信、哪一块不算数。最后,加航被判赔 812.02 加元(其中票价差额 650.88 加元,利息 36.14 加元,裁决费 125 加元)。钱不多。但这个判决的分量极重:一家公司,要为自己网站上机器人给出的错误信息,以及用户因此遭受的后果,负责。你不能把责任和机器人切开。把这件事摆到每个想用 AI 做产品的人面前,那个最该问的问题就浮出来了——产品经理真正要问的,从来不是”这个模型答不答得上来”。而是:”它答错了之后,谁签字,谁兜底,谁去修那条出了错的流程?”这个问题,AI 永远不会替你回答。因为答案那一栏,签的只能是你的名字。回头看我那个下架的应用,我从头到尾就没想过这一层:万一它处理用户数据真出了岔子,砸下来的责任该谁接?我那时满脑子只有”能不能做出来”。平台那一刀,与其说是拦住了我,不如说是替我补上了我自己没签的那张字。道理说到这儿,得落地了。否则就成了又一篇”正确的废话”。我从《启示录》里——主要是讲”评估产品机会”的第 11 章——拎出两件工具,是我现在每次动手让 AI 造东西之前,都会先过一遍的。它就三个问题。我建议你真的把它做成一张能截图、能照着填的表,而不是看完就忘。判定规则很简单:三个问题里,只要有一个填了x ,就别让 AI 动手。第二问我想多说一句,因为它最容易自欺。我那个被下架的应用,事后老实拿这张表一填,第二问就是个大大的 x——把 AI 生成的那层分析包装拿掉,剩下的东西,几乎没有什么是只有我能提供的。当时我要是先填了这张表,根本走不到提交那一步。我认识一个人,手上有个挺漂亮的点子——”碰一碰社交”。两个人各自填好类似简历的资料,手机碰一碰,立刻算出彼此的社交匹配度,告诉你适不适合深聊、能不能做资源互换。这东西用 AI 做出来,真的很快。我问他为什么。他说,他卡在了责任清单的第一问上:他想不清楚,到底有没有人真的需要这个,还是只有他自己觉得酷。这件事我后来越想越佩服。在一个”做出来几乎不要钱”的时代,忍住不做,本身就是把隐形产品经理重新雇回来的样子。AI 时代最稀缺的能力,是想清楚之前先按住自己的手。快速做出来这件事,早就不值钱了。工具二:一张”Cagan 动作 → AI 时代改写表”《启示录》里那些经典动作,在今天该怎么用,又有哪些东西其实一点没变。我做了张对照表:这张表读下来,你会发现一个有点反直觉的规律:AI 改写的,全是左边那一栏的”做法”;右边那一栏”只能你来的判断”,它一个字都没碰,甚至因为做法变快了,判断的分量还更重了。最后,附一张生产级的核对清单。每一项,你都拿去问问 AI 给你的那个 demo:它碰过吗?数据质量、权限与安全、合规、性能与成本、组织与运维——只要有任何一项,AI 的 demo 压根没碰过,那它就还停在”低阶幻觉”那一层,离能上线差着十万八千里。读完《启示录》,我没觉得自己学到了什么新方法。AI 已经把书里大半的方法,做得比 2008 年快了不知多少倍。这本书写于 2008 年,可它真正在防的那个东西,要到 AI 时代才彻底暴露出来:当”造”变得几乎免费,那个曾经靠”造得慢、造得贵”替我们站岗的隐形产品经理,就被一刀裁了。从惠普到 Humane,再到我那个半天就被下架的应用——四十年了,被裁的一直是它。AI 裁掉了”造得慢”这个隐形产品经理。而《启示录》,是你能凭它,亲手把这个人重新雇回来的那张合同。下一次,在你点下”提交”之前——先把它请回到桌子对面坐下,问你一句:这东西,到底该不该做。
基本
文件
流程
错误
SQL
调试
- 请求信息 : 2026-05-29 16:44:28 HTTP/1.1 GET : https://www.yeyulingfeng.com/a/681811.html
- 运行时间 : 0.100797s [ 吞吐率:9.92req/s ] 内存消耗:4,743.03kb 文件加载:145
- 缓存信息 : 0 reads,0 writes
- 会话信息 : SESSION_ID=ab7a40fa680ab9b7425a1ca7ec70ae69
- CONNECT:[ UseTime:0.000528s ] mysql:host=127.0.0.1;port=3306;dbname=wenku;charset=utf8mb4
- SHOW FULL COLUMNS FROM `fenlei` [ RunTime:0.000699s ]
- SELECT * FROM `fenlei` WHERE `fid` = 0 [ RunTime:0.000342s ]
- SELECT * FROM `fenlei` WHERE `fid` = 63 [ RunTime:0.000347s ]
- SHOW FULL COLUMNS FROM `set` [ RunTime:0.000536s ]
- SELECT * FROM `set` [ RunTime:0.000209s ]
- SHOW FULL COLUMNS FROM `article` [ RunTime:0.000559s ]
- SELECT * FROM `article` WHERE `id` = 681811 LIMIT 1 [ RunTime:0.000444s ]
- UPDATE `article` SET `lasttime` = 1780044268 WHERE `id` = 681811 [ RunTime:0.003161s ]
- SELECT * FROM `fenlei` WHERE `id` = 64 LIMIT 1 [ RunTime:0.000243s ]
- SELECT * FROM `article` WHERE `id` < 681811 ORDER BY `id` DESC LIMIT 1 [ RunTime:0.000480s ]
- SELECT * FROM `article` WHERE `id` > 681811 ORDER BY `id` ASC LIMIT 1 [ RunTime:0.001270s ]
- SELECT * FROM `article` WHERE `id` < 681811 ORDER BY `id` DESC LIMIT 10 [ RunTime:0.000581s ]
- SELECT * FROM `article` WHERE `id` < 681811 ORDER BY `id` DESC LIMIT 10,10 [ RunTime:0.000685s ]
- SELECT * FROM `article` WHERE `id` < 681811 ORDER BY `id` DESC LIMIT 20,10 [ RunTime:0.000809s ]
0.102686s