最近 Cursor 很火，火到我身邊的程序員們已經(jīng)不聊河北彩花，LOL，黑猴等，而是在各種場合討論這個 Cursor 的輔助編程能力。各類內容平臺也在以驚人的速度，迭代出了許多相關教學視頻：

圖片

我試用了一段時間，第一感覺確實很驚艷，能幫我解決很多基礎問題，實打實地提升開發(fā)效率，印象比較深的，包括：

• Codebase Indexing、@symbol 等功能帶來的更強的上下文索引能力，而這極大提升最終 LLM 生成的代碼效果；
• Cursor Composer 功能提供了一個注意力非常聚焦的編程面板，相比于過往 GPT 等產(chǎn)品的即聊即拋的模式，更容易做好跨文件的編輯開發(fā)，而這更符合專業(yè)開發(fā)者的模塊化編程習慣。

但是，我覺得，至少在當下階段，這類產(chǎn)品的定位只能是“輔助編程”，雖然能極大提升效率，但還只是編程活動中的輔助客體，俗稱打下手；程序員本體 —— 人類智能依然是主體地位，有點類似于掌柜的吧。

下面我列舉幾個點，分析 Cursor 能做好的任務，做不好的任務，以及更重要的，作為個體，應該如何適應這個 AI 快速發(fā)展的時代。

Cursor 的本質

毫無疑問，Cursor 能解決非常多基礎問題，包括我自己也已經(jīng)習慣了使用 Cursor 替代 VS Code 完成日常工作。它很好用，但并不神秘，本質上就是在傳統(tǒng) IDE 基礎上，搭配足夠好的交互與足夠好的 LLM，從而超越傳統(tǒng) IDE。交互方面，它在 VS Code 基礎上，補充提供了：

• 更適配 LLM 場景的上下文引用能力(即 @codebase/@files 等 symbol 指令)；
• 適合復雜編程的 Composer 面板，可以在此與 LLM 保持一個較長時間的回話，并且支持多文件編輯，可以在這里持續(xù)溝通，持續(xù)生成代碼，完成復雜任務；
• 提供了幾乎毫無門檻的代碼自動補全能力，并且支持多行編輯，這在一些場景，如修改變量名時，非常好用；
• 甚至還貼心的支持在 Terminal 中喚醒 LLM 交交互面板，實現(xiàn)命令生成、命令行錯誤處理等能力。

這些交互上的創(chuàng)新，從技術角度看并不特別復雜(甚至有不少瑕疵)，但從產(chǎn)品角度看，確實做到了即貼合開發(fā)者習慣，又能為 LLM 提供更多上下文信息，進而提升模型效果。非常值得稱道的一點是，這些交互與傳統(tǒng) IDE 的交互邏輯非常契合，對專業(yè)程序員而言不需要過多學習，很快就能上手應用，幾乎能做到無縫接入。

在交互之外，Cursor 并沒有過多投入精力開發(fā)自己的大模型(算是一種克制)，而是提供了比較流程的模型切換功能，用戶可以在配置面板上按自己的意愿在各種上下文中切換主流 LLM：

圖片

我認為這是一種非常聰明的產(chǎn)品決策，既規(guī)避了將有限資源投入到前途未卜的大模型研發(fā)中 —— 從而可以聚焦打磨產(chǎn)品本身的體驗；又給予用戶充分的自由度，延續(xù)自己的喜好。雖然讓渡了一部分商業(yè)利益，但使用者的接受度更高，進而更容易獲得種子用戶的信任，也就更容易在當下的市場中脫穎而出。

而作為一個普通開發(fā)者，我認為我們并不需要過度“神話”這個軟件，還是那句話：本質上就是在傳統(tǒng) IDE 基礎上，搭配足夠好的交互與足夠好的 LLM，因此完全把它看做增強版的 VS Code —— VS Code 能做到的事情它同樣都能做到，只是在此基礎上疊加了許多渾然天成的 LLM 交互能力，即使不做任何配置，也能通過 Auto Completion 等能力獲得極大增強的編程體驗與效率提升，即使為此需要每月支付 $20，我認為也是非常值得的。

Cursor 的適用場景

從我的使用經(jīng)驗看，我覺得 Cursor 非常適合下面這幾類編程場景。

問答

首先是最基礎的問答場景，我相信絕大部分程序員應該都做不到無所不知，開發(fā)過程中總會需要查找各類資料，在過去我不得不使用 Google/百度之類的搜索引擎查找相關文章，之后自己仔細閱讀多篇文章后，總結找到解決方案。

LLM 支持聯(lián)網(wǎng)功能后，我開始嘗試使用 Claude、ChatGPT、Perplexity 等平臺咨詢技術問題，這些工具都能夠根據(jù)我所提的問題自動提煉關鍵字、聯(lián)網(wǎng)搜索，以及 —— 最重要的，它們能夠總結分析搜索結果，之后直接返回一個相對簡潔的答案，理想情況下，我已經(jīng)不再需要在緊張的工作過程花時間閱讀仔細閱讀、理解這些文章，能更好地保持心流狀態(tài)。

但是，這類平臺給出的答案置信率并不是很高，主要原因在于我很難在一個簡單的對話框中給出足夠詳細的上下文信息 —— 總不能把整個倉庫的代碼都粘貼進去吧？而 Cursor 提供的諸多上下文符號(@xxx)引用能力就很好地彌補了這一點，例如可以使用 @Codebase 符號索引整個倉庫(前提是打開 Code Indexing 配置)，要求 LLM 給出分析結果：

圖片

這種極強的上下文索引能力，其底層本質上就是將整個倉庫 Embedding 成向量數(shù)據(jù)庫，之后提供給 LLM 消費，從而超越了常規(guī)的公共知識領域問答模型，而具備極強的私域知識理解能力，單純使用 GPT、Claude、Doubao 等模型是非常難以實現(xiàn)這一點的。

更進一步的，基于這些特性，Cursor 還能非常高效地幫我分析總結各類項目的底層原理：

圖片

這是一個非常非常有用的特性，過往我在接手一個舊項目，或者學習一些開源項目的時候，不得不逐行主句地理解整個項目的代碼，而現(xiàn)在我可以跳過許多細節(jié)，讓 Cursor 幫我更快地理解倉庫代碼。

生成單測

這個很強，一方面能夠增量生成，一方面你可以不斷要求它提升覆蓋率，生成更多單測用例

很多 LLM 工具、平臺都能生成單測，但 Cursor 表現(xiàn)的會更好一些。相對而言，GPT 等工具的交互形式過于簡單，只能一段一段將代碼復制粘貼進對話框請求生成單測，這會導致兩個問題：一是上下文缺失，難以正確推斷下游模塊的實現(xiàn)細節(jié)，進而影響生成效果；二是很難實現(xiàn)增量更新，例如你已經(jīng)為你的代碼模塊生成過一份單測代碼，但后續(xù)迭代維護導致單測過時后，很難借助 GPT 針對發(fā)生變化的這部分代碼調整單測。

而 Cursor 顯然已經(jīng)解決了這些問題。如前文所言，Cursor 可以向量化整個代碼倉庫，因此它有能力自由索引倉庫內的所有文件，在生成單測代碼時，可以同時將目標模塊以及模塊對應的上下游模塊代碼同時提供給 LLM，上下文信息越充分其勢必生成的結果會更精確一些。

舉個具體例子，我在使用 GPT 等工具生成單測時，由于缺少 Vitest 相關語料，無論怎么調整 Prompt，大多數(shù)時候都會返回基于 Jest 的測試代碼，而我更喜歡用 Vitest，所以每次都需要把代碼復制出來，一通調整后才能放入倉庫內運行；而在使用 Cursor 時，只要使用適當?shù)?Prompt，多數(shù)時候都能返回基于 Vitest 的結果，調整成本要小的多，例如我常用的 Prompt：

圖片

其次，經(jīng)常編寫單測的同學應該都有一個感受，就是為某個模塊從零到一編寫單測并不特別困難，麻煩的是后續(xù)的調整維護，因為你必須深入理解增量代碼對舊邏輯的影響，并據(jù)此調整存量單測。在過去使用 GPT 等工具時，面對這種增量場景通常只能把修改后的代碼全量粘貼入對話框，重新生成全量單測代碼，但這會導致過往對存量單測做的細微調整全部失效，需要重復這部分調整工作。

而使用 Cursor 后，問題被優(yōu)化了許多，我們可以使用 Cursor 專門針對變更內容生成單測，例如下面的 Prompt：

圖片

另外一個更實用的技巧是，Cursor 也支持通過 @ 符號引用某個 Git Commit，因此也可以針對某個 Commit 生成單測，例如下面的 Prompt：

圖片

不過實測下來，增量生成的單測質量相對全量生成還是會差一些，容易丟失上下文，或者添加多余的單測，因此還是有一些調試成本的，不過還是比使用 GPT 高效許多。

語言切換

在日常開發(fā)中，偶爾需要針對存量代碼做一些語言切換微調，例如將老項目的 Javascript 改寫為 Typescript，只需使用簡單的 Prompt：改寫為 Typescript，即可實現(xiàn)：

圖片

在上面的實例中，Cursor 根據(jù)函數(shù)體提煉出正確的參數(shù)類型，并且正確推斷出該函數(shù)的返回類型，雖稱不上完美，但相比手工操作已經(jīng)提效了許多，并且即使轉換結果又問題，也能通過 tsc 工具快速識別，因此非常建議面對類似場景的同學，優(yōu)先使用 Cursor 實現(xiàn)代碼轉換。

甚至，Cursor 還可以絲滑實現(xiàn)跨語言的轉換，例如從 Javascript 改寫為 Rust：

圖片

需要注意的是，這種場景下通常只是完成語法上的簡單轉換，底層調用的各類基礎接口還是需要手工調整，才能正確運行。

PS：還有另外兩種非常實用的場景：基于 JSON 生成類型描述、基于 JSON-Schema 生成類型描述，實測都很準確。

實現(xiàn) V0 版本

Cursor 的 Composer 面板非常適合用于實現(xiàn)功能的 V0 版本，例如：

圖片

雖然從專業(yè)程序員視角看，生成的結果可能比較粗糙，無法作為最終版本提交 —— 甚至有時候跑都跑不起來，但相對而言已經(jīng)節(jié)省了許多初始化項目、創(chuàng)建文件、編寫腳手架代碼等方面的時間。接下來，只需基于 V0 版本，按照個人的思維習慣不斷微調代碼，通常也就能完成一個完整功能的開發(fā)。

另外，體感上 Cursor 具有極強的學習能力，使用過程中似乎會不斷觀察你的編碼習慣，后續(xù)生成的代碼會越來越趨近你的編碼風格，代碼調整成本也會越來越低。

補充一個點：前期編寫 Prompt 雖然也需要花費一些時間，但這個過程本身也是在濾清自己的思路，對流程、設計、約束等想得更清楚一些而不是一上來就開始編碼，這樣反而更容易做對。

解決中等復雜度問題

Cursor 底層是非常典型的 Agent 架構，它并不是簡單調用 LLM 之后直接應用結果，在 Composer、Inline Prompt 等功能中會根據(jù)你給出的指令，做出基本的任務分析、拆分子任務、規(guī)劃等動作，之后結合豐富的上下文數(shù)據(jù)執(zhí)行多類子任務，合并產(chǎn)出最終結果。

圖片

這種執(zhí)行方式雖然有可能放大 LLM 隨機性帶來的不確定性，但也使得 Cursor 初步具備結構化思維模型，已經(jīng)有能力將一個復雜問題拆解為若干小問題，逐步求解，足以解決中等復雜度的綜合問題，日常畫個頁面，做個 CLI 工具，搭個工程腳手架，寫個常規(guī)算法等都不在話下，具體效果大家可以到各大自媒體平臺自行搜索，有太多人正在吹爆這個軟件，我就不啰嗦了。

值得一提的是，即使執(zhí)行這么多任務，Cursor 的性能依然非常可觀，特別是 Tab Completion ，我個人體感感覺基本可以在秒級內猜測出結果，并且準確率很高，相比市面上其他產(chǎn)品要好出非常多。

不過，即便如此，Cursor 依然很難直接解決復雜問題，例如開發(fā)一個成熟的商城小程序、做一個點餐系統(tǒng)等，有幾個方面的因素：

1. 自然語言表達力不足，很難在有限的 Prompt 描述清楚所有需求細節(jié)；
2. LLM 單次交互生成的 Token 數(shù)是有限的，多數(shù)時候無法滿足復雜需求所需的代碼量；

不過，Cursor 針對這種場景提供了一種非常不錯的解決方案 —— Composer，這個功能相對復雜，簡言之，你可以人為地將復雜任務拆解為若干小任務，之后在 Composer 面板中分多次發(fā)出指令，Cursor 會據(jù)此逐次生成多份文件，且文件之間關聯(lián)度較高，會互相引用消費，非常適合用于復雜功能開發(fā)。

Cursor 的短處

客觀的說，LLM 確實非常強大，給各類內容生產(chǎn)行業(yè)帶來了巨大想象空間，甚至稱之為新的技術奇點也不為過。不過，它還不足以完全代替人類，其底層實現(xiàn)邏輯已經(jīng)決定了它的能力極限只能達到或稍微超越人類總公開信息的平均水平。

Cursor 也一樣，它能極大提升代碼開發(fā)效率，但也存在許多缺陷與短板，當下不可能絲滑代替人類開發(fā)有復雜度的生產(chǎn)系統(tǒng)。雖然它確實能給出許多驚喜，但 LLM 推理過程的隨機性決定了它無法 100% 滿足功能、性能、可維護性、技術品味、向前向后兼容性等諸多工程需求，我認為它始終都只是一個“輔助編程”工具，人類智能才是編碼過程的主體。

隨機性

LLM 很強大，但它的本質其實就是概率計算 —— 根據(jù)上下文與模型本身的參數(shù)猜測下一個最可能“正確”的答案，既然是“猜測”就不可能做到像邏輯運算般嚴謹一致，上下文與 Prompt 的些微變化都可能引發(fā)蝴蝶效應導致完全不同的結果。雖然模型還在迭代發(fā)展，未來必然越來越穩(wěn)定，執(zhí)行越來越快，上下文也越來越長，但這種根子里的隨機性我認為是不可能消失的，而隨機意味著風險。

• 實現(xiàn)斐波那契數(shù)列

圖片

• 實現(xiàn)，斐波那契數(shù)列

圖片

僅僅在 Prompt 中加了一個“，”，生成結果就會發(fā)生很大變化

雖然人類智能也有極高的隨機性，但一個很大的區(qū)別在于，大部分活生生的人類都具備較強的自省與邏輯推導能力，有能力自行檢閱發(fā)現(xiàn)潛在問題，因而隨機性帶來的風險相對可控 —— 過往幾十年的軟件工程可都是人類智能發(fā)展起來的。而 LLM 并不具備這種自省糾偏能力，最終只能保證某種概率水平上的準確性，很難保證下次還能得到準確答案。并且，與文章、圖像等內容生產(chǎn)領域不同，軟件項目的容錯率非常低，任何一個細小錯誤都可能導致應用整體崩潰，或出現(xiàn)預料之外的細微錯誤。

這種隨機性導致的結果就是，雖然 LLM 能夠以極快的速度批量生成相對“合格”的代碼，但在嚴謹?shù)纳虡I(yè)環(huán)境中，工程師們還是需要花費許多時間調試 LLM 生成的代碼，確保與系統(tǒng)其他部件能兼容執(zhí)行，并且多數(shù)時候，還需要對代碼的多處細節(jié)做出微調，確保符合功能需求；需要花費時間理解這些代碼，Review 生成結果是否符合整體架構約束、風格約束等，確保長期可維護性，等等?？傊?，至少目前階段還是需要大量人力介入監(jiān)督，使用各類技術、非技術類方式方法保障代碼質量。

缺乏領域知識

網(wǎng)絡上有許多鼓吹關于 Cursor 的文章、視頻，在他們的表達中似乎 Cursor 已經(jīng)超越、替代人類，能夠像魔法一樣完成復雜應用的開發(fā)，可以做到《一行代碼不寫，讓 AI 幫我打工》。但我實際體驗這幾個月下來，感覺距離這個狀態(tài)還是比較遠的，一是 LLM 缺乏領域知識，很難解決特定領域里的具體問題；二是 LLM 并不具備結構化邏輯思維能力，無法將一個復雜任務拆解為若干子任務，逐步地、更穩(wěn)健地解決問題。

在我的使用過程中，有一個很強烈的感覺：即使我遵循 Prompt 工程的各類建議，花費許多時間精心編寫，多數(shù)時候也很難僅僅使用自然語言精確描述需求(我們更習慣使用代碼實現(xiàn))，進而 LLM 很難生成真正符合預期的代碼。這本質上是語言本身的表達力問題，在商業(yè)環(huán)境中，即使是同一團隊內部，相同領域背景下的產(chǎn)品與研發(fā)在溝通需求時也需要精心準備許多說明文檔，拉會溝通多次，從多個角度反復才能對齊需求細節(jié)，何況與并不太理解領域特定知識細節(jié)的大模型？說的更直觀點，LLM 很可能并不認識業(yè)務領域內特定代詞的具體含義，也沒有掌握某些特定歷史上下文信息，結果可能就是雞同鴨講，對開發(fā)者而言很難在有限的 Prompt 表達清楚所有上下文，對 LLM 而言有太多信息黑洞，兩邊無法完全對齊，也就無法順利完成業(yè)務需求開發(fā)。

舉個具體例子：“當用戶未通過 OAuth 登錄時，若點擊注冊按鈕，則彈框展示用戶說明書，并發(fā)送行為埋點到 B 平臺”，這里面 OAuth、注冊、彈框、埋點等都屬于開放知識，LLM 有相關語料知識的情況下都能理解的不錯，但：

• “用戶說明書”具體是什么？
• “B 平臺”是啥？具體如何上報埋點？
• 埋點的內容應該包含什么？
• 等等。

都屬于特定團隊領域內的私域知識，包含了太多細節(jié)，除非你能通過 RAG、Fine-Tune 等方式補齊這部分信息，否則 LLM 無法理解任務的具體實現(xiàn)方法，最終大概率也就生成類似下面這樣這種無法直接使用的結果：

圖片

不具備創(chuàng)造性

LLM 還有一個比較大的問題：缺乏創(chuàng)造性，這一點應該比較容易理解，從原理上講，LLM 就是大量收集公開資料，之后借助深度學習技術，尤其是神經(jīng)網(wǎng)絡中的 Transformer 架構，來捕捉語言中的復雜模式和語義關系，進而訓練出一套盡可能準確理解與生成自然語言的模型。

通俗地講，LLM 就像一個具有超高性能與智慧度的知識檢索工具，并且出廠時默認就自帶了海量互聯(lián)網(wǎng)公開資料，結果就是，當你提問的問題有對應的資料解釋時，它能非常好地生成答案，但超出其檢索范圍時，表現(xiàn)就會差很多，甚至出現(xiàn)所謂的“幻覺”。

當然，這一問題目前已經(jīng)有一個成熟的解決方案：Retrieval-Augmented Generation，可以簡單理解為通過向量數(shù)據(jù)庫給 LLM 外掛更多知識，LLM 在執(zhí)行時會同時檢索這些知識，從中推算出更接近特定領域的答案，這就使得 LLM 能夠被應用在各類具體業(yè)務領域中，適用性增強了許多。

但面對一些更深層次的問題，即使應用了 RAG 架構恐怕也很難解決，例如某些不甚知名框架，網(wǎng)絡上并沒有太多相關討論資料，并且你也無法提供相關知識時，LLM 就很難給出比較準確的答案，這是因為 LLM 本質上只是在做數(shù)學意義上的概率推算，但不具備復雜邏輯推導能力，無法基于新的語料推演出新的知識，缺乏人類智能的創(chuàng)造力。

舉個更具體的例子，當你編程過程遇到一些具體的 Bug，如果是前人研究過的點，并且在互聯(lián)網(wǎng)上詳細解釋了問題的原因與解決方案，那么 LLM 會表現(xiàn)的很好，直接給出最終答案；如果是框架的問題，但缺乏相關資料的，LLM 大概率無法給出解決方案，需要你深挖框架細節(jié)，自己找到答案；而如果是具體業(yè)務系統(tǒng)代碼本身的問題，LLM 基本是力不從心的，無法給出有價值的答案。因此，面對復雜而具體的問題時，依然還是需要人類智能出場。

最佳實踐

頻繁提交代碼

切記，LLM 始終是隨機的，無法保證下次執(zhí)行結果的正確性，在使用過程務必養(yǎng)成習慣頻繁提交代碼，方便出現(xiàn)問題時隨時回滾。我個人的操作習慣大致是：

• 使用 Cursor 各類面板生成代碼后，先做一遍簡單的代碼 Review，修改變量名、循環(huán)結構等基礎問題；
• 在軟件上下文中集成調試，初步驗證正確性后立即提交代碼；
• 審閱代碼設計，重點關注：函數(shù)輸入輸出結構、模塊導入導出內容、邏輯與循環(huán)分支處理等等，在這個節(jié)點通常會持續(xù)讓 LLM 按我的想法優(yōu)化代碼，或者自己上手做些小修改，迭代多次持續(xù)提交代碼，這個過程通常耗時最多；
• 代碼初步穩(wěn)定后，繼續(xù)讓 LLM 幫我生成單測代碼，這個階段通常需要迭代多次，提交多次，直至單測通過，覆蓋率達標為止；
• 功能代碼、測試代碼均準備就緒后，提交 PR 準備合碼；

這個過程中，每次調用 LLM 都可能得到不符合預期的結果，但只要基本達標我都會立即 Commit，后續(xù)遇到問題隨時 Revert 即可，雖然這會產(chǎn)生大量 Commit History ，但合碼前使用 Rebase 等操作調整歷史記錄即可。

重視 Code Review

其次，建議將更多時間精力放在 Code Review 上，因為 Cursor 生成的代碼可能是局部最優(yōu)，但可能因為缺失相對抽象的全局架構信息，而并不能做到全局最優(yōu)，例如重復編寫組件，或破壞某些約定俗成的架構規(guī)則等，日積月累同類代碼可能最終導致可維護性、可讀性都逐步劣化到無法繼續(xù)迭代的程度(公正點說，人類智能也會導致這類問題)。

因此非常建議重視建立嚴謹?shù)?Code Review 文化，理想情況應該是由 Cursor 生成盡可能多的代碼，盡可能代替人類完成編碼工作，再由人類智能負責驗證、審查這些代碼的合理性，保證結果正確且長期可維護。

更好的工程化體系

如前所述，Cursor，或者說 LLM 生成的結果是隨機的，無法保證每次都得到正確的結果，每次變更都有可能影響存量代碼的穩(wěn)定性，如果這些變更都必須由人類手動驗證，那么測試成本會搞起不下，測試環(huán)節(jié)會成為工程中新的效率卡點。

更好的方式，應該是投入更多精力建設更穩(wěn)健的工程化體系(這部分需求也可由 Cursor 輔助實現(xiàn))，使用自動化工具代替人力完成諸多基礎質檢任務，例如引入 UT/E2E 完成運行質量測試，CI/CD 中加入 TS 類型檢查、ESLint 風格檢查等保證代碼質量，等等。重點在于，使用更高效、成本更低的方式不斷驗證 AI 產(chǎn)物質量，更敏捷地應對變化，具體策略可參考我之前的文章：

• 《前端工程化系列一：序言》
• 《前端工程化系列二：編碼提效》

此處不再贅述。

使用 AI 友好的技術棧

在使用 Cursor 或其他同類輔助編程工具時，應盡可能選用各類 AI 友好的技術棧，以前端為例，如：Tailwind 優(yōu)于原生 CSS/Less 等；Typescript 優(yōu)于 JavaScript、CoffeeScript 等；React 或 Vue 等 MVVM 框架優(yōu)于原生 JS + HTML + CSS；GraphQL 優(yōu)于 Restful 等。

為什么技術棧之間會出現(xiàn)這種差異呢？關鍵在于 LLM 底層是基于概率推導實現(xiàn)內容生成的，結果好壞取決于模型質量、訓練語料、上下文完整度、Prompt 等諸多因素，單就輔助生產(chǎn)代碼這一任務而言，LLM 對技術棧的理解越充分必然效果越好；代碼結構越聚焦，推導時信息噪音越低，結果也會越好；業(yè)務實現(xiàn)中的特化場景越少，通用規(guī)則越多，LLM 需要理解的內容越少，效果通常也會越好；等等。

基于這些維度，我個人總結了幾類簡單規(guī)則可用于輔助評估某種技術棧是否更適用于 AIGC 場景，包括：

• 社區(qū)熱度：社區(qū)越繁榮，意味著使用者越多，相關的技術討論、技術資料也必然越豐富，LLM 訓練或執(zhí)行時所能索引的信息就越完整，那么也就越容易推導出較好的結果。舉個例子，假設你工作中遇到了某個非常具體而棘手的問題，若剛好有人也遇到過，并將該問題形成的底層原因、解決方案整理成文章并發(fā)布到互聯(lián)網(wǎng)上，若 LLM 運行時能檢索到該文章，則可以基于文章內容推導給出最終解決方案；若網(wǎng)絡上沒有這類信息，考慮到 LLM 并不具備復雜邏輯推理能力，那么大概率無法給出有效的解決方案。
• 結構化：技術棧本身的結構化、模塊化水平越強，則其信息表現(xiàn)形式越是聚焦，越容易被 LLM 正確推導。比如，原子 CSS(如 Tailwind) 就是一個很好的例子，原生 CSS 是通過具體的屬性的鍵值對表達頁面元素的視覺效果，而原子化 CSS 則是通過原子類名表達某類樣式規(guī)則集，信息更聚焦更容易被 AI 理解；并且受層疊規(guī)則影響，使用原生 CSS 時，元素樣式可能受全局、祖先級元素、多種選擇器等層級的樣式規(guī)則影響，這對 LLM 而言意味著具體信息分散在項目的多個角落，需要消費、理解更多上下文才能推導出正確的結果，相對而言原子化 CSS 框架下，大部分樣式信息都聚焦在元素對應的 Class 列表上，信息高度聚焦，推理成本更低，結果也會更可靠。
• 通用規(guī)則優(yōu)于特化設計：技術棧的設計規(guī)范越是通用，則越容易被 LLM 理解，也就越是適用于 AIGC 場景。例如，GraphQL 明顯優(yōu)于 Restful，因為 GraphQL 提供了一套用于描述實體 + 實體關聯(lián)關系的通用語言規(guī)則，足夠用于表達絕大多數(shù)數(shù)據(jù)存、取、刪、改等常規(guī)業(yè)務操作，因而對 LLM 而言只需理解這套通用語言規(guī)則，配合具體業(yè)務領域中的實體與實體關系即可基于 GraphQL 靈活編寫出各類數(shù)據(jù)操作邏輯；而 Restfull 規(guī)范則更多聚焦在實體上，除幾種基礎的數(shù)據(jù)操作外，涉及復雜數(shù)據(jù)結構場景時，出于實用性、性能等角度考慮，通常不得不特化設計、特化開發(fā)，而這些特化處理對 LLM 而言會顯得過于具體，相應的上下文復雜度與噪音也會更高，也就更難以推導出正確的答案。
• 自動化質檢：技術棧的質檢工具越強大，則能夠越早、越全面地發(fā)現(xiàn)質量問題，進而更能低效 LLM 隨機性帶來的質量風險，也就更適用于 AIGC 場景了。例如，Typescript 之于 JavaScript，前者具有更強的類型聲明系統(tǒng)，因此在靜態(tài)代碼分析階段即可找出諸多類型不匹配問題，那么即使 LLM 生成了類型不匹配的代碼，也能夠在運行代碼之前發(fā)現(xiàn)問題，糾錯成本要低很多。

當然，上述規(guī)則僅僅是我的一家之言，隨著大模型的迭代發(fā)展，具體規(guī)則后續(xù)必然還會新增或刪改，這不重要，重要的是非常建議讀者后續(xù)在做技術選型時，不要只是基于個人 or 團隊喜好做決定，應該更多考慮技術棧對 AI 的適用性，甚至可以以此為首要原則，盡可能選用對 AI 友好的技術與工具，使得 LLM 更好、更準確地輔助完成各類開發(fā)任務，充分融入到日常工作中，提升個體與團隊的整體效率。

降低預期

對，標題沒寫錯，你需要降低預期！前面也說過幾次，LLM 并不是魔法，它有幻覺，有知識漏洞，有隨機性，不擅長解決復雜問題，有各種各樣的缺點，從我的使用經(jīng)驗來說，多數(shù)時候它還遠沒有達到我預期的狀態(tài)，需要我參與到各種代碼細節(jié)中。

例如，生成單測通常都跑不通，需要各種修改微調測試；生成的文檔可能也會缺失某些重要內容，需要調整 Prompt 后多次重試，才有可能達到預期效果；生成的代碼，即使在 Cursor 各種上下文引用能力的加持下，也經(jīng)常會在細節(jié)處犯錯，導致執(zhí)行失敗。以 LLM 的底層實現(xiàn)邏輯來說，這些結果都太正常不過了。

因此，建議降低對 Cursor 或者其他 LLM 工具的預期，它并不是魔法，無法完全代替人類智能，當下你還是需要認真做好導演角色，引導 Cursor 更準確更好地解決你的問題，認真研讀理解倉庫已有的代碼與 LLM 生成的代碼。更進一步的說，你自身還是需要有比較強的技術能力，理解各類技術底層細節(jié)，才能及時發(fā)現(xiàn)、修復問題。某種程度上，Cursor 就像一把刀，它的鋒利程度取決于你自身的功力。

寫在后面

最后嘮叨幾句，這幾個月試用下來，Cursor 雖稱不上完美，但它確實能完成許多基礎而重復的任務，讓我把注意力更多聚焦在業(yè)務、架構等高緯度，而不必過多關注具體細節(jié)；能夠在我遇到知識盲點的時候提供真正有意義的提示與幫助；能幫我完成許多重復、低級任務。這不是玩具，而是真正提升開發(fā)效率的生產(chǎn)力工具，是我用過最好的 AI 輔助編碼工具，強烈建議讀者也上手試試。