Kerwin AI Information

標籤: Token 最佳化

  • RTK 終端機 AI 助手：少花 90% Token

    RTK 終端機 AI 助手：少花 90% Token

    📌 本文重點

    • RTK 用結構化壓縮幫你減少重複丟給模型的 Token
    • 常用專案可重用上下文，問越多次平均越省
    • 在終端開發流程中無痛接入，五分鐘內可上手

    你現在用 AI 幫忙寫程式，很可能有一大半錢都燒在「重複丟給模型看的 Token」上，而 RTK 要做的，就是在終端機幫你把這些多餘 Token 全部擠乾。

    專案連結：https://github.com/rtk-ai/rtk

    核心功能：RTK 怎麼幫你少丟 Token？

    1. Prompt 壓縮：把廢話變成精簡結構

    一般你在終端機複製錯誤訊息、整段程式碼給 AI，看起來沒幾行，實際 Token 超多。RTK 做的事是：

    • 先在本地做「結構化」：分出錯誤訊息、檔案片段、指令上下文
    • 用短 Prompt 模板描述需求，例如：
    • 錯誤訊息 + 詢問目標（幫我找 bug）
    • 這段程式 + 修改要求（改成 async）
    • 最後送給模型的內容會是高度壓縮的結構，而不是你手動貼的一大坨文字

    你可以這樣行動：

    • 不要再打長篇自然語言 Prompt，改用 RTK 的命令別名（例如 rtk fix, rtk explain），把「要做什麼」交給 RTK 的模板處理。

    2. 上下文重用：同一個專案不重講第二次

    平常你每問一次 AI：「這個專案是做什麼的？」「這個模組是幹嘛？」都在重複付費。RTK 會：

    • 對常問的目標（例如某個目錄、特定檔案）做一次「結構化摘要」
    • 接下來跟同一個會話相關的指令，就重用這些摘要，而不是把整份檔案再丟一次

    具體效果：

    • 問同一個 repo 的問題越多次，平均每次的 Token 消耗越低
    • 對超過數萬行的專案，差異會特別明顯

    💡 關鍵： 專案越大、問越多次，RTK 的上下文重用機制帶來的平均 Token 成本下降就越明顯。

    你可以這樣行動：

    • 針對常用專案建立一個 RTK 會話，之後都在這個會話裡問問題，而不是每次都「一次性丟完所有檔案」。

    3. 結構化輸入 / 輸出：減少「看懂答案」的成本

    RTK 不只壓縮你給模型的內容，也會讓模型的回答更結構化，例如：

    • 要求模型輸出固定格式：原因 / 修復步驟 / 建議指令，而不是亂聊一通
    • 要模型只返回「要改的那幾行」，而不是整份檔案，減少輸出 Token

    你可以這樣行動：

    • 習慣用 RTK 指令，而不是「請用條列式說明」這種自然語言；RTK 已經替你定義好能省 Token 又好讀的輸出格式。

    RTK 當 CLI 代理：三種高頻使用場景

    1. 日常開發：錯誤訊息、修小段程式、產生命令

    在日常開發中，你大概會一直做這幾件事：

    1. 看錯誤訊息：不知道哪裡爆
    2. 改小段程式：加 log、改型別、改函式簽名
    3. 產生命令：不知道某個工具的 CLI 參數要怎麼下

    RTK 的典型玩法：

    • 看錯誤訊息

    bash
    # 把上一個命令的錯誤訊息丟給 RTK 解釋
    some-command-that-fails 2>error.log
    rtk explain-error < error.log

    行動：把原本你會貼到 ChatGPT / Claude 的 error log，改成用 rtk explain-error，RTK 會用短 Prompt + 結構化提問幫你省 Token。

    • 改小段程式

    bash
    # 針對某個檔案的一小段範圍做修改建議
    rtk edit src/main.rs --range 20-60 --ask "改成 async/await 風格，保留原本邏輯"

    行動：只給 RTK「相關的幾十行」，不要整支檔案，RTK 會幫你把上下文描述給模型，降低 Token。

    • 產生命令

    bash
    # 根據需求生成 shell 指令，不用自己翻 man page
    rtk cmd "把 logs 資料夾裡 7 天前的 .log 壓成一個 tar.gz，檔名帶日期"

    行動：用自然語言描述「你想做什麼」，讓 RTK 負責用精簡 Prompt 跟模型談，輸出最終的 shell 指令。

    2. 讀專案：總結檔案、生成說明、快速問代碼

    當你接手一個新 repo，通常會做：

    • 看 README 還是不懂整體架構
    • 想知道某個模組的職責
    • 想快速問「這個函式在哪裡用到」

    RTK 的用法可以是：

    • 總結檔案 / 目錄

    “`bash
    # 總結一個檔案在幹嘛
    rtk summarize src/lib.rs

    # 總結一個目錄的主要模組與職責
    rtk summarize src/handlers/
    “`

    • 生成說明文件

    bash
    # 幫某個模組產生說明文字（例如供 PR 或文件用）
    rtk doc src/services/user.rs --format markdown

    • 快速問代碼

    bash
    # 在 repo 裡問問題，RTK 只會選關聯檔案給模型看
    rtk ask "登入流程中，token 驗證主要在哪幾個檔案處理？"

    行動：把「整個 repo 丟進 AI」改成「用 rtk summarize 和 rtk ask 針對性查詢」，每次只給必要檔案，Token 消耗會明顯下降。

    3. 結合 tmux / fzf / git workflow：變成隨叫隨用 AI 幫手

    RTK 的本質是單一 CLI binary，很適合跟你現有的終端機工具整合：

    • 搭配 tmux：固定一個 pane 做 RTK 聊天視窗

    bash
    # tmux 裡開一個新 pane 專門跑 rtk chat
    rtk chat

    行動：在 tmux 裡維持一個長期會話，RTK 可以反覆重用上下文，越聊越省 Token。

    • 搭配 fzf：選檔後丟給 RTK

    bash
    # 用 fzf 選一個檔案丟給 RTK 總結
    rtk summarize "$(fzf)"

    • 搭配 git workflow：讓 AI 看 diff 而不是整檔

    bash
    # 只把當前變更的 diff 丟給 RTK 請他協助寫 PR 說明
    git diff > /tmp/diff.patch
    rtk explain-diff < /tmp/diff.patch

    行動：在你的 shell 設定（例如 .zshrc 或 .bashrc）裡建立幾個 alias，把平常會複製貼上的工作改用 RTK 處理：

    alias rpr="git diff | rtk explain-diff"
alias rerr="rtk explain-error"

    適合誰用？三種典型開發者

    • 1. 每天都開著 AI 編輯器（Cursor、Claude Code）的工程師
      你已經習慣「寫一寫就問 AI」，RTK 適合接在你終端機工作流的空白處：看 log、看 diff、產生命令，這些在編輯器之外的操作用 RTK 承接，Token 花在真正需要的地方。

    • 2. 維護大型專案或多 repo 的開發者
      尤其是 Rust / Java / monorepo，檔案多、型別長、錯誤訊息又臭又長，用 RTK 的結構化摘要 + 上下文重用，可以顯著減少「每次都要把半個專案丟給 AI」的情況。

    • 3. 自費用 API Key 的個人開發者 / Side project 作者
      如果你是自己刷卡買 OpenAI / Anthropic / 其他 LLM Token，用 RTK 是直接對帳單有感的程度；原本一個月 30–50 美金的，也許可以壓到 10–20 美金。

    💡 關鍵： 若你自己付模型費，用 RTK 把「貼錯誤 / 貼整檔 / 貼 diff」改成結構化對話，帳單級別的節省會非常直接。

    5 分鐘開始用 RTK：安裝、設定、跑幾個指令

    1. 安裝單一 binary

    到 GitHub Releases 頁下載對應平台的 binary：

    • 進入 https://github.com/rtk-ai/rtk
    • 點選右側 Releases
    • 下載對應系統檔案（例如 rtk-x86_64-unknown-linux-gnu、rtk-aarch64-apple-darwin）
    • 賦予執行權限並放到 PATH 裡，例如：
    chmod +x rtk-x86_64-unknown-linux-gnu
sudo mv rtk-x86_64-unknown-linux-gnu /usr/local/bin/rtk

    2. 設定 API Key

    RTK 本身不附模型，你需要設定自己的 LLM 供應商 API key（例如 OpenAI / Anthropic 等，依官方文件為準）：

    export OPENAI_API_KEY="你的 key"
# 或依照 RTK 說明設定 RTK 專用環境變數，例如：
export RTK_MODEL_PROVIDER=openai
export RTK_MODEL=gpt-4.1-mini

    建議：

    • 選一個便宜的小模型當預設（例如 gpt-4.x-mini / o3-mini 類型），RTK 本身就已經會幫你省 Token，小模型更划算。

    💡 關鍵： 把 RTK_MODEL 設成較便宜的小模型，再搭配 Prompt 壓縮，能在不明顯犧牲效果的前提下把成本再壓一截。

    3. 試跑幾個典型指令

    照著下面三步走，你大概五分鐘內就能感受到 RTK 的節奏：

    1. 解讀錯誤訊息

    bash
    cargo build 2>error.log
    rtk explain-error < error.log

    1. 總結專案主檔案

    bash
    rtk summarize src/main.rs

    1. 生成一個命令

    bash
    rtk cmd "找出今天修改過的 .rs 檔，列出檔名和變更行數"

    怎麼量化：你到底省了多少 Token？

    如果你是自己付費買 API，建議直接用「帳單」來感受 RTK 的效果，而不是只看官方說的 60–90%。你可以：

    1. 先觀察一週的原始用量
    2. 不改工作流程，照常用 Cursor / Claude Code / ChatGPT 開發

    3. 記下這週在模型供應商後台的 Token 用量 / 金額

    4. 下一週加上 RTK

    5. 日常 terminal 問題全部改用 RTK（錯誤、log、diff、命令）

    6. 大型專案閱讀改用 rtk summarize 和 rtk ask

    7. 對比兩週帳單

    8. 如果你平常大量貼錯誤訊息、整檔 code、diff 給 AI，看起來會有 30–50% 甚至更多的節省

    進階做法：

    • 把 RTK 指令加上 --verbose 或開啟 debug log（依官方說明），讓它輸出實際的 Token 用量，對照供應商後台的數字，清楚看到壓縮前後的差異。

    RTK 的重點不是「多一個聊天機器人」，而是把你原本就會做的事——貼錯誤、貼代碼、貼 diff 問 AI——改成一種對 Token 比較友善的方式。如果你現在已經很依賴 AI 寫程式，那麼把這些對話搬進 RTK，大概是最省時、也最省錢的下一步。

    🚀 你現在可以做的事

    • 進入 RTK GitHub Releases 下載對應平台的 rtk binary 並加入 PATH
    • 在 shell 設定中加入 OPENAI_API_KEY 與 RTK_MODEL 等環境變數，設好預設小模型
    • 建立幾個常用 alias（例如 rerr, rpr），並用 rtk explain-error、rtk summarize 開始取代貼到聊天機器人的動作