Files
ShowenV2/docs/FIRST_PRINCIPLES.md
showen becd200150 refactor: 整理项目文件夹结构 + 更新项目状态
- docs/: 团队流程文档 (10个md)
- .showen/: 管理状态文件 (CEO_BACKUP, RECOVERY, TEAM_CHAT, CEO_LOOP)
- 根目录只保留 README.md + PROGRESS.md
- 更新 RECOVERY.md/CEO_BACKUP.md/PROGRESS.md 反映自测机制完成
- 更新 souls/liu-jianguo.md 当前状态
2026-03-13 04:45:35 +08:00

412 lines
9.0 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# ShowenV2 第一性原理
## 核心理念
ShowenV2 公司和团队遵循**第一性原理**First Principles Thinking
> 回归事物最基本的条件,将其拆分成各要素进行解构分析,从而找到实现目标最优路径的方法。
---
## 什么是第一性原理
### 定义
- 不盲目遵循惯例和经验
- 不照搬别人的做法
- 回到问题的本质
- 从基本事实出发推导解决方案
### 对比
#### ❌ 类比思维Analogical Thinking
```
"别的公司都这样做" → 我们也这样做
"行业最佳实践" → 直接照搬
"大家都用这个技术" → 我们也用
```
#### ✅ 第一性原理First Principles
```
我们要解决什么问题?
→ 问题的本质是什么?
→ 有哪些基本约束条件?
→ 从基本事实出发,最优解是什么?
→ 验证方案是否真正解决问题
```
---
## 在 ShowenV2 的应用
### 1. 技术决策
#### 问题:选择什么技术栈?
**❌ 类比思维**
- "大家都用 Go我们也用 Go"
- "React 很流行,我们用 React"
**✅ 第一性原理**
```
问题本质:
- 需要高性能、低延迟的视频处理
- 需要跨平台支持Linux/macOS/Windows
- 需要系统级控制(硬件、网络)
- 团队需要能快速迭代
基本约束:
- ARM 嵌入式设备,资源有限
- 实时性要求高60fps
- 内存安全很重要
推导结论:
- Rust零成本抽象、内存安全、跨平台、高性能
- 不是因为"Rust 很酷",而是它最符合我们的需求
```
### 2. 架构设计
#### 问题:如何设计系统架构?
**❌ 类比思维**
- "微服务很流行,我们用微服务"
- "别人用 MVC我们也用 MVC"
**✅ 第一性原理**
```
问题本质:
- 需要支持多种功能视频、网络、BLE、HTTP
- 功能需要独立开发和测试
- 需要支持动态扩展(插件市场)
- 不同功能的生命周期不同
基本约束:
- 单机运行,不需要分布式
- 功能之间需要通信
- 需要热插拔
推导结论:
- 插件架构:独立、可扩展、松耦合
- 消息传递:解耦、异步、可追踪
- 不是因为"插件架构很先进",而是它最适合我们的需求
```
### 3. 团队管理
#### 问题:如何管理团队?
**❌ 类比思维**
- "大公司都有严格的层级,我们也要"
- "敏捷开发很流行,我们用 Scrum"
**✅ 第一性原理**
```
问题本质:
- 需要高效协作
- 需要快速决策
- 需要知识传承
- 需要持续改进
基本约束:
- 团队规模小10人左右
- 都是顶尖人才
- 远程协作AI 团队)
- 信息容易丢失
推导结论:
- 扁平化:减少沟通层级,提高效率
- 文档化:所有重要信息必须记录
- 开放反馈:鼓励提建议,持续改进
- 不是因为"扁平化很酷",而是它最适合我们的情况
```
### 4. 产品设计
#### 问题:要做什么产品?
**❌ 类比思维**
- "全息宠物很火,我们做全息宠物"
- "别人做 AR我们也做 AR"
**✅ 第一性原理**
```
问题本质:
- 用户需要什么?→ 数字内容的展示和交互
- 为什么需要?→ 情感陪伴、娱乐、信息展示
- 有什么限制?→ 硬件、技术、成本
基本约束:
- 显示技术多样全息、VR、AR、屏幕
- 内容类型多样宠物、3D、数字人、歌姬
- 用户需求多样C端、B端、开发者
推导结论:
- 做平台,不做单一产品
- 插件化,支持任何内容和显示方式
- 开放生态,让第三方参与
- 不是因为"平台战略很高大上",而是它能满足最多用户需求
```
---
## 第一性原理的应用流程
### 1. 识别问题
```
我们要解决什么问题?
这个问题为什么重要?
不解决会有什么后果?
```
### 2. 拆解问题
```
问题的本质是什么?
有哪些基本约束条件?
哪些是必须的,哪些是可选的?
```
### 3. 回归基本事实
```
已知的事实有哪些?
哪些是假设,哪些是事实?
有哪些物理/技术/经济规律?
```
### 4. 推导解决方案
```
从基本事实出发,有哪些可能的方案?
每个方案的优缺点是什么?
哪个方案最优?
```
### 5. 验证方案
```
这个方案真的解决了问题吗?
有没有更简单的方案?
有没有遗漏的约束?
```
### 6. 迭代优化
```
实施后效果如何?
有没有新的问题?
需要调整吗?
```
---
## 实践指南
### 在技术决策中
#### 提问清单
- [ ] 我们要解决什么技术问题?
- [ ] 这个技术的本质优势是什么?
- [ ] 我们的约束条件是什么?
- [ ] 有没有更简单的方案?
- [ ] 这个技术真的适合我们吗?
#### 避免的陷阱
- ❌ "这个技术很新,我们要用"
- ❌ "大公司都用,我们也用"
- ❌ "我熟悉这个,就用这个"
- ❌ "简历上好看,就用这个"
### 在产品决策中
#### 提问清单
- [ ] 用户的真实需求是什么?
- [ ] 为什么用户需要这个功能?
- [ ] 不做这个功能会怎样?
- [ ] 有没有更简单的方案?
- [ ] 这个功能真的有价值吗?
#### 避免的陷阱
- ❌ "竞品有,我们也要有"
- ❌ "这个功能很酷,加上"
- ❌ "用户说要,就做"(没有深挖需求)
- ❌ "我觉得好,就做"
### 在团队管理中
#### 提问清单
- [ ] 这个流程要解决什么问题?
- [ ] 为什么需要这个流程?
- [ ] 不做会有什么后果?
- [ ] 有没有更简单的方式?
- [ ] 这个流程真的有效吗?
#### 避免的陷阱
- ❌ "大公司都这样做"
- ❌ "书上说要这样"
- ❌ "一直都这样做"
- ❌ "为了规范而规范"
---
## 案例分析
### 案例1为什么选择插件架构
**问题**:如何设计 ShowenV2 的架构?
**第一性原理分析**
1. **问题本质**:需要支持多种功能,且功能会不断增加
2. **基本约束**
- 功能独立开发和测试
- 支持动态扩展
- 不同功能生命周期不同
3. **推导**
- 需要模块化 → 插件
- 需要解耦 → 消息传递
- 需要扩展 → 动态加载
4. **结论**:插件架构 + 消息驱动
**不是因为**
- ❌ "插件架构很先进"
- ❌ "Chrome 用插件,我们也用"
- ❌ "看起来很酷"
**而是因为**
- ✅ 真正解决了我们的问题
- ✅ 符合我们的约束条件
- ✅ 是最优解
### 案例2为什么要扁平化管理
**问题**:如何管理 AI 团队?
**第一性原理分析**
1. **问题本质**:需要高效协作和快速决策
2. **基本约束**
- 团队小10人
- 都是顶尖人才
- 远程协作
- 信息容易丢失
3. **推导**
- 人少 → 不需要多层级
- 顶尖人才 → 可以自主决策
- 远程 → 需要文档化
- 信息丢失 → 必须记录
4. **结论**:扁平化 + 文档化 + 开放反馈
**不是因为**
- ❌ "扁平化是趋势"
- ❌ "硅谷公司都扁平化"
- ❌ "看起来很民主"
**而是因为**
- ✅ 最适合我们的团队规模和特点
- ✅ 能最大化效率
- ✅ 能保证信息不丢失
### 案例3为什么要多架构并存
**问题**:如何设计通讯架构?
**第一性原理分析**
1. **问题本质**:用户需要多种方式连接设备
2. **基本约束**
- 不同场景需要不同通讯方式
- WiFi、BLE、Zigbee 等各有优劣
- 用户环境不同
3. **推导**
- 不能只支持一种 → 多架构
- 架构之间可能协作 → 松耦合
- 未来可能有新方式 → 可扩展
4. **结论**:多架构并存 + 插件化
**不是因为**
- ❌ "支持越多越好"
- ❌ "显得功能强大"
- ❌ "竞品支持,我们也要"
**而是因为**
- ✅ 真正满足不同用户的需求
- ✅ 每种方式都有其适用场景
- ✅ 给用户选择权
---
## 团队文化
### 鼓励质疑
- ✅ 质疑任何决策,包括 CEO 的决策
- ✅ 问"为什么",不要盲目接受
- ✅ 要求给出第一性原理的解释
- ✅ 如果解释不合理,提出更好的方案
### 避免盲从
- ❌ "大家都这样做"
- ❌ "行业最佳实践"
- ❌ "书上说的"
- ❌ "领导说的"
### 追求本质
- ✅ 理解问题的本质
- ✅ 找到最优解
- ✅ 简单优于复杂
- ✅ 有效优于好看
---
## 决策模板
每次重要决策都应该回答以下问题:
```markdown
# 决策:[决策内容]
## 1. 问题
我们要解决什么问题?
## 2. 本质
问题的本质是什么?
## 3. 约束
有哪些基本约束条件?
- 技术约束:
- 资源约束:
- 时间约束:
- 其他约束:
## 4. 基本事实
已知的事实有哪些?
- 事实1
- 事实2
## 5. 方案推导
从基本事实出发,有哪些可能的方案?
### 方案A
- 描述:
- 优点:
- 缺点:
- 成本:
### 方案B
- 描述:
- 优点:
- 缺点:
- 成本:
## 6. 决策
选择方案:[A/B/C]
理由:
- 为什么这个方案最优?
- 为什么不选其他方案?
## 7. 验证
如何验证这个决策是正确的?
- 验证指标:
- 验证方法:
- 验证时间:
```
---
**文档版本**: v1.0
**最后更新**: 2026-03-12
**负责人**: 陈逸飞 (CEO)