【摘录】置身钉内

本文为阅读《置身钉内》时的摘录整理。
由于原文来自 PDF 拷贝，存在断行、错序和格式丢失；以下版本按主题重新分组，修正明显 OCR/复制错误，并尽量保留原意。

阅读背景

原文不是一组彼此独立的产品观点，而是一份约 7.5 万字的现场复盘。作者于 2025 年 6 月进入钉钉 ONE 项目，参与它从 0 到 1、发布、共创、运营再到收缩的过程。ONE 试图把消息、日程、待办、会议、文档和审批重新组织成一个由 Agent 驱动的工作信息流，让 AI 从“回答问题”走向“主动发现和推进工作”。

作者真正追问的是：理想如何被翻译成目标，目标如何被拆成需求，需求又如何在组织里变形、落地，并进入真实的用户现场。以下保留原摘录全文，并在每节前补充“背景 → 冲突 → 选择 → 结果 → 结论”的推导脉络。

一、产品的发心与定位

上下文与推导

ONE 同时承载了四层发心：

1. 用户发心：工作信息分散，用户依赖自己的记忆和注意力，把消息、日程、待办等勉强串起来。ONE 想让重要的事自己浮上来。
2. 产品发心：钉钉需要一个 AI 时代的新入口，证明自己不只是旧办公软件，还能重新组织工作。
3. 组织发心：无招回归后，需要一场新战役聚人心、提士气、改形象。ONE 既是产品，也是旗帜。
4. 商业发心：模型能力和 token 需要真实场景消化，钉钉的大量工作数据看起来正好可以承接。

这些目标单独看都合理，叠在一起却要求团队不断回答取舍：先替用户减负，还是先服务发布会表达；先做所有人的入口，还是先做少数深度用户的需求；先让事情被看见，还是先让事情被做完。

定位阶段又出现了两组更具体的矛盾。第一组是老板与员工：管理者是工作的发起者，需要督办和掌控；普通员工是承接者，更需要减少打扰。第二组是发信人与收信人：钉钉早年的已读未读、DING 等能力站在发信人一侧，ONE 对外却承诺做一个替收信人过滤噪音的 AI 秘书。

同时，ONE 还要在“大基数、高频、付费”之间找交点：覆盖面越广，痛点越容易浅；进入消息、日程等高频行为，又容易变成旧能力的重新摆放；要让用户付费，则要解决更深的业务问题，越深又越像客户定制。

原摘录

当一个产品的发心又多又没有主次的时候，就会成为一个贪心而焦虑的产品。

产品的发心，就是它的发起人最原始的出发点，主要有以下几类：

• 解决某个尚未被解决的具体问题；
• 提升解决某个问题的效率；
• 服务好某个具体的人群；
• 推广某种理念；
• 销售某种资源；
• 等等。

要说清产品定位，需要明确回答四个问题：

1. 用户定位——“为谁”
   1. 目标用户是谁？不是谁？
   2. 用户的关键特征是什么：规模、行业、角色、习惯？
2. 场景定位——“在哪用”
   1. 用户在什么情境下想到这个产品？
   2. 它是高频日常工具，还是特定场景的解决方案？
3. 价值定位——“解决什么问题”
   1. 产品提供的核心价值是什么？
   2. 用户原本愿意花费多少钱、时间或其他资源，来达成这种价值？
4. 竞争定位——“为什么是我们”
   1. 和替代方案相比，差异化在哪？
   2. 这个差异化是否可持续？

当这些问题能够一句话说清时，产品就有了清晰的定位。

定位不是命名，也不是一句对外口径。定位是一次又一次取舍以后，仍然留下来的方向。ONE 最大的遗憾也即在此：有过很多方向，每个方向都有道理，却没有来得及把其中任何一个方向走到足够深。

有的时候我真的不太懂为什么大家特别区分 to B 和 to C 的产品，或者特别区分前台、中台、后台的产品。这些只是标签，是行业为了方便沟通发明的分类框架。但它们的本质是一样的：你要明确你的用户是谁，用户的目标是什么。我们的目标就是帮他达成他的目标。

二、AI 工作产品：回到原场域，而不是制造控制感

上下文与推导

ONE 选择卡片，是因为卡片能把“主动服务”翻译成直观的移动端形态：AI 把消息、待办、日程和会议摘出来，像秘书把待批的事项提前摆到桌面。它轻巧、有 AI 感，也很适合演示。

但卡片先解决了“如何展示”，没有回答用户原来怎样完成工作。旧消息列表虽然不够智能，却同时承担浏览、预判、查找、分组、置顶、标记未读和管理会话等职责。用户从原场域迁移到 ONE，需要支付三种成本：

1. 入口迁移：相信从 ONE 开始比从消息页开始更省事；
2. 心智迁移：从按工具找内容，转向相信系统判断哪件事重要；
3. 责任迁移：系统主动把事情端到眼前后，用户可能提前承担回复和处理责任。

三个设计卡点把问题暴露得最清楚：

• 服务端异步生成的消息卡片可能重复或延迟，甚至留下编辑前、撤回前的内容；对高频变化的 IM 来说，不实时不仅是体验问题。
• 分组提供稳定的语义归属，排序提供动态的行动优先级；把分组硬搬进卡片，会拆散用户熟悉的工作结构。
• 用户在原消息页可以先看群名、发信人和 last message，再决定何时点开；ONE 直接展示并标记已读，相当于替用户签收了尚未准备处理的任务。

已读问题尤其说明了收益和成本的错配：发信人只多得到一个无法区分来源的“已读”，收益很弱；收信人却失去处理余地，承担“客户或老板看到我已读不回”的压力。底层规则不变，横滑、预览和跳过等交互只能不断补洞。

团队后期重新从用户动作拆题，不再先问“卡片还能怎么做”，而是先问用户如何读、写和管理消息。放弃大包大揽、收缩到重要内容覆盖、重点对象补漏、复杂查询和沟通辅助后，留存反而上升。

原摘录

读者再看到一个 AI 助手、一条智能摘要、一个自动提醒、一套 Agent 方案时，不只观察它的交互是不是够酷，而会追问：

系统里原本这个功能是怎么实现的？AI 做了正功还是负功？用户在获得某种好处的时候，是否付出了更大的隐形成本？AI 如何改变了原本的责任流向？

实时性问题，其实就是对标原场域的一个细分场景。

讨论和走查对标原场域，其实就是在计算用户的迁移成本。

寻找甜区的思路，主要是找到“用户有体感、会出现 Aha moment 的价值”和“设计开发成本低”的交集。

形式不该凌驾于内容。

回头看，ONE 的设计教训不在于卡片不能做。任务识别、会议准备、快速审批、AI 回复都证明，卡片和 AI 可以很好地承接某些工作。真正的问题在于，工作产品里的“看见”，从来不是中性的。

看见一条消息，可能意味着已读；看见一个待办，可能意味着责任；看见一场会议，可能意味着准备；看见一个总结，可能意味着后续分发。系统把事情提前端到用户面前，不能只计算阅读效率，还要计算责任成本。

设计也不只是把界面做好看，而是安排权力和责任怎么流动。

AI 工作产品的好设计，不是让系统更早发现工作，而是让用户更好地掌握工作。

如果没有做到这一点，所谓的主动服务，只是变成对用户傲慢而爹味的控制欲。

越是主动、越有思考的工作者，越需要保留对自己工作顺序和工作方式的掌控。AI 可以辅助他，可以记忆，可以提醒，但不该用很多强规则打断他已经形成的工作节奏。

如果你说自己是提醒器，用户看到提醒，大概也就接受了；如果你说自己是秘书，用户就会期待你有秘书的分寸和能力，搞不好还会期待一个钢铁侠的小辣椒。

这就是预期与履约之间的距离。

三、用户研究：不要听他说什么，要看他付出什么

上下文与推导

在企业软件里，付钱的人、使用的人和承受后果的人常常不是同一群人：老板买单，员工使用；管理者获得确定性，收信人承担响应压力。因此，“喜欢”不是单一态度，而是用户是否愿意支付某种成本：

• 是否愿意每天打开；
• 是否愿意改变熟悉路径；
• 是否愿意让团队使用，并交出真实业务流程；
• 是否愿意接受系统主动排序、提醒和已读；
• 是否愿意承担误判、权限和心理安全风险。

共创用户还会因为得到产品经理的解释、陪伴和密集响应，替未成熟的产品补全意义；正式用户只会看到入口、卡片、误触和关不掉的模块。共创中得到的“还可以”，不一定能迁移到真实市场。

原文给出过一个更重的用户信号：客服身处销售、客户和客服混合群，不想读完所有消息，却不能错过真正需要自己响应的问题。这个场景有明确的角色关系、群场景、业务责任和遗漏成本，很适合做“重要未读”。但它需要长期建设角色理解、消息语义和责任判断，无法在两三天内演示，因此一直停留在“重要不紧急”。

《The Mom Test》的作用也在这里：不是让产品经理怀疑用户，而是把问题从“你喜欢吗”“以后会用吗”，换成过去的事实、具体行为和真实成本。用户对学习内容的抽象认可，与他工作时嫌内容流像广告，并不矛盾；那是两个场景里的两个真实答案。

原摘录

首先，用户表达认可的最直接方式是花钱。

其次，用户表达认可的方式不只是花钱——有时候用户再认可也不会花钱，这和场景惯性下的心理预期有关。

用户最诚实的回答，往往不在嘴上，而在成本里。

做用户研究，最容易犯的错，是把用户说的话当成事实。

这里的“谎言”，不是说用户有意欺骗。更多时候，用户是礼貌的、想象中的、处在组织关系里的。尤其在企业共创里，用户面对的不是一个冷冰冰的问卷，而是一个合作关系、一个供应商、一个平台方、一个可能对自己组织有价值的机会。他说话时，会天然留余地。

《The Mom Test》里有一个很有名的提醒：不要问别人“你觉得我的想法好不好”。大多数人会出于礼貌、鼓励或想象，给你一个好听但无用的答案。真正有效的问题，应该问过去事实、具体行为和真实成本。

定性研究不是听到一个用户说什么，就原样照做。定性研究要挖原因，挖动机，挖情绪，挖真实痛点，挖底层行为逻辑。它不只看数据多少，也不只问比例，而要搞清楚：用户为什么这么做，怎么想，在意什么，隐藏诉求是什么。

你的服务要服务对象的目标，而不要服务他说出口的需求；要观察他在现实和社媒上如何自我表达，生活中究竟如何行为。

《The Mom Test》要点整理

核心思想：不要问别人“觉得你的想法怎么样”，而要问他们“生活中实际怎么做的”。

人们会对你的想法撒谎——出于礼貌、善意、不想伤害你。但他们不会对自己过去的行为撒谎。这本书的核心就是教你如何设计问题，让对方无法给你虚假的鼓励，从而获得真实的市场信号。

三条黄金法则：

1. 聊他们的生活，而非你的想法——不要推销，要挖掘真实痛点。
2. 问过去的具体事实，而非未来的假设——“你上次怎么做的？” > “你会不会用？”
3. 少说多听，让对方多讲——你说得越多，学到的越少。

五个关键概念：

1. 恭维是毒药（Compliments are Poison）

   当有人说“哇，这个想法太棒了！”——你什么都没学到。恭维让你感觉良好，但信息量为零。它是最危险的反馈形式，因为它让你误以为自己在正确的方向上，实际上对方只是在表达礼貌。

   把恭维当作警报信号。一旦听到赞美，立刻转回具体问题：“谢谢，那你现在具体是怎么处理这件事的？”

2. 挖掘承诺和推进（Commitment & Advancement）

   对话结束时，如果对方没有给出真实承诺，这次对话就是失败的。所谓真实承诺，是对方愿意拿出自己的时间、金钱或声誉来支持你：

   • 愿意预付费；
   • 愿意安排时间参加试用；
   • 愿意把你介绍给决策者；
   • 愿意签意向书。

   嘴上说“好棒”但不采取任何行动 = 毫无价值。没有承诺的对话就是失败的对话。模糊的“不错”是你能得到的最差结果，因为它既没有验证也没有否定，只是浪费了你的时间。

3. 寻找真相的三层挖掘法

   客户反馈有三个层次，你需要一层层往下挖：

   • 表层：他们说想要什么，最不可靠——人们不擅长预测自己的行为；
   • 中层：他们为什么想要，有价值——揭示动机和痛点；
   • 深层：他们目前实际怎么做、花了多少钱和时间，是黄金信息——行为不会说谎。

4. 避免三种致命错误

   错误	表现	后果
   钓鱼式提问	引导对方说你想听的话	得到虚假验证，自欺欺人
   过早推销	一开口就介绍产品	对方切换到“礼貌模式”，不再说真话
   接受模糊回答	对方说“这挺有意思的”你就满足了	你以为验证成功，其实啥也没验证

   这三个错误的共同点是：它们都让你感觉很好，但实际上让你离真相更远。

5. 对话的正确结构

   每次客户对话应该遵循这个流程：

   开场 → 提出宏观问题 → 深入具体场景 → 追问行为细节 → 请求承诺/推进 → 结束

   每次对话结束，你应该带走三样东西：

   • 至少一个你之前不知道的事实；
   • 对方的一个具体承诺，或明确拒绝——拒绝也是有价值的信号；
   • 清晰的下一步行动。

实操要点：

1. 找对人

   不要随便找人聊。你需要找到真正有这个痛点的人，而且最好是有决策权和预算的人。早期客户不等于所有人——你要找的是那群痛得最厉害、最迫切需要解决方案的人。Rob 称之为 Early Evangelists。这群人愿意容忍你产品的不完美，因为他们的问题足够痛。

2. 设置对话场景

   • 非正式场合效果最好：咖啡、会议间隙、行业活动；
   • 不要说“我想做个调研”，因为对方会进入防御模式；可以说“我在学习这个领域，想请教你”；
   • 对话控制在 15-20 分钟，短而高效。

3. 记录与整理

   • 对话后 5 分钟内记下关键笔记——记忆衰减得比你想象的快；
   • 和团队分享笔记，不要一个人消化——避免个人偏见过滤信息；
   • 用事实说话，不要用“我感觉他们喜欢”这种模糊表述。

十句精髓：

1. 观点毫无价值，行为才有价值。
2. 人们知道自己的问题，但不知道解决方案。
3. 如果他们还没有尝试解决这个问题，那这个问题就不够痛。
4. “我一定会买”是世界上最不值钱的承诺。
5. 好的客户对话让你感到害怕——因为你可能听到不想听的真相。
6. 如果你害怕问某个问题，那这个问题可能最重要。
7. 任何人都能在 10 分钟内学会 Mom Test，但需要一辈子来养成习惯。
8. 你不是在卖东西，你是在学习。
9. 每次对话要么推进，得到承诺；要么失败，得到拒绝。模糊的“不错”是最差的结果。
10. 创业失败的最常见原因不是产品做不出来，而是做了没人要的东西。

四、团队、节奏与长期主义

上下文与推导

ONE 采用“每日一包”：老板上午提出的问题，团队当天改交互、调规则、出稿、进包，晚上就能验收。这套机制让问题不过夜，也让产品在短时间内装进消息、待办、日程、会议、发现和 AI 指令等复杂能力。

问题不在团队不努力，而在于组织对谁、对什么最敏捷。被高层看见的问题会立刻进入战时处理；用户反复提出但难以当日显效的个性化、偏好学习、长期记忆、排序反馈闭环和权限审计，则容易留在“重要不紧急”。

“每日一包”天然偏爱今天能看见、截图、验收和写进 changelog 的变化，不擅长容纳长期建模与反复验证。已读问题就是缩影：团队很快增加横滑、预览、跳过和展开，持续回答“怎样让它没那么痛”，却没有回到“这个已读是否应该发生”。

“90 分 Agent”同样可能为提高命中率而缩小真实场景。例如把“已读未回”限制成只监听直属上级，规则更清楚、指标更好看，但用户真正容易遗漏的可能是客户群里没人接的话、同事随口托付的小事和会后没有落下来的动作。为了考试得高分而清理真实世界，最后可能只得到一个高分小题。

这也是《Build to Last》在原文中的位置：要做 Agent OS，先要有能独立站住的 Agent；要做工作入口，先要稳定处理一类工作；要主动执行，先要回答依据、权限、失败恢复和责任归属。未来感的框架不能代替地基。

原摘录

无论是做 AI 产品验证 idea，做其他产品，或者泛化为做一切实验假设，一旦立了项，或做出了某种初步假设，沉没成本就会让这个产品或者实验假设的发起人，下意识成为自己假设的拥趸。一个人提出一个念头，很快就会开始保护这个念头；一个团队做出一个形态，很快就会开始解释这个形态；一个组织投入了资源、时间、排期、汇报链路，就更难承认：也许一开始题就没问对。

大型组织的沉没成本更高，因而更容易陷入自恋、自我解释和难以掉头。

造成实现效果差异的，除了各产品既有的数据和生态护城河，最大的变量就是产研团队本身。一个团队是否能把愿景切成路径，把路径切成任务，把任务做成可用产品；是否能在每天都有人催促变化时，仍然保留一点建设地基的耐心；是否能在“看起来很快”和“真的在接近问题”之间，分出轻重。

一鼓作气，再而衰，三而竭。

士气要靠胜仗养。

夫战，勇气也。一鼓作气，再而衰，三而竭。

这句话放在项目里也一样。

团队可以加班，可以赶发布会，可以日更，可以随叫随到。人不怕累到极点，人怕累了很久，却不知道自己赢在哪里。

公司当然要求快：窗口期短，模型迭代快，竞品动作密。问题在于，快分层次。能快的地方要快——原型、验证、反馈、低风险试错。可有些地方一味求快，最后更慢。比如用户心智没想清楚就发入口，权限成本没算清就包装 Agent，业务场景没打穿就堆发布会。表面抢了时间，后面要用返工、解释、客服、信任来还债。

这不是替低效辩护。真正有价值的慢，要能说清它在换什么：换更准的用户判断，换更稳的系统地基，换更少的返工，换长期可复用的能力，换用户愿意再来的信任。说不清换什么的慢是拖延，说得清才是长期投资。

所以长期要争的不是快或慢，而是哪段时间该省、哪段时间该投。低价值重复交给 AI，高价值判断留给人；可规模化的个性化交给系统，需要审美、责任和取舍的地方留出时间。这样的快不乱阵脚，这样的慢不耗心态。

后来我读 fast.ai 一篇叫《Build to Last》的文章，反而对这件事有了更深的感触。

那篇文章整理了 Jeremy Howard 和 Chris Lattner 的一次长谈。Chris Lattner 是 LLVM、Swift、Mojo 背后很关键的人。文章里有一个很朴素的判断：真正能留下来的软件，靠的不是短期堆砌，而是第一性原理、架构质量和手艺。

Chris Lattner 在那篇文章里还批评了当下流行的“vibe coding”。他并不是反对用 AI。相反，他承认 AI 有用，也能提高效率。可他反感那种不求甚解的做法：让 Agent 一轮一轮生成代码，像拉老虎机一样，试到某个结果能跑，就以为问题解决了。真正危险的地方，不在于 AI 写了多少代码，而在于人放弃了理解和掌控。

敏捷若服务于学习，会让产品更快接近真实问题；敏捷若服务于证明，会让项目更快产生变化，也更难承认方向需要重来。

五、以友商为镜：看见远方，也要修脚下的路

上下文与推导

原文把几家产品放回各自已有的地形：

AI 没有凭空创造新地形，旧基因决定了新打法。钉钉最接近真实组织现场，飞书的知识资产更清楚，企业微信无需重新证明自己是客户连接入口。竞争不是谁先喊出 Agent，而是谁能让自身已有的工作流长出可靠的新能力。

发布会的差异进一步说明了这一点。钉钉用大叙事和新标识调动未来，飞书用 Demo 兑现当下。大组织需要旗帜，但发布内容太多、预售感太强，销售就难把愿景翻译成可开通、可定价、可交付、可兜底的产品。

Agent 真正难的也不是聊天，而是理解上下文、获得正确权限、调用工具、处理失败并完成闭环。钉钉的组织与流程资产既是机会，也是复杂度；小闭环还没有跑稳就宣布 Agent OS，等于旗子已经插上，脚下的路还没修好。

原文又用西南航空说明战略为什么首先是放弃：单一机型、点对点航线、简单服务和明确客群共同形成低成本且一致的系统。竞争者只复制表面做法，却不舍得删除原有复杂度，就无法复制结果。

原摘录

钉钉看得远，也打得急。

它最有希望的地方，是它真的在企业工作流里；它最危险的地方，是太想一次性宣布自己就是未来。以友商为镜吧，飞书的锋利，在于它抓准了 AI 时代开发者需要什么；企业微信的聪明，在于它不打扰旧路；Google 和 Slack 的成熟，在于它们把 AI 放回用户原来的工作流，再慢慢抬高平台。

军争之难者，以迂为直，以患为利。

看见远方以后，仍然有耐心先修脚下的路，这才是真章。

六、制度、工作与职业经验

上下文与推导

前文谈产品如何处理可见性和确定性，这一节把同一个问题转回组织。项目室、晨会晚会、已读未读、DING、验收包、Scrum 评分和即时响应，都在让工作变得可见。企业当然需要确定性；问题在于，当“被看见”成为最高价值，人会把时间投向怎样被看见，而不是怎样创造价值。

观察组织的真实优先级，不只看口号，还要看它怎样分配员工时间。高频召集、随时响应和每日验收让时间被切碎，团队越来越擅长追光，却难以保留完整时间思考难题。评价制度还会反过来训练行为：奖励在线、待机和即时回复，员工就会学会留下忙碌痕迹。

流水线式秩序适合目标明确、规则稳定的执行任务，却未必适合探索型产品。后者需要争论、完整思考和允许暂时没有答案。生产者在怎样的环境里产出，产品就会带上怎样的基因：只允许服从和可见进度，很难期待产品最终充满个体自主性、分寸与温度。

原文最后再把镜头移回从业者。判断一份工作养人还是耗人，不只看辛苦程度，而要看它是否让人长出技艺、判断和眼界，是否保住身体、尊严、亲密关系和恢复能力。作者不反对高压和学徒期，但“学徒不是柴火”：柴火烧完即可，学徒应该长出手艺。

“快就是慢，慢就是快”也由此成立。原型、验证和低风险试错可以快；用户心智、权限、安全、架构、审美和信任需要时间。慢不是拖延，必须说清它换来了更准的判断、更少的返工，还是更稳的地基。

结尾的火鸡悖论与泰坦尼克号，则是在回应一位担心自己工作太杂、履历受损的同事：职业和 JD 只是某一时期市场需求的归纳，过去持续正确不代表未来没有结构性变化；项目失败也不等于参与者没有能力，做过的真实工作和经历过的失败都会成为下一段旅程的经验。

原摘录

设置违反人性的制度，只会促进员工的注意力放在那些制度制定者初衷更不希望看到的地方。

判断一份工作对人是滋养还是消耗，要看它最后把人带到哪里去：是让人练成技艺、养好身体、健全尊严，还是只让人变得疲惫浑浊、学会应付了事。

首先，职业和 JD 是对经验的归纳，描述的是求职市场上企业在一段时间内认为自己需要的员工画像；需求本来就是动态的。我们在经验上发现，这些职业从求学到求职能稳定不变，很有可能只是一种“火鸡悖论”。

火鸡悖论（Turkey Paradox）：也称“罗素的火鸡”，是一个用来揭示归纳法的局限性和认知盲区的经典思想实验。火鸡根据 300 天被准时喂养的“大数据”，归纳出“饲养员爱我”的绝对真理。然而感恩节前夕，饲养员带来的不是食物，而是屠刀。

一句话概括：过去经验的持续正确，无法预测未来的系统性毁灭。

其次，泰坦尼克号的沉没，不影响船上的水手找到下一份工作。因为：

1. 水手能够上船，说明上船前的能力得到了船长的检验和认可；
2. 水手在船上做过切实的工作，船的沉没也和这个部分的工作不一定紧密相关；
3. 沉船经验世界上多少人能有？——何况塌这么大一艘船。这是多么宝贵的经验。