2025 年 1 月，Linear 前产品负责人 Nan Yu 把自己在产品与技术工作中最“承重”的观点整理成了一条 X 线程。此后一年半，他不断往里面补充新判断，最后一条更新到了 2026 年 7 月。
这不是 18 句互不相干的金句。把它们连起来看，会得到一套完整的产品操作系统：从具体问题出发，用组织承接判断，用速度搜索答案，再用真实使用校验质量。 AI 的加入没有推翻这套系统，只是把每个环节的优点和缺陷都放大了。
#好产品从“具体十倍”开始
Nan Yu 对 PRD 的要求不是写得更长，而是让信息本身拥有清晰的 UX：从最高层开始，逐步变细；从最广泛的读者开始，逐步缩小；从最不容易变化的内容开始，最后才放入会随开发不断变化的部分。
一份有效的 PRD 只有三层：
- Context ：这项功能对外怎么讲，为什么现在要做，凭什么有机会赢。它面向全公司，是最稳定的根本动机。
- Usage scenarios ：把功能放进真实人物、真实时间和真实行为里，让产品、销售和市场看到究竟在为谁解决什么问题。早期测试会让这些场景变得更准确，但不会轻易推翻它们。
- Milestones ：团队先验证什么、先降低什么风险、按什么顺序发布。它直接服务执行，因此是持续变化的“活”部分。
这套结构的价值，在于让不同读者只承担与自己有关的认知负担。全公司需要理解动机，面向市场的人需要理解用户，实际交付的人需要理解顺序和风险。
同样的具体性也适用于产品决策。“客户是 IT 管理员”还不够，应该具体到某家公司里某位负责 IT 的人；“帮助用户节省生成报告的时间”也不够，应该具体到每周报告已经预先缓存并送达收件箱，让那个人甚至不用打开应用。
一旦具体到这种程度，空泛概括就藏不住了：它究竟来自一组真实、具有代表性的案例，还是只有几个听起来正确的词，会立刻暴露出来。
#别说“更好”，说清用户获得了什么
Nan Yu 给产品沟通定过一条近乎苛刻的规则：尽量禁用“更快、更好、更多、更容易、更简单”这类比较词。它们没有告诉用户产品能做什么，也没有告诉用户生活会发生什么变化。
更有效的表达由两部分组成：能力和收益 。
“电池续航更长”是规格，“全天续航”稍微接近收益，但真正产生情绪共鸣的是“出门可以不带充电器”。后一句让用户直接看见了产品带来的自由。即便是 SaaS，最强的功能也不是参数更优，而是能让用户感受到一种新的工作状态。
#产品经理既要建设，也要销售
工程、产品、设计的三角关系只是产品管理的一部分。Nan Yu 认为，与 Sales 和 Marketing 的紧密协作，才让 PM 真正成为 Product Manager，而不是 Program Manager 或 Project Manager。
原因很直接：产品不是在需求文档里闭环的。销售掌握客户为何愿意付费，市场负责把能力翻译成价值，客户团队最早感受到承诺与现实之间的裂缝。产品经理如果只和工程、设计协作，得到的可能是一套完整的交付流程，却未必得到一件能被理解、购买和持续使用的产品。
但这不意味着 PM 独占产品决策。恰恰相反，Nan Yu 判断，工程师按数量计算做出了超过一半的产品决定。
产品和设计不可能写完每一个边缘状态、动画延迟、性能取舍、乱序执行、半完成状态和异常输入。如果没有亲手写代码，做出的只能是粗线条决定。真正决定产品手感的，是实现过程中密集出现的无数小判断。因此，产品判断力不是工程师的加分项，而应该进入招聘标准。
组织结构也会直接进入产品。汇报关系、所有权边界，以及谁能接触客户，决定了什么信息能进入决策、谁有权修正问题、哪些局部目标会压过整体体验。组织图从来不只是人事安排，它是产品设计的一部分。
#质量来自制度化的较真
Linear 保持质量的方法听起来并不复杂：修 Bug 的优先级高于其他事情，领导层非常在意质量。报告问题最积极的人，往往是最靠近客户的人和公司负责人，而不是被隔离在流程末端的 QA。
这背后有一个更强硬的定义：只要用户认为它是 Bug，它就是 Bug。
AI 幻觉尤其能说明这个问题。如果产品把答案包装成权威结论，却在出错后告诉用户“可以自行核查”，那不是用户没有尽责，而是产品和营销设定了错误预期。幻觉也许无法彻底消失，但验证必须被设计成工作流的自然组成部分，而不能变成事后的免责条款。
A/B 测试同样可能制造质量幻觉。Nan Yu 举过一个 Dropbox 的例子：营销邮件被设计成文件传输通知，营销团队可能因此得到惊人的打开率，顺利完成 OKR；另一边，文件传输团队看到参与度下降，通知团队收到大量无法解释的退订。
每个局部指标都可能“正确”，产品整体却在变坏。没有跨团队视角的实验，只是在奖励最会把成本转嫁给别人的团队。
领导者处理问题时也需要同样的克制：告诉对方“这令人失望，也让我生气，现在解决它”，但用平静的方式说出来。表达感受有助于传递严重性，把情绪直接表演出来，只会让信息被恐惧和防御吞掉。
#优雅不是一次想对，而是大量做错后删出来
Nan Yu 认为，想得到优雅、极简的设计，第一步往往是大幅做过头，再往回编辑。就像拍电影时先拍出最终所需素材的 50 倍，优秀的设计师和工程师从一开始就预期会丢掉大量想法和实现。
这也是他如此重视开发速度的原因。每次改变判断、获得新信息、修正方向，都会产生延迟；这个延迟就是开发速度。正确答案通常不是靠苦思冥想一次命中，而是在解空间里不断尝试有希望的方案。
当实现几个备选方案比开会争论哪个更好还快，优先级会议和内部谈判自然会减少。更重要的是，速度会复利：更早得到一个有希望的结果，就能更早看到下一个方向；版本 2 到版本 3 快一点，版本 3 到版本 4 再快一点，长期累积后就成为竞争对手难以复制的护城河。
Coding Agent 又把这种差异放大了一层。原本就习惯快速试验、愿意扔掉成果的人，突然获得了更强的执行外骨骼；把每一次敲键盘都当成珍贵资产的人，即使拿到同样的工具，也很难获得同样的搜索速度。
#战略是发现过程，不是署名竞赛
线程后来加入了一条看似相反、实际互补的判断：战略不是发明出来的，而是探索中发现的，就像棋手不是“发明”一步棋，而是在局面里找到它。
如果组织过度追求原创、首创和归功，个人自尊就会挡住那些已经浮现、等待被看见的好想法。真正的战略能力，不是让最高职位的人独自构思答案，而是设计组织与文化，让有价值的实验能够出现、被识别，再被汇入方向和路线图。
高速迭代因此不是“没有战略”，而是战略发现的基础设施。开放性决定能否看到答案，速度决定能否尽快验证答案。
#工具不只提高效率，也在塑造组织
商业软件卖的不只是功能，也是一套被打包的实践。
采用 Salesforce，团队会开始用线索、商机和 Pipeline 理解销售；采用 ERP，企业会花数月调整流程，让库存管理适应系统；采用 Linear，团队会接受 Cycle、Project、响应式工作分流，以及把功能请求连接到客户的做法。甚至 X 的线程功能，也在塑造观点如何被写出和被消费。
工具通过“让某些事容易、让另一些事困难”来塑造使用者。这种影响未必积极，也经常不被察觉。产品工作的一个重要部分，就是看见自己的产品和竞品正在悄悄训练用户形成什么习惯。
#管人和 Prompt，本质是同一种上下文工程
Nan Yu 观察到，管理者普遍会从学习 Prompt 中受益。人们让 AI 完成写作、反馈等软技能任务时，最常见的问题不是命令不够精巧，而是没有提供足够的元上下文：
- 有哪些对方不知道的隐性知识？
- 真正的动机是什么？
- 有哪些没有说出口的约束？
- 已经试过什么，哪些路线不要重复？
- 期待的产物在长度、形式和边界上是什么样？
这与管理人的难点完全相同。对方无法读取脑内背景，无论对方是人还是模型。只下命令、不共享目标和全局，会得到机械执行；把隐含信息变成共同上下文，才可能得到有判断力的协作。
#AI 已经成为产品和内容的新受众
当 Vibe Coding 工具频繁选择 Tailwind CSS 和 Supabase，这些产品会获得传统渠道之外的增长；当 ChatGPT 给一位作者带来的流量超过 X，内容分发的对象也不再只有人。如果模型把某个人视为某个主题的权威，这种判断还会在后续答案里不断自我强化。
同样的机制正在公司内部出现。管理层会问 Notion AI 或 Copilot：“当前最重要的项目是什么？”团队于是开始竞争能否被 AI 读到、理解和引用。远程工作形成的书面文化，在这里变成优势：组织经验被记录下来，AI 才能参与并执行。
但这也打开了新的博弈空间。文档可能被优化成面向 AI 的内部 SEO，甚至通过隐藏说明影响项目归功和绩效评价。AI 成为受众之后，信息可见性更强了，操纵可见性的激励也同时出现。
#AI 时代，代码审查要从“看 Diff”升级为“运行产品”
线程最新的一条观点，落在 AI 生成代码之后最容易被忽视的能力：阅读、理解和实际运行代码。
Nan Yu 对“认真代码审查”的定义很高：在开发环境里运行改动，确认它实现了声明的目标，阅读每一行，并判断整体方案是否接近自己认可的实现方式。
大多数 Bug 不是靠静态推演代码找到的，而是通过实际使用产品、主动尝试破坏它发现的。逐行审查更适合判断架构、API 设计，以及技术债务是否失控。代码作者知道功能“应该怎样工作”，容易受到知识诅咒；AI 生成的 Diff 越多，独立验证行为和边缘情况就越重要。
“Product Owner”不能成为责任转移的头衔。谁构建了它，谁就拥有它的质量。
#18 条原则，其实是一条链
把这 18 条观点压缩成一条工作链，就是：
把问题具体到真实的人和场景 → 让组织结构把信息送到正确的人 → 让有产品判断力的工程师快速试验 → 用真实使用而不是局部指标判断质量 → 把过程写下来，让人和 AI 都能继续行动。
产品质量不是某个职位在某次评审会上做出的单点决定。它是整个系统每天做出的无数小判断，最终在用户手里汇总出来的结果。