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能够精准定位并利用关键信息。