在一篇博客中，我曾興致勃勃地分享了如何用Cursor在短短半天內(nèi)完成AI工具的從0到1實現(xiàn)。那時的我，就像剛學(xué)會騎自行車的孩子，對這個“新玩具”充滿了熱情。但很快，我就意識到這只是冰山一角。單純的代碼生成固然令人興奮，但在實際開發(fā)中，我們面臨的挑戰(zhàn)遠不止于此。

于是，我開始了一段更深入的探索之旅。特別是在代碼重構(gòu)這個領(lǐng)域，我發(fā)現(xiàn)Cursor展現(xiàn)出了令人驚喜的潛力。當(dāng)我給它一些重構(gòu)指令時，它不僅能理解我的意圖，還能按照預(yù)期重構(gòu)代碼，而且速度快得驚人。這讓我不禁幻想：如果能把這項技能應(yīng)用到日常開發(fā)中，那豈不是能在別人還在埋頭重構(gòu)時，我已經(jīng)可以優(yōu)哉游哉地“摸魚”了？

一、現(xiàn)實給的一記重拳：復(fù)雜項目重構(gòu)的困境

然而，現(xiàn)實總是喜歡給我們一記重拳。當(dāng)我滿懷信心地將這種簡單直接的重構(gòu)方式應(yīng)用到實際項目中時，很快就碰了壁。由于真實項目的復(fù)雜度遠超簡單的AI工具代碼項目，簡單的prompt在這里就像是用牙簽撬動大象。

1. 遇到的主要問題：

• 改動范圍失控：就像是沒有地圖的探險，每次重構(gòu)都像是在隨機漫步。
• 重構(gòu)策略混亂：完全依賴大模型自動選擇重構(gòu)策略，就像是把方向盤交給了蒙著眼睛的司機。
• 上下文理解障礙：即使使用了@Codebase，Cursor依然像是對整個項目背景一無所知，重構(gòu)起來漫無目標(biāo)。
• 代碼審查負擔(dān)：每次改動都需要仔細審查，否則就像是在刀尖上跳舞，提心吊膽。
• 惡性循環(huán)：越重構(gòu)越亂，最后不得不推倒重來，陷入了一個“推倒重來-再次失敗”的死循環(huán)。

2. 問題根源分析

經(jīng)過深入思考，總結(jié)出了幾個核心原因：

• 邏輯復(fù)雜度過高：現(xiàn)實項目往往包含復(fù)雜的業(yè)務(wù)邏輯和條件判斷。
• 框架知識欠缺：沒有給AI進行適當(dāng)?shù)目蚣躉nboarding。
• 代碼風(fēng)格多樣性：不同開發(fā)者的編碼風(fēng)格差異帶來的挑戰(zhàn)。
• 上下文負擔(dān)過重：相互關(guān)聯(lián)的代碼太多，形成了復(fù)雜的依賴網(wǎng)絡(luò)。
• 行為不可預(yù)測：無法準(zhǔn)確預(yù)知AI的下一步操作。

二、人機對比：重構(gòu)思維的差異

為了找到突破口，我開始思考：為什么同樣是重構(gòu)，人類開發(fā)者能夠相對順利地完成，而AI卻頻頻踩坑？

人類開發(fā)者的重構(gòu)方式：

• 系統(tǒng)性分析：首先識別和消除code smell，提升代碼的可讀性和可擴展性。
• 面向?qū)ο髢?yōu)化：基于面向?qū)ο蟮淖罴褜嵺`進行重構(gòu)。
• 架構(gòu)層面調(diào)整：將代碼重新組織到合適的層次結(jié)構(gòu)中。
• 測試驗證：確保重構(gòu)后的代碼仍然符合預(yù)期行為。

AI的重構(gòu)方式：就像一個機械工人，簡單地重復(fù)“修改代碼”這個動作，缺乏我們期望的系統(tǒng)性思維和策略性規(guī)劃。

三、靈感突現(xiàn)：ReAct框架的啟發(fā)

在尋找解決方案的過程中，我接觸到了Agent和ReAct以及COT，這讓我眼前一亮。如果能讓AI像人類一樣思考并且按照人類期望的方式進行思考，是否就能克服當(dāng)前的困境？

1. ReAct框架簡介

ReAct 框架是由 Shunyu Yao 等人在 2022 年提出的一種方法，旨在結(jié)合推理與行動，以提高大型語言模型（LLMs）的性能。該框架允許 LLMs 交替生成推理軌跡和任務(wù)特定操作，從而使模型能夠誘導(dǎo)、跟蹤和更新操作計劃，并有效處理異常情況。

• 與外部工具的交互：ReAct 框架使 LLMs 能夠與外部知識庫或環(huán)境進行交互，從而獲取額外信息，提供更可靠的回應(yīng)。
• 性能提升：研究表明，ReAct 在語言和決策任務(wù)上表現(xiàn)優(yōu)于多個先進的基線模型，同時提高了 LLMs 的可解釋性和可信度。
• 與鏈?zhǔn)剿伎迹–oT）的結(jié)合：將 ReAct 與鏈?zhǔn)剿伎冀Y(jié)合使用，可以在推理過程中同時利用內(nèi)部知識和外部信息，從而取得最佳效果。

四、實踐：構(gòu)建重構(gòu)專用的Prompt

重構(gòu)步驟設(shè)計：

• 基礎(chǔ)清理：識別和處理基本的code smell
• 面向?qū)ο髢?yōu)化：應(yīng)用面向?qū)ο蟮淖罴褜嵺`
• 架構(gòu)調(diào)整：根據(jù)六邊形架構(gòu)的規(guī)范重組代碼
• 錯誤修復(fù)：處理明顯的編譯錯誤
• 人工復(fù)查：補充細節(jié)優(yōu)化
• 測試修復(fù)：確保所有測試用例通過

重構(gòu)Prompt模板設(shè)計：

• 上下文說明：提供架構(gòu)規(guī)范和最佳實踐指南
• 思考步驟：引導(dǎo)AI進行系統(tǒng)性分析
• 觀察記錄：記錄發(fā)現(xiàn)的問題
• 行動指南：明確具體的重構(gòu)步驟

基于上述的ReAct和COT的啟發(fā)，設(shè)計了一個用于當(dāng)前項目上DDD重構(gòu)的Prompt（包含重構(gòu)設(shè)計的前3步）：

1. Prompt for Refactoring

Context: 在六邊形架構(gòu)的DDD實現(xiàn)模式中，Application Service、Domain Service、Query 以及 Port 的設(shè)計和實現(xiàn)有一些最佳實踐和經(jīng)驗。以下是總結(jié)的經(jīng)驗和適合的重構(gòu)提示：

• Application Service：主要負責(zé)用例編排和事務(wù)管理，不包含業(yè)務(wù)邏輯，而是調(diào)用 Domain Service 執(zhí)行具體操作。
• Domain Service：包含核心業(yè)務(wù)邏輯，處理復(fù)雜業(yè)務(wù)規(guī)則和操作，是領(lǐng)域模型的一部分。
• Port：定義應(yīng)用程序與外部系統(tǒng)之間接口，包括 inbound 和 outbound 包中的 Repository 接口定義。

基于上述上下文。請參照 @AcademyCourseDomainService.java  對當(dāng)前文件進行重構(gòu)，如果涉及 @EnrollmentApplicationService.java  的修改，也可以進行修改。使用 ReAct 框架按照下面的思考步驟來指導(dǎo)此過程，以分析、觀察、執(zhí)行并最終完成代碼重構(gòu)。

• Thought-1：是否有明顯的codesmell？
• Observation-1：有codesmell：Longmethod
• Action-1：使用這個codesmell對應(yīng)的最佳實踐進行重構(gòu)
• Thought-2：是否有特別需要注意的codesmell，比如說面向?qū)ο蟮?大基本原則，單一職責(zé)原則、開放封閉原則、里氏替換原則、依賴倒置原則和接口隔離原則？
• Observation-2：有幾個地方，不符合單一職責(zé)原則
• Action-2：了解單一職責(zé)原則的最佳實踐，并進行代碼重構(gòu)
• Thought-3：當(dāng)前文件是什么Layer，需要遵循哪些職責(zé)？
• Observation-3：當(dāng)前的文件是DomainServiceLayer，里面有些實現(xiàn)做的事情不屬于domainservice的職責(zé)
• Action-3：根據(jù)Domainservice職責(zé)，對這幾個實現(xiàn)進行重構(gòu)，分析這些做的事情屬于哪些layer的職責(zé)，將實現(xiàn)挪到對應(yīng)的Layer中去

2. Cursor composer的輸出：

五、實驗效果與經(jīng)驗總結(jié)

通過多輪實驗，這種基于ReAct的重構(gòu)Prompt編寫方法展現(xiàn)出了明顯的優(yōu)勢：

• 更高的結(jié)果正確性： 這種重構(gòu)方法能夠在僅需兩到三輪的互動中，達成預(yù)期結(jié)果。與傳統(tǒng)方法相比，ReAct和COT的結(jié)合使得模型能夠更有效地整合信息和推理過程，從而減少了錯誤和不確定性。這種高效性使得用戶在處理復(fù)雜問題時，能夠更快地獲得準(zhǔn)確答案。
• 目標(biāo)導(dǎo)向的思考過程：采用ReAct框架后，模型的思考方向更加符合用戶的期望，而不是受到幻覺（即生成不實信息）的影響。通過引入額外信息源（觀察的步驟會引入需要的信息），模型能夠?qū)崟r驗證和更新其推理路徑，從而確保所生成的信息是基于事實而非虛構(gòu)。這一特性顯著提升了用戶對模型輸出的信任度。
• 可視化的思考與修改過程： 在Cursor的composer模式中，用戶可以清晰地看到思考和修改的中間過程。這種透明性讓開發(fā)者能夠追蹤每一步的修改步驟，從而更好地理解模型如何得出最終結(jié)論。通過展示具體的推理軌跡和所采取的行動，用戶不僅能審視模型的決策過程，還能對其進行必要的調(diào)整和優(yōu)化。

效果提升的關(guān)鍵因素：

• 邊界清晰：通過Context限定了AI的行為范圍
• 步驟明確：讓AI按照預(yù)定的思維方式進行重構(gòu)
• 反饋閉環(huán)：每個步驟都有明確的觀察和行動指南

思維方式的轉(zhuǎn)變：這個過程讓我意識到，使用AI的關(guān)鍵在于轉(zhuǎn)變思維方式：從“問題導(dǎo)向”轉(zhuǎn)向“引導(dǎo)式合作”。

我們需要做的是：

• 人負責(zé)分析和規(guī)劃
• AI負責(zé)執(zhí)行具體細節(jié)
• 通過精心設(shè)計的Prompt建立橋梁

六、AI編碼助手使用的新范式

這次的探索不僅幫助我解決了代碼重構(gòu)的難題，更重要的是讓我領(lǐng)悟到了一個道理：AI不是萬能的，但通過正確的引導(dǎo)，它可以成為我們強大的助手，起到能力放大器的作用。當(dāng)我們學(xué)會用“教練”而不是“提問者”的身份與AI互動時，往往能獲得更好的結(jié)果。當(dāng)然，這也給我們帶來了新的要求：在與AI進行協(xié)作時，了解最佳實踐和方法論成為了前提條件，只有這樣，我們才能更有效地引導(dǎo)AI以正確的方式完成工作。

這種思維方式的轉(zhuǎn)變，讓我們能夠更好地發(fā)揮人類的創(chuàng)造力和AI的執(zhí)行力，從而提升代碼質(zhì)量和開發(fā)效率（在理想情況下，提升開發(fā)效率應(yīng)當(dāng)將節(jié)省下來的時間來促進代碼質(zhì)量的提高，而不是單純追求高產(chǎn)出，否則我們可能會陷入另一個無法自拔的漩渦。追逐產(chǎn)出而忽視質(zhì)量，最終仍然會導(dǎo)致技術(shù)債務(wù)高筑，增加維護成本，甚至影響項目的可持續(xù)性。因此，平衡效率與質(zhì)量至關(guān)重要。通過注重代碼的可讀性、可維護性和合理的使用最佳實踐，我們不僅能夠提高開發(fā)速度，還能確保軟件的長期健康和穩(wěn)定性）。在未來，這種人機協(xié)作的模式也許會成為軟件開發(fā)的一種新范式。

七、Prompt分享

經(jīng)過實踐，我們總結(jié)出了一個專門針對代碼基礎(chǔ)異味（code smell）重構(gòu)的提示模板。如果你對代碼基礎(chǔ)異味的重構(gòu)感興趣，歡迎嘗試使用這個站點下的Prompt模板。這個重構(gòu)Prompt模版站點是為開發(fā)者量身打造的資源分享平臺，旨在提供高效可行的Prompt模版，以提升使用Cursor進行重構(gòu)的體驗，主要面向希望通過AI優(yōu)化重構(gòu)過程的同事。其Prompt特色在于能夠顯著降低AI在重構(gòu)時可能出現(xiàn)的幻覺。大家可以通過參考站點的Quick Start操作快速上手，從而提升重構(gòu)的準(zhǔn)確率和效率，讓大家更專注于最佳實踐和方法論的思考。

到此，我們的討論就告一段落了。感謝大家的閱讀和關(guān)注!