资料图。
置身钉内（上）
楔：钉钉是⼀只⾬燕
钉钉的动物园形象钉三多，是⼀只尖尾⾬燕，世界上平⻜最快的⻦类之⼀。它最特殊的地⽅在于，可以吃喝、睡眠、交配通通在空中完成；每年从⾮洲⻜经印度和东南亚，回中国北⽅繁殖，最多可以连续⻜⾏三百多天不落地。
尖尾⾬燕的拉丁⽂是apus apus，「pus」是「脚」的词根，「a」是「没有，否定」的词缀，所以⾬燕是字⾯意义上的「没有脚的⻦」。
我在 2025 年6⽉⼊职钉钉，⼊职即加⼊了作为核⼼保密项⽬的「O项⽬」。后来我才知道，「O」代表「ONE」。说起来我应该是ONE最晚进⼊的核⼼ PD，同时是最后⼀个留下并送⾛ ONE 的。我参与了从 0 到 1 的迭代，接触了从项⽬成型开始，到项⽬暮年运营期所有阶段，所有核⼼决策。也⽬送⾛了许多同事。
在钉钉⻜⾏了300多天，将满⼀年，最近也到了重新踩回地⾯的，离开的节点。
ONE是⼀个怎样的项⽬
ONE 的⽣命周期从 2025 年的 4 ⽉份开始孕育，8 ⽉ 25 ⽇发布会⾸次公开，DAU 巅峰稳定在 300 万左右，是⽆招回归后第⼀个主推的号称 AI 原⽣的项⽬ 。
影响 ONE ⼀系列产品决策的，主要是产品设计团队。ONE 的第⼀个⼀号位曾经是设计中⼼的负责⼈，这决定了ONE是⼀个设计基因极重、参与决策浓度很⾼的项⽬。
据我所知的，参与过ONE的产品设计是不少的，但ONE是⼀个流动性极⼤的项⽬。我来的第⼆周，我的设计 leader（也是第⼀个⼀号位）就离开了，第四周，联系并推荐我进组的师兄也被调离去了其他部⻔。
在 ONE 超过 3 个⽉的产品只有 3 个⼈，我是其中⼀个。
本⽂是⼀篇怎样的内容
本⽂将夹叙夹议地回⾸，这样⼀款曾经站在战略级⻛⼝位置的 AI 产品的开发往事。
我想记录⼀个 AI 产品从⽴项、发布、共创到收缩的过程中，理想如何被翻译成⽬标，⽬标如何被拆成需求，需求如何在组织⾥变形、落地，如何进⼊真实的⽤户现场⸺⽽退远镜头的景别，这⼀切究竟如何在钉钉、在时代的背景下发⽣。
「凡历术在于常数，⽽不在于变⾏。」编订历法，需要归纳规律性的常数，⽽不在于⼀味记载关注短期变化。感谢钉钉的⾼强度和快产品节奏，我在⼗个⽉内就完整体验了⼀款⼤⽤户量级的AI产品的⽣⽼病死。这实在是⾮常宝贵的经验。因此，这篇⽂档既想记录我这三百多天亲历的「变⾏」，也想尽可能凝练出⼀些在反复实践、受挫和复盘之后得到的「常数」。
当然，这⾥的「常数」可能不是把⼀个项⽬的成败归纳成⼏条规整、漂亮、让读者有充分获得感的原则。可能它只是⼀场现场经验留下的残余判断：在⾼速变化的 AI 产品开发中，哪些问题看似每次不同，其实反复出现；哪些冲突看似来⾃具体的⼈和事，其实来⾃组织、技术、商业与⽤户之间⻓期存在的结构性张⼒；哪些选择当时像偶然，事后看却⼏乎必然。
这份记录必不可能完全客观，我⽆法、也不愿意假装站在⼀个⽆菌的观察位上。很多判断来⾃我亲历的会议、争论、上线、复盘和失落，也来⾃我作为最后留下的 PD，对⼀款产品从热烈理想⾛向收缩的复杂感受。但也正因如此，它或许能保留⼀些正式复盘⾥不容易出现的东⻄：真实的犹豫、判断的代价、组织的惯性，以及⼀个产品⼈在现场⾥倍速积累的经验。
总之，希望这份记录能给所有正在、或希望从事 AI 产品开发的同事、同学与同道，提供⼀汪⼩⼩的经验池。若你能借此印证⼀些观点，或避开⼀些坑，那我便觉得略尽绵⼒，已经值得。
总之，请汉娜阿伦特和茨威格上我的身，请你和我⼀起翻开属于 ONE 的，昨⽇的世界。
FBI Warning （补充说明）
本⽂成⽂较⻓，7.5万字左右，三易其稿，是最近⼀两周⼯作间隙 + 紧急⼤熬夜写的；所以如略有前⾔不搭后语之处，敬请包涵雅正。
发⼼第⼀
发⼼是⾏为的内在动机与根本誓愿，是⼀切⼯作、⽣活、实践、修⾏的起点、⽅向和动⼒源泉。⼀个理性善良⼈的⾏为的发⼼，往往在帮助世界、物质回报和成就⾃我之间逡巡。在不同阶段，三种发⼼会有不同的优先级，促使⼈做出不同决策。
产品也有产品的发⼼。产品的发⼼就是它的发起⼈最原始的出发点，主要有以下⼏类：
解决某个尚未被解决的具体问题，
提升解决某个问题的效率，
服务好某个具体的⼈群，
推⼴某种理念，
销售某种资源，
等等。
举⼏个具体的例⼦：
1. 「淘宝」，发⼼是「提升解决商家对接客户销售地问题的效率」，也就是「让天下没有难做的⽣意」。
2. 「安缦酒店」，发⼼是「服务好度假的⾼净值⼈群」。
3. 「番茄钟」类产品，发⼼是「推⼴25min专注+5min休息的⼯作节奏的理念」。
上述列出的发⼼类型中，越靠前的越有可能诞⽣有历史价值的产品，因为发⼼越纯粹。虽然和⼈⼀样，⼀个产品也会混合以上多种发⼼，但⼤部分情况下，好产品只有⼀个主发⼼。⼤道⾄简，这也和许多投资⼈会提倡的「⼀句话说清产品价值」异曲同⼯。
当⼀个产品的发⼼⼜多⼜没有主次的时候，就会成为⼀个贪⼼⽽焦虑的产品。
贪⼼是七罪之⼀。什么都想要，容易什么都得不到。这⼀点在下⽂也会阐述更多。
环境背景
外部环境：2025 年的⻛向
2025 年中，整个⼤环境的 AI 产品的叙事正在换挡。
前⼀阶段，⼤家还在惊叹模型会聊天、会总结、会搜索。到了这⼀年，⾏业更关⼼ AI 能怎样调⽤⼯具、完成任务、进⼊真实⼯作流。
5⽉， Google I/O 2025举办，Google 在 Search 模块⾥强调 AI Mode，也在 Cloud 侧推出和增强了 Agent Development Kit、Agent Engine UI、Agent2Agent 等 agent 相关能⼒。它的重⼼已经从降低幻觉、回答问题的叙事，⾛向让模型进⼊更复杂的应⽤⽣态和⼯作流程。
7⽉，OpenAI 发布 ChatGPT agent，强调 ChatGPT 可以⽤⾃⼰的⼯具和计算机完成研究、预订、制作幻灯⽚等任务。
9⽉，Anthropic 发布 Claude Sonnet 4.5，重点也落在 complex agents 和 computer use 上。
钉钉有组织关系，有消息、⽇程、待办、会议、⽂档、审批等⼀系列产品。AI 如果要进⼊真实⼯作现场，钉钉这样的办公软件天然⽐⼀个单独的聊天机器⼈能满⾜⽤户需求。
这也是我当时被钉钉吸引的原因之⼀。银泰的经历让我切实意识到， LLM 在缺少 context 和不服务⽤户刚需时，有多鸡肋。
当然，优势也伴随着麻烦。钉钉不是⽩纸，它有多年积下来的产品逻辑、权限系统、端侧差异、多组织问题、客户定制和⽤户习惯。AI 要在这⾥做事，必须穿过旧系统的技术债。它站在⼀个很有吸引⼒的⻛⼝，但是取景再往远退⼀舍，就会发现，这个⻛⼝正处在⼀⽚难以改造的旧城中央。
内部环境：⽆招回归
另外，⽆招的回归本身也是⼀个⾮常奇特的变量。
⼀个⼈绕了⼀⼤圈，⼜回到⾃⼰曾经亲⼿点燃⽕种的迦密⼭。
来往失败后，⽆招带着⼏个⼈退到湖畔花园，从⼀⽚败局⾥做出钉钉。那⼏年，DING、已读未读、企业通讯录、审批，把钉钉从微信的阴影⾥硬⽣⽣拧将出来。那些功能后来被很多⼈批评为强管理、强控制，但在当年，它们确实回答了企业⾥最朴素也最焦虑的问题：我说的话，对⽅到底看⻅没有；我交代的事，到底有没有往前⾛。
更具体⼀些，解决了管理者的问题，解决了⼀个企业⾥愿意付钱的⼈的问题。
⼀个产品经理最难摆脱的，往往不是失败，⽽是成功。因为失败会留下伤⼝，⽽成功会留下⼿感。
钉钉早年的胜利，给⽆招留下了⼀套很深的身体记忆：站在发信⼈⼀侧，替组织争取确定性，⽤强触达把事情往前推。这套记忆后来也进⼊了ONE。为什么卡⽚⾥的消息⼀定要算已读，为什么系统要主动把事推到⽤户⾯前，为什么钉钉总忍不住替组织催促⼈⸺很多答案，都可以回到这⾥。
但2025年4⽉的⽆招，已经不是 2014 年湖畔花园⾥的⽆招。
他曾经离开钉钉，被调离⾃⼰⼀⼿做⼤的产品；也曾经离开阿⾥，去⽇本做了「两氢⼀氧」。那个项⽬没有跑出来。⼀个⼈最耀眼的战功留在过去，新的创业⼜未能证明⾃⼰，这时候再蒙旧主召回，很难只是⼀次普通任命。更何况召他回来的⼈是在他职业⽣涯⼏个关键节点上反复出现的学⻓，像命中有⼀根透明⽽柔韧的⻥线，把他从阿⾥第⼀位实习⽣、淘宝搜索、来往、钉钉，⼜牵回钉钉。
创⽴钉钉，被迫远⾛重回再挂帅。
此⼈此景，似曾相识燕归来。
Stay Hungry, Stay Foolish。⽆招的钉钉签名⽤它，钉钉的⽂化衫印它，在内部外部讲话，他也在寻找精神偶像的寄托时，每每提到那个男⼈⸺乔布斯。
乔布斯讲「stay hungry, stay foolish」的出处，是 2005 年斯坦福毕业典礼演讲。他讲到⾃⼰的辍学，讲到去印度学禅修、学字体课，讲被苹果赶⾛，讲感到死亡临近；最后说起《全球概览》封底上的⼀张乡间⼩路照⽚，底下印着 Stay Hungry, Stay Foolish。他把这句话送给毕业⽣，也像是在给⾃⼰⼀⽣盖印：不要太快餍⾜，不要太早聪明，保持不满，保持探索。
⽆招身上也有这种叙事的诱惑。创⽴钉钉，⼜离开钉钉；出去折腾⼀圈，再被召回旧地。⼀个⼈骤然发现命运之书被⻛吹开到和偶像相似的⼀⻚，很难不教⼈动⼼、疑⼼这是命运的召唤。
不过乔布斯离开苹果以后，做了 NeXT 和 Pixar。NeXT 商业上并不耀眼，却带回了苹果后来操作系统的⻣架；Pixar 则已在外部世界证明了⾃⼰。
⽆招回钉钉时，⼿⾥只有商业结果存疑的 HHO。它更像⼀次不⽢⼼的出⾛。证明他仍然想做事，出去转了⼀圈却没有带回更多筹码。背上背着的还是已经⻓出半刃铜锈的朴⼑。
身后是淘天的旧梦，来往的败绩，钉钉的胜利，HHO 的空响；眼前是 AI 重新洗牌的机会，时代重新开局的诱惑。⼀个⼈半⽣的伤⼝和功业，忽然都指向同⼀个⽅向，便很容易⽣出⼀种近乎宿命的确信。
ONE 后来的许多⽓味，都可以从这⾥闻到：它急着做成新⼊⼝，急着证明钉钉没有⽼，急着把 AI 落到消息、⽇程、审批和组织关系⾥；同时，它也带着旧钉钉的⼿感，带着发信⼈⽴场，带着强触达，带着把事情往前推的固执。
也正因为如此，ONE 这个项⽬本身，对他有⼀种特殊的吸引⼒。
我忍不住现象，在 25 年初，也许还在⽇本，也许他在⻅吴妈前，也在镜前反复练习和⾃问：当年我⽤钉钉把企业协作从微信嘴⾥抢出⼀⼝事业来；⼗年后，AI 要重写办公软件，我怎么带领团队，再搞⼀波⼤的？
镜⼦⾥的⼈脸上写满野⼼，也写满迫切和焦虑。后来的很多设计和争议，皆源于斯。
个⼈背景
最美逆⾏者
我在去年六⽉来到钉钉。
在那个节点，很多朋友开玩笑说我是「最美逆⾏者」。原因是，四⽉初⽆招回归后，雷厉⻛⾏地举⾏⼀系列措施：⼯时调整⸺提前到9点上班、开固定晨会晚会、午休缩短、周末单休，再兼全员Python考试，节假福利削减，部分职级以上薪酬调整，还有要求不私下加微信、需要说「对不起我只⽤钉钉」等等，组织整体在⼈⼝净流出。
岔开⼀句：这个⼈⼝净流出的数据结果，可能也是组织需要的，尽管流出的原因值得斟酌。伴随着流出数据的是⼤家对新⼊职钉钉的同事的同情和打趣，是就业者对钉钉的规避（并⾮虚⾔，君⻅各社媒劝退贴）（不过删帖公关也快，能不能⻅，要看⼿速），是钉钉像孔⼄⼰⼀样⾛进咸亨酒店，空⽓⾥就弥漫着快活的⽓氛。
收回⸺总之，现在回想起来，那时种种debuff，重峦叠嶂，但由于更在意具体做什么事情，以⾄于我对这⼀切毫不敏感，在当时有其他明显更好条件的offer的情况下，跳上轻⾈，平薪平职来了钉钉。
前情结算
在钉钉之前，我在银泰⼯作了⼀年多。也是做AI产品，做了银泰喵街app⾥的AI导购「喵街答答」和⼀些其他相关的AI服务⸺可以理解为银泰版淘宝问问（现 「AI 万能搜」）。为什么来钉钉呢？⼀⽅⾯，彼时正值银泰出售，新东家是传统企业，对AI和产研的投⼊逐渐不明；另⼀⽅⾯，银泰的⼯作实践也让我深刻意识到⼀件事，就是LLM有效服务成⽴的条件有两个，⽽银泰彼时的环境条件都不那么具备：
1. 【必要条件】⾜够的数据基建和context；
2. 【充分条件】最好⽤户想要消费的对象本身，就是LLM⽣产的产物。
智能是平权的，但是 context 是不平权的。
有context，才能判断⽤户的背景和偏好，才能提供⽤户想消费的商品/服务/内容。
其次，⽤户在电商零售场合最终想要获得的是「更好」或「更有性价⽐」的商品，LLM只是⼀个路径，在对⽐多种路径的性价⽐和给⽤户带来的损耗/收益⽐的平衡上，就会⾮常如履薄冰。电商的本质是「商」，是商品，是把渠道对接到销售⸺AI可以加速、或者优化这个本质的体验，但不会取代或者动摇这个本质。
⽽钉钉不同。
AI⼀定会颠覆⼈们组织办公的⽅式，如果跟不上，钉钉必然⾯临淘汰凋亡，此诚危急⽣死存亡之秋也。不过，挑战伴随着机遇⸺因为从这条思路出发，整个即时通讯的牌桌也有重新洗牌的可能。
学徒
虽然就从⼯作时间性价⽐和⼈性化程度⽽⾔，钉钉都不值得看好，但在⾯试的过程中，我觉得我有望在钉钉好好的学到⼀些东⻄。
⼀⽅⾯，在来到钉钉的那个节点，我⾃认为有⼀些审美，但苦⼿于总感觉还不能很好地把眼睛、⾆头上的审美，转化到⼿上，真正成为创造⼒和⽣产⼒。⼊职时招我的 +1 是设计出身，他给我的感受是，他有这样的⼿，以及他不吝让我从他身上好好学到这部分。
其次，更重的原因是，⽆招确实是⼀个超级产品经理型CEO。
当时的我，跟过⼀些leader，也⾃⼰做过⼀些⼩产品，但始终没有在⼀个⾼压⾼强的环境下，学徒式的学习过。
关键词「学徒」。
做产品和做菜、做⼿⼯⼀样，是⼀⻔⼿艺。有⼀个综艺叫《⼀饭封神》，⾥⾯许多厨师，流转于许多⽶其林三星的后厨，积累经验，最终的梦想是独当⼀⾯成为⽶三的主厨，或者开⼀间⾃⼰的餐厅。做产品也⼀样，在各个⼤中⼩司流转，学到本领，最后在哪⾥栖身独当⼀⾯，或者⾃⽴⻔户。
钉钉的⾯试流程很快，⼏乎就是⼀周之内，还包含了⼀个做⼤作业的周末。当时的最后⼀⾯就是⾯⽆招。
可能超级产品经理型的CEO都是这样⸺后来认识了在理想⼯作过的朋友，他们告诉我，产品经理去⾯理想，也要做⼤作业，也要过范皓宇和李想。
和⽆招的⾯试，让我产⽣⼀种强烈的直觉，钉钉或许是我的VEA（⾹港⽶三，《⼀饭封神》评委Vicky主厨的餐厅）。它迷⼈的地⽅不只在于昂贵、精致、难进，⽽在于它代表了⼀种⾼压、严苛、以及⾮常私⼈化的创作现场。那是⼀个后厨式的⼯作环境，⼀个主厨把⾃⼰的审美、野⼼、控制欲和成就欲，全部压缩进⼀套系统⾥，然后要求每个进⼊其中的⼈，都先接受这套系统的重⼒。
很多⼈警告过我他在指导产品⼯作过程中的暴虐⸺这点在我正式⼊职钉钉之后，也有所领略⸺但在那次⾯试中，他更多是以⼀种温和的态度，表达出和对⼈快速判断的能⼒和对产品的偏执的理想主义。
⾯试前半段聊得很顺。我们谈了我在银泰的经历，谈使命感，谈我学习 AI 的背景，也谈到本科⼼理学。直到聊⼤作业，我刚解释到「没有完成家族组织」的部分，⽆招就皱眉打断了我。
钉钉⾯试前要先完成的那份⼤作业，题⽬是「族谱上钉」。要求描述得⽐较模糊，⼤意是：把家族成员拉进钉钉，建⽴⼀个 6 ⼈以上的族谱组织，让他们在上⾯真实活动，并基于体验给出产品⻅解。
坦⽩说，这件事我没有真正完成。
我家⾥⼈⽐较少，能真正使⽤钉钉的⼈更少，⽆法满⾜「6 ⼈以上家族组织」的要求。不过我想，做这个作业核⼼是考察我的产品洞察，敏捷响应，和纳投名状。所以我做了代偿的证明⼯作：那个周末我去本地图书馆查阅真实的⼤型族谱，⽤表格和⽂档为别⼈的族谱做编撰和数字化；联系专⻔做族谱⽣意的商家，调研商业链条和可能的产品⽅向；也动员朋友上钉钉，搭了⼀个出境旅游前事项沟通的朋友组织。
这些⼯作不算少，我觉得也证明了我的⼯作能⼒，并纳上了投名状。
他反复追问：为什么做不成？
⽗亲家还有⼈吗？⺟亲家还有⼈吗？外公外婆还在吗？真的找不到了吗？真的凑不⻬六个能上钉钉的家⼈吗？
⼀系列低宜⼈性的问题，换个环境可能被投诉到政府⼯会。
在反复追问确认我的显示情况确实凑不⻬后，他沉默了⼤概⼗⼏秒，然后开始讲 2014 年他刚做钉钉时的经历。
彼时的钉钉也没有办法证明⾃⼰的价值，没有成熟产品和市场共识，只能⼀遍遍⻅客户、确认需求、陪笑脸，先承诺、再把东⻄做出来。⼤概就是典型的 「fake it until you make it」：在没有路径的时候，先把⾃⼰推到必须兑现的位置上。
最后，他给我的判断是：我的「学术底⾊」太重。
我⾄今仍不完全认同他的判断，也认为这是⼀种对⼈的服从性⾼于对⼈的能⼒的考察。你可以说这是挑选理想主义伙伴，也可以说这是PUA；可以说这是创业精神，也可以说这是权⼒关系下的过度索取⸺说到「PUA」，后来他还问了我的婚姻交友情况，以及问我创业有没有做好抛弃这些的准备。
不过，总之，这次⾯试确实引发了我的反思。
我并不完全同意⽆招说的，理想主义者就是在看不到希望时，也要坚持往⼀个⽅向做。不是所有事情都应该靠意志⼒硬推，也不是所有不计成本都值得赞美。但我还是被某种信念系统吸引了。我有时候着迷于那种经验事实上成⽴，但我不能从原理上解释它的东⻄，⽐如宗教。它们未必严密，甚⾄充满问题，但它们能组织⼈群意志和塑造现实。就像索罗斯的「反身性」原理：市场上的信念⾜够强烈时，会反过来介⼊现实，改变参与者的预期、⾏动和资源分布，最终让现实朝着信念本身靠拢。
「族谱上钉」也是这样，看似荒诞，但却有它实际的⽤途。换位思考，⽤最奚落的⼈际关系来类⽐，站在王伦的⻆度，让林冲上⼭前纳投名状，也是他最低成本判断和提前沟通上⼭后的⼯作模式的⽅式。
最后他还是通过了我的⾯试。
总之⸺在换⼯作之际，我最⼤的憧憬可以聚合到三个关键词上：⼀是context，⼆是主动服务，三是学徒。他们分别是我认为LLM有效服务成⽴的条件、我⼀直想实现的产品形态、和我渴望获得的阶段性成⻓的环境。
对于我这种⼀个逐 context （或者说数据）和产品⼯作⽽居的游牧⺠族来说，钉钉似乎都是⼀⽚应许的迦南，是撒⻢尔罕。
ONE 的发⼼
叫「ONE」的产品有很多，⽐如同为效率应⽤⽅向的 Google ONE，或者韩寒其实也有⼀个 app 叫 ONE，slogan 是「复杂世界⾥，⼀个就够了」。
ONE 的愿景发⼼，和所有叫「ONE」的产品⼀样：「all in ONE」，所有⼯作都在⼀⻚内处理。
更具象地拆，可以分成⼏层。
第⼀层，是⽤户发⼼。钉钉⾥的⼯作信息太散，群聊、待办、⽇程、会议、⽂档、审批各管⼀段，⽤户每天靠⾃⼰的记忆和注意⼒，把它们勉强串起来。ONE 想解决的是这个问题：让重要的事⾃⼰浮上来，让⽤户少⼀点遗漏，少⼀点翻找。
第⼆层，是产品发⼼。钉钉需要⼀个 AI 时代的新⼊⼝。它不能只把 AI 做成聊天框，也不能只把 AI 藏在各个⽼功能⾥。ONE 要把钉钉已有的消息、⽇程、待办、会议、⽂档重新摆⼀次，让外界看⻅：钉钉不是旧办公软件，它还能重新组织⼯作。
第三层，是组织发⼼。⽆招回归后，钉钉需要⼀场新的战役来聚⼈⼼、提⼠⽓、改形象。ONE 承担了这个角⾊。它既是产品，也是旗帜。旗帜能聚拢⼈，也容易把太多东⻄都挂上去。
第四层，是商业发⼼。AI 要消耗 token，模型能⼒也需要场景消化。这个阶段有点像发动机刚被发明出来，全世界都在找哪⾥可以装发动机。钉钉有⼤量⼯作场景，如果 AI 真能帮⽤户提升效率，当然是⽤户、产品、集团三⽅共赢。
这些发⼼若再压缩，可以归成⼏条：解决深度⽤户⼯作信息爆炸的问题，提升⼯作效率，更好地服务 KP ⼈群，销售 token 资源。哪怕最后⼀条是从集团使命出发，也有它⾃⼰的顺理成章。刚有了发动机，世界当然会寻找发动机的⽤武之地；如果它确实让⻋跑得更快，让船⾏得更远，那就是完美共赢。
所以 ONE ⼀开始就不是⼀个发⼼单纯的产品。它既想替⽤户减负，也想替钉钉换代；既想证明 AI 能进⼊⼯作流，也想证明钉钉还能站在下⼀代办公⼊⼝上。这⾥⾯有理想，也有指标；有⽤户价值，也有组织意志。
后来很多问题，都可以从这⾥追溯：ONE 究竟先服务⽤户减负，还是先服务发布会表达？先做所有⼈的⼊⼝，还是先做少数深度⽤户的真需求？先让事被看⻅，还是先让事被做完？
这些问题，在「发⼼」章⾥只是种⼦，到了后⾯的「定位」「设计」「⽤户」「敏捷」，它们会⼀层层萌芽、抽条、⻓叶、开花，结出完整的产品果实。
定位第⼆
如「发⼼」章所述，ONE 最吸引我的地⽅，在于钉钉丰饶的数据⼟壤，以及「主动服务」这个产品理念。
但发⼼只是起念，是⻢丁路德⾦的「I have a dream」，发散，抒情。⼀个产品真正进⼊开发，要回答的不是「想做什么」，甚⾄不是「要做什么」，⽽是「先做什么」。
所以，发⼼之后必须有定位。
如果把⼀个产品从虚到实的过程，⽐作拾柴点⽕，发⼼是选柴，定位就是捆柴的绳。柴选得好，只说明有得烧；捆不好，设计进来就是到处点⽕，这⼀丛，那⼀丛，看着热闹，⻛⼀吹就散。⽤户⽤不上、记不住，团队也徒耗⼒⽓和信⼼。
ONE 后来的许多问题，表⾯上出在设计、⽤户反馈和开发节奏⾥，根却埋在更早的定位问题：到底为谁服务，在哪个场景⾥⽤，解决什么价值，⼜凭什么由钉钉来做。
本章先不急着讲具体功能。我们先回到产品落地的第⼀步，看烧起 ONE 的这把柴⽕，最初究竟是怎样被捆起来的。
什么是产品定位
产品的定位其实可以拆为⼀系列关键的产品策略，⼀系列彼此解耦的主观选择和假设。
有的假设是客观题，有的则是主观题。主客观之间的底层差异在于，客观题是可以通过物理规律验证的，⽽主观题则符合索罗斯的反身性定律⸺好⽐股票市场，多数⼈的信念会反向影响现实。客观题到了⼀定阶段可以证伪，⽐如⾏业垂类⼩模型；⽽主观题⽆关真伪，纯粹是品味和选择，⽐如：
苹果选择闭源，安卓选择开源，ChatGPT、⾖包选择⼤ DAU，Anthropic、Manus 选择⾼净值塔尖⽤户，闭源还是开源，DAU还是塔尖⽤户⸺都没问题，都是选择，想清楚且⾛到底，都有可能成为开宗⽴派的现实。反过来说，如果⼀直在多种底层策略的判断上逡巡不定⸺那么从⽤户侧看来也会不伦不类，产品迭代起来鸡⽝不宁。另外从资源效能和团队信⼼⻆度出发，也是极⼤的浪费。
更具体地，要说清产品定位，需要明确回答四个问题：
1. ⽤户定位⸺\"为谁\"
1. ⽬标⽤户是谁？不是谁？
2. ⽤户的关键特征是什么（规模、⾏业、⻆⾊、习惯）？
2. 场景定位⸺\"在哪⽤\"
1. ⽤户在什么情境下想到这个产品？
2. 是⾼频⽇常⼯具，还是特定场景的解决⽅案？
3. 价值定位⸺\"解决什么问题\"
1. 产品提供的核⼼价值是什么？
2. ⽤户原本愿意花费多少钱/时间/其他资源，来达成这种价值？
4. 竞争定位⸺\"为什么是我们\"
3. 和替代⽅案相⽐，差异化在哪？
4. 这个差异化是否可持续？
当这些问题能够⼀句话说清时，产品就有了清晰的定位。
ONE 的产品定位
⽆招在 2025 年 4 ⽉ 1 ⽇回归钉钉， 8 ⽉ 25 ⽇开了第⼀次产品发布会，版本8.0，主题「蕨」。
按照第⼀次发布会的⼝径，ONE 是「钉钉⾯向 AI 时代打造的、以 Agent 驱动的⼯作信息流」。更详细的阐释是：ONE 是⼀次试图把群聊、待办、会议、⽂档、表格等分散⼯作信息重新组织起来的尝试⸺让 AI 不只是被动回答，⽽是主动替⽤户发现、整理和推进⼯作。
我们当时的 slogan 叫，「让『⼈找事』变成『事找⼈』」。
按照上述四个定位问题，来整理 ONE 的定位，⼤致如下：
然⽽，分析是清晰的、指⽇可待的，现实却往往是泥泞的、出乎意料的。就像项飙在《跨越边界的社区》中写道：「不管是⼀个⼈还是⼀个⺠族，发展主要来⾃不断的探索，⽽不是事先⼀揽⼦的设计。」
2025 年，正值 LLM 从 demo ⾛向真实⼯作流动荡⽽迅猛的上升期，能⼒令⼈兴奋，但稳定性、评测、成本、延迟、操作权限、⽤户隐私等等都还是⼀团草莽，没有成熟机制可以参考模仿。
同时，钉钉作为企业协作产品，本来就天然同时服务组织中多组相对⻆⾊的⽬标、管理者和员⼯、发信⼈和收信⼈，如何在相对⻆⾊中设⽴公平范式，还在探索期；⽽ ONE ⼜承担了对外宣发、对内集团指标、对客服务、商业化探索、及产品形象创新换代的多重⽬标，⽆法像⼀个独⽴创业产品那样，看住⼀个窄切⼝慢⼯打磨。
ONE 看似是⼀个很清楚的产品：⼀个 AI ⼯作信息流，⼀个专属⼯作秘书，⼀个让事找⼈的⼊⼝。但越往下做越会发现，它真正的难点不是功能实现，⽽在于要在⼀块⼩⼩的移动端屏幕上，同时回应管理者对全局掌控感的渴望、员⼯对信息过载的抗拒、以及AI对「什么值得我关注」这⼀判断本身所携带的权⼒属性。⼀个「让事找⼈」的⼊⼝，⼀旦运⾏起来，就不得不替组织回答：谁的事算「事」？在谁的优先级序列⾥插队？AI替谁节省时间，⼜替谁增加可⻅度？ 更深处，LLM 的不确定性让这些张⼒被急剧放⼤。当模型幻觉可能出现在审批意⻅、周报总结、跨部⻔同步中时，「秘书」的可靠性不再是技术指标，⽽变成了组织信任问题。成本约束要求我们对每⼀次「主动推送」精打细算，可重要信息恰恰可能因为⼀次节省资源的静默⽽被错过。隐私边界在多⻆⾊环境中没有明确标线：为员⼯提供更好的上下⽂，往往意味着让更多数据对模型可⻅；⽽向管理者透明化过程，⼜可能滑向微观监控。 总之，ONE 不是先定义好再执⾏的产品，⽽是在多⽅⽬标拉扯、技术草莽与现实泥泞中，⼀边建⽴判断⼒⼀边⻓出来的⼯作界⾯。
所设想的典型⼯作场景
在场景定位上，ONE 的核⼼假设⾮常纯粹：⽤ AI 帮⽤户整理⼯作并重新排序。团队并没有把功能零散地扔给⽤户，⽽是紧扣着职场⼈⼀整天最⾼频、最容易产⽣信息焦虑的三个特定时间节点，拎出了三段式的「时间线场景」：
场景⼀：⾼压之后的「补课与跟进」（信息堆积场景）
这是职场⼈最常⻅的痛点。当你开了⼀个两⼩时的⻓会，或者半天没看⼿机，再次打开钉钉时，⾯对的是⼏⼗个群⾥炸开的海量未读消息。此时⽤户的核⼼诉求是「快速赶上进度」。ONE 的场景定位就是在这个瞬间充当智能过滤器，不让⽤户逐条去翻聊天记录，⽽是把堆积的信息⾃动排好优先级，像呈送摘要⼀样让⽤户⼀⽬了然。
场景⼆：下班前的「查漏补缺」（收尾复盘场景）
在⼀天⼯作即将结束、准备下班的节⻣眼上，⽤户需要有⼀种「今天的事情都交代好了」的确定性。ONE 在这⾥的定位是安全⽹。它会启动「已读不回」的智能提醒，防⽌你遗漏重要客户或⽼板的信息；同时，它会把今天所有群聊⾥的⾦句、核⼼技术结论、重⼤业务决策进⾏汇总总结，让⽤户⽓定神闲地完成今⽇闭环。
场景三：晨间的「排兵布阵」与「发现」（开启新⼀天场景）
这是⽤户每天早上开启⼯作前的准备阶段。ONE 会在清晨为⽤户梳理好这⼀天的整体⼯作待办、准备好即将开始的⽇程，做好优先级的智能排班。在这个场景的尾端，产品还⻓出了⼀个具有前瞻性的「发现」功能⸺AI 会根据⽤户的⽇常⼯作上下⽂，主动推送你可能需要阅读的学术 Paper、竞品动态或⾏业新闻简讯，作为开启⼀天的认知燃料。
这三个场景在底层是⾼度⾃洽的，它们本质上都是在⽤户最需要组织⽣产⼒的时候，⽤ AI 的「事找⼈」去对抗⽆序的信息重⼒。
2025 年 9 ⽉ 25 ⽇，OpenAI 推出了同样主打「主动服务」的 ChatGPT Pulse：
Pulse 宣称打破了传统的「⼈问 AI 答」的被动范式，通过理解⽤户在 Google 全家桶上的⽇程、邮件等上下⽂，利⽤ AI 在⽤户熟睡的深夜进⾏异步研究，在清晨为⽤户呈上⼀套由 5 到 10 张视觉卡⽚组成的「Today's Pulse」早报。
Pulse 的出现，印证了 ONE 团队对于「清晨沙盘+主动发现」的场景直觉，是站在全球 AI ⽣产⼒⼯具前沿的。
两个影响⽤户定位的关键决策
有两个影响后续⼀系列设计开发的问题，在产品定位这个阶段就埋下了祸根。这两个问题都是⽤户定位的⽭盾，分别是：
⽼板 v.s. 员⼯
在钉钉上，⽼板和员⼯是截然不同的画像。
1. ⽼板，或者说管理者，是⼯作的发起者，需要对接更多的员⼯，督办、催办员⼯完成任务；他们有⼤量的⽇程，他们处理员⼯发起的审批，给员⼯布置待办。
相应的，员⼯是承接⽅和任务的完成⽅。他们⼀⽅⾯，打卡考勤，接受⽼板的任务和监督，向⽼板提出审批请求，完成⽼板的待办，另⼀⽅⾯，他们需要真正去填报表、写⽂档、联系客户。
举⼀个更有画⾯感的例⼦：员⼯给⽼板发语⾳消息的⽐例，是⽼板给员⼯发语⾳消息的零头。
⾯对这两种不同的⽤户画像，先服务好谁的诉求，必须有所取舍。
ONE 的服务对象，究竟是⽼板还是普通员⼯，是管理者还是被管理者，其实都有各⾃的理由。
先说服务员⼯。
前⽂已经说了，ONE 的⽬标是服务⼤ DAU 且⾼频的⽤户操作。如果只服务管理者这样的「塔尖」⽤户，就达不成给发现带量，或者卖 tokens 的⽬的。
另外，企业购买⼀个 SaaS 产品的本质，是为了更好地组织和管理⾃⼰的员⼯，确保每个员⼯可以上下⼀⼼，更⾼效地完成任务，达成组织⽬标。仅服务管理层，价值太薄。
那为什么⼜要服务⽼板呢？
做产品⼀⽅⾯看⽤户要什么，⼀⽅⾯看我们有什么。
2025 年 7 ⽉ 9 ⽇，⻜书开了发布会，重推 Aily（⻜书的 AI 助理）。会上谢欣借讽「某 app 上最多的数据就是各种打卡」，⼒陈⻜书才真正重视⽤户在办公场景中的信息流转和知识沉淀，更适合 AI 时代。
确实，钉钉早期推出已读未读，重搞 DING、考勤打卡、审批流等品，就是依靠服务企业管理层的监控和管理需求起家。钉钉的⽂档表格知识库是标准品，但是在⻜书出现后，历史上⻓期有⼀段时间，这些品的基建和交互体验都是弱于竞对的。
同时反向来说，由于如上的产品特性，制造业、传统企业、以及更多没有很强知识管理诉求的企业，会选择钉钉；服务好这部分企业，⼜让钉钉不断朝着这些企业需要的⽅向进化。由此形成了⻜轮。
钉钉上的信息枢纽，绝⼤多数还是管理层，他们有最多的 IM消息，⽇程，待办，审批。
ONE ⽬标对标⾼级机要秘书的职能：解决信息过载，让组织中的重要事项不再遗漏，通过智能排列⼯作信息的优先级，来节省⼈的精⼒、注意⼒。在封闭开发过程中我还开过玩笑，以后宣传⼝径就⽤「ONE 彻底治好了我的⼯作 ADHD」。
在钉钉，究竟谁有这么多⼯作需要批阅处理？
那也就是⽼板们了。
到这⾥，产品定位似乎被逼进了⼀个⻆落。
从产品⽬标⽽⾔，似乎应该服务钉钉的所有⽤户；但从交付的维度⽽⾔，⼜要从⽼板们服务起。那么，我们也就只有⼀个指望，就是通过⽼板 KOL 们的带动，让越来越多的员⼯⽤户，可以并愿意在钉钉处理所有的⼯作内容，并且把越来越多的信息沉淀到钉钉上。放眼同时期钉钉开始在做的录⾳卡硬件 A1，也都是为了协同完成让信息上钉更加⽅便容易的⽬标。
在初始定位的构思中，⽤户究竟是普通员⼯还是⽼板的问题，始终没有闭环。
但是事情总不能⽆休⽌地讨论下去，我们就这样，带着⼀盒薛定谔的⽤户出发了。
发信⼈ v.s. 收信⼈
钉钉和微信最⼤的区别是什么？
微信的⽴场是「收信⼈」。为了保护收信⼈的不被打扰，微信可以克制地不做已读未读，不做强触达。⽽钉钉的基因，从诞⽣的第⼀天起，就是永远站在「发信⼈」⽴场、为「发信⼈」所驱策的。
在进⾏ ONE 的产品讨论时，这个点也被反复提及，具体会在下⾯「设计」第三章，讲「已读」的时候细讲。
如果说有三种产品经理类型：布道者型/服务商型/朋友型，他们分别可以对应乔布斯，⻉尼奥夫，和雷军，那么⽆招是典型的第⼀种，⼀个极具煽动⼒的典型布道者。当他在会议室⾥讲到⼗年前如何顶着压⼒做 DING、做已读未读时，你⼏乎能从那些话语碎⽚⾥，看到⽼钉钉⼀以贯之的权⼒美学⸺站在发信⼈⼀侧，替组织争取绝对的确定性，⽤强触达把事情硬⽣⽣往前推。
在企业协作的⽣态位⾥，发信⼈的诉求，往往与管理者的控制欲和对确定性的焦虑⾼度咬合。管理者购买钉钉，核⼼痛点是消解「我说的话，对⽅到底看⻅没有；我交代的事，到底有没有往前⾛」的确定性焦虑。
这套身体记忆是如此成功，以⾄于它不可避免地流淌进 ONE 的⾎液⾥。
为什么卡⽚⾥的消息⼀定要算已读？为什么系统要主动把事情推到⽤户⾯前？为什么 AI 忍不住要替组织去催促个体？很多看似属于交互细节的争论，答案都可以回到这个原点。
然⽽，ONE 从概念阶段开始，就试图去承接⼀个宏⼤的、甚⾄带有平权⾊彩的 AI 愿景：通过「事找⼈」来帮员⼯减负。这就让 ONE 必须去⾯对组织中硬币的另⼀⾯⸺收信⼈，同时也是普通员⼯，或者说沉默的⼤多数。
这就带来了⽤户定位上的第⼀个内在张⼒：⼀个产品如果⻣⼦⾥流淌着「发信⼈⽴场」的强控制基因，它的功能设计和算法逻辑就会不⾃觉地倾向于催办、督办和绝对触达；但它在对外叙事和价值承载上，却⼜试图去扮演⼀个体贴「收信⼈」、帮收信⼈过滤噪⾳的超级秘书。
这种基因与愿景的底层拉扯，让产品在定义「我到底在为谁说话」时，从⼀开始就埋下了失焦的隐患。
当 AI 成为发信⼈的超级代理⼈，⾃动整理出待办、未读并呈现在移动端时，收信⼈（普通员⼯）感受到的并不是「智能的平权」，⽽是「被凝视的加剧」。AI 削弱了员⼯在⼯作流中⽤于喘息的「⼼理缓冲带」。普通员⼯变成了系统内的沉默⼤多数，他们的反抗通常极其隐蔽⸺⽐如在社媒上写劝退帖，或者在实际使⽤中寻找各种⼿段去糊弄和规避这个随时会跳出来的 AI 界⾯。
竞争定位⸺\"为什么是我们\"
I. 为什么是钉钉
ONE 的竞争定位，不能只看「谁也在做 AI 助⼿」。如果只是⽐模型能⼒、对话体验、⽣成质量，钉钉并不⼀定天然占优。真正的问题是：在 AI 时代，钉钉凭什么继续成为⼯作⼊⼝？
这⾥可以看 Stack Overflow 的曲线。ChatGPT 出现之后，Stack Overflow 的提问量急剧下滑。这张图对所有⼯具型产品都是⼀个提醒：当 AI 能直接给答案时，⽤户不⼀定还会回到原来的社区、流程和⼊⼝。过去积累起来的内容、关系和使⽤习惯，并不会天然构成护城河。它们可能反过来成为被 AI 抽象、吸收和绕过的对象。
对钉钉来说，挑战也是类似的。AI 不是给旧产品加⼀个聊天框，⽽是在重新分配⼊⼝。⽤户未来要完成⼯作，未必⼀定先打开某个应⽤、进⼊某个⻚⾯、点击某个功能。他可能直接对 AI 说：帮我总结会议，通知相关⼈，⽣成待办，更新项⽬进度，提醒我明天跟进。这个时候，谁掌握组织上下⽂、谁能调⽤真实权限、谁能完成闭环，谁才有资格成为⼊⼝。
钉钉的优势正在这⾥。它有组织关系，有消息链路，有⽇程、⽂档、会议、审批、待办，有企业通讯录和真实⼯作流。它不只是⼀个信息容器，⽽是企业协作的操作现场。理论上，ONE 可以利⽤这些上下⽂，把 AI 从「回答问题」推进到「理解⼯作」和「推动协作」。
钉钉来做这件事，有⼀个⾮常强的理由：它有真实⼯作现场。
⼀个普通 AI 助⼿很难知道组织⾥谁和谁有关，哪条消息重要，哪个会议有后续，哪个任务真的会影响项⽬。钉钉知道。它有通讯录，有群聊，有⽇程，有⽂档，有审批，有会议，有待办，有企业⾥的关系和流程。
这些是钉钉的优势。
但这些也是钉钉的重量。多组织、权限、历史链路、端侧差异、客户定制、旧交互习惯，都会变成 AI 产品的成本。越想进⼊真实⼯作流，越要⾯对这些东⻄。
我们也和⼀些⼤客户聊过，想看 ONE 的能⼒能不能覆盖他们已有的任务⼯作台和定制⾯板。结果很快发现，两者并不完全匹配。⼤客户要的是贴着⾃⼰业务⻓出来的东⻄：⾃⼰的流程，⾃⼰的字段，⾃⼰的任务⾯板，⾃⼰的管理动作。ONE 要做的则是⼀个⾯向所有钉钉⽤户的轻⼊⼝，不是专属钉式的定开功能。
这带来⼀个很现实的问题：钉钉是 SaaS，ONE 却带着很强的 To C ⼊⼝想象。
做得太⼴，就只能抓通⽤痛点；通⽤痛点⼜容易不够痛。做得太深，就会变成客户定制，失去全局⼊⼝的意义。ONE 卡在中间：它想成为所有⼈的⼊⼝，⼜很难替任何⼀类⼈把深问题做透。
II. 为什么是 ONE⸺或者说，为什么不得不⽤ AI
讨论 ONE 的竞争定位，不能只问「为什么是钉钉」，还要问「为什么是 ONE」。
钉钉有组织关系，有消息、⽇程、会议、待办、⽂档、审批，这些确实是它做 AI ⼯作⼊⼝的底⽓。但 ONE 并不是从零开始争夺⽤户。它⾸先要⾯对的竞争对⼿，恰恰是⽼钉钉。
⽤户已经有⾃⼰的⼯作路径：消息去消息⻚看，⽇程去⽇程⻚查，审批去审批中⼼批，待办去待办列表处理。
这个路径未必优雅，却⾜够熟悉。对很多⽤户来说，旧系统的最⼤优点不是先进，⽽是可预期。⼊⼝在哪⾥、红点怎么看、消息点进去会发⽣什么、审批点同意后是什么结果，⽤户⼼⾥有数。
所以如果⽤户在⽼钉钉⾥依靠「⾁眼扫视、⼿动标记、特意置顶」就能应付⽇常⼯作，他们就绝不会付出注意⼒和信任成本去迁移到⼀个新卡⽚流上。 ONE 必须解决⼀个「不依靠 ONE，⽤户在⽼钉钉⾥就算⽤断⼿也⽆法解决」的场景问题，才能击穿这⾥的迁移成本。
这⾥其实有三层迁移成本。
第⼀层是⼊⼝迁移。⽤户原本打开钉钉，第⼀反应是看消息⻚。ONE 如果要成为新⾸⻚，就要让⽤户相信：从这⾥开始，⽐从消息⻚开始更省事。
第⼆层是⼼智迁移。⽼钉钉是按⼯具分⼯：消息、⽇程、审批、待办，各⾃有边界。ONE 是按事情重新组织：哪件事重要，哪件事该看，哪件事该跟。这个⼼智更先进，但也更不稳定，因为它要求⽤户相信系统的判断。
第三层是责任迁移。⽼路径⾥，⽤户⾃⼰决定什么时候点开消息、什么时候进⼊会话、什么时候处理审批；ONE 主动把事情端到眼前，等于提前改变了⽤户和⼯作的距离。系统越主动，⽤户越会问：你凭什么现在推给我？我看⻅之后，会不会⻢上承担责任？
这个**「不依靠 AI 就⽆法解决」**的场景到底是什么？
⽼钉钉的局限（旧范式的死⽳）： 传统的 IM（消息流）是⼀维的时间线线性结构。当⼀个⽤户⾯临50个活跃群聊、每天上万条信息时，⽆论他的⾁眼有多快、操作多熟练，他也只能「⼀条⼀条地看」。在旧系统⾥，信息是「平铺直叙」的，前线 BD 聊出的⼀个重⼤客户痛点，和群⾥的⼀句「收到」、「哈哈」，在 IM 界⾯上占据的空间和红点权重是完全⼀样的。
⾮AI⽆法解决的场景：⾼密度的「⾮线性逻辑缝合」。 ⽐如你在7⽉3⽇遇到顾家家居的痛点：前线销售和供应链的协同，消息散落在「顾家⽣产群」、「顾家交付群」、「顾家销售群」等5多个不同的群聊⾥。原本⽼钉钉做得再好，员⼯也必须切换5个窗⼝，⽤⼤脑进⾏⼈⾁记忆、联想、拼凑，才能发现「哦，原来⽣产群⾥提到的延期，是因为销售群⾥昨天客户改了需求」。 这种跨群聊、跨时间、跨⽂档的「上下⽂⽹状逻辑缝合」，在⽼钉钉⾥，⽤户就算⽤断⼿，也只能靠⼤脑⾁搏。 只有通过基于 ONE 的 LLM推理，才能做到「把散落在不同时空碎⽚⾥的冰鞋线索，⾃动编织成⼀条线送给⽤户」。
这些才是 ONE 相⽐⽼钉钉可能成⽴的地⽅。
如果 ONE 只是把⽼钉钉⾥已有的东⻄换⼀种样式摆出来，⽤户很难迁移。因为原路径虽然旧，却已经够⽤；新⼊⼝若只是更好看、更聪明⼀点、更主动⼀点，不⾜以抵消迁移成本。尤其对企业软件来说，「够⽤」本身就是很强的惯性。
这也是 ONE 的竞争定位中最容易被低估的⼀点：它不是在和⼀个空⽩市场竞争，⽽是在劝⽤户离开⼀个他们已经习惯、已经会⽤、虽然抱怨但仍然依赖的旧系统。
所以，「为什么是 ONE」的答案不能停在「因为钉钉有数据」。数据只是资格，不是胜势。ONE 必须证明：它不只是钉钉旧能⼒的⼀次重新摆盘，⽽是真的解决了⽼钉钉解决不了、或者解决得太费⼒的问题。
换句话说，ONE 的竞争对⼿有三类：除了外部的两类⸺⻜书、企业微信这样的办公 SaaS 软件，和各种 AI Agent；还有内部的⽼钉钉：这是更深的⼀层，要和⽤户已经形成的⼯作习惯竞争。外部竞争决定钉钉为什么要做 AI，内部竞争决定⽤户为什么要从 ONE 开始⼯作。后⼀件事，⽐前⼀件事更难。
动态变化的定位与阶段⽬标
在整个开发周期中，定位和对应⽬标多次阶段性地标调整过，每次调整，都对应着⼀些不得不解决的现实问题。
最早摆在团队⾯前的，不是某⼀种具体形态，⽽是⼀个很难同时满⾜的三⻆：⼴⼤基数⽤户、⽤户⾼频⾏为、⽤户愿意付费。
不可能N⻆
ONE 期望多个⽬标之间同时找解法：
⽤户只需要⽤ ONE就可以完成在钉钉上的所有操作
⽤户每天⾼频使⽤
辐射⼤多数⽤户
服务好管理者⻆⾊
成本控制
引导⽤户去看资讯视频
AI 召回率、准确率。
最核⼼的处于量⼦纠缠态的⽬标三⻆是：
这三件事很难同时成：
如果要⼤基数，就要抓⼴谱痛点；⼴谱痛点通常不够痛。
如果要⾼频，就要进⼊消息、⽇程、待办、会议；这些⽼钉钉本来就能做，迁移理由不够强。
如果要付费，就要解决深问题；深问题往往⻓在⾏业、业务、组织习惯⾥，很难靠⼀个通⽤⼊⼝解决。
所以 ONE 早期真正的定位难题，是在「所有⼈都会⽤」「每天都会⽤」「有⼈愿意付费」之间找⼀个交点。这个交点本来就很窄。
如果要服务⼴⼤基数⽤户，产品就要轻，要泛，要让⾜够多⼈每天都能打开；如果要抓⾼频⾏为，就绕不开消息、⽇程、待办、会议这些⽼钉钉本来就有的东⻄；如果要让⽤户付费，⼜必须解决更深、更具体、更贴近业务的问题。三者都重要，却很难靠同⼀个⼊⼝同时满⾜。
这也是 ONE 早期定位最难的地⽅。它既不想只做⼀个⼩⼯具，也不想变成客户定制；既想覆盖所有钉钉⽤户，⼜想做出⾜够深的 AI 价值；既要让⽤户⾼频使⽤，⼜要证明这个⼊⼝不只是⽼钉钉换了⼀种摆法。
⽤「⼯作 + 发现」试图同时解三⻆
后来「⼯作」和「发现」的组合，可以看成对这个三⻆的⼀次求解。
「⼯作」负责⾼频和⼤基数。消息、⽇程、待办、会议每天都发⽣，只要能把它们重新组织起来，ONE 就有机会成为⽤户每天打开的⼊⼝。「发现」则承担另⼀层想象：学习内容、知识流、paper、视频化内容，理论上更接近收费场景。于是 ONE 既包揽钉钉全局信息，⼜试图⽤⼯作流给发现带量。
这个组合看上去完整。⼯作带 DAU，发现带收费，ONE 做统⼀⼊⼝。但它也把两种意图放进了同⼀个⻚⾯：
⼀种是处理⼯作，⼀种是消费内容。⽤户打开 ONE 时，最朴素的意图往往是看今天有什么事要处理，⽽不是突然进⼊⼀个学习流。于是「发现」在产品逻辑⾥负责商业想象，在⽤户体感⾥却容易变成不合时宜的打扰。
「⼯作」模块负责⼴⼤基数和⾼频⾏为；
「发现」模块负责收费想象；
ONE 作为统⼀⼊⼝，把钉钉全局信息都收进来，试图既有 DAU，⼜有商业化，⼜有 AI 新⼊⼝的故事。
这个思路内部是⾃洽的。
⼯作信息天然⾼频，消息、⽇程、待办、会议每天都发⽣；发现内容更接近学习、成⻓、知识付费，理论上有收费空间。两者放在⼀个⼊⼝⾥，似乎就能让⾼频带动低频，让免费带动付费，让⼯作流带动学习流。
但实际问题是，⽤户打开 ONE 的⾸要意图并不⼀定接受这种拼接。
他来处理⼯作，不⼀定想学习；他来清消息，不⼀定想看 paper；他来找今天该做什么，不⼀定想进⼊⼀个内容流。于是「发现」不是⾃然⻓出来的付费场景，⽽更像被⼯作流带量的商业⽬标。这个判断要写得克制，但可以明确。
这⼀段的核⼼不是「发现不好」，⽽是：
发现把商业发⼼提前塞进了⼯作⼊⼝。
⽤户看着某某台的电视剧，中间突然插进来⼀条某某乳业的⼴告⸺你可以说它的发⼼是给中国⼈推荐好⽜奶，但⽤户能不知道这他妈是⼴告吗？
发布会之后，ONE ⼜被寄予了更明确的指标。产品不再只是讲⼀个 AI ⼯作⼊⼝的故事，还要回答有没有⼈⽤、能不能提升效率、能不能贡献 AI 组织数。指标进来以后，定位⾃然会向更容易被计量的部分靠拢：曝光、打开、点击、AI 调⽤、组织覆盖。
只是，真正深的 AI 价值往往更慢，也⽆法通过这套指标衡量。⽤户希望 AI 帮他建待办、做搜索调研、跟进事项、跨系统执⾏、按⾃⼰的规则处理⼀类问题；但这些能⼒牵涉权限、稳定性、成本和⻓流程执⾏，短期内不容易被做成⼀个轻⼊⼝。于是 ONE 在现实推进中，更容易停留在让事情被看⻅、被整理、被触发，⽽不是让事情被完成。
到了 2025 年 9、10 ⽉份，随着发布会落幕，由于外界刺激与对赌指标的⾮连续性，原本的 ONE 路线开始边缘化，并出现了不⼩的⼈员流失。
到了 11 ⽉中旬，ONE 原本「提纯信息、对抗过载」的严肃⽣产⼒中枢定位被完全解构，让位给另⼀套更⼤的说法：AgentOS ，底部层层堆叠的⼀排对于普通打⼯⼈⽽⾔完全⽤不到的 Agent 图标，不仅在内⽹引发了剧烈的反弹，更遭遇了不少客户的直接质疑与投诉。
但它在概念层⾯上，完成了决策者个⼈对于「AI 操作系统」的宏⼤美学投射。这也让⼀线产研更加意识到，钉钉已很难⻓出真正刷新 AI 时代、尊重个体⾃主性的 AI ⼯作产品。
新的关键词已经变成 LUI + GUI、Agent OS、统⼀ AI ⼊⼝、多 Agent 运⾏态。消息、⽇程、考勤等⾼频功能，都被重新理解为可以运⾏的 Agent；未来的 Fusion 界⾯，则被设想为承载这些 Agent 的新⼯作台。
那次之后，ONE 在定位上基本开始退场了。它没有⽴刻消失，但从「钉钉 AI 的答案」退成了下⼀套答案⾥的某⼀层；从主⼊⼝退成承载位；从新⼯作台的想象，逐渐收缩为负⼀屏。
这样看，ONE 的定位变迁可以概括为⼏次改写：先在⼤基数、⾼频、付费之间找交点；再⽤⼯作带发现，试图同时承接 DAU 和商业想象；发布会后回到效率和 AI 组织数，被更明确的指标收束；最后让位给 Fusion，成为更⼤框架⾥的过渡层。
每⼀次改写都有理由。问题在于，前⼀次留下的缝，并没有在下⼀次⾥被补上。⼤基数和付费深度的⽭盾没有消失；⼯作流和学习流的错位没有消失；看⻅事和做完事之间的断层没有消失；⽼钉钉和新⼊⼝之间的迁移成本，也没有消失。
定位不是命名，也不是⼀句对外⼝径。定位是⼀次⼜⼀次取舍以后，仍然留下来的⽅向。ONE 最⼤的遗憾，也即在此：有过很多⽅向，每个⽅向都有道理，却没有来得及把其中任何⼀个⽅向⾛到⾜够深。
设计第三
ONE 的设计，是⼀个拿着锤⼦找钉⼦的⽅式做产品探索的过程，⼀个约束收敛的过程。我们从充满想象⼒的讨论，到放弃⼀步登天找到全局最优解的幻想，逐渐纠结在⼀个个看似⽀离破碎、实则彼此耦合的产品选择中。
这⼀章，不是为了向读者展示 ONE 当年做过⼏种卡⽚、⼏种交互、⼏次改版；⽽是想借 ONE 看清⼀件更普遍的事：AI ⼯作产品的设计，不是把模型能⼒摆上界⾯，也不是让系统显得更聪明。它⾸先是在重排⼈与⼯作的关系。
谁先被提醒，谁被默认已读，谁需要解释，谁拥有关闭权，谁承担模型误判后的代价，谁能把⾃⼰的规则交给系统，谁只能接受系统安排⸺这些问题看似细⼩，却决定了⼀个 AI 产品究竟是在帮⼈掌握⼯作，还是帮⼯作更早地掌握⼈。
如果读完这⼀章，读者再看到⼀个 AI 助⼿、⼀条智能摘要、⼀个⾃动提醒、⼀套 Agent ⽅案时，不只观察它的交互是不是够酷，⽽会追问「系统⾥原本这个功能是怎么实现的？AI 做了正功还是负功？⽤户在获得某种好处的时候，是否付出了更⼤的隐形成本？AI 如何改变了原本的责任流向？」⸺那么 ONE 的这段设计复盘，就不只是⼀个项⽬的旧账，⽽有了⼀点可迁移的价值。
⼯作内容如何寄身卡⽚
卡⽚形态的必要性讨论
余华透露过《活着》的创作历程：动笔以前，他已经「蓄谋已久」地想写⼀个关于⼈与⾃⼰⽣命关系的故事，但这种宏⼤的主题让他苦思冥想、沉吟良久，始终找不到切⼝，不知道从哪⾥落笔。
直到某天早上，他⼀觉醒来，忽然想到「活着」两个字，⽴刻对太太说：「我知道怎样写这篇⼩说了，因为我想出了题⽬，就叫《活着》。」这两个字像⼀把钥匙，瞬间打开了整个故事。福贵的⼀⽣⸺苦难、荒诞、忍耐、命运⸺⼀下⼦有了⼀个可以承载它们的容器。
「基于卡⽚的设计」之于 ONE，就像「活着」这两个字之于余华。
Agent 赛道最⼤的问题是：叙事强、估值⾼、但同质化严重，技术护城河⾮常容易被模型升级吞掉。从技术维度的本质来说，SaaS = 数据库 + 宜⼈的 UI。钉钉现有的⼯作内容 AI 化，做成 ONE，是⼀种围绕既有优势的产品设计。
AI 时代，怎么才算宜⼈的 UI 呢？
我来 ONE 的时候，ONE 就是基于「卡⽚」的了。
卡⽚并⾮随便选择的容器，它是 ONE 把「主动服务」翻译到具体设计时，最顺⼿和符合想象的交互语⾔。
我们在前两章讨论了 ONE 的发⼼和定位：AI ⼯作信息流、主动服务、让事找⼈、钉钉的新⾸⻚、⽤户的专属⼯作秘书。与之相配的，ONE 的设计⽅向关键词是「有 AI 感」和「让⽤户快速消费」。我们希望提供的⼀种体感是，当⽤户打开钉钉时，发现系统已经替他多看了⼀步、多想了⼀层。
我们希望它不像钉钉原场域，按 IM 消息、⽇程、待办这样的属类，割据⼯作内容，按照列表时间排序、红点、DING 这样的形式，组织紧急重要程度排序，让⽤户在⼀个个 tab 下进进出出，拼凑零散的⼯作线索⸺宏⼤⽽泛泛的概念，以⾄于很难直接变成⼀个产品，直到「卡⽚」的概念出现出现⸺ONE 才有了⼀个可以寄身的容器：消息、待办、⽇程、会议、审批、发现，这些原本散在钉钉各处的东⻄，都可以被 AI 拎出来，排成⼀张张卡⽚，主动送到⽤户⾯前。
ONE 像⼀个被收拾好的⼯作桌⾯， AI ⼩秘书敦淑体恤地侧⽴⼀旁伺候。当⽤户准备开始⼯作的时候，⼏案上已经恭敬地按序陈列好⼀本本需要批复的奏折。
这个形态很有诱惑⼒。
它轻巧直观，适合移动端，⽽且⼀下⼦让⼈联想到抖⾳的 feed 流，⼀款让 C 端⽤户沉浸上瘾的内容消费形态。
因此，它极宜 demo，尤宜向投资⼈ pitch。对外沟通客户、开发布会，对内汇报集团，亦然。
卡⽚设计的⻛险
不过，因为卡⽚解决的是「展示」，并没有回答「内核」，⾛进具体⽽鸡⽑的⼯作场景：⼯作并不会因为被做成卡⽚，就变成可以轻松消费的内容。
这正是 ONE 的设计在历史上许多时刻陷⼊难产的地⽅。
请读者与我⼀起想象⼀下卡⽚式的交互。可以联想Tinder、⻄窗烛这样的内容相对同质的图⽂卡⽚，或者抖⾳这样的全屏 feed 流。
⼀张全屏幕的卡⽚送到眼前，⽤户只需要停留消费卡⽚上的内容，不需要额外的上下滑动，操作⽽⾔，只需要左滑右滑或者少数点击，系统会根据⽤户的主动标记或停留时⻓，来记录⽤户喜欢或不喜欢，并⽆限给⽤户推送下⼀张卡⽚的内容。
由全屏的视觉展示和极简的操作可以推想，卡⽚更适合推荐、浏览、轻处理，也即更适合娱乐内容。这个交互操作，落在⼯作内容上，就会⽐较操蛋。
⼯作不是消费了就结束的内容。
划⾛⼀张 Tinder 卡⽚，卡⽚背后的⽤户，对你的「不感兴趣」也「不感兴趣」。但是每⼀张钉钉的⼯作卡⽚的背后，都可能有⼀个紧张等待你表态、回复或者交付的同事。
这不是说卡⽚完全不⾏，事实上，有些⼯作确实适合卡⽚。
⽐如审批就很适合。信息字段规整，核⼼操作单⼀，同意或拒绝，也正中卡⽚设计的下怀。待办也适合，因为它能把散落在消息、⽂档、会议⾥的信息转成⼀个待办对象。⽇程和会议准备，勉强也可以适合⸺这些场景的共同点是：结构相对清楚，动作相对明确，关系压⼒相对弱。卡⽚可以帮⽤户少看⼀点、少点⼏步、少漏⼀件事。
不过 IM 消息，就是⼀道天堑了。
IM 消息如何寄身卡⽚
IM 消息在 ONE 呈现的必要性讨论
IM 是钉钉⼯作中最重要的⼀部分，占据⽤户 80% 以上在钉钉的停留时⻓。钉钉的⽂档知识库等知识管理既已积弱，所服务的诸传统企业，本身信息沉淀的诉求⼜低，IM 的信息就更显重要。
想要⽤ ONE 给发现带量，再⽤发现变现，必须培养⽤户⽤ ONE 办公的习惯。不带 IM 玩，「⾼频」「⼤ DAU」的⽬标，就流⽔漂萍了。
落成移动端
ONE 主要落在移动端。
这个选择和卡⽚的原始设计选择是强关联的。
曾经 PC 难为⽔
事实上，在 ONE 项⽬启动的初期，6、7 ⽉份就出过 PC 端的需求设计，⾥⾯有涉及钉钉原场域端框架改造的，还拉 PC 端框架的产品和技术负责⼈讨论过。最终没成，主要因为：
1. 卡⽚的设计放在桌⾯端，就显得格格不⼊，信息量⽐之前还低；
2. 操作起来更不⽅便，没法像移动端那样滑屏；
3. 考虑过类 AI 浏览器的⽅案，也即把钉钉第四屏做成 copilot（现在的悟空⼊钉也是这样实现的），但是由于没有卡⽚元素，在提案初期即遭否决。
另外可能还有原因 4.：ONE 是保密项⽬，我们只被允许不暴露具体产品形态的情况下，兜着圈和「外⾯」的产品开发讨论⽅案，对⾯也是⼀头雾⽔，产品讨论起来鸡同鸭讲，你画我猜。
关于项⽬保密制度，我们会在「秩序第六」章讨论更多，本章还是聚焦前两点设计问题。不过，说起来也还好没有投⼊开发，不然也是徒然耗⼈。
再说回移动端，移动端其实不适合直接处理复杂⼯作：屏幕⼩，信息承载量有限，只适合提醒和轻量读写处理。它可以提醒⽤户有哪些⼯作事项要办，排好顺序，准备好轻量的处理选项，却很难让⽤户真正「顺⼿」把这件事完整做完。写⽂档、填表格、写代码、跨系统查资料、整合总结分发、跟进执⾏，很多还是更适合在 PC 端完成。
移动端还是 PC 端，这⼜是⼀盒薛定谔的⽤户。只是⼈⼒有限，还是要选择⼀端先下⼿为强。
可以想象地，我们选了移动端，同时也⼀直牵挂着 PC 端，记为「重要不紧急」。
和所有「重要不紧急」的任务⼀样，直到 ONE 死灯灭（其实倒也没有完全死）， PC 端都没真正被排上⼀天开发。
实时性问题
要在卡⽚中加⼊ IM ，就必须考虑实时性问题。
整理复盘资料的时候，发现 7 ⽉底在备忘录上记了⼀个产品卡点便签如下：
之所以会出现「卡⽚重复」「卡⽚上的消息已读，但卡⽚仍然以未读状态存在」「红点没有消除」的问题，核⼼皆因这⼀套卡⽚是由服务端上异步⽣产所致。
不实时对 IM 消息卡⽚来说是致命的。
因为⽤户消费的对象，80%以上是其收到的消息本身，⽽不是AI⽣产的内容。 IM 消息⽣产频次⾼、变化快，不实时就意味着对⽤户的欺诈。
如果只是卡⽚重复读，或者在 ONE 读了⼀遍、回到原场域⼜要重读，这还只是浪费⽤户时间的「⼩」问题。
⽽如果是被发信⼈编辑过的信息，⽤户在 ONE ⾥读了⼀遍编辑前的版本；亦或者是已经在原场域被发信⼈撤回的敏感信息，⼜可以在 ONE 的卡⽚⾥读到⸺这些可能就是会涉及数据泄露的⼤问题了。
其实，如果没有对实时性要求极⾼的 IM 消息，⼯作卡⽚是⾮常适合由服务端异步⽣产的。
正如前⽂提到的 OpenAI 推出的 ChatGPT Pulse，也是夜⾥异步产⽣卡⽚给⽤户第⼆天早上起来读。这样由异步服务端⽣产卡⽚的好处是：
1. 【⽣产侧】处理频次低，⼀次输⼊输出完整处理，⼤⼤节省了成本；
2. 【⽤户侧】⼀次性可以读到信息量更⾼的内容，减少打扰，提⾼效率；
3. 【产品运营侧】培养周期性进⼊产品的习惯。
可以说是个多赢。
只是这样，就注定不能满⾜产品要做成⾼频的需求⸺这⼜回到了定位的不可能三⻆。
重要性排序
ONE 要主动服务，第⼀步就是排序。
ONE 针对卡⽚重要性排序的设计，有过两种思路：
1. 所有⼯作卡⽚，不限类型，放在⼀起打散排序。
这样做的好处是更加灵活，⽐如有三张卡⽚，分别是⼀条来⾃主管上级在群⾥@你的提问消息，⼀条普通的群聊消息，还有⼀条还有 1 ⼩时截⽌的待办。打散排将这条紧急的待办放在重要紧急的主管未读消息之后，和⼀条不太重要的群聊消息之前。
2. 先规划各种⼯作卡⽚类型间的排序，再在每种类型内各⾃排序。
这样做也有好处：⼼智更加稳定，也符合⼼流理论。因为⼈在不同的任务间切换，认知层⾯上是需要「重新启动」的：先处理两条消息，再处理⼀条待办，再处理⼀条⽇程，再回来处理两条消息，其实也是对⼈更加⾼功耗的要求。
我们最后选了第⼆种。
由此，实际开发中，ONE ⾥的排序有两⽅⾯，⼀⽅⾯是各种类型卡⽚间的排序，这其实也就是⼀套⼈⼯规则；
另⼀⽅⾯是 IM 消息的排序，这⾥⾯的复杂度就要⾼很多。
（其他卡⽚类型内的排序也是⾮常简单的⼀句话⼈⼯规则，⽐如⽇程只和时间有关，待办也和截⽌时间有关。）
各种类型卡⽚的数量级，和⽤户在对应原场域的⼯作内容量，是成⽐例的。IM 消息占到钉钉⽤户⼯作的 80%以上，对应的，⽤户每天卡⽚数量的⼤头也都出在 IM 卡⽚上。
排序的设计思路上，我们主要根据组织关系（⽐如直属上级，重要联系⼈）、信息性质（⽐如 @ 我、DING消息）；⾏为亲密度（⽐如会话曝光点击、发⾔内容⻓度、停留时⻓）等组成的上下⽂，来构建会话的紧急重要排序。说到底，是想让系统理解企业消息⾥，对⼀个⽤户个性化的真实重要性评估。
卡点 1 ：排序和分组的⽭盾
有⼀些 IM 原场域的特性，如果不拆碎了重整，是⾮常难塞进卡⽚排序这套逻辑⾥的，其中最典型的特性就是分组。
⼀般什么样的⽤户会使⽤分组？⾸先，会话⾜够多，消息⾜够多，否则没必要分。其次，它在处理⼀些不同领域或不同⻆⾊身份的会话消息，否则也没必要分。所以概括起来，负责多个项⽬的信息中枢型员⼯更可能使⽤分组。这部分⽤户，也符合我们在⽤户定位⾥讨论的塔尖⽤户类型。
对应的，也有两种⽤户常⽤以分组的⼿段。以 PM 为例，同时在对接许多项⽬，也同时在对许多不同的岗位⻆⾊沟通。这⾥就有两种分组思路，⼀种是按照项⽬分组，另⼀种是按对客户、对内部这样沟通去做分组。
当⽤户在原场域切换分组的时候，⻚⾯上就会把这个分组下所有的会话都陈列出来，不区分已读未读，不区分重要程度。
如果要做排序，那么必然未读在前⸺甚⾄只能放未读，否则是对有限卡⽚空间的浪费。同时，各个分组内⼀定会被打散：⼀个不重要的分组⾥的客户愤怒的紧急舆情质问，很有可能重要过⼀个重要的分组⾥某个内部同事的玩笑发⾔。
所以要把分组也搬进排序卡⽚⾥，天然存在着不可调和的⽭盾。我们从具象的例⼦⾛到抽象的概念，主要是这些维度上的不可调和性：
我们实时同步处理IM消息的初衷，以及导航栏滑切的交互，决定了我们⼀定以「排序」为主要组织维度，「分组」作为辅助。
或者说，分组应该作为排序的加权项，⽽不能完全照搬。
我们提出过⽤标签形式软化和替代分组的可能性。不过这个⽅案最终没有通过。最后⽼板拍板还是希望我们把分组完整地搬进 one，最后的呈现形式也⽐较怪异，就是单拎了⼀个分组的卡⽚类型出来，卡⽚上放分组消息列表，当出现未读的时候呈现整个列表。
可以想象这是⾮常别扭的。⾸先，对于⼀些有⼤量分组，或者分组已经⽼化的⽤户来说，这样显著降低了卡⽚消费效率，其次，对于⼀些⽤户同⼀个会话设定在不同分组的情况，就更加难缠。
这个功能做上线之后，我们项⽬室⾥就有开发拿着⼿机找我展示他的分组消息卡⽚，每张卡⽚上只有⼀两个未读会话，零零散散分了⼗⼏张卡⽚。他苦笑说，幽素有没有办法调整⼀下？这是 bug 吧。
我说...可能没办法，这是他要的。
说这话的时候，我⾃⼰也脸红，感觉⾃⼰在逃避和推卸责任，不是⼀个好产品。
卡点 2 ：排序被卡⽚交互遮住
排序要成⽴的⼀个前提是，⾸先⽤户必须感知到排序。
列表天然让⼈感知顺序。第⼀条、第⼆条、第三条摆在⼀起，⽤户会⽐较，也会逐渐相信这个系统把重要的东⻄排在前⾯。
卡⽚不⼀样，卡⽚⼀次只出现⼀张。⽤户⾯对的不是⼀个序列，⽽是眼前这件事。即便再把卡⽚放进导航栏、横滑、头像和各种压缩空间⾥，⽤户⾸先感受到的，往往不是「系统帮我排好了」，⽽是「这个会话我看不清」「这个⼈是谁」「这条消息是不是已经被我读了」。智能没有消失，只是被交互遮住了。
如果眼前这件事还是未读的重要消息，⽤户就更难感知排序的好处。
这也是早期消息卡⽚很别扭的地⽅。系统花了很多⼒⽓判断重要性，⽤户的第⼀反应却不是「它排得准」，⽽是「它会不会替我暴露状态」。排序在卡⽚⾥被压⼒淹没了。
所以，排序是主动服务的起点，但排序必须被合适的界⾯承接。否则系统判断得再多，⽤户也不⼀定感受到价值。
⽐如，有没有可能直接做进 IM 列表⾥呢？
可惜，那是 ONE 的命题以外的⼯作了。我们尝试过「向前⼀步」，汇报提议过这个⽅案，但是可以想象地没有任何结果。
此外，相⽐「难以感知排序的好处」这种隐性 debuff，还有⼀个显著⾼亮的debuff：⽤户的注意⼒会完全被另⼀个问题攫取⸺
已读恐怖主义
「卧槽，这怎么直接把我已读了？！」
⽆论是内部同事还是外部⽤户，第⼀次在 ONE 的卡⽚⾥刷到 IM 消息，⼏乎都是这个反应。
消息卡⽚⾥最棘⼿的问题，不是排序，⽽是已读未读状态。
已读未读，其实也就是消息阅读状态功能，最早可以追溯到2005年，由⿊莓公司在BlackBerry Messenger (BBM) 中⾸创，设计初衷是为提升商务沟通效率。钉钉 IM 消息接⼊已读未读显示，是钉钉在 2016 年 1 ⽉ 16 ⽇推出的版本 1.0 ⾥的当家得意之作。
已读，即开启了回复的倒计时。
这在钉钉原场域，是⽤户早已习惯的机制，但在 ONE 在的卡⽚⾥却是⼤灾难。因为⽤户不再是观察未读消息列表，通过 last message 简单判断消息内容，再主动选择⼀条进⼊，清除已读状态，⽽是直接开了 AI 秘书呈上来的盲盒。
剥夺了⽤户的选择权，责任和后果却要⽤户承担。这委屈谁受得了？
那能不能在 ONE ⾥就不直接帮⽤户已读掉呢？
内部⼀开始讨论过其他⽅案，⽐如「只读卡⽚不算已读」「进⼊ IM 详情⻚才算已读」。这些⽅案都被否决了。
⽆招认为，这会损害发信⼈的利益，也会动摇钉钉的根本。这⾥主要是发信⼈⽴场，可能也有⼀点产品⼀致性的考虑。
更糟糕的是，这⾥的已读，纯粹是锦⾐夜⾏。
过去钉钉做已读未读成功。对⽐的是微信。⽤户⼀下⼦就有体感了：是钉钉帮我，让我布置出去的信息都可以查看状态，让我对⼀件事情的进展有更强的把控⼒。
然⽽在 ONE ⾥，现在收信⼈是清楚⾃⼰在这⼉半推半就、将信将疑地已读了⼏条他还没准备好签收的⼯作任务。⽽与此同时，对⾯的发信⼈，其实根本分不清⾃⼰发的消息，对⾯究竟是在钉钉原场域还是在 ONE 已读了⾃⼰的消息。于是，我们千⾟万苦硬着头⽪做出来的已读，不仅吃收信⼈的⽠落，发信⼈也不买它的账。
后续「⽤户」章也会提到，我们收到针对卡⽚形态最强烈的反馈也落在这⾥：「我怕客户/⽼板看到我已读不回。」
有时候，不⽴刻点开消息，不是怠惰拖延，⽽只是给⾃⼰留下⼀点处理的余地。
⼀个对⾃⼰⼯作内容熟稔于⼼的⼯作者，从群名、发信⼈和 last message 的上下⽂⾥，已经可以⼤概推知对⽅问什么要什么了。
⼀个运营同事反馈过类似场景：她看到是哪个群⾥、哪个⼈ @ 了她，就知道⼤概在问哪件事；但她还没准备好回。⽐如某个不是⾮常紧急需要的回复，可能依赖⼀个⼩时后要开的会议的结论，那么等会后有了结论再同步对⽅，就可以⼀次说清。如果现在读了，就要多解释⼀轮，多发⼀句「我看到了，但要等⼏点⼏点某某会后同步」。
ONE 的消息卡⽚把这点余地压缩了。它原本想替⽤户减少读信压⼒，实际却可能提前启动责任压⼒。
更尴尬的是，这个设计对发信⼈的收益也很弱。发信⼈并不知道⽤户是在 ONE ⾥看到的，还是在会话⾥看到的。他只看到⼀个「已读」。对他来说，体感差别并不明显。
所以这不是抽象的「发信⼈ vs 收信⼈」⽴场之争，⽽是⼀笔具体的收益和成本错配：发信⼈获得的增量很弱，收信⼈承担的不安很强。
我后来越来越觉得，这是⼀个锦⾐夜⾏的设计。它维护了⼀个抽象正确的⽴场，但真正被保护的⼈没有明显感知，真正付代价的⼈却清清楚楚。
当底层规则不能动，交互就只能补洞。补得再巧，也还是洞。为了缓解已读带来的压⼒，我们后来尝试过⼀些补丁。
⽆望的补丁 1：横滑
8 ⽉ 25 ⽇发布会前后，ONE 引⼊了横滑结构，从变成了 Tinder 进化为微信公众号。
它本质上还是卡⽚，只是在⻚眉加了⼀排头像。这样⽤户能提前知道后⾯⼤概是谁的消息，也可以点击跳过某些卡⽚。
横滑结构设计还是想解决两个问题：
1. 给⽤户预告感，缓解「不知道下⼀张是谁、但看⻅就已读」的压⼒；
2. 允许点击头像，主动跳过⼀些卡⽚。
然⽽，交互的底层规则没变，另外还增加了两重隐形⽽严重的麻烦：
1. 相⽐原场域有 last message、有消息发出时间等，⽤户在 ONE 需要依靠更少的信息⸺仅通过头像判断可能需要跳过谁的信息；
2. ⻚眉加了横滑头像之后，压缩了可读空间。在⼀些⼩屏幕机型上，键盘⼀拉起来，甚⾄看不到 IM 消息本身，反⽽更加损失了信息效率，加重了⽤户的阅读负担。
横滑相⽐原场域的好处，仅仅是减少了⽤户⼀进⼀出、点进⼀条消息查看的成本，但这对⽤户来说真的重要吗？假设点进点出需要耗费⽤户 1 秒，⽽判断⼀条消息需不需要跳过需要 10 秒。为了节省 1 秒⽽增加 10 秒的负担，这真的划算吗？
⽆望的补丁2：Peekaboo
Peekaboo 是我提出的。它的原理是，既然必须要标记⽤户已读，那么我们可以在明确标记已读的节点上略施花活。
⽤户在横滑到下⼀张卡⽚时，只要没有完全划到下⼀张、没有松⼿，就还不算正式读到，可以理解为「预读」。
这样⽤户可以⽐普通 IM 列表⾥的 last message 看到更多消息内容，⼜暂时不触发已读。
这个设计纯粹是⽆奈的、苦中作乐的、抱有侥幸⼼理的、但好在也没花什么成本的⸺补丁包。也如预料，⼏乎没有⽤户主动发现这出精致的淘⽓。
卡⽚的可玩性
当然，卡⽚绝⾮⼀⽆是处⸺如果真是⼀⽆是处，我们也不会启动了。
除了可以减少⽤户⼀进⼀出的操作，以及节省判断时间之外，卡⽚的想象空间很⼤，或者说可玩性很强。
卡⽚格式可以承载⾮常多的内容，⽐如我们做过「今⽇消息今⽇毕」「今⽇⾦句」等有意思的功能：
他们的定位是消息的解构和重新组织，辅助⽤户快速消费信息或者重吸收。
对标原场域
2.3 节提到的实时性问题，其实就是对标原场域的⼀个细分场景。
讨论和⾛查对标原场域，其实就是在计算⽤户的迁移成本。
如果说，我们的最终⽬标是⽤户可以完全迁移到 ONE 上，那么IM 消息卡⽚究竟对标和替代原场域什么功能的职能呢？
⾸先，替代了⼀部分阅读消息本身内容的职能；但是并不是所有消息都适合在移动端展示呈现，如果涉及⻓消息、⽂档、链接、动态卡⽚，还是更适合在已经迭代了⼗年的原场域或者回到 PC 端查收。
其次，替代了⼀部分提醒通知。我们⼀开始讨论希望 ONE ⾥读了消息可以算作「未读」，就是考虑 ONE 可以对标 notification bar的可能性。这也很符合常理：毕竟卡⽚可展示空间有限，可以认为是⼀条⻓提醒。
第三，鉴于我们做了「已读未回」「今⽇⾦句」等卡⽚，相当于帮⽤户做消息的「重吸收」，因此我们也可以对标这样⼀部分超越原场域范畴的⼯作。
最后，消息列表。IM 消息卡⽚的⽬标，可能是要把整个消息列表吞掉。这并不是因为我们已经对标了 IM 列表的能⼒，⽽是我们在卡⽚的形态⾥，已经没有列表的容身之处了。
不过，我们真能替代得了么？
以 IM 消息列表为例，它不仅承担未读按时间排序的展示，它实际上容纳了所有的会话。当⽤户想要根据⼀些模糊的记忆，对照时间线模糊下翻寻找某个会话的时候，当⽤户想根据 last message ⼤致预知未读消息中可能包含内容的时候，当⽤户⻓按某个会话，把它标记为未读的时候⸺还有许多其他场景，IM 列表其实隐形地承担了⾮常多的职责。
另外，还有⼀些原场域的隐性优势我们是缺失的，⽐如说消息可视区域的空间。为了。缓解已读的恐怖，我们做了横滑和⻚眉的头像，这是⼀块信息浓度很低，⼜很占空间的区域。
讨论卡⽚形态的时候虽然兴奋，在实际推进中，由于我们把重兵压在了移动端的卡⽚流，产品展现出来的形态，只是把这些信息提炼成了⼏⾏简短的摘要卡⽚。
这导致了最致命的错位：AI 在台⾯下做了最难的「⽹状逻辑缝合」，但在台⾯上，却只给⽤户呈现了⼀个「⽼钉钉⾥⽤⾁眼扫⼀下也能看到」的简短摘要。 ⽤户感知不到那个「不依靠 AI 就⽆法解决的降维打击」，只看到了⼀个多出来的、需要⼤拇指去滑动的卡⽚。
新范式的⾼昂信任成本（⽤户需要担⼼ AI 摘要得准不准、会不会漏掉重要信息），最终败⾛钉钉原场域那虽然痛苦、但⾼度产⽣安全感的「⼿动刷红点」的肌⾁记忆。
成本问题
如果说，上⼀节「2.7 对标原场域」是我们在计算⽤户的迁移成本，那么由于功能设计涉及 AI ，即必有 tokens 的消耗，我们也需要计算这个 AI 秘书⽇常运⾏的成本。
之前做成服务端⽅案时，没有考虑到实时性，成本还相对可控。要做成实施排序的⽅案⽣产出来的卡⽚⽤户却不⼀定消费，岂不是「损成本以奉功能完整，犹割股以啖腹，腹饱⽽身毙」？
但是不实时是不⾏的。上⽂已经讨论过，不实施就是欺诈。我只能在⼼⾥悲壮地想：「⽽今不实时死，实时亦死，等死，死实时可乎？」
不过办法总是⼈想出来的，办法总⽐困难多（不包括 2.4.1 的分组问题）。 后来我们⽤了端上的⼩模型，做了实时和离线计算的组合，从某种意义上解决了这个问题。
那么，IM 卡⽚最终服务好它的⽬标⽤户了吗？
显然是没有的。
除了上述提到的所有问题，有⼀只房间⾥的⼤象⾄今尚未讨论，那就是：
卡⽚整体是⽤来阅读，⽽不是操作，或者⽤来查找的。
我们在 2.5 节，站在发信⼈的⽴场，挣扎着做了「已读」的操作，却没在发信⼈⾯前讨到好；我们在 2.7 节⾛查了和原场域对⻬还相差哪些内容⸺到这⾥，卡⽚对发信⼈来说最致命的问题⽴刻浮现了：
消息列表承载的查找会话、管理会话的职能在卡⽚形态上是完全丢失的，我们做了语⾳指令能⼒来填补搜索查找，另外在卡⽚上加⼊搜索图标来缓解前者，但是效率已经⼤⼤降低。读者可以想象⼀下，在脑海⾥列出，你最近⼏天⾼频沟通的 top 10 群聊的具体名称。由于平时我们不需要输出这个名称，所以直接输出是困难的，尽管你可以在看到它的名称时⼀眼认出，那就是它。
同时，在 IM 列表上找到这个⾼频会话只需要 2～3 秒，如果你把它设成置顶，你可以凭⼿感在 1 秒内找到它。但在卡⽚， 15 秒是⼀个⾮常保守的估计。
重新拆题：AI 到底能帮⽤户读、写、管什么
到 10 ⽉中旬，团队已经围绕卡⽚、排序、已读折腾了⼀⼤圈，我逐渐强烈意识到⼀件事：或许设计不该先从卡⽚开始，⽽该先从⽤户动作开始。
⽤户在原场域究竟在做什么？核⼼动作是在读、写、和管理消息（分组、打标签）。
于是我们可以把 IM Copilot 的⽬标重新写成三件事：
1. 提⾼⽤户读信效率，
2. 降低⽤户写信⻔槛，
3. 兜底⽤户丢信⻛险。
寻找甜区
寻找甜区的思路，主要是找到⽤户有体感、会出现 Aha moment 的，和设计开发成本低的交集。
遵循这条思路，我们在 ONE ⾥做了 AI 回复。它后来取得了⽐较好的反馈，并且并⼊了钉钉主端，成为了灵动回复。
默认值的权⼒：平台产品不能只靠主厨审美
AI ⼯作产品⾥的默认值很重要。
默认是否已读，默认展示什么卡⽚，默认排序规则，默认是否出现发现，默认是否主动推送，默认把⽤户带向哪⾥。这些看起来是产品设置，实际上是产品价值观。⼤多数⽤户不会⼀项项配置，也不会花时间研究开关。
默认值就是他们实际⽣活在⾥⾯的制度。
ONE 的默认值⾥，带着很强的产品设计者的意志。
⽐如默认读到消息即已读，默认系统替你排序，默认⼯作卡⽚后⾯跟着发现，默认让⽤户先进⼊⼀个由系统安排好的信息流。对于⼀个⼩众产品来说，这种强⻛格可以成⽴。
像番茄钟⼀类产品，本身未必解决多深的痛点，但它提供交互美学、节奏感和仪式感。喜欢的⼈来，不喜欢的⼈⾛，它像⼀家餐馆，有⾃⼰的菜品、审美和规矩。
ONE 不⼀样。
ONE 想做⼤ DAU，想做钉钉的新⼊⼝，想覆盖⼴⼤基数⽤户。它更像平台，不像餐馆。平台产品当然也需要⻛格，但它不能要求所有⼈都按主厨的⼝味吃饭。⼀个⼩餐馆可以坚持「我就这样出品」，美团不⾏。美团要承载千千万万种吃法。
ONE 的许多设计问题，正在这⾥。它想做平台级⼊⼝，却采⽤了很强的主厨式默认。⽼板和少数产品设计者反复⽿提⾯命，把⾃⼰的⼯作⽅式、审美、判断，做成了所有⼈的默认处境。
发现是典型例⼦。
发现不属于⼯作卡⽚，更像学习流。⾥⾯会出现 paper、学习内容、视频化内容。某种意义上，它是⼀个被放进⼯作⼊⼝⾥的内容频道。
发现的存在有⼏重原因：⽆招个⼈对学习内容的执念，商业化压⼒，以及⼀种组合思路⸺⼯作模块负责⾼频和 DAU，发现模块负责知识订阅付费和 token 消耗。三者并不⽭盾，甚⾄可以互相解释。
问题在于⽤户场景。⽤户打开 ONE，主要是处理⼯作。消息、⽇程、待办、会议都是压在眼前的事。刷完⼯作卡⽚之后，如果系统⾃动进⼊发现，开始播视频，⼏乎所有的⽤户都会被吓⼀跳。很多反馈也很直接：「像⼴告」「⼯作时不想看」「占地⽅」。后台和 ONE ⽤户反馈群⾥，要求把发现关掉，是⾮常⾼频的问题。
⼏乎没有普通⽤户给发现正反馈。
有少数⽼板或 KP 会喜欢，⽐如市场部 KP 希望⽤来监控舆情，但他们也更多希望⾃⼰⽤，并不会给全体员⼯开权限。不过我们对发现的期待，是⽼板能给全体员⼯开；不然这要怎么（⾜够⾼地）收费呢？
这⼜回到平台和餐馆的问题。少数⾼能动⽤户可能喜欢学习内容，喜欢信息摄⼊，喜欢随时看到外部变化；多数打⼯⼈打开 ONE，只想把今天的⼯作处理掉。发现的问题不在内容质量，⽽在时机和默认。学习当然有价值，可当⼀个⼈正在处理消息、会议、待办时，系统突然递来⼀个学习流，就很容易从服务变成岔路。
从这个⻆度出发，也再⼀次印证了⽤户⾃定义的重要性。越有主观能动性的⽤户，越希望⾃⼰能调规则：我想看哪些⼈，哪些群不要提醒，发现能不能关掉，什么消息算重要，哪些卡⽚以后少推。可 ONE 早期给⽤户的⾃定义⼝很弱，更多让⽤户接受系统安排，⽽不是让⽤户驯化系统。
探索⾮卡⽚的可能性：信息流
上⽂提到过和展示过⻄窗烛的划卡⽚式交互。
其实有两个⾮常有名的古诗⽂类 App，还有⼀个叫古诗⽂⽹。古诗⽂⽹就是⼀个典型的⽆限信息流式的⾸⻚，和今⽇头条⾮常相似：所有呈现的信息可以在⼀个⻚⾯上，可以向下⼀划再划，但是不会提供像卡⽚那样切割出来的、⼀件事是⼀件事的⼿感。
在 ONE ⾛出项⽬室、产研团队也收缩为⼀个更⼩规模团队的时候，这种可能性终于被我们提上⽇程。
我们的新⽬标是，在⼀屏内展示所有重要的内容。⾸先，我们重新把重要未读，以列表的形放出来了，接着我们在下⾯同⼀⻚内，继续呈现当天重要的⽇程、需要做的审批和待办等等。
这个形态还是受到了⼀些好评，尽管它失去了最初项⽬启动时理想主义的卡⽚⼿感。
放弃⼤包⼤揽
其实到后期，放弃「什么都想要」的⼼态，不做满⼿抓着⾦银宝翠⼀颗都不肯放⼿的强盗，反⽽好了。只抓重点⼀个⼼智：当⾸⻚为空时，⽤户即已解除当前所有紧急重要的依赖，不再是任何⼈的卡点。
上了这个版本之后，在我们没有任何主动放量和宣传的情况下，产品还是保持⽐较温和的⾃然增⻓。⽐较令⼈惊喜的是留存，次流从 10% 出头涨到接近 30%。到 one ⼊⼝被换成悟空的 4 ⽉份之前，次⽇留存涨到巅峰 45% 以上。
⼩结：形式不该凌驾于内容
回头看，ONE 的设计教训不在于卡⽚不能做。任务识别、会议准备、快速审批、AI 回复都证明，卡⽚和 AI 可以很好地承接某些⼯作。真正的问题在于，⼯作产品⾥的「看⻅」从来不是中性的。
看⻅⼀条消息，可能意味着已读；看⻅⼀个待办，可能意味着责任；看⻅⼀场会议，可能意味着准备；看⻅⼀个总结，可能意味着后续分发。系统把事情提前端到⽤户⾯前，不能只计算阅读效率，还要计算责任成本。
设计也不只是把界⾯做好看，⽽是安排权⼒和责任怎么流动。
AI ⼯作产品的好设计，不是让系统更早发现⼯作，⽽是让⽤户更好地掌握⼯作。
如果没有做到这⼀点，所谓的主动服务，只是变成对⽤户傲慢⽽爹味的控制欲。
⽤户第四
其实在我的理解和倾向上，「⽤户」和「设计」之间，「⽤户」排序应该更靠前。⽤户是靶⼦，产品是箭；焉有靶⼦在哪还不清楚、甚⾄场地和⽐赛项⽬都没确定，就先挑选箭⽀的道理呢？
然⽽⾏⽂顺序最终定下是「设计第三」「⽤户第四」⸺因为就实际执⾏⽽⾔，ONE的开发过程确实有很多「设计」在前，⽽拿「⽤户」来贴近设计的成分。
这不是钉钉独有的问题。
⽆论是做 AI 产品验证 idea，做其他产品，或者泛化为做⼀切实验假设，⼀旦⽴了项，或做出了某种初步假设，沉没成本就会让这个产品或者实验假设的发起⼈，下意识成为⾃⼰假设的拥趸。⼀个⼈提出⼀个念头，很快就会开始保护这个念头；⼀个团队做出⼀个形态，很快就会开始解释这个形态；⼀个组织投⼊了资源、时间、排期、汇报链路，就更难承认：也许⼀开始题就没问对。
⼤型组织的沉没成本更⾼，因⽽更容易陷⼊⾃恋、⾃我解释和难以掉头。
如果说前三章更多还是是逻辑学科，那么从本章开始，则更加偏向经验学科。前三章我们讨论了 ONE 如何想象世界：为什么出发，想成为什么，⼜怎样落到卡⽚、排序、已读、发现和 AI 回复上。到了这⼀章，产品终于要离开会议室、设计稿和发布会，去⻅真正的⼈。
⽤户不会读 PRD，也不会⾃动继承产品团队的上下⽂。他们不会因为我们经历了多少争论，就多给⼀个⼊⼝三秒钟；也不会因为某个设计是排除过许多更差⽅案之后的最优解，就天然理解它、⽀持它。他们只会在⾃⼰的⼯作⾥判断：这个东⻄有没有帮到我，有没有打扰我，有没有让我少做⼀步，还是让我多背⼀层负担。
所以这⼀章不是简单的⽤户反馈汇总，⽽是 ONE 带着⾃⼰的理想和设计去⻅⽤户之后，⽤户如何验收它、拆穿它，质疑它，允许它⸺有时候也点亮它的其它⽅向。
To B or Not To B，that is the question.
2025 年 7 ⽉ 3 ⽇，产品师兄拉我⼀起和顾家家居的两位前线 BD 同学沟通。我们去了 C6 楼下的 M Stand，点了四杯拿铁。两位 BD 聊起顾家当时正在定制开发⼀个内部的轻量 Teambition ，呈现在 PC 端的主⻚，解决各种⼯作信息分散在钉钉各场域的痛点。顾家的痛点和 ONE 的底层技术⼏乎完全重合⸺他们也是希望 AI 能够从海量的群聊消息、⽇程、历史上下⽂中，⾃动把待办事项摘取出来，进⾏汇总和智能推荐。
这本该是⼀个绝佳的、能验证⼤模型进⼊真实业务语境的共创场景。但在沟通现场，当聊到我们当前主要在设计移动端时，对⾯的两位前线 BD 同学突然沉默了，并且彼此对视了⼀下，眼神中流露出了明显的犹疑。
回到项⽬室，师兄私下把我拉到⼀边谈话，语⽓⾮常坦率：「这个后⾯优先级排低、甚⾄不考虑了。」
师兄告诉我，⼤⽼板的希望肯定是我们 for 所有钉钉⽤户的，甚⾄可以当做 「To C 效率⼯具」来做。这种针对⼤客户、在 PC 端搞深度定制的业务语境，不是上⾯想要的宏⼤故事。虽然现在上⾯也在讨论收费⽬标，但⾛这条路，最终肯定收不成钱。
⽤户如何买单离场
「有钱的捧个钱场，没钱的捧个⼈场。」
⾸先，⽤户表达认可的最直接的⽅式是花钱。
其次，⽤户表达认可的⽅式不只是花钱⸺有时候⽤户再认可也不会花钱，这和场景惯性下的⼼理预期有关。
⽐如搜索，⽤户已经习惯了免费的 Google 和百度，⽽且他们起码达到了「可⽤」⻔槛。⼜⽐如⽹游，很难让已经习惯了先免费⼊场再买装备买道具的⽤户，先付费买断，即便买断价格可能⽐后续可能买装备道具的钱便宜很多。
在企业产品中尤甚。付钱的⼈、使⽤的⼈、受影响的⼈，常常不是同⼀群⼈。⽼板买单，员⼯使⽤；管理员开权限，⼀线员⼯承受新流程；发信⼈获得确定性，收信⼈承担响应压⼒；采购决策者看组织效率，实际使⽤者看⾃⼰⼀天能不能少被打扰⼏次。
所以判断⼀个⽤户是否接受产品，不能只听他说「挺好」还是「不好」。更要看他愿意为这个产品付出什么。
他可以付钱，可以付时间，可以付注意⼒，可以付迁移成本，可以付组织授权，也可以付⼼理安全感。
对 ONE 来说，⽤户愿意每天打开，是⼀种买单；愿意从⽼钉钉路径迁移到 ONE，是更重的买单；愿意接受系统主动排序、提醒和已读，是⼼理安全感层⾯的买单；客户愿意把真实业务流程交给 ONE，则是组织授权层⾯的买单。
离场也不⼀定是卸载。企业软件⾥，⽤户很多时候没有真正「离开」的⾃由。他可以不点，不看，不迁移，不推荐，不授权，不把它纳⼊⾃⼰的真实⼯作流。功能还在⻚⾯上，⼊⼝还在⾸⻚⾥，后台也许还能看到曝光，但⽤户实际上已经离开了。
这也是为什么⽤户研究不能只听嘴上的喜欢。
⼀个⽤户说「这个功能不错」，却不愿意多点⼀次，不愿意改变路径，不愿意让团队使⽤，也不愿意为它承担⼀点⻛险，那么这个「不错」就很轻。相反，⼀个⽤户没有说太多好话，却愿意把⾃⼰的⼯作流程交出来，愿意告诉你哪些消息必须被及时响应，愿意围绕这个系统调整⾃⼰的操作，这才是更重的信号。
⽤户最诚实的回答，往往不在嘴上，⽽在成本⾥。
ONE 的问题也常常出在这⾥。我们以为⽤户在评价「这个产品好不好」，但⽤户其实在衡量：「我要为它多付出什么？」
我在「设计」章始终没有提 one 中发现的设计，⼀⽅⾯因为我没有参与过发现的设计开发，另⼀⽅⾯因为我⾃⼰可能也不是它的⽤户。
我想象不到，在什么情况下，我需要在⼯作中打开⼀个视频流开始刷，也想象不到我是⼀个⽼板时，出于什么⽴场会给员⼯购买这种服务。
预期与履约
⽤户可没有参加过 PRD 评审，他对⼀款产品的预期，来⾃于产品的名称、交互以及他看到的宣称这个产品能做什么的⼴告。
ONE 的 slogan 很⿎舞⼈⼼：「AI ⼯作信息流」「专属⼯作秘书」「让事找⼈」。不过，宣传越模糊，越漂亮，⽤户的⼼理预期也会越⾼。
如果你说⾃⼰是提醒器，⽤户看到提醒，⼤概也就接受了；如果你说⾃⼰是秘书，⽤户就会期待你有秘书的分⼨和能⼒，搞不好还会期待⼀个钢铁侠的⼩辣椒。
这就是预期与履约之间的距离。
ONE 并⾮没有价值。它能整理，能排序，能总结，能提醒，也能识别⼀些待办。但当它被包装成⼀个 AI ⼯作⼊⼝、⼀个专属⼯作秘书时，当整个钉钉赋予它⾸⻚左下⻆这个硕⼤的 AI ⼊⼝时，⽤户⾃然会拿更⾼的尺⼦来量它。
第三章讲过，设计把事情端到了⽤户⾯前。⽤户章要问的是：⽤户是否认为这算履约。
很多时候，⽤户并不是拒绝产品说出⼝的价值，⽽是在拒绝产品没说出⼝的代价。
你说帮我整理⼯作，但没有说会改变我的已读状态；你说让我少漏消息，但没有说会多⼀个容易误触的⼊⼝；你说给我学习内容，但没有说它会在我处理⼯作时突然出现。
钉钉的共创⽂化
钉钉并⾮不重视⽤户，相反，钉钉有很强的共创⽂化。「与⽤户共创」的理念，是我在钉钉蒸馏到的最重要权重之⼀。要从共创⽤户⸺也就是钉钉的客户⸺身上去发现需求、挖掘需求、做出有⽤的产品设计。
我很喜欢共创⽅法论⾥的⼀句话：共创不是去证明你的想法是对的，最终结果才能证明你是对的。
这句话说得很好。好的共创，不是把产品拿给⽤户看，然后等待⼀句「不错」；也不是找⼏个客户站台，给发布会增加说服⼒。好的共创应该让产品团队和⽤户深度在⼀起，通过观察、倾听、交互，挖出真实痛点，发现真实机会。
共创真正有价值的时候，往往不是⽤户夸产品，⽽是⽤户把⾃⼰的⼯作结构摊开给你看。
我们有⼀家智能⼈事相关的供应商公司，是 ONE 的共创对象。他们给过⼀个很具体的场景。他们的客服会在那种既有销售、⼜有客户、⼜有客服的群⾥。群⾥很多消息，是前线销售和客户之间的沟通，客服并不需要每条都看，也不需要每次都出⾯回复。可是这个群⼜不能轻易屏蔽，因为⼀旦客户发消息提问，或者出现需要客服响应的问题，客服必须及时看到并处理。
他们希望系统能做到：只有在客户发消息提问，或者这条消息确实需要客服回复时，才把这个会话的未读红点更明显地标出来，并把该会话置顶前置，成为重要未读。
这个场景⾮常适合 ONE。
因为 ONE 本质上就在做消息优先级排序。我们规划「重要未读」的原理，本来就要判断三件事：什么样的⼈，在什么样的群⾥，发了什么主题的消息。
这不是⼀个空泛的「帮我看消息」。它有清晰的⻆⾊关系，有明确的群场景，有具体的业务责任，也有真实的响应成本。客服不想被所有消息打扰，⼜不能错过真正需要⾃⼰出现的时刻。它要求系统理解的不只是⽂本，⽽是⼯作结构：谁说话，在哪说，说的是什么，这句话是否意味着责任轮到某个⼈。
这类需求才是共创⾥最珍贵的东⻄。⽤户不是在帮你验证⼀张卡⽚，⽽是在把⾃⼰的⼯作现场拆开给你看。
可惜的是，具体到这件事情，我们始终没有真正做起来。
原因也很现实。它涉及⽐较⻓期的开发，需要对群、⻆⾊、消息主题、响应责任做持续建设，不是两三天就能出效果的事情。我们⼀直把它当作⼀个「重要不紧急」的任务。
⽽当时 ONE 的开发，被另⼀套节奏牵着⾛。
这个节奏我们后来叫「每⽇⼀包」。关于它，后⾯「敏捷」章节会详细讲。简单说，就是每天都要做出让⽤户有感知的东⻄，每天都要有东⻄给⽆招验收。于是团队很容易被紧急可⻅的任务拖住，把真正重要但不容易当天展示的事情往后推。
⽤户给出了真实结构，组织未必接得住。
这件事让我后来很⻓时间都觉得遗憾。因为它说明，ONE 并不是完全没有遇到正确问题。正确问题出现过，⽽且很清楚。问题在于，正确问题常常需要时间；⽽项⽬当时最稀缺的，正是时间和耐⼼。
⽤户研究能指出⽅向，但开发重⼼和迭代节奏，决定⽅向能不能落地。
泥泞的⽤户现场
有时候共创⽤户不等于真实⽤户，共创现场也不等于真实现场。
钉钉共创要求⽤户有参与感，并能产⽣⼝碑效应。这当然有价值，但也意味着⽤户会深度介⼊产品过程。介⼊本身就是沉没成本。尤其当⽤户也在某种层⾯上「有求于」钉钉时，他对产品的评判就会变得更委婉、更合作，也更愿意替产品补全意义。
当内测玩家，不是正式服玩家
虽然说，钉钉「共创」的要求是：「不是去证明你的想法是对的，最终结果才能证明你是对的」，但是「共创」过程要求⽤户有参与感，并能产⽣「⼝碑效应」，这也就意味着需要⽤户的深度参与和介⼊，⽽这种介⼊代表着⽤户的沉没成本。尤其当⽤户也在某种层⾯上「有求于」钉钉的时候，这种介⼊会让⽤户对产品做出更委婉的评判。
这让我想到⽹易互娱的《射雕》。2024 年 3 ⽉公测的时候，这款重⾦买下⾦庸射雕三部曲的版权的MMORPG，雄⼼壮志，宣称要做「150 年⻓线运营」。传闻 6 年投⼊ 10 亿， 600 ⼈团队打造。直到25 年 9 ⽉，项⽬发布停运公告，短短⼀年半⽿。
上线前，⽹易内部寄予其厚望，⾼评分通过多轮内部专家评审，上线前的评级应该是 A 或者 S（对⽐蛋仔派对是 B）；但实际上线后数据惨淡，迅速凋零。
核⼼问题是内部评审、内测⽤户和真实市场之间，发⽣了断裂。
项⽬组精⼼挑了⼀组内测玩家，内测期间⼜密集发福利、深度服务和沟通，可以说⽤⼀种⼈弥补上了真实玩家和真实游戏之间的gap，让少数精选玩家理解策划的意图、容忍游戏阶段性的不成熟，甚⾄参与游戏意义的建构。可是正式上线之后，真实玩家不会⾃动继承这些上下⽂。他们没有享受到内测阶段密集的福利，也不会因为设计者曾经在游戏以外的场域，解释过很多次，就天然理解其中的设计。
于是，内测阶段被验证过的「⽤户喜欢」，到了真实市场⾥验证为⼀种梦幻泡影。
ONE 也有⼀样的问题。
我们的「内测玩家」，也就是共创⽤户，他们愿意给时间，愿意反馈，愿意理解产品尚未成熟的地⽅，也更容易被产品团队的叙事、演示和陪伴影响。但共创⽤户不等于真实⼤量使⽤ ONE 的⽤户：真实⽤户不会继承共创时的上下⽂。
共创⽤户⻅过产品经理，普通⽤户只⻅到⼊⼝。
共创⽤户知道我们想做什么，普通⽤户只知道这个东⻄有没有在三秒内帮到他。
共创⽤户可以被密集运营，真实⽤户只能被产品本身运营。
⽐如说 ONE 放在钉钉⾸⻚左下⻆的⼊⼝，共创⽤户知道我们已经排除了不少更加激进和打扰的选项，选择了⼀个影响相对较温和的；但直接接触上线产品的内外⽹⽤户，只会感觉这个⼊⼝很容易误触，以往习惯点这⾥去消息tab，被强⾏影响了使⽤习惯。
内测玩家会替产品补全意义，正式⽤户只验收眼前价值。前者体验的是产品加服务，后者体验的仅仅是产品本身。
这就是为什么很多共创⾥「还可以」的设计，上线后会显得突然刺眼。共创中的解释、陪伴和耐⼼，在正式⽤户那⾥都消失了。剩下的只有⼀个⼊⼝、⼀张卡⽚、⼀次误触、⼀个关不掉的模块。
当⽤户说谎
做⽤户研究，最容易犯的错，是把⽤户说的话当成事实。
这⾥的「谎⾔」，不是说⽤户有意欺骗。更多时候，⽤户是礼貌的、想象中的、处在组织关系⾥的。尤其在企业共创⾥，⽤户⾯对的不是⼀个冷冰冰的问卷，⽽是⼀个合作关系、⼀个供应商、⼀个平台⽅、⼀个可能对⾃⼰组织有价值的机会。他说话时，会天然留余地。
《The Mom Test》⾥有⼀个很有名的提醒：不要问别⼈「你觉得我的想法好不好」。⼤多数⼈会出于礼貌、⿎励或想象，给你⼀个好听但⽆⽤的答案。真正有效的问题，应该问过去事实、具体⾏为和真实成本。
⼀句「挺好的」，也许只是礼貌；⼀句「以后会⽤」，也许只是当场想象；⼀句「这个⽅向有价值」，也许只是对⽅向的认可，和真正迁移⼯作流之间，还隔着很⻓⼀段路。
企业场景⾥，这层偏差更重。
⽼板说「这个对员⼯很好」，员⼯未必这么感受；管理员说「可以推」，⼀线未必愿意接；共创客户说「⽅向不错」，也未必意味着正式上线后，普通⽤户能忍受误触、打扰和额外路径。
⽤户还会说⼀种「想象中的真话」。
⽐如学习内容。理论上，没有⼈会反对学习；理论上，paper、⾏业资讯、管理知识都很有价值。可当⽤户正在处理消息、⽇程和待办时，系统突然把他带进⼀个学习流，实际感受可能就是「像⼴告」「占地⽅」「⼯作时不想看」。
他并没有撒谎。他只是在两个不同场景⾥，给出了两个都真实的答案。
所以⽤户的话当然要听，但不能照单全收。要听话⾥的意思，也要看话后的成本；要看他当场怎么说，也要看他回去怎么做；要看他愿不愿意多点⼀次，愿不愿意改习惯，愿不愿意让团队使⽤，愿不愿意把真实流程交出来。
产品研究⾥最诚实的答案，常常不在嘴上，⽽在这些成本⾥。
当设计在计划外的⽤户群体奏效
ONE 的核⼼共创对象⼀直是⽼板，KP，管理者，信息化负责⼈和采购决策者。在第⼆章「定位」的讨论中，也阐释过 ONE 的定位是⾯向消息爆炸的枢纽⻆⾊和管理者，故⽽也是优先围绕移动端展开设计。
这个判断有道理，管理者的消息确实更多，决策链路更⻓，也更需要信息过滤。但管理者毕竟凤⽑麟⻆，真实⼤量使⽤ ONE 的⼈，是沉默的⼤多数。
当时有⼀个产品同事去⼴东拜访碧桂园。对⽅领导层⾮常重视 ONE 的能⼒，希望⽤卡⽚的形式，动态、智能地安排保安和保洁每天的⼯作内容和顺序。
⽐如先巡逻，再清洁，再拍照反馈。做完⼀个任务，就 check 掉⼀张卡⽚。
这个 case 很具体，也很通情达理。基层和流动性⽐较⾼的⼯作者，不需要学习复杂系统，也不需要⾃⼰判断优先级，只要按 ONE 的提醒往下执⾏即可。
他周⽇赶回来参加了那周的汇报，兴冲冲向⽆招介绍了这个 case。
不过⽆招并不欣赏这个共创 case。他的判断是，ONE 不是要服务保安保洁，⽽是要服务⽼板、管理者和⾼净值⼈群。
其实从这个分歧点延伸出去，不难发现，主动服务⾥有⼀个很难绕开的分岔：_越是主动、越有思考的⼯作者，越需要保留对⾃⼰⼯作顺序和⼯作⽅式的掌控。_AI 可以辅助他，可以记忆，可以提醒，但不该⽤很多强规则打断他已经形成的⼯作节奏。
反⽽是⼯作内容相对标准、任务链路相对明确的⼈，更可能接受卡⽚式的主动安排。
这种计划外的⽤户群体⽐计划内的⽤户群体更诚实。因为他们不是被产品叙事召唤来的，⽽是被具体价值吸引来的。⼀个设计在⽬标⽤户那⾥不成⽴，却在另⼀群⼈那⾥成⽴，这不是偏题，可能恰恰是在提醒我们：真正的产品机会不在原先想象的地⽅。
这就回到了最开始的问题：ONE 到底先服务谁？
如果服务管理者，就不能假装他们愿意被系统安排⼯作顺序。
如果服务执⾏者，⼜不能假装这是⼀个⾼净值⼈群产品。
定性研究：当⽤户是⽆招
写到这⾥，就不得不回到⽆招。
不是因为⽤户章应该突然变成⼀段⽼板画像，⽽是因为前⾯的许多问题⾛到这⾥，会集中到⼀个更深的原因上：ONE ⾯对的「⽤户」，并不只有客户、共创对象和普通员⼯，也包括⼀个极强势、极⾼权重、极有产品表达欲的⽤户⸺⽆招本⼈。
⽤户研究⼀般分为定性研究和定量研究。各司各组织的策略倾向不同。就我观察，字节会更喜欢做定量研究，强调北极星指标、漏⽃和数据验证；钉钉更喜欢做定性研究，强调共创中的具体⽤户、具体场景、具体需求。
有的时候我真的不太懂为什么⼤家特别区分 to B 和 to C 的产品，或者特别区分前台、中台、后台的产品。这些只是标签，是⾏业为了⽅便沟通发明的分类框架。但他们的本质是⼀样的：你要明确你的⽤户是谁，⽤户的⽬标是什么。我们的⽬标就是帮他达成他的⽬标。我曾经在⽹易伏羲 lab ⼯作。我们的客户是内部的游戏⼯作室，⽐如我服务过倩⼥端游，服务过逆⽔寒⼿游，⼯作室的⽬标是什么？⼯作室的⽬标是玩家的粘性，付费。他们采购伏羲的服务，本质上是希望。外包出去⼀部分⼯作⽬标给我们达成。⽆论他们提的需求是什么，我们在⽬标上。要和⼯作室对⻬，这才是真正的以⼼印⼼，⼼⼼不异。
在钉钉这⾥，服务⽆招也是⼀样的，和服务 C 端群体没有什么很⼤的区别。只是前者更加定性研究，或者更加定量研究⽽已。
从这个意义上说，⽆招既是钉钉的⼤⽼板，也是钉钉的⼤⽤户。研究和服务⽆招，也是⼀种⽤户共创、定性研究、⼀种特殊情况的讨论。
但定性研究不是听到⼀个⽤户说什么，就原样照做。定性研究要挖原因，挖动机，挖情绪，挖真实痛点，挖底层⾏为逻辑。它不只看数据多少，也不只问⽐例，⽽要搞清楚：⽤户为什么这么做，怎么想，在意什么，隐藏诉求是什么。
要服务你的服务对象的⽬标，⽽不要服务他说出⼝的需求，⽽要观察他在现实和社媒上如何⾃我表达，⽣活中究竟如何⾏为。
他的头像是⼀个武侠形象的⿊⽩背影，上⾯写着「⽆招」两个字。这个符号本身就很有意思：武侠、背影、招式之外的招式，既有江湖⽓，也有强烈的⾃我命名。再看他过去公开演讲⾥表达的态度，看他在会议⾥如何提问、如何打断、如何兴奋、如何不耐烦，看他⾃⼰的钉钉使⽤数据、使⽤习惯和提出的具体业务需求，都能看⻅⼀套相当⼀致的产品⼈格。
他是⼀个⾼密度、⾼能动、⾼控制欲的⽤户。他处理⼤量消息、会议、组织信息，需要快速推进，需要确定性，也需要⼀个系统把事情往前推。
但⽆招不是普通⽤户。
他的权⼒位置、信息密度、注意⼒阈值、⼯作节奏，都和普通员⼯不同。**他是 CEO，是发信⼈，是组织⽬标的承压者，也是钉钉历史成功经验的携带者。**他觉得已读重要，普通员⼯可能感到的是被迫承担；他想要强推进，普通⽤户需要的是缓冲和控制；他喜欢主动掌控，普通员⼯可能先问「我能不能关」。
更重要的是，⽆招回归钉钉时，身上背的不只是⼀个⽤户的痛点。
2025 年 3 ⽉底，阿⾥拟收购⽆招创业公司「两氢⼀氧」的投资⼈股份，⽆招回任钉钉 CEO。阿⾥当时的主线是「⽤户为先、AI 驱动」，钉钉被放在 AI To B 的关键⼊⼝位置。到 2025 年底，阿⾥合伙⼈体系在 2025 财年从 26 ⼈缩到 17 ⼈，席位更加稀缺。与此同时，周靖⼈因通义 / Qwen 体系晋升合伙⼈，吴嘉也被放到千问 C 端事业群，负责千问、夸克、AI 硬件、UC 等⼊⼝型业务。
AI 时代的「⼊场券」正在被重新分配，阿⾥内部的牌桌也在重新盘点坐席。合伙⼈身份正在从历史荣誉变成现役战功，从元⽼共同体变成战略作战席位。
张勇、戴珊、彭蕾、俞永福等⼈的退出，意味着上⼀阶段阿⾥的组织 memory 被压缩；蒋凡进⼊合伙委员会，则意味着阿⾥重新把电商主战场交给能打仗的⼈。吴泳铭时代的阿⾥，不再试图维持每个⼭头的体⾯，⽽是在「电商」和「AI + 云」两条主线上重排座次。
在这样的背景下，⽆招回归钉钉，就被寄予别样的厚望。背井离乡的创始⼈重归故⾥，他必须证明钉钉不是旧时代的企业 IM 和 OA，⽽是能成为阿⾥ AI To B 的关键⼊⼝。吴妈召他回宫，恐怕也不是想要 yesterday once more，⽽是想到 2014 年的⽆招，破釜沉⾈，草创新业，希望这匹⽼骥伏枥，尚能饭⽿。
所以 ONE 的压⼒，从⼀开始就不是纯产品压⼒。它背后有⼀道更硬的组织命题。
这也解释了为什么 ONE 这个⽆招回归后最重视的项⽬，在初始阶段过度追求「⼤⼊⼝」「新形态」「发布会表达」。因为它服务的不只是⽤户，也服务⽆招的⾃我价值证明，以及他在阿⾥新权⼒结构⾥的位置证明。
⽤户需求是第⼀层，集团战略是第⼆层，个⼈再⼊场是第三层。ONE 的种种纠结挣扎，恰恰来⾃这三层⽬标经常不完全⼀致。
不过，⽼板的身份认同，不是⽤户的⽬标。
这句话后来反复在我脑⼦⾥回响。⽆招作为⽤户是真实的，但他是⼀个极端⽤户；⽆招作为 CEO 是关键的，但他不是普通员⼯；⽆招作为产品经理是敏锐的，但他的兴奋点不等于⼤众⽤户的兴奋点。
如果把⼀个极端⽤户的痛点，当成全体⽤户的路径；把⼀个 CEO 的身份任务，当成产品本身的⽤户⽬标；把⼀个组织战役的胜负，压到⼀个移动端⼊⼝上，产品就容易⾛进怪圈。
延伸：「千⼈千⾯」的AI产品服务，本质是奢侈服务下放
还有⼀个后来才慢慢想明⽩的点：AI 的⼀⼤价值，是把奢侈品级别的服务下放给普通⼈。
奢华酒店会记住客⼈的偏好：喜欢什么⽔果、枕头要多⾼、欢迎卡写什么称呼、上⼀次住在哪⼀间房。普通酒店通常做不到。不是不想做，⽽是成本不允许。⼀个⼈能被记住，是因为他⾜够重要，或者付了⾜够多的钱。
⼯作系统⾥也是⼀样。⽼板、核⼼客户、关键⼈物，天然有⼈替他筛信息、排优先级、做提醒、记偏好。他们已经享受了⼈⼯个性化服务。普通员⼯没有。普通⽤户⾯对的是同⼀套默认规则、同⼀块⼊⼝、同⼀种红点、同⼀份信息洪⽔。
所以，越是已经被⼈⾁个性化服务的⼈，越不容易意识到普通⽤户为什么需要「⾃定义⾃⼰的 ONE」。⽆招看到的 ONE，本来就不是⼀个标准⽤户看到的 ONE；他的反馈链路、⼈⼯解释、问题响应、产品修补，天然围着他转。对他来说，系统不够个性化，不构成强痛点；对普通⽤户来说，这恰恰是 AI 最应该补上的差距。
这也是 ONE 当时很可惜的地⽅。ONE 早期经常试图⽤⼀个个硬规则，去 cater to 以⽆招为⾸的少数 KP，然后期待它⾃然服务好⼤多数⼈。
可现实是，⼤多数⼈的⼯作，并不是少数 KP ⼯作⽅式的缩⼩版。⽤户真正需要的，可能不是⼜多⼀个统⼀⼊⼝，⽽是⼀个逐渐学会「我是谁」的⼊⼝。AI 如果只能把⽼板级体验再送给⽼板，价值并不⼤；它更该做的，是把过去只有少数⼈享受得起的贴身服务，变成每个普通⼯作者也能拥有的⽇常。
谁重要、哪个群重要、什么消息该回、什么时候该提醒、发现要不要看、⼊⼝放哪⾥舒服⸺这些事情都⾼度依赖个⼈⻆⾊、组织关系、⼯作阶段和⼼理阈值。⼀个⽼板、⼀个客服、⼀个销售、⼀个普通员⼯、⼀个信息化负责⼈、⼀个项⽬经理，对「重要」的理解完全不同。
到最后，我们再回看各种⽤户反馈，会发现⼀个有意思的现象：
除了明确提出想关掉「发现」⼊⼝，以及解决左下⻆ AI ⼊⼝误触的问题，⽤户需求分布⾮常不集中。
这个现象不能简单理解成「⽤户没有需求」，也不能理解成「⽤户说不清楚」⸺它更可能说明：⽤户真正需要的，不是⼜⼀个统⼀硬规则，⽽是更个性化的服务。
于是⼜可以 call back 设计章的尾声：形式不该凌驾于内容。
以有涯的设计求⽆涯的⽤户需求，⽆异舍本逐末，缘⽊求⻥。
敏捷第五
钉钉是个勤⾏。
什么是勤⾏？勤⾏就是早餐店，杂耍摊，⼿⼯业，是冬练三九，夏练三伏。
这句话没有⼀丝讽刺。恰恰相反，这是我对钉钉产研最深的敬意和赞美。我⻅过不少团队，也在不同公司做过产品，但钉钉的响应速度和开发配合程度，确实罕⻅。
有个⼯龄六年多的同事后来去了字节，某个周末聊起来，他感慨：「我感觉字节没钉钉快。」我问是哪⽅⾯的快，他秒答：「开发速度。」
「字节没有钉钉快？」
「没有钉钉快。」
半晌他⼜补了⼀句：「字节流程还是慢。」
于是我们⼀起叹⽓：「真是⽩瞎了。」
听到「开发速度」「流程」，我⼀下⼦想起项⽬室的⽇⽇夜夜。
⽼板们上午在群⾥提的要求，晚上必须能打进彩虹包⾥验收。今天改交互，今天出稿，今天调整规则，今天进包，今天指出问题，今天给⽅案。很多时候，连「明天」都显得奢侈。
我们称这套机制为「每⽇⼀包」。
这套机制当然有它的好处。它让团队⼀直在动，让问题不过夜，让产品每天都有新东⻄。对于⼀个新项⽬，尤其在发布会前后，这种速度会带来强烈的战时感：所有⼈都在场，所有问题都被盯着，所有变化都能迅速看⻅。
ONE 能在短时间内形成复杂的移动端框架，能把消息、待办、⽇程、会议、发现、AI 指令、播报、总结等⼀系列能⼒塞进⼀个新⼊⼝，靠的正是这套勤⾏⼿艺。
所以，复盘 ONE 时，不能把问题归结为「团队不努⼒」。
甚⾄恰恰相反，很多问题发⽣在⼀种过度努⼒之中。
在「发⼼第⼀」章节中我提到，「智能是平权的，但是 context 是不平权的」。其实还有⼀件东⻄是不平权的，那就是⼈的创造性和主观能动性。
针对「搭建企业Agent」的愿景和效果，其实是⾮常共识的。⼤家对于 AI 提效的愿景已经⾮常趋同⼀致，拉任何⼀个⼈上台，照「I have a dream」的发⾔稿起⼿，也能说出不少⼦丑寅卯来。
说起来原理也简单。那些你放⼼布置给⼀个刚⼊职不久的同事⼲的活，将来都可以放⼼交给 AI：查资料、整理会议、建⽇程、写周报、跟进事项、汇总进展、把散在各处的信息归拢成⼀个可⾏动的判断。它不⽤睡觉，不怕重复，理论上还能「越⽤越懂你」。
然⽽，知道最终幻想是什么样，实际情况与之仍然隔着⼀⽚ limbo。
造成实现效果差异的，除了各产品既有的数据和⽣态护城河，最⼤的变量就是产研团队本身。⼀个团队是否能把愿景切成路径，把路径切成任务，把任务做成可⽤产品；是否能在每天都有⼈催促变化时，仍然保留⼀点建设地基的耐⼼；是否能在「看起来很快」和「真的在接近问题」之间，分出轻重。
这就是「敏捷第五」要写的事。
上⼀章写⽤户。⽤户告诉我们，ONE ⾥有些东⻄成⽴，有些东⻄不成⽴；有些⾏为⽤户愿意迁移，有些⾏为⽤户不愿意交出来。到了这⼀章，问题往下⾛⼀层：既然真实问题已经出现，组织有没有能⼒持续做对的事？
这不是简单的开发速度问题。
钉钉很快。ONE 也很快。问题在于，跑得很快以后，谁来决定⽅向；每天都有交付以后，什么会被做深，什么会被挤掉；敏捷究竟是在接近真实问题，还是在更快地、被动地响应，⼀条⼜⼀条新的信息流。
迭代与汇报节奏
我有朋友在腾讯 WXG ⼯作，有时候私下⾥我们会对⽐两边产研的节奏，发现⼀个很有意思的现象：微信是默认⼀动不如⼀静，如⽆必要，不增加产品改动；钉钉反之。
（叠甲：到这⼀步，我并没有认为⼆者孰优孰劣，这只是由产品性质和⻛格决定的、中性的产品迭代的选择。有时候⽤户也乐意看到产研团队折腾，毕竟钉钉是付费的 SaaS 产品，有时候你不折腾，⽤户觉得钱没花到位，或者产研团队在⼫位素餐。）
钉钉的敏捷，⾸先体现在对⽆招信息流的响应。
⼀般早上九点到⼗⼀点，有问题，⽆招会直接发给技术负责⼈或管理层群。管理层各⾃响应，领⾛问题。⼀个⼩时内反馈打算怎么处理，⼆⼗四⼩时内交付。
这很像⼀套最⾼优先级的问题单系统。
AI 创建⽇历不符合预期，⽴刻查；消息列表抖动，⽴刻看；导航栏⾥标题截断，⽴刻讨论；⽤户说「不智能」，⽴刻追问原因；某个外部截图、某个内⽹帖⼦、某个客户反馈、某个竞品动作，只要进⼊⽆招视野，就会获得极⾼权重。
这套机制的好处显⽽易⻅。⽼板不隔层，不装聋，不等周报。看到问题就问，问了就要解。许多企业做不到这⼀点。很多问题在层层传递中已经失真，到了⽼板那⾥只剩⼀句「持续优化中」。钉钉不是。钉钉很多时候是问题刚冒头，⼑已经递过来了。
敏捷从来不是抽象的。组织总是对某些⼈、某些事、某些信号更敏捷。问题并不是「钉钉敏不敏捷」，⽽是「钉钉对谁敏捷」。
当⽆招的信息流成为最⾼优先级队列，团队就会天然围着它转。被他看⻅的问题，会迅速进⼊战时处理；没有被他看⻅的问题，即使⽤户反复提、产品反复想，也容易留在「重要不紧急」。
这就是 ONE 后期很典型的处境。
⽆招看到列表抖动，列表抖动要解。⽆招觉得消息助理不智能，消息助理要⻢上给出体感。⽆招对 Agent OS 有新想法，框架⽴刻进⼊讨论。可⽤户个性化、⾃定义主⻚、偏好学习、⻓期记忆、重要消息反馈闭环，这些更像地基的事情，很难⽤⼀天的包证明⾃⼰。
于是，敏捷像⼀把很快的⼑。
它能切开眼前的结，也能把⻓期问题切碎，分散到每天的改动⾥。
每⽇⼀包
每⽇⼀包，本质上是⼀套可⻅变化的⽣产机制。
我在刚接触到这个概念的时候，说实话我觉得它很好，是⼀种对⽤户的负责和⼀种对产研团队⾃⼰的严格要求。但在具体的执⾏中，我越来越不敢完全苟同，并且意识到其中的⻛险和害处。
它退化成了⾼管意志下的⼀场实验。
它偏爱：今天能看⻅的，今天能截图的，今天能被⽼板验收的，今天能写进 changelog 的。
它不喜欢：需要⻓期建模的，需要打通底层数据的，需要反复验证才有效的，⼀开始看不出效果、但半年后决定上限的。
这不是某个⼈的错，是机制本身的偏好。
⽐如，我⼀直想做⽤户个性化设计⾃⼰的 ONE 主⻚。每个⼈的⼯作不⼀样，重要的⼈不⼀样，常⽤模块不⼀样，对提醒的忍耐度也不⼀样。⼀个销售、⼀个客服、⼀个管理者、⼀个普通研发、⼀个信息化负责⼈，理想中的 ONE 不可能⻓成同⼀张脸。
这件事在⽤户章⾥已经有答案：⽤户需要的，未必是⼜⼀个统⼀硬规则，⽽是系统逐渐学会「对我来说，什么重要」。
可这件事很难进⼊每⽇⼀包。
它要做偏好，要做配置，要做记忆，要做反馈闭环，要允许⽤户关掉⼀些东⻄、固定⼀些东⻄、调整⼀些东⻄。它不会在第⼀天就让⼈惊呼「哇，变了」。甚⾄它最好的状态，是⽤户⽤久了之后觉得顺，觉得少被打扰，觉得这个系统越来越像⾃⼰的。
这种价值很难汇报。
更关键的是，⽆招并没有这个强诉求。
因为他看到的产品，本来就不是标准⽤户看到的产品。围绕他的反馈链路、问题响应、⼈⼯解释、产研⽀持，已经构成了⼀套「⼈⼯个性化」。他不需要⾃⼰慢慢配置系统，也不需要忍受⼀个陌⽣⼊⼝⻓期不懂⾃⼰。
他的问题被看⻅得太快了，他的需求被响应得太快了。
于是，正确问题被留在旁边。每天交付的，是更容易被看⻅的变化。
汇报技巧
翻到去年 8 ⽉份记录的⽆招汇报技巧，截图留念，以后有需要的朋友⾃取。
Beating Around the Bush
其实在产品讨论和开发阶段，我就感到我们「在回避真正问题、只做表⾯优化」。
这个底层是⾮常傲慢的，我们希望⼀下⼦上来就猜准⽤户想要什么，然后推荐。有时候客户明明明确说了，有⼀些个性化的需求，希望能指挥AI做xxx，但我们纠结在⾃⼰的能⼒域⾥，⿎励⽤户削⾜适履。明明调研下来，绝⼤多数⽤户都不能在做好⼼理准备之前，直接点开消息看未读，我们还硬着头⽪做。
⽤户怕下⼀张卡⽚是什么，于是做横滑头像，让他先看到⼀点预告；⽤户怕完全划过去就已读，于是做 Peekaboo，让他在没有完全松⼿前处于⼀种「预读」；⽤户觉得消息不清楚，于是补摘要、调排序、改展现；⽤户对卡⽚焦虑，就想办法给更多跳过、展开、预览。
这些⼯作不能说没有价值。每⼀项都是在缓解痛感。
但它们共同绕开了同⼀个根问题：这个已读到底该不该发⽣？
响应快，是不断回答「怎样让这个设计没那么痛」。迭代深，是敢问「这个设计是不是⼀开始就不该这样」。
ONE 在已读问题上，⼤量时间花在前者。我们很敏捷地修补了很多地⽅，却始终没有敏捷地回到最初的判断。
这就像房梁歪了，却每天换窗帘、擦地板、调灯光。屋⼦确实越来越像样，住在⾥⾯的⼈还是觉得不安。■
通弘网提示：文章来自网络，不代表本站观点。
