日程 › Agentic AI 软件工程方法论与形式化验证 › 纪要
需求编译与软件工厂
金句 · 一句话抓重点
需求终将被源码化——像编译器一样，把自然语言需求「编译」成可运行的系统。
📊 信息图 · 一图读懂
音频围绕需求编译、软件工程方法、智能体编程等内容展开，探讨了相关技术的应用、挑战及行业趋势，还介绍了教学实践和未来计划
①
需求编译与软件工程发展
抽象过程与新思路
②
智能体编程面临的挑战
学生使用问题
③
解决方案与框架
二框架设想：提出 agent requirement compiler
④
行业趋势与教学计划
行业趋势判断：编码外包行业逐渐衰落，需求工程和测试工程的工作量将显著提升
智能纪要
音频围绕需求编译、软件工程方法、智能体编程等内容展开，探讨了相关技术的应用、挑战及行业趋势，还介绍了教学实践和未来计划，内容如下：
- 需求编译与软件工程发展
- 抽象过程与新思路
- 不断抽象的历史：从自动化底层的高低电平到高级语言，编程语言和软件工程经历了不断抽象和自然语言化的过程。如今在大语言模型时代，思考能否再次进行抽象，将程序员的自然语言编程，把高级语言转化为新的中间语言。
- 需求编译的作用：需求编译是解决自动化二义性和确定性问题的有效思路，可将人的需求更好地转化为代码。
- 智能化工程课程实践
- 课程内容设置：9 月与斯坦福同时开课，开展智能化工程课程。前两个月教授软件工程基本概念，要求学生复刻 12306 和携程网站；后期讲解需求驱动、MCP 和智能体编程，让学生根据需求文档编译出已实现的项目。
- 实践结果：正常无法编程的 GUI 测试通过率为 96%，需求编译成功率基本为 100%，总体较为成功，但也收到一些差评。
- 智能体编程面临的挑战
- 学生使用问题
- 缺乏驾驭能力：学生在未掌握方法论时，面对大模型生成的大量代码，不知如何修改，缺乏驾驭模型的能力。
- 调试与阻断困难：需求编译耗时较长，大模型持续编写代码时，学生不知如何调试和阻断，心流体验差。
- 技术层面问题
- 需求处理难题：当需求文档包含大量场景时，大模型难以处理复杂需求，会出现需求遗漏和自由发挥的情况。
- 多模态处理挑战：需求文档是多模态的知识载体，如何将其转化为代码的前端和后端是需要解决的问题。
- 代码维护问题：要确保编出的代码可维护、能进行增量修改和持续演化，避免出现“屎山代码”。
- 缺陷追溯与管理：面对多个智能体编程，如何追溯缺陷、进行可控管理和保持心流体验是亟待解决的问题。
- 解决方案与框架
- 二框架设想：提出 agent requirement compiler 二框架，希望像传统编译器一样提高抽象层次，跨越自然语言需求和可执行形态之间的鸿沟。
- 软件开发流程
- 需求分解与测试用例生成：让智能体根据复杂需求分解出大框架，为框架内的每个接口生成测试用例，将需求阅读态转化为执行态，使软件开发从基于逻辑开发变为优化问题。
- 代码填充与测试：根据细粒度需求生成测试用例，反向填充代码，通过单元测试、集成测试和 GUI 测试，最终完成可交付的软件系统。
- 软件维护与追溯：利用智能体系统可快速维护软件，通过 git 作为特殊日志方式，让人能回溯需求和让智能体重返工，实现历史追溯。
- 行业趋势与教学计划
- 行业趋势判断：编码外包行业逐渐衰落，需求工程和测试工程的工作量将显著提升，还提出软件再造工程的概念，如 CUDA 算子向 CAN 算子的自动迁移。
- 教学记忆场推出：推出 Artbench 需求编译和软件工厂的教学记忆场，将代码生产过程可视化，引导大家尝试将复杂文档转化为系统。
- 课程回顾与交流邀请：回顾课程顶住教评压力，邀请多位老师授课，感谢字节跳动赞助，欢迎各界来交大交流。
章节速览
00:00需求编译、软件工程方法及编程抽象新思路
本章节中，说话人1先介绍董老师网球相关背景，提及会议进展有故事性，工业界与学术界态度不同。指出破立循环能推动事物发展，强调需求编译是解决自动化顽疾的好思路。回顾编程语言从高低电平到高级语言的抽象过程，提出在大语言模型时代再做一次抽象，将程序员需求自然语言化变成新中间语言。
02:38智能化工程课程成果及AI带来的利弊问题
本章节介绍了9月与斯坦福同时开设的智能化工程课程。前两个月教软件工程基本概念，让学生复刻12306和携程网站，后期讲需求驱动等。需求编译结果总体成功，GUI测试通过率96%，需求编译成功率100%。课程有好评也有差评，一是学生无驾驭模型之力，二是编译时间长，不知如何调试阻断，AI带来新挑战和人机交互问题。
06:02智能体编程面临的挑战及待解决问题
本章节主要讨论了智能体编程面临的挑战。一是需求文档场景过多时，大模型难以处理，会出现需求遗漏和自由发挥问题；二是多模态处理难题，需将含文本、图片、视频的知识载体转化为代码；三是软件工程问题，要保证代码可维护、能增量修改和持续演化；四是涉及多个智能体时，要解决缺陷追溯、可控管理和保持交互体验等问题。
07:08紧缺体系方案与二框架助力软件开发优化
本章节介绍了紧缺体系方案的二框架“agent requirement compiler”，希望像编译器一样拔高抽象层次，跨越自然语言需求和可执行形态间的差距。在软件工程流程上，让智能体先分解复杂需求成大框架，为框架接口生成测试用例，实现两个目的：使需求从阅读态变为执行态，让软件开发从基于逻辑开发变为优化问题。
08:34多模态需求建模及软件开发流程介绍
本章节围绕多模态需求建模展开，需求具有二义性，需破解以增强确定性，用 DCL 分解需求。学生写文档本质是需求建模，借助工具引导。给定需求可分解为 UI、API 等模块，搭建框架。通过自顶向下分解需求生成测试用例，再自底向上填充代码，经单元、集成、GUI 测试，完成可交付软件系统。
11:31智能体系统助力软件维护及迭代追溯成果
本章节围绕软件工程中的软件维护展开。指出软件维护代价大，痛点在于需求快速迭代后代码的维护更新。智能体系统可快速维护需求、设计、底层实现和测试等，还能对节点进行操作。将git作为特殊日志方式，便于驾驭复杂迭代过程和追溯历史。文章虽发表且效果优于基线，但表示事情尚未完成。
13:05编码趋势、人机交互及软件再造工程探讨
本章节主要讨论了生成需求时的痛点，如自然语言描述不清导致完备性、断言生成和需求数量不足，需人为干预；还提到软件工厂模式下人机交互界面及监控能力的重要性。趋势判断认为编码行业受影响，需求工程和测试工程工作量将提升。此外，提出软件再造工程概念，并提及 CUDA 算子往 CAN 算子自动迁移的尝试。
14:46Artbench教学记忆场设想、课程情况及交流邀请
本章节说话人1介绍将推出Artbench，即需求编译和软件工厂的教学记忆场。会做demo，把代码生产过程可视化，引导大家尝试将复杂文档转化为系统。认为需求会源码化，需编译并引入约束，人更多做监控。还提及课程顶住教评压力搭建，邀请老师分享，感谢字节赞助，欢迎大家来交大交流。
🤖 模型解读 · 要点点评AI 生成的第三方点评 · 由大模型 Claude（Opus 4.8）依据本场智能纪要撰写，非主办方 / 演讲者观点，可能有误，仅供参考
林云把「软件工厂」从口号做成了可教、可测的课程实验：与斯坦福同期开课，让学生用「需求编译」复刻 12306 / 携程，GUI 通过率 96%、需求编译成功率近 100%。更可贵的是他诚实报告了「差评」——学生驾驭不了大模型生成的海量代码、调试无从下手，这些「心流被打断」的细节，比成功率更有信息量。
要点需求编译：像传统编译器一样抬高抽象层次，跨越自然语言需求与可执行形态的鸿沟。
点评这是对「prompt engineering → requirement compilation」趋势最具体的工程化。把软件开发从「基于逻辑的编写」重述为「基于测试用例的优化问题」，是范式级的视角转换。
要点GUI 测试通过率 96%、需求编译成功率近 100%，但也收到差评。
点评漂亮的数字背后，真正的金矿是差评：学生「无驾驭模型之力」「不知如何调试阻断」。这说明瓶颈已从「能不能生成」转向「人如何监控与干预」——这是 HCI 问题，而非模型能力问题。
要点用 git 作为「特殊日志」来回溯需求、让智能体重返工，避免「屎山代码」。
点评一个朴素却聪明的工程手法：把版本控制重新诠释为 agent 协作的可追溯层。它直面了多 agent 编程最致命的风险——可维护性与缺陷追溯，而非一次性生成的炫技。
要点趋势：编码外包衰落，需求与测试工程量上升；并提出「软件再造工程」（CUDA→CANN 算子自动迁移）。
点评这个判断与全天主线高度自洽。「再造工程 / 代码迁移」很可能是 AI 编程最先产生确定商业价值的场景——因为它有明确的正确性判据（行为等价），最适合「验证比生成便宜」的范式。
现场幻灯片 · 14 张
📷 参会者现场拍摄的演讲幻灯片 · 点击放大翻看（支持 ← → ↑ ↓ 键、滑动、自动播放 ▶）。为保护隐私，画面中的人脸已自动打码；按拍摄归集，个别可能串场。
本场涉及 · 知识库
以上为飞书妙记 AI 自动生成的纪要与章节摘要，可能存在识别误差，仅供参考。