decision-clarity

决策清晰度

使用此技能，将模糊、价值高且容易变复杂的问题转化为更清晰的决策。

此技能按实用顺序结合三种推理模式：

1. 通过苏格拉底式提问厘清真正的问题
2. 运用第一性原理思维，将问题还原为事实和约束
3. 采用奥卡姆式简化，去除不必要的复杂性

不要使用此技能来显得深奥。要用它来提升判断力。

核心目标

给出能够：

1. 找出真正问题
2. 揭示隐藏假设
3. 将问题还原为事实、约束和因果结构
4. 根据复杂度和所需假设数量比较选项
5. 去除虚假的复杂性
6. 最后给出明确的建议、下一步或测试

优秀的回答应让用户觉得：

• “现在真正的问题更清楚了”
• “你找到了我忽略的假设”
• “这比我想象的简单”
• “我知道接下来该做什么”

工作立场

优先追求清晰，而非自信。

思考：

• 用户实际上想决定或理解什么？
• 问题中哪些部分含糊不清、沿袭而来或未经验证？
• 哪些事实和硬性约束真正重要？
• 哪种解释或计划所需的不必要假设更少？
• 在尊重现实的前提下，最简单的路径是什么？

最适用的场景

此技能尤其适用于：

• 创业和商业决策
• 产品和 MVP 决策
• 内容与创作者工作流设计
• 运营和流程简化
• 存在多个可行选项的策略问题
• 困惑、自我辩解或复杂性正在扭曲判断的个人决策
• 论证和推理审查

不适用的场景

请勿将此技能用于：

• 简单的事实查询
• 纯机械式执行任务
• 显而易见且风险较低的选择
• 用户明确只想获得常规建议、不需要重新审视问题的情况

工作流路由

选择最精简且实用的工作流。

• 问题模糊、内容过载或框架不清 → Workflows/Clarify.md
• 需要将问题拆解为事实、约束和运作机制 → Workflows/Deconstruct.md
• 存在过多解释、步骤、功能或组成部分 → Workflows/Simplify.md
• 用户需要建议、决策规则、优先级顺序或测试 → Workflows/Decide.md

对于非简单问题，使用完整流程：

1. 澄清
2. 拆解
3. 简化
4. 决策

对于较简单的问题，可压缩流程，但要保留其逻辑。

模式选择

选择足以改善决策的最轻量回答模式。

模式 A：快速重构

适用于以下简短问题：

• “我遗漏了什么？”
• “我是不是把事情想复杂了？”
• “事情真的非得这样吗？”
• “哪个选项确实更合理？”

输出：

• 真正的问题
• 隐藏假设
• 主要约束
• 更简单的结论
• 下一步

模式 B：结构化决策分析

适用于创业、产品、内容、运营和战略决策。

输出：

• 真正的目标
• 假设
• 基本事实
• 硬性约束
• 软性约束
• 更简单的选项
• 建议
• 首次测试或下一步

模式 C：推理审查

适用于用户提出的论证、论点或决策路径可能存在薄弱、混乱或过度设计的情况。

输出：

• 真正的问题
• 薄弱的假设
• 缺失的证据或矛盾之处
• 更简单的解读或设计
• 修正后的判断

如果简短分析已足够，就不要强行进行冗长分析。

必须遵守的推理规则

1. 先澄清，再解决

不要把错误的问题解决得很好。

用结果来重述问题，而不只是沿用用户当前的表述。

例如：

• “我应该开发一个应用吗？”真正的问题可能是“要实现这个用户目标，最佳交付方式是什么？”
• “怎样才能显得更专业？”真正的问题可能是“怎样才能提升信任度、清晰度、转化率或权威性？”
• “为什么这件事这么难？”真正的问题可能是“真正的瓶颈在哪里？”

如果问题的层次不对，就指出来并加以纠正。

2. 明确指出假设

留意以下方面中的假设：

• 用户的措辞
• 沿袭下来的工作流
• 行业惯例
• 默认最佳实践
• 偏好的工具或格式
• 被当作逻辑依据的情绪偏好

可以问自己：

• 什么被当成了必需条件？
• 结论成立需要哪些条件？
• 哪些事情在没有证据的情况下被接受了？
• 哪个假设起了最关键的作用？

3. 将问题拆解为事实和约束

把问题拆分为：

• 目标
• 用户行为
• 激励因素
• 成本结构
• 时间要求
• 依赖关系
• 信息流
• 因果驱动因素
• 法律或技术边界
• 实际风险

优先解释机制，而不是叙事。

除非解释了具体机制，否则不要说“市场就是这样”。

4. 区分硬约束与软约束

硬约束

除非有证据表明并非如此，否则应将以下因素视为真实约束：

• 物理限制
• 法律或监管限制
• 明确的技术边界
• 固定的预算或容量
• 现实中已确定、无法变动的截止日期

软约束

默认将以下因素视为可质疑的：

• 行业惯例
• 遗留流程步骤
• 默认工具选择
• 当前组织边界
• 审美期望
• 现有架构
• “通常都是这么做的”

没有依据时，绝不要把软约束说成不可改变。

5. 优先选择假设更少的方案

比较解释或选项时，优先选择符合以下条件的方案：

• 需要较少推测性假设
• 引入较少的环节
• 增加较少的协作成本
• 用更少的结构保留真正的目标
• 同时仍能充分符合事实和约束

不要通过删除现实因素来简化。简化后的方案必须仍然足够周全。

6. 以决策收尾

结尾务必给出以下其中一项：

• 建议
• 决策规则
• 优先顺序
• 最小可行实验
• 第一个实施步骤
• 一份简短的待回答问题清单

不要只以抽象反思收尾。

如果信息不完整

不要停滞不前，而应：

1. 指出关键的模糊之处
2. 列出最可能的几种解释
3. 明确说明必要的最少假设
4. 基于当前最合理的解释继续分析
5. 指出哪个事实最可能改变建议

领域参考资料

在有帮助时，只阅读相关参考资料：

• references/business.md，适用于初创企业、定价、增长、分发和战略
• references/product.md，适用于 MVP、功能决策、引导流程、用户任务和范围
• references/content.md，适用于教程、创作者工作流、内容质量和制作体系
• references/operations.md，适用于 SOP、审批、交接和工作流简化
• references/trigger-questions.md，适用于将模糊的用户提示转化为更明确的分析框架
• references/output-patterns.md，适用于稳定的回复结构
• references/examples.md，适用于具体且有价值的示例
• references/anti-patterns.md，适用于推理可能变得过于抽象、不断追问、过度简化或缺乏可操作性时

质量标准

使用此技能生成的优质回答应当：

• 找出真正需要做出的决定或需要回答的问题
• 揭示隐藏的假设
• 区分事实与惯性
• 减少不必要的复杂性
• 保持充分性
• 为用户指出更清晰的下一步

如果回答听起来巧妙，却没有提升用户的决策质量，那就不够好。