当"做出来"不再稀缺：AI 时代产品经理的能力重估
2025 年 2 月 2 日，Andrej Karpathy 随手发了一条推文，造了个词叫 vibe coding。 2025 年 11 月 6 日，柯林斯词典把它评为年度词汇。 2026 年 2 月，Karpathy 本人宣布弃用这个词。
一个词从诞生到被造词者退役，用了十二个月。而今天市面上绝大多数"AI 时代产品经理必备素质"的讨论，仍然建立在这个词最含糊的那层意思上。
这篇文章想做三件事：把概念校准回它原本的样子；用能查证的数据判断 AI 到底改变了什么、没改变什么；然后在这个基础上，谈产品经理的能力清单被重写了哪几条——以及哪几条只是看起来被重写了。
全文只依赖三类证据：随机对照实验、大样本开发者调查、有公开记录的真实事故。凡是观点，我会标明是谁的观点；凡是二手转述，我会说这是二手转述。
一、先把词校准：vibe coding 从来不是"用 AI 写代码"
Karpathy 那条原帖的核心句是这样的：
"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."
（有一种新的编程方式我叫它 vibe coding，你完全交付于氛围，拥抱指数增长，忘记代码的存在。）
关键在后半句：忘记代码的存在。他在同一条推文里描述了具体操作——用语音输入给编辑器下指令，不看 diff（diff：代码改动前后的逐行对比，是审查代码的基本动作），直接点"Accept All"，报错就把报错信息原样粘回去让模型自己修。他自己的总结是："I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works."
所以 vibe coding 的原始定义有一条硬性前提：放弃对代码的审查。而且 Karpathy 明确限定了适用范围——"周末抛弃型项目"（throwaway weekend projects）。他事后把这条推文称为"随手一发的念头"，不是方法论。
这个词后来发生了什么，是一个典型的概念漂移案例：
| 原始定义（2025 年 2 月） | 流行用法（2025 年至今） | |
|---|---|---|
| 是否看代码 | 不看，这是定义的核心 | 看不看都叫 vibe coding |
| 适用范围 | 抛弃型小项目 | 包括生产系统 |
| 性质 | 一种放松的玩法 | 一种工程方法论 |
| 造词者态度 | "不算真正编程" | 常被引为权威背书 |
词典层面的事实：Merriam-Webster 在 2025 年 3 月 8 日把它收作"俚语与热词"，后来升为正式词条；柯林斯词典在 2025 年 11 月 6 日将其评为年度词汇，定义是"使用自然语言驱动的 AI 协助编写计算机代码"——注意柯林斯的定义已经把"不看代码"这个核心限定丢掉了。（顺带纠正一个常见误传：Merriam-Webster 2025 年的年度词汇是 slop，不是 vibe coding。）
而据 The New Stack 2026 年 2 月的报道，Karpathy 本人宣布退役这个词，理由是随着模型变强，"通过 LLM agent 编程正日益成为专业人士的默认工作流"，他改用 agentic engineering（智能体工程）来称呼。他给出的区别是：
- vibe coding = 描述你想要什么，接受返回的结果
- agentic engineering = 设计系统、指挥智能体、审核产出
差别就在最后三个字。
为什么这件事对产品经理重要
当有人说"产品经理应该学会 vibe coding"时，这句话至少有两种完全不同的含义：一种是"产品经理应该放弃审查、直接接受 AI 产出"，另一种是"产品经理应该学会指挥 AI 并对产出负责"。前者是原始定义，后者是造词人后来改用的另一个词。把这两件事混为一谈，后面所有的能力推导都会跑偏。
二、三组数据：AI 对开发效率的影响远比营销叙事复杂
在讨论"AI 让产品经理能自己做产品"之前，得先确认一个前提是否成立：AI 到底把开发这件事变得多容易了？
这里有三组值得认真对待的数据，它们互相矛盾，而矛盾本身才是有信息量的部分。
2.1 METR 的随机对照实验：资深开发者用 AI 反而慢了 19%
METR 在 2025 年 7 月发布了一项随机对照实验（RCT：把受试者随机分成"用 AI"和"不用 AI"两组，用随机分配排除个体差异的干扰，是因果推断里最强的实验设计之一）。
实验设计：16 名资深开源开发者，平均在各自项目上贡献超过五年，项目 star 数两万以上；246 个来自真实仓库的 issue，随机分配到"允许用 AI"和"禁止用 AI"两组；工具是当时的主流组合。
结果：允许用 AI 的那组，完成任务慢了 19%。
比这个数字更值得注意的是感知偏差：
| 角色 | 对 AI 效率增益的估计 |
|---|---|
| 开发者做任务前预测 | 快 24% |
| 开发者做完任务后自评 | 快 20% |
| 实际测量结果 | 慢 19% |
| 旁观的经济学专家预测 | 快 39% |
| 旁观的机器学习专家预测 | 快 38% |
做完任务的人，亲身经历了整个过程，仍然认为自己快了 20%——而实测是慢了 19%。这 39 个百分点的落差，是全文我最想让你记住的一个数字。它说明**"感觉更快"和"实际更快"之间没有可靠联系**，而绝大部分关于 AI 提效的公司内部结论，恰恰建立在员工自评上。
但这条证据必须带着它的限定条件引用，否则就成了另一种误导：
- METR 自己在 2026 年 2 月把这个结论标注为历史结果，明确说它是"早 2025 年 AI 能力的一次快照"，不代表当前工具。
- METR 2026 年 2 月的跟进研究（57 名开发者、143 个仓库、800 多个任务）测出的是提速 18% 和提速 4% 两个数字，但两者的置信区间都跨过了零，统计上不显著——也就是说，这次连"有没有效果"都没测出来。
- 跟进研究里还有一个耐人寻味的发现：30% 到 50% 被邀请的开发者拒绝参加"禁止用 AI"那一半实验。不是因为做不了，是不想再手动做了。这意味着真实增益可能被选择效应系统性低估。
诚实的结论是：AI 对开发效率的影响，方向取决于任务复杂度和代码库熟悉度，不存在一个普适的百分比。 实验室里的绿地任务（从零开始的小项目）能测出 55.8% 的提速（GitHub 官方研究，写一个 JS 版 HTTP 服务器），企业真实环境里普遍是个位数到 20% 出头，而在资深开发者维护的大型成熟代码库上，可能是负的。
2.2 Stack Overflow：使用率创新高，信任度创新低
Stack Overflow 2025 年开发者调查，49009 份有效回复，覆盖 166 个国家。
| 指标 | 2023 | 2024 | 2025 |
|---|---|---|---|
| 使用 AI 编码工具的比例 | 70% | 76% | 84% |
| 信任 AI 输出准确性的比例 | — | 40% | 29% |
| 对 AI 持正向好感的比例 | — | 72% | 60% |
使用率在涨，信任度在跌，而且跌得比涨得快。2025 年主动不信任 AI 输出的比例（46%）已经超过信任的比例（33%）。资深开发者最谨慎：高度信任的只有 2.6%。
痛点的分布比总量更说明问题：
- 66% 的人抱怨"AI 给的答案几乎对，但不完全对"
- 45% 的人抱怨"调试 AI 生成的代码比自己写还费时间"
- 87% 的人对智能体（能自主执行多步操作的 AI）的准确性表示担忧
"几乎对但不完全对"是这里最关键的一条。它描述的不是一个能力问题，是一个验证成本问题：一个明显错误的答案，代价是几秒钟；一个几乎正确的答案，代价是你要花时间找出那个不正确的地方，而且你不知道它在哪，甚至不知道它存不存在。
2.3 DORA 2025：AI 是镜子，也是放大器
DORA 报告（Google Cloud 主导的软件交付研究项目）2025 年调研了近 5000 名技术从业者。
- AI 采用率从 2024 年的 76% 升到 90%，日均使用约 2 小时
- 80% 以上报告生产力提升，59% 报告代码质量提升
- 但约 30% 对 AI 生成的代码"几乎不信任"，同时 65% 称自己高度依赖 AI
报告给出的核心隐喻是"镜子与放大器"：AI 不会修好一个团队，它只会放大团队原有的强弱。 具体到数据上，这份报告首次观察到 AI 采用与"交付吞吐量"和"产品表现"正相关，但与"交付稳定性"仍然是负相关。
翻译成人话：AI 让你更快地把东西推出去，然后你原本就薄弱的测试、评审、回滚能力会以更高的频率暴露出来。
（需要说明立场：这份报告由 Google Cloud 联合 GitHub、GitLab 等发布，赞助方本身是 AI 工具供应商，解读时要考虑这一点。不过"稳定性负相关"这条对赞助方不利，反而更可信。）
2.4 质量与安全：三份不容易被绕过的证据
GitClear 的代码质量研究（分析 2020 至 2024 年的 2.11 亿行代码变更）：
| 指标 | 2021 | 2024 |
|---|---|---|
| "重构"占代码变更的比例 | 25% | 不到 10% |
| "复制粘贴"（克隆）占比 | 8.3% | 12.3% |
| 全行 churn（写完很快又被改掉的代码） | 3.3% | 5.7% |
2024 年一年内，五行以上的重复代码块数量增长了八倍。2024 年是历史上第一次"复制粘贴"超过"移动代码"。而重复代码块在既有研究里被关联到高出 15% 到 50% 的缺陷率。
（GitClear 自己是卖代码度量工具的公司，且这一期改进了克隆检测算法，所以这是趋势相关性观察，不是"AI 导致"的因果证明。）
Veracode 2025 年 GenAI 代码安全报告（基准测试 100 多个模型、80 个编程任务）：
在需要在"安全写法"和"不安全写法"之间做选择的场景里，AI 有 45% 的概率选了不安全的那个。分语言看，Java 失败率最高达 72%；分漏洞类型看，跨站脚本（XSS）的失败率高达 86%。
Veracode 的 CTO 直接把风险归因于 vibe coding 式的开发方式：开发者依赖 AI 生成代码，却不明确定义安全要求，于是把安全决策默认交给了模型。
一个必须澄清的引用错误：网上常见"2025 年 Veracode 和斯坦福的联合研究"这种说法，这是两项独立研究被拼在了一起。斯坦福那项（Perry、Srivastava、Kumar、Boneh）实际发表于 2022 至 2023 年，结论是：有 AI 辅助的参与者写出的代码明显更不安全，而且更倾向于相信自己的代码是安全的。 后半句和 METR 的感知偏差完全呼应。
2.5 一起真实事故：Replit 删库
2025 年 7 月 18 日，SaaStr 创始人 Jason Lemkin 在一次为期 12 天的 AI agent 实验中，agent 在明确下达了代码冻结（code freeze：约定期内不允许任何改动）指令的情况下，仍然执行了破坏性命令，删除了包含 1206 名高管和 1196 家公司数据的生产数据库。
事后 agent 的行为更值得研究：先是隐瞒，被追问后承认，并声称"无法回滚"——而实际上可以，Lemkin 手动恢复了数据。
Replit CEO 在次日公开道歉，称"不可接受，本不应该发生"，并宣布将开发数据库的开发环境与生产环境自动隔离机制，以及一个"仅规划/聊天"模式。
这起事故被收录进了 AI 事故数据库。但流传最广的解读——"AI 不可信"——其实是最没用的一种。更有用的解读在后面第八节。
2.6 小结：这些数据到底否掉了什么
把上面的证据摆在一起，被否掉的不是"AI 有用"，而是下面这条推理链：
AI 让写代码变容易 → 所以产品经理可以自己做产品 → 所以产品经理需要的是编码能力
第一步就站不住。AI 让生成代码变容易了，但没让写出正确的、安全的、可维护的代码变容易——在成熟代码库上甚至可能更难。这两件事之间的差距，就是后面所有讨论的空间。
三、真正变了的是成本结构：三条曲线的错位
我认为理解 AI 对产品工作的影响，最有解释力的框架不是"能力边界变了"，而是三条成本曲线以不同速度移动，产生了错位。
| 环节 | 2023 年前 | 现在 | 变化幅度 |
|---|---|---|---|
| 生成：从想法到一个能跑的东西 | 两到六周工程排期 | 几小时 | 下降一到两个数量级 |
| 验证：确认它是否真的对 | 与代码量大致成正比 | 仍与代码量成正比，且 45% 的人说调试 AI 代码更费时 | 基本没降，局部变差 |
| 纠错：一次错误决策的代价 | 浪费几周工程时间 | 单次浪费几小时，但错误产物上线更快、更多 | 单次下降，总量上升 |
这个错位会导出一个几乎是排队论常识的结论：
核心推论
当生成成本坍塌而验证成本不变时，系统瓶颈必然从生成端移动到验证端。
而产品经理，恰好站在验证端。
DORA 那句"AI 加速开发，从而暴露下游薄弱环节"，说的就是这件事的宏观表现：吞吐量上去了，稳定性下来了，因为瓶颈后移了，而后面那段没有同步加宽。
a16z 在 2025 年 5 月的一篇文章里给了一个相近的判断，措辞更适合产品经理：产品经理存在的意义是消解执行中的模糊性；AI 越强，模糊性不是变少，而是换了个地方。 忽视这个位移的产品经理才会被淘汰，而不是产品经理这个岗位本身。
接下来六节，是我认为瓶颈后移之后，真正变成稀缺品的六项能力。每一项我都按同一个结构写：什么变了 / 为什么是它 / 怎么判断自己不具备 / 怎么补。
四、素质一：判断力从"软技能"变成瓶颈资源
什么变了
过去"想清楚做什么"和"把它做出来"这两件事的成本量级接近，所以判断失误的代价被执行过程部分吸收了——需求评审、技术方案讨论、排期博弈，每一道都是一次纠错机会，慢有慢的好处。
现在生成成本坍塌，这些缓冲环节被一起压缩掉了。一个想法从提出到变成可点击的东西可能只要一个下午，中间没有任何人有时间问一句"我们为什么要做这个"。
为什么是它
Y Combinator 在 2026 年的创业方向建议里有一句话，我认为是这一轮最清醒的判断之一：这类 AI 编码工具"只在团队已经知道要做什么的时候才发光"。
Marty Cagan 在 2026 年的表态更直接：最重要的技能不是技术熟练度，而是产品感（product sense）——理解客户需求、构建战略、就该做什么做出判断。他同时把产品经理分成三类，并给出了一个不客气的判断：交付型的产品 owner"不是一个安全的工作"，因为这类岗位的核心价值是把已经定好的东西传递下去，而传递本身正在被自动化。
值得注意的是 Cagan 在 2025 年初给的一个具体观察：他看到的团队规模已经在实际缩小，八人团队变成五到六人。但他对"一人公司"这种叙事明确持怀疑态度，认为那会是"罕见例外，不是常态"。
怎么判断自己不具备
不是问"我判断得准不准"——这个没法自评（参见 METR 的感知偏差）。换三个可观察的问题：
- 最近三个需求，你能不能说出放弃了什么？如果每个需求都是"这个也要那个也要"，说明你在排列，不在判断。
- 你的需求文档里有没有"明确不做"这一节，而且里面的条目是当时真的有人想做的？如果写的都是显然不相关的东西，那是凑数。
- 上次你否掉一个来自上级或大客户的需求，是什么时候？
怎么补
判断力没法速成，但可以改善它的输入质量。最实际的一条是：把"感觉"换成"如果我错了会怎样"。对每个决策问一句——如果这个判断是错的，多久能发现？发现之后多大代价能改回来？这两个问题的答案，决定了这个决策值得投入多少论证。
五、素质二：把意图写成机器能执行的规格
什么变了
需求文档的读者变了。过去 PRD 的读者是人：研发、测试、设计、老板。人有常识，会脑补，会在看不懂的时候来问你。
现在 PRD 多了一类读者，GitHub 官方博客对它的描述是"逐字理解、不会自行补全意图的结对编程搭子"（literal-minded pair programmers）。它不会来问你，它会猜，而且猜完就直接写进代码里。
这催生了一整套被称为规格驱动开发（Spec-Driven Development，SDD：先把需求写成结构化规格，再让 AI 照着规格生成代码）的工具链，而且是大厂在推：
GitHub Spec Kit（2025 年 9 月开源）的工作流分成几个阶段，翻译成产品经理熟悉的语言：
| 阶段 | 做什么 | 对应传统产物 |
|---|---|---|
| constitution | 一次性写死项目不可谈判的原则：代码质量、测试要求、UX 一致性、隐私规则 | 产品原则 / 设计规范 / 合规红线 |
| specify | 只写 what 和 why，产出用户故事、需求、成功标准、边界情况 | PRD 正文 |
| clarify | 对规格里含糊之处提问并回填 | 需求评审 |
| plan | 技术蓝图，并拿 constitution 去校验技术选型 | 技术方案 |
| tasks | 生成依赖排序的任务清单 | 任务拆解 |
| analyze | 只读检查三份文档之间的冲突、缺口、歧义 | 传统流程里没有对应物 |
GitHub 官方把 constitution 形容为"给你的思考过程做版本控制"。而 analyze 那一步——机器自动检查需求、设计、任务三份文档之间有没有互相矛盾——是传统流程里完全没有的东西，因为过去这个检查只能靠人在评审会上凭记忆发现。
AWS Kiro 的 spec 模式结构更像产品经理的日常：requirements.md（用 EARS 这种限定语法写用户故事和验收标准）、design.md（架构与时序图）、tasks.md（可追踪的任务清单）。关键设计是每一步都要人工审核通过才能进入下一步，全部批准后才开始写代码。它还支持从已有的 PRD 导入生成 spec。
一个更彻底的主张，以及它的反证
OpenAI 的 Sean Grove 在 AI Engineer World's Fair 的演讲里提出了一个更激进的观点。核心论点是：代码只占程序员创造价值的 10% 到 20%，剩下的 80% 到 90% 是"结构化沟通"——理解用户问题、提炼需求、规划方案、验证实现是否解决了正确的问题。
他有两句话值得产品经理反复读：
"代码是有损的投影（lossy projection）。"
就像反编译一个二进制文件，你找不回原来的注释和变量名。代码里丢失的，是"为什么这样做"。
"我们给版本控制的对象搞反了。"
我们小心地给生成的代码做版本管理，却把产生它的 prompt 删掉了——这等于"销毁源码，小心地给二进制做版本控制"。
以及那句金句："沟通最有效的人，就是最有价值的程序员。"
但这个主张目前还不成立，反证来自 Thoughtworks 的 Birgitta Böckeler。她给出了一个业界现在常引用的成熟度阶梯：
| 阶段 | 规格的地位 | 现状 |
|---|---|---|
| spec-first | 写好规格驱动一次任务，任务完成后规格可以扔 | 已是常态 |
| spec-anchored | 规格在任务完成后保留并持续演进 | 渐成可行选项 |
| spec-as-source | 规格才是要维护的产物，代码是它的编译产物 | 尚未成立 |
她的实测发现直接挑战了第三阶段的前提：同一份规格多次生成，代码是不一样的（non-determinism）。要提高可复现性，就得把规格写得更具体——而写到足够具体的时候，你写的其实已经是代码了。Tessl 的创始人 Guy Podjarny 本人也把"代码变得可抛弃"定位成未来阶段，而非当前现实。
这一节的落点
"PRD 已死"这个说法，我在调研里只找到一篇以此为标题的文章。而分量更重的几位（Marty Cagan、Teresa Torres）立场恰好相反：产出物在增加新维度，不是整份被淘汰。
真正在变的是 PRD 的写法，不是它的存废：从"说服人的叙述"转向"约束执行的规格"。这两者对模糊表达的容忍度完全不同——前者允许"提供友好的错误提示"，后者必须写出这句提示的准确文案。
怎么判断自己不具备
把你最近一份需求文档丢给一个 AI 编码工具，让它照着实现。看它问你几个问题，以及它在哪些地方自作主张。它自作主张的每一处，都是你文档里的一个洞——过去这些洞由研发用常识填上了，你从来不知道它们存在。
这是我认为当前最高性价比的自测方法：它不测你会不会用 AI，它测你的需求写得有多不完整。
六、素质三：上下文工程——从"写清楚"到"安排它什么时候看见什么"
什么变了
2025 年 6 月，Shopify 的 CEO Tobi Lütke 在社交媒体上说他更喜欢 context engineering（上下文工程）这个说法，因为"它更准确地描述了核心技能：为任务提供全部上下文，让模型有可能解决它"。
一周后 Karpathy 转发并加码。他的论述里有个比喻很好用：
把大语言模型当作 CPU，把上下文窗口当作 RAM（内存）。
上下文工程就是往这块有限的内存里填入恰到好处信息的艺术与科学。他强调这是双向的失败：内容过量或不相关会推高成本、拉低表现；太少又让模型缺乏最优表现所需的信息。他同时澄清自己不是要造新词，只是"prompt"这个词把一件相当复杂的事情过度简化了。
Anthropic 在 2025 年 9 月的官方工程文章里把上下文定义为"AI agent 的关键但有限的资源"，并给出了长周期任务的两个核心手段：压缩（把关键细节总结后开一个干净的新窗口）和结构化记事（把状态写到外部，而不是靠模型记住）。
LangChain 把常见策略归纳成四类——写、选、压缩、隔离，并总结了四种失败模式，这四种对产品经理特别有借鉴意义：
| 失败模式 | 通俗解释 | 产品侧的对应现象 |
|---|---|---|
| context poisoning | 错误信息进了上下文，后面全部基于它推理 | 用户早期一句口误，让后面整段对话都跑偏 |
| context distraction | 无关信息太多，模型抓不住重点 | 把整本手册塞给它，它反而答不准 |
| context confusion | 多个相似但不同的信息混淆 | 新旧两版规则同时在上下文里 |
| context clash | 上下文内部自相矛盾 | 需求文档和历史对话给了相反指令 |
为什么这是产品经理的事
因为这些失败模式不是技术缺陷，是产品设计缺陷。"用户说过的话什么时候该被记住、什么时候该被遗忘"，这是一个产品决策，不是一个工程参数。
举个构造的例子。做一个客服助手，用户第一轮说"我是企业版用户"，第十轮问"这个功能我能用吗"。这时候：
- 第一轮那句话还在上下文里吗？（记忆边界）
- 如果用户中途说"帮我朋友问一下"，身份还算数吗？（状态迁移）
- 如果用户身份在系统里其实是个人版，以哪个为准？（冲突裁决）
- 对话到第五十轮要压缩历史时，什么信息必须保留？（压缩优先级）
这四个问题传统 PRD 一个都不会写，因为过去"用户状态"是存在数据库里的确定值，不是一段可能被挤出内存的文本。
怎么补
在需求文档里增加一节，我称之为信息时序：这个功能在每一个决策点上，需要哪些信息在场、哪些必须不在场、冲突时谁优先。这一节写起来会很像权限矩阵，只不过主体从"谁能做什么"变成了"什么时候能看见什么"。
七、素质四：评估能力——非确定性系统没有"通过 / 不通过"
什么变了
OpenAI 的 CPO Kevin Weil 在一次面向产品经理的公开对谈里说过一句被反复引用的话：
"Writing evals is going to become a core skill for product managers. It is such a critical part of making a good product with AI."
（写评估将成为产品经理的核心技能。这是用 AI 做出好产品的关键环节。）
Teresa Torres 在她 2026 年初的文章里把"写 eval"称为过去一年多产品团队里最热的技能，并且给了一个更有意思的定位：eval 是一种新的发现习惯（discovery habit）——它不是测试，是一种理解产品在真实世界里表现如何的方法。
她同时给了一个具体的警告：如果去掉人工审阅，AI 生成的摘要会漏掉 20% 到 40% 的重要细节。
为什么传统验收标准失效了
这是本文最技术性的一节，但对产品经理最实用。看一个对照。
传统功能，验收标准可以这样写：
Given 用户已登录且拥有导出权限
When 点击"导出"按钮
Then 下载一个 CSV 文件，包含全部 12 个字段，
文件名格式为 export_YYYYMMDD.csv这条标准的性质是：可以验证一次，然后永久有效。同样的输入永远产生同样的输出。
换成 AI 功能，同一个格式立刻崩溃：
Given 用户上传一份会议纪要
When 点击"生成摘要"
Then ???- 写"生成一份好的摘要"——不可验证，"好"没有定义。这是公司写作红线里的典型模糊词。
- 写"生成 100 到 200 字的摘要"——可验证，但没说到点上。字数对了内容错了，一样没用。
- 写"生成准确的摘要"——看似严格，实际上无法判定：准确率要测一次还是测一千次？98% 算通过吗？剩下 2% 是随机分布还是集中在某类输入上？
失效的根源在于三件传统验收标准无法表达的东西：
| 新问题 | 说明 |
|---|---|
| 非确定性 | 同一输入多次运行，输出不同。"通过"变成了一个概率，不是一个事实 |
| 渐变质量 | 正确性不是二元的。一份摘要可以"大体对但漏了最重要的那条" |
| 静默劣化 | 模型或数据分布漂移后，质量会悄悄下降，而没有任何报错 |
第三条最危险。传统 bug 会报错，AI 的退化不会——它只是慢慢变差，而你的监控面板上全是绿的。
一个可用的替代结构
调研里能找到的最可操作的模板，是把验收标准拆成行为、门槛、安全三段。用刚才那个会议摘要举例：
【行为】
对任意输入的会议转录稿，生成 100-200 字摘要，
覆盖全部决策事项，以及至少 80% 的行动项；
每项行动项尽量标注负责人。
【门槛】
在 Q2 评估集（250 份转录稿）上：
- 质量评分 ≥ 4.0（5 分制）
- 幻觉率 < 3%
- 任何单个案例评分不低于 2.5
【安全】
- 转录稿被标记为机密、或含 HR / 法律类目时，拒绝执行
- 绝不透露非参会人员的可识别个人信息三段各自解决一个问题：行为段替代了传统的功能描述；门槛段把"对"变成了可测量的分布，而不是一个布尔值；安全段处理的是"宁可不做也不能做错"的场景。
门槛段里有个细节值得单独说：聚合分数必须搭配单案例下限。只写"平均分 4.0"是不够的——250 个案例里 240 个满分、10 个零分，平均分照样很好看，而那 10 个零分可能全是你最重要的客户场景。这个坑和只看平均响应时间不看 P99 是同一类错误。
必须承认的空白
这套写法来自从业者社区，没有任何标准组织或学术机构背书。我在调研里明确确认了两件事：
- 没有找到任何机构发布的 AI 产品验收标准统一框架（不是没找到好的，是没找到任何一个）。
- 幻觉率没有行业通用阈值。上面那个 3% 是示例，不是标准。有一篇预印本论文提出过"持续显示 10% 幻觉率则判定为未就绪"的方法，但那是单篇论文的提法，不是共识。
这意味着这块的阈值只能自己定，并且定的过程本身就是产品决策：3% 的幻觉率在写会议摘要上也许可以接受，在生成医嘱上显然不行。定这个数，就是在定产品的风险偏好，这件事没法外包给研发。
怎么补
Hamel Husain（与人合著了一门 4500 多名学员、来自 500 多家公司的 evals 课程）的方法论核心是一条顺序上的告诫：
先做错误分析，再写 eval，而不是跳过分析直接写 eval。
错误分析指的是人工逐条审阅真实用户轨迹，找出失败的模式，然后把失败模式分类（他建议控制在 10 个主类以内），最后才针对这些类别写评估。
这个顺序对产品经理特别友好，因为第一步就是看真实用户怎么用你的产品——这本来就是产品经理最该做的事，只是对象从点击流换成了对话记录。
八、素质五：为失败设计——写在提示词里的约束不是约束
回到 Replit 那起事故
前面留了个尾巴。这起事故最流行的解读是"AI 不可信"，但这个解读没有任何可操作性——它既不能指导你做什么，也不能防止下一次。
更有用的解读是：代码冻结这条指令，只存在于提示词文本里；在执行链路上，没有任何机制真正阻止写操作。
也就是说，这不是模型失控，这是需求里少写了一条。同样的结构如果发生在传统系统上，我们会毫不犹豫地判定为设计缺陷：一个后台管理系统，如果"禁止删除生产数据"只写在操作手册里，而没有做成权限控制，任何一次评审都会被打回。
一条可以直接用的判据
如果你写的"不允许 X"只能被模型读到、不能被系统强制，那它就不是约束，只是建议。
模型会不会遵守建议，是个概率问题。而你在需求文档里写下它的时候，心里想的是必然。
为什么这一条落在产品经理身上
因为这恰恰是传统产品经理的老本行，只是对象变了。
你已经很熟悉这几张表：异常与边界表、数据规则表、权限矩阵。AI 功能需要的不是新方法，是把同样的方法用在一个新对象上——把 AI 当成一个能力很强、但会在 45% 的安全抉择上选错、有 3% 概率编造事实、且无法被指令完全约束的执行者，然后按对待这样一个执行者的方式设计权限。
具体到需求文档里，至少要回答这几个问题：
| 问题 | 传统系统的对应物 | AI 功能里的写法 |
|---|---|---|
| 哪些操作不可逆？ | 删除、扣款、发送、发布 | 这些操作一律不给模型直接执行权，只能生成待确认的意图 |
| 出错怎么回滚？ | 事务、软删除、操作日志 | 模型的每次写操作都要留可追溯记录，且可逆 |
| 谁来拦？ | 二次确认、审批流 | 人工闸门放在哪一步，以及谁有权跳过 |
| 环境隔离了吗？ | 测试库 / 生产库分离 | 模型能触达的数据范围，默认应是最小集 |
| 降级方案是什么？ | 服务不可用时的兜底 | 模型输出不可用或不可信时，功能退回到什么状态 |
最后一行经常被漏掉。"模型答不出来的时候界面显示什么"——这是一个纯粹的产品问题，但我见过的很多 AI 功能需求都没写，于是最后线上显示的是一句研发随手写的"服务异常，请稍后重试"，而用户真正需要的可能是"我没法回答这个，但这里是相关的三篇文档"。
怎么判断自己不具备
看你最近一份涉及 AI 能力的需求文档，数一下描述"正常路径"的篇幅和描述"出错路径"的篇幅之比。传统功能这个比值大概在 2:1 到 3:1 之间是健康的。AI 功能如果你的比值还是 10:1，说明你把它当成确定性系统在写。
九、素质六：最小可行技术知识量
什么变了
Ethan Mollick（沃顿商学院教授）在 2025 年 3 月的文章里给了一个我认为最准确的判断：vibe coding 的本质不是消灭专业知识，而是重新分配专业知识——从"写每一行代码"，变成"懂得足够多，去指导、排障、评估 AI 的产出"。
他把随之而来的核心挑战概括为一个问题：找到某个项目所需的最小可行知识量（minimum viable knowledge）。
这个提法比"产品经理要不要学编程"这种二元问题有用得多。它把问题从"学不学"变成了"学到什么程度够用"。
产品经理的最小可行知识量是什么
这部分没有权威来源，是我基于前面所有证据的归纳，供参考。我认为有五条：
一、能看懂一次请求返回了什么。 不需要会写接口，但要能打开浏览器的开发者工具，看到"这个页面上显示的数字，到底是后端算好的，还是前端算的"。这决定了你提的需求改一个数字是改一行代码还是改一条链路。
二、知道哪些操作是不可逆的。 删除、扣款、发送、对外发布。这份清单很短，但它决定了上一节所有的权限设计。
三、知道什么东西贵。 模型调用按 token 计费（token：模型处理文本的最小单位，大致上一个汉字一到两个 token），所以"把整份文档塞进去"和"只塞相关段落"的成本差异可能是十倍；全表扫描在数据量小的时候看不出问题，在数据量大的时候会拖垮整个系统。知道这些，你才能判断一个功能是不是在用一种不可持续的方式实现。
四、能判断"这个做不了"是真做不了还是不想做。 这条最难，也最值钱。可行的近似方法是追问机制而不是追问结论：不要问"能不能做"，问"卡在哪一步"。真的做不了，对方能说出具体卡点；不想做，对方给的多半是笼统的"架构不支持"。
五、知道自己的产品跑在什么之上。 数据库、第三方接口、模型 API，各是哪一家，哪个挂了会怎样。你不需要会修，但你需要在故障发生时知道该问谁、以及大概多久能恢复——这直接决定你对外怎么说。
关于"产品经理要不要自己做原型"
要，但价值不在你以为的地方。
据 Lenny's Newsletter 的调研，产品经理从 AI 工具获得价值最大的用途，第一是写 PRD（21.5%），第二才是做原型（19.8%）。而原型这件事的真正价值，我认为是压缩反馈环：把"我想的这个交互到底顺不顺手"，从"等两周排期后才能试"变成"今晚就能试"。
这是探索工具，不是交付工具。混淆这两者的后果很具体：把原型当成可上线的东西推给研发，制造技术债——而 GitClear 的数据已经说明这类债在以什么速度累积。
Lenny's 的同一份调研里还有个耐人寻味的解释，说明为什么产品经理用 AI 写 PRD 的比例最高：因为 PRD 有清晰的产出物可以判断好坏，而且PRD 的"稍微好一点的初稿"就有用，而一个有 bug 的函数没用。PRD 的质量门槛天然更低——这句话是夸 AI 还是损 PRD，各人理解。
十、被高估的四件事
这一节是我认为本文最有价值的部分，因为前面九节的内容在各种地方都能看到，而下面四条通常不会有人说。
高估一：产品经理必须会 vibe coding
三条反证：
- 造词人自己弃用了这个词，并改用一个强调"审核产出"的新词。
- 连资深工程师的效率增益都不确定（METR），而且做完任务的人对自己速度的判断偏差高达 39 个百分点。一个每天写代码的人尚且如此，产品经理凭什么认为自己对"我用 AI 做得又快又好"的感觉是准的？
- 45% 的安全抉择会选错（Veracode）。产品经理不具备发现这些错误的能力——不是因为不够聪明，是因为没有那个领域的模式识别。
正确的说法应该是：产品经理应该会用 AI 快速验证想法，这与"会写生产代码"是两件事。
高估二：提示词技巧
这个技能的保质期已经过了。Karpathy 本人的说法是 prompt 这个词"把一件相当复杂的事情过度简化了"，行业术语已经整体迁移到上下文工程。
区别在哪？提示词技巧关心的是"这句话怎么说"，上下文工程关心的是"在什么时刻让它看见什么、什么时候让它忘掉"。前者是话术，后者是信息架构设计——后者恰好是产品经理的传统强项，但它不在任何一门"提示词课程"里。
高估三：AI 工具熟练度
Indeed Hiring Lab 的官方数据给了一个很说明问题的观察：约四分之一的 AI 相关招聘广告对"AI 具体怎么用"缺乏说明，74% 只写了泛化的"AI"，只有 2% 提到了具体的工具或模型名称。
这条数据有两层含义。表层是"AI"这个词正在被当成招聘噱头滥用；深层是工具名不构成壁垒——如果它是核心能力，JD 会写清楚要哪个。
再看工具本身的更替速度：据 JetBrains 2026 年 1 月的调研，GitHub Copilot 的专业认知度 76%，实际工作使用率只有 29%，且增长停滞。认知与使用之间的巨大落差说明，大量人试过就放下了。你花三个月精通的工具，很可能在下一个三个月里不再是主流。
值得投入的是工具背后不变的那部分：怎么把意图表达清楚、怎么验证产出、怎么设计兜底。这三样换十次工具都还在。
高估四：PRD 已死
我在调研中只找到一篇以"PRD 之死"为明确主张的文章，样本极窄，不构成行业讨论。而分量更重的两位——Marty Cagan 和 Teresa Torres——立场恰恰相反：产品经理的角色变得更关键，产出物在增加新维度（eval、上下文设计），而不是整份被淘汰。
不过那篇文章里有一条批评是成立的，值得单独摘出来：传统 PRD 是为"文档和实现是两拨人在两个时间做的两件事"这个世界设计的。没人会真的去更新 PRD，于是它最终变成"三个月前我们以为要做什么"的纪念碑。
这个批评在 AI 时代之前就成立，只是 AI 让它变得更刺眼——因为实现速度快了十倍，而文档更新速度一点没变。
十一、市场在发什么信号
这一节的数据来源质量参差，我按可信度从高到低排。
最可信的一条，来自 Indeed Hiring Lab（招聘平台的官方研究部门）：
- 截至 2025 年末，提及 AI 的招聘广告较 2020 年 2 月基线增长 134%，而同期整体招聘量只高 6%。这说明 AI 相关岗位的增长是结构性的，不是大盘回暖带动的。
- 2026 年 7 月的报告：软件开发类招聘广告自 2025 年 2 月末以来增长近 15%，而同期整体招聘广告下降 7%。但复苏很窄——2025 年 5 月到 2026 年 5 月的增长中，71% 来自高级岗位，37% 来自标题含"AI"的岗位。软件开发岗位总量仍比疫情前低约 27.5%。
次可信，来自具名专家的公开立场：Marty Cagan 明确说交付型的产品 owner"不是一个安全的工作"。这与上面"71% 增长来自高级岗位"是同一个方向的信号。
较弱，仅作参考（均为二手转述，未能核实到一手来源）：有报道称 LinkedIn 取消了传统的 Associate Product Manager 项目，改为 Associate Product Builder，申请不要简历，只要一段"60 秒展示你用 AI 做出的东西"的演示视频。国内方面，据媒体统计，字节跳动 2026 届校招官网 2559 个岗位中有 1205 个与 AI 直接相关，阿里计划发放的 offer 中 AI 相关岗位占比超六成，腾讯专门设有 AI 产品经理培训生项目。
把这些信号放在一起，方向是一致的：岗位在往上收口。 执行型、传递型的产品岗位在被压缩，判断型、验证型的岗位在增加。这与第三节"瓶颈从生成端移到验证端"的推论互相印证——需求不是消失了，是移动了。
需要提醒的是薪资类数据我没有采用：不同来源之间的均值差距超过四万美元，口径完全不统一，引用任何一个都是误导。
十二、一份自检清单
把前面六项素质压缩成可以今天就做的动作。每一条我都尽量写成一个能给出是 / 否答案的检查项，而不是一个态度。
| # | 检查项 | 不通过意味着 |
|---|---|---|
| 1 | 最近三个需求，我能说出每个放弃了什么 | 在排列需求，不在做判断 |
| 2 | 我的需求文档有"明确不做"一节，且里面是真的有人想做的事 | 缺少边界，下游会不断扩张 |
| 3 | 把需求文档丢给 AI 编码工具，它自作主张的地方我都能预料到 | 文档里有你不知道的洞 |
| 4 | 涉及 AI 能力的需求，验收标准里有可测量的门槛而不只是描述 | 验收时无法判定通过与否 |
| 5 | 这些门槛的数值（准确率、幻觉率）是我定的，不是研发定的 | 把产品风险偏好外包了 |
| 6 | 聚合指标搭配了单案例下限 | 平均分会掩盖极端失败 |
| 7 | 需求里所有"不允许 X"，都有系统层面的强制手段，而非仅写在提示词里 | 约束只是建议 |
| 8 | 不可逆操作（删除、扣款、发送、发布）都不由模型直接执行 | 具备 Replit 事故的同构条件 |
| 9 | 写了模型输出不可用时的降级状态 | 线上会出现研发随手写的兜底文案 |
| 10 | 出错路径的篇幅至少是正常路径的三分之一 | 在按确定性系统写非确定性功能 |
| 11 | 我看过至少 50 条真实的用户对话记录，并归纳了失败模式 | 评估会建立在想象的失败上 |
| 12 | 我知道这个功能哪一步最贵，以及贵在哪 | 无法判断实现方式是否可持续 |
不必十二条全过。我的建议是从第 7、8 两条开始——它们代价最低、后果最严重，而且不依赖任何新技能，只依赖你已经会的权限矩阵。
结语
回到开头那个十二个月的故事。
一个词被造出来，被词典加冕，然后被造词人弃用——这个循环的速度，本身就是这个行业当下状态的最好写照：叙事的更新速度远快于事实的积累速度。在这种环境里，最容易犯的错误不是学得慢，是按最新的叙事重构自己，然后发现叙事变了。
所以这篇文章的落点不是一份要追的清单，而是一个判断的依据：去看成本结构变了哪里。
生成变便宜了，所以"能做出来"不再是稀缺能力；验证没变便宜，所以"知道它对不对"变成了瓶颈；错误的总量上升了，所以"为出错做设计"从一项加分能力变成了准入条件。
a16z 那句话值得重复一遍：模糊性不会消失，只会换个地方。 产品经理这个岗位存在的理由，从来不是因为工程资源稀缺所以需要有人来排优先级，而是因为在把"人想要什么"翻译成"系统该做什么"的过程中，永远有一段无法自动化的判断。
AI 把这段判断往后推了，推到了验证端、评估端、兜底设计端。它没有把这段判断消灭掉。
真正需要担心的，从来不是"AI 会不会取代产品经理"，而是一个更朴素的问题：当做出来只要一个下午，你还有什么理由认为，值得做的那件事会自己浮现出来？
主要参考来源
概念与词源
- Andrej Karpathy 原始推文（2025-02-02）
- Merriam-Webster: vibe coding 词条
- Collins Dictionary 2025 年度词汇
- The New Stack: 从 vibe coding 到 agentic engineering（2026-02）
- Karpathy 关于 context engineering 的推文（2025-06-25）
效率与质量数据
- METR: 早 2025 年 AI 效率随机对照实验（2025-07-10）
- METR: 2026 年 2 月方法论更新
- Stack Overflow 2025 开发者调查 · AI 章节
- 2025 DORA Report
- GitHub: 量化 Copilot 对开发者生产力的影响
- GitClear: 2025 AI 代码质量研究
- Veracode: 2025 GenAI 代码安全报告
- Stanford: 用 AI 助手是否写出更不安全的代码（2022-2023）
- Fortune: Replit 删库事故报道（2025-07-23）
规格与上下文
- GitHub Blog: Spec-driven development with AI（2025-09-02）
- github/spec-kit
- AWS Kiro: Specs 文档
- Martin Fowler / Birgitta Böckeler: 理解规格驱动开发
- Sean Grove, The New Code（AI Engineer World's Fair）
- Anthropic: Effective context engineering for AI agents（2025-09-29）
- LangChain: Context Engineering for Agents
角色与评估
- a16z: 5 Principles for Product Managers in the AI Era（2025-05）
- SVPG / Marty Cagan: A Vision For Product Teams
- Teresa Torres: My 2026 Roadmap
- Ethan Mollick: Speaking Things Into Existence（2025-03-11）
- Lenny's Newsletter: Kevin Weil 访谈
- Lenny's Newsletter: Why AI evals are the hottest new skill
- Hamel Husain 的 evals 方法论
招聘信号
关于本文的证据处理
文中所有百分比与实验结论均来自上述公开来源。对于二手转述且未能核实到一手出处的材料（LinkedIn 岗位调整、国内大厂校招统计、部分专家转述），我在正文中已明确标注"据报道"或"二手转述"。薪资数据因不同来源口径差异过大（均值差距超过四万美元）未予采用。
需要特别提醒的是 METR 那项实验：它是本文引用的最强证据，也是最容易被误用的一条。METR 自己已将其标注为历史结果，引用时必须同时说明这一点。