Menu
直觉进化——持续训练判断力、建立标准提升机制
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 | p13k-intuition-evolution |
| description | 直觉进化——持续训练判断力、建立标准提升机制 |
| stage | p13 |
| tags | ["判断力","直觉进化","标准提升","持续修炼"] |
| source_book | 判断力与直觉力 |
| source_chapter | 第12章 直觉的边界与进化 |
| version | 1.0.0 |
| 字段 | 说明 |
|---|---|
| judgment_history | 历史判断记录 |
| learning_feedback | 反馈与学习素材 |
| current_standards | 当前判断标准 |
用户愿意托付通常不是因为他忽然变得胆大了，而是因为产品让他觉得：我知道它在做什么、我知道我能管住它、我知道我可以核一下、我知道出错时退得回来、我知道最后谁承担结果。这五种感觉一旦成立，托付就开始发生。少了其中一项，用户就会进入防御姿态。
(1) 它可理解吗——用户至少要知道系统在替他做什么、依据什么做、做到什么程度会停。(2) 它可控制吗——托付不是把控制权全部让出去，而是重新分配。用户能调、能改、能停、能拒绝、能设边界。(3) 它可校验吗——让用户能迅速判断结果靠不靠谱：来源引用、不确定项标记、关键推理依据。(4) 它可回退吗——结果可以撤回、流程可以切回人工、错误不会直接扩散。(5) 它可承担吗——责任边界清楚：哪些是建议、哪些自动做、哪些必须人工确认、哪些异常升级。
信任缺失在产品里经常不是以强烈投诉出现的。更常见的情况是：用户嘴上说还不错，行为上却一直绕过你。他会让 AI 先起草但不会让 AI 直接发送；会看 AI 总结但不会拿它做会议结论；会在产品里点"自动处理"却私下再留一套人工台账。这类静默绕过比抱怨更值得警惕——它说明产品表层功能可能成立了，但托付结构并没有成立。
很多团队一谈智能体就天然想做全自动闭环。但真实世界里的托付更像一段梯度：先看→先建议→帮我起草→你先做我来批→低风险你自动做→高风险你停下来等我。如果把梯度设计对了，用户会自然越交越多。如果上来就要求全量托付，用户往往用最保守的方式回应你。
很多人以为强智能体的标志是尽可能少停、尽可能全做。其实不是。真正让用户放心的系统往往在该停的地方停得很对：信息不足时停、风险升高时停、责任跨边界时停、用户偏好不明确时停、低把握度但高后果的位置停。知道在哪里停，说明系统对自己的边界有判断，也说明产品对人的角色还有尊重。
"用户嘴上说还不错，行为上却一直绕过他。他会让AI先起草但不会让AI直接发送；会看AI总结但不会拿它做会议结论。这类静默绕过比抱怨更值得警惕——它说明产品表层功能可能成立了，但托付结构并没有成立。" ——书稿第11章
信任缺失在产品里经常不是以强烈投诉出现的。用户不是不用，而是用了但不信任结果——搜索后手动核验、AI起草后自己重写、点了"自动处理"却私下留一套人工台账。这种行为说明：功能层面"能用"，但托付层面"没成立"。应用：设计3个可以观察的用户行为指标来检测静默绕过——搜索后手动核验率、结果直接采纳率、AI功能使用后的手动修正率。如果这些指标不健康，问题不在功能本身，而在托付结构。
"真正让用户放心的系统往往在该停的地方停得很对：信息不足时停、风险升高时停、责任跨边界时停、用户偏好不明确时停、低把握度但高后果的位置停。" ——书稿第11章
很多人以为强智能体的标志是尽可能少停、尽可能全做。其实不是。知道在哪里停，说明系统对自己的边界有判断，也说明产品对人的角色还有尊重。停得太多→用户觉得"还不如自己做"；停得太少→用户觉得"我管不住它"。正确的停点是：信息不足、风险升高、责任跨边界、低把握度。应用：为每个AI功能设计智能停点——信息不足时请求补充、风险升高时等人工确认、责任跨边界时明确归属、低把握度时标注不确定。高质量的智能体不只是更会做事，更是更知道该在哪里停。
"很多信任问题，并不是成功路径做差了，而是失败路径根本没设计。用户之所以绕过你，经常不是因为他已经看见错误，而是因为他提前闻到了'出事时没法收场'的味道。" ——书稿第11章
每设计一个AI功能，不仅要写成功路径（用户点击→系统生成→用户确认→完成），还必须补全失败路径：信息不完整怎么办？来源冲突怎么办？用户不同意怎么办？系统低把握怎么办？执行后后果变严重怎么办？缺少失败路径=产品在成功时很好用，出问题时用户无法收场。应用：每设计一个AI功能，强制补全6条失败路径。如果失败路径没有被设计，不要上线——因为用户之所以不托付，往往不是因为已经看见错误，而是因为提前感知到"出事时没法收场"。
对产品逐问评估：(1) 用户知不知道系统在做什么？依据是什么？(2) 用户能不能调、改、停、拒绝、设边界？(3) 用户能不能低成本验证结果？(4) 出了问题能不能撤回/切回人工？(5) 责任边界清不清楚——建议/自动/人工确认/异常升级各在哪？找到最弱的一层。
观察用户是否有静默绕过行为：嘴上说不错但私下留人工台账？让 AI 起草但自己手动发送？看了 AI 总结但自己重新整理？这些行为说明托付结构没有成立，需要进一步诊断卡在哪一层。
每设计一个 AI 功能，强迫自己补一版失败路径。不要只写"用户点击→系统生成→用户确认→任务完成"，还要写：信息不完整怎么办？来源冲突怎么办？用户不同意怎么办？系统低把握怎么办？执行后后果变严重怎么办？很多信任问题不是成功路径做差了，而是失败路径根本没设计。
设计从低风险到高风险的托付梯度。每级都需要：明确的升级条件、清晰的回退机制、异常处理路径。不要一步到位推全自动化，让用户在每一步都有安全感。
在产品中设计智能"停"点：信息不足时停下来请求补充、风险升高时停下来等人工确认、责任跨边界时停下来明确归属、低把握度时停下来标注不确定。好的停点设计不是能力弱的表现，而是对用户角色的尊重。
场景：两个 AI 客服回复助手服务同一类售后场景（物流延迟、退款、赔付、保修例外）。
产品 A（缺乏可托付感）：客户提问后 AI 直接生成完整回复，默认一键发送。不展示依据，不提示哪些来自知识库/哪些只是推断。客服想改只能整体重写。资料不全时仍给出很确定口吻，赔付/保修例外问题不主动停下来。
产品 B（设计了可托付感）：先给建议回复，附来源条目，标出高风险表述。赔付/承诺/政策例外问题自动停在"建议草稿"状态，提示人工确认。客服可局部改写、整段重生、一键切回人工。责任更重的对话直接把建议降级成参考。
五问对比：
| 维度 | 产品 A | 产品 B |
|---|---|---|
| 可理解 | ❌ 不展示依据 | ✅ 来源标注 |
| 可控制 | ❌ 只能整体重写 | ✅ 局部改写/重生/切人工 |
| 可校验 | ❌ 无法验证 | ✅ 来源对照 |
| 可回退 | ⚠️ 困难 | ✅ 一键切回人工 |
| 可承担 | ❌ 责任模糊 | ✅ 赔付/例外自动停等确认 |
结论：产品 A 更像在逼用户赌一次。产品 B 虽然没那么激进，却更容易进入真实工作——它把托付所需的结构条件补齐了。
场景：设计一个 AI 文档审批助手的停点规则。
| 停点类型 | 触发条件 | 系统行为 | 用户操作 |
|---|---|---|---|
| 信息不足 | 关键字段缺失或矛盾 | 暂停执行，高亮缺失项 | 补充信息后继续 |
| 风险升高 | 涉及金额>阈值或合规敏感 | 降级为"建议模式" | 人工审核确认 |
| 责任跨边界 | 涉及外部承诺或法律条款 | 停在草稿状态 | 必须人工确认 |
| 低把握度 | 模型置信度<阈值 | 标注不确定，给出多个选项 | 用户选择或修改 |
| 用户偏好不明 | 多个合理方向 | 列出选项和各自利弊 | 用户决策 |
设计原则：停下来不代表能力弱。知道在哪里停，说明系统对自己的边界有判断，也说明产品对人的角色还有尊重。高质量的智能体不只是更会做事，更是更知道该在哪里停。
场景：用五问框架评估一个 AI 采购审批助手的可托付感。
逐问评估：
| 问题 | 评估结果 | 得分 | 改进方向 |
|---|---|---|---|
| 可理解？ | 展示了审批依据，但不展示哪些规则触发了建议 | 6/10 | 增加规则触发链路展示 |
| 可控制？ | 可以修改金额，但不能修改审批规则 | 5/10 | 增加规则自定义入口 |
| 可校验？ | 有审批依据，但来源不可点击 | 4/10 | 来源可追溯、可对照 |
| 可回退？ | 审批通过后不可撤销 | 3/10 | 增加撤销窗口期 |
| 可承担？ | 责任边界模糊——"系统建议通过" | 4/10 | 明确哪些是建议/哪些自动做 |
总分：22/50，最弱层是"可回退"和"可承担"。
改进优先级：
场景：检测一个企业 AI 知识库助手是否存在静默绕过行为。
观察数据：
| 行为 | 数据 | 诊断 |
|---|---|---|
| AI 搜索使用率 | 60% | 表面不错 |
| 搜索后直接采纳结果的比例 | 15% | 极低——用户在大量二次核验 |
| 用户搜索后去旧知识库查证的比例 | 45% | 静默绕过严重 |
| 会议中引用 AI 结果的比例 | 8% | 信任度极低 |
| 向同事推荐 AI 搜索的比例 | 22% | 推荐意愿弱 |
诊断结论：
| # | 评估项 | 状态 | 当前得分 | 目标得分 |
|---|---|---|---|---|
| 1 | 用户知道系统在做什么 | ⬜ | /10 | 8+ |
| 2 | 用户知道结果依据什么 | ⬜ | /10 | 7+ |
| 3 | 用户能修改/重做/缩小范围 | ⬜ | /10 | 7+ |
| 4 | 用户能暂停/停止 | ⬜ | /10 | 8+ |
| 5 | 用户能低成本验证结果 | ⬜ | /10 | 7+ |
| 6 | 结果可撤回/流程可回退 | ⬜ | /10 | 7+ |
| 7 | 高风险动作有确认点 | ⬜ | /10 | 8+ |
| 8 | 责任边界清晰 | ⬜ | /10 | 8+ |
| 9 | 异常有升级路径 | ⬜ | /10 | 7+ |
| 10 | 失败路径已设计 | ⬜ | /10 | 7+ |
总分：/100，目标 70+。低于 50 说明可托付感严重不足，需要优先补齐。
用户输入 → 系统生成 → 用户确认 → 任务完成
| 异常场景 | 系统行为 | 用户操作 | 后果控制 |
|---|---|---|---|
| 输入信息不完整 | 暂停，提示缺失项 | 补充信息 | 不执行不完整任务 |
| 来源数据冲突 | 标注冲突，列出两边 | 用户判断 | 不硬给结论 |
| 用户不同意结果 | 允许修改/重新生成 | 用户编辑 | 不强制采纳 |
| 系统低把握 | 标注不确定，给选项 | 用户选择 | 不假装确定 |
| 执行后后果变严重 | 告警 + 暂停 + 回退入口 | 用户干预 | 后果不扩散 |
| 外部依赖失败 | 暂停，提示外部原因 | 用户决定 | 不盲目重试 |
使用说明：每设计一个 AI 功能，必须同时设计以上 6 条失败路径。缺少失败路径 = 产品在成功时很好用，出问题时用户无法收场。
产品文档里写满了"用户点击→系统处理→任务完成"，但没有任何关于"如果系统做错了怎么办"的设计。用户遇到问题时只能自己摸索。
虽然设计了"撤销"功能，但撤销后需要重新输入大量信息。用户宁可手动修正也不愿撤销重来。回退应该是低成本的——一键回到上一步，不需要重新配置。
在低风险步骤设置了确认点（用户觉得烦），在高风险步骤没有确认点（用户觉得怕）。确认点应该出现在后果变重的位置，而不是每个步骤都有。
停得太多 → 用户觉得"还不如自己做"，系统变成一个不断需要审批的助手。停得太少 → 用户觉得"我管不住它"，系统变成一个不受控的自动执行器。正确的停点是：信息不足、风险升高、责任跨边界、低把握度。
为了展示透明度，把所有推理过程、数据来源、模型权重都展示出来。用户看到一堆信息反而更不知道该看什么。可理解不等于信息量大——关键是有层次地展示：先结论、再依据、再不确定项、再详情。
选一个你正在做的 AI 功能，写下成功路径后，补全以下 6 条失败路径：
对同一个产品分别用五个问题打分（每问 1-10），画出雷达图。最弱的一层就是改进优先级最高的。
设计 3 个可以观察的用户行为指标，判断用户是否在静默绕过你的 AI 功能。例如：
核心训练：可托付感不是用户调研问卷里的"信任度评分"，而是行为数据里的"用户是否真的在用你处理的结果"。
阶段 0：不了解
→ 用户不知道你的存在
阶段 1：好奇试用
→ 用户试了一下，觉得"挺厉害"
阶段 2：谨慎使用
→ 用户在低风险场景使用，每次都检查
阶段 3：习惯使用
→ 用户形成固定使用习惯，只在关键步骤检查
阶段 4：放心托付
→ 用户在大部分场景放心使用，只在高风险步骤确认
阶段 5：深度依赖
→ 用户把系统当成默认工具，拿掉会觉得明显不便
| 跃迁 | 需要满足的条件 | 典型时间 |
|---|---|---|
| 0→1 | 有明确的价值主张和试用入口 | 1-2 周 |
| 1→2 | 首次体验有价值，有低风险入口 | 1 周 |
| 2→3 | 低风险段稳定可靠，有回访理由 | 2-4 周 |
| 3→4 | 可预期性建立，校验成本低 | 4-8 周 |
| 4→5 | 组织采用，工作流嵌入 | 8-16 周 |
使用说明：判断你的产品当前在哪个阶段，找到跃迁需要的条件，集中精力满足它。
在不确定的场景，停下来等人工确认，比冒险自动执行更好。用户宁可多等一秒，也不愿事后花一小时收场。
用户应该始终保持主导感。系统是工具，不是决策者。即使系统在自动执行，用户也应该觉得自己在"使用一个工具"，而不是"被一个系统接管"。
不要隐藏不确定性，而要把不确定变成用户可以判断的信息。"我不确定"比"我猜一个答案"更有价值。
如果用户想撤回，成本必须低于继续用下去的成本。否则用户会"将错就错"，这比不用更危险。
不要在营销材料里写"值得信赖"。信任是用户在一次次使用中逐渐建立的——每次使用结果可靠、每次出错能收场、每次不确定会标注，信任自然累积。
| 症状 | 最可能缺的层 | 快速验证方法 | 改进方向 |
|---|---|---|---|
| 用户试了就走 | 可理解 | 用户能说出系统做了什么吗 | 增加动作说明和范围边界 |
| 用户反复检查 | 可校验 | 校验成本是否低于原始劳动 | 增加来源标注和不确定标记 |
| 用户私下留台账 | 可控制 | 用户能否随时暂停/修改 | 增加控制权和回退机制 |
| 用户不推荐团队 | 可承担 | 责任边界是否清晰 | 增加角色权限和审批链 |
| 用户只用低风险 | 可回退 | 出错后能否低成本收场 | 增加撤销和回退机制 |
使用说明：观察最突出的"症状"，找到最缺的层，集中改进。不要试图一次补齐所有层——先解决最痛的那个。