GPT4开发应用实践（全栈篇）

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

分步构建是分步思考的延伸，即在整个开发构建过程中，对每个执行步骤再拆解，不要试图一次性解决一堆问题。要从主干到枝端，从框架到细节，分步构建的思路如下：

从操作步骤拆解：

1. 原型设计/UI设计
   

2. 必要工具、环境安装

3. 后端实现

4. 前端实现

5. 功能调试/测试

6. 应用打包/部署

从主体到细节拆解：

1. 系统—>模块—>组件

2. 主干功能—>枝干功能—>功能细节—>异常校验

3. 整体布局—>主要交互—>样式细节

具备完整项目开发经验的人基本都会熟悉这套流程和思想，在与GPT协同开发时也是类似思路。我们需要通过循序渐进的提问方式，引导GPT分步完成最终任务。 

三. 过程经验

1. 赋予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 最本质的原理的解释的权威之作！