Hub 達人實戰

達人實戰 · 開發與維運

APP 開發達人：別再當 Xcode 和 Claude Code 之間的人肉傳話筒

你是不是也受夠了每次改完 UI 都要切去 Xcode 或 Android Studio 手動 build、裝模擬器、肉眼核對？這篇整理獨立開發者到團隊工程師怎麼把整條驗證迴圈交給 Claude Code 自己跑完，讓你專心寫邏輯，不當人肉傳話筒。

這行的痛點

App 開發的日常有一個特別磨人的迴圈：改一行程式碼，切去 Xcode 或 Android Studio 按 build，等模擬器開機，肉眼核對畫面對不對，出錯了再把錯誤訊息複製貼回聊天視窗——整個人變成 AI 與 IDE 之間的傳話筒。獨立 iOS 開發者 twocentstudios 開發電車時刻表 App 時就點出這個核心浪費：「編譯器抓低級語法錯誤……讓人來處理是巨大的時間浪費」。

這正是 CLI AI 工具的強項：Claude Code 能直接呼叫 xcodebuild、simctl、adb 這些指令列工具，把「build → 裝機 → 啟動 → 讀 log → 截圖 → 判斷 → 修正」整條流程收進同一個 session，不需要離開終端機。掛上 XcodeBuildMCP 這類 MCP 之後，Claude 甚至能自己操作模擬器裡的手勢、自己讀 crash log，比對截圖判斷 UI 對不對。

換成團隊規模，這套做法一樣行得通。Cars24 的資深行動工程師 Ankit Bhalla 把 Claude Code 從「個人玩具」升級成團隊工程系統——CLAUDE.md 定架構規範、subagent 分攤 context、hooks 擋掉不合規的程式碼，導入 TDD 迴圈後新元件的 QA bug 回報降了約六成。這說明 App 開發不只是叫 AI 寫程式，而是把測試、review、確定性防線這套工程紀律用 CLI 工具串起來。

不過這行也有明顯的天花板：視覺結果的最終判斷還是要人眼。多位獨立開發者都實測過 Claude「自信地說畫面修好了，但明明還是壞的」——AI 能自動跑完整條驗證流程，但「好不好看」這件事永遠得靠你自己盯著螢幕看一眼。

動手前的準備

  • 先看 Claude Code 教學第 2 章（安裝 Claude Code），把 CLI 裝好、登入帳號。
  • 先看 Claude Code 教學第 5 章（CLAUDE.md 與工作記憶）——這章會反覆用到 CLAUDE.md 存 build 指令與架構慣例。
  • 先看 Claude Code 教學第 9 章（連接工具 MCP）——這職業幾乎離不開 XcodeBuildMCP 這類 MCP server。
  • iOS 開發需要 Xcode（Xcode 26.3 起才有 Apple 原生 MCP xcrun mcpbridge）；Android 開發需要 Android Studio 與 JDK；React Native、Flutter 依各自官方環境設定安裝好。
  • 外掛、MCP 與社群套件不是必要安裝項。先確認來源、版本、會讀取的資料與要求的權限，並在測試專案驗證；API key 不進版控、不貼進對話。若必須放寬網路或寫入範圍，只限目前專案的必要目錄與必要時間，不要擴到整個使用者資料夾或正式環境。
  • 若走 Codex CLI 對照，先看 Codex CLI 教學第 2 章（安裝）與第 8 章（config.toml 個人化設定）——行動開發常要打開 network_access 與 writable_roots 這類沙盒設定，不然 pod install、gradle sync 會被擋掉。

場景一：iOS 開發閉環

獨立 iOS 開發者 twocentstudios 開發日本電車時刻表 App「Eki Bright」時，受夠了「改完程式碼、切去 Xcode 按 build、裝模擬器、開 App、肉眼看結果、把錯誤貼回去」這個迴圈裡自己只是傳話筒的角色，決定把整條流程交給 Claude Code 自己跑完。

Claude Code 怎麼做

  1. 把 DerivedData 移到專案資料夾內，安裝 xcsift（brew install xcsift）把 xcodebuild 的天書輸出轉成看得懂、能直接處理的 JSON 錯誤，把專案位置與 scheme 名稱寫進 CLAUDE.md。

  2. 用 xcodebuild + xcsift 編譯：

    xcodebuild -project train-timetable.xcodeproj -scheme "train-timetable" \
  -destination "platform=iphonesimulator,id=<UDID>" \
  -derivedDataPath DerivedData -configuration Debug build 2>&1 | xcsift -w

  3. 裝機啟動：

    xcrun simctl install <UDID> "DerivedData/Build/Products/Debug-iphonesimulator/Eki Bright.app"
xcrun simctl launch <UDID> com.twocentstudios.train-timetable

    要跳到特定頁面可以直接用 universal link：xcrun simctl openurl <UDID> "train-timetable://tab?name=search"。

  4. 讀 log：小輸出用阻塞式 xcrun simctl launch --console-pty --terminate-running-process ...；要長時間監看就讓 Claude Code 開一個 run_in_background: true 的背景任務盯 OSLog。

  5. 操作模擬器：裝 AXe CLI，截圖後用 ImageMagick 縮到 1x 讓座標對齊，再用 axe tap -x 201 -y 297 --udid <UDID> 點擊、axe gesture swipe-from-left-edge 滑動。

  6. 把環境設定（模擬器 UDID、App 二進位路徑、bundle id、OSLog 過濾條件）寫死進 CLAUDE.md，省得每次重查。

要注意：--terminate-running-process 一定要加，不加的話舊實例會留在模擬器記憶體裡，log 全空，Claude 看不到錯誤訊息就會開始亂改一通；手勢命名（scroll-up 到底是手指往上滑還是內容往上捲）也要在 CLAUDE.md 講清楚，不然會混淆模型判斷。

換成 Codex CLI

Codex 官方 iOS use-case 頁講的心法幾乎是同一條路：CLI-first——用 xcodebuild 列 scheme、跑 build/test/archive，讓 agent 留在流程裡、不進 Xcode GUI；每次改動先在小範圍內驗證，確認沒問題才擴大到完整 build。設定上要留意 Codex 特有的沙盒坑：行動開發需要網路（pod install、gradle sync、SPM）與模擬器目錄寫入權，得在 .codex/config.toml 明確打開：

sandbox_mode = "workspace-write"

[sandbox_workspace_write]
writable_roots = ["~/Library/Developer/CoreSimulator", "/tmp"]
network_access = true

Codex 側也有第一手實測（azukiazusa.dev，一位零 iOS 經驗的網頁工程師）：用 Codex 雲端版加 build-ios-apps plugin 做 TODO App，靠 list_schemes → build_run_sim → screenshot 這樣的順序迭代，但也踩到模擬器名稱對不上（「iPhone 16」不存在）、iOS Simulator Runtime 沒預裝要進 Xcode GUI 手動裝這類坑。

場景二：RN 團隊工程化

Cars24 的資深行動工程師 Ankit Bhalla（14 年以上行動開發資歷）要解的不是「怎麼叫 AI 寫程式」，而是怎麼把 Claude Code 變成團隊可依賴的工程系統——他的核心主張是「把 Claude 當你架構出來的系統，不是你隨口聊的聊天機器人」。

Claude Code 怎麼做

  • CLAUDE.md 是地基：寫進架構決策、程式碼規範、檔案結構、測試方法。Bhalla 實測寫得好的 CLAUDE.md 能把「錯誤架構」建議減少約 70%。
  • 用 /init 掃 codebase 生初版 CLAUDE.md；日常 90% 時間先用 Shift+Tab 進 plan mode 再動手；用 @ 檔案參照減少幻覺。
  • 掛 Callstack「React Native Best Practices」等 plugin，依上下文自動觸發；自訂 skill 自動幫新的 RN feature module 搭好鷹架。
  • 用 subagent 省 context：自己查可能吃掉 170K token，subagent 在自己的 context 做完只回傳 5K token 摘要。他自訂了一個「rn-perf-auditor」subagent 專查七類效能問題（FlatList 設定錯誤、缺 React.memo 等）。
  • Hooks 做確定性防線：PreToolUse 在寫完 .tsx 後跑 TypeScript 驗證；Stop hook 完工時發原生通知。
  • 日常五步：plan mode 分析 → subagent 調查既有相似模式 → 實作 → /review 審 staged 變更 → 換功能前 /compact。
  • TDD 迴圈：先寫會失敗的測試（不寫實作）→ plan mode 檢查測試覆蓋 → 實作到通過 → !npx jest 驗證。

他把 /review 當每個功能收尾前的固定動作，讓一雙全新 context 的眼睛審過 staged 變更再收工：

/review

導入這套 TDD 工作流後，Bhalla 團隊新元件的 QA bug 回報降了約六成。他也點出最常見的失敗模式：「開發者從不用 /compact 或 /clear，45 分鐘的 session 裡 Claude 逐步忘掉 CLAUDE.md 慣例……開始產出垃圾」——context 管理是紀律，不是選配。

換成 Codex CLI

React Native 側 Codex 吃的是同一套 Callstack 生態：

npx codex-plugin add callstackincubator/agent-skills

裝進去後有 Building（Callstack、Vercel 最佳實務、RN 升版）與 Testing（RN 測試、Agent Device 模擬器控制、Dogfood 探索式 QA）兩組 plugin 可用，跟 Claude Code 側掛的 plugin 是同一個生態圈，可以依團隊工具鏈習慣二選一。

場景三：Flutter 工程

一位開發金融類 App（電子錢包）的 Flutter 工程師要解的問題是：AI 在傳統 layer-first（models/、services/、widgets/）結構裡「要跨資料夾拼湊每個功能在幹嘛，會犯錯」，加上 AI 常亂改生成檔、亂加套件。

Claude Code 怎麼做

  • CLAUDE.md 必含指令區（flutter pub get、dart run build_runner build --delete-conflicting-outputs、flutter analyze、flutter test、flutter run）、架構總覽、慣例，以及明確的「What NOT to do」：不先問就不准加新套件、不准直接改 *.g.dart／*.freezed.dart。關鍵原則是「CLAUDE.md 要反映程式碼現在實際的樣子，不是理想中的樣子」。
  • 改用 feature-first 結構：每個功能自成模組，理解轉帳流程所需的一切都住在 lib/features/transfer/ 裡。
  • Hooks 做確定性防線：PreToolUse 直接擋掉對 *.g.dart／*.freezed.dart 的編輯；Stop hook 在 session 收尾前強制跑 flutter analyze——「Hooks 是確定性的，不管 Claude 決定什麼都會執行」。
  • 用 .claude/skills/<name>/SKILL.md 放重複性任務，例如 flutter-release（出 APK 的多步檢查清單）、commit（conventional commits）。
  • 用 /loop 跑測試迴圈： 
    /loop
Run: flutter test --name "WalletNotifier"
If test fails, read failure output and fix minimally
Do not change the test itself
Run test again
Stop when test passes with no errors
    同型的 lint 迴圈就是「跑 flutter analyze，逐條修到零 issue 為止」。
  • 用 subagent 平行開畫面：像把每個畫面交給不同工程師，同時派三個 subagent 分別做交易紀錄、轉帳、儲值三個畫面。

金額處理有條鐵則要寫進規範：一律用最小單位存 int，永不用 double 存錢；加套件必須人工核准，AI 很愛順手 pub add。

換成 Codex CLI

Codex CLI 目前找不到 Flutter 這職業的第一手案例，但用它的通用能力應該也能做到類似效果：把上面這套 CLAUDE.md 慣例原封不動搬進 AGENTS.md（指令區、What NOT to do、feature-first 慣例），Codex 一樣讀得懂；/loop 這類迴圈可以換成 Codex 的窄驗證心法（每次改動先跑小範圍測試，過了才擴大）做出同樣「修到測試綠燈為止」的效果，只是目前沒有實測數字可以佐證成效。

場景四：Android 對照

InfernoRed 工程師 Charlie Castro 想把 Claude Code 引進日常 Android 工作（Kotlin、Jetpack Compose、MVVM、Hilt），要解掉的是樣板碼、重複修錯、查語法這三類磨損。

Claude Code 怎麼做

  • 安裝 Node.js 18+、npm install -g @anthropic-ai/claude-code，首次啟動走 OAuth 連 Anthropic 帳號。
  • 在專案根目錄建 CLAUDE.md 當專案記憶：build 指令（./gradlew assembleDebug）、測試流程、技術堆疊（Kotlin／Compose／MVVM／Hilt）、程式碼慣例，免去每個 session 重講一遍。
  • 三個高頻功能：@path/to/File.kt 精準指檔、/clear／/compact／/model 管 session、Shift+Tab plan mode 先看計畫再放行。

範例 prompt：

Create a simple counter app in Jetpack Compose with a ViewModel and dependency injection setup.

Claude 會直接生出含 ViewModel 與 DI 設定的完整程式碼。Castro 的心得很白話：「移除拖慢我們的摩擦——樣板碼、重複修錯、查語法的時間」。

要注意 Gradle 冷啟動常要 10–30 秒（這點延伸自通用開發建議，非本案逐一驗證），有些開發者會讓 Claude 只改程式碼、build 留在 Android Studio（增量編譯已暖機）裡跑。

換成 Codex CLI

Android 這題反而是 Codex 側資料更完整：Google 官方對 android-cli 做了系統化的 agent 支援——android init 會自動把 android-cli skill 裝進偵測到的 agent（含 Codex CLI）。建專案到跑起來全部走 CLI：

android create --output=./MyApp --name=com.example.myapp empty-activity-agp-9
android emulator create --profile=medium_phone
./gradlew assembleDebug
android run --apks=...

還有給 agent 用的 UI 自動化三件套：android screen capture --annotate（截圖加帶編號的元件框）、android layout --output=hierarchy.json、android screen resolve --string="input tap #5"，以及查文件用的 android docs search 'Jetpack Compose performance optimisation'。這套 skill 機制通用，Claude Code 同樣掛得上，等於兩套 CLI 可以共用同一組 Android 工具。要注意限制：android-cli 沒有專門的 gradle 子指令，要直接編輯 build.gradle.kts；Windows 上 android emulator 這個子指令是停用的。

常踩的坑

四個常踩的坑

  • 不加 --terminate-running-process 會靜默啟動失敗（達人實測，twocentstudios）：舊 App 實例留在模擬器記憶體裡，log 全空，Claude 看不到任何錯誤訊息就開始亂改一通。
  • 視覺結果的最終判斷留給人眼（多位達人實測交叉印證）：獨立開發者 plankenau 與 blakecrosley 都實測過 Claude「自信地說畫面修好了，但明明還是壞的」，截圖能讓 AI 自己跑驗證流程，但好不好看這件事終究要你自己盯著螢幕確認一次。
  • --dangerously-skip-permissions 是高風險旗標（業者部落格教學，做法較激進）：拿掉權限確認能加速全自動流水線，但務必在隔離環境（乾淨的模擬器帳號、非正式簽章）操作，別在正式開發機上開。
  • 加套件要人工核准（Flutter 達人實測）：AI 很愛順手 pub add 或安裝新依賴，CLAUDE.md／AGENTS.md 裡要明講「不先問就不准加新套件」，不然套件版本很快就跟團隊規範脫節。

延伸資源