编译器在回路里：嵌入式团队怎么把生成式 AI 放进流水线

本文是论文 Agentic Pipelines in Embedded Software Engineering: Emerging Practices and Challenges（arXiv:2601.10220）正文第 I 节至第 VII 节的中文译文，由智测团队翻译。作者是哥德堡大学与查尔姆斯理工大学的 Simin Sun（simin.sun@gu.se）和 Miroslaw Staron。研究部分由 Software Center 资助。摘要写的是查尔姆斯、哥德堡大学与 17 家公司的合作；致谢写的是两所大学与 18 所大学和公司。两处数字不一致，译文不替作者抹平。参考文献未逐条展开。这是定性研究，不是新的模型实验，文中没有通过率或耗时。Mentimeter 投票的具体分数只在图里，正文没有印出，译文不估读。

摘要

软件工程正在经历一次新的转变，驱动力是生成式人工智能迅速进入开发工作流。版本控制系统曾经把手工协调自动化，人工智能工具现在开始把编程的许多环节自动化。对嵌入式软件工程组织来说，这却是第一次把人工智能放进安全关键、资源受限的环境。确定性、可靠性和可追溯性的硬要求，给采用生成式技术带来独特困难。

本文报告一项定性研究。四家公司的十位资深专家正在评估用生成式人工智能增强的嵌入式软件开发。通过半结构化焦点小组访谈和结构化头脑风暴，作者找出十一项正在出现的做法，以及十四项挑战，分别落在编排、负责任的治理和可持续采用上。结果显示，这些团队正在重想工作流、角色和工具链，以便可持续地转向智能体流水线，以及由生成式人工智能增强的开发。

关键词：嵌入式软件工程；大语言模型；确定性；可靠性；可追溯性。

I 引言

计算早期，软件开发靠大量人力手工编写、测试和调试。工具、框架和自动化发展之后，尤其是集成开发环境、持续集成与持续部署，以及生成式人工智能编程助手出现之后，许多任务所需的人数下降了。今天，单个开发者可以借助高级工具，独自或在小团队里构建、测试和部署复杂应用，做以前整个编程部门的事。

生成式人工智能开始把许多编程过程自动化，和版本控制、自动代码管理类似。这给职业带来问题：开发者、测试人员和项目经理这些传统角色，在生成式人工智能成为开发过程的主动参与者之后会怎样演变？组织如何调整过程和治理，使这次转变里的安全、质量和问责仍然成立？对嵌入式软件工程，这些问题尤其紧。确定性是基本要求。大语言模型不能取代程序员，必须补充他们。嵌入式系统变大和变复杂之后，可靠性和可追溯性的担忧也在上升，在汽车这类安全关键领域已经成为必需。

因此，把生成式人工智能放进嵌入式开发有独特困难。产品必须保持严格的确定性、可靠性和可追溯性。可是代码、测试和文档若借助大语言模型产生，开发过程就变得不那么可预测，输出会随运行或模型版本变化。图 1 上面是传统流水线：固定的需求、法规和工具，从规格到实现有一条稳定、可审计的路径。下面是人工智能增强的流水线：意图和制品之间多了一步概率性的生成。所以需要的不只是技术创新，还有新的问责、验证和认证机制，让制品即使产生路径是概率性的，仍然可审计、可信。

先前研究描述过工业组织如何组织自己的「人工智能旅程」，但对嵌入式开发实践如何演变，所知少得多。这里的确定性、可靠性和可追溯性不可谈判。尤其缺少实践者在日常工程里如何理解、适应并治理生成式人工智能的经验叙述。

研究问题是：嵌入式软件工程组织在保持高保障的同时，如何采用并适应生成式人工智能？这对工程实践和治理结构有什么含义？

作者对四家公司的十位资深工程师和技术专家做了定性研究。这些公司正在积极探索生成式人工智能增强的嵌入式开发是否可行。焦点小组和结构化头脑风暴收集了一手看法。贡献是经验洞察：团队如何在概率性人工智能面前处理确定性、可靠性和可追溯性。正在出现的做法包括人在回路里监督、对生成式人工智能友好的制品设计，以及编译器在回路里的反馈。组织也在为可持续、可审计的转变做准备。

II 背景

II-A 嵌入式软件工程

嵌入式系统是专用计算单元，软硬件结合，在严格的资源、时序和安全约束下完成专门功能。它们是汽车、医疗和航空航天的基础，软件失败会造成安全危害或财务损失。典型架构要求实时执行、确定性，以及与硬件接口的紧耦合。开发过程因此受严格标准指导：一般机械的 IEC 61508、汽车的 ISO 26262、航空航天的 DO-178C。

这些性质使嵌入式工程天生有纪律，在整个生命周期里把可预测、可复现和可追溯放在前面。同时，软件复杂度上升、发布周期变短，又在推动新的自动化。近期研究已经有早期探索，例如生成式人工智能工作负载的实时调度，以及安全关键系统里的故障预测。但把生成式人工智能放进嵌入式工作流，会在认证、版本控制和确定性上提出新问题。因此嵌入式系统是一个有力的试验场：看生成式人工智能如何与受监管、高保障的开发环境共存。

II-B 软件工程中的生成式人工智能

近期大语言模型，包括 GPT-5、Sonnet 4.5、Claude 3 和 Gemini 2，已经表现出对软件工程任务的广泛适用：自动补全、文档生成、修缺陷和测试合成。GitHub Copilot、Amazon CodeWhisperer 和 Meta 的 CodeCompose 已经在工业开发里常规使用。这些是背景里的工具名单，不是本文的实测排名。

研究里，大语言模型越来越多地被当成智能体式软件工程框架的组件，多个生成式智能体协作做需求细化、开发、测试和维护。尽管进展快，学者仍指出持续存在的局限：非确定性、推理不一致、可解释性不足。这些冲击嵌入式开发的核心原则：验证、可追溯和可复现。处理它们既要技术办法，也要负责任采用的新组织实践。

一边，生成式人工智能可以自动化外设驱动或配置文件的代码、文档和测试，加快原型和维护。另一边，大语言模型的非确定行为、缺少透明的来源，以及模型版本的演化，引起对长期支持和认证是否仍然有效的担心。

III 方法

作者做了混合方法：半结构化焦点小组，加结构化头脑风暴。访谈看日常挑战和策略，头脑风暴让参与者一起说出未来方向和共同担忧。目标是理解生成式人工智能在软件开发中的采用现状，以及参与者对未来五年演变的设想。

先对十位正在组织里探索可行性和影响的软件工程师做焦点小组。再用同一批人做基于 Mentimeter 的头脑风暴，讨论未来五年。讨论层次包括个人角色、工具、团队动态、组织策略和投资优先级。

参与者通过有针对性的邀请招募，目的抽样，保证十人来自四家公司，角色、经验和一手参与都相关。公司规模定义为：小型少于 1,000 名员工，中型 1,000 到 10,000，大型多于 10,000。表 I 如下。

焦点小组是半结构化的，各场共用一套提问框架，又留开放讨论。每场先自我介绍，再由各公司简短介绍组织背景和当前的生成式人工智能举措。然后围绕三件事：组织里生成式人工智能的现状；个人和团队在日常开发中采用工具的经验；对未来集成的担忧、挑战和期望。鼓励举具体例子、反思教训、指出实践中的机会和风险。

访谈之后是 Mentimeter 头脑风暴，实时收集、聚类和投票，谈未来五年实践、工具和角色。表 II 的问题类型包括 100 分分配、开放式和量表。题目覆盖：哪种技术影响最大（智能体式人工智能、像 Copilot 的编程助手、提示工程、持续集成助手、智能测试助手、代码评审助手）；哪些角色最需要再培训（程序员、架构师和设计师、测试人员、用户体验设计师、需求工程师、项目经理、发布工程师）；哪些能力必须在内部建设（把人工智能放进产品、提示工程、开发智能体、用人工智能做软件工程、人工智能工程、按需软件）；什么阻碍采用；若投资改进人工智能会改什么（生成的透明度、用于验证的预言、幻觉、速度、提示或工具的数据泄露、终止标准、解题时间范围）；若投资组织会投什么（新能力、新工具或更好的工具、与现有工具集成、新模型或更好的模型、对人工智能友好的代码、重构或重写遗留软件、专职人工智能团队）；未来三到五年团队、组织和软件工程角色会怎样；希望人工智能或智能体在哪影响最大（编程、合规、维护、测试与质量保证、设计与重构、代码评审、程序修复、入职）；人在回路何时可以跳过；如何验证带生成代码的系统；十年后的长期支持和可追溯怎么办。投票分数未写入正文。

焦点小组和头脑风暴都转录，由两位研究者做主题分析，识别反复出现的做法和挑战。

IV 发现

参与组织既在发展新做法，也遇到反复出现的挑战。三者聚成三个主题。主题 1 是编排好的人工智能工作流：把生成式人工智能在技术上接进工程过程。主题 2 是负责任的人工智能治理：监督、问责和可追溯。主题 3 是可持续的人工智能采用：如何建立并维持大规模使用所需的人和基础设施能力。结论里把主题 3 写成「组织标准化」，与正文的「可持续采用」不是同一个名字，译文在结论处保留这个差别。

IV-A 正在出现的做法

表 III 共十一项。

主题 1。团队把人工智能直接放进开发生命周期，从传统自动化转向更智能、由反馈驱动的过程。智能体流水线里，生成式智能体跨实现、编译、测试和部署协作。C2 说，他们正走向多智能体开发，智能体应该像今天的团队一样在流水线里工作。这是在现有持续集成上加自主组件，做迭代的构建、测试和验证。对人工智能友好的制品，是为生成式解释优化的代码和文档，例如 agent.md 或带注释的指令集，写明功能意图、时序约束和硬件依赖。C4 说，对人工智能友好的代码基本上就是更结构化的注释和更清楚的逻辑。这些制品是人与智能体之间的通信层，用来提高确定性、减少幻觉。编译器在回路里，是把生成的代码自动编译、仿真或测试，再把结果喂回去。学习由可执行结果引导，而不是由文本相似引导。C2 说，只要让大语言模型能用编译器，它就会好很多。C3 把 Copilot 和 Visual Studio Code 的智能体模式一起用。测试和验证方面，智能体被用来做回归测试或符合领域标准的合规制品。C3 说定制智能体做单元测试是很强的补充。C1 说生成测试用例也用得很多。这些是补充人的验证，不是取代，主要提高早期验证的效率。

主题 2。组织在把治理正式化，在安全关键情境里平衡自动化和人的监督。提示管理被作者称为可能最重要的做法：提示要系统、可审计、可复用。版本控制的提示库定义标准模板、上下文指令和领域参数。C3 用全体开发者共享的指令来保证风格一致。C2 用结构化系统提示来减少幻觉。人在回路里，工程师仍是主动决策者。参与者一致强调，人工智能是有价值的协作者，但还不能在安全关键环境里自主运行。C2 说，人在回路最好用的时候，是工程师仍然控制方法。C4 说，助手是协助开发者，不能直接拿走代码，需要重写。治理与合规把负责任人工智能政策扩到许可审计、数据访问控制和生成制品的验证。若干组织在把生成代码放进生产前有内部批准，常由合规团队或「人工智能倡导者」看伦理和法律含义。C1 说，需要知道为什么要采用人工智能。C3 关心生成代码的版权归谁。可追溯把模型版本、提示和配置与源代码仓库放在一起。C2 的挑战是如何把模型版本签入，供以后引用。C3 用 GitLab 管指令文件，简洁的生成有助于可追溯。在有十年支持或认证要求的行业，这正在变成治理的基础。

主题 3。培训方面，工程师除了会用工具，还要懂负责任使用和合规。C2 有加速团队，做技术侦察、产品合规和渗透测试工具。C4 要用黑客松提高意识、传播知识。MCP 被当成连接生成式系统与企业数据和工程工具的标准层，使交互安全、可审计、可互操作，每个工具遵守一致的访问和合规规则。C2 说，他们在推动所有工具都进自己的 MCP，也都有 MCP 接口，这样智能体就没有限制。作者把这理解为架构统一，也是从孤立实验扩到全组织工作流的载体。C4 希望事情自上而下，以便获得授权。协作实验是黑客松、试点和非正式跨团队试验。C3 说，那次黑客松里很多开发者用人工智能，不是因为被要求，而是因为它有效率。C1 有专职人工智能团队在实验并传播知识。

IV-B 挑战

表 IV 共十四项。

主题 1。认证缺口是首要担心。工具能提高生产率，但认证和安全保障变不确定。C2 说，需要认证智能体系统，但模型一直在变，不清楚怎么认证。传统认证框架是为确定性系统建的，对每次运行或每个模型版本都可能不同的输出，几乎没有指导。实验激励不足：迭代速度或功能产出这类指标，让探索性使用显得像更不产出。C2 说，开发者犹豫，是因为用了人工智能工具看起来更不产出。没有管理层的明确支持，实验常被看成风险而不是创新。抵制和恐惧：有人对可靠性怀疑，或担心自动化降低职业价值。C1 说，人们谨慎，不确定人工智能对角色意味着什么。再培训：嵌入式专长强的工程师往往缺少生成式工具经验。C1 的意思是需要人工智能编排者，但领域专家还没有那种训练。

主题 2。归属和许可：C1 说必须小心，因为不知道生成的代码归谁。这使人们犹豫把生成代码放进生产。非确定性：相同提示多次运行结果不同。C2 说不能保证每次输出相同，可复现因此变复杂。对时序、资源和确定性执行是必需的嵌入式系统，这是重大的验证挑战。版本机制：没有提示、模型配置和支持数据的可靠版本，就几乎无法复现某件制品的生成上下文。C3 说需要存提示和模型哈希，但还没有流程。长生命周期：汽车等行业系统可能要维护十年或更久，模型持续演化会造成版本漂移。C2 说，十年前的编译器可以签入，大语言模型不行。供应商依赖：第三方平台的更新、许可变化或弃用会直接影响开发基础设施。C1 说，稳定性依赖供应商，他们可以随时改模型或访问条款。

主题 3。法规方面，参与者特别提到欧盟人工智能法案和其他正在出现的标准。创新速度往往超过法律框架。C2 说，他们在等人工智能法案对软件验证意味着什么的明确指导。可审计和可解释：内部政策因安全和可追溯而限制或推迟对工具的访问。C4 说，内部政策严，外部人工智能工具被拦。采用不均：有的组已经完全接受，有的仍怀疑或缺少资源。C2 说，组织里有的部分远远领先，有的仍被信息技术政策挡住。烟囱：部门各自实验，不一定知道别人学到了什么。领导层和一线：高管把采用当战略目标，中层和工程团队常常没有明确指导或资源。C4 说，领导层想要采用，但他们没有有效实施的授权或支持。

三个主题合在一起：对集成的热情高，但可持续、负责任、标准化的采用仍有显著挑战。认证和确定性是技术障碍，问责和可复现是治理问题，法规、结构和领导对齐是组织约束。

V 相关工作

人工智能与软件工程的交叉在过去十年从传统机器学习集成，走到基于基础模型的软件系统。早期工作处理数据版本、模型漂移和测试流水线，说明机器学习赋能的软件需要不同于常规工程的专门实践。随后的研究记录大语言模型带来的破坏：非确定输出、正确性难以定义、缺少系统评估或治理。

Hassan 等人提出他们所称的 FMware：建在基础模型上的软件系统。他们列出开发可信 FMware 的十项主要挑战，包括提示脆弱、数据对齐和多代软件集成，并呼吁跨人工智能世代的可复现和语义可观测。Parnin 等人访谈正在做「副驾驶」产品的职业工程师，痛点贯穿提示工程、编排、测试和合规，多数人靠试错写提示，因此需要「给提示加上工程」。Nahar 等人对 26 次访谈和 182 名微软实践者的调查，编目了 19 项正在出现的做法，包括定性和定量指标结合、用大语言模型当裁判、自动化离线测试。Terragni 等人把软件工程看成从以代码为中心，走向智能体式、协作式的人工智能系统。更早的设计研究包括 Visual Studio 里的补全体验、Meta 的 CodeCompose，以及 PromptMaker、Promptify 这类提示原型工具。模型上下文协议被写成把大语言模型和智能体安全、透明地连到组织系统的开放、厂商中立标准。

这些工作大多聚焦通用或企业软件。嵌入式领域仍然探索不足。本文补的是：嵌入式组织如何负责任地集成生成式人工智能。

VI 含义

把生成式人工智能放进嵌入式开发，不只是技术挑战，而是触及战略、基础设施和职业身份的多维转变。智能体流水线在重塑组织如何分配责任、如何理解可复现、如何定义对自动系统的信任。含义分三块：正在出现的协议、战略路径、未来和更宽的边界。

VI-A 正在出现的协议

人工智能友好代码协议（AICP）规定项目里的信息应如何结构化，以便人工智能解释。MCP 提供基础设施，让这些制品在人工智能系统和企业数据源之间安全交换：双向、经过认证的通信，强制访问控制和可审计，回应数据治理和模型透明度的担忧。一位参与者说，所有工具都应有符合 MCP 的接口，智能体才能在流水线里安全使用。两者是互补层：AICP 管交换什么、如何表示；MCP 管如何传输、校验和记日志。

对人工智能友好的代码是结构化、上下文丰富、机器可读的代码，被广泛认为是实现 AICP 的关键。有人看成模型成熟之前的临时适应，有人看成良好工程卫生的持久演变。在确定性和可追溯关键的嵌入式系统里，这类做法很可能留下来。把元数据、模型标识和生成上下文嵌进制件，既帮助机器理解，也帮助长期维护。

提示作为一等制品。参与者一致强调，提示和指令文件必须是正式项目资产，而不是转瞬即逝的文本。它们抓住设计意图、约束和推理，是复现或审计生成代码的必要上下文。有人说，他们开始保存用于生产代码的每一条提示，这已经是文档的一部分。把提示和源代码一起做版本，不仅使复现成为可能，也在人的意图和人工智能生成的制品之间建立新的可追溯链接。

VI-B 战略路径

采用有两条轨迹。自上而下由领导授权和集中基础设施驱动，对齐、合规和资源更有保障，但可能压住本地创新。自下而上由实践者实验带动，创造力和学习快，但实践和治理容易碎片化。一位工程师说，管理层在推使用人工智能，真正学会它怎么工作的，是在实验的小团队。看起来更可持续的是混合：领导层划边界和激励，团队在本地适应和迭代。

什么算可复现。嵌入式开发期望相同工具链得到相同二进制。生成系统打破这一点，因为输出天生随机，而且随时间演化。参与者强调要追溯生成上下文，包括提示、模型版本和配置。一位说，在汽车行业，十五年前的整个环境都能重建，但不能用同样的方式把模型签入。另一位说，需要存的不只是代码，还有它如何生成：提示、模型，一切。因此可复现也许要被重新定义成固定约束下的功能等价，而不是字节级相同。这与其他受监管领域的安全认证实践更一致。

VI-C 未来方向

人在回路何时可以跳过，仍是开放问题。参与者同意，安全和合规关键的软件，人的评审不可缺少；文档、测试生成或非生产构建这类低风险任务，部分自动化是可行的。一位工程师说，我们信任编译器优化代码而不检查每一条指令，也许有一天会以同样方式信任人工智能智能体。这指向按风险分层的自主：监督强度随制品类型和智能体已被证明的可靠性而变。

研究聚焦软件开发，但参与者预期生成式人工智能会远超出工程角色，财务、人力资源和运营里已经有智能体在做文档、分析和决策工作流。文中说这创造出价值以百万美元计的业务价值，这是参与者的观察和预期，不是本文测量。一位说，不只是开发者，从工程师到会计，人工智能都会改变每个人怎么工作。嵌入式工程里的集成，可能成为更宽组织适应的样板，需要跨部门协调培训、治理和伦理监督。

是不是开始探索已经太晚。并非所有参与组织都已把人工智能放进生产工作流。有人问：是不是已经太晚？大玩家已经训练自己的模型很多年，而我们还在弄清怎么用 Copilot。讨论中的共识是，开始探索从来不会太晚。更小或更传统的公司可能失去了开发专有基础模型的先发优势，仍可以利用领域数据、系统知识和既有过程，去微调或定制已有模型。原文这里人称混用，意思是：自己未必造基础模型，但数据在自己手里，用已经知道的东西做微调可能是捷径。后来者还可能避开早期实现的坑，用上更稳的工具链、接口和治理框架。对嵌入式供应商，这可以变成更快、更安全的集成，使用最新的智能体架构和上下文协议，而不背上遗留实验的技术债。

参与者设想的近期未来是：智能体式持续集成与持续部署通过结构化协议、标准化制品，以及演变中的人与人工智能协作，重塑嵌入式软件工程。要做到这一点，必须平衡战略对齐、稳健治理和文化准备，使自动化增强而不是损害嵌入式系统所要求的严格和可靠。

VII 结论

本研究调查嵌入式软件领域的组织如何采用并适应生成式人工智能，以及对工程实践、职业角色和治理意味着什么。对四家公司十位资深工程师的焦点小组和头脑风暴做定性分析后，作者识别出十一项正在出现的做法和十四项关键挑战，聚成三个主题。正文前面把第三主题称为可持续采用，结论改称为组织标准化。

团队开始把人工智能放进持续集成与持续部署，设计对人工智能友好的制品，把提示管理和人在回路的监督正式化，并通过培训、标准化和 MCP 这类协议建设机构能力。同时，他们面对生成制品的认证、非确定模型下的可复现、长期可追溯，以及烟囱和监管约束下的组织对齐。

这些发现说明，在嵌入式开发中采用生成式人工智能，不只是接上工具，而是重塑工作流、治理模型和能力结构。成功采用要求技术基础设施和组织实践一起演化，使自动化增强而不是削弱系统所要求的可靠性、可追溯性和监管合规。