Menü
直觉训练——将直觉转化为可压缩的认知模型与模式识别
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
AI Native 产品方法论——价值发现循环的实操 Skill。 用户提供已上线或正在验证的 AI 产品，Skill 自动执行价值发现流程： 价值信号识别 → 伪价值排除 → 价值密度评估 → 市场测试设计 → 定价策略联动 → 方向修正建议 → 输出价值发现方案。 基于《AI Native 产品方法论》第22章。
《观照》全书编排器——根据用户输入的问题类型，路由到对应的章节Skill，串联全链路决策修正流程
检查方法使用的前提是否成立——识别情境变化、验证假设前提、重配适用方法
先看机制是否有害，再看结果是否有效——价值/代价/情绪/退出权四重检查
停止错误方向，也是一种推进——归零分析、暂停策略、止损决策
收入从哪里来，产品就会站在哪边——收入来源审视与激励偏差检查
| name | p13d-intuition-training |
| description | 直觉训练——将直觉转化为可压缩的认知模型与模式识别 |
| stage | p13 |
| tags | ["判断力","直觉训练","模式识别"] |
| source_book | 判断力与直觉力 |
| source_chapter | 第4章 直觉不是天赋，而是压缩后的认知模型 |
| version | 1.0.0 |
| 字段 | 说明 |
|---|---|
| decision_type | 频繁需要判断的决策类型 |
| expert_examples | 专家判断的案例（输入→输出） |
| novice_performance | 新手在该决策上的表现 |
能力只是某种可用的技术性动作，产品则意味着更完整的一件事：有明确的问题、有重复出现的场景、有持续稳定的价值、有足够强的使用理由、有一条能够长期交付的路径。会做不等于该单独做。你把一个能力误判成产品，就会开始追求错误的东西：独立入口、独立品牌、独立增长、独立定价、独立留存。最后发现功能本身没问题，问题出在用户根本不想为这件事单独开一个窗口。
判断一个 AI 功能能不能成为产品的五问：(1) 问题独立吗——用户会自然地把它认作一件单独的事吗？(2) 场景重复吗——它对应一个会反复发生的场景吗？(3) 价值够强吗——拿掉后用户是"有点可惜"还是会明显难受？(4) 适合独立还是嵌入——用户最自然的使用路径在哪里？(5) 能持续交付吗——它能不能在未来一年持续稳定地被交付、被使用、被解释、被买单？
AI 的能力呈现方式太有说服力——摘要看起来像产品，改写看起来像产品，搜索建议看起来像产品，助手更像产品。但"看起来像产品"和"真的能成立"之间差着一条很长的路。很多时候 AI 只是把一个原本应该嵌在工作流中的能力包装得比过去更像独立产品。它让你更容易演示价值，却没有自动创造独立使用场景。
真正高质量的判断不是"这功能能不能做"，而是"它应该长在哪里"。如果一个功能天然发生在别人的工作台里（CRM、文档、客服后台），强行抽出来就相当于要求用户切换上下文、复制粘贴、重新理解界面。产品判断力的成熟常常体现在这里：你不再执着于把每个亮眼能力都做成独立入口，而是能接受有些最有价值的东西恰恰应该藏在主工作流里。
挑三个你看到的 AI 功能，强迫自己回答：如果独立做成产品，为什么可能会失败？你会开始更敏感地看到：用户是否真的会单独打开它、它对应的是不是完整任务、没有主工作流承接时价值会不会变薄、留存是不是只来自新鲜感。做多了会形成很重要的产品直觉。
"AI的呈现方式太有说服力——摘要看起来像产品，改写看起来像产品，搜索建议看起来像产品，助手更像产品。但'看起来像产品'和'真的能成立'之间差着一条很长的路。" ——书稿第4章
AI时代最危险的误判之一，就是把"功能很亮眼"等同于"值得独立做产品"。能力本身会制造一种幻觉：因为它太容易演示、太容易让人惊艳，团队就会天然高估它的独立价值。但独立产品要解决的不只是"能不能用"，而是"用户愿不愿意为它单独开一个窗口"。应用：每周挑三个你看到的AI功能，强迫自己回答"如果独立做成产品，为什么可能会失败"。做多了会形成一种关键直觉——不是每个好功能都值得成为产品。
"真正高质量的判断不是'这功能能不能做'，而是'它应该长在哪里'。产品判断力的成熟常常体现在这里：你不再执着于把每个亮眼能力都做成独立入口。" ——书稿第4章
很多功能天然发生在别人的工作台里——CRM、文档、客服后台。强行抽出来就相当于要求用户切换上下文、复制粘贴、重新理解界面。产品判断力的成熟不是看到能力就想单独立项，而是能接受有些最有价值的东西恰恰应该藏在主工作流里。应用：对每个候选功能问——"用户最自然的使用路径在哪里？"如果功能天然发生在已有工具里，嵌入是更明智的选择；如果功能本身能承接完整任务且用户愿意围绕它组织行为，才有机会单独成立。
"它能不能在未来一年持续稳定地被交付、被使用、被解释、被买单？" ——书稿第4章
独立产品意味着持续责任：输入质量不稳定时怎么处理、用户预期越来越高时怎么应对、效果难以解释时怎么沟通、成本结构是否健康。这些问题在模块形态下还能被宿主产品稀释，但一旦变成独立产品，它就必须独自扛住所有压力。应用：对每个想独立做的AI功能，检查以下清单：输入质量稳不稳、留存是否足以覆盖服务成本、场景是否太窄导致增长困难、价值是否太轻导致商业化无力。任何一项严重不过关，独立产品形态就要非常谨慎。
问自己：如果没有这个功能，用户会清楚地感受到自己少了一个完整工具，还是只会觉得某个流程里少了一个方便的小帮手？前者更接近产品，后者更接近能力。把 AI 摘要和"记账""视频会议"对比——后者用户一想到要完成就能明确知道要打开什么，前者只是中间步骤。
判断这个功能对应的是一个稳定重复的场景，还是偶尔被想起来的场景。如果每次使用都得靠你提醒用户"你可以来用我"，那它大概率更像插件而不是产品。看使用频率是否足以支撑独立产品的持续运营。
做"拿掉测试"：拿掉这个功能后，用户是"有点可惜"还是"明显难受"？如果只是正价值（有帮助），它更像增强项。如果是强价值（缺了就别扭），它才更像产品底层能力。独立产品要求的是强价值，而不是正价值。
判断用户最自然的使用路径在哪里。如果功能天然发生在别人的工作台里，嵌入是更明智的选择。如果功能本身能承接完整任务、有独立输入/产出/反馈循环，且用户愿意围绕它组织行为，才更有机会单独成立。
问自己：它能不能在未来一年持续稳定地被交付、被使用、被解释、被买单？检查：输入质量是否稳定、用户预期是否会越来越高、效果是否难以解释、成本结构是否健康、留存是否足以覆盖服务成本、场景是否太窄导致增长困难。
场景：团队做了一个 AI 会议纪要功能，第一次体验满意度很高，分享转发很多，每个人都说"比手写纪要方便"。团队考虑独立做成产品。
五问诊断：
结论：更适合做嵌入能力而非独立产品。如果要独立做，必须接住从"生成纪要"到"推动会后动作"的完整链路。
场景：每周 AI 功能分析练习。
分析三个功能：
| 功能 | 独立做为什么会失败 |
|---|---|
| AI 文案改写 | 用户写作发生在编辑器/邮件系统里，改写只是偶尔被调用的一步。用户不会为了改写单独打开一个工具。更适合作为编辑器插件。 |
| AI 智能客服 | 有完整任务（接收→理解→回复→记录）、有独立输入/输出/反馈循环、有稳定高频场景。有机会独立成立。 |
| AI 自动补全表单 | 用户的核心任务是提交报销/申请，不是"补全表单"。补全只是流程中的便利项。更适合嵌入表单系统。 |
训练收获：通过反复做这个练习，逐渐形成判断直觉——不是每个好功能都值得成为产品，只有那些真正承接独立任务和持续价值的能力才配被当作产品来设计。
| 维度 | 独立产品 | 能力层 | 模块 |
|---|---|---|---|
| 用户心智 | 专门打开、记住、回来 | 在工作流中自然触发 | 整体体验的一部分 |
| 任务完整性 | 承接完整任务 | 提供任务链中一段增量 | 增强某个方面 |
| 增长方式 | 独立获客、独立留存 | 依附主产品扩散 | 随主产品增长 |
| 商业化 | 独立定价、独立预算 | 被包含在主产品定价中 | 被包含在整体价值中 |
| 失败模式 | 用户不想单独打开 | 没有主工作流承接 | 被更好的模块替代 |
| 典型例子 | Slack、Notion | AI 起草嵌入 CRM | 拼写检查嵌入编辑器 |
把功能做成独立产品后，它必须独自扛住以下所有压力：
每周挑三个 AI 功能，对每个功能回答：
挑一个你最近觉得"很像产品"的 AI 功能，写下这六个问题：
把这六问写清楚，你很可能就会发现：真正难的不是把功能做出来，而是把它放到对的位置上。
用户会自然地把它当作一件单独的事吗？
├─ 是 → 场景会稳定重复吗？
│ ├─ 是 → 拿掉后用户会明显难受吗？
│ │ ├─ 是 → 用户会为它单独付费吗？
│ │ │ ├─ 是 → 【独立产品】
│ │ │ └─ 否 → 【免费独立产品或付费能力层】
│ │ └─ 否 → 【嵌入能力层】
│ └─ 否 → 【模块或插件】
└─ 否 → 它在哪个工作流中被触发？
├─ 能明确 → 【嵌入能力层】
└─ 不明确 → 【重新审视是否值得做】
| 维度 | 评估 |
|---|---|
| 问题独立 | ✅ "处理客户问题"是独立任务 |
| 场景重复 | ✅ 每天高频 |
| 价值够强 | ✅ 拿掉后客户等待时间大幅增加 |
| 位置判断 | ✅ 有独立输入/输出/反馈循环 |
| 持续交付 | ✅ 知识库可更新，效果可优化 |
| 结论 | 独立产品 |
| 维度 | 评估 |
|---|---|
| 问题独立 | ❌ "改写"是写作流程中的一步 |
| 场景重复 | ⚠️ 偶尔调用 |
| 价值够强 | ⚠️ 有帮助但不关键 |
| 位置判断 | ❌ 用户在编辑器/邮件系统里写作 |
| 持续交付 | ⚠️ 改写质量波动大 |
| 结论 | 嵌入编辑器的插件 |
| 维度 | 评估 |
|---|---|
| 问题独立 | ✅ "审查合同"是独立任务 |
| 场景重复 | ✅ 法务日常工作 |
| 价值够强 | ✅ 人工审查耗时且容易遗漏 |
| 位置判断 | ⚠️ 需要接进合同管理系统 |
| 持续交付 | ⚠️ 法规变化需要持续更新 |
| 结论 | 独立产品或 CRM/法务系统的能力层 |
| 维度 | 评估 |
|---|---|
| 问题独立 | ❌ "补全表单"不是用户的最终目标 |
| 场景重复 | ⚠️ 填表单时触发 |
| 价值够强 | ⚠️ 方便但不关键 |
| 位置判断 | ❌ 用户在表单系统里操作 |
| 持续交付 | ⚠️ 表单结构变化需要适配 |
| 结论 | 嵌入表单系统的模块 |
除了五问之外，还有几个因素影响独立 vs 嵌入的判断：
如果已有强竞品占据独立产品位置，做能力层嵌入可能是差异化策略。如果市场空白，独立产品有机会建立心智。
用户规模大且需求明确时，独立产品更容易获得足够的心智份额。用户规模小时，嵌入已有产品的获客效率更高。
如果技术壁垒足够高，独立产品可以靠壁垒保护自己。如果壁垒低，嵌入已有产品的工作流可以建立更深的粘性。
如果团队有完整的产品、技术、运营能力，可以尝试独立产品。如果团队更擅长技术，做能力层嵌入是更务实的选择。
把功能做成独立产品后，它必须独自扛住以下所有压力：
用户不知道什么时候该打开它。破解：场景驱动的入口设计，让用户在特定时刻自然想到它。
只有小众用户会用。破解：横向拓展场景，或接受小众市场的定位。
替代品太多或"有也行没有也行"。破解：深化价值，从"有帮助"变成"离不开"。
用户在工作流中找不到它。破解：嵌入用户已有的工作流，而不是要求用户来找你。
用户愿意用但不愿意单独付费。破解：探索不同的商业化模式，或接受嵌入形态。
对每个 AI 功能，回答以下 10 个问题：
功能名称: ____
1. 用户是否真的会单独打开它？
回答: ____
2. 它对应的是一个完整任务，还是任务中的一步？
回答: ____
3. 没有主工作流承接时，价值会不会变薄？
回答: ____
4. 它的留存主要来自新鲜感还是持续需要？
回答: ____
5. 它的商业化需要依附别的产品吗？
回答: ____
6. 如果输入质量变差，它还能工作吗？
回答: ____
7. 用户预期提高后，它还能满足吗？
回答: ____
8. 如果竞品免费提供类似功能，它还有壁垒吗？
回答: ____
9. 如果独立做失败，最可能失败在什么地方？
回答: ____
10. 如果嵌入已有产品，价值会不会更强？
回答: ____
综合判断: [ ] 独立产品 [ ] 能力层 [ ] 模块 [ ] 不值得做