4月6日,OpenAI发布了一份13页的政策文件《智能时代的产业政策:以人为本的理念》。其中最抓眼球的提议:政府补贴的32小时工作制,薪资不变,作为AI生产力提升的"效率红利"。

政策争论留给别人。真正的问题是——你的团队真的能用AI省下8小时吗?还是像大多数团队一样,省下的时间悄无声息地变成了更多的工作量?

时间去哪了:一个没人愿意做的审计

时间去哪了:一个没人愿意做的审计

OpenAI的提议有个前提:AI确实能大幅提升效率,足以支撑每周少干一天。但这个前提在大多数团队里从未被验证过。

实际情况是,AI工具省下的时间像漏水一样流走了。写代码快了两小时?产品经理立刻填满新需求。文档生成自动化了?团队开始要求更详尽的版本。效率提升被"做更多"吃干抹净,没人记得曾经省下来过什么。

这种吞噬如此隐蔽,以至于当你提议试行四天工作制时,管理层的第一反应是"我们哪有这个余裕"。

余裕明明存在过,只是被 scope creep(范围蔓延)消化掉了。

要试点32小时工作制,第一步不是说服老板,而是做一次诚实的时间审计:AI到底在哪省了时间,在哪没有。

效率红利的两种命运

效率红利的两种命运

OpenAI的文件里埋着一个有趣的词:"efficiency dividend"(效率红利)。这个词原本用在石油资源上——阿拉斯加永久基金把石油收益分给居民,让所有人共享资源变现的好处。

AI的效率红利理论上也该如此:技术提升的果实,以时间或金钱的形式回流给劳动者。

但目前的默认路径是另一种。企业把AI省下的时间重新投入生产,换取增长、市场份额、或者 simply more output(更多产出)。劳动者得到的是更满的任务列表,而不是更短的工作周。

这不是阴谋,是系统惯性。没有外部机制(比如政策补贴、工会谈判、或者公司主动选择),效率红利不会自动流向"工作更少"。

OpenAI的提议本质上是在说:如果市场不会自发分配,政府可以设计一个分配机制。32小时工作制+补贴,就是把"做更多"的默认选项,切换成"做更少"的实验选项。

你的团队能试点吗?一个自测框架

你的团队能试点吗?一个自测框架

政策层面的32小时制遥不可及。但团队层面的实验随时可以开始——前提是你能回答几个具体问题。

第一,AI在你团队的核心工作流中渗透率多高?如果只有20%的任务用到AI,省下的时间不足以支撑全天缩减。如果80%以上,才有讨论空间。

第二,省下的时间是否可聚合?AI帮你写了三封邮件、调试了一段代码、生成了一份报告——这些碎片时间很难凑成完整的一天。但如果AI接管了整个模块的开发或整类文档的撰写,时间块才够大。

第三,团队对"做更少"的接受度如何?有些工程师听到四天工作制会担心职业安全,有些会立刻开始规划副业。文化阻力往往比技术可行性更难跨越。

第四,度量标准是什么?如果试点32小时制,用什么指标判断成功?产出持平?员工满意度提升?离职率下降?没有清晰的目标,实验会在模糊中流产。

这个框架的残酷之处在于:多数团队做完审计会发现,自己离"效率红利"的门槛还差得远。

OpenAI的真正意图:一场关于分配的政治

OpenAI的真正意图:一场关于分配的政治

回到那份政策文件。32小时工作制只是其中一项提议, alongside robot taxes(机器人税)、national public wealth fund(国家公共财富基金)、portable benefits(可携带福利)、automatic safety-net triggers(自动安全网触发器)。

这些提议共享一个逻辑:AI带来的经济重构需要主动设计,不能放任市场自行演化。

这很符合Sam Altman的一贯立场。他多次公开谈论AI可能造成的就业冲击,并主张通过类似阿拉斯加永久基金的机制,让全民分享AI收益。32小时工作制是这个思路的延伸——不是等失业来了再发钱,而是提前用时间 Redistribution(再分配)来预防过度冲击。

批评者会说这是科技巨头的公关策略,用乌托邦愿景转移对当下问题的注意力。支持者会说,至少有人在系统性地思考分配问题,而不是假装一切都会自然解决。

两种解读都有空间。但文件本身提供了一个有用的概念工具:efficiency dividend。无论政策是否落地,这个词可以帮助团队和管理层讨论一个被回避的问题——AI省下的时间,到底归谁?

从政策到实践:一个产品经理的视角

从政策到实践:一个产品经理的视角

作为曾经的产品经理,我对这类政策文件的习惯性反应是:落地复杂度被严重低估。

政府补贴32小时工作制,意味着需要定义"AI驱动效率"的认证标准、防止企业套利、处理跨行业差异、协调税收和福利系统的联动。每一个都是硬仗。

但文件的价值不在于可执行性,而在于 framing(框架设定)。它把"AI与工作时长"从"会不会失业"的恐惧叙事,转向"如何分配收益"的设计叙事。

这个转向对团队管理者更实用。当你和CTO讨论试点四天工作制时,"OpenAI说应该这样"没什么说服力。但"我们来审计一下AI到底省了多少时间,再决定怎么分配"是一个可以操作的起点。

政策是别人的战场。审计是你能控制的第一步。

多数团队永远不会做这份审计。因为审计的结果可能证明,我们并没有想象中那么高效——或者证明,我们高效了,但选择把红利全部喂给了增长机器。

两种结论都不舒服。所以时间继续漏水,32小时工作制继续是别人的提议。

你的团队上周用AI省下的时间,现在在哪?