6.4 KiB
6.4 KiB
智能挂车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代码仓库: 源代码和设计文件备份
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 沟通规范
- 工作群: 日常沟通和紧急问题
- 文档: 正式决策和详细说明
- 会议: 重要讨论和决策制定
- 一对一: 敏感问题和深度技术讨论
本规范自发布之日起生效，所有团队成员必须遵守。项目经理负责监督执行，并根据项目实际情况进行适时调整。