一、前言

在寫作過程中，我受益于若干優秀的博客分享，它們給予我寶貴的啟發：

• 《5分鐘選對AI編輯器，每天節省2小時開發時間讓你早下班！》：https://mp.weixin.qq.com/s/f0Zm3uPTcNz30oxKwf1OQQ

二、AI編輯的代表

關于AI編輯器的種類和選擇，目前我挑選出來有代表性的三種類型的編輯器

1、Cursor

• Tab獨一檔的存在
• 中型項目可以

2、Agument

• 架構設計很特別

  • 上下文理解能力：在處理大型項目時表現最為出色
  • ACE引擎：上下文理解能力更強，可以理解更復雜的上下文
  • 項目記憶：可以記住項目AI生成的聊天記錄，方便后續回顧。
  • 使用限制較少：相比其他工具的各種限制，使用比較流暢

• 大型項目可以

3、Claude Code

• 是終端cli，無Tab
• 所有項目都可以，效果很不錯

三、使用場景分析

場景一、后端開發和算法優化

在后端開發的過程中，業務邏輯的梳理編寫是最為主要的，編寫健壯且邏輯安全的代碼。開發者在AI編輯器使用上有兩種選擇

第一種：如果復雜的業務邏輯想完全交給Agent或大模型來實現的話，那或許Agument和Claude Code更合適，因為它能獨自獲取到更多且有用的上下文能力

第二種： 如果自己和o3或Genimi 2.5pro等高級模型先梳理一下大概的業務邏輯，這樣的話你自己是有一個清晰的上下文的，對于這個需求的開發，從某種程度上來說可以降低對編輯器的要求，Cursor、ClaudeCode+K2、rooCode+Genimi2.5Pro等，或許都可以考慮一下

場景二、大型項目和架構設計

當代碼量達到萬行以上，普通的工具被上下文限制，上下文中的相關信息變得“模糊”，這個時候大模型拿到的上下文大部分都可能是對問題的解決沒有幫助的，還空耗費Token，一般這種情況的限制大概有兩種（模型上下文的限制、AI編輯器本身索引能力的限制），以下三款工具可以考慮Augement、ClaudeCode+Claude

四、模型能力評估

以下的評估是我結合自己的使用經歷+一些分析博客整理的，經供參考！！

4.1、模型開發能力

第一梯隊：Claude 4、O3、Claude3.7、Genimi2.5pro

第二梯隊：Claude3.5、DeepSeekR1、K2

第三梯隊：GPT-4o、DeepSeekV3

4.2、UI能力

第一梯隊：Claude4、O3、Claude3.7

第二梯隊：DeepSeekV3、Claude3.5、DeepSeekR1

第三梯隊：Gemini2.5Pro

第四梯隊：GPT-4o

五、AI編碼工具的關鍵點

其實一個AI編碼工具是否好用，有如下幾點的占比分析

• 能檢索到最大上下文是多少 - 最大性（10%）
• 檢索功能相關上下文是否準確 - 準確性（40%）
• 能使用到的模型能力是多少 - 模型能力（50%）

我們在編碼的過程中，就是在解決一個一個問題， 本身最關鍵的只有兩點對于模型來說：

1. 上下文的精準性和相關性
2. 模型自身的推理能力和理解水平

5.1、上下文的精準性和相關性

關于上下文的精準性和相關性有兩種說法：

第一種是：極致暴力美學

第二種是：靈巧優雅美學

這兩種方式就像在圖書館找一本書，有的人會直接一本一本書的對比找，而有的人會利用索引，定位區域，定位書架，縮小范圍的找

還有點像你喜歡吃魚，你要獲取魚，有點人會直接選擇抽干水，有的人則會選擇技法釣魚

所以從這個角度出發，模型廠商提高上下文限制是有意義的，但不是必要的，模型更應該提高推理、理解等真正的底層能力

我們假設一下智能時代的到來，智能可以解決一個現實的問題，難道要暴力的將世界信息塞入分析嗎？

我覺得當然不行，應該塞入相關的記憶即可，這便是工程化的意義，這個領域才是工程化應該大展身手的地方，這個時代是很需要工程創新的能力的

但是不可否認，適當的增強模型的上下文是需要的，但是不可一味的追求，這不是長久之計

六、分析總結

經過上述的分析，我們可以得出一個公式出來或者說是一個模型出來

我自己還根據自己的使用經歷，給出自己理解的大概范圍的波動影響，以下是一個不太嚴謹的數據分析

上圖是一張問題難度x模型能力x上下文準確性之間，其中一個升降如何影響其他兩個的

• 橫軸：模型能力，從0（很弱）到10（很強），越右代表模型越聰明

• 樅軸：上下文準確性，從0（粗糙）到10（精準），越上代表喂給模型的背景越嚴謹

• 曲線：問題的等勢線

  • 問題難度（高）：要想搞定這類的硬茬，組合點必須落在實線之上
  • 問題難度（中）：要解決這類問題，只有點落在實線之上，才可能輕松解決

在問題難度高的情況下，模型能力必須要大于4-5左右，太“笨”的模型，上下文再相關都是無事于補

在問題難度低的情況下，或許對于模型能力要求不高，但是上下文不太無關，牛頭不對馬嘴

所以都是會有一個閾值出現的，或許我理解的這個閾值是不太準確的，但是我確定的是一定會有

所以大家可以結合自身的想法和情況來選擇AI編輯器，沒有最好的，只有適合自己才是最好的， 我之前看一本小說，雪中悍刀行中的江湖中，沒有最強的人，只有最強時，這個時間這個人才是最強的

🍻 如果你是一位只想快速構建項目原型，或者快速高效的解決這個需求的開發者，那么選擇工具要站在模型能力強，編輯器能準確檢索足夠相關的上下文

🍻 如果你是一位成長型的開發者，想自己參與需求的開發，想足夠掌握自己代碼，那么你的選擇工具范圍目前會很大，模型方面你可以考慮中等模型即可，編輯器檢索能力中等，不過最重要的你需要一位“經驗十足”的模型和你配合，例如：O3、Genimi2.5Pro

七、一點看法

我很欣賞Kiro，原因是它為開發者與模型在上下文整理檢索方面都提供了一個共同的操作空間

開發者研發一個項目會因時間產生一系列的研發行為，這組成了這個需求的研發記憶，今天研發了多少功能，或者該功能研發多少時間，這個功能的設計和具體的邏輯是如何的

之前大家只能通過散亂的記憶整理，思考閱讀，但是現在開發者與模型都有一個文檔空間，對雙方都友好，模型適合檢索，開發者適合閱讀回憶，甚至間接的降低了問題的難度的閾值