有一种掉队的方式，比不努力更难被发现。

你没有停下来，每天都在做需求、推进迭代、开评审会，看起来一切正常。但某天你突然发现，你对”这个技术现在能做到什么程度”的判断，已经是过期的了——不知道从什么时候开始，悄悄过期的。

我认识一个比我早入行做AI产品的朋友，他说他亲眼见过好几个团队有过类似的遭遇：认认真真憋了将近半年，做了一个PDF解析的独立工具，做得还挺用心，结果某个大厂突然宣布这个能力直接内置了，系统原生支持。他说那种感觉，就像你在认真挖井，旁边人接了自来水，而你完全不知道那根管子是什么时候铺的。

这不是小概率事件。

AI这个方向有一个跟普通产品方向很不一样的地方：它的”基准线”是动的，而且动的速度不均匀。普通产品，一个功能难实现，三个月后可能还是难实现，你的判断不容易过期。AI这边，你上个月认为”还做不到”的事，这个月可能已经有现成方案了，成本比你想象的低得多，延迟也比你想象的短得多。

你脑子里那张关于”能做什么/不能做什么”的地图，会在你不注意的时候悄悄失效。

带我入行的前老板做了十几年产品，说过一句话我印象很深：做产品最怕的不是判断错，是拿着过期的地图走路，还以为方向准确。

这种状态有一个特征，就是你不知道自己不知道。

1.为什么要盯着那些大会

这个问题问过不少同行，收到的答案通常是”追行业动态””保持信息量”。

这个说法不是错，但太虚，实际的价值比这具体得多。

关注那些发布会，对我来说最直接的用处就一件事：校准自己对技术天花板的判断。

具体怎么理解。假设你在规划一个跟语音交互相关的产品方向，你脑子里对”语音转文字的延迟能低到什么程度””多轮对话的上下文能维持多久””极端情况下识别准确率是什么量级”有一套预期。这套预期，直接影响你在设计交互时做什么假设，留多大容错空间，以及什么样的体验是”可以发布的”。

如果你对技术天花板的预期是错的，你的产品决策就建立在一个错误的地基上——而且最麻烦的是，这种错误不是显而易见的，它会藏在你每一个”理所当然”里，等到出问题了才会暴露。

大会能帮你做的，就是定期拿外部信息来冲刷一下这套预期，逼自己问：我以为行不通的事，现在是不是行了？我以为需要半年的事，现在有没有更快的路？

这比”保持信息量”这种说法要踏实得多。

2.值得盯的不只是那三个”春晚”

Google I/O、Apple WWDC、Microsoft Build，这三个是做科技产品的人基本都知道要跟的，合称”科技春晚”。确实值得看，但只看这三个会有几个不小的盲区。

先纠正一个我之前自己也有的误解：Google I/O 经常被说成”偏C端”的会议，其实这个说法不太准。I/O 从来都是以开发者为核心的大会，API发布、框架更新、开发工具的变化才是实质内容，只是近几年 Gemini 的产品展示感太强，才给人一种面向消费者的错觉。对AI产品经理来说，I/O 里的开发者专场，比主舞台的产品秀对日常工作的参考价值更直接——但很多人根本不知道还有这层。

NVIDIA GTC是另一个经常被低估的会议。它不讲产品，讲的是算力的天花板往哪移、架构在往哪演进。听起来好像跟产品经理关系远，但实际上不是。你在做AI产品，迟早会面对”这个功能端侧能不能跑””推理成本什么时候能降到可接受的范围””什么量级的场景才能撑起来”这类问题。GTC 是离这些问题答案最近的地方，比任何产品分析报告都更接近真实情况，比问研发同事也更有全局感。

然后是一个在很多”必看清单”里反而缺席的：OpenAI 的开发者活动。对做AI产品的人来说，这个的重要程度不亚于前面任何一个，因为影响是最直接的。API能力边界怎么变、调用限制调了什么、新的工具层或者模型层开放了什么——如果你的产品有相当一部分是建在这套能力上的，那这个就必须跟着。错过一次关键更新，可能意味着你下个季度的方向规划要重来。

AWS re:Invent做ToB方向的人别跳过。每年这个会上都有大量企业AI真实落地的案例，不是那种包装过的成功故事，而是工程上踩了什么坑、数据治理怎么搞、合规怎么绕过去的真实经验。这类信息在网上很难找，基本只在这种场合才拿得到第一手的。

Meta的动向也值得单独留意，尤其如果你所在的团队在做私有化部署、或者用开源基座做微调。Meta 在开源模型上的投入和节奏，会直接影响这条路的可行性和成本。它不一定通过专门的大会发布，但更新节奏很快，值得找一个固定的方式跟踪。

（顺便说一句——以前我也整理过一个”必看清单”，列了七八个会议，后来发现根本跟不完，真正有时间认真消化的也就三四个。”值得看哪些”和”你真的能看完哪些”是两个不同的问题，后者其实才是需要先想清楚的。）

学术会议这块，NeurIPS、ICLR 这类顶会，不是让你去啃论文，而是可以把它当成一个提前量来用：今年学术圈集中在哪个技术方向使劲卷，差不多一两年后就会出现在产品层面。带着这个视角扫一下热门论文的标题和摘要，成本不高，在某些时候比追发布会更有价值。

3.看什么，比看哪个更重要

这一节是我觉得最想说的，也是最容易被跳过的。

很多人关注这些发布会，主要在吸收的是：新功能来了，新接口开了，又支持什么了。这些当然要看，但如果只看这个，其实是在被动接收信息，而不是在主动校准判断——两件事看起来像，但能从中拿到的东西差得很多。

更有价值的，是看那些”还不行”的地方在哪里。

举一个很具体的例子。看大会上的 Live Demo，大多数人的注意力在”这个功能好厉害”。但如果你仔细看，能注意到演示者说完话到系统开始响应之间的时间间隔，能注意到他有没有重复说了一遍才识别成功，能注意到演示选用的场景是不是极其理想的输入条件——网络极好、话语清晰、没有任何歧义。这些细节，博主剪辑版几乎都会修掉，因为留着不好看。但这些细节，才是当前技术真实能力边界的证据。

（说一句题外话——不是让你带着挑毛病的心态去看发布会。只是对做AI产品的人来说，能感受到”这个Demo的前提条件有多苛刻”，是一种很实用的判断能力。你知道天花板在哪，才知道哪些产品方向站在扎实地基上，哪些是在赌技术还没解决的问题。）

还有一个被忽视的信息来源：每次大会之后，官方文档的变更。

发布会上讲的是”能做什么”，文档里还有”限制条件”——调用频率上限、上下文长度的边界、内容过滤的范围、哪些特定场景不在支持之列。这些限制的位置，就是当前技术天花板的位置。看起来枯燥，但它比新闻稿诚实，比任何二手解读都更直接。

最后一点值得单独说：关注那些只有一家在讲的东西。如果三家会议都在强调同一个方向，那个方向已经是行业共识了，不需要你特别警觉。真正值得多想几分钟的，是只有一家在讲的、其他人还没跟上的那个细节——那里可能是下一个不对称的机会，也可能是一个值得长期观察的变化信号。

4.原片和二手信息，怎么分配时间

时间不够是真实的限制，不可能每场都从头看到尾。

所以更实际的问题是：哪些值得看原片，哪些看博主复盘就够了？这部分网上讨论挺多的，我只说几个自己想过的角度。

Keynote 里的现场 Demo，建议看原片。原因上面说了，关键信息在那些细节里。这部分通常不长，一两个小时的主旨演讲，真正值得仔细看的Live Demo可能就二三十分钟，时间成本是可控的。

设计类的专题分享，建议看原片。这类内容有一个特点，大厂设计团队在解释”我们为什么放弃某种交互、选了另一种”的时候，里面是很多层的推理，不是一个结论，是一整套关于用户意图、反馈预期、容错机制的思考过程。你跟着这个推理走一遍，和只看”结论是什么”，拿到的东西差得很远。博主很难转述这种内容，不是不认真，是格式本身限制了深度。

算力方向的重大发布，比如 NVIDIA 展示新一代硬件的那部分，也建议看原片。文字描述传达不了那种量级感，”原来AI在物理世界可以做到这个程度了”这种空间感，是需要视觉来建立的。

可以交给博主的内容，大概是这几类：

软件功能的常规更新，比如系统应用多了某个小功能、界面调整了什么，看汇总图文就够，逐一追着看效率极差。底层工程架构的改进，比如编译器优化、某个内部框架的调整，除非你正面临具体的工程瓶颈，否则让技术博主帮你翻译成人话更合适。还有会议开场那段商业数据的自我表扬，”我们有多少开发者””市场占有率是多少”这类，直接跳过，没有信息量。

如果决定靠博主，有一点建议：不要只跟一类视角的。

极客和开发者视角的博主，会告诉你接口好不好用，调用起来顺不顺，有没有换汤不换药的成分——这是最接近”技术天花板真实位置”的声音。产品和商业分析视角的博主，会拆解这次发布对竞争关系意味着什么，哪个玩家受益、哪个被打压。设计向的博主，会讲交互语言在往什么方向演变。三类信息拼在一起，才比较接近完整的图景——单看任何一类，都会有盲区。

5.敏感，不是焦虑

这两件事看起来像，但性质完全相反。

我认识一个做AI方向的朋友，有一段时间几乎每隔几天就在刷最新发布，什么都知道，什么都能聊，开会特别能说。但他自己后来跟我说，那段时间其实很空，什么都没真正沉下去想过。

信息焦虑和信息敏感，区别在驱动力不同。焦虑是被信息追着跑，停下来就会难受；敏感是你知道自己在找什么、在验证什么，找到了就够了，不需要更多。前者越跑越累，后者其实不太耗力气。

我现在大概的节奏，是重要会议不缺席，但不追直播；优先关注官方文档的变更，而不是媒体报道；偶尔拿新工具自己跑一个小demo，比看十篇分析稿都更直接。这套方式不一定对，是我觉得目前还能持续的做法。

关于这件事，我真正想说的其实只有一点：

你关注这些东西，是为了让自己的产品判断更准，还是为了在会议室里有东西可说？

这两件事看起来都是”保持信息量”，但背后的驱动不同，最终能用上的东西也完全不同。如果只是为了”有话说”，其实用不着盯着这些会议，刷热搜足够了。

你现在盯着外部信号的方式，算哪一种？

《简易设计》产品设计专栏：

这套产品设计方法举例了若干案例，包含了下面5个核心步骤

1.需求调研和用户研究

2.产品设计的减法和功能组合

3.微创新产品设计

4.系统和单元模块的简易设计案例

5.简易设计不止是在产品设计

专栏大纲

讲解了需求调研&用户研究、功能减法、组合、微创新、迭代框架的5个步骤。本书不仅适用于产品设计，而且能将简易设计的理念将渗透到你工作和生活的每一个角落。