name: reasoning-dialectical description: 通过结构化的正题-反题-合题过程综合对立立场。当利益相关者意见分歧、存在权衡取舍或多个有效视角需要整合时使用。生成带有明确权衡的综合立场。
辩证推理
将对立观点综合为更高层次的解决方案。富有成效的异议逻辑。
类型签名
辩证推理 : 正题 → 反题 → 合题
其中:
正题 : 立场 × 证据 × 利益相关者 → 论证A
反题 : 论证A → 对立立场 × 证据 × 利益相关者 → 论证B
合题 : (论证A, 论证B) → 综合立场 × 权衡取舍
使用时机
在以下情况使用辩证推理:
- 利益相关者持有对立但有效的立场
- 需要明确分析权衡取舍
- 战略张力需要解决
- 多个视角各有其价值
- "一方面…另一方面…"的情况
不要在以下情况使用:
- 需要因果链 → 使用因果推理
- 解释观察现象 → 使用溯因推理
- 评估过去决策 → 使用反事实推理
核心原则
善意解读
每个立场必须以最强形式呈现:
- 强化论证，而非曲解论证
- 假设善意和有效推理
- 识别每个观点中的合理内核
真正综合
合题不是:
- 妥协（折中处理）
- 胜利（一方胜出）
- 回避（推迟决策）
合题是:
- 在更高抽象层次上的整合
- 解决根本关切的解决方案
- 超越原始框架的新立场
三阶段流程
阶段1：正题
目的: 以最大强度阐述第一个立场。
组成部分:
正题:
立场:
陈述: "提出的核心主张"
根本关切: "这个立场真正关注的是什么"
利益相关者:
谁: "持有此观点的人/团队"
角色: "他们的组织职能"
激励: "他们优化什么"
证据:
支持:
- 主张: "证据点"
来源: "来源"
强度: 0.0-1.0
实证: [数据点]
逻辑: [论证]
影响:
若采纳: "如果走这条路会发生什么"
风险: [风险]
收益: [收益]
示例:
正题:
立场:
陈述: "我们应该优先企业功能而非SMB增长"
根本关切: "收入集中度和交易规模效率"
利益相关者:
谁: "销售领导层"
角色: "收入生成"
激励: "ARR、交易规模、配额达成"
证据:
支持:
- 主张: "企业交易平均40万美元 vs SMB 5千美元"
来源: "Q3销售数据"
强度: 0.95
- 主张: "企业每美元收入的销售成本低5倍"
来源: "CAC分析"
强度: 0.85
实证:
- "3个企业交易 = 全部SMB收入"
- "企业流失率3% vs SMB 8%"
影响:
若采纳: "集中工程资源于企业功能，减少SMB投资"
风险:
- "将SMB市场输给竞争对手"
- "收入集中风险"
收益:
- "更高利润率"
- "更大平均交易规模"
阶段2：反题
目的: 以最大强度阐述对立立场。
流程:
- 识别正题遗漏或低估的内容
- 找到持有对立观点的利益相关者
- 为替代方案构建最强论证
- 识别正题假设的缺陷
组成部分:
反题:
立场:
陈述: "对立主张"
根本关切: "这个立场真正关注的是什么"
利益相关者:
谁: "持有此观点的人/团队"
角色: "他们的组织职能"
激励: "他们优化什么"
对正题的批判:
- 挑战的假设: "正题假设X"
反证: "但实际上Y"
- 识别的风险: "正题忽略了Z"
证据:
支持: [证据点]
实证: [数据点]
逻辑: [论证]
影响:
若采纳: "如果走这条路会发生什么"
风险: [风险]
收益: [收益]
示例:
反题:
立场:
陈述: "SMB数量为可持续增长奠定基础"
根本关切: "市场存在、产品迭代和风险分散"
利益相关者:
谁: "产品领导层"
角色: "产品市场匹配和增长"
激励: "使用率、留存率、功能验证"
对正题的批判:
- 挑战的假设: "企业功能驱动增长"
反证: "SMB使用产生产品洞察的速度快10倍"
- 挑战的假设: "收入集中是可接受的"
反证: "失去1个企业交易 = 失去80个SMB账户"
- 识别的风险: "企业销售周期为9个月"
证据:
支持:
- 主张: "SMB账户产生80%的功能请求"
来源: "产品反馈分析"
强度: 0.90
- 主张: "SMB提供更快的迭代周期"
来源: "发布指标"
强度: 0.85
实证:
- "SMB流失预测准确率95% vs 企业60%"
- "来自SMB反馈的产品改进在2周内发布"
影响:
若采纳: "维持SMB投资，将其作为产品实验室"
风险:
- "短期收入增长较慢"
- "整体利润率较低"
收益:
- "多元化的收入基础"
- "更快的产品迭代"
- "更低的集中风险"
阶段3：合题
目的: 在更高层次整合立场，解决根本张力。
合题方法:
| 方法 | 使用时机 | 示例 |
|---|---|---|
| 整合 | 两个立场都解决有效关切 | “企业收入 + SMB作为产品实验室” |
| 排序 | 时间上的解决方案可行 | “先SMB实现PMF，然后企业规模化” |
| 细分 | 不同情境需要不同方法 | “产品X针对SMB，产品Y针对企业” |
| 重构 | 原始二分法是错误的 | “真正的问题不是SMB vs 企业，而是价值实现时间” |
| 超越 | 更高目标包含两者 | “优化可持续的单位经济，无论细分市场” |
合题组成部分:
合题:
综合立场:
陈述: "我们实际将做什么"
框架: "这如何解决张力"
正题如何解决:
确认的关切: "正题中正确的部分"
如何纳入: "我们如何解决该关切"
反题如何解决:
确认的关切: "反题中正确的部分"
如何纳入: "我们如何解决该关切"
承认的权衡:
- 权衡: "我们放弃什么"
缓解措施: "我们如何减少影响"
接受者: "接受此点的利益相关者"
解决类型: 整合 | 排序 | 细分 | 重构 | 超越
实施:
行动: [行动]
指标: [指标] # 如何知道它有效
审查日期: 日期 # 何时重新评估
示例:
合题:
综合立场:
陈述: "SMB作为快速学习引擎，企业作为收入引擎，
具有明确的功能升级路径"
框架: "不是SMB vs 企业，而是学习速度 vs 收入效率，
并在两者之间建立桥梁"
正题如何解决:
确认的关切: "企业交易每美元效率更高"
如何纳入: "维持企业销售流程，优先考虑通过SMB验证的企业功能"
反题如何解决:
确认的关切: "SMB产生更快的产品学习"
如何纳入: "保护SMB投资作为产品实验室，使用SMB指标
来优先考虑企业功能"
承认的权衡:
- 权衡: "某些仅企业功能将发布较慢"
缓解措施: "识别'必须拥有'的企业功能，快速推进这些"
接受者: "销售领导层（附快速推进清单）"
- 权衡: "某些SMB功能不会升级到企业"
缓解措施: "预先定义明确的升级标准"
接受者: "产品领导层（附标准协议）"
解决类型: 整合
实施:
行动:
- "定义功能升级标准（产品+销售）"
- "创建SMB → 企业功能管道"
- "分配60%工程资源给升级功能，40%给SMB实验室"
指标:
- "SMB功能升级率（目标：3个/月）"
- "升级功能的企业成交率（目标：+20%）"
- "综合收入增长（目标：30% 季度环比）"
审查日期: "Q2末"
质量门控
| 门控 | 要求 | 失败处理 |
|---|---|---|
| 正题强度 | 强化论证、证据支持 | 在继续前加强 |
| 反题真实性 | 非曲解论证、不同利益相关者 | 找到真正的对立面 |
| 合题整合性 | 非妥协或胜利 | 重构直到真正综合 |
| 权衡明确性 | 所有方承认成本 | 揭示隐藏分歧 |
| 可操作性 | 具体后续步骤 | 添加实施细节 |
利益相关者协议协议
合题在受影响利益相关者承认以下内容前不完整：
- 他们的关切被理解（正题/反题准确呈现）
- 合题解决他们的核心利益（不仅仅是他们的陈述立场）
- 他们接受权衡（明确地，而非假设）
利益相关者确认:
正题利益相关者:
名称: "销售领导层"
关切被理解: true
合题解决关切: true
接受权衡: true
条件: "关键企业功能的快速推进清单"
反题利益相关者:
名称: "产品领导层"
关切被理解: true
合题解决关切: true
接受权衡: true
条件: "实施前明确的升级标准"
常见失败模式
| 失败 | 症状 | 修复 |
|---|---|---|
| 虚假二分法 | 立场并非真正对立 | 重构实际张力 |
| 曲解论证 | 一方呈现薄弱 | 涉及实际利益相关者 |
| 模糊中间 | 合题只是"两者都做" | 强制资源分配 |
| 未承认损失 | 权衡被隐藏 | 揭示放弃的内容 |
| 无实施 | 合题抽象 | 添加具体行动 |
输出契约
辩证推理输出:
正题:
立场: 字符串
利益相关者: 字符串
证据: [证据点]
强度: 浮点数 # 0.0-1.0
反题:
立场: 字符串
利益相关者: 字符串
证据: [证据点]
强度: 浮点数
合题:
立场: 字符串
解决类型: 字符串
置信度: 浮点数
整合:
正题已解决: 字符串
反题已解决: 字符串
权衡:
- 权衡: 字符串
缓解措施: 字符串
接受者: 字符串
利益相关者协议:
- 利益相关者: 字符串
同意: 布尔值
条件: 可选<字符串>
实施:
行动: [字符串]
指标: [字符串]
审查日期: 日期
下一步:
建议模式: 推理模式 # 通常是因果推理
画布更新: [字符串]
追踪:
持续时间_毫秒: 整数
优化轮次: 整数
示例执行
背景: “工程团队希望重建核心平台（6个月）。销售团队需要Q2交易的新功能。”
阶段1 - 正题（工程）:
立场: "技术债务正在阻碍速度。现在重建或以后支付10倍代价。"
证据:
- 部署时间同比增长300%
- 40%的冲刺时间用于变通方案
- 3个关键bug来自架构问题
根本关切: 可持续的开发速度
阶段2 - 反题（销售）:
立场: "我们有200万美元的管道依赖于Q2功能。延迟 = 失去交易。"
证据:
- 5个企业交易等待特定功能
- 竞争对手在3月推出类似功能
- 没有新能力，Q2配额面临风险
根本关切: 收入目标达成
阶段3 - 合题:
综合立场: "绞杀者模式 - 在交付高优先级功能的同时增量重建"
正题如何解决: 平台重建发生，但与功能一起模块化进行
反题如何解决: Q2功能交付，无延迟
权衡:
- 重建需要9个月而非6个月（工程接受）
- Q2仅交付前3个功能，而非全部5个（销售在优先排序输入下接受）
解决类型: 通过排序整合
实施:
- 第1周: 联合优先排序会议（前3个功能 + 第一个重建模块）
- Q2: 尽可能在新模块上交付功能
- Q3-Q4: 在功能交付持续的情况下完成重建