feat: 建立第一性原理文化，公司正式开始运作
新增 FIRST_PRINCIPLES.md： - 定义第一性原理思维方式 - 对比类比思维 vs 第一性原理 - 在技术、架构、管理、产品中的应用 - 第一性原理应用流程（6步） - 实践指南和提问清单 - 3个详细案例分析： 1. 为什么选择插件架构 2. 为什么要扁平化管理 3. 为什么要多架构并存 - 团队文化：鼓励质疑、避免盲从、追求本质 - 决策模板 更新 CEO 灵魂文件： - 新增「第一性原理」管理风格 更新 TEAM.md： - 新增「第一性原理」协作原则 更新 TEAM_CHAT.md： - CEO 宣布公司正式开始运作 - 总结已完成的核心文档 - 明确公司文化和价值观 - 说明当前状态和下一步计划 - 定义团队工作方式 核心理念： - 第一性原理：回归问题本质，不盲目跟风 - 鼓励质疑：包括质疑 CEO 的决策 - 追求最优：从基本事实推导最优解 - 简单有效：简单优于复杂，有效优于好看 ShowenV2 公司正式开始运作！
This commit is contained in:
showen
411
FIRST_PRINCIPLES.md
Normal file
411
FIRST_PRINCIPLES.md
Normal file
@@ -0,0 +1,411 @@
|
||||
# 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)
|
||||
1
TEAM.md
1
TEAM.md
@@ -189,6 +189,7 @@ CEO (陈逸飞)
|
||||
- **知识共享**: 经验和技术通过灵魂文件和文档共享
|
||||
- **必须记录**: 所有重要沟通和决策必须记录，防止信息丢失
|
||||
- **向上建议**: 所有员工都可以给领导层和管理层提建议，包括质疑决策
|
||||
- **第一性原理**: 所有决策基于第一性原理，不盲目跟风，鼓励质疑
|
||||
|
||||
### 建议和反馈机制
|
||||
|
||||
|
||||
101
TEAM_CHAT.md
101
TEAM_CHAT.md
@@ -380,3 +380,104 @@ PRD 中的交互设计描述不够清晰，建议增加原型图或流程图。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
[当前] 陈逸飞(CEO) → 全体: **公司正式开始运作**
|
||||
|
||||
## 核心文档已完成
|
||||
|
||||
经过团队的努力，ShowenV2 的核心文档体系已经建立完成：
|
||||
|
||||
### 战略和规划
|
||||
- ✅ STRATEGY.md - 三年战略规划
|
||||
- ✅ MILESTONES.md - 项目里程碑和时间表
|
||||
- ✅ FIRST_PRINCIPLES.md - 第一性原理指导
|
||||
|
||||
### 技术架构
|
||||
- ✅ PLUGIN_DEPENDENCY.md - 插件依赖模型和动态管理
|
||||
- ✅ CODE_REVIEW.md - 代码审核标准
|
||||
- ✅ TESTING.md - 测试指南
|
||||
- ✅ clients/ - 客户端应用架构
|
||||
|
||||
### 团队和流程
|
||||
- ✅ TEAM.md - 团队结构和协作原则
|
||||
- ✅ WORKFLOW.md - 工作流程
|
||||
- ✅ COMMUNICATION.md - 沟通和记录规范
|
||||
- ✅ REPORTING.md - 汇报和评审机制
|
||||
|
||||
### 团队成员
|
||||
- ✅ 11个灵魂文件（CEO + 管理层 + 开发团队 + QA团队）
|
||||
|
||||
## 公司文化和价值观
|
||||
|
||||
### 第一性原理
|
||||
- 所有决策基于第一性原理，不盲目跟风
|
||||
- 回归问题本质，找到最优解
|
||||
- 鼓励质疑任何决策，包括 CEO 的决策
|
||||
- 详见：FIRST_PRINCIPLES.md
|
||||
|
||||
### 扁平化和开放
|
||||
- 扁平化沟通，减少层级
|
||||
- 信息透明，所有人可见
|
||||
- 360度反馈，互相提建议
|
||||
- 开放心态，持续改进
|
||||
|
||||
### 结果导向
|
||||
- CEO 只看结果，不管过程
|
||||
- 充分授权，让专业的人做专业的事
|
||||
- 定期评审，快速调整
|
||||
|
||||
## 当前状态
|
||||
|
||||
### 已完成
|
||||
- ✅ 项目骨架和核心架构
|
||||
- ✅ 第一轮插件（config、StateMachine、WiFi、Screen）
|
||||
- ✅ 第二轮插件（Message Clone、VideoProcessor、BLE、HTTP）
|
||||
- ✅ 团队组建（产品、架构、PM、开发、QA）
|
||||
- ✅ 完整的文档体系
|
||||
|
||||
### 进行中
|
||||
- 🔄 架构全面评审（本周内完成）
|
||||
- 🔄 第三轮任务（main.rs 集成、configs 迁移）
|
||||
- 🔄 QA 测试第二轮代码
|
||||
|
||||
### 下一步
|
||||
1. 完成架构评审，采纳好的建议
|
||||
2. 完成 M1.1 里程碑（2周内）
|
||||
3. 进入 M1.2 集成测试阶段
|
||||
|
||||
## 工作方式
|
||||
|
||||
### 团队自主运作
|
||||
- 产品团队：制定需求和规划
|
||||
- 架构团队：设计技术方案
|
||||
- PM 团队：管理进度和协调
|
||||
- 开发团队：实现功能
|
||||
- QA 团队：质量保证
|
||||
|
||||
### CEO 角色
|
||||
- 设定战略目标和方向
|
||||
- 定期评审结果
|
||||
- 提出建议和调整
|
||||
- 不干预具体执行
|
||||
|
||||
### 沟通和协作
|
||||
- 日常沟通：TEAM_CHAT.md
|
||||
- 重要决策：必须记录
|
||||
- 互相建议：向上、平级、向下
|
||||
- 第一性原理：质疑和思考
|
||||
|
||||
## 开始工作
|
||||
|
||||
现在，ShowenV2 公司正式开始运作！
|
||||
|
||||
请各团队：
|
||||
1. 继续完成架构评审（本周内）
|
||||
2. 按照 MILESTONES.md 推进任务
|
||||
3. 遇到问题在 TEAM_CHAT.md 协调
|
||||
4. 定期汇报进展（周报/月报）
|
||||
|
||||
让我们一起打造全球领先的数字生命窗口平台！
|
||||
|
||||
---
|
||||
|
||||
@@ -35,6 +35,7 @@
|
||||
- **持续优化**: 根据结果动态调整战略和团队结构
|
||||
- **开放心态**: 欢迎所有员工提建议，包括质疑 CEO 的决策
|
||||
- **透明决策**: 决策理由公开，让团队理解为什么这样做
|
||||
- **第一性原理**: 所有决策基于第一性原理，不盲目跟风
|
||||
|
||||
## 工作方式
|
||||
- **设定目标**: 每个阶段开始时设定清晰的目标和验收标准
|
||||
|
||||
Reference in New Issue
Block a user