For PMs

来源：「厂内 AI 实践学习档案」2026-04-19 ～ 2026-05-11 | 30+ 篇实践案例提炼 整理人：hongxinbo | 整理时间：2026-05-11 一、最高频共识：AI 质量上限定律 AI 生成的质量上限 = 人的规约/设计文档的质量上限，与模型能力无关。 这是出现频率最高（8+ 次）的核心结论，被以下实践反复印证： Spec-Driven 四层规约：「两天两万行代码只出一个 bug」的底层密码 Design Token：有 Token，AI Demo 还原度 20% → 90%+ 0 行手写代码反而要求更多深度思考 NMLeak、OOM 排查：Plan 模式前置 = 结构化对齐 > 直接生成 Superpowers 强制澄清流程：纪律 > 智力 实操结论：每个功能开始前花几百字写清楚——问题背景、边界条件、验收标准、不做什么。前置思考 1 分钟，节省后期 10 倍返工时间。 二、Spec-Driven 规约体系（四层） 适用场景：长期项目、核心系统、多人协作 架构层（Architecture） ↓ 服务边界、数据流向、技术选型 契约层（Contract） ↓ 接口定义、数据结构、依赖关系 具体规格层（Specification） ↓ 每个功能的行为描述、边界条件、异常处理 Story 交付清单（Stories） ↓ 可验证的最小交付单元，含验收标准 核心价值：把脑子里的隐含假设显性化为可执行规约，人定义边界、AI 填充实现。 「反向采访」技术：把问题+背景+架构给 AI，让它以架构师角色主动向你提问，把隐含假设全挖出来——比直接命令 AI 更有效。 三、Vibe Coding vs Spec Coding 的适用边界 维度 Vibe Coding Spec Coding 适用场景 短期/小功能/快速验证/Demo 长期/核心系统/多人协作/生产级 前置投入 低 高（方案和 Spec 前置近 4 天） 输出质量 不稳定 「两天两万行代码只出 1 个 bug」 返工风险 高（数据库设计/接口划分等架构决策一旦 Vibe 进去需完全重做） 低 PM 边界 PM Vibe 1 天做 Demo，RD 花 1 周重构核心 PM 定义 WHAT，AI 负责 HOW 关键洞察：速度感是假象，架构判断才是 PM 真正不可让渡的核心价值。 ...

事情是这样的 2026 年 1 月 10 日，一款叫「死了么」的 App 登顶 App Store 付费榜。 产品本身简单到有点寒酸：只有一个页面，中间一个签到按钮。填好用户名和紧急联系人的邮箱，连续两天没签到，系统就会给联系人发一封邮件——「我是某某，我已经连续 2 天没有活动了。快来检查下我的身体状态。」 定价 8 元。开发成本 1000 多块。3 个 95 后远程协作，花了不到一个月。 1 月 15 日，App 在国内应用商店下架。下架前 3 天，创始人原计划 100 万卖 10% 股权，竞价到近千万；团队透露估值已达 1000 万元，60 多个投资人在 3 天里主动找上门。 一个从技术到创意都不独特的应用，为什么能这样爆？ 一、爆火的真实原因：不是产品，是圈层 1. 名字本身就是传播引擎 「死了么」3 个字，完成了三件事： 蹭到「饿了么」的语义结构，读一次就记住 踩到了「死」这个在中文语境里被压抑的禁忌词，自带话题性 用黑色幽默精准筛出目标用户——能 get 到这个笑点的，就是它想要的人 同赛道的「善言」(2020) 和「朝气」(2025) 都不火。「朝气」开发者告诉界面新闻，他原本申请的名字是「死了吗」「活着呢」之类，都因为工信部备案过不了，只能改成积极向上的名字。「死了么」团队据传是通过 App Store 后台改名绕过审核，ICP 备案号对应的名字其实是 Demumu。 监管画的那条线，本身就是爆款的筛选器。敢踩线、能踩到还能上线，就具备了稀缺性。 2. 它解决的是一个微信解决不了的问题 独居青年每天在微信里有几百条消息、朋友圈点赞不断，为什么还需要「死了么」？ 人人都是产品经理的分析戳中了要害：点赞社交 ≠ 生命守望。 你三天没发朋友圈，朋友只会觉得「他最近挺安静」。但你连续两天没签到，系统会判定这是一次无人知晓的意外。前者是泛泛之交，后者是性命相托。 微信是社交网络，它默认你活着；「死了么」是生命信号，它默认你可能已经不在了。这是两套完全不同的预设，也是通用社交软件天然覆盖不到的空白。 3. 低成本 + 高传播的极致组合 维度 数值 开发成本 1000 多元 团队规模 3 人远程 开发周期 不到 1 个月 起售价 1 元 → 8 元 爆发期下载量 涨了 100 倍以上 估值 1000 万元 它几乎没有营销——小郭自己也说，爆火是用户自发传播。一个话题性拉满的名字 + 一个 8 块钱的门槛，这本身就是最便宜的 PMF 测试。 ...

回顾这一年 过去这一年，我在百度贴吧主导了三个 AI 方向的项目： 抓虾吧 Agent 社区 — 从 0 到 1 搭建 AI 智能体社区，上线即登微博热搜总榜 #12 AI 小游戏 & Vibe Coding — 搭建"自然语言→AI 小游戏"的 UGC 创作生态 AI 表情包 — 落地 AI 生图表情包全链路，面板曝光提升 51% 这三个项目让我对"大模型时代做产品"有了一些不一样的理解。 方法论的"变" From PRD to Prompt Design 传统 PM 写 PRD 定义产品逻辑，AI PM 需要额外做一件事——Prompt Design。 这不是说 PM 要替代工程师写 prompt，而是 PM 需要理解 prompt 的设计原则，才能准确定义 AI 功能的预期行为。当你不了解 Chain-of-Thought 和 Few-Shot 的区别时，你很难写出一个好的 AI 功能需求文档。 From A/B Test to Eval Pipeline 传统的 A/B 测试依然有效，但 AI 产品需要更多——一套完整的 Evaluation Pipeline。 ...

“AI-Enhanced” vs “AI-Native” 很多产品在做的事情是 AI-Enhanced——在现有流程上叠加一个 AI 功能。比如搜索框加个"AI 总结"，编辑器加个"AI 续写"。这当然有价值，但这不是 AI-Native。 AI-Native 产品的核心特征是：AI 不是功能，而是基础设施。 产品的核心体验围绕 AI 能力设计，去掉 AI 这个产品就不存在。 举几个例子： 产品 AI-Enhanced AI-Native 搜索 搜索结果加 AI 摘要 Perplexity — 对话即搜索 编程 IDE 加 Copilot 补全 Cursor — AI 是编程的主循环 社区 帖子加 AI 评论 Agent 社区 — AI 是内容生产者 Three Principles of AI-Native Design 1. Interaction Model Redesign 传统产品的交互是"用户操作 → 系统响应"。AI-Native 的交互是 “用户表达意图 → AI 理解并执行 → 用户确认/调整”。 这意味着 UI 要从"功能菜单"转向"意图表达"。Natural Language Interface 不一定是最优解，但 降低用户表达意图的成本 是设计核心。 ...