---
type: article
title: "从代码编写到需求编译：智能体软件工程的范式演进、技术框架与教学实践"
date: 2026-08-09 13:37:00 +0800
tags: [agent, coding, arc, llm, dsl, tdd]
---

## 摘要
大语言模型驱动的代码生成技术正在重构传统软件工程的生产模式，软件开发重心逐步从**手工代码编写**迁移至需求定义、约束建模与质量验证环节。上海交通大学林云副教授提出 **需求编译（Requirement Compilation）** 理念，以 **ARC（Agentic Requirement Compilation）智能体需求编译**框架为核心，探索把大规模多模态业务需求文档直接转化为可运行软件系统的技术路径，同时开展面向智能体软件工程的课程教学改革，推动开发者从“代码工人”向“智能体架构师”转型。本文基于该前沿报告，梳理智能体软件工程范式变革背景、ARC框架技术原理、现存技术痛点、教学实践方案，同时分析产业落地瓶颈与未来研究方向，为Agent软件工程领域提供研究参考。

**关键词**：智能体软件工程；需求编译；ARC框架；大语言模型；测试驱动开发；DSL领域特定语言

## 一、引言
传统软件工程流程以人工编码为核心，需求、设计、编码、测试环节由人主导完成。生成式大模型出现后，单轮提示词生成小程序代码已经较为成熟，但面对**包含数十至数百业务场景的大规模真实业务需求**时，通用大模型普遍存在需求理解不全、逻辑幻觉、边界场景遗漏、架构混乱、需求‑代码不可追溯等问题，很难直接产出完整可维护的软件系统，形成AI编程的“复杂性高墙”。

现有Agent编程大多聚焦于代码补全、小脚本生成，缺少一套完整的、工程化的端到端链路：即从非结构化自然语言需求出发，自动完成架构设计、模块拆分、代码实现、测试生成、缺陷追溯全流程。在此背景下，**需求编译**概念被提出：这里的“编译”不再是传统高级语言转机器码，而是**把业务需求规格（自然语言/多模态文档）编译转换为完整、可测试、可运行的软件项目制品**，包含架构、代码、测试用例、链路追溯信息。

B站视频[《需求编译：智能体软件工程演进的教学与前沿探索》](https://www.bilibili.com/video/BV1e3Tj6sEsp/)完整呈现该方向科研与教学两条主线：科研上构建ARC智能体需求编译框架；教学上重构软件工程课程，训练学生指挥多智能体完成复杂业务系统开发，实现业务概念与底层编码解耦。

## 二、范式变革：从代码编写走向需求编译
### 2.1 传统软件工程与AI时代的角色迁移
传统软件工程V模型：业务需求→系统规格→高层设计→底层设计→编码，配套对应层级验收、系统、模块、单元测试。开发者核心工作是写代码。

智能体软件工程范式发生翻转：
> **人负责定义需求、约束、验收标准；AI智能体负责架构设计、编码实现、单元模块测试**。

开发者不再主要手写大量业务代码，核心能力转变为：需求拆解、编写约束、定义验收测试、建模领域知识、校验智能体输出，成为**智能体架构师**。

### 2.2 需求编译的核心内涵
需求编译（Requirement Compilation）：输入为非结构化多模态需求文档（文档、截图、业务流程描述，包含50‑200个业务场景）；输出为完整可运行软件系统，包含软件架构、模块化源码、全套测试套件、**需求‑设计‑代码‑测试之间全链路可追溯关系**。

和普通LLM代码生成的本质区别：

|维度|普通LLM代码生成|需求编译ARC范式|
|---|---|---|
|输入|简短自然语言提示词|大规模多模态业务需求文档|
|工作模式|单次生成|多智能体双向测试驱动迭代|
|产出|片段代码/小demo|完整可维护项目，含架构、测试集|
|可靠性保障|依赖模型自身能力|测试用例作为约束，强制校验输出|
|可追溯性|缺失|完整链路记录，定位哪段需求对应哪段代码|

### 2.3 当前智能体软件工程面临关键挑战
1. **幻觉与场景遗漏**：面对大量业务场景，大模型容易忽略边界条件，生成逻辑错误代码；
2. **架构失控**：长上下文下，智能体难以维持全局架构一致性，模块耦合混乱；
3. **调试追溯困难**：智能体生成上万行代码后，出现缺陷很难回溯原始需求，分不清错误来自需求歧义还是模型生成错误；
4. **可维护性差**：生成代码缺少规范，无法迭代演化；
5. **评估难**：缺少面向完整系统的自动化评测手段，仅靠人工肉眼判断效果，难以工业化落地。

## 三、ARC（Agentic Requirement Compilation）需求编译框架技术解析
ARC框架是需求编译理念的工程化实现，模拟传统软件工程V模型，构建**双向测试驱动智能体工作流**：自顶向下架构分解 + 自底向上代码实现，依靠测试作为约束，约束智能体的每一步输出，缓解大模型幻觉问题。

### 3.1 整体工作流程
1. **需求结构化建模**：将非结构化多模态业务需求，转化为轻量级图结构DSL（面向智能体的领域特定语言），把业务场景、约束、交互逻辑显式建模；
2. **自顶向下：架构与测试生成**：多智能体完成系统高层、底层架构拆分，同步生成对应层级验收测试、模块测试、单元测试套件；**先出测试，后实现代码**，继承测试驱动开发TDD思想；
3. **自底向上：受约束代码生成**：各个模块智能体，以上一步生成的测试用例作为校验oracle，迭代生成模块代码，运行测试，不通过则修复，直到满足测试约束；
4. **全链路追溯记录**：记录每一条原始需求对应哪些架构节点、哪些代码片段、哪些测试用例；当出现bug时，可以反向定位是需求歧义，还是架构错误，还是代码生成错误；
5. **系统集成与输出**：整合全部模块，输出完整可运行Web系统，配套完整测试集、追溯元数据。

### 3.2 实验效果
在Web系统基准集、AppForge移动端生成任务基准开展评测，ARC的GUI自动化测试通过率对比主流大模型基线平均提升**50.6%**，可以处理50‑200个业务场景的复杂需求文档，输出完整Web应用系统。

### 3.3 关键创新点
1. 将经典软件工程V模型转化为多智能体可执行工作流，把测试驱动开发TDD引入Agent系统构建；
2. 面向智能体设计轻量级图DSL，解决非结构化需求歧义；
3. 需求‑架构‑代码‑测试全链路可追踪，解决AI生成软件难以调试的痛点；
4. 双向驱动：自上而下做架构拆分，自下而上受测试约束实现代码，防止长上下文带来的全局架构崩坏。

## 四、智能体软件工程的教学实践探索
报告同时展示软件工程课程改革实践，面向学生开展智能体软件工程教学，解决AI时代软件工程人才培养问题。

1. **角色转变教学目标**：不再训练学生重点练习手写大量业务代码，而是培养学生成为**智能体架构师**，学会如何描述需求、定义DSL模型、编写验收测试、指挥多智能体协作完成大型系统；
2. **课程实践案例**：让学生使用该范式指挥多智能体复现12306这类复杂业务系统。业务逻辑、流程、约束由学生建模定义，底层编码交给智能体完成，实现业务概念与底层编码解耦；
3. **教学逻辑**：学生核心训练点：需求分析、规格建模、测试定义、验证与纠错，而不是机械写代码；理解大模型概率性缺陷，学会用测试约束去制衡模型幻觉；
4. **教学启示**：软件工程教学需要更新，除传统软件开发知识外，增加智能体建模、测试驱动AI开发、AI生成制品校验、可追溯工程思维等新内容。

> 痛点：如果教学仍然只训练学生手写代码，会与产业现实脱节；未来工程师的竞争力来自需求、约束、验证能力，而不是单纯敲代码。

## 五、现存局限与产业落地现实困境
尽管ARC取得显著评测提升，但距离大规模工业落地仍存在明显瓶颈：
1. **需求本身的歧义问题**：如果原始业务需求文档模糊、互相矛盾，即便再好的智能体框架，也无法产出正确系统；需求编译不能替代需求分析工作；
2. **复杂非功能性需求支持不足**：性能、安全、并发、高可用这类非功能约束，目前DSL与测试体系还难以完整刻画；
3. **成本开销**：多智能体多轮迭代，大量调用大模型，Token消耗高，系统构建时间长；
4. **马太效应**：框架高度依赖底层大模型能力，基座模型能力直接决定输出质量；
5. **调试负担转移**：代码写得少，但架构、DSL、测试用例编写、调试的负担转移到人类架构师身上，对人的业务建模能力提出更高要求。

FlagOS开源生态与SkillHub技能库也为该方向提供底层支撑：通过Skill标准化封装领域最佳实践，给编程智能体注入软件工程领域知识，降低智能体软件工程落地门槛。

## 六、未来研究方向
1. **DSL领域特定语言演进**：设计更加友好、可面向业务人员使用的需求建模DSL，降低需求结构化门槛；
2. **非功能需求编译**：把性能、安全、并发约束纳入需求编译链路，生成同时满足功能与非功能指标的软件；
3. **需求歧义自动检测**：智能体自动识别原始需求文档内部矛盾、缺失，主动向人提出澄清问题；
4. **智能体软件工程完整评测体系**：不止GUI通过率，构建架构质量、可维护性、可追溯性多维度评测基准；
5. **教学工具链完善**：开发面向高校教学的需求编译轻量化教学平台，赋能软件工程课程改革；
6. **与现有CI/CD工程体系打通**：把需求编译输出无缝接入现有工业持续集成流水线，真正融入企业软件开发流程。

## 七、结论
需求编译代表智能体时代软件工程的重要演进方向：软件开发从“人写代码”演进为“人定义需求与约束，智能体完成架构与编码实现”。ARC框架验证了双向测试驱动、DSL建模、全链路追溯可以显著提升大模型从大规模需求生成完整软件系统的能力。

与此同时，软件工程人才培养需要同步变革，重点培养“智能体架构师”能力，聚焦需求建模、规格定义、测试约束、输出校验。该方向仍存在需求歧义、非功能需求处理、计算成本等现实挑战，未来需要学术界、开源社区（FlagOS）、产业界共同推进技术迭代与工具链建设。

## 参考文献
- [1] 林云.从“代码编写”到“需求编译”：AI智能体驱动下的软件工程演进与前沿探索[R].2026智源大会&第9届AI+研发数字峰会，2026.
- [2] Kong W, Lin Y, et al. Compiling Large Multi‑Modal Requirement Documents into Runnable Software Systems: From an Agentic Test‑Driven Perspective[J].arXiv preprint arXiv:2602.13723,2026.
- [3] CCF. SPP第164期：从“代码编写”到“需求编译”——AI智能体驱动下的软件工程教学演进与前沿探索[EB/OL].CCF数字图书馆，2026.
- [4] B站视频：上海交大计算机学院副教授林云分享需求编译：智能体软件工程演进的教学与前沿探索，BV1e3Tj6sEsp，2026‑07‑11.
