Merge branch 'main' of http://47.253.94.217:3000/zxu/its-gen1
This commit is contained in:
commit
4c7d6d1fe0
|
|
@ -0,0 +1,61 @@
|
||||||
|
# 3月份重点工作计划表
|
||||||
|
|
||||||
|
## 项目概述
|
||||||
|
- **项目名称**: 智能挂车AI-Box Demo开发
|
||||||
|
- **项目目标**: 验证智能挂车方案原型,基于H100核心板实现端侧大模型推理
|
||||||
|
- **关键约束**: -40℃~85℃工作温度,60×60mm尺寸,50g重量
|
||||||
|
|
||||||
|
## 重点工作及目标
|
||||||
|
|
||||||
|
### 1. 需求分析与确认 (3/4-3/8)
|
||||||
|
- **目标**: 完成正式PRD文档并获得团队确认
|
||||||
|
- **负责人**: 猪小杰 (产品经理)
|
||||||
|
- **交付物**: 商用车AI-Box Demo产品需求规格书
|
||||||
|
- **成功标准**: 所有团队成员确认需求无歧义
|
||||||
|
|
||||||
|
### 2. 系统架构设计 (3/9-3/15)
|
||||||
|
- **目标**: 完成软件和硬件系统架构设计方案
|
||||||
|
- **负责人**: 孙大圣 (软件架构师) + 孙凯瑾 (硬件专家)
|
||||||
|
- **交付物**: 系统架构设计方案文档
|
||||||
|
- **成功标准**: 通过架构评审,满足所有技术约束
|
||||||
|
|
||||||
|
### 3. 核心功能开发 (3/16-3/29)
|
||||||
|
- **目标**: 完成SoC和MCU核心功能模块开发
|
||||||
|
- **负责人**: 季增超 (SoC工程师) + 刘彬彬 (MCU工程师)
|
||||||
|
- **交付物**: 核心功能代码 + 单元测试报告
|
||||||
|
- **成功标准**: 所有核心功能通过单元测试
|
||||||
|
|
||||||
|
### 4. 团队协作机制建立 (3/4-3/31)
|
||||||
|
- **目标**: 建立高效的团队协作流程
|
||||||
|
- **负责人**: 唐小僧 (项目经理)
|
||||||
|
- **交付物**:
|
||||||
|
- 团队分工表
|
||||||
|
- Defect管理规范
|
||||||
|
- 项目开发计划
|
||||||
|
- 沟通管理机制
|
||||||
|
- **成功标准**: 团队成员清楚职责,协作顺畅
|
||||||
|
|
||||||
|
### 5. 配置管理体系建设 (3/4-3/31)
|
||||||
|
- **目标**: 建立完整的配置管理流程
|
||||||
|
- **负责人**: 唐小僧 (项目经理)
|
||||||
|
- **交付物**:
|
||||||
|
- Gitea仓库结构
|
||||||
|
- 飞书文档管理规范
|
||||||
|
- 双轨配置管理策略
|
||||||
|
- **成功标准**: 所有成果物都有版本控制和备份
|
||||||
|
|
||||||
|
## 关键里程碑
|
||||||
|
- **3/8**: 需求确认完成
|
||||||
|
- **3/15**: 架构设计完成
|
||||||
|
- **3/29**: 核心开发完成
|
||||||
|
- **3/31**: 3月份目标达成评估
|
||||||
|
|
||||||
|
## 风险管理
|
||||||
|
- **技术风险**: 芯片兼容性问题 → 提前技术验证
|
||||||
|
- **进度风险**: 需求变更 → 建立变更控制流程
|
||||||
|
- **质量风险**: 极端环境稳定性 → 强化测试覆盖
|
||||||
|
|
||||||
|
## 资源需求
|
||||||
|
- **人力资源**: 开发工程师、测试工程师按计划到位
|
||||||
|
- **工具资源**: Gitea、飞书、todonow等工具正常使用
|
||||||
|
- **硬件资源**: H100核心板开发套件及时到位
|
||||||
|
|
@ -0,0 +1,92 @@
|
||||||
|
# 智能挂车AI-Box项目配置管理规范
|
||||||
|
|
||||||
|
## 1. 总体配置策略
|
||||||
|
|
||||||
|
### 双轨存储原则
|
||||||
|
- **飞书云文档**: 主要设计文件、需求文档、项目管理资料
|
||||||
|
- **Gitea (47.253.94.217:3000/zxu/its-gen1)**:
|
||||||
|
- 源代码主要存储位置
|
||||||
|
- 设计文件备份位置
|
||||||
|
- 所有技术资产的版本控制
|
||||||
|
|
||||||
|
### 访问信息
|
||||||
|
- **Gitea地址**: http://47.253.94.217:3000
|
||||||
|
- **仓库名称**: zxu/its-gen1
|
||||||
|
- **账号**: zxu / zxu123456
|
||||||
|
|
||||||
|
## 2. 仓库目录结构
|
||||||
|
|
||||||
|
```
|
||||||
|
its-gen1/
|
||||||
|
├── docs/ # 文档目录
|
||||||
|
│ ├── specs/ # 需求规格文档(已存在)
|
||||||
|
│ ├── architecture/ # 系统架构文档(已存在)
|
||||||
|
│ ├── design/ # 详细设计文档
|
||||||
|
│ └── project/ # 项目管理文档
|
||||||
|
│ └── CONFIGURATION_MANAGEMENT.md
|
||||||
|
├── design/ # 设计文档备份(已存在)
|
||||||
|
├── src/ # 源代码目录(待创建)
|
||||||
|
│ ├── drivers/ # 驱动层代码
|
||||||
|
│ ├── framework/ # 框架层代码
|
||||||
|
│ ├── applications/ # 应用层代码
|
||||||
|
│ └── utils/ # 工具类代码
|
||||||
|
├── scripts/ # 构建和部署脚本(待创建)
|
||||||
|
├── configs/ # 配置文件(待创建)
|
||||||
|
└── README.md # 项目说明(已存在)
|
||||||
|
```
|
||||||
|
|
||||||
|
## 3. 提交规范
|
||||||
|
|
||||||
|
### 文件命名规范
|
||||||
|
- 文档: `功能名_版本号.md` 或使用现有命名规范
|
||||||
|
- 代码: 遵循各语言的命名规范
|
||||||
|
- 配置: `环境_功能.conf`
|
||||||
|
|
||||||
|
### 提交信息格式
|
||||||
|
```
|
||||||
|
[类型] 简要描述
|
||||||
|
|
||||||
|
详细说明(可选)
|
||||||
|
|
||||||
|
关联任务ID(可选)
|
||||||
|
```
|
||||||
|
|
||||||
|
类型包括: feat(新功能), fix(修复), docs(文档), style(格式), refactor(重构), test(测试), chore(构建)
|
||||||
|
|
||||||
|
## 4. 分支管理策略
|
||||||
|
|
||||||
|
### 主要分支
|
||||||
|
- **main**: 生产发布分支,受保护
|
||||||
|
- **develop**: 开发集成分支
|
||||||
|
- **feature/**: 功能开发分支
|
||||||
|
- **hotfix/**: 紧急修复分支
|
||||||
|
|
||||||
|
## 5. 角色职责
|
||||||
|
|
||||||
|
### 产品经理 (emb-system/猪小杰)
|
||||||
|
- 需求文档在飞书归档后,同步备份到Gitea `/docs/specs/`
|
||||||
|
- 需求变更需同时更新两个位置
|
||||||
|
|
||||||
|
### 软件架构师 (emb-arch/孙大圣)
|
||||||
|
- 架构设计方案在飞书发布后,备份到Gitea `/docs/architecture/`
|
||||||
|
- 提供详细的接口定义和模块说明
|
||||||
|
|
||||||
|
### 项目经理 (emb-pm/唐小僧)
|
||||||
|
- 维护配置管理规范
|
||||||
|
- 监督配置纪律执行
|
||||||
|
- 协调配置相关问题解决
|
||||||
|
|
||||||
|
### 开发团队
|
||||||
|
- 代码提交到对应src子目录
|
||||||
|
- 遵循分支管理和提交规范
|
||||||
|
- 及时更新相关设计文档
|
||||||
|
|
||||||
|
## 6. 同步机制
|
||||||
|
|
||||||
|
### 设计文档同步
|
||||||
|
- 飞书文档更新后24小时内同步到Gitea对应目录
|
||||||
|
- 以飞书为主版本,Gitea为备份版本
|
||||||
|
|
||||||
|
### 代码提交
|
||||||
|
- 所有代码必须通过Pull Request流程
|
||||||
|
- 重要功能必须有对应的文档更新
|
||||||
|
|
@ -0,0 +1,131 @@
|
||||||
|
# AI-Box项目Defect管理规范
|
||||||
|
|
||||||
|
## 1. 标签体系设计
|
||||||
|
|
||||||
|
### 1.1 按模块分类
|
||||||
|
- `mcu`: MCU软件相关问题
|
||||||
|
- `soc`: SoC软件相关问题
|
||||||
|
- `f1-npu`: Fellow 1 NPU芯片相关问题
|
||||||
|
- `power-management`: 电源管理模块问题
|
||||||
|
- `communication`: 通信协议和接口问题
|
||||||
|
|
||||||
|
### 1.2 按类型分类
|
||||||
|
- `bug`: 缺陷和错误
|
||||||
|
- `feature`: 新功能需求
|
||||||
|
- `enhancement`: 功能改进
|
||||||
|
- `documentation`: 文档相关
|
||||||
|
|
||||||
|
### 1.3 按严重程度分类
|
||||||
|
- `critical`: 系统崩溃、数据丢失等严重问题
|
||||||
|
- `high`: 主要功能不可用
|
||||||
|
- `medium`: 次要功能问题
|
||||||
|
- `low`: 界面优化、文案修正等
|
||||||
|
|
||||||
|
### 1.4 按状态分类
|
||||||
|
- `in-review`: 待评审
|
||||||
|
- `in-progress`: 开发中
|
||||||
|
- `testing`: 测试中
|
||||||
|
- `resolved`: 已解决
|
||||||
|
|
||||||
|
## 2. Issue模板
|
||||||
|
|
||||||
|
### 2.1 Defect报告模板
|
||||||
|
```
|
||||||
|
## 问题描述
|
||||||
|
[简要描述问题]
|
||||||
|
|
||||||
|
## 重现步骤
|
||||||
|
1. [步骤1]
|
||||||
|
2. [步骤2]
|
||||||
|
3. [步骤3]
|
||||||
|
|
||||||
|
## 环境信息
|
||||||
|
- 硬件平台: H100核心板
|
||||||
|
- 温度环境: [实际温度]
|
||||||
|
- 软件版本: [版本号]
|
||||||
|
|
||||||
|
## 预期结果
|
||||||
|
[期望的行为]
|
||||||
|
|
||||||
|
## 实际结果
|
||||||
|
[实际的行为]
|
||||||
|
|
||||||
|
## 附件
|
||||||
|
[截图、日志等]
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2.2 Feature请求模板
|
||||||
|
```
|
||||||
|
## 业务价值
|
||||||
|
[说明此功能的业务价值]
|
||||||
|
|
||||||
|
## 功能描述
|
||||||
|
[详细功能描述]
|
||||||
|
|
||||||
|
## 技术方案
|
||||||
|
[建议的技术实现方案]
|
||||||
|
|
||||||
|
## 验收标准
|
||||||
|
- [标准1]
|
||||||
|
- [标准2]
|
||||||
|
- [标准3]
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2.3 任务模板
|
||||||
|
```
|
||||||
|
## 任务描述
|
||||||
|
[任务详细描述]
|
||||||
|
|
||||||
|
## 负责人
|
||||||
|
[负责人姓名]
|
||||||
|
|
||||||
|
## 截止日期
|
||||||
|
[YYYY-MM-DD]
|
||||||
|
|
||||||
|
## 依赖关系
|
||||||
|
- [依赖任务1]
|
||||||
|
- [依赖任务2]
|
||||||
|
|
||||||
|
## 验收标准
|
||||||
|
[具体的验收标准]
|
||||||
|
```
|
||||||
|
|
||||||
|
## 3. 工作流程规范
|
||||||
|
|
||||||
|
### 3.1 Defect创建和分配流程
|
||||||
|
1. 任何人发现Defect都可以创建Issue
|
||||||
|
2. 项目经理根据模块标签分配给相应负责人
|
||||||
|
3. 负责人确认后更新状态为`in-progress`
|
||||||
|
|
||||||
|
### 3.2 状态转换规则
|
||||||
|
- `in-review` → `in-progress`: 负责人开始处理
|
||||||
|
- `in-progress` → `testing`: 开发完成,提交代码
|
||||||
|
- `testing` → `resolved`: 测试通过,问题解决
|
||||||
|
|
||||||
|
### 3.3 代码提交关联规范
|
||||||
|
- 提交信息必须包含Issue编号,格式: `fix #123`
|
||||||
|
- 相关代码文件必须有适当的注释说明
|
||||||
|
|
||||||
|
### 3.4 评审和关闭标准
|
||||||
|
- Critical/High级别Defect必须经过代码评审
|
||||||
|
- 所有Defect必须有对应的测试用例
|
||||||
|
- 关闭前必须验证在极端环境(-40℃~85℃)下的稳定性
|
||||||
|
|
||||||
|
## 4. 团队协作要求
|
||||||
|
|
||||||
|
### 4.1 新成员培训
|
||||||
|
- 入职时必须学习本规范
|
||||||
|
- 第一个任务必须在导师指导下完成
|
||||||
|
|
||||||
|
### 4.2 日常维护
|
||||||
|
- 每日站会检查高优先级Defect状态
|
||||||
|
- 每周清理已解决的Issue
|
||||||
|
- 每月回顾Defect趋势,优化开发流程
|
||||||
|
|
||||||
|
### 4.3 质量保证
|
||||||
|
- Critical Defect 24小时内响应
|
||||||
|
- High Defect 3天内解决
|
||||||
|
- Medium/Low Defect 在下一个里程碑前解决
|
||||||
|
|
||||||
|
---
|
||||||
|
**本规范自发布之日起生效,所有团队成员必须遵守。**
|
||||||
|
|
@ -0,0 +1,122 @@
|
||||||
|
# AI-Box设计评审流程规范
|
||||||
|
|
||||||
|
## 1. 设计评审适用范围
|
||||||
|
|
||||||
|
### 必须进行正式设计评审的重要设计结果:
|
||||||
|
- **系统架构设计方案** (孙大圣负责)
|
||||||
|
- **产品需求规格书(PRD)** (猪小杰负责)
|
||||||
|
- **核心模块详细设计文档**
|
||||||
|
- **接口定义和协议规范**
|
||||||
|
- **电源管理策略设计**
|
||||||
|
- **安全性和可靠性设计方案**
|
||||||
|
|
||||||
|
### 可以简化评审的常规设计:
|
||||||
|
- **工具脚本和辅助程序**
|
||||||
|
- **非核心功能模块设计**
|
||||||
|
- **文档格式和排版调整**
|
||||||
|
|
||||||
|
## 2. 飞书审批流集成方案
|
||||||
|
|
||||||
|
### 2.1 审批流配置需求
|
||||||
|
由于当前飞书应用权限限制,需要申请以下审批流相关权限:
|
||||||
|
- `approval:approval_instance` - 审批实例管理
|
||||||
|
- `approval:approval_template` - 审批模板管理
|
||||||
|
|
||||||
|
### 2.2 临时审批流程(当前可用)
|
||||||
|
在获得完整审批权限前,采用以下临时流程:
|
||||||
|
|
||||||
|
#### 步骤1: 文档创建与初审
|
||||||
|
- 设计者在飞书云文档中创建设计文档
|
||||||
|
- 在文档开头添加 **【设计评审】** 标识
|
||||||
|
- @相关评审人员进行初步技术评审
|
||||||
|
|
||||||
|
#### 步骤2: 评审会议组织
|
||||||
|
- 在 **04 项目会议** 文件夹中创建评审会议
|
||||||
|
- 邀请所有相关干系人参加
|
||||||
|
- 会议议程包含:设计介绍、问题讨论、决策确认
|
||||||
|
|
||||||
|
#### 步骤3: 评审结果记录
|
||||||
|
- 在会议文档中记录评审结论
|
||||||
|
- 明确标注:**通过/有条件通过/不通过**
|
||||||
|
- 列出所有需要修改的问题项和负责人
|
||||||
|
|
||||||
|
#### 步骤4: 文档更新与确认
|
||||||
|
- 设计者根据评审意见修改文档
|
||||||
|
- 在文档修订历史中记录修改内容
|
||||||
|
- 评审人员确认修改后,在评论区回复 **【确认通过】**
|
||||||
|
|
||||||
|
### 2.3 正式审批流流程(权限开通后)
|
||||||
|
一旦获得审批流权限,将升级为正式审批流程:
|
||||||
|
|
||||||
|
#### 自动化审批触发
|
||||||
|
- 设计文档保存时自动触发审批流
|
||||||
|
- 系统自动识别文档类型并分配相应审批人
|
||||||
|
- 审批流包含:技术评审 → 架构评审 → 项目经理确认 → 最终批准
|
||||||
|
|
||||||
|
#### 审批状态跟踪
|
||||||
|
- 实时显示审批进度
|
||||||
|
- 超时自动提醒审批人
|
||||||
|
- 审批历史完整记录
|
||||||
|
|
||||||
|
## 3. 评审角色与职责
|
||||||
|
|
||||||
|
### 3.1 评审委员会组成
|
||||||
|
| 角色 | 人员 | 职责 |
|
||||||
|
|------|------|------|
|
||||||
|
| **技术评审员** | 孙大圣 | 技术可行性、架构合理性 |
|
||||||
|
| **产品评审员** | 猪小杰 | 需求符合度、用户体验 |
|
||||||
|
| **项目经理** | 唐小僧 | 进度影响、资源协调 |
|
||||||
|
| **质量保证** | 测试团队 | 可测试性、质量标准 |
|
||||||
|
|
||||||
|
### 3.2 评审标准
|
||||||
|
- **技术先进性**: 是否采用合适的技术方案
|
||||||
|
- **需求符合度**: 是否完全满足产品需求
|
||||||
|
- **可实施性**: 开发团队是否具备实施能力
|
||||||
|
- **可维护性**: 后续维护和扩展的便利性
|
||||||
|
- **风险可控性**: 技术风险是否在可接受范围内
|
||||||
|
|
||||||
|
## 4. 评审流程执行细节
|
||||||
|
|
||||||
|
### 4.1 评审准备
|
||||||
|
- **提前通知**: 评审前至少24小时通知评审人员
|
||||||
|
- **材料准备**: 提供完整的背景资料和参考文档
|
||||||
|
- **环境准备**: 确保演示环境和测试数据就绪
|
||||||
|
|
||||||
|
### 4.2 评审会议
|
||||||
|
- **时间控制**: 单次评审会议不超过2小时
|
||||||
|
- **议题聚焦**: 严格按照议程进行,避免偏离主题
|
||||||
|
- **记录完整**: 指定专人记录会议要点和决策
|
||||||
|
|
||||||
|
### 4.3 评审后续
|
||||||
|
- **问题跟踪**: 所有问题必须有明确的解决计划
|
||||||
|
- **状态更新**: 每周更新评审问题的解决进度
|
||||||
|
- **闭环验证**: 问题解决后必须进行验证确认
|
||||||
|
|
||||||
|
## 5. Gitea与飞书协同机制
|
||||||
|
|
||||||
|
### 5.1 双向同步规则
|
||||||
|
- **飞书为主**: 设计文档以飞书版本为准
|
||||||
|
- **Gitea备份**: 评审通过的最终版本必须同步到Gitea
|
||||||
|
- **版本对应**: 飞书文档版本号与Gitea提交哈希对应
|
||||||
|
|
||||||
|
### 5.2 同步时机
|
||||||
|
- **评审前**: 在飞书创建和编辑文档
|
||||||
|
- **评审后**: 评审通过24小时内同步到Gitea
|
||||||
|
- **重大变更**: 任何重大修改都需要重新评审
|
||||||
|
|
||||||
|
## 6. 应急处理机制
|
||||||
|
|
||||||
|
### 6.1 紧急设计决策
|
||||||
|
对于紧急情况下的设计决策:
|
||||||
|
- **快速通道**: 项目经理可授权临时决策
|
||||||
|
- **事后补审**: 72小时内必须补办正式评审
|
||||||
|
- **风险评估**: 必须记录决策的风险和应对措施
|
||||||
|
|
||||||
|
### 6.2 评审争议处理
|
||||||
|
当评审出现重大分歧时:
|
||||||
|
- **升级机制**: 提交给更高层级决策
|
||||||
|
- **专家咨询**: 邀请外部专家提供意见
|
||||||
|
- **原型验证**: 通过快速原型验证方案可行性
|
||||||
|
|
||||||
|
---
|
||||||
|
**本规范自发布之日起生效,所有重要设计结果必须遵循此评审流程。项目经理负责监督执行,并根据实际运行情况进行优化调整。**
|
||||||
|
|
@ -0,0 +1,22 @@
|
||||||
|
# 智能挂车AI-Box详细项目开发计划
|
||||||
|
|
||||||
|
## 项目概述
|
||||||
|
开发商用车AI-Box Demo,验证智能挂车方案原型。
|
||||||
|
|
||||||
|
## 关键里程碑
|
||||||
|
- **M1-需求确认**: 3/8 - 正式PRD文档
|
||||||
|
- **M2-架构完成**: 3/15 - 系统架构方案
|
||||||
|
- **M3-核心开发**: 3/29 - 核心功能模块
|
||||||
|
- **M4-集成测试**: 4/5 - 集成测试报告
|
||||||
|
- **M5-Demo交付**: 4/12 - AI-Box Demo
|
||||||
|
|
||||||
|
## 主要任务分配
|
||||||
|
- **猪小杰**: 需求定义和PRD管理
|
||||||
|
- **孙大圣**: 软件架构设计和实现
|
||||||
|
- **季增超**: SoC软件开发和测试
|
||||||
|
- **刘彬彬**: MCU软件开发和测试
|
||||||
|
- **丁海军**: MCU代码评审支持
|
||||||
|
- **孙凯瑾**: 硬件架构和系统设计
|
||||||
|
- **唐小僧**: 项目管理和协调
|
||||||
|
|
||||||
|
完整详细计划请参考飞书文档: https://feishu.cn/docx/LYvHd7ejUo2EDdxEsBKcZ17Snya
|
||||||
|
|
@ -0,0 +1,156 @@
|
||||||
|
# 智能挂车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
|
||||||
|
|
||||||
|
|
||||||
|
### 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 沟通规范
|
||||||
|
- **工作群**: 日常沟通和紧急问题
|
||||||
|
- **文档**: 正式决策和详细说明
|
||||||
|
- **会议**: 重要讨论和决策制定
|
||||||
|
- **一对一**: 敏感问题和深度技术讨论
|
||||||
|
|
||||||
|
---
|
||||||
|
**本规范自发布之日起生效,所有团队成员必须遵守。项目经理负责监督执行,并根据项目实际情况进行适时调整。**
|
||||||
|
|
@ -0,0 +1,54 @@
|
||||||
|
# 商用车AI-Box系统需求规格说明书
|
||||||
|
|
||||||
|
## 1. 核心目标
|
||||||
|
### 1.1 低功耗设计
|
||||||
|
- **整机功耗**:≤15W(待验证)
|
||||||
|
- **休眠功耗**:≤2W
|
||||||
|
- **电源管理**:支持多级休眠模式(深度休眠/待机/工作)
|
||||||
|
|
||||||
|
### 1.2 国产化适配
|
||||||
|
- **主控芯片**:瑞芯微RK3588/RK3568(优先)或华为昇腾310
|
||||||
|
- **操作系统**:OpenHarmony 4.0+ 或 麒麟V10
|
||||||
|
- **AI框架**:MindSpore Lite 或 Paddle Lite
|
||||||
|
|
||||||
|
### 1.3 高集成度
|
||||||
|
- **接口密度**:单设备支持≥8路视频输入
|
||||||
|
- **扩展能力**:预留CAN总线、4G/5G模组、GNSS接口
|
||||||
|
- **结构设计**:IP67防护等级,-40℃~85℃工作温度
|
||||||
|
|
||||||
|
## 2. 功能需求
|
||||||
|
### 2.1 视频处理
|
||||||
|
- 支持H.265/H.264编码
|
||||||
|
- 实时视频分析(ADAS/DSM/DMS)
|
||||||
|
- 事件触发录像(碰撞/急刹/车道偏离)
|
||||||
|
|
||||||
|
### 2.2 通信能力
|
||||||
|
- 4G/5G远程数据传输
|
||||||
|
- V2X通信(预留DSRC/C-V2X接口)
|
||||||
|
- 蓝牙/WiFi近场配置
|
||||||
|
|
||||||
|
### 2.3 数据存储
|
||||||
|
- 本地存储:≥64GB eMMC
|
||||||
|
- 循环覆盖策略:保留最近7天数据
|
||||||
|
- 加密存储:国密SM4算法
|
||||||
|
|
||||||
|
## 3. 非功能需求
|
||||||
|
### 3.1 可靠性
|
||||||
|
- MTBF ≥50,000小时
|
||||||
|
- 抗振动:符合ISO 16750-3标准
|
||||||
|
- 电磁兼容:GB/T 18655 Class 3
|
||||||
|
|
||||||
|
### 3.2 环境适应性
|
||||||
|
- 工作温度:-40℃ ~ +85℃
|
||||||
|
- 存储温度:-40℃ ~ +95℃
|
||||||
|
- 湿度范围:5%~95% RH(无凝露)
|
||||||
|
|
||||||
|
### 3.3 安全性
|
||||||
|
- 启动安全:Secure Boot
|
||||||
|
- 运行安全:TEE可信执行环境
|
||||||
|
- 数据安全:国密SM2/SM9证书体系
|
||||||
|
|
||||||
|
## 4. 验证标准
|
||||||
|
- 符合JT/T 1076-2016《道路运输车辆卫星定位系统车载终端技术要求》
|
||||||
|
- 通过CCC认证及EMC测试
|
||||||
|
- 满足GB/T 28046.1-2019道路车辆电气电子环境要求
|
||||||
|
|
@ -0,0 +1,155 @@
|
||||||
|
# 商用车AI-Box Demo - 产品需求规格书(v2.0)
|
||||||
|
|
||||||
|
**版本**:v2.0
|
||||||
|
**日期**:2026-03-04
|
||||||
|
**产品经理**:猪小杰
|
||||||
|
**项目经理**:徐工
|
||||||
|
**对接人**:孙凯瑾
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. 文档修订记录
|
||||||
|
|
||||||
|
| 时间 | 版本 | 作者 | 变更内容 |
|
||||||
|
|------|------|------|----------|
|
||||||
|
| 2026-03-04 | v1.0 | 猪小杰 | 初稿,整合飞书需求、Gitea架构、IPCL通信、电源设计文档 |
|
||||||
|
| 2026-03-04 | v2.0 | 猪小杰 | **重大更新**:移除F1本地大模型,调整为云端API + Trailer Agent架构 |
|
||||||
|
|
||||||
|
## 2. 项目背景
|
||||||
|
|
||||||
|
### 2.1 产品目标
|
||||||
|
打造一款面向商用车场景的AI域控制器Demo,聚焦**低功耗、低成本、高集成度、国产化适配**四大核心目标。
|
||||||
|
|
||||||
|
### 2.2 技术架构调整
|
||||||
|
- **原架构**:MCU + SoC + F1(本地大模型推理)
|
||||||
|
- **新架构**:MCU + SoC + 云端大模型API
|
||||||
|
- **核心组件**:Trailer Agent(挂车数据专家,本地部署)
|
||||||
|
- **协同模式**:本地Trailer Agent与云端AI协同,实现挂车本地化智能化管理
|
||||||
|
|
||||||
|
### 2.3 技术平台
|
||||||
|
- **核心芯片**:SoC(具体型号待确认)
|
||||||
|
- **系统架构**:双核异构(MCU电源管理 + SoC逻辑控制)
|
||||||
|
- **工作温度**:-40℃ ~ 85℃
|
||||||
|
- **物理规格**:60mm × 60mm,50g
|
||||||
|
|
||||||
|
## 3. 功能需求
|
||||||
|
|
||||||
|
### 3.1 核心功能(优先级排序)
|
||||||
|
|
||||||
|
#### 🔴 P0 - 传感器数据融合(优先实现)
|
||||||
|
- **传感器接入**:支持多种传感器数据采集
|
||||||
|
- **数据融合**:多源传感器数据融合处理
|
||||||
|
- **云端上传**:将融合数据上传到云端服务器
|
||||||
|
- **展示接口**:通过web和app展示数据结果
|
||||||
|
|
||||||
|
#### 🟡 P1 - 图像识别
|
||||||
|
- **摄像头接入**:连接摄像头,采集图像
|
||||||
|
- **物体识别**:CNN模型识别物体类型
|
||||||
|
- **数据通路**:演示传感器数据通路及CNN模型
|
||||||
|
|
||||||
|
#### 🟢 P2 - Trailer Agent(挂车数据专家)
|
||||||
|
- **本地部署**:在AI-Box SoC上部署Trailer Agent
|
||||||
|
- **数据专家**:作为挂车领域数据专家,处理本地智能决策
|
||||||
|
- **云端协同**:与云端大模型API协同工作
|
||||||
|
- **智能管理**:实现挂车的本地化智能化管理
|
||||||
|
|
||||||
|
#### 🔵 P3 - 云端大模型API集成
|
||||||
|
- **API接入**:通过网络API调用云端大模型服务
|
||||||
|
- **数据同步**:与云端保持数据同步
|
||||||
|
- **智能增强**:利用云端大模型能力增强本地智能
|
||||||
|
|
||||||
|
### 3.2 系统服务
|
||||||
|
- **电源管理**:四级电源模式(运行/休眠/低功耗/关机)
|
||||||
|
- **健康监控**:SoC状态监测,异常自动复位
|
||||||
|
- **故障恢复**:通信失效时GPIO强制复位
|
||||||
|
|
||||||
|
## 4. 系统架构
|
||||||
|
|
||||||
|
### 4.1 分层架构
|
||||||
|
```
|
||||||
|
┌─────────────────┐
|
||||||
|
│ 应用层 │ ← Trailer Agent、传感器融合、图像识别、云端API
|
||||||
|
├─────────────────┤
|
||||||
|
│ 框架层 │ ← 通信中间件、推理引擎、模型管理
|
||||||
|
├─────────────────┤
|
||||||
|
│ 驱动层 │ ← MCU电源管理、SoC Linux驱动
|
||||||
|
└─────────────────┘
|
||||||
|
```
|
||||||
|
|
||||||
|
### 4.2 芯片间通信
|
||||||
|
- **MCU ↔ SoC**:SPI(10Mbps) + UART(1Mbps) + GPIO(复位)
|
||||||
|
- **SoC ↔ 云端**:网络API(4G/5G/WiFi/Ethernet)
|
||||||
|
|
||||||
|
## 5. 通信协议规范
|
||||||
|
|
||||||
|
### 5.1 SPI通信协议
|
||||||
|
- **速率**:≥10Mbps
|
||||||
|
- **包长**:≤512字节
|
||||||
|
- **校验**:CRC校验
|
||||||
|
- **命令类型**:
|
||||||
|
- `0x01` POWER_MODE_REQ(电源模式请求)
|
||||||
|
- `0x02` POWER_MODE_ACK(电源模式确认)
|
||||||
|
- `0x03` DATA_TRANSFER(数据传输)
|
||||||
|
- `0x05` STATUS_REPORT(状态报告)
|
||||||
|
|
||||||
|
### 5.2 UART通信协议
|
||||||
|
- **速率**:≥1Mbps
|
||||||
|
- **用途**:SoC健康状态监测(CPU/内存/外设状态)
|
||||||
|
- **超时机制**:3个周期无响应 → GPIO强制复位
|
||||||
|
|
||||||
|
### 5.3 GPIO通信协议
|
||||||
|
- **信号**:RESET_N(低电平有效)
|
||||||
|
- **持续时间**:≥100ms
|
||||||
|
- **使用场景**:SPI/UART失效、SoC无响应、严重故障
|
||||||
|
|
||||||
|
## 6. 电源管理策略
|
||||||
|
|
||||||
|
### 6.1 四级电源模式
|
||||||
|
|
||||||
|
| 模式 | SoC状态 | MCU状态 | 功耗 | 唤醒时间 |
|
||||||
|
|------|---------|---------|------|----------|
|
||||||
|
| 运行模式 | 全功率运行 | 正常监控 | ~10W | 0ms |
|
||||||
|
| 休眠模式 | 降频运行 | 正常监控 | ~2W | 100ms |
|
||||||
|
| 低功耗模式 | 深度睡眠 | 低功耗监控 | ~0.5W | 500ms |
|
||||||
|
| 关机模式 | 完全关闭 | 超低功耗 | ~0.1W | 2000ms |
|
||||||
|
|
||||||
|
### 6.2 唤醒源管理
|
||||||
|
- **最高优先级**:钥匙启动(关机模式唤醒)
|
||||||
|
- **高优先级**:远程唤醒(所有模式)
|
||||||
|
- **中优先级**:传感器触发(休眠/低功耗模式)
|
||||||
|
- **低优先级**:定时唤醒(休眠/低功耗模式)
|
||||||
|
|
||||||
|
## 7. 验收标准
|
||||||
|
|
||||||
|
### 7.1 功能验收
|
||||||
|
- [ ] 传感器数据融合:多源数据融合准确率 ≥ 95%
|
||||||
|
- [ ] 图像识别:物体识别准确率 ≥ 95%
|
||||||
|
- [ ] Trailer Agent:本地智能决策响应时间 ≤ 100ms
|
||||||
|
- [ ] 云端API:大模型API调用成功率 ≥ 99%
|
||||||
|
- [ ] 电源切换:四级模式切换成功率 100%
|
||||||
|
|
||||||
|
### 7.2 性能验收
|
||||||
|
- [ ] 工作温度:-40℃ ~ 85℃稳定运行
|
||||||
|
- [ ] 功耗指标:各模式功耗符合设计规格
|
||||||
|
- [ ] 通信可靠性:SPI/UART误码率 ≤ 10⁻⁶
|
||||||
|
- [ ] 网络延迟:云端API响应时间 ≤ 500ms
|
||||||
|
|
||||||
|
### 7.3 可靠性验收
|
||||||
|
- [ ] 故障恢复:SoC异常复位时间 ≤ 3秒
|
||||||
|
- [ ] 环境测试:通过高低温、振动、EMC车规级测试
|
||||||
|
|
||||||
|
## 8. 后续工作计划
|
||||||
|
|
||||||
|
- [ ] 3月10日前:完成详细接口规范定义(重点:传感器融合接口)
|
||||||
|
- [ ] 3月20日前:驱动开发和调试(MCU-SoC通信驱动)
|
||||||
|
- [ ] 3月25日前:Trailer Agent原型开发
|
||||||
|
- [ ] 3月30日前:传感器数据融合功能实现
|
||||||
|
- [ ] 4月10日前:云端API集成和端到端系统联调
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
> **备注**:本文档基于以下资料整合:
|
||||||
|
> 1. 《商用车AI-Box Demo开发需求》(飞书文档,v2.0)
|
||||||
|
> 2. 《AI-Box智能终端IPCL设计文档》
|
||||||
|
> 3. 《AI-Box智能终端电源设计文档》
|
||||||
|
> 4. 客户最新需求澄清:云端大模型API + Trailer Agent架构
|
||||||
|
|
@ -0,0 +1,73 @@
|
||||||
|
# 智能挂车AI-Box团队成员分工表
|
||||||
|
|
||||||
|
## 团队角色与职责
|
||||||
|
|
||||||
|
### 真人成员
|
||||||
|
|
||||||
|
| 成员 | 角色 | 主要职责 | 协作方式 |
|
||||||
|
|------|------|----------|----------|
|
||||||
|
| 徐祖龙 | 产品线总监 | 总体管理,监控监督交付 | 决策审批,进度监督 |
|
||||||
|
| 孙凯瑾 | 硬件专家 | 系统架构和硬件设计 | 技术方案,硬件验证 |
|
||||||
|
| 季增超 | SoC软件工程师 | SoC软件设计和编码测试 | SoC开发,集成测试 |
|
||||||
|
| 刘彬彬 | MCU软件工程师 | MCU软件设计和编码测试 | MCU开发,电源管理 |
|
||||||
|
| 丁海军 | 软件工程师 | 评审和支持刘彬彬的开发工作 | 代码评审,技术支援 |
|
||||||
|
| 潘定海 | 研究院院长 | 代表公司和董事会进行技术决策 | 重大决策,技术方向 |
|
||||||
|
|
||||||
|
### AI Agent成员
|
||||||
|
|
||||||
|
| Agent | 角色 | 主要职责 | 协作方式 |
|
||||||
|
|-------|------|----------|----------|
|
||||||
|
| 唐小僧 (emb-pm) | 项目经理 | 项目交付管理,协调资源和分工,管控开发进度 | 项目协调,进度跟踪,风险管理 |
|
||||||
|
| 猪小杰 (emb-system) | 产品经理 | 产品定义和需求开发,回答需求问题 | 需求管理,PRD编写,需求澄清 |
|
||||||
|
| 孙大圣 (emb-arch) | 软件架构师 | 软件架构设计和实现 | 架构设计,技术方案,代码指导 |
|
||||||
|
|
||||||
|
## 协作机制
|
||||||
|
|
||||||
|
### 沟通渠道
|
||||||
|
- **飞书工作群**: 日常沟通和紧急问题 (chat_id: oc_429193eeffe847ff7bc2da2f062d640e)
|
||||||
|
- **Gitea Issues**: 任务跟踪和Defect管理
|
||||||
|
- **飞书文档**: 计划、规范和成果物归档
|
||||||
|
- **Agent-to-Agent**: AI agent间的技术讨论
|
||||||
|
|
||||||
|
### 工作流程
|
||||||
|
1. **需求阶段**: 猪小杰收集需求 → 徐祖龙确认 → 孙大圣架构设计
|
||||||
|
2. **开发阶段**: 季增超(SoC) + 刘彬彬(MCU)开发 → 丁海军评审支持
|
||||||
|
3. **测试阶段**: 全体参与集成测试 → 孙凯瑾硬件验证
|
||||||
|
4. **交付阶段**: 唐小僧协调Demo准备 → 潘定海技术决策
|
||||||
|
|
||||||
|
### 决策机制
|
||||||
|
- **技术决策**: 孙凯瑾(硬件) + 孙大圣(软件) + 相关工程师
|
||||||
|
- **需求决策**: 猪小杰 + 徐祖龙
|
||||||
|
- **项目决策**: 唐小僧 + 徐祖龙
|
||||||
|
- **重大决策**: 潘定海院长最终决定
|
||||||
|
|
||||||
|
## 关键协作原则
|
||||||
|
|
||||||
|
### 透明沟通
|
||||||
|
- 所有讨论和决策都要有记录
|
||||||
|
- 问题要及时暴露,不隐瞒
|
||||||
|
- 信息要在团队内充分共享
|
||||||
|
|
||||||
|
### 高效协作
|
||||||
|
- AI agent提供7x24执行能力
|
||||||
|
- 真人员工提供专业判断和深度技术能力
|
||||||
|
- 人机协同,发挥各自优势
|
||||||
|
|
||||||
|
### 质量保证
|
||||||
|
- 所有代码必须通过评审
|
||||||
|
- 所有设计必须通过评审
|
||||||
|
- 所有成果物必须及时归档
|
||||||
|
|
||||||
|
## 联系方式
|
||||||
|
|
||||||
|
### 飞书账号
|
||||||
|
- 所有AI agent都借用徐祖龙的飞书账号
|
||||||
|
- 真人员工使用各自的飞书账号
|
||||||
|
|
||||||
|
### 紧急联系
|
||||||
|
- **项目阻塞问题**: 立即联系唐小僧(项目经理)
|
||||||
|
- **需求问题**: 联系猪小杰(产品经理)
|
||||||
|
- **技术问题**: 联系孙大圣(架构师)或相关工程师
|
||||||
|
|
||||||
|
---
|
||||||
|
**本分工表自发布之日起生效,所有团队成员必须遵守。如有疑问,请及时与项目经理唐小僧沟通。**
|
||||||
Loading…
Reference in New Issue