[论文阅读] 人工智能 + 软件工程 | LLM辅助软件开发：需求如何转化为代码？
LLM辅助软件开发：需求如何转化为代码？——解读《From Requirements to Code》
论文标题：From Requirements to Code: Understanding Developer Practices in LLM-Assisted Software Engineering
arXiv:2507.07548
From Requirements to Code: Understanding Developer Practices in LLM-Assisted Software Engineering
Jonathan Ullrich, Matthias Koch, Andreas Vogelsang
Comments: This paper has been accepted for publication at the 33rd IEEE International Requirements Engineering (RE) conference
Subjects: Software Engineering (cs.SE)
研究背景：LLM来了，需求工程就没用了吗？
近年来，生成式大语言模型（LLM）如GPT-4、CodeLlama等展现出惊人的代码生成能力。有人畅想：未来，领域专家只要把需求告诉LLM，就能直接得到完整的软件，传统软件工程流程可能会被颠覆。
但现实真的如此吗？
在实际开发中，软件的诞生离不开“需求-设计-实现”的流程：需求描述“做什么”，设计衔接“怎么做”，最终由开发者转化为代码。而LLM虽然能生成代码，却面临一个关键问题——它能直接理解原始需求吗？
论文中提到一个生动的案例：有开发者直接把“为Keithley万用表写一个命令接口”这样的需求输入LLM，结果生成的代码完全无法使用。另一位从业者也表示，直接用大粒度需求生成代码，往往需要大量调整，效率极低。
这揭示了一个核心矛盾：现有研究多关注LLM的代码生成能力，却很少思考它如何融入完整的软件工程流程，尤其是需求和设计在LLM辅助开发中到底扮演什么角色。这正是这篇论文要解决的问题。
主要作者及单位信息
- Jonathan Ullrich、Matthias Koch：德国弗劳恩霍夫IESE研究所（Fraunhofer IESE Kaiserslautern）
- Andreas Vogelsang：德国杜伊斯堡-埃森大学Ruhr软件技术研究所（paluno – The Ruhr Institute for Software Technology）
创新点：首次揭开工业实践中LLM与需求的“互动密码”
这篇论文的独特之处在于，它跳出了实验室里的代码生成 benchmark，聚焦真实工业场景，首次系统回答了“开发者如何在LLM辅助开发中处理需求和设计信息”。
具体来说，它的创新点包括：
- 打破“LLM直接接收需求就能生成可用代码”的误区，明确传统需求必须经过“翻译”才能被LLM有效利用；
- 构建了两个实用模型：描述需求到代码的过程模型（怎么做）和提示词的内容模型（输入什么）；
- 总结了开发者使用LLM的三种典型交互模式，揭示了LLM在实际开发中的“真实位置”。
研究方法：18位从业者的“真心话”如何变成理论？
论文采用定性访谈法，整个研究过程可以拆解为4个步骤：
-
选对人：访谈18名从业者，覆盖14家公司（大中小规模都有）、12个领域（如汽车、医疗、电商），角色包括开发者、软件架构师、产品负责人等。他们使用的需求类型（用户故事、标准化规格等）和LLM交互方式（ChatGPT等聊天工具、GitHub Copilot等IDE集成工具）也多样化，确保结论的普适性。
-
问对问题：采用半结构化访谈，分两部分：
- 第一部分：了解从业者不用LLM时的开发流程，以及需求、设计等前期文档的情况；
- 第二部分：聚焦LLM使用场景，比如“什么时候会想到用LLM？”“提示词里会写什么？”“怎么确保生成的代码符合需求？”。
-
挖深信息：访谈时长30-60分钟，全程录音并转录（德语访谈用DeepL翻译成英语），最终提炼出179条关键引用作为分析基础。
-
建出模型：通过“归纳编码”分析数据——先把引用归类成“主题”，再合并成更高层次的模型。比如从“需求太抽象，得拆成小任务”这个共同反馈，提炼出“需求分解”的过程；从“提示词里要写架构约束”等说法，总结出内容模型的要素。整个过程由三位作者交叉验证，确保结论可靠。
主要贡献：原来LLM辅助开发是这样“玩”的
论文的核心发现可以总结为“1个核心结论+2个模型+3种模式”，直接告诉你在实际开发中该如何用好LLM：
核心结论：传统需求不能直接喂给LLM
开发者不会把用户故事、功能需求等原始需求直接输入LLM，因为这些需求太抽象。他们会先把需求拆解、细化成“编程任务”（比如“实现用户登录的密码加密功能”），再用这些具体任务作为LLM的输入。
过程模型：从需求到代码的“两步走”
第一步：把需求拆成编程任务。比如“做一个电商购物车”这个需求，会被拆成“计算商品总价”“处理优惠券折扣”等具体任务；
第二步：用LLM实现编程任务，有三种方式可选：
- 技术探索：如果任务不熟悉（比如“如何用Python解析JSON”），先让LLM给出解决方案思路；
- 代码生成：明确任务时，让LLM生成代码（需提供代码上下文，比如现有函数、框架约束）；
- 手动编码：生成的代码不合适时，手动编写或调整，可能搭配IDE的自动补全功能。
内容模型：好提示词得包含这些“料”
想让LLM生成能直接用的代码，提示词不能只写编程任务，还得加这些信息：
- 业务逻辑/算法（比如“按用户等级计算折扣”）；
- 架构与部署约束（比如“必须符合公司的云原生规范”）；
- 语言和库（比如“用Java 17和Spring Boot框架”）；
- 接口和数据格式（比如“返回JSON格式，包含code和message字段”）；
- 单元测试要求（比如“需要覆盖90%的分支”）；
- 现有代码上下文（比如“调用已有的UserService类”）。
三种交互模式：不同开发者的“LLM使用偏好”
- 增量代码生成：像“结对编程”一样，交替用LLM探索方案、生成代码和手动调整，适合用聊天工具（比如ChatGPT），能复用聊天历史的上下文；
- 手动编码+智能补全：主要自己写代码，偶尔接受IDE集成工具（比如GitHub Copilot）的自动补全建议，LLM的作用较小；
- 广泛代码生成：尽可能让LLM多干活，自己专注于写提示词和检查代码（比如“我几乎不自己写代码了，主要和AI迭代”）。
1. 一段话总结
本研究通过对14家公司的18名从业者进行访谈，探究了从业者在LLM辅助开发中如何整合需求和设计信息。核心发现包括：传统需求文档过于抽象，需分解为编程任务才能作为LLM输入；从业者通过过程模型（分解需求为编程任务，结合技术探索、代码生成、手动编码实现）和内容模型（在提示中加入业务逻辑、架构约束、代码上下文等）使用LLM；存在增量代码生成、手动编码与智能自动补全、广泛代码生成三种交互模式。研究表明，LLM辅助开发仍需需求工程和软件工程专业知识，全自动软件工程仍为远景。
2. 思维导图
3. 详细总结
一、研究背景
- 生成式LLM（如GPT-4、CodeLlama）在代码生成等任务中表现出色，工具（如GitHub Copilot）提升了易用性。
- 现有研究多关注LLM的代码生成能力，但较少结合软件工程流程，尤其是需求工程和设计阶段的作用，存在研究空白。
二、研究目的
- 核心问题：从业者如何在LLM辅助开发中整合需求和设计信息。
- 具体目标：明确从业者是否将需求作为提示输入，以及提示中需包含的设计信息。
三、研究方法
- 参与者：18名来自14家公司（含大中小型）的从业者，覆盖12个领域，角色包括开发者、架构师、产品负责人等；使用的需求类型有用户故事、标准化规格等，交互方式包括聊天界面（如ChatGPT）和IDE集成（如GitHub Copilot）。
- 数据收集：2024年11月至2025年2月进行在线访谈（30-60分钟），半结构化访谈提纲，内容涵盖开发流程、LLM使用场景等；访谈记录转录并翻译（德语→英语）。
- 数据分析：通过体内编码（179个引用）归纳主题，构建过程模型和内容模型，编码经三位作者交叉验证。
四、主要发现
-
过程模型
- 需求分解：传统需求（如用户故事）过于抽象，无法直接作为LLM输入，需分解为更具体的编程任务（补充实现细节）。
- 实现方式：结合三种模式
- 技术探索：开发者对任务不熟悉时，用LLM探索解决方案。
- 代码生成：生成大部分代码，需选择代码上下文，构建提示（含设计决策等）。
- 手动编码：手动编写或调整生成的代码，可能使用自动补全。
-
内容模型：提示需包含的关键信息（图2）
- 核心：编程任务（含业务逻辑/算法）。
- 补充：架构与部署约束、语言与库、接口与数据格式、单元测试、代码上下文。
-
交互模式
- 增量代码生成：如“结对编程”，交替进行技术探索、手动编码和代码生成，复用聊天历史上下文。
- 手动编码与智能自动补全：依赖IDE集成工具，主要手动编码，接受自动补全建议。
- 广泛代码生成：尽可能将任务交给LLM，重点在提示构建和代码检查。
五、讨论与影响
- 与现有研究的关系：支持现有关于LLM需上下文信息、与开发流程整合的观点，补充了架构约束等关键信息的重要性。
- 对研究的影响：需探索任务分解粒度、上下文复用、提示工程与代码调整的权衡等方向。
- 对实践的影响：全自动软件工程暂不现实，需求工程和软件工程技能仍不可或缺；提示词未被视为重要工件，需关注其可追溯性。
六、结论
本研究提出的理论揭示了LLM辅助开发中需求和设计信息的整合过程，强调了需求分解和上下文构建的重要性，为相关研究和实践提供了基础。
4. 关键问题
-
问题：为什么传统的需求文档不能直接作为LLM辅助代码生成的输入？
答案：传统需求文档（如用户故事、功能需求）过于抽象，缺乏具体实现细节，直接输入LLM会导致生成的代码难以使用或需要大量调整，效率低下。例如，有从业者尝试用“为Keithley万用表编写命令接口”这样的需求输入LLM，却未得到可用代码。因此，需将其分解为更具体的编程任务。 -
问题：为了生成可整合到现有代码库的有用代码，提示词中需要包含哪些关键内容？
答案：提示词以编程任务为核心，需补充多类信息：①业务逻辑或算法细节；②架构与部署约束（如基础设施要求）；③语言与库（避免过时或领域特定信息缺失）；④接口与数据格式；⑤单元测试；⑥相关代码上下文。这些信息确保生成的代码符合项目环境和需求。 -
问题：从业者使用LLM辅助代码生成时，主要有哪些交互模式？这些模式的差异是什么？
答案：主要有三种模式：①增量代码生成：如“结对编程”，交替使用技术探索、代码生成和手动编码，依赖聊天历史复用上下文，适合聊天界面；②手动编码与智能自动补全：以手动编码为主，接受IDE集成工具的自动补全建议，交互抽象层次低；③广泛代码生成：尽可能让LLM生成代码，重点在提示构建和代码检查。差异体现在LLM的依赖程度、交互界面和抽象层次上。
总结：LLM很能打，但需求工程仍“不可替代”
这篇论文通过真实的工业实践案例，打破了“LLM能搞定一切”的幻想：
- 解决的问题：填补了“需求和设计在LLM辅助开发中到底起什么作用”的研究空白，让我们知道LLM不是孤立的“代码生成器”，而是需要融入现有软件工程流程的工具。
- 关键成果：提出的过程模型和内容模型，相当于给开发者画了一张“LLM使用说明书”；三种交互模式则揭示了不同场景下的最佳实践。
- 现实意义：全自动软件工程（领域专家直接给需求，LLM出完整软件）还很遥远。至少现在，需求拆解、提炼上下文这些需求工程和软件工程的核心能力，依然是开发者的“必修课”。