《置身钉内》是一篇7.5万字的离职记录。作者是钉钉的一名产品经理，在2025年加入了一个代号”ONE”的AI核心项目——无招回归后第一个主推的AI原生产品，DAU巅峰300万。她在十个月内经历了这个产品从立项、发布、共创到收缩的完整周期，是最后一个留下、最后一个离开的人。
这篇文章记录的，是ONE项目300天里反复撞上的同一类问题。不管团队多强、模型多好，这些问题都在。作者称之为”常数”。
理解这些常数，比学习任何方法论都更有用。方法论告诉你”可以做什么”，常数告诉你”哪些东西你永远消除不了，只能设计系统去适应它”。分不清这两件事，很多精力会花在错误的地方。
发心就是优先级排序#
“发心”这个词在中文互联网语境里已经被稀释得差不多了。它通常被理解为某种情怀——“做产品的初心”、“不忘初衷”——听起来正确但没法操作。《置身钉内》把它拉回到了可操作的层面。
ONE的发心至少有四层：替用户减负、替钉钉做AI时代的新入口、替组织聚人心提士气、替商业消化token消耗。四层同时成立，互相冲突。作者写道：
“当一个产品的发心又多又没有主次的时候，就会成为一个贪心而焦虑的产品。”
这句话指出了一个被普遍忽略的事实：多数产品的失败源于目标太多，且没有人愿意为它们排序。
从这个角度看，发心从PM专属的情怀概念，变成了在任何需要做取舍的时刻，替你把优先级排清楚的那个东西。一个工程师选择架构方案、决定抽象程度、为某些场景做容错而放弃另一些——这些技术决策的背后，全部藏着一个发心排序。一个功能为什么被创造出来，直接决定了它应该被怎样实现。
进一步区分，功能可以按发心大致归为三类：
- 验证性功能：为了验证某个假设而做，不应该深度抽象
- 标杆性功能：为了在发布会或关键场景中展示，需要极致的还原度
- 基础设施性功能：为了支撑其他功能长期运行，才值得在架构上投入
把三类功能混在一起用同样的精力对待，意味着团队从来没认真问过”这些功能各自为什么存在”。而这个问题在大多数技术评审中根本不会被提出。
这个视角也能解释一个常见现象：大公司做AI产品经常”什么都有但什么都不好用”。能力本身没有短板，但是发心太多。一个功能要同时满足用户价值、组织KPI、发布会演示、商业变现——四个目标的方向本来就不一致，但很少有人敢说”这次只做其中一件”。结果是每个方向都做了60分，合在一起还是一个60分的产品。
发心写在PPT里没有意义。它的实际作用，是在每次面临取舍时替系统说出那个”不”字。
你站在谁那边#
《置身钉内》里关于”已读”的讨论值得单独展开。
钉钉的传统是站在发信人（管理者）那边：消息发出去，发送者有权知道对方看没看。这种”强触达”逻辑深嵌在钉钉的身体记忆里。而ONE试图站在收信人（普通员工）那边：帮用户过滤信息，让重要的事浮上来。
一个按钮的位置、一个通知的触发条件、一个默认排序规则——这些看起来很小的设计选择，实际上都在替产品回答同一个问题：你站在谁那边。
推还是拉。按发送者的优先级排序还是按接收者的优先级排序。控制权放在消息的发出端还是接收端。这些设计选择，就是组织里谁说了算这件事，直接写在了界面上。
可以对比微信和企微对”已读”的处理。微信没有已读——产品立场站在接收者这边，给用户不回复的自由。企业微信有已读——进入组织后，用户不再天然拥有这种自由。同一家公司，两个产品，对同一功能的处理方式截然相反。“用户需求差异”解释不了这个现象——同一批用户，在家里用微信、在公司用企微。区别在于场景背后的权力关系变了。
当AI开始在组织内部接管信息分发——自动总结、自动过滤、自动优先级排序——它实际上在做一件更根本的事：替组织重新决定”谁该看到什么、谁不该看到什么”。AI代理的”智能排序”从工程上看是一个特性，从组织角度看是一次权力再分配。它的核心问题和技术无关：你站在谁那边。
常数不会被解决#
《置身钉内》最核心的概念是”常数”。
模型能力快速提升，但产品形态变得远没有模型本身快——这是一个常数。AI要进入工作现场就需要上下文（组织关系、消息历史、日程安排），但这些上下文所在的旧系统本身就是AI落地最大的摩擦力——这是另一个常数。组织里的人来了又走，完整因果链只有少数留到最后的人能看到——这又是一个。
这里有一个关键区分：原则告诉你”可以做什么来改善局面”，常数告诉你”什么永远不会消失，只能被容纳”。
分不清这两件事的代价很大。以最常见的例子来说：需求在组织传递过程中必然变形。根源在于每个接收端都自带解码器——把输入信息按照自己的KPI和已有认知框架重新解释。一个人不可能完整地把全部上下文传递给另一个人，一个组织更不能。只要信息经过人手传递，失真就一定会发生，谁都拦不住。
但大多数团队的反应是什么？更长的PRD、更详细的评审、更充分的对齐会。以为”更充分的信息传递”能解决信息必然失真的问题——这从根本上搞错了问题的性质，相当于以为把重力描述得更精准，物体就能飞起来。
一个东西从”待解决问题”一栏移到”给定条件”一栏，后续所有策略都会跟着变。
承认了需求会变形，策略就转向缩短传递链路、砍掉中转节点、让做决策的人直接接触原始信息。承认了旧系统会拖慢AI落地，策略就转向在旧系统的缝隙里找到AI可以独立运作的空间。
站在废墟上看因果#
《置身钉内》的结尾，作者用茨威格自传的书名”昨日的世界”来形容这段经历。那本书记录的是一战前已经不存在的欧洲。一个被寄予厚望、快速崛起、又迅速收缩的产品，配得上这个比喻。
结局本身不是重点。难得的是它提供的视角：站在废墟上看完整的因果链。
大多数产品复盘写在成功之后，隐去了运气，隐去了那些”恰好做对了但不知道为什么对”的决策。失败记录没有这个包袱。它保留了更多犹豫、更多代价、更多”当时觉得有道理但后来发现不对”的判断。这些东西更接近经验本来的样子。
这篇文章的价值在于一组经过验证的问题——功能到底为什么而存在，产品站在谁那边，面对的东西是一个可以被解决的问题还是一个必须被承认的常数。三个问题是同一件事的三种问法，答案得在每次做选择的时候自己给出来。