补遗 · 产品方法论（11 题）

AI 产品年度规划


图怎么读：如何制定一款 AI 产品（人工智能产品）的年度规划与季度 Roadmap（路线图：产品开发计划表）？年度规划：定北极星（核心目标：一句话说清产品为谁解决什么问题）→拆三条线：①用户价值线（功能迭代：用户能用的新功能——看得见的部分）、②技术线（模型/数据能力升级：能力底座的进步）、③基建线（评测体系（评估模型好坏的体系）/监控（监测运行状态）/数据管道（数据搬运流程）——看不见但保命的）；三条线并排走，北极星不变。季度 Roadmap 按「验证→落地→扩展→收口」排：Q1 验证核心假设（最小功能+真实用户——先验证「用户要不要」）；Q2 做深单点（用户真的用的那 10% 功能——做深不铺广）；Q3 扩展场景（核心功能复制到更多场景）；Q4 收口沉淀（评测体系完善、成本优化——一年收个尾）。与传统不同：传统 Roadmap 的功能是确定的，AI Roadmap 的能力是不确定的——每个功能要标「依赖什么模型能力、能力不达标时的降级方案」；模型能力表（如 6 个月后长上下文成本降 90%——能力会变）本身就是 Roadmap 的一部分。

① 一句话大白话定义
这道题问的是：AI 产品的年度规划（一年做什么）和季度 Roadmap（每个季度排什么）怎么定？和传统产品（普通软件）的 Roadmap 有什么不同？
用大白话说：年度规划：定北极星（一句核心目标）+拆三条线（用户价值线：功能迭代；技术线：模型/数据能力升级；基建线：评测/监控/数据管道——三条线并排走）；季度按「验证→落地→扩展→收口」排（Q1 验证核心假设、Q2 做深单点、Q3 扩展场景、Q4 收口沉淀）。和传统不同：传统功能确定（写进计划就能做），AI 能力不确定（模型会变）——每个功能要标「依赖什么模型能力+能力不达标时怎么降级」，模型能力表本身就是 Roadmap 的一部分。

打个比方：开一家「智能餐厅」（AI 产品）的年度计划——北极星：「让客人 30 分钟吃上热乎饭」；三条线：①用户价值线（菜单迭代：这季度加什么菜——客人看得见）；②技术线（后厨能力升级：换更好的炉子、招更好的厨师——能力底座）；③基建线（记账系统、食材管道、卫生监控——看不见但保命）；季度节奏：Q1 先试「招牌菜」（验证核心假设：客人要不要——最小功能+真实客人）；Q2 把「客人真点的那个菜」做深（做深单点）；Q3 把招牌菜复制到更多场景（加下午茶、加外卖——扩展场景）；Q4 收尾（把记账和卫生体系完善、食材成本优化——收口沉淀）。与传统餐厅不同：智能餐厅的能力（机器人厨师）会变（明年机器人更强）——每个菜标「依赖什么厨艺+厨艺不行时的做法（人工炒——降级方案）」，厨艺能力表（明年机器人成本降一半）本身就是菜单计划的一部分。

30 秒电梯版：「年度规划三步：第一，定北极星（核心目标一句话：为谁解决什么问题）；第二，拆三条线——用户价值线（功能迭代：用户看得见）、技术线（模型/数据能力升级）、基建线（评测体系/监控/数据管道：看不见但保命）；第三，季度按『验证→落地→扩展→收口』排——Q1 验证核心假设（最小功能+真实用户，先验证要不要）、Q2 做深单点（用户真用的那 10% 功能）、Q3 扩展场景（核心功能复制到更多场景）、Q4 收口沉淀（评测体系完善、成本优化）。与传统 Roadmap 的不同：传统功能确定（写进计划就能做），AI 能力不确定（模型会变：新模型发布、成本变化）——所以每个功能标『依赖什么模型能力、能力不达标时的降级方案』；模型能力表（如 6 个月后长上下文成本降 90%）本身就是 Roadmap 的一部分——为『能力会变』设计，不把赌注押在某个模型不变。」

② 为什么学 / 面试为什么考
年度规划+季度 Roadmap 是产品经理的「宏观能力」题，面试考它的原因有三：
第一，它考「全局视野」。年度规划不是「列功能清单」，是「定方向+排资源」（北极星、三条线、季度节奏）——面试官想看你有没有「全局视野」（一年怎么走、资源怎么配——不是只盯眼前功能）——这是产品经理和「执行者」的分水岭。
第二，它考「节奏感」。季度按「验证→落地→扩展→收口」排——面试官想看你懂不懂「产品节奏」（什么时候验证（Q1）、什么时候深耕（Q2）、什么时候铺开（Q3）、什么时候沉淀（Q4）——节奏对了，一年顺；节奏乱了，一年乱）。
第三，它考「AI 特有认知」。AI Roadmap 和传统的差别（功能确定 对比 能力不确定——模型能力表进 Roadmap）——面试官想看你懂不懂「AI 规划的独特之处」（为能力会变设计——这是 AI 产品经理和传统产品经理的核心差别）。
一句话：这道题考的是「全局视野」＋「节奏感」＋「AI 特有认知」。

③ 原理拆解：年度三步→季度四段→传统对比→收口

第一步：年度——定北极星。年度规划的第一步：定北极星（核心目标）——一句话说清「产品为谁解决什么问题」（不是「做十个功能」，是「为谁解决什么问题」：为求职者解决「简历写不好」问题、为骑手解决「路线绕远」问题）——北极星的标准：①一句话（说得清：30 秒能讲明白）；②业务目标（不是技术目标：不是「上线 10 个 AI 功能」，是「让 10 万求职者写出满意简历」——业务语言）；③一年不变（北极星不能天天换——今天为求职者、明天为 HR——方向就乱了）——北极星定了，全年动作都有了「方向」（所有规划围绕它排）。
打个比方：开餐厅的北极星——「让客人 30 分钟吃上热乎饭」（一句话+业务目标+一年不变）——北极星一定，全年动作有方向：加菜（围绕「吃得快」）、换厨师（围绕「热乎」）、优化流程（围绕「30 分钟」）——如果北极星天天换（今天「吃快」明天「吃贵」后天「吃浪漫」）——厨师懵、菜单乱、客人走（没有方向的餐厅，啥都做不好）。北极星是规划的「锚」（锚定全年不漂）。
翻车案例：有团队年度规划没有北极星（或北极星是技术目标）——「今年要上线 10 个 AI 功能」（技术目标：上线功能数）——做了 10 个功能，半年后发现：功能多但没人用（10 个功能没解决「用户的什么问题」——功能是技术清单不是业务目标）——「没有北极星」翻车：年度规划第一步是「定北极星」（业务目标一句话），不是「列功能清单」（技术目标）——方向（为谁解决什么问题）先定，功能（怎么解决）才排得上。

第二步：年度——拆三条线（用户价值线/技术线/基建线）。北极星定了，拆三条线（三条线并排走，不是只做一条）：①用户价值线——功能迭代（用户能用的新功能：这季度上线什么——看得见的部分：用户感受的产品）；②技术线——模型/数据能力升级（能力底座：换更强的模型、数据更干净——用户看不见但功能变强了）；③基建线——评测体系（评估模型好坏的体系）/监控（监测运行状态）/数据管道（数据搬运流程）（看不见但保命：没有评测不知道功能好坏、没有监控坏了不知道、没有数据管道数据枯竭——基建是「不翻车的保障」）。三条线为什么都要：只做用户线（加功能）——技术跟不上一堆坏功能；只做技术线（升级模型）——用户感受不到白升；只做基建线——团队没输出（都是内部建设）——三条线并排，产品才健康。
打个比方：餐厅三条线：①菜单线（加菜——客人看得见）；②后厨线（换炉子、培训厨师——能力底座）；③账管线（记账、食材管道、卫生检查——看不见但保命）。只加菜（只做用户线）——后厨跟不上（菜好出餐慢——翻车）；只换炉子（只做技术线）——客人感受不到（菜还是那几道——白换）；只建账管（只做基建线）——餐厅没新菜（客人腻了——没输出）。三条线并排走（加菜+换炉子+建账管），餐厅才健康。
翻车案例：有团队只做用户价值线（功能迭代拉满）——一年上线 20 个功能——但评测体系（基建线）是零（没有评估标准：功能好不好不知道）、数据管道（基建线）靠人肉（数据枯竭：模型越用越差）——Q4 发现：20 个功能有 8 个「不知道好不好」（没评测）、模型越来越差（数据枯竭）——「只做一条线」翻车：三条线缺一不可（用户线有产出、技术线有底气、基建线保命）——只做用户线=功能多但产品烂（一堆没评测的功能+越来越差的模型）。

第三步：季度——验证→落地→扩展→收口。年度定了，季度按「验证→落地→扩展→收口」四段排：Q1 验证核心假设（最小功能+真实用户——先验证「用户要不要」：用最小功能（MVP（最小可行产品））给真实用户用，看数据（用了没、满意没）——验证核心假设（需求真假）；Q2 做深单点（用户真的用的那 10% 功能——做深不铺广：Q1 数据发现用户最常用的是某个功能（10% 的功能 90% 的使用）——Q2 把它做深（功能深、体验好、数据好）；Q3 扩展场景（核心功能复制到更多场景——一个场景跑通了，复制到相邻场景（同功能的更多用途））；Q4 收口沉淀（评测体系完善、成本优化——一年收个尾：把这一年攒的债（技术欠账）还一点、评测（评估测试）完善、成本优化（模型调用费降下来））。
打个比方：餐厅一年节奏（验证→落地→扩展→收口）：Q1 验证（试菜：推 3 道新菜试卖，看哪道客人点得多——验证核心假设（哪道菜有人要））；Q2 做深（Q1 数据发现「酸菜鱼」点得最多（10% 的菜 90% 的销量）——Q2 把酸菜鱼做深（加鱼片、加辣度选择、做好吃的口碑）；Q3 扩展（酸菜鱼跑通了——复制到更多场景（酸菜鱼套餐、酸菜鱼外卖、酸菜鱼火锅——扩展场景）；Q4 收口（把后厨流程优化、食材成本降下来——收口沉淀）。四段节奏：先验证（试）、再深（做透）、后扩（铺开）、末收（沉淀）。
翻车案例：有团队季度排反了（先扩展后验证）——Q1 就铺 20 个场景（扩展先行）——没有验证（不知道哪个场景有人要）——20 个场景全是「猜的」，数据全差——Q2 想回头做深，发现「没有验证过的点」（没有「用户真用的功能」——因为从没验证过）——「节奏反了」翻车：先验证（Q1 最小功能+真实用户）→做深（Q2）→扩展（Q3）——顺序反了（先铺开）——没有验证的扩展=20 个没人要的场景（白干一年）。

第四步：与传统不同——功能确定 对比 能力不确定。AI Roadmap 与传统 Roadmap 的最大不同：传统 Roadmap 的功能是「确定」的（写进计划的功能一定能做出来——登录就是登录、支付就是支付——技术确定，计划=承诺）；AI Roadmap 的功能是「不确定」的（效果取决于模型能力——模型强（90 分）功能就好、模型弱（60 分）功能就差——而模型能力会变（下季度可能发布新模型、成本可能降一半）——所以 AI Roadmap 每个功能要标三样：依赖什么模型能力（这个功能靠模型什么本事：长文本理解？图像识别？）、能力不达标时的降级方案（模型不行时产品怎么办：降级到简单版/人工/推迟）、能力升级时的升级路径（模型变强时怎么接入：接口（对接通道）预留了吗）——每个功能都标「能力依赖+降级+升级」，Roadmap 才不是「赌某个模型不变」。
打个比方：餐厅菜单（传统 对比 AI）——传统餐厅菜单：菜是确定的（酸菜鱼就是酸菜鱼——原料确定、做法确定——菜单=承诺（写了就有））；智能餐厅菜单（AI）：菜的效果取决于「机器人厨师」（模型）——机器人会升级（明年更强）——所以菜单上每个菜标三样：「依赖什么厨艺」（机器人切菜？炒菜？）、「厨艺不行时怎么办」（降级：人工炒——降级方案）、「厨艺升级时怎么办」（升级：接口预留——升级路径）——AI Roadmap 同理：每个功能标「能力依赖+降级+升级」，不赌某个模型不变。
翻车案例：有团队 AI Roadmap 按传统写法（只写功能）——「Q2 上线 AI 长文摘要」——没写「依赖什么能力、降级方案」——Q2 到了：模型的「长文理解」能力不足（摘要像复述）——产品硬上线（功能写了就得做——承诺）——效果差、用户差评——「传统写法」翻车：AI Roadmap 每个功能要标「能力依赖+降级方案」（能力不达标怎么降级）——只写功能（传统写法）=上线时发现能力不够（硬上=差评，不上=失信）——标好依赖和降级，能力不达标时「按预案降级」（不硬上也不失信）。

第五步：收口——模型能力表是 Roadmap 的一部分。AI Roadmap 的收口一个特殊点：模型能力表（模型能力会怎么变：6 个月后长上下文成本降 90%、新模型支持多模态、开源模型追上闭源——能力预测表）本身就是 Roadmap 的一部分（不是附加文档）：因为 AI 功能的排期（什么时候做什么）取决于「能力什么时候到位」（长文本功能排 Q3——因为预测 Q3 长文本成本降 90%（现在做太贵）——能力表决定功能排期）；能力表有依据（厂商发布计划、论文趋势、行业报告——不是拍脑袋）——能力表和功能表并排（左边功能、右边能力——对着看），Roadmap 才完整。
打个比方：餐厅的「食材行情表」（模型能力表）——智能餐厅的菜单计划不是只排菜（功能表），还排「食材行情表」（明年鱼价降 30%、新食材上市——行情预测表）——排菜跟着行情走（酸菜鱼排 Q3——因为预测 Q3 鱼价降 30%（现在做太贵））——行情表有依据（市场报告——不是拍脑袋）——菜单计划和行情表并排（左边菜、右边价——对着看），计划才完整。AI Roadmap 同理：功能表+能力表并排——能力决定排期，Roadmap 才完整。
翻车案例：有团队 Roadmap 只有功能表（没有能力表）——「Q1 做 AI 视频剪辑」——没看能力预测（视频模型当时能力不足）——Q1 做出来效果差（视频理解能力没到位）——白干一季度；另一队「Q3 做 AI 视频剪辑」（看了能力表：Q3 视频模型成熟——排到 Q3）——Q3 效果达标（能力到位）——「没有能力表」翻车：AI 功能的排期取决于「能力什么时候到位」（能力表是排期依据）——只有功能表（不看能力预测）=在能力没到位时做（效果差白干）——能力表进 Roadmap，排期才不瞎排。
小结：年度（定北极星→拆三条线）→季度（验证→落地→扩展→收口）→传统对比（功能确定 对比 能力不确定）→收口（能力依赖+降级写进版本、能力表是 Roadmap 一部分）。

④ 对比表格：AI Roadmap 对比 传统 Roadmap
| 维度 | 传统 Roadmap | AI Roadmap | |------|------|------| | 功能性质 | 确定（写进计划就能做） | 不确定（效果看模型能力） | | 排期依据 | 资源（人力排期） | 资源+能力表（能力到位时间） | | 功能要素 | 功能+时间 | 功能+时间+能力依赖+降级方案 | | 年度结构 | 北极星+功能清单 | 北极星+三条线（用户/技术/基建） | | 季度节奏 | 按版本迭代 | 验证→落地→扩展→收口 | | 附加文档 | 无（功能表就是全部） | 模型能力表（能力预测是规划的一部分） | | 变化应对 | 一年锁死 | 定期重评（季度看能力调整） | | 比喻 | 传统菜单（菜确定） | 智能餐厅菜单（菜依赖机器人厨师） |

⑤ 3+个例子：年度规划+季度 Roadmap 实战
例子1：AI 简历助手年度规划。北极星：「让 10 万求职者写出满意简历」；三条线：用户价值线（AI 优化、模板、排版功能）、技术线（简历解析模型升级、行业词库扩展）、基建线（评测集（评估测试题）扩建、数据管道）；季度：Q1 验证（AI 优化功能 MVP（最小可行产品）给 100 个群友用——验证「愿不愿意用」）；Q2 做深（数据发现「AI 改写」用得最多——做深改写（更多写法、更懂行业））；Q3 扩展（改写复制到更多场景：英文简历、实习简历）；Q4 收口（评测体系完善、模型调用费降 30%）。
例子2：AI 客服年度规划（能力表驱动）。能力表：「Q2 开源模型支持 128K 上下文（预测）、Q3 长文本成本降 50%」——排期跟着能力走：「Q1 验证（FAQ 问答 MVP）、Q2 做深（多轮对话——依赖 128K 上下文（Q2 能力到位））、Q3 扩展（长文档问答——依赖成本降 50%（Q3 便宜了））、Q4 收口（评测体系+监控完善）」——每个功能标「能力依赖」（多轮对话依赖长上下文）+「降级方案」（上下文不够时分段处理）。
例子3：AI 绘画工具季度节奏。Q1 验证（文生图 MVP（最小可行产品）：给 50 个群友用——验证「生成+下载」核心链路）；Q2 做深（数据发现「人像风格」用得最多——做深人像（更真、更多风格））；Q3 扩展（人像复制到更多场景：头像定制、海报、商品图）；Q4 收口（评测（评估测试）完善：人像质量评测集+成本优化（生成成本降 40%））。
例子4：AI 推荐系统 Roadmap 降级标注意。功能表每个功能标「能力依赖+降级」：「Q2 个性化推荐——依赖『用户画像模型』；降级方案：画像模型不达标时降级为『热门推荐+规则推荐』（推荐不掉链子）；升级路径：模型升级后接入实时画像（接口预留）」——能力不达标有预案，不硬上不裸奔。

⑤b 补充板块：三条线怎么配资源（比例建议）
三条线都知道要做，资源怎么配（人力/预算）——比例建议：
第一，用户价值线 50%（一半资源给用户看得见的功能迭代——产品要有产出（用户线是「面子」：没新功能，用户和老板都觉得没进展））。
第二，技术线 30%（三成给模型/数据能力升级——能力底座（里子：模型强、数据干净，功能才好——技术线是「里子」：没升级，功能迟早撑不住））。
第三，基建线 20%（两成给评测/监控/数据管道——保命（底子：没评测不知道好坏、没监控坏了不知道——基建线是「底子」：没底子，早晚翻车））。
一句话：资源配比建议——用户线 50%（面子）+技术线 30%（里子）+基建线 20%（底子）——面子要产、里子要升、底子要保，比例约 5:3:2。

⑤c 补充板块：季度 Roadmap 的「一页纸模板」
季度 Roadmap 怎么写（一页纸）——四段模板：
第一，本季目标（一句话）：这个季度完成什么（如「验证 AI 改写的核心假设」——一句话说清）。
第二，三个里程碑（阶段目标）：季度拆三到四个里程碑（阶段目标）（如：第 1-4 周 MVP（最小可行产品）上线、第 5-8 周 100 群友测试、第 9-12 周数据复盘）——每两周一个可验收节点。
第三，能力依赖（标出来）：这个季度的功能依赖什么模型能力（如「改写依赖摘要模型：当前准确率 80%」——能力现状写清楚）。
第四，风险与降级（预案）：最大风险+怎么办（如「模型效果不达标：降级为规则改写+人工审核」——预案提前写）。
一句话：季度一页纸四段——目标一句话、里程碑三四个、能力依赖标出来、风险降级写预案——一页纸过完，季度清晰可见。

⑥ 常见误区（3个）
误区1：「年度规划=列功能清单（今年做什么功能）。」错！年度规划先定北极星（为谁解决什么问题）+拆三条线（用户/技术/基建）——功能清单是「用户价值线」的一部分（还有技术线、基建线——只列功能=只做一条线）。
误区2：「季度节奏=平均用力（每季度做一样多的事）。」错！季度节奏是「验证→落地→扩展→收口」（Q1 验证、Q2 做深、Q3 扩展、Q4 沉淀——每季度重点不同）——平均用力=没有节奏（每季度都「铺新功能」=一年没有验证期也没有沉淀期）。
误区3：「AI Roadmap 和传统一样（写功能+时间就行）。」错！AI Roadmap 每个功能要标「能力依赖+降级方案」+「能力表是 Roadmap 一部分」（能力会变——不标依赖不排能力，等于赌模型不变——赌输了就翻车）。

⑦ 第一人称面试回答（3年景观设计→自学转行 AI 产品）
「我 3 年景观设计，被裁后自学转行——年度规划+季度节奏，我做景观设计时就有雏形：做设计院的年度项目规划，先定『北极星』（我们院今年主打什么——「市政公园」还是「商业景观」——一句话定方向），拆三条线（①项目线（用户价值：接新项目）、②技术线（设计软件升级、团队培训）、③基建线（资质、案例库、报价体系））；季度节奏也是『验证→落地→扩展→收口』（Q1 先接小项目验证市场（验证）、Q2 把最赚钱的项目类型做深（做深）、Q3 复制到更多区域（扩展）、Q4 整理案例库和报价体系（收口））。转行学 AI 产品后，翻译成 AI 语言：年度规划——定北极星+拆三条线（用户价值线：功能迭代；技术线：模型/数据能力升级；基建线：评测体系/监控/数据管道）；季度——验证（Q1 最小功能+真实用户）→落地（Q2 做深单点）→扩展（Q3 扩展场景）→收口（Q4 评测完善+成本优化）；和传统最大的不同：AI Roadmap 的功能是不确定的（效果看模型能力）——每个功能标『能力依赖+降级方案』，模型能力表（能力会怎么变）本身就是 Roadmap 的一部分——为『能力会变』设计，不赌某个模型不变。我没有大厂规划经验，但设计院年度规划的经历证明：我懂北极星、三条线、季度节奏——传统规划我做过，AI 规划的增量我学得会。」

⑧ 小结口诀
「年度：北极星+三条线（用户/技术/基建）；季度：验证→落地→扩展→收口；AI 不同：功能标能力依赖+降级，能力表进 Roadmap——为能力会变设计，不赌模型不变。」

⑨ 三轮追问（面试官深挖）
追问1：「北极星和季度目标冲突时（季度要赚钱、北极星要体验）怎么办？」「北极星是『长期方向』，季度目标是『短期路径』——冲突时用『北极星校准』：季度目标可以偏（赚钱：拉新功能优先），但每个季度末做一次『北极星检查』（这个季度的动作是往北极星走还是绕远了——绕远就拉回（下季度补体验）；偏离就修（季度目标不是北极星本身，是通往北极星的路径——路径可以绕，方向不能丢）」——北极星是校准器，不是枷锁（短期可以灵活，长期必须对齐）。」
追问2：「能力表（模型能力预测）不准怎么办（预测的没实现）？」「能力表不是『预测』是『计划』：①表上有来源（厂商发布计划、论文、行业报告——不是拍脑袋，有依据）；②表上有缓冲（能力预测标注置信度（把握程度）：高/中/低——低置信度的功能排期后置+留备用方案（不把核心赌在低置信度上）；③定期重评（每季度重看能力表：预测变了——功能排期跟着调）——能力表是『活的计划』（有来源、有置信度、有重评），不是『死的预测』（错了就调，不硬扛）。」
追问3：「三条线都要做，但人力只够一条线，怎么排？」「看产品阶段：验证期（Q1：需求没验证）——先用户线（验证需求最优先：先做最小功能验证核心假设——技术基建可以后置）；增长期（需求已验证）——用户线+技术线并排（做深功能（用户线）+升级能力（技术线）——两条线都要）；稳定期（产品成熟）——基建线为主（评测/监控/成本优化——把攒的债（欠账）还掉）——人力不够时按阶段排（验证期用户线、增长期用户+技术、稳定期基建）——不是三条线平均分（资源跟着阶段走）。」

⑩ 进阶加分点（说出口就加分）
加分点1：用「能力依赖表」让 Roadmap 可执行。「我的 AI Roadmap 每个功能配一张能力依赖表：功能→依赖能力→当前能力水平→差距→补齐路径（功能『多轮对话』→依赖『长上下文』→当前 32K→目标 128K→路径：等开源模型升级或自研压缩）——依赖表让『为什么这季度做这个』有依据（排期=能力差距的补齐顺序）。」——「能力依赖表」说明你排期有依据（不是拍脑袋）。
加分点2：引入「降级矩阵」。「每个 AI 功能配降级矩阵：能力等级×功能行为（模型 90 分：全功能；70 分：简化版；50 分：规则兜底+人工）——能力不达标时『自动降档』（不硬上也不裸奔——每档都有预案）」——「降级矩阵」是高级词（预案体系化：不是『不行了再说』，是『每档都设计好』）。
加分点3：把年度规划和「评测预算」挂钩。「我的年度规划里基建线不是『杂项』，是带预算的：评测集扩建 X 万、监控体系搭建 X 人力、数据管道改造 X 周期——基建线有明确预算，才不会『有空再做』（保命的事要排期，不是顺带）」——「基建线带预算」说明你懂保命的事要排期（不是口头重视）。

⑪ 话术库（直接抄着说）
「年度规划：定北极星（一句核心目标）+拆三条线（用户价值/技术/基建——并排走，北极星不变）。」
「季度节奏：Q1 验证核心假设、Q2 做深单点、Q3 扩展场景、Q4 收口沉淀。」
「AI Roadmap 与传统不同：功能确定 对比 能力不确定——每个功能标『依赖什么模型能力+降级方案』。」
「模型能力表（如 6 个月后成本降 90%）本身就是 Roadmap 的一部分——排期跟着能力走。」
「资源配比建议：用户线 50%（面子）+技术线 30%（里子）+基建线 20%（底子）。」

⑫ 小白 Q&A（可能踩的坑）
Q1：北极星怎么定（有什么标准）？三标准：一句话（30 秒讲明白：为谁解决什么问题）、业务目标（不是技术目标：让 10 万求职者写出满意简历——不是上线 10 个 AI 功能）、一年不变（定了就别天天换——方向锚住）。
Q2：季度节奏四段（验证/落地/扩展/收口）必须一年走完吗？一年是「典型节奏」（四季四段）——实际可以压缩（半年走完：2 个月验证、2 个月做深、1 个月扩展、1 个月收口）——关键是「顺序不变」（先验证再扩展——顺序错了，节奏就废了）。
Q3：能力表（模型能力预测）从哪看（信息源）？四类：模型厂商发布计划（官方路线图）、开源社区动态（新模型发布）、行业报告（技术趋势预测）、自己评测（评估测试：跑一版看现有能力水平）——四个源交叉验证，能力表才有依据。

⑬ 没人告诉你的事（面试潜规则）
这道题面试官真正在听的，是「你有没有宏观思维」——大部分候选人答「今年做这些功能」（功能清单思维），你说「北极星+三条线+季度节奏」（全局规划思维）——当场拉开（面试官要的是能规划一年的人，不是列功能的人）。另一个潜规则：这道题的亮点是「能力表进 Roadmap」——80% 的候选人答「AI 和传统差不多」（写功能+时间），你多说「每个功能标能力依赖+降级、能力表是 Roadmap 的一部分」（AI 特有认知）——说明你懂 AI 规划的独特之处（为能力会变设计——这是 AI 产品经理和传统产品经理的分水岭）。还有一个：用「设计院年度规划」讲北极星和三条线，比背「用户价值线/技术线/基建线」动人十倍——你的真实经历（传统规划做过）就是最稀缺的素材——面试官会记住「这个转行者懂规划」。

⑭ 做一件事（学完就动手）
今天给你「未来一年」定一份规划（转行学习/求职/副业都行）：①定北极星（一句话：一年后我要成为什么）；②拆三条线（能力线：学什么；项目线：做什么作品；基础线：健康/作息/资金——并排走）；③季度节奏（Q1 验证：先试一个方向；Q2 做深：把最有效的做深；Q3 扩展：复制到更多场景；Q4 收口：整理成果）——一年规划落地一页纸，你就超过 90% 的「走一步看一步」的人。

⑮ 求职助手联系（面试前必做）
面试前用本卡做 3 件事：①把「北极星+三条线+季度四段」练熟（面试框架）；②准备你的「规划」案例（设计院年度规划——真实经历最动人）；③把「为能力会变设计，不赌模型不变」练熟（收口金句）。面试被问「年度规划与 Roadmap」时：先说年度（北极星+三条线）→再说季度（验证/落地/扩展/收口）→收口（AI 不同：能力依赖+能力表）——框架完整+节奏清楚+AI 增量到位，面试官立刻记住你。

⑯ 练习（自己测一遍）
1.（排序）季度 Roadmap 的正确节奏？A 验证→落地→扩展→收口；B 扩展→验证→收口→落地——答案：A。
2.（三条线）「评测体系、监控、数据管道」属于哪条线？——答案：基建线（看不见但保命）。
3.（角色）面试官问「AI Roadmap 和传统最大的不同」，你一句话回答？——参考答案：「传统功能确定（写进计划就能做），AI 能力不确定（效果看模型、能力会变）——所以 AI Roadmap 每个功能标『能力依赖+降级方案』，模型能力表本身就是 Roadmap 的一部分——为能力会变设计，不赌某个模型不变。」

AI PRD 结构变化


图怎么读：为什么传统 PRD（产品需求文档）的「用户故事/用户旅程」叙事不再适配 AI 产品（人工智能产品）？——传统 PRD 是「二元叙事」（主角两个：用户+产品——写「用户旅程」：用户点这里→产品给那里——功能确定、行为可预期——像点菜：顾客对着菜单点，点就有）；AI 产品是「三元交互」（主角三个：用户+模型+产品——用户的行为结果取决于模型输出的质量和稳定性——模型可能错、可能不稳——像点菜加了服务员和厨师：传错菜就砸了——所以 PRD 结构要变：新增四块——①模型故事：这个功能依赖什么模型能力、能力边界在哪；②失败模式：模型会怎么错（答错/答偏/不答）、错了产品怎么办（兜底（备用方案）/降级（换简单版）/人工）；③评测设计：怎么定义好坏输出（评测集（评估测试题）+阈值（及格线））；④数据需求：训练/评测数据从哪来、谁标、多久更新）。收口：传统 PRD 回答「功能做什么」，AI PRD 还要回答「模型可能做不到时产品怎么办」。

① 一句话大白话定义
这道题问的是：传统 PRD（产品需求文档）里的「用户故事/用户旅程」（围绕用户讲故事：用户怎么用、产品给什么）为什么对 AI 产品不适用了？「用户-模型-产品」三元交互（三个角色互相影响的模式）怎么改变文档结构？
用大白话说：传统 PRD 是「两个人」的故事（用户+产品：用户点这里，产品给那里——像点菜，点就有）；AI 产品是「三个人」的故事（用户+模型+产品：用户说的话→模型理解→产品展示——模型可能理解错、可能答偏——所以 AI PRD 要把「模型」也写成主角：写清楚它依赖什么能力、它会怎么错、错了怎么办、怎么算做得好。一句话：传统 PRD 回答「功能做什么」，AI PRD 还要回答「模型可能做不到时产品怎么办」。

打个比方：点菜——传统是「顾客对着菜单点」（二元：顾客—菜单——点就有，结果确定）；AI 是「顾客—服务员—厨师」（三元：顾客说「少辣」→服务员记→厨师炒——服务员记错（模型理解错）、厨师炒错（模型输出错）——菜就可能不对！）——所以 AI 点菜的「规则文档」不能只写「顾客点什么上什么」，还要写：服务员可能记错什么（模型失败模式）、记错了怎么办（重报/退菜——兜底）、怎么算菜对（少辣=一颗辣椒都不放——评测标准）。三元交互：多了一个「会出错的中间人」——文档就要多写「中间人」的故事。

30 秒电梯版：「传统 PRD 是『二元叙事』：主角是用户和产品——写用户旅程：用户点这里、产品给那里——功能确定、行为可预期（像点菜，点就有）。但 AI 产品是『三元交互』：用户、模型、产品三个角色——用户的行为结果取决于模型输出的质量和稳定性（模型可能理解错、可能答偏、可能不稳定）——所以『用户旅程』写不全了（旅程里多了模型这个会出错的变量）。AI PRD 要新增四块：第一，模型故事——这个功能依赖什么模型能力、能力边界在哪（能做什么、做不了什么）；第二，失败模式——模型会怎么错（答错、答偏、不答）、错了产品怎么办（兜底、降级、人工）；第三，评测设计——怎么定义好坏输出（评测集+阈值（及格线：准确率 90% 算好））；第四，数据需求——训练/评测数据从哪来、谁标、多久更新。收口：传统 PRD 回答『功能做什么』，AI PRD 还要回答『模型可能做不到时产品怎么办』——把模型写进文档，AI PRD 才完整。」

② 为什么学 / 面试为什么考
AI PRD 怎么写是 AI 产品经理的核心基本功，面试考它的原因有三：
第一，它考「文档思维」。PRD 是产品经理的语言（团队都看它干活）——面试官想看你懂不懂「文档怎么组织」（写什么、不写什么——传统和 AI 的差别在哪）——这是产品经理的基本功（文档结构错了，团队理解全错）。
第二，它考「AI 特有认知」。AI 产品的核心变量是「模型会出错」（传统功能不会错：按钮就是按钮；模型会理解错、会答偏）——面试官想看你懂不懂「把不确定性写进文档」（失败模式、兜底方案、评测标准——AI PRD 四件套）——这是 AI 产品经理和传统产品经理的最大差别。
第三，它考「结构化输出」。「如何改变文档结构」——考你把「三元交互」翻译成「文档的哪几块」（模型故事/失败模式/评测设计/数据需求）——结构化能力（把抽象概念变成文档章节）是产品经理的核心技能。
一句话：这道题考的是「文档思维」＋「AI 特有认知」＋「结构化输出」。

③ 原理拆解：二元→三元→四块新增→收口

第一步：先懂传统 PRD 的二元叙事。传统 PRD 的骨架是「用户故事/用户旅程」——围绕「用户」讲故事：用户是谁（角色）、用户要什么（需求）、用户怎么用（旅程：点这里→看到那个→做这个）——主角只有两个：用户（需求方）和产品（供给方）——为什么够用？因为传统功能是「确定性的」（用户点按钮→产品响应——按钮就是按钮，行为可预期；功能写进文档就能实现，实现出来就符合预期——没有「做出来的东西不按文档跑」的风险）。
打个比方：自动售货机（二元叙事）——写它的「使用文档」只要写两个角色：顾客（投币→按按钮）和机器（出货）——因为机器是确定性的（投币 3 元→按可乐→出可乐——不会「想给可乐给了雪碧」）。所以文档写「顾客旅程」就够了：顾客投币、顾客按键、顾客取货（二元：顾客—机器——行为可预期）。
翻车案例：有团队做 AI 产品还用「纯用户旅程」写 PRD：「用户输入问题→用户看到回答」——写完发现没法开发：输入什么（提示词（给模型下指令的话）规则？）、回答错了怎么办（模型会答错！）、多好算好（准确率多少？）——全部没写（因为「用户旅程」只写了「用户输入、用户看到」——中间「模型怎么处理」是空的）——「纯用户旅程」翻车：二元叙事没写「模型」这个会出错的中间环节——AI 产品按这份 PRD 开发，必翻车。

第二步：懂三元交互——用户、模型、产品三个主角。AI 产品的实际交互是「三元」：用户（输入：说的话、点的按钮）→模型（处理：理解用户输入、生成输出——会出错！）→产品（呈现：把模型输出包装给用户——错了要兜底）——用户的行为结果取决于「模型输出的质量和稳定性」（模型理解对了→用户得到好结果；模型理解错了→用户得到错结果——结果不是产品决定的，是模型决定的）——所以「用户旅程」叙事不够了：旅程里多了一个「会出错的中间人」（模型）——文档必须写它的故事。
打个比方：相亲（三元交互）——传统（二元）：你直接见对方（两个人：你—对方——行为直接）；AI（三元）：介绍人（模型）传话——你说「我 27 岁、被裁、想转行」（输入）→介绍人转达（模型处理——可能传错：把「被裁」说成「被裁了很开心」！）→对方听到（输出）——你的「相亲旅程」结果取决于介绍人传得准不准（模型输出质量）——所以「相亲计划文档」不能只写「你和对方怎么约」——要写介绍人（模型）：他会怎么传错（失败模式）、传错了怎么办（当面澄清——兜底）、怎么算传得准（评测标准）——三元交互：多了一个「会传错的介绍人」，文档就要多写介绍人。
翻车案例：有团队写 AI 客服 PRD，只有「用户旅程」：「用户问『发票怎么开』→用户看到回答」——开发时发现：模型答「发票流程」答偏了（把「开票」理解成「开箱」）——产品直接展示错误回答（没有失败模式预案）——用户投诉（答非所问）——「只写用户旅程」翻车：模型理解错（会出错）是必然的，没写「错了怎么办」，产品就只能「展示错误」——三元交互的世界，文档必须写模型（它怎么错、错了怎么办）。

第三步：AI PRD 新增四块——把模型写进文档。三元交互改变文档结构，具体加四块：
第一块「模型故事」——这个功能依赖什么模型能力（理解、生成、分类）、能力边界在哪（能做什么、做不了什么：能答 FAQ、答不了复杂推理）——写清楚，团队才知道「模型的活」和「产品的活」怎么分。
第二块「失败模式」——模型会怎么错（三类：答错（给错误答案）、答偏（给不相关答案）、不答（拒绝/超时））、错了产品怎么办（三层兜底：规则兜底（关键词匹配给预设答案）、降级（换简单模型/简单版功能）、人工（转人工客服））——写清楚，模型错了产品不裸奔。
第三块「评测设计」——怎么定义好坏输出（评测集（评估测试题库：1000 条真实问题+标准答案）、阈值（及格线：准确率 90% 算好）、通过标准（低于 90% 不上线））——写清楚，上线有标准（不是「感觉还行」）。
第四块「数据需求」——训练/评测数据从哪来（真实对话记录）、谁标（标注规则：怎么标算对）、多久更新（数据管道（数据搬运流程）：每周更新）——写清楚，数据不枯竭（模型的效果=数据的质量）。
打个比方：请人替你接电话（模型）——「使用说明书」要写四块：①他擅长什么（模型故事：能接简单咨询，复杂转述不来——能力边界）；②他可能怎么搞砸（失败模式：听错号码、记错时间）——搞砸了怎么办（兜底：重要电话转给你）；③怎么算接得好（评测设计：转述准确率 90% 算合格）；④通讯录从哪来、谁更新（数据需求：你每周更新一次）。四块写全，「替身」才敢用。AI PRD 同理：模型是「替身」，四块写全才敢上线。
翻车案例：有团队 AI PRD 只写「功能做什么」：「AI 客服自动回答用户问题」——没写评测设计——上线后「效果行不行」没有标准：产品说「感觉还行」，算法说「得看准确率」——扯皮一个月（没有阈值（及格线），就没有「达标/不达标」）——「只写功能」翻车：AI 功能没写评测（怎么算好）+失败模式（错了怎么办），上线就是裸奔（好坏没标准、出错没预案）——四块（模型故事/失败模式/评测设计/数据需求）写全，AI PRD 才完整。

第四步：收口——传统回答「功能做什么」，AI 还要回答「模型做不到时怎么办」。最后的一句话总结：传统 PRD 的核心问题（question）是「功能做什么」（用户要什么→产品给什么——功能清单+交互流程）；AI PRD 的核心问题多一个：「模型可能做不到时产品怎么办」（模型会出错是必然——不是「如果出错」，是「什么时候出错、出了怎么办」——答错答偏不答都有预案）——文档结构围绕两个问题组织：功能部分（做什么）+模型部分（模型故事/失败模式/评测设计/数据需求——模型做不好时产品怎么办）。
打个比方：传统菜谱 对比 AI 菜谱——传统菜谱回答「做什么菜」（红烧肉：怎么做——步骤确定）；AI 菜谱（请了机器人厨师）多回答一句「机器人做砸了怎么办」（火大了怎么办——关火/加水（兜底）；盐多了怎么办——加土豆吸盐（降级）；烧糊了怎么办——倒掉重做（人工））——AI 菜谱=传统菜谱+「砸了怎么办」专章。AI PRD 同理：功能做什么+模型做砸了怎么办——两个问题都回答，文档才完整。
翻车案例：有团队 AI PRD 写得很全（功能、流程、界面全有），但整份文档没写一句「模型出错」——开发完成后第一次上线，模型答错被用户截图发网上（没有失败模式预案：产品直接展示错误答案）——口碑受损（一天内）——「没写失败模式」翻车：AI 模型出错是必然（不是概率问题，是时间问题），文档没写「错了怎么办」=产品裸奔——AI PRD 必须回答「模型做不到时怎么办」。
小结：懂二元（用户+产品）→懂三元（用户+模型+产品）→四块新增（模型故事/失败模式/评测设计/数据需求）→收口（功能做什么+模型做不到时怎么办）。

④ 对比表格：传统 PRD 对比 AI PRD
| 维度 | 传统 PRD | AI PRD | |------|------|------| | 叙事 | 二元（用户+产品） | 三元（用户+模型+产品） | | 主角 | 用户（旅程） | 用户+模型（都要写） | | 功能性质 | 确定性（点就有） | 概率性（模型可能出错） | | 模型故事 | 无（不依赖模型） | 有（能力+边界） | | 失败模式 | 无（功能不会错） | 有（答错/答偏/不答+兜底） | | 评测设计 | 功能测试（能不能用） | 效果评测（评测集+阈值） | | 数据需求 | 无（数据自备） | 有（来源/标注/更新） | | 核心问题 | 功能做什么 | 功能做什么+模型做不到怎么办 | | 比喻 | 顾客—菜单（点就有） | 顾客—服务员—厨师（传错菜） |

⑤ 3+个例子：AI PRD 四块实战
例子1：AI 客服 PRD（模型故事+失败模式）。模型故事：依赖「意图识别+FAQ 问答」能力；边界：能答常见问题（退换货、发票），答不了复杂纠纷（转人工）。失败模式：答错（把「退货运费」答成「退款时间」）→兜底（关键词匹配：检测到「运费」话题给标准答案）；答偏（用户问 A 答 B）→兜底（追问确认：「您问的是退货运费吗？」）；不答（超时）→降级（提示「正在转人工」）。
例子2：AI 摘要功能 PRD（评测设计）。评测设计：评测集=200 条长文+人工标准摘要；阈值=摘要准确率 90%、关键信息保留率 95%；通过标准=低于 90% 不上线（先内部评测，达标才开放）。数据需求：数据来源=群友授权的长文样本；标注=标注规范（保留哪三类关键信息）；更新=每月补充 50 条新样本（覆盖新话题）。
例子3：AI 推荐 PRD（三元交互）。用户（看什么视频）→模型（理解偏好+生成推荐）→产品（展示推荐位）——模型可能错：偏好理解偏（把「喜欢做饭」理解成「喜欢吃饭」）→兜底（推荐位混入 20% 热门内容——错了也有兜底展示）；评测设计：点击率（评测指标）+用户反馈（「不感兴趣」按钮数据）——两条线衡量。
例子4：AI 翻译 PRD（数据需求）。模型故事：依赖「中英互译」能力；边界：专业术语（法律、医疗）翻译可能不准确。数据需求：数据来源=领域语料（法律文书样本）；标注=双人标注（两个标注员互相校验）；更新=每季度更新术语库（法律新词、行业新词）——数据不更新，翻译能力就停在过去。

⑤b 补充板块：传统 PRD 里「哪些还能用」——不是全盘推翻
AI PRD 不是把传统 PRD 全扔掉——传统的三块依然有用：
第一，「功能清单」依然有用。「用户能做什么」照写（用户输入、产品展示、设置项）——功能是骨架，不能少。
第二，「交互流程」依然有用。「用户点什么、看到什么」照写（界面、跳转、反馈）——交互是产品的壳，照写。
第三，「验收标准」要升级。传统验收（功能能不能用：按钮点了有反应）升级为「AI 验收」（效果达不达标：准确率 90%、回复率 30%——功能能用只是底线，效果达标才是目标）。
一句话：AI PRD = 传统三件（功能清单/交互流程/验收标准）升级版 + 新增四块（模型故事/失败模式/评测设计/数据需求）——不是推翻，是「加章」。

⑤c 补充板块：「模型故事」怎么写——一页纸模板
「模型故事」是 AI PRD 新增四块里最容易空的（很多人只会写「用大模型」）——一页纸模板五段：
第一，任务（模型干什么）：一句话——「把用户的问题分类成 5 类」。（定义任务）
第二，能力（模型靠什么）：依赖什么能力——「意图识别+文本分类」。（依赖能力）
第三，边界（做不了什么）：明确写「做不了」——「涉及情绪安抚的复杂对话不支持，转人工」。（能力边界——最容易漏）
第四，输入输出（喂什么吐什么）：输入格式（用户原文+对话历史）、输出格式（分类结果+置信度（模型对自己的信心程度））。（接口定义）
第五，升级路径（模型怎么演进）：后续可升级什么——「分类准确率提升、新增第 6 类」（预留演进）。
一句话：模型故事五段——任务、能力、边界、输入输出、升级路径——写全五段，团队对模型「能干什么、不能干什么」一目了然。

⑤d 补充板块：「数据需求」怎么落到文档——三张表
数据需求是四块里最容易被「一句话带过」的（很多人写「需要数据」）——落到文档要三张表：
第一，数据来源表：数据从哪来（来源列清楚——「群友真实提问记录（已授权）」/「公开语料」/「人工整理」），每类数据写「来源+用途」（这份数据喂给模型干什么——训练？评测？）——来源不明=数据不可用（版权、隐私风险）。
第二，标注规则表：数据怎么标（标注规则写清楚——「问题分类：按 5 类分」+「标注示例：『发票怎么开』→『开票流程』」），谁标（标注人/外包/模型自标），怎么验（抽检比例：抽 20% 双人复核）——规则不清=标出废数据（口径不一，模型学歪）。
第三，更新节奏表：数据多久更新（「每周更新：新问题入库」「每月重标：旧样本复核」），谁负责（数据负责人：更新是工作不是顺带），停了会怎样（「数据停更 1 个月：模型对新问题的回答能力下降」——把后果写出来，更新才有人管）——节奏不清=数据变废（越用越旧）。
一句话：数据需求三张表——来源表（哪来的）、标注表（怎么标的）、更新表（多久更）——三张表写全，数据才不是「一句带过」。

⑥ 常见误区（3个）
误区1：「AI PRD = 传统 PRD + 一句『用大模型』。」错！「用大模型」是最模糊的需求（哪个模型、什么能力、错了怎么办——全没写）——AI PRD 要写「模型故事」（任务/能力/边界/输入输出）+「失败模式」（错了怎么办）——「用大模型」四个字=没写需求。
误区2：「失败模式等开发时再说（模型错了我再想）」。错！失败模式必须「写进 PRD」（文档层面定好预案：答错/答偏/不答各有兜底）——开发时再想=上线时裸奔（模型上线就会错，预案必须提前定）。
误区3：「评测是算法的事，产品不用写。」错！评测标准（评测集+阈值）必须产品定义（业务口径：准确率 90% 是业务要求，不是算法自己定的）——产品不写评测，算法自己定阈值（大概率是「怎么好看怎么定」）——评测设计是产品的事（定义好坏是产品职责）。

⑦ 第一人称面试回答（3年景观设计→自学转行 AI 产品）
「我 3 年景观设计，被裁后自学转行——三元交互（三个角色互相影响），我做景观设计时有体会：传统设计图纸是『二元』（甲方—图纸：甲方提需求，图纸表达——图纸不会出错，照着建就行）；但实际施工是『三元』（甲方—施工方—图纸）：施工方（模型）可能理解错图纸（把『微地形』做成『大土堆』！）——所以成熟的项目不是只有图纸，还有『施工交底』（模型故事：图纸的哪些部分是硬要求）、『变更单』（失败模式：施工错了怎么改）、『验收标准』（评测设计：坡度差多少算合格）——这就是 AI PRD 的底层逻辑，我当时不知道名字，但用过。转行学 AI 产品后翻译成 PRD 语言：传统 PRD 二元叙事（用户+产品：点就有）；AI 产品三元交互（用户+模型+产品：模型会出错——像施工方会理解错图纸）；所以 AI PRD 新增四块：模型故事（能力+边界——图纸的硬要求）、失败模式（答错/答偏/不答+兜底——变更单）、评测设计（评测集+阈值——验收标准）、数据需求（来源/标注/更新——材料清单）；收口：传统 PRD 回答『功能做什么』，AI PRD 还要回答『模型可能做不到时产品怎么办』——用施工交底的经验，我懂『把会出错的环节写进文档』。」

⑧ 小结口诀
「二元变三元（用户模型产品），四块新增（模型故事/失败模式/评测设计/数据需求），两个问题（功能做什么+模型做不到时怎么办），AI PRD 才完整。」

⑨ 三轮追问（面试官深挖）
追问1：「失败模式写三种（答错/答偏/不答）够吗？」「三种是『保底分类』，我还会加两维：『频率』（每种错误多常见：答偏占 30% 就重点管）和『代价』（每种错误多严重：医疗场景答错=高风险，娱乐场景答偏=低风险）——失败模式写全：分类（三种）×频率×代价——重点管『高频+高代价』的（比如医疗答错），低风险的写个兜底就够。」
追问2：「评测集（评估测试题）谁建？产品还是算法？」「共建：产品定『业务口径』（评测集覆盖哪些真实场景——从群友真实问题里抽样：问得最多的 100 类问题），算法定『技术口径』（评测怎么跑、指标怎么算——准确率公式）——产品管『测什么』（业务），算法管『怎么测』（技术）——两边共建，评测才既准又服气。」
追问3：「模型能力边界写进 PRD，会不会限制算法发挥？」「边界不是『限制』，是『共识』：写『这个版本做不了 X』，算法知道这版的重点是 Y（聚焦）；写『下个版本做 X』，算法知道演进方向（预期）——边界写在 PRD 里=计划的一部分（这版做什么、下版做什么都清楚）——不是限制发挥，是让发挥有方向。」

⑩ 进阶加分点（说出口就加分）
加分点1：用「模型角色」画交互图。「我会在 AI PRD 里加一张『三元交互图』：用户（输入）→模型（处理）→产品（呈现），三条线都画出来（用户到产品、用户到模型、模型到产品）——文档阅读者一眼看到『模型在中间』（比文字说明直观十倍）。」——「画图」说明你不只会写文档，会表达。
加分点2：引入「兜底金字塔」。「失败模式我配一张兜底金字塔：顶层规则兜底（关键词匹配给预设答案——便宜快速）、中层降级（换简单模型/简单版——平衡）、底层人工（转人工——最贵但最稳）——从顶往下，能顶住就不用底层（成本从低到高，一层层顶）。」——「兜底金字塔」一说出口，预案就有层次了。
加分点3：把「数据需求」和「模型演进」挂钩。「数据需求不是一次性（不是上线前准备一次），是『持续管道』（上线后每周更新——用户新问题进评测集、标注、训练）——数据管道（数据搬运流程）的持续性决定模型的持续性（数据不更新，模型越用越旧）。」——「持续管道」说明你懂 AI 是「活的产品」（数据在流动，模型在演进）。

⑪ 话术库（直接抄着说）
「传统 PRD 二元叙事（用户+产品：点就有），AI 产品三元交互（用户+模型+产品：模型会出错）。」
「AI PRD 新增四块：模型故事（能力+边界）、失败模式（答错/答偏/不答+兜底）、评测设计（评测集+阈值）、数据需求（来源/标注/更新）。」
「失败模式三种：答错（给错误答案）、答偏（给不相关答案）、不答（拒绝/超时）——三层兜底：规则、降级、人工。」
「传统 PRD 回答『功能做什么』，AI PRD 还要回答『模型可能做不到时产品怎么办』。」
「模型故事五段：任务、能力、边界、输入输出、升级路径。」

⑫ 小白 Q&A（可能踩的坑）
Q1：AI PRD 是不是要懂技术才能写？不用懂算法——写「模型故事」写的是「业务需求」（这个功能要模型干什么、做不了什么——业务语言），不是技术实现（模型内部怎么算的不用写）——产品写「要什么」，算法写「怎么做」。
Q2：传统 PRD 的用户旅程还要不要写？要写——用户旅程是「壳」（用户怎么用），四块新增是「芯」（模型怎么处理）——壳+芯才完整（不写用户旅程=不知道用户怎么用；不写四块=不知道模型出错了怎么办）——两者都要。
Q3：评测阈值（及格线）定多高？看「错误代价」：医疗/法律（答错代价高）阈值定高（95%）；娱乐/资讯（答错代价低）阈值定低（80%）——阈值跟着风险走（风险越高，及格线越严），不是拍脑袋定。

⑬ 没人告诉你的事（面试潜规则）
这道题面试官真正在听的，是「你有没有见过 AI 产品出错」——说「模型答错」说得越具体（答偏、答错、不答——还知道兜底），说明你真做过（或认真想过）——背书（「用大模型」）和讲细节（「答偏了怎么办」）一耳朵就分出来。另一个潜规则：这道题的加分点是「失败模式」——80% 的候选人会答「增加评测和数据」（大部分人只想到这两个），你多说「失败模式+兜底」（模型错了怎么办）——当场拉开（「错了怎么办」是 AI PRD 区别于传统 PRD 的灵魂）。还有一个：用「施工交底」讲三元交互，比背「模型故事/失败模式」动人十倍——你的景观设计经历（施工方会理解错图纸=模型会理解错输入）就是最稀缺的素材。

⑭ 做一件事（学完就动手）
今天找一个你常用的 AI 功能（AI 客服、AI 摘要、AI 翻译都行），给它写一份「AI PRD 四块」：①模型故事（它靠什么能力、边界在哪——什么场景它做不好）；②失败模式（它最近一次答错/答偏是什么情况、产品怎么兜底的）；③评测设计（怎么算它「好用」——你心里的及格线）；④数据需求（它「变聪明」需要什么新数据）。写完你再看它——你从「用 AI 的人」变成「设计 AI 的人」了。

⑮ 求职助手联系（面试前必做）
面试前用本卡做 3 件事：①把「二元变三元+四块新增」练熟（面试框架）；②准备你的「三元」案例（景观设计施工交底——真实经历最动人）；③把「传统回答功能做什么，AI 还要回答模型做不到时怎么办」练熟（收口用）。面试被问「AI PRD 结构」时：先说差异（二元 对比 三元）→再说四块（模型故事/失败模式/评测设计/数据需求）→收口（两个问题）——差异清楚+四块完整+经历真实，面试官立刻记住你。

⑯ 练习（自己测一遍）
1.（判断）AI PRD 相比传统 PRD 新增的四大块是？A 功能清单/交互流程/验收标准/界面设计；B 模型故事/失败模式/评测设计/数据需求——答案：B（A 是传统就有）。
2.（分类）「模型答错后转人工客服」属于四块里的哪块？——答案：失败模式（兜底方案——错了怎么办）。
3.（角色）面试官问「AI PRD 的核心问题是什么」，你一句话回答？——参考答案：「两个问题：功能做什么（传统就答这个）+模型可能做不到时产品怎么办（AI 新增的）——回答全两个问题，AI PRD 才完整。」

AI 路线图是移动靶


图怎么读：AI 产品路线图（roadmap：产品开发计划表——什么时候做什么功能）与传统路线图最大的不同：传统是「打固定靶」（规划功能：Q1 做登录、Q2 做支付——确定性交付：写进路线图就能做出来——环境稳定：技术、成本一年不变——一年锁死：年初定，年底照着做）；AI 是「打移动靶」（规划「能力+降级」（能力怎么演进+能力不行时怎么降级）——概率性交付：效果好不好试了才知道——环境在变：下季度可能有大模型发布、成本可能降一半——定期重评：每季度按模型能力调整）。为移动靶设计做三件事：①按 6 个月后的模型能力设计（规划时假设能力更强、更便宜，预留升级路径）；②模型无关层（把业务逻辑和模型调用解耦（分开），换模型不动产品）；③定期重评（每个季度根据模型能力变化调整，而不是一年锁死）。收口：把路线图当「方向和验收标准」，不当「承诺清单」——功能可以变（模型能力变了就换方案），北极星（产品的核心目标，指引方向的那个数）和评测标准（评估好坏的测试标准）不变。

① 一句话大白话定义
这道题问的是：AI 产品（人工智能产品）的路线图（开发计划表）和传统产品（普通软件）的路线图，最大区别是什么？
用大白话说：传统路线图规划「功能」（Q1 做登录、Q2 做支付——写进计划就能做出来），AI 路线图规划「能力+降级」（模型能力会变——下季度可能出新模型、成本可能降一半——计划要按 6 个月后的能力设计，还要想清楚「能力不行时怎么办」）。传统是一年锁死（年初定，年底照着做），AI 要定期重评（每季度按模型能力调整）。一句话：传统打固定靶（靶子不动），AI 打移动靶（靶子在动）——瞄准的方向要对，还要跟着靶子动。

打个比方：装修（传统路线图）vs 装修遇上「材料市场天天变」（AI 路线图）——传统装修：年初定方案（用什么砖、什么柜子），照着施工，年底验收——方案确定，不会变（固定靶）；AI 装修：年初定方案，但半年后「智能瓷砖」（新模型）出来了、材料降价一半（模型能力变了）——方案要重做（用新技术、省一半钱）——所以 AI 装修不能「方案锁死一年」，要「按半年后的材料行情设计+材料变了能换方案+每季度重新看行情」（移动靶：方案跟着市场动）。

30 秒电梯版：「最大的不同：传统路线图规划『功能』，AI 路线图规划『能力+降级』——因为 AI 的环境是移动的：模型能力在变（下个季度可能有大模型发布、成本可能降一半、能力可能上一个台阶），所以传统『写进路线图就能做出来』（确定性交付）变成『效果好不好试了才知道』（概率性交付）。三件事为移动靶设计：第一，按 6 个月后的模型能力设计——规划时假设能力更强、更便宜（预留升级路径：今天先做基础版，升级点留好）；第二，模型无关层——把业务逻辑和模型调用解耦（分开），换模型不动产品（模型升级、换供应商，产品逻辑不用改）；第三，定期重评——每个季度根据模型能力变化调整路线图（不是一年锁死）。收口：把路线图当『方向和验收标准』，不当『承诺清单』——功能可以变（模型能力变了就换方案），北极星（核心目标）和评测标准（验收尺子）不变——方向定住，路径可改。」

② 为什么学 / 面试为什么考
路线图是产品经理的「方向盘」，面试考它的原因有三：
第一，它考「规划思维」。产品经理的核心工作之一是「排计划」（什么先做、什么后做、为什么）——面试官想看你懂不懂「路线图怎么排」——这是产品经理的基本功（排错了，团队白干半年）。
第二，它考「AI 特有认知」。AI 产品的路线图难在「模型能力不可控」（今天做不到的事，明天模型升级可能就做到了；今天做到的事，新模型可能让旧方案作废）——面试官想看你懂不懂「AI 规划的不确定性管理」（按 6 个月后设计、模型无关层、定期重评——AI 路线图三件套）。
第三，它考「定力」。AI 变化快，容易「天天改方向」（今天跟风这个、明天追那个）——面试官想看你有没有「定力」（方向（北极星）定住，路径可改——不是天天换方向）——这是 AI 产品经理和「跟风的人」的分水岭。
一句话：这道题考的是「规划思维」＋「AI 特有认知」＋「定力」。

③ 原理拆解：固定靶 对比 移动靶→三件事→收口

第一步：先懂传统路线图——打固定靶。传统产品（软件）的路线图逻辑：规划「功能」——Q1 做登录、Q2 做支付、Q3 做会员（功能清单+时间排期）；确定性交付——「写进路线图的功能一定能做出来」（技术是确定的：登录就是登录，不会做着做着变成别的）；环境稳定——技术、成本一年内基本不变（开发框架、服务器价格不会半年变一次）；一年锁死——年初定好，年底照着做（按计划走，偏差小）。
打个比方：做菜（传统路线图）——定了菜单（四菜一汤：红烧肉、清蒸鱼、炒时蔬、蛋花汤），菜谱确定（怎么做写得清清楚楚）、食材确定（猪肉就是猪肉）、时间确定（2 小时上齐）——照着菜谱做，肯定能出菜（确定性交付）。传统产品路线图同理：功能确定、技术确定、时间确定——「写进计划=做得出来」。
翻车案例：有团队把传统路线图思维直接搬到 AI 产品：「Q2 上线 AI 客服，准确率 90%」——写进路线图就以为能做出来（确定性思维）——结果 Q2 到了：模型准确率只有 60%（技术没到位）——「写进计划=一定做出来」翻车：AI 效果是「试了才知道」，不是「计划了就能有」（传统思维的确定性假设，在 AI 世界不成立）。

第二步：懂 AI 路线图——打移动靶。AI 产品的路线图逻辑变了：规划「能力+降级」——不只规划「功能」（做什么），还要规划「能力」（模型能力演进：这季度能用什么模型、什么效果）和「降级」（能力不行时怎么办：模型效果差就降级到人工/简单版）；概率性交付——「写进路线图的功能」效果好不好要试了才知道（准确率 60% 还是 90%，评测（评估测试）了才知道）；环境在变——模型能力在变（下季度可能有大模型发布、能力上一个台阶）、成本在变（调用成本可能降一半）、供应商在变（新模型公司冒出来）；所以「一年锁死」不成立——要定期重评（每季度按模型能力变化调整路线图）。
打个比方：打猎（AI 路线图）——目标是移动的（兔子在跑：模型能力天天在变）：你不能「瞄准兔子原来的位置扣扳机」（按年初的能力规划——打空了），要「瞄准兔子现在的位置+预判它往哪跑」（按 6 个月后的能力设计——打移动靶要预判）。兔子跑得快了（新模型发布）——你也要跟着调整瞄准（定期重评）——打移动靶和打固定靶的差别：目标在动，你的瞄准也要动。
翻车案例：有团队按年初能力规划 AI 路线图：「Q3 用模型 A 做摘要」——Q3 到了，模型 B 发布了（能力更强、成本更低）——按计划用 A（照着年初做）——效果差、成本高、竞品都用 B 了——「照着年初规划执行」翻车：移动靶世界，年初的瞄准已经过时（能力变了，路径不变=被时代抛下）。要定期重评（每季度看模型能力，调整路线图）。

第三步：按 6 个月后的模型能力设计。第一件事：规划时「假设 6 个月后的模型能力」（更强、更便宜、更稳），按那个能力设计——为什么是 6 个月？因为 AI 能力迭代快（半年后模型通常明显更强），而产品开发周期也是半年左右（今天设计、半年后上线——按上线时的能力设计，不按今天的能力设计）；同时「预留升级路径」（今天做基础版时就把升级点留好：数据接口（数据对接的通道）按标准设计、评测集（评估测试题库）先建好——6 个月后能力升级，产品直接接入，不用重做）。
打个比方：买插座（预留升级路径）——装修时多留几个插座口（现在用不上，但留好了）——半年后买了新家电（模型升级），插上就能用（不用重新走线）。AI 设计同理：今天做基础版（先用今天的模型），但接口（对接通道）、评测、数据结构都按「6 个月后的标准」设计（升级点留好）——半年后新模型上线，直接接入（不用推翻重做）。
翻车案例：有团队按「今天的能力」设计：「先用模型 A 写个简单摘要（今天就够用）」——半年后模型 B 能力翻倍（能理解长文、能总结图表），但产品数据结构是按 A 设计的（接口不兼容）——接入 B 要重做数据层（两个月）——「按今天设计」翻车：没留升级路径，能力升级时「接不上」（升级点没留，升级就重做）。按 6 个月后设计+预留升级路径——升级是「插上就能用」，不是「推翻重来」。

第四步：模型无关层——换模型不动产品。第二件事：把「业务逻辑」和「模型调用」解耦（分开）——中间加一层「模型无关层」（一层隔离：产品逻辑不直接碰模型，通过这层调用）——好处：换模型不动产品（今天用模型 A，明天换模型 B——只换「模型无关层」里的调用配置，产品功能逻辑一点不用改——像换电池：换电池不用改手机）；模型升级不慌（新模型发布，评测（测试）一下，好就换——产品不用动）。
打个比方：手机换电池——手机（产品逻辑）和电池（模型）是分开的（换电池不用重造手机）——如果手机和电池焊死（业务逻辑和模型直接耦合），换电池=换手机（换模型=重做产品）。模型无关层就是「电池仓」（标准接口：电池规格统一，什么电池都能装）——模型无关层就是「模型仓」：模型规格统一（调用标准一样），什么模型都能换——换模型，手机（产品）不动。
翻车案例：有团队做 AI 客服时把模型调用直接写死在业务代码里（提示词（给模型下指令的话）写死、模型名字写死、返回格式写死）——模型 A 升级后效果变差，想换模型 B——发现要改 20 处业务代码（模型调用散落在各处）——换模型=重写产品（一个月）——「模型写死」翻车：模型升级/换供应商，产品跟着遭殃。模型无关层（一层隔离）：模型怎么换，产品逻辑不动。

第五步：定期重评——每季度根据模型能力调整。第三件事：路线图「定期重评」（不是一年锁死）——每季度做一次「重评会」：看模型能力变化（有没有新模型发布、现有模型有没有升级、成本有没有变化）、看评测结果（现在的方案效果如何）、看竞品动向——然后调整路线图（哪个功能提前、哪个推迟、哪个换方案）——方向（北极星）不变，路径（具体功能和时间）可以改。
打个比方：导航——出发去北京（北极星：方向不变），导航软件会「定期重评」：前方堵车（模型能力变了）就换路线（调整路径）——不会「年初规划一条路，堵死也走」（一年锁死）；也不会「换路线=换目的地」（功能可以变，方向不变）。定期重评同理：每季度看「路况」（模型能力），调整「路线」（路线图），目的地（北极星）不变。
翻车案例：有团队年初定路线图后一年不看（一年锁死）——Q3 时行业出了重大变化（新模型发布，能力翻倍），竞品全换了——他们还按年初计划做旧方案（年底上线就过时了）——「一年锁死」翻车：AI 世界三个月就是一个时代（模型迭代快），一年不看=一年后你的产品用旧技术打新市场。定期重评（每季度看能力、调路线）——方向定住，路径跟着时代走。

第六步：收口——路线图是「方向和验收标准」，不是「承诺清单」。最后的心态：把路线图当「方向和验收标准」——方向（北极星：产品的核心目标，如「让每个群友都能一键生成简历」）和验收标准（评测标准：怎么算做好——准确率 90%、回复率 30%）不变——功能、方案、时间都可以变（模型能力变了就换方案——变的是路径，不是方向）——不当「承诺清单」（承诺 Q2 一定上线 X 功能——做不到就失信）——AI 路线图对功能是「弹性承诺」（方向定，路径活）。
打个比方：旅行（方向和验收标准）——目的地：去海边（方向：北极星——不变）；验收标准：看到海+拍到照片（验收标准——不变）；但行程可以改（坐飞机还是高铁、先去哪站——模型能力变了就换路径——变的是方案，不是目标）。如果当「承诺清单」（承诺第 3 天一定到 X 景点——天气变了也硬去）——做不到就失信（对团队、对老板）。路线图：方向+验收标准定住，路径灵活。
翻车案例：有团队把 AI 路线图当「承诺清单」：「Q2 承诺上线 AI 摘要，准确率 92%」——Q2 到了准确率只有 78%（模型能力没到）——团队硬上（承诺不能破）——上线后用户体验差、口碑崩——「承诺清单」翻车：AI 效果不是承诺出来的（模型能力没到就是没到）——硬上承诺=用差效果换失信。当「方向和验收标准」：准确率没到就「推迟上线+说明原因+更新路线图」（弹性承诺）——不硬上，不失信。
小结：懂差异（固定靶 对比 移动靶）→按 6 个月后设计（预留升级路径）→模型无关层（换模型不动产品）→定期重评（季度调整）→收口（方向+验收标准定住，路径可改）。

④ 对比表格：传统路线图 对比 AI 路线图
| 维度 | 传统路线图 | AI 路线图 | |------|------|------| | 规划对象 | 功能（登录、支付） | 能力+降级（能力演进+不行怎么办） | | 交付性质 | 确定性（写进计划就能做） | 概率性（效果试了才知道） | | 环境 | 稳定（技术成本一年不变） | 在变（新模型、成本降、供应商多） | | 时间跨度 | 一年锁死 | 定期重评（每季度调整） | | 设计基准 | 按今天的能力 | 按 6 个月后的能力（留升级路径） | | 模型依赖 | 无（逻辑和实现一体） | 模型无关层（换模型不动产品） | | 承诺方式 | 承诺清单（Q2 上线 X） | 方向和验收标准（功能可换） | | 比喻 | 打固定靶/做菜照菜谱 | 打移动靶/导航动态换路 |

⑤ 3+个例子：AI 路线图实战
例子1：AI 客服路线图（按 6 个月后设计）。今天模型只能答简单问题（FAQ 问答）——规划时不只写「Q1 做 FAQ 客服」，写「按 6 个月后设计：Q3 时模型能理解长文上下文（今天留好：数据结构按长文设计、评测集先建）——Q3 模型升级，客服直接接入长文理解（不用重做数据层）」——预留升级路径（数据接口、评测先建好），升级是「插上就能用」。
例子2：AI 摘要功能（模型无关层）。做 AI 摘要时把模型调用封装成「摘要服务层」（模型无关层：产品只调「摘要服务」接口，不直接碰模型）——今天用模型 A（成本低），Q3 模型 B 发布（效果更好）——评测一下，B 好就换——只改「摘要服务层」里的配置（换成 B 的调用），产品功能逻辑（摘要的展示、交互）一点不用改——换电池，不换手机。
例子3：AI 推荐路线图（定期重评）。年初定：「Q1 规则推荐、Q2 模型推荐、Q4 个性化推荐」——Q2 重评会：发现新发布的大模型推荐效果评测远好于自家模型（能力变了）——调整：Q2 直接接大模型（提前）、Q4 目标改为「结合用户行为微调」（改路径）——方向（推荐更准）不变，路径（用什么模型、什么节奏）跟着能力调整。
例子4：AI 翻译功能（方向+验收标准）。路线图第一行写「方向：让群友一句中文翻译成 20 种语言；验收标准：翻译准确率 90%、支持领域词库」——功能和时间可以变（今天先支持 5 种语言，Q3 模型升级再加 15 种；今天先做文档翻译，Q4 加语音翻译）——但方向和验收标准不变（准确率 90% 是死线）——路线图是「方向和验收标准」，不是「承诺 Q3 一定支持 20 种」。

⑤b 补充板块：AI 路线图的一页纸模板（怎么写）
AI 路线图怎么写？一页纸五块：
第一，北极星（方向）：一句话核心目标（「让群友一句话生成可用简历」）——定方向（不变）。
第二，评测标准（验收尺子）：怎么算做好（准确率 90%、回复率 30%、人工复核比例 <10%）——定验收（不变）。
第三，能力假设（6 个月后）：我们假设 6 个月后模型能力如何（更强、更便宜、支持多模态）——按它设计（留升级路径）。
第四，功能队列（路径）：按季度排的功能清单（Q1 基础版、Q2 升级版、Q3 多语言）——路径（可以调）。
第五，降级方案（不行怎么办）：每个功能写「能力不达标时怎么办」（降级到人工/简单版/推迟）——预案（不能没有）。
一句话：一页纸五块——北极星（方向）、评测标准（验收）、能力假设（6 个月后）、功能队列（路径）、降级方案（预案）——前两块定住，后三块可调。

⑤c 补充板块：路线图「重评会」怎么开（三问）
每季度重评会，就开三问：
第一，「模型能力变了没有？」——扫一遍：有没有新模型发布、现有模型升级没、成本变没变（能力变了，路径可能要换）。
第二，「现在做的还符合方向吗？」——回看北极星：这个季度做的事是往方向走吗（功能可以调，方向不能漂——漂了就拉回来）。
第三，「有什么该止损的？」——看降级方案：有没有「做了一半发现效果不行」的功能（该砍就砍，该换就换——止损比硬撑体面）。
一句话：重评会三问——能力变没变（换路径）、方向偏没偏（拉回）、该不该止损（砍掉）——三问过完，路线图更新一版。

⑥ 常见误区（3个）
误区1：「AI 路线图不用做（变化太快，做了也白做）。」错！变化快更要「方向+验收标准」定住（没有北极星，团队天天漂）——路线图不是「锁死计划」，是「方向+路径」——方向定住，路径跟着能力调（不做路线图=团队各走各的）。
误区2：「路线图要写得细（每个功能的时间精确到周）。」错！AI 路线图功能层「写粗」（方向、验收标准、能力假设清楚就行），路径层「弹性」（功能和时间可以调）——写太细=天天改（模型能力一变，细计划全作废——越细越脆）。
误区3：「模型能力变了才重评，没变就不管。」错！定期重评是「定期」（每季度一次，不管变没变）——因为「变化」不是只有模型（还有竞品、成本、政策）——而且「没变」本身也是信息（说明方案还有效——确认了也是价值）。定期做，才不慌。

⑦ 第一人称面试回答（3年景观设计→自学转行 AI 产品）
「我 3 年景观设计，被裁后自学转行——移动靶（目标会动的规划），我做景观设计时就有体会：景观方案（传统）是一套固定图纸（定了就照着建）；但我遇到过「材料行情变了」——半年后苗木价格涨了一半（类似模型能力变化），按原方案做预算超支——我们当时的做法：方案里「弹性设计」（核心效果（北极星：这个园子的气质）不变，材料配置留替换空间（升级路径：贵的苗木可以换便宜的同类）），定期重看行情（每季度重评：价格变了就调配置）——这就是 AI 路线图的逻辑，我当时不知道名字，但用过。转行学 AI 产品后，把「弹性设计」翻译成 AI 路线图语言：传统路线图规划功能（确定交付），AI 路线图规划『能力+降级』（概率交付）；三件事：按 6 个月后的模型能力设计（预留升级路径——像留替换苗木的坑）、模型无关层（换模型不动产品——像换材料不动景观效果）、定期重评（每季度调整——像每季度看苗木行情）；收口：路线图是『方向和验收标准』不是『承诺清单』——核心效果（北极星）不变，材料（路径）可换。我没有大厂规划经验，但我用『苗木行情的弹性设计』证明了：我懂移动靶，不是只会打固定靶。」

⑧ 小结口诀
「传统打固定靶（功能确定交付），AI 打移动靶（能力+降级）；三件事：按 6 个月后设计（留升级路径）、模型无关层（换模型不动产品）、定期重评（季度调）；收口：方向和验收标准定住，路径可改。」

⑨ 三轮追问（面试官深挖）
追问1：「按 6 个月后的能力设计，万一没实现呢（模型没升级）？」「所以设计要『两条腿』：按 6 个月后的能力设计『升级路径』（数据结构、接口、评测先备好——升级了直接接入），同时按今天的能力做『当下交付』（今天能交付什么就交付什么——不空等升级）——两条腿：今天能跑（当下交付）、明天能升（升级路径）——模型升级了就接上（快人一步），没升级也不耽误（今天也在跑）。」
追问2：「路线图调整的频率怎么定（季度够吗）？」「季度是『固定重评』（保证最小频率），但触发条件可以更勤：三个信号出现就提前重评——①有新模型发布且能力明显更强（技术信号）；②竞品用了新方案且效果好（市场信号）；③成本变化超过 30%（成本信号）——固定季度+信号触发（固定频率兜底，信号随时升级）——比死等季度快，比天天改稳。」
追问3：「老板要你把 AI 路线图写成承诺（Q2 一定上线），怎么办？」「不硬承诺功能，但承诺『过程和验收』：『Q2 一定上线』改成『Q2 上线 AI 摘要，若准确率未达 90% 评测标准，则降级为人工+AI 协同版上线（功能降级，时间不失信）』——承诺『时间+降级预案』（时间守住，质量用降级兜）——既对老板负责（时间不漂），又对用户负责（效果不吹）。」

⑩ 进阶加分点（说出口就加分）
加分点1：把「移动靶」升级为「能力时间表」。「我会在路线图里加一张『能力时间表』：预测 6 个月/12 个月模型能力到什么程度（标注来源：厂商发布计划、论文趋势、行业报告）——路线图的路径都挂在能力时间表上（能力到哪，路径跟到哪）——不是拍脑袋调路线，是按能力预测调。」——「能力时间表」一说出口，你就是「有依据的规划者」。
加分点2：引入「降级矩阵」。「每个 AI 功能我配一张降级矩阵：功能×能力等级→行为（模型 90 分怎么表现、70 分怎么表现、50 分怎么表现——每档都有预案）——路线图里每功能都带降级矩阵，能力不达标知道自动降到哪档。」——「降级矩阵」是高级词，说明你想到了「能力不行时」的完整预案。
加分点3：把路线图和「评测预算」挂钩。「我的路线图里每个功能都配评测预算（建评测集、跑评测的时间成本）——因为 AI 功能『效果好不好要测了才知道』，评测是 AI 开发的必要成本（不是附加项）——评测预算进路线图，验收才有着落。」——「评测预算」说明你懂 AI 开发的真实成本结构。

⑪ 话术库（直接抄着说）
「传统路线图规划功能（确定交付），AI 路线图规划『能力+降级』（概率交付）——环境在变，能力会变，方案要能换。」
「三件事：按 6 个月后的能力设计（留升级路径）、模型无关层（换模型不动产品）、定期重评（季度调整）。」
「路线图是『方向和验收标准』不是『承诺清单』——功能可以变，北极星和评测标准不变。」
「降级矩阵：功能×能力等级→行为——每档都有预案，能力不达标自动降档。」
「重评会三问：能力变没变（换路径）、方向偏没偏（拉回）、该不该止损（砍掉）。」

⑫ 小白 Q&A（可能踩的坑）
Q1：模型无关层是不是要写代码（我不会）？不用——产品经理的工作是「在 PRD（产品需求文档）里定义模型无关层」：「模型调用走统一接口，产品逻辑不直接依赖具体模型，模型评估通过评测后更换」——写清楚这个「分层要求」，技术同事按你的文档实现（产品定义规则，技术实现代码）。
Q2：定期重评会不会让团队觉得「计划总变」没安全感？重评要「变的透明」：每次调整路线图都写明「为什么变」（模型 B 发布，评测更好，路径从 A 换 B）——团队怕的不是变，是「变不知道为什么」（透明变更=信任不变）。
Q3：北极星选了「准确率」，模型达不到怎么办？北极星要选「业务目标」不选「技术指标」（选「群友满意度 4.5 分」不选「准确率 92%」——技术指标会变（模型能力问题），业务目标不变（群友满意就是满意））——北极星选业务目标，路径可以技术灵活。

⑬ 没人告诉你的事（面试潜规则）
这道题面试官真正在听的，是「你有没有被『变化』吓到过」——AI 变化快，很多人「不做路线图」（怕做了白做）或「死守路线图」（怕变）——你说「方向定住、路径可改」（既做计划又不死板）——当场立住。另一个潜规则：这道题是「概念题」变体——面试官不期待你讲得多深，期待你「一句话说清差异」（传统=功能确定、AI=能力+降级）——说不清差异，细节再多也没用。还有一个：用「景观设计的苗木行情」讲移动靶，比背「模型无关层、定期重评」动人十倍——你的真实经历（材料行情变=模型能力变）就是最稀缺的面试素材——面试官会记住「这个转行者真的理解变化」。

⑭ 做一件事（学完就动手）
今天给你手头的「计划」（工作目标、学习计划、副业规划都行）做一次「AI 化改造」：①写一句「北极星」（方向：为什么做这件事——不变）；②写「验收标准」（怎么算做好）；③列「功能路径」（具体步骤——可调）；④写「降级方案」（卡住了怎么办）——然后执行一个月，过程中记录「哪些变了、北极星变没变」。做完你就懂：好计划不是「不变的计划」，是「方向不变、路径灵活的移动靶计划」。

⑮ 求职助手联系（面试前必做）
面试前用本卡做 3 件事：①把「传统=固定靶、AI=移动靶」一句话差异练熟（面试开头用）；②准备你的「弹性设计」案例（景观设计苗木行情——真实经历）；③把「方向+验收标准定住、路径可改」练熟（收口用）。面试被问「路线图差异」时：先说差异（固定靶 对比 移动靶）→再说三件事（按 6 个月后设计/模型无关层/定期重评）→收口（方向和验收标准）——差异一句话+框架三步+经历真实，面试官立刻记住你。

⑯ 练习（自己测一遍）
1.（判断）下面哪个是 AI 路线图的做法？A 年初定死全年功能清单，年底照着做；B 每季度重评，模型能力变了就调路径——答案：B（A 是传统思维，固定靶）。
2.（三件事）「换模型不用改产品逻辑」靠哪件事实现？——答案：模型无关层（业务逻辑和模型调用解耦）。
3.（角色）老板说「路线图写承诺，Q2 一定上线 AI 客服」，你怎么回应？——参考答案：「功能我不硬承诺（模型效果要试了才知道），但我承诺『时间和降级』：Q2 一定上线——若准确率未达 90%，降级为人工+AI 协同版上线——时间守住、效果用降级兜底。」

入职前 90 天规划


图怎么读：入职 AI 产品岗（人工智能产品经理岗位）的前 90 天怎么规划——分三段：第 1 个月「听懂」——读代码读文档（了解产品和技术栈（技术体系））、把现有评测体系（评估模型好坏的体系）/数据管道（数据搬运流程）搞明白、约每个关键角色（算法/数据/业务）聊一遍——产出：一张「产品现状地图」（功能、指标、技术债（技术欠账）、卡点（卡住的地方））；第 2 个月「找痛」——从数据里找最痛的单点（转化漏斗（用户一步步走到转化的环节）最差的一环、用户投诉最多的一类），和算法确认可行性——产出：一个高优先级验证方案（痛+可行=开干）；第 3 个月「落地小赢」——做一个小而完整的功能/优化（从上线到看到数据——完整闭环（做完整个流程）），建立「我能交付」的信誉，同时把评测基线（评测的基准数据）建好。雷区：前 90 天最忌讳「大动干戈」（一进来就改流程、推重构——新人没信任时放大动作=被反弹）；先证明你能做对小事（小赢），才有资格动大事——节奏：听懂（不装懂）→找痛（不空谈）→小赢（不画饼）——90 天结束，老板记得你「交付了什么」，不记得你「多聪明」。

① 一句话大白话定义
这道题问的是：入职 AI 产品岗（人工智能产品经理）的前 90 天（三个月试用期），你会怎么规划（做什么、按什么顺序）？
用大白话说：前 30 天听懂（读文档、跑数据、约人聊——画出产品现状地图），中间 30 天找痛（从数据里找最痛的一个点，和算法确认可行性），后 30 天落地小赢（做一个小而完整的功能，从上线看到数据——建立「我能交付」的信誉）。最忌讳「大动干戈」（一进来就改这改那——新人没信任，动大事=被反弹）——先证明能做对小事，才有资格动大事。

打个比方：新搬进一个家（入职）——前 30 天「听懂」：先搞清楚家里都有什么（水电在哪、柜子在哪——产品现状地图）、每样东西怎么用（数据管道、评测体系）；中间 30 天「找痛」：住下来发现「厨房最不好用」（最痛的单点——做饭最费劲的地方），研究怎么改（和算法确认可行性）；后 30 天「小赢」：先做一件小事（换个更好用的水龙头——小而完整），用起来顺手了（上线看到数据），家人（团队）信任你会干活了——再谈「改厨房格局」（动大事）。一搬进来就「把墙砸了重改」（大动干戈）——家人肯定不干（没信任，动大事=被反弹）。

30 秒电梯版：「前 90 天分三段：第 1 个月「听懂」——读代码读文档（产品和技术栈（技术体系））、把评测体系（评估好坏的体系）和数据管道（数据搬运流程）搞明白、约每个关键角色（算法/数据/业务）聊一遍——产出：产品现状地图（功能、指标、技术债（欠账）、卡点）；第 2 个月「找痛」——从数据里找最痛的单点（转化漏斗（转化环节）最差的一环、投诉最多的一类），和算法确认可行性——产出：高优先级验证方案（痛+可行=开干）；第 3 个月「落地小赢」——做一个小而完整的功能/优化（从上线到看到数据——完整闭环（做完整个流程）），建立「我能交付」的信誉，同时把评测基线（基准数据）建好。雷区：前 90 天最忌讳「大动干戈」（一进来就改流程、推重构）——新人没信任时放大动作=被反弹——先证明你能做对小事，才有资格动大事。节奏：听懂（不装懂）→找痛（不空谈）→小赢（不画饼）。90 天结束，老板记得你交付了什么，不记得你多聪明。」

② 为什么学 / 面试为什么考
「前 90 天规划」是入职类的高频面试题（考的是新人期思维），面试考它的原因有三：
第一，它考「新人期认知」。新人的最大风险是「着急证明自己」（一进来就想干大事、改大流程）——面试官想看你懂不懂「新人的正确节奏」（先听懂再动手、先小赢再放大——不急于证明，稳着来）——新人期认知决定你能不能活过试用期。
第二，它考「信任建设」。90 天的核心不是「做了多少」，是「建立多少信任」——面试官想看你懂不懂「信任的顺序」（先证明能做对小事（小赢）→才有人信你动大事（放大）——信任是挣来的，不是职位给的）。
第三，它考「AI 产品认知」。AI 产品岗的 90 天和传统不同：要搞懂评测体系（评估模型好坏的体系）和数据管道（数据搬运流程）（AI 产品的两条腿）、要建评测基线（基准数据）——面试官想看你懂不懂「AI 产品岗的技术底座」（不懂评测和数据，AI 产品经理是空壳）。
一句话：这道题考的是「新人期认知」＋「信任建设」＋「AI 产品认知」。

③ 原理拆解：三段规划→雷区→收口

第一步：第 1 个月「听懂」——不装懂，先画地图。第一个月的目标不是「产出功能」，是「听懂现状」：读代码读文档（了解产品长什么样、技术栈（技术体系）是什么——不用懂代码细节，懂「技术架构」（系统怎么搭的）和「数据流」（数据从哪来、到哪去））；把评测体系（评估模型好坏的体系：评测集（评估测试题）有哪些、怎么跑、及格线多少）和数据管道（数据搬运流程：数据从哪来、谁标、多久更新）搞明白（AI 产品两条腿——不懂评测数据，AI 产品经理是空壳）；约每个关键角色聊一遍（算法（模型怎么做、什么做不到）、数据（数据从哪来、什么脏）、业务（业务指标是什么、什么最痛））——产出：一张「产品现状地图」（功能清单、指标清单、技术债（欠账）清单、卡点清单——一张图看清现状）——「听懂」的标准：能画出地图（不是背下来，是画出来——画得出=真懂）。
打个比方：新搬家的前 30 天（听懂）——不急着改房子（不产出功能），先「逛明白」：每个房间转一遍（读文档）、水电线路看一遍（评测体系）、和每个家人聊一遍（约关键角色）——画一张「房子地图」（哪里是什么、哪里有什么问题）——住进去 30 天，能画出房子地图=听懂了（画不出=还没懂，继续逛）。搬家的第一件事不是「改」，是「逛明白」——入职同理。
翻车案例：有新人入职第一周就「输出方案」：「我发现推荐系统有问题，建议重构」——方案写得有模有样，但全是想象（没读数据、没聊算法——不知道现状：推荐系统为什么这么设计、之前改过什么、有什么技术债（欠账））——方案被算法一句话打回：「你了解过我们为什么这么设计吗？」——「没听懂就输出」翻车：新人没画地图就谈改造=纸上谈兵（不读数据不聊人，方案全是想象）——第 1 个月的任务是听懂（画地图），不是输出（改方案）。

第二步：第 2 个月「找痛」——从数据里找最痛的单点。第二个月的目标：从数据里找「最痛的单点」——不是泛泛的「产品有很多问题」，是「一个最痛的点」：转化漏斗（用户一步步走到转化的环节）最差的一环（用户在哪一步流失最多——数据说话：100 人进来 90 人卡在第 2 步——第 2 步最痛）；用户投诉最多的一类（客服记录、评价、群聊——哪类问题被反复提——数据说话：100 条投诉里 60 条是「发票问题」——发票最痛）；和算法确认可行性（最痛的点也要「做得动」：找算法聊「这个痛点能不能用模型解决、评测（评估测试）能不能达标」——痛+可行=开干；痛但不可行=记下，选下一个）——产出：一个高优先级验证方案（一个最痛的点+可行的解法+验证计划（怎么证明有效）——不是十个方案，是一个方案）。
打个比方：住进新家一个月后（找痛）——不装修所有房间（不做所有事），先找「最痛的一个点」：厨房做饭最费劲（最痛的单点——每天用 3 次、每次烦 10 分钟）——再确认「能不能改」（可行性：水龙头能换吗？燃气灶能换吗？——和师傅确认）——产出一个「改进方案」：换个好用的水龙头（一个方案，不是十个）——厨房痛点+可行=开干（不是「把所有房间都装修一遍」——那要一年）。
翻车案例：有新人第 2 个月列了「10 大改进建议」（十个痛点）发给团队——团队一看：「全是问题，哪个先做？」——没有优先级（十个痛点=没有重点）——建议石沉大海（老板不知道先干哪个，等于没建议）——「十个方案」翻车：第 2 个月的产出是「一个最痛的点+验证方案」（不是十个痛点清单）——最痛的单点（数据说话）+可行（和算法确认）——一个方案推进，才叫找痛。

第三步：第 3 个月「落地小赢」——做一个小而完整的功能。第三个月的目标：落地「一个小赢」——做一个小而完整的功能/优化（不是大功能，是「小但完整」：从上线到看到数据——完整闭环（做完整个流程：设计→开发→上线→看数据））；建立「我能交付」的信誉（小赢的价值不是功能本身，是「信誉」——团队看到「新人能交付」（能做完一件事、能看到数据）——以后你提大方案，团队愿意听（信誉是放大动作的门票））；同时把评测基线（评估基准：评测集（评估测试题）+基准数据（现在的水平：准确率 80%——以后改了好没好看基线）建好（AI 产品的「秤」——没有基线，以后改进没有对比——基线是第 3 个月的隐藏任务）。
打个比方：搬进新家三个月（小赢）——前两个月逛明白+找到痛点（厨房费劲），第三个月「做一件小事」：换个好用的水龙头（小而完整——从买到装到用上），家人用着顺手了（上线看到数据：家人做饭不烦了）——家人信「这人会干活」（信誉建立）——再谈「改厨房格局」（动大事——有信誉才有人支持）。同时把「水电登记表」建好（评测基线：哪里的水电多少——以后改了好没好看表——基线是秤，没有秤不知道改没改好）。
翻车案例：有新人第 3 个月想「搞个大的」：「AI 客服全流程重构」（大动干戈）——没小赢先放大——做了 3 个月没做完（大项目周期长），中间没有一个小胜利（没有信誉积累），团队开始怀疑（「这人到底能不能交付」）——项目没成、信誉也没建——「大动干戈」翻车：新人期的大项目=慢+没信誉（大项目周期长，90 天做不完=0 交付）——第 3 个月要「小赢」（小而完整：2-3 周能上线看数据的），不是「大动作」（3 个月做不完的）。

第四步：雷区——前 90 天最忌讳「大动干戈」。全周期最忌讳的一件事：「大动干戈」——一进来就改流程（「我觉得现在的需求流程有问题，建议改」）、推重构（「代码太乱了，建议重构」）、否定现状（「这个功能设计得不对，应该重做」）——为什么忌讳：新人没有信任（团队还不了解你——你说改流程，团队凭什么听？——「你懂什么？」）；大动干戈=大项目（周期长：90 天做不完=0 交付=试用期失败）；正确姿势：先小赢（做对小事：2-3 周的小功能上线看数据——证明能交付）→再放大（信任有了，再谈动大事——「先证明能做对小事，才有资格动大事」）。
打个比方：新来的厨师（新人）——进后厨第一天就「改菜单」（大动干戈）：「这个招牌菜的做法不对，应该改！」——老板（团队）不干：「你做过一天吗？就改招牌菜？」（没信任）——正确姿势：先做「配菜」（小赢：把小菜做好——老板看到「配菜做得好」）→再提「改一道菜试试」（放大：信任有了，试一道）→改好了（数据好）→再谈「改招牌菜」（动大事）——顺序：小赢→信任→放大。直接放大=被反弹（第一天改招牌菜=被赶出厨房）。
翻车案例：有新人入职一个月提「组织流程改革建议」（入职 30 天动大事——比 90 天还急）——方案被搁置（没信任：入职 30 天，团队不知道你靠不靠谱——改革建议=纸上谈兵）——本人还委屈（「我提的建议不好吗」——不是建议不好，是时机不对：没小赢没信任，好建议也推不动）——「太急」翻车：新人期放大动作=被反弹（好建议也需要信任承载）——先小赢（90 天做 1-2 个小功能），信任有了，建议才有分量。

第五步：收口——听懂（不装懂）→找痛（不空谈）→小赢（不画饼）。90 天的收口一句话：三个阶段各有各的「不」：第 1 个月听懂——「不装懂」（不懂就问（读文档、约人聊——画地图），不装懂（不懂装懂=画错地图））；第 2 个月找痛——「不空谈」（从数据里找痛（数据说话），不空谈（凭感觉说「产品有问题」））；第 3 个月小赢——「不画饼」（落地小功能（从上线看到数据），不画饼（「我规划了三个月后的大项目」——90 天结束，老板记得你「交付了什么」，不记得你「多聪明」））——听懂→找痛→小赢，90 天走完，你在团队里的位置就立住了。
打个比方：学游泳（90 天收口）——第 1 个月「不装懂」：先看教练怎么游（听懂——不装会游）；第 2 个月「不空谈」：找到自己最不会的动作（找痛：换气最差——练换气）；第 3 个月「不画饼」：游完一个 25 米（小赢：能游完一段——不吹「我下个月参加比赛」）——90 天结束，教练（老板）记得你「能游 25 米了」（交付了什么），不记得你「会分析游泳理论」（多聪明）。入职同理：听懂→找痛→小赢——交付比聪明值钱。
翻车案例：有新人 90 天「聪明但没交付」——第 1 个月讲了 5 次「我的产品方法论」（装懂），第 2 个月提了 3 份「建议报告」（空谈——没数据支撑），第 3 个月宣布「我有个大项目构想」（画饼——没落地）——90 天结束，老板评价：「人很聪明，但没看到交付」——试用期不过——「聪明没交付」翻车：新人期老板要的是「小赢」（交付了什么），不是「聪明」（讲了多少方法论）——听懂（不装懂）→找痛（不空谈）→小赢（不画饼），90 天交付立住。
小结：听懂（30 天画地图）→找痛（30 天一个痛点+验证方案）→小赢（30 天一个小功能+信誉+评测基线）→雷区（不大动干戈）→收口（不装懂/不空谈/不画饼）。

④ 对比表格：三个月的正确动作 对比 踩坑动作
| 阶段 | 正确动作 | 踩坑动作 | |------|------|------| | 第 1 个月听懂 | 读文档、跑数据、约人聊、画地图 | 不读数据就输出方案（纸上谈兵） | | 第 2 个月找痛 | 数据找最痛单点+算法确认可行 | 列十个痛点（没有重点） | | 第 3 个月小赢 | 小功能上线看数据+建评测基线 | 大项目重构（90 天做不完） | | 核心目标 | 建立「我能交付」的信誉 | 证明「我聪明」（方法论） | | 动作尺度 | 小赢→信任→放大 | 一进来就大动干戈（被反弹） | | 老板记忆 | 交付了什么 | 多聪明（没交付） | | 比喻 | 先做配菜再改招牌菜 | 第一天就改菜单（被赶出去） |

⑤ 3+个例子：90 天实战
例子1：AI 客服产品岗 90 天。第 1 个月：读客服产品代码和文档、搞懂评测集（评估测试题：哪些问题算答对）和数据管道（客服数据从哪来）、约算法（模型什么做不到）和数据（数据质量如何）聊一遍——产出客服产品现状地图；第 2 个月：从数据发现「退款问题」是投诉最多的一类（100 条投诉 60 条退款）——和算法确认（意图识别能不能精准识别退款问题——评测（评估测试）一版）——产出验证方案；第 3 个月：做一个「退款 FAQ 优化」小功能（2-3 周：加 20 条退款问答+评测通过）——上线看数据（退款问题解决率从 40% 到 65%）——小赢+建立评测基线（退款问答准确率 92%）。
例子2：AI 搜索产品岗 90 天。第 1 个月：搞懂搜索架构（召回（找到候选内容）→排序（排先后））、评测集（搜索评测：哪些查询算搜对）、数据管道（用户搜索日志）——约算法和数据聊——画搜索产品地图；第 2 个月：从搜索日志发现「长尾查询（少数人问的冷门问题）」搜不到是最大痛点（50% 查询搜不到结果）——和算法确认（模型能不能覆盖长尾——评测一版）——产出验证方案；第 3 个月：做「长尾查询兜底」小功能（加相关搜索建议+人工兜底——2-3 周）——上线看数据（无结果率从 50% 到 20%）——小赢+建立搜索评测基线。
例子3：AI 内容产品岗 90 天。第 1 个月：搞懂内容生产链路（AI 生成→人工审核→发布）、评测体系（内容质量怎么评）、数据管道（内容数据）——约角色聊——画内容产品地图；第 2 个月：从数据发现「AI 生成内容的低质率」最高（20% 内容不过审——人工审核成本高）——和算法确认（内容质量评分能不能提升——评测一版）——产出验证方案；第 3 个月：做「低质内容预筛」小功能（AI 先筛一轮再人工审——2-3 周）——上线看数据（人工审核量降 30%）——小赢+建立内容质量评测基线。
例子4：90 天的「隐藏任务」——评测基线。三个月里还有一个「隐藏任务」：第 1 个月搞懂评测体系→第 2 个月用现有评测跑一版基线（评估基准：现在准确率 80%——记住它）→第 3 个月小赢上线后用同一套评测再跑（准确率 85%——对比基线，证明改好了 5%）——基线（基准数据）是 AI 产品的「秤」：没有基线，你做的改进「不知道好不好」（没有对比）；建好基线，每次改进都有「数字对比」（数据说话）。

⑤b 补充板块：「听懂」阶段的三个清单（读什么、问什么、聊什么）
「听懂」阶段最容易「漫无目的」——三个清单帮你听懂：
第一，读什么清单：产品文档（PRD（产品需求文档）/需求清单）、技术文档（架构图/数据流图）、数据文档（指标口径（指标怎么算的）：指标清单/看板）——三份文档读完，产品现状有个骨架（不读文档=听别人讲（二手信息），读完=一手信息）。
第二，问什么清单：问自己三个问题——产品核心指标是什么（北极星（核心目标））？现在最痛的问题是什么？技术债（欠账）在哪？——三个问题有答案，「现状地图」有主线（没主线=地图散架）。
第三，聊什么清单：约三个角色各聊一次——算法（模型什么做不到、评测（评估测试）怎么跑）、数据（数据从哪来、什么脏）、业务（业务要什么、什么最痛）——每人 30 分钟，聊完记笔记（不记笔记=白聊（过一周就忘））。
一句话：听懂三清单——读什么（三份文档）、问什么（三个问题）、聊什么（三个角色）——清单在手，听懂不迷路。

⑤c 补充板块：「找痛」阶段的数据三查——不凭感觉找痛
「找痛」阶段最容易「凭感觉」（我觉得这里最痛）——数据三查：
第一，查转化（漏斗（转化环节））：用户一步步走到目标的环节——哪一步流失最多（数据：100 人进来，90 人卡在第 2 步——第 2 步最痛——流失率最高的环节就是最痛的点）。
第二，查投诉（反馈）：客服记录/评价/群聊——哪类问题被反复提（数据：100 条投诉 60 条「退款」——退款最痛——被提最多的就是最痛的点）。
第三，查成本（运营）：团队每天在花时间处理什么（数据：客服 50% 时间在处理同一类问题——这类问题最痛——人工成本最高的环节就是最痛的点）。
一句话：找痛三查——查转化（流失最多）、查投诉（被提最多）、查成本（耗时最多）——三个数据看下来，「最痛的单点」自然浮现（不凭感觉，凭数据）。

⑥ 常见误区（3个）
误区1：「前 90 天要多输出（多提建议、多展示自己）。」错！前 90 天多「听懂」（读文档、跑数据、画地图），少「输出」（建议要有数据支撑、时机要等信任）——多输出的新人=纸上谈兵（没数据没信任的输出=噪音）。
误区2：「第 3 个月要搞个大的（大项目才能证明自己）。」错！第 3 个月要「小赢」（小而完整：2-3 周上线看数据）——大项目 90 天做不完=0 交付（没有小胜利=没有信誉）——大项目是小赢之后的（信任有了再放大）。
误区3：「评测基线和数据是算法的事，产品不用管。」错！评测基线（评估基准）是产品的「秤」（定义怎么算好是产品的活：评测集（评估测试题）覆盖哪些场景、及格线多少——产品定义，算法实现）——产品不管基线=改了好没好看（没有对比数据=白改）。

⑦ 第一人称面试回答（3年景观设计→自学转行 AI 产品）
「我 3 年景观设计，被裁后自学转行——听懂→找痛→小赢，我做景观设计时的经验完全一致：进设计院头三个月，我没有急着出方案（大动干戈——新人出方案没人看），而是先「听懂」——把公司做过的项目图纸全看一遍（读文档）、搞懂公司的设计规范和流程（评测体系）、约老设计师聊（每个项目的坑在哪）——画了一张「公司项目地图」（什么项目类型、什么甲方风格、什么坑最常见）；第 2 个月「找痛」——从地图里找到最痛的：甲方最爱改「屋顶造型」（改 10 次有 7 次是屋顶）——和师傅确认可行性（屋顶怎么设计才不容易被改）；第 3 个月「小赢」——做一个「屋顶造型分析」小研究（小而完整：分析 20 个项目的屋顶方案，总结 3 种防改设计）——团队开始用我的结论（信誉建立：「新人能交付」）。转行学 AI 产品后，把同样的节奏翻译成 AI 语言：第 1 个月听懂（读文档、搞懂评测体系（评估好坏的体系）和数据管道（数据搬运流程）、约算法/数据/业务聊——画产品现状地图）；第 2 个月找痛（数据找最痛单点（转化漏斗（转化环节）最差一环）+算法确认可行）；第 3 个月小赢（小功能上线看数据+建评测基线（基准数据）——建立我能交付的信誉）。我没有大厂 90 天经验，但设计院头三个月的经历证明：我懂新人期的正确节奏——先听懂、再找痛、后小赢，不装懂、不空谈、不画饼。」

⑧ 小结口诀
「30 天听懂（画地图）、30 天找痛（一个痛点）、30 天小赢（小功能+信誉+基线）；不大动干戈（先小赢再放大）；不装懂/不空谈/不画饼——90 天，交付立住。」

⑨ 三轮追问（面试官深挖）
追问1：「如果 90 天里老板催你出成果（等不了小赢），怎么办？」「催是常态——用『小赢』回应：把大成果拆成小阶段（90 天的大项目拆成 3 个 30 天的里程碑（阶段目标）），每 30 天交一个『小赢』（第一个里程碑：听懂报告（1 页纸地图）；第二个：验证方案（1 页纸）；第三个：小功能上线（看数据））——老板看到『每 30 天有交付』，就不催了（他催的是『没有进展』，不是『成果太大』——持续的小赢=持续的进展）。」
追问2：「听懂阶段，算法不愿意和你聊（觉得你外行），怎么办？」「先自己补功课再去聊（不空手聊）：读文档+跑一版评测（评估测试）数据（自己动手跑一遍——带着问题去聊：『我跑了评测，发现 X 类问题准确率只有 60%，这是什么原因？』——带着数据的问题，算法愿意答（他在解决具体问题，不是给你补课）；聊完记笔记+复述（把算法说的复述一遍确认——『您是说评测集（评估测试题）偏了？』——让他知道你真的听懂了）——带功课+带数据+复述确认，算法愿意聊（你尊重他的时间，他也尊重你的问题）。」
追问3：「小赢之后，第 4 个月怎么放大？」「放大三选一：①同痛点深化（小赢做的退款 FAQ 效果好——继续做退款全链路（从答到退到查）——同一痛点的纵深（越做越深）；②新痛点（退款做好了——做下一个最痛（物流）——痛点的横向扩展（一个接一个）；③流程放大（有信誉了——提『评测流程优化』（改团队的工作方式）——从做事到改事（信任到了才动流程））——放大不是『换个更大的项目』，是『在信誉上叠加』（小赢的信任，是放大的本钱）。」

⑩ 进阶加分点（说出口就加分）
加分点1：把 90 天写成「三个一」。「我的 90 天三个一：第 1 个月一张地图（产品现状地图）、第 2 个月一个方案（高优先级验证方案）、第 3 个月一个小赢（小功能上线）——三个一好记好汇报（老板问进度：地图画好了→方案定了→小赢上线了）——90 天讲成三个一，节奏清清楚楚。」——「三个一」让规划可汇报（不用背长篇）。
加分点2：引入「信任账户」概念。「我把新人期当『信任账户』：小赢是存款（每交付一个功能=存一笔信任），大动作是取款（动大事=花信任）——前 90 天只存不取（小赢攒信任），第 4 个月才取（放大动作——账户里有货才能取）」——「信任账户」一说出口，你就懂「信任经济学」（先存后取，别透支）。
加分点3：把评测基线和「我的小赢」绑定。「我的小赢不只是功能上线，是『功能上线+评测基线』两个产出：退款 FAQ 上线（功能）+退款问答准确率 92% 的基线（秤）——以后这个功能每次改动，都拿基线对比（改了没改好，数字说话）——我交付的不只是一个功能，是一把『以后能用的尺子』。」——「交付一把尺子」说明你懂 AI 产品是「持续改进」（基线是持续改进的基础）。

⑪ 话术库（直接抄着说）
「前 90 天分三段：30 天听懂（读文档、跑数据、约人聊、画地图）、30 天找痛（数据找最痛单点+算法确认可行）、30 天小赢（小功能上线看数据+建评测基线）。」
「听懂的标准：能画出产品现状地图（功能/指标/技术债（欠账）/卡点）——画得出=真懂。」
「找痛三查：查转化（流失最多）、查投诉（被提最多）、查成本（耗时最多）。」
「前 90 天最忌讳大动干戈——先证明你能做对小事，才有资格动大事。」
「90 天结束，老板记得你交付了什么，不记得你多聪明。」

⑫ 小白 Q&A（可能踩的坑）
Q1：听不懂技术（代码/架构），第 1 个月怎么听懂？不用懂代码——懂「技术架构」和「数据流」就行（系统怎么搭的、数据从哪来到哪去——问算法/工程，让他们用大白话讲一遍，画成图）——产品经理的听懂是「懂业务逻辑+数据流」，不是「懂代码实现」。
Q2：第 3 个月的小赢，功能太小会不会显得没本事？不会——「小赢」的对比对象是「0 交付」（大项目做不完=0），不是「大功能」——老板眼里「小功能上线+数据」远胜「大项目进行中」（一个是有结果，一个是没结果）——小赢不小，0 交付才小。
Q3：评测基线（基准数据）建在哪（用什么工具）？工具不重要（评测集（评估测试题）+跑分脚本+结果文档就行——最简：电子表格（Excel）记分数）——重要的是「标准」（评测集覆盖哪些场景、及格线多少——产品定义）和「习惯」（每次改动都跑一版记录——坚持记）——工具是壳，标准和习惯是芯。

⑬ 没人告诉你的事（面试潜规则）
这道题面试官真正在听的，是「你有没有新人期认知」——大部分新人答「我要大干一场」（证明自己的冲动），你说「听懂→找痛→小赢」（稳着来的节奏）——面试官当场加分（他要的是「能活过试用期的人」，不是「三个月就烧光信任的人」）。另一个潜规则：这道题的灵魂是「信任」——「先证明能做对小事，才有资格动大事」是全场的金句（信任的顺序比能力更重要——面试官自己也是从新人过来的，最懂）。还有一个：用「设计院头三个月」讲 90 天规划，比背「听懂找痛小赢」动人十倍——你的真实经历（新人期的正确节奏）就是最稀缺的面试素材——面试官会记住「这个转行者懂新人期」。

⑭ 做一件事（学完就动手）
今天给你「接下来 90 天」定一份规划（学习计划、求职计划、副业计划都行）：①前 30 天听懂——列「读什么」（3 份资料）+「聊什么」（3 个人/3 个信息源）；②中间 30 天找痛——找出「最痛的一个点」（卡你最久的那个问题）；③后 30 天小赢——定一个「小而完整」的目标（2-3 周能完成、能看到结果的）——90 天走完，你会发现：稳着来，比急着来快一倍（小赢攒信心，信心带速度）。

⑮ 求职助手联系（面试前必做）
面试前用本卡做 3 件事：①把「30 天听懂、30 天找痛、30 天小赢」练熟（面试框架）；②准备你的「新人期」案例（设计院头三个月——真实经历最动人）；③把「先证明能做对小事，才有资格动大事」练熟（收口金句）。面试被问「前 90 天规划」时：先说三段（听懂/找痛/小赢）→再说雷区（不大动干戈）→收口（不装懂/不空谈/不画饼）——节奏清晰+经历真实+金句收口，面试官立刻记住你。

⑯ 练习（自己测一遍）
1.（排序）入职前 90 天的正确顺序？A 听懂→找痛→小赢；B 大干一场→发现推不动→重来——答案：A。
2.（产出）第 1 个月「听懂」阶段的产出是什么？——答案：产品现状地图（功能/指标/技术债（欠账）/卡点）。
3.（角色）老板问「前 90 天你要做什么」，你一句话回答？——参考答案：「30 天听懂（画产品现状地图）、30 天找痛（数据找最痛单点+算法确认可行）、30 天小赢（小功能上线看数据+建评测基线）——先证明能做对小事，才有资格动大事。」

AI 技术债优先级


图怎么读：技术债（技术上的欠账——为了赶进度先凑合、以后要补的账）怎么还，分三步：①先分清欠的啥——两类债：模型债（model debt：提示词（prompt，给模型下指令的话）一人私有、评测集（评估模型好坏的测试题）没有、模型版本没锁——换个人就崩）和数据债（data debt：标注口径不统一、数据管道（数据搬运流程）断链、样本没人维护——越用越不准）；②三维度打分——风险（债不还会出什么事：上线事故/合规问题）、频率（多久撞一次：天天堵最急）、成本（还债要多少工作量：越小越好）——优先级＝风险×频率÷成本；③按分排序——第1批还「高频+高风险+低成本」的债（如补自动化回归评测集——先堵天天漏水的地方），「低风险+高成本」的债（如数据管道重构）排到路线图慢慢还；收口：技术债是产品指标——把「评测覆盖率」「数据新鲜度」写进产品看板（项目管理看板，大家盯着看的地方），债有人看才有人还；还债节奏＝每次迭代带一点+季度还债周。

① 一句话大白话定义
这道题问的是：AI 产品（人工智能产品）里的技术债——模型可维护性（模型好不好维护、换人能不能接得住）和数据流程规范性（数据从哪来、怎么标、怎么更新有没有规矩）——到底先还哪个？
用大白话说：技术债就是「为了赶进度先凑合、以后要还的账」——先还「会出事、天天撞、还好还」的债（高频+高风险+低成本），把「不会出事、偶尔撞、很难还」的债（低风险+高成本）排到后面慢慢还。排序公式：风险×频率÷成本——不是工程师说先还哪个就还哪个。

打个比方：老房子装修欠的账——墙里埋的旧电线（不动没事，一加空调就跳闸：高风险+低频——要排前，因为出事就是大事故）、厨房下水道（天天堵：高频——必须马上修，不然日子没法过）、墙角一道细裂缝（不好看但不会塌：低风险+高成本——排在最后，有空再补）。技术债同理：先堵「天天漏水」的地方（高频），再修「一修就炸」的地方（高风险），最后才管「好看不好看」的地方（低成本高收益的顺手干）。

30 秒电梯版：「技术债分两类：模型债（提示词一人私有、评测集没有、版本没锁）和数据债（标注口径不一、管道断链、样本没人维护）。排优先级看三个维度：风险（不还会出什么事）、频率（多久撞一次）、成本（还债工作量）——按『风险×频率÷成本』打分排序：先还『高频+高风险+低成本』的（比如补一个自动化回归评测集——每天在跑的东西天天错，先堵它），『低风险+高成本』的（比如数据管道重构）排到最后。关键认知：技术债不是工程师的私事，是产品指标——把『评测覆盖率』『数据新鲜度』写进产品看板，债有人看才有人还；偿还节奏是每次迭代带一点+季度还债周，不让债滚成雪球。」

② 为什么学 / 面试为什么考
技术债是 AI 产品做一段时间后必然撞上的墙，面试考它的原因有三：
第一，它考「优先级思维」。AI 产品的技术债永远还不完（评测没建全、数据没标完、提示词没沉淀）——面试官想看你懂不懂「资源有限时先干什么」——这是产品经理（PM）的核心能力（做决策，不是做全部）。
第二，它考「产品视角 对比 技术视角」。工程师想还「技术上有意思的债」（重构架构、换新技术），产品经理要还「对业务最疼的债」（天天出错的地方）——面试官想看你有没有「产品视角」（从业务价值出发，不是从技术兴趣出发）。
第三，它考「AI 产品特有认知」。传统产品（软件）的技术债是「代码债」，AI 产品多两类：模型债和数据债——面试官想看你懂不懂「AI 产品的账欠在哪」——这决定了你会不会踩 AI 的坑（模型换人维护就崩、数据越用越不准）。
一句话：这道题考的是「优先级思维」＋「产品视角」＋「AI 产品特有认知」。

③ 原理拆解：分清债→打分→排序→定节奏

第一步：分清欠的什么债——两类债。AI 产品的技术债分两类：第一类「模型债」——模型（人工智能模型）这摊子的事：提示词（prompt：给模型下指令的模板话术）写成一人私有（只有写的人懂，换人就看不懂）、评测集（评估模型好坏的测试题库）没有（改没改坏都不知道）、模型版本没锁（今天用 V1 明天用 V2，出了事不知道是哪版干的）——一句话：模型这摊子换个人就接不住；第二类「数据债」——数据这摊子的事：标注口径不统一（同样的东西，昨天标「猫」今天标「猫咪」）、数据管道断链（数据搬运流程断了，新数据进不来）、样本没人维护（库里全是旧样本，越来越不反映现实）——一句话：数据越用越不准。
打个比方：家里欠的账分两类：电器债（空调坏了、冰箱结霜——电器这摊子）和管道债（下水道堵、水管漏——管道这摊子）。模型债就是「电器债」（模型这摊子），数据债就是「管道债」（数据这摊子）——两类债都要还，但先还哪类、还哪个，要看后面的打分，不是凭「哪个先想起」。
翻车案例：有团队只认「代码债」（觉得技术债=代码写得乱），模型债和数据债不算债——结果：写提示词的人离职，别人看不懂他写的提示词（模型债爆了）；数据管道断了没人管，模型越用越不准（数据债爆了）——「只认代码债」是 AI 团队最常见的翻车（债不止代码一种，模型和数据各有一摊）。

第二步：三维度打分——风险×频率÷成本。每笔债按三个维度打分：风险（债不还会出什么事——上线事故（产品上线出问题）、合规问题（违反法规）、用户投诉）；频率（多久撞一次——天天撞的高频 对比 一年撞一次的低频）；成本（还债要多少工作量——补个评测集三天 对比 重构数据管道三个月）。优先级＝风险×频率÷成本：风险高、频率高、成本低的债最优先（划算是「一笔小钱堵一个大坑」）；风险低、频率低、成本高的债最后还（不划算——钱花得多，坑也不大）。
打个比方：记账本记三笔欠账：①厨房下水道——天天堵（频率最高），堵一次淹一厨房（风险不低），通一次五十块（成本低）——最优先！②墙里旧电线——平时没事，一加空调就跳闸（频率低但风险高：出一次就是火灾级别），重走线三千块（成本高）——第二优先（风险高压过频率）。③阳台瓷砖缝——不好看但没事（风险低、频率低），重铺八百块（成本高）——最后。公式「风险×频率÷成本」就是把「感觉」变成「数字」——下水道＝高×高÷低＝最高分，瓷砖缝＝低×低÷高＝最低分。
翻车案例：有团队按「工程师喜好评」还债——工程师觉得「重构数据管道」最有技术含量（加分项），就先做了三个月；结果期间模型天天输出旧数据（数据债没还：管道还是断的），用户天天投诉（风险+频率双高）——「凭兴趣还债」翻车：还了三个月的技术爽债，最疼的债（管道）反而没还。要按「风险×频率÷成本」打分，不是按「谁觉得有意思」。

第三步：按分排序——先还「高频+高风险+低成本」。排完分从高到低还：第1批「高频+高风险+低成本」——例子：补一个自动化回归评测集（每天模型改动都在跑，没有评测集就不知道改没改坏——风险高（出事不知道）、频率高（天天在改）、成本低（建一套测试题三天））——先堵这个「天天漏水」的地方；中间「中频+中风险+中成本」——按路线图排期还（如统一标注口径：标数据的人天天在标，口径不一就是天天在制造债）；最后「低风险+高成本」——如数据管道重构（不重构也能跑，只是费人力）——排到路线图里，有空/有预算再还。
打个比方：还债顺序像修老房子：先修「天天漏水的厨房」（高频+高风险：不修日子没法过）→再修「跳闸的电线」（高风险：不修夏天没法过）→最后才「重新刷墙」（低风险+高成本：不刷也住得下去，有空再说）。技术债同理：先堵天天错的（回归评测集——每天在跑），再修大风险的（合规问题——出事就是大事），装饰性的（管道重构——费人力但能跑）最后。
翻车案例：有团队先还「低风险高成本」的债（数据管道重构——三个月），把「高频高风险」的债（模型版本没锁——每次上线都不知道跑的是哪版）留在后面——结果上线出事故（版本没锁：改了个坏版本上线了），用户数据受损（风险爆了）——排序反了：先还了「不着急」的债，把「要命」的债留在后头。排序铁律：先堵天天漏水的（高频），再修一炸就没的（高风险），最后才碰「慢慢来」的（低成本优先）。

第四步：定偿还节奏——每次带一点+季度还债周。技术债不能「攒一年还一次」（债越攒越大，还的时候全停摆），也不能「一次全还完」（业务迭代全停，老板不答应）——要「细水长流」：每次迭代（产品开发的一个小周期）带 10%～20% 的还债工作量（每个 sprint（迭代周期，一般两周）都安排一点还债任务，不还债就不算完成）；每季度留一个「还债周」（一周不排新功能，专门清技术债）——债滚不成雪球，业务也不停摆。
打个比方：健身练腹肌——不是「一年突击一个月」（突击完又胖回去），是「每天 20 分钟」（细水长流才有效）。还债同理：每次迭代带一点（每天 20 分钟——债不长）＋季度还债周（每月一次大扫除——债清零）——两种节奏配合，债永远在可控范围。
翻车案例：有团队「先冲功能，债攒着」——攒了一年：评测没有、数据乱标、版本乱换——年底一算，还债要三个月，业务停摆三个月（老板炸了）——「攒着还」翻车：债滚成雪球，还债成本比当初凑合省下的高十倍。还债要「细水长流」（每次带一点），不是「攒一年清一次」。

第五步：收口——技术债是产品指标，不是工程师私事。最关键的一步：把技术债变成「产品指标」——把「评测覆盖率」（多少比例的改动有评测兜底）、「数据新鲜度」（数据多新、断链几天）写进产品看板（项目管理看板，大家都盯着的地方），和「日活、留存」并列——债有人看，才有人还；债进了看板，产品经理和老板才看得到「债在吃未来」——还债才有预算、有排期。
打个比方：体重秤——不称体重的人不知道自己在胖（债在偷偷长）；每天称（写进看板），一胖就知道，立刻控制。技术债写进产品看板＝每天称体重——「评测覆盖率 30%」一看就知道模型快失控了，「数据断链 7 天」一看就知道答案在过时——看得见，才管得住。
翻车案例：有团队技术债只在工程师群里聊（产品经理不知道）——老板看产品「功能很全」很开心，不知道底下全是债（评测 0%、数据断链半个月）——某天模型大崩（没评测兜底），产品停摆两周——「债不进看板」翻车：债没被看到，就不会被还，最后以事故的形式爆发。把债写进看板（产品指标），是产品经理对技术债最大的贡献。
小结：分清债（模型债/数据债）→打分（风险×频率÷成本）→排序（先高频+高风险+低成本）→定节奏（每次带一点+季度还债周）→收口（写进产品看板当指标）。

④ 对比表格：什么债先还 对比 什么债后还
| 维度 | 先还的债（高优先级） | 后还的债（低优先级） | |------|------|------| | 风险 | 高风险：不还会出事（合规、事故） | 低风险：不还只是「不够好」 | | 频率 | 高频：天天撞（回归评测集没有） | 低频：一年撞一次（旧代码兼容） | | 成本 | 低成本：三天能补（建评测集） | 高成本：三个月重构（管道重构） | | 公式 | 风险×频率÷成本＝高分 | 风险×频率÷成本＝低分 | | 典型 | 自动化回归评测集、合规整改 | 数据管道重构、老功能重构 | | 比喻 | 天天漏水的厨房下水道 | 阳台一道细裂缝 | | 决策权 | 产品经理拍板（业务疼不疼） | 排进路线图慢慢还 | | 后果 | 先还=事故率下降、上线有底 | 先还=业务停摆、债越滚越大 |

⑤ 3+个例子：技术债怎么排
例子1：回归评测集（高频+高风险+低成本——第1批）。模型每周都在改（提示词调一版、模型换一版）——没有评测集（评估模型好坏的测试题库），改坏了自己都不知道（风险高）；每周都改（频率高）；建一套自动化回归评测集三天（成本低）——先还它：以后每次改完自动跑一遍，坏了立刻知道（上线有底）。
例子2：合规问题（高风险——优先插队）。数据里有用户隐私没脱敏（个人信息处理不合规）——不还会被罚（风险最高），虽然频率低（不是天天出事），但出事就是大事——插队还：先脱敏再上线（高风险压过一切）。
例子3：数据管道重构（低风险+高成本——最后）。数据搬运流程全靠人肉（手动导出导入），费人力但不至于出事——不重构也能跑（风险低），重构要三个月（成本高）——排到路线图最后：有空/有预算再还（先记到债单里，别丢）。
例子4：标注口径统一（中频+中风险——中间批次）。标数据的人各标各的（有人标「猫」有人标「猫咪」）——样本库越来越乱（中风险），每天都在标（中频率）——排中间：定一套标注规范（标什么、怎么标、谁审核），写进文档让所有标注的人照着做。

⑤b 补充板块：技术债从哪来（欠账怎么产生的）
技术债不是天上掉的，是「凑合」攒出来的——四个典型来源：
第一，赶上线凑合。发布日（上线日期）到了，功能还没测完——「先上，债后面还」——上线了，债记下了（最常见来源）。
第二，「先做出来看看」。想法不确定，先做个 MVP（最小可行产品，最简版本试水）——做出来验证想法，但 MVP 的代码/数据都是凑合的——想法验证完了，凑合的债留下了。
第三，人走债留。写提示词的人离职、标数据的人换人——人走了，他脑子里的规则没人知道（一人私有）——人走了，债留下了。
第四，没人认领。债没有记到任何人的账上（没有债单）——「这不是我的事」——没人认领的债，慢慢变成「不知道存在的债」。
一句话：技术债四个来源——赶上线、先凑合、人走债留、没人认领——知道债从哪来，才知道怎么防（不是只还，还要少欠）。

⑤c 补充板块：产品经理怎么推动还债（不写代码也能还债）
产品经理不写代码，怎么推动还债？四个抓手：
第一，建债单（技术债清单）。把技术债记成一张清单（什么债、谁发现的、风险多大、频率多高）——债先被看见（看得见的债才是债）。
第二，排进路线图（产品开发计划表）。还债任务排进路线图（不是「顺便」，是正式排期）——债有排期才有人做。
第三，绑业务指标。把还债和业务指标绑定（「评测覆盖率到 80% 才放新模型上线」——不还债就不能上新）——债和业务利益挂钩，还债才有动力。
第四，还债要验收。还完债要验收（「评测集建好了，跑一遍看看能不能拦住坏模型」——不是还完就算，要验证债真还清了）——还债不验收=白还。
一句话：产品经理推动还债四个抓手——建债单、排路线图、绑业务指标、验收——不写一行代码，债也能被还掉。

⑤d 补充板块：AI 产品的债为什么比传统产品更难还
传统产品（软件）的技术债是「代码债」——还债=改代码，边界清楚（改哪段代码，修哪个 bug）；AI 产品的债有三个「更难」：
第一，债会「自己长大」。代码债放着不变（代码不自己变坏），AI 的债会自己变坏——模型版本外部在更新（底座模型（底层大模型）升级，你的提示词可能失灵）、数据环境在变（用户说的话变了，旧样本不匹配）——AI 的债不还，不是「放着」，是「在长」（今天不锁版本，明天升级崩一次）。
第二，债的边界不清楚。代码债能定位（这个功能慢，是这段代码的问题）；AI 的债往往「说不出是谁的」——输出不对，是提示词的问题？数据的问题？模型的问题？（定位难：三个环节都可能）——还债前先要「定位」：跑评测（评估测试）、看样本、复盘输出——AI 还债多一步「找病根」。
第三，债的验收难。代码债修完能测（跑一遍用例（测试场景）过了就是修好）；AI 的债修完「测不干净」——提示词改了，这题对了那题错了（没有完美的评测）——AI 还债没有「修好了」的确认键，只有「评测通过率 90%」的相对标准。
一句话：AI 的债三难——自己长、边界糊、验收难——所以 AI 团队更要「欠债记账」（债单）、「高频检查」（评测覆盖率写进看板），因为债会自己滚雪球。

⑤e 补充板块：不同产品阶段的还债策略（欠债也有好时机）
还债不是「任何时候都一样」——产品阶段不同，策略不同：
第一，MVP 阶段（最简验证期：产品刚做出个样子验证想法）：多欠少还。这个阶段的目标是验证「想法有没有人用」——想法没验证，还债没意义（把债还完了，想法错了，白还）；所以 MVP 阶段允许凑合（先跑起来），但要记账（债单记下来），等验证通过再还——欠债有理，记账必备。
第二，增长阶段（用户量涨得快的时候）：边跑边还。这个阶段目标跑量（用户和功能增长），但不能裸奔（没评测就放量，一次事故伤一批用户）——每次迭代带 10%～20% 还债（细水长流），高频的债（评测、版本锁）优先——跑得快，但别忘了穿鞋。
第三，稳定阶段（产品成熟期）：集中清债。这个阶段功能稳定，可以安排季度还债周（一周不排新功能，专门清债）+集中还「高成本」的债（数据管道重构、标注体系重建）——平时跑得快欠的债，这个阶段集中还（像年假大扫除）。
一句话：还债策略跟产品阶段走——MVP 多欠少还（记账）、增长边跑边还（带一点）、稳定集中清债（还债周）——「什么时候欠、什么时候还」也是优先级的一部分。

⑥ 常见误区（3个）
误区1：「技术债是工程师的事，产品不用管。」错！技术债决定产品能跑多快（债多了，加个功能要三天——全在还债）——产品经理必须管：债单、排期、指标（产品视角管还债，工程师视角管实现）。
误区2：「债要一次全还完。」错！一次全还完＝业务停摆三个月（老板不答应）——细水长流（每次迭代带一点+季度还债周）才是对的（债不长、业务不停）。
误区3：「技术债=代码写得乱。」错！AI 产品的债三分：模型债（提示词、评测、版本）＋数据债（口径、管道、样本）＋代码债——只盯代码债，模型债数据债爆了都不知道（AI 产品特有的债别漏）。

⑦ 第一人称面试回答（3年景观设计→自学转行 AI 产品）
「我的经历有点特别：3 年景观设计，被裁之后自学转行，没做过正式上线的大项目——但我对技术债这件事，有自己的真实体会。转行后我用 AI 工具做过一些自己的项目，技术债我实实在在踩过：我写过一个统计脚本，给一本书的 942 道题统计字数、检查格式——一开始没有留文档，规则口径都在我自己脑子里（这就是模型债：一人私有）；后来有一次备份文件被覆盖了，规则和脚本差点全丢（这就是数据债：数据没人维护）——那之后我给自己定了三条规矩：统计口径写成文档放在脚本旁边、每次改脚本先备份、规则统一记在一处——这就是我理解的『还债』：把欠的账（没人懂的规则、没人管的备份）补上，换个人也能接住。所以回答这道题：技术债分两类——模型债（提示词一人私有、评测集没有、版本没锁）和数据债（标注口径不一、管道断链、样本没人维护）；排优先级用三维度打分——风险（不还会出什么事）×频率（多久撞一次）÷成本（还债工作量），先还『高频+高风险+低成本』的（比如自动化回归评测集），『低风险+高成本』的排最后；关键认知：技术债是产品指标——把评测覆盖率、数据新鲜度写进产品看板，债有人看才有人还；节奏：每次迭代带 10%～20% 还债工作量+季度还债周。我没有大厂数据，但我用『写书统计脚本的债』证明了我会还债、懂排序。」

⑧ 小结口诀
「分两类债（模型债、数据债），打三个分（风险、频率、成本），先堵高频+高风险+低成本，细水长流带着还，写进看板有人看。」

⑨ 三轮追问（面试官深挖）
追问1：「你怎么量化『风险』？」「三个客观信号：①事故记录——这类债上次出过事吗、几次（有事故=风险高）；②合规清单——有没有踩合规红线（隐私、安全、法规——踩了=风险最高）；③用户影响——债爆了影响多少人、多严重（影响面广=风险高）。把『感觉』变成『记录』：有事故记录、在合规清单上、影响用户面广——三项占两项就是高风险。」
追问2：「工程师说『这个债必须马上还』，你怎么判断？」「我不否定，但请他给三个数：风险（不还会出什么事）、频率（多久撞一次）、成本（要多久）——用『风险×频率÷成本』对齐：如果他说的债算出来分数确实最高，那马上还；如果分数不高（只是他觉得『技术上有意思』），排到路线图后面，并明确告诉他排期理由（不是不还，是排序）。关键是『用同一把尺子』，不是谁嗓门大听谁的。」
追问3：「预算只够还一笔债，你选哪笔？」「选『高频+高风险+低成本』里分数最高的——比如自动化回归评测集：每天在改模型（高频）、没有评测改坏了不知道（高风险）、三天能建（低成本）——小钱堵大坑，最划算。选它的逻辑不是『最急』，是『最划算』：同样一笔预算，还它带来的风险下降最大。」

⑩ 进阶加分点（说出口就加分）
加分点1：把债和「模型信任」绑在一起。「我理解技术债的终极成本是『模型信任』：评测没了、数据脏了——模型输出越来越不靠谱，用户对产品的信任一点点流失——还债不只是还技术账，是修信任（债吃的是未来，不是现在）。」——这句话说明你不只懂排序，懂「债的深层成本」。
加分点2：引入「债息」概念。「技术债有利息：欠一天，多一天的摩擦（改个提示词要问三个人、跑个数据要手动导三天）——利息就是每天多花的力气；还债=还本金，早还一天省一天利息。」——专业术语（债息/利息）一说出口，层次就上来了。
加分点3：用「债单+评审」闭环。「我还债会带闭环：债单（记下来）→评审（每两周过一遍债单，重排优先级）→还债（排期）→验收（验证真还清）——闭环保证债不丢、不烂尾。」——闭环思维（从记到验的完整流程）是产品经理的加分项。

⑪ 话术库（直接抄着说）
「技术债分两类：模型债（提示词一人私有、评测集没有、版本没锁）和数据债（标注口径不一、管道断链、样本没人维护）。」
「排优先级用三维度打分：风险×频率÷成本——先还高频+高风险+低成本的债，低风险+高成本的排最后。」
「技术债不是工程师的私事，是产品指标——把评测覆盖率、数据新鲜度写进产品看板，债有人看才有人还。」
「还债节奏：每次迭代带 10%～20% 还债工作量+季度还债周——不让债滚成雪球。」
「技术债有利息：欠一天多一天摩擦——还债=还本金，早还一天省一天利息。」

⑫ 小白 Q&A（可能踩的坑）
Q1：技术债和 bug（程序缺陷/漏洞）有什么区别？bug 是「现在就有问题」（程序跑错了），技术债是「现在能跑但以后要还账」（凑合做的、欠的改进）——bug 立刻修，债排期还。
Q2：技术债一定不好吗？不一定——「赶上线先凑合」有时是对的（MVP 阶段（最简版验证期）不凑合就没速度），关键是「凑合要记账、要排期还」——有计划的债是工具，没计划的债是雪球。
Q3：产品经理不懂技术，怎么还债？不用写代码——建债单（记下来）、排路线图（排期）、绑业务指标（评测覆盖率达到才放新版本）、验收（还完验证）——四件事都不写代码，债一样被还掉。

⑬ 没人告诉你的事（面试潜规则）
这道题真正的分水岭不是「会不会排优先级」，是「你敢不敢管技术」——80% 的候选人会说「技术债是工程师的事」，你说「技术债是产品指标，我来建债单、排排期、绑指标」——当场立住。另一个潜规则：面试官考技术债，实际在考你「踩过坑没有」——没踩过的人背书，踩过的人讲细节（我备份被覆盖的坑、统计口径一人私有）——真实细节比标准答案值钱。还有一个：技术债是最容易「聊出信任」的题——因为你承认「我欠过债、我踩过坑」，反而让面试官觉得你真实（面试官自己天天被债追着跑，最懂）。

⑭ 做一件事（学完就动手）
今天给你手头的项目（工作、学习、副业都行）建一张「技术债清单」：写下 3 笔你正在欠的账（什么债、风险多高、多久撞一次、还债要多久），按「风险×频率÷成本」打分排序——然后只还分数最高的那一笔（哪怕只做一半）。做完你就懂了：还债的难点不是还，是「看清哪笔最划算」——这就是产品经理的优先级思维。

⑮ 求职助手联系（面试前必做）
面试前用本卡做 3 件事：①把「技术债=风险×频率÷成本」练成 30 秒顺口溜（面试开头用）；②准备一个自己的债案例（备份被覆盖/统计口径一人私有——真实细节最打动面试官）；③把「技术债是产品指标」这句话练熟（追问时甩出来立人设）。面试被问「技术债」时：先说分类（模型债/数据债）→再说排序（三维度打分）→最后收口（写进看板当指标）——框架完整，细节真实，面试官立刻记住你。

⑯ 练习（自己测一遍）
1.（排序）下面三笔债按「风险×频率÷成本」排序：A 自动化回归评测集（高风险+高频+三天）；B 数据管道重构（低风险+低频+三个月）；C 合规脱敏（风险最高+低频+两周）——答案：C 第一（风险最高压一切），A 第二（高频+低成本划算），B 最后。
2.（分类）下列属于模型债还是数据债？①提示词只有一个人看得懂——模型债；②样本库三个月没更新——数据债；③模型版本没锁——模型债；④标注口径不统一——数据债。
3.（角色）老板说「这季度只上新功能，不还债」，你怎么回应？——参考答案：用数据说话：「现在评测覆盖率为 0，每次改模型都裸奔（风险）；我建议每次迭代带 10% 还债工作量，只影响一个功能的上线时间，但换来全年不翻车（绑定业务指标：评测覆盖率达到 60% 再放新版本）。」

AI PRD 难定 ROI


图怎么读：为什么 AI 产品经理（PM：产品经理）很难写出 ROI（投资回报率：投入产出比）指标明确的 PRD（产品需求文档）？三个原因：①效果不确定——传统功能交付即生效（按钮加上转化率就涨——确定性），AI 功能的效果取决于模型能力（可能 70 分也可能 90 分——概率性）——ROI 是区间不是单点；②成本不确定——token（代币：AI 按量计费的单位）成本随调用量和模型选型浮动——效果和成本要一起验证；③验收口径要一起定——「什么算成功」必须和算法对齐（回复率 10% 还是 15%？按什么评测集（评估测试题）算？）——否则双方各有一套标准，扯皮。解决办法：PRD 里写「效果区间+验证计划」——预期提升 5-15%，通过 A/B 测试（对比实验：一组用新功能一组不用，比数据）验证，低于 5% 则回退或换方案（止损线）；和算法多次沟通，对的是三件事——目标（做什么模型任务）+验收（用什么评测集、及格线）+边界（做不了什么）——一次对齐不了，因为模型的「做得到/做不到」要试了才知道。收口：AI 的 ROI 是「区间+验证」，不是「单点+承诺」——确定性功能写死承诺（涨 10%），概率性功能写区间+验证计划（5-15%）——把不确定变成可验证的实验设计，就是 AI PM 的 ROI 写法。

① 一句话大白话定义
这道题问的是：为什么 AI 产品的 PRD（产品需求文档）里很难写清 ROI（投资回报率：投入产出比）？为什么还要和算法（算法工程师）多次沟通确认目标范围（做什么、做到什么程度）？
用大白话说：因为 AI 的效果是「概率」不是「确定值」——传统功能写了「涨 10%」就一定能涨（按钮加上就有反应），AI 功能写了「涨 10%」可能只涨 5% 也可能涨 15%（效果取决于模型，而模型表现要试了才知道）——所以 AI PRD 写「区间+验证」（预期 5-15%，A/B 测（对比实验）验证，低于 5% 回退），不写「单点+承诺」（保证 10%）。和算法多次沟通，是因为目标（做什么）、验收（怎么算成）、边界（做不了什么）必须一起定——模型「做不做得到」试了才知道，一次定不完。

打个比方：请人「帮你介绍对象」（AI 功能）vs 买台冰箱（传统功能）——买冰箱：说明书写「容量 500 升、制冷 24 小时」（确定值：买来就是这样——ROI 明确）；请人介绍对象：效果取决于「介绍人」（模型）——可能给你介绍 3 个（效果 70 分），也可能介绍 30 个（效果 90 分）——你能写的承诺是「介绍 5-30 个，先试一个月，少于 5 个就换介绍人」（区间+验证：不写「一定介绍 15 个」——因为效果取决于人，试了才知道）。而且要多和介绍人沟通：你要求什么（目标）、怎么算介绍得好（验收：见面几次算成功）、他做不到什么（边界：不介绍离过婚的？）——一次说不清，要反复对（他的「做得到做不到」要试了才知道）。

30 秒电梯版：「为什么 AI PRD 写不清 ROI（投资回报率）？三个原因：第一，效果不确定——传统功能交付即生效（按钮加上转化率就涨），AI 功能的效果取决于模型能力（可能 70 分也可能 90 分）——ROI 是区间不是单点；第二，成本不确定——token（代币，按量计费的单位）成本随调用量和模型选型浮动——效果和成本要一起验证；第三，验收口径要一起定——『什么算成功』必须和算法对齐（回复率 10% 还是 15%？按什么评测集算？）——否则双方各有一套标准，扯皮。所以 AI PRD 的 ROI 写法是『效果区间+验证计划』：预期提升 5-15%，通过 A/B 测试（对比实验）验证，低于 5% 则回退或换方案（止损线）——把不确定变成可验证的实验设计。为什么和算法多次沟通？因为要对三件事：目标（做什么模型任务）、验收（用什么评测集、及格线多少）、边界（做不了什么）——而模型的『做得到/做不到』要试了才知道（一次评测（评估测试）给一个答案），所以要多次沟通（对齐一次不够，评测出数据再对齐）。收口：确定性功能写死承诺（涨 10%），概率性功能写区间+验证（5-15%）——这就是 AI PM 的 ROI 写法。」

② 为什么学 / 面试为什么考
「AI PRD 的 ROI 怎么写」是 AI 产品经理的核心难题，面试考它的原因有三：
第一，它考「对不确定性的处理」。AI 产品最大的特点是「效果不确定」（模型表现试了才知道）——面试官想看你懂不懂「和不确定性共处」（不是假装确定（拍脑袋写死承诺），也不是逃避（不写 ROI）——而是「区间+验证」（把不确定变成可验证的实验设计））——这是 AI 产品经理和传统产品经理的分水岭。
第二，它考「协作能力」。「和算法多次沟通确认目标范围」——考你和算法怎么对齐（目标/验收/边界三件事——不是一次对齐，是「评测出数据再对齐」的多次对齐）——面试官想看你懂不懂「和算法协作的正确姿势」（把「做得到/做不到」交给评测（数据说话），不靠拍脑袋）。
第三，它考「商业思维」。ROI（投资回报率）是商业语言（投入多少、产出多少）——面试官想看你有没有「商业思维」（产品不只讲功能，讲投入产出；AI 的投入产出是「概率性」的——会算「区间账」的人才是真产品经理）。
一句话：这道题考的是「对不确定性的处理」＋「协作能力」＋「商业思维」。

③ 原理拆解：三个原因→ROI 写法→对齐三件事

第一步：原因一——效果不确定（ROI 是区间不是单点）。传统功能的效果是「确定」的：按钮加上→转化率涨（功能实现即生效——「涨 10%」写了就能到）；AI 功能的效果取决于「模型能力」：同样一个 AI 客服，模型强（90 分：答得好、用户满意）效果就好，模型弱（70 分：答得一般、用户不满意）效果就差——而「模型强还是弱」要试了才知道（评测（评估测试）之前谁也不知道准确率是 70 还是 90）——所以 ROI（投入产出比）写不成「单点」（保证涨 10%），只能写「区间」（预期涨 5-15%——好模型 15%，一般模型 5%）。
打个比方：请家教（AI 功能）vs 买教辅书（传统功能）——教辅书（传统）：内容确定（买了就有效——「提分 10 分」写死了（书的内容固定，效果确定））；家教（AI）：效果取决于老师（模型）——好老师提 20 分，一般老师提 5 分——「请家教能提多少分」写不成「一定提 10 分」，只能写「预期提 5-20 分，看老师的水平（试了才知道）」。AI 功能同理：效果取决于模型（试了才知道），ROI 写区间不写单点。
翻车案例：有产品经理在 AI PRD 里写死承诺：「上线后回复率提升 10%」——上线后实际只提升 3%（模型效果一般）——老板按承诺考核：「为什么没到 10%？」——产品没法解释（写死了承诺，效果没到=失信）——「写死单点」翻车：AI 效果是概率（70 分还是 90 分试了才知道），写死承诺（10%）就是把自己架在火上烤——写区间（5-15%）+验证计划（A/B 测（对比实验）），才符合 AI 的现实。

第二步：原因二——成本不确定（token 成本浮动）。AI 产品的第二个「不确定」是成本：传统功能的成本是「开发成本」（写完了就固定：花多少人力就多少）；AI 功能的成本是「运行成本」（每次调用都花钱——token（代币：按量计费的单位）费用）：调用量不确定（用户多用就多花钱：今天 1000 次明天 10 万次——成本跟着调用量走）、模型选型不确定（便宜模型（效果一般）vs 贵模型（效果好）——选哪个要试了才知道效果差多少）、模型升级不确定（新模型可能更贵也可能更便宜——成本跟着市场走）——所以「ROI」里的「I」（投入：投资）也是不确定的——效果（R：回报）不确定+成本（I：投入）不确定=ROI 只能写「区间」+「验证」（效果和成本一起验证：A/B 测（对比实验）时同时看效果和成本——效果好但太贵=不划算，效果一般但便宜=划算）。
打个比方：开网约车（AI 功能）vs 开公交（传统功能）——公交（传统）：成本固定（司机工资+油费——定死的）；网约车（AI）：成本跟着「单量」走（今天 10 单油费 30 块，明天 100 单油费 200 块——成本不确定）——所以「网约车一个月赚多少」写不成固定值（单量不定、成本不定），只能写「预期月入 5000-15000，看单量（先跑一个月看数据）」。AI 的 token 成本同理：跟着调用量走，ROI 写区间+验证（效果和成本一起测）。
翻车案例：有团队算 ROI 只算效果（「回复率提升 10%」）不算成本——上线后才发现：用贵模型，每月的 token（代币）费用比省下的人工还贵——「省了人工费，多了模型费」——ROI 算反了（只算收入（效果）不算支出（成本））——「只算效果」翻车：AI 的 ROI 要「效果+成本一起算」（好模型贵，贵模型的效果值不值那个价——要验证了才知道）——成本不确定，ROI 就不能写死。

第三步：原因三——验收口径要一起定（各有一套标准就扯皮）。AI PRD 的第三个难题是「验收口径」：传统功能验收简单（按钮能不能点、功能能不能用——客观标准）；AI 功能验收难（「什么算成功」没有客观标准：回复率 10% 算成功还是 15%？准确率（答对的比率）按什么评测集（评估测试题）算？）——必须和算法「一起定」：产品定「业务口径」（回复率 10%——业务上算成功：省了人力），算法定「技术口径」（准确率 90%——技术上算成功：答对得多）——两边各定各的=扯皮（产品说「回复率没到 10% 算失败」，算法说「准确率 90% 算成功」——两套标准）——所以验收口径（什么算成功）必须「一起定」（开对齐会：产品说业务要求、算法说技术可能——一起定「回复率 10% 且准确率 90%」才算成功）。
打个比方：两人合伙开店（验收口径）——A 说「月流水 10 万算成功」（业务口径），B 说「菜品好评率 90% 算成功」（技术口径）——各算各的：流水 8 万但好评 95%——A 说「没达标」，B 说「达标了」——扯皮！一起定：「月流水 10 万且好评 90%」才算成功（两个口径合成一个标准）——AI 验收同理：业务口径（回复率）+技术口径（准确率）一起定（合成一个验收标准），不扯皮。
翻车案例：有团队验收口径各定各的——产品 PRD 写「回复率提升 10% 算成功」，算法给自己定「准确率 90% 算成功」——上线后：回复率 8%（没到产品标准）、准确率 95%（过了算法标准）——产品说「失败」（没到 10%），算法说「成功」（过了 90%）——验收扯皮一个月（两套标准）——「各定各的」翻车：AI 验收没有统一标准=扯皮（产品一个数、算法一个数）——验收口径（什么算成功）必须一起定（业务+技术合成一个标准）。

第四步：解决办法——ROI 写「区间+验证计划」。知道了三个原因，解决办法就清晰了——AI PRD 的 ROI 写法：「效果区间+验证计划」——写区间（预期提升 5-15%：不写单点（10%）——因为效果是概率（好模型 15%、一般模型 5%）——区间符合现实）；写验证计划（通过 A/B 测试（对比实验）验证：一组用 AI 功能、一组不用——比真实数据（不是「感觉有效」，是「数据验证」））；写止损线（低于 5% 则回退或换方案：效果差就回退（回到原版本）或换方案（换模型/换功能设计）——不硬扛）——「区间+验证+止损」三件套：把「不确定」（效果多少）变成「可验证的实验设计」（试了就知道）——这就是 AI PM 的 ROI 写法。
打个比方：餐厅推新品（AI 功能上线）——不写「新品一定日销 100 份」（单点承诺——效果不确定），写「预期日销 50-100 份（区间），试卖两周（验证计划：A/B——一半菜单推新品一半不推，比销量），低于 30 份就下架（止损线）」——「区间+验证+止损」：试卖数据说话（卖得好留、卖不好撤），不拍脑袋（不写死「一定 100 份」也不不敢推（不写 ROI））。AI 功能同理：写区间+验证+止损——把不确定变成「试了就知道的实验」。
翻车案例：有团队写 ROI 两极端：要么写死（「保证提升 10%」——效果没到被打脸）要么不写（「AI 功能不好说，上了看」——老板不批预算：没有 ROI 凭什么投钱）——「两极端」翻车：写死承诺=失信，不敢写=没钱——正确写法：区间（5-15%）+验证（A/B 测）+止损（低于 5% 回退）——既给老板「预期」（有数），又不承诺「保证」（符合现实）。

第五步：和算法多次沟通——对三件事，靠评测再对齐。为什么「多次沟通」（不是一次对齐）？因为要对三件事，而每件事都要「试了才知道」：目标（做什么模型任务——「把用户问题分成 5 类」：沟通一次定方向，但「分得准不准」要评测（评估测试）了才知道——评测出数据再沟通）；验收（用什么评测集（评估测试题）、及格线多少——「准确率 90%」：沟通定标准，但「评测集合不合理」要跑一版才知道——跑了再沟通）；边界（做不了什么——「不做复杂情绪安抚」：沟通定边界，但「哪些场景真的做不了」要试了才知道——试了再沟通）——所以是「多次沟通」：一次对齐是「初步共识」（方向、标准、边界先定），评测出数据后再对齐（数据说话：准确率 85%——差 5%，怎么补？补数据？调模型？改范围？——再沟通）。
打个比方：装修对方案（多次沟通）——装修公司（算法）说「这个柜子能做」（目标：初步共识），你（产品）说「好」——但「做出来什么样」要做了才知道（试了才知道）：做出来发现「柜门开合不方便」（评测出数据）——再沟通：「改合页？换拉手？改尺寸？」（再对齐）——装修不可能「一次沟通定终身」（做出来要调），AI 也一样（评测出数据要再对齐）——「多次沟通」不是低效，是 AI 协作的正确节奏（一次对齐=初步共识，数据出=再对齐）。
翻车案例：有产品经理和算法「一次沟通定目标」——「准确率 90%，就这么定了」——算法做了一版：准确率 82%（评测出了数据——差 8%）——产品说「你按 90% 做啊」，算法说「做不到了，模型就这样」——僵住（一次沟通定死，数据出来没法调）——「一次定死」翻车：AI 的「做得到/做不到」试了才知道——一次沟通定死=数据出来僵住——多次沟通（初步共识→评测出数据→再对齐）才是 AI 协作的节奏。
小结：三个原因（效果不确定/成本不确定/验收口径）→ROI 写法（区间+验证+止损）→多次沟通（目标/验收/边界三件事，评测出数据再对齐）。

④ 对比表格：AI 功能 ROI 对比 传统功能 ROI
| 维度 | 传统功能 ROI | AI 功能 ROI | |------|------|------| | 效果 | 确定（交付即生效） | 概率（70 分还是 90 分试了才知道） | | 成本 | 固定（开发成本一次投入） | 浮动（token（代币）按量计费） | | 写法 | 单点（涨 10%） | 区间（5-15%） | | 验证 | 功能测试（能用就行） | A/B 测试（对比实验）+评测 | | 止损 | 无（做了就有） | 有（低于 5% 回退或换方案） | | 验收 | 功能标准（能不能用） | 双口径（业务+技术一起定） | | 对齐 | 一次对齐（需求确认） | 多次对齐（评测出数据再对齐） | | 比喻 | 买冰箱（说明书确定） | 请家教（效果看老师） |

⑤ 3+个例子：AI PRD 的 ROI 实战
例子1：AI 客服 ROI（区间写法）。「预期效果：客服成本降低 10-20%（区间：好模型 20%、一般模型 10%）；验证计划：A/B 测试（对比实验）2 周（一半用户走 AI 客服、一半走人工——比成本和服务质量）；止损线：成本降低低于 10% 或用户满意度下降超过 5% 就回退人工；成本评估：token（代币）费用约每月 3000-8000 元（看调用量），与省下的人工费（2 人×8000 元）对比——效果和成本一起算。」
例子2：AI 摘要功能 ROI（验证计划）。「预期效果：阅读完成率提升 5-15%（区间）；验证计划：先灰度（小范围上线）20% 用户 2 周，对比阅读完成率（灰度数据说话）；止损线：提升低于 5% 或跳出率（用户中途离开的比例）上升就回退；评测口径：摘要准确率 90%（评测集（评估测试题）：100 篇长文+标准摘要——和算法对齐：准确率按这个评测集算，90% 算达标。」
例子3：AI 推荐 ROI（成本不确定）。「预期效果：点击率提升 5-15%（区间）；成本：推荐模型调用费每月约 5000 元（token（代币）费用随用户量浮动：用户涨 10 倍成本也涨 10 倍——所以 ROI 用『单用户成本』算（每 1000 次推荐花多少钱），不用总成本；验证：A/B 测试（对比实验）看点击率+单用户成本——效果好且单用户成本可控才算通过。」
例子4：AI 翻译 ROI（双口径验收）。「验收口径（和算法一起定）：业务口径=翻译任务完成率 95%（用户发起的翻译 95% 有结果）+技术口径=翻译准确率 90%（按评测集（评估测试题）算：专业术语表校验）——两个口径合成一个验收标准（95% 完成率且 90% 准确率才算成功）——不扯皮（标准和算法提前对齐）。」

⑤b 补充板块：和算法对齐的「三张纸」——一次沟通带什么
和算法沟通不是空手去，带「三张纸」效率翻倍：
第一，需求纸（目标）：一页纸写清「模型要做什么」——任务（把问题分成 5 类）、输入（用户原文）、输出（分类结果）——算法一眼看懂要做什么（不带需求纸=开会现说，效率减半）。
第二，评测纸（验收）：一页纸写清「怎么算成功」——评测集（评估测试题）来源（群友真实问题抽样 1000 条）、及格线（准确率 90%）、通过流程（评测通过才上线）——算法知道验收标准（不带评测纸=验收现吵，返工加倍）。
第三，边界纸（做不了什么）：一页纸写清「哪些不算目标」——不做复杂情绪安抚、不做多轮长对话——算法知道范围（不带边界纸=做歪返工，周期加倍）。
一句话：三张纸——需求纸（目标）、评测纸（验收）、边界纸（范围）——一次沟通带三张纸，和算法对齐又快又准（目标清、标准清、范围清）。

⑤c 补充板块：ROI 写「区间」的具体格式模板
AI PRD 里 ROI 怎么写（照着填）：
第一，效果区间：「预期【指标】提升【下限】-【上限】%」——如「预期回复率提升 5-15%」——区间两头都要写理由（下限理由：模型最差情况（评测（评估测试）最差得分）；上限理由：模型最好情况（评测最好得分））。
第二，验证方式：「通过 A/B 测试（对比实验）验证，周期 X 周，样本 Y 组」——如「A/B 测 2 周，50% 用户灰度」——验证方式写死（不写=效果没依据）。
第三，止损线：「低于【下限】则【回退/换方案】」——如「低于 5% 回退人工客服」——止损线写死（不写=效果差也硬扛）。
第四，成本口径：「成本按【单用户/单次】计，约【金额】」——如「单次调用 0.05 元，月调用 10 万次约 5000 元」——成本算清（不算=ROI 没有分母）。
一句话：ROI 四段模板——效果区间（下限+上限）、验证方式（A/B 测）、止损线（低于就回退）、成本口径（单次/单用户）——四段填全，AI PRD 的 ROI 才完整。

⑥ 常见误区（3个）
误区1：「AI 的 ROI 写不了，干脆不写。」错！不写 ROI=老板不批预算（没有投入产出凭什么投钱）——写「区间+验证」（预期 5-15%+A/B 测（对比实验））就是合格的 ROI（不写单点不是不写 ROI——区间+验证就是 AI 的 ROI 写法）。
误区2：「和算法沟通一次就够（目标说清就行）。」错！模型「做得到/做不到」试了才知道（一次对齐是初步共识，评测（评估测试）出数据要再对齐）——多次沟通（初步共识→评测数据→再对齐）是 AI 协作的节奏，不是低效。
误区3：「验收标准产品自己定就行（算法照着做）。」错！验收是「双口径」（业务口径（回复率）+技术口径（准确率））——产品自己定=算法不认（「准确率怎么算你说了算？」）——和算法一起定（业务+技术合成一个标准），才不扯皮。

⑦ 第一人称面试回答（3年景观设计→自学转行 AI 产品）
「我 3 年景观设计，被裁后自学转行——ROI 写不清（效果不确定），我做景观设计时有体会：给甲方报预算（传统）：材料费、人工费都是确定价（报 10 万就是 10 万——单点）；但遇到「效果不确定」的项目（比如「要做出高级感」——效果取决于设计水平，做了才知道）：我不能写死「保证满意」，只能写「预期效果 80-90 分（区间），先出效果图（验证计划：先看效果图再施工），效果不满意就改方案（止损线）」——这和 AI 的 ROI 一模一样（效果是概率不是确定值）。转行学 AI 产品后我还会自己跑数据：我用 AI 工具统计 942 道题的字数时，同样的任务换个模型（模型选型）结果差很多（有的准有的偏）——效果和成本（token（代币）费用）都要试了才知道——所以回答这道题：三个原因（效果不确定/成本不确定/验收口径）+解法（写区间+验证+止损）+和算法多次沟通（目标/验收/边界三件事，评测出数据再对齐）。我没有大厂 ROI 经验，但『给甲方报效果不确定的预算』和『自己换模型测字数』都证明：我懂『效果是概率，ROI 写区间』。」

⑧ 小结口诀
「三个不确定（效果/成本/验收口径），一个写法（区间+验证+止损），多次对齐（目标/验收/边界，评测出数据再对齐）——AI 的 ROI：不写死承诺，写可验证的实验。」

⑨ 三轮追问（面试官深挖）
追问1：「区间（5-15%）怎么来的？会不会拍脑袋？」「区间的下限和上限都有依据：下限=模型最差情况的评测（评估测试）结果（先做一版『最差模型』的快速评测（用已有模型+现成数据跑一版，看最差得分）——下限来自真实数据）；上限=行业基准+模型最好情况（同类产品的公开数据、模型厂商的基准测试（标准测试成绩）——上限也有依据）——区间不是拍的：下限有数据（最差评测）、上限有数据（最好评测+行业基准）。」
追问2：「算法说『做不到 90%』，你怎么判断他说得对不对？」「不凭嘴判断，靠评测（评估测试）：让算法给出『为什么做不到』的证据链——①评测集（评估测试题）对不对（评测集太偏？标准题选得不代表真实场景？——先查评测）；②瓶颈在哪（数据不够？模型能力不够？还是任务定义太难？——分环节定位）；③换个做法行不行（换模型？缩小任务范围？调整提示词（给模型下指令的话）？——试替代方案）——三步走：查评测（尺子对不对）→找瓶颈（哪个环节）→试替代（换方案）——用证据判断，不靠感觉信不信。」
追问3：「老板非要写死承诺（保证 10%），怎么办？」「不硬顶，写『双轨承诺』：对老板的承诺轨（时间+流程：X 月上线、A/B 测（对比实验）验证、验证结果透明汇报——承诺『过程』不承诺『数字』）；对效果的预期轨（区间 5-15%+止损线：效果低于 5% 回退——给老板预期管理的台阶）——老板要的是『确定性』（不是数字，是「有数」）：双轨承诺给足确定性（时间确定、流程确定、结果透明），数字不写死（效果是概率，写死了就是埋雷）。」

⑩ 进阶加分点（说出口就加分）
加分点1：把 ROI 写成「三区间」。「我的 ROI 写三个区间：效果区间（5-15%）、成本区间（每月 3000-8000 元）、时间区间（2-4 周验证）——三个区间合起来才是完整 ROI（效果×成本×时间——只写效果区间不完整）」——「三区间」说明你想得全（ROI 不是一个数，是三组数）。
加分点2：引入「价值下限」概念。「AI PRD 里我写『价值下限』：效果低于 X 就『不值得做』（不是低于 X 就回退——回退只是止损，价值下限是『这个功能的投入产出底线』：成本 5000/月，至少要省回 5000 的人力——低于价值下限，功能本身就不该存在）」——「价值下限」是高级概念（止损线之上还有价值线）。
加分点3：把「多次沟通」结构化。「和算法的多次沟通我定节奏：第一次（需求对齐：目标/验收/边界三张纸）、第二次（评测对齐：首版评测（评估测试）数据出来——达标？差多少？怎么补）、第三次（上线对齐：灰度（小范围上线）数据出来——是否全量）——三次对齐对应三个数据点（首版评测、灰度数据、全量决策）——多次沟通不是『反复扯皮』，是『数据驱动的三次对齐』。」——「三次对齐对应三个数据点」说明你的多次沟通有结构、有节奏。

⑪ 话术库（直接抄着说）
「AI PRD 写不清 ROI 三个原因：效果不确定（70 还是 90 分试了才知道）、成本不确定（token（代币）费用浮动）、验收口径要一起定。」
「AI 的 ROI 写法：效果区间（5-15%）+验证计划（A/B 测（对比实验））+止损线（低于 5% 回退）。」
「和算法对齐三件事：目标（做什么）、验收（评测集+及格线）、边界（做不了什么）——评测出数据再对齐。」
「确定性功能写死承诺（涨 10%），概率性功能写区间+验证（5-15%）——把不确定变成可验证的实验设计。」
「ROI 四段模板：效果区间、验证方式、止损线、成本口径——四段填全才完整。」

⑫ 小白 Q&A（可能踩的坑）
Q1：写「区间 5-15%」老板会不会觉得我不专业（不敢承诺）？不会——写「区间+理由」就是专业（下限有数据（最差评测（评估测试））、上限有数据（最好评测）——你带数据的区间，比拍脑袋的单点专业 10 倍）；反而「保证 10%」不专业（效果是概率，保证就是埋雷）。
Q2：和算法沟通，产品不懂技术会不会被忽悠？不懂算法细节没关系，守住「三张纸」（需求纸：做什么；评测纸：怎么算成功；边界纸：做不了什么）——技术细节算法负责，验收标准（评测集+及格线）你负责——守标准不守技术，就不被忽悠。
Q3：A/B 测试（对比实验）不会做怎么办？A/B 测试不用自己跑（技术实现是工程的事），你负责「实验设计」：测什么（效果指标）、怎么分（一半一半）、测多久（2 周）、怎么判断（效果差多少算过）——实验设计是产品的活，跑实验是工程的活。

⑬ 没人告诉你的事（面试潜规则）
这道题面试官真正在听的是「你敢不敢承认不确定」——80% 的候选人会硬写 ROI（拍脑袋承诺「涨 10%」——假装确定），你说「AI 效果是概率，我写区间+验证」（承认不确定+给解法）——当场立住（面试官自己也被 ROI 折磨过，最懂「敢承认不确定的人」是真做过）。另一个潜规则：这道题的亮点是「多次沟通」——大部分人会答「和算法对齐目标」（一次），你多说「评测出数据再对齐」（多次——因为做得到做不到要试了才知道）——说明你懂 AI 开发的真实节奏（数据驱动，不是文档驱动）。还有一个：用「给甲方报效果不确定的预算」讲 ROI 区间，比背「效果区间+验证计划」动人十倍——你的真实经历（景观设计的效果不确定性）就是最稀缺的素材。

⑭ 做一件事（学完就动手）
今天给你手头「效果不确定」的一件事（学技能效果好不好、副业赚不赚钱、AI 工具选哪个——都行）写一份「ROI 区间表」：①效果区间（预期效果下限-上限+各自理由）；②验证方式（怎么试——试多久、对比什么）；③止损线（低于什么就换/停）；④成本口径（投入多少钱/多少时间）——写完后你会发现：效果不确定的事，也能「心里有数」（区间+验证，就是不慌）。

⑮ 求职助手联系（面试前必做）
面试前用本卡做 3 件事：①把「三原因+区间写法+多次对齐」练熟（面试框架）；②准备你的「效果不确定」案例（给甲方报预算/自己换模型测字数——真实经历）；③把「确定性写死承诺，概率性写区间+验证」练熟（收口金句）。面试被问「AI PRD 难定 ROI」时：先说三原因（效果/成本/验收）→再说解法（区间+验证+止损）→收口（多次对齐三件事）——原因清+解法实+金句收口，面试官立刻记住你。

⑯ 练习（自己测一遍）
1.（判断）AI PRD 的 ROI 正确写法是？A 保证回复率提升 10%；B 预期提升 5-15%，A/B 测（对比实验）验证，低于 5% 回退——答案：B。
2.（对齐）和算法沟通要对哪三件事？——答案：目标（做什么）、验收（评测集+及格线）、边界（做不了什么）。
3.（角色）老板问「AI 功能的 ROI 到底多少」，你怎么回答？——参考答案：「三个数：效果区间（预期 5-15%，下限来自最差模型评测、上限来自行业基准）、成本区间（token（代币）费用每月 3000-8000 元）、验证计划（A/B 测 2 周，低于 5% 回退）——效果是概率不是确定值，我给的是可验证的区间+止损线，不是拍脑袋的保证。」

设计思维与 AI 产品


图怎么读：设计思维（Design Thinking：一套以用户为中心的创新方法）如何应用于 AI 产品（人工智能产品）的需求洞察——五步流程：①共情（用户研究：观察/访谈——AI 产品这里多一步：观察「人和 AI 协作」的过程——卡点往往在「人的预期」和「模型行为」不匹配（人以为 AI 懂，AI 理解偏了））；②定义（把洞察变成问题陈述——AI 产品要定义「模型要做对什么」（不是只定义产品要做什么））；③构思（发散方案——AI 产品考虑「规则/小模型/大模型/人工」四种解法组合（不是只一种））；④原型（快速验证——AI 产品用提示词原型（Prompt 原型：用提示词（给模型下指令的话）快速做出假功能）、假后端（Wizard of Oz（奥兹巫师：人工假装系统在工作——用户以为在用 AI，其实是人手动响应））验证）；⑤测试（真实用户验证——AI 产品重点测「模型输出变化时用户反应」（模型答好/答坏用户怎么反应——信任怎么变））。关键认知：设计思维给 AI 产品的增量是——把「模型能力」也当作用户体验的输入来设计（共情时共情的是「人+AI 的组合」，不是只共情人）。收口：五步流程不变，变的是「每一步里 AI 的增量」——共情看人+AI、定义写模型要做对什么、构思四解法、原型用提示词/假后端、测试测输出变化反应。

① 一句话大白话定义
这道题问的是：设计思维（Design Thinking：以用户为中心的创新方法——先理解用户再设计方案）怎么用在 AI 产品（人工智能产品）的需求洞察（发现用户真正要什么）上？
用大白话说：设计思维五步（共情、定义、构思、原型、测试）流程不变，AI 产品变在「每一步里加 AI 的料」：共情时观察「人和 AI 一起干活」（卡点在人的预期和模型行为不匹配）；定义时写清「模型要做对什么」；构思时想「规则/小模型/大模型/人工」四种解法；原型时用提示词（给模型下指令的话）快速做假功能（假后端（人工假装 AI））；测试时重点看「模型输出变化时用户什么反应」。一句话：把「模型能力」也当作用户体验的输入来设计——共情的是「人+AI 的组合」。

打个比方：设计一把椅子（传统设计思维）vs 设计「一个会说话的椅子」（AI 产品）——传统五步：共情（观察人怎么坐）、定义（椅子要舒服）、构思（几种椅型）、原型（做个小样）、测试（人坐坐看）；AI 版五步：共情（观察「人+会说话的椅子」一起用——人跟椅子说话，椅子听岔了（模型理解偏）——卡点在「人以为椅子懂、椅子没听懂」）；定义（椅子要听懂什么、答对什么）；构思（怎么让椅子听懂：装按钮（规则）、装简单芯片（小模型）、接大模型、配个人藏在后面（人工）——四种解法）；原型（用「假椅子+人躲在后面回话」（假后端：奥兹巫师（人工假装 AI））——先试「人愿不愿意跟椅子说话」）；测试（椅子答好/答坏时，人什么反应——答对了惊喜、答错了翻白眼（信任变化））。五步没变，每一步都加了「AI 的料」——这就是设计思维×AI 产品。

30 秒电梯版：「设计思维五步——共情、定义、构思、原型、测试——流程不变，AI 产品变在每一步的增量：①共情（用户研究：观察/访谈）——AI 产品多一步：观察『人和 AI 协作』的过程——卡点往往在人的预期和模型行为不匹配（人以为 AI 懂，AI 理解偏了）；②定义（洞察→问题陈述）——AI 产品要定义『模型要做对什么』（不只定义产品做什么）；③构思（发散方案）——AI 产品考虑『规则/小模型/大模型/人工』四种解法组合（不是只一种）；④原型（快速验证）——AI 产品用提示词原型（Prompt 原型：用提示词快速做出假功能）+假后端（Wizard of Oz（奥兹巫师：人工假装系统——用户以为在用 AI，其实是人响应））验证；⑤测试（真实用户验证）——AI 产品重点测『模型输出变化时用户反应』（答好答坏，用户信任怎么变）。关键认知：设计思维给 AI 的增量是——把『模型能力』也当作用户体验的输入来设计：共情时共情的是『人+AI 的组合』，不是只共情人——五步不变，变的是每一步里 AI 的增量。」

② 为什么学 / 面试为什么考
设计思维是产品经理的方法论基础，面试考它的原因有三：
第一，它考「方法论的底层」。设计思维（以用户为中心）是产品经理的第一方法论（所有需求洞察的源头）——面试官想看你懂不懂「需求洞察的正确姿势」（先共情用户再设计方案，不是拍脑袋）——这是产品经理的基本功（没有共情，方案都是自嗨）。
第二，它考「AI 增量认知」。设计思维是老的（几十年），AI 产品是新的——面试官想看你懂不懂「老方法×新产品的增量在哪」（五步流程不变，每一步加什么 AI 的料——共情看人+AI、原型用提示词（给模型下指令的话）、测试测输出变化）——「旧方法论×新技术」的迁移能力是 AI 产品经理的核心能力。
第三，它考「工具组合思维」。构思阶段 AI 产品要选「规则/小模型/大模型/人工」四种解法——面试官想看你懂不懂「解法不是只有大模型」（最合适的解法可能是规则或人工——大模型不是万能锤子）——工具组合思维（什么场景用什么解法）是高级产品经理的标志。
一句话：这道题考的是「方法论的底层」＋「AI 增量认知」＋「工具组合思维」。

③ 原理拆解：五步流程→每步 AI 增量→关键认知

第一步：共情——AI 产品多观察「人+AI 协作」。共情（同理心：站在用户角度理解他的感受和需求）是设计思维的第一步——传统做法：观察用户（看用户怎么用产品）、访谈用户（问用户要什么）——AI 产品的增量：多观察「人和 AI 协作」的过程（用户怎么和 AI 对话、怎么调整问题、怎么放弃）——为什么：AI 产品的卡点往往不在「人不会用」，在「人的预期和模型行为不匹配」（人以为 AI 懂他的意思（预期），AI 理解偏了（行为）——卡点就在这个「不匹配」——观察「人+AI 协作」，才能发现这个不匹配（用户问了三遍「我说的是不是不够清楚」——预期和行为的裂缝出来了）。
打个比方：观察外卖小哥（共情）——传统：观察小哥怎么骑车（用户行为）；AI 版（小哥配了 AI 导航耳机）：观察「小哥+耳机」一起干活（协作）——发现卡点：耳机说「前方 300 米左转」，小哥听成「右转」（人的预期：耳机应该懂我、模型行为：播报模糊——预期和行为不匹配）——只观察小哥（传统）发现不了这个卡点，观察「小哥+耳机」才发现（AI 增量：共情「人+AI 的组合」）。
翻车案例：有团队做 AI 客服，只访谈用户「你希望客服怎么回答」（传统共情——只共情人）——用户说「希望快点回答」（预期）——团队做出来的客服「答得快但听不懂人话」（模型行为：理解偏）——用户更气（「快是快，全是废话」）——「只共情人」翻车：AI 产品的卡点在「人+AI 协作」（预期和模型行为不匹配）——共情要观察「人+AI 的组合」（用户怎么和 AI 对话、卡在哪），不是只问用户「你要什么」（他说的预期，模型做不到——共情组合，才能看到裂缝）。

第二步：定义——AI 产品要定义「模型要做对什么」。定义（把洞察变成问题陈述）是第二步——传统做法：定义「产品要做什么」（洞察：用户觉得找东西麻烦→问题陈述：产品要做一个更好的搜索）；AI 产品的增量：定义「模型要做对什么」（不只是产品做什么——产品要搜索，但「模型要做对什么」：要理解用户查的是「找朋友」还是「找工作」——意图识别要对；定义「模型做对」的标准：识别准确率（答对的比率）多少算对）——为什么：AI 产品的效果取决于模型「做对」（模型理解对了，产品才有用；模型理解偏了，产品做得再好也没用）——所以定义阶段就要写「模型要做对什么」（模型的 KPI（关键绩效指标）：识别准确率 90%）。
打个比方：开一家「会翻译的奶茶店」（AI 产品）——定义阶段：传统只定义「产品做什么」（奶茶店卖奶茶——菜单、价格、店面）；AI 版多定义「翻译模型要做对什么」（外国顾客说「少糖」→模型要翻成「低糖度」——翻译要做对：翻准糖度（做对糖度理解）、翻准口味（做对口味表达）——模型做对的标准：翻译准确率 90%）——只定义「卖奶茶」（产品）不定义「翻译要做对什么」（模型），翻译翻错了（把「少糖」翻成「多糖」）——奶茶店生意再好也砸（模型做对，是 AI 产品的定义核心）。
翻车案例：有团队定义阶段只写「产品要做什么」（AI 摘要功能：产品要提供摘要入口）——没写「模型要做对什么」（摘要要做对什么：保留关键信息？不添油加醋？）——开发时模型「摘要」做得像「复述」（没做对：关键信息没保留、加了原文没有的细节）——产品功能齐全但模型没做对（摘要没用）——「只定义产品」翻车：AI 产品的定义必须写「模型要做对什么」（模型做对的标准：保留关键信息率 95%）——定义「模型做对」，产品才做对。

第三步：构思——AI 产品考虑四种解法组合。构思（发散方案：头脑风暴，想出很多可能）是第三步——传统做法：发散产品方案（几种界面、几种流程）；AI 产品的增量：解法不只一种——四种解法组合：规则（写死规则：关键词匹配（「发票」→给发票流程）——便宜、可控、但只能覆盖预设场景）、小模型（轻量模型：分类、抽取——便宜、快、但能力有限）、大模型（大语言模型（能理解对话的模型）——贵、慢、但理解力强）、人工（真人服务——最贵、但最懂）——构思时把四种解法排列组合（大部分 AI 功能是「组合拳」：大模型理解+规则兜底+人工兜底——不是只选一种）。
打个比方：开「智能客服店」（构思）——解法四种：①贴纸条（规则：贴上常见问题答案——顾客自己看（便宜但覆盖有限））；②招个实习店员（小模型：答常见问题（便宜、快、能力有限））；③请个金牌店员（大模型：什么都能聊（贵、但理解力强））；④老板亲自上（人工：最贵、最懂）——聪明店主的构思：不是「只请金牌店员」（只选大模型），是「组合拳」：实习店员答常见问题（小模型）＋金牌店员答难的（大模型）＋老板兜底投诉（人工）＋常见问题贴纸条（规则）——AI 构思同理：四种解法组合，不是只选一种。
翻车案例：有团队构思阶段只考虑一种解法：「全部用大模型」——常见问题（「怎么开发票」）也用大模型（贵、慢——杀鸡用牛刀）；结果：成本高（每次调用都花钱）＋响应慢（大模型生成要几秒）——「只选大模型」翻车：解法选择跟着场景走（常见问题用规则（便宜快）、难问题用大模型（理解强）、兜底用人工）——四种解法组合，成本低效果好（只选一种=要么贵要么蠢）。

第四步：原型——AI 产品用提示词原型+假后端。原型（快速做个小样验证想法）是第四步——传统做法：画原型图（低保真（粗糙但能看出结构）草图、可点击的假界面——验证「界面和流程」）；AI 产品的增量：两种 AI 原型：提示词原型（Prompt 原型：用提示词（给模型下指令的话）快速做出「假功能」——写一段提示词让模型扮演你的功能（「你是客服，用户问发票怎么开，你回答」）——不写代码，2 小时做出功能原型——验证「这个功能靠模型能不能做出来」）；假后端（Wizard of Oz（奥兹巫师：人工假装系统）——界面是真的，但「AI」是人工假装（用户以为在跟 AI 对话，其实是产品经理手动回复）——验证「用户对 AI 功能的真实反应」——不依赖模型，先验证需求（用户要的是「功能效果」，不是「是不是 AI」）。
打个比方：试菜（原型）——传统原型：画个菜单图（画图：验证菜品名称和价格看着行不行）；AI 原型两种：提示词原型（先让「邻居大厨」按你的配方做一道（用提示词让模型扮演功能）——试味道（验证配方行不行——2 小时出菜，不装修店面）；假后端（店里菜单是真的，但「厨师」是家人冒充的（人工假装 AI）——顾客以为吃的是大厨做的（验证「这道菜顾客买不买账」——不请大厨，先验需求）。AI 原型同理：提示词原型（验证模型能不能做）、假后端（验证用户要不要）——两种原型，又快又省。
翻车案例：有团队原型阶段「一步到位」——直接开发真功能（不做提示词原型、不做假后端（奥兹巫师））——开发 2 个月上线，发现「模型效果不行」（没做提示词原型：先试提示词（给模型下指令的话）就知道模型行不行——现在白开发 2 个月）＋「用户根本不用」（没做假后端：先人工假装（假后端）就知道用户要不要——现在功能没人用）——「一步到位」翻车：AI 原型两种（提示词原型验证模型、假后端验证需求）——跳过原型=风险加倍（模型不行+需求没人要——两个坑一起踩）。

第五步：测试——AI 产品重点测「模型输出变化时用户反应」。测试（真实用户验证）是最后一步——传统做法：真实用户用原型（测试「界面好不好用、流程顺不顺」）；AI 产品的增量：重点测「模型输出变化时用户反应」——模型输出会变（同一个问题，模型这次答好、下次答差（概率性））——测的不是「一次好用」，是「输出变化时用户的反应」：答对时（用户信任：哇，好聪明）、答错时（用户什么反应：理解？投诉？放弃？）、答错频率多高用户会流失（信任的临界点：错 1 次没事、错 3 次投诉、错 5 次卸载）——测试目标是「找到信任临界点」（模型差到什么程度，用户就不用了——产品要在临界点之前兜底（规则/降级/人工））。
打个比方：试菜（测试）——传统测试：顾客吃一次（好吃不好吃——一次性评价）；AI 版测试：顾客吃三次（第一次好吃（模型答对——信任 +1）、第二次难吃（模型答错——信任 -1）、第三次又难吃（信任 -2——顾客下次不来了））——测的不是「一次好不好吃」，是「连续三次里难吃几次顾客就不来了」（信任临界点：错 2 次流失）——AI 测试同理：测「模型输出变化时用户反应」，找到信任临界点（差到什么程度流失——产品在临界点前兜底）。
翻车案例：有团队测试只测「一次好用」——找 10 个用户各用一次，8 个说好用（测试通过）——上线后：用户天天用，模型时好时坏（答对 3 次答错 1 次）——一周后用户流失一半（「时好时坏最伤信任」——一次测试看不到，连续使用才发现）——「只测一次」翻车：AI 产品是「天天用」的产品（模型输出天天在变）——测试要测「输出变化时的反应」（答错频率和信任的临界点），不是测「一次好用」（时好时坏=信任流失）。

第六步：关键认知——把「模型能力」当作用户体验的输入来设计。全流程的收口认知：设计思维给 AI 产品的增量是——把「模型能力」也当作用户体验的输入来设计（传统设计思维：用户体验=界面+流程（人的体验由产品设计决定）；AI 产品：用户体验=界面+流程+模型能力（人的体验由模型输出决定——模型答得好体验就好、答得差体验就差）——所以设计时要「把模型能力当输入」：设计「模型答好时的体验」（答对时怎么展示、怎么加强信任）和「模型答差时的体验」（答错时怎么兜底、怎么止损）——两个体验都要设计（不只设计「好时候」，也设计「坏时候」）。
打个比方：餐厅设计（把厨师能力当输入）——传统餐厅设计：装修+菜单（界面+流程）；AI 版（把厨师能力当输入）：除了装修菜单，还要设计「厨师发挥好时的体验」（好吃时：怎么让顾客记住）和「厨师发挥差时的体验」（难吃时：怎么补救（重做/免单）——两个体验都设计，餐厅才稳）——AI 产品同理：模型输出是「输入」（天天在变）——设计「答好时体验」+「答差时体验」，才是完整的 AI 用户体验设计。
翻车案例：有团队只设计「模型答好时的体验」——「AI 答得好时展示流畅动画、加分」——没设计「答差时」——上线后模型答差（必然：概率性（不是如果，是时候））——产品直接展示错误答案（没有兜底设计）——用户看到「AI 一本正经说错话」（信任崩）——「只设计好时候」翻车：AI 产品的模型输出是「输入」（时好时坏是常态）——设计要「把模型能力当输入」：答好时（加分体验）+答差时（兜底体验）——两个都设计，信任才稳。
小结：五步流程（共情/定义/构思/原型/测试）+每步 AI 增量（共情看人+AI、定义模型做对什么、构思四解法、原型提示词/假后端、测试输出变化反应）+关键认知（把模型能力当作用户体验的输入）。

④ 对比表格：传统设计思维 对比 AI 版设计思维
| 步骤 | 传统版 | AI 版（增量） | |------|------|------| | ①共情 | 观察用户怎么用产品 | 观察「人+AI 协作」（预期和模型行为不匹配） | | ②定义 | 产品要做什么 | 模型要做对什么（模型 KPI（关键指标）） | | ③构思 | 产品方案（界面/流程） | 四种解法组合（规则/小模型/大模型/人工） | | ④原型 | 画原型图（界面流程） | 提示词原型（Prompt 原型）+假后端（奥兹巫师） | | ⑤测试 | 测界面好不好用 | 测「模型输出变化时用户反应」（信任临界点） | | 体验设计 | 界面+流程 | 界面+流程+模型能力（答好答差都设计） | | 共情对象 | 人 | 人+AI 的组合 |

⑤ 3+个例子：设计思维×AI 实战
例子1：AI 简历助手（共情增量）。共情：不只访谈求职者「你要什么」，观察「求职者+AI 简历助手」协作——发现卡点：求职者说「帮我优化这段」，AI 把「优化」理解成「重写」（预期：微调措辞；行为：大改内容——预期和行为不匹配）——定义：模型要做对「区分微调/重写」（理解「优化」的两种意图）——构思：规则（关键词「微调/精简」→微调模式）+大模型（理解复杂指令）+人工兜底（重要简历人工审）——原型：提示词原型（「你是简历助手，用户说优化时保留原意」——2 小时试效果）——测试：测「AI 大改内容时用户反应」（发现：改 2 次以上用户就自己改回原文——信任临界点）。
例子2：AI 学习助手（构思四解法）。构思：学员问题分四类——常见题（「怎么背单词」）用规则（关键词匹配给标准答案——便宜快）；分类题（「这是名词还是动词」）用小模型（轻量分类——快）；开放题（「帮我规划学习计划」）用大模型（理解力强——贵）；情绪题（「我学不会好焦虑」）用人工（辅导员回应——最贵但最懂）——四解法组合，成本最优（不是全部大模型）。
例子3：AI 客服（原型两种）。原型阶段：①提示词原型——写提示词（给模型下指令的话）「你是客服，用户问退换货你回答」——试模型效果（发现：模型对「退货运费」理解不准——补提示词/补规则）；②假后端（奥兹巫师（人工假装 AI））——界面是真的，客服是产品经理手动回复——试用户反应（发现：用户愿意用 AI 客服——需求真实）——两种原型都过了再开发（模型行+需求真=开发）。
例子4：AI 翻译（测试输出变化）。测试：找 10 个用户各翻 5 句（不是各 1 句——测「输出变化」）——发现：翻错 1 句时用户理解（自己改）、翻错 2 句时用户皱眉（信任下降）、翻错 3 句时用户放弃用 AI（信任临界点：错 3 句流失）——产品设计：在临界点前兜底（翻错 2 次后提示「人工校对」）——信任临界点=兜底触发点。

⑤b 补充板块：「提示词原型」怎么做——三步出原型
提示词原型（Prompt 原型：用提示词快速做假功能）是 AI 原型的关键，三步：
第一，写角色（设定）：给模型设定角色和规则——「你是客服，只回答退换货问题，其他问题说『已转人工』」（角色+边界——模型按角色走）。
第二，给样例（示范）：给 3-5 个问答样例——「用户问：退货要运费吗？答：要看商品类目……」（样例让模型「学会」你的规则——光说不练，模型照着样例做）。
第三，跑场景（验证）：拿 10 个真实问题试——「退货运费、发票、发货时间……」——看答得怎么样（哪些对、哪些偏——偏的改提示词/加规则）——三步出原型：角色+样例+跑场景——2 小时做出功能原型（比开发快 20 倍）。
一句话：提示词原型三步——写角色（设定）、给样例（示范）、跑场景（验证）——2 小时做出 AI 功能原型，验证「模型行不行」不用等开发。

⑤c 补充板块：构思的「解法评估表」——四种解法怎么选
构思时四种解法（规则/小模型/大模型/人工）怎么选——评估表五个维度：
第一，成本：规则（几乎免费）、小模型（便宜）、大模型（按量计费（用多少付多少））、人工（最贵）——成本从低到高。
第二，效果：规则（只覆盖预设场景）、小模型（中规中矩）、大模型（理解力强）、人工（最懂）——效果从低到高。
第三，速度：规则（毫秒级）、小模型（快）、大模型（秒级——生成要时间）、人工（看人手）——速度有差别。
第四，可控性：规则（完全可控）、小模型（可控）、大模型（输出不稳定）、人工（看人）——可控性不同。
第五，组合判断：高频简单场景（规则/小模型——便宜快）、低频复杂场景（大模型——贵但懂）、兜底场景（人工——最稳）——四种解法组合用（不是单选）。
一句话：解法评估五维——成本/效果/速度/可控性/组合判断——评估表过一遍，四种解法怎么组合一目了然（高频简单用便宜、低频复杂用懂、兜底用人工）。

⑥ 常见误区（3个）
误区1：「设计思维是传统方法，AI 时代过时了。」错！设计思维（以用户为中心）在 AI 时代更重要（AI 让产品复杂，用户更需要被理解）——过时的不是方法，是「不用方法」（拍脑袋做 AI 功能=自嗨）——五步流程不变，加 AI 增量（共情看人+AI、原型用提示词（给模型下指令的话））。
误区2：「构思就是选一个模型（大模型最强就用大模型）。」错！构思是「四种解法组合」（规则/小模型/大模型/人工——高频简单用规则、复杂用大模型、兜底用人工）——只选大模型=贵+慢+不稳（杀鸡用牛刀）——解法跟着场景走（不是最强，是最合适）。
误区3：「测试就是找几个人用一下。」错！AI 测试要测「输出变化」（模型时好时坏——错 3 次流失的临界点）——只测「一次好用」=测不到信任流失（时好时坏最伤信任）——测试目标是找到「信任临界点」，在临界点前设计兜底。

⑦ 第一人称面试回答（3年景观设计→自学转行 AI 产品）
「我 3 年景观设计，被裁后自学转行——设计思维五步，我做景观设计时天天用：共情（观察居民怎么用小区花园——传统只观察人）；但后来我发现 AI 产品的增量：共情要观察『人+AI 协作』——转行后我用 AI 工具给书里 942 道题统计字数时，最大的卡点不是『我不会用工具』，是『我的预期和模型行为不匹配』（我预期 AI 准确统计，AI 理解偏了（把标题也算进字数）——预期和行为不匹配——共情『人+AI 组合』才能发现）；定义（要定义『模型要做对什么』：统计要做对『只数正文不算标题』——模型 KPI（关键指标））；构思（解法四种：规则（正则匹配（按格式匹配））、小模型（轻量处理）、大模型（理解力）、人工（自己核对——我用的是组合：脚本规则+人工抽查）；原型（提示词原型：先让 AI 扮演统计工具，试它行不行——2 小时试出效果再写脚本）；测试（测『AI 输出变化时我的反应』：统计错了 1 次我发现了（信任还在）、错了 3 次我就自己核对了（信任临界点——产品要在临界点前兜底：加抽查环节））。我没有大厂设计思维项目，但『花园设计』和『942 道题统计』都证明：我懂五步流程，也懂每一步的 AI 增量——把模型能力当作用户体验的输入来设计。」

⑧ 小结口诀
「五步不变（共情定义构思原型测试），每步加 AI 料（共情看人+AI、定义模型做对什么、构思四解法、原型提示词/假后端、测试输出变化反应）——关键：把模型能力当作用户体验的输入来设计。」

⑨ 三轮追问（面试官深挖）
追问1：「共情阶段怎么观察『人+AI 协作』（具体怎么做）？」「三种方法：①陪用户用（坐在旁边看用户用 AI 功能——看他在哪停顿、哪皱眉、哪重试（停顿/皱眉/重试=不匹配的信号）；②回看对话记录（AI 产品的对话日志——看用户怎么改问题（改 3 次=模型没听懂）、怎么放弃（说一半不说了=预期崩了））；③让用户「说出来」（边用边说想法（出声思维法（边做边说的测试方法）——他说「我以为它会懂」=预期和行为裂缝）。三个方法：陪着看（行为）+回看记录（数据）+听他说（想法）——不匹配藏不住。」
追问2：「四种解法怎么分场景（什么情况用规则什么用大模型）？」「按两维分：频率×复杂度——高频+简单（常见问题：『怎么开发票』）用规则（关键词匹配（关键词对应答案）——便宜快）；高频+复杂（用户天天问的难问题）用小模型（轻量分类——快够用）；低频+复杂（少见的难问题）用大模型（理解力强——贵但值得）；低频+简单（少见简单问题）规则覆盖不了就人工或通用回答（兜底）——分场景口诀：高频简单用规则、高频复杂用中模型、低频复杂用大模型、兜底用人工——不是选一个，是组合（每个场景选合适的）。」
追问3：「测试找到信任临界点后，产品怎么用这个点？」「临界点是兜底的『触发器』：临界点前自动兜底——比如临界点是『错 3 句流失』：产品设计『错 2 次后提示人工校对』（在临界点前 1 步触发兜底——不让用户走到流失那一步）；同时『持续监测』（上线后看实际错误率：离临界点还有多远——近临界点就加强兜底（更多人工/更多规则））；临界点不是一次测完的（模型会变：升级后临界点可能变——每季度重测）——临界点=兜底触发器+监测仪表盘（用起来，临界点才有价值）。」

⑩ 进阶加分点（说出口就加分）
加分点1：把「模型能力当输入」升级为「双体验设计」。「我的 AI 设计分两条线：『能力线』（模型答好时：怎么展示、怎么强化信任——好时候的体验）和『兜底线』（模型答差时：怎么补救、怎么止损——坏时候的体验）——两条线都画原型、都测试（不只测好时候）——双体验设计，信任才稳。」——「双体验设计」一说出口，你就懂 AI 体验的完整结构。
加分点2：引入「信任余额」概念。「我把用户对 AI 的信任当『余额』：答对一次存 1 分、答错一次扣 2 分（错的伤害大于对的收益——心理学：损失厌恶（人对损失比对收益更敏感））——产品设计的目标是『余额不归零』（答对率高+答错有补救——余额为正，用户留着；余额归零，用户卸载）」——「信任余额+损失厌恶」说明你有心理学视角（信任经济学）。
加分点3：用「灰度（小范围上线）+监测」闭环测试。「测试不只发问卷，我加『灰度+监测』：先 10% 用户上线（灰度（小范围上线试水）），监测『错误率和流失率』（数据监测：错误率 5% 流失 1%、错误率 10% 流失 5%——错误率和流失的关系曲线）——用真实数据找到『这个产品的信任临界点』（比问卷测试准 10 倍）」——「灰度+监测闭环」说明你懂 AI 产品的持续验证（真实数据说话）。

⑪ 话术库（直接抄着说）
「设计思维五步：共情、定义、构思、原型、测试——流程不变，AI 产品变在每一步的增量。」
「共情 AI 版：观察『人+AI 协作』——卡点在人的预期和模型行为不匹配。」
「定义 AI 版：不只产品要做什么，写清『模型要做对什么』（模型 KPI（关键指标））。」
「构思 AI 版：四种解法组合——规则/小模型/大模型/人工（不是只选大模型）。」
「原型 AI 版：提示词原型（Prompt 原型）+假后端（奥兹巫师（人工假装 AI））；测试 AI 版：测『模型输出变化时用户反应』（信任临界点）。」

⑫ 小白 Q&A（可能踩的坑）
Q1：设计思维听着很玄，新人怎么入门？不玄——就是「先看用户（共情）→再定问题（定义）→多想方案（构思）→快做小样（原型）→让用户试（测试）」五步——入门练法：给自己手头的小项目走一遍五步（哪怕帮群友设计一个「简历优化」功能）——走一遍就懂，不走永远觉得玄。
Q2：提示词原型（Prompt 原型）做出来的是「假功能」，怎么确认「真功能」也有效？确认分两步：提示词原型确认「模型行不行」（2 小时试出效果：答得好不好）；真功能确认「工程行不行」（开发后评测（评估测试）达标：准确率 90%）——提示词原型验证「效果」，真功能验证「工程」——两层验证，缺一不可。
Q3：小团队没人做「假后端」（奥兹巫师（人工假装 AI））怎么办？一个人就行：产品经理自己当「假 AI」（用户消息你手动回——一次回 10 个用户就够验证）——假后端不挑人（谁都能当「假 AI」），挑的是「样本」（找 10 个精准目标用户——比 100 个随便用户有用）。

⑬ 没人告诉你的事（面试潜规则）
这道题面试官真正在听的，是「你会不会用方法论」——大部分候选人背五步（共情定义构思原型测试——背书），你说「五步+每步的 AI 增量」（共情看人+AI、原型提示词（给模型下指令的话）、测试输出变化——理解+应用）——当场拉开（背方法的是学生，用方法的是产品经理）。另一个潜规则：这道题的加分点是「构思四解法」——80% 的候选人会答「用大模型」（万能锤子思维），你多说「规则/小模型/大模型/人工组合」（工具组合思维）——说明你懂「最合适的解法不是最强的」（成本意识+场景思维——这是面试官最缺的候选人品质）。还有一个：用「花园设计+942 题统计」讲设计思维，比背「五步流程」动人十倍——你的真实经历（传统方法×AI 工具的迁移）就是最稀缺的素材。

⑭ 做一件事（学完就动手）
今天给你手头一个「AI 相关的想法」（用 AI 做什么——学习/工作/副业都行）走一遍「AI 版设计思维」：①共情（观察你自己或群友「人和 AI 一起用」卡在哪）；②定义（AI 要做对什么）；③构思（四种解法里选组合）；④原型（用提示词（给模型下指令的话）2 小时做出假功能）；⑤测试（找 3 个人试，重点看「AI 答差时他们什么反应」）——走完五步，你从「想用 AI」变成「会设计 AI 产品」。

⑮ 求职助手联系（面试前必做）
面试前用本卡做 3 件事：①把「五步+每步 AI 增量」练熟（面试框架：共情看人+AI/定义模型做对什么/构思四解法/原型提示词假后端/测试输出变化）；②准备你的「设计思维」案例（花园设计/942 题统计——真实经历最动人）；③把「把模型能力当作用户体验的输入来设计」练熟（收口金句）。面试被问「设计思维×AI」时：先说五步（不变）→再说每步增量（AI 的料）→收口（把模型能力当输入）——框架完整+增量清楚+经历真实，面试官立刻记住你。

⑯ 练习（自己测一遍）
1.（排序）设计思维五步的顺序？A 共情→定义→构思→原型→测试；B 构思→原型→共情→测试→定义——答案：A。
2.（增量）AI 版「原型」和传统原型最大的差别是什么？——答案：AI 用提示词原型（Prompt 原型）+假后端（奥兹巫师（人工假装 AI））——不写代码快速验证模型和需求；传统画界面原型图。
3.（角色）面试官问「设计思维哪一步对 AI 产品最重要」，你怎么回答？——参考答案：「每一步都有 AI 增量，但原型最关键：AI 产品的两个不确定性（模型行不行、用户要不要）用提示词原型（验证模型）和假后端（验证需求）一次验证——原型阶段是 AI 产品『2 小时知道结果』和『开发 2 个月才知道』的分水岭。」

组织架构适配 AI


图怎么读：组织架构（organization structure：公司/团队怎么分工、谁听谁的）怎么调整才能适应 AI 产品（人工智能产品）开发——三个层次：①病：产品-算法两张皮——产品要效果（回复率、满意度），算法按自己的指标迭代（准确率、损失函数（衡量模型好坏的计算公式））——互相等、互相甩锅（产品说「算法不行」，算法说「需求不清」）；②三味药：第一，配小组——每个核心功能由「产品+算法+评测」固定三人组负责，共担一个指标（不是各干各的）；第二，建中台（共享平台：评测集、数据管道大家共用）——避免各小组各建一套评测集（指标口径统一：大家用同一把尺子）；第三，对齐节奏——模型迭代周期和产品发版节奏对齐（模型版本列车（模型跟着产品版本一起发，不互相等）——产品不等模型、模型不追产品）；③检验标准：组织调整成不成，只看一件事——从「产品提需求→算法排期」的交接模式（锅是对方的），变成「共同对一个指标负责」的共担模式（成了是大家的）。

① 一句话大白话定义
这道题问的是：公司团队的组织架构（谁负责什么、怎么配合）怎么调，才能让 AI 产品开发更顺？
用大白话说：AI 产品最常出的组织病是「产品-算法两张皮」（产品要效果，算法按自己的标准干，互相等、互相甩锅）——调整方向三个：配小组（产品+算法+评测固定三人组，共担一个指标）、建中台（评测集和数据大家共用、口径统一）、对齐节奏（模型版本跟着产品一起发，不互相等）。检验标准一句话：从「交接模式」（你的锅）变成「共担模式」（我们的指标）。

打个比方：餐厅后厨两张皮——点菜员（产品）给顾客承诺「20 分钟上菜」，后厨（算法）按自己的节奏炒（不排单、不看时间）——顾客投诉「我的菜呢」，点菜员说「后厨太慢」，后厨说「你催也没用，我得按顺序炒」！调整：①配小组——每个菜品由「点菜员+厨师+试菜员」固定三人负责，共担一个指标（上菜时间）；②建中台——所有菜品共用一套「备料标准」（食材、分量统一），不各做各的；③对齐节奏——厨房的出菜速度和餐厅的翻台节奏对齐（高峰期前备好半成品）。检验：以前「点菜→催菜」（交接），以后「一起对上菜时间负责」（共担）。

30 秒电梯版：「AI 产品开发最大的组织问题是『产品-算法两张皮』：产品要效果（回复率、满意度），算法按自己的指标迭代（准确率）——互相等、互相甩锅。调整方向三个：第一，配小组——每个核心功能由『产品+算法+评测』固定三人组负责，共担一个指标（不是各干各的，是一起对一个数负责）；第二，建中台——共享评测集（评估模型好坏的测试题库）和数据管道（数据搬运流程），口径统一（大家用同一把尺子，不各建一套）；第三，对齐节奏——模型迭代周期和产品发版节奏对齐（模型版本列车：模型跟着产品版本一起发，不互相等——产品不等模型、模型不追产品）。检验标准只有一个：从『产品提需求→算法排期』的交接模式（锅是对方的），变成『共同对一个指标负责』的共担模式（成了是大家的）——组织调整成不成，就看这一条。」

② 为什么学 / 面试为什么考
组织架构调整是 AI 产品落地的「地基问题」，面试考它的原因有三：
第一，它考「组织敏感度」。AI 产品做不成，一半是技术，一半是组织（产品-算法两张皮：互相等、互相甩锅）——面试官想看你懂不懂「产品问题不只在产品里，也在组织里」（会看组织，才是高级产品经理）。
第二，它考「系统思维」。组织调整不是「改个部门名字」，是「改协作方式」（谁对什么指标负责、节奏怎么对齐）——面试官想看你有没有「系统思维」（动一个环节，想全链条：指标、节奏、接口全考虑）。
第三，它考「AI 协作特有认知」。AI 产品开发里「产品-算法」协作是命门（效果和指标经常对不上：产品要满意度，算法提准确率）——面试官想看你懂不懂「AI 团队的协作模式」（三人组共担、中台统一、节奏对齐——AI 组织的三个关键词）。
一句话：这道题考的是「组织敏感度」＋「系统思维」＋「AI 协作特有认知」。

③ 原理拆解：看清病→三味药→检验标准

第一步：看清病——产品-算法两张皮。AI 产品开发最典型的组织病：产品团队和算法团队各干各的——产品要业务效果（回复率、满意度：业务指标（业务层面的衡量标准）），算法按技术指标迭代（准确率、损失函数：技术指标（模型层面的衡量标准））——两套指标对不上（产品说「回复率怎么没涨」，算法说「准确率到 90% 了」），于是互相等（产品等模型的模型排期、模型等产品的需求澄清）、互相甩锅（上线效果不好：产品说「模型不行」，算法说「需求不清」）。
打个比方：装修——设计师（产品）画了张效果图（要「好看」），施工队（算法）按自己的标准干（要「结实」）——设计师说「这墙颜色不对」，施工队说「我这墙砌得可结实了」——两个人标准不一样（好看 对比 结实），互相看不惯。产品-算法同理：指标不一样（满意度 对比 准确率），互相不认账——病根：两套指标、两套节奏、两个「我的活」——「两张皮」就是这么来的。
翻车案例：有团队产品提需求「让 AI 客服回复率提升到 30%」，算法接了排期「我们这季度提升准确率到 95%」——季度末：产品看回复率（没涨，因为准确率高≠用户爱点），算法看准确率（95%，达标）——产品说「算法没干我的活」，算法说「我干完了啊」——两张皮翻车：两套指标各说各话，谁都没错但项目废了。病根：没有「共担一个指标」（产品一个数、算法一个数，中间没人串）。

第二步：配小组——「产品+算法+评测」固定三人组，共担一个指标。第一味药：每个核心功能配一个固定小组——产品（管需求和对业务指标负责）、算法（管模型实现）、评测（管效果验证：建评测集、跑评测、报数）——三个人对「同一个指标」负责（这个功能的业务指标：回复率 30%——产品管定义、算法管实现、评测管验证——一个数，三个人一起扛）。好处：指标只有一个（没有两套数）、锅没法甩（回复率没到，三个人一起想办法：需求问题？模型问题？评测问题？——一个组内解决）。
打个比方：足球——以前是「前锋提要求、后卫自己练」（两张皮：前锋说「你传的球不行」，后卫说「你跑位不行」）；现在是「一条线三个人」（前锋+中场+后卫共担一个目标：赢球）——丢球了不互相骂，一起复盘（是传球问题还是跑位问题？）。产品-算法-评测三人组同理：共担「回复率 30%」——没到就三个人一起复盘（需求偏了？模型弱了？评测错了吗？——组内闭环，不甩锅）。
翻车案例：有团队不做三人组，产品需求直接扔给算法团队池子（需求池排队），算法按自己的优先级排（谁的活「有意思」先干谁的）——产品问「我的 AI 客服呢」，算法说「排期到下季度」——产品没法推动（需求进了池子就失去了控制权）——交接模式翻车：产品提需求→算法排期（产品只能等）。配小组（三人共担）后：产品不是「提需求的人」，是「组里的一员」——进度自己知道，问题组内解决。

第三步：建中台——共享评测集和数据管道，口径统一。第二味药：建「共享中台」（评测中台（共享的评测平台：评测集、评测流程大家共用）+数据中台（共享的数据平台：数据管道、标注标准大家共用））——所有小组用同一套评测集、同一条数据管道、同一个标注口径（标准：标什么、怎么标）——好处：指标口径统一（小组 A 说「准确率 90%」和小组 B 说「准确率 90%」是同一把尺子测的——可以横向比较）、避免重复建设（各小组各建一套评测集=重复劳动三倍）。
打个比方：学校的统一考试——以前每个班自己出题自己改（A 班 90 分、B 班 95 分没法比——卷子难度不一样）；现在全校统考（同一张卷子、同一个标准）——A 班 90 分、B 班 85 分直接可比（哪班教得好一目了然）。评测中台同理：统一评测集（同一张卷子）——小组 A 的模型 90 分、小组 B 的模型 85 分——谁好谁坏一目了然（同一把尺子）。
翻车案例：有团队不建中台，两个小组各建各的评测集——A 组说「我们的模型准确率 92%」，B 组说「我们 88%」——产品想选好的，一比才发现：A 组的评测集只有 50 条测试题（好过），B 组有 1000 条（难考）——数据不可比（尺子不一样）！而且两套评测集维护双倍人力（重复建设）。建中台后：一套评测集、一个口径——比数有意义、维护省一半。

第四步：对齐节奏——模型版本列车。第三味药：节奏对齐——模型迭代周期（模型多久改一次）和产品发版节奏（产品多久发一版）对齐——做法：「模型版本列车」（模型跟着产品版本一起发：产品每个版本（sprint（迭代周期，一般两周））发布时，模型更新跟着这个版本走）——产品不等模型（产品排期不用等「模型好了没」，模型跟着产品节奏走）、模型不追产品（模型不用「为产品赶工」，跟着版本列车走）——两边节奏一致，谁也不等谁、谁也不催谁。
打个比方：火车时刻表（版本列车）——以前：产品是「打车的人」等「高铁」（模型）——「车什么时候到？」（等模型）；现在是「地铁换乘」（产品发版=列车到站，模型更新=同车到站）——到了就换乘，不用等（对齐了：一起走）。模型版本列车同理：产品发版时模型更新同步发——没有「等模型」的等待期，也没有「模型追产品」的赶工期。
翻车案例：有团队模型和产品各排各的期——产品定好发版日，算法说「模型还要两周才能好」（产品等模型：发版延期）；或者算法催「模型好了，产品什么时候接？」（模型追产品：接不上，白训练）——节奏不齐翻车：等，是双倍的浪费（产品等=人闲着，模型等=算力空转）。版本列车对齐后：发版日=模型更新日，谁也不用等。

第五步：检验标准——从「交接」到「共担」。组织调整成不成，不看架构图画得多漂亮，看协作模式变没变：以前是「交接模式」（产品提需求→算法排期——做完交接，锅是对方的：效果不好是算法的事，延期是产品的事）；调整后是「共担模式」（共同对一个指标负责——成了是大家的，败了也是一起的：回复率没到，三个人一起复盘，不是找谁背锅）。
打个比方：接力赛 对比 拔河——接力赛（交接模式）：跑完一段把棒交给下一个人——掉棒了怪交接的人（锅是对方的）；拔河（共担模式）：所有人一起拉一根绳——输了大家一起使劲方向不对（没有「锅」，只有「一起」）。组织调整就是「从接力赛改拔河」：接力赛再流畅也有掉棒风险（交接点），拔河没有交接（共担）——检验标准：你们还在接力吗？还是已经拔河了？
翻车案例：有团队组织架构图画得很漂亮（小组、中台、版本列车全画上了），实际还是老样子：产品发需求邮件→算法回排期邮件→效果不好互相发邮件——架构图改了，协作没改（图是图，人是人）——「纸上调整」翻车：组织调整的检验不是「架构图变了没」，是「协作模式变了没」（交接→共担）。判断方法：看一次「效果不好时的会议」——是「互相解释为什么不是我的锅」（交接），还是「一起分析哪里可以更好」（共担）——一场会，验出组织真伪。
小结：看清病（两张皮）→配小组（三人共担一指标）→建中台（统一口径）→对齐节奏（版本列车）→检验（交接→共担）。

④ 对比表格：交接模式 对比 共担模式
| 维度 | 交接模式（两张皮） | 共担模式（组织调整后） | |------|------|------| | 指标 | 产品看业务数，算法看技术数 | 共同对一个指标负责 | | 节奏 | 产品等模型、模型追产品 | 版本列车（一起发） | | 评测 | 各小组各建一套（尺子不一） | 中台统一（同一把尺子） | | 效果不好时 | 互相解释「不是我的锅」 | 一起复盘「哪里能更好」 | | 组织形态 | 产品团队、算法团队分开排队 | 产品+算法+评测固定三人组 | | 比喻 | 接力赛（交接有掉棒风险） | 拔河（一起拉一根绳） | | 产品经理角色 | 提需求的人（发完邮件就失去控制） | 小组的一员（进度自己知道） | | 结果 | 项目废了没人背锅 | 指标没到组内闭环解决 |

⑤ 3+个例子：组织调整实战
例子1：AI 客服功能（配小组）。公司做 AI 客服，以前产品提需求给算法团队（需求池排队），算法按自己优先级排——产品催不动。调整：成立「客服三人组」（产品+算法+评测），共担指标「回复率 30%」——产品定义需求（回复率怎么算、答什么）、算法实现（模型、提示词（给模型下指令的话））、评测验证（建客服评测集：1000 条真实对话）——季度末一起看数：没到就一起复盘（需求偏了？模型弱了？评测错了？——组内解决）。
例子2：两个小组的模型比数（建中台）。公司两个 AI 功能（客服+推荐）各建各的评测集——客服组说准确率 92%、推荐组说 88%——没法比（尺子不同）。调整：建评测中台——统一评测集（共用 2000 条标准测试题）、统一数据管道（同一套数据清洗流程）、统一标注口径（标注规范写进文档）——两组模型放同一把尺子比（92% 和 88% 直接可比），重复维护也省一半。
例子3：模型和产品互相等（对齐节奏）。以前：产品定好 6 月发版，算法说「模型 7 月才好」（产品等模型，延期）；算法 3 月好了，产品说「这季度没排你的模型」（模型追产品，白训练）。调整：版本列车——产品每个 sprint（两周一个迭代）发一版，模型的更新跟着产品版本走（产品 v1.2 发版日=模型 v1.2 更新日）——没有「等」的环节，两边节奏一致。
例子4：效果不好时的会议（检验标准）。调整前：效果不好开会——产品说「模型能力不行」（锅给算法），算法说「需求一开始就没说清」（锅给产品）——会开完，没人认领（交接模式）。调整后：同样的会——「回复率没到 30%，我们三个人一起过一遍：需求是不是偏了？（评测报告：用户问的问题 40% 不在知识库里）模型是不是弱了？（评测：准确率 90% 但答非所问多）评测是不是漏了？（评测集覆盖不全）」——三个环节一起查（共担模式）——一场会，验出组织改没改。

⑤b 补充板块：小型团队怎么做组织调整（没有中台怎么办）
大公司有资源建中台，小团队（创业公司、5 人以下）怎么办？三个「轻量版」：
第一，没有中台，就统一「口径文档」。不建平台，但把「评测集怎么建、数据怎么标、指标怎么算」写成一份共享文档（放团队共用网盘）——所有成员照同一份文档执行——文档就是「纸面中台」（口径统一不靠平台靠规矩）。
第二，没有三人组，就「角色兼职」。人少配不起专职评测——产品兼评测（产品自己建评测集、跑评测）或算法兼评测（算法自己写测试题）——关键是「一个功能必须有一个人对指标负责」（兼职能做，指标不能没人认）。
第三，没有版本列车，就「固定发版日」。小团队不用复杂节奏——定死「每周五发版」——模型的更新必须在周四前合入（模型跟着发版日走）——固定节奏就是小团队的「版本列车」。
一句话：小型团队三件套——口径文档（纸面中台）、角色兼职（指标有人认）、固定发版日（版本列车简化版）——没有平台，规矩和节奏顶上。

⑤c 补充板块：组织调整的「阻力」——为什么架构改不动
组织调整最难的不是「设计」，是「推动」——三个典型阻力：
第一，部门墙（各管各的预算和人头）。产品团队归产品总监、算法团队归技术总监——三人组跨了两个部门，汇报线不同（听谁的？）——阻力解法：先试点（不重组整个公司，选一个核心功能做「虚拟小组」（跨部门临时组队，汇报线不变，但指标共担））——试点成功再推广。
第二，算法担心「被评测绑住」。统一评测集后，算法的 KPI（关键绩效指标）就绑定了评测分数——算法怕「评测不准反而吃亏」（标准是死的，模型是活的）——阻力解法：评测集要「共建共审」（不是产品单方面定，算法参与建评测集——尺子一起造，才服气）。
第三，管理层只看短期。组织调整前两季度可能更慢（磨合期：大家不习惯共担）——管理层看「这个季度产出」会动摇——阻力解法：调之前先讲清「先慢后快」（磨合期 2 个月，之后是双倍速度），并用「试点数据」证明（试点组的指标提升 对比 非试点组）。
一句话：组织调整三个阻力——部门墙（试点破）、算法不服（共建评测）、管理层没耐心（先慢后快+数据证明）——设计好的架构，推不动等于零。

⑥ 常见误区（3个）
误区1：「组织调整=改部门结构（加部门、换汇报线）。」错！改结构只是表面——真正的调整是「改协作」（指标共担、口径统一、节奏对齐）——结构图改了协作没改=纸上调整（检验：效果不好时的会议，是找锅还是一起复盘）。
误区2：「团队小，不用管组织。」错！小团队更容易两张皮（人少分工模糊：产品提需求、算法闷头干）——小团队用轻量版（口径文档、角色兼职、固定发版日）——组织问题不分大小，只分「管不管」。
误区3：「调整后产品就轻松了（指标算法扛）。」错！共担模式下产品更重（不是发完需求就没事，是要对指标负责：跟进评测、复盘数据、协调组内）——但重得有回报：产品对结果有控制权（以前发完邮件只能等，现在组内自己能推）。

⑦ 第一人称面试回答（3年景观设计→自学转行 AI 产品）
「我 3 年景观设计，被裁后自学转行——组织两张皮的痛，我做景观设计时就体会过：设计师（产品）画效果图，施工队（算法）按自己的标准干活——设计师要『好看』，施工队要『结实』，两套标准，互相看不惯：设计师说『这墙颜色不对』，施工队说『我这墙砌得可结实了』——项目延期、效果打折扣，就是『两张皮』。后来我们改成一件事：设计施工一体化小组（一个项目由设计师+施工员+监理固定三人组负责，共担『按时交付且甲方满意』一个目标）——改完，项目顺了，没人甩锅（都是自己组的事）。转行学 AI 产品后我发现，AI 团队的组织病一模一样：产品要效果（回复率），算法按自己指标迭代（准确率），两套指标各说各话。所以回答这道题：调整方向三个——第一，配小组（产品+算法+评测固定三人组，共担一个指标：一个数三个人一起扛）；第二，建中台（共享评测集和数据管道，口径统一：同一把尺子才能比数）；第三，对齐节奏（模型版本列车：模型跟着产品版本一起发，谁也不等谁）。检验标准：从『交接模式』（产品提需求→算法排期）变成『共担模式』（共同对一个指标负责）——我做景观设计时验证过这套：共担的小组，项目最顺。」

⑧ 小结口诀
「两张皮病（指标各管各），三味药：配小组（三人共担一指标）、建中台（尺子统一）、版本列车（节奏对齐）——检验：交接变共担，组织才真改。」

⑨ 三轮追问（面试官深挖）
追问1：「配三人组，算法人不愿意怎么办？」「先听懂算法不愿意的原因——多半是担心『共担指标=被评测绑死』（尺子不准反而吃亏）。解法两条：①共建评测集（算法参与建评测集，尺子一起造，服气）；②共担不是追责（『回复率没到 30%』不是『算法背锅』，是『三个人一起复盘需求、模型、评测三个环节』——共担的意思是共同解决，不是共同背锅）。说清楚这两条，算法愿意进组。」
追问2：「中台要多少资源？小公司建不起怎么办？」「先分清『平台』和『规矩』：建平台（独立的中台系统）确实贵（要专职人力维护）；但口径统一不一定要平台——先做『纸面中台』：评测集怎么建、数据怎么标、指标怎么算写成共享文档，所有人照同一份文档执行——口径统一了，平台后面再建。我的原则：先统一尺子（纸面也行），再谈建平台（系统化）。」
追问3：「版本列车会不会让产品被模型拖累（模型没准备好就要发）？」「版本列车的核心不是『强制发』，是『一起计划』——模型准备度在发版前就评估（评测没达标就标记『此版本模型不升级』：版本照发，模型不换）——列车的意义是『节奏可预期』（什么时候发、模型什么时候就绪，计划里都有），不是『硬发』（模型没达标也要上线）。可预期，就是价值。」

⑩ 进阶加分点（说出口就加分）
加分点1：把组织调整和「模型信任」挂钩。「组织两张皮的深层成本是模型信任（模型输出越来越不可靠，用户对产品的信任流失）——共担模式让『模型好坏』有专人每天盯着（评测在组内），信任不流失。」——组织问题挂上「信任」，层次立刻高一层。
加分点2：引入「接口长度」概念。「组织调整的本质是把『产品-模型』的接口做短：两张皮（交接模式）的接口是『需求邮件+排期回复』（又长又慢）；共担模式（三人组）的接口是『同一个指标』（最短的接口）——接口越短，协作越顺。」——「接口」是产品经理的专业词（API（应用程序接口）都讲接口），一说出口显专业。
加分点3：用「先试点再推广」落地。「组织调整我不一步到位：先选一个核心功能做『虚拟小组』（跨部门临时组队，汇报线不变，指标共担）——试点 1-2 个季度，用数据证明（试点组指标提升 对比 非试点组），管理层看到效果再全面推广。」——「先试点再推广」是推动组织变革的黄金节奏（降低阻力、数据说话）。

⑪ 话术库（直接抄着说）
「AI 产品最大的组织病是『产品-算法两张皮』：产品要效果，算法按自己的指标迭代——互相等、互相甩锅。」
「调整三个方向：配小组（产品+算法+评测共担一指标）、建中台（评测数据口径统一）、对齐节奏（模型版本列车）。」
「检验标准只有一个：从『交接模式』（产品提需求→算法排期）变成『共担模式』（共同对一个指标负责）。」
「小团队用轻量版：口径文档（纸面中台）、角色兼职（指标有人认）、固定发版日（简化版列车）。」
「组织调整推不动的原因：部门墙（试点破）、算法不服（共建评测）、管理层没耐心（先慢后快）。」

⑫ 小白 Q&A（可能踩的坑）
Q1：产品经理能推动组织调整吗（不是领导能改吗）？能——不用「改组」，「改协作」：先在自己的项目里做（给项目组配虚拟三人组、统一口径文档、定固定发版日）——从自己的一亩三分地开始，做出效果再往上推（组织调整是自下而上+自上而下结合）。
Q2：产品-算法互相甩锅，产品经理先做什么？先「建同一把尺子」：把两套指标对齐（产品要回复率、算法提准确率——找一个都能认的中间指标：比如「回复率」里算法能认的部分）——尺子对齐了，锅就没了（没了两套标准，没法甩）。
Q3：组织调整会不会让产品经理更累？会，但累得值——共担模式里产品要跟评测、跟数据、跟进度（比「发邮件等排期」累），但换来「对结果的控制权」（以前只能等，现在组内能推）——累在「负责」，不累在「焦虑」。「发邮件等结果」的累是干着急，共担的累是有进展。

⑬ 没人告诉你的事（面试潜规则）
这道题面试官真正在听的是「你有没有组织视角」——80% 的候选人只会答「加人、加部门」（结构思维），你说「配小组、建中台、对齐节奏」（协作思维）——当场拉开。另一个潜规则：这道题是「工程题」不是「设计题」——面试官不期待你给出完美的组织架构图，期待你说出「推动组织调整会遇到的阻力」（部门墙、算法不服、管理层没耐心）——你说了阻力+解法，他就知道你真推过（或者认真想过）。还有一个：用「做景观设计时的设计施工一体化」讲组织调整，比背「中台、版本列车」概念动人十倍——你的真实经历，就是最稀缺的面试素材。

⑭ 做一件事（学完就动手）
今天找出你手头一个「两张皮」的协作（工作里项目组各干各的、学习里自己和自己拖延、甚至家庭分工都行）：①画出两边的指标（各自在追求什么）；②找「一个共同指标」（两边都能认的数）；③定「一个固定节奏」（每周几对齐一次）——做一个月，看协作顺了多少。做完你就懂：组织调整不是改架构图，是「把两把尺子换成一把」——共担，比任何架构图都管用。

⑮ 求职助手联系（面试前必做）
面试前用本卡做 3 件事：①把「配小组+建中台+对齐节奏」三味药练熟（面试核心框架）；②准备你的「两张皮」案例（景观设计的设计施工一体化——真实经历最打动面试官）；③把「检验标准：交接变共担」这句话练熟（追问时收口用）。面试被问「组织架构调整」时：先说病（两张皮）→再说三味药（配小组/建中台/版本列车）→收口检验标准（交接变共担）——框架清晰+经历真实，面试官立刻记住你。

⑯ 练习（自己测一遍）
1.（判断）以下哪个是「共担模式」的表现？A 产品发需求邮件、算法回排期邮件；B 产品+算法+评测一起看回复率数据，没到一起复盘——答案：B（A 是交接）。
2.（三味药）团队出现「两个小组各建各的评测集，比不了数」，该用哪味药？——答案：建中台（统一评测集、统一口径）。
3.（角色）老板问「组织调整到底改什么？」你一句话回答？——参考答案：「改协作方式：把『产品提需求→算法排期』的交接模式，变成『共同对一个指标负责』的共担模式——指标、尺子、节奏三个对齐，组织就顺了。」

新 AI 产品线与团队


图怎么读：如果给一条新的 AI 产品线（人工智能产品业务线：一个新的产品方向）怎么做、团队怎么搭——三步走：第一步验证（2-4 周）——先验证「用户要不要」（用最小方案：假方案/手动流程测试需求——不写代码！像做景观设计先给效果图看反响，不做完整个园子再问要不要——问 30 个目标群友：愿意用吗、愿意付费吗——验证不过就换方向，省下整个团队的成本）；第二步跑通（1-2 月）——最小团队做最小可行产品（MVP（最小可行产品）：最简版本先跑起来）——团队搭「能力三角」：产品（定义需求）+算法（模型能力）+全栈/工程（落地实现），再加半个评测/数据——目标：核心链路 0→1 跑通、拿到真实数据（不是「感觉可行」，是「数据可行」）；第三步扩编——验证通过后再加人加功能（有真实数据支撑，才谈扩规模——数据说话）。收口：新线最大的坑是「团队搭好了但需求没验证」——先验证再搭团队，顺序别反（验证是 2-4 周的小投入，团队是几十万的大投入——顺序反了，钱白花）。

① 一句话大白话定义
这道题问的是：给你一条新的 AI 产品线（新方向），你打算怎么做（做什么、按什么顺序）？团队怎么搭（几个人、什么角色）？
用大白话说：三步走：先验证需求（2-4 周：不写代码，用手动流程测试「用户要不要」）、再最小团队跑通（1-2 月：产品+算法+全栈三个人把核心链路跑通、拿到真实数据）、验证通过再扩编（有数据才加人加功能）。团队按「能力三角」搭（产品定义+算法模型+全栈落地——三个人三种能力），优先招「能端到端」的人（一个人能扛一段完整链路），不按大厂岗位细分。一句话：先验证再搭团队——顺序别反（验证便宜，团队贵）。

打个比方：开餐厅（新 AI 产品线）——先「试菜」（验证：用朋友试吃+发朋友圈问「想吃吗」——不租店面不招厨子——2-4 周验证有没有人想吃）；试菜有人排队（验证通过）——再开「小店」（跑通：老板自己炒菜+一个服务员——最小团队跑通生意链路：买菜→炒菜→收钱——拿到真实流水）；小店赚钱了（数据说话）——才开「大店招人」（扩编：加厨子、加服务员、加店长）。顺序反了（先租大店招人再试菜）——菜没人想吃，店和人都白搭。

30 秒电梯版：「新 AI 产品线三步：第一步，验证（2-4 周）——不写代码，用最小方案验证『用户要不要』：假方案/手动流程测试需求（人工先跑通，验证需求再上模型），问 30 个目标群友『愿意用吗、愿意付费吗』——验证不过就换方向（省下整个团队的成本）；第二步，跑通（1-2 月）——最小团队做最小可行产品（产品+算法+全栈三个人），目标是把核心链路从 0 到 1 跑通、拿到真实数据（不是感觉可行，是数据可行）；第三步，扩编——验证通过后再加人加功能（有真实数据支撑才谈扩规模）。团队搭建：最小团队是『能力三角』——产品（定义需求）+算法（模型能力）+全栈/工程（落地实现），再加半个评测/数据；人少事多时优先招『能端到端』的人（一个人能扛一段完整链路），不要一开始就按大厂岗位分得很细（小团队分太细=人人都等别人）。收口：新线最大的坑是『团队搭好了但需求没验证』——先验证再搭团队，顺序别反（验证是 2-4 周的小投入，团队是几十万的大投入）。」

② 为什么学 / 面试为什么考
「新线怎么做」是 AI 产品经理的高频面试题（考的是从 0 到 1 的完整思维），面试考它的原因有三：
第一，它考「从 0 到 1」的完整链路。新线=从零开始（需求、方案、团队、节奏全要你规划）——面试官想看你有没有「完整的产品思维」（不是只懂一个环节，是从验证到扩编全链路）——这是产品经理和「只会写文档的人」的分水岭。
第二，它考「资源敏感度」。新线最大的风险是「钱花在没验证的地方」（团队搭好了需求没人要）——面试官想看你懂不懂「小步快跑」（先验证再投入、最小团队跑通再扩编——资源花的顺序就是成败）——资源敏感度（把钱花在刀刃上）是产品经理的核心素养。
第三，它考「AI 特有节奏」。AI 新线的节奏和传统不同：验证阶段可以「人工版先跑」（不用模型也能验证需求——用人工模拟 AI 效果），团队要有「能力三角」（产品+算法+全栈——AI 开发三件套）——面试官想看你懂不懂「AI 从 0 到 1 的节奏和团队结构」。
一句话：这道题考的是「从 0 到 1 完整链路」＋「资源敏感度」＋「AI 特有节奏」。

③ 原理拆解：三步走→团队搭建→收口

第一步：验证需求（2-4 周）——不写代码，先测「用户要不要」。新线的第一件事不是招人、不是写代码——是「验证需求」：用最小方案测试「用户要不要」——具体做法：不写代码（用假方案：一个原型图/一个手动流程——让用户「假装用」）、手动流程测试（用户提需求→你手动做出来给他看——验证「他到底要不要、要什么」——像写书先写 3 章给群友看反响，不写完 40 章再问）——验证标准：问 30 个目标群友（愿意用吗？愿意付费吗？会推荐给别人吗？）——验证通过（30 个里 20 个说愿意用）再进下一步；不通过就换方向（省下整个团队的成本——2-4 周的人力 对比 半年团队开销）。
打个比方：摆摊前先「问路过的」——想卖手打柠檬茶（新线），先别租店买设备（不写代码），先在小区门口摆个小桌试卖三天（手动流程：自己手打+纸杯卖——测试「有没有人买」）——有人买（验证通过）再租店买机器（投入）；没人买就换（酸梅汤？）——2-4 周的试卖 对比 半年店面租金——验证阶段省下的钱，就是利润。
翻车案例：有团队做 AI 新线，「先招人再验证」——招了 10 人团队（产品 3+算法 4+工程 3）干了 3 个月做出产品——上线发现「没几个人要」（需求没验证：做的是团队认为好的，不是用户要的）——10 人 3 个月白干（几百万人力成本）——「先搭团队后验证」翻车：验证只花 2-4 周（问 30 个人愿不愿意用），团队花几百万（10 人 3 个月）——顺序反了，贵的白花。

第二步：跑通（1-2 月）——最小团队做最小可行产品。验证通过后，进入「跑通」阶段——目标不是「做全功能」，是「把核心链路从 0 到 1 跑通+拿到真实数据」：最小可行产品（MVP（最小可行产品）：只做核心链路的最简版本——其他全砍：不做设置页、不做好看的界面，只做「用户进来→用核心功能→有结果」这一条线）；拿到真实数据（真实用户用起来的数据：用了多少次、卡在哪、结果满意吗——不是「感觉可行」，是「数据可行」——用数据判断要不要继续投入）。
打个比方：开面馆试营业（跑通阶段）——只做「一碗招牌面」（最小可行产品：砍掉 30 种面、砍掉装修、砍掉外卖平台——只做「顾客进门→点面→吃面」核心链路）；目标不是「品种全」，是「拿到真实数据」：一天卖几碗、顾客吃得满意吗、复购吗——数据好（有人天天来）→继续投入；数据差（没回头客）→换招牌面（方向调整）。跑通阶段：链路通+数据真，就算赢。
翻车案例：有团队 MVP 阶段追求「功能全」——最小可行产品做成了「全功能产品」（设置、多语言、数据报表全要）——做了 6 个月才上线（超出 1-2 月节奏 3 倍），上线发现核心链路用户根本不满意（全功能掩盖了核心问题：核心功能本身做得差）——「MVP 做全」翻车：最小可行产品的「最小」是纪律（只做核心链路），做全=慢+看不清核心问题（功能多≠需求对）。

第三步：扩编——验证通过后再加人加功能。跑通阶段拿到真实数据后，进入「扩编」阶段：数据说话（数据好——用户活跃、复购、愿意付费——说明需求是真的——再扩：加人（从 3 人扩到 8 人）、加功能（从核心链路扩到完整功能））；数据一般（用户用了但留不住——说明核心链路有问题——先修核心，不扩编）；数据差（没人用——止损：换方向或砍掉——不是「再投钱抢救」，是「验证失败，换线」——止损比硬撑体面）。扩编的决策依据永远是「数据」，不是「感觉」或「投入了不能白投入」。
打个比方：小店试营业后的决策（扩编）——数据好（天天排队：营业额 3000/天）→扩（招两个服务员+加菜品种类）；数据一般（有人来但不多：营业额 800/天）→先修核心（换招牌菜/调价格——先解决「为什么人不多」）；数据差（没人来：营业额 100/天）→止损（关店换项目——不是「再撑三个月看看」，是「验证失败，及时止损」）。扩编的决策：数据说话。
翻车案例：有团队数据一般（用户留不住）还硬扩——「功能不够全，加功能就能留住用户」——加了 10 个功能（扩编）——用户还是留不住（核心问题不是功能少，是核心功能做得差）——「数据不好还扩编」翻车：扩编的前提是「数据好」（核心链路被验证），数据不好先修核心（不是加功能，是修核心）——数据是扩编的门票，不是「投入了就必须扩」。

第四步：团队搭建——「能力三角」+「能端到端」。团队怎么搭：最小团队是「能力三角」（三个人三种能力）：产品（定义需求：做什么、不做什么、怎么算好）+算法（模型能力：模型选型、训练/微调（在已有模型基础上调整）、评测）+全栈/工程（落地实现：前端（界面）+后端（服务）+数据管道（数据搬运流程）——把模型变成能用的产品）——再加「半个评测/数据」（评测和数据不用专职：产品兼或算法兼——小团队人少，兼职就行）。招聘原则：人少事多时优先招「能端到端」的人（一个人能扛一段完整链路：产品兼评测、全栈兼数据——不用等别人），不要一开始就按大厂岗位分得很细（小团队分太细=人人都等别人：前端等后端、后端等数据——链路卡死）。
打个比方：三个人开小面馆（能力三角）——A 管「卖什么」（产品：菜单定什么、多少钱、怎么算好吃）、B 管「怎么做」（算法：配方、火候、原料）、C 管「店」（全栈：收银、上菜、记账）——三个人三种能力，缺一不可（只有菜单没配方=空店；只有配方没店面=摆摊）；招人标准「能端到端」——A 兼「试菜」（产品兼评测）、C 兼「进货」（全栈兼数据）——三个人能干五个人的活（不按大饭店细分：切菜员、炒菜员、传菜员分开——小馆子分太细=菜都上不了）。
翻车案例：有团队搭新线按大厂编制招人——「前端、后端、测试、数据、算法、产品、交互」7 个岗位各招一人——7 个人互相等（前端等后端接口、测试等开发完成、数据等产品定义）——2 个月过去核心链路还没跑通（7 人 2 个月 对比 3 人 1 个月）——「大厂编制」翻车：小团队分太细=链路卡死（人人都有「不是我的活」）——最小团队：能力三角（产品+算法+全栈）+能端到端（兼职评测数据）——3 个人，链路通。

第五步：收口——先验证再搭团队，顺序别反。全流程的收口一句话：新线最大的坑是「团队搭好了但需求没验证」——正确的顺序：先验证（2-4 周：手动流程测需求——不写代码不招人）→再搭最小团队（通过验证才投入：能力三角三个人）→跑通（1-2 月：核心链路+真实数据）→扩编（数据好才加人加功能）——验证是 2-4 周的小投入（几万），团队是几十万到几百万的大投入（几十人/年）——顺序反了（先团队后验证），验证失败=大投入白花；顺序对了（先验证后团队），验证失败=小投入止损（换个方向重新来）。
打个比方：先「问路」还是先「买票」（顺序）——想去一个地方（新线），先问去过的朋友「那里好不好玩」（验证：2-4 周问 30 个人）——好玩（验证通过）再买机票订酒店（投入：搭团队）；不好玩就不去（止损：省机票酒店钱）。顺序反了——先买机票订酒店（搭团队）再问朋友——不好玩，机票酒店白订（钱白花）。新线同理：先验证再搭团队——验证失败损失小（2-4 周），团队白搭损失大（几百万）。
翻车案例：有公司新线「先立项批预算招人」（公司流程：先给 500 万预算、招 20 人）——做了 1 年——发现需求没人要（从没验证过：团队按「公司觉得 AI 能做」做的）——500 万+20 人年白花（大翻车）——「流程反了」翻车：公司的正规流程（先立项后验证）在 AI 新线是「先验证后立项」（验证需求才值得立项）——顺序反了，钱按「亿」级白花。
小结：验证需求（2-4 周手动测）→最小团队跑通（能力三角 1-2 月）→扩编（数据说话）→团队搭建（三角+端到端）→收口（先验证再搭团队）。

④ 对比表格：正确顺序 对比 反序（踩坑）
| 维度 | 正确顺序（先验证后团队） | 反序（先团队后验证） | |------|------|------| | 第一件事 | 验证需求（2-4 周手动测） | 搭团队（招人、立项） | | 成本 | 小（几万：2-4 周人力） | 大（几十万起：团队开销） | | 失败代价 | 止损（换方向重新来） | 白花（团队白养几个月） | | 团队规模 | 先 3 人（能力三角）后扩编 | 一上来 10-20 人 | | 决策依据 | 数据（验证结果） | 感觉/流程（立项就要做） | | 节奏 | 验证→跑通→扩编 | 扩编→……→发现没人要 | | 比喻 | 先试菜再开店 | 先租大店再试菜 | | 结果 | 钱花在验证过的地方 | 钱花在没验证的地方 |

⑤ 3+个例子：新线实战
例子1：AI 简历优化工具（验证阶段）。新线做「AI 简历优化」——验证阶段不写代码：建一个群（30 个目标群友），群友发简历→你手动用 AI 工具帮改（模拟产品效果）→看反馈：愿不愿意用、愿不愿意付费（10 个愿意付费=验证通过）——2-4 周验证完，再决定要不要开发（验证阶段只有人力成本，没有开发成本）。
例子2：AI 客服新线（跑通阶段）。验证通过后搭「能力三角」：产品（定义客服范围：答什么、怎么算好）+算法（选模型：意图识别+FAQ 方案）+全栈（把模型接到聊天界面、记录数据）——1-2 个月跑通「用户提问→AI 回答→用户反馈」核心链路——拿到真实数据（回复率、满意度、答错率）——数据好（回复率 30% 达标）再扩编。
例子3：AI 摘要工具（扩编阶段）。跑通后数据好（群友活跃：周留存 40%、愿意订阅付费）——扩编：加算法（模型升级：从摘要到多语言）、加全栈（界面优化、移动端）、加产品（数据分析、迭代节奏）——从 3 人扩到 8 人——扩编的依据是「数据」（周留存 40% 是数据，不是「感觉有戏」）。
例子4：AI 绘画新线（止损案例）。验证阶段数据差（30 个群友只有 3 个愿意用、没人愿意付费）——止损：不开发（换方向：从「绘画」换成「头像定制」——30 个群友里 8 个说「头像定制愿意付费」）——止损不是失败，是「2-4 周的小投入换了方向」（省下开发成本）。

⑤b 补充板块：验证阶段的「人工版先跑」——AI 新线的独门技巧
AI 新线的验证有个独门技巧：「人工版先跑」——验证 AI 需求时，不用真模型，用「人工模拟 AI」：
第一，为什么先人工版：验证的是「需求」（用户要不要这个功能），不是「模型」（模型效果好不好）——用人工模拟 AI 效果（你手动做，假装是 AI 做的）——用户要的是「效果」（回答得好不好），不是「是不是 AI 做的」——需求验证和模型验证分开（先验需求，再谈模型）。
第二，人工版怎么跑：建小群（30 人）→用户提问→你手动用 AI 工具回答（人工模拟 AI 产品）→观察：用户用不用、满不满意、愿不愿意付费——2-4 周跑下来，数据（用不用/付费意愿）就是「需求验证结果」——比开发一个真模型（2 个月）快 8 倍。
第三，什么时候换真模型：人工版数据好（需求验证通过）→再上真模型（开发最小可行产品）——模型效果不达标→优化模型（不优化需求——需求已验证，问题在模型）；人工版数据差（没人用）→换方向（不用上模型——需求没验证，上模型也是白上）。
一句话：人工版先跑=先验需求后验模型（需求用人工验，模型用开发验）——AI 新线验证快 8 倍的独门技巧（不用真模型，也能验证需求）。

⑤c 补充板块：新线节奏的「三个不」——常见翻车预警
新线最常见的三个翻车，提前预警：
第一，「不验证就开发」：跳过验证直接开发（「这个需求肯定有」——感觉代替验证）——6 个月后发现没人要——解法：验证阶段不省（2-4 周手动测，成本最低的时候测）。
第二，「不跑通就扩编」：核心链路没跑通（真实数据没拿到）就加人加功能（「人手不够所以做不出来」——其实是不确定性没消除）——加再多人都慢——解法：跑通优先（链路通+数据真，才谈扩编）。
第三，「不砍就硬撑」：数据差还不止损（「投入了不能白投入」——沉没成本（已经花掉收不回来的钱）绑架决策）——硬撑半年，浪费更多——解法：止损标准提前定（验证前就写：「30 人里少于 10 人愿意付费=换方向」——标准提前定，止损不犹豫）。
一句话：三个不——不验证就开发、不跑通就扩编、不砍就硬撑——三个都是「顺序/节奏」问题（顺序反了或节奏错了），提前预警就不翻车。

⑥ 常见误区（3个）
误区1：「新线第一步是写方案（PRD（产品需求文档））。」错！第一步是验证（手动流程测需求——不写代码不做方案）——方案是验证之后的事（需求没验证，方案写得再漂亮也是白纸）——顺序：验证→方案→开发。
误区2：「团队按大厂编制搭（各岗位分开招）。」错！小团队按「能力三角」搭（产品+算法+全栈三个人）+「能端到端」（兼职评测数据）——大厂编制（前端/后端/测试/数据分开）是小团队的卡点（人人等别人）——编制跟着团队规模走。
误区3：「验证就是做个问卷调查。」错！问卷问「你愿意用吗」用户都说愿意（嘴上说愿意≠真会用）——真验证是「手动流程让用户用」（他真用了、真付费了=验证通过）——行为验证（用行动证明）比问卷验证（用嘴巴证明）真 10 倍。

⑦ 第一人称面试回答（3年景观设计→自学转行 AI 产品）
「我 3 年景观设计，被裁后自学转行——新线三步（验证→跑通→扩编），我自学转行时完整走过一遍：我先做的是『验证』——转行方向还没定（做 UI（用户界面）还是做产品还是做 AI），我没急着报班交 2 万学费（没急着搭团队），先做了一件事：用手动流程试——帮 30 个群友改简历、答疑 AI 学习问题（人工版先跑：用 AI 工具手动帮他们做，模拟产品效果）——2-4 周下来看数据：群友愿意用吗（每天来找）、愿意付费吗（有人发红包）——验证通过（有人愿意付费）我才决定投入学习（搭『团队』：时间+学费）；然后『跑通』——做最小可行产品：我用 AI 工具+脚本做了一个『书本统计工具』（给自己 942 道题统计字数），核心链路跑通（统计→生成报告→备份），拿到真实数据（跑完 942 题没问题）；数据好再『扩编』——加功能（结构检查、重复检测）。团队搭建我也实践过：我自己一个人就是『能力三角』（产品：定义要统计什么+算法：选 AI 工具+工程：写脚本落地——一个人端到端）。我没有大厂新线经验，但我用转行的亲身经历证明了：先验证（帮 30 个群友手动试）再投入（学习/开发）——顺序对了，钱和时间都花在验证过的地方。」

⑧ 小结口诀
「先验证（2-4 周手动测需求）、再跑通（能力三角 1-2 月）、后扩编（数据说话）；团队三角（产品算法全栈）+端到端（兼职评测数据）；最大的坑：团队搭好了需求没验证——顺序别反。」

⑨ 三轮追问（面试官深挖）
追问1：「验证阶段问 30 个群友，样本太少怎么办？」「30 个是『快验证』不是『全面验证』：30 个里 20 个愿意付费=强信号（需求大概率真），10 个以下=弱信号（换方向）；样本要『精准』不要『量大』（30 个精准目标群友（真的是目标用户、真的会付费）＞300 个随便填问卷的路人）；强信号后再扩大验证（付费内测：30 个里愿意付费的 10 个做真付费内测——钱是最好的验证）。」
追问2：「如果老板说『团队已经招好了，直接干』怎么办？」「团队招好不用解散——调整顺序：团队先用 2-4 周做『验证冲刺』（全员做验证：产品建群手动测、算法做模型可行性评测（评估测试）、全栈做技术可行性验证——不写正式代码，只做验证）——验证通过再进入正式开发（团队没闲着，只是先验证）；验证不通过就调整方向（团队重新聚焦新方向——比团队解散便宜）——顺序可调（验证先行），团队不浪费。」
追问3：「能力三角里谁最重要？」「关键时刻产品最重要——因为产品管『方向』（做什么、不做什么、怎么算好）：方向错了，算法再强、工程再快也是白干（产品把『做什么』定义清楚，算法和工程才有意义）；但平时三角缺一不可（没有算法=只有想法，没有工程=只有演示）——产品是方向盘（决定去哪），算法是发动机（决定跑多快），工程是车身（决定能不能上路）——方向错了最贵，所以产品最重要。」

⑩ 进阶加分点（说出口就加分）
加分点1：把「验证」设计成「付费验证」。「我的验证标准不止『愿意用』，是『愿意付费』：先给 10 个群友免费内测（他们用得好），再收他们 99 元/年（愿意付费=真需求，免费愿意用≠需求）——付费验证比问卷验证真 10 倍（钱是最好的验证工具）。」——「付费验证」一说出口，你的验证就比别人的深一层。
加分点2：引入「验证矩阵」。「验证阶段我用一个矩阵：需求（要不要）×技术（做不做得到）→四种情况：需求真+技术可行（做！）、需求真+技术难（换技术方案）、需求假+技术行（换方向）、需求假+技术难（放弃）——验证把四个象限探清楚，再决定做什么——不是只验需求，是需求和技术一起验。」——「验证矩阵」说明你验证的不只是需求，是「需求×技术」全貌。
加分点3：把「止损标准」写进立项书。「新线立项第一天就写止损标准：『验证期 30 人付费少于 10 人=换方向；跑通期核心指标（回复率）低于 X=砍线』——标准提前写（写在立项书里），执行时靠标准不靠感觉（提前定好，止损不犹豫）。」——「止损标准提前写」说明你懂「决策要在事前做」（事后的决策都太晚）。

⑪ 话术库（直接抄着说）
「新线三步：验证（2-4 周手动测需求）、跑通（最小团队 1-2 月）、扩编（数据说话再投入）。」
「验证阶段不写代码：假方案/手动流程/人工版先跑——验证需求，不验证模型。」
「最小团队是能力三角：产品（定义）+算法（模型）+全栈（落地）——再加半个评测/数据。」
「招人优先『能端到端』的：一个人能扛一段完整链路，不按大厂岗位分细。」
「最大的坑：团队搭好了需求没验证——先验证再搭团队，顺序别反。」

⑫ 小白 Q&A（可能踩的坑）
Q1：新线第一步不写方案，那老板要看方案怎么办？给「验证方案」不给「开发方案」：一页纸写「验证什么（需求真假）、怎么验（手动流程/人工版）、验证标准（30 人付费 10 人）、验证时间（2-4 周）」——老板要的是「靠谱」，验证方案比开发方案靠谱（开发方案是没验证过的假设，验证方案是马上验证的计划）。
Q2：人工版先跑，是不是骗用户（假装是 AI）？不用骗——明说「这是产品内测版（人工模拟 AI）」，用户要的是「效果」（问题答得好不好），不是「是不是 AI」——而且内测本来就是要迭代的（人工模拟的也是产品的一部分，以后换真模型）——诚实内测+效果真实，不骗。
Q3：新线没人带，自己一个人能做吗？能——你就是「能力三角」（产品自己定义需求、选 AI 工具（算法）、写脚本落地（全栈）——一个人端到端）——我的转行项目（书本统计工具）就是一个人做的：产品（统计什么）+算法（选 AI 工具）+工程（脚本落地）——一个人也能把新线从验证跑到通。

⑬ 没人告诉你的事（面试潜规则）
这道题面试官真正在听的是「你有没有从 0 到 1 完整走过」——面试官不期待你有大厂新线经历（新人哪有），期待你说「我用自己的小项目验证过这套」（我用转行经历、帮群友手动试、一个人端到端）——用真实的小经历证明大方法。另一个潜规则：这道题的灵魂是「顺序」——「先验证再搭团队」是全场的金句（80% 的候选人会答「先写方案、搭团队、开发」——资源敏感度一眼见高低）——你把顺序讲清楚（验证便宜团队贵），面试官就知道你懂「钱怎么花」。还有一个：面试官问「团队怎么搭」，其实在问「你懂不懂小团队协作」——你答「能力三角+端到端」（3 个人干 5 个人的活），比答「按大厂编制」懂行十倍——小团队思维（一人多能）是创业公司最看重的。

⑭ 做一件事（学完就动手）
今天拿你「想学但还没学」的一个新技能（或想做还没做的副业），走一遍「新线三步」：①验证——先不报名不买课（不投入），用 2 周手动试（找 30 个会的人问「这个技能学了有用吗」+自己用免费资源试 2 周）；②跑通——验证有用再投入（报个便宜的课/买本最基础的书——最小投入跑通「学-用」链路）；③扩编——学出成果（能做出作品）再追加投入（贵课、系统训练）——顺序对了，你的时间和钱都花在验证过的地方。

⑮ 求职助手联系（面试前必做）
面试前用本卡做 3 件事：①把「验证→跑通→扩编」三步+「能力三角」练熟（面试框架）；②准备你的「新线」案例（转行验证：帮 30 个群友手动试/书本统计工具——真实经历最动人）；③把「先验证再搭团队，顺序别反」练熟（收口金句）。面试被问「新 AI 产品线」时：先说三步（验证/跑通/扩编）→再说团队（能力三角+端到端）→收口（先验证再搭团队）——框架完整+经历真实+金句收口，面试官立刻记住你。

⑯ 练习（自己测一遍）
1.（排序）新 AI 产品线的正确顺序？A 搭团队→开发→验证；B 验证→最小团队跑通→扩编——答案：B。
2.（团队）最小团队「能力三角」是哪三种能力？——答案：产品（定义）+算法（模型）+全栈（落地）。
3.（角色）老板说「新线直接招 10 个人开干」，你怎么回应？——参考答案：「建议先花 2-4 周验证：我建 30 人群友群，手动流程测试需求（不写代码）——30 人里 20 人愿意付费再招人；团队先招『能力三角』3 人（产品+算法+全栈）跑通核心链路，拿到真实数据再扩到 10 人——验证便宜（2-4 周），团队贵（10 人半年），顺序对了钱花在刀刃上。」

金字塔原理汇报


图怎么读：金字塔原理（Pyramid Principle：一种汇报方法，结论在最上面、论据在中间、细节在最下面，像金字塔一样一层层展开）在向高管汇报 AI 产品（人工智能产品）方案时怎么用：①顶层结论先行——第一句话给判断（「这个 AI 功能建议做，预期三个月内回复率提升 10%，要一人算法资源」——结论在最尖，高管 3 秒听懂）；②中层论据分组——三个理由一组（用户证据：30% 群友（社群里的朋友，不是虚构的用户）行为显示需要；技术证据：模型评测已达标；商业证据：成本可控）——每组内部 MECE（相互独立、完全穷尽：理由之间不重叠、不遗漏）；③底层细节挂载——数据、方案、风险、排期全挂在对应论据下面（高管问哪层展开哪层，不问不展开）；特别提示：AI 方案的「不确定性」（效果可能好也可能不好）要量化成「验证计划」（先花 X 做验证，达标继续、不达标止损——别只扔一句「效果可能好」）。

① 一句话大白话定义
这道题问的是：用金字塔原理（结论先行、论据分层、不重不漏的汇报方法）向高管（公司高层领导）汇报 AI 产品方案——怎么用？
用大白话说：汇报先说结论（3 秒说清「做不做、值不值、要什么」），再说理由（分组，不重复不遗漏），最后挂细节（数据、风险、排期——高管问哪给哪）。高管时间少、只关心「值不值得做、风险多大、要什么资源」——金字塔就是按他的关心排序：结论最尖、细节最底。

打个比方：问路——你会先说「往东走，300 米就到了」（结论：方向+距离），再解释「过了红绿灯、看到奶茶店右转」（理由+细节）——不会先讲「我昨天也走错路了，当时……」最后才说「往东」！向高管汇报同理：结论先说（3 秒），细节后给（问到了再展开）——顺序反了，高管 3 分钟就失去耐心。

30 秒电梯版：「金字塔原理四个步骤：第一步，结论先行——第一句话给判断：『这个 AI 功能建议做，预期三个月内回复率提升 10%，要一人算法资源』；第二步，论据分组——三个理由：用户证据（30% 群友行为显示需要）、技术证据（模型评测已达标）、商业证据（成本可控）；第三步，MECE（相互独立、完全穷尽）——理由之间不重叠（每个理由说不同的事）、不遗漏（用户、技术、商业三面都覆盖）；第四步，细节挂载——数据、方案、风险、排期全挂在对应论据下，高管问哪层展开哪层。特别提示：AI 方案的『不确定性』（效果可能好也可能不好）别只说『效果可能好』，要量化成验证计划：先花 X 做验证，达标继续、不达标止损——高管要的不是承诺，是『知道最坏情况的预算』。」

② 为什么学 / 面试为什么考
金字塔原理是产品经理（PM）汇报的「基础设施」，面试考它的原因有三：
第一，它考「结构化表达」。AI 产品方案复杂（技术、数据、商业交织），说不清方案就推不动——面试官想看你懂不懂「把复杂讲简单」（结论先行、论据分层——这是所有汇报的底层逻辑）。
第二，它考「高管视角」。向高管汇报和向同事汇报不一样（高管时间少、只看决策点：值不值、险多大、要什么）——面试官想看你有没有「向上管理」意识（知道高管关心什么，按他关心的话说话）。
第三，它考「AI 方案的特殊性」。AI 方案的不确定性（效果是概率不是保证）让汇报更难——面试官想看你懂不懂「把不确定性变成验证计划」（不是藏，是透明地给台阶）——这是 AI 产品经理和传统产品经理汇报的最大差别。
一句话：这道题考的是「结构化表达」＋「高管视角」＋「AI 方案的特殊性」。

③ 原理拆解：四步金字塔＋AI 特别提示

第一步：结论先行——第一句话给判断。开场第一句不是「我们分析了很多数据」（铺垫），是「这个 AI 功能建议做，预期三个月内回复率提升 10%，要一人算法资源」（结论+预期+成本——一个句子全给到）。高管只给 3 分钟，结论 3 秒给到，剩下的时间都是论证（他不打断你就能讲完）。
打个比方：相亲对象问你「上次约会怎么样」——你不会说「那天我先打车，路上堵了半小时，然后……」——你会先说「挺好的！」，再补细节。汇报同理：先说「建议做」（结论），再补「为什么做、怎么做」（论据）——结论先行是尊重对方时间。
翻车案例：有产品经理汇报 AI 功能，先讲了 5 分钟技术背景（「我们这个模型用了……架构，数据量……」）——高管打断：「所以呢？做不做？要多少钱？」——铺垫式汇报翻车：高管的耐心只有 3 分钟，先讲背景就是浪费他的耐心。第一句必须是结论（做不做、值不值、要什么）。

第二步：论据分组——三个理由一组。结论下面挂「一组论据」，不是「一条条零散的理由」——典型分组：用户证据（用户/群友的真实需要：30% 群友行为显示需要）、技术证据（技术可行：模型评测（评估模型好坏的测试）已达标）、商业证据（商业划算：成本可控）——三组并列，每组一个角度。分组的意义：高管听完一组就记住一个角度（三个角度=用户要+技术行+商业值），不分组就是一团乱麻。
打个比方：卖房中介带你看房——好的中介只说三件事：「地段好（离地铁 5 分钟）、户型好（南北通透）、价格好（比同小区便宜 20 万）」——三组理由，每组一个角度，你全记住；差的中介：「这个房子吧，采光其实也还行，你看这墙，去年刚刷的，楼下有个超市，房东人挺好的……」——一团乱麻，你啥也没记住。论据分组：三组（用户+技术+商业），每组一个角度，高管全记住。
翻车案例：有产品经理汇报时列了 8 条理由：「我们调研了 5 个群友、看了 3 篇论文、对比了 2 家竞品、模型准确率 82%、成本每个月 2000 块、开发要 2 个月、上线后运营要跟上、还要改一下视觉……」——高管听完一个都没记住（理由没有分组，8 条=0 条）。分组成三组（用户要+技术行+商业值），8 条塞进 3 组——高管记住 3 组就够了。

第三步：MECE——组内不重叠、不遗漏。MECE（相互独立、完全穷尽：Mutually Exclusive Collectively Exhaustive）——每组理由之间「不重叠」（独立：一个理由讲用户，另一个就别再讲用户）＋「不遗漏」（穷尽：用户、技术、商业三个角度全覆盖，没有漏掉的角度）。检查方法：把理由写下来，两两比（有没有两个理由其实在说同一件事？——重叠要去掉）；再扫一遍（有没有一个角度完全没覆盖？——遗漏要补上）。
打个比方：衣柜整理——MECE 的「不重叠」：每件衣服只有一个位置（衬衫在衬衫区，不会同时出现在裤区）；「不遗漏」：所有衣服都有位置（没有一件衣服没地方放）。汇报同理：每个理由只在一个组里（不重叠），所有角度都有组（不遗漏）——高管听完不会觉得「好像少了点什么」。
翻车案例：有产品经理汇报理由：「①用户需要（30% 群友问过）②市场机会（同类产品都在做）③用户粘性（群友天天用）」——①②③都有问题：①和③都在讲用户（重叠——粘性也是用户需要的一种）；②和①都涉及市场（同类都在做=市场需要）——三个理由其实在说两件事（用户+市场），技术、商业两个角度完全没覆盖（遗漏）。MECE 检查一下：「用户+技术+商业」三组——用户证据（①②合并）、技术证据（补：模型评测达标）、商业证据（补：成本可控）——不重叠、不遗漏。

第四步：细节挂载——问哪层展开哪层。数据、方案、风险、排期——所有细节挂在对应论据下面（细节是论据的支撑，不是独立的大段）。汇报时「不主动倒细节」（高管没问，别自己讲 20 分钟数据），「问到立刻给」（高管问「准确率多少」——立刻从对应论据下拿出来：「评测集上 82%，样例见附件」——胸有成竹，不是翻材料）。
打个比方：点菜——服务员问你「喝什么？」你不会把整本菜单背一遍（不主动倒细节），你会说「有可乐、雪碧、橙汁」（直接给选项）；他追问「可乐多少钱？」你立刻答「6 块」（问到立刻给）。汇报同理：高管不问数据，别主动倒；高管一问，立刻从对应论据下拿——胸有成竹（细节都在手边，只是不主动倒）。
翻车案例：有产品经理汇报 AI 方案，讲到「商业证据」时顺带把「成本明细表」从头念了一遍（19 行数据：服务器、标注、人工、电费……）——高管皱眉：「这个我回头看附件，你继续讲结论」——主动倒细节翻车：细节不是不能给，是「问到再给」（高管要的是决策信息，不是账单）。细节挂载：挂在论据下，问哪层展开哪层。

第五步：AI 特别提示——不确定性要「验证计划」。AI 方案和传统方案的最大区别：效果不确定（传统功能「按钮加上，转化率大概率涨」；AI 功能「效果 60 分还是 90 分，试了才知道」）——向高管汇报 AI 方案，最怕只说「效果可能好」（高管没法决策：好到什么程度？要投多少钱？）——要把不确定性变成「验证计划」：「先花 2 周、1 个算法人力、3 万预算做验证（小范围试点），评测达到 80% 就继续放大，达不到就止损」——高管拿到的是「有边界的赌博」（知道最坏损失多少），而不是「可能好」的空话。
打个比方：相亲——对方说「我人挺好的」（效果可能好——没法判断）；说「我们见三次面，聊得来就继续，聊不来就各自安好」（验证计划：有边界、有止损点）——后者才敢继续。AI 汇报同理：「效果可能好」没人敢投；「先花 X 验证，达标继续、不达标止损」——高管敢拍板。
翻车案例：有产品经理汇报 AI 功能：「这个功能我们觉得会很好，用户肯定喜欢，建议直接上线」——高管：「好到什么程度？要投多少人？达不到怎么办？」——三个问题全答不上来（没有验证计划）——「效果可能好」翻车：AI 效果没人保证，没有验证计划（阶段验证、止损点、预算边界）就是让高管裸赌。汇报 AI 方案必带验证计划。
小结：结论先行（3 秒给判断）→论据分组（用户+技术+商业三组）→MECE（不重叠不遗漏）→细节挂载（问哪层给哪层）→AI 特别提示（不确定性=验证计划）。

④ 对比表格：金字塔汇报 对比 平铺式汇报
| 维度 | 金字塔汇报（推荐） | 平铺式汇报（踩坑） | |------|------|------| | 开头 | 结论先行（做不做、值不值、要什么） | 背景铺垫（先讲 5 分钟技术背景） | | 论据 | 分组（用户+技术+商业三组） | 零散罗列（8 条理由=0 条） | | 检查 | MECE（不重叠、不遗漏） | 重复+漏项（自己没发现） | | 细节 | 挂载在论据下（问到再给） | 主动倒细节（背成本明细表） | | AI 特别点 | 不确定性=验证计划（有止损） | 「效果可能好」（高管没法决策） | | 高管体验 | 3 秒懂、3 分钟拍板 | 听完不知道要干嘛 | | 结果 | 资源拿到、方案推进 | 被打断、被质疑、方案搁置 | | 比喻 | 问路先说方向 | 先讲昨天迷路的经过 |

⑤ 3+个例子：金字塔汇报实战
例子1：汇报「AI 客服」方案（结论先行）。「建议做 AI 客服，预期客服成本降 30%，要 2 周试点。」——第一句给全：做不做（建议做）、预期（降 30%）、成本（2 周试点）；高管不问数据，不主动讲「我们调研了 200 条对话记录……」——问「为什么降 30%」才展开（论据：用户证据=80% 咨询是重复问题；技术证据=模型评测通过率 85%；商业证据=替代人工 2 人）。
例子2：汇报「AI 摘要」功能（MECE 检查）。理由先列草稿：「①群友常问长文太长 ②同类产品有摘要功能 ③摘要能提高阅读完成率」——MECE 检查：①和③都在讲用户（重叠——长文太长=读不完）；②是市场（同类都在做）——补全为「用户（长文读不完）、技术（模型摘要评测达标）、商业（竞品已有、不做就落后）」——三组不重叠不遗漏。
例子3：汇报「AI 审核」项目（AI 特别提示）。「建议做 AI 内容审核，预期漏审率从 1% 降到 0.1%；不确定性在于模型误判率——建议先花 3 万、1 个月做试点（拿真实数据测误判），误判率低于 5% 就全量，高于 5% 就退回人工+AI 协同。」——验证计划给到（预算 3 万、阶段 1 个月、达标线 5%、止损路径），高管敢拍板。
例子4：汇报「AI 推荐」改造（细节挂载）。结论：「建议改造推荐逻辑，预期点击率提升 15%。」高管问「怎么改？」——从技术论据下展开：「模型从规则改成交互（三元交互：用户+模型+产品），评测集上点击率提升 12%～18%（区间不是单点，因为是概率模型）」；再问「要多久？」——从成本论据下展开：「2 个月，2 个算法+1 个产品。」——问哪层展开哪层。

⑤b 补充板块：金字塔的「倒金字塔」变体——口头 对比 书面
金字塔原理不是只有一种用法，分场景有两类：
第一，口头汇报（当面/视频）：正金字塔——结论→论据→细节。面对面时间有限，先给结论（3 秒），再给论据（3 分钟），细节只在被问时给（高管打断你也能收住）；适合：周会汇报、方案评审（口头场景）。
第二，书面文档（邮件/PRD（产品需求文档）/方案书）：倒金字塔——细节→结论。书面材料读者自己掌控节奏（他可以慢慢看），所以文档开头写「结论摘要」（Executive Summary（高管摘要：一页纸写清结论和要点）），后面放完整论据和细节（读者想看哪层看哪层）；适合：方案邮件、PRD、立项书（书面场景）。
一句话：口头用正金字塔（结论最尖），书面用倒金字塔（摘要开路、细节在后）——两种都是「结论先行」的变体，只是节奏不同（口头怕被催，书面怕没人看）。

⑤c 补充板块：向高管汇报 AI 方案的「三分钟结构」模板
如果只给 3 分钟，照这个模板走：
第 1 分钟（结论）：做不做+预期+要什么资源（「建议做，预期回复率提升 10%，要一人算法 3 个月」）。
第 2 分钟（论据）：三个理由各 20 秒——用户证据（30% 群友行为需要）、技术证据（评测已达标）、商业证据（成本可控、有竞品对标）。
第 3 分钟（验证计划+风险）：不确定性怎么管——「先花 2 周做验证，评测达到 80% 就放大，达不到就止损；最大的风险是模型误判，我们已准备人工兜底」——风险不是藏，是「说出来+有方案」。
一句话：三分钟模板：1 分钟结论+1 分钟论据+1 分钟验证计划——时间再少，结论和风险不能省（高管要的是判断和兜底，不是完整论文）。

⑤d 补充板块：三种高管的应对（金字塔要「因人调整」）
高管不是同一种，金字塔的节奏要跟着人调：
第一，「数据型」高管（先问数字）：结论后立刻给量化。他听完结论会马上问「多少？」——准备阶段就把「预期数字+来源」备好（「回复率提升 10%，来自 200 条对话的模型评测」）——他对论据的兴趣在数字，不在故事；应对：结论→数字→再说逻辑（数字型：用数字立住结论）。
第二，「风险型」高管（先问坏处）：验证计划放在论据前。他听完结论会马上问「有什么风险？」——准备阶段就把「最坏情况+兜底方案」备好（「最大风险是模型误判，我们准备了人工兜底，试点期误判率超过 5% 就转人工」）——他关心的不是多好，是会不会翻车；应对：结论→风险→验证计划→再讲收益（风险型：先把丑话说在前面）。
第三，「愿景型」高管（先问意义）：结论先说战略价值。他听完结论会问「这事对公司意味着什么？」——准备阶段就把「战略价值」备好（「AI 客服不只是省钱，是公司 AI 能力落地的第一个样板」）——他关心的不是这个功能，是方向；应对：结论→战略意义→再讲执行细节（愿景型：用意义勾住他）。
一句话：数据型给数字、风险型给兜底、愿景型给意义——金字塔的框架不变（结论先行），但「论据的顺序和侧重」跟着高管类型走（同一座金字塔，不同的人从不同的面看）。

⑥ 常见误区（3个）
误区1：「结论先行=只讲结论不讲细节。」错！结论先行是「顺序」不是「数量」——结论先说（3 秒），细节照给（问到再给）——不是不准备细节，是「细节在手边，不问不倒」（胸有成竹 对比 主动倒料）。
误区2：「MECE 就是分三个组。」错！MECE 是「不重叠不遗漏」的检查标准（两两比对去重叠、扫一遍补遗漏），不是「必须三组」——理由多分组多，但组与组之间必须独立（MECE 是质量检查，不是数量规定）。
误区3：「AI 方案效果不确定，所以不敢拍板，只能模糊汇报。」错！恰恰相反——不确定性越大，越要给「验证计划」（预算、阶段、达标线、止损路径）——模糊汇报（「效果可能好」）高管不敢投，验证计划高管才敢拍板（有边界的赌博=敢赌）。

⑦ 第一人称面试回答（3年景观设计→自学转行 AI 产品）
「我 3 年景观设计，被裁后自学转行——但我对金字塔原理有真实的实践：做景观设计时，我要向甲方（委托方）汇报方案，甲方时间比高管还少（他只看『这个方案能不能让领导满意、要多少钱、多久能建完』）——所以我汇报方案永远是：先说结论（『这个方案建议采用，比原预算省 15%』），再讲理由（分成『功能』『造价』『工期』三组，每组一个角度），细节（植物配置、铺装材料）挂到最后，甲方问哪层展开哪层——这就是金字塔原理，我当时不知道这个名字，但甲方从不打断我。转行学 AI 产品后，我把这套用到 AI 汇报上：结论先行（建议做 AI 客服，预期成本降 30%）；论据分组（用户证据：80% 咨询是重复问题；技术证据：模型评测通过率 85%；商业证据：替代人工 2 人）；特别地，AI 汇报我会加『验证计划』（先花 2 周试点，评测达到 80% 就放大，达不到就止损）——因为 AI 效果是概率不是保证，高管最怕听到『效果可能好』，验证计划让他敢拍板。我没有大厂汇报经验，但 3 年向甲方汇报的经历告诉我：结论先行的人，永远不被打断。」

⑧ 小结口诀
「结论先行 3 秒，论据分组成三（用户技术商业），MECE 不重不漏，细节问到再给，AI 不确定性变验证计划——高管 3 分钟敢拍板。」

⑨ 三轮追问（面试官深挖）
追问1：「如果高管听完结论就说『不做』，你怎么办？」「先确认他否的是什么：是结论（这个功能不值得做）还是前提（他以为成本很高）？——如果是前提误解，立刻用论据纠正（『成本其实只有 X，不是 Y』）；如果是结论否定，接受并问『主要顾虑是什么』（把否定变成信息：他不做总有原因——是预算、是时机、还是方向）——记录下来，下次汇报带上他的顾虑：『上次您说担心数据安全，这次方案里我们加了本地化部署方案』——把『不做』变成下一次的『做』。」
追问2：「三组论据里，高管只对技术证据感兴趣，你怎么办？」「顺着展开技术论据（问哪层展开哪层：准确率、评测集、模型选型），但展开完一定拉回商业（『技术上准确率 85%，对应到业务是每月节省 2 个人力』）——高管的兴趣点可以跟随，但汇报的目标（决策）不能丢：他是被技术吸引，不是要学技术——用他的兴趣讲他想听的价值。」
追问3：「汇报时间只有 1 分钟，你怎么用金字塔？」「结论+验证计划两句话：『建议做 AI 客服，预期成本降 30%，要 2 周试点；不确定的是模型误判率，试点期用 1000 条真实对话测，误判率低于 5% 就放大，否则转人工协同。』——1 分钟没有论据的时间，但结论（做不做+预期+要什么）和风险（怎么管不确定性）必须给全——高管 1 分钟也能拍板。」

⑩ 进阶加分点（说出口就加分）
加分点1：用「决策点」重构汇报结构。「我准备汇报时会先问自己：高管听完要做什么决策？（投不投、放不放量、给不给资源）——然后整个金字塔围绕决策点搭：结论=我的建议，论据=支持这个建议的三面，细节=决策需要的全部信息。」——「决策点」三个字一出口，你就从「汇报的人」变成「帮高管做决策的人」。
加分点2：把「验证计划」说得像投资。「AI 项目的汇报本质是融资路演——高管是投资人，验证计划就是试投产：先投一小笔验证回报（花 X 做试点），回报达标追加投资（评测过了全量），不达标止损退出（达不到转人工）——我把汇报当路演，把验证当试投产，高管自然当我是创业者。」——「试投产」类比一说出口，汇报高度直接拉满。
加分点3：会后用「一页纸结论」巩固。「汇报完我会发一页纸：结论（做什么）+论据（三组一句话）+决策记录（高管拍板了什么、下一步谁做什么）——金字塔不只用在会上，也用在会后（书面倒金字塔：摘要开路）——高管翻一页纸就能执行。」——闭环（从会到纸的完整流程）说明你不只懂汇报，懂推动。

⑪ 话术库（直接抄着说）
「建议做……，预期……，需要……」——结论先行开场句（做不做+预期+成本）。
「三个理由：用户需要（30% 群友行为显示）、技术可行（评测已达标）、商业划算（成本可控）。」——论据分组句。
「理由之间我做了 MECE 检查：不重叠（每个理由说不同的事）、不遗漏（用户技术商业全覆盖）。」——MECE 呈现句。
「关于不确定性，我准备了验证计划：先花 X 做验证，达标继续、不达标止损。」——AI 特别提示句。
「细节我带了附件，您问到哪层我展开哪层。」——细节挂载句。

⑫ 小白 Q&A（可能踩的坑）
Q1：结论先行，万一结论错了怎么办？结论先行是「顺序」不是「承诺」——先给判断（推进对话），被反驳就修正（「您说得对，如果成本超出预期，这个方案要重新评估」）——错得快的结论比藏着的结论好（高管能帮你纠偏）。
Q2：没做过汇报，怎么练金字塔？从小的开始：微信发消息先说结论（「我建议选 A」再补理由）、周报第一行写结论（「本周完成 3 件事」）、群聊发言先亮观点——金字塔是习惯不是天赋，练 30 天就长在身上。
Q3：高管不懂 AI 技术，技术论据怎么说？说人话：不说「模型准确率 82% 用了 BERT（一种预训练语言模型）」——说「10 句话里能答对 8 句，答错的有人工兜底」——技术论据翻译成「效果+兜底」（高管要的是效果和风险，不是技术名词）。

⑬ 没人告诉你的事（面试潜规则）
这道题面试官真正在看的不是「你懂不懂金字塔」——是「你会不会被我打断」：面试官会故意打断你（模拟高管），看你慌不慌（慌=没准备，稳住=真练过）。所以面试练这道题，练的不是背答案，是「被任何一句话打断都能收回来」（练法：背熟结论句+三组论据句，被打断就回结论——「刚才说到建议做，理由是三点……」）。另一个潜规则：你说「甲方」比说「用户」更真实（你 3 年景观设计，甲方就是你的高管）——面试官想听到你用自己的经历讲道理，不是背书。还有一个：AI 汇报的「验证计划」是全场最亮的一句——80% 的候选人只会说「效果可能好」，你多说了「先花 X 验证、达标继续、不达标止损」，当场拉开差距。

⑭ 做一件事（学完就动手）
今天找你手头的一件「要向人汇报的事」（工作汇报、学习计划、甚至跟家人商量一件事都行），用金字塔重讲一遍：①结论先行（第一句说清做什么+预期+要什么）；②论据分成三组（每个角度一组）；③MECE 检查（不重叠不遗漏）；④细节备在手边（问到再给）。讲完对比以前——你会发现对方听懂的速度快了一倍。做完你就懂：金字塔不是「汇报技巧」，是「对别人时间的尊重」。

⑮ 求职助手联系（面试前必做）
面试前用本卡做 3 件事：①把「结论先行句+三组论据句+验证计划句」三句话背熟（面试开头和追问都用）；②准备你的汇报案例（景观设计向甲方汇报的经验——真实经历最打动面试官）；③练「被打断能收回来」（背熟结论句，被打断就回「刚才说到……理由是三点」）。面试被问「金字塔原理」时：先说四步（结论→论据→MECE→细节）→再加 AI 特别提示（验证计划）→收口用自己的甲方经历（「我做景观设计时就练过」）——框架+亮点+真实，面试官当场记住你。

⑯ 练习（自己测一遍）
1.（排序）汇报时以下顺序哪个对？A 先讲背景再讲结论；B 先讲结论再讲论据；C 先讲细节再讲结论——答案：B（结论先行）。
2.（MECE）下列三组理由哪个是 MECE 的？①用户需要+市场机会+技术可行；②用户需要+用户粘性+用户增长——答案：①（三组不同角度：用户/市场/技术）；②三组都在讲用户（重叠）。
3.（角色）高管说「AI 效果不确定，我不敢投」，你怎么回应？——参考答案：「我理解，所以我把不确定性变成验证计划：先花 3 万、1 个月做试点，用真实数据测效果；评测达到 80% 就放大，达不到就止损转人工——您投的不是『可能好』，是『知道最坏损失的验证』。」

90 天落地方案


图怎么读：京东外卖 AI 产品「上线后 90 天从 0 到 1」落地方案——五件套：①目标——第一版解决「骑手/商家/用户」中最痛的一个环节（如骑手智能调度、商家 AI 回复——三选一，不做三个），目标写业务指标（调度效率提升 X% / 回复及时率 Y%——业务语言不是技术语言）；②关键路径——四步：数据打通（订单/商家数据接入）→模型选型与评测（用历史数据回测（拿过去的数据试模型：如果当初用这个模型，结果会怎样））→小流量灰度（单城市/单商圈——小范围试水）→全量上线；③里程碑（阶段目标）——按周拆：第 1-2 周数据盘点与可行性验证、第 3-6 周模型回测达标（离线指标过阈值）、第 7-10 周灰度（在线指标对比）、第 11-12 周全量+复盘——每两周一个可验收节点；④上线标准——离线评测过阈值+灰度期核心指标不降+无严重 badcase（严重的错误案例）；⑤指标绑定——每个里程碑挂一个业务指标，不达标就停，不「延期上线」硬上。收口：90 天方案的核心是「每两周有一个可验收的节点」——方案可以变，节点不能丢。

① 一句话大白话定义
这道题问的是：京东外卖（外卖平台）的 AI 产品（人工智能产品）上线后 90 天，怎么从 0 做到 1（怎么落地）？给出目标/关键路径/里程碑/上线标准/业务指标绑定五件套。
用大白话说：目标：第一版只解决「骑手/商家/用户」中最痛的一个环节（如骑手智能调度——一个环节，不做三个）；关键路径四步：数据打通→模型评测（用历史数据回测）→小流量灰度（单商圈试水）→全量上线；里程碑按周拆：1-2 周数据盘点、3-6 周模型回测达标、7-10 周灰度对比、11-12 周全量+复盘（每两周一个可验收节点）；上线标准：评测过阈值+核心指标不降+无严重错误案例；指标绑定：每个里程碑挂业务指标，不达标就停。一句话：每两周有一个可验收的节点——方案可以变，节点不能丢。

打个比方：开外卖店（90 天落地）——目标：「先只做好一道招牌菜」（先解决最痛的一个环节——不是 30 道菜一起上）；关键路径：买菜进货（数据打通）→先试做（模型评测：用以前的订单试做，看看做出来啥样）→在小区门口试卖（小流量灰度）→全平台卖（全量上线）；里程碑：第 1-2 周「盘点食材+试做可行性」（能进到货吗？能做出来吗？）、第 3-6 周「试做达标」（做出来的味道过关——回测达标）、第 7-10 周「小区试卖」（对比：试卖数据和预期）、第 11-12 周「全平台卖+复盘」（卖起来+总结）；上线标准：试做过关+试卖销量不降+没有严重差评（badcase（错误案例））；指标绑定：每两周一个指标（第 3-6 周「试做合格率」不达标就停——不硬上）。每两周有节点，店就能活。

30 秒电梯版：「90 天落地方案五件套：第一，目标——第一版解决『骑手/商家/用户』中最痛的一个环节（如骑手智能调度、商家 AI 回复——三选一），目标写业务指标（调度效率提升 X% / 回复及时率 Y%）；第二，关键路径——四步：数据打通（订单/商家数据接入）→模型选型与评测（用历史数据回测（拿过去的数据试模型））→小流量灰度（单城市/单商圈）→全量上线；第三，里程碑（阶段目标）——按周拆：第 1-2 周数据盘点与可行性验证、第 3-6 周模型回测达标（离线指标过阈值）、第 7-10 周灰度（在线指标对比）、第 11-12 周全量+复盘——每两周一个可验收节点；第四，上线标准——离线评测过阈值+灰度期核心指标不降+无严重 badcase（错误案例）；第五，指标绑定——每个里程碑挂一个业务指标，不达标就停，不『延期上线』硬上。收口：90 天方案的核心是『每两周有一个可验收的节点』——方案可以变，节点不能丢。」

② 为什么学 / 面试为什么考
「90 天落地」是 AI 产品的落地题（考的是把方案变成现实的能力），面试考它的原因有三：
第一，它考「落地能力」。面试官最怕「只会讲概念的人」（说一堆大模型、AI 趋势，落不了地）——90 天方案考的就是「落地」（目标→路径→里程碑→标准→指标——五件套具体到周）——面试官想看你懂不懂「把想法变成计划」——落地能力是产品经理的核心（想法谁都有，落地见高下）。
第二，它考「节奏管理」。90 天=13 周——每两周一个可验收节点（节点管理：到点验收，不达标就停）——面试官想看你懂不懂「节奏」（不憋大招（90 天后才见成果——太慢），也不天天汇报（没有节点——太乱）——两周一个节点，节奏正好）。
第三，它考「AI 落地特有步骤」。AI 产品的落地和传统不同：数据打通（AI 靠数据）、模型回测（历史数据试模型）、灰度对比（小流量验证——AI 效果要对比才知道）——面试官想看你懂不懂「AI 落地的四步」（数据→评测→灰度→全量——AI 特有的落地路径）。
一句话：这道题考的是「落地能力」＋「节奏管理」＋「AI 落地特有步骤」。

③ 原理拆解：目标→路径→里程碑→标准→指标绑定

第一步：定目标——先解决最痛的一个环节。90 天的第一件事：定目标——第一版只解决「骑手/商家/用户」中最痛的一个环节（三选一：骑手智能调度（骑手最痛：路线绕远、送单顺序乱——AI 优化调度：调度效率提升 X%）；商家 AI 回复（商家最痛：回复消息慢、漏单——AI 自动回复：回复及时率 Y%）；用户端（用户最痛：找餐难、等太久——AI 推荐））——为什么三选一：90 天只够做深一个环节（三个一起做=三个都做不透）；目标写业务指标（调度效率提升 X% / 回复及时率 Y%——业务语言（老板能看懂：省了多少成本、快了多少时间），不是技术语言（「上线一个 AI 模型」——老板听不懂））。
打个比方：开外卖店定目标——「先做好一道招牌菜」（一个环节——不做 30 道菜）；目标写「业务指标」：「这道菜每天卖 50 份、毛利 60%」（业务语言：赚钱多少——老板看得懂），不是「引进一套新厨具」（技术语言：老板听不懂）——90 天定目标：一个环节+业务指标（三选一+业务语言——目标才能落地）。
翻车案例：有团队 90 天目标定三个环节（骑手+商家+用户一起做）——团队 90 天全铺开（10 人分三组）——Q4 复盘：三个环节都「半吊子」（骑手调度没测透、商家回复没跑通、用户推荐没上线）——「三个目标」翻车：90 天只够做深一个环节（一个环节做透=有效果；三个环节做半=没效果）——目标三选一（最痛的一个），90 天做透一个。

第二步：关键路径——四步走（数据→评测→灰度→全量）。目标定了，关键路径（最核心的路线）四步：第一步数据打通（订单/商家数据接入——AI 靠数据：没有订单数据（订单怎么分配、哪里堵）模型没有学习素材——先打通数据（订单、商家、骑手的数据接入））；第二步模型选型与评测（选模型+用历史数据回测（拿过去的数据试模型：「如果当初用这个模型调度，每单能省几分钟」——回测：历史数据模拟真实效果——不花钱不扰民就能试效果））；第三步小流量灰度（单城市/单商圈——小范围试水：在真实场景小规模上线（一个商圈），对比数据（AI 调度 对比 人工调度的效率差——真实数据说话））；第四步全量上线（灰度数据好（核心指标提升）→全量铺开（全国范围上线）——不是一步到位，是四步走（每步有验收，过一步走一步）。
打个比方：外卖店四步（数据→评测→灰度→全量）：①进食材（数据打通：猪肉、蔬菜进货——没有食材没法做菜）；②试做（模型评测：用以前的订单回测——「如果按这个配方做，客人评价会怎样」——试做不花钱不扰客）；③小区试卖（小流量灰度：在小区门口试卖一周——真实客人试——对比：试卖销量 对比 预期）；④全平台卖（全量上线：试卖数据好→全平台铺开）。四步走：进料→试做→试卖→全卖——每步验收，过一步走一步。
翻车案例：有团队跳步（不灰度直接全量）——模型回测完（离线指标过了）直接全国上线——上线第二天：真实场景发现「恶劣天气调度崩溃」（回测没覆盖恶劣天气场景——离线数据没有这类情况）——全国调度乱成一锅粥（骑手超时、商家出餐乱——全量翻车）——「跳步」翻车：灰度（小流量试水）就是「低风险试错」（单商圈先试：恶劣天气的坑在单商圈踩（影响小），不在全国踩（影响大））——四步走（数据→评测→灰度→全量）一步不能跳（跳了，坑在全国层面踩）。

第三步：里程碑——按周拆，每两周一个可验收节点。90 天=13 周，拆四个里程碑（阶段目标）：第 1-2 周「数据盘点与可行性验证」（数据齐不齐（订单数据能拿到吗）、可行性验证（这个方向 AI 做得到吗——快速验证：用 1-2 周确认「数据有+方向可行」——不行早换方向）；第 3-6 周「模型回测达标」（模型选型+历史数据回测——离线指标过阈值（评估测试：回测准确率/效率提升过及格线：调度效率提升 ≥10%——过阈值才继续）；第 7-10 周「灰度对比」（单商圈上线——在线指标对比（真实数据：AI 调度 对比 人工调度——灰度期核心指标不降（效率没降才算过））；第 11-12 周「全量+复盘」（全量上线+复盘（总结：什么有效、什么要改——留下经验））——每两周一个可验收节点（节点=到点验收，不达标就停——90 天有 6-7 个节点，每两周有「到没到点」的检查）。
打个比方：外卖店 13 周拆节点——第 1-2 周「盘点+试做可行性」（食材齐吗？能做吗？——不行换招牌菜）；第 3-6 周「试做达标」（试做味道过关（合格率 90%——过阈值））；第 7-10 周「小区试卖」（试卖销量对比（真实数据：卖得动吗——销量不降算过））；第 11-12 周「全平台+复盘」（全平台卖+总结（什么菜受欢迎、什么要改））——每两周一个节点（第 2 周、第 6 周、第 10 周、第 12 周都有「到没到点」的检查——不憋 90 天一次性看结果）。
翻车案例：有团队 90 天「憋大招」（不拆节点）——第 1 周开始闷头做模型——第 10 周才第一次给老板看（「快好了」）——老板一看：方向不对（模型做的是「骑手路径优化」，业务要的是「商家回复」——方向偏了）——90 天白做 10 周（方向错误 10 周后才发现）——「憋大招」翻车：没有节点=没有「到点验收」（第 1-2 周的节点「数据盘点+方向确认」就能发现方向问题（2 周发现 对比 10 周发现））——每两周一个节点（到点验收），错误早发现（90 天有 6-7 次纠错机会）。

第四步：上线标准——三条件缺一不可。上线的判断标准（三条件）：①离线评测过阈值（模型回测达标：调度效率提升 ≥10%（评估测试：历史数据模拟——离线指标过及格线）；②灰度期核心指标不降（在线验证：真实场景核心指标没降（AI 上线后，商家的回复及时率、骑手的送达时效没变差——核心指标不降（不降=没破坏，提升=有价值）；③无严重 badcase（错误案例）（没有严重的错误案例：AI 把订单派错（严重 badcase（严重的错误案例：影响用户的错误））——三个条件缺一不可（只过离线（回测好）不够——灰度（在线）要好（真实场景）；只在灰度好不够——没有严重错误（错误不能有）——三条件齐了才全量）。
打个比方：外卖店上线标准（三条件）——①试做达标（离线评测：试做合格率 90%）；②试卖不降（灰度：试卖销量不比之前差——销量没降算过）；③没有严重差评（badcase（错误案例）：没有「客人吃了拉肚子」（严重错误））——三条件齐了才全平台卖（只试做达标（①）不够——试卖也要好（②）；试卖好但有人吃坏肚子（③）——也不能全卖（严重错误一票否决））——三条件缺一不可。
翻车案例：有团队只按一个条件上线（离线指标过了就全量）——「回测效率提升 15%（离线达标）→全量上线」——上线后：灰度没做（②没验证）、严重 badcase（错误案例）没查（③没查）——真实场景：恶劣天气调度崩溃（②没验出来：灰度没做）、把订单派到 50 公里外（③没查：严重错误）——全国翻车——「单条件上线」翻车：三条件缺一不可（离线过（①）+灰度不降（②）+无严重错误（③））——只看离线（回测好）不够（真实场景和模拟不一样——恶劣天气、意外情况只有灰度（真实小范围）才知道）——三条件齐了才全量。

第五步：指标绑定——每个里程碑挂业务指标，不达标就停。最后一件套：指标绑定——每个里程碑挂一个业务指标（每个阶段目标挂一个可量化的业务指标：第 1-2 周挂「数据完整性」（订单数据覆盖率 ≥80%）；第 3-6 周挂「回测效率提升」（≥10%）；第 7-10 周挂「灰度期送达时效」（不降反升）；第 11-12 周挂「全量后效率提升」（≥15%））——不达标就停（指标没到=停下查原因（数据问题？模型问题？场景问题？——查到再继续），不是「延期上线」硬上（延期硬上=效果没验证就上——上线翻车）——指标绑定=每个节点有「量化验收」（到点看数，数不到就停——不是感觉，是数字）。
打个比方：外卖店每两周一个指标（指标绑定）——第 1-2 周挂「食材齐全率」（进货覆盖率 ≥80%——食材没齐就停：先补齐再继续）；第 3-6 周挂「试做合格率」（≥90%——试做不合格就停：调整配方再试）；第 7-10 周挂「试卖销量」（不比之前差——销量降了就停：查原因（价格？口味？）再继续）；第 11-12 周挂「全平台销量」（≥目标）——每两周一个指标，到点看数（数不到就停——不「延期硬上」（试卖销量差还硬全卖=全平台差评））。
翻车案例：有团队指标不达标还「延期上线」——第 7-10 周灰度数据差（送达时效没提升）——团队说「再等等，延期 2 周上线」——延期硬上（没查原因就硬推）——全量后时效更差（灰度的问题没解决就放大到全国——全量翻车）——「延期硬上」翻车：指标不达标=停（停下查原因：数据？模型？场景？——查到再继续）——延期硬上（不达标还上线）=把灰度的问题放大到全量（小坑变大坑）——指标绑定：不达标就停（查因→修复→再达标→继续）。
小结：目标（最痛一个环节+业务指标）→关键路径（数据→评测→灰度→全量）→里程碑（按周拆、两周一节点）→上线标准（离线过+灰度不降+无严重错误）→指标绑定（每里程碑挂指标，不达标就停）。

④ 对比表格：五件套完整 对比 常见踩坑
| 件套 | 正确做法 | 踩坑做法 | |------|------|------| | ①目标 | 最痛一个环节+业务指标 | 三个环节一起做（都做不透） | | ②路径 | 数据→评测→灰度→全量（四步走） | 跳步（不灰度直接全量） | | ③里程碑 | 按周拆、每两周一个可验收节点 | 憋大招（90 天后才看结果） | | ④上线标准 | 三条件（离线过+灰度不降+无严重错误） | 单条件（离线过了就上） | | ⑤指标绑定 | 每里程碑挂指标、不达标就停 | 延期硬上（不达标也上线） | | 节奏 | 两周一节点（6-7 次纠错机会） | 一次验收（错了 90 天白做） | | 比喻 | 进料→试做→试卖→全卖 | 跳过试卖直接全平台卖 |

⑤ 3+个例子：90 天落地实战
例子1：骑手智能调度（目标+路径）。目标：解决「骑手最痛」（路线绕远、接单顺序乱）——业务指标：调度效率提升 15%（每单配送时长降 3 分钟）；关键路径：数据打通（订单+骑手位置数据接入）→模型选型与评测（用 3 个月历史订单回测：AI 调度 对比 人工调度时长对比）→灰度（单商圈 30 个骑手试点 3 周）→全量（全国骑手）；里程碑：1-2 周数据盘点、3-6 周回测达标（效率提升 ≥10%）、7-10 周灰度（配送时效不降）、11-12 周全量+复盘。
例子2：商家 AI 回复（上线标准）。目标：解决「商家最痛」（消息回复慢、漏单）——业务指标：回复及时率从 40% 到 80%；上线标准三条件：①离线评测（AI 回复准确率 ≥90%（评测集（评估测试题）：1000 条商家对话回测））；②灰度不降（50 家商家灰度：商家漏单率不升）；③无严重 badcase（错误案例）（AI 没有答错关键信息（价格、地址——答错一票否决））；三条件齐了才全量。
例子3：用户智能推荐（里程碑+指标绑定）。里程碑：1-2 周挂「数据完整」（用户行为数据覆盖率 ≥80%——数据不齐就停）；3-6 周挂「回测点击率提升」（≥10%——回测不达标就停：换模型/换特征）；7-10 周挂「灰度期点击率」（不降——灰度数据差就停：查原因）；11-12 周挂「全量后点击率提升」（≥15%）——每两周一个指标，到点看数。
例子4：智能调度坏天气预案（badcase（错误案例）防线）。上线标准里的「无严重 badcase（错误案例）」要提前想：AI 调度在「恶劣天气」可能崩溃（暴雨天单量暴增——调度算法没考虑天气）——预案：①回测数据加入「天气特征」（历史数据里加天气维度——回测时看雨天表现）；②灰度期刻意测雨天（单商圈灰度覆盖一个雨天——看表现）；③严重错误兜底（雨天自动降级为人工调度——有兜底才敢上线）。

⑤b 补充板块：为什么「回测」是 AI 落地省钱的关键
AI 落地四步里「模型回测」最省钱（不花钱不扰民试效果），讲透它：
第一，回测是什么：拿过去的历史数据试模型——「如果当初用这个模型调度，每单能省几分钟」——用「过去」验证「现在」的模型（历史数据模拟真实效果）。
第二，回测省什么：省「真实试错」的钱和时间——直接上线试（真实场景试错：错了影响真实订单——损失大）；回测试（历史数据模拟：错了只是数据上差——零损失）——回测把「上线才知道」变成「上线前就知道」（风险前置（风险在模拟阶段暴露））。
第三，回测的坑：回测不是万能的——「历史数据的场景」≠「未来的场景」（恶劣天气没在历史里——回测看不到）；回测指标好≠在线指标好（模拟环境≠真实环境——所以还要灰度（真实小范围）验证）——回测是「第一道筛子」（筛掉明显不行的），灰度是「第二道筛子」（筛掉隐藏的问题）。
一句话：回测=用历史数据模拟真实效果（省钱省时）——但回测不是终点（历史≠未来：还要灰度（真实小范围）验证）——回测筛明显不行的，灰度筛隐藏的问题。

⑤c 补充板块：灰度（小范围试水）怎么做——三要素
灰度（小流量试水）是 AI 落地的关键一步，三要素：
第一，灰度范围（选哪试）：单城市/单商圈——选「有代表性」的范围（一个订单量中等、场景丰富的商圈——数据有代表性（不是选最好或最差的——选平均的，试出来的结果才准））。
第二，灰度时长（试多久）：2-3 周——覆盖「正常周期」（至少覆盖一个完整业务周期（周一高峰、周末高峰——一周一个周期，试 2-3 周覆盖 2-3 个周期——数据稳定））。
第三，灰度对比（比什么）：AI 对比 现状——同商圈内对比（AI 调度的骑手 对比 人工调度的骑手——同条件对比（效率差一目了然））；对比指标提前定（送达时效、商家满意度——指标提前定，灰度结束看数）。
一句话：灰度三要素——范围（有代表性的单商圈）、时长（2-3 周覆盖业务周期）、对比（AI 对比 现状、指标提前定）——三要素齐了，灰度数据才可信。

⑥ 常见误区（3个）
误区1：「90 天目标越多越好（多解决几个环节显本事）。」错！90 天只够做深一个环节（三选一：骑手/商家/用户——一个做透有效果，三个做半没效果）——目标三选一+业务指标（最痛的一个做深，比三个都碰强十倍）。
误区2：「回测（历史数据试模型）过了就可以直接全量。」错！回测是「第一道筛子」（筛掉明显不行的）——还要灰度（真实小范围：模拟≠真实——恶劣天气、意外情况只有真实场景才知道）——回测过+灰度过+无严重错误（三条件）才全量。
误区3：「指标不达标，延期 2 周硬上。」错！指标不达标=停（停下查原因：数据？模型？场景？——查到再继续）——延期硬上=把灰度的问题放大到全量（小坑变大坑）——指标绑定：不达标就停（查因→修复→再达标→继续）。

⑦ 第一人称面试回答（3年景观设计→自学转行 AI 产品）
「我 3 年景观设计，被裁后自学转行——90 天落地五件套，我做景观设计时就有雏形：接一个市政公园项目（90 天落地）——目标：「先只做公园最痛的一个环节」（我们当时选「排水」（甲方最痛：一下雨就淹——一个环节不做三个）——目标写业务指标（排水效率：雨后 2 小时积水排空——业务语言不是技术语言）；关键路径：数据打通（地形测绘数据接入）→方案评测（用历史暴雨数据回测（如果这个排水方案，上次暴雨会怎样——模拟试错不花钱））→小范围试建（一个角落先做——灰度：真实天气验证）→全面施工（全量）；里程碑：1-2 周数据盘点、3-6 周方案回测达标（排水模拟过阈值）、7-10 周角落试建（真实暴雨验证）、11-12 周全建+复盘；上线标准：模拟过阈值+试建不降（真实降雨排水不差）+无严重问题（没淹水——badcase（错误案例））；指标绑定：每两周一个指标（排水效率不达标就停——不「延期硬上」（试建没达标还全面施工=全面翻车））。转行学 AI 产品后，这套完全平移：目标（最痛环节+业务指标）、路径（数据→评测→灰度→全量）、里程碑（两周一节点）、标准（三条件）、指标绑定（不达标就停）——我做景观设计的落地经验，就是 AI 落地的雏形。」

⑧ 小结口诀
「五件套：目标（一环节+业务指标）、路径（数据→评测→灰度→全量）、里程碑（两周一节点）、标准（离线过+灰度不降+无严重错误）、指标绑定（不达标就停）——方案可变，节点不能丢。」

⑨ 三轮追问（面试官深挖）
追问1：「三个环节（骑手/商家/用户）怎么选最痛的那个？」「用数据选：三个环节各看一组数据——骑手（骑手投诉率/超时率：数据最高的环节最痛）、商家（商家流失率/回复延迟率）、用户（用户差评率/等待时长）——三组数据横向比：哪组最差（超时率 30% 对比 流失率 5%——超时最痛——选骑手）；再加「AI 可行性」（最痛的也要做得动：这个环节 AI 有数据吗、模型能解决吗——痛+可行=选它（痛但不可行——选第二个痛的））——选痛点：数据比（最痛）+可行查（做得动）。」
追问2：「灰度期核心指标不降，但也没升（持平），算过吗？」「分情况：持平（没破坏）=过第一阶段（可以继续扩大灰度——但『持平』不是终点：扩大灰度看数据（样本大了再比一次——持平还是提升）；提升=过第二阶段（可以全量）；持平的原因要查（为什么没升：样本不够？场景特殊？模型没发挥？——查清楚再决定全量（不查就全量=带着疑问放大））——节奏：持平→扩大验证→提升→全量（持平不是不过，是『要继续验证』（扩大样本再看））。」
追问3：「老板要 45 天上线（90 天砍一半），怎么压缩？」「压缩不砍件套，砍阶段：①砍目标（90 天做深一个环节→45 天做『最简版』（只做核心子环节：骑手调度里的『接单顺序优化』——不做完整调度）；②砍里程碑（四周一个节点→两周一个（压缩：回测并行（数据盘点和回测同时做——第 1 周就回测）；③不砍的：灰度（小范围试水）不能砍（不灰度直接全量=翻车风险）——压缩原则：砍目标大小（做小一点）砍周期长短（并行快一点），不砍验证环节（灰度/评测——保命的不能砍）。」

⑩ 进阶加分点（说出口就加分）
加分点1：把五件套挂上「复盘节点」。「五件套之外我加一个复盘节点：每两周节点验收时必做三问——目标变没变（需求还是不是这个）、路径对不对（四步走到哪）、指标合不合理（阈值要不要调）——复盘不是走形式（三问过完，方案才跟得上现实）」——「复盘三问」说明你不只执行，会调整（方案可以变——收口句）。
加分点2：引入「止损阈值」概念。「每个里程碑我不只挂『达标指标』（≥10%），还挂『止损阈值』（连续两周效率提升 <5%=换方向：回测数据差（模型不行——换模型）；灰度数据差（场景不对——换商圈/换环节）——止损阈值=提前定好的『换方向开关』（数据差到一定程度自动触发换方向——不硬扛）」——「止损阈值」说明你懂「有计划的止损」（不是硬扛到失败）。
加分点3：把「指标绑定」升级为「指标仪表盘」。「90 天我会建一个『指标仪表盘』（可视化看板）：五个里程碑的指标全挂上去（数据完整性、回测效率、灰度时效、全量效率、复盘结论）——每周看一次（不是节点才看：每周看趋势——趋势差提前处理（不等节点））——仪表盘让 90 天『看得见』（老板随时能看——汇报也省事）」——「指标仪表盘+每周看趋势」说明你懂「持续监测」（不是到点才看）。

⑪ 话术库（直接抄着说）
「90 天五件套：目标（最痛一环节+业务指标）、路径（数据→评测→灰度→全量）、里程碑（两周一节点）、标准（三条件）、指标绑定（不达标就停）。」
「目标三选一：骑手智能调度/商家 AI 回复/用户推荐——90 天只够做深一个环节。」
「回测=用历史数据试模型（省钱省时）——回测筛明显不行的，灰度筛隐藏的问题。」
「上线三条件：离线评测过阈值+灰度期核心指标不降+无严重 badcase（错误案例）。」
「90 天方案的核心：每两周有一个可验收的节点——方案可以变，节点不能丢。」

⑫ 小白 Q&A（可能踩的坑）
Q1：「业务指标」具体指什么（举几个）？骑手调度（调度效率提升 X%、每单配送时长降 Y 分钟）、商家回复（回复及时率从 40% 到 80%、漏单率降 50%）、用户推荐（点击率提升 X%、转化率提升 Y%）——业务指标=业务价值（省成本、快时间、涨转化——老板看得懂的数）。
Q2：回测（历史数据试模型）不会做怎么办？回测的技术实现是算法/数据的事，产品负责「设计回测」：用什么历史数据（3 个月订单）、比什么指标（AI 对比 人工的时长差）、过什么阈值（≥10%）——产品定义回测的标准，技术实现回测的代码。
Q3：灰度（小范围试水）会不会影响真实业务（试错了怎么办）？灰度就是「低风险试错」的设计——选单商圈（影响面小：试错了只影响一个商圈）；有兜底（灰度期保留人工调度（AI 出问题立刻切人工——兜底开关）；灰度数据是「对比」不是「孤注」（AI 对比 人工同时跑——AI 差就切人工——灰度不赌）。

⑬ 没人告诉你的事（面试潜规则）
这道题面试官真正在听的，是「你有没有把方案落过地」——大部分候选人答「方案很美好」（目标宏大、路径模糊——没有周度节点），你说「五件套+按周拆+两周一节点」（落地细节：具体到周、每两周可验收）——当场拉开（面试官要的是能落地的人，不是讲愿景的人）。另一个潜规则：这道题的灵魂是「指标绑定、不达标就停」——「延期上线硬上」是面试官最怕听到的（他见过太多「硬上翻车」），你说「不达标就停（查因→修复→再达标）」（有纪律的落地）——他就知道你有「止损纪律」（比技术能力更值钱）。还有一个：用「市政公园排水项目」讲 90 天落地，比背「数据打通→模型评测→灰度→全量」动人十倍——你的真实经历（传统项目的落地节奏）就是最稀缺的素材——面试官会记住「这个转行者真落过地」。

⑭ 做一件事（学完就动手）
今天给你手头「90 天目标」（转行计划、求职计划、副业项目都行）写一份「五件套」：①目标（只选一个最痛的环节+业务指标）；②关键路径（四步：准备→模拟试→小范围试→正式做）；③里程碑（按周拆：两周一个可验收节点）；④验收标准（三条件：模拟过关+试做不降+无严重错误）；⑤指标绑定（每两周挂一个指标，不达标就停）——写完你会发现：90 天有了地图，走起来不慌（节点在，方向就在）。

⑮ 求职助手联系（面试前必做）
面试前用本卡做 3 件事：①把「五件套」练熟（面试框架：目标/路径/里程碑/标准/指标绑定）；②准备你的「落地」案例（市政公园排水项目——真实经历最动人）；③把「每两周有一个可验收的节点」练熟（收口金句）。面试被问「90 天落地方案」时：先说目标（最痛一环节）→再说路径（数据→评测→灰度→全量）→收口（两周一节点+不达标就停）——五件套完整+经历真实+金句收口，面试官立刻记住你。

⑯ 练习（自己测一遍）
1.（排序）关键路径的正确顺序？A 数据打通→模型回测→灰度→全量；B 全量→灰度→回测→数据——答案：A。
2.（五件套）「离线评测过阈值+灰度期核心指标不降+无严重 badcase（错误案例）」属于哪一件套？——答案：上线标准（三条件）。
3.（角色）面试官问「90 天方案的核心是什么」，你一句话回答？——参考答案：「核心是『每两周有一个可验收的节点』：目标（最痛一环节+业务指标）、路径（数据→评测→灰度→全量）、里程碑（按周拆）、上线标准（三条件）、指标绑定（不达标就停）——五件套齐了，方案可以变，节点不能丢。」

补遗 · 基本功补充（6 题）

MoSCoW 法则


图怎么读：MoSCoW 法则（优先级分类法：把需求分成必须有/应该有/可以有/不要四级——M、S、C、W 是四个英文词的首字母）怎么用：四级分类——Must Have（必须有：没有产品就不能用/核心承诺——登录/支付/核心功能——「不做会死」——进本期必做）；Should Have（应该有：重要但可推迟——没有也上线，但有更好——「不做会痛」——看资源排）；Could Have（可以有：锦上添花——有时间就做——「不做无所谓」——进待办池）；Won't Have（不要：明确不做——本期范围外——「刻意不做」——价值=明确说不：管理范围蔓延）。怎么用三招：①团队一起分类（需求清单逐条投「四级」——强制讨论：防止「什么都 Must」（人人都说自己最急——投票讨论逼出真实优先级））；②按分类排期（Must 进本期、Should 看资源、Could 进 backlog（待办池）、Won't 明确拒绝——「Won't 的价值=明确说不：管理范围蔓延」）；③时间盒约束（周期固定：Must 超载时把 Should 降级为 Could——「砍需求有依据」（时间不够不是「都要做」，是「Should 降 Could」））。注意：Won't 不是「永远不做」是「本期不做」——明确记录（避免「悄悄加回来」——范围蔓延的防线）。

① 一句话大白话定义
这道题问的是：MoSCoW 法则（优先级分类法）是什么？怎么用来排优先级？
用大白话说：MoSCoW 把需求分四级：必须有（Must：不做会死——登录/支付/核心功能——本期必做）、应该有（Should：不做会痛——重要但可推迟——看资源排）、可以有（Could：不做无所谓——锦上添花——有时间就做）、不要（Won't：刻意不做——本期范围外——明确说不）。怎么用三招：团队一起分类（防止什么都 Must）、按分类排期（Must 进本期、Should 看资源、Could 进待办、Won't 拒绝）、时间盒约束（Must 超载时 Should 降 Could——砍需求有依据）。注意：Won't 是「本期不做」不是「永远不做」——明确记录。

打个比方：装修房子的需求清单（MoSCoW 四级）——必须有（Must：水电、墙、门——没有房子不能住——不做会死——必做）；应该有（Should：地暖、新风——没有也能住，但有更舒服——不做会痛——看预算排）；可以有（Could：影音室、吧台——锦上添花——不做无所谓——有钱再做）；不要（Won't：泳池——本期不做——刻意不做——明确说不）。怎么用：①全家一起分类（每个人把需求投四级——防止「什么都必须」：孩子觉得「游戏房」必须——大家投票——游戏房是「可以有」不是「必须」）；②按分类排期（必须的先进施工、应该的看预算、可以的后置、不要的不做）；③时间盒约束（工期 3 个月固定：必须的超载了（水电要 2 个月）——把「应该的」（地暖）降级为「可以有的」（以后加）——砍需求有依据（不是「都要做」）。注意：「不要」不是永远不做（以后有钱可以建泳池——记录「本期不做」，避免「加着加着又改主意」。

30 秒电梯版：「MoSCoW 四级分类：Must Have（必须有——没有产品就不能用/核心承诺：登录/支付/核心功能——『不做会死』——进本期必做）；Should Have（应该有——重要但可推迟：没有也上线，但有更好——『不做会痛』——看资源排）；Could Have（可以有——锦上添花：有时间就做——『不做无所谓』——进待办池）；Won't Have（不要——明确不做：本期范围外——『刻意不做』——价值=明确说不：管理范围蔓延）。怎么用三招：①团队一起分类（需求清单逐条投『四级』——强制讨论：防止『什么都 Must』（人人都说自己最急——投票讨论逼出真实优先级））；②按分类排期（Must 进本期、Should 看资源、Could 进待办、Won't 明确拒绝——『Won't 的价值=明确说不：管理范围蔓延』）；③时间盒约束（周期固定：Must 超载时把 Should 降级为 Could——『砍需求有依据』（时间不够不是『都要做』，是『Should 降 Could』））。注意：Won't 不是『永远不做』是『本期不做』——明确记录（避免『悄悄加回来』——范围蔓延的防线）。」

② 为什么学 / 面试为什么考
MoSCoW 是优先级排序的「经典方法」（面试高频），面试考它的原因有三：
第一，它考「优先级基本功」。排优先级是产品经理的日常（需求永远比资源多——必须排）——MoSCoW 是最基础的优先级方法（四级分类：不做会死/会痛/无所谓/不做）——面试官想看你懂不懂「优先级的基础方法」（MoSCoW 是第一个该想到的——还有 RICE（加权评分）等，但 MoSCoW 最基础）。
第二，它考「分类思维」。MoSCoW 的本质是「按不做会怎样分类」（不做会死=必须；不做会痛=应该；不做无所谓=可以；不做=不要——分类标准是「不做会怎样」不是「感觉多重要」）——面试官想看你懂不懂「分类的标准」（优先级不是拍脑袋，是按「后果」分类——分类思维是优先级的核心）。
第三，它考「范围管理」。MoSCoW 的隐藏价值是「Won't」（明确说不：本期不做——管理范围蔓延（需求不断加——范围越来越大——永不上线））——面试官想看你懂不懂「范围管理」（敢说不、会说不——Won't 的价值=明确说不——范围蔓延的防线）。
一句话：这道题考的是「优先级基本功」＋「分类思维」＋「范围管理」。

③ 原理拆解：四级分类→三招用法→收口

第一步：Must Have（必须有）——不做会死。第一级：必须有——没有产品就不能用/核心承诺（不做产品没法上线）：登录（用户进不来——没有登录产品不能用）；支付（用户付不了钱——没有支付业务跑不通）；核心功能（产品的看家本领：外卖产品的核心是「下单」——没有下单不叫外卖产品）——分类标准「不做会死」（不做这个，产品不能用/上线不了/承诺兑现不了——后果是「死」（产品不能用=死））；排期地位：进本期必做（Must 是「本期底线」：本期上线必须包含——没有 Must，本期上线不了）。
打个比方：开餐厅（Must 必须有）——必须有：灶台（没有灶台做不了菜——产品不能用）、菜单（没有菜单客人不知道点啥——核心承诺）、收银（没有收银收不了钱——业务跑不通）——分类标准「不做会死」（没有灶台餐厅开不了——死）；排期地位：开业必做（开业的底线：没有灶台菜单收银，开业不了）。Must=不做会死+本期必做。
翻车案例：有团队把「美化」当 Must——「本期必须有炫酷的动效」——结果：动效做了（Must 资源占了）、支付流程没做完（真正的 Must 被挤掉）——上线时：用户付不了钱（核心 Must 缺失）——「假的 Must」翻车：Must 的标准是「不做会死」（支付不做=业务跑不通——死）；动效不做=还能用（只是不好看——不是 Must）——分类时要问「不做会怎样」：会死才是 Must（美化不做不会死——不是 Must）。

第二步：Should Have（应该有）——不做会痛。第二级：应该有——重要但可推迟（没有也上线，但有更好）：体验优化（搜索更快一点——没有也能用，有更好）；非核心功能（消息提醒——没有也能用，有更好）；数据报表（报表全一点——没有也能用，有更好）——分类标准「不做会痛」（不做这个，产品能用但「痛」：体验差一点/效率低一点——痛但不死）；排期地位：看资源排（Should 进「资源够就做」：资源够（人力/时间充足）——做；资源不够——推迟（Should 可以推迟：推迟不会死，只是痛）。
打个比方：开餐厅（Should 应该有）——应该有：点餐小程序（没有也能开（手写点单），有更方便——不做会痛（排队久一点——痛但不死））；儿童椅（没有也能开，有更贴心——不做会痛）；分类标准「不做会痛」（没有点餐小程序餐厅还能开——不痛只是效率低）；排期地位：看预算排（预算够——装；预算不够——推迟（点餐小程序可以后面再装——推迟不会死）。Should=不做会痛+看资源。
翻车案例：有团队把 Should 当 Must 做——「本期必须做会员系统」（Should：没有会员系统也能上线——但团队当成 Must）——会员系统做了 2 个月（挤掉资源）——核心功能（Must）延期——「Should 当 Must」翻车：Should 是「不做会痛」（会员系统不做——产品能用只是没有会员功能——痛但不死）；Must 是「不做会死」（核心功能不做——产品不能用——死）——分类错了（Should 当 Must）=资源浪费（做了「会痛」的，耽误了「会死」的）。

第三步：Could Have（可以有）——不做无所谓。第三级：可以有——锦上添花（有时间就做）：彩蛋/趣味功能（分享卡片好看一点——不做无所谓）；个性化设置（自定义主题——不做无所谓）；非核心的扩展（第三方集成（接入其他服务）——不做无所谓）——分类标准「不做无所谓」（不做这个，产品照常用——没有任何影响——无所谓）；排期地位：进待办池（Could 进 backlog（待办池）：有时间就做——不是「本期目标」是「可选项」（资源有富余——做；资源紧张——不做，完全不亏）。
打个比方：开餐厅（Could 可以有）——可以有：背景音乐（没有也能吃，有更氛围——不做无所谓）；生日灯牌（没有也正常，有更惊喜——不做无所谓）；分类标准「不做无所谓」（没有背景音乐餐厅照常营业——无所谓）；排期地位：有时间就做（周末有空——装个音响；忙——不装，不亏）。Could=不做无所谓+有时间就做。
翻车案例：有团队把 Could 提前做——「本期做 AI 彩蛋功能」（Could：锦上添花——不做无所谓）——彩蛋做了 3 周（创意好玩）——核心功能（Must）被挤（延期）——上线时：核心功能还没做完（彩蛋上线了）——「Could 提前」翻车：Could 是「有时间就做」（资源有富余才做——不挤 Must）；把 Could 提前（在 Must 没做完时做彩蛋）=资源错配（做了「无所谓的」，耽误了「会死的」）——排期铁律：Must 优先，Could 最后。

第四步：Won't Have（不要）——刻意不做。第四级：不要——明确不做（本期范围外）：超出方向的需求（和产品方向不符——不做）；成本太高的需求（要做 3 个月但价值一般——不做）；不紧急不重要的需求（既不痛也不无所谓里的「低价值」——不做）——分类标准「刻意不做」（不是「没想起来」，是「刻意」：大家讨论过、明确决定不做——Won't 是「讨论后刻意排除」）；排期地位：明确拒绝（Won't 不进本期、不进待办——直接说不）；价值=明确说不：管理范围蔓延（范围蔓延（scope creep：需求不断加——范围越来越大——产品永不上线）的防线——每期明确「不做什么」，范围才封得住）。
打个比方：开餐厅（Won't 不要）——不要：自助火锅（方向不符：做炒菜不做火锅——刻意不做）；请米其林大厨（成本太高：预算不够——不做）；外卖配送（不紧急不重要：堂食先做好——不做）——分类标准「刻意不做」（不是没想起自助火锅——是讨论过（自助火锅不适合小店）——明确决定不做）；价值=明确说不（防止范围蔓延：客人说「加个火锅吧」——有 Won't 记录：这期不做火锅（范围封住——不然今天加火锅明天加烧烤——店没完没了）。Won't=刻意不做+明确说不。
翻车案例：有团队没有 Won't（什么都不说「不做」）——需求不断加（今天老板加个功能、明天客户加个功能——都不拒绝）——半年后：范围膨胀 3 倍（原计划 10 个功能变 30 个）——永不上线（范围蔓延：什么都做=什么都做不完）——「没有 Won't」翻车：Won't 的价值=明确说不（管理范围蔓延——每期明确「不做什么」：不做火锅/不做外卖/不做米其林——范围封住）——没有 Won't=范围蔓延（需求无限加——永不上线）。

第五步：怎么用三招——①团队一起分类。第一招：团队一起分类（需求清单逐条投「四级」——不是产品一个人分（一个人分=大家不服：「凭什么你说 Must」——团队一起投：每个人有自己的理由——强制讨论（逐条讨论：这条为什么 Must？为什么 Should？——讨论逼出真实优先级——「什么都 Must」的现象：人人都说自己最急（不讨论=全是 Must——自己的需求都说急）——强制讨论（投四级+说明理由）——「什么都 Must」被讨论破除（你的需求真会死吗？——讨论下来发现不会——降级）。
打个比方：装修分类（团队一起）——不是爸爸一个人定（一个人定=妈妈不服：「凭什么你说游戏房是 Could」）——全家一起投（每条讨论：儿童房 Must？游戏房 Must？——孩子说「游戏房必须」（他急）——讨论：没有游戏房能住吗（能——不是 Must——是 Could 甚至 Won't）——强制讨论破除「什么都 Must」（自己提的都急——讨论发现不一定会死）——最后分级：儿童房 Must、游戏房 Could——全家都认（一起投的结果）。
翻车案例：有团队产品一个人分类——产品自己把 20 条需求标了级（Must 8 条）——评审时开发炸了：「8 条 Must？一个迭代（开发周期）最多做 4 条——你 8 条 Must 做不完」——产品说「我标的」——开发不认（一个人分类=大家不服）——「一个人分类」翻车：团队一起分类（逐条投四级+强制讨论——防止「什么都 Must」）——一个人分=标准是产品的主观（大家不服）+「什么都 Must」（自己标的不收敛）——一起分+讨论：8 条 Must 被讨论到 4 条（会死吗——讨论下来一半不会——降级）。

第六步：怎么用三招——②按分类排期，③时间盒约束。第二招：按分类排期（Must 进本期（本期必做：上线底线）；Should 看资源（资源够就做：人力/时间充足——做；不够——推迟）；Could 进待办（backlog（待办池）：有时间就做——不是本期目标）；Won't 明确拒绝（直接说不——不进任何排期））；第三招：时间盒约束（时间盒（timebox：固定周期——本期就这么多时间）——周期固定（一个迭代（2 周）固定——时间不会变多）；Must 超载时把 Should 降级为 Could（时间不够：不是「都要做」（都想做——时间不够——延期），是「Should 降 Could」（本期做 Must+部分 Should——超载的 Should 降级为 Could（以后做）——砍需求有依据（砍的是「Should」（会痛但不死——先砍），不砍 Must（会死——不砍）。
打个比方：装修排期（按分类排+时间盒）——按分类排：Must（水电墙门）进本期施工（必做）；Should（地暖新风）看预算（够就装）；Could（影音室）进「以后再说」清单；Won't（泳池）不排（明确不做）；时间盒约束：工期 3 个月固定（时间不会变多）；Must 超载（水电要 2.5 个月）——把 Should 降级（地暖降为「以后加」——本期装完 Must（水电墙门）再谈地暖）——砍需求有依据（砍的是 Should（没地暖能住——痛但不死）；不砍 Must（没水电不能住——死）。
翻车案例：有团队时间不够还「都要做」——迭代（开发周期）排了 8 条（Must 4+Should 4）——时间只够 5 条——团队硬做（8 条都做——加班）——延期 2 周（8 条做完——都延期）——「都要做」翻车：时间盒约束（周期固定：时间不会变多）+Must 超载时 Should 降 Could（时间不够不是「都要做」（延期——全都晚），是「Should 降 Could」（本期做 Must+部分 Should——超载的 Should 降级——砍需求有依据（砍 Should 不砍 Must））。

第七步：收口——Won't 是「本期不做」不是「永远不做」。最后的注意点：Won't 不是「永远不做」是「本期不做」——明确记录（Won't 的记录：本期不做 X（为什么：方向不符/成本太高/价值低——理由记下）；下期重新评估（本期不做 ≠ 永远不做——下期评审时 Won't 可以重新投（情况变了：成本降了/方向变了——Won't 变 Should——重新评估）；避免「悄悄加回来」（Won't 明确记录+评审时复查——防止「加着加着又回来了」：没有记录=悄悄加回来（范围蔓延的漏洞）；有记录=加回来要走评审（Won't 变其他级——要讨论——不是悄悄加）。
打个比方：装修的 Won't（本期不做）——「泳池：本期不做」（明确记录：成本太高）——不是「永远不做」（以后有钱可以建——下期重新评估（钱够了：泳池从 Won't 变 Could——重新评估）；避免「悄悄加回来」（没有记录：装修到一半「要不加个泳池吧」——加了——范围蔓延（预算爆了）；有记录：「泳池是 Won't（成本高）——要加走评审（预算够吗——够才加）——不是悄悄加）。
翻车案例：有团队的 Won't 悄悄加回来——评审时定了「不做多语言」（Won't——成本高）——开发到一半：老板说「客户想要多语言」——直接加（没走评审——悄悄加回来）——多语言做了 2 个月（挤掉 Must——延期）——「悄悄加回来」翻车：Won't 明确记录（本期不做 X+为什么）+加回来要走评审（不是悄悄加）——没有记录=悄悄加回来（范围蔓延的漏洞）；有记录=加回来走评审（Won't 变其他级——要讨论）。
小结：四级分类（Must 不做会死/Should 会痛/Could 无所谓/Won't 刻意不做）→三招用法（一起分类/按类排期/时间盒约束）→收口（Won't 是本期不做——明确记录，防悄悄加回）。

④ 对比表格：MoSCoW 四级
| 级别 | 英文 | 分类标准 | 典型 | 排期 | |------|------|------|------|------| | Must | 必须有 | 不做会死 | 登录/支付/核心功能 | 本期必做 | | Should | 应该有 | 不做会痛 | 体验优化/非核心 | 看资源排 | | Could | 可以有 | 不做无所谓 | 彩蛋/个性化 | 进待办（有时间做） | | Won't | 不要 | 刻意不做 | 方向外/成本高 | 明确拒绝（记录） |

⑤ 3+个例子：MoSCoW 实战
例子1：AI 客服产品（Must 分类）。本期需求分类：Must（AI 问答主流程——不做产品不能用；人工转接——核心承诺（答不了要转人））；Should（多轮对话——没有也能用，有更好；满意度评价）；Could（语音播报、个性语气）；Won't（多语言——本期不做，成本高）——分类后：Must 4 条进本期、Should 看资源、Could 进待办、Won't 记录。
例子2：AI 摘要产品（Should 降级）。时间盒约束：迭代（开发周期）2 周固定——Must 超载（摘要核心流程要 1.5 周+评测（评估测试）要 0.5 周——Must 满了）——Should 里的「多语言摘要」降级为 Could（本期做不完——Should 降 Could——砍需求有依据（砍 Should 不砍 Must））。
例子3：AI 简历产品（团队一起分类）。团队 5 人逐条投四级：AI 改写（5 票 Must——核心）；简历模板（3 票 Must 2 票 Should——讨论后定 Must（求职者都要模板））；AI 面试模拟（2 票 Should 3 票 Could——定 Could）；企业端功能（5 票 Won't——方向是 C 端）——一起投+讨论：分类有共识（没人不服）。
例子4：AI 推荐产品（Won't 记录）。Won't 记录：「不做社交功能——方向不符（推荐产品做内容不做社交）；不做 PC 端——成本高（先手机端）」——记录在案；下期评审复查：PC 端需求又来了——看记录（成本还是高——继续 Won't；老板说「大客户要 PC」——走评审（重新评估：成本降了还是客户重要——Won't 变 Should——走评审，不悄悄加）。

⑤b 补充板块：MoSCoW 和 RICE（加权评分）怎么配合用
MoSCoW 和 RICE（加权评分）是两套优先级方法，怎么配合：
第一，MoSCoW 先分类（定性）：先用 MoSCoW 把需求分四级（Must/Should/Could/Won't——分类：不做会怎样）——分完级，Must 一目了然（本期必做）——MoSCoW 是「第一道筛子」（先分大小：哪些必做哪些不做）。
第二，RICE 后排序（定量）：在同一级里用 RICE 排序（Must 里有 5 条——5 条先做哪条：RICE 打分（触达×影响×信心÷成本——分数高的先做）——RICE 是「第二道筛子」（同级排序：Must 内部排先后）。
第三，配合逻辑：MoSCoW 管「分级别」（定范围：这期做什么级别），RICE 管「排先后」（定顺序：同级里谁先）——先分类（MoSCoW）再排序（RICE）——两个配合，优先级又清楚又精细。
一句话：MoSCoW 先分类（哪些必做——定范围）、RICE 后排序（同级谁先——定顺序）——先分级别再排先后，优先级又清楚又精细。

⑤c 补充板块：AI 产品用 MoSCoW 的「AI 注意事项」
AI 产品用 MoSCoW，三个 AI 特有的注意：
第一，Must 要标「评测（评估测试）达标」：AI 的 Must 不只「功能做出来」，是「效果达标」（AI 问答 Must——但准确率 90%（评测集（评估测试题）算）才叫 Must 达标——效果没达标不算 Must 完成（AI 的 Must=功能+效果双达标）。
第二，降级不是砍是「能力档位」：Should 降 Could 时，AI 有「能力档位」可降（多轮对话 Should——降级：不做多轮（砍掉）或降级为「单轮+提示」（能力降档——保留部分价值）——AI 的降级多一个「档位」选择（砍功能 or 降能力）。
第三，Won't 要写「数据代价」：AI 的 Won't 记录要写「数据代价」（不做多语言——代价：多语言数据不积累（以后想做要重新攒数据——数据是时间）——Won't 的代价写清楚，决定才明智（不是「不做就完了」——是有代价的不做）。
一句话：AI 用 MoSCoW 三注意——Must 标评测达标（功能+效果双达标）、降级是能力档位（砍或降能力）、Won't 写数据代价（不做有数据损失）——三个注意补齐，AI 的 MoSCoW 才完整。

⑥ 常见误区（3个）
误区1：「Must 越多越好（需求都重要，都标 Must）。」错！Must 的标准是「不做会死」（登录/支付/核心——会死才算 Must）——「都标 Must」=没有优先级（8 条 Must 做不完——和没标一样）——分类标准严格：会死才是 Must（讨论破除「什么都 Must」）。
误区2：「Won't 就是不做（不用记录）。」错！Won't 要明确记录（本期不做 X+为什么）——不记录=悄悄加回来（范围蔓延的漏洞）；记录+评审复查（加回来走评审——Won't 变其他级要讨论）——记录是范围蔓延的防线。
误区3：「时间不够就都做（延期也要做完）。」错！时间盒约束（周期固定）+Must 超载时 Should 降 Could（时间不够不是「都要做」（延期），是「Should 降 Could」（砍 Should 不砍 Must））——延期=全晚；降级= Must 按时（砍需求有依据）。

⑦ 第一人称面试回答（3年景观设计→自学转行 AI 产品）
「我 3 年景观设计，被裁后自学转行——MoSCoW 四级分类，我做景观设计时就用过（当时不知道名字）：设计院接项目，需求清单（甲方要什么）——分级：Must（必须有：消防通道、排水——没有不能验收——不做会死）；Should（应该有：景观小品、灯光——没有也验收，有更好——不做会痛）；Could（可以有：喷泉、雕塑——锦上添花——不做无所谓）；Won't（不要：泳池——方向不符/成本高——刻意不做）。三招用法我都实践过：①团队一起分类（设计院评审会逐条投四级——防止「什么都 Must」：甲方什么都急——讨论「不做会怎样」——消防通道会死（Must）、灯光会痛（Should）——分级清楚）；②按分类排期（Must 进施工图、Should 看预算、Could 后置、Won't 明确拒绝——明确说不：不建泳池（范围蔓延防线））；③时间盒约束（工期固定：Must 超载（排水工程要 2 个月）——Should 降级（灯光降为「二期加装」——砍需求有依据）。转行学 AI 产品后，把「设计院分级」翻译成 MoSCoW：四级（Must/Should/Could/Won't）+三招（一起分/按类排/时间盒）+收口（Won't 是本期不做——明确记录防悄悄加回）——我做景观设计时分级分了 3 年，MoSCoW 我用过，不是背的。」

⑧ 小结口诀
「四级：Must 会死、Should 会痛、Could 无所谓、Won't 刻意不做；三招：一起分类（防什么都 Must）、按类排期（Must 本期/Should 看资源/Could 待办/Won't 拒绝）、时间盒（超载 Should 降 Could）；收口：Won't 是本期不做——记录防加回。」

⑨ 三轮追问（面试官深挖）
追问1：「团队分类时吵起来（你说 Must 我说 Should），怎么处理？」「用『不做会怎样』对齐：吵的不是『重要不重要』（主观——都觉得自己重要），是『不做会怎样』（客观——不做这个产品能用吗？）：『不做会死（产品不能用）→Must；会痛（能用但差）→Should；无所谓→Could』——用标准对齐：你说 Must 我说 Should——问『不做会怎样』（你的需求不做，产品能上线吗——能=不是 Must——是 Should）——标准对齐了，吵就结束了（不是嗓门，是标准）。」
追问2：「Should 和 Could 分不清（都像可推迟），怎么分？」「用『做了的价值 对比 不做的代价』分：Should（不做会痛：做了有明显价值——体验提升/效率提升——不做有代价（痛）；Could（不做无所谓：做了锦上添花——价值有但不大——不做没代价（无所谓））——判断句：『这个不做，用户会抱怨吗』（会——Should（会痛）；不会——Could（无所谓））——用户会不会抱怨，就是 Should/Could 的分界线。」
追问3：「一个迭代（开发周期）里 Must 太多做不完（老板要的 Must 就 6 条），怎么办？」「先『拆』再『砍』：拆（Must 拆开：6 条 Must 拆成『核心版 Must』（3 条：不拆就上不了线）和『增强版 Must』（3 条：拆开做——分两个迭代（开发周期））；砍（时间盒约束：一个迭代（2 周）做 3 条——老板的 6 条 Must 拆两期（这期 3 条+下期 3 条——分两期按时交付，比 6 条一起延期好）；和老板对齐（拆期的方案给老板看：6 条 Must 分两期——每期 3 条按时上——老板要的是「都做」（分两期做完了）不是「都这期做」（一起延期））——拆+砍+对齐：Must 再多也有解（拆两期）。」

⑩ 进阶加分点（说出口就加分）
加分点1：把「分类讨论」升级为「后果四问」。「团队分类时我问四个『后果问题』：不做这个，产品能用吗（会死→Must）；用户会抱怨吗（会→Should）；做完有价值吗（有→Could）；现在不做以后会后悔吗（会→再想想）——四问走完，四级自动分好（不是凭感觉投，是四个后果判断）」——「后果四问」让分类有标准（不是投票靠感觉）。
加分点2：引入「Must 预算」概念。「我会给每期定『Must 预算』：一个迭代（开发周期）最多 3-5 条 Must（产能上限：2 周做 3-5 条核心）——Must 超预算就『拆期』（拆两个迭代）——Must 预算防止『什么都 Must』（预算一框：6 条 Must 超预算——拆期——不硬塞）」——「Must 预算」是高级词（优先级有产能意识）。
加分点3：把 Won't 记录升级为「不做清单公示」。「我的 Won't 会公示：每期发布『本期不做清单』（不做 X/不做 Y/为什么——贴团队可见）——公示的价值：①透明（大家知道为什么不做什么——不再反复被问『X 怎么不做』）；②防线（公示过的不做——加回来要走评审（白纸黑字——不悄悄加））——不做清单公示=范围蔓延的『公开防线』」——「不做清单公示」说明你懂「范围管理要透明」（不做的也要让大家都知道）。

⑪ 话术库（直接抄着说）
「MoSCoW 四级：Must（不做会死：登录/支付/核心）、Should（不做会痛：体验优化）、Could（不做无所谓：彩蛋）、Won't（刻意不做：方向外/成本高）。」
「分类标准：按『不做会怎样』分，不按『感觉多重要』分——会死才是 Must。」
「三招用法：①团队一起分类（防止什么都 Must）；②按分类排期（Must 本期/Should 看资源/Could 待办/Won't 拒绝）；③时间盒约束（超载 Should 降 Could）。」
「Won't 的价值=明确说不：管理范围蔓延——每期明确『不做什么』，范围才封得住。」
「Won't 不是永远不做，是本期不做——明确记录，防悄悄加回来。」

⑫ 小白 Q&A（可能踩的坑）
Q1：MoSCoW 和 RICE（加权评分）用哪个？两个配合：MoSCoW 先分类（哪些必做——定范围：Must/Should/Could/Won't 四级），RICE 后排序（同级谁先——定顺序：Must 内部打分排先后）——先分级别再排先后（不是二选一，是两步走）。
Q2：四级分类会不会太简单（需求很复杂）？MoSCoW 简单是优点（30 秒能分类——评审会不拖）；复杂需求先拆再分（大需求拆成小需求——每个小需求再分四级）——「简单的方法+拆解」足够应付复杂（不复杂的不是需求，是不拆）。
Q3：Won't 的需求以后真的可能做吗？可能——Won't 是「本期不做」（不是永远不做）：情况变了（成本降了/方向变了/客户重要了）——下期重新评估（Won't 变 Should/Could——走评审）——Won't 记录+下期复查：既封范围（本期不做）又留余地（下期可重新评估）。

⑬ 没人告诉你的事（面试潜规则）
这道题面试官真正在听的，是「你敢不敢说不」——大部分候选人答「Must 进本期、Should 看资源」（背分级——谁都会），你说「Won't 的价值=明确说不：管理范围蔓延」（范围管理——敢于说不）——当场拉开（面试官见过太多「什么都做→永不上线」的团队——会说「不」的产品经理是宝贝）。另一个潜规则：这道题的灵魂是「分类标准」——「按『不做会怎样』分，不按『感觉多重要』分」是全场金句（分类标准是 MoSCoW 的核心——面试官追「怎么分」就是考标准）。还有一个：用「设计院项目分级」讲 MoSCoW，比背「Must/Should/Could/Won't」动人十倍——你的真实经历（传统项目的优先级分类）就是最稀缺的素材——面试官会记住「这个转行者真分过级」。

⑭ 做一件事（学完就动手）
今天把你手头「想做的事」（学习计划/副业待办/甚至装修清单都行）用 MoSCoW 分一次级：①列出所有事（10 条内）；②逐条问「不做会怎样」（会死（不做这事目标完不成）→Must；会痛（不做这事难受）→Should；无所谓→Could；刻意不做（方向外/成本高）→Won't）；③按分级排（Must 先做、Should 看时间、Could 后置、Won't 记录「为什么不」）；④定时间盒（这周就做 Must——超载的 Should 降 Could）——做完你会发现：优先级清晰了，焦虑少了（分级就是减负）。

⑮ 求职助手联系（面试前必做）
面试前用本卡做 3 件事：①把「四级+三招」练熟（面试框架：Must/Should/Could/Won't+一起分类/按类排期/时间盒）；②准备你的「分级」案例（设计院项目分级——真实经历最动人）；③把「Won't 的价值=明确说不：管理范围蔓延」练熟（收口金句）。面试被问「MoSCoW 法则」时：先说四级（会死/会痛/无所谓/刻意不做）→再说三招（一起分类/按类排期/时间盒）→收口（Won't 是本期不做——明确记录）——分级清楚+三招齐全+金句收口，面试官立刻记住你。

⑯ 练习（自己测一遍）
1.（分类）「登录功能」属于 MoSCoW 哪一级？——答案：Must（不做产品不能用——不做会死）。
2.（三招）「时间盒约束」的具体做法是？——答案：周期固定；Must 超载时把 Should 降级为 Could（砍需求有依据——砍 Should 不砍 Must）。
3.（角色）面试官追问「Won't 和砍掉有什么区别」，你怎么回答？——参考答案：「Won't 是『本期不做』不是『永远不做』：明确记录（不做 X+为什么——成本高/方向不符）；下期重新评估（情况变了：成本降了/方向变了——Won't 变 Should/Could——走评审）——区别：砍掉是消失（没有记录——悄悄加回来也没人知道），Won't 是『记录在案的本期不做』（加回来要走评审——范围蔓延的防线）。」

需求池管理


图怎么读：如何管理需求池（backlog：产品需求的总清单）——六步机制：①统一入口——所有需求进一个池子（表格/看板（可视化的任务板）：用户反馈/业务提的/自己发现的——「收到需求先入池，不口头承诺」（口头答应不算，进池子才算））；②字段标准化——每条需求记录：来源（谁提的）/描述（做什么）/价值（解决什么问题）/优先级打分（RICE（加权评分）：触达×影响×信心÷成本）/状态（待评审/已排期/开发中/已上线/已拒绝——需求有生命周期）；③定期评审——每周/双周需求评审会：新需求过一遍（价值判断+优先级排序——「评审会的产出=优先级共识」（大家同意先做什么——不吵不内耗））；④排期机制——评审通过的需求按优先级进迭代（开发周期）（和 Roadmap（路线图：开发计划表）联动——不脱节）；⑤清理机制——需求池要「瘦身」：过期需求（3 个月没人要）标记/删除、已拒绝的注明理由（「拒绝理由」是资产：下次不用重新吵——再提时直接看上次为什么拒）；⑥数据说话——需求池的数据（各来源占比/拒绝率/平均处理时长）反哺「需求管理质量」（哪个来源需求最多/拒绝太多=需求质量差/处理太慢=池子堵——数据发现问题再调整）。收口：需求池的核心价值=「把需求管理从口头变成系统」——每条需求有去处、有状态、有结论（不再丢需求、不再靠记忆、不再口头承诺）。

① 一句话大白话定义
这道题问的是：需求池（所有待做需求的清单）怎么管理？
用大白话说：需求池就是「需求的收件箱+看板」——六步：①统一入口（所有需求进一个池子——「收到需求先入池，不口头承诺」）；②字段标准化（每条记：来源/描述/价值/优先级打分/状态）；③定期评审（每周/双周评审会——产出优先级共识）；④排期机制（按优先级进迭代，和路线图联动）；⑤清理机制（过期标记/删除、拒绝注明理由——理由=资产）；⑥数据说话（需求池的数据反哺管理质量）。一句话：把需求管理从口头变成系统——每条需求有去处、有状态、有结论。

打个比方：家庭「待办清单」（需求池）——以前：妈妈说「记得买酱油」（口头）、爸爸说「周末修一下灯」（口头）、孩子说「想要新书包」（口头）——过一周：买酱油忘了、修灯忘了、书包也忘了（口头需求全丢——聊天记录里找不着）——现在建「待办清单」（需求池）：①统一入口（所有事写进一张清单——「说了就记，不记不算」）；②每条记清（谁提的/什么事/急不急/做没做——字段标准化）；③每周六家庭会过一遍（新事一起商量——评审）；④排好顺序（先做急的——排期）；⑤清理（3 个月没做的事划掉、不做的事注明「为什么不」（下次不用再吵——理由=资产））；⑥看看数据（这半年「买东西」的事最多——以后购物单单独建（数据反哺））——清单一建：丢事没了、吵架少了、全家不乱（口头变系统）。

30 秒电梯版：「需求池六步：①统一入口——所有需求进一个池子（表格/看板：用户反馈/业务提的/自己发现的——『收到需求先入池，不口头承诺』（口头答应不算，进池子才算））；②字段标准化——每条需求记录：来源/描述/价值（解决什么问题）/优先级打分（RICE（加权评分）：触达×影响×信心÷成本）/状态（待评审/已排期/开发中/已上线/已拒绝）；③定期评审——每周/双周需求评审会：新需求过一遍（价值判断+优先级排序——『评审会的产出=优先级共识』（大家同意先做什么——不吵不内耗））；④排期机制——评审通过的需求按优先级进迭代（开发周期）（和 Roadmap（路线图）联动——不脱节）；⑤清理机制——需求池要『瘦身』：过期需求（3 个月没人要）标记/删除、已拒绝的注明理由（『拒绝理由』是资产：下次不用重新吵——再提时直接看上次为什么拒）；⑥数据说话——需求池的数据（各来源占比/拒绝率/平均处理时长）反哺『需求管理质量』（哪个来源需求最多/拒绝太多=需求质量差/处理太慢=池子堵——数据发现问题再调整）。收口：需求池的核心价值=『把需求管理从口头变成系统』——每条需求有去处、有状态、有结论——不再丢需求、不再靠记忆、不再口头承诺。」

② 为什么学 / 面试为什么考
需求池管理是产品经理的「日常基本功」（每天都在用），面试考它的原因有三：
第一，它考「系统性思维」。需求池不是「记需求的表格」，是「需求的系统」（入口/字段/评审/排期/清理/数据——六步闭环）——面试官想看你懂不懂「把零散的需求管理成系统」（不靠记忆、不靠口头——靠机制）——系统性思维（把「人管」变成「机制管」）是产品经理和「打杂的人」的分水岭。
第二，它考「落地细节」。需求池人人会说（「记下来」），细节见高下（入口统一吗/字段全吗/评审定期吗/清理有标准吗——细节决定需求池活不活）——面试官想看你懂不懂「需求池的具体机制」（六步：入口/字段/评审/排期/清理/数据——每步有具体做法）。
第三，它考「AI 产品适配」。AI 产品的需求池和传统有差别（AI 需求要标「模型能力依赖/评测（评估测试）标准」；需求池要联动「数据飞轮」（数据贡献维度））——面试官想看你懂不懂「AI 需求池的特有字段」（传统字段+AI 字段：能力依赖/评测/数据贡献——AI 产品的需求池不只是传统需求池）。
一句话：这道题考的是「系统性思维」＋「落地细节」＋「AI 产品适配」。

③ 原理拆解：六步机制→收口

第一步：①统一入口——所有需求进一个池子。需求池的第一步：统一入口——所有需求（用户反馈、业务提的、自己发现的、老板提的）都进「一个池子」（一个表格/看板（可视化任务板）——不是多个（销售一个群、客服一个表、自己一个本子——三个入口=需求三分天下——丢一半）；「收到需求先入池，不口头承诺」（别人口头提需求——不口头答应（「好的，我记一下」不算）——入池（「我记到需求池了，评审后回复你」——进池子才算数）——为什么：口头承诺=需求容易丢（「我上次跟你说过」——聊天记录里找不着）＋没记录没优先级（口头需求无法排序——所有人的需求都是「最急的」）；统一入口=需求不丢（所有需求在一个池子——找得着）＋有据可查（什么时候提的、谁提的——记录在案）。
打个比方：家里的「待办清单」统一入口——以前：妈妈说「买酱油」记自己脑子里、爸爸说「修灯」记手机备忘录、孩子说「书包」记小本本（三个入口）——买酱油忘了（妈妈以为爸爸记了、爸爸以为妈妈记了——三个入口=都以为别人记了）——现在：全家一张清单（统一入口）——「说了就记到清单」（不口头答应——「说完了吗？我记上了」）——买酱油（清单上有一—忘不了）、修灯（清单上有——丢不了）、书包（清单上有——跑不掉）——统一入口：需求不丢+有据可查。
翻车案例：有团队需求「三个入口」——销售在群里提（聊天记录）、客服在表格记（客服的表）、产品自己记本子（自己的本）——季度末：三个入口各有一批需求（互相不知道）——销售说「我提的 AI 客服功能呢」（在群里——产品没看到）、客服说「我记的退款优化呢」（在客服的表——产品没收到）——需求丢了一半（三个入口=需求三分天下）——「多入口」翻车：统一入口（所有需求进一个池子）+「收到需求先入池，不口头承诺」——入口统一，需求才不丢。

第二步：②字段标准化——每条需求记录全。需求池的第二步：字段标准化——每条需求记录五个字段：来源（谁提的：用户反馈/业务/自己/老板——追源（有问题找提出人））；描述（做什么：一句话说清——「AI 客服自动回复退款问题」）；价值（解决什么问题：为谁解决什么——「商家回复慢：回复及时率从 40% 到 80%」——价值不写=需求没意义）；优先级打分（RICE（加权评分）：触达×影响×信心÷成本——打分排位——优先级不是「感觉」是「分数」）；状态（待评审/已排期/开发中/已上线/已拒绝——需求有生命周期：走到哪一步一目了然）——字段标准化为什么重要：没字段=需求信息不全（「做个 AI 功能」——来源没有/价值没有/优先级没有——评审没法评（没来源没价值——评什么））；字段齐全=评审有依据（来源/价值/优先级/状态——评审 30 秒看清一条需求）。
打个比方：家里的「待办清单」字段标准化——以前：清单只写「买东西」（没写买什么、给谁买、急不急）——家人看不懂（买什么？谁的事？什么时候要？）；现在每条记全：「买酱油——妈妈提的（来源）——做菜用（描述）——今晚用（价值）——急（优先级）——没买（状态）」——字段齐全：谁提的/干什么/为什么/多急/做没做——一目了然（全家看得懂）。需求池同理：五字段（来源/描述/价值/优先级/状态）记全——评审有依据。
翻车案例：有团队需求池没字段（一行一条：「AI 客服」「AI 摘要」「做推荐」）——评审会：第一条「AI 客服」——谁提的？（不知道）；解决什么？（不知道）；多急？（不知道）——评审没法评（没信息）——会开完：三条需求全「待定」（没信息没法定）——「没字段」翻车：字段标准化（来源/描述/价值/优先级打分/状态——五字段）——没字段=评审没依据（信息不全没法评——需求全待定）。

第三步：③定期评审——评审会的产出是优先级共识。需求池的第三步：定期评审——每周/双周一次需求评审会（固定节奏：不是「有需求才开」（不定期的会=永远不开——需求积压），是「固定时间开」（每周五 30 分钟——固定节奏，需求不过夜））；评审会做什么：新需求过一遍（价值判断（这个需求值得做吗——价值数据说话）+优先级排序（和已有需求比：谁先谁后——RICE（加权评分）分数排位））；评审会的产出=优先级共识（大家同意「先做什么、后做什么」——共识（不是产品一个人定：开发/运营都同意——没有共识=排期打架））——不吵不内耗（有共识，团队不内耗）。
打个比方：家里的「每周六家庭会」（定期评审）——固定每周六上午（定期：不是「有事才开」——有事才开=永远不开）；会上做什么：新事过一遍（「孩子要书包」——值得买吗（价值判断：旧书包破了——值得）+和已有事比（买书包 对比 修灯——哪个先（优先级排序：书包急（要开学）——先买）））；产出=全家共识（都说「先买书包」——共识：不吵了（没共识=妈妈要买书包、爸爸要修灯——打架））——定期评审：固定节奏+产出共识（不吵不内耗）。
翻车案例：有团队「有事才开会」（不定期）——两个月没开评审会（需求积压 40 条）——开发问「下个迭代做什么」（没人排过优先级——40 条需求没有顺序）——临时拉会（40 条过一遍——3 小时）——吵（每条都说自己急——没有优先级共识）——「不定期」翻车：定期评审（每周/双周固定开——需求不过夜）+产出=优先级共识（大家同意先做什么）——不定期=需求积压+排期打架（40 条没顺序——谁都说自己急）。

第四步：④排期机制——按优先级进迭代，和路线图联动。需求池的第四步：排期机制——评审通过的需求按优先级进迭代（开发周期：一个迭代（2 周）做 3-5 条——按 RICE（加权评分）分数从高到低排进迭代（分数高的先进——先做影响大的）；和 Roadmap（路线图：开发计划表）联动（不脱节）：需求池的需求排期跟 Roadmap 走（Roadmap 说这季度做「客服」——需求池里「客服相关」的需求先进迭代——需求池和路线图对齐（不脱节：路线图规划方向、需求池排具体需求——两个对不上=乱套（路线图说做客服、需求池排了一堆摘要——脱节））。
打个比方：家里清单排期（排期机制）——清单的事按「急不急」排（优先级）：开学要用的书包先进「本周计划」（按优先级进近期计划）；和「年度计划」对齐（家里年度计划说「暑假装修儿童房」——清单里「儿童房相关」的事先进计划（联动——不脱节：年度计划定方向（装修儿童房）、清单排具体事（买床/买柜/刷墙）——两个对不上=乱套（年度计划说装修儿童房、清单排了一堆旅游——脱节））。需求池同理：按优先级进迭代+和路线图联动。
翻车案例：有团队需求池和路线图「两张皮」——Roadmap（路线图）写「Q2 做 AI 客服」——需求池排的却是「AI 摘要」（排期没按路线图）——Q2 到：开发做了摘要（需求池排的）、客服没做（路线图写的）——老板问「客服呢」——开发说「池子没排」——「两张皮」翻车：排期机制要「和 Roadmap（路线图）联动」（路线图定方向（客服）、需求池排具体（客服相关需求先进）——两个对齐——不脱节：方向（路线图）和具体（需求池）对不上=乱套。

第五步：⑤清理机制——过期标记/删除、拒绝注明理由。需求池的第五步：清理机制——需求池要「瘦身」（池子会膨胀：需求只进不出=池子越来越堵（评审 3 小时过不完）——定期瘦身）：过期需求（3 个月没人要——标记/删除（3 个月没排上=大概率不重要（重要的早排上了）——标记（待清理）或删除）；已拒绝的注明理由（「拒绝理由」是资产：为什么拒（价值不够/技术不支持/和方向不符——记下来）——下次有人再提（「这个需求做一下」——直接看上次为什么拒——不用重新吵（理由=资产：省一次吵架））。
打个比方：家里清单瘦身（清理机制）——3 个月没做的事（「学钢琴」说了 3 个月没动——标记（还学吗？不学划掉——过期标记/删除）；不做的事注明理由（「不养狗」——孩子再提「养狗」——直接说「上次为什么不养」（家里没人遛——理由在——不用重新吵一遍）——理由=资产：省一次吵架）。需求池同理：过期标记/删除+拒绝注明理由（理由=资产——下次不用重新吵）。
翻车案例：有团队需求池「只进不出」——两年攒了 300 条（只进不出——池子膨胀）——评审会 3 小时过不完（300 条）——没人敢删（每条都「可能有用」）——池子彻底堵死（评审失焦：看完前面忘了后面）——「只进不出」翻车：清理机制（过期 3 个月标记/删除+拒绝注明理由（理由=资产））——只进不出=池子膨胀（300 条没法评审——评审失焦）——定期清理（瘦身），池子才活。

第六步：⑥数据说话——需求池的数据反哺管理质量。需求池的第六步：数据说话——需求池不只是「记录工具」，还是「数据源」——看三个数：各来源占比（需求从哪来最多——用户反馈 60%？业务 30%？自己 10%？（来源占比失衡：全是业务提的=没在听用户——调整：多听用户））；拒绝率（拒绝的需求占比——拒绝率太高（>50%）=需求质量差（提的需求大多没价值——调整：评审标准太严？还是提需求的人不靠谱——加强需求指导）；拒绝率太低（<10%）=评审太松（什么都过——调整：严一点））；平均处理时长（需求从进池到排期多久——处理太慢（>2 个月）=池子堵（评审/排期流程有问题——调整：加快评审节奏））——三个数每月看一次，需求管理质量数据说话（发现问题→调整机制——数据反哺）。
打个比方：家里清单看数据（数据说话）——半年看一次三个数：各来源占比（「买东西」的事占 60%——购物单太多——调整：单独建「购物单」，清单留大事）；拒绝率（半年拒绝了 30% 的事——孩子提的「买玩具」占一半——调整：和孩子说清「什么可以提」）；平均处理时长（事从记上到做完平均 2 个月——太慢——调整：每周家庭会过一遍（加快节奏））——三个数每月看：清单管得好不好数据说话。需求池同理：三个数（来源占比/拒绝率/处理时长）——数据反哺。
翻车案例：有团队需求池「只记不看」（记录了从不用数据）——两年后：需求池 300 条（从没看过数据）——实际上：业务提的需求占 80%（用户反馈没人管——用户需求积压）——「只记不看」翻车：需求池要「数据说话」（各来源占比（需求从哪来最多——来源失衡就调整）/拒绝率（拒绝太多=需求质量差——加强指导）/平均处理时长（处理太慢=池子堵——加快节奏）——三个数每月看：数据反哺管理质量——只记不看=问题永远发现不了。

第七步：收口——把需求管理从口头变成系统。全流程的收口：需求池的核心价值=「把需求管理从口头变成系统」——口头管理（需求在聊天记录里：用户说的/业务说的/老板说的——都在聊天里——丢（翻聊天记录找需求）、忘（口头答应忘了）、乱（优先级靠嗓门——谁说的大声先做谁））；系统管理（需求在池子里：有去处（统一入口——进池子）、有状态（字段标准化——待评审/开发中/已上线）、有结论（定期评审+清理——做/不做/为什么不做）——不丢（都在池子——找得着）、不忘（有状态——走到哪了）、不乱（有优先级——分数排位））——从口头到系统，是需求池的灵魂。
打个比方：口头管理 对比 清单管理（收口）——口头管理（以前）：全家的要求都在聊天里（妈妈在客厅说、爸爸在电话里说、孩子在群里说——丢：买酱油忘了（在聊天里找不着）、忘：修灯口头答应忘了、乱：都觉得自己最急）——清单管理（现在）：都在清单上（有去处：说了就记；有状态：做没做写着；有结论：做/不做/为什么——不丢（清单找得着）、不忘（状态写着）、不乱（急不急排着））——从口头到清单：全家不乱。需求池同理：从口头到系统（有去处/有状态/有结论）。
翻车案例：有团队需求全在聊天记录里（口头管理）——用户提的（在客服群里）、老板提的（在微信里）、销售提的（在销售群里）——需求散在三个聊天工具（丢：用户提的「退款优化」沉到聊天记录底——找不着；忘：老板提的「做个 AI 功能」口头答应——忘了）——半年后：老板问「我说做的 AI 功能呢」（忘——口头答应的没记录）——「口头管理」翻车：需求池核心价值=把需求管理从口头变成系统（统一入口（进池子）+字段（有状态）+评审排期（有结论）——不丢不忘不乱）——口头管理（聊天记录）=丢忘乱（需求沉底、口头答应、嗓门优先）。
小结：六步机制（统一入口/字段标准化/定期评审/排期机制/清理机制/数据说话）→收口（把需求管理从口头变成系统：有去处/有状态/有结论）。

④ 对比表格：口头管理 对比 系统管理（需求池）
| 维度 | 口头管理（踩坑） | 系统管理（需求池） | |------|------|------| | 需求在哪 | 聊天记录（三个群） | 一个池子（表格/看板） | | 记录 | 口头答应（忘了） | 统一入口（说了就记） | | 字段 | 无（一句话需求） | 五字段（来源/描述/价值/优先级/状态） | | 优先级 | 嗓门（谁说的大声先做谁） | 打分（RICE（加权评分）分数排位） | | 评审 | 有事才开（永远不开） | 定期（每周/双周固定开） | | 清理 | 只进不出（300 条膨胀） | 定期瘦身（过期删/拒绝记理由） | | 数据 | 从不看（问题发现不了） | 三数（来源占比/拒绝率/处理时长） | | 结果 | 丢需求、忘承诺、乱优先级 | 有去处、有状态、有结论 |

⑤ 3+个例子：需求池管理实战
例子1：AI 客服团队的需求池（统一入口）。团队需求三个入口（销售群/客服表/产品本子）——需求丢一半——调整：统一入口（一个表格：所有需求进同一个表——「收到需求先入池，不口头承诺」）——三个月后：需求不丢了（都在一个表——找得着）、追源方便（来源字段——谁提的查得到）。
例子2：需求评审会（定期评审）。每周五 30 分钟评审会：新需求过一遍（价值判断：带价值数据（影响多少用户））+优先级排序（和已有需求比：RICE（加权评分）分数排位）——产出=优先级共识（大家同意先做什么）——团队不吵了（有共识——排期不打架）。
例子3：AI 摘要需求被拒（拒绝理由=资产）。「AI 摘要」需求评审时被拒（理由：和核心方向（简历优化）不符——技术也要 3 个月）——三个月后销售又提「AI 摘要」（再提）——产品直接看「上次拒绝理由」（方向不符+成本高——现在方向还是简历优化、成本还是 3 个月——仍然不做）——不用重新吵（理由=资产：省一次吵架）。
例子4：需求池数据发现问题（数据说话）。月度看三个数：来源占比（业务提的 70%——用户反馈没在管——调整：加「用户反馈」收集渠道）；拒绝率（55%——需求质量差——调整：评审前先让提需求的人补价值数据）；处理时长（平均 3 个月——池子堵——调整：评审会从双周改每周）——三个数发现问题→调整机制（数据反哺）。

⑤b 补充板块：AI 需求池的「特有字段」——AI 需求比传统多记什么
AI 产品的需求池，除了传统五字段（来源/描述/价值/优先级/状态），还多四个「AI 特有字段」：
第一，能力依赖（这个需求靠模型什么本事：摘要需求依赖「长文本理解」模型——依赖写清楚，排期看能力（能力没到位，需求排不上——排期依据）。
第二，评测标准（怎么算做成了：摘要需求——准确率 90%（按评测集（评估测试题）X 算）——评测标准写清，验收有依据（AI 需求「做成了」必须有评测（评估测试）标准——不是「感觉好了」）。
第三，数据需求（这个需求要什么数据：摘要需求——长文样本 500 条、谁标、多久更新——数据需求写清，开发不卡壳（AI 需求没有数据=做不了——数据提前备）。
第四，数据贡献（这个需求能带来什么数据：摘要需求——用户摘要行为数据（喂给模型——模型变好——飞轮）——数据贡献标出，优先级加分（能养数据的需求优先——飞轮思维）。
一句话：AI 需求池 = 传统五字段（来源/描述/价值/优先级/状态）+ AI 四字段（能力依赖/评测标准/数据需求/数据贡献）——AI 需求多记四个字段，排期不踩坑（能力/评测/数据全看清）。

⑤c 补充板块：需求池工具怎么选（表格还是看板）
需求池用什么工具（表格 对比 看板）——按团队选：
第一，小团队（5 人内）：表格（Excel/在线表格）——够用（五字段+排序——表格就够）；简单（不用学新工具——打开就能用）；灵活（想加字段就加——轻量）。
第二，大团队（10 人+）：看板（项目管理工具）——状态可视化（待评审/开发中/已上线——看板列一目了然）；协作方便（多人同时操作+评论——大团队需要）；自动统计（数据字段自动汇总——数据说话省事）。
第三，选择标准：工具跟团队走（小团队表格（简单够用）、大团队看板（协作统计）——不是工具越高级越好，是「团队用得起」最好（表格用得好的团队 > 看板用得烂的团队——工具是壳，机制是芯）。
一句话：工具选择：小团队表格（简单）、大团队看板（协作）——关键是「用得起」（机制（六步）是芯，工具（表格/看板）是壳——机制好，什么工具都行）。

⑥ 常见误区（3个）
误区1：「需求池就是个记需求的表格。」错！需求池是「需求的系统」（六步：入口/字段/评审/排期/清理/数据——闭环）——只当表格用（记下来就不管）=需求池名存实亡（记了没人评、排了没人做——表格变废纸）——系统思维（六步闭环）才是需求池。
误区2：「需求记得越多越好（全记上）。」错！需求池要「瘦身」（过期标记/删除+拒绝注明理由——理由=资产）——全记上=池子膨胀（300 条没法评审——评审失焦）——「记有价值+定期清理」才是对的（过滤器不是仓库）。
误区3：「AI 需求池和传统一样（记需求就行）。」错！AI 需求池多四个字段（能力依赖/评测标准/数据需求/数据贡献）——只记传统字段（来源/描述/价值）=AI 需求排期踩坑（能力没到位排了（做不了）/评测没有（验收不了）/数据没备（开发卡壳）——AI 四字段补齐，AI 需求池才完整。

⑦ 第一人称面试回答（3年景观设计→自学转行 AI 产品）
「我 3 年景观设计，被裁后自学转行——需求池的系统化管理，我做景观设计时有真实实践：设计院有个「项目台账」（所有项目的登记表：跟需求池一样）——以前是「口头管理」：甲方电话提需求（口头）、领导开会说（口头）——需求丢过：甲方说「绿化加两棵银杏」——没记（口头）——验收时甲方问「银杏呢」——找不到记录（翻聊天记录没有）——被罚整改（口头管理的代价）。后来建「项目台账」（需求池）：①统一入口（所有甲方需求进台账——「说了就记，口头不算」）；②字段标准化（甲方/需求/位置/时间/状态——五字段）；③每周例会过一遍（定期评审）；④按项目进度排（排期）；⑤验收后关闭+拒绝的注明理由（「甲方要求的不合理项」记理由——下次不吵）；⑥看数据（哪类改动最多——绿化 60%——以后报价时绿化部分多留余地——数据反哺）。转行学 AI 产品后，把「项目台账」翻译成「需求池」：六步（统一入口/字段标准化/定期评审/排期机制/清理机制/数据说话）+收口（把需求管理从口头变成系统——有去处/有状态/有结论）+AI 特有字段（能力依赖/评测标准/数据需求/数据贡献）——我做景观设计时用项目台账吃了亏也得了益，需求池的坑和值我都懂。」

⑧ 小结口诀
「六步：统一入口（进池子）、字段标准化（记全）、定期评审（共识）、排期联动（路线图）、清理瘦身（理由=资产）、数据说话（三数反哺）——收口：从口头变系统，有去处/有状态/有结论。」

⑨ 三轮追问（面试官深挖）
追问1：「老板直接说『这个需求明天就要』，怎么处理？」「先入池再谈：礼貌确认——『好的，我记到需求池，标记最高优先级，马上安排评审』（入池：有记录）；再排期——『要 3 天还是 3 周？我看了下，明天来不及（开发 3 天），我安排最快路径：明天先出方案、3 天内上线』（给现实：不空口答应）；复盘——事后看这个需求真的急吗（真急（生产事故级）：机制上给「紧急通道」；伪急（老板随口说）：复盘时和老板对齐「紧急需求的成本」（每次插队都打断迭代——插队成本说清楚））——老板的需求也要入池（记录）——入池不是拒绝，是「有序处理」。」
追问2：「需求池和路线图（Roadmap）怎么联动（两个表对不上怎么办）？」「两个表一个方向：路线图管「方向」（这季度做客服——方向性规划）、需求池管「具体」（客服相关需求排期——具体执行）——对不上就「对齐」：每周评审时对照路线图（这季度方向是客服——池子里「摘要」需求排不排？（和方向不符——推迟到路线图调整时再评））；路线图调整时同步筛池子（路线图变了（客服改摘要）——池子重新排（客服需求降级、摘要需求升级））——联动机制：评审对方向、方向变筛池——两个表永远对齐。」
追问3：「需求池谁管（产品一个人还是团队一起）？」「产品是「池长」（负责机制：入口/字段/评审/清理——机制的维护者），团队是「参与者」（都往里提需求——提需求是所有人的事（销售提客户需求、客服提用户反馈、开发提技术优化——人人能提）；评审是团队的会（不是产品一个人定——优先级共识要团队一起达成）；但「最终排期」产品拍板（共识之后，产品做最终决定（分歧时产品升级决策））——角色分工：产品管机制+拍板、团队管输入+共识——需求池是团队的池子，不是产品一个人的。」

⑩ 进阶加分点（说出口就加分）
加分点1：把需求池和「数据回流」挂钩。「AI 产品的需求池有个传统没有的『自我造血』：AI 需求上线后会自动回流数据（用户反馈/新对话样本——数据回流）——回流数据里藏着新需求（用户问的新问题=新需求的素材）——所以我会在需求池加『回流来源』字段：每条需求标注是否来自数据回流（回流需求=需求池的自我造血——AI 产品的需求池越用越有料，不是用一条少一条）」——「数据回流」一说出口，你就是懂 AI 产品长期逻辑的人。
加分点2：引入「池子饱和度」监控。「我会看需求池的『饱和度』：池子容量（近期池 10 条）×当前已排期数——饱和度超 80%=排期过载预警（池子快满=团队要超载——提前砍/延期）；饱和度低于 30%=排期不足（池子太空=团队要闲置——提前补需求）——饱和度是池子的『油表』（满和空都要调——不是越满越好也不是越空越好）」——「需求健康度」是高级词（管理有量化指标）。
加分点3：把「状态流转」做成可视化。「需求池的状态（待评审/已排期/开发中/已上线/已拒绝）我会做成可视化流转（看板列：需求卡片从『待评审』拖到『已上线』——全程看得见）——状态流转可视化的价值：①团队一眼看到需求走到哪（不用问『X 需求呢』——看板自己会答）；②卡住的需求自动暴露（某列堆积=那一步卡住——及时处理）——状态可视化让需求池『活』在眼前（不是躺在表格里）

⑪ 话术库（直接抄着说）
「需求池六步：统一入口（进池子，不口头承诺）→字段标准化（五字段）→定期评审（共识）→排期联动（路线图）→清理瘦身（理由=资产）→数据说话（三数反哺）。」
「收到需求先入池，不口头承诺——口头答应不算，进池子才算。」
「评审会的产出=优先级共识——大家同意先做什么，不吵不内耗。」
「拒绝理由=资产：下次有人再提，直接看上次为什么拒——不用重新吵。」
「需求池核心价值：把需求管理从口头变成系统——每条需求有去处、有状态、有结论。」

⑫ 小白 Q&A（可能踩的坑）
Q1：需求池用什么工具开始（我不会用项目管理软件）？从「在线表格」开始（Excel/在线表格——五字段一行一条：来源/描述/价值/优先级/状态——表格就够）；用熟了再升级（看板（可视化任务板）——团队大了再说）——工具不是门槛（表格就能管需求池），机制才是（六步——机制用起来，表格也够）。
Q2：RICE（加权评分）打分不会算怎么办？RICE 是四个数（触达：影响多少人；影响：提升多大；信心：把握多大；成本：要多少工作量——触达×影响×信心÷成本）——不用算太细（大概分就行：影响大×把握大÷成本小=先做）——练法：拿你手头 3 件事各打一次分，排个序——练一次就会。
Q3：评审会同事都不来（不重视）怎么办？先让评审会有「产出」：每场会结束发「评审纪要」（本次定了什么：X 做、Y 不做、Z 下次——有结论，同事看到「会没白开」才来）；再让评审会有「时效」（定好的排期同步给大家：评审会 30 分钟——不拖堂）；坚持 3 次——有产出有时效，同事自然来（不来的原因通常是「开了没结果」——有结果就有人）。

⑬ 没人告诉你的事（面试潜规则）
这道题面试官真正在听的，是「你有没有被需求坑过」——说「需求丢过」（口头管理的代价：翻聊天记录找不着）、「拒绝理由省吵架」（经验：被同一个人反复提过需求）——细节越具体，说明真管过需求池（背书「记需求排期」=没管过）。另一个潜规则：这道题的加分点是「六步闭环」——大部分候选人答「记需求、排优先级」（两步），你说「六步」（入口/字段/评审/排期/清理/数据——闭环）——说明你懂「需求池是系统不是表格」（从收集到数据反哺全链路）。还有一个：用「设计院项目台账」讲需求池，比背「统一入口/字段标准化」动人十倍——你的真实经历（传统台账的坑和值：丢过需求、被罚过整改）就是最稀缺的素材——面试官会记住「这个转行者真被需求坑过」。

⑭ 做一件事（学完就动手）
今天给你手头「想做的事」（学习计划/副业想法/甚至家里的待办）建一个「需求池」：①统一入口（全写进一张表格——「说了就记」）；②五字段（来源/描述/价值/优先级/状态）；③定评审时间（每周固定 10 分钟过一遍）；④按优先级排（分数高的先做）；⑤定清理规则（3 个月没动=标记/划掉、不做的注明理由）；⑥月底看三个数（哪类最多/拒了多少/拖了多久）——一个月后你会发现：你的「待办池」从混乱变系统（不丢、不忘、不乱）。

⑮ 求职助手联系（面试前必做）
面试前用本卡做 3 件事：①把「六步机制」练熟（面试框架：入口/字段/评审/排期/清理/数据）；②准备你的「需求池」案例（设计院项目台账——真实经历最动人）；③把「把需求管理从口头变成系统」练熟（收口金句）。面试被问「如何管理需求池」时：先说六步（统一入口→字段→评审→排期→清理→数据）→再说收口（有去处/有状态/有结论）→加 AI 特有字段（能力依赖/评测/数据）——六步完整+经历真实+AI 适配到位，面试官立刻记住你。

⑯ 练习（自己测一遍）
1.（排序）需求池六步的正确顺序？A 统一入口→字段→评审→排期→清理→数据；B 评审→入口→数据→排期→字段→清理——答案：A。
2.（字段）需求池五字段是哪五个？——答案：来源/描述/价值/优先级打分（RICE（加权评分））/状态。
3.（角色）面试官追问「AI 需求池比传统多记什么」，你怎么回答？——参考答案：「多四个 AI 特有字段：能力依赖（靠模型什么本事——排期看能力）、评测标准（怎么算做成了——准确率 90% 按评测集（评估测试题）算）、数据需求（要什么数据——没有数据做不了）、数据贡献（能带来什么数据——能养数据的需求优先——数据飞轮）。」

PRD 找问题


图怎么读：给一个 PRD（产品需求文档）找问题并给改进建议——核心是「PRD 评审五查清单」：①查价值——需求为什么做（有没有「用户场景+业务目标」——只写功能不写价值的 PRD 是需求清单不是 PRD（没写「为谁解决什么问题」=没价值的清单））；②查场景——用户流程完整吗（主流程+异常流程：用户中途退出怎么办/失败怎么办——「只写 happy path（顺利路径：一切顺利的流程）的 PRD 一定有坑」）；③查边界——边界条件清楚吗（空数据/超长文本/并发（同时很多用户操作）/权限——边界写没写（边界没写=上线就崩））；④查验收——指标可测吗（「提升体验」不是验收——「回复率提升 5%」才是；验收标准=上线怎么判断成功（可量化的数字））；⑤查可行——技术/成本/依赖（实现方案可行吗/依赖谁/风险）。改进建议格式：问题（位置+现象）→影响（为什么是问题）→建议（怎么改）——按严重度排序（致命问题（逻辑不通）>重要（边界缺失）>建议（可优化））。收口：评审不是找茬，是「帮 PRD 变完整」——五查过一遍+建议格式标准+严重度排序，评审会变成「一起把文档补完整」。

① 一句话大白话定义
这道题问的是：给一份 PRD（产品需求文档）找问题（哪里写得不对、哪里漏了）并给改进建议（怎么改）——怎么做？
用大白话说：按「五查清单」找问题：①查价值（为什么做——有用户场景和业务目标吗）；②查场景（用户流程完整吗——异常流程（出问题时怎么办）写了吗）；③查边界（边界条件清楚吗——空数据/超长文本/并发/权限）；④查验收（指标可测吗——「提升体验」不算，「回复率提升 5%」才算）；⑤查可行（技术/成本/依赖——做得出来吗）。改进建议按格式给：问题→影响→建议，按严重度排序（致命>重要>建议）。一句话：评审不是找茬，是帮 PRD 变完整。

打个比方：给一份「菜谱」（PRD）找问题——五查：①查价值（这道菜为什么做——给谁吃、图什么：只写「做一道菜」不写「给病人吃、要清淡」=需求清单不是菜谱）；②查场景（做菜流程完整吗——主流程（洗→切→炒→出锅）写了，异常流程（火大了怎么办/盐放多了怎么办）写了吗——只写顺利流程的菜谱一定有坑）；③查边界（边界条件清楚吗——没盐了怎么办/没有锅怎么办/来 20 个人吃（人多的边界）怎么办）；④查验收（怎么算菜成功——「好吃」不是验收，「咸淡 5 克盐以内」才是）；⑤查可行（食材买得到吗/需要 2 小时但只有 30 分钟——做得出来吗）。改进建议格式：问题（第 3 步没写火候）→影响（火大了会糊）→建议（补上火候说明）——按严重度排（致命：配方逻辑不通>重要：缺火候>建议：摆盘可优化）。

30 秒电梯版：「给 PRD 找问题，按『五查清单』：①查价值——需求为什么做（有没有用户场景+业务目标——只写功能不写价值的 PRD 是需求清单不是 PRD）；②查场景——用户流程完整吗（主流程+异常流程：用户中途退出/失败怎么办——『只写 happy path（顺利路径）的 PRD 一定有坑』）；③查边界——边界条件清楚吗（空数据/超长文本/并发/权限——边界没写=上线就崩）；④查验收——指标可测吗（『提升体验』不是验收——『回复率提升 5%』才是；验收标准=上线怎么判断成功）；⑤查可行——技术/成本/依赖（实现方案可行吗/依赖谁/风险）。改进建议格式：问题（位置+现象）→影响（为什么是问题）→建议（怎么改）——按严重度排序：致命问题（逻辑不通）>重要（边界缺失）>建议（可优化）。收口：评审不是找茬，是『帮 PRD 变完整』——五查过一遍+建议格式标准+严重度排序，评审会变成『一起把文档补完整』。」

② 为什么学 / 面试为什么考
PRD 评审是产品经理的日常核心工作（每周都要做），面试考它的原因有三：
第一，它考「评审基本功」。PRD 评审（给文档找问题）是产品经理的基本功（周会、评审会、跨部门对齐都要用）——面试官想看你懂不懂「评审的套路」（五查清单：价值/场景/边界/验收/可行——不是凭感觉找茬，是按清单查）——评审能力=发现问题+给建议（两件事都能做才算会）。
第二，它考「批判性思维」。「给 PRD 找问题」——考你的批判性思维（不盲从文档：文档写得再漂亮也找得出问题——价值、边界、验收——每个维度都敢质疑）——面试官想看你有没有「挑毛病的能力」（PRD 是团队照着做的，有坑不挑=团队踩坑）。
第三，它考「建议能力」。「给改进建议」——找问题谁都会，给建议见高下（「这里不行」谁都会说，「这里为什么不行+怎么改」才值钱）——面试官想看你懂不懂「建议的格式」（问题→影响→建议——按严重度排序：不是把问题扔出来，是带方案解决问题）。
一句话：这道题考的是「评审基本功」＋「批判性思维」＋「建议能力」。

③ 原理拆解：五查清单→建议格式→严重度排序→收口

第一步：①查价值——需求为什么做。第一查：查「价值」——需求为什么做？有没有「用户场景+业务目标」：用户场景（谁、在什么情况、要解决什么：求职者在改简历时不知道怎么突出亮点——场景具体）；业务目标（做完带来什么：简历优化功能上线后，付费转化率提升 10%——目标量化）——只写功能不写价值的 PRD 是「需求清单」不是 PRD（「做一个简历优化功能」——没写为谁解决什么问题、带来什么目标——这是需求清单（功能列表），不是 PRD（产品需求文档：有场景有目标）——没有价值的 PRD：团队不知道为什么做（开发问「这功能图啥」——没人答得上）。
打个比方：菜谱查价值（第一查）——「做一道菜」（只写了做什么——需求清单）；「给高血压的父亲做一道低盐菜——吃完血压不升，全家安心」（场景+目标——PRD）——只写「做一道菜」的菜谱（没写给谁吃、图什么）——家人不知道做给谁、为什么做（做出来没人吃——白做）。PRD 同理：只写「做一个功能」=需求清单（不知道为谁、图啥）；写清「场景+目标」=PRD（团队知道为什么做）。
翻车案例：有 PRD 只写功能不写价值：「Q2 上线 AI 摘要功能」（功能清单）——评审时开发问「这个功能图什么？」产品答不上（没写场景没写目标）——开发说「那我不做」（没价值=没动力）——评审会就卡在「为什么做」——「只写功能」翻车：PRD 第一查就是「价值」（用户场景+业务目标）——没写价值=需求清单（评审第一句话就问「为什么做」——答不上=不合格）。

第二步：②查场景——用户流程完整吗（主流程+异常流程）。第二查：查「场景」——用户流程完整吗？主流程（顺利路径 happy path（顺利路径）：用户怎么用——输入→处理→输出——一切顺利的流程）写了，异常流程（出问题时怎么办）写了吗：用户中途退出怎么办（填了一半关掉了——数据保没保存）；失败怎么办（上传失败——提示+重试）；超时怎么办（等待超过 30 秒——怎么反馈）——「只写 happy path（顺利路径）的 PRD 一定有坑」：现实中用户一半在异常流程里（网络差、操作错、中途走）——异常流程没写=上线后异常场景全裸奔（用户中途退出丢数据——投诉）。
打个比方：菜谱查场景（第二查）——主流程（顺利路径）：洗→切→炒→出锅（写得很全）；异常流程：火大了怎么办（糊了——怎么救：关火）；盐放多了怎么办（咸了——怎么救：加土豆）；油溅了怎么办（烫到——怎么防）——只写主流程的菜谱（顺利路径齐全）——新手照着做：火大了（异常）——菜谱没说——糊了（翻车）——「只写顺利路径」的菜谱一定有坑。PRD 同理：主流程写全+异常流程（中途退出/失败/超时）也要写——异常没写=上线裸奔。
翻车案例：有 PRD 只写主流程（顺利路径）：「用户上传简历→AI 优化→下载」——评审五查发现：异常流程全没写（上传失败怎么办/中途退出数据保不保存/AI 优化超时怎么办）——开发上线后：用户网络差上传失败（没提示没重试——直接报错）；用户中途退出（填的职位信息丢了——下次重填）——投诉不断——「只写 happy path（顺利路径）」翻车：现实中用户一半在异常场景（网络差、操作错、中途走）——异常流程没写=上线后异常场景全裸奔（评审时查异常：中途退出/失败/超时——补上）。

第三步：③查边界——边界条件清楚吗。第三查：查「边界」——边界条件（极端情况）清楚吗？空数据（没有数据时怎么办：空列表怎么展示/搜索无结果怎么提示）；超长文本（内容特别长怎么办：标题超长截断？正文 10 万字怎么办）；并发（同时很多用户操作怎么办：双十一同时下单 10 万笔——系统扛得住吗）；权限（谁能做什么：普通用户/管理员权限分开吗）——边界没写=上线就崩（空数据显示报错（应该显示「暂无内容」）；超长文本排版爆炸（应该截断）——边界是「极端情况的预案」，不写=极端情况裸奔。
打个比方：菜谱查边界（第三查）——边界条件：没盐了怎么办（替代：酱油）；20 个人来吃怎么办（分量翻 4 倍——人多的边界）；停电了怎么办（煤气灶能不能用——极端情况的边界）——只写「正常做」（正常食材、2 人份、有火）的菜谱——极端情况（没盐、来 20 人、停电）全没写——真遇到（没盐）——菜谱没说——抓瞎。PRD 同理：边界（空数据/超长文本/并发/权限）写没写——没写=极端情况裸奔。
翻车案例：有 PRD 边界全没写——「搜索功能」：空搜索（没输入直接点搜索——报错还是提示）；搜索无结果（空列表怎么展示——白屏还是「没有找到」）；超长关键词（100 字关键词怎么办）——上线后：用户没输入点搜索（白屏——报错）；搜不到（白屏——用户以为坏了）——「边界没写」翻车：边界（空数据/超长/并发/权限）是极端情况的预案——没写=极端情况全裸奔（评审时查边界：空数据/超长文本/并发/权限——四类边界问一遍）。

第四步：④查验收——指标可测吗。第四查：查「验收」——指标可测吗？「提升体验」不是验收（主观词：什么叫「体验提升」——没法测）；「回复率提升 5%」才是（客观数：可测可对比——验收标准=上线怎么判断成功：量化指标（回复率提升 5%）、对比方式（和谁比：和上个版本比）、时间窗口（多久看：上线 2 周后看）——不可测的验收=上线后没法判断成功（「体验提升了吗」——各说各话：产品说提升了、老板说没感觉——没有数字）。
打个比方：菜谱查验收（第四查）——「做得好吃」不是验收（好吃——主观）；「咸淡 5 克盐以内、上桌 40 分钟以内」才是（可测：咸淡用盐量测、时间用表测）——只写「好吃」的菜谱——做完怎么判断成功（好吃吗——各有各的标准：你说好吃、家人说太咸——没法判断）；写「5 克盐+40 分钟」——做完一测（咸淡 4 克、用时 35 分钟——达标）。PRD 同理：「提升体验」不是验收，「回复率提升 5%」才是。
翻车案例：有 PRD 验收写「提升用户体验」——上线后评审「成功了吗」——产品说「提升了」（感觉）；老板说「没感觉」（也是感觉）——没有数字（「提升体验」不可测）——吵不出结果——「不可测验收」翻车：验收标准=上线怎么判断成功（可量化：回复率提升 5%、和上个版本比、上线 2 周后看）——「提升体验」不可测=上线后没法判断（各说各话）——评审时查验收：指标可测吗（量化了吗/和谁比/多久看）。

第五步：⑤查可行——技术/成本/依赖。第五查：查「可行」——技术/成本/依赖：实现方案可行吗（技术上有解吗：要 AI 识别手写体——模型能做吗）；成本可接受吗（开发人力/时间/模型调用费——做这个功能要 3 个人 2 个月——值得吗）；依赖清楚吗（依赖谁：依赖算法团队的模型——他们的排期呢；依赖第三方服务——对方稳定吗）；风险写了吗（最大风险：模型效果不达标/成本超支——风险+预案）——不可行的 PRD=评审白开（方案做得再好，做不出来=白做——技术没解/成本超支/依赖没着落——评审现场就要问）。
打个比方：菜谱查可行（第五查）——食材买得到吗（要「蓝鳍金枪鱼」——小城市买不到——技术没解）；时间够吗（要 3 小时——今晚只有 30 分钟——成本超支）；依赖清楚吗（要「特殊烤箱」——家里有吗——依赖没着落）——只写「高大上菜谱」不查可行（食材/时间/工具）——真做：买不到食材（做不了）、时间不够（做不完）——「不可行」翻车。PRD 同理：技术/成本/依赖——评审时查可行：做得出来吗。
翻车案例：有 PRD 可行没查——「AI 手写体识别功能」——评审时算法说「手写体识别模型我们没有，要训练 3 个月」（技术没解）——开发说「依赖算法团队，但他们排期到明年了」（依赖没着落）——评审会白开（方案再好，做不出来）——「可行没查」翻车：评审时查可行（技术有解吗/成本可接受吗/依赖清楚吗/风险写了吗）——不可行的 PRD 当场打回（不用等开发）。

第六步：改进建议格式——问题→影响→建议，按严重度排序。找完问题，给改进建议——格式三步：问题（位置+现象：「第 3.2 节：用户中途退出时数据未保存」——指出位置和现象，不笼统说「有问题」）；影响（为什么是问题：「用户重填信息，流失率预计 +30%」——说清后果）；建议（怎么改：「中途退出自动保存草稿，30 天内可恢复」——给方案，不给「你看着办」）；排序按严重度：致命问题（逻辑不通：流程根本走不通——必改）；重要（边界缺失：极端情况会崩——该改）；建议（可优化：体验更好——可选）——格式标准+排序清晰，改进建议才能被执行（评审会不是「问题大杂烩」，是「按优先级排好的改进清单」）。
打个比方：给菜谱提建议（格式+排序）——问题（第 3 步炒制：没写火候）→影响（火大了会糊，新手必翻车）→建议（补上：中火 2 分钟）；排序：致命（配方逻辑不通：写「先炸后煮」但步骤是「先煮后炸」——必改）；重要（缺火候——该改）；建议（摆盘可优化——可选）——格式标准（问题→影响→建议）+排序清晰（致命>重要>建议）——家人照着改（改完菜谱能用了）。PRD 评审同理：问题→影响→建议+严重度排序。
翻车案例：有评审人找问题不给格式——「这个 PRD 不行，很多地方有问题」（笼统）；「用户流程有问题」（没位置没现象——不知道哪段流程）；「应该改」（没建议——怎么改？）——问题被开发搁置（没位置没影响没建议=没法执行）——「不给格式」翻车：改进建议三步（问题（位置+现象）→影响（为什么是问题）→建议（怎么改））+严重度排序（致命>重要>建议）——格式标准，建议才被执行。

第七步：收口——评审不是找茬，是帮 PRD 变完整。全流程的收口心态：评审不是「找茬」（挑毛病证明我厉害），是「帮 PRD 变完整」（发现问题补全它——五查过一遍：价值/场景/边界/验收/可行——每个维度帮文档补一块；建议格式标准（问题→影响→建议）+严重度排序（致命>重要>建议）——评审会变成「一起把文档补完整」（不是对立：写 PRD 的补文档，评审的帮找坑——一起把文档变完整）。
打个比方：请人尝菜（评审）——不是「挑刺」（这菜不行——证明我嘴刁），是「帮菜变完整」（尝出缺盐（问题）→咸了影响口味（影响）→补半勺盐（建议）——一起把菜变好吃）；排序（缺盐致命（必须补）、摆盘重要（该调）、盘子可选（能换））——尝菜的人不是找茬，是帮菜变完整。PRD 评审同理：不是找茬，是帮 PRD 变完整——五查+格式+排序，评审会变成协作。
翻车案例：有评审人全程「找茬」——「这个 PRD 太差了」「这个功能没意义」「这个需求是垃圾」——写 PRD 的人被批得一文不值（只找茬不给建议）——团队对立（评审会变成批斗会——写 PRD 的人以后不敢写）——「找茬式评审」翻车：评审是「帮 PRD 变完整」（问题→影响→建议：指出问题+给出方案——一起补全），不是「找茬」（只挑毛病不给方案——对立）——评审会应该是协作，不是批斗。
小结：五查（价值/场景/边界/验收/可行）→建议格式（问题→影响→建议）→严重度排序（致命>重要>建议）→收口（评审是帮 PRD 变完整）。

④ 对比表格：五查清单查什么
| 五查 | 查什么 | 典型问题 | 验收标准 | |------|------|------|------| | ①查价值 | 需求为什么做 | 只写功能不写场景/目标 | 有用户场景+业务目标 | | ②查场景 | 用户流程完整吗 | 只写顺利路径（happy path（顺利路径）） | 主流程+异常流程都有 | | ③查边界 | 边界条件清楚吗 | 空数据/超长/并发/权限没写 | 四类边界都有预案 | | ④查验收 | 指标可测吗 | 「提升体验」（不可测） | 「回复率提升 5%」（可测） | | ⑤查可行 | 技术/成本/依赖 | 做不出来/依赖没着落 | 技术有解+成本可控+依赖清楚 |

⑤ 3+个例子：PRD 评审实战
例子1：AI 客服 PRD 评审（查价值）。问题：「第 1 节：只写『上线 AI 客服功能』——没写为谁解决什么问题」（位置+现象）；影响：「开发不知道为什么做，价值说不清——优先级站不住」（为什么是问题）；建议：「补上场景和目标：为商家解决回复慢的问题——回复及时率从 40% 到 80%，人工成本降 30%」（怎么改）。
例子2：简历优化 PRD 评审（查场景）。问题：「第 4 节：只写主流程（上传→优化→下载），异常流程没写——上传失败怎么办、中途退出数据保不保存」；影响：「上线后异常场景裸奔：上传失败无提示、中途退出丢数据——投诉+流失」；建议：「补异常流程：上传失败提示+重试、中途退出自动保存草稿（30 天可恢复）」——致命问题（异常没写=上线崩）。
例子3：AI 推荐 PRD 评审（查验收）。问题：「第 6 节：验收写『提升用户体验』——不可测」；影响：「上线后没法判断成功：产品说提升了、老板说没感觉——各说各话」；建议：「改成可测指标：点击率提升 5%（和上个版本对比、上线 2 周后看）」——重要问题（验收不可测=没法验收）。
例子4：AI 翻译 PRD 评审（查可行）。问题：「第 7 节：没写依赖——翻译模型依赖第三方服务，对方稳定性和排期没提」；影响：「开发到一半发现依赖服务涨价/不稳定——项目卡壳」；建议：「补依赖和风险：翻译模型用 X 服务（月费 5000 元，SLA（服务等级协议：服务质量承诺）99.9%），风险：服务涨价——预案：备选模型 B」——重要问题（依赖没着落=项目风险）。

⑤b 补充板块：评审会的「三要三不要」
评审会怎么开（除了五查，还有「三要三不要」）：
第一，要「提前发文档」不要「现场读文档」：评审前 1 天发 PRD（大家提前看——现场只讨论问题不读文档）；现场读文档=浪费时间（10 个人等 1 个人读完——评审会变阅读会）。
第二，要「记录问题」不要「当场改文档」：评审会记录问题（问题清单：谁提的、什么位置、什么影响——会后统一改）；当场改文档=会议失焦（改着改着跑题——文档改一半）。
第三，要「结论收口」不要「问题散场」：散会前总结（本次发现 X 个问题：3 个致命、5 个重要——谁负责改、什么时候改完）；问题散场=白开会（没人认领——问题都丢了）。
一句话：评审会三要三不要——要提前发（不现场读）、要记录问题（不当场改）、要结论收口（不问题散场）——会开完，问题有认领。

⑤c 补充板块：AI PRD 评审的「AI 专项四查」
AI 产品的 PRD 评审，除了五查还有「AI 专项四查」：
第一，查模型故事（依赖什么模型能力、能力边界在哪——「AI 摘要依赖摘要模型，边界：长文 10 万字以上效果下降」——写没写）。
第二，查失败模式（模型会怎么错、错了怎么办——「答错/答偏/不答各有兜底：关键词匹配/降级/人工」——写没写）。
第三，查评测设计（怎么定义好坏输出、评测集（评估测试题）和阈值（及格线）——「准确率 90% 算好，按评测集 X 算」——写没写）。
第四，查数据需求（数据从哪来、谁标、多久更新——「对话数据来自商家授权，双人标注，每周更新」——写没写）。
一句话：AI PRD 评审 = 五查（价值/场景/边界/验收/可行）+ AI 专项四查（模型故事/失败模式/评测设计/数据需求）——AI 产品的坑（模型会错、效果要测、数据要养）专项查。

⑥ 常见误区（3个）
误区1：「评审就是找茬（挑毛病证明我厉害）。」错！评审是「帮 PRD 变完整」（问题→影响→建议：指出问题+给出方案——一起补全）——找茬式评审（只挑毛病不给方案）对立团队（写 PRD 的人不敢写）——评审会应该是协作，不是批斗。
误区2：「找问题要『感觉』（看一遍觉得哪里不对）。」错！按「五查清单」查（价值/场景/边界/验收/可行——每个维度按清单过一遍）——凭感觉=漏查（觉得哪里不对=只发现表面的；五查=系统地查（每个维度都过——不靠感觉，靠清单）。
误区3：「改进建议说到位就行（指出问题即可）。」错！改进建议三步格式（问题（位置+现象）→影响（为什么是问题）→建议（怎么改））+严重度排序（致命>重要>建议）——只说「有问题」=没法执行（开发不知道哪段、为什么、怎么改）——格式标准，建议才被执行。

⑦ 第一人称面试回答（3年景观设计→自学转行 AI 产品）
「我 3 年景观设计，被裁后自学转行——给文档找问题，我做景观设计时天天做：审施工图（给图纸找问题）——我有自己的『五查』：①查价值（这张图解决什么问题——给谁用、图什么）；②查场景（施工流程完整吗——正常流程写了，异常流程（下雨天施工怎么办）写了吗）；③查边界（边界条件清楚吗——土壤条件差怎么办/极端天气怎么办）；④查验收（怎么算施工达标——『好看』不是验收，『坡度 3% 以内』才是）；⑤查可行（材料买得到吗/工期排得开吗——做得出来吗）；改进建议格式也一样（问题（第 3 张图排水坡度没标）→影响（下雨会积水）→建议（补标坡度 3%）——按严重度排（致命：结构逻辑不通>重要：排水坡度缺>建议：绿化可选）。转行学 AI 产品后，把『审施工图』翻译成『审 PRD』：五查清单（价值/场景/边界/验收/可行）+建议格式（问题→影响→建议）+严重度排序——完全一样的方法论，换个文档而已；AI 产品还多 AI 专项四查（模型故事/失败模式/评测设计/数据需求——AI 的坑要专项查）。我没有大厂评审经验，但『审施工图三年』证明：我懂五查、懂建议格式、懂严重度排序——评审的基本功，我在景观设计里练了三年。」

⑧ 小结口诀
「五查：价值（为什么做）、场景（主流程+异常）、边界（空/长/并发/权限）、验收（可测指标）、可行（技术成本依赖）；建议三步：问题→影响→建议；排序：致命>重要>建议——评审是帮 PRD 变完整。」

⑨ 三轮追问（面试官深挖）
追问1：「五查如果时间不够（只够查两个），先查哪两个？」「先查『验收』和『边界』：验收不可测=没法判断成功（最致命：整个功能做了不知道成没成）；边界没写=上线就崩（空数据/极端情况——上线翻车）——价值场景可行可以会后补（问一下就行），验收边界是『坑』（不查就踩）——时间不够先查坑（验收+边界——两个最容易翻车的），再补其他的。」
追问2：「评审时开发说『做不到』，你怎么判断是『真做不到』还是『不想做』？」「不凭嘴判断，看证据：让开发给『做不到的环节』——是技术没解（模型不支持：手写体识别没有模型——查证：行业里有没有人做出来过）、是成本太高（要 3 个月——查证：有没有更省的方案：换模型/简化功能）、还是排期冲突（在排别的——查证：优先级排序：这个需求值不值得调排期）——三个环节查完，『做不到』是真是假有答案（真做不到：换方案/砍功能；不想做：排期谈不拢——把证据摆出来，用证据对齐不用嗓门）。」
追问3：「你自己写的 PRD 被人挑出 10 个问题，怎么应对？」「先谢后查：先感谢（挑出问题是帮我变完整——评审不是攻击我，是帮文档）；再查（10 个问题分三类：真问题（确实漏了——记下来改）；理解偏差（评审理解错了——解释清楚：文档哪里写得有歧义——改文档）；意见分歧（评审的建议和我的判断不同——摆数据讨论：用数据对齐）——10 个问题处理完，文档更完整+关系更顺（不怕被挑，怕挑不出——挑出 10 个问题的评审是好评审）。」

⑩ 进阶加分点（说出口就加分）
加分点1：把五查升级为「五查打分表」。「我的评审用打分表：五查各 20 分（价值 20/场景 20/边界 20/验收 20/可行 20）——60 分以下打回重写、60-80 改后过、80 以上过——打分表让评审『有标准』（不是感觉过不过，是分数说话）」——「五查打分表」说明你的评审有量化标准（不是凭感觉）。
加分点2：引入「问题密度」指标。「我会统计『问题密度』（每千字几个问题）：同类 PRD 平均 5 个/千字——密度特别高（10 个/千字）=文档基础差（写的人没用心）；密度特别低（1 个/千字）=评审没查透（要么文档真好，要么评审偷懒）——密度是评审质量的镜子（不是找茬数问题，是看密度找信号）。」——「问题密度」是高级词（评审有量化视角）。
加分点3：把评审建议和「验收绑定」。「我的评审建议会追到验收：每个『重要』以上问题（严重度）挂到验收清单（改完怎么验：『补异常流程』→验收时测『上传失败场景』——问题改没改，验收时见）——建议不是『提了就完』，是『改完验收』（闭环：问题→改→验）」——「建议挂验收闭环」说明你懂「建议要落地」（提了不算完，验收才算）。

⑪ 话术库（直接抄着说）
「PRD 评审五查：①查价值（为什么做）②查场景（主流程+异常流程）③查边界（空/长/并发/权限）④查验收（指标可测吗）⑤查可行（技术/成本/依赖）。」
「『只写 happy path（顺利路径）的 PRD 一定有坑』——异常流程（中途退出/失败/超时）必查。」
「『提升体验』不是验收——『回复率提升 5%』才是；验收标准=上线怎么判断成功。」
「改进建议三步：问题（位置+现象）→影响（为什么是问题）→建议（怎么改）；排序：致命>重要>建议。」
「评审不是找茬，是帮 PRD 变完整。」

⑫ 小白 Q&A（可能踩的坑）
Q1：没写过 PRD，怎么练评审（找问题）？从「看别人的 PRD」练起：找 3 份 PRD（网上模板/同事的），用五查清单各查一遍（价值/场景/边界/验收/可行——每个维度查一遍）——查完你就发现：90% 的 PRD 边界和异常是空的（练 3 份就入门，练 10 份就熟练）。
Q2：评审时和写 PRD 的人吵起来怎么办？用「数据」吵：双方各摆证据（你说异常没写——指出哪一段哪一处；他说写了——指出在哪一页）——用「位置+现象」对齐（不争「你的文档差」（对人不）——争「这一处缺了」（对事））——对事不对人，评审就吵不起来。
Q3：AI 专项四查（模型故事/失败模式/评测/数据）不会查怎么办？四查是「问问题」不是「懂技术」：模型故事（这个功能靠模型什么本事——写了吗）；失败模式（模型答错/答偏/不答——怎么办写了吗）；评测（怎么算好——准确率多少、按什么题算）；数据（数据哪来、谁标、多久更）——四个问题问一遍，AI 专项就查完了（不需要懂模型内部，需要懂「这四个问题必答」）。

⑬ 没人告诉你的事（面试潜规则）
这道题面试官真正在听的，是「你敢不敢挑毛病」——大部分候选人答「PRD 要写清楚」（怎么写的角度），你说「按五查清单挑毛病」（怎么审的角度）——当场拉开（面试官要的是「会评审的人」（帮团队把关），不是「会写文档的人」（只会自己写））。另一个潜规则：这道题的灵魂是「建议格式」——「问题→影响→建议」三步（带方案解决问题）是全场金句（找问题谁都会，带方案才是产品经理——面试官最烦「光挑毛病不给方案」的候选人）。还有一个：用「审施工图三年」讲五查评审，比背「价值/场景/边界/验收/可行」动人十倍——你的真实经历（传统文档的评审经验迁移到 PRD）就是最稀缺的素材——面试官会记住「这个转行者审过三年文档」。

⑭ 做一件事（学完就动手）
今天找一份「别人的文档」（同事的报告/群里的方案/甚至一份使用说明书都行），用五查清单审一遍：①查价值（为什么做——写了吗）；②查场景（流程完整吗——异常流程写了吗）；③查边界（极端情况写了吗）；④查验收（怎么算成功——可测吗）；⑤查可行（做得出来吗）——然后给 3 条改进建议（按格式：问题→影响→建议+严重度排序）——做完你就懂：评审不是天赋，是清单+格式（照五查走，问题自然浮出来）。

⑮ 求职助手联系（面试前必做）
面试前用本卡做 3 件事：①把「五查清单」练熟（面试框架：价值/场景/边界/验收/可行）；②准备你的「评审」案例（审施工图三年——真实经历最动人）；③把「评审不是找茬，是帮 PRD 变完整」练熟（收口金句）。面试被问「给 PRD 找问题」时：先说五查（价值/场景/边界/验收/可行）→再说建议格式（问题→影响→建议）→收口（严重度排序+帮文档变完整）——清单完整+格式标准+经历真实，面试官立刻记住你。

⑯ 练习（自己测一遍）
1.（排序）五查清单的顺序？A 价值→场景→边界→验收→可行；B 可行→验收→价值→边界→场景——答案：A。
2.（格式）改进建议的正确格式是？——答案：问题（位置+现象）→影响（为什么是问题）→建议（怎么改）。
3.（角色）面试官给你一份 PRD（只写功能清单没写价值），你怎么评？——参考答案：「按五查第一查：查价值——这份 PRD 只写了功能（『上线 AI 摘要功能』），没写用户场景（为谁解决什么问题）和业务目标（带来什么）——影响：团队不知道为什么做、优先级站不住；建议：补上场景（求职者改简历时……）和目标（付费转化率提升 10%）——这是重要问题（没价值=需求清单不是 PRD）。」

AI PRD 8 大模块


图怎么读：AI PRD（人工智能产品需求文档）应包含哪 8 大关键模块？——八模块分两组：传统五件套（升级版）+AI 三件套（灵魂）：①背景与目标——业务问题+成功指标（AI 功能的价值主张：为谁解决什么问题、带来什么指标）；②用户场景——谁在什么场景用（AI 功能的使用流程：输入什么→期望什么输出）；③功能需求——AI 能力定义（输入/输出/交互：AI 做什么、不做什么）；④模型故事——模型能力与边界（依赖什么模型能力、能力边界在哪（做不到什么）、模型选型（选哪个模型、为什么）——AI 三件套之一）；⑤评测设计——怎么定义「做得好」（评测集（评估测试题：覆盖什么场景）+指标（准确率/满意度）+阈值（达标线：准确率 90% 算好）——AI PRD 的灵魂：没有评测设计的 AI 需求无法验收（AI 效果好不好要测了才知道——评测是验收尺子）；⑥数据需求——数据从哪来（训练/评测/回流数据：来源、规模、质量要求、更新频率——AI 三件套之二）；⑦失败模式与兜底——模型错了怎么办（降级/重试/人工/拒答——「AI 产品必须写『出错预案』」（模型会错是必然——预案必写）——传统「边界」的 AI 升级）；⑧上线与监控——灰度计划（小范围上线计划）+线上监控指标+回滚条件（效果差了怎么回滚（退回旧版）——传统「验收」的 AI 升级）。收口：传统 PRD 五件套（背景/场景/功能/边界/验收）在 AI 语境下升级为八模块——「AI 三件套（模型/评测/数据）是区别」。

① 一句话大白话定义
这道题问的是：AI 产品的 PRD（产品需求文档）应该包含哪 8 大关键模块？
用大白话说：八模块 = 传统五件套（①背景与目标②用户场景③功能需求⑦失败模式与兜底⑧上线与监控——传统背景/场景/功能/边界/验收的 AI 升级）+ AI 三件套（④模型故事⑤评测设计⑥数据需求——AI 独有的灵魂）。其中「评测设计」是灵魂：没有评测设计（怎么定义做得好：评测集+指标+阈值）的 AI 需求无法验收（AI 效果好不好要测了才知道——评测是验收尺子）。一句话：AI 三件套（模型/评测/数据）是 AI PRD 和传统 PRD 的区别——写全八模块，AI 需求才完整。

打个比方：请「机器人厨师」（AI 产品）的「使用说明书」（AI PRD）——八模块：①背景与目标（为什么请机器人厨师：店里的菜不好吃——目标：好评率提升 10%）；②用户场景（客人在什么场景吃：点餐后 20 分钟上菜——输入菜单→期望出菜）；③功能需求（机器人做什么、不做什么：做中餐、不做西餐）；④模型故事（机器人靠什么本事：会炒菜（模型能力）、不会做西餐（能力边界）、选哪个型号（模型选型））；⑤评测设计（怎么算做得好：尝菜（评测集）+咸淡分（指标）+90 分算合格（阈值）——没有评测设计=没法验收（好吃吗——没标准没法判断））；⑥数据需求（菜谱从哪来：100 道菜谱（数据来源）、谁整理（标注）、多久更新（更新频率））；⑦失败模式与兜底（机器人做砸了怎么办：重做/免单/换人工（降级/重试/人工）——必须写「出错预案」）；⑧上线与监控（先在小店试（灰度计划）+看差评数（监控指标）+做砸了退回人工（回滚条件））——八模块写全，机器人厨师才敢请。

30 秒电梯版：「AI PRD 八模块分两组：传统五件套（升级版）+AI 三件套（灵魂）。①背景与目标——业务问题+成功指标（为谁解决什么问题、带来什么指标）；②用户场景——谁在什么场景用（输入什么→期望什么输出）；③功能需求——AI 能力定义（输入/输出/交互：AI 做什么、不做什么）；④模型故事——模型能力与边界（依赖什么模型能力、能力边界在哪（做不到什么）、模型选型）；⑤评测设计——怎么定义『做得好』（评测集（评估测试题：覆盖什么场景）+指标（准确率/满意度）+阈值（达标线）——AI PRD 的灵魂：没有评测设计的 AI 需求无法验收）；⑥数据需求——数据从哪来（训练/评测/回流数据：来源、规模、质量要求、更新频率）；⑦失败模式与兜底——模型错了怎么办（降级/重试/人工/拒答——『AI 产品必须写出错预案』）；⑧上线与监控——灰度计划（小范围上线）+线上监控指标+回滚条件（效果差了退回旧版）。收口：传统 PRD 五件套（背景/场景/功能/边界/验收）在 AI 语境下升级为八模块——『AI 三件套（模型/评测/数据）是区别』——写全八模块，AI 需求才完整。」

② 为什么学 / 面试为什么考
AI PRD 八模块是 AI 产品经理的「文档基本功」（面试高频题），面试考它的原因有三：
第一，它考「文档结构能力」。PRD 是产品经理的语言（团队照它干活）——面试官想看你懂不懂「AI PRD 的结构」（八模块：哪些是传统有的、哪些是 AI 特有的——结构清楚，团队才照得对）——文档结构能力是产品经理的基本功。
第二，它考「AI 特有认知」。AI PRD 和传统的区别在「AI 三件套」（模型故事/评测设计/数据需求——AI 特有的三块）——面试官想看你懂不懂「AI 需求的独特之处」（模型会错（写失败模式）、效果要测（写评测设计）、数据要养（写数据需求）——AI 三件套是 AI 产品经理和传统产品经理的分水岭）。
第三，它考「验收思维」。「评测设计是灵魂」（没有评测的 AI 需求无法验收——AI 效果好不好要测了才知道）——面试官想看你懂不懂「AI 验收」（评测集+指标+阈值——怎么定义做得好——验收思维是 AI 产品经理的核心（没有验收标准的需求=做了不知道成没成）。
一句话：这道题考的是「文档结构能力」＋「AI 特有认知」＋「验收思维」。

③ 原理拆解：传统五件套→AI 三件套→收口

第一步：①背景与目标——业务问题+成功指标。第一模块：背景与目标——业务问题（为谁解决什么问题：商家回复慢（业务问题——回复及时率只有 40%）；成功指标（带来什么：回复及时率从 40% 到 80%——成功指标量化（不量化=没法判断成功））——AI 功能的价值主张（AI 功能值不值得做：解决什么问题+带来什么指标——价值主张清楚，团队知道为什么做）；AI 特别提示：目标写「业务指标」不写「技术指标」（「回复及时率 80%」（业务——老板看得懂）vs「模型准确率 95%」（技术——老板听不懂——技术指标放「评测设计」里，目标模块写业务指标）。
打个比方：机器人厨师说明书第一模块（背景与目标）——业务问题（店里菜不好吃：差评率 20%）；成功指标（差评率从 20% 到 5%——量化）；价值主张（请机器人厨师值不值：解决「菜不好吃」+带来「差评率降到 5%」）——目标写「业务指标」（差评率 5%——老板看得懂）不写「技术指标」（炒菜温度精确到 1 度——老板听不懂——技术指标放「评测设计」）。背景与目标：业务问题+成功指标=为什么做。
翻车案例：有 PRD 背景与目标写技术指标——「目标：模型准确率达到 95%」（技术——AI 功能的业务价值没说：为谁解决什么问题、带来什么业务指标）——老板看 PRD：「准确率 95% 然后呢？省了多少钱？」——答不上（没有业务价值）——「技术目标」翻车：背景与目标写「业务问题+成功指标」（回复及时率 80%——业务）；技术指标（准确率 95%）放「评测设计」——目标模块是给老板看的（业务语言），评测模块是给算法看的（技术语言）。

第二步：②用户场景——谁在什么场景用。第二模块：用户场景——谁在什么场景用（目标用户+使用场景：商家（谁）在顾客发消息时（场景）用 AI 自动回复——场景具体（不是「用户用 AI 客服」（笼统）——是「商家在顾客发消息 30 秒内（场景）用 AI 回复」）；AI 功能的使用流程：输入什么→期望什么输出（用户输入（顾客消息：「运费多少？」）→期望输出（AI 回答：「满 99 免运费」——输入输出写清楚，算法知道做什么）——AI 特别提示：场景写「输入→输出」流程（传统场景写「用户旅程」（点这里→看到那里——界面流程）；AI 场景多写「输入→输出」（用户说什么→期望 AI 答什么——模型的行为流程）。
打个比方：机器人厨师说明书第二模块（用户场景）——谁在什么场景用（客人在晚上 7 点高峰（场景）用机器人点菜（目标用户是客人）；使用流程：输入什么→期望什么输出（客人输入「宫保鸡丁」（输入）→期望机器人 20 分钟端出宫保鸡丁（输出））——场景写「输入→输出」流程（客人报菜名→期望出菜）；不是传统「用户旅程」（客人看菜单→点菜→等餐——界面流程——AI 场景多写输入输出：报菜名→出菜）。
翻车案例：有 PRD 用户场景只写「用户用 AI 客服」（笼统——谁、什么场景、输入输出都没写）——算法开发时问：「输入是什么？输出是什么？」——答不上（没写「输入→输出」）——开发猜（猜错了返工）——「场景笼统」翻车：用户场景写「谁+什么场景+输入→输出」（商家（谁）在顾客发消息时（场景）输入「运费多少」（输入）→输出「满 99 免运费」（输出）——输入输出写清楚，算法不猜。

第三步：③功能需求——AI 能力定义。第三模块：功能需求——AI 能力定义：输入（AI 接收什么：顾客消息+对话历史）、输出（AI 返回什么：回复文本+分类标签）、交互（产品怎么用 AI 的输出：展示回复/转人工按钮——AI 做什么、不做什么：做什么（自动回复常见问题）；不做什么（不处理退款操作——只回答，不操作）——AI 特别提示：功能需求写「能力边界」（AI 做什么、不做什么——写清楚，算法不过度实现（以为什么都要做——做多了返工））。
打个比方：机器人厨师说明书第三模块（功能需求）——输入（客人报的菜名+忌口要求）；输出（一盘菜+做菜时间）；交互（服务员怎么用机器人：下单给机器人→机器人出菜）；做什么（做中餐 30 道）；不做什么（不做西餐、不做甜品——能力边界：写清楚，机器人工厂不过度实现（把甜品机也造了——浪费）。功能需求：AI 做什么、不做什么（能力边界）。
翻车案例：有 PRD 功能需求没写「不做什么」——「AI 客服自动回复用户问题」（只写了做什么）——算法开发：把「退款操作」也实现了（以为客服要能退款——过度实现）——开发多花 2 周（做多了）——上线发现「退款操作」超出功能边界（产品没要）——「没写不做」翻车：功能需求写「做什么+不做什么」（做什么：自动回复常见问题；不做什么：不处理退款——只回答不操作）——能力边界写清楚，算法不过度实现（不做什么=省 2 周）。

第四步：④模型故事——模型能力与边界（AI 三件套之一）。第四模块：模型故事——模型能力与边界（AI 三件套之一）：依赖什么模型能力（这个功能靠模型什么本事：意图识别+FAQ（常见问题）（常见问题）问答）；能力边界在哪（做不到什么：能答常见问题（退换货/发票），答不了复杂纠纷（涉及赔偿——边界写清）；模型选型（选哪个模型、为什么：选 A 模型（成本低）+备选 B 模型（效果更好但贵——选型+备选））——为什么写模型故事：团队知道「模型的活」和「产品的活」怎么分（模型管理解、产品管展示——分工清楚）；模型选型有依据（为什么选这个——不是拍脑袋）。
打个比方：机器人厨师说明书第四模块（模型故事）——依赖什么能力（会炒菜：煎炒烹炸——模型能力）；能力边界（不会做西餐、不会做甜品——做不到什么写清）；模型选型（选 A 型号（便宜够用）+备选 B 型号（更贵但更快——选型+备选））——为什么写：后厨知道「机器人的活」和「服务员的活」怎么分（机器人管炒菜、服务员管上菜——分工）；选型有依据（为什么选 A——不拍脑袋）。模型故事：能力+边界+选型。
翻车案例：有 PRD 没写模型故事——「AI 客服」（没写依赖什么能力、边界在哪）——算法开发时自己猜（猜成「全能客服」——什么都想答）——上线后：复杂纠纷也答（答错——涉及赔偿的纠纷 AI 瞎答——出事故）——「没写边界」翻车：模型故事写「能力+边界」（能做常见问题、做不了复杂纠纷——边界写清）——没写边界=模型越界（什么都答——复杂纠纷答错出事故）——边界写清，模型不越界。

第五步：⑤评测设计——怎么定义「做得好」（灵魂）。第五模块：评测设计——怎么定义「做得好」（AI 三件套之二，AI PRD 的灵魂）：评测集（评估测试题：覆盖什么场景——1000 条真实对话（覆盖：退换货/发票/物流——场景覆盖全）；指标（准确率/满意度——准确率（答对的比率）90%；满意度（用户评价）4.5 分）；阈值（达标线：准确率 90% 算好——低于 90% 不上线）——为什么是灵魂：AI 效果好不好要测了才知道（模型效果是概率——不测不知道）；没有评测设计的 AI 需求无法验收（没有标准=上线后没法判断成功：准确率多少算好？——各说各话）；评测设计=AI 的验收尺子（怎么定义做得好，验收才有标准）。
打个比方：机器人厨师说明书第五模块（评测设计——灵魂）——评测集（试菜：100 道菜试吃——覆盖：川菜/粤菜/家常菜——场景覆盖全）；指标（咸淡分：90 分；出菜时间：20 分钟）；阈值（咸淡 90 分算合格——低于 90 分不上岗）——为什么是灵魂：机器人做得好不好要试了才知道（炒菜效果是概率——不尝不知道）；没有评测设计=没法验收（咸淡多少算好？——各说各话：老板说差不多、客人说太咸——没标准）——评测设计=机器人的上岗尺子。评测：评测集+指标+阈值。
翻车案例：有 PRD 没有评测设计——「AI 客服」（没写评测集/指标/阈值）——上线后「做得好不好」没有标准：产品说「感觉不错」（感觉）；算法说「准确率还行」（没具体数）——验收没法做（没标准=没尺子——吵）——「没有评测」翻车：评测设计是 AI PRD 的灵魂（评测集+指标+阈值——怎么定义做得好）；没有评测设计=无法验收（上线后各说各话——没法判断成功）——评测写清（准确率 90%、按评测集 X 算），验收才有标准。

第六步：⑥数据需求——数据从哪来（AI 三件套之三）。第六模块：数据需求——数据从哪来（AI 三件套之三）：训练/评测/回流数据（训练数据（教模型的数据：对话样本）、评测数据（评估测试的数据：评测集）、回流数据（上线后收集的数据：用户新问题）——三类数据都要）；来源（从哪来：商家授权对话记录/公开语料/人工整理——来源写清）；规模（多少：训练 1 万条/评测 1000 条——规模写清）；质量要求（什么样算好：双人标注（两个标注员互相校验）/口径统一——质量写清）；更新频率（多久更新：每周补充新问题/每月重标——更新写清）——为什么写数据需求：AI 效果=数据质量（数据好模型好、数据差模型差——数据是模型的粮食）；没有数据需求=开发卡壳（数据没备好——模型没得学——项目卡住）。
打个比方：机器人厨师说明书第六模块（数据需求）——数据从哪来（菜谱：100 道菜谱——来源：大厨整理+采购记录）；规模（100 道——每道有标准做法）；质量要求（每道菜双人试做确认（双人标注——两道工序互相校验））；更新频率（每月加 10 道新菜（更新——菜谱不旧））——为什么写：机器人炒菜好不好=菜谱质量（菜谱好菜好、菜谱乱菜差——菜谱是机器人的粮食）；没有菜谱需求=开发卡壳（菜谱没备好——机器人没得学——店开不了）。数据需求：来源/规模/质量/更新。
翻车案例：有 PRD 没写数据需求——「AI 客服」（没写数据从哪来、谁标、多久更新）——开发时：算法问「训练数据呢」——产品说「还没准备」（数据没备好）——等数据 2 个月（项目卡住——模型没得学）——「没写数据」翻车：数据需求写清（来源（商家授权对话）/规模（1 万条）/质量（双人标注）/更新（每周）——数据提前备）——没写数据需求=开发卡壳（数据没备好——模型没得学——项目卡住 2 个月）。

第七步：⑦失败模式与兜底——模型错了怎么办。第七模块：失败模式与兜底——模型错了怎么办（传统「边界」的 AI 升级）：失败模式（模型会怎么错：答错（给错误答案）/答偏（给不相关答案）/不答（拒绝/超时）——三类错误）；兜底方案（错了怎么办：降级（换简单版：从智能回复降为关键词匹配）/重试（重试一次：网络/超时重试）/人工（转人工客服：AI 答不了转人——最稳的兜底）/拒答（明确说不知道：不瞎编——安全兜底）——「AI 产品必须写『出错预案』」（模型会错是必然——不是「如果出错」，是「什么时候出错、出了怎么办」——预案必写）；为什么重要：模型错误=信任流失（答错一次=信任减一分——错误无预案=信任崩）——失败模式写清，错误有预案。
打个比方：机器人厨师说明书第七模块（失败模式与兜底）——失败模式（机器人会怎么搞砸：炒糊（做错）/炒咸（做偏）/没反应（不做——三类失败）；兜底（炒糊了怎么办：重做（重试）；炒咸了怎么办：加料补救（降级）；做不了怎么办：换人工厨师（人工——最稳的兜底）——「请机器人必须写『出错预案』」（机器人出错是必然——不是「如果出错」，是「什么时候出错、出了怎么办」——预案必写）；为什么：机器人炒糊=客人差评（糊一次=差评一次——糊了没预案=差评崩）。失败模式：三类错误+四个兜底。
翻车案例：有 PRD 没写失败模式——「AI 客服」（没写模型错了怎么办）——上线后：AI 答错（把「退货运费」答成「退款时间」）——产品直接展示错误答案（没预案——裸奔）——用户投诉「AI 一本正经说错话」（信任崩）——「没写失败模式」翻车：失败模式与兜底必写（答错/答偏/不答——三类错误+降级/重试/人工/拒答——四个兜底）——没写预案=错误裸奔（答错直接展示——用户信任崩）。

第八步：⑧上线与监控——灰度计划+监控+回滚。第八模块：上线与监控（传统「验收」的 AI 升级）：灰度计划（小范围上线计划：先 20% 用户上线 2 周——小范围试水：效果差影响面小）；线上监控指标（上线后看什么：准确率/满意度/投诉率——上线后持续看）；回滚条件（效果差了怎么回滚：准确率低于 80% 或投诉率升 2 倍——回滚（退回旧版——不硬扛））——为什么写：AI 上线不是终点（上线后效果会变：数据变了/用户变了——要持续监控）；没有回滚条件=效果差硬扛（上线后效果差——没有预案——硬扛到差评崩）。
打个比方：机器人厨师说明书第八模块（上线与监控）——灰度计划（先在一家店试（小范围上线）2 周——效果差影响面小）；监控指标（看什么：差评率/出菜时间/翻台率）；回滚条件（差评率升 2 倍——换回人工厨师（回滚——退回旧方案——不硬扛））——为什么写：机器人上岗不是终点（上岗后效果会变：菜价变了/客人口味变了——持续看）；没有回滚条件=差评硬扛（差评率升 2 倍——没预案——硬扛到店倒闭）。上线与监控：灰度+监控+回滚。
翻车案例：有 PRD 没写上线与监控——「AI 客服全量上线」（没写灰度/监控/回滚）——直接全量（没灰度——影响面全开）——上线后效果差（准确率只有 60%——没有监控指标——没人发现）；投诉爆了才发现（没有回滚条件——硬扛 2 周）——「没写上线监控」翻车：上线与监控写清（灰度计划（先 20% 试 2 周）+监控指标（准确率/投诉率）+回滚条件（低于 80% 回滚））——没写=全量上线（影响面全开）+效果差没人发现（没监控）+硬扛（没回滚）。
小结：传统五件套（背景目标/用户场景/功能需求/失败模式/上线监控——传统背景场景功能边界验收的 AI 升级）→AI 三件套（模型故事/评测设计/数据需求——AI 独有的灵魂）→收口（八模块写全，AI 需求才完整——AI 三件套是区别）。

④ 对比表格：传统 PRD 五件套 对比 AI PRD 八模块
| 传统 PRD | AI PRD 对应模块 | AI 增量 | |------|------|------| | 背景 | ①背景与目标 | 成功指标量化（业务指标） | | 场景 | ②用户场景 | 写「输入→输出」流程 | | 功能 | ③功能需求 | 写能力边界（做什么+不做什么） | | （新增） | ④模型故事 | 模型能力+边界+选型（AI 三件套） | | （新增） | ⑤评测设计 | 评测集+指标+阈值（灵魂） | | （新增） | ⑥数据需求 | 来源/规模/质量/更新（AI 三件套） | | 边界 | ⑦失败模式与兜底 | 错误三类+兜底四方案 | | 验收 | ⑧上线与监控 | 灰度+监控+回滚条件 |

⑤ 3+个例子：AI PRD 八模块实战
例子1：AI 客服 PRD（背景目标+评测设计）。①背景与目标：商家回复慢（回复及时率 40%）→目标：80%；②用户场景：商家（谁）在顾客发消息 30 秒内（场景）输入「运费多少」（输入）→输出「满 99 免运费」（输出）；⑤评测设计：评测集=1000 条真实对话（覆盖退换货/发票/物流）；指标=准确率 90%+满意度 4.5 分；阈值=低于 90% 不上线（评测是灵魂）。
例子2：AI 摘要 PRD（模型故事+数据需求）。④模型故事：依赖「长文本理解+摘要生成」能力；边界=10 万字以上长文效果下降；选型=A 模型（成本低）+备选 B（效果更好）；⑥数据需求：来源=群友授权长文样本；规模=500 条；质量=双人标注（保留关键信息）；更新=每月补 50 条（数据不枯竭）。
例子3：AI 推荐 PRD（失败模式+上线监控）。⑦失败模式：答偏（推荐不相关）→兜底（混入 20% 热门内容）；答错（推荐违规内容）→兜底（人工审核后才展示）；⑧上线与监控：灰度=先 20% 用户 2 周；监控=点击率/投诉率；回滚条件=点击率低于基线 10% 或投诉率升 2 倍（回滚旧版）。
例子4：AI 翻译 PRD（功能需求边界）。③功能需求：做什么（中英互译+术语表）；不做什么（不做语音翻译、不做多语言互译——能力边界写清）；⑦失败模式：不答（超时）→重试一次；答错（术语翻错）→降级（提示「术语存疑，建议人工校对」——兜底写清）。

⑤b 补充板块：八模块的「写作顺序」——先写哪个后写哪个
八模块写作顺序有讲究（不是想到哪写到哪）——推荐顺序：
第一，先写①背景与目标（先定「为什么做」——方向没定，后面没法写（目标定方向：做客服还是做摘要——背景目标先定）。
第二，再写②用户场景+③功能需求（定「做什么」——谁用、AI 做什么不做什么——功能范围定下）。
第三，然后写④模型故事（定「靠什么做」——依赖什么模型能力、边界在哪——模型范围定下）。
第四，接着写⑤评测设计+⑥数据需求（定「怎么验收+靠什么数据」——评测集指标阈值+数据来源规模——验收和数据备下）。
第五，最后写⑦失败模式+⑧上线监控（定「出错了怎么办+上线后怎么办」——兜底和监控补全——八模块闭环）。
一句话：写作顺序：背景目标（为什么）→场景功能（做什么）→模型故事（靠什么）→评测数据（怎么验+靠什么料）→失败上线（错了怎么办）——从为什么到怎么办，八模块一气呵成。

⑤c 补充板块：八模块的「一页纸模板」——新人照着填
八模块写成「一页纸模板」（新人照着填）：
第一，背景与目标：业务问题（一句）+成功指标（一个数：回复及时率 80%）。
第二，用户场景：谁（商家）+场景（顾客发消息 30 秒内）+输入→输出（运费多少→满 99 免运费）。
第三，功能需求：做什么（自动回复常见问题）+不做什么（不处理退款）。
第四，模型故事：依赖能力（意图识别+FAQ）+边界（答不了复杂纠纷）+选型（A 模型+备选 B）。
第五，评测设计：评测集（1000 条真实对话）+指标（准确率 90%）+阈值（低于 90% 不上线）。
第六，数据需求：来源（商家授权）+规模（1 万条）+质量（双人标注）+更新（每周）。
第七，失败模式：答错→人工兜底；答偏→追问确认；不答→转人工。
第八，上线监控：灰度（20% 用户 2 周）+监控（准确率/投诉率）+回滚（低于 80% 回滚）。
一句话：八模块一页纸模板——每模块一句到两句（目标一个数、评测三个数、兜底三种错）——新人照着填，第一版 AI PRD 就合格。

⑥ 常见误区（3个）
误区1：「AI PRD = 传统 PRD + 一句『用大模型』。」错！「用大模型」是最模糊的需求（哪个模型/什么能力/错了怎么办——全没写）——AI PRD 要写全八模块（尤其 AI 三件套：模型故事/评测设计/数据需求）——「用大模型」四个字=没写需求。
误区2：「评测设计是算法的事（产品不用写）。」错！评测设计（怎么定义做得好：评测集+指标+阈值）必须产品定义（业务口径：准确率 90% 是业务要求——不是算法自己定）——产品不写评测=算法自己定阈值（大概率「怎么好看怎么定」）——评测设计是产品的活（定义好坏是产品职责）。
误区3：「失败模式等开发时再说（模型错了我再想）。」错！失败模式必须「写进 PRD」（文档层面定好预案：答错/答偏/不答各有兜底）——开发时再想=上线时裸奔（模型上线就会错——预案必须提前定）。

⑦ 第一人称面试回答（3年景观设计→自学转行 AI 产品）
「我 3 年景观设计，被裁后自学转行——AI PRD 八模块，我用『请机器人厨师』的类比想通过：传统设计院的『设计任务书』（传统 PRD 的雏形）——五件套：背景（项目为什么做：公园给谁用）、场景（谁在什么场景用：居民傍晚遛弯）、功能（做什么：绿化/座椅/灯光）、边界（不做什么：不做停车场）、验收（怎么算好：坡度 3% 以内）——但 AI 产品多了『会出错的环节』（模型像机器人厨师：会炒糊、会做偏）——所以 AI PRD 加三件套：模型故事（机器人靠什么本事、做不了什么）、评测设计（怎么算做得好：试菜+咸淡分+90 分阈值）、数据需求（菜谱从哪来、谁整理、多久更新）；还要加『出错预案』（失败模式：炒糊了重做/换人工）和『上线监控』（先一家店试+看差评+差评升 2 倍换回人工）。八模块 = 传统五件套（背景/场景/功能/边界/验收升级版）+ AI 三件套（模型/评测/数据）——『AI 三件套是区别』：没有评测设计（怎么定义做得好）的 AI 需求无法验收——我 3 年设计院的『设计任务书』经验打了底，AI 三件套我理解得透。」

⑧ 小结口诀
「八模块：传统五件套升级（背景目标/用户场景/功能需求/失败兜底/上线监控）+ AI 三件套灵魂（模型故事/评测设计/数据需求）——评测设计是灵魂：没有评测的 AI 需求无法验收。」

⑨ 三轮追问（面试官深挖）
追问1：「八模块里如果只保留三个（时间不够），保留哪三个？」「保留 AI 三件套（模型故事/评测设计/数据需求）——为什么：这三块是 AI 和传统的区别（传统五件套里背景/场景/功能——传统 PRD 有现成模板可以补；AI 三件套是 AI 特有的（不写=AI 需求不完整）；其中评测设计最优先（没有评测=无法验收——整个需求没法判断成功）——时间不够：AI 三件套优先（模型/评测/数据——AI 的灵魂），传统五件套从模板补。」
追问2：「评测集（评估测试题）怎么建（从哪来）？」「三个来源：①真实数据抽样（从历史对话/用户反馈里抽：覆盖高频场景——最常见最真）；②人工构造（设计边界场景：极端问题/脏数据（乱输入）——覆盖边界）；③三方共建（产品定业务场景+算法定技术口径+数据团队整理——共建评测集，尺子一起造才服气）——评测集来源：真实抽+边界造+三方建（评测集覆盖全，验收才可信）。」
追问3：「八模块和『传统 PRD 五件套』的关系（是推翻还是升级）？」「是『升级』不是『推翻』：传统五件套（背景/场景/功能/边界/验收）继续用——AI 语境下升级（背景升级为背景+目标（加成功指标）；场景升级为场景+输入输出；功能升级为功能+能力边界；边界升级为失败模式与兜底；验收升级为上线与监控）；再加 AI 三件套（模型故事/评测设计/数据需求——AI 特有的新增）——八模块=五件套升级+三件套新增（不推翻传统，是传统之上加 AI 的料）。」

⑩ 进阶加分点（说出口就加分）
加分点1：把评测设计和「业务价值」挂钩。「我的评测设计不只技术指标（准确率 90%），还挂业务指标（准确率 90% 对应『回复及时率 80%』——评测达标=业务达标）——评测设计不脱离业务（技术指标是过程、业务指标是结果——两个都写，评测才有业务意义）」——「评测挂业务」说明你懂「评测的最终目的是业务」（不是技术自嗨）。
加分点2：引入「失败模式分级」。「我的失败模式分三级：高频错误（天天错——必须兜底：关键词匹配）；高风险错误（出大事——一票否决：答错医疗信息——必须人工）；低频低险错误（偶尔错——记录观察）——三级分级：资源给高频高险（重点兜底），低频低险写个预案就够」——「失败模式分级」说明你有「风险评估」意识（不是所有错误同等对待）。
加分点3：把「上线与监控」升级为「效果看板」。「我的上线监控会做成『效果看板』（可视化：准确率/满意度/投诉率——趋势图每周看）——看板让『AI 效果』看得见（不是『感觉还行』，是『趋势数据说话』：准确率这周降了 3%——趋势警报——提前处理（不等投诉爆发））」——「效果看板」说明你懂「AI 上线后要持续监测」（上线是起点不是终点）。

⑪ 话术库（直接抄着说）
「AI PRD 八模块：传统五件套（背景目标/用户场景/功能需求/失败兜底/上线监控）+ AI 三件套（模型故事/评测设计/数据需求）。」
「评测设计是灵魂：评测集（覆盖什么场景）+指标（准确率/满意度）+阈值（达标线）——没有评测设计的 AI 需求无法验收。」
「模型故事：依赖什么模型能力+能力边界在哪（做不到什么）+模型选型。」
「失败模式与兜底：答错/答偏/不答——降级/重试/人工/拒答——『AI 产品必须写出错预案』。」
「上线与监控：灰度计划+线上监控指标+回滚条件——上线是起点不是终点。」

⑫ 小白 Q&A（可能踩的坑）
Q1：八模块会不会太多（写不过来）？用「一页纸模板」：每模块一句到两句（目标一个数、评测三个数、兜底三种错）——八模块一页纸能装下（不是八章是八段——一页纸模板，新人照着填）。
Q2：模型故事/评测设计要懂技术才能写吗？不用懂算法——写「业务口径」：模型故事写「这个功能靠模型什么本事、做不了什么」（业务语言）；评测设计写「怎么算做得好」（准确率 90%——业务要求）——技术实现（模型内部）算法负责，业务口径（要什么效果）你负责。
Q3：写 AI PRD 没写过（没有模板），从哪开始？从「一页纸模板」开始：把八模块每块填一句（目标一个数、场景一句话、评测三个数……）——填完第一版就合格（八模块全在）；再迭代（每块写深）——模板起步（八模块骨架），细节慢慢长。

⑬ 没人告诉你的事（面试潜规则）
这道题面试官真正在听的，是「你会不会写 AI 需求」——大部分候选人答「PRD 要写清楚」（空话），你说「八模块：传统五件套升级+AI 三件套」（具体结构——八块都有内容）——当场拉开（面试官要的是「能写 AI PRD 的人」，不是「会说 PRD 重要的人」）。另一个潜规则：这道题的灵魂是「评测设计」——「没有评测设计的 AI 需求无法验收」是全场金句（80% 的候选人漏掉评测（只答功能/场景——传统思维），你多说评测（评测集+指标+阈值——怎么定义做得好）——说明你懂 AI 验收（效果要测了才知道——这是 AI 产品经理的核心认知）。还有一个：用「设计任务书」讲八模块，比背「背景/场景/功能」动人十倍——你的真实经历（传统文档的骨架+AI 的增量）就是最稀缺的素材。

⑭ 做一件事（学完就动手）
今天找一个你常用的 AI 功能（AI 客服/AI 摘要/AI 翻译都行），给它写一份「八模块一页纸」：①背景目标（解决什么问题+一个指标）；②用户场景（谁+场景+输入输出）；③功能需求（做什么+不做什么）；④模型故事（靠什么本事+边界）；⑤评测设计（怎么算好：评测集+指标+阈值）；⑥数据需求（数据哪来+多久更新）；⑦失败模式（它最近答错的情况+产品怎么兜底）；⑧上线监控（灰度+监控+回滚）——写完你会惊叹：原来 AI 功能背后要有这么多设计——你从「用 AI 的人」变成「设计 AI 的人」。

⑮ 求职助手联系（面试前必做）
面试前用本卡做 3 件事：①把「八模块」练熟（面试框架：传统五件套+AI 三件套）；②准备你的「PRD」案例（设计任务书经验+自己写过的 AI 功能一页纸——真实经历最动人）；③把「评测设计是灵魂：没有评测的 AI 需求无法验收」练熟（收口金句）。面试被问「AI PRD 8 大模块」时：先说结构（传统五件套升级+AI 三件套）→再说灵魂（评测设计）→收口（八模块写全，AI 需求才完整）——结构清楚+灵魂点透+经历真实，面试官立刻记住你。

⑯ 练习（自己测一遍）
1.（记忆）AI PRD 八模块是哪八个？——答案：①背景与目标②用户场景③功能需求④模型故事⑤评测设计⑥数据需求⑦失败模式与兜底⑧上线与监控。
2.（灵魂）八模块里的「灵魂」（没有它 AI 需求无法验收）是哪个？——答案：⑤评测设计（评测集+指标+阈值——怎么定义做得好）。
3.（角色）面试官追问「AI 三件套是哪三件、为什么是区别」，你怎么回答？——参考答案：「三件套：模型故事（依赖什么能力+边界）、评测设计（怎么算做得好：评测集+指标+阈值）、数据需求（数据从哪来）——为什么是区别：传统 PRD 不需要写这三块（传统功能不依赖模型、效果确定不用测、数据自备）；AI 产品全依赖（模型会错（写模型故事）、效果要测（写评测设计）、数据要养（写数据需求））——AI 三件套写全，AI 需求才完整。」

敏捷开发 Scrum


图怎么读：什么是敏捷开发（Scrum：一种短周期迭代的开发方法）？——核心机制：①三角色——PO（Product Owner：产品负责人——需求优先级负责人，通常是产品经理）、Scrum Master（流程保障者：保证流程跑顺，不干扰内容）、开发团队（自组织：自己分活自己干）；②三工件——Product Backlog（产品需求池：所有需求）、Sprint Backlog（本期任务：本期要做的任务）、增量（每期可用的产出：每期结束能用的东西）；③四会议——Sprint 计划会（定本期做什么）、每日站会（15 分钟：昨天做了什么/今天做什么/有什么阻塞）、Sprint 评审会（演示成果：给干系人看）、Sprint 回顾会（复盘流程：怎么改进——只聊流程不聊人）。产品经理如何参与（PO 职责）：维护需求池（优先级排序：需求评审会定本期范围）→计划会讲清「为什么做这些」（价值传达：让团队知道为什么做）→评审会验收（本期成果符不符合预期）→回顾会提流程改进（需求传达效率/评审反馈速度）。AI 产品特例：Sprint 里加「模型验证」活动（本期需求涉及模型能力：先跑评测（评估测试）再开发——「AI 的 Sprint 要先验证模型再开发功能」）。

① 一句话大白话定义
这道题问的是：敏捷开发（Scrum）是什么？你（产品经理）怎么参与？
用大白话说：Scrum = 短周期迭代（Sprint：1-4 周一个小周期）+ 三角色（PO 产品负责人/Scrum Master 流程保障/开发团队自组织）+ 三工件（产品需求池/本期任务/每期产出）+ 四会议（计划会/站会/评审会/回顾会）——小步快跑，持续交付。产品经理的参与（PO 职责）：维护需求池（排优先级）→计划会讲清为什么做（价值传达）→评审会验收（符不符合预期）→回顾会提改进。AI 产品特例：Sprint 里加「模型验证」（先跑评测（评估测试）再开发——AI 的 Sprint 要先验证模型再开发功能）。

打个比方：装修（Scrum 式装修 对比 传统装修）——传统装修：一次性把全屋图纸画完→施工队干 3 个月→交付（半年后才看到效果——不满意全改）；Scrum 装修：拆成「小周期」（Sprint：每 2 周一个周期——每周期装一个房间）；三角色（业主（PO：定装修优先级——先装厨房还是先装卧室）、工头（Scrum Master：管流程——材料到位没、进度到哪）、施工队（开发团队：自己分活干）；三工件（装修清单（产品需求池：所有要装的）、本期清单（本期任务：这 2 周装厨房）、装好的厨房（增量：每期能用的产出）；四会议（计划会（定这 2 周装厨房）、站会（每天 10 分钟：昨天装了什么/今天装什么/材料到没到）、评审会（每 2 周验收：厨房装好了——业主看）、回顾会（复盘：这次材料买慢了——下次提前））——Scrum 装修：每 2 周能看到一个装好的房间（小步快跑），不满意立刻改（不用等半年）。

30 秒电梯版：「Scrum 是什么：短周期（1-4 周一个 Sprint（迭代周期））迭代交付的敏捷框架——核心机制三个：①三角色——PO（Product Owner 产品负责人：需求优先级负责人——通常是产品经理）、Scrum Master（流程保障者：保证流程跑顺）、开发团队（自组织：自己分活自己干）；②三工件——Product Backlog（产品需求池）、Sprint Backlog（本期任务）、增量（每期可用的产出）；③四会议——Sprint 计划会（定本期做什么）、每日站会（15 分钟：昨天/今天/阻塞）、Sprint 评审会（演示成果）、Sprint 回顾会（复盘流程改进——只聊流程不聊人）。我如何参与（产品经理=PO 职责）：维护需求池（优先级排序：需求评审会定本期范围）→计划会讲清『为什么做这些』（价值传达：团队知道为什么做，做得有劲）→评审会验收（本期成果符不符合预期）→回顾会提流程改进（需求传达效率/评审反馈速度）。AI 产品特例：Sprint 里加『模型验证』活动——本期需求涉及模型能力：先跑评测（评估测试）再开发（『AI 的 Sprint 要先验证模型再开发功能』——模型效果不达标，功能开发了也白做）。」

② 为什么学 / 面试为什么考
敏捷开发（Scrum）是团队协作的「基础设施」（大厂基本都在用），面试考它的原因有三：
第一，它考「协作常识」。Scrum 是产品团队最常见的协作方式（入职就要参与：计划会/站会/评审会/回顾会——每周都在开）——面试官想看你懂不懂「团队怎么协作」（三角色/三工件/四会议——基本机制）——不懂 Scrum=入职听不懂会（团队说「站会」「回顾」你不知道干嘛）。
第二，它考「产品角色认知」。「你如何参与」——考产品经理在 Scrum 里的角色（PO：维护需求池/计划会讲价值/评审会验收/回顾会提改进——产品是需求的主人）——面试官想看你懂不懂「产品经理在敏捷里的职责」（不是参与者是 PO——需求的优先级负责人——产品对需求负责）。
第三，它考「AI 适配」。AI 产品用 Scrum 有特例（Sprint 里加「模型验证」：先评测（评估测试）再开发——AI 效果不确定，先验证模型）——面试官想看你懂不懂「AI 敏捷的特有活动」（模型验证/评测（评估测试）进 Sprint——AI 的 Sprint 和传统 Sprint 的差别）。
一句话：这道题考的是「协作常识」＋「产品角色认知」＋「AI 适配」。

③ 原理拆解：三角色→三工件→四会议→产品参与→AI 特例

第一步：三角色——PO/Scrum Master/开发团队。Scrum 的三个角色：PO（Product Owner：产品负责人——需求优先级负责人：定「做什么」——通常产品经理兼任（产品经理=PO：需求的最终负责人）——PO 的核心：定需求优先级（先做什么后做什么——PO 拍板）；Scrum Master（流程保障者——保证流程跑顺：会按时开/阻塞及时解决/流程怎么改进——SM 不管内容（不管「做什么」）只管流程（「怎么做顺」）——SM 常由资深工程师或专门的人担任）；开发团队（自组织——自己分活自己干：本期任务怎么拆、谁做什么——团队自己定（不是 PO 派活——团队自组织）——团队成员 3-9 人（小团队：大了没法自组织）。
打个比方：装修团队三角色（Scrum）——业主（PO：定优先级——先装厨房还是先装卧室——业主拍板）；工头（Scrum Master：管流程——材料到没到、进度顺不顺——工头不管「装什么」（那是业主的事）只管「怎么装顺」）；施工队（开发团队：自组织——这 2 周装厨房怎么拆（拆墙/铺管/贴砖）、谁做哪块——施工队自己分（不是业主派活——施工队自己组织）。三角色：PO 定做什么（优先级）、SM 管怎么做顺（流程）、团队自组织（怎么干）。
翻车案例：有团队角色混乱——PO 没定优先级（「都急，你们看着办」）——开发团队不知道先做啥（自己猜）——做完 A 发现老板要 B（猜错了——返工）——「没 PO」翻车：三角色各司其职（PO 定优先级（做什么——先做 A 还是 B——PO 拍板）；SM 管流程（怎么做顺）；团队自组织（怎么干））——没 PO 定优先级=团队猜（猜错返工）。

第二步：三工件——Product Backlog/Sprint Backlog/增量。Scrum 的三件工件：Product Backlog（产品需求池——所有需求：待做的需求全在这里——按优先级排好（PO 维护：排序是 PO 的核心工作）；Sprint Backlog（本期任务——本期要做的任务：从需求池里挑本期要做的（计划会定）——本期任务拆解（拆成小任务：谁做什么）；增量（每期可用的产出——本期做完能用的东西：每期结束交付（一个能用的功能/版本——不是半成品——「可用」是标准）——增量保证「小步快跑」：每期都有能用的东西（不是攒半年交付一次）。
打个比方：装修三工件——装修清单（产品需求池：所有要装的——厨房/卧室/客厅——按优先级排好（业主维护：排序是业主的核心工作）；本期清单（本期任务：这 2 周装厨房——拆成小任务：拆墙/铺管/贴砖）；装好的厨房（增量：这 2 周结束能用的东西——厨房能做饭了（不是装一半——「能用」是标准）——增量保证每 2 周有能用的东西（不是攒半年一次装完）。
翻车案例：有团队没有「增量」意识（每期交半成品）——Sprint 结束「功能做了一半」（还差测试/还差上线）——「增量」不达标（不是能用的东西）——下期继续做（半成品积累——3 期后全是半成品）——「没有增量」翻车：增量=每期可用的产出（每期结束交付能用的功能——不是半成品）——没有增量=半成品堆积（3 期后全是半成品——没一个能用）。

第三步：四会议——计划会/站会/评审会/回顾会。Scrum 的四个会议：Sprint 计划会（每期开头：定本期做什么——从需求池挑本期任务（PO 讲价值：为什么做这些——团队估工作量：做得了吗——定本期范围：本期做 3 条还是 5 条）；每日站会（每天 15 分钟：昨天做了什么/今天做什么/有什么阻塞（卡住的事）——站着开（不坐下——保持短）——站会不是汇报（是对齐：互相知道进度+阻塞及时暴露）；Sprint 评审会（每期结束：演示成果——团队演示本期做的功能（给 PO 和干系人看）——PO 验收：符不符合预期（不符→记改进）；Sprint 回顾会（每期结束：复盘流程——聊什么：流程怎么改进（需求传达效率/评审反馈速度/沟通问题）——只聊流程不聊人（不追责：改进的是「事」不是「人」）。
打个比方：装修四会议——计划会（每 2 周开头：定这 2 周装厨房——业主讲为什么（厨房最急：天天做饭）；施工队估量（2 周装得完吗——拆墙要 1 周——定范围：这期装「拆墙+铺管」）；站会（每天 10 分钟：昨天装了什么/今天装什么/材料到没到——站着说（不坐下——保持短）；评审会（每 2 周结束：演示成果——业主看厨房（装好能用吗——验收：不符合预期→记改进）；回顾会（每 2 周结束：复盘流程——材料买慢了→下次提前买（聊流程不聊人：不怪谁——改进的是「事」不是「人」）。
翻车案例：有团队站会开成汇报会——每天站会 30 分钟（每人讲 5 分钟细节——不是对齐是汇报）——团队烦（站会变批斗会——阻塞没暴露：都说「还行」（怕被追责）——「站会变汇报」翻车：站会 15 分钟（昨天/今天/阻塞——对齐三件事）+不坐下（保持短）——变汇报=浪费时间+阻塞不暴露（都说「还行」——出问题没人说）。

第四步：产品经理（PO）如何参与——四个职责。产品经理在 Scrum 里的参与（PO 职责）四个：①维护需求池（优先级排序——需求评审会定本期范围：PO 的核心工作——需求池排序（先做什么后做什么——PO 拍板）；②计划会讲清「为什么做这些」（价值传达——团队知道为什么做（不是「让你做就做」——讲清价值（为谁解决什么问题/带来什么——团队做得有劲+做对方向）；③评审会验收（本期成果符不符合预期——验收标准（本期做的符不符合需求——不符→记改进（下期修）；符合→确认通过（成果可用）；④回顾会提流程改进（需求传达效率/评审反馈速度——产品流程的问题（需求传达不清（团队老问）——改进（需求写细）；评审反馈慢（下期才发现不对——改进（评审前置）——产品在回顾会提「产品的流程问题」——不是只批评团队）。
打个比方：业主（PO）怎么参与装修——①维护装修清单（优先级排序——先装厨房还是卧室——业主拍板）；②计划会讲清为什么（这 2 周装厨房——因为厨房最急（天天做饭——团队知道为什么装（装得有劲+装对方向）；③评审会验收（厨房装得符不符合要求——装得不好→记改进（下期修）；装得好→确认（可用）；④回顾会提改进（图纸表达不清（施工队老问）→改进（图纸画细）；验收太慢（装完 3 天才看）→改进（装完当天看）——业主提「图纸/验收流程」的问题——不是只怪施工队）。
翻车案例：有产品经理只参与「评审会」（其余会都不参加）——需求池没人维护（优先级乱——团队自己猜）；计划会不讲价值（团队不知道为什么做——瞎做）；回顾会不去（流程问题没人提——老问题反复犯）——「只参加评审会」翻车：产品经理（PO）四个职责（维护需求池/计划会讲价值/评审会验收/回顾会提改进——四个会都参与）——只参加评审会=需求没人管（优先级乱）+价值没人讲（瞎做）+流程没人提（老问题反复）。

第五步：AI 产品特例——Sprint 里加「模型验证」活动。AI 产品用 Scrum 的特例：Sprint 里加「模型验证」活动——本期需求涉及模型能力（本期要做「AI 客服」——涉及「意图识别」模型能力）——先跑评测（评估测试）再开发（Sprint 开头加「模型验证」：先评测（评估测试）模型能力（准确率多少——达不达标）——达标才开发（模型能力够——开发功能）；不达标先处理模型（换模型/调提示词（给模型下指令的话）/补数据——模型不达标，功能开发了也白做（功能做好了——模型效果差——功能白做））——「AI 的 Sprint 要先验证模型再开发功能」：传统 Sprint 直接开发（功能是确定的）；AI Sprint 先验证模型（效果是不确定的——先验证再开发——避免白做）。
打个比方：装修的「材料验证」特例（AI 特例）——本期要装「智能马桶」（涉及新材料能力）——先「验证材料」（买来试装：这材料防水吗（评测）——达标才正式装；不达标先换材料（换品牌/调方案——材料不达标，装上去也白装（装完漏水——返工））——「装修的 Sprint 要先验证材料再施工」：传统装修直接施工（材料是确定的）；智能马桶 Sprint 先验证材料（效果不确定——先验证再施工——避免返工）。AI 同理：Sprint 加「模型验证」（先评测（评估测试）再开发——避免白做）。
翻车案例：有团队 AI Sprint 没有「模型验证」——Sprint 计划会直接排「开发 AI 客服」（没验证模型）——团队开发 2 周（界面/交互全做好）——评审会：模型效果差（准确率只有 50%——没提前验证）——功能全白做（界面再好——模型不行——功能不能用）——「没模型验证」翻车：AI 的 Sprint 加「模型验证」（先评测（评估测试）再开发——本期需求涉及模型能力：先跑评测（达标才开发））——没有验证=开发 2 周白做（模型不达标——功能全废）——「AI 的 Sprint 要先验证模型再开发功能」。
小结：三角色（PO/SM/团队）→三工件（需求池/本期任务/增量）→四会议（计划/站会/评审/回顾）→产品参与（维护需求池/讲价值/验收/提改进）→AI 特例（Sprint 加模型验证——先评测再开发）。

④ 对比表格：传统开发 对比 敏捷 Scrum 对比 AI 敏捷
| 维度 | 传统开发（瀑布） | 敏捷 Scrum | AI 敏捷 | |------|------|------|------| | 节奏 | 一次交付（半年后） | 短周期（Sprint 1-4 周） | 短周期+模型验证 | | 需求 | 一次定完（不轻易改） | 需求池（持续迭代） | 需求池+模型能力依赖 | | 会议 | 少（阶段评审） | 四会议（计划/站会/评审/回顾） | 四会议+模型验证活动 | | 验收 | 最后验收（半年后） | 每期评审（小步快跑） | 每期评审+评测（评估测试）验收 | | 变化 | 怕变（变=返工） | 拥抱变化（每期可调） | 拥抱变化+模型能力变化 | | 产品角色 | 写需求文档 | PO（优先级负责人） | PO+模型验证组织者 |

⑤ 3+个例子：Scrum 实战
例子1：AI 客服产品 Sprint（计划会）。Sprint 计划会：PO（产品）讲本期范围（做「AI 自动回复」——为什么：回复及时率 40% 太低）+模型验证（先评测（评估测试）意图识别模型：准确率 82%（达标——可以开发）；团队估量（开发 1.5 周+评测 0.5 周——本期做 3 条需求）；定本期范围（AI 回复+人工转接+反馈收集）。
例子2：每日站会（阻塞暴露）。站会 15 分钟：开发 A「昨天完成回复界面，今天接模型接口，阻塞：模型接口文档没给」——SM 记下（阻塞暴露：会后协调算法给文档）——阻塞当天解决（不是等 2 周评审才发现——站会的价值：阻塞及时暴露）。
例子3：评审会验收（产品验收）。Sprint 评审会：团队演示（AI 回复功能：输入「运费多少」→AI 答「满 99 免运费」）；PO 验收（符合预期：回复及时率目标 80%——测试 3 个场景通过——确认通过）；不符的记改进（「答非所问的场景」——下期修）。
例子4：回顾会提改进（产品流程）。Sprint 回顾会：产品提改进（需求传达效率低——团队老问「这个需求什么意思」——改进：需求写「输入→输出」示例）；团队提改进（评审反馈慢——下期改：评审前置（开发到一半先给产品看）——回顾会：聊流程不聊人（改进的是「事」不是「人」）。

⑤b 补充板块：产品经理在 Scrum 里的「三个不要」
产品经理（PO）在 Scrum 里，除了四个职责还有「三个不要」：
第一，不要「每天改优先级」：Sprint 期间（本期进行中）不改本期范围（本期定了就做完——天天改=团队白干（今天改 A 明天改 B——Sprint 乱套）——要改排到下期（Sprint 期间稳定——下期再调）。
第二，不要「跳过站会」：站会是产品了解进度的窗口（每天 15 分钟——阻塞及时暴露——产品跳过站会=阻塞没人关注（需求卡住不知道）——站会必到（哪怕只说一句「有问题找我」）。
第三，不要「评审会甩锅」：评审会验收时不说「怎么做成这样」（甩锅——团队白干 2 周），说「这个场景和预期不符，我们看下为什么」（对齐——预期没传达清（产品的锅）还是实现错了（团队的锅）——对事不对人：评审是验收不是追责）。
一句话：产品三个不要——Sprint 期间不改范围（天天改=白干）、不跳站会（阻塞没人关注）、评审不甩锅（对事不对人——验收不是追责）。

⑤c 补充板块：AI Sprint 的「模型验证」怎么做——三步
AI Sprint 加「模型验证」活动，三步：
第一，本期识别（哪些需求涉及模型）：计划会时标出「模型依赖」需求（AI 回复（依赖意图识别）、AI 摘要（依赖摘要模型）——标出涉及模型的需求（不涉及模型的照常开发）。
第二，Sprint 开头验证（先跑评测（评估测试））：Sprint 第一周跑评测（评估测试）：用评测集（评估测试题）测模型（准确率多少——达标（≥90%）：继续开发；不达标：先处理模型（换模型/调提示词（给模型下指令的话）/补数据——模型达标才开发功能）。
第三，评审会双验收（功能+效果）：评审会不只验功能（功能做了没），还验效果（评测（评估测试）过没过：准确率 90%——功能做了+效果达标=完成（双验收——AI 功能的完成标准）。
一句话：模型验证三步——本期识别（标出模型依赖）、开头验证（先跑评测再开发）、双验收（功能+效果都过才算完成）——三步走完，AI Sprint 不白做。

⑥ 常见误区（3个）
误区1：「Scrum 就是每天开站会。」错！站会只是四会议之一——Scrum 是完整机制（三角色（PO/SM/团队）+三工件（需求池/本期任务/增量）+四会议（计划/站会/评审/回顾）——只开站会=只有壳没有芯（优先级没人管/增量没有/回顾不做——只剩站会的 Scrum 不叫 Scrum）。
误区2：「PO 就是传达需求的（团队做什么照说）。」错！PO 是「需求的主人」（定优先级（先做什么——PO 拍板）+讲价值（为什么做）+验收（符不符合预期）——PO 不是传话筒（传达需求=没主见；定优先级+验收=有主见）——PO 对需求负责（不是照说，是负责）。
误区3：「AI 产品和传统一样做 Scrum（照搬就行）。」错！AI Sprint 要加「模型验证」（先评测（评估测试）再开发——AI 效果不确定，先验证模型）——照搬传统（直接开发）=模型不达标白做（开发 2 周全废）——AI 的 Sprint 要先验证模型再开发功能。

⑦ 第一人称面试回答（3年景观设计→自学转行 AI 产品）
「我 3 年景观设计，被裁后自学转行——Scrum 的机制，我做景观设计时有类似实践：设计院做项目不是『传统瀑布』（一次画完全部图纸→施工 1 年→交付——半年后业主才看到效果——不满意全改）；我们做的是『分段交付』（和 Scrum 同构）：每 2 周一个『段』（Sprint）——每段交付一个『能看的成果』（一段：总平面；二段：节点详图——每段业主能看能反馈）；角色（业主（PO：定每段优先级——先出总平面还是先出效果图——业主拍板）；项目负责人（Scrum Master：管进度——图纸到没到/审批过没过）；设计组（开发团队：自组织——谁画总平、谁画详图）；会议（段计划会（定这段画什么）/站会（每天 10 分钟：昨天画了什么/今天画什么/规范卡没卡住）/段评审会（给业主看成果——验收）/段回顾会（复盘：上次审批慢了——这次提前送审））——这套我做设计时用了 3 年，现在才知道它叫 Scrum。转行学 AI 产品后，把『分段交付』翻译成 Scrum 语言：三角色（PO/Scrum Master/团队）+三工件（需求池/本期任务/增量）+四会议（计划/站会/评审/回顾）；产品经理（PO）参与：维护需求池/计划会讲价值/评审会验收/回顾会提改进；AI 特例：Sprint 加『模型验证』（先评测（评估测试）再开发——AI 效果不确定，先验证模型再开发功能——就像施工前先验材料）。我没有大厂 Scrum 经验，但设计院『分段交付』三年证明：我懂敏捷的节奏和产品角色——Scrum 的芯，我用了三年。」

⑧ 小结口诀
「三角色（PO/SM/团队）、三工件（需求池/本期/增量）、四会议（计划/站会/评审/回顾）；PO 职责：维护池子/讲价值/验收/提改进；AI 特例：Sprint 加模型验证——先评测再开发。」

⑨ 三轮追问（面试官深挖）
追问1：「Sprint 期间团队说『做不完』（本期范围太大），怎么办？」「先『砍范围』再『加人』：砍范围（把本期任务砍到能做完：Must 保留（本期必做）、Should 顺延（排下期）——本期范围太大是『计划会估量错了』（估量是团队的活——PO 提供信息（需求细节/价值——团队估量错 PO 有责任：信息没给全）；加人（不是首选——加人慢（新人要熟悉）——范围砍不动才考虑）；根本解（回顾会复盘：为什么估量错——需求不清（下期写细）还是估量方法有问题（下期改进））——做不完：砍范围→加人（备选）→回顾会根治（为什么估量错）。」
追问2：「站会上有阻塞（团队被卡住），产品经理做什么？」「分三类：需求阻塞（需求不清卡住——产品当场解答（站会前准备好：需求细节都在脑子里）；外部阻塞（依赖算法/第三方——产品协调（拉算法对齐/催第三方——阻塞是产品的活：牵线搭桥）；技术阻塞（技术难题卡住——SM 主导（组织技术讨论——不是产品的事））——站会阻塞三分类：需求类（产品答）、外部类（产品协调）、技术类（SM 管）——产品在站会的价值：阻塞当天解决（不拖到评审）。」
追问3：「回顾会大家都不说话（不敢提问题），怎么开？」「三招让回顾会活起来：①主持人换人（不是 SM 主持——轮流主持（大家敢说——不是对 SM 汇报）；②匿名提问题（先写纸条匿名提——再讨论（匿名=敢说真话）；③只聊流程不聊人（强调规则：回顾会改进的是『事』不是『人』——不追责（大家放心说）；开头先肯定（这期做得好的 3 件事——先暖场再改进（先表扬后改进——气氛好了才敢提））——三招：轮换主持/匿名纸条/先肯定后改进——回顾会敢说话，流程才改进。」

⑩ 进阶加分点（说出口就加分）
加分点1：把「模型验证」升级为「验证 Sprint 前置」。「我的 AI 项目会把『模型验证』做成正式活动：Sprint 计划会标『模型依赖需求』→Sprint 第一周固定『评测（评估测试）日』（跑评测集（评估测试题）——达标进开发、不达标进『模型攻坚』（本期做模型，功能下期））——验证前置（不占开发时间——独立环节）」——「验证 Sprint 前置」说明你把 AI 特例做成了机制（不是随口说）。
加分点2：引入「PO 决策记录」。「我的 PO 职责会留痕：每次优先级决策写『决策记录』（为什么 A 先做 B 后做——价值数据+理由）——决策记录的用处：①团队服气（有依据——不是拍脑袋）；②争议可查（下期有人质疑——翻记录）；③回顾会复盘（决策质量——这期优先级定得好不好）——决策记录让 PO 的优先级『有据可查』」——「PO 决策记录」说明你懂「决策要留痕」（不是口头定完就忘）。
加分点3：把评审会升级为「数据评审」。「我的 AI 评审会不只演示功能，还过『数据』：评测（评估测试）数据（准确率 90%——达标没）；业务数据（回复及时率 78%——离目标 80% 差 2%——下期怎么补）——数据评审让验收有标准（不是『演示好看』，是『数据达标』——AI 评审会，数据说话）」——「数据评审」说明你懂 AI 验收的本质（效果要数据验证——不是演示）。

⑪ 话术库（直接抄着说）
「Scrum = 短周期迭代（Sprint 1-4 周）+三角色（PO/Scrum Master/团队）+三工件（需求池/本期任务/增量）+四会议（计划/站会/评审/回顾）。」
「产品经理=PO：维护需求池（优先级排序）→计划会讲价值（为什么做）→评审会验收（符不符合预期）→回顾会提改进。」
「站会 15 分钟三问：昨天做了什么/今天做什么/有什么阻塞——阻塞当天解决。」
「AI 产品特例：Sprint 里加『模型验证』——先跑评测（评估测试）再开发（AI 的 Sprint 要先验证模型再开发功能）。」
「回顾会只聊流程不聊人——改进的是『事』不是『人』。」

⑫ 小白 Q&A（可能踩的坑）
Q1：Scrum 和「敏捷」是一回事吗？敏捷（Agile：一种开发理念——小步快跑拥抱变化）是「理念」，Scrum 是「具体方法」（实现敏捷的一种框架：三角色/三工件/四会议）——就像「健康」（理念）和「跑步」（具体方法）——敏捷是理念，Scrum 是方法。
Q2：站会每天开会不会太频繁？站会 15 分钟（很短——不坐下——每天开成本低）；价值大（阻塞当天暴露（不拖到评审——当天解决）；进度天天对齐（不用等周报）——15 分钟换「不踩坑」——值。
Q3：AI 的「模型验证」会不会拖慢 Sprint？会占一点时间（第一周跑评测（评估测试）——半天到一天）——但「验证时间」远小于「白做时间」（验证半天 对比 开发 2 周白做——验证是省钱不是花钱）——模型验证是 AI Sprint 的「保险」（花小钱防大坑）。

⑬ 没人告诉你的事（面试潜规则）
这道题面试官真正在听的，是「你会不会开会」——说「站会三问」（昨天/今天/阻塞——真开过会）、「回顾会只聊流程不聊人」（被追责过——懂规则）、「评审会验收不是追责」（验收过——懂分寸）——细节越具体，说明真参与过 Scrum（背书「三角色三工件四会议」=背概念）。另一个潜规则：这道题的加分点是「AI 特例」——大部分候选人答「三角色/四会议」（背机制——谁都会），你多说「Sprint 加模型验证」（先评测（评估测试）再开发——AI 特有活动）——说明你懂「AI 敏捷的独特之处」（效果不确定——先验证模型——这是 AI 产品经理和传统产品经理的分水岭）。还有一个：用「设计院分段交付」讲 Scrum，比背「PO/SM/团队」动人十倍——你的真实经历（传统项目的分段交付和 Scrum 同构）就是最稀缺的素材——面试官会记住「这个转行者懂敏捷的节奏」。

⑭ 做一件事（学完就动手）
今天把你手头的一件事（学习计划/求职准备/副业项目都行）改成「Scrum 式」：①拆周期（Sprint：2 周一个小周期）；②定三角色（你=PO（定优先级——先做什么）；你=SM（管进度——每周检查）；你=团队（自组织——怎么干）；③三工件（任务池（所有任务）/本期任务（这 2 周做 3 件）/每期产出（2 周后能用的成果）；④四会议（周计划（定这周做什么）/每日 10 分钟（昨天/今天/卡住）/2 周评审（成果验收）/2 周回顾（流程改进）——做完两周，你会发现：小步快跑，比闷头干 3 个月强一倍（每 2 周有成果——不焦虑）。

⑮ 求职助手联系（面试前必做）
面试前用本卡做 3 件事：①把「三角色+三工件+四会议」练熟（面试框架）；②准备你的「敏捷」案例（设计院分段交付三年——真实经历最动人）；③把「AI 的 Sprint 要先验证模型再开发功能」练熟（AI 特例收口）。面试被问「敏捷开发（Scrum）」时：先说机制（三角色/三工件/四会议）→再说产品参与（PO 四职责）→收口（AI 特例：模型验证）——机制全+角色清+AI 适配到位，面试官立刻记住你。

⑯ 练习（自己测一遍）
1.（记忆）Scrum 的三角色/三工件/四会议是？——答案：三角色（PO/Scrum Master/开发团队）；三工件（产品需求池/本期任务/增量）；四会议（计划会/站会/评审会/回顾会）。
2.（角色）产品经理在 Scrum 里的角色和职责是？——答案：PO（产品负责人）：维护需求池（优先级排序）/计划会讲价值/评审会验收/回顾会提改进。
3.（AI 特例）AI 产品用 Scrum 的特例是什么？——参考答案：「Sprint 里加『模型验证』活动：本期需求涉及模型能力——先跑评测（评估测试）（准确率达标没）再开发——『AI 的 Sprint 要先验证模型再开发功能』——不验证=开发 2 周白做（模型不达标——功能全废）。」

需求池追问版


图怎么读：需求池（backlog：产品需求的总清单——所有待做的需求都放这里）管理的「追问版」（面试官深挖三个问题）：①「评审会上需求吵起来怎么办」——答三个机制：数据先行（每个需求带「价值数据」（影响用户数/预期指标——用数据讨论不是用嗓门））、优先级规则（预先定好排序标准（RICE（加权评分：按触达×影响×信心÷成本打分）/北极星（核心目标）相关性——按规则排不按人排）、决策升级（吵不出结果的——记录分歧+双方理由，升级给负责人拍板——「评审会不是争输赢，是产出决策」）；②「需求池多大合适」——答：池子要「小而活」：长期池（战略方向）20-30 条、近期池（2-3 个迭代（开发周期））10 条以内——池子太大=评审失焦（「需求池是过滤器不是仓库」——3 个月没评审的需求自动清理）；③「怎么防止紧急需求插队」——答：插队机制明确（生产事故（系统出问题）/客户承诺（答应客户的事）可以插——其他「紧急」走评审：紧急需求也要记入池子（插队的是「优先级」不是「流程」——事后复盘插队频率（插队太多=排期失真）。核心：给「决策机制」不是给「流程」（流程=怎么走：记录/评审/排期——谁都会说；决策机制=分歧时听谁的、规则是什么——才是追问要的）。

① 一句话大白话定义
这道题问的是：需求池（所有待做需求的清单）怎么管理？——而且是「追问版」（面试官会深挖三个问题：评审吵起来怎么办/池子多大合适/紧急需求插队怎么办）
用大白话说：需求池管理有三个「决策机制」：①评审吵起来——数据先行（每个需求带价值数据）+优先级规则（RICE（加权评分）预先定好）+升级拍板（吵不出的升级给负责人）；②池子多大——小而活（长期池 20-30 条+近期池 10 条以内——池子太大评审失焦；3 个月没评审的需求自动清理——「需求池是过滤器不是仓库」）；③紧急插队——机制明确（生产事故/客户承诺可以插，其他走评审；插队的是优先级不是流程；事后复盘插队频率）。核心：追问要的是「决策机制」（分歧时听谁的），不是「流程」（怎么走）。

打个比方：家庭「想做的事清单」（需求池）——三个追问：①家人吵起来（「去海边还是去爬山」吵翻天）——怎么办：数据先行（看数据：上周孩子说想玩沙（价值数据）、查天气（海边台风爬山晴——用数据不用嗓门））+规则（提前定好「投票制」——按规则排不按嗓门排）+升级拍板（吵不出——爸爸妈妈拍板（升级给负责人）——不是争输赢，是产出决策）；②清单多大——小而活（「长期清单」20 条（想去的远方——战略方向）+「近期清单」10 条以内（最近 2-3 个周末——近期计划）——清单太大=周末会开得没完（评审失焦）；3 个月没提的事=划掉（自动清理——清单是过滤器不是仓库）；③临时插队（奶奶突然住院——真紧急（生产事故级）可以插；「突然想逛街」——走周末会评审（插队的是优先级不是流程）——事后看看「插队多不多」（插太多=计划形同虚设）。

30 秒电梯版：「需求池管理三个决策机制：第一，评审吵起来——三步：数据先行（每个需求带价值数据：影响用户数/预期指标——用数据讨论不是用嗓门）；优先级规则（预先定好排序标准：RICE（加权评分：触达×影响×信心÷成本）或北极星（核心目标）相关性——按规则排不按人排）；决策升级（吵不出结果的——记录分歧+双方理由，升级给负责人拍板——『评审会不是争输赢，是产出决策』）。第二，池子多大——小而活：长期池（战略方向）20-30 条、近期池（2-3 个迭代）10 条以内——池子太大=评审失焦（『需求池是过滤器不是仓库』——3 个月没评审的需求自动清理）。第三，紧急需求插队——插队机制明确：生产事故/客户承诺可以插——其他『紧急』走评审（紧急需求也要记入池子——插队的是『优先级』不是『流程』——事后复盘插队频率（插队太多=排期失真）。核心：给『决策机制』不是给『流程』——流程（记录/评审/排期）谁都会说，决策机制（分歧时听谁的、规则是什么）才是追问要的。」

② 为什么学 / 面试为什么考
需求池是产品经理的「日常工具」，面试考「追问版」的原因有三：
第一，它考「决策能力」。「追问版」的追问都是「决策题」（吵起来听谁的、池子多大、插不插队——都是要拍板的）——面试官想看你懂不懂「决策机制」（数据、规则、升级——三个机制都是「怎么拍板」）——决策能力是产品经理的核心（需求管理 90% 是决策，10% 是记录）。
第二，它考「分歧处理」。「评审吵起来怎么办」——考分歧处理（用数据不用嗓门、用规则不用人、吵不出升级）——面试官想看你懂不懂「团队分歧的正确处理」（不是比谁嗓门大，是有机制）——分歧处理决定团队能不能「吵架不伤感情」。
第三，它考「机制思维」。「追问版」的答案全是「机制」（数据机制/规则机制/升级机制/清理机制/插队机制——都是机制）——面试官想看你有没有「机制思维」（个人会做不算，定机制让团队都会做——产品经理的价值是把「会做」变成「机制」）——机制思维是高级产品经理的标志。
一句话：这道题考的是「决策能力」＋「分歧处理」＋「机制思维」。

③ 原理拆解：三个追问→三个机制→收口

追问①：评审会上需求吵起来怎么办——数据先行。第一问：评审吵起来（A 说先做他的需求、B 说先做我的——嗓门比赛）——第一步机制：数据先行——每个需求带「价值数据」（影响用户数：覆盖多少用户（影响 10 万用户 对比 影响 100 人——数据说话）；预期指标：带来什么提升（转化率提升 5% 对比 提升 0.1%——数据说话））——用数据讨论不是用嗓门（A 的需求「影响 10 万用户+转化率提升 5%」、B 的需求「影响 100 人+提升 0.1%」——数据摆出来，谁先做一目了然——不用吵，看数据）；数据不齐的需求（没带数据）——先补齐数据再评审（没数据的需求没有发言权——评审时「你的价值数据呢？」）。
打个比方：家里吵「周末去哪儿」（数据先行）——A 说「去游乐场」（嗓门大）、B 说「去公园」（嗓门更大）——数据先行：游乐场（孩子上次玩得开心——数据：上次去了 3 次孩子都高兴）；公园（最近下雨——数据：天气预报周末有雨）——数据摆出来（游乐场：孩子高兴 3 次；公园：周末下雨去不成）——去哪还用吵吗（数据说话：游乐场——下雨去公园=淋雨）——不吵了（数据替代嗓门）。评审同理：价值数据摆出来，吵就结束了。
翻车案例：有评审会没有「数据先行」——A 需求（影响 10 万用户）和 B 需求（影响 100 人）一起评审——B 的提出者嗓门大（「我这个是老板提的！必须做！」）——结果 B 先做（嗓门赢了）——上线后：B 功能影响 100 人（白做）、A 功能推迟（10 万用户受影响）——「嗓门决定」翻车：没有数据先行（每个需求带价值数据：影响用户数/预期指标——用数据讨论）——嗓门大的先做（做错优先级：10 万用户的需求被 100 人的需求挤掉）——数据先行：数据摆出来，优先级自然对。

追问①（续）：吵不出的——优先级规则+决策升级。数据先行的升级版：吵不出的情况（数据都差不多/数据都缺）——第二、三步机制：优先级规则（预先定好排序标准——不吵架时定好，吵起来按规则排：RICE（加权评分：Reach 触达（影响多少人）×Impact 影响（提升多大）×Confidence 信心（把握多大）÷Effort 成本（要多少工作量）——四个数一乘除，得分排序——按规则排不按人排：得分高的先做——规则是「事前定的尺子」，吵起来不用争人，按尺子量）；决策升级（规则也算不出的（两个需求得分一样/规则争议）——记录分歧+双方理由，升级给负责人拍板（「你们俩各写一条理由，我去找负责人定」——不是拖，是升级：评审会不是争输赢，是产出决策（吵不出的，升级到能拍板的人——决策必须出来，评审会才算开完）。
打个比方：家里吵「先买冰箱还是先买洗衣机」（吵不出）——数据先行（都用旧了——数据差不多）——优先级规则（提前定的尺子：谁坏了影响最大先买——冰箱坏了（菜放不住——天天影响）vs 洗衣机坏了（手洗——累但能忍）——按规则：冰箱先买——按尺子量，不按嗓门排）；还吵不出（觉得规则不合理）——升级拍板（爸爸妈妈拍板：冰箱先买——记录你们俩的理由，爸妈定了——不是争输赢，是产出决策（必须有个决定））。评审同理：规则（RICE 评分）+升级（负责人拍板）——决策必须出来。
翻车案例：有评审会「吵不出也不升级」——A/B 两个需求吵了三次会（每次都是「下次再定」）——拖了 2 个月（两个需求都没做——时间全浪费在吵）——「不升级」翻车：吵不出要升级（记录分歧+双方理由→负责人拍板——评审会不是争输赢，是产出决策（决策出不来=会白开）——升级机制：吵不出的，升级到能拍板的人——决策必须出来。

追问②：需求池多大合适——小而活。第二问：池子多大合适——答：小而活（池子要小、要活）——两层池子：长期池（战略方向：一年内可能要做的方向性需求——20-30 条（池子不超 30 条——方向性需求有限，超过=没有方向））；近期池（2-3 个迭代（开发周期）内要做的需求——10 条以内（一个迭代（2 周）做 3-5 条——近期池 10 条=2-3 个迭代的量——多了排不下））——为什么小而活：池子太大=评审失焦（100 条需求——评审会开不完（每条过一遍就 3 小时）——评审失焦（看了后面忘了前面——池子越大越没法认真评））；「需求池是过滤器不是仓库」（过滤器：需求进来→评审→过滤掉没价值的→留下有价值的——池子里的需求是「过滤过的」（每一条都有价值）；仓库：什么都堆（有价值的没价值的都放——池子变仓库=评审无从下手））——3 个月没评审的需求自动清理（过期清理：3 个月没评审=大概率不重要（重要的早排上了）——自动清理，池子不膨胀）。
打个比方：衣柜（需求池）——小而活：当季衣柜（近期池：这个季节穿的 10 件——2-3 个「季节周期」的量）+换季衣柜（长期池：其他季节的 30 件——方向性储备）——太大（100 件塞一个柜子）=找衣服找不到（评审失焦：100 条需求找不到重点）；「衣柜是过滤器不是仓库」：衣柜里的衣服是「过滤过的」（常穿的留下——不常穿的捐掉）；仓库是「什么都放」（三年没穿的衣服也堆着——占地方）——3 个月没穿的衣服=捐掉（自动清理——过期清理，衣柜不膨胀）。
翻车案例：有团队需求池 200 条（大仓库）——评审会开 3 小时（200 条过一遍）——过完前面的忘了（评审失焦）——半年后：200 条里 150 条没动（没评审的占 75%——池子膨胀）——「池子太大」翻车：需求池是过滤器不是仓库（长期 20-30+近期 10 条以内——小而活）——200 条=评审失焦（3 小时过不完）+没人敢清理（每条都「可能有用」）——自动清理机制（3 个月没评审=自动清理）——池子才活。

追问③：怎么防止紧急需求插队——插队机制明确。第三问：紧急需求（突然来的「急事」）怎么防插队——答：插队机制明确（不是「不许插队」（不现实：真急事不让插=出事），是「什么能插、什么不能插说清楚」）：可以插的（两类：生产事故（系统出问题：线上故障——必须马上修——可以插）；客户承诺（答应客户的事：合同里承诺的交付日期——必须兑现——可以插）——两类真紧急可以插）；其他「紧急」走评审（「老板突然说要做 X」（口头紧急——不一定是真紧急：走评审（带价值数据过一遍——数据不支持的「紧急」不插队）——「紧急」的判定走机制，不走嗓门）——紧急需求也要记入池子（插队的也记录：插队的是「优先级」不是「流程」（插队=这个需求优先级最高——但流程（记录/评审/验收）照走——插队不逃流程）；事后复盘插队频率（每个月看：插队多少次——插队太多（>20%）=排期失真（计划形同虚设——复盘：是排期不对（该预判的没预判）还是「伪紧急」太多（不该插的插了）——复盘调整）。
打个比方：家庭「周末计划」防插队（插队机制）——可以插的：奶奶住院（真紧急：生产事故级——必须去——可以插）；孩子答应同学的生日会（承诺过的事——必须兑现——可以插）；其他「紧急」：孩子「突然想去动物园」（口头紧急——走周末会评审：这周计划满了——下周排——「想去」不插队）；插队的也记录（去奶奶家也记进「家庭计划表」——插队的是优先级不是流程（事紧急但记录照做）；月底复盘「插队多不多」（一个月插了 5 次——太多：是计划没排好（该预判的没预判）还是「伪紧急」多（孩子想一出是一出）——复盘调整）。
翻车案例：有团队没有插队机制——「谁嗓门大谁插队」：周一老板说 A 紧急（插队）、周二销售说 B 紧急（插队）、周三运营说 C 紧急（插队）——一个迭代（开发周期）被插队 5 次——原计划全泡汤（排期失真）——「无机制插队」翻车：插队机制要明确（生产事故/客户承诺可以插——其他走评审；插队也记录（插队的是优先级不是流程）；复盘插队频率（插太多=排期失真））——没有机制=谁都能插（计划形同虚设）。

收口：给「决策机制」不是给「流程」。追问版的收口：面试官追问需求池，真正要的是「决策机制」不是「流程」——流程（怎么走：需求怎么记录、怎么评审、怎么排期——流程是「动作」：谁都会说（记下来→评审→排期——照着念就行））；决策机制（分歧时听谁的、规则是什么、插队怎么判——机制是「决策」：这才是难点（数据先行（吵起来用数据）/优先级规则（按 RICE 排）/升级拍板（吵不出升级）/清理机制（3 个月自动清）/插队机制（什么能插）——五个机制全是「怎么决策」）——回答需求池：给流程（记录评审排期）是入门，给决策机制（五个机制）才是追问要的。
打个比方：家里「家庭会议」（需求池追问）——「流程」：每周六开会、把想法记在本子上、排下个月计划（流程——谁都会说）；「决策机制」：吵起来听谁的（数据先行：用数据不用嗓门）、买什么按什么规则（优先级规则：谁影响大先买）、吵不出怎么办（升级：爸妈拍板）、本子记太多怎么办（清理：3 个月没提的划掉）、突然的事怎么办（插队：奶奶住院可以插、想去动物园不插）——五个机制才是「家庭会议的灵魂」（没有机制=会开了，事定不了）。面试追问同理：给机制，才过。
翻车案例：有候选人答需求池只给流程——「需求池就是记录需求、评审、排期」（流程——背得溜）——面试官追问「评审吵起来怎么办」——答不上（没有决策机制——只背了流程没准备机制）——「只给流程」翻车：面试官追问要的是「决策机制」（分歧时听谁的：数据先行/规则/升级——三个机制）——只给流程（记录评审排期）=面试官一追就露（流程谁都会背，机制才是经验）。
小结：三个追问（吵/大/插）→五个机制（数据先行/优先级规则/升级拍板/清理机制/插队机制）→收口（给决策机制，不是给流程）。

④ 对比表格：流程 对比 决策机制
| 维度 | 流程（入门答案） | 决策机制（追问要的） | |------|------|------| | 内容 | 记录→评审→排期（怎么走） | 数据/规则/升级/清理/插队（怎么决策） | | 评审吵起来 | 「好好沟通」（空话） | 数据先行+规则排+升级拍板 | | 池子大小 | 「越全越好」（大仓库） | 小而活（长期 20-30+近期 10 条） | | 紧急插队 | 「不许插队」（不现实） | 机制明确（事故/承诺可插，其他走评审） | | 谁都会说 | 是（流程背得溜） | 否（机制靠经验） | | 面试效果 | 一追就露 | 追问越深答得越稳 |

⑤ 3+个例子：需求池管理实战
例子1：评审吵起来（数据先行）。评审会：A 提「AI 简历优化」（影响 10 万求职者、预期转化率提升 5%——带数据）；B 提「暗黑模式」（影响 1000 人、无预期指标——没带数据）——数据先行：A 的数据（10 万用户+5%）和 B 的数据（1000 人+无指标）摆出来——A 先做（数据说话）；B 补齐数据再评（没数据的需求没有发言权）。
例子2：两个需求得分一样（决策升级）。RICE（加权评分）算完：A 需求 80 分、B 需求 80 分（得分一样——规则算不出）——决策升级：记录分歧（A 的价值在用户数、B 的价值在客户口碑）+双方理由，升级给负责人拍板（负责人定了 B——因为 B 关联大客户续约）——评审会产出决策（不拖会）。
例子3：需求池膨胀（小而活+清理）。需求池 150 条（膨胀）——清理：按「小而活」分层（长期池：方向性需求 20-30 条——筛到 25 条；近期池：2-3 个迭代的量 10 条以内——筛到 8 条）；3 个月没评审的 90 条自动清理（过期清理：真重要早排上了）——池子从 150 条变 33 条（评审会从 3 小时变 30 分钟——评审恢复聚焦）。
例子4：紧急插队（机制明确）。迭代（开发周期）中：生产事故（推荐系统挂了——真紧急：可以插——马上修）；客户承诺（答应大客户 6 月交付——可以插）；「老板说要做个 AI 新功能」（口头紧急——走评审：带价值数据过一遍——数据不支持就排到下个迭代（不插队））；插队的记录进池子+月底复盘（这个月插队 3 次（15%）——可接受；复盘：2 次是生产事故（该插）、1 次是「伪紧急」（不该插——下次走评审））。

⑤b 补充板块：需求池的「字段设计」——一条需求记什么
需求池里的每条需求记什么（字段设计）——八个字段：
第一，需求标题（一句话：做什么——「AI 简历优化」）。
第二，提出人+时间（谁提的、什么时候——追源（有问题找提出人））。
第三，价值数据（影响用户数+预期指标——评审用数据（数据先行））。
第四，优先级（RICE（加权评分）得分或手动标——排序用）。
第五，状态（待评审/已通过/开发中/已上线/已关闭——生命周期）。
第六，依赖（依赖谁：算法模型/第三方——排期要等什么）。
第七，评估周期（下次评审时间——3 个月没评=自动清理）。
第八，备注（背景/讨论记录——上下文）。
一句话：需求八字段——标题/提出人/价值数据/优先级/状态/依赖/评估周期/备注——八个字段记全，评审有数据、排期有依据、清理有标准。

⑤c 补充板块：RICE（加权评分）怎么算——四步打分
优先级规则 RICE（加权评分）怎么算（追问细节）：
第一，Reach 触达（影响多少人）：「影响 10 万用户」——打分（10 万=10 分、1 万=5 分——影响面）。
第二，Impact 影响（提升多大）：「转化率提升 5%」——打分（5%=10 分、1%=5 分——提升度）。
第三，Confidence 信心（把握多大）：「有历史数据支撑」——打分（有数据=8 分、靠感觉=3 分——数据支撑度）。
第四，Effort 成本（要多少工作量）：「2 人 1 个月」——打分（1 个月=10 分、3 个月=3 分——成本越低分越高）。
公式：RICE =（触达×影响×信心）÷成本——得分排序（得分高的先做）——规则预先定好（不吵时定尺子，吵起来按尺子量）。
一句话：RICE 四步——触达（影响多少人）×影响（提升多大）×信心（把握多大）÷成本（工作量）——四数乘除得排序分，规则预先定好，吵起来按尺子量。

⑥ 常见误区（3个）
误区1：「需求池管理就是记录+评审+排期（流程）。」错！流程（记录评审排期）只是入门——追问要的是「决策机制」（评审吵起来：数据先行/规则/升级；池子多大：小而活；插队：机制明确——五个机制）——只给流程=一追就露。
误区2：「需求池越全越好（什么都记上）。」错！需求池是「过滤器不是仓库」（有价值的过滤留下——没价值的过滤掉——小而活：长期 20-30+近期 10 条）——什么都记=池子膨胀（评审失焦：200 条过不完）——3 个月没评审自动清理。
误区3：「紧急需求不许插队（规则要铁）。」错！不是「不许插队」是「机制明确」（生产事故/客户承诺可以插——其他走评审；插队的也记录+复盘频率）——一刀切不许插=真急事出事（事故不修=翻车）——机制明确（什么能插、什么走评审），既防乱插也不误真事。

⑦ 第一人称面试回答（3年景观设计→自学转行 AI 产品）
「我 3 年景观设计，被裁后自学转行——需求池的『决策机制』，我做景观设计时就有实践：设计院有个『项目池』（所有待接项目：跟需求池一样）——三个场景我处理过：①评审吵起来（「接市政还是接商业」吵翻天）——数据先行（市政：预算稳但回款慢；商业：回款快但风险高——数据摆出来不吵了）+规则（提前定好：回款周期优先——按规则排）+升级（还吵不出——院长拍板）；②池子多大——小而活：项目池常年 20 个以内（超过就乱：院长看不过来——评审失焦）；3 个月没跟进的项目清掉（过期清理）；③紧急插队——甲方突然要求加急（真急事：可以插——客户承诺）vs「觉得这个项目有前途」（口头紧急：走例会评审）——插队的记录+年底复盘（插队太多=年度计划失真）。转行学 AI 产品后，把『项目池』经验翻译成『需求池』：三个追问（吵/大/插）→五个机制（数据先行/优先级规则/升级拍板/清理机制/插队机制）→收口：给决策机制不是给流程——我做景观设计时管过 3 年的项目池，决策机制是管出来的，不是背出来的。」

⑧ 小结口诀
「三个追问（吵/大/插），五个机制（数据先行/规则/升级/清理/插队机制）；池子小而活（过滤器不是仓库）；插队的是优先级不是流程——给决策机制，不是给流程。」

⑨ 三轮追问（面试官深挖）
追问1：「数据先行，但两个需求数据都很好（都带数据）怎么办？」「数据都好的情况——用『规则』和『战略』：优先级规则（RICE（加权评分）算分：都 80 分——规则算不出）；战略对齐（北极星（核心目标）相关性：A 往北极星走（直接服务核心目标）、B 是边缘优化——A 先做（战略相关性：往北极星走的需求优先）；战略也分不出——升级拍板（记录双方理由，负责人定——决策必须出来）」——数据→规则→战略→升级，四级决策链（一级分不出走下一级）。」
追问2：「3 个月没评审的需求，万一是重要的（只是忘了）怎么办？」「清理不是『删除』是『归档』：3 个月没评审的——先『提醒』（提醒提出人：你的需求 3 个月没评，还做吗——给一次申辩机会）；没回应的——『归档』（移到归档区（不是删除——留档可查）——真重要的会被重新提起（提出人会来找：『我那个需求呢』——重新提起=重新评估）；归档的标准不是『删掉』是『让池子干净』（活跃池子保持小而活——归档区随便放（不影响评审））——清理=归档+可找回，不是丢弃。」
追问3：「插队需求插进来，原计划被挤掉的需求怎么办？」「挤掉的不是『消失』是『重排』：①记录（被挤掉的需求记下状态：排到下个迭代（开发周期）——记录在案不丢）；②通知（通知被挤掉需求的提出人：你的需求被 X 插队，排到下个迭代——透明不暗箱）；③补偿（插队多的迭代，下个迭代补回来：这个迭代插 2 条——下个迭代少排 2 条（插队占的坑要还——节奏不失衡））——插队三件套：记录/通知/补偿——被挤的不丢、不被挤的知情、节奏不崩。」

⑩ 进阶加分点（说出口就加分）
加分点1：把需求池和「数据飞轮」挂钩。「AI 产品的需求池我会挂『数据飞轮』意识：AI 需求的优先级不只看价值，还看『数据贡献』（这个需求能带来什么数据（用户反馈/新样本——数据喂给模型——模型变好——产品变好——飞轮转起来）——两个价值相近的需求，选『能养数据』的那个（飞轮需求优先——AI 产品的需求池多一个维度）」——「数据飞轮」一说出口，你就是懂 AI 产品长期逻辑的人。
加分点2：引入「需求健康度」指标。「我会统计需求池的健康度：活跃率（每周有评审/讨论的需求占比——低于 30%=池子变仓库）、平均滞留时长（需求从进池到排期的平均天数——超 90 天=评估周期太长）、插队率（插队需求占比——超 20%=排期失真）——三个数每月看一次，池子健不健康数据说话」——「需求健康度」是高级词（管理有量化指标）。
加分点3：把「评审会」升级为「决策会」。「我的评审会不叫『需求评审会』，叫『需求决策会』——标准：每场会必须产出『决策』（X 做、Y 不做、Z 升级——三个明确结论）——产出不了决策的会=白开（下次重开）——从名字开始改：评审（评一评——没有决策压力）→决策（必须拍板——有决策压力）——会风一变，效率翻倍」——「评审会改决策会」说明你懂「会的价值=产出决策」（不是走流程）。

⑪ 话术库（直接抄着说）
「需求池管理三个决策机制：吵起来（数据先行+规则+升级）、池子（小而活）、插队（机制明确）。」
「数据先行：每个需求带价值数据（影响用户数/预期指标）——用数据讨论不是用嗓门。」
「需求池是过滤器不是仓库——3 个月没评审的需求自动清理（归档）。」
「插队机制：生产事故/客户承诺可以插——其他紧急走评审；插队的是优先级不是流程。」
「评审会不是争输赢，是产出决策——给决策机制，不是给流程。」

⑫ 小白 Q&A（可能踩的坑）
Q1：RICE（加权评分）听都没听过，怎么学？RICE 就是四个数（触达：影响多少人；影响：提升多大；信心：把握多大；成本：要多少工作量——触达×影响×信心÷成本）——不用背公式，记「影响大×把握大÷成本小=先做」就行（四个数乘除，谁高谁先）——练法：拿你手头 3 件事各打一次分，排个序——练一次就会。
Q2：数据先行，但我是新人没数据怎么办？「没数据」有两种：需求本身没数据（没调研——先补调研再评审：评审时「你的价值数据呢」——补上再来）；有数据但不会找（问数据同事要：影响用户数看后台、预期指标看历史——数据是查出来的不是想出来的）——新人先学会「要数据」（评审前问：这个需求有数据吗），再学会「用数据」。
Q3：3 个月自动清理，会不会得罪提需求的人？清理走「提醒→归档」两步（先提醒：你的需求 3 个月没评——还做吗；没回应再归档——不是突然删）——提需求的人被提醒时反而会想「这需求还重要吗」（他自己也会清理）——归档不是得罪，是「帮大家聚焦」（池子干净了，真重要的才看得见）。

⑬ 没人告诉你的事（面试潜规则）
这道题面试官真正在听的，是「你有没有被需求吵过架」——说「数据先行」（被吵过：用数据止住过嗓门）、「升级拍板」（被卡过：吵不出找过领导）——细节越具体，说明真管过需求池（背书「记录评审排期」=没管过）。另一个潜规则：追问版的答案是「机制」不是「流程」——这是全场最大的分水岭：背流程（谁都会说）的候选人一大半，给机制（数据/规则/升级/清理/插队）的凤毛麟角——你说「五个机制」，面试官就知道你是「管过事的人」。还有一个：用「设计院项目池三年」讲需求池，比背「RICE/小而活」动人十倍——你的真实经历（传统项目池的管理经验迁移）就是最稀缺的素材——面试官会记住「这个转行者管过三年池子」。

⑭ 做一件事（学完就动手）
今天给你手头「想做的事」（学习计划/副业想法/甚至家里的待办都行）建一个「需求池」：①列出来（10 条以内——近期池）；②每条标「价值数据」（影响谁/带来什么）；③按 RICE（加权评分）打分排序（影响大×把握大÷成本小先做）；④定「清理规则」（3 个月没动=归档）；⑤定「插队规则」（什么能插：真急事——什么走评审：想一出是一出）——做完你会发现：你的精力池也「小而活」了（聚焦+过滤——不忙乱）。

⑮ 求职助手联系（面试前必做）
面试前用本卡做 3 件事：①把「三个追问+五个机制」练熟（面试框架：吵（数据/规则/升级）、大（小而活）、插（机制明确））；②准备你的「需求池」案例（设计院项目池三年——真实经历最动人）；③把「给决策机制，不是给流程」练熟（收口金句）。面试被问「需求池追问版」时：先说三个追问（吵/大/插）→再说五个机制（数据先行/规则/升级/清理/插队）→收口（决策机制不是流程）——框架完整+机制齐全+经历真实，面试官立刻记住你。

⑯ 练习（自己测一遍）
1.（机制）评审吵起来的三步机制是？——答案：数据先行（带价值数据）→优先级规则（RICE 评分）→决策升级（负责人拍板）。
2.（池子）需求池「小而活」的具体标准是？——答案：长期池 20-30 条+近期池 10 条以内；3 个月没评审自动清理（归档）。
3.（角色）面试官追问「需求池和传统需求池有什么不同（AI 产品）」，你怎么回答？——参考答案：「AI 需求池多一个维度：数据贡献——AI 需求优先级不只看价值，还看『能不能养数据』（带来用户反馈/新样本——数据喂模型——模型变好——飞轮转起来）——两个价值相近的需求，选能养数据的那个（AI 产品的需求池，数据飞轮是隐藏的优先级规则）。」