diff --git a/docs/planning/MARCH_2026_KEY_WORK_PLAN.md b/docs/planning/MARCH_2026_KEY_WORK_PLAN.md
new file mode 100644
index 0000000..00be72f
--- /dev/null
+++ b/docs/planning/MARCH_2026_KEY_WORK_PLAN.md
@@ -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核心板开发套件及时到位
\ No newline at end of file
diff --git a/docs/project/CONFIGURATION_MANAGEMENT.md b/docs/project/CONFIGURATION_MANAGEMENT.md
new file mode 100644
index 0000000..74e6594
--- /dev/null
+++ b/docs/project/CONFIGURATION_MANAGEMENT.md
@@ -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流程
+- 重要功能必须有对应的文档更新
\ No newline at end of file
diff --git a/docs/project/DEFECT_MANAGEMENT.md b/docs/project/DEFECT_MANAGEMENT.md
new file mode 100644
index 0000000..bf3c1df
--- /dev/null
+++ b/docs/project/DEFECT_MANAGEMENT.md
@@ -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 在下一个里程碑前解决
+
+---
+**本规范自发布之日起生效，所有团队成员必须遵守。**
\ No newline at end of file
diff --git a/docs/project/DESIGN_REVIEW_PROCESS.md b/docs/project/DESIGN_REVIEW_PROCESS.md
new file mode 100644
index 0000000..1174ced
--- /dev/null
+++ b/docs/project/DESIGN_REVIEW_PROCESS.md
@@ -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 评审争议处理
+当评审出现重大分歧时：
+- **升级机制**: 提交给更高层级决策
+- **专家咨询**: 邀请外部专家提供意见
+- **原型验证**: 通过快速原型验证方案可行性
+
+---
+**本规范自发布之日起生效，所有重要设计结果必须遵循此评审流程。项目经理负责监督执行，并根据实际运行情况进行优化调整。**
\ No newline at end of file
diff --git a/docs/project/DETAILED_PROJECT_PLAN.md b/docs/project/DETAILED_PROJECT_PLAN.md
new file mode 100644
index 0000000..a97fc7e
--- /dev/null
+++ b/docs/project/DETAILED_PROJECT_PLAN.md
@@ -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
diff --git a/docs/project/TEAM_CULTURE_AND_DEVELOPMENT_GUIDELINES.md b/docs/project/TEAM_CULTURE_AND_DEVELOPMENT_GUIDELINES.md
new file mode 100644
index 0000000..7e52169
--- /dev/null
+++ b/docs/project/TEAM_CULTURE_AND_DEVELOPMENT_GUIDELINES.md
@@ -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 沟通规范
+- **工作群**: 日常沟通和紧急问题
+- **文档**: 正式决策和详细说明
+- **会议**: 重要讨论和决策制定
+- **一对一**: 敏感问题和深度技术讨论
+
+---
+**本规范自发布之日起生效，所有团队成员必须遵守。项目经理负责监督执行，并根据项目实际情况进行适时调整。**
\ No newline at end of file
diff --git a/docs/requirements/SYSTEM_REQUIREMENTS.md b/docs/requirements/SYSTEM_REQUIREMENTS.md
new file mode 100644
index 0000000..87234d5
--- /dev/null
+++ b/docs/requirements/SYSTEM_REQUIREMENTS.md
@@ -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道路车辆电气电子环境要求
\ No newline at end of file
diff --git a/docs/specs/商用车AI-Box-Demo-产品需求规格书-v2.0.md b/docs/specs/商用车AI-Box-Demo-产品需求规格书-v2.0.md
new file mode 100644
index 0000000..0e1e267
--- /dev/null
+++ b/docs/specs/商用车AI-Box-Demo-产品需求规格书-v2.0.md
@@ -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架构
\ No newline at end of file
diff --git a/docs/team/TEAM_ROLES_AND_RESPONSIBILITIES.md b/docs/team/TEAM_ROLES_AND_RESPONSIBILITIES.md
new file mode 100644
index 0000000..a63bb48
--- /dev/null
+++ b/docs/team/TEAM_ROLES_AND_RESPONSIBILITIES.md
@@ -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都借用徐祖龙的飞书账号
+- 真人员工使用各自的飞书账号
+
+### 紧急联系
+- **项目阻塞问题**: 立即联系唐小僧(项目经理)
+- **需求问题**: 联系猪小杰(产品经理)
+- **技术问题**: 联系孙大圣(架构师)或相关工程师
+
+---
+**本分工表自发布之日起生效，所有团队成员必须遵守。如有疑问，请及时与项目经理唐小僧沟通。**
\ No newline at end of file