一条Vibe coding的好提示词长啥样？看下来自一线的18位工程师画的流程图

您是否也曾经想过这样的场景：产品经理把idea直接扔给AI编程，然后就能得到完美能用的代码？来自德国弗劳恩霍夫研究所和杜伊斯堡-埃森大学的研究者们刚刚给我们泼了一盆冷水。他们深度访谈了14家公司的18位工程师，发现了一个让人不安的真相：没有任何一位工程师能够直接把需求文档"喂"给LLM并得到可用的代码。这项研究开展于2024年11月至2025年2月

18位工程师的真实告白

研究者们找来了18位来自不同行业的工程师，包括汽车、银行、电商、航空航天等14个领域。这些工程师中有普通开发者、团队负责人、软件架构师，甚至还有产品负责人。访谈分为两个部分：他们会先问"不用LLM时，您是怎么把需求转化为代码的？"，然后再问"用了LLM后，这个过程发生了什么变化？特别是提示词（prompt）里包含了什么内容。"

访谈参与者详细信息

需求文档：太抽象的噩梦

结果所有18位工程师都说，传统的需求文档根本没法直接给LLM使用。有位来自健康领域的工程师这样描述他的经历："我对GPT说'写一个Keithley万用表的命令接口'，这个需求直接来自我们的需求目录，但我从来没有得到过可以直接使用的代码。"原因其实很简单：需求文档描述的是"要做什么"，而LLM需要知道的是"怎么做"。感兴趣您可以看下这篇《第一性原理的Context Engineering工具、指南》

双重模型：论文的核心发现

基于对18位工程师的深度访谈，研究者们提出了一个颠覆性的双重模型理论框架。这个理论揭示了一个残酷的现实：理想化的"需求→LLM→代码"根本不存在，真实的过程要复杂得多。这个框架包含两个核心模型：流程模型和内容模型。

LLM辅助实现的流程模型，展示了从需求到代码的完整过程

流程模型：从需求到代码的真实路径

第一步：手工分解是不可跨越的鸿沟

工程师们必须先把需求手工分解成具体的编程任务。来自大型企业资源规划公司的团队负责人P06解释他的工作流程："程序的粗略草图，或者我想如何构建它，我会自己做。我思考剩余部分需要什么，然后考虑放入什么逻辑，需要调用哪个函数，如何连接数据库等等。"有趣的是，这个分解过程并不是LLM带来的新要求，而是传统软件开发就有的必要步骤。

第二步：三种实现模式的灵活组合

研究者们发现，工程师们会根据任务的熟悉程度选择不同的实现模式：

技术探索模式：主要用于不熟悉的任务，工程师会把LLM当作"智能搜索引擎"来了解可能的解决方案。来自服务管理领域的开发者P12称其为"更精准的谷歌替代品"。

代码生成模式：用于熟悉的任务，这时需要提供大量的代码上下文给LLM。来自大型服务管理公司的开发者P01描述她的典型工作流："我经常复制我已有的代码，然后让模型添加这个功能。所以我已经有了工作代码，现在我希望当无效输入进来时，它能抛出错误。"

手工编码模式：工程师主要还是自己写代码，只是接受LLM的自动补全建议。来自银行业的开发者P18表示："我要么继续写代码因为建议没有意义，要么我就使用自动补全建议并稍作调整。"

内容模型：有效提示的构成要素

LLM辅助实现的内容模型，显示了有效提示所需的各种信息要素

上下文信息：成败的关键

想要LLM生成有用的代码，光有编程任务还不够，还必须提供大量的上下文信息。来自大型税务与法律业务公司的产品负责人P05，主要使用聊天界面和IDE集成工具，他这样描述公司的情况："我们有特定的基础设施要求，必须以特定的方式满足，当然Copilot或者任何模型都不知道我们有什么规范。"

五大关键信息要素

研究发现，有效的提示词必须包含以下信息：

• 代码上下文：现有代码片段，让LLM了解将要集成新代码的环境

• 基础设施与部署：如云原生规范、部署环境要求等架构约束

• 语言与库：明确的编程语言、框架版本和依赖库信息

• 接口与数据格式：输入输出格式、API规范等技术细节

• 单元测试：测试用例可以指导LLM生成更符合预期的代码

我之前写过一篇文章，专门详解在软件工程任务中表现最好的提示词技术，感兴趣您可以看下这篇《14种主流Prompt技术，顶级团队2000次实验，只有这几种真能打》这点我也会同步到我的Agent群员专属IMA知识库“AI修猫Prompt-上下文工程”当中，作为上下文工程体系的一部分，欢迎你来交流！

提示工程：新的技能要求

这个研究还揭示了一个新的技能要求：Prompt Engineering。工程师们现在需要学会如何构建有效的提示，如何管理聊天历史和上下文信息，如何平衡提示工程的投入与代码质量的产出。有趣的是，论文中显示目前没有任何一位工程师把“提示词”当作需要追溯和管理的重要工程产物，这在一些高要求的领域可能成为未来的隐患。

未来的发展方向

基于这些发现，研究者们指出了几个值得关注的未来发展方向。第一个是需求分解的自动化：能否用AI来辅助需求分解过程？第二个是上下文信息的智能管理：如何让LLM自动获取和管理项目相关的上下文信息？第三个是提示质量的量化评估：如何建立标准来评估提示的有效性？

对AI产品的启示

对正在开发类似GitHub Copilot的产品，建议关注以下几个方面。不要过度宣传LLM的能力，而应该强调它的协作价值。产品应该更好地集成项目上下文，比如自动读取配置文件、API文档和架构约束。还需要提供更好的提示管理功能，让工程师能够保存、复用和优化他们的提示模板。

写在最后

传统的软件工程活动在LLM时代不仅没有消失，反而至关重要。那种让没有技术背景的领域专家直接通过描述需求就生成完整复杂软件的愿景，目前来看仍然“遥不可及”。开发人员必须利用其专业的软件工程技能，手动进行需求的分解、细化，并为LLM提供精确的技术和架构上下文，才能使其发挥作用。它提醒企业，不能因为LLM的出现就忽视对工程师在需求工程和软件设计方面能力的培养。并且“提示词”目前并未被当作需要追溯和管理的重要工程产物，这在一些高要求的领域可能成为未来的隐患 。

文章来自于微信公众号“AI修猫Prompt”。