AI Product 方法论

来源：「厂内 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 真正不可让渡的核心价值。 ...

“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 不一定是最优解，但 降低用户表达意图的成本 是设计核心。 ...