its-gen1/docs/project/TEAM_CULTURE_AND_DEVELOPMEN...

# 智能挂车AI-Box团队文化与开发规范

## 1. 新成员入门知识

### 1.1 必须了解的项目背景
- **项目目标**: 开发商用AI-Box Demo，验证智能挂车方案原型
- **硬件平台**: H100核心板（深明奥思Fellow 1芯片，132TOPS算力）
- **工作温度**: -40℃ ~ 85℃ 极端环境适应性要求
- **尺寸限制**: 60mm × 60mm，重量50g的严格约束

### 1.2 核心配置工具
- **飞书云文档**: 需求文档、设计文档、项目管理资料主存储
  - 共享文件夹: https://mcn7kggf4yn0.feishu.cn/drive/folder/ZICnfWaY7lc5Nrdh8qic9Y7Dnkb
  - 主要目录: 01管理/02系统/04软件/05测试
- **Gitea代码仓库**: 源代码和设计文件备份
  - 地址: http://47.253.94.217:3000/zxu/its-gen1
  - 账号: zxu / zxu123456

### 1.3 团队成员角色
- **产品经理**: 猪小杰 (emb-system) - 需求定义和PRD管理
- **软件架构师**: 孙大圣 (emb-arch) - 技术架构和设计方案
- **项目经理**: 唐小僧 (emb-pm) - 项目协调和进度管理
- **开发团队**: 功能开发和代码实现
- **测试团队**: 质量保证和验证测试

### 1.4 历史知识获取路径
1. **飞书共享文件夹**: 查看现有需求和设计文档
2. **Gitea仓库**: 查看代码历史和设计文件备份
3. **工作群消息**: 了解项目讨论和决策过程
4. **项目配置规范**: 阅读《项目配置目录结构和管理规范》

## 2. 开发流程规则与设计指导

### 2.1 双轨配置管理规则
- **设计文档**: 飞书为主，Gitea为备份（24小时内同步）
- **源代码**: Gitea为主存储，必须有完整版本控制
- **需求变更**: 必须同时更新飞书和Gitea两个位置

### 2.2 代码开发规范
- **分支策略**: 
  - main: 生产发布分支（受保护）
  - develop: 开发集成分支
  - feature/*: 功能开发分支
- **提交规范**: 
  - 格式: `[类型] 描述` (feat/fix/docs/style/refactor/test/chore)
  - 关联任务ID和详细说明
- **代码评审**: 所有代码必须通过Pull Request评审才能合并

### 2.3 设计指导原则
- **极端环境适应性**: 所有设计必须考虑-40℃~85℃工作环境
- **资源优化**: 在60×60mm/50g限制下做极致优化
- **多框架兼容**: 支持TensorFlow/PyTorch/ONNX/OpenAI API
- **电源管理**: 实现四种电源模式（运行/待机/低功耗/关机）
- **实时性要求**: 大模型推理必须满足低时延需求

### 2.4 文档编写标准
- **格式**: Markdown为主，便于版本控制
- **内容**: 必须包含接口定义、模块说明、使用示例
- **更新**: 代码变更必须同步更新相关文档
- **归档**: 按照Gitea目录结构规范存放

## 3. 详细开发计划与风险管理

### 3.1 项目里程碑计划

#### 第一阶段：需求与架构（1周）
- **任务**: PRD确认 + 系统架构设计
- **负责人**: 猪小杰 + 孙大圣
- **交付物**: 正式PRD + 架构设计方案
- **风险管控**: 需求变更控制，架构评审

#### 第二阶段：核心开发（2周）
- **任务**: 驱动层 + 框架层开发
- **负责人**: 开发团队 + 孙大圣
- **交付物**: 核心功能模块 + 单元测试
- **风险管控**: 技术难点攻关，代码质量保证

#### 第三阶段：集成测试（1周）
- **任务**: 系统集成 + 端到端测试
- **负责人**: 开发团队 + 测试团队
- **交付物**: 集成测试报告 + Bug修复
- **风险管控**: 集成问题快速定位，回归测试

#### 第四阶段：Demo交付（1周）
- **任务**: Demo优化 + 客户演示准备
- **负责人**: 全体团队
- **交付物**: AI-Box Demo + 演示文档
- **风险管控**: 演示稳定性，客户反馈处理

### 3.2 分工与职责矩阵

| 任务 | 产品经理 | 架构师 | 项目经理 | 开发 | 测试 |
|------|----------|--------|----------|------|------|
| 需求分析 | ✓ 主导 | ✓ 评审 | ✓ 协调 | | |
| 架构设计 | ✓ 评审 | ✓ 主导 | ✓ 协调 | | |
| 代码开发 | | ✓ 指导 | ✓ 跟踪 | ✓ 主导 | |
| 测试验证 | ✓ 验收 | ✓ 评审 | ✓ 协调 | ✓ 配合 | ✓ 主导 |
| 文档编写 | ✓ 需求 | ✓ 架构 | ✓ 计划 | ✓ 技术 | ✓ 测试 |
| 风险管理 | ✓ 识别 | ✓ 技术 | ✓ 全面 | ✓ 执行 | ✓ 质量 |

### 3.3 风险识别与应对策略

#### 技术风险
- **芯片兼容性问题**: 提前进行技术验证，准备备选方案
- **极端温度稳定性**: 增加环境测试，强化错误处理机制
- **性能不达标**: 优化算法，合理分配计算资源

#### 进度风险  
- **需求变更频繁**: 建立变更控制流程，评估影响后再实施
- **人员技能不足**: 提供技术培训，安排经验丰富的开发者指导
- **外部依赖延迟**: 提前识别依赖项，制定应急计划

#### 质量风险
- **代码质量不高**: 严格执行代码评审，增加自动化测试
- **测试覆盖不足**: 制定详细的测试计划，确保关键路径覆盖
- **文档缺失**: 将文档作为交付物的一部分，纳入验收标准

### 3.4 进度管理机制

#### 日常机制
- **每日站会**: 上午9:30，15分钟同步进展和阻塞问题
- **进度跟踪**: 使用飞书表格实时更新任务状态
- **问题升级**: 阻塞问题2小时内升级到项目经理

#### 周度机制  
- **周计划评审**: 每周一制定本周详细计划
- **周进度汇报**: 每周五总结本周完成情况
- **风险评估**: 每周识别和评估新风险

#### 里程碑机制
- **里程碑评审**: 每个阶段结束进行正式评审
- **质量门禁**: 达到质量标准才能进入下一阶段
- **客户同步**: 重要里程碑向客户汇报进展

## 4. 团队协作文化

### 4.1 核心价值观
- **客户导向**: 始终以客户需求和体验为中心
- **技术卓越**: 追求高质量的技术实现和创新
- **透明沟通**: 信息及时共享，问题主动暴露
- **责任担当**: 对自己的工作负责，对团队目标负责

### 4.2 协作原则
- **尊重专业**: 充分信任各领域专家的专业判断
- **主动沟通**: 发现问题立即沟通，不等待问题恶化
- **互相支持**: 团队成员互相帮助，共同解决问题
- **持续改进**: 从每个任务中学习，不断优化流程

### 4.3 沟通规范
- **工作群**: 日常沟通和紧急问题
- **文档**: 正式决策和详细说明
- **会议**: 重要讨论和决策制定
- **一对一**: 敏感问题和深度技术讨论

---
**本规范自发布之日起生效，所有团队成员必须遵守。项目经理负责监督执行，并根据项目实际情况进行适时调整。**
-												[docs] Add team culture and development guidelines

											
										
										
											2026-03-04 15:01:24 +08:00
+								# 智能挂车AI-Box团队文化与开发规范
 								## 1. 新成员入门知识
 								### 1.1 必须了解的项目背景
 								- **项目目标**: 开发商用AI-Box Demo，验证智能挂车方案原型
 								- **硬件平台**: H100核心板（深明奥思Fellow 1芯片，132TOPS算力）
 								- **工作温度**: -40℃ ~ 85℃ 极端环境适应性要求
 								- **尺寸限制**: 60mm × 60mm，重量50g的严格约束
 								### 1.2 核心配置工具
 								- **飞书云文档**: 需求文档、设计文档、项目管理资料主存储
 								  - 共享文件夹: https://mcn7kggf4yn0.feishu.cn/drive/folder/ZICnfWaY7lc5Nrdh8qic9Y7Dnkb
 								  - 主要目录: 01管理/02系统/04软件/05测试
 								- **Gitea代码仓库**: 源代码和设计文件备份
 								  - 地址: http://47.253.94.217:3000/zxu/its-gen1
 								  - 账号: zxu / zxu123456
 								### 1.3 团队成员角色
 								- **产品经理**: 猪小杰 (emb-system) - 需求定义和PRD管理
 								- **软件架构师**: 孙大圣 (emb-arch) - 技术架构和设计方案
 								- **项目经理**: 唐小僧 (emb-pm) - 项目协调和进度管理
 								- **开发团队**: 功能开发和代码实现
 								- **测试团队**: 质量保证和验证测试
 								### 1.4 历史知识获取路径
 . **飞书共享文件夹**: 查看现有需求和设计文档
 . **Gitea仓库**: 查看代码历史和设计文件备份
 . **工作群消息**: 了解项目讨论和决策过程
 . **项目配置规范**: 阅读《项目配置目录结构和管理规范》
 								## 2. 开发流程规则与设计指导
 								### 2.1 双轨配置管理规则
 								- **设计文档**: 飞书为主，Gitea为备份（24小时内同步）
 								- **源代码**: Gitea为主存储，必须有完整版本控制
 								- **需求变更**: 必须同时更新飞书和Gitea两个位置
 								### 2.2 代码开发规范
 								- **分支策略**:
 								  - main: 生产发布分支（受保护）
 								  - develop: 开发集成分支
 								  - feature/*: 功能开发分支
 								- **提交规范**:
 								  - 格式: `[类型] 描述` (feat/fix/docs/style/refactor/test/chore)
 								  - 关联任务ID和详细说明
 								- **代码评审**: 所有代码必须通过Pull Request评审才能合并
 								### 2.3 设计指导原则
 								- **极端环境适应性**: 所有设计必须考虑-40℃~85℃工作环境
 								- **资源优化**: 在60×60mm/50g限制下做极致优化
 								- **多框架兼容**: 支持TensorFlow/PyTorch/ONNX/OpenAI API
 								- **电源管理**: 实现四种电源模式（运行/待机/低功耗/关机）
 								- **实时性要求**: 大模型推理必须满足低时延需求
 								### 2.4 文档编写标准
 								- **格式**: Markdown为主，便于版本控制
 								- **内容**: 必须包含接口定义、模块说明、使用示例
 								- **更新**: 代码变更必须同步更新相关文档
 								- **归档**: 按照Gitea目录结构规范存放
 								## 3. 详细开发计划与风险管理
 								### 3.1 项目里程碑计划
 								#### 第一阶段：需求与架构（1周）
 								- **任务**: PRD确认 + 系统架构设计
 								- **负责人**: 猪小杰 + 孙大圣
 								- **交付物**: 正式PRD + 架构设计方案
 								- **风险管控**: 需求变更控制，架构评审
 								#### 第二阶段：核心开发（2周）
 								- **任务**: 驱动层 + 框架层开发
 								- **负责人**: 开发团队 + 孙大圣
 								- **交付物**: 核心功能模块 + 单元测试
 								- **风险管控**: 技术难点攻关，代码质量保证
 								#### 第三阶段：集成测试（1周）
 								- **任务**: 系统集成 + 端到端测试
 								- **负责人**: 开发团队 + 测试团队
 								- **交付物**: 集成测试报告 + Bug修复
 								- **风险管控**: 集成问题快速定位，回归测试
 								#### 第四阶段：Demo交付（1周）
 								- **任务**: Demo优化 + 客户演示准备
 								- **负责人**: 全体团队
 								- **交付物**: AI-Box Demo + 演示文档
 								- **风险管控**: 演示稳定性，客户反馈处理
 								### 3.2 分工与职责矩阵
 								| 任务 | 产品经理 | 架构师 | 项目经理 | 开发 | 测试 |
 								|------|----------|--------|----------|------|------|
 								| 需求分析 | ✓ 主导 | ✓ 评审 | ✓ 协调 | | |
 								| 架构设计 | ✓ 评审 | ✓ 主导 | ✓ 协调 | | |
 								| 代码开发 | | ✓ 指导 | ✓ 跟踪 | ✓ 主导 | |
 								| 测试验证 | ✓ 验收 | ✓ 评审 | ✓ 协调 | ✓ 配合 | ✓ 主导 |
 								| 文档编写 | ✓ 需求 | ✓ 架构 | ✓ 计划 | ✓ 技术 | ✓ 测试 |
 								| 风险管理 | ✓ 识别 | ✓ 技术 | ✓ 全面 | ✓ 执行 | ✓ 质量 |
 								### 3.3 风险识别与应对策略
 								#### 技术风险
 								- **芯片兼容性问题**: 提前进行技术验证，准备备选方案
 								- **极端温度稳定性**: 增加环境测试，强化错误处理机制
 								- **性能不达标**: 优化算法，合理分配计算资源
 								#### 进度风险
 								- **需求变更频繁**: 建立变更控制流程，评估影响后再实施
 								- **人员技能不足**: 提供技术培训，安排经验丰富的开发者指导
 								- **外部依赖延迟**: 提前识别依赖项，制定应急计划
 								#### 质量风险
 								- **代码质量不高**: 严格执行代码评审，增加自动化测试
 								- **测试覆盖不足**: 制定详细的测试计划，确保关键路径覆盖
 								- **文档缺失**: 将文档作为交付物的一部分，纳入验收标准
 								### 3.4 进度管理机制
 								#### 日常机制
 								- **每日站会**: 上午9:30，15分钟同步进展和阻塞问题
 								- **进度跟踪**: 使用飞书表格实时更新任务状态
 								- **问题升级**: 阻塞问题2小时内升级到项目经理
 								#### 周度机制
 								- **周计划评审**: 每周一制定本周详细计划
 								- **周进度汇报**: 每周五总结本周完成情况
 								- **风险评估**: 每周识别和评估新风险
 								#### 里程碑机制
 								- **里程碑评审**: 每个阶段结束进行正式评审
 								- **质量门禁**: 达到质量标准才能进入下一阶段
 								- **客户同步**: 重要里程碑向客户汇报进展
 								## 4. 团队协作文化
 								### 4.1 核心价值观
 								- **客户导向**: 始终以客户需求和体验为中心
 								- **技术卓越**: 追求高质量的技术实现和创新
 								- **透明沟通**: 信息及时共享，问题主动暴露
 								- **责任担当**: 对自己的工作负责，对团队目标负责
 								### 4.2 协作原则
 								- **尊重专业**: 充分信任各领域专家的专业判断
 								- **主动沟通**: 发现问题立即沟通，不等待问题恶化
 								- **互相支持**: 团队成员互相帮助，共同解决问题
 								- **持续改进**: 从每个任务中学习，不断优化流程
 								### 4.3 沟通规范
 								- **工作群**: 日常沟通和紧急问题
 								- **文档**: 正式决策和详细说明
 								- **会议**: 重要讨论和决策制定
 								- **一对一**: 敏感问题和深度技术讨论
 								---
 								**本规范自发布之日起生效，所有团队成员必须遵守。项目经理负责监督执行，并根据项目实际情况进行适时调整。**