- 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 当前状态
412 lines
9.0 KiB
Markdown
412 lines
9.0 KiB
Markdown
# 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)
|