Kerwin AI Information

標籤: Cursor

  • Graphify：讓 AI 助手看懂整個專案

    Graphify：讓 AI 助手看懂整個專案

    📌 本文重點

    • Graphify 把整個專案轉成可查詢的知識圖譜
    • 讓 Claude Code、Cursor 等助手理解「整個系統」而非單檔
    • 特別適合接手專案、Code review、排錯與重構場景

    Graphify 就是替 Claude Code、Cursor 等 AI 編碼助手建立專案的知識底層，把程式碼、SQL、腳本、文件通通轉成可查詢的圖譜，讓 AI 回答不再只看單檔，而是理解整個系統。

    專案連結：Graphify-Labs/graphify（GitHub）

    核心功能：把「專案」變成可對話的地圖

    1. 把任何專案資料夾變成知識圖譜

    Graphify 支援：

    • 程式碼：Python、JavaScript 等一般 repo
    • 資料庫：SQL schema
    • 腳本：R、shell scripts
    • 文件：docs、論文
    • 多媒體：圖片、影片（以檔案與路徑資訊的形式收錄）

    實際可做的事：

    1. 選一個專案資料夾，例如 ~/projects/legacy-crm
    2. 讓 Graphify 掃描後生成知識圖譜
    3. 把「圖譜」接到你的 AI 助手，開始用自然語言查專案

    效果：你可以問 AI：

    • 「這個專案所有跟訂單狀態相關的函式和 SQL 表有哪些？」
    • 「從 API 收到請求到入庫，整個流程經過哪些檔案？」

    行動建議：先挑一個你覺得難接手的專案，當作 Graphify 的第一個練習對象。

    2. 一次整合：程式碼 + DB schema + 基礎設施

    Graphify 強調的是「整個系統放進同一張圖」：

    • App code：API、service、models
    • Database schema：tables、relations
    • Infrastructure：scripts、部署設定、CI/CD

    這意味著 AI 助手不只看到某個函式，而是可以沿著圖譜一路追：

    • 「這支 API 最後寫進哪個資料表？」
    • 「這張資料表在哪裡被讀取／更新？」
    • 「這個 Cron job 觸發哪些腳本，再改變哪些表？」

    💡 關鍵： 把代碼、資料庫與基礎設施放進同一張圖，才能讓 AI 追蹤完整的請求與資料流向。

    行動建議：如果你常在大型專案裡迷路，優先把 App code + DB schema 一起餵給 Graphify，請 AI 幫你畫出「從前端到資料庫」的完整路徑。

    3. 支援主流 AI 編碼助手與本地模型

    Graphify 自稱是「AI coding assistant skill」，專門替各種助手提供專案知識底層，目前支援：

    • Claude Code
    • Cursor
    • Codex / OpenCode
    • Gemini CLI
    • 以及其他可透過 CLI / API 串接的助手

    好處是：你不用換開發工具，只是多了一層「專案圖譜」，讓原本的 AI 助手變得更懂上下文。

    行動建議：先選一個你已經在用的助手（例如 Cursor），只做一件事：把 Graphify 生成的圖譜加進你的 Prompt 或工具設定，看 AI 回答專案問題的精準度差異。

    適合誰用：3 個具體場景

    1. 接手大型專案：用 Graphify 做「三小時系統導覽」

    接手舊專案最常遇到：

    • 文件缺失
    • 系統邏輯分散在各層
    • 找不到「這個功能到底怎麼跑」

    操作範例：

    1. 從 Git 拉下專案：

    bash
    git clone <your-legacy-repo>
    cd <your-legacy-repo>

    1. 用 Graphify 掃描整個 repo，生成圖譜（假設有 CLI 指令 graphify scan）：

    bash
    graphify scan . -o graph.json

    1. 在 Claude Code 或 Cursor 裡，附上 graph.json（或指向 Graphify server），向 AI 提問：
    2. 「列出與『會員等級計算』相關的所有檔案與流程，並畫文字流程圖。」
    3. 「說明訂單取消從 API 到資料庫寫入的完整路徑。」

    行動建議：把你接手的新專案都跑一次 Graphify，強制自己在第一天就用 AI 做一輪「系統導覽問答」。

    2. Code review：從「看單檔」變成「看整條影響路徑」

    傳統 Code review 很容易只盯著 diff，看不到改動在整個系統的影響。

    用 Graphify 的方式：

    1. 在 PR 對應的分支跑 graphify scan，生成該版本的圖譜。
    2. 在 AI 助手裡，輸入：
    3. 「這個 PR 修改的函式，影響到哪些上游呼叫點與下游資料表？」
    4. 「幫我列出這個改動所有可能破壞的流程。」

    AI 可以沿著圖譜追蹤呼叫鏈、資料流向，給你一份「改動影響報告」，你再決定要多測哪些地方。

    💡 關鍵： 利用圖譜讓 AI 做「改動影響分析」，可以系統性找出需要回歸測試的區域，而不是只憑經驗猜。

    行動建議：選一個你覺得風險高的 PR，讓 Graphify + AI 助手一起做一次「影響分析」，當作試驗。

    3. 排錯與系統重構：先畫圖，再動手

    排錯時最痛苦的是：

    • 找不到錯誤在哪條鏈路上爆
    • 重構時不敢動，怕牽一髮動全身

    Graphify 的知識圖譜可以幫你：

    • 快速列出某個錯誤堆疊涉及的所有節點（檔案、函式、表）
    • 在重構前問 AI：「我要拆分 user_service，請列出所有依賴它的模組與路徑。」

    實戰問句示例：

    • 「根據圖譜，payment_timeout_error 這個錯誤從觸發到記錄經過哪些模組？幫我列出路徑。」
    • 「如果我要把 orders 表拆成兩張表，請告訴我所有讀寫 orders 的程式碼位置。」

    行動建議：下一次遇到棘手 bug，不要先改碼，先用 Graphify + AI 把「錯誤路徑」問清楚，再決定從哪個節點下手。

    工具與助手比較：怎麼搭配使用？

    以下是 Graphify 與常見 AI 編碼助手的定位差異與搭配方式：

    名稱 核心功能 免費方案 適合誰
    Graphify 專案知識圖譜；整合代碼、DB、腳本等 開源，GitHub 可用 想讓 AI 助手「看懂整個專案」的人
    Claude Code 雲端 AI 編碼助手，強自然語言理解 有免費使用額度 想用對話方式改碼／理解代碼的人
    Cursor VS Code 風格編輯器 + AI 補全與聊天 有免費方案 想把 AI 深度融入 IDE 的工程師
    Gemini CLI Google Gemini 命令列助手 有免費配額 喜歡在終端機用 AI 的開發者

    行動建議：先選一個你主要的開發環境（例如 Cursor），再把 Graphify 當成「增強模組」接上去，而不是全部一起嘗試，降低學習成本。

    怎麼開始：從 GitHub 到「可用工作流」

    官方入口：https://github.com/Graphify-Labs/graphify

    以下示範兩個「從零到可用」的最短路徑，以你已有的開發工具為中心來設計。

    工作流 1：接手專案 + Claude Code 問答

    步驟一：安裝與掃描專案

    1. 安裝（假設使用 Python pip，依實際 README 為準）：

    bash
    pip install graphify

    1. 進入你的專案目錄，掃描並輸出圖譜：

    bash
    cd ~/projects/legacy-crm
    graphify scan . -o graph.json

    步驟二：把圖譜交給 Claude Code

    1. 在 Claude Code 裡開啟專案，將 graph.json 上傳或貼到系統提示（System Prompt），例如：

    「你可以使用以下專案知識圖譜回答問題。請依圖譜中的檔案關係、表結構與腳本依賴，協助我理解和修改系統。」

    1. 問第一組問題：

    2. 「請整理出『會員等級計算』相關的所有模塊與資料表。」

    3. 「依據圖譜，畫出從前端呼叫到 DB 的完整流程（文字版即可）。」

    做到這一步，你就完成了：接手專案 → 建立圖譜 → 用 AI 做系統導覽 的基本工作流。

    💡 關鍵： 把圖譜丟給 AI 之後，每一個新問題都在累積你對整個系統的結構化理解。

    工作流 2：Cursor 裡做 Code review 影響分析

    步驟一：在 PR 分支生成圖譜

    1. 切換到 PR 對應分支：

    bash
    git checkout feature/new-pricing

    1. 跑 Graphify：

    bash
    graphify scan . -o pr-graph.json

    步驟二：在 Cursor 裡使用圖譜

    1. 打開 Cursor，載入這個專案，並在 AI 設定中把 pr-graph.json 放進系統提示，說明：

    「這是目前分支的專案知識圖譜。做 Code review 時，請根據圖譜分析改動的上游呼叫和下游資料影響。」

    1. 在看 diff 的同時詢問 Cursor：

    2. 「這次修改的 calculate_discount 函式，上游有哪些呼叫者？下游有哪些寫入或查詢動作？」

    3. 「依據圖譜，列出最需要回歸測試的 5 個功能。」

    這樣你就有一套：看 diff → 問圖譜 → 寫測試計畫 的 Code review 工作流。

    行動建議：先把上述其中一個工作流完整跑一次，感受「AI 從看單檔」變成「看整個系統圖」的差異，再決定要不要把 Graphify變成團隊標準工具。

    小結：把 AI 助手升級成「系統顧問」

    Graphify 的本質，是幫你的 AI 助手補上一層「專案整體結構」：

    • 不再只依靠目前開啟的 1–2 個檔案
    • 而是能沿著代碼、資料庫、腳本和設定，追到整條路徑

    如果你已經在用 Claude Code、Cursor 這類助手，下一步值得做的事，就是讓它們不只會寫函式，而是真的看懂你的系統——Graphify 正好是那一層缺少的底座。

    🚀 你現在可以做的事

    • 到 Graphify GitHub 把專案 clone 下來並跑一次 graphify scan
    • 挑一個現有專案，把產生的圖譜接到你最常用的 AI 助手（如 Cursor 或 Claude Code）
    • 在下一次接手專案或處理高風險 PR 時，用 Graphify + AI 做一次完整的系統導覽或影響分析
  • SpaceX 6000 億買 Cursor：不是買編輯器，是買未來入口

    SpaceX 6000 億買 Cursor：不是買編輯器，是買未來入口

    📌 本文重點

    • SpaceX 以基礎設施思維收購 Cursor，控盤 AI 開發入口
    • Cursor 將成為 SpaceX 內部軟體與 AI 代理平台的核心入口
    • 企業與開發者若不掌握開發入口，將淪為他人平台上的插件

    這不是一筆誇張的 acquihire，而是一次對「AI 開發入口」的控盤戰。當 SpaceX 剛以 2.6 兆美元 市值上市，轉身就拿出 600 億美元股票收購 Cursor，真正要買的不是「更聰明的 VS Code 插件」，而是未來十年 AI 工程基建的門口。從現在起，寫程式這件事，正被當成一條可以像火箭、衛星一樣被「垂直整合」的基礎設施。

    💡 關鍵： 用 600 億美元股票收購 Cursor，是在用資本直接鎖定「AI 工程基建入口」，而不是單純買一個工具。

    為什麼不是 xAI、而是 SpaceX 出手？——這是一筆基礎設施收購

    很多人第一個疑問是：AI 編輯器不是應該由 xAI 買嗎？為什麼掛在 SpaceX 底下？

    這裡有三層現實考量：

    1. 資本市場敘事：
    2. SpaceX 剛 IPO、市值衝到 2.6 兆美元，股價高、股票當貨幣最好用，600 億美元「全股交易」幾乎不傷現金流。
    3. 同一時間，根據 Epoch AI 分析，微軟、亞馬遜、Google 等 hyperscaler 的 AI CapEx 正以 70% 年增長，現金流只長 23%，資本壓力已經顯性化。

    4. 馬斯克很清楚：AI 戰爭後半場比的是資本結構與敘事能力。把 Cursor 裝進 SpaceX，而不是放在還沒完全變現的 xAI，會讓「SpaceX = 火箭 + 衛星 + AI 平台」這個故事在華爾街更好賣。

    5. 基礎設施思維，而非單點產品：

    6. OpenAI 買雲端 IDE Ona 的邏輯，是要讓 Agent 有自己的「雲端工作空間」，不受使用者電腦與線上時間限制。
    7. 馬斯克做的是更激進的一步：直接把「寫程式」本身視為公司級基礎設施，掛在做火箭的同一個資產負債表上，而不是當作一個 AI SaaS 生意。

    8. 這在形式上看起來怪異，本質上卻是：把 AI 研發、嵌入式軟體、地面系統到星鏈網路的一切開發工作，全部注入同一個 AI 加速層。

    9. 對 hyperscaler 的戰略側翼：

    10. OpenAI / Anthropic / Google Cloud / AWS 的主戰場，依然是「雲端 + 模型」租賃模式，賺的是 GPU 時間與 API 調用。
    11. SpaceX 則是「用得越多、賺得越多」的硬體 + 網路公司：火箭發射、衛星建置、Starlink 帶寬，這些成本是實打實的 CapEx。
    12. 如果它能透過 Cursor 把軟體開發效率拉高一個數量級，每一發火箭、每一顆衛星的軟體邊際成本就被 AI 攤薄，這是 hyperscaler 做不到、也無法向股東解釋的 Synergy。

    結論：把 Cursor 放在 SpaceX，而不是 xAI，是在向市場宣告：AI 工具不是附加服務，而是 SpaceX 火箭和星鏈同級的基礎設施。

    第一層戰略：把「寫程式」變成 SpaceX 全線業務的 AI 渦輪

    從內部效率看，這筆收購最直接的目標，是把 Cursor 變成 SpaceX / Starlink / 機器人 全線業務的統一開發入口。

    1. 超複雜系統的軟體，是 SpaceX 真正的 bottleneck：
    2. 火箭導航、姿態控制、衛星通訊協定、地面站網路、星鏈終端韌體，都是高風險、高審查、重度測試的軟體工程。

    3. 這些系統的特點是：需求變化快、部署週期長、錯誤代價極高（一次發射失誤就是數億美元）。

    4. Cursor 能做的不只是「補全程式碼」：

    5. 掌握 IDE 入口，就掌握了：
      • 代碼結構分析與重構
      • 測試生成與覆蓋率優化
      • CICD 管線自動維護
      • 安全審查與合規檢查

    6. SpaceX 完全可以為內部工程團隊打造「SpaceX 版 Cursor」：懂自家語言、框架、硬體抽象層、甚至飛行軌跡與通訊協定。

    7. 結果是：火箭不只是硬體疊代更快，軟體也被 AI 加上「渦輪」：

    8. 如果 AI 能把安全可靠的軟體交付速度提升 2 倍，SpaceX 可以在同樣 CapEx 下完成更多次軌道測試、推出更多星鏈服務、甚至加速機器人與地面自動化。
    9. 這對 OpenAI、Anthropic 這類「賣模型 API」的公司來說，是另一個世界：他們靠賣模型賺錢，SpaceX 靠用模型讓自己的實體資產跑得更快。

    💡 關鍵： 同樣是用 AI，有人賣 API 賺費用，有人用 AI 降低每顆衛星、每次發射的軟體成本，後者的槓桿完全不同。

    這是第一層賭注：用 AI IDE 做一個巨大內部槓桿，把 SpaceX 本業的軟體開發變成 AI 驅動的工廠，而不是人肉寫碼作坊。

    第二層戰略：從 AI 編程 IDE，吃進企業軟體與代理平台生態

    很多人還把 Cursor 看成「會寫程式的插件」，但 60B 價格只成立在一個前提：它將成為 AI 代理的主戰場，而不是人類輔具。

    1. IDE 是未來 Agent 的「作業系統」：
    2. OpenAI 的三連招（5M Codex 週活、收購雲端 IDE Ona、推出更完整 Agent 工作流）已經給了答案：
      • 開發者不只是要問答，而是要委派任務；
      • Agent 需要一個長時間持續運行的雲端環境；
      • 入口就會從「CLI / GUI 工具」慢慢收斂到 雲端 IDE / Workspace。

    3. Cursor 若被 SpaceX 完整吸收，有機會走同一條路：從本地 IDE 向「AI 代碼雲工作區」演化，讓 Agent 能在裡面持續寫碼、測試、部署、監控。

    4. 從開發者入口，吃進企業工作流：

    5. 一旦 IDE 變成雲端工作區，它自然會接上：
      • Git / Issue Tracking（Jira、Linear）
      • CICD（GitHub Actions、GitLab CI）
      • 監控（Datadog、Grafana）
      • 甚至企業內部 ERP、CRM、數據倉庫
    6. 這時候，Cursor 就不只是「寫程式工具」，而是企業工作流自動化的總控台：Agent 透過它修改程式、改報表、調整 pipeline、呼叫第三方 API。

    7. 這直接衝擊誰？雲端巨頭 + IDE 生態：

      • VS Code / JetBrains 會被迫從「本地編輯器」變成「AI 代理中介層」，如果做不到，就會淪為 AI IDE 的前端皮膚。
      • AWS / Azure / GCP 若沒有自己強力的 AI IDE + Agent 平台，只能在 API 層面被抽象掉，變成 Cursor / SpaceX 平台底下的「雲端供電公司」。

    8. SpaceX 可以憑什麼跟這些巨頭搶？

    9. 因為它手上有三張牌：
      • xAI 模型能力（不一定最強，但能與 OpenAI 等談多雲策略）；
      • Starlink 全球網路（邊緣裝置到雲端的閉環）；
      • Cursor 作為開發者入口。
    10. 把三者綁在一起，你會得到一個有趣的畫面：
      • AI 代理在 Cursor 中寫程式、部署到雲端，透過 Starlink 跑在全球邊緣設備上，底層部分或全部算力可能又回到 xAI / 其他模型供應商。

    第二層賭注是：把 Cursor 從「強力插件」拉到「企業 AI 代理平台的核心入口」，對準的是 OpenAI、Anthropic、Google 所還沒完全鎖死的開發者生態縫隙。

    第三層戰略：用高估值 AI 資產，重寫 SpaceX 的資本故事

    談到 600 億美元，就不能假裝這只是產品戰略。

    1. AI 是 SpaceX 新一輪估值擴張的敘事引擎：
    2. TechCrunch 指出，SpaceX 在 IPO 後兩天市值就多了 1 兆美元，達到 2.6 兆，市場顯然在找「下個十年的增長故事」。
    3. 火箭、星鏈都有物理與監管瓶頸，AI 則是可以無限疊加的故事，而且暫時不受火箭發射頻率限制。

    4. 把 Cursor 這樣一個被市場預期具爆發力的 AI 資產裝進來，實際上是在把 AI 高成長溢價，灌進 SpaceX 的估值模型裡。

    5. 對比 hyperscaler 的資本壓力，SpaceX 在玩反向操作：

    6. Hyperscaler 目前的問題是：AI 基建投資可能在 2026 年就超過自有現金流，被迫舉債或找外部資金。
    7. SpaceX 則是：先透過 IPO 把火箭 + 星鏈的未來現金流前置變現，再用高估值股票去收購 AI 成長資產。

    8. 結果是：同樣在燒 AI，Big Tech 在借錢，SpaceX 在用股本換未來故事。

    9. Cursor 團隊拿到的是什麼？

    10. 表面上是 600 億賣身，實際上是：
      • 用 Cursor 的增長，去推 SpaceX 股價；
      • 用 SpaceX 股價，反向放大 Cursor 的財務回報；
      • 同時取得全球最極端、最高價值的應用場景（航太、衛星、機器人），作為 AI IDE 的試驗場。

    💡 關鍵： Cursor 被放進上市後的 SpaceX，是在用一個高成長 AI 資產，為整家公司開出新一輪估值倍數空間。

    第三層賭注：Cursor 是被當成一個「AI 引擎 + 敘事引擎」植入上市公司裡，讓 SpaceX 在資本市場的軌道上，再往外推一個圈。

    對開發者與大公司的警訊：入口被封裝，你還能掌握什麼？

    回到問題本身：這 600 億，到底在買什麼？

    答案是：買一個可以重新封裝開發流程的「AI 工程基建入口」。

    • 對 開發者 而言：
    • 你的工作流程正被平台重新設計：
      • 從「我在 VS Code 寫程式，偶爾叫一下 AI」
      • 變成「AI 在 Cursor / 雲端 IDE 替我持續寫程式，我在旁邊審核與決策」。

    • 這意味著幾件事：

      • 真正稀缺的是對系統與業務的抽象能力，而不是打字速度；
      • 能掌控 pipeline、能定義 guardrail、能把 AI 變成團隊的一部分，而不是一個玩具的人，會成為新一代 tech lead；
      • IDE 入口一旦被少數平台鎖死，你對工具的可組裝空間會變小，越晚上車的人，就越被迫接受預封裝的工作流與商業條款。

    • 對 其他大型公司 而言：

    • 如果還在把 AI 當成「附加功能」（在產品加幾個 AI 按鈕、在後台接幾個模型 API），而不去掌握開發入口與工作流定義權，你就會變成別人平台上的一個插件。
    • 在新的 AI 工程秩序裡，有三種角色：
      1. 掌握入口的平台方（Cursor + OpenAI / SpaceX 這一類）；
      2. 供應雲端與模型的基礎設施商；
      3. 在別人 IDE 裡被調用的服務提供者。
    • 若你不刻意向前移動到第 1 層，最終只能在別人的軌道上繞圈，靠被動流量過活。

    具體建議：

    • 對開發者：
    • 儘快把日常工作搬到 AI IDE / 雲端工作區，刻意練習「讓 AI 寫，我做 code review 與架構決策」的模式；

    • 投資在系統設計、產品理解、AI pipeline 與安全治理，而不是僅僅學「提示工程」。

    • 對公司：

    • 儘快決定你要不要自己掌握一個「內部 AI IDE + 代理平台」：
      • 可以用開源方案，但入口一定要在你自己控制的域名與權限體系內；
      • 把內部開發流程視為戰略資產，而不是交給隨便一個 SaaS 插件。

    SpaceX 用 6000 億做出的選擇，其實是寫給所有人的一句話：在 AI 下半場，誰掌握開發入口，誰就掌握新的軌道設計權；其他人，只能在那條軌道上周而復始地繞圈。

    🚀 你現在可以做的事

    • 對開發者：挑一個主流 AI IDE（如 Cursor 等）把日常專案搬過去，實測「AI 寫碼、你做架構與 review」一整週
    • 對技術主管：盤點公司現有開發流程與工具鏈，設計一個由你方控管域名與權限的「內部 AI IDE + Agent」試點環境
    • 對決策者：在年度技術／產品策略會議上，明確討論「我們要做入口平台，還是接受成為他人 IDE 裡的一個插件」
  • 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 與時間成本差異