Skillquality 0.48

p13d-intuition-training

直觉训练——将直觉转化为可压缩的认知模型与模式识别

Price
free
Protocol
skill
Verified
no

What it does

直觉训练 Skill

适用场景

  • 希望快速做出高质量判断
  • 有经验的专家直觉难以复制
  • 需要将个人直觉转化为团队能力

输入

字段说明
decision_type频繁需要判断的决策类型
expert_examples专家判断的案例(输入→输出)
novice_performance新手在该决策上的表现

输出

  • 决策模式卡片
  • 判断Checklist
  • 训练计划

工作流程

  1. 模式提取:从专家案例中提取判断模式("当X出现时,通常意味着Y")
  2. 模式验证:验证模式在不同情境下的适用性
  3. Checklist化:将模式转化为可执行的检查清单
  4. 训练设计:设计让新手练习该模式的场景与反馈机制
  5. 迭代优化:根据训练效果持续优化模式

注意事项

  • 直觉不是玄学——它是对大量模式的压缩表达
  • 可训练的直觉需要"场景+反馈+迭代"

核心概念

1. 能力不是产品

能力只是某种可用的技术性动作,产品则意味着更完整的一件事:有明确的问题、有重复出现的场景、有持续稳定的价值、有足够强的使用理由、有一条能够长期交付的路径。会做不等于该单独做。你把一个能力误判成产品,就会开始追求错误的东西:独立入口、独立品牌、独立增长、独立定价、独立留存。最后发现功能本身没问题,问题出在用户根本不想为这件事单独开一个窗口。

2. 独立产品五问

判断一个 AI 功能能不能成为产品的五问:(1) 问题独立吗——用户会自然地把它认作一件单独的事吗?(2) 场景重复吗——它对应一个会反复发生的场景吗?(3) 价值够强吗——拿掉后用户是"有点可惜"还是会明显难受?(4) 适合独立还是嵌入——用户最自然的使用路径在哪里?(5) 能持续交付吗——它能不能在未来一年持续稳定地被交付、被使用、被解释、被买单?

3. AI 时代最容易高估"功能的独立性"

AI 的能力呈现方式太有说服力——摘要看起来像产品,改写看起来像产品,搜索建议看起来像产品,助手更像产品。但"看起来像产品"和"真的能成立"之间差着一条很长的路。很多时候 AI 只是把一个原本应该嵌在工作流中的能力包装得比过去更像独立产品。它让你更容易演示价值,却没有自动创造独立使用场景。

4. 嵌入不等于低级

真正高质量的判断不是"这功能能不能做",而是"它应该长在哪里"。如果一个功能天然发生在别人的工作台里(CRM、文档、客服后台),强行抽出来就相当于要求用户切换上下文、复制粘贴、重新理解界面。产品判断力的成熟常常体现在这里:你不再执着于把每个亮眼能力都做成独立入口,而是能接受有些最有价值的东西恰恰应该藏在主工作流里。

5. 训练直觉:每周问"如果独立做,为什么会失败"

挑三个你看到的 AI 功能,强迫自己回答:如果独立做成产品,为什么可能会失败?你会开始更敏感地看到:用户是否真的会单独打开它、它对应的是不是完整任务、没有主工作流承接时价值会不会变薄、留存是不是只来自新鲜感。做多了会形成很重要的产品直觉。

深入核心概念

1. 能力过剩时代,独立性是被高估最严重的维度

"AI的呈现方式太有说服力——摘要看起来像产品,改写看起来像产品,搜索建议看起来像产品,助手更像产品。但'看起来像产品'和'真的能成立'之间差着一条很长的路。" ——书稿第4章

AI时代最危险的误判之一,就是把"功能很亮眼"等同于"值得独立做产品"。能力本身会制造一种幻觉:因为它太容易演示、太容易让人惊艳,团队就会天然高估它的独立价值。但独立产品要解决的不只是"能不能用",而是"用户愿不愿意为它单独开一个窗口"。应用:每周挑三个你看到的AI功能,强迫自己回答"如果独立做成产品,为什么可能会失败"。做多了会形成一种关键直觉——不是每个好功能都值得成为产品。

2. 嵌入不等于低级,做对位置比做大叙事更重要

"真正高质量的判断不是'这功能能不能做',而是'它应该长在哪里'。产品判断力的成熟常常体现在这里:你不再执着于把每个亮眼能力都做成独立入口。" ——书稿第4章

很多功能天然发生在别人的工作台里——CRM、文档、客服后台。强行抽出来就相当于要求用户切换上下文、复制粘贴、重新理解界面。产品判断力的成熟不是看到能力就想单独立项,而是能接受有些最有价值的东西恰恰应该藏在主工作流里。应用:对每个候选功能问——"用户最自然的使用路径在哪里?"如果功能天然发生在已有工具里,嵌入是更明智的选择;如果功能本身能承接完整任务且用户愿意围绕它组织行为,才有机会单独成立。

3. 持续交付压力是独立产品最容易忽视的考验

"它能不能在未来一年持续稳定地被交付、被使用、被解释、被买单?" ——书稿第4章

独立产品意味着持续责任:输入质量不稳定时怎么处理、用户预期越来越高时怎么应对、效果难以解释时怎么沟通、成本结构是否健康。这些问题在模块形态下还能被宿主产品稀释,但一旦变成独立产品,它就必须独自扛住所有压力。应用:对每个想独立做的AI功能,检查以下清单:输入质量稳不稳、留存是否足以覆盖服务成本、场景是否太窄导致增长困难、价值是否太轻导致商业化无力。任何一项严重不过关,独立产品形态就要非常谨慎。

分步执行

步骤 1:问题独立性判断

问自己:如果没有这个功能,用户会清楚地感受到自己少了一个完整工具,还是只会觉得某个流程里少了一个方便的小帮手?前者更接近产品,后者更接近能力。把 AI 摘要和"记账""视频会议"对比——后者用户一想到要完成就能明确知道要打开什么,前者只是中间步骤。

步骤 2:场景稳定性与频率评估

判断这个功能对应的是一个稳定重复的场景,还是偶尔被想起来的场景。如果每次使用都得靠你提醒用户"你可以来用我",那它大概率更像插件而不是产品。看使用频率是否足以支撑独立产品的持续运营。

步骤 3:价值强度测试

做"拿掉测试":拿掉这个功能后,用户是"有点可惜"还是"明显难受"?如果只是正价值(有帮助),它更像增强项。如果是强价值(缺了就别扭),它才更像产品底层能力。独立产品要求的是强价值,而不是正价值。

步骤 4:位置判断——独立 vs 嵌入

判断用户最自然的使用路径在哪里。如果功能天然发生在别人的工作台里,嵌入是更明智的选择。如果功能本身能承接完整任务、有独立输入/产出/反馈循环,且用户愿意围绕它组织行为,才更有机会单独成立。

步骤 5:长期交付可行性评估

问自己:它能不能在未来一年持续稳定地被交付、被使用、被解释、被买单?检查:输入质量是否稳定、用户预期是否会越来越高、效果是否难以解释、成本结构是否健康、留存是否足以覆盖服务成本、场景是否太窄导致增长困难。

示例 1:AI 摘要是产品还是能力

场景:团队做了一个 AI 会议纪要功能,第一次体验满意度很高,分享转发很多,每个人都说"比手写纪要方便"。团队考虑独立做成产品。

五问诊断

  1. 问题独立吗:用户真正要做的不是"得到纪要",而是"让会后的责任、待办和同步继续往前走"。纪要只是中间步骤。❌ 不够独立。
  2. 场景重复吗:会议确实高频,但用户不会为了"生成纪要"单独打开一个工具。⚠️ 场景有但入口不自然。
  3. 价值够强吗:用户说"挺厉害"但不等于"离不开"。⚠️ 正价值有,强价值弱。
  4. 适合独立还是嵌入:用户真正要做的是把纪要搬进飞书/Notion/Jira,重新确认负责人、拆待办。嵌入已有 IM 或项目工具更自然。→ 嵌入。
  5. 能持续交付吗:第一次很好,但独立留存不稳,因为最烦的部分(任务分发、待办流转、责任确认)还没被接住。⚠️ 长期交付有风险。

结论:更适合做嵌入能力而非独立产品。如果要独立做,必须接住从"生成纪要"到"推动会后动作"的完整链路。

示例 2:训练"独立产品判断直觉"

场景:每周 AI 功能分析练习。

分析三个功能

功能独立做为什么会失败
AI 文案改写用户写作发生在编辑器/邮件系统里,改写只是偶尔被调用的一步。用户不会为了改写单独打开一个工具。更适合作为编辑器插件。
AI 智能客服有完整任务(接收→理解→回复→记录)、有独立输入/输出/反馈循环、有稳定高频场景。有机会独立成立。
AI 自动补全表单用户的核心任务是提交报销/申请,不是"补全表单"。补全只是流程中的便利项。更适合嵌入表单系统。

训练收获:通过反复做这个练习,逐渐形成判断直觉——不是每个好功能都值得成为产品,只有那些真正承接独立任务和持续价值的能力才配被当作产品来设计。

独立产品 vs 能力层 vs 模块——三种形态对比

维度独立产品能力层模块
用户心智专门打开、记住、回来在工作流中自然触发整体体验的一部分
任务完整性承接完整任务提供任务链中一段增量增强某个方面
增长方式独立获客、独立留存依附主产品扩散随主产品增长
商业化独立定价、独立预算被包含在主产品定价中被包含在整体价值中
失败模式用户不想单独打开没有主工作流承接被更好的模块替代
典型例子Slack、NotionAI 起草嵌入 CRM拼写检查嵌入编辑器

长期交付压力清单

把功能做成独立产品后,它必须独自扛住以下所有压力:

  • 输入质量不稳定时怎么处理
  • 用户预期越来越高时怎么应对
  • 效果难以解释时怎么沟通
  • 成本结构是否健康(API 调用成本 vs 收费)
  • 留存是否足以覆盖服务成本
  • 场景是否太窄导致增长困难
  • 价值是否太轻导致商业化无力
  • 竞品门槛是否足够高

"如果独立做,为什么会失败"练习模板

每周挑三个 AI 功能,对每个功能回答:

  1. 用户是否真的会单独打开它?
  2. 它对应的是一个完整任务,还是任务中的一步?
  3. 没有主工作流承接时,价值会不会变薄?
  4. 它的留存主要来自新鲜感还是持续需要?
  5. 它的商业化需要依附别的产品吗?
  6. 如果独立做失败,最可能失败在什么地方?

5 分钟练习

挑一个你最近觉得"很像产品"的 AI 功能,写下这六个问题:

  1. 用户想解决的是一个独立问题,还是流程中的一步。
  2. 这个场景会不会稳定重复发生。
  3. 拿掉它之后,用户是明显难受,还是只是觉得少了点方便。
  4. 它更自然地应该独立存在,还是嵌进某个已有工具。
  5. 如果把它做成独立产品,留存和商业化会靠什么成立。
  6. 如果独立做失败,最可能失败在什么地方。

把这六问写清楚,你很可能就会发现:真正难的不是把功能做出来,而是把它放到对的位置上。

独立产品 vs 能力层:位置判断决策树

用户会自然地把它当作一件单独的事吗?
  ├─ 是 → 场景会稳定重复吗?
  │       ├─ 是 → 拿掉后用户会明显难受吗?
  │       │       ├─ 是 → 用户会为它单独付费吗?
  │       │       │       ├─ 是 → 【独立产品】
  │       │       │       └─ 否 → 【免费独立产品或付费能力层】
  │       │       └─ 否 → 【嵌入能力层】
  │       └─ 否 → 【模块或插件】
  └─ 否 → 它在哪个工作流中被触发?
          ├─ 能明确 → 【嵌入能力层】
          └─ 不明确 → 【重新审视是否值得做】

更多产品 vs 能力判断案例

案例 1:AI 智能客服

维度评估
问题独立✅ "处理客户问题"是独立任务
场景重复✅ 每天高频
价值够强✅ 拿掉后客户等待时间大幅增加
位置判断✅ 有独立输入/输出/反馈循环
持续交付✅ 知识库可更新,效果可优化
结论独立产品

案例 2:AI 文案改写

维度评估
问题独立❌ "改写"是写作流程中的一步
场景重复⚠️ 偶尔调用
价值够强⚠️ 有帮助但不关键
位置判断❌ 用户在编辑器/邮件系统里写作
持续交付⚠️ 改写质量波动大
结论嵌入编辑器的插件

案例 3:AI 合同审查

维度评估
问题独立✅ "审查合同"是独立任务
场景重复✅ 法务日常工作
价值够强✅ 人工审查耗时且容易遗漏
位置判断⚠️ 需要接进合同管理系统
持续交付⚠️ 法规变化需要持续更新
结论独立产品或 CRM/法务系统的能力层

案例 4:AI 自动补全表单

维度评估
问题独立❌ "补全表单"不是用户的最终目标
场景重复⚠️ 填表单时触发
价值够强⚠️ 方便但不关键
位置判断❌ 用户在表单系统里操作
持续交付⚠️ 表单结构变化需要适配
结论嵌入表单系统的模块

位置判断的额外考量因素

除了五问之外,还有几个因素影响独立 vs 嵌入的判断:

因素 1:竞品格局

如果已有强竞品占据独立产品位置,做能力层嵌入可能是差异化策略。如果市场空白,独立产品有机会建立心智。

因素 2:用户规模

用户规模大且需求明确时,独立产品更容易获得足够的心智份额。用户规模小时,嵌入已有产品的获客效率更高。

因素 3:技术壁垒

如果技术壁垒足够高,独立产品可以靠壁垒保护自己。如果壁垒低,嵌入已有产品的工作流可以建立更深的粘性。

因素 4:团队能力

如果团队有完整的产品、技术、运营能力,可以尝试独立产品。如果团队更擅长技术,做能力层嵌入是更务实的选择。

长期交付压力清单(扩展版)

把功能做成独立产品后,它必须独自扛住以下所有压力:

效果稳定性压力

  • 输入质量不稳定时怎么处理(垃圾进垃圾出)
  • 模型效果波动时怎么兜底(降级方案)
  • 边界情况怎么处理(异常输入、极端场景)
  • 效果难以解释时怎么沟通(用户问"为什么错了")

用户预期压力

  • 用户预期越来越高时怎么应对(期望管理)
  • 用户发现竞品更好时怎么留住(差异化价值)
  • 用户要求定制化时怎么平衡(标准化 vs 个性化)

商业化压力

  • API 调用成本 vs 收费是否健康(单位经济模型)
  • 留存是否足以覆盖服务成本(LTV > CAC)
  • 定价策略是否可持续(免费增值/订阅/按量)
  • 增长来源是否可复制(自然增长 vs 付费获客)

竞争压力

  • 竞品门槛是否足够高(护城河)
  • 大厂是否可能切入(防御策略)
  • 开源替代是否会出现(差异化策略)

长期韧性压力

  • 场景是否太窄导致增长困难(横向扩展路径)
  • 价值是否太轻导致商业化无力(纵向深化路径)
  • 技术变化时产品是否会被淘汰(适应性设计)

独立产品的五个常见失败模式

失败模式 1:用户心智缺失

用户不知道什么时候该打开它。破解:场景驱动的入口设计,让用户在特定时刻自然想到它。

失败模式 2:场景太窄

只有小众用户会用。破解:横向拓展场景,或接受小众市场的定位。

失败模式 3:价值不够强

替代品太多或"有也行没有也行"。破解:深化价值,从"有帮助"变成"离不开"。

失败模式 4:位置不对

用户在工作流中找不到它。破解:嵌入用户已有的工作流,而不是要求用户来找你。

失败模式 5:商业化困难

用户愿意用但不愿意单独付费。破解:探索不同的商业化模式,或接受嵌入形态。

"如果独立做为什么会失败"深度练习模板

对每个 AI 功能,回答以下 10 个问题:

功能名称: ____

1. 用户是否真的会单独打开它?
   回答: ____

2. 它对应的是一个完整任务,还是任务中的一步?
   回答: ____

3. 没有主工作流承接时,价值会不会变薄?
   回答: ____

4. 它的留存主要来自新鲜感还是持续需要?
   回答: ____

5. 它的商业化需要依附别的产品吗?
   回答: ____

6. 如果输入质量变差,它还能工作吗?
   回答: ____

7. 用户预期提高后,它还能满足吗?
   回答: ____

8. 如果竞品免费提供类似功能,它还有壁垒吗?
   回答: ____

9. 如果独立做失败,最可能失败在什么地方?
   回答: ____

10. 如果嵌入已有产品,价值会不会更强?
    回答: ____

综合判断: [ ] 独立产品  [ ] 能力层  [ ] 模块  [ ] 不值得做

Capabilities

skillsource-gmaxxxieskill-p13d-intuition-trainingtopic-agent-skillstopic-ai-agenttopic-ai-nativetopic-ai-producttopic-methodologytopic-product-managementtopic-product-methodologytopic-product-thinkingtopic-skills

Install

Quality

0.48/ 1.00

deterministic score 0.48 from registry signals: · indexed on github topic:agent-skills · 56 github stars · SKILL.md body (7,529 chars)

Provenance

Indexed fromgithub
Enriched2026-05-18 18:57:29Z · deterministic:skill-github:v1 · v1
First seen2026-05-01
Last seen2026-05-18

Agent access

p13d-intuition-training — Clawmart · Clawmart