FirstPrinciples

自定义

执行前，请检查以下位置的用户自定义设置： ~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/FirstPrinciples/

如果此目录存在，请加载并应用其中找到的任何 PREFERENCES.md、配置或资源。这些设置优先于默认行为。如果此目录不存在，则使用技能默认设置。

🚨 强制要求：语音通知（执行任何操作前必须完成）

调用此技能后，在进行任何其他操作之前，必须发送此通知。

1. 发送语音通知：

   curl -s -X POST http://localhost:31337/notify \
     -H "Content-Type: application/json" \
     -d '{"message": "Running the WORKFLOWNAME workflow in the FirstPrinciples skill to ACTION"}' \
     > /dev/null 2>&1 &
   

2. 输出文本通知：

   Running the **WorkflowName** workflow in the **FirstPrinciples** skill to ACTION...
   

此步骤不可省略。调用技能后，必须立即执行此 curl 命令。

FirstPrinciples 技能

功能

将问题拆解为基本事实，并据此重建解决方案，而不是照搬现有做法。分为三步：解构（DECONSTRUCT）：拆分为组成部分和实际价值；质疑（CHALLENGE）：将每个要素归类为硬性约束、软性约束或未经验证的假设——只有物理定律才是真正不可改变的；重建（RECONSTRUCT）：仅从基本原理出发构建最优解决方案。输出包括组成部分拆解、约束表和重建后的解决方案。

核心区别

大多数推理都是类比推理——“我们以前如何解决类似问题”“其他人怎么做”——然后照搬并稍作修改。这会继承他人的所有假设，并把政策和惯例当作物理定律，因此你只是在优化行李箱，而不是发明车轮。FirstPrinciples 会迫使我们区分真正不可改变的因素与仅仅沿袭下来的因素，然后仅根据无法改变的部分重新构建。

• 类比推理（默认方式，且常常有误）：复制现有解决方案并稍作变化。
• 基于第一性原理的推理（此技能）：追问“它实际上由什么构成？”，并从不可再简化的事实出发重建。

可直接调用；当继承的假设可能限制解决方案空间时，其他技能也会调用它——例如，架构师会质疑“这是约束还是惯例？”，红队和渗透测试人员会攻击假定的边界，工程师则会尝试摆脱局部最优。

工作流路由

根据请求路由至适当的工作流。

执行工作流时，直接输出此通知：

Running the **WorkflowName** workflow in the **FirstPrinciples** skill to ACTION...

• 将问题拆解为基本组成部分 → Workflows/Deconstruct.md
• 系统地质疑假设 → Workflows/Challenge.md
• 从基本原理出发重建解决方案 → Workflows/Reconstruct.md

约束分类

分析任何系统时，请对约束进行分类：

类型	定义	示例	可更改？
硬性约束	物理定律／现实	“数据无法以超过光速的速度传输”	否
软性约束	政策／选择	“我们一直使用 REST API”	是
假设	未经验证的看法	“用户不会接受这种用户体验”	可能是错误的

规则：只有硬性约束才是真正不可改变的。应当质疑软性约束和假设。

集成模式

其他技能按如下方式调用 FirstPrinciples：

## Before Analysis
→ Use FirstPrinciples/Challenge on all stated constraints
→ Classify each as hard/soft/assumption

## When Stuck
→ Use FirstPrinciples/Deconstruct to break down the problem
→ Use FirstPrinciples/Reconstruct to rebuild from fundamentals

## For Adversarial Analysis
→ RedTeam uses FirstPrinciples/Challenge to attack assumptions
→ Pentester uses FirstPrinciples/Deconstruct on security model

示例

问题：“云托管每月要花 10,000 美元——成本就是这么高。”

• 解构：我们实际付费购买的是什么？（计算、存储、带宽、托管服务）
• 质疑：托管 Kubernetes 是硬性要求吗？必须使用这个区域吗？10,000 美元是市场价格，而非基本成本。
• 重建：实际计算需求 = 2,000 美元。其余 8,000 美元是我们选择付费购买的便利性。

输出格式

使用 FirstPrinciples 时，输出应包含：

## First Principles Analysis: [Topic]

### Deconstruction
- **Constituent Parts**: [List fundamental elements]
- **Actual Values**: [Real costs/metrics, not market prices]

### Constraint Classification
| Constraint | Type | Evidence | Challenge |
|------------|------|----------|-----------|
| [X] | Hard/Soft/Assumption | [Why] | [What if removed?] |

### Reconstruction
- **Fundamental Truths**: [Only the hard constraints]
- **Optimal Solution**: [Built from fundamentals]
- **Form vs Function**: [Are we optimizing the right thing?]

### Key Insight
[One sentence: what assumption was limiting us?]

承重规则

• 市场价格和行业最佳实践并非基本真理。“电池成本为 $600/kWh”或“托管费用为 $10K/mo”都是惯例，不是物理定律——在接受之前，应先拆解到材料／算力成本。
• 重功能，不重形式——关注你想实现的目标，而不是传统做法（改进车轮，而不是打磨手提箱）。
• 重建，而非修补——假设错了，就从硬性约束入手，而不是修补继承下来的形式。来自无关领域的跨领域解决方案往往也适用。

---

出处：本框架源自 Elon Musk 的第一性原理方法论，相关内容由 James Clear、Mayo Oshin 记录，并见于公开访谈。

注意事项

• 分解到公理——基本真理，而不仅仅是更简单的组成部分。 价值在于找到不可再分的要素。
• 具体质疑继承下来的假设。 有哪些人人都相信、却可能是错的假设？
• 这是分析／推理，不是执行。“Analyze” = FirstPrinciples。“Fix” = 直接动手解决。

执行日志

完成任何工作流后，都追加一条 JSONL 记录：

echo '{"ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","skill":"FirstPrinciples","workflow":"WORKFLOW_USED","input":"8_WORD_SUMMARY","status":"ok|error","duration_s":SECONDS}' >> ~/.claude/LIFEOS/MEMORY/SKILLS/execution.jsonl

将 WORKFLOW_USED 替换为执行的工作流，将 8_WORD_SUMMARY 替换为对输入的简短描述，并将 SECONDS 替换为大致的实际耗时。如果工作流失败，则记录 status: "error"。