书名:十倍速开发:AI时代的Cursor编程手记
ISBN:978-7-115-69210-8
本书由人民邮电出版社发行数字版。版权所有,侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用,未经授权,不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟,与我们共同保护知识产权。
如果购买者有侵权行为,我们可能对该用户实施包括但不限于关闭该帐号等维权措施,并可能追究法律责任。
著 王 尧
责任编辑 杨海玲
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线:(010)81055410
反盗版热线:(010)81055315
本书是基于Web的博客系统BlogN的开发过程,采用人与AI工具对话的形式,记录AI辅助编程工具Cursor在实际项目开发中的应用过程。书中不仅展示AI工具在技术决策、代码生成和问题解决及优化方面的强大能力,还深入探讨AI工具的特性、最佳实践及AI技术对传统编程的冲击。通过具体的案例,本书揭示AI工具在编程中的优势,如快速生成高质量代码、处理复杂逻辑等,同时也指出其局限性,如对复杂问题理解不足、可能出现错误和幻觉问题等,还示范如何通过自然语言指令驱动AI工具完成任务,如何对生成的代码进行评审和优化,以及在AI工具失效时如何及时介入并解决问题。这些内容将为读者传达最新的AI辅助编程理念并提供宝贵的实战经验,帮助读者理解如何在实际开发中合理利用AI工具,提升开发效率。
全书共15章,详细描述从项目规划、技术选型、开发环境搭建,到各个功能模块的实现及最终的性能优化和测试的全过程,不仅涵盖后端服务的搭建、数据库设计与优化,还涉及前端界面的开发和用户体验的提升,全面展示与传统编程过程不同的人与AI工具协同的开发方式。
本书面向有经验的软件开发者,尤其是那些希望在AI时代提升开发效率、掌握新开发方法的专业人士。无论是在个人项目中寻求高效开发,还是在大型团队中探索新的协作模式,本书都能为读者提供实用的指导和启发。
本书是我在开发一个小型Web项目(准确地说,是重写一个多年前的老项目)时的副产品。我使用AI辅助编程工具Cursor作为开发工具,尽可能地应用AI辅助编程技术,尝试了一种与以往截然不同的人机协同的开发方式。本书逐章记录了开发过程的各个步骤,包括开发者如何通过与AI工具讨论做出技术决策,如何使用AI工具实现代码,如何解决AI辅助编程中遇到的各种问题,等等。本书的目的不是介绍开发一个Web系统的具体技术,而是以一个实际项目为基础,记录AI辅助编程的经验,尤其是我对于“AI时代如何编程”的思考和实践。本书面向的不是希望通过“不写一行代码”就能开发软件的读者,而是希望拥抱AI技术以提高效率,甚至彻底改变开发方式的专业开发者。
AI技术的出现,对软件开发的影响是颠覆性的。可以说,未来几乎不会有AI缺席的编程工作。无论是软件开发者、管理人员、产品经理、学生,还是行业投资者,都有必要了解AI辅助编程的基本原理和实践。
对软件开发者来说,这种变革带来了极大的挑战。“一切坚固的东西都烟消云散了。”从算法到设计模式,从单元测试到软件配置管理,我们曾经熟悉的技术栈中的一切,无不受到影响。不仅如此,AI技术对软件架构和软件产业生态的影响也是深远的。作为软件开发者,我们是积极思考应该掌握什么样的技能,学习哪些知识,才能利用AI技术发挥最大的生产力,适应这个新的时代,还是“放弃治疗”,趁早改行?
在AI辅助编程这个领域,由于涉及面的广泛和深入,以及AI技术和工具本身一直在以惊人的速度进化,情况处于相当混乱的状态。我们常常从不同的途径听到自相矛盾甚至截然相反的观点,从“AI终将取消软件开发行业”到“AI毁掉了我的整个项目”,从“AI的编码能力远超人类开发者”到“修复AI生成的bug的新行业正在蓬勃成长”,不一而足。要回应软件开发者面临的严峻挑战和巨大机遇,要正面回答上面这些问题,唯一的办法是躬身入局,在实践中寻求答案。
试图将AI辅助编程工具(Cursor)应用于手头一个真实项目,这次经历彻底改变了我的编程实践和思维方式,也引发了我对“AI时代的编程”的一系列相关问题的思考。我将自己的经验、心得与总结编写成书,愿与有兴趣的朋友分享。无论是正在变得越来越重要的个人开发者和小型开发团队,还是在IT巨头企业中从事大型软件开发的工程师,如果能够从本书记录的开发过程和经验中得到一些帮助,作为本书的作者,我也就功不唐捐了。
在编程工作中,AI工具的表现像一个受过很好教育的初级开发者,基本功扎实,写的代码和文档都很规范,符合一般意义上的最佳实践(best practice)。只要给出明确的提示,它实现相对简单的算法也没问题。它对语言和相关领域知识的了解相当准确和完整。例如,我决定使用Web组件(Web component)技术实现HTML层的组件复用。虽然我对Web组件有一些技术上的了解,但在此之前我从没有过相关的编码经验,因此AI工具生成的代码有时候会超出我的知识范围。对于我理解不了的代码,我会让它详细解释,事实上是我在通过AI学习。当然,AI工具的编程效率更是人类难以企及的,它能够在几分钟之内就生成上千行代码,往往只需要很少的修改甚至不需要修改就能够正常运行。
AI工具的问题也不少。最主要的一个问题是:它对问题的理解限制在一个小的范围内,而不会主动从更大的范围来考虑,这很可能是因为上下文大小有限制。这一点其实非常像缺乏经验的初级开发者。这种“脑容量不足”很容易导致AI工具在某个“牛角尖”无限制地越钻越深。事实上这种情况多次发生,AI把很多不相关的代码改得面目全非,最后彻底失控。要避免这种情况,一是在AI工具每次修改代码后人工进行仔细评审,二是频繁提交到Git,随时准备回滚代码。这样就非常耗费算力,而AI工具是按算力计费的。
另一个严重的问题是AI的幻觉,也就是说,AI工具会说谎,有时候称为“精心编织的谎言”也不为过。对于明明没有修复的bug,它会明目张胆地宣称已经解决,而且会无中生有地编造一堆所谓的证据。对于没有通过的单元测试,它会偷偷修改测试用例,跳过测试逻辑,直接生成“需要的”结果。这对软件开发,尤其是严谨的企业级软件开发来说,不啻为一场灾难。随着技术的发展,幻觉问题是否有一天能够彻底解决?目前业界尚无定论。就我个人的理解而言,至少在大模型技术这个框架内难以抱有希望。
在整个开发过程中,我与Cursor协同工作,感觉就好像堂吉诃德和他的搭档桑丘。它(基本上)忠实可靠,任劳任怨,但有时候会干蠢事,把我带到沟里,有时候也会偷奸耍滑,甚至说谎骗人,蒙混过关。在我眼里,它是一个非常善于处理琐碎的工作、但智力有些缺陷的伙计,需要时时刻刻盯着,才能不出乱子。至于它怎么看我,就不得而知了。
总的来说,人与AI工具的结合,极大地提升了开发者的生产力。传统开发中很多具体而琐碎的工作,如创建用户界面、生成复杂的SQL代码、维护测试用例等,通过AI工具都可以非常方便地完成。这种生产力的提升也导致传统的软件工程方法正在发生深刻的变化。开发工具的AI化降低了创业门槛,未来可能会出现更多由少数人组成的、极具竞争力的小型软件公司。传统的软件外包模式可能面临挑战,而围绕数据标注、模型训练和模型即服务(model-as-a-service,MaaS)的新的产业环节可能会蓬勃发展。(嗯,也不一定。)
AI辅助编程对生产力的提高非常惊人。因为AI工具能够在极短的时间内处理大量的代码细节(在传统开发中这些细节往往占据了主要的时间成本),借助AI工具我基本以10倍速在工作。由于前述问题,我无法完全依赖AI。为了让代码呈现我想要的样子,我需要非常详细地、反复地描述需求,有时候需要细化到某个函数的输入输出、主要逻辑和算法,还要告诉AI参考哪一部分代码来完成;要尽可能仔细地评审代码,提出改进意见(AI工具实现的往往不是我想要的);在AI工具失控的时候,还要自己动手修正bug。这也很像是资深开发者带着一个新手工作。
随着技术的进步,上述问题是否可以被修正呢?毋庸置疑,随着AI的“脑容量”越来越大,代码质量肯定会越来越高,debug能力会越来越强,对问题的理解能力也会越来越全面。目前我仍然尽量评审AI工具生成的代码,但是很显然,用不了多久,大多数AI生成的代码就会不需再经过人工评审。这不仅是因为AI工具生成的代码的质量足够好,也是因为人类的精力完全跟不上AI的生产效率。
但是,有两项工作,至少是现阶段的AI工具无法代替人类完成的。一是确定需求。人需要把产品需求非常详细地、没有歧义地描述出来,这个过程不像很多人想象的那么简单。这是开发过程中最复杂的环节,是对现实世界的建模。二是根据项目的具体情况进行技术决策。这两项工作,不但需要技术知识,而且需要对业务逻辑、对现实世界的复杂条件乃至对人性等多方面的理解。从某种意义上说,这就是编程的本质。
在这个背景下,人的角色转变成“产品经理+技术架构师”,而传统的“开发者”角色将逐渐消亡。这是一种进步。
我们不能盲目地完全依赖AI,也不能简单地否定AI的能力。软件开发者需要深入理解和评估AI能力的边界,合理地使用它,并尽量精确地把握AI和人工的边界。在AI时代,这是软件开发者(也许是所有的智力工作者)需要掌握的核心技能。复杂性在于,这个边界总是处于动态变化之中。
当然,没有任何理由给AI的能力设限。AI的进化固然一日千里,但它是会一直延续这样的进化速度,直至远远超出人类,还是只能在目前的理论上限之内尽量完善,难以进化出真正的智能?目前来看,真正的通用人工智能(artificial general intelligence,AGI)仍然遥遥无期,但也有人认为,强化学习(reinforcement learning,RL)或其他技术终将赋予AI无限进化的空间。无论答案是什么,都已经远远超出了本书的范围。
下面我尝试回答一些常见的问题,当然这些回答仅代表我个人的观点。
(1)完全不需手工编写代码的软件开发可行吗?
不行。虽然网上到处可见“我用AI工具生成了一个完整的软件产品”的例子,但是简单的演示样本和真正的产品是完全不一样的。光是规模带来的复杂度就足以产生质的差别。在功能单一的演示样本中,或者在需求明确的简单功能的开发中,AI工具往往能生成非常优秀的代码,因为理论上它只需要在记忆库中找到优秀的代码模板就行了,无论这个模板有多么复杂。但是,在大规模的开发中,AI工具像人一样不可避免地会制造bug,而且这些bug并不是它都能够自己修复的,往往会越改越坏,范围越来越大,直至失控。更重要的是,AI工具缺乏某种“大局观”,难以在较高的层次做出明智的决策。例如,它往往在不同的模块中生成重复的代码,或者过一段时间就犯重复的错误。如果没有人类开发者时时进行评审和提示改进,当项目达到一定规模时,可能会陷入失控状态。
(2)AI工具生成的代码比人工编写的代码的质量高吗?
不一定。如上文所言,对于需求明确的小范围的功能,AI工具往往能生成非常优秀的代码,而且在代码可读性、异常处理、边界条件检查(如空值、输入有效性)方面往往比人类开发者更严谨和全面。但对大规模的开发或者某些无法在代码库中找到现成模板的问题来说,AI工具远不如人类,尤其是无法提出创新性的解决方案。AI工具似乎总是往复杂的方向去“堆叠”解决方案,而不是通过“简化”从本质上解决问题。总的来说,我的印象是“AI的速度比较快,但人比较聪明”。当然,这种情况会持续多久,目前还无法断言。
(3)AI工具生成的代码会有安全问题吗?
会,而且有时候非常严重。可以参见本书中的具体例子。
(4)学习算法还有用吗?
有用。首先,人类开发者必须能够理解AI工具生成的代码,否则一定会被它带到坑里。更重要的是,AI往往会生成正确但非最优的代码。开发者必须能够评估和判断生成的算法是否最适合当前场景,能够进行复杂度分析,识别性能瓶颈并优化,必要的时候,还需要设计全新的算法或范式。
(5)单元测试和软件配置管理软件还是必要的吗?
我很奇怪网上会有人提出这样的问题。使用AI工具编程,单元测试(unit test)和软件配置管理(software configuration management,SCM)软件(如Git)不但是必要的,而且比传统开发中还要重要。在传统的手工开发中,如果没有单元测试和Git,我还勉强能够编程,因为我至少知道哪些地方进行了哪些改动。在AI辅助编程中,没有单元测试和Git是完全不可想象的。AI工具往往会进行不符合预期的修改,甚至改动完全不相关的代码。没有单元测试,就无法知道代码修改的结果是否符合预期或者是否破坏了其他地方的代码;没有Git,就无法回滚错误的修改,甚至连修改了哪些地方都无法知道。如果在那种条件下编程,很可能用不了多久,你就会被折磨得筋疲力尽。
(6)还需要代码重构吗?
需要。有一种说法是重写(rewriting)已经取代了重构(refactoring),因为在AI工具强大的生产力的加持下,与其对遗留系统的“屎山”进行费力不讨好的重构,还不如在短时间内推翻重来。我无法判断这种观点是否正确,但是,即使不考虑这种情况,重构在AI辅助编程中也是不可或缺的。如前所述,AI工具生成的代码往往存在各种缺陷,容易顾此失彼,代码评审和重构是解决这一问题的关键。在本书的项目开发过程中,我坚持在一个较完整的功能开发完成后(一般是几千行的规模),提示AI工具进行重构,这往往能够明显地提高代码质量。当然,如果发现有明确的需要重构的理由,也可以随时进行小规模的重构。
(7)需要人工评审每行代码吗?
取决于具体情况。对于某些关键代码,或者某些特定产品(如对性能极其敏感的系统软件),人工评审每行代码是必要的。但是在大多数情况下,无法做到人工评审每行代码,因为人的评审速度远远比不上AI生成代码的速度。如果坚持人工评审每行代码,不但人会筋疲力尽,而且会将开发速度拖慢到人工开发的水平,甚至更慢(因为有时候理解别人的代码比自己写代码更花时间)。在这些情况下,人工仅评审关键代码并通过测试保证结果正确就足够了。对人类开发者来说,关键不在于编写每行代码的能力,也不在于评审每行代码的能力,而在于理解每行代码的能力。
(8)长期依赖AI会造成开发者技能退化吗?
会。这就像长期坐办公室会导致体能退化一样。但通过有意识的锻炼能够避免这一点。
驾驭AI工具让其输出最佳的效果,是一门新的技术。下面是我有限的经验。
(1)把控具体任务的粒度。AI工具的单次处理能力存在客观上限。要确保其输出稳定可靠,核心方法是将宏大的任务目标分解为多个规模适中、指向明确的具体子任务。任务粒度的把控至关重要:如果子任务过于庞大复杂,AI工具可能无法兼顾所有要求,导致生成内容质量下降,出现逻辑缺失、细节错误甚至忽略部分指令的情况。如果子任务过于零碎细小,则会频繁进行人机交互和结果整合,导致整体工作效率降低。“恰到好处”的拆分并非易事,即使是经验丰富的开发者,也不一定能精准预估每个任务模块的实际工作量。因此,在着手一项大型任务前,先与AI工具就整体思路、关键细节进行初步讨论,共同规划任务分解方案,是一种被实践证明的有效策略。这种方法不仅有助于厘清思路,也能让人机协作更为流畅高效。
(2)提供明确的提示和详尽的上下文。让AI工具去完成某种任务,一定要给它尽可能明确、详细的提示,而不是依靠它自己的发挥。否则,结果十有八九不符合预期。除了提示词,相关的上下文信息(如数据库中的表结构和关系)也至关重要。举例来说,告诉AI工具“生成用户登录页面”,它也能够完成任务,但生成的很可能是一个乱七八糟、无论是用户界面还是代码逻辑都与现有的系统完全匹配不上的页面(天知道它是从哪个页面模板复制过来的)。而“先和它详细讨论相关的技术细节,然后给出提示”这种方法就会好得多。下面摘录了一段我和AI工具讨论后给出的提示:
数据库中的users表已经完成MD5+Bcrypt双重哈希的升级。根据以上讨论,实现基于JWT的用户登录功能。界面如下:当用户点击顶栏(header-component)的“登录”按钮时,打开新的用户登录窗口。用户输入用户名或者电子邮件(二者均可)和密码,进行登录。登录成功后,返回登录的出发页面(如果不能获得出发页面,则返回首页)。在登录状态下,顶栏不再显示“登录”按钮,而是显示带头像的用户名。数据库中的users.password字段存储了MD5+Bcrypt双重哈希的结果,users.state为用户级别(10为管理员,1为普通用户,0为已经冻结用户),users.lastupdate为最后登录时间,users.iplog为最后登录的IPv4地址。
(3)提供明确的反馈或评价标准。提供一个明确的反馈或评价标准,往往能够明显提升AI工具的工作效率。在人机协同工作过程中,人有很大一部分时间是在向AI工具提供代码运行的结果,如果这种反馈能够自动化,AI工具就能够自我评估和改进,从而节省大量时间。例如,你要求AI工具对一段SQL代码的性能进行优化。如何评估优化的效率呢?可以要求它写一段脚本,测试不同的SQL代码的执行速度,只有当优化后的执行速度明显提升时,才能够认为优化是有效的。你甚至可以为这种提升设置一个合理的期望值。否则,AI工具可能会“优化”出一段效率更差的代码,并且自我吹嘘一通它的工作成果(就像某些人类开发者)。
(4)依靠单元测试控制代码质量。如前所述,因为效率的问题,人类难以逐行评审AI工具生成的全部代码。在这种情况下,只能依靠单元测试来控制代码质量。设计完善的单元测试不但能保证生成的代码符合预期,而且能够作为一种标准化工具,验证AI工具在修改代码时没有破坏任何已有的功能。尤其是在进行复杂的任务(如大范围的重构)时,单元测试是必不可少的工具。因此,建立完善的单元测试体系是复杂软件开发中的必要步骤。不过,要注意,AI工具有时候会偷偷地修改单元测试,企图蒙混过关。但有些时候,修改单元测试又确实是必要的。这时候必须依赖人的判断。
(5)判断AI工具失效和及时介入。敏锐地判断AI工具失效是人类开发者的一项基本能力。AI工具有时候会出现钻“牛角尖”的情况,明明问题出在另一个维度,它却在某个不相干的方面反复尝试,修改的范围越来越大,甚至想把明明正常的功能推翻重来。这时候唯一的办法就是人工介入。人工介入的程度可以分为几个层次。一般情况下,当代码的行为不符合预期时,人类开发者会提供包括上下文的反馈,AI工具在一到两轮修改后就可以修复问题。但是当AI工具在某个问题上进行了三到四轮修改仍然没有取得任何进展,只是简单地重复工作时,开发者就应当判断是否需要人工介入。先向AI工具询问问题的具体情况,并建议不同的研究方向。如果AI工具在各个方向上都无法取得进展,开发者就必须介入得更深:深入理解具体的技术细节,阅读关键代码,分析日志,将问题的可能性反馈给AI工具,并提示它下一步的工作。如果这样还是不能取得进展,开发者就只能完全接管,进行手工编码和调试,AI工具的作用仅限于生成某些工具脚本。幸运的是,最后一种情况并不多见。
必须明确的是,上述所有经验的成立,都基于一个根本前提:人类开发者自身具备足以驾驭项目全局的技术能力和专业判断能力。那种认为“无须编码经验即可开发完整软件产品”的说法,更多的是一种不切实际的幻想。从这个角度来说,AI工具并不能完成人类开发者认知边界之外的任务,它只能提升人类的开发效率和创新半径。
本书通过一个真实项目(基于Web的博客系统BlogN,技术栈为Linux+Apache+Unicorn+FastAPI+ Web组件+PostgreSQL)的开发,一步步展示了使用AI辅助编程开发软件项目的完整过程。
本书的目标读者很明确:如果你是一位有经验的软件开发者,已经掌握了一些专业的开发知识(编程语言、算法、软件架构、数据库、开发流程等,尤其是Web应用开发的知识),在这个从传统编程向AI辅助编程迅速演化的时代,迫切地想要了解和掌握新的开发方法和驾驭AI之道,那么本书可能正是你在寻找的。
如果你缺乏必要的软件开发背景知识,只是希望通过AI工具快速生成软件原型,而无须深入理解相关的技术细节,那么本书可能并不适合你。
必须指出,如果你在某个特定领域的技术知识比较欠缺,那也无须过于忧虑;在AI工具的帮助下,一个有经验的开发者可以迅速掌握特定领域的专门知识。在项目开始时,我并没有FastAPI的编程经验,但是随着开发的进行,我很快掌握了它的使用;在AI工具的帮助下,这个过程比以往的类似学习过程要快得多。
关于本书的叙述风格,我和本书的编辑反复讨论,最终决定采取一种可能不太寻常的方式。
传统的软件开发领域的图书,如果是基于某个项目实例,大部分会按部就班地介绍项目的需求、架构、各部分的功能,再细分到某个特性(feature),直至展示相关代码。读者可以看到特性的定义和实现,但是看不到定义和实现的过程。其实,一个特性的定义和一段代码的实现往往需要经过反复修改。在修改过程中,开发者可能会意识到自己的错误,这些错误可能是编程语言语法上的(语法错误),也可能是语义上的(代码行为不符合预期),还可能是功能逻辑上的(设计的逻辑本身不合理)。软件是在这个反复修改过程中逐渐完成的,这些修改展示了开发者对设计和代码的思考。
在AI辅助编程的时代,人与AI工具对话成了编码的基本方式。相较于展示AI工具生成的代码,展示人与AI工具的对话记录可能更有意义:人如何通过自然语言驱动AI工具编写代码,如何反馈错误,如何重构,如何定位问题,如何在AI工具失效的情况下接管代码,最终生成正确的代码。在这种意义上,人与AI工具的对话记录更类似于传统的“源码”。林纳斯·托瓦兹(Linus Torvalds)的名言“空谈无益,代码为证”(talk is cheap, show me the code),如今似乎将被“代码易得,洞见为证”(code is cheap, show me the talk)所取代。
在本书中,除第1章(AI辅助编程概述)、第2章(BlogN系统开发项目简介)和第3章(开发环境和工具)之外,其他章主要由人与AI工具的对话记录和相应的代码组成。当然,原始的对话记录不免会有冗长的部分,例如,AI工具可能试图反复修正一个问题,但是总是无法产生正确的结果,开发者不得不介入,手动定位并修正问题。我对大部分冗长的部分做了技术性处理,但考虑到这种冗长也是开发的一部分,书中也保留了少量必要的冗长内容。
这种可能不太寻常的编写方式是否成功,有待读者评判。
此外,因篇幅有限,书中只呈现了需要重点讲解的部分代码,BlogN系统项目的所有项目源码(包括相关脚本)都发布在https://github.com/yaowangm/blogn2,采用BSD 3-Clause许可证,欢迎读者批评指正和贡献代码。
必须说明的是,AI辅助编程的演化速度快得让人眼花缭乱,我无法保证自己所用的开发方式是最好的甚至是正确的。如果读者发现其中的错误或者可以改进之处,希望能够不吝指正,在此谨致谢意。
最后,我要感谢本书的责任编辑、老朋友杨海玲。如果没有她的热情推动和辛勤工作,本书不可能完成。
作者
2026年1月
AI辅助编程(AI-assisted coding,AIAC,也称人工智能辅助编程)是近年来软件开发领域涌现出的一个变革性概念,它利用人工智能工具(如大语言模型)生成源码。与传统的人工编写代码方式不同,AI辅助编程的核心在于人与AI工具的对话式协作:人类提供需求、技术规范和约束,AI工具负责编写代码,并由人类进行评审和验证。这种模式的出现标志着软件开发范式的一次重大转变,超越了低代码/无代码工具和集成开发环境(integrated development environment,IDE)中自动补全功能的范畴。
经过多年的发展,IDE已经能够根据开发者提供的需求描述、注释或已有代码,实现自动补全代码、检测错误、生成文档等,也能够提供上下文感知的代码建议和自动补全,并能生成单元测试、文档注释或给出重构建议。但是,直到最近,随着大语言模型技术的成熟,主要依赖对话式协作的工作方式才得以实现,使开发者能够从繁重的编码任务中基本解放出来。但是,对于开发者在多大程度上必须控制掌握代码(从人类完全不需要接触代码,到人类必须完全理解AI生成的代码)这个问题,仍然处于激烈争议之中。
低代码/无代码工具主要依赖预构建的代码模块组装应用,而AI辅助编程工具则能够根据自然语言描述从零开始生成定制代码,理论上其功能没有限制,只要算法足够复杂、训练数据足够全面,就能实现高度复杂的应用。尽管开发者长期以来一直渴望更快的代码编写方式,但AI辅助编程解决方案在最近几年才逐渐成熟。
AI辅助编程工具的运作机制主要依赖于以下核心技术。
(1)机器学习(machine learning,ML)。机器学习是人工智能领域的一个子领域,专注于让机器在未被明确编程的情况下从数据中学习。在AI辅助编程中,机器学习帮助AI工具识别模式、检测错误并随着时间推移进行改进。机器学习算法通过分析海量代码数据来预测准确的代码补全,并识别潜在的编码问题。选择正确的机器学习模型对实现高性能AI代码生成至关重要,这些模型必须在包含各种编程语言和编码范式的大量多样化数据集上进行训练。
(2)自然语言处理(natural language processing,NLP)。自然语言处理是一个复杂的领域,它使机器能够有效地理解和生成人类语言。AI辅助编程中的自然语言处理功能使AI能够解释开发者的注释,并从文本描述中生成代码。通过自然语言处理,开发者可以轻松地将他们的想法转化为可执行代码,无论是常见的编程语言还是像YAML这样的结构化格式。
(3)大语言模型(large language model,LLM)。大语言模型是先进的AI系统,旨在根据海量数据集理解和生成类人文本(即在流畅性、连贯性、语法正确性及语义合理性等方面接近人类自然语言表达的文本)。
(4)生成式AI(generative artificial intelligence,GenAI,也称生成式人工智能)。生成式AI的代码生成能力主要归功于大语言模型技术和自然语言处理的最新进展。这些模型利用深度学习算法和广泛的神经网络,在从公开可用的开源项目代码库中提取的多样化数据集上进行训练。当开发者输入描述所需代码功能的纯文本提示时,生成式AI工具会通过建议代码片段或生成完整函数来响应,从而通过自动化重复性任务和最小化手动编码工作来简化编码流程。
(5)代码分析与预测。代码分析与预测技术的应用使AI辅助编程工具可以分析源码,识别其结构、模式和语义;可以将代码解析成抽象语法树(abstract syntax tree,AST),以理解代码中不同元素之间的层次结构和关系,从而实现精确的分析和解释;可以基于学到的模式和上下文预测并生成相关的代码片段或完整的代码;可以利用概率模型建议编码环境中下一个最有可能的词元或词元序列,促进更快、更准确编码。
值得注意的是,正如其他基于文本的生成式AI一样,生成代码的AI工具背后的大语言模型对代码的工作机制或背后的逻辑并没有真正“理解”,它只是根据统计原理或者推理,基于算法对文本序列中接下来的内容进行预测。这意味着AI工具编写的代码可能在语法上是正确的,但并不一定能达到开发者的预期,甚至可能在逻辑上无法运行。这种依赖统计模式而非语义理解的特性,是AI辅助编程的一个关键点,它强调了人类在代码评审和验证中不可或缺的作用。
AI辅助编程主要通过自动化、验证和指导3种方式,在软件开发生命周期(software development life cycle,SDLC)的各个阶段协助软件工程师进行开发。这种开发流程与传统方式有所不同,更强调人与AI工具的协同。
AI辅助编程的典型流程分为以下几个步骤。
(1)需求与提示。开发者首先在IDE中以自然语言或注释形式描述功能需求,例如“创建一个带有用户登录功能的Web API”或在代码中写入待完成函数的说明。
(2)AI代码生成。AI工具会根据上下文生成代码建议。例如,在Visual Studio Code编辑器中输入代码时,Copilot会实时提供补全提示,按下Tab键即可接受建议。同时,许多工具支持通过类似聊天对话的方式提出问题或提示。例如,在Cursor中可使用聊天功能让Cursor根据提示编写函数、类或测试。
(3)人工评审调试。开发者接受或修改AI生成的代码后,需要手动进行编译、运行和调试。此时可结合AI工具进一步完善代码,让AI生成针对这段代码的单元测试。例如一些工具支持“测试生成”,即分析现有代码以自动生成有意义的测试用例。开发者运行测试,检查潜在缺陷,并根据反馈继续调整需求或提示。
(4)部署集成。当代码通过测试并满足需求后,按常规流程将其合并到代码库和部署流水线中。
在整个开发过程中,AI工具承担了生成代码、初步检查的角色,而开发者则负责需求拆解、提示工程、代码评审和最终决策。
AI辅助编程的典型流程如图1-1所示。

图1-1
在这种人机协作模式下,开发者不再需要从零开始手写大量样板代码,而是像“指挥员”一样指导AI生成代码、评审输出代码。AI工具显著加速了常规编码任务,如编写CRUD(Create- Read-Update-Delete,创建-读取-更新-删除)接口、编写重复性函数等。同时,开发者仍需设计架构和把控质量。
下面以Web API开发为例,看一下常见的开发者与AI的协作流程。Web API开发协作流程如图1-2所示。

图1-2
在图1-2所示的整个人机协作流程中,AI承担了生成样板代码和测试脚本的任务,开发者则负责需求描述、代码评审和调试部署。
下面介绍一些当前市场上流行的AI辅助编程工具。
Windsurf(原Codeium)是一款AI驱动的代码补全工具,旨在通过下一代自动补全功能和AI聊天协助来提高开发者的生产力。它支持多种编程语言,帮助开发者更快地编写代码、更有效地调试并即时生成样板代码或文档。Windsurf采用“代理式开发”方法,其核心是Cascade智能系统,能够深入理解代码库,并实时感知开发者的操作,从而实现人与AI工具的无缝协作。它提供超级补全(Supercomplete)功能,预测开发者意图而非仅预测下一行代码,并能进行连贯的多文件编辑。
Cursor是一款创新的AI代码编辑器,通过集成AI大模型来帮助开发者编写、调试和优化代码。它能够预测下一步编辑操作,理解整个代码库,并允许用户通过自然语言描述进行代码编写和修改。Cursor以快速、智能的特点而闻名,支持导入扩展、主题和快捷键,并提供隐私模式保护代码数据。
Claude Code是由Anthropic公司开发的基于命令行的AI编程工具,深度集成Claude系列大模型(如Claude 4.1 Opus),通过自然语言交互实现代码生成、调试与优化。该工具直接运行于开发者终端环境,支持Visual Studio Code、JetBrains等主流IDE,无须额外的服务器配置即可快速理解代码库结构和依赖关系,尤其擅长多文件协同编辑和复杂代码重构。Claude Code的核心技术优势体现在20万token超长上下文处理能力,可精准定位大型代码库中的问题而不引入冗余修改。
Codex是OpenAI推出的AI编程智能体,基于GPT-3架构(GPT-5-Codex是基于GPT-5,针对Codex平台优化的专用模型),专注于将自然语言指令转换为代码。它既提供命令行工具,也集成在IDE和云端环境中,能够自动完成代码编写、调试、测试乃至提交拉取请求(pull request,PR)这一完整的任务链。它的特点是响应迅速,执行任务聚焦,尤其适合快速完成需求明确的功能开发和在云端托管运行复杂任务。
这些AI辅助编程工具可以划分为集成开发环境(IDE)工具和命令行(CLI)工具两大类。集成开发环境工具将AI能力深度嵌入Visual Studio Code或JetBrains系列这样的开发环境中,提供无缝的图形化操作体验;命令行工具直接在终端中运行,通过自然语言指令驱动AI完成复杂的开发任务。Windsurf和Cursor属于前者,Claude Code属于后者。Codex既能够以插件的形式集成在Cursor这样的IDE中,也提供Codex CLI这样的命令行工具。
与传统的由开发者手写代码的方式相比,AI辅助编程在很多方面表现出明显差异。理解这些差异对评估其影响至关重要。
在效率方面,AI辅助编程工具显著提高了基础编码效率。多项调研表明,使用AI辅助编程的开发者生产力有大幅提升。实际使用经验也显示,在生成常见代码框架、写单元测试、构建项目脚手架等重复性任务中,AI辅助编程工具可显著提升单步效率和整体效率。传统编程需手动键入每行代码,而AI辅助编程工具可以自动生成或补全大量模板化内容,从而节省时间。
在准确性与安全方面,AI生成的代码并非总是可靠的。研究发现,AI生成的代码常包含安全漏洞。AI工具本质上基于概率模型“猜测”代码,输出结果存在不确定性,需要开发者仔细评审。相比之下,传统编程的错误更易被开发者预见。
在可维护性方面,AI生成的代码可能因风格或结构不一致带来维护负担。一些观察认为AI辅助编程工具可以提高代码一致性(例如自动遵循最佳实践)并减少低级错误,但也可能生成难以理解的“黑盒”逻辑。总体来说,由AI辅助编程工具生成的代码需要人工重构和整理才能确保长期可维护。
在学习曲线与工作曲线方面,传统编程依赖于对编程语言、算法和框架的掌握,而AI辅助编程需要开发者熟悉提示设计和AI辅助编程工具交互。成功利用AI工具需要编写清晰的提示并学会迭代求精,否则可能输出无关或低质量代码。例如,初次向AI辅助编程工具提出请求时往往得到不相关的建议,需要不断调整提示。因此,AI辅助编程的学习曲线主要在于掌握“提示工程”和对AI辅助编程工具的行为的理解,对开发者提出了新要求。
在协作方式方面,传统团队多是通过代码评审和组会的形式协作,加入AI辅助编程工具后,开发流程中出现了“AI助手”这一新角色。开发者与AI辅助编程工具像“结对编程”一样协作:开发者指导AI辅助编程工具完成模板化代码部分,进而可以把精力集中在架构设计、逻辑思考上;AI辅助编程工具帮助团队共享知识(通过学习团队代码模式)并自动化某些代码评审工作。总体而言,AI技术改变了开发者的分工——简单重复的任务由AI辅助编程工具完成,开发者变为指挥员和评审者。
在偏见与控制方面,在传统编程中,开发者对逻辑和决策过程有更大的控制权,能够实现更公平和透明的系统。而在AI辅助编程中,AI系统从历史数据中学习,数据中存在的任何偏见都可能在无意中延续甚至放大。这可能导致AI辅助编程工具生成带有偏见的代码,导致在招聘、医疗保健等关键领域做出不公平的决策。
AI辅助编程工具虽然提供了无与伦比的速度和自动化能力,但其“黑箱”特性和潜在的偏见意味着人类的监督仍然不可或缺。
氛围编程(vibe coding)是最近流行的一个概念,往往作为AI辅助编程的同义词,或者被认为是编程工作的理想愿景。我个人的观点是,虽然广义上的AI辅助编程包括氛围编程,但二者无法等同。这里有必要介绍一下氛围编程和专业意义上的AI辅助编程的区别。
氛围编程是由人工智能科学家安德烈·卡帕西(Andrej Karpathy)提出的一种新型编程范式,其核心理念是开发者通过自然语言与AI辅助编程工具交互,描述功能需求,由AI生成代码并直接运行,开发者无须深入理解代码细节或手动编写代码。
氛围编程有3个核心特点。
(1)沉浸式体验:开发者关注“氛围”(即整体功能目标)而非代码实现细节。
(2)无评审依赖:开发者不评审AI生成的代码,仅通过反馈错误消息让AI迭代修正。
(3)快速迭代:开发者通过自然语言提示和AI反馈循环快速完成从原型到成品的开发。
氛围编程和专业意义上的AI辅助编程的区别是非常明显的。
氛围编程强调“结果导向”,开发者更像“产品经理”,通过语言指令驱动AI实现功能。氛围编程不要求开发者掌握开发语言和其他相关领域(数据库、性能、可维护性、安全性等)的技术细节,因此非技术人员也能参与开发(如设计师用AI生成界面代码),但他们可能缺乏调试复杂问题的能力。
相比之下,专业意义上的AI辅助编程注重“过程控制”,尽管开发者也通过对话方式驱动AI,但是他们仍然需要掌握所有的底层逻辑,平衡性能、安全性与可维护性,了解算法复杂度或内存管理,还需要通过一整套开发流程管理(代码评审、单元测试、持续集成等)确保软件的质量。
氛围编程适合低风险、快速验证的场景(如用于创业的产品原型),专业意义上的AI辅助编程适用于需求复杂、对可维护性和可靠性要求高的领域。表面上看,二者区别似乎没有那么大,只不过一个面向非专业人员,相对简单,一个面向专业人员,相对复杂而已。但是,有经验的开发者很容易理解,一个简单的软件原型和一个工业级别的软件应用在复杂程度、使用者、编程哲学、技术要求、架构设计、开发流程等方面是完全不同的。