4月份时我写了一篇文章《与ChatGPT“结对编程”开发应用的过程体验》,分享了我借助GPT开发一个聊天机器人前端页面的过程,这也是我使用ChatGPT进行辅助编程的初体验。
有了这次经验以后,我产生了一个想法:或许今年可以利用ChatGPT来独立开发一些小型项目,并考虑其商业化的可能性。
在本文中,我将分享我与GPT第二次进行结对编程的开发实践经验。此次开发的是一个小型工具类桌面应用,相较于上次更加深入和复杂,也更接近日常真实的项目:
遵循标准开发流程(设计-编码-调试-测试-打包)
拥有独立的后端服务
更精美可控的前端布局样式
引入了测试流程
在应用开发完成之后,我总结了项目实践过程中的几点经验,并在每一条经验后提供了本项目使用到的Prompt提示词作为参考。
希望这篇文章能为有意借助ChatGPT来提高应用开发效率的开发同学提供一些参考,也非常欢迎在文章下面留言评论,分享出你们的GPT开发技巧。
提示:本次开发过程使用的是GPT-4(推荐),经个人实测,GPT-3.5与4.0在代码生成方面存在较大差距。
原则一:Think step by step
“Think step by step”,既是我们人类思考的方式,也能显著提高GPT面对复杂任务的解决能力。
就像我们在实际项目开发过程中一样,工程师在进行正式编码工作之前,需要先和产品经理、客户确认需求,并预先做好系统设计,提出解决方案和实施步骤给需求方确认。
实践方式:在需求阶段插入需求确认的步骤,不要在输入需求后让GPT立刻生成代码,先提供具体的操作步骤/实现路径,留给模型足够的时间进行思考,并在输出步骤后先检查是否符合预期。
以下是我的需求{xxxxxxxxx},你能否理解以上我提出的所有需求,如果可以请输出计算(推导)方法,暂时不需要写出全部代码。
与人跟人的协作方式一样,团队在具体执行前需先统一目标和认识,确认了实现步骤也就明确了实现预期。
原则二:Build step by step
分步构建是分步思考的延伸,即在整个开发构建过程中,对每个执行步骤再拆解,不要试图一次性解决一堆问题。要从主干到枝端,从框架到细节,分步构建的思路如下:
从操作步骤拆解:
原型设计/UI设计
必要工具、环境安装
后端实现
前端实现
功能调试/测试
应用打包/部署
从主体到细节拆解:
系统—>模块—>组件
主干功能—>枝干功能—>功能细节—>异常校验
整体布局—>主要交互—>样式细节
具备完整项目开发经验的人基本都会熟悉这套流程和思想,在与GPT协同开发时也是类似思路。我们需要通过循序渐进的提问方式,引导GPT分步完成最终任务。
三. 过程经验
赋予GPT任务角色
假设你是一个非常有经验的程序开发者/领域专家,接下来我将向你提出关于xxxx的开发问题,请为我提供详细指导。
这个步骤是必须的,是在所有提问开始之前的第一步,大模型的原理是通过概率推导生成与提示词相关的内容,“如果你没有跟它说「你是个领域专家」,它就会在低质量的推导中消耗较多的计算概率,反之,它就会丢弃更多低质量的分支逻辑,这样就可以确保更多的计算资源在预期的结果上了。”
2. 跨会话发送更多代码信息
我现在运行xxxx应用之后始终无法启动xx后端服务,接下来,我将逐一发送你xx.js,xx.json,xx.py三个文件的代码以及文件所属路径,请在拿到这三份信息后,帮我全面分析一下问题可能出现的原因
这个技巧在上篇文章中也有分享过,在实践中确实屡试不爽。当代码文件过长时,我们可以通过一个提示词技巧绕过单轮对话的发送词数限制:要求GPT等待多轮文本发送完毕之后再整体分析。
3. 调试运行经验汇总
发送完整服务端错误日志/命令行报错/控制台报错信息给GPT,附带简单描述操作步骤和预期结果。我们可以要求GPT在代码中覆盖更多日志监控点,以便于反馈更详尽的报错信息。
环境变量我添加后重新在命令行运行,浏览器控制台仍旧在报错:{xxxxxx}
请结合我的操作步骤和当前的报错信息帮我逐步检查问题所在,这是我之前的操作步骤:{xxxxxx}
多轮对话之后要定期重新发送相关代码段落发给GPT,避免GPT遗忘之前的代码结构。
请在我的代码上进行修改,修改后发给我完整的前端代码,以下是我的代码:{xxxxxx}
对于GPT无法解决的问题,可以在Google或者开发社区中寻找解决方法并作为上下文提供给GPT。
我在网上找到一个方法,你可以参考这个方法来解决上面的问题:{xxxxxx}
完整代码review
请你根据对于需求理解,来检查我的代码是否有误或者提供相关的优化建议,以下是我的原始代码:{xxxxxxx}
直接提出修改建议
我不希望用户输入错误之后直接报错,若用户输入为空值,请在前端处理为0,若用户输入为非整数,请在前端取整。
4. 前端开发经验汇总
用模糊的自然语言描述来精确微调界面布局和样式是非常困难的,所以要尽可能减少任何模糊的定义。
根据UI设计稿上的样式标注精确微调,提供具体的色值,字号,间距,相对位置等
修改“xxxx”按钮的背景色为十六进制0760B1,并将“xx”文字加粗
给应用主标题“xxxx”下面添加一张图片背景,图片宽度与卡片宽度一致,图片高度86px,然后将“xx”文字放在图片的水平和垂直居中位置
描述时使用代码中的组件名,类名
修改“xxxx”标题文字的字号为20,并且将文字移到title-container的垂直居中位置
ant-card-body的宽度现在是358px,请调到360px
引入设计系统/UI组件库
为了能让应用界面和组件样式设计更标准和精美,我尝试让GPT引用设计系统,没想到未联网的GPT4竟然真的知道该如何使用Antd(V4)。
5. 让GPT来帮助我们测试
自行编写用例
针对xxxx功能的几种特殊情况,我希望你能为我写出一份测试用例,用于完整测试该模块的计算的逻辑是否能够覆盖各种情况。
我们可以让GPT根据某一个模块来批量生成测试用例。一种用法是在开发前要求GPT根据需求生成,测试用例的编写质量能反映GPT对于需求和编码逻辑的理解,另一种用法是在完成代码调试后生成,用于后续的GPT自动化测试执行。
GPT生成的测试用例有一定参考意义,但需注意的是,GPT自行生成测试依据是我们的需求,而非已经生成的代码。并且生成后仍需要人为二次检查,必要时进行人工修改和补充。
逐条自动化执行用例
case1:…..,case2:….,case3:….,……请将以上测试用例与后端xxxx模块计算规则逐一比对,检查所有用例是否执行正确
在Prompt中提及“逐条”非常重要,GPT在输出时会对每一条用例的执行(推理)结果进行分析。
需要注意的是,实际上GPT并没有在开发环境中逐条执行用例,而是通过语言推理能力来判断用例在相关代码中是否能够执行正确,所以这个方法虽然能够帮助测试工作,但还无法替代人工或自动化测试,我测试下来会出现偶尔误测的情况。
四. 总结
如果我们仅仅是让GPT写出一个demo小工具,比如通用计算器等,GPT确实可以迅速完成。但在创建复杂的生产级应用时,GPT虽然在一定程度上降低了代码编写的门槛,但是整个过程依然需要人为深度参与,包括任务拆解、指令明确化和过程监督。
而上述三个步骤需要使用者对于无论是业务、流程、架构、技术实现都要有一定的理解。一方面要将需求拆解并抽象成GPT好理解、明确且具体的指令,另一方面要在整个实践过程中比GPT思考得更全面,不断监督GPT的执行过程,确保其始终未偏离我们的目标,也要时刻警惕人工智能的生成幻觉。
我们所期望的AI-Generate-Code的最终目标是:需求→自然语言→实现,但自然语言相较于编程语言在信息传递上是模糊的,非确定性的(否则也不会有编程语言的出现),所以通过自然语言生成代码会在未来长期内仍需要人为解释和监督。
事实上,向AI分步传递需求的过程,背后靠的是使用者对产品/项目深度理解后的精确业务抽象和步骤拆解,而这恰恰是最困难的地方。我的观点是,目前的GPT4并没有真正降低软件工程的门槛,但确实提升了使用者的开发效率,也降低了开发的准入门槛。
xiaowenz在《人工智能和传统行业的思考》智能之障一节的观点我非常认同:
人类对世界的积累,对逻辑的理解,对世界的抽象的平均水平和能力,其实惨不忍睹。
大部分企业的现状其实是:业务部门经常认为研发部门开发的系统功能不好用,研发部门经常认为业务部门讲不清楚需求。
按理说,大家都是人类,都用自然语言沟通,有啥讲不清楚的?但令人悲伤的事实就是如此,业务需求是对客观世界的抽象和归纳,功能实现是从原始的基础能力往上进行逐层具象和堆叠——他们从未对齐过。
人工智能可以填平自然语言的鸿沟,却无法填平人类远远跟不上的逻辑和抽象能力。
https://xiaowenz.com/blog/2023/04/decouple-your-time/
感谢阅读,欢迎分享。
推荐阅读
《这就是ChatGPT》
[美] 斯蒂芬·沃尔弗拉姆|著
WOLFRAM传媒汉化小组|译
OpenAI CEO,ChatGPT 之父山姆·阿尔特曼推荐,国内首部由世界顶级 AI 学者、科学和技术领域重要的革新者、“第一个真正实用的人工智能”搜索引擎 WolframAlpha 发明人斯蒂芬·沃尔弗拉姆对 ChatGPT 最本质的原理的解释的权威之作!