产品方法论简介

产品方法论简介

本页是产品方法论栏目的入口与导航中枢，面向有经验的产品经理和准备 AI PM 岗位的候选人——这里不讲"什么是产品经理"式的科普，只讲能直接用的判断框架与决策链。栏目主体是一条从机会到商业的决策链——每篇回答一个具体决策问题：做什么、为谁做、怎么设计、怎么按时交付、怎么迭代校准、怎么让开发照做、怎么赚钱；其中「产品设计与原型」在总览之上另辟七页深度类目（设计哲学、视觉、交互、系统、原型、评审、黑话），供按需深入，两条线都以总览页为枢纽串联。

先用一张总图看清整条链，再按自己的场景选「分场景阅读路径」；每篇的位置、产出与误用见「内容列表」。

本页可以当「面试前 15 分钟地图」使用：读完能说出每篇解决什么问题、怎么串起来，也能指出「评测结果会推翻需求优先级」这类环节间的关键关系。

方法论总图

一个 AI 产品从机会到增长的完整闭环，大致走七个环节：

读图方式：从手头的场景切入，而不是从第一行开始——0 到 1 立项从机会判断进入，改造现有功能从用户研究进入，企业级落地从需求分析进入。每个环节往下走时，带着上一环的产出逐项检查：问题定义够不够具体、用户证据是否支撑需求、需求是否写得可验收、设计是否覆盖失败路径、迭代是否有评测兜底、商业是否算得过账。对不上的地方，就是当前最该补的环节。

整张图里有两个最容易被跳过的回环：一是 AI 校准回到机会判断——评测发现需求不成立时，回去改需求定义，而不是硬修模型；二是商业化回到产品设计——毛利不达标时先改模型选型与交互降本，而不是只调价格。

一个完整走查（客服工单助手）：机会判断——从「工单流转太慢」的抱怨出发，访谈发现真正的痛点是路由靠人工按标题判断；用户研究——一线客服日均 500 张工单，按退款/物流/投诉/咨询四类分布；需求定义——PRD 写清「只做路由建议、不做自动回复」，路由准确率 ≥ 90% 才算好；产品设计——路由界面放「一键改路由」兜底，识别失败直接转人工；交付迭代——按「两快一慢」节奏先给 10% 工单灰度；AI 校准——每周抽 30 条低置信度工单人工复核，错误回填评测集；商业化增长——按单次调用成本 × 月调用量算账，先确认毛利为正再放量。

为什么产品方法论重要

• AI 改变技术底座，不改变产品本质：一个 AI 产品是否成功，仍然取决于需求是否真实、体验是否顺畅、成本是否可控、商业是否成立。模型再强，需求是伪需求也白搭——典型的失败是"先做一个智能助手"：功能做了半年，用户没有真实场景，能力越强越不知道该往哪用。
• 需求是产品工作的起点：《俞军产品方法论》把"用户价值 = 新体验 − 旧体验 − 替换成本"作为第一公式，《人人都是产品经理 2.0》的 Y 模型提醒"用心听，但不要照着做"——用户说的表层需求背后是目标动机，方法论的第一个作用就是把模糊诉求变成可判断、可分级、可执行的需求（需求分析）。
• 方法决定迭代效率：《精益创业》把进步定义为"验证式学习"而非功能交付，《启示录》强调发现与交付的连续循环——产品失败大多不是执行差，而是用昂贵的方式验证了错误假设；方法论的价值是让你用最小成本尽早证伪（详见读书笔记）。
• 方法论是团队的共同语言：CC/CD 框架的底层是判断力——发什么、出错时怎么保护用户、何时交还控制、何为"足够好"——框架给优秀的产品直觉一个循环、节奏和共同语言，让产品、工程、数据在同一节奏上协作（AI 产品开发生命周期）。
• AI 放大了方法论的必要性：不确定性进入了需求的每个环节（模型能不能做到、效果达不达标、成本会不会失控），方法的作用是把这些不确定性翻译成可决策、可管理的产品问题——这正是能力模型里"翻译与仲裁"的定位。

内容列表

本栏目与其他栏目的分工：AI 基础回答"模型能做什么"（能力边界与评测），实战回答"具体产品形态怎么设计"（Agent、Copilot、知识库问答），工具回答"怎么算账"（成本、数据），求职回答"怎么把方法论讲给面试官"。本页负责把方法论串成决策链。

决策链上的正文按使用顺序排列，每篇解决一类决策问题：

产品设计与原型已扩为深度类目：总览页之外，另有设计哲学与设计思维、视觉设计基础、交互设计基础、设计系统与规范、原型与设计交付、设计评审与可用性度量、设计师黑话速查七页，对应设计流程的各条支线，需要深入某一环时按名进入。

相关枢纽页（正文之外，本专题高频引用）：

• 评估与评测：评测集怎么建、线上指标怎么定、三层评估体系
• 模型能力与边界：判断"模型做得到做不到"，需求可行性的依据
• Agent 产品设计：代理权分级、确认点与护栏的实操
• LLM 成本估算：从单次调用到月成本的完整估算方法
• 数据与标注：埋点、标注与反馈回流，数据飞轮的落地
• 出海与合规：合规是开发前置约束，不是上线前补的检查项
• 读书笔记：四本经典的精读笔记，方法论的底层语言

这些枢纽页与决策链正文的关系：正文给判断框架，枢纽页给落地工具——评测、成本、合规是 AI 产品经理相对传统 PM 的新增必修课，正文里引用它们的地方就是衔接点。

分场景阅读路径

0 到 1 立项：需求分析 → 用户研究 → PRD → 商业化。

为什么是这个顺序：先证明"值得做"（需求分析判断价值与优先级），再搞懂"为谁做"（用户研究），然后把判断落成开发照做的文档（PRD），最后在立项前确认"赚钱的账算得过来"（商业化）——AI 立项最怕做到一半发现赚不回推理成本。这条路径里最容易跳过的环节是商业化：推理成本要在立项前验证，而不是上线后。消费级 C 端产品可以把商业化后置到验证 PMF 之后——先验证留存与口碑，再谈定价，但推理成本仍然要在立项时算清楚。

已有功能改造：用户研究 → 产品设计 → AI 生命周期 → PRD。

为什么是这个顺序：改造的前提是知道现状哪里不对（用户研究看真实使用与失败模式），再改交互与兜底（设计），用 CC/CD 节奏小步校准而不是推倒重写（生命周期），最后把改动落进 PRD 让开发照做——别一上来就换模型、重写提示词，先问"错在哪一类"：可能是评测、数据或交互问题，而不是模型问题。

企业级落地：需求分析 → 项目管理 → AI 生命周期 → 合规与商业化。

为什么是这个顺序：企业客户必须先区分 buyer / user / operator——买单的人、日常使用的人、运维的人诉求常常冲突（需求分析），再谈交付节奏与干系人管理（项目管理），Agent 自主度按信任逐步放开（生命周期），合规（数据出境、算法备案）是前置约束，最后用单位经济谈价格（商业化）。最常见的坑是把 operator 当 user 访谈——天天面对系统的人，才是错误模式与交接需求的一手来源。

面试答题：方法论总图 → 需求分析 → PRD → 商业化，再结合知识库页面组成完整答案。

为什么是这个顺序：先有全局地图，能说清环节关系（"评测结果会推翻需求优先级"比堆名词高级）；需求分析给"做什么"的判断框架，PRD 给"怎么把 AI 功能写清楚"的模板（面试高频题），商业化补单位经济视角——这是区分普通 PM 与 AI PM 的加分项；遇到 Agent、评测类题目，再补 Agent 产品设计与评估与评测的细节。答题时先把总图放进引言——先给框架再给细节，是结构化答题的基本功。面试准备的具体方法见产品经理求职与面试。

系统学习（转岗/自学）：为什么产品方法论重要 → 方法论总图 → 需求分析 → 用户研究 → PRD → AI 生命周期，最后回到能力模型自测。

为什么是这个顺序：先用"为什么重要"建立动机，再用总图建立全局（不会学一篇忘一篇）；需求分析与用户研究是入门第一步（对应能力模型的 ② 产品方法论），PRD 是把前两者串起来的交付物，AI 生命周期解释 AI 特有的迭代节奏；学完对照能力模型的自测清单找短板，再补 评估与评测与 LLM 成本估算。四本读书笔记适合在学完正文后对照阅读——正文是方法，笔记是底层语言。

设计专题：产品设计与原型总览 → 按需钻进设计哲学、视觉、交互、原型交付、评审度量等深度页——画原型、做评审或面试设计题前，先看总览搭框架，再钻对应支线。

AI 带来的新变化

AI 产品的方法论在通用框架之上有一些新的特点。原有的三个判断仍然成立：能力驱动创新（需求往往由"模型能做什么"启发，落地前先用 Playground 验证"模型能不能做到"）、迭代成本变化（调模型、写提示词比写功能代码快得多，但要学会"用评估说话"）、不确定性管理（模型输出不可完全预测，产品需要设计兜底与降级策略）。在此基础上，还有七个必须纳入决策的变量：

概率性输出：需求、设计、PRD、评测都要写"好坏标准"，而不是"对错断言"。验收从"测试用例断言精确结果"变成"评测集评估做得好不好"——每个 AI 功能都要回答：做到什么程度算好、由谁评、多差算不可接受。设计上体现为可解释、可纠错、状态可见；PRD 里每条功能需求都要跟一条评测指标。

代理权阶梯：从建议、草稿、确认执行到受限自治，每一级都有权限、护栏、回退责任。代理权靠表现逐步赚取，而非一次性授予（CC/CD 框架）：先让它给建议，用数据证明"犯错时可控"再放开执行权；不可逆操作必须有人工确认点（Agent 产品设计）。每一级都要提前回答：出错了谁负责？用户能一键接管吗？

评估成本：评测集、人工抽检、线上指标、回归集不是一次性成本，而是随产品生命周期持续投入的固定支出——评测集会失真，需要回填与轮换；预算里不写评估成本，效果就是开盲盒。建议把评测成本写进项目预算与排期，而不是当作临时加班。

数据飞轮：反馈、纠错、真实错误回填决定模型/产品能否持续变好。埋点要记录"系统看到什么、返回什么、用户怎么改"，错误要回流进评测集——没有飞轮的产品，每次迭代都在原地打转。第一版就要埋好反馈入口：没有反馈入口的 AI 功能等于盲飞。

模型依赖：模型版本、供应商、成本结构、能力边界都是产品变量，不是工程的内部细节。换模型等于换能力边界与成本结构，需求要留出抽象层、要有基线评测与固定版本策略。选供应商时同步评估退出成本：换供应商时，评测集与数据管道能否平移？

推理成本：单位经济从传统 SaaS 的"边际成本趋零"变成"每次调用都有 COGS"。单次几分钱、日调用十万次就是几千块，成本要写进 PRD、按毛利率监控（LLM 成本估算）。定价要覆盖推理成本与护栏成本，毛利按月监控，超限自动降级。

合规与安全：内容安全、数据用途、算法备案、模型供应链组成前置约束——不是上线前补的检查项，而是从一开始就要做的设计约束（出海与合规）。至少在需求评审时过一遍合规清单，而不是等法务来拦。

落地判断口诀：先问"怎么算好"，再问"错了怎么办"，最后问"一个月烧多少钱"——三个问题都答得出，才进入开发。答不出任何一个，说明对应的环节（评测、兜底、成本）还没做实，回到方法论总图补那一环。

方法论的边界

• 框架是决策工具，不是结论来源：方法给出判断的结构与提问顺序，证据和数据决定答案。《俞军产品方法论》的理性决策三要素（信念 > 目标 > 行动）提醒我们：目标错了，跑得越快错得越多——先确认"用什么证据判断对错"，再套框架。
• 模型、框架与真实需求之间，至少隔着三类验证：定性证据（访谈与可用性测试）、定量行为证据（线上指标与评测集）、业务结果证据（商业指标与单位经济）——三者可以互相推翻，任何单一证据都不构成"需求成立"的结论。举例：访谈里用户都说"想要 X"，线上数据却显示 X 入口几乎没人用——数据会推翻访谈结论，先查行为，再决定做不做。
• 组织执行、团队信任、工程能力与时机，往往比选哪个框架更重要：同样的方法，在不同团队、不同时机下结果天差地别（《启示录》强调赋权团队，《精益创业》强调执行速度）。本专题所有页面都应和能力模型接上关系：产品方法论只是五维之一，"数据与评测"是它的延伸，"商业与成本"约束它的技术选型——方法不是用来背的，是用来对照自己缺哪一维的。

方法的适用条件：方法论需要"问题可被定义、用户可被接触、结果可被验证"三个前提。当三者都说不清（全新品类的最早期探索），先做原型实验、直接接触用户，比先套完整框架更有效——框架此时给出的是提问清单，而不是执行计划。

来源说明

发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用