Menu
AI产品决策九步闭环总论——覆盖做什么、值不值得、用不用AI、做成什么、用户托付、怎么做、怎么验证、怎么卖、反馈回路
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
AI Native 产品方法论——价值发现循环的实操 Skill。 用户提供已上线或正在验证的 AI 产品，Skill 自动执行价值发现流程： 价值信号识别 → 伪价值排除 → 价值密度评估 → 市场测试设计 → 定价策略联动 → 方向修正建议 → 输出价值发现方案。 基于《AI Native 产品方法论》第22章。
《观照》全书编排器——根据用户输入的问题类型，路由到对应的章节Skill，串联全链路决策修正流程
检查方法使用的前提是否成立——识别情境变化、验证假设前提、重配适用方法
先看机制是否有害，再看结果是否有效——价值/代价/情绪/退出权四重检查
停止错误方向，也是一种推进——归零分析、暂停策略、止损决策
收入从哪里来，产品就会站在哪边——收入来源审视与激励偏差检查
| name | p13e-nine-step-framework |
| description | AI产品决策九步闭环总论——覆盖做什么、值不值得、用不用AI、做成什么、用户托付、怎么做、怎么验证、怎么卖、反馈回路 |
| stage | p13 |
| tags | ["判断力","九步闭环","决策框架","AI产品"] |
| source_book | 判断力与直觉力 |
| source_chapter | 第5章 AI产品决策的九步闭环 |
| version | 1.0.0 |
| 字段 | 说明 |
|---|---|
| product_idea | 产品/功能想法 |
| decision_stage | 当前处于哪个决策阶段（如不清楚则输入"初始"） |
用户愿不愿意把一个功能留在自己的工作里，关键不在于它单次表现有多亮眼，而在于它有没有让后续动作变得更顺。会议纪要写得再好，如果没人接着分配任务、同步负责人、推进下一步，就只是一个漂亮的文本块。真正该判断的不是"这个功能生成了什么"，而是"它有没有改变用户原本完成任务的路径"。如果一个功能只是让某一步看起来更聪明，它可能只是一个增强项；如果它让整条链路更短、更稳、更少摩擦，它才开始拥有工作流价值。
产品流程是你在界面里设计的路径（点击哪里、输入什么、看到什么）。真实工作流是用户在现实工作里为了完成一个任务必须穿过的一整段行为链——跨工具、跨角色、跨时间、跨责任边界。包含等待、确认、沟通、复制、手动补丁、解释、追责和回退，这些东西往往根本不在你的页面里。一个 AI 功能如果只在产品流程里成立，却没有在真实工作流里成立，就会出现：用户在产品里说"好厉害"，回到工作里说"还是先算了"。
(1) 它改的是工作流的哪一段——信息输入/整理/判断/协同/交付/复盘？(2) 它减少了什么成本——时间/认知负担/沟通/切换/出错概率/补偿劳动？(3) 它有没有推动下一步——输出之后谁来接、谁来处理、谁来确认？(4) 它有没有改变用户行为路径——少打开了旧工具？少找了同事帮忙？(5) 拿掉后用户会不会明显难受——从"可选增强"变成"缺了就别扭"？
用户为了把事情真正做成，不得不在系统外额外补上的动作：再发一条确认消息、再去原文核一次出处、再开一个表格手动整理、再找同事口头解释一次、再把 AI 结果改写成组织能接受的话。这些动作看起来小，却常常最接近工作流里的真实代价。很多团队在数据面板上能看见"生成了一份纪要"，却看不见用户后面又手动补了多少步。
判断工作流价值最有效的训练：别急着画产品流程图，先画用户真实工作流。不是"打开页面→上传文件→生成结果→导出"，而是：用户为什么在这个时刻需要做这件事？在用你之前做了哪些准备？通常在哪些工具间切换？谁会看这个结果？结果出来后谁要继续处理？哪一步最容易断？哪一步最容易拖？哪一步今天主要靠用户自己补？
定义：很多团队把注意力放在输出质量上——摘要准不准、文案顺不顺。但用户愿不愿意把一个功能留在自己的工作里，关键不在于它单次表现有多亮眼，而在于它有没有让后续动作变得更顺。如果一个功能只是让某一步看起来更聪明，它可能只是一个增强项；如果它让整条链路更短、更稳、更少摩擦，它才拥有工作流价值。
书稿引用：「用户在真实世界里，不是为了'得到一个输出'而工作。他们是为了完成一串连续动作：理解信息、做决定、和别人对齐、提交结果、推动下一步、承担后果。一个 AI 功能如果只优化了其中一个点，却没有接住后续动作，就很容易停在'演示很好看，实际用不起来'。」（第5章）
应用：评估 AI 功能时，画出用户在使用该功能前后的完整任务链。标出功能优化了哪一段，以及后续动作是否因此变得更顺。如果功能只是让单步更聪明但没有推动下一步，它大概率只是一个增强项而非工作流价值。
定义：判断一个 AI 产品有没有真实工作流价值，从五个问题入手：它改的是工作流的哪一段？它减少了什么成本？它有没有推动下一步？它有没有改变用户行为路径？拿掉它之后，用户会不会明显难受？这五问的核心不是证明"有帮助"，而是判断它是否已进入真实工作。
书稿引用：「工作流价值很少来自'处处都能用一点'，更多来自'在关键一段上显著改变了事情是如何完成的'。所以你一定要逼自己具体：它到底接进了哪一段链路？如果没有它，用户本来怎么完成这一段？有了它之后，这一段具体少了什么动作、多了什么能力、换掉了什么旧方法？」（第5章）
应用：用五问框架逐一评估你的 AI 产品。特别关注第五问——拿掉后用户会不会"明显难受"。如果答案是"不太会"，说明功能还没进入核心工作流。找到那个让用户"拿掉会难受"的关键段落，集中资源做深做透。
定义：产品流程是你在界面里设计的路径，真实工作流是用户在现实工作里必须穿过的一整段行为链——它跨工具、跨角色、跨时间、跨责任边界。很多产品团队最容易犯的错，是把自己在页面里画出的流程，当成了用户真实工作的流程。
书稿引用：「真实工作流则包含等待、确认、沟通、复制、手动补丁、解释、追责和回退，这些东西往往根本不在你的页面里。一个 AI 功能如果只在产品流程里成立，却没有在真实工作流里成立，它就很容易出现一种典型局面：用户在产品里说'好厉害'，回到工作里说'还是先算了'。」（第5章）
应用：从"页面视角"退到"任务视角"。别只看用户在你产品里的那几步，要看他在使用你之前做了什么，用完你之后还要做什么，谁来接这个结果，谁来承担这个结果。工作流价值从来不能只在页面里自证。
把用户的真实工作任务拆成完整链路，标注当前 AI 功能接进了哪一段。如果没有它，用户本来怎么完成这一段？有了它之后，具体少了什么动作、多了什么能力、换掉了什么旧方法？如果连这一点都说不清，你也说不清它到底为什么有价值。
明确说出这个功能压掉了哪一种成本。不是笼统的"更省时间"，而是具体的：少了一次复制粘贴、少了一轮人工解释、少了一次跨工具切换、少了一种经常发生的错误、少了一个让人拖延的动作、少了一次系统外补确认的劳动。越具体越接近真实价值。
检查 AI 输出之后有没有推动下一步。AI 纪要后面能不能变成任务分配、责任认领、待办同步？AI 搜索后面能不能连接原始来源？AI 起草后面能不能进入编辑、审批、发送？如果输出只能停留在"看起来不错"，它就很难进入真实工作流。
观察用户使用这个功能后，真实行为路径有没有变化：少打开了一个旧工具？少找了同事帮忙？少做了重复劳动？开始把某个任务更频繁地完成？如果行为没有变化，功能就算有帮助，也往往只是局部辅助。
做最直接也最残酷的测试：如果拿掉这个功能，用户会不会明显抱怨、效率倒退、流程卡住、开始找替代品？如果用户只是说"有点可惜"，它大概率还没有进入工作流核心。
场景：一款 AI 会议纪要产品。一段录音进去，几分钟后出来结构清楚、重点明确的纪要。用户反馈"总结得挺准""比我自己写快多了"。但使用频率持续下降。
工作流分析：
诊断：产品完成了"生成纪要"，但把"让纪要进入组织动作"的责任继续留给用户。用户不是不喜欢 AI 纪要，只是不愿意为了一个"好看的中间结果"改变工作方式。真正的工作流价值需要接住任务分发、待办流转、责任确认、后续追踪。
场景：评估一个 AI 销售跟进助手是否有工作流价值。
用户真实工作流（不是产品流程图）：
AI 功能定位：如果 AI 能在"会后"段接住"整理→起草→更新→同步"这四步，就真正压缩了工作流。如果只接住"写邮件"，价值就弱很多。关键看它有没有减少"会后那 15 分钟"的补偿劳动。
| 场景 | 补偿劳动 | 工作流断裂点 |
|---|---|---|
| AI 会议纪要 | PM 会后手动复制到飞书、确认负责人、拆待办 | 纪要→任务分配 |
| AI 搜索结果 | 用户自己回到原系统找原文、复制链接、重新核对 | 搜索→引用溯源 |
| AI 起草邮件 | 用户每次都得重写一半、确认上下文、担心语气 | 起草→发送 |
| AI 分析报告 | 用户自己把分析结果翻译成可执行建议 | 分析→决策 |
| AI 分类工单 | 用户手动复核分类结果、修正错误 | 分类→流转 |
挑一个你最近觉得"很好用"的 AI 功能，写下这六个问题：
把这六问写清楚，你会越来越少被单次演示说服，而越来越能看清：一个产品到底有没有真的进入现实工作。
画出用户真实工作流，而非产品流程图：
用户角色: ____
核心任务: ____
=== 会前/准备阶段 ===
1. 用户为什么会触发这个任务？
____
2. 在用你之前，用户做了哪些准备？
____
3. 用户通常在哪些工具间切换？
____
=== 核心执行阶段 ===
4. 用户的核心动作是什么？
____
5. 哪一步最容易断（工作流断裂点）？
____
6. 哪一步最容易拖（用户拖延点）？
____
7. 哪一步一旦做错就出问题（高风险点）？
____
=== 会后/收尾阶段 ===
8. 输出结果后，谁来接？
____
9. 谁来确认、谁来执行下一步？
____
10. 哪一步主要靠用户自己补（补偿劳动）？
____
=== AI 功能定位 ===
AI 功能接进了哪一段？____
它具体减少了什么动作？____
它有没有推动下一步？[ ] 是 [ ] 否
拿掉后用户会怎样？____
补偿劳动是工作流断裂的最直接信号。识别补偿劳动的关键不是问用户"你觉得怎么样"，而是观察用户在系统外多做了什么。
| 模式 | 典型表现 | 工作流断裂点 |
|---|---|---|
| 搬运 | 把 AI 结果复制到另一个工具 | 输出→下游系统 |
| 翻译 | 把 AI 输出改写成组织能接受的语言 | AI 格式→组织格式 |
| 确认 | 发消息找人确认 AI 推断是否正确 | AI 判断→人工确认 |
| 补充 | 手动补充 AI 没有覆盖的信息 | AI 产出→完整信息 |
| 校验 | 去原始来源核对 AI 引用是否准确 | AI 引用→原始出处 |
| 整理 | 把 AI 零散输出整理成结构化格式 | AI 输出→可用格式 |
| 分发 | 手动把结果发给相关人员 | AI 产出→团队同步 |
| 追踪 | 手动设置提醒和后续跟进 | AI 产出→后续执行 |
判断工作流价值是否真正成立，需要观察行为迁移指标。
如果使用了两周后行为没有变化，检查：
| 可能原因 | 诊断方法 | 破解 |
|---|---|---|
| 价值不够强 | 做"拿掉测试" | 深化价值 |
| 位置不对 | 观察用户在哪里卡住 | 调整入口 |
| 用户不知道有这个功能 | 看功能发现率 | 场景化引导 |
| 使用门槛太高 | 看功能使用率 | 降低门槛 |
| 用户习惯没变 | 观察旧习惯是否还在 | 渐进式迁移 |
| 维度 | 功能价值 | 工作流价值 |
|---|---|---|
| 用户感知 | "这个功能挺厉害" | "少了它我就不顺" |
| 使用频率 | 偶尔尝试 | 日常使用 |
| 拿掉后反应 | "有点可惜" | "明显难受" |
| 行为变化 | 无 | 少了切换/补劳动 |
| 价值来源 | 单次输出质量 | 整条链路效率 |
| 商业化基础 | 新鲜感 | 持续依赖 |
| 典型信号 | "挺厉害" | "缺了就别扭" |
当产品停留在功能价值阶段，如何向工作流价值进化：
当前：AI 生成纪要 → 用户手动分发 进化：AI 生成纪要 → 自动提取待办 → 自动分配负责人 → 自动同步
当前：AI 起草邮件 → 用户重写一半 进化：AI 起草邮件 → 提供修改建议 → 用户微调 → 直接发送
当前：用户在 A 工具完成 → 复制到 B 工具处理 进化：AI 在 A 工具完成 → 直接在 A 内处理 → 结果自动同步到 B
当前：需要手动触发 → 需要配置参数 → 需要等待结果 进化：自动检测场景 → 自动配置 → 即时结果
以"AI 会议纪要"为例，量化补偿劳动：
AI 产出：一份结构化纪要（生成耗时 2 分钟）
用户后续补偿劳动：
1. 复制纪要到飞书文档（1 分钟）
2. 确认每个待办的负责人（5 分钟）
3. @ 缺席的人并同步关键结论（3 分钟）
4. 把待办拆进 Jira/项目管理工具（5 分钟）
5. 设定跟进提醒（2 分钟）
6. 在下次会议前手动检查执行情况（3 分钟）
补偿劳动总计：19 分钟
AI 节省的时间：手写纪要约 15 分钟
净效果：用户反而多花了 4 分钟
结论：AI 只完成了"记录"这一段，没有接住"让纪要进入组织动作"。