TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
AXe：用終端機與 AI agent 驅動 iOS 模擬器 UI 的開源 CLI
AXe 是 cameroncooke 開源的 MIT 命令列工具，把 Meta idb 的 HID 底層包成單一執行檔，用來驅動 iOS 模擬器的觸控、文字輸入、硬體按鈕、截圖與錄影，並透過 axe init 原生對接 Claude Code 等 AI coding agent。本文整理它與 xcrun simctl、idb 的分層定位、代表性 batch 用法，以及裝之前要先接受的五個限制。
用 AI 摘要這篇文章：
AXe 是一個 MIT 授權、Swift 寫成的命令列工具，專門在 macOS 上驅動 iOS 模擬器的 UI 互動。點擊、滑動、輸入文字、按硬體按鈕、截圖、錄影，都能從終端機一行指令完成。它要補的不是蘋果原生 xcrun simctl 已經做的事，而是 simctl 沒有涵蓋的那一層：在已經開機的模擬器上，怎麼跟畫面反覆互動。
一個必須先講清楚的限制：AXe 只驅動模擬器，不支援實機；底層走的是蘋果私有（非公開）的 Accessibility API，這是多數進階模擬器自動化工具共同的代價。如果你要做實機測試，或想把 CI 跑在 Linux 上，這工具不符合需求。
AXe 站在 Meta idb 的肩膀上，不是從頭打造
AXe 的 README 與授權檔把它的出身講得很清楚：AXe 是「從一個固定的 idb fork revision 構建，不加本地 patch 佇列」地使用 Meta idb 的框架。idb 是 Meta 開源的 iOS 自動化套件，走 client/server 架構，透過 RPC 協定溝通。AXe 把 idb 已經驗證過的 HID（Human Interface Device，人機介面裝置）底層包起來，做成單一執行檔，不需要開 daemon。
這個出身值得讀者注意，因為它回答了「AXe 會不會是另一個沒人驗證過的 HID 實作」這層疑慮。README 進一步交代，AXe 從一個固定的 idb fork revision 構建，不加本地 patch 佇列，這代表它的 HID 核心跟 idb 主線是可追蹤的對應關係，而不是 fork 出去自己改到分岔。
AXe 在 README 第一行自稱是 comprehensive（涵蓋完整）的 CLI 工具，要注意這是作者自己的宣稱，不是第三方實測結論。repo 的描述欄同時點明它用的是 Apple’s Private Accessibility APIs（蘋果私有 API），這個「private」是評估長期維護風險的關鍵字。
一行 batch 指令跑完整個登入流程：AXe 的代表性用法
想理解 AXe 解決什麼，看官網首頁與 docs 文件都拿出來當樣本的 batch 指令最快。你把一連串 UI 步驟寫進一個檔案，AXe 會按順序執行。
# login-flow.steps 檔案內容（官方範例）
tap --label "Email"
type "[email protected]"
tap --label "Password"
type "s3cureP@ss"
tap --label "Sign In"
sleep 2在終端機一行呼叫：
axe batch --file login-flow.steps --udid <UDID>這個範例展現了 AXe 的核心價值：你不用為了跑一個登入流程去架一個 XCUITest 專案，也不用先啟動 idb daemon，只要會寫步驟清單，就能在已經開機的模擬器上把多螢幕流程跑完。tap --label 走的是 accessibility 樹（無障礙樹）選擇器，比單純算座標點擊更耐得住 UI 微調。
不過這個範例也劃出了接觸層級的邊界：官網與 docs 都沒有給出這段流程實際會花多少毫秒的數字。repo 的 scripts 目錄附了一支 benchmark_batch.sh 腳本讓你自己量，本文不替你宣稱結果。
batch 預設是 fail-fast，遇到第一個錯誤就停；加 --continue-on-error 會換成 best-effort 模式，把能跑的步驟跑完。batch 的設計也把驗證拆到指令外面做：跑完之後另外用 axe describe-ui 或 axe screenshot 去看畫面狀態，而不是期待 batch 自己回報成不成功。這個「執行」跟「驗證」分離的設計，對寫測試的人是好事：你可以用同一份 steps 檔重跑，再用不同的驗證方式比對。
describe-ui：讓 AXe 能驗證、而不只是能點
很多 CLI 自動化工具只能「做動作」，不能「看結果」。AXe 補上這塊的關鍵指令是 describe-ui，它會倒出目前畫面的 accessibility 樹，讓你知道每個元素的可點擊區域、label、id。
# 倒出全畫面無障礙資訊
axe describe-ui --udid <UDID>
# 只看某個座標點上的元素
axe describe-ui --point 100,200 --udid <UDID>這個指令的價值在於它讓 selector 式點擊（tap --label、tap --id）變得可偵錯。當 tap --label "Sign In" 沒反應時，你不用瞎猜，先跑一次 describe-ui 看 label 是不是叫「Sign in」（大小寫不同）或被 Localized 字串改掉了。它同時是 AI agent 能在迴圈裡自我修正的基礎：agent 點完之後可以呼叫 describe-ui 比對預期畫面，決定要不要重試。
手勢類操作 AXe 也整理了一組 preset，不用每次都算座標 delta：
| preset | 做什麼 | 常見用途 |
|---|---|---|
| scroll-up／scroll-down | 在畫面中央上下捲 | 內容導覽 |
| scroll-left／scroll-right | 左右捲 | 水平滑動 |
| swipe-from-left-edge | 從左邊緣往右滑 | 回上一頁 |
| swipe-from-top-edge | 從上往下 | 關閉／下拉通知 |
這組 preset 讓「常見手勢」不必每次重寫參數，對維護一份共用的 steps 檔有實際幫助。
跟 xcrun simctl、Meta idb 是分層關係，不是二選一
讀者在評估時最容易搞混的，是 AXe、simctl、idb 三者的相對位置。用一句話講：simctl 管裝置生命週期，idb 管全套自動化但需要 daemon，AXe 是 idb 那套 HID 互動層的單檔封裝。
| 工具 | 蘋果原生？ | 需要跑 daemon？ | 主要層級 |
|---|---|---|---|
| xcrun simctl | 是 | 否 | 裝置管理（boot、erase、install、screenshot） |
| Meta idb | 否（Meta 開源） | 是（client/server RPC） | 完整自動化，涵蓋實機與模擬器 |
| AXe | 否（社群開源） | 否（單一執行檔） | 模擬器 UI 互動，站在 idb 底層上 |
這張表是依官網首頁對 AXe 的產品定位與蘋果 simctl 文件整理出來的分層，不是效能比較。如果你的需求只是開機、裝 app、截圖，simctl 就夠了，不必裝 AXe；如果你已經在跑 idb daemon 且用得很順，AXe 對你沒有迫切需求。AXe 真正的甜蜜點，是「想要 idb 的 HID 能力、又不想在 CI 環境多顧一個 daemon」的那種情境。
axe init：讓 Claude Code 與其他 AI agent 直接驅動模擬器
AXe 在 2026 年特別值得寫的角度，是它原生對接 AI coding agent。官網首頁與 docs 寫的 axe init 指令會把 AXe 的 skill 檔裝進 ~/.claude/skills 與 ~/.agents/skills，裝完之後，Claude Code、Cursor 這類工具就能直接呼叫 AXe 指令去點畫面、輸入文字、截圖驗證。
這條路由跟你在終端機自己敲 axe 指令是同一套，差別在於 agent 能根據畫面回饋決定下一步。官網首頁直接標示 AI Agent Ready，並展示一段讓 AI agent 自動測登入流程的範例，這是 AXe 相較於單純 CLI 工具多出來的一層價值。如果你本來就在用 Claude Code 的 skill 生態或 agent skill 建構工具，AXe 的 axe init 走的是同一條「把工具能力包成 agent 可呼叫技能」的方向。
裝之前要先接受的五個限制
工具導覽最怕讀者裝完才發現不適用，這段把會改變結論的條件集中講。
- 只驅動模擬器，不支援實機：GitHub 描述、README 與官網全篇都以 Simulators 為範圍。做實機 UI 測試請改找 XCUITest 或 idb 的實機模式。
- 要 macOS 14+ 與 Xcode 26 或 27：官網標示 macOS 14+，README 的 Xcode compatibility 段標明只支援 Xcode 26 與 27。舊版 Xcode 或 Linux CI 環境不適用。
- 底層是蘋果私有 API：repo 標題原文用 Private Accessibility APIs。私有 API 不在蘋果公開穩定介面裡，iOS 或 Xcode 大改版時有失效風險，這是同類工具共同的代價，不是 AXe 獨有缺陷。
- 不是 Deque 那個 axe：README 結尾有免責聲明，AXe 與 Deque Systems 的 axe 無障礙檢測產品無關。網路上更知名的 axe 是 Deque 的 web 無障礙工具，這個 AXe 是 iOS 模擬器 CLI，兩者完全不同領域。
- 星星數不等於品質保證：觀測日（2026-08-06）用 GitHub API 看到 2117 顆星、86 forks、10 個開啟 issue，最近一次程式碼推送在 2026-07-21，顯示專案在活躍維護，但社群熱度跟「適不適合你的場景」是兩件事。
v1.8.0（2026-07-20 發布）是近期最值得注意的版本更新，它加入 Xcode 27 與 iOS 27 模擬器自動化，走 Device Hub，不需要開 Simulator.app，同時保留 Xcode 26 支援。在評估要不要賭 Xcode 大改版風險時，這條更新節奏是加分訊號。
三分鐘裝好並跑第一個指令
安裝走 Homebrew，在 macOS 終端機輸入兩行：
brew tap cameroncooke/axe
brew install axe裝完先確認指令清單：
axe --help接著列出目前機器上的模擬器，拿到 UDID：
axe list-simulators先用 Xcode 開好一台模擬器（或用 xcrun simctl boot <UDID> 開機），再下第一個點擊指令試水：
axe tap -x 100 -y 200 --udid <UDID>如果你想接 AI agent，再把 skill 裝起來：
axe init --client claude到這裡，你已經能把模擬器 UI 互動腳本化，或交給 Claude Code 代跑。想更進一步把流程編排成可重現的步驟檔，只要回頭把指令寫進 .steps 檔餵給 axe batch 就好。
把錄影當 CI 失敗證據：record-video 與 stream-video
CI 跑 UI 測試最常見的痛點是「本地綠、CI 紅，又看不到畫面」。AXe 的 record-video 指令直接把模擬器畫面錄成 H.264 MP4，適合丟進 CI artifact：
axe record-video --udid <UDID> --fps 15 --output recording.mp4按 Ctrl+C 停止，AXe 會先把 MP4 收尾寫完再離開，並把檔案路徑印到 stdout，方便腳本接手。--quality 與 --scale 可以在頻寬有限時降檔。
如果你要即時畫面串流（例如接給遠端監看或自架測試平台），stream-video 可以輸出 MJPEG、raw JPEG、ffmpeg 相容格式，或舊版 BGRA：
axe stream-video --udid <UDID> --fps 30 --format ffmpeg | \
ffmpeg -f image2pipe -framerate 30 -i - -c:v libx264 -preset ultrafast output.mp4v1.8.0 順便修了一個會影響錄影的 bug：BGRA 串流過去會忽略 --fps、以未限速的影格率跑，現已修正。這條修復說明錄影功能在近期版本才穩定下來，挑版本時建議直接用 v1.8.0 或之後。
硬體按鈕與鍵盤組合：覆蓋測試容易漏掉的互動
除了觸控與文字輸入，AXe 也把硬體按鈕獨立成一個指令族，每個按鈕都能帶持續時長參數：
axe button home --udid <UDID>
axe button lock --duration 2.0 --udid <UDID>
axe button siri --udid <UDID>可模擬的按鈕對應 iOS 裝置上的 Home、Lock/Power、Side（iPhone X 之後的側邊鍵）、Siri、Apple Pay。這些按鈕在實體裝置上要靠手按，在自動化流程裡通常是「測深景」才會碰到（例如測試 Siri 啟動後的語音流程、或側邊鍵雙擊喚出 Apple Pay），多數 UI 測試不會天天用，但缺了它們就測不到邊角情境。
鍵盤組合是另一組對文字編輯場景很實用的指令：
# Cmd+A（全選）這類 atomic modifier 組合（docs command-reference 範例）
axe key-combo --modifiers 227 --key 4 --udid <UDID> # Cmd+A所謂 atomic（不可分割）是指 modifier 跟主鍵被當作一次動作送出，不會被模擬器拆成兩個獨立事件。對於要測試文字編輯流程（剪下、貼上、復原）的腳本，這比逐一按下 Shift、Cmd 再放開更可靠。
時間控制是貫穿所有指令的共同參數。幾乎每個動作都能帶 --pre-delay 與 --post-delay，這對付會抖動的 UI（畫面還沒畫完就點）很有用：你在步驟之間插一個 0.5 秒延遲，比寫 sleep 一步步算座標更省事。這組參數在 batch 裡也能用 sleep N 當獨立步驟，差別在於 pre/post-delay 是綁在特定動作上，語意更清楚。
為什麼「單一執行檔、無 daemon」對 CI 重要
idb 的 client/server 架構不是缺陷，而是它能同時吃實機跟模擬器、提供完整自動化能力的設計代價。但對一個只跑模擬器 UI 流程的 macOS CI runner 來說，多一個 daemon 意味著 Docker image 要多裝一層服務、冷啟動要先等 daemon 起來、失敗時要分清楚是 client 還是 server 出問題。
AXe 的單檔設計在這個切面上省事。官網首頁用「Single binary, no servers, no dependencies」描述這個定位，對應到的實際場景是：你把 axe 二進位丟進 CI image，boot 一台模擬器，直接呼叫 axe batch，流程結束就結束，沒有背景服務要清。對於想把 iOS UI 煙霧測試塞進既有 CI pipeline、又不想為此多養一套 idb 部署的團隊，這個差異比帳面規格更值得納入決策。
如果你需要 pin 版本或稽核 AXe 用的 idb fork，repo 的 scripts/build.sh（README 在 IDB 構建段落引用的同一支腳本）提供了從原始碼構建的路徑，E2E 開發流程並要求 XcodeGen 來產生 idb 專案。這條路比 Homebrew 麻煩，但對有供應鏈審計要求的企業導入來說，是個實際的查核點。
誰該裝、誰可以先跳過
AXe 適合的人很明確：在 macOS 上做 iOS 開發或測試、想用終端機或 AI agent 批次驅動模擬器 UI、又不想為了 idb daemon 多顧一個服務的團隊。如果你同時也在找 Android 端的自動化方案做對照，或想知道 瀏覽器端的自動化 CLI 怎麼跟 AXe 搭，那條跨平台線就是這篇之外要自己兜的部分。
可以先跳過的人也講清楚：只做實機測試、用 Linux CI、或已經有 idb daemon 跑得很順的團隊，AXe 帶來的增量有限，不必為了裝而裝。AXe 的價值不在它「取代」了誰，而在它把 idb 驗證過的 HID 層，做成一般開發者 brew install 完就能上手、AI agent 也能直接呼叫的單檔 CLI，這在 2026 年 AI agent 開始大量接手終端機工作的脈絡下，是個實際的定位。
一個判斷基準提供給還在猶豫的讀者：如果你的 iOS UI 流程目前是用 XCUITest 寫、跑得很穩，沒有特別痛點，那 AXe 對你是「備用工具」而不是必裝；如果你正想在 CI 加一層模擬器煙霧測試、或想讓 Claude Code 幫你跑一遍登入與結帳流程順便截圖存證，那 AXe 的單檔＋agent skill 設計就是為這類情境而生。先跑一次 axe describe-ui 看你目標 app 的無障礙樹品質，再決定要不要把整套 steps 檔搬過來，會比直接重寫測試省很多冤枉路。
