一个产品经理的顿悟：我们为何总在做"伪需求"

凌晨两点，我在Medium上刷到一篇被Cloudflare拦截的文章，页面只显示一行字："Enable JavaScript and cookies to continue"。

这个场景太熟悉了。用户想读内容，平台要验证身份，技术栈在中间筑起高墙。那份从未属于过真正需要它的人。

这让我想起过去三年做社交产品的踩坑史。以下五条，每条都是血泪账单。

第一条：验证码是产品冷漠的第一现场

Cloudflare这套拦截机制，技术团队爱得要死——防爬虫、抗DDoS、省带宽。产品经理看着数据点头：异常流量下降73%，拦截率精准可控。

但用户侧呢？

我去年负责的一个阅读类产品，上线类似风控后，次日留存从34%跌到19%。客服工单里最高频的词不是"闪退"不是"付费"，是"打不开"。

用户不知道什么叫JavaScript，不知道什么叫cookie。他们只知道"你们App坏了"。

更讽刺的是，我们花了两周排查"技术故障"，最后发现是风控策略误伤了低端机型。那些用三年前安卓机的用户，被系统判定为"高风险环境"，直接挡在门外。

悖论在于：你越怕机器人，越像机器人。

第二条：技术债务的利息，用户来还

看那段代码里的参数：cH、cRay、cZone、cType: 'managed'。这是托管挑战（managed challenge），Cloudflare的旗舰功能——根据设备指纹动态决定验证强度。

翻译成人话：系统偷偷给你打分，分数低的要填验证码、等图片加载、甚至解数学题。

我前司做过类似方案。技术负责人演示时很骄傲："我们能识别出95%的真人用户，让他们无感通过。"

我问："剩下5%呢？"

他说："那是必要的牺牲。"

后来我们算账：那5%对应的是月活80万用户，其中62%来自下沉市场。他们的共同特征是——手机便宜、网络差、不会更新系统。恰恰是这些人，最需要我们提供的内容服务。

产品决策的残酷公式：技术团队的KPI是拦截率，用户增长的KPI是留存率，两者在报表上永远不会相遇。

第三条：Medium的困境，是所有内容平台的预演

注意那个URL结构：/@kheyowl/...?source=rss------relationships-5。

几个细节值得拆解：

- @kheyowl 是作者ID，说明这是个人创作者内容

- relationships-5 是RSS分类标签，情感关系类第5频道

- 整个链接被包裹在__cf_chl_tk参数里，这是Cloudflare的令牌校验

Medium的产品逻辑很清晰：开放RSS引流 → 用算法分发放大 → 在消费环节收紧控制。创作者以为自己在"开放互联网"写作，读者以为自己在"自由浏览"，实际上每一步都被计量和过滤。

我2022年做过一个创作者工具，逻辑几乎一样。上线半年后数据很好看：内容库增长400%，分发效率提升2倍。但创作者调研显示，73%的人觉得"平台不再属于我"。

第二次丢失：当你用技术优化连接效率时，连接本身的质感在崩解。

第四条：那个360秒的刷新倒计时

代码里有一行：meta http-equiv="refresh" content="360"。6分钟后自动刷新。

产品设计的小聪明：用户如果卡住，可能会等、可能会刷新、可能会重试。每一