嵌入式软件开发历来对工程规范的要求有别于桌面、移动或 Web 软件。遇到问题时，这里没有可弹性扩容的云实例，内存告急也没有简单的扩容途径。更关键的是，嵌入式软件故障不仅是某个可从历史版本恢复的办公应用出错，而可能直接导致车辆、医疗设备或工业设备停止运转，风险等级大相径庭。这一本质差异，决定了各企业在投入预算和工程资源之前，应以怎样的视角审视在嵌入式系统中引入 AI 的方式。
嵌入式硬件的智能体式开发如何达到生产级标准？
生产级智能体式开发需要三个维度的协同：
-
一套专为目标平台构建、具备 UI 与硬件感知能力的智能体技能，
-
专项的人工闭环审核机制，确保不单纯依赖智能体的判断。
-
对最终交付内容明确的组织责任划分。
评估嵌入式 AI 工具的企业，应将上述三点视为必要前提条件，而非可选项。
Qt 近期主持了一场嵌入式系统 AI 应用现状小组讨论，参与者包括来自 Beningo Embedded Group 的Jacob Beningo、来自 Spyrosoft 的Przemyslaw Nogaj，以及 Qt Group 的Peter Schneider。讨论聚焦于嵌入式团队当前在将智能体代码稳定推进生产环境时所面临的共性挑战。
为何现在就要关注嵌入式系统的 AI 应用
AI 编程浪潮兴起的最初几年，生产力提升几乎全部集中在 Web、桌面和移动软件领域。嵌入式开发相对滞后，部分原因在于市场体量，部分则源于结构性制约：目标设备通常面临内存限制、缺少可卸载计算负载的 GPU，以及通用智能体编码模型未经训练的特定硬件需求。
如今，这一差距正在快速缩小。过去六到九个月间，即便是传统上谨慎保守或受严格监管的行业，也出现了明显转变。一年前还完全排斥 AI 辅助开发的医疗设备制造商，如今已在制定内部目标，规定提交并通过审批的代码中必须有一定比例由 AI 生成。国防承包商则在评估哪些大语言模型（LLM）可部署在自有数据中心，而非通过公共云 API 调用。
嵌入式产品周期仍慢于消费软件，受监管行业的实际落地预计在两到五年之间——但这一趋势的方向已无争议。等待观望的企业，将把生产力先发优势拱手相让给率先行动的竞争对手。
嵌入式 AI 工具在生产环境中的共性挑战
从 AI 实验到生产部署之间的落差，往往被大多数企业低估。在实际硬件上应用嵌入式 AI 工具的团队，普遍面临以下四类挑战：
-
硬件感知能力。通用 LLM 基于桌面、Web 或移动应用的模式训练，难以胜任资源受限的 HMI 设备场景。
-
内存与算力预算。每项优化决策必须严守目标硬件在二进制大小和 CPU 周期上的固定约束。
-
机密性。尤其对于安全关键型嵌入式系统，向云端共享模型发送数据可能并非可行选项，工作负载须转向私有部署实例、本地部署或更小型的本地模型。
-
仿真盲区。在桌面构建或仿真环境中难以察觉的性能问题，在实际目标设备上可能极为严重，必须在真实硬件上进行充分验证。
这些约束对嵌入式软件开发并不陌生。真正的变化在于：在适当的上下文引导下，AI 智能体如今能够针对性地应对这些挑战。
能否信任用于嵌入式或安全关键设备的 AI 生成代码？
直接的答案是：不能，不能未经验证就信任。对于桌面或移动应用，生成的代码同样不能直接信任，但当目标是生产环境中运行的硬件时，风险等级从根本上更高。
嵌入式 AI 小组讨论中提出了一个贴切的类比：当今的编码智能体好比一位资历亮眼的应届毕业生，理论能力具备，但对特定代码库的实践理解尚有欠缺。缺乏监督时，二者的结合很容易在新增功能的同时破坏已有功能。这正是嵌入式设备场景的核心问题：看似自信生成的代码，并不等同于经过验证的正确代码。
企业应将 AI 智能体视为工具，而非捷径。在启动代码生成之前，投入精力细化需求定义，并以验证清单把关可接受的输出，这样做是值得的。智能体必须在监督下运行，而非作为无人看管的决策者。
谁来审查和测试代码？为什么智能体 AI 系统仍需要人工审核
随着智能体生成代码的速度不断加快，代码评审正成为新的瓶颈。部分问题可通过智能体代码评审与确定性静态代码分析的结合来缓解。但智能体评审与质量保障应被视为初步过滤手段，而非最终审批。
最基本的是，领域专属的智能体技能有助于提升生成代码的质量。例如，QML 性能分析技能可系统性地识别 UI 性能瓶颈，而非依赖人工逐一排查；内存分析则有助于将性能控制在合理范围内。Qt 已发布了一套专为此类硬件感知审查设计的智能体技能与 MCP 工具。
然而，这还远远不够。一个可行的模式是借鉴传统代码评审实践：审批既需要智能体评审——弥补人工可能疏漏之处——也需要人工执行的最终审批。在智能体判断之上叠加静态分析，同样应保留在流水线中，因为受监管行业始终需要明确、可审计的审查步骤。
合规挑战：智能体 AI 软件开发如何满足 CRA 及类似法规要求？
适用行业日益扩大的合规要求，进一步抬高了代码质量与安全的门槛。
《欧盟网络弹性法案》（Cyber Resilience Act，CRA）适用于包含软件元素的设备，将网络安全责任直接归于设备制造商，贯穿产品全生命周期。类似法规正在从美洲到亚太地区全球范围内推进。随着软件在每款产品风险面中占比持续上升，监管机构正对供应商整个技术栈追责，包括 AI 智能体参与生成的任何代码。
正确实施的嵌入式 AI 应用与合规要求并不相悖，恰恰相反。智能体工作流能够监测已知漏洞并维护代码可追溯性。在满足合规义务的框架上构建产品，将嵌入式 AI 与自动对照既定标准验证代码的稳定库及工具配合使用，实际上能比单纯依赖人工努力更好地保障合规。
性能优化：AI 智能体能否针对目标嵌入式硬件优化 UI 代码？
尤其在嵌入式开发中，功能正确性并非终点。代码必须在实际目标设备的严格性能约束下运行。桌面或仿真环境中难以察觉的开销，在真实硬件上可能造成严重问题，因此必须在硬件在环的环境中开展优化工作。
然而，自主智能体循环如今已能大幅简化并提升这一过程。例如，为降低二进制大小和 CPU 周期，智能体可修改代码、部署至开发板、采集遥测数据并确定下一轮迭代方向，速度是人工操作的十倍。但必须牢记：仿真和桌面代理环境无法替代此类调优工作；嵌入式设备的性能优化必须在实际硬件上形成闭环。
人工闭环：智能体 AI 系统如何改变嵌入式软件开发
这一切并不意味着开发者沦为被动旁观者。AI 带来的是责任的转移：开发者从逐行编写代码，转向统筹调度智能体参与的系统——定义技术规范、设定约束、验证架构、指导评审。这与编译器成熟后淘汰手写汇编的历史转变如出一辙；智能体 AI 系统正在更高层面推动类似变革，将时间从重复性实现工作中解放出来，转向系统级思考。
角色演变。高级工程师将面临技能转型：需要高效评估生成代码，迅速识别架构缺陷，而非逐行阅读。这是一项正向挑战——将时间从重复性任务转向更有价值的创造性工作。
招聘决策的影响。招聘标准已在悄然转变——从工具熟练度转向可展示的好奇心与适应力。但也应正视：如果未来的初级工程师实际编码经验不足，可能需要通过导师制来培养对潜在问题的直觉判断能力。
对留才与成果质量的提升。智能体最擅长吸收的正是重复性实现工作。节省下来的时间，将流向真正留住人才的工作：解决新问题、从整体视角理解系统，以及创造性构建而非重复已有工作。
嵌入式设备软件开发中 AI 的未来走向
智能体式开发并不会降低嵌入式工程所要求的严格标准。恰恰相反，它提高了"已评审""已测试"和"合规"的实际门槛，同时赋予企业更强的能力去达到这一门槛。将嵌入式系统 AI 这一转变视为嵌入式软件开发结构性变革的企业，将获得持久的竞争优势。选择推迟的企业，并非规避了风险——而是将一个日后代价更高的能力差距延期至未来。
全软件生命周期的智能体式开发
