Back to Details

moai-foundation-philosopher

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

MoAI Foundation Philosopher

MoAI Foundation Philosopher

Strategic thinking framework that promotes deeper analysis over quick calculations. Integrates three proven methodologies for systematic problem-solving.
Core Philosophy: Think deeply before acting. Question assumptions. Consider alternatives. Make trade-offs explicit. Check for cognitive biases.
一种倡导深度分析而非快速计算的战略思考框架。整合三种经过验证的方法论，实现系统性问题解决。
核心理念：行动前深度思考。质疑假设。考量替代方案。明确权衡取舍。检查认知偏差。

Quick Reference (30 seconds)

快速参考（30秒）

What is the Philosopher Framework?
A structured approach to complex decisions combining:
  • First Principles Analysis: Break problems to fundamental truths
  • Stanford Design Thinking: Divergent-convergent solution generation
  • MIT Systems Engineering: Systematic risk assessment and validation
Five-Phase Thinking Process:
  1. Assumption Audit: Surface and question what we take for granted
  2. First Principles Decomposition: Break down to root causes
  3. Alternative Generation: Create multiple solution options
  4. Trade-off Analysis: Compare options systematically
  5. Cognitive Bias Check: Verify thinking quality
When to Activate:
  • Architecture decisions affecting 5+ files
  • Technology selection (library, framework, database)
  • Performance vs maintainability trade-offs
  • Refactoring scope decisions
  • Breaking changes consideration
  • Any decision with significant long-term impact
Quick Access:
  • Assumption questioning techniques: Assumption Matrix Module
  • Root cause analysis: First Principles Module
  • Option comparison: Trade-off Analysis Module
  • Bias prevention: Cognitive Bias Module
什么是Philosopher框架？
一种针对复杂决策的结构化方法，整合了：
  • First Principles Analysis：将问题拆解至基本事实
  • Stanford Design Thinking：发散-收敛式解决方案生成
  • MIT Systems Engineering：系统性风险评估与验证
五阶段思考流程：
  1. 假设审核：挖掘并质疑我们想当然的前提
  2. First Principles Decomposition：拆解至根本原因
  3. 替代方案生成：创建多种解决方案选项
  4. 权衡分析：系统性比较各选项
  5. 认知偏差检查：验证思考质量
激活场景：
  • 影响5个以上文件的架构决策
  • 技术选型（库、框架、数据库）
  • 性能与可维护性的权衡
  • 重构范围决策
  • 重大变更考量
  • 任何具有显著长期影响的决策
快速入口：
  • 假设质疑技巧：Assumption Matrix Module
  • 根本原因分析：First Principles Module
  • 选项比较：Trade-off Analysis Module
  • 偏差预防：Cognitive Bias Module

Implementation Guide (5 minutes)

实施指南（5分钟）

Phase 1: Assumption Audit

阶段1：假设审核

Purpose: Surface hidden assumptions before they become blind spots.
Five Critical Questions:
  • What are we assuming to be true without evidence?
  • What if this assumption turns out to be wrong?
  • Is this a hard constraint or merely a preference?
  • What evidence supports this assumption?
  • Who else should validate this assumption?
Assumption Categories:
  • Technical Assumptions: Technology capabilities, performance characteristics, compatibility
  • Business Assumptions: User behavior, market conditions, budget availability
  • Team Assumptions: Skill levels, availability, domain knowledge
  • Timeline Assumptions: Delivery expectations, dependency schedules
Assumption Documentation Format:
  • Assumption statement: Clear description of what is assumed
  • Confidence level: High, Medium, or Low based on evidence
  • Evidence basis: What supports this assumption
  • Risk if wrong: Consequence if assumption proves false
  • Validation method: How to verify before committing
WHY: Unexamined assumptions are the leading cause of project failures and rework. IMPACT: Surfacing assumptions early prevents 40-60% of mid-project pivots.
目的：在隐藏假设成为盲区前将其挖掘出来。
五个关键问题：
  • 我们在没有证据的情况下假设哪些是真实的？
  • 如果这个假设被证明是错误的会怎样？
  • 这是硬性约束还是仅仅是偏好？
  • 有哪些证据支持这个假设？
  • 还需要谁来验证这个假设？
假设分类：
  • 技术假设：技术能力、性能特征、兼容性
  • 业务假设：用户行为、市场状况、预算可用性
  • 团队假设：技能水平、可用性、领域知识
  • 时间线假设：交付预期、依赖进度
假设文档格式：
  • 假设陈述：清晰描述所假设的内容
  • 置信度：基于证据分为高、中、低
  • 证据基础：支持该假设的依据
  • 错误风险：假设被证明为假时的后果
  • 验证方法：在投入前如何验证
原因：未经审视的假设是项目失败和返工的主要原因。 影响：提前挖掘假设可避免40-60%的项目中期转向。

Phase 2: First Principles Decomposition

阶段2：First Principles Decomposition

Purpose: Cut through complexity to find root causes and fundamental requirements.
The Five Whys Technique:
  • Surface Problem: What the user or system observes
  • First Why: Immediate cause analysis
  • Second Why: Underlying cause investigation
  • Third Why: Systemic driver identification
  • Fourth Why: Organizational or process factor
  • Fifth Why (Root Cause): Fundamental issue to adddess
Constraint Analysis:
  • Hard Constraints: Non-negotiable (security, compliance, physics, budget)
  • Soft Constraints: Negotiable preferences (timeline, feature scope, tooling)
  • Self-Imposed Constraints: Assumptions disguised as requirements
  • Degrees of Freedom: Areas where creative solutions are possible
Decomposition Questions:
  • What is the actual goal behind this request?
  • What problem are we really trying to solve?
  • What would a solution look like if we had no constraints?
  • What is the minimum viable solution?
  • What can we eliminate while still achieving the goal?
WHY: Most problems are solved at the wrong level of abstraction. IMPACT: First principles thinking reduces solution complexity by 30-50%.
目的：穿透复杂性，找到根本原因和基本需求。
五问法：
  • 表面问题：用户或系统观察到的现象
  • 第一问：直接原因分析
  • 第二问：潜在原因调查
  • 第三问：系统性驱动因素识别
  • 第四问：组织或流程因素
  • 第五问（根本原因）：需要解决的核心问题
约束分析：
  • 硬性约束：不可协商（安全、合规、物理限制、预算）
  • 软性约束：可协商的偏好（时间线、功能范围、工具选择）
  • 自我施加约束：伪装成需求的假设
  • 自由度：可提出创造性解决方案的领域
拆解问题：
  • 这个请求背后的实际目标是什么？
  • 我们真正要解决的问题是什么？
  • 如果没有任何约束，解决方案会是什么样子？
  • 最小可行解决方案是什么？
  • 在仍能实现目标的前提下，我们可以剔除哪些内容？
原因：大多数问题都在错误的抽象层面得到解决。 影响：第一性原理思考可将解决方案复杂度降低30-50%。

Phase 3: Alternative Generation

阶段3：替代方案生成

Purpose: Avoid premature convergence on suboptimal solutions.
Generation Rules:
  • Minimum three distinct alternatives required
  • Include at least one unconventional option
  • Always include "do nothing" as baseline
  • Consider short-term vs long-term implications
  • Explore both incremental and transformative approaches
Alternative Categories:
  • Conservative: Low risk, incremental improvement, familiar technology
  • Balanced: Moderate risk, significant improvement, some innovation
  • Aggressive: Higher risk, transformative change, cutting-edge approach
  • Radical: Challenge fundamental assumptions, completely different approach
Creativity Techniques:
  • Inversion: What would make this problem worse? Now do the opposite.
  • Analogy: How do other domains solve similar problems?
  • Constraint Removal: What if budget, time, or technology were unlimited?
  • Simplification: What is the simplest possible solution?
WHY: The first solution is rarely the best solution. IMPACT: Considering 3+ alternatives improves decision quality by 25%.
目的：避免过早收敛于次优解决方案。
生成规则：
  • 至少需要三个不同的替代方案
  • 包含至少一个非常规选项
  • 始终将“不采取任何行动”作为基准线
  • 考量短期与长期影响
  • 探索增量式与变革式方法
替代方案分类：
  • 保守型：低风险、增量改进、熟悉的技术
  • 平衡型：中等风险、显著改进、一定创新
  • 激进型：较高风险、变革性改变、前沿方法
  • 彻底型：挑战基本假设、完全不同的方法
创意技巧：
  • 反转法：什么会让这个问题变得更糟？现在做相反的事。
  • 类比法：其他领域如何解决类似问题？
  • 约束移除：如果预算、时间或技术不受限制会怎样？
  • 简化法：最简单的解决方案是什么？
原因：第一个解决方案很少是最佳方案。 影响：考量3个以上替代方案可将决策质量提升25%。

Phase 4: Trade-off Analysis

阶段4：权衡分析

Purpose: Make implicit trade-offs explicit and comparable.
Standard Evaluation Criteria:
  • Performance: Speed, throughput, latency, resource usage
  • Maintainability: Code clarity, documentation, team familiarity
  • Implementation Cost: Development time, complexity, learning curve
  • Risk Level: Technical risk, failure probability, rollback difficulty
  • Scalability: Growth capacity, flexibility, future-proofing
  • Security: Vulnerability surface, compliance, data protection
Weighted Scoring Method:
  • Assign weights to criteria based on project priorities (total 100%)
  • Rate each option 1-10 on each criterion
  • Calculate weighted composite score
  • Document reasoning for each score
  • Identify score sensitivity to weight changes
Trade-off Documentation:
  • What we gain: Primary benefits of chosen approach
  • What we sacrifice: Explicit costs and limitations accepted
  • Why acceptable: Rationale for accepting these trade-offs
  • Mitigation plan: How to adddess downsides
WHY: Implicit trade-offs lead to regret and second-guessing. IMPACT: Explicit trade-offs improve stakeholder alignment by 50%.
目的：将隐性的权衡取舍明确化并进行比较。
标准评估标准：
  • 性能：速度、吞吐量、延迟、资源使用
  • 可维护性：代码清晰度、文档、团队熟悉度
  • 实施成本：开发时间、复杂度、学习曲线
  • 风险等级：技术风险、失败概率、回滚难度
  • 可扩展性：增长能力、灵活性、前瞻性
  • 安全性：漏洞面、合规性、数据保护
加权评分法：
  • 根据项目优先级为各标准分配权重（总计100%）
  • 为每个选项在各标准上评分1-10分
  • 计算加权综合得分
  • 记录每个得分的理由
  • 识别得分对权重变化的敏感性
权衡文档：
  • 我们获得的：所选方法的主要收益
  • 我们牺牲的：明确接受的成本与限制
  • 为何可接受：接受这些权衡的理由
  • 缓解计划：如何解决弊端
原因：隐性的权衡取舍会导致后悔和反复质疑。 影响：明确的权衡取舍可将利益相关者的一致性提升50%。

Phase 5: Cognitive Bias Check

阶段5：认知偏差检查

Purpose: Ensure recommendation quality by checking for common thinking errors.
Primary Biases to Monitor:
  • Anchoring Bias: Over-reliance on first information encountered
  • Confirmation Bias: Seeking evidence that supports existing beliefs
  • Sunk Cost Fallacy: Continuing due to past investment
  • Availability Heuristic: Overweighting recent or memorable events
  • Overconfidence Bias: Excessive certainty in own judgment
Bias Detection Questions:
  • Am I attached to this solution because I thought of it first?
  • Have I actively sought evidence against my preference?
  • Would I recommend this if starting fresh with no prior investment?
  • Am I being influenced by recent experiences that may not apply?
  • What would change my mind about this recommendation?
Mitigation Strategies:
  • Pre-mortem: Imagine the decision failed; what went wrong?
  • Devil's advocate: Argue against your own recommendation
  • Outside view: What do base rates suggest about success?
  • Disagreement seeking: Consult someone likely to challenge you
  • Reversal test: If the opposite were proposed, what would you say?
WHY: Even experts fall prey to cognitive biases under time pressure. IMPACT: Bias checking prevents 20-30% of flawed technical decisions.
目的：通过检查常见思维错误，确保建议质量。
需监控的主要偏差：
  • 锚定偏差：过度依赖最先接触到的信息
  • 确认偏差：寻找支持现有信念的证据
  • 沉没成本谬误：因过去的投入而继续坚持
  • 可得性启发法：过度重视近期或难忘的事件
  • 过度自信偏差：对自身判断过度确定
偏差检测问题：
  • 我是否因为自己最先想到这个解决方案而对其有所偏爱？
  • 我是否主动寻找过反对我偏好的证据？
  • 如果从零开始，没有过去的投入，我会推荐这个方案吗？
  • 我是否受到了可能不适用的近期经历的影响？
  • 什么会改变我对这个建议的看法？
缓解策略：
  • 事前验尸：想象决策失败了，哪里出了问题？
  • 魔鬼代言人：反驳自己的建议
  • 外部视角：基础比率对成功的预示是什么？
  • 寻求异议：咨询可能会挑战你的人
  • 反转测试：如果提出相反的方案，你会怎么说？
原因：即使是专家在时间压力下也会陷入认知偏差。 影响：偏差检查可避免20-30%的有缺陷技术决策。

Advanced Implementation (10+ minutes)

高级实施（10分钟以上）

Integration with MoAI Workflow

与MoAI Workflow的集成

SPEC Phase Integration:
  • Apply Assumption Audit during /moai:1-plan
  • Document assumptions in spec.md Problem Analysis section
  • Include alternative approaches considered in plan.md
  • Define validation criteria in acceptance.md
DDD Phase Integration:
  • Use First Principles to identify core test scenarios
  • Generate characterization test alternatives for legacy code
  • Generate specification test alternatives for new features
  • Apply Trade-off Analysis for test coverage decisions
Quality Phase Integration:
  • Include Cognitive Bias Check in code review process
  • Verify assumptions remain valid after implementation
  • Document trade-offs accepted in final documentation
SPEC阶段集成：
  • 在/moai:1-plan期间应用假设审核
  • 在spec.md的问题分析部分记录假设
  • 在plan.md中记录考量过的替代方法
  • 在acceptance.md中定义验证标准
DDD阶段集成：
  • 使用First Principles识别核心测试场景
  • 为遗留代码生成特征测试替代方案
  • 为新功能生成规范测试替代方案
  • 对测试覆盖决策应用权衡分析
质量阶段集成：
  • 在代码审查流程中加入认知偏差检查
  • 验证假设在实施后仍然有效
  • 在最终文档中记录接受的权衡取舍

Time Allocation Guidelines

时间分配指南

Recommended effort distribution for complex decisions:
  • Assumption Audit: 15% of analysis time
  • First Principles Decomposition: 25% of analysis time
  • Alternative Generation: 20% of analysis time
  • Trade-off Analysis: 25% of analysis time
  • Cognitive Bias Check: 15% of analysis time
Total Analysis vs Implementation:
  • Simple decisions (1-2 files): 10% analysis, 90% implementation
  • Medium decisions (3-10 files): 25% analysis, 75% implementation
  • Complex decisions (10+ files): 40% analysis, 60% implementation
  • Architecture decisions: 50% analysis, 50% implementation
复杂决策的建议精力分配：
  • 假设审核：分析时间的15%
  • First Principles Decomposition：分析时间的25%
  • 替代方案生成：分析时间的20%
  • 权衡分析：分析时间的25%
  • 认知偏差检查：分析时间的15%
总分析与实施占比：
  • 简单决策（1-2个文件）：10%分析，90%实施
  • 中等决策（3-10个文件）：25%分析，75%实施
  • 复杂决策（10个以上文件）：40%分析，60%实施
  • 架构决策：50%分析，50%实施

Decision Documentation Template

决策文档模板

Strategic Decision Record:
Decision Title: Clear statement of what was decided
Context: Why this decision was needed
Assumptions Examined:
  • Assumption 1 with confidence and validation status
  • Assumption 2 with confidence and validation status
Root Cause Analysis:
  • Surface problem identified
  • Root cause determined through Five Whys
Alternatives Considered:
  • Option A with pros, cons, and score
  • Option B with pros, cons, and score
  • Option C with pros, cons, and score
Trade-offs Accepted:
  • What we gain with chosen approach
  • What we sacrifice and why acceptable
Bias Check Completed:
  • Confirmation of bias mitigation steps taken
Final Decision: Selected option with primary rationale
Success Criteria: How we will measure if decision was correct
Review Trigger: Conditions that would cause reconsideration
战略决策记录：
决策标题：清晰说明所做的决策
背景：为何需要做出此决策
审核的假设：
  • 假设1，包含置信度与验证状态
  • 假设2，包含置信度与验证状态
根本原因分析：
  • 识别的表面问题
  • 通过五问法确定的根本原因
考量的替代方案：
  • 选项A，包含优缺点与得分
  • 选项B，包含优缺点与得分
  • 选项C，包含优缺点与得分
接受的权衡取舍：
  • 所选方法带来的收益
  • 我们牺牲的内容及可接受的原因
偏差检查完成情况：
  • 确认已采取偏差缓解步骤
最终决策：所选选项及主要理由
成功标准：我们将如何衡量决策是否正确
复审触发条件：会导致重新考量的情况

Works Well With

适配场景

Agents:
  • manager-strategy: Primary consumer for SPEC analysis and planning
  • expert-backend: Technology selection decisions
  • expert-frontend: Architecture and framework choices
  • expert-database: Schema design trade-offs
  • manager-quality: Code review bias checking
Skills:
  • moai-foundation-core: Integration with TRUST 5 and SPEC workflow
  • moai-workflow-spec: Assumption documentation in SPEC format
  • moai-domain-backend: Technology-specific trade-off criteria
  • moai-domain-frontend: UI/UX decision frameworks
Commands:
  • /moai:1-plan: Apply Philosopher Framework during specification
  • /moai:2-run: Reference documented trade-offs during implementation
Agents：
  • manager-strategy：SPEC分析与规划的主要使用者
  • expert-backend：技术选型决策
  • expert-frontend：架构与框架选择
  • expert-database： schema设计权衡
  • manager-quality：代码审查偏差检查
Skills：
  • moai-foundation-core：与TRUST 5和SPEC工作流集成
  • moai-workflow-spec：以SPEC格式记录假设
  • moai-domain-backend：特定技术的权衡标准
  • moai-domain-frontend：UI/UX决策框架
Commands：
  • /moai:1-plan：在规格制定阶段应用Philosopher框架
  • /moai:2-run：在实施阶段参考已记录的权衡取舍

Quick Decision Matrix

快速决策矩阵

When to use which phase:
Simple Bug Fix: Skip Philosopher (direct implementation) Feature Addition: Phases 1, 3, 4 (assumptions, alternatives, trade-offs) Refactoring: Phases 1, 2, 4 (assumptions, root cause, trade-offs) Technology Selection: All 5 phases (full analysis required) Architecture Change: All 5 phases with extended documentation
Module Deep Dives:
  • Assumption Matrix
  • First Principles
  • Trade-off Analysis
  • Cognitive Bias
Examples: examples.md External Resources: reference.md
Origin: Inspired by Claude Code Philosopher Ignition framework
何时使用哪个阶段：
简单Bug修复：跳过Philosopher（直接实施） 功能新增：阶段1、3、4（假设、替代方案、权衡） 重构：阶段1、2、4（假设、根本原因、权衡） 技术选型：全部5个阶段（需要完整分析） 架构变更：全部5个阶段并扩展文档
模块深度解析：
  • Assumption Matrix
  • First Principles
  • Trade-off Analysis
  • Cognitive Bias
示例：examples.md 外部资源：reference.md
起源：受Claude Code Philosopher Ignition框架启发