命令列工具 on KnightLi的博客

RTK：給 AI 編程代理省 token 的命令列代理工具

Wed, 27 May 2026 13:52:01 +0800

rtk-ai/rtk 是一個面向 AI 編程代理的命令列代理工具。它的思路很直接：很多 agent 在開發過程中會頻繁呼叫 ls、cat、grep、git status、git diff、測試命令和建置命令，而這些命令的原始輸出經常又長又重複。RTK 會在命令輸出進入 LLM 上下文之前先做過濾和壓縮，讓模型看到更短、更有用的結果。

專案地址：rtk-ai/rtk

它解決的是什麼問題

AI 編程工具真正貴的不只是模型呼叫次數，還有上下文裡被塞進去的無效資訊。

例如：

ls -la 可能輸出大量權限、時間和無關檔案。
git diff 可能夾雜很多重複上下文。
pytest、cargo test、npm test 失敗時，最重要的是失敗用例和錯誤堆疊，而不是所有通過項。
docker ps、kubectl pods、aws 命令往往欄位很多，但 agent 只需要少數關鍵資訊。

這些輸出如果原樣進入模型上下文，會快速消耗 token。RTK 的目標不是替代這些命令，而是在它們和 AI 編程代理之間加一層「壓縮代理」。

RTK 的基本工作方式

RTK README 裡給出的定位是：它會在命令輸出到達 LLM context 之前，對結果做過濾和壓縮。它是一個 Rust 單檔二進位程式，支援大量常見開發命令，並強調低額外開銷。

它主要做四類處理：

Smart Filtering：去掉註解、空白、樣板內容和低價值雜訊。
Grouping：把相似項目聚合起來，例如按目錄、錯誤類型或狀態分組。
Truncation：保留關鍵上下文，截斷重複或不重要的部分。
Deduplication：把重複日誌折疊成更短的計數表達。

從 agent 的角度看，命令仍然是熟悉的開發命令；變化在於返回給模型的結果更短。

支援哪些命令

RTK 覆蓋的命令範圍比較偏「日常開發現場」：

檔案查看：rtk ls、rtk read、rtk find、rtk grep
Git：rtk git status、rtk git log、rtk git diff
GitHub CLI：rtk gh pr list、rtk gh pr view、rtk gh issue list
測試命令：rtk pytest、rtk go test、rtk cargo test、rtk vitest、rtk playwright test
建置和 lint：rtk lint、rtk tsc、rtk next build、rtk cargo clippy
容器和雲命令：rtk docker ps、rtk docker logs、rtk kubectl pods、rtk aws sts get-caller-identity
資料和日誌：rtk json、rtk deps、rtk env、rtk log

這類工具最適合 agent 高頻讀命令輸出的場景。它不負責替你寫程式碼，而是讓 agent 少讀雜訊。

安裝和接入方式

README 給了幾種安裝方式。

Homebrew：

`1`	`brew install rtk`

Linux/macOS 快速安裝：

`1`	`curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh \| sh`

Cargo：

`1`	`cargo install --git https://github.com/rtk-ai/rtk`

安裝後可以先檢查版本和統計資訊：

1
2

rtk --version
rtk gain

接入 AI 編程工具時，可以用初始化命令：

rtk init -g
rtk init -g --gemini
rtk init -g --codex
rtk init -g --agent cursor
rtk init --agent windsurf
rtk init --agent cline

初始化後需要重啟對應的 AI 工具。對於支援 hook 的 agent，Bash 命令會在執行前被重寫，例如把 git status 變成 rtk git status，讓 agent 收到壓縮後的輸出。

使用時要注意什麼

RTK 的收益取決於 agent 是否真的透過 shell 命令讀取資訊。

README 裡特別提醒：像 Claude Code 的內建 Read、Grep、Glob 這類工具不經過 Bash hook，因此不會自動被 RTK 改寫。要讓 RTK 介入，需要使用 shell 命令，例如 cat、head、tail、rg、grep、find，或者直接呼叫 rtk read、rtk grep、rtk find。

這點很關鍵。RTK 不是全域透明地壓縮所有 agent I/O，它更像是 shell 命令層面的代理。

Windows 使用者也要注意，README 建議不要直接雙擊 rtk.exe，而是把它放到 PATH 裡，透過 Command Prompt、PowerShell 或 Windows Terminal 使用。它也提到，如果想獲得完整 hook 體驗，WSL 會更自然。

適合誰用

RTK 適合三類人：

重度 AI 編程使用者：每天讓 agent 跑很多 git、rg、測試和建置命令。
大倉庫使用者：命令輸出動輒幾百行，agent 經常被無關上下文淹沒。
關心 token 成本和上下文窗口的人：希望模型把注意力放在失敗、變更和關鍵檔案上。

如果你的專案很小，或者 agent 主要透過 IDE 內建工具讀取檔案，RTK 的體感收益可能沒那麼明顯。它真正發力的地方，是命令列輸出又長又頻繁的開發流。

我的判斷

RTK 的方向很實用。現在很多 AI 編程工作流都在強調更強的模型、更大的上下文、更長的任務，但開發現場還有一個樸素問題：agent 經常讀了太多沒必要讀的東西。

把命令輸出先壓縮，再交給模型，能減少 token 消耗，也能降低模型被雜訊帶偏的機率。

不過它不是魔法開關。要用好 RTK，需要把 agent 的工作方式往 shell 命令靠一靠，並確認目前工具的 hook 是否真的生效。對 Codex、Claude Code、Gemini CLI、Cursor、Windsurf 這類場景來說，它更像一個值得測試的「上下文節流器」：不改變開發命令本身，但讓 agent 讀到更乾淨的結果。

wx-cli 專案解讀：用命令列查詢本機微信聊天記錄

Mon, 18 May 2026 21:02:21 +0800

wx-cli 是一個用 Rust 編寫的本機微信資料命令列工具，目標是在命令列裡查詢自己的微信會話、聊天記錄、聯絡人、群成員、收藏、朋友圈、公眾號文章、附件和統計資訊。

它不是雲端微信同步服務，也不是聊天機器人。它更像是一個本機唯讀資料檢索層：微信仍然在本機執行，資料仍然留在本機，wx-cli 負責按需解密、快取和查詢本機資料庫，再把結果以 YAML 或 JSON 形式輸出給人或 Agent 使用。

這個專案有兩個值得關注的點：一是它把微信本機資料查詢做成了跨平台 CLI；二是它專門考慮了 Claude Code、Cursor、Codex 這類 AI Agent 的使用場景，提供了 SKILL.md 和帶 meta 的結構化輸出。

wx-cli 能做什麼

按專案 README 的描述，wx-cli 覆蓋的功能很完整：

查看最近會話和未讀會話。
查詢某個聯絡人或群的聊天歷史。
全庫搜尋關鍵字。
查看新增訊息。
查詢聯絡人、群成員和群暱稱。
查詢收藏。
查詢朋友圈通知、朋友圈時間線和朋友圈正文。
查詢公眾號文章推送。
列出和提取聊天圖片附件。
做聊天統計。
匯出聊天記錄為 Markdown 或 JSON。

這些能力讓它不只是「查聊天記錄」，而是把微信本機資料變成了可搜尋、可統計、可匯出的本機資料庫。

為什麼適合 AI Agent

很多命令列工具只是給人看的，輸出是一段文字。wx-cli 則明顯考慮了 Agent 讀取。

README 提到，history、search、sessions、unread、new-messages、stats、attachments 等命令會附帶 meta 資訊。meta 裡包含結果狀態、未知分片、命中資料的最新時間、session 記錄的最新時間等資訊。

這對 Agent 很有用。因為 AI 不只需要「查到了什麼」，還需要知道「結果新不新」「有沒有可能漏訊息」「是不是需要重新 init」。例如：

status 可以提示結果是否 ok 或 possibly_stale。
unknown_shards 可以提示是否存在 daemon 目前沒有 key 的資料庫分片。
chat_latest_timestamp 可以告訴 Agent 目前命中資料裡的最新訊息時間。
session_last_timestamp 可以幫助判斷本機 session 記錄是否明顯領先於查詢結果。

這類元資訊可以減少 AI 誤判，讓 Claude Code、Cursor、Codex 這類工具在處理微信資料時更穩。

安裝方式

專案推薦透過 npm 全平台安裝：

`1`	`npm install -g @jackwener/wx-cli`

也支援 macOS / Linux 的 curl 安裝：

`1`	`curl -fsSL https://raw.githubusercontent.com/jackwener/wx-cli/main/install.sh \| bash`

Windows 可以在系統管理員 PowerShell 中執行：

`1`	`irm https://raw.githubusercontent.com/jackwener/wx-cli/main/install.ps1 \| iex`

如果要從原始碼建置，也可以直接用 Rust：

1
2

git clone git@github.com:jackwener/wx-cli.git && cd wx-cli
cargo build --release

建置產物是 target/release/wx，Windows 下是 wx.exe。

和 Agent Skill 的關係

wx-cli 還提供了面向 AI Agent 的 Skill。可以透過 skills CLI 一鍵安裝到 Claude Code、Cursor、Codex 等支援 Skills 的環境：

`1`	`npx skills add jackwener/wx-cli`

全域安裝：

`1`	`npx skills add jackwener/wx-cli -g`

安裝後，Agent 會讀取倉庫裡的 SKILL.md，知道如何安裝、初始化和呼叫 wx-cli。

這意味著你可以讓 Agent 幫你做一些本機資訊整理任務，例如：

找某段時間某個群聊裡討論過的關鍵字。
彙總最近未讀訊息。
從某個會話裡匯出最近聊天記錄。
搜尋公眾號文章推送連結。
分析某個群聊裡的發言統計。

前提仍然是：這些資料必須是你本機、你自己的微信資料。

基本使用方式

初始化前需要保持微信正在執行。不同平台要求不同。

Linux 上可以執行：

`1`	`sudo wx init`

Windows 上需要用系統管理員 PowerShell：

wx init

macOS 上更複雜。README 說明，預設路徑需要先對 WeChat 做 ad-hoc 簽名，才能掃描程序記憶體；重新簽名後還要清理舊 TCC 授權記錄，否則截圖、視訊通話、麥克風等權限可能出現「看起來已開啟但實際拒絕」的問題。專案文件也提醒，重新簽名會帶來 macOS 頻繁彈出存取其他 App 資料提示的副作用。

初始化後，可以用下面的命令驗證：

`1`	`wx sessions`

能看到最近會話，說明基本鏈路已經可用。daemon 會在首次呼叫時自動啟動。

常用命令示例

查看最近會話：

`1`	`wx sessions`

查看未讀會話：

`1`	`wx unread`

只看真人未讀，過濾公眾號和摺疊入口：

`1`	`wx unread --filter private,group`

查看某個會話最近聊天記錄：

`1`	`wx history "張三"`

拉取更多歷史訊息：

`1`	`wx history "張三" -n 2000`

按時間範圍查詢群聊：

`1`	`wx history "AI群" --since 2026-04-01 --until 2026-04-15`

全庫搜尋：

`1`	`wx search "關鍵詞"`

搜尋某個群中的關鍵字：

`1`	`wx search "會議" --in "工作群" --since 2026-01-01`

匯出聊天記錄：

1
2

wx export "張三" --format markdown -o chat.md
wx export "AI群" --since 2026-01-01 --format json

這些命令都比較適合被腳本或 Agent 呼叫，尤其是加上 --json 後。

朋友圈和公眾號文章

wx-cli 不只查聊天。

朋友圈相關命令分成通知和貼文：

1
2
3

wx sns-notifications
wx sns-feed
wx sns-search "關鍵詞"

需要注意，朋友圈資料只覆蓋你本機刷到過的內容。微信客戶端按需下載，沒在本機出現過的資料，工具也不會憑空拿到。

公眾號文章則透過獨立命令查詢：

wx biz-articles
wx biz-articles --account "返朴"
wx biz-articles --since 2026-05-01 --until 2026-05-10
wx biz-articles --json | jq '.[].url'

它會回傳公眾號名稱、標題、URL、摘要、封面、時間等欄位。對做資料整理、文章收集和本機知識庫的人來說，這個功能很實用。

附件提取

微信聊天裡的圖片附件通常不是直接可讀的普通圖片檔，而是存在 xwechat_files/<wxid>/msg/attach/... 下的 .dat 檔案。

wx-cli 提供了兩步流程：

1
2

wx attachments "張三"
wx attachments "AI群" --kind image -n 100

先拿到 attachment_id 後，再提取：

`1`	`wx extract <attachment_id> -o ~/Desktop/photo.jpg`

輸出報告裡會帶 md5、dat_path、dat_size、output、format、decoder 等資訊。README 中說明它支援 legacy XOR、V1 fixed-AES、V2 AES + XOR 等解碼檔位，不同平台的 image key 提取方式也不同。

這部分能力很強，但也更需要謹慎使用：只處理自己的資料，不要把它用於未經授權的資料存取。

daemon 架構為什麼重要

wx-cli 的效能點在 daemon。

README 中給出的結構大致是：

wx (CLI) ──Unix socket──▶ wx-daemon (背景程序)
                              │
                    ┌─────────┴──────────┐
               DBCache               聯絡人快取
           (mtime 感知複用)

daemon 首次解密後，會把資料庫和 mtime 資訊持久化到 ~/.wx-cli/cache/。如果資料庫檔案 mtime 沒變，後續呼叫就可以複用快取，不需要每次重新解密。

這對命令列查詢和 Agent 循環都很關鍵。Agent 可能會連續查詢多個會話、搜尋多個關鍵字、再做統計和匯出。如果每次都重新掃描和解密，體驗會很差；daemon 快取讓它更接近一個本機查詢服務。

原理簡述

專案 README 對原理有直接說明：微信 4.x 使用 SQLCipher 4 加密本機資料庫，WCDB 會在程序記憶體中快取派生後的 raw key。

wx-cli 會根據平台使用不同方式掃描微信程序記憶體，匹配 key 模式後提取密鑰，再由 daemon 按需解密和快取資料庫。

不同平台的底層機制不同：

macOS 使用 Mach VM API。
Linux 使用 /proc/<pid>/mem。
Windows 使用 VirtualQueryEx 和 ReadProcessMemory。

這些能力解釋了為什麼初始化通常需要較高權限，也解釋了為什麼 macOS 上會涉及簽名和隱私授權。

使用邊界和風險

這類工具必須先講邊界。

wx-cli README 的免責聲明寫得很明確：工具僅用於學習和研究目的，用於解密自己的微信資料，並要求遵守相關法律法規，不得用於未經授權的資料存取。

實際使用時也建議注意：

只在自己的電腦、自己的微信帳號上使用。
不要把匯出的聊天記錄隨意上傳到雲端模型。
用 Agent 分析聊天記錄時，先確認 API 供應商和資料跨境風險。
匯出 Markdown / JSON 後要注意檔案權限和備份位置。
公司或多人裝置上使用前，先確認合規和授權。

本機工具不等於沒有隱私風險。它減少了資料離開本機的預設路徑，但如果你把輸出交給雲端模型、網盤或第三方腳本，風險又會回來。

適合誰使用

wx-cli 適合這些場景：

想在本機快速搜尋自己的微信歷史訊息。
需要把某個會話匯出為 Markdown 或 JSON。
想統計某個群聊在一段時間內的發言情況。
想讓 Claude Code、Cursor、Codex 等 Agent 幫忙整理本機微信資料。
想把公眾號文章推送連結整理進本機知識庫。
想研究微信本機資料庫結構和解密流程。

不太適合這些場景：

想做雲端微信同步。
想繞過他人裝置或帳號權限。
想無腦圖形介面操作，不接觸命令列。
不願意處理 macOS 權限、Windows 系統管理員權限或 Linux sudo 的使用者。

小結

wx-cli 的價值，不只是「命令列查微信聊天記錄」。更準確地說，它把本機微信資料變成了一個可查詢、可匯出、可被 Agent 消費的本機資料源。

它的 daemon 架構解決了反覆解密和查詢效能問題；meta wrapper 讓 AI Agent 更容易判斷結果是否新鮮；SKILL.md 則把安裝和使用方式交給 Claude Code、Cursor、Codex 這類工具理解。

如果你經常需要從微信裡找資訊、整理群聊、匯出記錄或建構個人資料庫，wx-cli 很值得關注。但使用它時也要始終記住一條底線：只處理自己的資料，並且謹慎管理匯出結果。

參考資料

jackwener/wx-cli GitHub 倉庫

auto-editor 是什麼：自動剪掉靜音空白，再匯出到 Premiere 和 Resolve

Thu, 23 Apr 2026 13:31:27 +0800

很多影片真正耗時間的地方，不是加轉場、調色或修字幕，而是先把一大段素材從頭看到尾，再手動刪掉那些沒人說話、沒有動作、沒有資訊量的空白段。

auto-editor 解決的就是這件事。它不是傳統意義上的可視化剪輯軟體，而是一個命令列工具，先分析影片或音訊，再把靜音段、低運動段這類「死區」自動切掉，幫你完成第一遍粗剪。

如果你手上的素材經常長這樣，這類工具會特別順手：

螢幕錄製講解
教學影片
Podcast 或口播內容
長時間直播回放
需要先粗剪再精修的訪談素材

它最核心的價值是什麼

auto-editor 的核心思路可以壓成一句話：

先把枯燥的第一遍剪輯自動化，再把結果交回給人處理。

官方 README 最強調的一點，就是它會先切掉常見的「dead space」，最典型的就是靜音。對長影片來說，這往往是最機械、也最耗時間的一步。

最基本的用法非常直接：

`1`	`auto-editor path/to/your/video.mp4`

跑完之後，你可以把它理解成已經幫你做完一輪初步篩選。它不是替你做最後的審美判斷，而是先把明顯沒什麼資訊量的段落清掉。

它不只會按靜音剪，也能按運動畫面剪

很多人聽到「自動剪輯」，第一反應會以為它只能辨識靜音。

但 auto-editor 的規則不只一套。官方文件裡比較常見的兩種自動判斷方式是：

audio：依照音量或響度判斷
motion：依照畫面運動變化判斷

例如：

`1`	`auto-editor example.mp4 --edit motion:threshold=0.02`

這代表它不只適合「沒人說話就刪掉」這種素材，也適合某些主要靠畫面變化來推進內容的影片。

官方也支援把不同規則組合起來，例如把音訊和運動條件一起使用。這樣的好處是，你可以把「什麼時候該保留、什麼時候該切掉」寫得更接近實際需求，而不是只靠單一閾值硬切。

`--margin` 很重要，它決定剪出來像不像人剪的

自動粗剪最容易翻車的地方，不是有沒有刪掉空白，而是刪得太狠。

一句話剛開頭就被切掉，或是一句話講完立刻斷掉，都會讓影片看起來很機械。auto-editor 在這裡有一個很實用的參數：--margin。

它的作用可以理解成，在原本要切掉的邊界前後，多留一點緩衝。官方示例裡的預設值是 0.2s，也就是前後各多留一點點空白，讓節奏更自然。

例如：

1
2

auto-editor example.mp4 --margin 0.2sec
auto-editor example.mp4 --margin 0.3s,1.5sec

這個參數很值得注意，因為它往往決定成片看起來像是生硬的自動裁斷，還是比較像人手先做過一輪順手的粗剪。

它更適合第一遍處理，不是完整 NLE 的替代品

這是理解 auto-editor 時最重要的一點。

它更像是一個自動化粗剪器，而不是完整的非線性編輯器。它的優勢在於：

快速處理長素材
批量完成重複性的刪空白工作
先把明顯低價值的時間段壓掉

但真正遇到下面這些工作時，你大多還是會回到傳統編輯器：

精細調整節奏
手動挑出重點片段
加字幕、轉場和 B-roll
調色、混音和最後包裝

所以更實際的定位不是「以後不用 Premiere / Resolve 了」，而是「先讓 auto-editor 做掉機械勞動，再進編輯器裡做精修」。

它可以直接輸出成片，也可以匯出時間線給其他編輯器

這也是 auto-editor 很實用的一點。

如果你只是想快速得到一個已經刪掉空白段的版本，它可以直接渲染媒體檔。
但如果你後面還要繼續精修，官方也支援把時間線匯出到常見編輯器。

README 裡列出的匯出目標包括：

Adobe Premiere Pro：--export premiere
DaVinci Resolve：--export resolve
Final Cut Pro：--export final-cut-pro
Shotcut：--export shotcut
Kdenlive：--export kdenlive
獨立片段序列：--export clip-sequence

例如：

`1`	`auto-editor example.mp4 --export premiere`

這類設計很實用，因為它讓 auto-editor 更像前處理工具，而不是把你鎖死在自己的封閉工作流裡。

它也支援手動補規則，不是只能全自動

很多自動工具一旦判斷錯了，就會讓人很難救回來。

auto-editor 在這方面算是比較靈活，它允許你明確指定某些片段一定刪掉，或一定保留。官方示例裡常見的是：

--cut-out：無論如何都切掉
--add-in：無論如何都保留

例如：

1
2

auto-editor example.mp4 --cut-out 0,30sec
auto-editor example.mp4 --add-in 0,30sec

這表示你不需要把判斷權完全交給程式，而是可以先用自動規則處理大部分工作，再用手動規則補邊角。

官方現在更推薦直接下載二進位檔

從官方安裝頁來看，現在最推薦的安裝方式不是 pip，而是直接下載 GitHub Releases 的二進位檔。

大致流程是：

到 Releases 頁面下載對應平台的二進位檔
重新命名為 auto-editor，或 Windows 下的 auto-editor.exe
在終端裡直接執行
用 auto-editor --help 確認是否安裝成功

如果是平台套件管理器，官方也提到這些方式：

macOS 可用 brew install auto-editor
Ubuntu / Debian 系可用 apt
Arch 系可用 yay -S auto-editor

另外一個值得注意的細節是，官方安裝頁明確提到：新版本已經不再持續發佈到 pip，所以 pip install auto-editor 雖然還看得到，但已經不是首選安裝路徑。

裝了 `yt-dlp` 之後，它也能直接吃 URL

安裝頁裡還有一個很實用的可選依賴說明：如果系統裡已經安裝 yt-dlp，auto-editor 可以直接把 URL 當作輸入來源。

這對某些先抓線上素材、再做自動粗剪的人會很方便。也就是說，它不只處理本地檔案，在某些工作流裡也能直接接線上影片網址。

不過更實際的用法仍然是：先確認素材來源與授權沒問題，再把它放進自己的剪輯流程。

這類工具最適合什麼人

如果你平常做的是強敘事、強鏡頭語言、需要大量人工節奏設計的影片，auto-editor 不會替你做掉最難的部分。

但如果你經常遇到的是下面這些任務，它很可能真的能省下不少時間：

一小時錄屏裡刪掉大量停頓
Podcast 或口播先去靜音再進編輯器
課程影片先做粗剪再補字幕
批量處理結構相似的長素材

它的價值不在於「剪得比人更有審美」，而在於先把最重複、最機械、最耗耐心的第一步自動化。

結語

auto-editor 值得關注的地方，不是它把剪輯變成某種神奇的 AI 黑盒，而是它老老實實解決了一個很具體的問題：怎麼更快做完第一遍粗剪。

如果你把它當成自動刪靜音、刪空白、匯出時間線的前處理工具，它的定位其實很清楚：

不負責最後的精修審美
很適合長素材的第一遍處理
和 Premiere、Resolve 這類傳統編輯器不是替代關係，而是配合關係

對很多教學、錄屏、口播和長影片工作流來說，這種工具往往不是炫技型神器，而是真正在重複勞動上幫你省時間的那一種。