形式语义作为 AI 辅助软件工程中缺失的控制层
I’m happy to translate the article for you, but I need the full text of the post (the content you’d like translated). Could you please paste the article’s body here? Once I have the text, I’ll provide a complete Simplified Chinese translation while keeping the source link, formatting, markdown, and any code blocks or URLs unchanged.
最近的研究概览 (2025)
关键洞见：
在需求工程、形式化方法、程序验证和 AI 原生工具链中，出现了一个共同的模式：只有在意义被明确、结构化并受到形式约束时，大语言模型（LLMs）才能显著帮助软件构建。
没有这些约束，AI 驱动的开发会在可复现性、可解释性和长期可维护性方面遇到困难。
本文综合了近期的同行评审论文、实证研究和形式化方法研究，展示了 显式语义、形式规范和确定性接受机制 如何共同构成更可靠、可扩展的 AI 辅助软件工程的基础。虽然没有单篇工作提出完整的端到端范式，但各个构建块已经清晰可见。
需求不是文档——它们是控制结构
2025 年文献中的一个核心转变是 对需求的重新定义。需求不再被视为描述性产物，而是日益被理解为 为 AI 系统结构化并控制输入的手段。
| 研究 | 贡献 |
|---|---|
| Ferrari & Spoletini – Two‑way roadmap on formal requirements engineering and LLMs | 将形式化需求定位为在使用 LLM 进行软件开发时提升可控性、可解释性和可验证性的手段。主张形式化需求在人的意图与机器生成之间提供结构化接口。 |
| Caporusso & Perdue – ISCAP 2025 | 实证表明 需求优先工作流（在调用 LLM 生成代码之前先生成结构化规范）能够显著提升输出质量，优于直接提示生成代码的方式。 |
| Lu et al. – Multi‑agent vision for requirements development and formalization | 提出一个系统，在下游代码生成之前主动对需求进行细化和形式化。强调 “需求 → 形式化” 是一项一等的质量杠杆。 |
新兴模式： 不是 AI 对抗 形式方法，而是 AI 嵌入在形式化控制之中。
责任划分：AI 与形式机制
2025 年研究的另一个一致主题是 明确的责任划分：
- AI 擅长提出候选产物（契约、后置条件、注解、文档）。
- 形式机制 保持对正确性、有效性或接受性的确定性决策。
| 研究 | AI 的角色 | 形式方法的角色 |
|---|---|---|
| Teuber & Beckert – LLM‑supported Java verification | 生成候选 JML 规范。 | 演绎验证充当接受门槛。 |
| Zhang, Wang & Zhai – Post‑condition inference | 推断有意义的后置条件（即使使用相对较小的模型）。 | 展示下游检查的可行性。 |
| Recio Abad et al. – Formal JML context for Java documentation | 生成 Java 文档。 | 形式化 JML 规范约束 AI 输出，即使没有完整的形式化证明。 |
语义一致性作为系统层属性
除了单个产物外，2025 年的若干贡献关注 系统层面的语义一致性。
-
基于模型的系统工程 – Cibrián 等
在元模型层面编码语义约束，并在复杂的 SysML v2 模型空间中自动验证这些约束。 -
AI 原生编译器讨论 – Cogo、Oliva 与 Hassan
将可复现性和互操作性识别为将高级意图转化为可执行系统时的核心未解挑战。 -
治理视角 – Think7 2025 年关于 “Rules as Code” 的政策工作
将意图和法规转化为机器可执行的表示，以提升透明度、可追溯性和一致性。
纯意图驱动（对话式）方法的局限性
（后续内容将在第 2 部分继续）
onal) 方法
Purely conversational programming paradigms encounter structural limits as systems grow in complexity.
| 研究 | 发现 |
|---|---|
| Bamil – Vibe coding | 强调在代码主要通过对话交互生成时，关于可重复性、可维护性和可解释性方面的挑战。 |
| Sarkar & Drosos – Empirical work | 使用对话式编程工具的开发者必须高度依赖迭代检查和手动验证来建立信任。 |
| Sapkota et al. – Vibe coding vs. agentic approaches | 强调缺乏正式的接受标准仍是核心限制。 |
综合结论
- 显式、形式化语义 是实现可扩展且可靠的 AI‑辅助软件工程的核心推动因素。
- 大型语言模型（LLM）非常适合提出形式化产物，而 形式化验证提供最终的依据。
- 确定性接受机制 在技术上是可行的，并已在特定领域得到验证。
- 只要意义被显式建模，语义一致性可以在系统层面强制实现。
- 目前尚无工作能够端到端覆盖完整范式，但必要的形式化组件已清晰可辨。
要点: 2025 年的研究呈现的图景并非自动化取代纪律，而是 纪律促成自动化。AI 可以加速软件构建——但前提是嵌入显式语义、形式化规范和确定性验证的框架。
语义‑优先的 AI‑辅助软件工程
向 语义‑优先 AI‑辅助软件工程的转变强调了 形式规范、确定性接受 和 基于合约的开发 的必要性。这一视角与诸如 Secos Rocks 等实际工作相契合，后者研究语义‑优先和基于合约的 AI‑支持软件构建方法。
因此，AI‑辅助软件工程的未来 不是 基于提示的即兴创作，而是 以语义为中心的构建。
参考文献
- Ferrari, A.; Spoletini, P. (2025). Information and Software Technology, 卷 181, 2025年5月, 107697.
- Caporusso, N.; Perdue, J. (2025). Proceedings of ISCAP 2025.
- Lu, Y.; et al. (2025). arXiv:2508.18675.
- Teuber, S.; Beckert, B. (2025). arXiv:2502.01573.
- Zhang, G.; Wang, Z.; Zhai, J. (2025). arXiv:2507.10182.
- Recio Abad, J.; et al. (2025). arXiv:2506.09230.
- Cibrián Sánchez, E.; et al. (2025). IEEE Access 2025.3587786.
- Cogo, F. R.; Oliva, G. A.; Hassan, A. E. (2025). arXiv:2510.24799.
- Rapson, J.; et al. (2025). Think7 (G7) Policy Brief.
- Bamil, V. (2025). arXiv:2510.17842.
- Sarkar, A.; Drosos, I. (2025). arXiv:2506.23253.
- Sapkota, S.; et al. (2025). arXiv:2505.19443.