Menu
九步后段——怎么验证、怎么进入市场、反馈回路的决策框架
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
AI Native 产品方法论——价值发现循环的实操 Skill。 用户提供已上线或正在验证的 AI 产品，Skill 自动执行价值发现流程： 价值信号识别 → 伪价值排除 → 价值密度评估 → 市场测试设计 → 定价策略联动 → 方向修正建议 → 输出价值发现方案。 基于《AI Native 产品方法论》第22章。
《观照》全书编排器——根据用户输入的问题类型，路由到对应的章节Skill，串联全链路决策修正流程
检查方法使用的前提是否成立——识别情境变化、验证假设前提、重配适用方法
先看机制是否有害，再看结果是否有效——价值/代价/情绪/退出权四重检查
停止错误方向，也是一种推进——归零分析、暂停策略、止损决策
收入从哪里来，产品就会站在哪边——收入来源审视与激励偏差检查
| name | p13h-validation-market |
| description | 九步后段——怎么验证、怎么进入市场、反馈回路的决策框架 |
| stage | p13 |
| tags | ["判断力","九步闭环","后段判断"] |
| source_book | 判断力与直觉力 |
| source_chapter | 第8章 后段判断（验证/市场/反馈） |
| version | 1.0.0 |
| 字段 | 说明 |
|---|---|
| prototype_or_product | 原型或产品 |
| target_market | 目标市场描述 |
| success_criteria | 成功标准 |
试用意愿成本很低——用户只需要付出几分钟注意力就能体验一次新鲜感。托付意愿完全不同——一旦托付开始发生，用户必须接受"这一步以后不再完全由我亲自完成"。这意味着：一旦做错后果会回来找我、一旦流程变化我得重新适应、一旦别人质疑我得解释为什么相信它。真正的采用不是从"愿不愿意点开"开始，而是从"愿不愿意交出一部分判断或劳动"开始。
(1) 错误后果有多重——错了只是多改两句文案，还是影响客户关系/业务决策/财务结果？错误后果越重，托付门槛越高。(2) 用户有控制权吗——AI 只是先给建议还是直接执行？关键时刻能不能把手伸回来？(3) 用户要不要理解过程——如果用户要拿结果去说服别人、承担责任，就不只想要结论还要知道依据。(4) 用户原来有没有成熟做法——成熟旧路径本身就是托付门槛。(5) 用户愿意交的是哪一步——绝大多数任务不是"全交"或"全不交"，而是分段交。
先看看→先给建议→帮我起草→你先做我来批→低风险你自动做→高风险你停下来等我。很多 AI 产品迟迟进不了深水区，不是因为用户永远不会托付，而是因为团队总想一步到位。今天真正要找的不是"用户全不全交"，而是"用户现在最愿意先交出哪一段"。
用户愿意让 AI 帮自己起草，不代表愿意让 AI 直接发送。愿意让 AI 提醒，不代表愿意让 AI 拍板。愿意让 AI 解释数据，不代表愿意让 AI 决定预算。如果把这个任务粗暴理解成"用户愿不愿意让 AI 做"，就会错过真正的采用机会——用户也许不愿意全交，但非常愿意把某一段交出来。
更有效的问法：他愿不愿意少写第一稿？少做一次核对？少切一次工具？少承担一段低价值重复劳动？把低风险那一段先交出去？用户不是天然抗拒 AI，而是在判断"哪一段我今天最愿意先放手"。
"试用意愿成本很低——用户只需要付出几分钟注意力就能体验一次新鲜感。托付意愿完全不同——一旦托付开始发生，用户必须接受'这一步以后不再完全由我亲自完成'。" ——书稿第8章
试用只需要付出几分钟注意力，不需要改变原有流程，不需要承担额外后果。托付则意味着：一旦做错后果会回来找我、一旦流程变化我得重新适应、一旦别人质疑我得解释为什么相信它。真正的采用不是从"愿不愿意点开"开始，而是从"愿不愿意交出一部分判断或劳动"开始。应用：不要被试用数据迷惑。观察用户是否开始减少某个旧习惯、是否开始在低风险段依赖系统、是否开始主动把更多步骤交出来。如果嘴上说不错但行为没变，说明托付还没有真正开始。
"用户愿意让AI帮自己起草，不代表愿意让AI直接发送。愿意让AI提醒，不代表愿意让AI拍板。" ——书稿第8章
如果把任务粗暴理解成"用户愿不愿意让AI做"，就会错过真正的采用机会。用户也许不愿意全交，但非常愿意把某一段交出来。写错了可以改，发错了会影响客户关系——这两种后果完全不同，决定了完全不同的托付边界。应用：把目标任务拆成连续步骤，标注每一步的错误后果等级、用户控制需求、是否需要解释过程。找到用户最愿意先交出的那一段（通常是低风险+重复性高+错误可快速纠正的步骤），作为托付入口。
"先看看→先给建议→帮我起草→你先做我来批→低风险你自动做→高风险你停下来等我。很多AI产品迟迟进不了深水区，不是因为用户永远不会托付，而是因为团队总想一步到位。" ——书稿第8章
托付从来不是一次发生的，而是逐步建立的。如果上来就要求全量托付，用户往往用最保守的方式回应你。如果把梯度设计对了，用户会自然越交越多。每一步都需要明确的升级条件和回退机制。应用：设计从托付入口到更深度托付的路径。先让用户在低风险段交出任务，建立信任后逐步扩展。不要上来就推全自动化——路径设计要包含每一步的升级条件、回退机制、异常处理。
把目标任务拆成连续步骤，标注每一步的：错误后果等级（低/中/高）、用户控制需求（强/中/弱）、是否需要解释过程。不要把任务当成一个整体来判断"交不交"。
在任务链上找到用户最可能愿意先交出的那一段。通常是：低风险+重复性高+用户已有补偿行为+错误可快速纠正的步骤。把这一段作为托付入口。
为托付入口设计控制权结构：用户能不能修改？能不能撤销？能不能跳回人工？高风险动作有没有确认点？系统做错后用户能不能低成本收场？
设计从托付入口到更深度托付的路径。先让用户在低风险段交出任务，建立信任后逐步扩展。不要上来就推全自动化。路径设计要包含：每一步的升级条件、回退机制、异常处理。
监测托付是否真的在发生：用户是否开始减少某个旧习惯？是否开始在低风险段依赖系统？是否开始主动把更多步骤交出来？如果用户嘴上说不错但行为没变，说明托付还没有真正开始。
场景：AI 销售跟进助手，可根据会议内容自动生成后续邮件、跟进行动和风险提示。第一次演示时销售觉得很惊艳。
托付五问诊断：
产品设计建议：把重点放在"起草到发送之间"的协作更顺——风险标注、口气校正、客户历史引用、审批链连接。而不是一开始就推全自动发送。
场景：设计一个 AI 工单处理系统的托付梯度。
| 阶段 | 托付程度 | 用户行为 | 系统行为 | 升级条件 |
|---|---|---|---|---|
| 看看 | 0% | 用户自己处理 | 不参与 | — |
| 先建议 | 20% | 用户自己处理 | 给出建议和参考 | 用户采纳率>70% |
| 帮我起草 | 40% | 用户审核修改 | 生成草稿 | 用户修改率<30% |
| 你先做我来批 | 60% | 用户批阅确认 | 自动处理低风险工单 | 确认通过率>90% |
| 低风险你自动做 | 80% | 用户只看异常 | 低风险自动处理 | 异常率<5% |
| 高风险你停下来等我 | 90% | 用户只处理高风险 | 高风险暂停等待 | — |
设计原则：每一级都需要明确的升级条件和回退机制。用户不是一次性交出全部判断，而是不断往前挪一点点。
场景：为一个 AI 会议纪要产品设计验证方案，判断它到底是 demo 成立还是真成立。
demo 成立的信号（不可靠）：
真成立的信号（可靠）：
验证方案设计：
| 验证维度 | 具体指标 | 采集方式 | 判断标准 |
|---|---|---|---|
| 回访行为 | 第 7 日回访率 | 产品埋点 | > 30% |
| 任务嵌入 | 纪要后续动作触发率 | 行为日志 | > 50% |
| 时间节省 | 用户自评节省时间 | 问卷 | > 30 分钟/周 |
| 替代行为 | 用户手动整理频率下降 | 行为对比 | 下降 > 50% |
| 推荐行为 | NPS / 自然推荐 | 回访访谈 | NPS > 30 |
场景：AI 客户分析工具准备进入市场，需要判断先卖给谁。
用户分层分析：
| 用户层 | 特征 | 托付意愿 | 付费意愿 | 建议 |
|---|---|---|---|---|
| 创新型个人 | 什么新工具都试 | 高试用意愿 | 低付费 | 不适合首批 |
| 痛点型小团队 | 当前方法有明显痛点 | 中等 | 中等 | 适合首批 |
| 流程型中团队 | 有固定流程想优化 | 低（怕打破） | 高 | 适合第二批 |
| 保守型大企业 | 合规要求高 | 很低 | 很高 | 不适合早期 |
建议：先找"痛点型小团队"作为种子用户。他们有真实痛点（所以有采用动力），团队小（决策链短），反馈快（迭代效率高）。同时他们也会成为案例素材，吸引"流程型中团队"。
| 反馈类型 | 采集方式 | 频率 | 负责人 |
|---|---|---|---|
| 行为数据 | 产品埋点 | 实时 | 产品 |
| 定性反馈 | 用户访谈 | 每两周 | PM |
| 客诉分析 | 客服工单 | 每周 | 运营 |
| 竞品动态 | 行业跟踪 | 每月 | 战略 |
| 反馈类别 | 典型信号 | 对应调什么 |
|---|---|---|
| 模型问题 | 生成质量下降/不一致 | 模型/prompt/数据 |
| 交互问题 | 用户不知道下一步 | 交互设计/onboarding |
| 工作流问题 | 用户绕过你 | 工作流接入/集成 |
| 定位问题 | 用户期望不对 | 市场教育/价值主张 |
| 商业化问题 | 付费意愿弱 | 定价/packaging |
| 节奏问题 | 用户觉得太激进/太保守 | 托付梯度/自动化程度 |
每个反馈循环结束时，必须产出：(1) 问题归类（模型/交互/工作流/定位/商业化/节奏）；(2) 优先级排序（影响面 × 严重度）；(3) 下一步动作（谁、做什么、什么时候完成）。
症状：首次使用率高，回访率低。 诊断：新鲜感驱动，没有找到持续使用理由。 对策：停止新增功能，集中精力找到"第二次回来的理由"。
症状：用户愿意用 AI 处理低风险任务，但关键任务不用。 诊断：托付梯度设计缺失，没有建立从低风险到高风险的信任通道。 对策：设计明确的升级条件和回退机制。
症状：个别员工在用，团队没有形成集体采用。 诊断：产品没有解决组织层面的信任问题（责任归属、合规审查）。 对策：增加管理视角功能（审计日志、权限控制、责任边界）。
症状：用户访谈说"挺好的"，但行为上一直绕过。 诊断：托付结构没有成立，用户在防御。 对策：不要问"好不好用"，要问"哪一步你不敢交"。
症状：团队在用，但不愿意正式采购或续费。 诊断：价值没有从"可用"升级到"不可或缺"。 对策：做拿掉测试，找到产品真正进入资源分配逻辑的条件。
| # | 检查项 | 状态 | 说明 |
|---|---|---|---|
| 1 | 种子用户画像已确定 | ⬜ | 痛点明确、决策链短、反馈快 |
| 2 | 托付入口已定位 | ⬜ | 用户最愿意先交出的那一步 |
| 3 | 定价策略已设计 | ⬜ | 匹配产品成熟度和用户付费意愿 |
| 4 | 验证指标已定义 | ⬜ | 区分 demo 成立和真成立 |
| 5 | 反馈回路已建立 | ⬜ | 采集、分类、行动闭环 |
| 6 | 销售/营销材料已准备 | ⬜ | 能讲清价值和边界 |
| 7 | 异常处理机制已设计 | ⬜ | 出问题时的回退方案 |
使用说明：以上 7 项全部确认后，才适合正式进入市场。缺少任何一项，都可能在早期产生不可逆的负面口碑。
| 问题 | 回答选项 | 诊断 |
|---|---|---|
| 你试用过几次？ | 1 次 / 2-3 次 / 4+ 次 | 试用深度 |
| 试用后有没有改变原来的做法？ | 完全没 / 部分 / 完全 | 行为改变程度 |
| 你愿意把它推荐给同事吗？ | 不会 / 会提但不力推 / 会力推 | 真实认可度 |
| 你愿意为它付费吗？ | 不愿意 / 看价格 / 愿意 | 价值感知 |
| 如果它明天消失了你会？ | 无所谓 / 有点可惜 / 明显不便 | 依赖程度 |
| 任务步骤 | 你愿意 AI 帮你做吗 | 不愿意的原因 |
|---|---|---|
| 信息收集 | 是/否 | |
| 初步整理 | 是/否 | |
| 起草初稿 | 是/否 | |
| 修改润色 | 是/否 | |
| 内部审核 | 是/否 | |
| 对外发送 | 是/否 | |
| 最终承诺 | 是/否 |
使用说明：通过问卷找到"是"和"否"的分界线，这就是当前的托付入口。
| 阶段 | 目标 | 核心动作 | 成功标准 | 时间窗口 |
|---|---|---|---|---|
| 种子期 | 找到托付入口 | 只在低风险段提供服务 | 用户在低风险段形成习惯 | 2-4 周 |
| 扩展期 | 建立信任梯度 | 逐步开放更多步骤 | 用户开始在中风险段使用 | 4-8 周 |
| 成熟期 | 实现深度托付 | 高风险段有确认机制 | 用户在大部分步骤依赖系统 | 8-16 周 |
| 阶段 | 行为指标 | 满意度指标 | 效率指标 |
|---|---|---|---|
| 种子期 | 日活跃率 > 40% | NPS > 20 | 节省时间 > 10% |
| 扩展期 | 多步骤使用率 > 30% | NPS > 30 | 节省时间 > 25% |
| 成熟期 | 全流程使用率 > 50% | NPS > 40 | 节省时间 > 40% |
| 模式 | 适用条件 | 优势 | 风险 |
|---|---|---|---|
| 免费增值 | 需要快速获客 | 低门槛 | 付费转化难 |
| 按量计费 | 使用频率差异大 | 公平 | 收入不稳定 |
| 订阅制 | 使用频率稳定 | 可预测收入 | 获客门槛高 |
| 按效果付费 | 价值可量化 | 强价值主张 | 效果难归因 |
| 企业定制 | 大客户需求 | 高客单价 | 销售周期长 |
| # | 检查项 | 状态 | 说明 |
|---|---|---|---|
| 1 | 目标用户付费能力已评估 | ⬜ | 个人/团队/企业 |
| 2 | 竞品定价已调研 | ⬜ | 市场基准 |
| 3 | 价值量化已完成 | ⬜ | 节省多少时间/成本 |
| 4 | 付费意愿已验证 | ⬜ | 不是"愿意试"而是"愿意付" |
| 5 | 定价与产品成熟度匹配 | ⬜ | 不要过早收高价 |
| 层级 | 指标类型 | 具体指标 | 说明 |
|---|---|---|---|
| 表层 | 使用指标 | DAU/MAU、使用频次 | 看起来有人用 |
| 中层 | 行为指标 | 任务完成率、步骤采纳率 | 真的在用 |
| 深层 | 价值指标 | 时间节省、错误减少、收入增加 | 产生价值 |
| 底层 | 依赖指标 | 拿掉测试、付费续费率 | 离不开 |
诊断方法：从表层往下看。如果表层指标好但深层指标差，说明产品"看起来有人用但没产生真实价值"。如果底层指标好但表层指标差，说明产品"价值真实但获客有问题"。
| 环节 | 内容 | 时间 | 产出 |
|---|---|---|---|
| 数据回顾 | 上周关键指标变化 | 5 分钟 | 趋势判断 |
| 反馈分类 | 新收到的反馈归类 | 10 分钟 | 问题清单 |
| 优先级排序 | 按影响面×严重度排序 | 5 分钟 | Top 3 问题 |
| 行动分配 | 谁做什么、什么时候完成 | 5 分钟 | 任务列表 |
| 上周行动回顾 | 上周任务完成情况 | 5 分钟 | 闭环确认 |
