CSDN专栏：

• 嵌入式程序开发实战
• 嵌入式双范式AI编程
• 嵌入式开发必掌握
• 嵌入式求职面试技术资料

第5讲：嵌入式场景二范式决策树：什么情况快写、什么情况严写

开篇：为什么需要决策树？

在实际开发中，很多工程师会困惑：

• 这个项目应该用Vibe还是Spec？
• 这个驱动应该快写还是严写？
• 这个功能应该追求速度还是质量？

错误的做法：

• ❌ 全部用Vibe：代码质量差，无法量产
• ❌ 全部用Spec：开发速度慢，效率低
• ❌ 随意混用：代码风格混乱，难以维护

正确的做法：

• ✅ 根据场景选择范式
• ✅ 使用决策树指导决策
• ✅ Vibe和Spec有机结合

一、二范式决策树

1.1 主决策树

1.2 决策树详解

第一层：是否需要量产？

判断标准：

• 是否需要批量生产？
• 是否需要长期使用？
• 是否需要客户交付？

选择Vibe的情况：

• 实验室原型
• 概念验证
• 学习实验
• 临时测试

选择Spec的情况：

• 量产产品
• 客户项目
• 长期使用
• 商业交付

第二层：是否安全关键？

判断标准：

• 失效是否危及人身安全？
• 失效是否造成重大损失？
• 是否有SIL等级要求？
• 是否需要安全认证？

选择Spec的情况：

• 轨交设备（SIL2/SIL3/SIL4）
• 工控设备（SIL1/SIL2）
• 医疗设备（IEC 62304）
• 汽车电子（ISO 26262）

第三层：是否长期维护？

判断标准：

• 是否需要长期维护？
• 是否有团队协作？
• 是否需要版本管理？
• 是否需要文档交付？

选择Spec的情况：

• 长期维护项目
• 团队协作项目
• 需要交接的项目
• 需要文档的项目

第四层：开发时间是否紧张？

判断标准：

• 是否有紧急截止日期？
• 是否可以先交付后优化？
• 是否可以接受后续重构？

选择Vibe的情况：

• 时间非常紧张
• 可以后续优化
• 快速验证优先

选择Spec的情况：

• 时间充裕
• 一次性做对
• 质量优先

二、典型场景决策

2.1 按项目类型决策

2.2 按开发阶段决策

2.3 按代码类型决策

三、混合使用策略

3.1 Vibe→Spec转换策略

最优策略：Vibe探路 + Spec定型

开发流程：

时间对比：

效率提升：2.2倍

3.2 分模块混合策略

策略：不同模块使用不同范式

项目结构：

项目结构： ├── drivers/ # 驱动层 │ ├── i2c/ # I2C驱动（Spec） │ ├── spi/ # SPI驱动（Spec） │ └── sensor/ # 传感器驱动（Vibe→Spec） ├── middleware/ # 中间层 │ ├── protocol/ # 通信协议（Spec） │ └── algorithm/ # 算法（Spec） ├── application/ # 应用层 │ ├── task/ # RTOS任务（Spec） │ └── logic/ # 业务逻辑（Spec） └── test/ # 测试代码 └── debug/ # 调试代码（Vibe）

决策原则：

• 底层驱动：Spec（稳定可靠）
• 中间层：Spec（可维护）
• 应用层：Spec（业务关键）
• 测试代码：Vibe（临时使用）

3.3 分阶段混合策略

策略：不同阶段使用不同范式

阶段1：原型开发（Vibe）

• 目标：快速验证可行性
• 范式：Vibe
• 产出：可运行的Demo

阶段2：功能完善（Vibe→Spec）

• 目标：完善功能，提升质量
• 范式：逐步转换为Spec
• 产出：功能完整的代码

阶段3：量产准备（Spec）

• 目标：准备量产，完善文档
• 范式：Spec
• 产出：可量产的代码

阶段4：维护迭代（Spec）

• 目标：长期维护，持续改进
• 范式：Spec
• 产出：可维护的代码

四、决策树实战案例

案例一：毕设项目

项目背景：

• 项目：智能温控系统
• 要求：演示功能 + 撰写论文
• 时间：3个月
• 团队：个人项目

决策分析：

Q1：是否需要量产？

• 答：否（毕设演示为主）
• 推导：倾向Vibe

Q2：是否需要长期维护？

• 答：否（毕设结束后不需要）
• 推导：倾向Vibe

Q3：是否有论文要求？

• 答：是（需要撰写论文）
• 推导：倾向Spec（提升工整度）

最终决策：Vibe+Spec混合

实施方案：

阶段1（1个月）：Vibe快速实现

• 快速搭建硬件平台
• 快速实现基本功能
• 快速验证可行性
• 产出：可运行的Demo

阶段2（1个月）：Spec提升质量

• 提炼规格文档
• 重写关键代码
• 完善错误处理
• 产出：高质量代码

阶段3（1个月）：文档撰写

• 撰写论文
• 整理代码注释
• 准备答辩材料
• 产出：完整毕设材料

时间分配：

• Vibe开发：30%
• Spec优化：40%
• 文档撰写：30%

案例二：工控设备

项目背景：

• 项目：工业温度控制器
• 要求：量产1000台
• 环境：工业现场，电磁干扰大
• 认证：CE认证

决策分析：

Q1：是否需要量产？

• 答：是（量产1000台）
• 推导：倾向Spec

Q2：是否安全关键？

• 答：是（工业现场，失效危险）
• 推导：倾向Spec（SIL1/SIL2）

Q3：是否需要长期维护？

• 答：是（工业设备长期使用）
• 推导：倾向Spec

最终决策：全Spec

实施方案：

阶段1：需求分析（1周）

• 详细需求文档
• 安全需求分析
• 性能需求分析

阶段2：规格定义（2周）

• 硬件层规格
• 数据层规格
• 函数层规格
• 容错层规格

阶段3：代码实现（4周）

• 按规格生成代码
• 代码审查
• 单元测试

阶段4：集成测试（2周）

• 功能测试
• 性能测试
• 安全测试
• EMC测试

阶段5：认证准备（2周）

• 准备认证材料
• 提交CE认证
• 整改问题

范式使用：100% Spec

案例三：外包项目

项目背景：

• 项目：物联网网关
• 要求：交付源码 + 文档
• 时间：2个月
• 团队：3人协作

决策分析：

Q1：是否需要量产？

• 答：是（客户会量产）
• 推导：倾向Spec

Q2：是否需要长期维护？

• 答：是（客户长期使用）
• 推导：倾向Spec

Q3：是否有团队协作？

• 答：是（3人协作）
• 推导：倾向Spec（统一规范）

最终决策：Vibe验证 + Spec交付

实施方案：

阶段1（2周）：Vibe快速验证

• 验证硬件设计
• 验证关键技术
• 风险评估
• 产出：可行性报告

阶段2（1周）：Spec规格定义

• 统一规格模板
• 团队评审规格
• 确定接口规范
• 产出：规格文档

阶段3（4周）：Spec代码开发

• 按规格生成代码
• 团队代码审查
• 持续集成测试
• 产出：可交付代码

阶段4（1周）：文档整理

• 技术文档
• 使用手册
• 维护手册
• 产出：完整交付包

范式使用：

• 验证阶段：Vibe（10%）
• 开发阶段：Spec（90%）

五、决策树使用技巧

5.1 快速决策技巧

三问法：

第1问：要量产吗？

• 是 → Spec
• 否 → 继续问

第2问：要长期维护吗？

• 是 → Spec
• 否 → 继续问

第3问：时间紧吗？

• 是 → Vibe
• 否 → Spec

场景速查表：

5.2 避免常见错误

错误1：全部用Vibe

后果：

• 代码质量差
• 无法量产
• 难以维护
• 团队混乱

正确做法：

• 至少核心模块用Spec
• 关键功能用Spec
• 外部接口用Spec

错误2：全部用Spec

后果：

• 开发速度慢
• 效率低下
• 过度设计
• 成本高

正确做法：

• 验证阶段用Vibe
• 测试代码用Vibe
• 临时功能用Vibe

错误3：随意混用

后果：

• 代码风格混乱
• 难以维护
• 团队困惑
• 质量不稳定

正确做法：

• 明确使用规则
• 按模块/阶段划分
• 团队统一认识

5.3 团队决策规范

团队决策流程：

1. 项目启动会

   • 明确项目类型
   • 确定范式策略
   • 制定开发规范

2. 模块分配

   • 按模块确定范式
   • 明确交付标准
   • 确定审查标准

3. 开发过程

   • 按范式编写代码
   • 代码审查
   • 持续改进

4. 项目总结

   • 总结范式使用经验
   • 优化决策树
   • 更新团队规范

六、决策树工具

6.1 决策检查清单

## 范式决策检查清单 ### 项目信息 - 项目名称： - 项目类型：[ ]量产 [ ]原型 [ ]实验 [ ]毕设 [ ]外包 - 团队规模：[ ]个人 [ ]小团队 [ ]大团队 - 开发周期： ### 决策问题 1. 是否需要量产？ [ ] 是 → 倾向Spec [ ] 否 → 倾向Vibe 2. 是否安全关键？ [ ] 是 → 必须Spec [ ] 否 → 继续判断 3. 是否长期维护？ [ ] 是 → 倾向Spec [ ] 否 → 继续判断 4. 是否团队协作？ [ ] 是 → 倾向Spec [ ] 否 → 继续判断 5. 开发时间是否紧张？ [ ] 是 → 倾向Vibe [ ] 否 → 倾向Spec ### 最终决策 - 推荐范式：[ ]Vibe [ ]Spec [ ]Vibe→Spec - 使用比例：Vibe ___% Spec ___% - 注意事项：

6.2 决策记录模板

## 范式决策记录 **项目**：XXX **日期**：2024-XX-XX **决策人**：XXX ### 决策依据 1. 项目类型：量产产品 2. 安全要求：SIL2等级 3. 维护要求：长期维护 4. 团队协作：3人团队 ### 决策结果 - 主范式：Spec - 辅助范式：Vibe（验证阶段） - 使用比例：Vibe 10% + Spec 90% ### 实施计划 1. 阶段1：Vibe快速验证（1周） 2. 阶段2：Spec规格定义（1周） 3. 阶段3：Spec代码开发（4周） 4. 阶段4：测试验证（1周） ### 注意事项 - 驱动层必须用Spec - 测试代码可用Vibe - 文档必须完整

七、总结：决策树的核心要点

7.1 核心观点

决策树作用：

• 指导范式选择
• 避免随意决策
• 提升开发效率

决策树原则：

• 量产 → Spec
• 安全 → Spec
• 维护 → Spec
• 验证 → Vibe
• 紧急 → Vibe

混合策略：

• Vibe探路 + Spec定型
• 分模块使用
• 分阶段使用

7.2 使用建议

何时使用决策树：

• 项目启动时
• 模块开发前
• 团队协作时

如何使用决策树：

1. 明确项目类型
2. 逐层回答问题
3. 确定范式策略
4. 制定实施计划

注意事项：

• 不要教条主义
• 根据实际情况调整
• 团队统一认识

八、下讲预告

第6讲：嵌入式代码腐烂根源：无约束AI生成导致的时序BUG、资源冲突

内容预告：

• 代码腐烂的定义
• AI代码腐烂的根源
• 典型腐烂案例
• 如何避免腐烂

敬请期待！