一、開發信息

• 開發時間：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）窗口，將新的問題單獨提出來，然后觀察新的結果。