钉钉AI产品ONE项目的失败复盘引发行业热议，7.5万字的离职长文揭示了产品从300万DAU到最终拆解的全过程。文章聚焦四个关键问题：用户定义闭环、功能保护对象、迭代反馈来源以及AI提效的真正受益者。这不仅是一次职场文化的讨论，更是对AI时代产品经理核心命题的深度拷问。

上周，一篇7.5万字的离职长文《置身钉内》从阿里内网传遍全网。

作者是钉钉AI产品ONE项目的核心产品经理。她在文中复盘了这款产品从立项、冲到峰值DAU约300万，到最终拆分落幕的全过程，也写下了团队在这个过程里的真实状态。四天后，刚离职的钉钉副总裁马锐拉发文《置身钉外》回应，说自己看完”久久不能平静”。再之后，阿里合伙人委员会在内网表态：文中描述的管理方式”不是阿里文化该有的样子”。

网上的讨论大多停在职场内卷、大厂文化这一层。但我是做产品的，看完这件事，真正让我睡不着的不是加班，是另外四个问题。

这四个问题，每一个都可能正发生在你手上的项目里。

需要先说明一句：原文发在内网，流传版本的细节外界无法逐一求证。下面涉及具体管理行为的部分，都来自长文作者的自述和公开报道的转述，大家当一个案例来看，别当判决书。

一、产品死因的第一行：你的用户到底是谁

先看ONE是个什么产品。

按公开梳理，ONE是钉钉8.0推出的旗舰AI工作入口，目标是让工作信息从”人找事”变成”事找人”——AI主动帮你汇总消息、排好优先级，你打开钉钉，该处理的事已经摆在面前了。

听起来很性感，对吧？方向也确实前沿。峰值DAU到了300万，这个数字放在任何一家公司都不算失败。

但它还是被拆掉了。

长文里反复出现的一个困境是：这个产品，到底在为谁服务？

是普通员工？是老板？是发布会的观众？还是集团的AI战略叙事？

这不是抬杠。你仔细想，”事找人”这四个字，对员工和对管理者，是两个完全相反的体验——

对员工，理想状态是：AI帮我过滤噪音，把真正重要的事捞出来，我少看消息、少被打扰。

对管理者，理想状态是：AI确保我下发的每件事都精准触达，没人能装没看见。

同一个功能，一边想做减法，一边想做加法。产品每一次迭代，都在这两个用户之间摇摆。摇摆的结果就是：谁都没被真正服务好，但发布会上很好讲。

这是产品经理的第一课，老掉牙，但ONE用300万DAU的代价又讲了一遍：用户定义没闭环，后面所有的努力都是在精致地跑偏。 DAU可以靠入口位置堆出来，但”为谁创造了什么价值”这个问题，堆不出来。

下次立项，别先画原型。先回答：当员工的利益和老板的利益冲突时，这个产品站在哪边？如果答案是”都要”，那你大概率会得到一个”都没有”。

二、别再说”工具是中立的”了

钉钉的产品基因，长期偏向管理者——已读、DING、响应可见性，这些功能你我都不陌生。

单看每一个功能，都能讲出合理的故事：已读是为了沟通确定性，DING是为了重要事项不遗漏。但用脚投票的打工人都知道，同一个功能，站在不同位置的人，体验是完全不同的。”已读”天然服务于发信人，而职场里的发信人，多数时候是你的上级。

这件事在AI时代会被指数级放大。

因为AI接入的是组织的全量数据。谁的数据权限更高，谁能看见更多;谁能下发任务，谁就能让AI追踪得更细。AI不会天然站在弱势一方，它只会放大已有的权力结构。

如果一个”AI工作助手”做出来的效果是：老板更快知道项目卡在哪，系统更快提醒你有消息没回，周报更快被总结成风险项——那它当然也算”AI化”，但本质上只是一套更精密的压力传导系统。

所以做工具产品的同行，尤其是做B端、做协同、做AI办公的，有个问题值得写进PRD的第一页：这个功能，默认保护谁？

你不回答，产品会替你回答。而产品的回答，通常跟着付钱的人走。B端产品”买单的人和使用的人不是同一拨人”是老命题了，AI只是让这个命题的代价变得更高。

三、敏捷的反义词，不是慢，是交作业

长文里被讨论最多的细节之一，是作者描述的迭代节奏：据称上午提需求、晚上验收，版本”每日一包”，每天早晚会，Scrum打分，连调休都会影响评分。作者自述在这种强度下两次被送医。

这些细节真实程度如何，外界无法核实。但这种模式本身，很多大厂的产品同学应该都不陌生，只是程度不同。

我想说的是方法论层面的事：敏捷开发被用歪的时候，长什么样。

健康的敏捷，闭环是这样的：从真实用户那里拿到反馈 → 修正假设 → 快速验证 → 再拿反馈。 速度服务于学习，迭代是为了离用户更近。

病态的敏捷，闭环是这样的：权力中心提出关注点 → 团队当天做出可被验收的变化 → 汇报 → 等待下一个关注点。 速度服务于汇报，迭代是为了离老板的视线更近。

两种模式表面上都很快，日报里都很好看。区别只有一个：反馈的来源，是用户，还是权力。

AI产品尤其经不起第二种模式。因为AI Native真正难的部分——上下文工程、权限体系、数据链路、系统耦合——全是水面之下的底层工作，不是一天能做出”可验收变化”的东西。当迭代节奏被”每天必须有看得见的进展”绑架，团队只能把资源持续投向表面交互，水下的债越欠越多，直到产品被自己的地基拖垮。

如果你团队的日会，讨论的全是”明天给老板看什么”，而不是”用户昨天反馈了什么”，这就是最早的报警信号。

四、”AI提效”这个词，先别急着写进你的slogan

最后说一个有点扎心的观察。

这篇长文之所以引发这么大范围的共鸣，有个黑色幽默的原因：一个号称用AI帮大家提效的产品，背后的团队在用高强度加班的方式赶工。做提效产品的人，自己没有被提效。

这暴露了”AI提效”叙事里一直没人接的那个问题：效率提升之后，省下来的时间归谁？

AI让一个人能更快处理十件事，组织是让他早点下班，还是把任务加到五十件？AI能自动总结会议，会议会变少，还是会议记录变得更密集、更可追溯？AI能自动识别风险，是责任更清楚了，还是每个人都被提前标记、提前问责？

这些问题没有标准答案，但做AI产品的人不能假装它们不存在。因为答案决定了你的产品最终是被用户欢迎，还是被用户应付。一个让用户”自由度没增加、被管控的颗粒度却增加了”的产品，留存曲线早晚会告诉你真相——ONE的300万DAU没能救它，就是例子。

写在最后

《置身钉内》之后有《置身钉外》，之后无招走人，这件事大概暂时告一段落。各方说法谁对谁错，时间会给答案，我们也不必急着站队。

但对产品经理来说，这7.5万字里有一份不需要等待核实的礼物：一个完整的、罕见的、来自一线核心成员的失败复盘。大厂的成功学满天飞，认真写下来的失败太稀缺了。

把四个问题留给你，也留给我自己：

1. 你的产品，用户定义闭环了吗？利益冲突时，它站谁？
2. 你的功能，默认保护谁？
3. 你的迭代，反馈来自用户，还是来自权力？
4. 你的产品省下的时间，归谁？

AI把产品的技术范式掀了个底朝天，但产品经理的第一课一个字都没变：

先想清楚，你在为谁，创造什么价值。

共勉。