一、靈魂拷問 - “AI提效200%？我信你個(gè)鬼！”

提到AI輔助開發(fā)，很多同學(xué)都吐槽過。

“AI寫的代碼都很垃圾啊，問AI問題很多時(shí)候就像對(duì)牛彈琴一樣，答非所問”。

其實(shí)并不見得是AI無法勝任我們的開發(fā)需求，關(guān)鍵在于要掌握正確的使用方法，就像學(xué)習(xí)IDE和Git工具一樣。

那為什么很多同學(xué)使用AI的效果不好呢？通常有以下三個(gè)原因：

1.提示詞不夠精準(zhǔn)

許多人習(xí)慣用模糊指令，比如“寫個(gè)登錄代碼”，但AI不是人類，它需要明確的任務(wù)路徑。正確的提問方式應(yīng)當(dāng)為：“使用 Spring Boot 框架，搭配 MySQL 數(shù)據(jù)庫，采用 BCrypt 加密算法，編寫包含用戶名密碼驗(yàn)證、登錄失敗提示、用戶會(huì)話管理的用戶登錄功能代碼”。

2.使用方式不當(dāng)

我們不能期待AI完全替代我們來進(jìn)行思考，正確的AI輔助開發(fā)思路應(yīng)該為：

1：用提示詞生成80%框架代碼。

2：人工補(bǔ)充核心業(yè)務(wù)邏輯。

3.工具選擇不當(dāng)

使用通用的大模型AI工具進(jìn)行代碼生成，而不是專業(yè)的開發(fā)工具。有時(shí)候我們會(huì)發(fā)現(xiàn)，讓ChatGPT生成代碼，光給AI講清需求背景以及代碼上下文就得反復(fù)溝通十多次，有這功夫確實(shí)不如我自己動(dòng)動(dòng)手了。

二、Cursor的殺手锏 - 不是“問答AI”，是“編碼協(xié)作者”

Cursor與通用大模型AI的本質(zhì)區(qū)別在于與代碼環(huán)境深度集成，解決了基于通用AI進(jìn)行代碼生成時(shí)，溝通吃力的致命缺陷。

它“看得見”你的代碼

Cursor 不僅僅是一個(gè)代碼補(bǔ)全工具，它實(shí)際上是一個(gè)完整的 IDE，它的核心是圍繞 AI 驅(qū)動(dòng)的編程體驗(yàn)進(jìn)行設(shè)計(jì)。基于Cursor進(jìn)行開發(fā)時(shí)，再也不需要在聊天框里費(fèi)力描述代碼，省去了復(fù)制粘貼的麻煩。你只需要把代碼片段、多個(gè)文件、甚至整個(gè)文件夾選中并拖動(dòng)到Cursor的Chat界面，Cursor就可以基于上述的代碼背景完成開發(fā)。

任務(wù)自治：從指令到交付的閉環(huán)

通用大模型AI往往只會(huì)生成代碼片段或描述，在此之后你需要手動(dòng)進(jìn)行逐行整合。

而Cursor會(huì)從創(chuàng)建代碼目錄開始，到Cursor幫你創(chuàng)建測(cè)試類并自動(dòng)執(zhí)行測(cè)試完畢為止，完整的進(jìn)行代碼交付。中途出現(xiàn)的任何問題，Cursor會(huì)給出方案，并讓用戶選擇如何修改。然后重新自動(dòng)進(jìn)行測(cè)試，直到代碼可用為止。

我們以讓Cursor生成一個(gè)簡(jiǎn)單的天氣爬蟲為例： Cursor基于我們的要求生成完成代碼后，會(huì)自動(dòng)展開測(cè)試

Image text

此時(shí)Cursor發(fā)現(xiàn)沒有爬取到任何天氣數(shù)據(jù)后，給出了兩個(gè)建議讓我們選擇。

Image text

我們讓Cursor自動(dòng)修復(fù)后，Cursor會(huì)重新引導(dǎo)用戶執(zhí)行測(cè)試，我們點(diǎn)擊右上角“Run”執(zhí)行腳本，這一次爬蟲可以正常運(yùn)行。

Image text

風(fēng)險(xiǎn)把控：Cursor驅(qū)動(dòng)代碼審查

在代碼審查方面，Cursor能夠基于用戶給出的規(guī)范更靈活地識(shí)別不合理的代碼，極大提升代碼質(zhì)量和審查效率。并根據(jù)CR的結(jié)果自動(dòng)生成修復(fù)方案并應(yīng)用。下面給出一個(gè)CR的提示詞案例：

使用下面的git命令, 輸出當(dāng)前分支與遠(yuǎn)程主分支的差異, 輸出到cr.diff 文件中
git diff origin/master  > cr.diff
掃描diff 文件中的差異代碼。reviwe 的規(guī)則如下

1. 方法體行數(shù)應(yīng)少于100行, 不包括空行,和注釋
2. 枚舉定義需要有兩個(gè)以上屬性, code, name, 并且需要有通過code獲取枚舉項(xiàng)的方法
3. 接口返回false , 前端是否有對(duì)false進(jìn)行處理 
4. throw 了異常的位置, 一定要打log日志 
5. 所有的public 公有方法都要打印入?yún)og.info日志 
6. 所有的public 公有方法, 結(jié)束都要打印結(jié)束日志 
7. 所有調(diào)用rpc的方法, 都要打印日志
8. 所有方法都要有方法級(jí)別的注釋
9. try catch異常后, 如果在catch 中又拋出了新創(chuàng)建的異常時(shí), 需要將原異常賦值給新異常, 案例如下:
    ```java
        try {
            ApiResult<String> result = uploadService.getUploadId(uploadIdDTO);
            log.info("UploadServiceHelper#getUploadId result:{}", JsonUtils.toJsonWithoutNull(result));
            if (result.isSuccess()){
                return result.getData();
            }
        }catch (Exception e){
            log.error("UploadServiceHelper#getUploadId 調(diào)用uploadService.getUploadId失敗", e);
            throw new MyException("調(diào)用uploadService.getUploadId失敗", e);
        }

    ```
10. 不能調(diào)用被標(biāo)記@Deprecated 的屬性或方法或類
11. 定義的常量值, 給出清晰的注釋說明用途, 避免硬編碼
12. 標(biāo)注了@transactional的方法要明確回滾異常類型, 對(duì)于只讀操作要標(biāo)注只讀readOnly=true 提高性能
13. 3次以上字符串拼接使用StringBuilder代替字符串拼接
14. 檢查是否存在其他破壞兼容性的改動(dòng)或邏輯上的錯(cuò)誤

遍歷所有規(guī)則, 一個(gè)規(guī)則一個(gè)規(guī)則的去檢查增量代碼的規(guī)范性, 每個(gè)規(guī)則進(jìn)行Review時(shí), 使用獨(dú)立的上下文, 最后歸納所有的Review結(jié)果.
輸出違反規(guī)則的文件位置, 并修改對(duì)應(yīng)文件 符合規(guī)范
cr 結(jié)束后將cr.diff 文件刪除

然后Cursor會(huì)給出如下的輸出：

Image text

Image text

最后，Cursor會(huì)基于上述審查結(jié)果自動(dòng)進(jìn)行代碼修改，用戶可以手動(dòng)選擇接受。

這些能力的疊加，使得在實(shí)際開發(fā)中，原本需要一天完成的任務(wù)，借助Cursor往往三四個(gè)小時(shí)就能搞定，真正實(shí)現(xiàn)效率翻倍的可能。

三、關(guān)鍵提醒：效率倍增的前提是“善用其長(zhǎng)，避其之短”

• 它不是“魔法”是“神器”：核心價(jià)值是處理定義明確、模式化、有上下文的任務(wù)，而不是替代你的設(shè)計(jì)、架構(gòu)以及核心業(yè)務(wù)邏輯。
• 核心原則：Review, Review, Review！生成的代碼/修改必須仔細(xì)審查！它能幫你寫出功能正確、語法規(guī)范的代碼，但業(yè)務(wù)邏輯的正確性和最優(yōu)性最終在你。
• 清晰指令是關(guān)鍵：描述需求時(shí)盡可能清晰、具體。就像給一個(gè)聰明的實(shí)習(xí)生下任務(wù)一樣。

四、結(jié)語：擁抱進(jìn)化，成為更強(qiáng)大的開發(fā)者

擁抱AI的本質(zhì)，是開發(fā)者的一場(chǎng)戰(zhàn)略性進(jìn)化。它絕不意味著能力的退化，而是幫助開發(fā)者將精力聚焦于更高級(jí)的任務(wù)（設(shè)計(jì)、架構(gòu)、復(fù)雜業(yè)務(wù)、創(chuàng)新）。就像工匠有了電動(dòng)工具，大師依然是大師，只是效率更高而已。

關(guān)于作者，張晨朝，俠客匯Java開發(fā)工程師。