从语法流畅到架构理解的范式转移

　　编者按：大模型的文生文能力正在引发软件开发的范式转移，下一代的软件开发将由提示驱动，开发者不会消失，但沟通能力与战略思维会变得更加重要。

　　我在感恩节期间开发了一个应用，很快就收获了1000名用户，并在圣诞节前实现盈利。

　　但最疯狂的是……我本人一行代码都没写。那都是我一步步指导大模型（LLM）写的，我们一起开发了一个全栈的NodeJS/React应用，这个应用带有PostgreSQL数据库，实现了与Stripe的集成，托管在Heroku上，用SendGrid发送电子邮件，用CloudFlare进行DNS处理。

　　此后我一直都在思考提示驱动开发的事情，琢磨着该怎么做才好，思考其对行业发展的意义。以下就是我的想法。

　　▋概要

　　什么是提示驱动开发（PDD）？

　　工具与工作流

　　成功的心智模式

　　行业影响

　　▋什么是提示驱动开发（PDD）？

　　从本质上讲，PDD是一种开发工作流程，开发人员主要促使LLM生成所有必要的代码。让我们将其与传统开发进行对比。

　　PDD本质上是这么一种开发范式：开发者主要通过向LLM提供提示（prompt）来生成所有的必要代码。我们来跟传统开发模式对比一下。

　　传统软件开发的高阶流程通常是这样的：

　　1.开发者收到需求

　　2.开发人员在IDE本地迭代代码变更

　　3.开发者提交代码变更以供审查

　　4.另一位开发者审查并合并变更

　　传统开发的高阶流程

　　相比之下，PDD有几个关键区别。首先，LLM会参与并编写主要（甚至全部）代码。其次，开发者专注于提示工程和代码审查，而不是自己编写代码。除此之外，其余流程大致是相同的。

　　高阶提示驱动开发流程：

　　1.开发者收到需求

　　2.开发者将需求分解为一系列提示*

　　3.LLM针对每个提示生成代码

　　4.开发者审查LLM生成的代码*

　　5.开发者提交所有变更以供审核

　　6.另一位开发者审查并合并变更

　　提示驱动开发高阶流程

　　*我想强调几个步骤。

　　1.“将需求分解为提示”是一项新技能，需要学习和练习。我会在“思维模式”章节讨论怎么做。

　　2.“审查LLM生成的代码”至关重要。你不会不假思索就合并进人工编写的代码，所以对LLM编写的代码也别这样做！

　　▋给谁用？

　　简而言之，每个人。

　　我曾经跟一位资深工程师交流过，他们正在用这种做法开发极具创新性的技术。我的一位朋友甚至用PDD从头开始做出了自己的编程语言。我也接触过一些非技术人员，这些人能开发出功能完备的原型，甚至有人还部署到生产环境并吸引到用户了。LLM最惊人的特性之一就是大幅降低了编程门槛，让零技术经验的人也能生成可运行的代码。

　　但我认为有类人群特别适合这种技术：那就是具有技术背景但转型从事产品、战略或设计工作的人。这当中包括技术产品经理、技术设计师以及工程经理等。由于我的个人背景与此类似（开发者→用户体验→产品经理），所以我对PDD的热情可能有些偏颇。

　　这种技能组合之所以能够从PDD获益，是因为这些人可能对软件工作原理具备了架构上的理解，但对编程语法却不太熟悉。由于LLM可以帮忙处理语法，因此语法不熟练不再是制约因素。通过PDD，他们可以高效、无拘束地进行开发。

　　▋工具和工作流

　　基础模型

　　以下是可编写代码的一些LLM。随着新模型不断被训练并部署到市场上，这个领域会非常活跃，充满活力。就PDD而言，需关注：

　　·我通常用Claude 3.5 Sonnet、GPT 4o和GPT o1

　　·对各种模型的编码能力进行测试的基准测试有很多。选择模型时请参考最新的基准测试

　　这些基准数据可能已过时

　　聊天工具

　　ChatGPT，Claude，Gemini

　　常规聊天工具可作为PDD的一个选项。就我个人而言，我更喜欢大模型原生IDE，但我访谈过的几位开发者都用了聊天工具，因为比较简单。因为要给LLM提供一切适当的上下文，然后还要将输出粘贴到代码库中，这种做法的人工操作更多，但用起来是没问题的。

　　其工作流如下：

　　1.给LLM写提示

　　2.从代码库中复制所有必要的代码上下文，并将其作为提示的一部分

　　3.复制LLM生成的代码

　　4.将代码输出粘贴到代码库中的正确位置

　　虽然我的主要工作流不是这样，但PDD过程中也会偶尔使用。如果要尝试这种方式，强烈推荐使用Claude Projects或ChatGPT Projects功能，你可用来组织文件和聊天记录，极大提升上下文管理效率。

　　ChatGPT Project

　　LLM原生IDE

　　Cursor、Windsurf、Bolt、v0、Replit工具

　　这些工具彻底改变了游戏规则。它们将LLM集成到IDE中，相比聊天模式有两大优势：

　　1.为LLM提供代码上下文非常容易

　　2.LLM能够直接在IDE中编辑你的文件

　　这显著加快了代码生成反馈循环，无需反复复制粘贴到IDE内。

　　此类工具层出不穷，我个人用的是Cursor。说实话，这些工具大同小异：Replit可自动部署代码库，Windsurf与GitHub集成等，但核心价值都在于简化PDD的用户体验。

　　我强烈建议选择个LLM原生的IDE然后坚持用下去。在各种选项之间切换的成本非常低。关键要培养如何编写出色提示的技能，而不是记住特定IDE的所有功能。所以选好一个，坚持用下去，聚焦在提示上。

　　Cursor，注意右侧的“Composer”窗口

　　我的工作流

　　我在工作流结合了ChatGPT与Cursor的使用。大致分解如下：

　　·80%时间与Cursor交互：通过Composer功能向Claude发送提示，审查接受/拒绝修改。重复此过程。如有错误，我们会一起解决。

　　·15%时间把GPT4o当作技术思考伙伴：处理复杂变更或新功能开发时，要求其提供技术方案并创建任务工单，以此作为提示输入给Cursor，然后进入Cursor工作流

　　·5%的时间使用GPTo1进行深度规划：启动新项目或实施系列复杂变更时，GPTo1可生成更高质量、更长篇幅的输出（例如一次性生成十余个任务工单）

　　我对PDD工具使用的大致分布情况

　　▋成功的心智模式

　　更好的提示==LLM生成更好的代码。垃圾进，垃圾出，对吧？每个人的目标、环境和技能组合都不一样。所以这里不会告诉你究竟该怎么写提示，而是会提供一些思维模式，这些思维模式可提高提示质量，进而提高生成代码的质量。

　　LLM是刚加入本项目的初级开发者

　　LLM拥有令人难以置信的编码能力。但是，如果你是PDD新手，我强烈建议你先想到这一点。告诉自己，LLM是刚接触该项目的初级开发者。在编写提示时，要考虑到如何指导这类人。错误示范：“给我写个可以让朋友们发布照片并互相关注的app。”这样绝对行不通。

　　别这样，你得给出很小、非常具体的变更。你可能还要提供各种相关的文件，并说明关于产品是什么以及别人会怎么用的一大堆信息。这是思考如何给LLM提示来生成代码的正确方法。这样不仅会生成更好的结果，还会迫使你更好地给出提示，你的关注点应该在这里。

　　更好的提示==LLM生成更好的代码。垃圾进，垃圾出，对吧？

　　表现得像自己就是一整支产品团队一样

　　给LLM提供的东西不用局限在技术背景上。不妨设想自己是产品经理、设计师、开发主管以及QA工程师，你可以就工作范围提供意见。你要尽可能地模仿角色，但也不要用力过度。

　　除了技术指导之外，你还应提供：

　　·用户故事

　　·业务目标

　　·UI描述

　　·UX流程描述

　　·测试计划

把这些类型的附注添加到提示中可以给LLM提供更全面的上下文，也能提高其实现预期目标的能力。

　　上下文、具体性及范围

　　这是调整提示时需要考虑的三个变量。这些变量跟代码质量的关系很简单。为了提高LLM生成代码的质量，你需要：

　　·增加提供的上下文的信息量

　　·提高请求的具体性

　　·缩小变更范围

　　为了获得最佳输出，你需要上下文丰富、特别具体，范围很窄

　　以下是我对这些术语的定义……

　　上下文是提示提供的代码库片段或文件。

　　·上下文不充分：“在后端进行这些变更”

　　·上下文丰富：“调整backend/routes/user.js文件的getMarker函数。文件在这儿，它一般会进行交互的另外3个文件在这儿......”

　　具体性是指请求定义得有多明确、多精确。

　　·不够具体：“当用户单击提交时，将其提交添加到feed中。”

　　·非常具体：“当用户单击提交时，调用saveSubmission端点将提交存储到数据库内。保存后，自动调用loadFeed函数刷新前端的feed，让用户能够立即看到自己的提交，而无需重新加载页面。”

　　范围是要求LLM一次性变更多少东西。

　　范围很广：“添加一个设置页面，用户可以在该页面管理和更新账号。”

　　范围很窄：“在设置页面上添加一个切换按钮，用户可以将自己的帐户设置为私密或公开。”

　　请记住，要想得到最佳输出，上下文得丰富、请求要足够具体，范围不要太宽。是，写成这样需要时间，但写代码也一样。提示成什么样你得根据自己的技能组合来权衡。

　　LLM写代码也会有bug（就像人类一样）

　　知道不，LLM并不完美。我和曾经尝试过PDD的人聊过，“因为AI产生了一个bug，所以我就放弃了。”我建议你不要期望过高，只需知道LLM会时不时产生bug就行了。这是正常开发过程的一部分，那怕是人类写代码也会出错。

　　这也是为什么在接受LLM代码之前对其进行审查和测试如此重要的原因。不要盲目地合并它所做的变更。人写的代码你不会无脑合并，那为什么LLM写的代码你就会无脑合并呢？如果你遇到bug的概率超过5%，请使用上述建议重新审视你的提示技术。

　　人写的代码你不会无脑合并，那为什么LLM写的代码你就会无脑合并呢？

　　▋行业影响

　　门槛提高了

　　常见误区认为LLM将取代开发者。更准确的认知是：对所有从业来说门槛提高了。

　　对于技术人员来说，熟练掌握一门编程语言已不再足够。因为这项技能可以100%外包给LLM。现在，开发者需要对所用的代码库有深入的架构理解，并且需要具备强大的写作技能，以便能够准确地向LLM表达所需做出的变更。

　　对于非技术人员来说，能够给开发团队编写需求已经不够了。相反，他们还得会开发可在本地运行的功能齐全的原型。为此，他们需要具备足够的技术知识，好向LLM描述所需的内容，还得知道如何启动本地Web服务器。

　　低阶工作不会消失，但工作性质会改变

　　最近有很多关于入门级（甚至中级）开发者角色被AI取代的讨论。我知道他们想说什么，但我认为那是不对的。其实他们是想说LLM现在已经能做我们目前认为需要入门级或中级开发者才能完成的工作了。这一点我大抵是同意的。但认为这些角色会消失的想法是只见树木不见森林。

　　消灭初级和中级岗位会导致开发者的人才断代。现在那些高级开发者总有一天会退休的，而由于没有人才储备，我们没法用足够快的速度去替换他们。

　　中级开发者的定义肯定会发生变化。他们需要完成的任务类型会变得更加复杂。他们可能会使用LLM来生成大量代码。而且，他们还需要对产品有深入的架构理解，并具备强大的书面沟通能力。

　　软件开发的学法不一样了

　　2010年代我刚开始学习软件开发时，概念学习的顺序大致是像下面这样的：

　　1.基本概念（变量、数据结构等）

　　2.语言语法和特性（我学过C++、Java、LISP、Ruby、JavaScript）

　　3.协作（Git）

　　4.架构模式（前端/后端、MVC）

　　5.之后我转行去做产品了

　　我预计现在对于学软件的人来说会发生一些变化了。首先，他们不会像我一样去学5种编程语言。没有理由去做这样的事情了。他们可能会学习一种语言，然后靠LLM去学习其他语言和框架。其次，他们会学习架构模式的时间会提前，可能学习基本概念的同时就开始学了。这是因为你必须掌握这些知识才能编写出高质量的提示。第三，他们从第一天开始就会学习使用LLM，逐步练就非常强大的书面沟通技巧，从而写出高质量的提示。

　　整个过程大概是这样的：

　　1.学基本概念+架构模式

　　2.学一种编程语言+提示写作（语言可能是python或Javascript，会通过提示来学习）

　　3.合作

　　4. ......等等

　　小一点、新一点的公司会率先采用提示驱动开发

　　改变很难，组织惯性会妨碍成熟的大型科技公司大规模采用这些做法。他们需要更长的时间才能共同建立起对LLM代码质量的信任感，才能理解提示质量才是更重要的因素，才不会感到受到LLM的威胁，并最终接受这些工具。

　　小一点、新一点的公司有充分的理由从第一天开始就成为AI原生企业，没有理由不这样做。他们没有历史负担，很快就能学会如何将其融入自己的独特文化，并以业内前所未有的速度交付产品。这种情况正在上演，Headstart等公司就是典范。

　　▋结论

　　提示驱动开发(PDD)是一场软件开发变革，强调的是对架构的理解而非语法流畅。通过利用LLM，开发者和非开发者都可以更快、更高效地开发出产品。不过，LLM生成代码的质量在很大程度上要取决于提示够不够清晰，够不够具体，因此，沟通能力与战略思维至关重要。

本文来源：36氪

文章转载于其他网络，如有侵权请联系我们及时删除