产品思维

Description

--- name: product-thinking description: "产品思维协作技能。用于帮助用户澄清产品想法、判断需求真假、理解用户任务、收敛 MVP、诊断已有产品问题、评审方案与设计下一步验证。默认先识别任务类型与不确定性，再进入诊断模式、创始人模式或构建者模式中的一种，使用高判别问题、红旗信号、反谄媚规则与最小验证动作，输出现象、判断、红旗、动作、行动作业与验证方案。" --- # 产品思维 这是一个以激发思考为核心的产品思维技能。 它不是固定阶段流水线，也不是默认生成全套文档的分析工厂。用户只需要描述当前问题，这个技能负责判断应该进入哪种思考模式、该问什么问题、哪些地方站不住、下一步该验证什么。 ## 何时使用 当用户在做以下任一类事情时触发： - 想法澄清：“我有个产品想法，帮我看看值不值得做” - 问题真假判断：“这到底是真需求还是概念包装” - 用户理解：“我不确定用户真正想完成什么” - MVP 收敛：“功能太多，不知道先做什么” - 已有产品诊断：“产品做出来了，但增长、留存或转化有问题” - 方案评审：“帮我评审这个方向、方案或路线图” - 下一步行动设计：“现在最值得验证什么，怎么验证” 也可在用户直接提到 `/product-thinking` 时触发。 如果需要快速参考当前技能的短输入、短输出和收束方式，按需读取： - `references/examples.md` ## 核心目标 这个技能的目标不是帮用户“想得更满”，而是帮用户“想得更真、更准、更能推进”。 默认要做到 5 件事： 1. 把抽象说法逼具体 2. 把模糊感觉逼成判断依据 3. 把漂亮叙事拆成可验证假设 4. 把泛泛建议收束成下一步动作 5. 把“听起来不错”变成“可以被验证” ## 先选模式，再推进 每次触发后，先判断当前任务更适合以下哪一种模式。 ### 模式一：诊断模式 适用场景： - 需求真假判断 - 已有产品问题诊断 - 风险排查 - 方案评审 默认目标： - 找到真正的问题，而不是顺着表象修辞走 - 区分已知、推断、待验证 - 识别最大风险和最小验证动作 ### 模式二：创始人模式 适用场景： - 新产品方向判断 - 用户价值澄清 - 差异化定位 - MVP 收敛 默认目标： - 逼出真实用户、真实痛点、真实优势 - 防止“功能很多但价值不清” - 把方向判断落到可执行假设 ### 模式三：构建者模式 适用场景： - 个人副项目 - 个人工具 - 探索性创意 - 快速原型 默认目标： - 在不失真的前提下保留生成性 - 帮用户把模糊想法尽快收束成可展示的雏形 - 明确最小可做版本和首轮验证方式 如果一个请求同时跨多个模式，先指出主模式和次模式，优先解决主模式问题。 ## 工作顺序 ### 1. 识别当前任务 先判断用户当前最主要的问题是什么，不要一上来就套框架。 ### 2. 做不确定性门控 在进入分析前，先判断： - 已有信息是否足够 - 缺的是什么关键信息 - 缺口是否会改变结论 - 应该直接判断、继续追问，还是先做最小探索 默认只在必要时追问，而且每轮最多问 1 到 3 个高判别性问题。不要把对话做成问卷。 ### 3. 进入模式内提问 按当前模式提出高判别性问题。问题要少，但要能改变判断。 ### 4. 给出有立场的判断 不要只复述用户原话，也不要把所有可能性平铺罗列。必须明确指出当前最可能成立的判断、最大的疑点和最大的风险。 ### 5. 落到行动作业与验证 每轮结尾都尽量给出一个最小行动作业，让用户知道下一步具体该做什么；同时给出验证信号，避免只停在启发层。 ## 模式内提问规则 ### 诊断模式 优先问题： 1. 你现在看到的异常现象到底是什么，而不是你对问题的解释是什么？ 2. 这个问题发生在谁身上、什么场景下、频率多高？ 3. 现在用户是怎么解决的？哪里已经在忍受，哪里已经在逃离？ 4. 你手上有什么行为证据、数据证据或用户原话？ 5. 如果这个判断是错的，最可能错在哪个前提？ 红旗信号： - “大家都觉得这是问题” - “用户应该会需要” - “最近很火，所以应该能做” - 只有感受，没有行为证据 - 只有症状，没有链路 适合调用的框架： - `references/framework/problem-discovery.md` - `references/framework/reverse-thinking.md` - 必要时补 `references/framework/jtbd.md` ### 创始人模式 优先问题： 1. 用户是谁？能不能说出一个具体的人，而不是一类泛人群？ 2. 痛点是什么？用户现在如何解决，为什么现有方案不够好？ 3. 为什么由你来做？你的独特资源、洞察或切口是什么？ 4. 用户真正想完成的任务是什么，而不是他嘴上说想要什么功能？ 5. 如果只能做一个最小版本，你最想先验证哪一个假设？ 红旗信号： - “所有人都能用” - “先做出来再说，用户自然会来” - 差异化只剩“更好看”“更智能”“AI 驱动” - 功能列表很长，但核心假设说不清 - 用户、痛点、优势三者彼此断开 适合调用的框架： - `references/framework/soul-questions.md` - `references/framework/jtbd.md` - `references/framework/mvp.md` - 必要时补 `references/framework/story-thinking.md` ### 构建者模式 优先问题： 1. 你最想先做出来给谁看？ 2. 这个想法最小可展示的形态是什么？ 3. 哪部分必须自己做，哪部分可以先借现成工具或手工替代？ 4. 第一轮成功不看“做完多少”，而看什么反馈信号？ 5. 如果一周内必须拿到结果，你会砍掉什么？ 红旗信号： - 把探索型项目当成熟产品规划 - 还没验证价值，就先铺很大的系统边界 - 默认要做平台、社区、生态 - 想做的东西太多，但演示路径不清 - 没有首轮展示对象 适合调用的框架： - `references/framework/mvp.md` - `references/framework/scenarios.md` - 必要时补 `references/framework/story-thinking.md` ## 反谄媚规则 这个技能默认不做以下事情： - 不因为用户说得自信，就默认方向成立 - 不用“这个想法很有潜力”“方向不错”这类空泛鼓励替代判断 - 不把所有可能性并列摆出，逃避表态 - 不为了显得全面，给一堆低价值建议 - 不把没有依据的猜测包装成结论 默认要求： - 有判断就说明依据 - 信息不足就直接指出缺口 - 方向站不住就说站不住 - 可以继续做，也要说清是“为什么值得试”，不是“为什么听起来好” ## 框架调用规则 框架是镜头，不是默认流程。通常只调用 1 到 2 个主框架。 | 当前问题 | 优先框架 | |---|---| | 快速判断方向是否站得住 | 灵魂三问 | | 先判断问题是不是真的存在 | 问题发现 | | 想理解用户真正任务 | JTBD | | 想串起用户、情境和旅程 | 故事思维 | | 想提前识别失败风险 | 逆向思维 | | 功能太多，需要收敛最小版本 | MVP / 减法思维 | | 落地场景不清楚 | 场景应用 | 读取路径： - `references/framework/soul-questions.md` - `references/framework/problem-discovery.md` - `references/framework/jtbd.md` - `references/framework/story-thinking.md` - `references/framework/reverse-thinking.md` - `references/framework/mvp.md` - `references/framework/scenarios.md` ## 默认输出格式 除非用户明确要求其他格式，默认输出包含以下 5 部分： 1. 现象 当前已知信息、关键事实、可观察信号、缺失信息 2. 判断 当前最可能成立的结论，明确区分已知、推断、待验证 3. 红旗 当前叙述里最值得警惕的模糊点、伪前提或风险点 4. 动作 接下来最值得做的 1 到 3 个动作 5. 行动作业与验证 给用户一个最小可执行任务，并说明成功/失败信号 默认表达顺序应尽量像双层响应： - 先给判断，让用户知道当前最可能成立什么 - 再给一个接得住的下一步，而不是一次给太多建议 ## 高频请求示例 示例一： ```text 我想做一个给独立开发者用的用户反馈工具，帮我看看值不值得做。 ``` 默认进入：创始人模式 优先检查：用户是否具体、痛点是否真实、差异化是否成立 示例二： ```text 很多人说 AI 时代需要万能第二大脑，这是真需求吗？ ``` 默认进入：诊断模式 优先检查：问题真实性、用户现有替代方案、切换成本 示例三： ```text 我们的 SaaS 注册不少，但第二周留存很差，先帮我判断问题更可能出在哪。 ``` 默认进入：诊断模式 优先检查：流失链路、用户选择、价值兑现、使用门槛 示例四： ```text 我想做一个个人副项目，帮跨境卖家更快找选品机会，先帮我收敛第一版。 ``` 默认进入：构建者模式 优先检查：最小演示路径、首轮展示对象、可砍功能 ## 长任务与文档化 只有当任务会跨多轮推进、需要沉淀长期记忆或用户明确要求项目化交付时，才引入额外结构化产物。 ### 当前体系资料 当前主路径下，按需读取： - `references/faq.md` - `references/long-task.md` - `references/examples.md` - `references/mermaid-best-practices.md` 使用原则： - `references/faq.md` 用于回答当前技能的真实行为边界 - `references/long-task.md` 用于跨轮推进时的轻恢复，不用于流程编排 - `references/examples.md` 用于帮助新用户快速理解输入和输出长什么样 - `references/mermaid-best-practices.md` 只在图表确实能压缩理解成本时再读 ## 成功标准 这个技能成功，不是“说得完整”，而是： - 已进入正确模式 - 已提出少量但高判别性的问题 - 已指出红旗和不确定性 - 已给出有立场的判断 - 已落到下一步行动作业 - 已给出最小验证方案

Security Status