mcpField
M
moai-foundation-philosopher

moai-foundation-philosopher

github.com/modu-aiAgent 工作流1.2k70 次安装今天更新
代码仓库

关于 moai-foundation-philosopher

供 MoAI Agent 和团队处理复杂技术决策的思考框架。五个阶段涵盖假设审查、第一性原理分析、方案生成、权衡比较和认知偏差检查。

主要功能

  1. 01五阶段决策流程
  2. 02假设审查
  3. 03根因分析
  4. 04生成备选方案
  5. 05结构化权衡评分
  6. 06认知偏差检查

适用场景

  1. 01评估技术选型
  2. 02规划架构变更
  3. 03确定重构范围
  4. 04审视性能与可维护性的取舍

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/modu-ai/moai-adk --skill moai-foundation-philosopher

安装后在 Claude Code 中输入/moai-foundation-philosopher确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

modules/
assumption-matrix.md
cognitive-bias.md
first-principles.md
trade-off-analysis.md
references/
examples.md
reference.md

详细介绍

MoAI Foundation 哲学家

倡导深入分析而非快速计算的战略思维框架。整合三种经实践验证的方法,用于系统化解决问题。

核心理念:行动之前深入思考。质疑假设。考虑其他方案。明确权衡取舍。检查认知偏差。

快速参考(30 秒)

什么是哲学家框架?

一种用于复杂决策的结构化方法,结合了:

  • 第一性原理分析:将问题拆解为基本事实
  • Stanford 设计思维:发散式与收敛式方案生成
  • MIT 系统工程:系统化风险评估与验证

五阶段思维流程:

  1. 假设审查:揭示并质疑我们想当然的内容
  2. 第一性原理拆解:分解至根本原因
  3. 方案生成:创建多个解决方案
  4. 权衡分析:系统化比较方案
  5. 认知偏差检查:验证思维质量

启用时机:

  • 影响 5 个以上文件的架构决策
  • 技术选型(库、框架、数据库)
  • 性能与可维护性的权衡
  • 重构范围决策
  • 考虑是否引入不兼容变更
  • 任何具有重大长期影响的决策

快速访问:


实施指南(5 分钟)

阶段 1:假设审查

目的:揭示隐藏假设,避免其演变成盲点。

五个关键问题:

  • 我们有哪些假设是在没有证据的情况下被当成事实的?
  • 如果这个假设最终被证明是错误的,会怎样?
  • 这是硬性约束,还是仅仅是偏好?
  • 有什么证据支持这个假设?
  • 还应由谁来验证这个假设?

假设类别:

  • 技术假设:技术能力、性能特征、兼容性
  • 业务假设:用户行为、市场状况、预算可用性
  • 团队假设:技能水平、可用性、领域知识
  • 时间安排假设:交付预期、依赖项时间表

假设记录格式:

  • 假设陈述:清晰描述假设内容
  • 置信度:根据证据分为高、中或低
  • 证据依据:支持此假设的内容
  • 假设错误时的风险:假设被证明为假时的后果
  • 验证方法:承诺之前如何进行验证

原因:未经审视的假设是项目失败和返工的主要原因。 影响:及早揭示假设可避免 40%–60% 的项目中途转向。

阶段 2:第一性原理拆解

目的:拨开复杂性,找到根本原因和基本需求。

五个为什么技巧:

  • 表面问题:用户或系统观察到的现象
  • 第一个为什么:分析直接原因
  • 第二个为什么:调查潜在原因
  • 第三个为什么:识别系统性驱动因素
  • 第四个为什么:组织或流程因素
  • 第五个为什么(根本原因):需要解决的根本问题

约束分析:

  • 硬性约束:不可协商(安全、合规、物理定律、预算)
  • 软性约束:可协商的偏好(时间安排、功能范围、工具)
  • 自设约束:伪装成需求的假设
  • 自由度:可以采用创新方案的领域

拆解问题:

  • 此请求背后的实际目标是什么?
  • 我们真正要解决的是什么问题?
  • 如果没有任何约束,解决方案会是什么样?
  • 最小可行方案是什么?
  • 在仍能实现目标的前提下,我们可以舍弃什么?

原因:大多数问题都是在错误的抽象层次上解决的。 影响:第一性原理思维可将解决方案的复杂度降低 30%–50%。

第 3 阶段:生成备选方案

目的:避免过早收敛到次优方案。

生成规则:

  • 至少提出 3 个不同的备选方案
  • 至少包含一个非常规方案
  • 始终将“什么都不做”作为基准方案
  • 考虑短期和长期影响
  • 探索渐进式和变革式方案

备选方案类别:

  • 保守:低风险、渐进式改进、采用熟悉的技术
  • 平衡:中等风险、显著改进、包含一定创新
  • 激进:较高风险、变革性改动、采用尖端方案
  • 根本性:挑战基本假设、采用截然不同的方案

创造性技巧:

  • 逆向思考:怎样做会让这个问题变得更糟?现在反其道而行之。
  • 类比:其他领域如何解决类似问题?
  • 移除约束:如果预算、时间或技术不受限制,会怎样?
  • 简化:最简单可行的方案是什么?

原因:第一个想到的方案往往不是最佳方案。 影响:考虑 3 个以上的备选方案,可将决策质量提高 25%。

第 4 阶段:权衡分析

目的:明确并比较隐性的权衡。

标准评估标准:

  • 性能:速度、吞吐量、延迟、资源使用量
  • 可维护性:代码清晰度、文档、团队熟悉程度
  • 实施成本:开发时间、复杂度、学习曲线
  • 风险等级:技术风险、失败概率、回滚难度
  • 可扩展性:增长能力、灵活性、面向未来的能力
  • 安全性:漏洞暴露面、合规性、数据保护

加权评分法:

  • 根据项目优先级为各项标准分配权重(总计 100%)
  • 按每项标准为各个方案打 1–10 分
  • 计算加权综合得分
  • 记录各项评分的理由
  • 确定权重变化对得分的敏感程度

权衡记录:

  • 我们获得什么:所选方案的主要优势
  • 我们舍弃什么:明确接受的成本和局限
  • 为何可以接受:接受这些权衡的理由
  • 缓解计划:如何应对不利影响

原因:隐性的权衡会导致后悔和反复质疑。 影响:明确权衡可将利益相关者之间的共识提升 50%。

第 5 阶段:认知偏差检查

目的:检查常见的思维错误,确保建议的质量。

需要关注的主要偏差:

  • 锚定偏差:过度依赖最先接触到的信息
  • 确认偏差:只寻找支持既有信念的证据
  • 沉没成本谬误:因过去的投入而继续推进
  • 可得性启发:过度看重近期或令人难忘的事件
  • 过度自信偏差:对自己的判断过度确信

偏差检测问题:

  • 我是否因为最先想到这个方案而对它产生了依恋?
  • 我是否主动寻找了反对自己偏好的证据?
  • 如果从零开始、没有任何先前投入,我还会推荐这个方案吗?
  • 我是否受到了可能并不适用的近期经历的影响?
  • 什么因素会改变我对这个建议的看法?

缓解策略:

  • 事前验尸:设想决策失败了;出了什么问题?
  • 反方论证:提出反对自己建议的论据
  • 外部视角:基础概率对成功的可能性有何启示?
  • 寻求异议:咨询可能会挑战你的人
  • 反转测试:如果有人提出相反方案,你会怎么说?

原因:即使是专家,在时间压力下也会受到认知偏差的影响。 影响:检查偏差可避免 20–30% 的错误技术决策。


高级实施(10 分钟以上)

与 MoAI 工作流集成

SPEC 阶段集成:

  • 在 /moai:1-plan 期间执行假设审查
  • 在 spec.md 的 Problem Analysis 部分记录假设
  • 在 plan.md 中纳入考虑过的替代方案
  • 在 acceptance.md 中定义验证标准

DDD 阶段集成:

  • 使用第一性原理识别核心测试场景
  • 为遗留代码生成特征测试替代方案
  • 为新功能生成规格测试替代方案
  • 在测试覆盖率决策中应用权衡分析

质量阶段集成:

  • 在代码审查流程中纳入认知偏差检查
  • 验证实施后假设仍然有效
  • 在最终文档中记录已接受的权衡
时间分配指南

复杂决策的建议投入比例:

  • 假设审查:分析时间的 15%
  • 第一性原理分解:分析时间的 25%
  • 替代方案生成:分析时间的 20%
  • 权衡分析:分析时间的 25%
  • 认知偏差检查:分析时间的 15%

分析与实施的总时间比例:

  • 简单决策(1-2 个文件):10% 分析,90% 实施
  • 中等决策(3-10 个文件):25% 分析,75% 实施
  • 复杂决策(10 个以上文件):40% 分析,60% 实施
  • 架构决策:50% 分析,50% 实施
决策文档模板

战略决策记录:

Decision Title:对所做决策的清晰陈述

Context:做出此决策的原因

Examined Assumptions:

  • 假设 1,以及置信度和验证状态
  • 假设 2,以及置信度和验证状态

Root Cause Analysis:

  • 已识别的表面问题
  • 通过五个为什么确定的根本原因

Alternatives Considered:

  • 选项 A 及其优点、缺点和评分
  • 选项 B 及其优点、缺点和评分
  • 选项 C 及其优点、缺点和评分

Accepted Trade-offs:

  • 所选方案带来的收益
  • 我们放弃的内容及其可接受的原因

Bias Check Completed:

  • 确认已采取偏差缓解措施

Final Decision:所选选项及主要依据

Success Criteria:衡量决策是否正确的方式

Review Trigger:会导致重新考虑决策的条件


配合使用效果良好

Agent:

  • manager-strategy:SPEC 分析和规划的主要使用者
  • expert-backend:技术选型决策
  • expert-frontend:架构和框架选择
  • expert-database:架构设计权衡
  • manager-quality:代码审查偏差检查

技能:

  • moai-foundation-core:与 TRUST 5 和 SPEC 工作流集成
  • moai-workflow-spec:以 SPEC 格式记录假设
  • moai-domain-backend:特定技术的权衡标准
  • moai-domain-frontend:UI/UX 决策框架

命令:

  • /moai:1-plan:在规格制定期间应用哲学家框架
  • /moai:2-run:在实施期间参考已记录的权衡

快速决策矩阵

各阶段的适用场景:

简单 Bug 修复:跳过 Philosopher(直接实施) 添加功能:阶段 1、3、4(假设、替代方案、权衡) 重构:阶段 1、2、4(假设、根本原因、权衡) 技术选型:全部 5 个阶段(需要完整分析) 架构变更:全部 5 个阶段,并扩展文档

模块深入解析:

示例:examples.md 外部资源:reference.md

来源:受 Claude Code Philosopher Ignition 框架启发

评论

支持 Markdown