Kerwin AI Information

標籤: 開發效率提升

  • Cursor Composer 2.5：平價 GPT-5.5 程式助手？

    Cursor Composer 2.5：平價 GPT-5.5 程式助手？

    📌 本文重點

    • Composer 2.5 以更低成本提供接近 GPT‑5.5 / Opus 的程式能力
    • 深度整合 Cursor，可做跨檔與整庫重構
    • 適合接手 70% 可驗證的日常開發任務，替代昂貴模型

    只要用 Cursor 選擇 Composer 2.5，你就能用接近 GPT‑5.5 / Opus 等級的程式助理處理日常開發工作，但花更少的錢。

    參考：Cursor 官方 X 貼文、The Decoder 報導

    核心功能：為什麼說它是「低成本高性能」

    1. 基於 Kimi K2.5，對準「寫程式」這件事

    Composer 2.5 建在 Kimi K2.5 模型上，Cursor 官方說明它在訓練時加入了 比前一代多 25 倍的合成任務（synthetic tasks），重點就是：

    💡 關鍵： 多 25 倍合成任務，代表模型在「讀／寫／改程式碼」這類可控任務上被專門強化，而非泛用聊天。

    • 訓練內容更聚焦在「寫程式、改程式、讀程式」這三件事
    • 對多檔案專案、跨語言呼叫（例如 Python + TypeScript）理解更好
    • 對「先看懂再動手改」的任務（重構、查 bug）特別有幫助

    你可以做的事：

    • 把舊專案整個丟進 Cursor workspace，直接問：

      「幫我概述這個專案的資料流，從 API 到 DB。」

    • 預期它對跨檔案邏輯的掌握會比一般純聊天模型更穩定。

    2. 性能接近 GPT‑5.5 / Opus 4.7，但成本更低

    根據 The Decoder 報導，Composer 2.5 在多項基準測試中 接近 GPT‑5.5、Anthropic Opus 4.7 的程式能力，但使用成本卻只要一小部分。

    💡 關鍵： 以「一小部分成本」換到接近 GPT‑5.5 / Opus 水準的程式能力，意味著同樣預算可以支撐更多開發量與更多輪迭代。

    實際體感上，你會得到：

    • 長對話與長檔案表現穩定：不容易「忘記前文」，適合大專案
    • 生成程式碼較少離題：CRUD / API 類需求比較不會「寫歪」
    • 多輪修改成本可控：不用每次都叫 GPT/Claude 出來燒 token

    你可以做的事：

    • 把日常「寫 API、修小 bug、重構單檔」改用 Composer 2.5；
    • 把「產品需求討論、架構設計」這類高風險決策，才交給 GPT‑4.1 / Claude，節省昂貴模型的用量。

    3. 深度整合 Cursor IDE：跨檔讀寫、整庫重構

    Composer 2.5 是為 Cursor 量身調校的模型，搭配 IDE 使用，可以：

    • 跨檔案查找與修改：一次改一整個 feature 涉及的檔案
    • 支援多語言專案：例如前端 React + 後端 Node + Infra IaC 同時理解
    • 直接在側邊欄展示 diff：你可以逐行檢查 AI 提案再決定要不要套用

    你可以做的事：

    • 在專案根目錄使用「Composer」面板，下指令：

      「在不破壞現有 API 行為的前提下，把整個 user 模組改成使用 repository pattern，並維持測試通過。」

    適合誰用？三個具體場景

    1. 日常 CRUD / API 寫作 & 重構舊專案

    典型需求：

    • 寫 RESTful API / GraphQL resolver
    • 加上簡單驗證 / 分頁 / 排序
    • 把舊的 callback / promise code 改成 async/await

    在 Cursor 編輯器中，你可以這樣用：

    1. 選取一段老舊程式碼，按 Cmd+K（或右鍵選 AI Command）。
    2. 輸入 prompt：

      「重構這段程式碼：改用 async/await，避免重複邏輯，並維持現有行為不變。」

    3. 檢查 diff，如果 OK 就套用。

    小技巧：對整個檔案重構可用：

    「重構這個檔案並維持測試通過，不要改動對外 export 的介面名稱。」

    — 這句話能提醒模型「不要亂改對外 API」，減少你後面修爆錯誤。

    2. 搭配 Cursor 做「整庫重構」與大規模查改

    當你需要：

    • 把整個專案從 Express 換成 Fastify
    • 把所有 any 慢慢補成正確 TypeScript 型別
    • 把一堆散落函式集中到 service class

    Composer 2.5 的用法會是：

    1. 在 Cursor 開啟專案，確保整個 repo 都在 workspace。
    2. 打開 Composer 面板（左側「火箭」圖示），選擇 Composer 2.5 模型。
    3. 下指令：

      「在整個專案中，將所有 express 相關使用改成 Fastify，保留 API 路徑與回應格式，並更新相關型別定義。每一組改動請分開 commit 欄位說明。」

    Cursor 會：

    • 找出相關檔案
    • 給出一組可檢查的改動

    搭配 git 避免「一鍵改爆」：

    建議流程：

    1. 新開分支
      bash
      git checkout -b refactor/use-fastify
    2. 每次只讓 Composer 改一小塊（例如一個模組、一個資料夾）。
    3. 跑測試再 commit：
      bash
      pnpm test # 或 npm/yarn
      git add .
      git commit -m "refactor: migrate auth module to Fastify"
    4. 改壞了就 git restore . 或 git reset --hard 回到上一次測試通過的點。

    3. 用它取代部分 GPT / Claude 編碼任務，降成本

    你不需要把 GPT / Claude 整個換掉，而是：用 Composer 2.5 接手「可預測、可驗證」的程式任務。

    💡 關鍵： 把約 70% 可驗證的編碼工作交給 Composer 2.5，可在不改工作流程的情況下顯著壓低高價模型帳單。

    適合交給 Composer 2.5 的任務：

    • 寫 CRUD / API handler
    • 轉寫語言（Python ↔ Node、JS ↔ TS）
    • 單檔重構、加 log、補型別
    • 根據錯誤訊息嘗試修 bug（你再跑測試驗證）

    保留給 GPT / Claude 的任務：

    • 探討產品需求、技術決策
    • 大型架構設計、權衡方案
    • 需要多領域知識的解題（例如演算法 + 數學 + 故事情節）

    實作建議：

    • 在 Cursor 預設模型選 Composer 2.5，讓日常操作都走它
    • 只有在遇到明顯超出範圍的需求，再手動切換到 GPT‑4.1 / Claude

    這樣你可以在不改變工作習慣的情況下，實際降低高價模型用量。

    怎麼開始：3 分鐘完成安裝與設定

    1. 安裝 Cursor 與建立 Workspace

    1. 前往官網下載 Cursor：https://www.cursor.com
    2. 安裝後登入（支援 GitHub / Google 帳號）。
    3. File → Open Folder 打開你的專案，Cursor 會自動建立 workspace。

    建議：第一個試驗專案先選有測試的 repo，方便驗證 AI 修改的結果。

    2. 選擇 Composer 2.5 模型

    1. 在右上角模型選單中，選擇 Composer 2.5。
    2. 在聊天視窗 / Composer 面板，都可以確認當前使用模型名稱。

    之後你在：

    • Cmd+K 觸發的 inline 指令
    • 側邊欄聊天
    • Composer「在整個專案上操作」

    預設都會走 Composer 2.5（除非你手動切換）。

    3. 實用 prompt 模板：直接複製就能用

    下面幾組可以直接貼在 Cursor 裡，記得根據專案語言調整細節：

    1. 單檔重構 + 保證測試

      「重構這個檔案並維持測試通過：
      1. 保留對外 export 的 function 名稱與參數型別；
      2. 移除重複邏輯，適度抽取 helper；
      3. 將 callback 風格改為 async/await。」

    2. 新增 CRUD API

      「在這個專案的風格下，為 Article 資源新增 CRUD API：
      – 使用現有的 router / controller 架構；
      – 套用與 User 相同的驗證與錯誤處理方式；
      – 寫對應的單元測試並保持現有測試通過。」

    3. 全專案查改 + 小範圍提交
      在 Composer 面板：

      「在整個專案中，把所有 console.log 改成使用既有 logger（src/lib/logger.ts），
      每次只修改單一 module，並清楚標註將被修改的檔案清單。」

    搭配 git 分支與測試，你可以逐步、安全地享受「整庫 AI 重構」，而不是被「一鍵改爆」。

    小結：Composer 2.5 值得你怎麼用？

    • 當作「日常程式夥伴」：CRUD / API、重構舊檔案全部交給它
    • 搭配 Cursor 做跨檔案重構與查改，善用 diff + 測試守門
    • 把昂貴的 GPT / Claude 留給真正需要高思考密度的任務

    如果你已經在支付 OpenAI / Anthropic 的帳單，現在就試著把一週內 70% 的程式任務改交給 Cursor 的 Composer 2.5，實際比較「完成同一個需求時的成本差」，你會更清楚它在你的團隊裡能省下多少錢。

    🚀 你現在可以做的事

    • 下載並安裝 Cursor，建立一個有測試的專案 workspace 試跑 Composer 2.5
    • 在 Cursor 將預設模型改為 Composer 2.5，挑一個舊模組交給它重構並用測試驗證
    • 往後一週刻意記錄「同一類任務用 Composer 2.5 vs GPT/Claude」的實際 token 與時間成本差異