你請 Cursor 點一下 iOS 模擬器裡的按鈕，畫面截得很清楚，助手也說操作完成，App 卻停在原地。這篇 Cursor Computer Use 排錯教學，帶你把「看得到」與「操作有生效」分開檢查，找到下一個值得測試的環節。
本文寫給第一次配置 macOS Worker 的讀者：先用白話看懂原理，再照五步工作單蒐集證據。你需要一台已能使用 Cursor 自架 Worker 的 Mac，以及自己的測試 App；程式片段可交給開發者放入測試專案。重點是學會判讀結果，不必先背作業系統名詞。
以下依 2026 年 10 月 26 日的官方文件與原始回報整理。AlphaLab 本次未執行 Cursor Worker 或 iOS 點擊測試；文中的操作是驗收方法，預期結果與示例分支均不是本站量測。
先說結論：看得到、按下去、做成功，是三張不同收據
有效操作＝看對目標＋送達輸入＋驗證狀態。把它想成按門鈴：監視器拍到門口，不代表電線把訊號送到屋內；屋裡響了一聲，也不代表訪客已經進門。
- 先定義「點擊後應改變什麼」，例如計數由 0 變 1。
- 先測簡單桌面操作，再測同一台 Mac 上的 iOS 模擬器；每次只改一個條件。
- 如果原生 UI 測試通過、桌面點擊失敗，先保留兩條路的證據，別直接判定模型不夠聰明。
一、Cursor Computer Use 排錯原理：拆開四個零件
Worker 是執行工作的電腦程序；Helper 是在 Mac 桌面上代為操作的小程式；座標是畫面上的位置；斷言（assertion）則是測試結束前必須成立的條件。四者像派工員、手、地址與簽收單，任何一段出錯，都可能表現成「點了沒反應」。
依 My Machines 官方說明，Agent 的迴圈在 Cursor 雲端，工具動作在你的機器執行。先到 cursor.com/agents 選對 My Machines 裡的目標機器，再送任務；別把雲端代管桌面、自己的 Mac 與另一台遠端 Worker 混在同一次比較裡。
Mac 的「螢幕與系統音訊錄製」控制 擷取畫面的授權；「輔助使用」則管理 透過輔助功能控制 Mac 的授權。這也是為什麼一張正確截圖，還不足以替滑鼠輸入驗收。
更深一層的觀念是：模型負責選動作，執行層負責把動作送出去；可接著讀 Agent Harness 白話解析。如果工具只回報「請求已送出」，就應再加一個讀取 App 結果的步驟，才形成完整閉環。
二、五步做 Cursor Computer Use 排錯：先建立能簽收的實驗
① 你比較的真的是同一個環境嗎？先固定版本
解法是先留一張環境單。在實際啟動 Worker 的帳號與終端機中，依序執行以下唯讀指令，將輸出存入自己的工作紀錄。這些指令不會替你啟動 Worker、修改權限或更新 Xcode。
sw_vers
xcode-select -p
xcodebuild -version
agent --version
agent worker debug再記下 Helper 的版本、模擬器裝置與 iOS runtime、啟動方式（終端機或 launchd）、當下登入的桌面帳號。若 agent 找不到，先按 官方 My Machines 安裝與登入步驟完成既有環境；若 xcodebuild 指向另一套 Xcode，先把路徑差異寫進紀錄，不急著把不同環境的結果放在一起。
驗收點很簡單：下一位接手的人，能從這張單知道你用的是哪個執行檔、哪個 Xcode、哪個桌面。更新前先存舊版本，更新後重做相同測試，才看得出改動造成的差別。
② 權限開了，卻開給誰？核對 Helper 身分
解法是核對 Cursor Computer Use 本身。依 官方 Computer Use 設定，在已登入的 macOS 桌面，以 agent worker --computer-use start 啟動；CLI 管理的 Helper 位於 ~/.cursor/cursor-computer-use/Cursor Computer Use.app。到「系統設定 → 隱私權與安全性」，分別確認輔助使用與螢幕錄製給了這個 App。
官方指定的 bundle identifier 是 co.anysphere.cursor-computer-use。授權 Terminal 或 Cursor 主程式，不會轉移到它。若系統要求結束並重開，停止 Worker 後再啟動；保持 Worker 所用帳號的 GUI 桌面登入。agent worker debug 能確認安裝，不會證明兩項權限已通過。
接著請 Agent 在自己的空白測試頁按一個無害按鈕，再擷取新畫面。驗收必須同時看見新截圖與預期狀態。不要為了排錯重簽 Helper、編輯 macOS 隱私資料庫或關閉 SIP；官方要求由 CLI 管理 App，權限走系統設定或既有 MDM 流程。
③ 什麼才叫成功？用只有一個按鈕的 App 定義結果
解法是把結果做得可見、可讀、可重設。請開發者建立一個 SwiftUI 測試 App，把 ContentView 換成下面的最小畫面，使用測試專案原有的 App 入口，在指定模擬器啟動。它不連網、不登入，也不使用真實帳號資料。
import SwiftUI
struct ContentView: View {
@State private var count = 0
var body: some View {
VStack(spacing: 24) {
Text("Count: \(count)")
.accessibilityIdentifier("tapCount")
Button("Tap once") { count += 1 }
.accessibilityIdentifier("tapProbe")
}
.padding(40)
}
}這是自製教學程式，未在本次執行中建置或跑過 iOS。它只示範本機計數；沒有持久化、資料同步或網路錯誤處理。測試用識別字依 Apple 的 accessibilityIdentifier 文件設定，讓後面的測試找得到同一個按鈕。
先由你手動按一次，確認 Count: 0 變為 Count: 1；完全結束測試 App 再重新啟動，確認回到 0，再請 Agent「只點 Tap once 一次，然後讀出 Count」。若它只回覆「完成」，追問實際讀到的數值與操作後畫面。示例的 0 → 1 是通過條件，不是已發生的測試結果。
④ 桌面可以、模擬器不行？用對照縮小問題
解法是同一台機器、兩種操作路徑、同一個結果。先在自己的桌面測試頁驗證按鈕，再測 iOS 的計數 App。每次固定視窗位置、縮放與裝置方向，將目標放到前景，關閉會遮住它的選單或彈窗，截取操作前的新畫面。
- 手動點擊也失敗：先看 App 是否可互動、有無遮罩，別把這個結果算成 Cursor 的專屬故障。
- 桌面與 iOS 都失敗：優先重查 Helper、帳號、權限與目標機器；這是排查順序，不是確診。
- 桌面成功、iOS 失敗：記錄兩者差異，再測模擬器內的原生 UI 路徑。
- 改動視窗位置後才失敗：把座標換算列為待查假設，重新截圖再定位，不沿用舊座標。
若工具提供的座標基於縮小截圖，便需要知道它如何映射到桌面；不要憑 Retina 的名詞就直接把數值乘二。一次只改縮放或位置其中一項，記錄是否恢復。這種對照只能縮小可疑區段；沒有輸入事件證據時，還不能分清是座標、焦點或特定事件傳遞機制。
⑤ 換原生 UI 路徑能通嗎？加上狀態斷言
解法是另外建立一條可追蹤的對照。若團隊已有 Maestro，可用 Maestro Studio選取元素確認識別字，再存成以下 Flow；把 com.example.TapProbe 換成你測試 App 真正的 Bundle ID。這裡不為排錯另裝 Java、SDK 或大型 runtime。
appId: com.example.TapProbe
---
- launchApp
- assertVisible: "Count: 0"
- takeScreenshot: before-tap
- tapOn:
id: "tapProbe"
- assertVisible: "Count: 1"
- takeScreenshot: after-tap先用 xcrun simctl list devices booted 找到裝置 UDID，再依 指定裝置文件執行 maestro --device YOUR_UDID test tap-probe.yaml，將 YOUR_UDID 換成同一模擬器的識別碼。tapOn負責動作，assertVisible負責等候並檢查畫面，takeScreenshot留下 PNG。若起始不是 0，先重設測試 App，別刪掉起始斷言讓測試假通過。
Maestro 的 iOS 架構說明將操作描述為經 iOS 輔助使用層與原生觸控事件完成。另一條路是團隊既有的 XCTest／XCUIAutomation：找到按鈕、操作，再檢查計數文字。Apple 的 UI 測試錄製教學明確要求互動後加入狀態斷言；waitForExistence則只等待元素存在，仍要另外驗證操作後的值。
假設你得到「手動通過、Maestro 通過、Cursor 桌面通過、Cursor iOS 失敗」四筆紀錄，可以說：同一個 App 在不同路徑出現不同結果，值得追查桌面到模擬器這一段。這不是證明某個工具全面不支援 iOS，也不是保證換 Maestro 就能修好 Cursor。兩者的用途在這裡是交叉定位。
三、Xcode 27 的原始回報，能告訴我們多少？
2026 年 10 月 25 日的 Cursor 論壇原始求助，發文者自述 macOS 27.0.1、Xcode 27.1、CLI 2026.10.22-27dcf5f、Helper 0.0.1003：截圖正常，Device Hub 中的 iOS 點擊未生效，同機 Android 與 Maestro 操作正常。這些是回報者提供的配置與觀察，AlphaLab 未獨立驗證。
它的價值是提供對照方向，而不是給出所有環境通用的結論。本文不採納「某版本已全面移除獨立 Simulator」或「Device Hub 必然擋掉事件」作為既定原因。若你的介面與回報不同，記錄實際開啟的 App 與版本，不為了套案例而更動整套開發環境。
送出問題時，附上環境單、最小 App、同一目標的操作前後畫面、每條路徑的起始與結束狀態，以及只改一項條件的對照。先遮掉帳號、通知、憑證與其他專案內容。比起「AI 點不到」，「相同按鈕在 A 路徑變成 1、B 路徑維持 0」更容易讓維護者接手。
四、三個常見坑：重試、畫面差異與備援
第一個坑是無限重試。對自己的計數 App，一次只點一次；每次都留結果。若遇到會送出訂單、刪除資料或重複扣款的動作，先停止自動點擊，改用隔離測試資料與可撤回的練習流程。
第二個坑是只比較整張圖有沒有變。時鐘、游標、動畫會改變像素，卻不一定代表目標按鈕生效。先檢查 Count 或 App 的可觀察狀態，截圖作輔助；不要把畫面差異本身當成功率。
第三個坑是備援偷偷變成驗收。人工或原生 UI 測試可以讓開發繼續，但報告要寫清楚是哪條路通過。如果 Cursor 的 iOS 路徑仍失敗，就保留該失敗；把修復前後的同一測試都跑通，才關閉這個問題。想把工具結果與停機條件接好，可讀 建立 Agent Harness 的流程拆解；瀏覽器任務的證據邊界則可搭配 Chrome DevTools MCP 前端驗證。
五、常見問題 FAQ
截圖成功，就代表權限都好了嗎？
不代表。畫面擷取與輸入操作要分開驗收；用會改變明確狀態的無害按鈕做第二個測試。
debug 顯示 Helper 已安裝，可以跳過點擊測試嗎？
不能。官方區分安裝狀態與權限驗證；還要完成實際截圖與操作。
把權限給 Terminal 就夠了嗎？
不夠。這個 Worker 流程應核對 Cursor Computer Use 的授權與所用桌面帳號。
應該直接把 Retina 座標乘二嗎？
先不要。先確認工具的座標基準與截圖尺寸，再以固定視窗做單一變因對照。
Maestro 通過，代表 Cursor 的模型有問題嗎？
不代表。只能顯示不同操作路徑的結果不同；定位與事件傳遞等環節仍待查。
Xcode 27 使用者一定會遇到這個問題嗎？
目前這篇引用的是一則指定配置的原始回報。它不足以估計受影響人數，也不足以判定你的配置。
看見按鈕，就能立刻點嗎？
不一定。先讓目標穩定並可互動；需要時依 Maestro 等候文件加入條件等待，別用盲目連點替代驗證。
沒有 Maestro，還能照做嗎？
可以。先完成人工、桌面與模擬器三組對照；已有 XCTest 的團隊再用原生 UI 測試補第四組，不必先添購工具。
給新手的三個重點
- 先把「成功」寫成狀態變化，讓工具回報有可核對的對象。
- 版本、帳號、視窗與起始狀態固定後，再一次改一項條件。
- 把哪條路通過、哪條路失敗分開記錄，留下別人能接手的證據。
接著閱讀
左右滑動查看更多推薦
下一步：先取得一筆可簽收的點擊
現在只選一個無害按鈕：留下環境單，記錄操作前的 0、請工具點一次、核對操作後的 1。有效操作的等式——看對目標＋送達輸入＋驗證狀態——走完這一圈，才值得擴大成整段 App 測試。想繼續安排學習路線，可以從 AI 文章總覽或 AlphaLab 課程挑下一個練習。