有一类文章的价值不在于”写了什么”，而在于它让你重新审视那些你已经习以为常的判断。钉钉匿名PM的离职记录《置身钉内》属于这一类。
7.5万字，不提供任何可复制的成功原则。它记录的是一组反复出现的结构性张力——无论团队怎么换、无论模型能力怎么提升，这些东西都在那里。作者称之为”常数”。
以下是我从这些常数中真正被击中的几个点，以及它们延伸出去的思考。
发心不是情怀。发心是优先级的底层算法。#
“发心”这个词在中文语境里已经被用烂了。它听起来像某种鸡汤——“做产品的初心”、“不忘初衷”。但《置身钉内》把它拉回到了一个完全不同的层面。
ONE的发心至少有四层：替用户减负、替钉钉做AI时代新入口、替组织聚人心、替商业消化token消耗。四层同时成立，互相冲突。作者的原话是：
“当一个产品的发心又多又没有主次的时候，就会成为一个贪心而焦虑的产品。”
这句话的锋利之处在于，它揭示了一个几乎所有团队都在犯、但极少有人能说清的错误：不是没有目标，而是目标太多，并且拒绝为它们排序。
把发心理解为”优先级排序的底层算法”之后，它就不再是一个只属于PM的概念。任何一个工程师在做技术决策的时候——选什么架构、抽象到什么程度、为哪些场景做容错——背后都隐含着某种发心排序。你以为你在做技术决策，实际上你在替产品回答”这件事到底为谁而存在”。
我之前写过”验证性功能不值得深度抽象，标杆性功能需要极致还原度，基础设施性功能才值得在架构上投入”。这三句话的本质就是在说：一个功能被创造出来的原因，直接决定了它应该被怎样实现。但大多数团队不会在动手之前问这个问题。他们直接跳到”怎么实现”，然后在一个月后发现方向错了。
分辨一个功能真正为什么而存在，是比”这个功能怎么做”更基础的问题。而这个问题在大多数技术评审中根本不会出现。
这让我联想到一个更广的视角：大公司做AI产品为什么总是看起来”什么都有但什么都不好用”？不是因为能力不够，而是因为发心太多。一个功能要同时满足用户价值、组织KPI、发布会演示、商业变现——四个目标本质上就不是同一个方向，但没有人敢说”我们这次只做其中一件”。结果是每个方向都做了60分，合在一起就是一个60分的产品。
这也是为什么独立开发者和初创团队在某些产品类型上能碾压大厂——他们的发心通常只有一层，不需要内耗。
已读功能不是UX问题。它是权力问题。#
《置身钉内》里关于”已读”的讨论是全文最精准的一段。
钉钉的传统站发信人（管理者）那边：我发的消息，我有权知道你看没看。ONE试图站收信人（普通员工）那边：我帮你过滤信息，让重要的浮上来。
这看起来是一个产品定位问题。但它背后有一个更根本的命题：每一个涉及信息分发的产品，都在用一个看似不起眼的UI决策替用户回答”权力在谁手里”。
推还是拉？按发送者的优先级排序还是按接收者的优先级排序？通知的触发条件由谁定义？这些不是设计偏好，它们是权力结构在界面层上的投射。一个按钮的位置就是一份政治声明。
再往下推一层。为什么微信没有”已读”？不是因为技术做不到，而是因为微信的产品立场站在接收者这边——我给你不回复的自由。但企业微信有已读——因为你进了组织，就不再拥有这种自由。同一家公司，两个产品，同一功能的处理方式截然相反。这不是巧合。
这个视角放到AI产品上会更有意思。当AI开始在组织内部接管信息分发——自动总结、自动过滤、自动优先级排序——它实际上在替组织重新分配”谁看什么、谁不看什么”的权力。AI代理的”智能排序”看起来是一个技术特性，但它其实在替产品回答那个老问题：你站在谁那边？
常数不是原则。常数的意思是，你解决不了它。#
《置身钉内》最让我觉得有价值的概念，是”常数”——那些无论团队多强、无论模型多好，都会反复出现的结构性张力。
模型能力快速提升，但产品形态进化速度远慢于模型——这是一个常数。AI要进入工作现场就需要上下文，但这些上下文所在的旧系统本身就是最大的摩擦力——这是另一个常数。组织里的人来了又走，信息的完整因果链只有留到最后的人能看到——这又是一个常数。
“原则”和”常数”的区别在于：原则告诉你可以做什么来改善局面，常数告诉你某些东西你永远无法消除，只能设计自己的系统去容纳它。
这让我想到一个几乎所有人都犯过的错误：把一个常数当成一个可以解决的问题去处理。需求在组织传递过程中必然变形——不是因为沟通技巧不够，而是因为每个接收端都自带解码器，把输入信号按照自己的KPI和认知框架重新解释。这不是执行问题，这是信息论层面的必然。一个人不可能完整地把自己的全部上下文传递给另一个人，组织更不能。
但大多数团队的做法是什么？开一个更详细的PRD评审会，写一份更长的需求文档。以为”更充分的信息传递”能解决信息必然失真的问题——这本身就是一个范畴错误。
常数不是要被解决的。常数是要被承认的。
承认了需求会变形，你的策略就不再是”更准确地传递需求”，而是缩短需求传递的链路、减少中转节点、让做决策的人直接接触原始信息。承认了旧系统会拖慢AI落地，你的策略就不再是”把旧系统全面改造”，而是在旧系统的缝隙里找到AI可以先独立运作的空间。
这些策略变化的起点，仅仅是把一个东西从”待解决问题”一栏移到了”给定条件”一栏。
最后一句话#
《置身钉内》的结尾，作者用茨威格自传的书名”昨日的世界”来形容这段经历。那个书名记录的是一战前已经不存在的欧洲。一个被寄予厚望、快速崛起、又迅速收缩的产品，配得上这个比喻。
但这篇文章真正重要的不是它的伤感。重要的是它提供了一种罕见的视角：站在废墟上看因果。 大多数产品复盘是在成功之后写的，隐去了运气，隐去了恰好做对但不知道为什么对的东西。失败记录保留了更多犹豫、代价、“当时觉得有道理但后来发现不对”的判断。这些东西才是经验本来的样子。
对于正在做AI产品的人，这篇文章的价值不在于提供了答案。它的价值在于提供了一组经过验证的问题——
你的功能到底为什么而存在？你的产品站在谁那边？你面对的东西，是一个可以被解决的问题，还是一个必须被承认的常数？
分清这三件事，大概已经解决了一半的问题。