培训对象:已使用AI工具1-2年的嵌入式研发团队(中高级水平)
学员基础:会使用Skills / Workflow / Agent,部分代码由AI生成
培训目标:梳理AI工具使用,建立最佳实践,有效提升嵌入式软件开发效率
本次培训围绕四大重点展开:
|
重点方向 |
核心目标 |
|
工作流程、架构梳理/重组 |
对现有研发流程进行AI-first审视,识别瓶颈,重组关键环节 |
|
研发团队提升工作效率 |
从个体效率到团队协同,建立可量化的AI增效体系 |
|
AI对产品的加持与赋能 |
从+AI到AI Native,探索嵌入式产品的智能化升级路径 |
|
AI边界(避坑经验沉淀) |
明确AI能力边界,建立规避幻觉与质量失控的工程防线 |
目标:从行业全局视角建立AI辅助研发的认知框架,深度理解手头三大工具的能力边界,重新审视敏捷开发与工业标准流程在AI时代的适配方式。
上午(9:00-12:00)
1.1 顶级组织AI生产力分析
ü 【结合Q1-Q4:标杆企业、提升幅度、度量方法、优秀实践】
1.1.1 全球AI辅助开发标杆企业深度扫描
ü GitHub / Microsoft:Copilot内部全员部署实践——代码生成占比35-40%,代码编写速度提升55%
ü Google:Duet AI for Developers——代码审查自动化,审查时间减少38%
ü Meta:内部AI辅助代码提交占比已超50%,重点发力测试生成与代码审查
ü 腾讯:工蜂AI代码助手内部覆盖率85%——后端开发效率提升40-50%
ü 字节跳动:豆包MarsCode——前端组件生成效率提升60%+,支持私有化部署
ü 华为:CodeArts Snap——嵌入式/内核开发场景专项优化,驱动代码生成
1.1.2 生产率提升的量化方法论
ü DORA指标延伸:部署频率、变更前置时间、MTTR、变更失败率——AI前后的Delta分析
ü AI专属度量指标体系:
ü ○ 代码生成接受率(Acceptance Rate)——行业基准约30-45%
ü ○ AI辅助代码占比(AI Code Ratio)——衡量AI渗透深度
ü ○ 人工修改轮次(HITL Turns)——越少越好,反映Prompt质量
ü ○ 首次通过率(First-Pass Rate)——AI生成代码不经修改即可合入的比例
ü ○ 任务完成时间对比(With/Without AI)——A/B对照实验设计
ü SPEED指标框架(Space, Performance, Efficiency, Effort, Defect)
1.1.3 嵌入式领域AI生产力的特殊性
ü 嵌入式研发的AI适用性光谱:工具链/构建脚本(高)→ 驱动/业务逻辑(中)→ 寄存器/时序(低)
ü 与Web/后端开发的效率差异分析:编译周期、硬件依赖、调试方式的影响
ü 嵌入式场景下"生产率"的重新定义:不只是代码行数,还包括调试时间、文档维护、测试覆盖
1.1.4 实战演练:设计团队AI效能看板
ü 基于DORA+AI指标,构建嵌入式团队的效能度量看板
ü 工具:Excel/Notion,输出可立即使用的看板模板
1.2 Copilot嵌入式研发功能解析
1.2.1 Copilot核心能力与嵌入式适用性评估
ü 代码补全与建议:C/C++/Rust语言的上下文理解深度
ü Copilot Chat:架构讨论、调试辅助、代码解释的嵌入式场景适配
ü Copilot Edits:多文件协同编辑——对跨模块重构的价值
ü Copilot Autofix:安全漏洞自动修复——嵌入式安全编码规范对接
1.2.2 嵌入式专项场景实测
ü 驱动框架代码生成(platform_driver / HAL层)
ü 设备树(Device Tree)片段生成与校验
ü 构建脚本(CMake / Makefile / Kconfig)的AI辅助编写
ü Linux网络框架与IPC通信代码生成
ü 寄存器操作封装与位域操作辅助
1.2.3 Copilot的嵌入式边界与局限
ü 上下文窗口限制:大型嵌入式项目(10万+行)的上下文断裂问题
ü 硬件特异性知识缺失:自定义SoC/MCU的理解盲区
ü 实时性与确定性约束:AI无法验证时序/中断行为
1.3 Windsurf嵌入式研发功能解析
1.3.1 Windsurf核心架构与差异化优势
ü Cascade智能体架构:多步骤任务自主规划与执行
ü 深度代码库索引:对嵌入式大型工程的跨文件理解能力
ü 终端集成:编译/烧录/调试命令的AI辅助编排
1.3.2 嵌入式专项场景实测
ü 跨模块重构:从裸机迁移到RTOS的任务拆解
ü 依赖分析与影响范围评估:修改HAL层后的涟漪效应追踪
ü 文档-代码对齐:从Doxygen注释反向生成代码框架
ü 调试会话辅助:从日志/Coredump定位根因
1.3.3 Windsurf vs Copilot:嵌入式场景对比
|
维度 |
Copilot |
Windsurf |
嵌入式场景判断 |
|
上下文理解 |
单文件为主 |
全工程索引 |
Windsurf在大型项目中优势明显 |
|
多步骤任务 |
需人工分步 |
Cascade自动编排 |
Windsurf适合复杂重构场景 |
|
IDE集成 |
VS Code深度集成 |
VS Code原生 |
Copilot生态更成熟 |
|
C/C++补全 |
优秀 |
优秀 |
两者接近 |
|
终端操作 |
有限 |
深度集成 |
Windsurf在编译/烧录场景更强 |
|
价格 |
个人免费/企业付费 |
个人免费/企业付费 |
需根据团队规模评估TCO |
1.4 OpenClaw功能挖掘解析
1.4.1 OpenClaw定位与核心能力
ü 开源AI编程助手生态定位:与Copilot/Windsurf的互补关系
ü 自定义Agent能力:Skills / Workflow / Agent的深度定制
ü 私有化部署与数据安全:嵌入式企业的核心诉求
1.4.2 嵌入式场景深度定制
ü 自定义Skill开发:针对团队工具链(交叉编译器、JTAG调试器)的AI封装
ü Workflow编排:从需求文档到代码框架的自动化Pipeline
ü Agent协作:多Agent模式处理复杂嵌入式任务(构建数字研发团队)
1.4.3 三大工具的协同策略
ü 工具分工矩阵:Copilot(日常编码)+ Windsurf(复杂重构)+ OpenClaw(定制自动化)
ü 避免工具碎片化:80/20法则——80%场景用20%核心工具
ü 统一上下文管理:跨工具的知识沉淀与共享机制
下午(14:00-17:30)
1.5 敏捷开发与嵌入式研发
1.5.1 敏捷在嵌入式领域的适配现状
ü 传统敏捷(Scrum/Kanban)在嵌入式中的水土不服:硬件依赖、长编译周期、调试不可预测
ü 嵌入式敏捷的修正实践:Sprint长度弹性化、硬软解耦、仿真先行
ü 行业案例:一个敏捷的融合实践
1.5.2 AI如何重塑嵌入式敏捷流程
ü Sprint Planning:AI辅助Story拆分与工作量估算(基于历史数据)
ü Daily Standup:AI自动汇总昨日进展(从Git/CI数据提取)
ü Code Review:AI预审+人工终审的二级审查模式
ü Retrospective:AI分析Sprint数据,识别效率瓶颈
ü 关键转变:从"人在流程中驱动"到"AI在流程中辅助、人在关键节点决策"
1.5.3 实战演练:AI增强的嵌入式Sprint模拟
ü 分组模拟一个2周Sprint,使用AI工具完成从需求到代码的全流程
ü 对比传统Sprint与AI增强Sprint的效率差异
1.6 工业标准流程与嵌入式研发
1.6.1 嵌入式领域关键工业标准梳理
|
标准 |
领域 |
核心要求 |
AI接入挑战 |
|
ISO 26262 |
汽车功能安全 |
ASIL分级、安全生命周期 |
AI代码的可追溯性挑战 |
|
IEC 61508 |
电气/电子功能安全 |
SIL分级、V模型 |
AI生成代码的验证要求 |
|
ASPICE |
汽车软件过程改进 |
过程评估模型 |
AI辅助过程的能力等级评估 |
|
DO-178C |
航空软件 |
目标导向验证 |
AI工具的鉴定(Qualification)问题 |
|
IEC 62304 |
医疗器械软件 |
软件安全分级 |
AI在SoC开发中的可接受性 |
1.6.2 AI在标准流程中的合规嵌入
ü 工具鉴定(Tool Qualification):AI工具是否需要按TCL分级进行鉴定?
ü 可追溯性(Traceability):AI生成代码的需求追溯链路构建
ü 验证与确认(V&V):AI生成代码的测试覆盖要求——不低于人工代码
ü 配置管理:AI Prompt/上下文作为配置项纳入版本管理
1.6.3 标准流程中AI使用的红线与绿区
ü 红线:安全关键代码(ASIL-C/D, SIL-3/4)不得由AI直接生成——必须人工逐行审查
ü 绿区:工具链脚本、测试框架、文档生成、代码审查辅助——AI高价值场景
ü 黄区:驱动框架、通信协议栈——AI生成骨架+人工填充关键逻辑
1.7 AI工具选型与评估方法论【补充】
1.7.1 嵌入式场景AI工具评估矩阵
ü 评估维度:能力匹配度 / 学习成本 / 集成难度 / TCO / 社区活跃度 / 厂商可靠性
ü 嵌入式特有维度:交叉编译支持 / 目标平台理解 / 调试器集成 / 安全合规
ü 实战:用评分矩阵对当前团队在用工具进行系统化评估
1.7.2 避免工具疲劳的三个原则【解答Q9】
ü 原则1——80/20法则:80%场景用20%核心工具,不为长尾场景频繁切换
ü 原则2——季度评估制:每季度评估一次工具矩阵,不跟风,有数据支撑
ü 原则3——内部工具平台:封装常用工具,提供统一界面,降低切换成本
1.7.3 工业标准化研发流程与AI机会鉴别
ü Review标准流程图
ü 温故下AI潜在机会
第一天总结:建立认知框架——AI能做什么、不能做什么、在嵌入式场景中该怎么做。
课后任务:每位学员用AI工具完成一个嵌入式小任务(如编写一个UART驱动框架),记录使用过程和遇到的问题,第二天讨论。
目标:将AI工具深度嵌入研发全流程,解决团队从"会用工具"到"用好工具"的关键跨越,建立可落地、可度量、可持续的AI辅助研发实践体系。
上午(9:00-12:00)
2.1 AI与新质生产力
2.1.1 新质生产力的AI内核
ü 从"劳动密集型"到"智能密集型":嵌入式研发的范式转变
ü AI作为新质生产力的三个维度:
ü ○ 效率维度:代码生成/测试生成/文档生成的速度倍增
ü ○ 质量维度:AI辅助审查减少缺陷逃逸,提升首次通过率
ü ○ 创新维度:AI辅助架构探索、方案对比,缩短技术决策周期
2.1.2 嵌入式研发的生产力重构模型
ü 传统模型:需求→设计→编码→单元测试→集成→系统测试→发布(线性瀑布)
ü AI增强模型:AI在每个环节同时并行辅助,压缩反馈回路
ü 关键指标:从需求到可运行代码的时间(Time-to-Runnable-Code)
2.1.3 新质生产力的度量与归因
ü 如何证明AI投入的ROI:建立A/B对照基线
ü 嵌入式领域的特殊考量:编译等待时间、硬件调试时间的AI缩减空间
2.2 团队研发活动与工具对接
2.2.1 研发活动全景与AI嵌入点
ü 研发活动: 从需求分析到发布运维
ü 传统方式
ü AI增强方式
ü 增效潜力
2.2.2 嵌入式特有活动的AI对接
ü 交叉编译环境配置:AI辅助工具链选型与CMake/Makefile生成
ü BSP移植与适配:AI辅助寄存器配置与初始化代码框架
ü 硬件调试:AI辅助JTAG/GDB命令编排与异常分析
ü 固件打包与OTA:AI辅助版本管理与升级脚本生成
2.2.3 实战演练:绘制团队AI工具对接全景图
ü 分组绘制As-Is(现状)与To-Be(目标)工具对接架构图
ü 识别Top-3高价值嵌入点,制定实施优先级
2.3 MDD有效性与对接: 双模型驱动开发范式
2.3.1 双模型驱动开发的概念与必要性
ü 传统MDD的痛点:模型与代码的双向同步、代码生成质量、定制化困难
ü 双模型驱动开发DMDD
ü UML模型
ü AI模型
ü 双模型互补逻辑
ü 单模型驱动的局限
ü 嵌入式领域特殊性
2.3.2 双模型协同机制与工作流
ü 核心协同流程
ü 正向路径:UML→AI生成
ü 反向路径:AI输出→UML回溯
ü 一致性校验机制
ü 工具链支撑
2.3.3 DMDD驱动的嵌入式实践路径
ü 3种落地路径:谁先谁后
ü 实践要点与避坑:UML粒度控制,PlantUML优先,安全关键代码边界,Prompt模板化
2.4 TDD有效性与对接
2.4.1 TDD在嵌入式的困境与AI的破局点
ü 嵌入式TDD困境:硬件依赖、模拟困难、测试运行慢
ü AI破局:AI生成Mock/Stub、AI辅助硬件抽象层设计、AI优化测试执行顺序
2.4.2 AI辅助TDD实践框架
ü 红阶段:AI根据需求/接口定义自动生成测试用例骨架
ü 绿阶段:AI生成最小实现代码使测试通过
ü 重构阶段:AI辅助识别代码异味并建议重构方案
ü 嵌入式TDD工具链:CMock + Ceedling + AI → 自动生成Mock与测试
2.4.3 实战演练:AI驱动的TDD编码Kata
ü 练习:用AI辅助TDD方式实现一个环形缓冲区(Ring Buffer)模块
ü 目标:体验AI在Red-Green-Refactor各阶段的具体价值
下午(14:00-17:30)
2.5 面临研发实践问题清单
2.5.1 嵌入式AI研发十大高频问题【解答Q6核心】
|
编号 |
问题 |
典型表现 |
应对策略 |
|
1 |
AI幻觉 |
生成看似正确但实际有bug的代码 |
建立AI代码审查清单,关键路径必须人工验证 |
|
2 |
上下文丢失 |
长会话后期修改越来越离谱 |
每个独立任务开新会话,关键信息沉淀到知识库 |
|
3 |
迭代退化 |
初次代码可用,后续修改越改越乱 |
版本锁定策略:AI修改前先commit,不满意可回滚 |
|
4 |
Token爆炸 |
成本失控 |
分级模型策略 + Prompt压缩 + 本地小模型分流 |
|
5 |
工具碎片化 |
同时使用N个AI工具,上下文不互通 |
工具矩阵评估,固定2-3个主力工具 |
|
6 |
安全合规 |
AI代码的安全性与可追溯性 |
AI生成代码必须经过同等安全审查流程 |
|
7 |
知识流失 |
AI生成的代码团队不理解,维护困难 |
AI必须输出解释,团队建立代码理解机制 |
|
8 |
依赖黑盒 |
过度依赖AI,团队能力退化 |
设定"无AI时段",保持手动编码能力 |
|
9 |
版本管理 |
AI生成的Prompt/上下文如何版本化 |
Prompt作为配置项纳入Git管理 |
|
10 |
评估困难 |
难以量化AI工具的实际价值 |
建立AI效能看板,持续追踪关键指标 |
2.6 自动化测试可能方案
2.6.1 AI辅助嵌入式自动化测试体系
ü 单元测试层:AI生成CMock/FFF的Stub与Mock,Ceedling测试用例自动生成
ü 集成测试层:AI辅助构建HIL(硬件在环)测试场景
ü 系统测试层:AI辅助生成测试序列,覆盖状态机转换路径
ü 回归测试层:AI识别变更影响范围,智能选择回归测试子集
2.6.2 嵌入式测试的AI辅助工具链
2.6.3 实战演练:AI生成嵌入式单元测试
ü 练习:给定一个GPIO驱动模块,用AI生成完整的Ceedling测试套件
ü 进阶:AI辅助实现HIL测试场景的自动化编排
2.7 研发生产力提高可能方案
2.7.1 生产力提升的系统性方案
● 个体层面:
ü ○ Prompt技能提升:从"直接提问"到"结构化指令+上下文管理"
ü ○ AI辅助编码习惯:先描述意图,再让AI生成,然后审查修改
ü ○ 知识沉淀:个人Prompt模板库的建立与维护
● 团队层面:
ü ○ 统一工具矩阵:固定2-3个主力工具,建立使用规范
ü ○ 共享Prompt库:团队级Prompt模板的版本管理与持续优化
ü ○ AI代码审查流程:AI预审→人工终审的二级审查模式
● 组织层面:
ü ○ AI效能度量体系:持续追踪关键指标,数据驱动改进
ü ○ AI Center of Excellence:建立专职团队推动AI实践
ü ○ 激励机制:将AI使用效果纳入绩效考核(建议占比10-15%)
2.7.2 Token成本优化策略【解答Q5】
|
策略 |
实施方案 |
成本节省 |
实施难度 |
|
本地小模型分流 |
简单任务用本地7B模型 |
60-80% |
中 |
|
Prompt压缩 |
去掉冗余描述,结构化表达 |
20-40% |
低 |
|
缓存常见Query |
相似问题复用历史回答 |
30-50% |
低 |
|
分级模型策略 |
简单→GPT-3.5,复杂→GPT-4 |
50-70% |
中 |
|
批量处理 |
合并请求减少API调用 |
15-25% |
低 |
|
开源模型 |
Llama 3 / Qwen2.5本地部署 |
80-95% |
高 |
|
自建Prompt库 |
减少试错Token消耗 |
10-20% |
低 |
|
Token预算告警 |
设置月度预算阈值 |
避免超支 |
低 |
|
精准提问培训 |
团队Prompt技能系统化提升 |
15-30% |
中 |
|
混合云部署 |
敏感代码私有化,通用代码云端 |
长期节省 |
高 |
2.7.3 AI幻觉应对策略【解答Q6深入】
ü 预防层:结构化Prompt(角色+任务+上下文+约束+输出格式)
ü 检测层:AI代码审查清单(安全/性能/边界/规范四维检查)
ü 修复层:版本锁定+回滚策略,避免在错误基础上继续修改
ü 沉淀层:幻觉案例库,团队共享避坑经验
2.8 现存规范与AI规范的和解
2.8.1 现存研发规范与AI使用的冲突点
|
规范类别 |
现存要求 |
AI冲突点 |
和解方案 |
|
代码规范 |
编码风格统一、命名规范 |
AI生成代码风格不一致 |
AI Prompt中嵌入编码规范约束 |
|
代码审查 |
人工逐行审查 |
AI生成代码量大,审查负担加重 |
AI预审+人工终审二级模式 |
|
版本管理 |
Git分支策略、Commit规范 |
AI生成的Commit信息不规范 |
AI按规范模板生成Commit Message |
|
文档规范 |
设计文档、API文档格式 |
AI生成文档格式不统一 |
提供文档模板作为Prompt上下文 |
|
测试规范 |
覆盖率要求、测试用例标准 |
AI生成的测试覆盖不充分 |
AI生成+人工补充边界Case |
|
安全规范 |
MISRA-C、CERT-C |
AI不了解安全编码规则 |
将安全规则嵌入Prompt约束 |
2.8.2 建立AI友好的研发规范
ü 原则1:不是让AI适应旧规范,而是让规范适配AI的工作方式
ü 原则2:AI生成的内容必须经过与人工同等标准的审查
ü 原则3:规范要为AI提供足够的上下文(如编码规范作为Prompt一部分)
ü 原则4:持续迭代——规范随AI能力演进而调整
2.8.3 实战演练:制定《团队AI开发规范v1.0》
ü 分组针对当前团队规范,识别Top-5冲突点并提出和解方案
ü 用AI辅助编写规范文档(本身就是AI使用实践)
2.9 AI开发避坑指南与Prompt工程【补充】
2.9.1 高级Prompt工程技术
ü Context Management:上下文窗口优化——结构化上下文替代堆砌代码
ü Chain-of-Thought(CoT):让AI分步推理,提升复杂问题解决质量
ü 会话分叉策略:每个独立任务开新会话,避免上下文污染
ü 版本对比审查:AI修改前后代码diff审查,确保修改符合意图
2.9.2 嵌入式场景Prompt模板示例
ü 驱动开发模板:目标MCU + 外设类型 + 寄存器映射 + 初始化流程要求
ü RTOS任务模板:任务职责 + 通信方式 + 优先级约束 + 栈大小估算
ü 测试生成模板:被测模块接口 + 边界条件 + Mock策略 + 覆盖率要求
第二天总结:从"会用工具"到"用好工具"——建立可落地、可度量、可持续的AI辅助研发实践体系。
课后任务:各组基于第二天的方案,完成一个AI辅助的嵌入式模块开发(含TDD),第三天展示。
目标:从个体效率提升到组织能力跃迁,探索AI对嵌入式产品和团队的深层赋能,建立可持续的AI实践演进机制,确保培训成果能够长期落地。
上午(9:00-12:00)
3.1 组织架构分享讨论
3.1.1 AI时代的研发组织架构演进
ü 传统架构:职能型(开发/测试/运维)→ 矩阵型 → 敏捷小队
ü AI增强架构:在敏捷小队基础上增加"AI能力层"
ü 标杆组织案例:
ü ○ GitHub:Copilot专项团队 + 全员AI Ambassador制度
ü ○ Google:AI平台工程团队 + 业务线AI Champion
ü ○ 国内头部:AI Center of Excellence(CoE)+ 各团队AI接口人
3.1.2 AI Center of Excellence(CoE)设计
|
角色 |
人数 |
职责 |
能力要求 |
|
AI架构师 |
1人 |
技术选型与架构设计、工具链集成 |
资深架构师 + AI实践经验 |
|
Prompt工程师 |
1-2人 |
维护Prompt模板库,优化生成质量 |
开发背景 + 自然语言能力 |
|
AI培训师 |
1人 |
组织培训、编写教程、解答疑问 |
技术培训 + AI工具使用 |
|
效果分析师 |
1人 |
度量AI使用效果、持续优化 |
数据分析 + 研发流程理解 |
3.1.3 分组讨论:适合我团队的AI组织模式
ü 分组讨论:基于各自团队规模与业务特点,设计AI组织架构
ü 输出:组织架构图 + 角色定义 + 推进路线图
3.2 AI使用与组织架构盲区
3.2.1 常见组织盲区与风险
|
盲区类型 |
典型表现 |
潜在风险 |
|
影子AI |
团队成员私自使用未经审批的AI工具 |
数据泄露、代码安全风险、不可控依赖 |
|
AI孤岛 |
个别团队深度使用AI,其他团队不用 |
效率差距拉大、代码风格分裂 |
|
能力退化 |
过度依赖AI,团队基础编码能力下降 |
AI不可用时团队陷入瘫痪 |
|
知识外流 |
AI工具使用导致核心代码/设计外泄 |
商业秘密风险、合规风险 |
|
责任模糊 |
AI生成代码出问题,责任归属不清 |
流程混乱、推诿扯皮 |
|
评估缺失 |
没有度量AI使用的效果 |
无法证明ROI、投入决策缺乏依据 |
3.2.2 盲区治理策略
ü 影子AI治理:建立AI工具白名单,提供合规替代方案
ü AI孤岛治理:建立AI实践分享机制(月度Showcase),设立AI接口人
ü 能力退化预防:设定"无AI时段"(如每月1天手动编码),保持核心能力
ü 知识外流防护:敏感代码使用私有化部署/本地模型,建立数据分级制度
ü 责任界定:明确AI生成代码的责任归属——使用者负最终审查责任
ü 评估机制:建立AI效能看板,持续追踪关键指标
3.3 开源项目分组实践分析与总结
3.3.1 实践项目设定
ü 各组选择一个嵌入式开源项目,用AI工具完成指定任务:
ü ○ 项目A:Zephyr RTOS驱动模块——AI辅助添加新外设驱动
ü ○ 项目B:FreeRTOS+STM32——AI辅助实现通信协议栈
ü ○ 项目C:Linux内核模块——AI辅助编写字符设备驱动
ü ○ 项目D:ROS2节点——AI辅助实现自定义消息与Service
3.3.2 实践评估维度
|
评估维度 |
定义 |
目标值 |
|
AI代码接受率 |
AI生成代码直接使用的比例 |
>40% |
|
首次通过率 |
AI生成代码不经修改即可编译/测试通过的比例 |
>60% |
|
时间节省率 |
对比纯手写的完成时间节省比例 |
>30% |
|
缺陷密度 |
AI生成代码的缺陷率 vs 人工代码 |
≤人工水平 |
|
Prompt质量 |
Prompt的结构化程度与复用性 |
团队统一模板 |
3.3.3 分组展示与交叉评审
ü 各组展示实践成果(15分钟/组)
ü 交叉评审:其他组从"可复用性"和"可推广性"角度点评
ü 讲师总结:提炼共性经验与个性化方案
下午(14:00-17:30)
3.4 可能的产品赋能办法
3.4.1 从"+AI"到"AI First"的产品思维
ü +AI产品:传统产品叠加AI功能(如老师带GE工厂物联网项目案例)
ü AI Native产品:从设计之初就以AI为核心(如自适应控制系统)
3.4.2 嵌入式产品AI赋能的五个层次
|
层次 |
核心价值 |
嵌入式产品案例 |
落地难度 |
|
L1 功能增强 |
用AI优化现有功能 |
智能参数自整定、自适应滤波 |
低 |
|
L2 体验升级 |
AI改变交互方式 |
自然语言配置界面、语音诊断 |
中低 |
|
L3 能力跃迁 |
AI开启新能力 |
预测性维护、异常检测 |
中 |
|
L4 模式创新 |
AI创造新商业模式 |
按设备健康度付费、远程运维 |
中高 |
|
L5 生态重构 |
AI连接上下游 |
智能供应链、端云协同优化 |
高 |
3.4.3 嵌入式产品AI赋能的技术架构
ü 端侧AI:TinyML / Edge AI——MCU上运行轻量推理模型
ü 端云协同:设备端采集+云端推理+结果下发——延迟与算力的平衡
ü 开发工具AI化:AI辅助产品配置、调试、运维——降本增效的隐形价值
3.4.4 跨领域AI优秀实践【解答Q8】
|
领域 |
AI实践 |
代表工具/方案 |
|
硬件开发 |
AI辅助PCB布局布线、原理图审查、BOM优化 |
AutoDesk Fusion AI, Flux.ai |
|
办公自动化 |
AI生成技术文档、会议纪要、项目周报 |
Notion AI, Otter.ai + Claude |
|
自动化测试 |
AI生成测试用例、视觉回归测试、日志分析 |
Testim, Applitools |
|
客户服务 |
AI技术支持问答、故障诊断、工单分类 |
自定义Agent + 知识库RAG |
|
供应链 |
AI需求预测、库存优化、供应商评估 |
行业定制化方案 |
3.4.5 实战演练:重新设计一款嵌入式产品的AI架构
ü 案例:将传统工业控制器改造为AI驱动的智能控制器
ü 分组完成:识别3个AI优化场景 → 设计技术架构 → 评估ROI
3.5 可能的成员赋能办法
3.5.1 成员AI能力成长路径
|
阶段 |
时间 |
能力标准 |
标志性成果 |
|
入门期 |
0-3个月 |
会用工具,掌握基本Prompt技巧 |
独立使用Copilot完成编码任务 |
|
熟练期 |
3-6个月 |
能设计Workflow,处理复杂任务 |
用Windsurf完成跨模块重构 |
|
进阶期 |
6-12个月 |
能定制Agent,优化团队流程 |
开发OpenClaw自定义Skill |
|
专家期 |
12+个月 |
能推动组织AI转型,定义实践范式 |
设计团队AI开发规范 |
3.5.2 持续赋能机制
● 培训体系:
ü 新员工AI Onboarding:1周集中培训 + 2周导师带教
ü 月度AI Workshop:分享最新实践与工具更新
ü 季度AI Hackathon:用AI解决实际业务问题
● 知识管理:
ü 团队Prompt模板库:持续迭代,版本管理
ü AI避坑案例库:幻觉/错误/安全问题的记录与分享
ü 优秀实践Wiki:可搜索、可复用的AI使用案例集
● 激励机制:
ü ○ "AI使用之星"月度评选
ü ○ AI使用效果纳入绩效考核(建议占比10-15%)
ü ○ 分享优秀实践给予奖励
3.5.3 工具演进的应对策略【解答Q9深入】
ü 建立"工具雷达":当前在用/评估中/待观察,季度更新
ü 设定"技术债预算":每月不超过10%时间用于工具评估与试错
ü 依赖抽象:核心流程不绑定单一工具,保留切换灵活性
ü 社区参与:参与开源AI工具社区,提前感知方向变化
3.6 人在回路:AI自动化开发中的人类角色【补充,解答Q7】
3.6.1 人类参与的七个关键节点
|
节点 |
阶段 |
参与内容 |
核心职责 |
|
1 |
需求澄清 |
AI理解需求后,人确认AI的理解是否正确 |
确认/修正AI的理解 |
|
2 |
架构决策 |
技术方案选择,人拍板 |
技术选型决策 |
|
3 |
代码审查 |
AI写代码,人审查(关键节点!) |
代码质量把关 |
|
4 |
测试验证 |
AI生成测试用例,人补充边界Case |
测试充分性保证 |
|
5 |
安全审查 |
AI生成代码的安全合规审查 |
安全底线守卫 |
|
6 |
部署审批 |
AI准备发布脚本,人审批 |
发布风险控制 |
|
7 |
复盘优化 |
AI分析数据,人提炼经验与规则 |
持续改进驱动 |
3.6.2 参与方式的进化
ü 当前阶段(Tool-Assisted):人在前,AI在后——人主导,AI辅助
ü 过渡阶段(AI-Assisted):AI在前,人在后——AI执行,人审查
ü 未来阶段(Human-Supervised):AI自主,人设边界——人定义约束,AI自主规划
ü 核心原则:人在回路中的角色从"执行者"转向"决策者"和"审查者"