产品经理

欧盟市场。该条例于 2024 年 7 月 12 日刊于欧盟官方公报,本条自 2026 年 8 月 2 日起适用;2026 年 7 月的修订(2026/1744 号条例)保留了这个日期,但给在此之前已上市的生成式系统宽限到 2026 年 12 月 2 日来满足第 50 条第 2 款。它约束的是系统的提供方,不是使用它的雇主 —— 这正是它挂在这一页、而不是挂在某个「部署 AI」页面上的原因。两项义务,性质不同:第 50 条第 1 款是对着产品前面那个人的告知,只有在「一个合理知情、留心且审慎的人」看来显而易见时才免除,并对受保障措施约束的执法系统不适用;第 50 条第 2 款是一项技术要求 —— 输出必须以机器可读的格式标记、可被检测为人工生成,并在技术可行范围内有效且可互操作。后者是一项有工程成本的构建要求,不是隐私政策里的一行字。这条记录建立的是「这项义务存在、以及它何时开始」;它不是执法的证据,不是任何产品发生改变的证据,也没有说明欧盟以外市场的任何事。

失败、撤回、监管或成本正在抑制采用。可以下调评估,或扩大不确定区间。

一家软件公司首次公开募股最终招股书里的风险因素,由公司在出售股票时撰写。它说,公司的产品设计师、产品经理和工程师通过用户研究、问卷和对客服互动的分析收集输入,其中包括汇总和分类用户反馈的 AI 工具;这些输入可能不完整、误导、有偏差或不具代表性,也可能被误读。它描述的是一家公司的现行做法;没有给出工具做了多少工作的数字,也没有提到产品经理的人数。

企业已正式投入使用。可以改变基线,但要结合规模与场景相似度加权。

监管机构自己的公告;它之所以重要,是因为本站已经收录了那条规则,而这一条是规则被真的用上。公告列出的违规情形分成两组,而两组读起来都像是「没被写进去的产品需求」。对生成服务一方:未对生成合成内容添加显式标识;提供导出功能时未在文件中添加显式标识;未在文件元数据中添加含属性信息、服务提供者名称或编码、内容编号的隐式标识;隐式标识添加位置不规范。对传播服务一方:未落实隐式标识核验、未在发布内容周边添加显著提示标识、未在文件元数据中添加传播要素信息,以及未向用户提供声明生成合成内容的功能。公告写明的处置手段是约谈、责令限期改正、下架下线。有两条限制要说死。公告没有点任何一款应用的名字,也没有给出数量 —— 只说了「一批」,所以这里没有任何东西支持关于规模的说法。另外它针对的是在中国境内提供的服务;同一份功能清单在别处并不是法律,尽管欧盟的标识义务方向一致。

失败、撤回、监管或成本正在抑制采用。可以下调评估,或扩大不确定区间。

加州的法规,约束个人信息处理存在重大风险的企业,包括用于重大决定的自动化决策技术。企业必须在启动处理之前做风险评估,并记录是否启动;对企业是否启动该处理有权参与决定的人,必须审阅并批准评估;规定写明的目标是在对消费者的风险大于收益时限制或禁止该处理。它约束的是企业,没有点名产品经理;涵盖的是个人数据处理,不是每一个产品决定;首次向监管机构提交的期限在之后。

失败、撤回、监管或成本正在抑制采用。可以下调评估,或扩大不确定区间。

领英时任首席产品官描述领英自己产品组织的变化。他列出留给人的东西 —— 愿景、同理心、沟通(围绕一个想法对齐并调动他人)、创造力和判断 —— 并说其余一切公司都想自动化;公司当时在试点新的团队结构,由能用自家工具端到端做产品的小团队运作,并推出一个新人项目,参与者不只写需求文档。这是一位高管对试点的描述,没有给出小团队的数量或产品经理人数,记录的是 2025 年 8 月的情况。

真实场景里的小规模试验。说明落地条件正在被检验,不代表条件已经成立 —— 所以单独一次试点永远不够,两次互不相干的才够。

一项混合方法研究(arXiv 预印本),对象是微软的产品经理,2025 年 4 月至 6 月进行:885 名产品经理回答了问卷,731 人同意接受遥测数据分析,15 人接受访谈。在个人贡献者型产品经理使用生成式 AI 的各种用途里,22% 说用它做用户研究或数据分析;参与者更愿意把低问责的任务交出去,而在撰写需求规格或用户旅程图这类高问责的工作上犹豫。微软出售所研究的工具,受访者是这家早期采用公司自己的员工;自报的使用频率与使用日志只呈中等相关。

一件工具在真实工作里被大规模使用,并且被测量到 —— 而做出「用它」这个决定的是使用者本人,不是雇主。它比「技术能力」多:干的是真活,不是演示;又比「实际部署」少:没有任何雇主把它投入生产、要求使用、或围绕它改过流程。权重定为 `cautious`:`automating` 的定义是「机器能做这件事**并且**有采用迹象」,而这就是一种采用迹象 —— 但使用可能只是试用,而且相当一部分测量来自有利害关系的一方,所以一条永远不够,两条独立的才够。还要注意是谁在计数。厂商遥测直接看得见这件事,而它同时在卖这件工具,所以这类记录要在适用范围里写明这层利害;而一个统计机构去问企业「员工有没有在任务里用 AI」,看见的是同一条通道、却没有任何利害 —— 在它存在的地方,它是更好的来源。

你最先会被交派的活 —— 写工单和需求文档 —— 是暴露的那一半,而把它做好本身并不会让你成为一个产品经理。让这个岗位变成一份职业的,是你被信任去决定「什么不做」,而那份信任是靠先在小事上公开地判断正确挣来的。

如果你一周主要在写文档和同步进度,那是承压的那种配置 —— 而它也正是很多公司悄悄造出来的那种配置。如果你一周主要在做「你能为之辩护的拒绝」和「你自己拥有的决定」,暴露度就低。区别不在资历,在于这个岗位有没有带着一个决定。

保住并强化

确认这个岗位带着一个决定

这份工作暴露的那个版本,是「把别人做的决定写下来」。耐久的那个版本是「做决定」。你手上是哪一种,通常取决于公司,不取决于你的能力。

调整职责

把「AI 功能被允许做什么」接过来

每一个带生成式功能的产品,都需要有人决定它可以在哪儿出错、必须拒绝什么。那是一个产品决定,在多数团队里目前没人认领,而在若干市场里它正在变成需要留痕的义务。

相邻转岗

转到约束是真实的地方

受监管的产品、硬件、支付 —— 在这些领域里,「做错东西」的代价是具体的而不是名誉上的,因此那个决定必须由某个人扛着。

对这个岗位来说这是个错的问题,因为暴露度取决于你手上是哪一个版本的工作,不取决于时间。写需求文档与工单在很大程度上已经是机器的活。而「决定什么不做」、以及「为一次失败的押注答复」,完全没有动。一个你自己能核对的信号:你的团队最近上线的五件事里,有几件是你决定的,而不是你记录的。

能,而且写得不错 —— 这恰恰说明那份文档从来就不是这份工作。规格是一个决定的记录,而价值一直在「做决定」上:让哪个客户失望、把哪个季度花掉、哪个问题才是真正的问题。如果文档就是你所在的组织用来考核你的交付物,那这件事值得你重新认识一下这家组织。

够分得清「估算」和「猜」就行 —— 而这条线是移动了,不是抬高了。当生成让原型变便宜,有用的技术判断就从「什么难做」挪向了「什么难运维、什么难撤回」—— 而这些代价,已经不再体现在第一版要花多久上了。

「做」变便宜,让「决定」的后果更大而不是更小:当一个团队用过去做一件事的时间能做五件,做错五件的代价就是五倍。它真正改变的是:这个岗位不能再靠「协调开发」来证明自己的必要性了。它必须靠选择的质量来证明 —— 那是一条更高的线,也是一条更诚实的线。