AI编程：[体验]从 0 到 1 开发一个项目的初体验

一、开发信息

• 开发时间：1.5-2天
• 工具使用：
  • 不熟练，开发本项目前1天，才简单使用了Cursor的功能
• 功能复杂度：
  • 开发的功能相对简单。
  • 页面：2个，登录页面，个人中心页面
  • 功能：5个，登录注册、个人信息、修改密码、退出登录、弹窗提示
• 技术复杂度：
  • 前后端分离，含前端（vue）和后端（Java）
• 痛点问题：
  • 后端：生成的代码存在版本兼容性问题，需要花费大量时间去调试和修正
  • 前端：由于对vue仅限了解，所以在解决比较普通的问题时，若AI解决不了，于我而言也是一个痛点问题
  • 工具：AI工具在解决问题时，存在答非所问，张冠李戴的情况，导致耗费大量时间去调试错误
  • 提示词：输入的提示词可能不够好，导致生成的质量不达预期

---

二、开发模式

基于当前AI编程助手所具备的能力，从实践得出的如下内容。

全栈开发模式

• 适用用户：
  • 全栈开发者：在意代码的有效性，也在意代码的优美和结构
  • 非技术人员：更在意代码的有效性，而非代码的优美和结构
• 适用场景：
  • 团队维度：有全栈开发者的团队或初创公司；无技术人员的公司；
  • 项目维度：验证性项目的MVP版本；一次性项目，如可完整交付的项目。
• 风险提示：
  • 技术盲区：单端能力缺失，将显著降低效率。如：一名前端，不懂后端，用Cursor开发，遇到错误反复调试不通时，过程很痛苦，效率也很低。

---

专业开发模式（现状）

• 适用用户：
  • 专业开发者：前端、后端
• 适用场景：
  • 团队维度：前端、后端、测试、运维等各岗位俱全，且分工明确的团队
  • 项目维度：长期运营迭代的复杂项目
• 实施路径：
  • 第一步：基于脚手架搭建项目（1分钟生成+100%可用）
  • 第二步：基于模板生成代码（1分钟生成+100%可用）
  • 第三步：AI助手生成代码片段（使用AI的关键环节，目标：开发效率提升40%以上）
• 实施说明：
  • 第一步和第二步，需要团队或开发者，沉淀脚手架和模板。若当前没有沉淀，也可借助AI来快速生成并沉淀脚手架和模板。
  • 第一步和第二步，若采用AI生成代码，需要花时间编写良好的提示词，且生成的代码需要大量调试，效率和质量，都不如基于脚手架和模板 生成的代码来的好。
  • 第三步，专业开发者，借助AI助手生成本技术栈的代码，效率会得到极大提升。
• 最佳实践：
  • 复用：AI生成代码时，可询问AI有没有现成的组件或框架，避免用AI从0到1造轮子。
  • 质量：AI生成的每一行代码，都必须review，否则没办法保证质量。
  • 效率：开发者清楚的知道，要实现什么功能，要改哪里的代码，用AI辅助开发就会很快。
  • 熟练：对AI助手的熟练程度，对编码效率的影响很大，一定要多用，尽快熟练起来。

---

总结：综合对比

• 如果你是一名非技术人员，无所谓代码不代码，只要开发项目就行，那么建议使用全栈开发模式。
• 如果你是一名专业开发者，那肯定有自己熟悉的技术栈和沉淀，那么建议使用专业开发模式。
• 如果你是一名全栈开发者，完全可以按照专业开发模式的实施路径来执行，速度会更快，效果会更好，因此建议将全栈开发模式和专业开发模式结合起来使用。
• 最后，专业开发模式的实施路径，可以通过Agent串起来，形成一个工作流，进一步提升效率。

---

个人理解

• 核心目的：使用AI是为了快速开发项目，而不是为用AI生成代码。因此不是所有代码都要通过AI来生成。
• 未来已来：可预测未来AI会越来越强，开发门槛只会越来越低
• 超级个体：懂产品+技术全栈（前端、后端、测试、运维）
• 系统工程：从原型图开始，UI设计稿，到前端代码生成，后端代码生成，再到测试用例生成，测试用例执行，通过智能体平台全部自动化（Agent或工作流），但效果可能堪忧。
• 提示词
  • 提示词写不好怎么办？
    • 采用Prompt模板的方式，来简化和加速提示词的编写
    • 通过调用大模型来优化Prompt，然后沉淀为Prompt模板

---

三、实践遇到的问题

Cursor后端：第三方Jar包的版本兼容性问题

Cursor错误分析：在cursor上提问如下错误，提示是spring-security的问题，但实际是springboot3与mybatis-plus集成的版本兼容问题

说明：本质是springboot 3，集成mybatis-plus的版本不兼容导致的问题。

• 错误1：Invalid value type for attribute ‘factoryBeanObjectType’: java.lang.String
• 解决：mybatis-plus 3.5.3.2 中mybatis-spring版本为2.1.2，升级为3.0.3

<dependency><groupId>com.baomidou</groupId><artifactId>mybatis-plus-boot-starter</artifactId><version>3.5.3.2</version><exclusions><exclusion><artifactId>mybatis-spring</artifactId><groupId>org.mybatis</groupId></exclusion></exclusions></dependency>
<dependency><artifactId>mybatis-spring</artifactId><groupId>org.mybatis</groupId><version>3.0.3</version></dependency>

• 错误2：Bean named ‘ddlApplicationRunner’ is expected to be of type ‘org.springframework.boot.Runner’ but wa
• 分析：因为使用的是springboot 3，应该使用mybatisplus3
• 参考：https://blog.csdn.net/weixin_46211609/article/details/135552632
• 解决：mybatis-plus 3.5.3.2 升级为 mybatis-plus 3.5.5
• 最终方案：推荐基于脚手架做项目初始化

Cursor前端：弹窗一直展示，且无法关闭的问题

• 现象：生成的代码，连续报错，一个一个解决后，最后还是弹窗还是一直显示着，且无法关闭。
• 原因：最终咨询前端同学，发现cursor一开始生成的弹窗组件代码就有问题，所以效果一直不达预期。
• 方案：删除掉弹窗组件相关的代码，让cursor重新帮忙生成一个苹果样式的弹窗方法，效果达到预期。

Trae前端：生成代码失败，可新建会话，重新对话

• 分析：可能是我一直在一个 Builder 对话窗口中，进行提问并生成代码，累积的上下文太长，导致Trae生成失败。就像人类注意力会在阅读长文时逐渐分散一样，模型处理特长文本时的表现也会大打折扣。所以在实际应用中，短小精悍往往比冗长絮叨更有效。
• 方案：在 Builder 中创建新对话，为每个不同的任务开启新的 Builder 对话，保持智能体对话简短。
• 原则：
  1. 一次只处理一个任务，避免思维混乱；
  2. 将任务规模控制在上下文窗口范围内，确保模型能够充分理解；
  3. 对于大型项目，善用检索增强，让AI能够精准定位并利用关键信息。

Trae前端：在使用回退到本轮对话发起前功能时，导致代码被回滚

• 分析：没有将之前的代码提交到Git，导致回滚后找不回之前的代码，浪费了大量时间。
• 方案：每个不同的任务或功能生成且调试完后，记得一定要提交代码，一定要通过Git来做版本管理。

Trace前端：与Trae多轮对话，问题仍然无法解决

• 分析：可能被之前的信息给影响了，陷入到了一个死循环里面
• 方案：
  • 遇到多轮对话，还解决不了的问题，可以让Trae详细分析并解释问题，再基于分析去解决
  • 更好的做法是，开启一个新的聊天（Chat）或编排（Builder）窗口，将新的问题单独提出来，然后观察新的结果。