Menu
直觉进化——持续训练判断力、建立标准提升机制
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
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 周 |
使用说明：判断你的产品当前在哪个阶段，找到跃迁需要的条件，集中精力满足它。
在不确定的场景，停下来等人工确认，比冒险自动执行更好。用户宁可多等一秒，也不愿事后花一小时收场。
用户应该始终保持主导感。系统是工具，不是决策者。即使系统在自动执行，用户也应该觉得自己在"使用一个工具"，而不是"被一个系统接管"。
不要隐藏不确定性，而要把不确定变成用户可以判断的信息。"我不确定"比"我猜一个答案"更有价值。
如果用户想撤回，成本必须低于继续用下去的成本。否则用户会"将错就错"，这比不用更危险。
不要在营销材料里写"值得信赖"。信任是用户在一次次使用中逐渐建立的——每次使用结果可靠、每次出错能收场、每次不确定会标注，信任自然累积。
| 症状 | 最可能缺的层 | 快速验证方法 | 改进方向 |
|---|---|---|---|
| 用户试了就走 | 可理解 | 用户能说出系统做了什么吗 | 增加动作说明和范围边界 |
| 用户反复检查 | 可校验 | 校验成本是否低于原始劳动 | 增加来源标注和不确定标记 |
| 用户私下留台账 | 可控制 | 用户能否随时暂停/修改 | 增加控制权和回退机制 |
| 用户不推荐团队 | 可承担 | 责任边界是否清晰 | 增加角色权限和审批链 |
| 用户只用低风险 | 可回退 | 出错后能否低成本收场 | 增加撤销和回退机制 |
使用说明：观察最突出的"症状"，找到最缺的层，集中改进。不要试图一次补齐所有层——先解决最痛的那个。