becd200150
- 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 当前状态
379 lines
8.8 KiB
Markdown
379 lines
8.8 KiB
Markdown
# ShowenV2 沟通和记录规范
|
||
|
||
## 沟通原则
|
||
|
||
### 核心理念
|
||
- **扁平化**: 员工之间直接沟通，不需要层层汇报
|
||
- **透明化**: 重要信息必须记录，所有人可见
|
||
- **可追溯**: 决策和讨论有据可查
|
||
- **知识沉淀**: 经验和方案通过记录传承
|
||
- **向上开放**: 所有员工都可以给领导层和管理层提建议
|
||
|
||
### 向上沟通原则
|
||
- ✅ 可以质疑任何决策，包括 CEO 的决策
|
||
- ✅ 可以提出管理流程的改进建议
|
||
- ✅ 可以建议调整团队结构
|
||
- ✅ 可以对产品方向提出不同意见
|
||
- ✅ 可以指出领导层的问题
|
||
- ✅ 畅所欲言，没有禁区
|
||
|
||
### 平级沟通原则
|
||
- ✅ 可以给同事提工作建议
|
||
- ✅ 可以指出同事代码的问题
|
||
- ✅ 可以建议改进协作方式
|
||
- ✅ 可以对其他团队的输出提意见
|
||
- ✅ 建议要具体、建设性
|
||
- ✅ 接受建议要开放、理性
|
||
|
||
### 建议和反馈
|
||
所有员工都可以在 TEAM_CHAT.md 提出建议，格式：
|
||
|
||
#### 向上建议格式
|
||
```markdown
|
||
[时间] [姓名]([角色]) - 建议
|
||
|
||
建议对象：[CEO/管理层/某个流程]
|
||
建议内容：
|
||
1. 问题描述：[当前存在的问题]
|
||
2. 影响分析：[这个问题的影响]
|
||
3. 改进建议：[具体的改进方案]
|
||
4. 预期效果：[改进后的预期效果]
|
||
```
|
||
|
||
#### 平级建议格式
|
||
```markdown
|
||
[时间] [姓名]([角色]) → [接收者]([角色]) - 建议
|
||
|
||
建议内容：
|
||
- 当前问题：[观察到的问题]
|
||
- 改进建议：[具体建议]
|
||
- 参考：[可参考的例子]
|
||
- 预期效果：[改进后的效果]
|
||
```
|
||
|
||
---
|
||
|
||
## 沟通方式
|
||
|
||
### 1. 异步沟通（推荐）
|
||
|
||
#### 工具
|
||
- **TEAM_CHAT.md** - 团队沟通主渠道
|
||
- **Git commit** - 代码变更说明
|
||
- **文档** - PRD、技术设计文档、API 文档
|
||
|
||
#### 适用场景
|
||
- 技术讨论和方案设计
|
||
- 需求澄清和变更
|
||
- 问题反馈和解决方案
|
||
- 经验分享和最佳实践
|
||
- 跨团队协作
|
||
|
||
#### 优点
|
||
- ✅ 自动记录，可追溯
|
||
- ✅ 可搜索，易查找
|
||
- ✅ 异步处理，不打断工作
|
||
- ✅ 深度思考，质量更高
|
||
|
||
#### 记录格式
|
||
```markdown
|
||
[时间] 发送者 → 接收者: 内容
|
||
|
||
示例：
|
||
[14:30] 李思琪(视频工程师) → 王浩然(网络工程师):
|
||
视频流传输性能问题已解决，采用零拷贝方案。
|
||
- 参考代码：src/plugins/video/processor.rs:456
|
||
- 性能提升：从 30fps 提升到 60fps
|
||
- 关键技术：tokio::fs::File + 流式传输
|
||
```
|
||
|
||
---
|
||
|
||
### 2. 实时沟通（可选）
|
||
|
||
#### 工具
|
||
- **kilo 命令** - 启动子任务进行实时协作
|
||
- **语音/视频会议** - 复杂问题讨论
|
||
- **屏幕共享** - 代码调试和演示
|
||
|
||
#### 适用场景
|
||
- 紧急问题需要快速解决
|
||
- 复杂技术方案需要深入讨论
|
||
- 头脑风暴和创意碰撞
|
||
- 代码调试和问题定位
|
||
|
||
#### 记录要求
|
||
**重要**：实时沟通后必须在 TEAM_CHAT.md 记录要点
|
||
|
||
```markdown
|
||
[时间] 会议记录 - [主题]
|
||
参与人：[人员列表]
|
||
讨论内容：
|
||
1. 问题描述
|
||
2. 讨论要点
|
||
3. 决策结果
|
||
4. 行动计划
|
||
```
|
||
|
||
---
|
||
|
||
### 3. 代码协作
|
||
|
||
#### 工具
|
||
- **Git commit message** - 代码变更说明
|
||
- **代码注释** - 复杂逻辑说明
|
||
- **Pull Request** - 代码审查和讨论
|
||
|
||
#### 记录要求
|
||
|
||
##### Commit Message 规范
|
||
```
|
||
<type>: <subject>
|
||
|
||
<body>
|
||
|
||
<footer>
|
||
```
|
||
|
||
**Type 类型**:
|
||
- `feat`: 新功能
|
||
- `fix`: Bug 修复
|
||
- `docs`: 文档更新
|
||
- `refactor`: 重构
|
||
- `perf`: 性能优化
|
||
- `test`: 测试
|
||
- `chore`: 构建/工具
|
||
|
||
**示例**:
|
||
```
|
||
feat: 实现插件动态注册机制
|
||
|
||
- 新增 ServiceManager::register_plugin() 方法
|
||
- 支持运行时加载插件
|
||
- 自动检查依赖关系
|
||
|
||
Closes #123
|
||
```
|
||
|
||
##### 代码注释规范
|
||
```rust
|
||
/// 公共 API 文档注释（三斜杠）
|
||
///
|
||
/// # Arguments
|
||
/// * `plugin` - 要注册的插件
|
||
///
|
||
/// # Returns
|
||
/// 成功返回 Ok(())，失败返回错误
|
||
///
|
||
/// # Examples
|
||
/// ```
|
||
/// manager.register_plugin(Box::new(MyPlugin::new()))?;
|
||
/// ```
|
||
pub fn register_plugin(&mut self, plugin: Box<dyn Plugin>) -> Result<()> {
|
||
// 实现细节注释（双斜杠）
|
||
// 为什么这样做，而不是做了什么
|
||
}
|
||
```
|
||
|
||
---
|
||
|
||
### 4. 文档协作
|
||
|
||
#### 工具
|
||
- **Markdown 文档** - PRD、技术设计、API 文档
|
||
- **Git** - 版本控制和变更追踪
|
||
|
||
#### 文档类型
|
||
- **PRD** - 产品需求文档
|
||
- **技术设计文档** - 架构和实现方案
|
||
- **API 文档** - 接口说明
|
||
- **用户文档** - 使用指南
|
||
- **开发文档** - 开发规范和流程
|
||
|
||
#### 记录要求
|
||
- 文档变更通过 Git 提交
|
||
- 重大变更在 TEAM_CHAT.md 通知相关人员
|
||
- 文档版本号和更新日期
|
||
|
||
---
|
||
|
||
## 记录规范
|
||
|
||
### 必须记录的内容
|
||
|
||
#### 技术决策
|
||
```markdown
|
||
[时间] 技术决策 - [主题]
|
||
决策人：[姓名]
|
||
背景：[为什么需要决策]
|
||
方案：
|
||
- 方案A：[描述] - 优点/缺点
|
||
- 方案B：[描述] - 优点/缺点
|
||
决策：选择方案A
|
||
理由：[决策理由]
|
||
影响：[影响范围]
|
||
```
|
||
|
||
#### 需求变更
|
||
```markdown
|
||
[时间] 需求变更 - [功能名称]
|
||
提出人：[姓名]
|
||
原需求：[原来的需求]
|
||
新需求：[变更后的需求]
|
||
变更原因：[为什么变更]
|
||
影响评估：[对进度、架构的影响]
|
||
批准人：[CEO/产品总监]
|
||
```
|
||
|
||
#### 架构调整
|
||
```markdown
|
||
[时间] 架构调整 - [模块名称]
|
||
提出人：[姓名]
|
||
当前架构：[现状]
|
||
调整方案：[新方案]
|
||
调整原因：[为什么调整]
|
||
影响范围：[影响的模块]
|
||
迁移计划：[如何迁移]
|
||
```
|
||
|
||
#### Bug 和解决方案
|
||
```markdown
|
||
[时间] Bug 修复 - [Bug 描述]
|
||
发现人：[姓名]
|
||
严重程度：P0/P1/P2/P3
|
||
复现步骤：[如何复现]
|
||
根因分析：[为什么出现]
|
||
解决方案：[如何修复]
|
||
代码位置：[文件:行号]
|
||
验证：[如何验证修复]
|
||
```
|
||
|
||
#### 经验教训
|
||
```markdown
|
||
[时间] 经验分享 - [主题]
|
||
分享人：[姓名]
|
||
场景：[遇到什么问题]
|
||
教训：[学到了什么]
|
||
最佳实践：[推荐做法]
|
||
避免：[不要这样做]
|
||
参考：[相关文档/代码]
|
||
```
|
||
|
||
---
|
||
|
||
### 可以不记录的内容
|
||
|
||
- ❌ 日常问候和闲聊
|
||
- ❌ 简单的代码语法问题（已在代码中解决）
|
||
- ❌ 已在文档中详细说明的内容
|
||
- ❌ 临时性的、不重要的讨论
|
||
|
||
---
|
||
|
||
## 记录管理
|
||
|
||
### 记录位置
|
||
- **TEAM_CHAT.md** - 日常沟通和协作
|
||
- **Git commit** - 代码变更
|
||
- **文档** - 正式的需求、设计、规范
|
||
- **灵魂文件** - 个人经验和技能
|
||
|
||
### 记录检索
|
||
- 使用 Git 搜索历史记录
|
||
- 使用文本搜索工具（grep、ripgrep）
|
||
- 按时间顺序浏览 TEAM_CHAT.md
|
||
|
||
### 记录归档
|
||
- 每月归档 TEAM_CHAT.md（保留最近 3个月）
|
||
- 重要决策整理到专门文档
|
||
- 经验教训更新到灵魂文件
|
||
|
||
---
|
||
|
||
## 沟通礼仪
|
||
|
||
### 提问技巧
|
||
- ✅ 描述清楚问题背景
|
||
- ✅ 说明已经尝试的方案
|
||
- ✅ 提供相关代码和日志
|
||
- ✅ @ 相关人员
|
||
- ❌ 不要问"在吗"
|
||
- ❌ 不要问"能帮我吗"
|
||
|
||
### 回复规范
|
||
- ✅ 及时回复（24小时内）
|
||
- ✅ 提供具体的解决方案
|
||
- ✅ 附上代码示例或文档链接
|
||
- ✅ 说明为什么这样做
|
||
- ❌ 不要只说"可以"或"不行"
|
||
|
||
### 协作态度
|
||
- ✅ 主动分享知识和经验
|
||
- ✅ 尊重他人的意见
|
||
- ✅ 建设性的反馈
|
||
- ✅ 承认错误，快速改进
|
||
- ❌ 不要指责和抱怨
|
||
|
||
---
|
||
|
||
## 示例
|
||
|
||
### 技术讨论示例
|
||
```markdown
|
||
[14:30] 李思琪 → 王浩然:
|
||
我在实现视频流传输时遇到性能瓶颈，帧率只能达到 30fps。
|
||
已尝试：
|
||
1. 减少内存拷贝 - 效果不明显
|
||
2. 使用 SIMD 优化 - 提升 10%
|
||
你在 HTTP 插件中是怎么处理大数据传输的？
|
||
|
||
[14:45] 王浩然 → 李思琪:
|
||
我用了零拷贝和流式传输，性能提升明显。
|
||
关键技术：
|
||
1. tokio::fs::File - 异步文件读取
|
||
2. warp::reply::Response::new() - 流式响应
|
||
3. 避免 Vec<u8> 缓冲 - 直接传输
|
||
参考代码：src/plugins/http/routes.rs:234
|
||
建议你试试 opencv::Mat 的零拷贝接口。
|
||
|
||
[15:00] 李思琪 → 王浩然:
|
||
感谢！已采用你的方案，帧率提升到 60fps。
|
||
更新代码：src/plugins/video/processor.rs:456
|
||
经验记录：避免不必要的内存拷贝是性能优化的关键。
|
||
```
|
||
|
||
### 跨团队协作示例
|
||
```markdown
|
||
[10:00] 张婉琳(产品) → 王思远(架构师):
|
||
Phase 2 插件市场需求已完成，需要你评审技术可行性。
|
||
文档：PRD_PLUGIN_MARKET.md
|
||
关键需求：
|
||
1. 插件动态安装
|
||
2. 版本管理
|
||
3. 依赖检查
|
||
请在本周五前给出技术方案。
|
||
|
||
[10:30] 王思远(架构师) → 张婉琳(产品):
|
||
已阅读 PRD，整体可行。
|
||
技术方案：
|
||
1. 使用 libloading 动态加载 .so/.dll
|
||
2. 版本管理用 semver
|
||
3. 依赖检查在 ServiceManager 实现
|
||
风险：
|
||
1. 插件签名验证需要额外工作
|
||
2. 沙箱隔离可能影响性能
|
||
建议：Phase 2 先实现基础功能，安全机制放 Phase 3。
|
||
技术设计文档：本周三完成。
|
||
|
||
[10:45] 张婉琳(产品) → 王思远(架构师):
|
||
同意你的建议。安全机制确实可以后续迭代。
|
||
请在技术设计文档中说明 Phase 2/3 的功能划分。
|
||
@ 刘建国(PM) 请关注进度。
|
||
```
|
||
|
||
---
|
||
|
||
**文档版本**: v1.0
|
||
**最后更新**: 2026-03-12
|
||
**负责人**: 陈逸飞 (CEO)
|