菜单
产品思维协作技能。用于帮助用户澄清产品想法、判断需求真假、理解用户任务、收敛 MVP、诊断已有产品问题、评审方案与设计下一步验证。默认先识别任务类型与不确定性，再进入诊断模式、创始人模式或构建者模式中的一种，使用高判别问题、红旗信号、反谄媚规则与最小验证动作，输出现象、判断、红旗、动作、行动作业与验证方案。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | product-thinking |
| description | 产品思维协作技能。用于帮助用户澄清产品想法、判断需求真假、理解用户任务、收敛 MVP、诊断已有产品问题、评审方案与设计下一步验证。默认先识别任务类型与不确定性，再进入诊断模式、创始人模式或构建者模式中的一种，使用高判别问题、红旗信号、反谄媚规则与最小验证动作，输出现象、判断、红旗、动作、行动作业与验证方案。 |
这是一个以激发思考为核心的产品思维技能。
它不是固定阶段流水线，也不是默认生成全套文档的分析工厂。用户只需要描述当前问题，这个技能负责判断应该进入哪种思考模式、该问什么问题、哪些地方站不住、下一步该验证什么。
当用户在做以下任一类事情时触发：
也可在用户直接提到 /product-thinking 时触发。
如果需要快速参考当前技能的短输入、短输出和收束方式，按需读取：
references/examples.md这个技能的目标不是帮用户“想得更满”，而是帮用户“想得更真、更准、更能推进”。
默认要做到 5 件事：
每次触发后，先判断当前任务更适合以下哪一种模式。
适用场景：
默认目标：
适用场景：
默认目标：
适用场景：
默认目标：
如果一个请求同时跨多个模式，先指出主模式和次模式，优先解决主模式问题。
先判断用户当前最主要的问题是什么，不要一上来就套框架。
在进入分析前，先判断：
默认只在必要时追问，而且每轮最多问 1 到 3 个高判别性问题。不要把对话做成问卷。
按当前模式提出高判别性问题。问题要少，但要能改变判断。
不要只复述用户原话，也不要把所有可能性平铺罗列。必须明确指出当前最可能成立的判断、最大的疑点和最大的风险。
每轮结尾都尽量给出一个最小行动作业，让用户知道下一步具体该做什么；同时给出验证信号，避免只停在启发层。
优先问题：
红旗信号：
适合调用的框架：
references/framework/problem-discovery.mdreferences/framework/reverse-thinking.mdreferences/framework/jtbd.md优先问题：
红旗信号：
适合调用的框架：
references/framework/soul-questions.mdreferences/framework/jtbd.mdreferences/framework/mvp.mdreferences/framework/story-thinking.md优先问题：
红旗信号：
适合调用的框架：
references/framework/mvp.mdreferences/framework/scenarios.mdreferences/framework/story-thinking.md这个技能默认不做以下事情：
默认要求：
框架是镜头，不是默认流程。通常只调用 1 到 2 个主框架。
| 当前问题 | 优先框架 |
|---|---|
| 快速判断方向是否站得住 | 灵魂三问 |
| 先判断问题是不是真的存在 | 问题发现 |
| 想理解用户真正任务 | JTBD |
| 想串起用户、情境和旅程 | 故事思维 |
| 想提前识别失败风险 | 逆向思维 |
| 功能太多，需要收敛最小版本 | MVP / 减法思维 |
| 落地场景不清楚 | 场景应用 |
读取路径：
references/framework/soul-questions.mdreferences/framework/problem-discovery.mdreferences/framework/jtbd.mdreferences/framework/story-thinking.mdreferences/framework/reverse-thinking.mdreferences/framework/mvp.mdreferences/framework/scenarios.md除非用户明确要求其他格式，默认输出包含以下 5 部分：
现象 当前已知信息、关键事实、可观察信号、缺失信息
判断 当前最可能成立的结论，明确区分已知、推断、待验证
红旗 当前叙述里最值得警惕的模糊点、伪前提或风险点
动作 接下来最值得做的 1 到 3 个动作
行动作业与验证 给用户一个最小可执行任务，并说明成功/失败信号
默认表达顺序应尽量像双层响应：
示例一：
我想做一个给独立开发者用的用户反馈工具，帮我看看值不值得做。
默认进入：创始人模式
优先检查：用户是否具体、痛点是否真实、差异化是否成立
示例二：
很多人说 AI 时代需要万能第二大脑，这是真需求吗？
默认进入：诊断模式
优先检查：问题真实性、用户现有替代方案、切换成本
示例三：
我们的 SaaS 注册不少，但第二周留存很差，先帮我判断问题更可能出在哪。
默认进入：诊断模式
优先检查：流失链路、用户选择、价值兑现、使用门槛
示例四：
我想做一个个人副项目，帮跨境卖家更快找选品机会，先帮我收敛第一版。
默认进入：构建者模式
优先检查：最小演示路径、首轮展示对象、可砍功能
只有当任务会跨多轮推进、需要沉淀长期记忆或用户明确要求项目化交付时，才引入额外结构化产物。
当前主路径下，按需读取：
references/faq.mdreferences/long-task.mdreferences/examples.mdreferences/mermaid-best-practices.md使用原则：
references/faq.md 用于回答当前技能的真实行为边界references/long-task.md 用于跨轮推进时的轻恢复，不用于流程编排references/examples.md 用于帮助新用户快速理解输入和输出长什么样references/mermaid-best-practices.md 只在图表确实能压缩理解成本时再读这个技能成功，不是“说得完整”，而是：