把 iOS 獨生子，養成 Android 三好生

Android 不是iOS 穿了一件綠色外套

所謂“從iOS 適配到Android”，最容易做錯的方式，就是照著頁面截圖逐像素復刻。真正需要遷移的是產品契約：使用者輸入一個中文字元只能到遠端一次；renderer 失敗不能斷SSH；後台回來要看到新frame；訂閱恢復要認得當前plan；Pad 不是一台被橫著放大的手機。

於是每項能力都被翻譯成三層：共享語意、平台實現、證據邊界。iOS 可以用自己的viewport primitive，Android 可以通過Ghostty ABI 3；但「手指向下瀏覽更舊歷史、點擊回到live」必須一致。

flowchart LR
  I["iOS 已有能力"] --> C{"共享產品契約"}
  C --> A["Android 原生實作"]
  A --> D["平台差異策略"]
  D --> V["三設備與真實服務驗證"]
  V --> R{"證據通過?"}
  R -- "否" --> F["定位根因並縮小聲明"]
  F --> V
  R -- "是" --> S["小批複審與原子提交"]
            

跨平台不是“長得一樣”，而是“出事時也守同一份承諾”。

先讓Ghostty 失敗，再允許它成功

Android Ghostty 的第一原則有點反直覺：一開始絕對不樂觀。同步常數永遠先給`ok=false`，非同步自測必須證明native core、ABI、VT、EGL、shader、texture upload、draw 和readback 都成立，才從xterm 切到Ghostty。

這避免了首幀“先黑一下再說”的經典移動端玄學。健康證明還有2.5 秒上限：GPU 真要進入沉思，用戶最多看2.5 秒spinner，然後得到一台能工作的xterm，而不是一塊禪意十足的永久空白。

stateDiagram-v2
  [*] --> Pending
  Pending --> Ghostty: health proof succeeds before timeout
  Pending --> Xterm: timeout or proof fails
  Ghostty --> Xterm: runtime GL failure
  Xterm --> StableSession: same transport and ring replay
  Ghostty --> StableSession: native renderer active
  StableSession --> [*]
  note right of Ghostty
    Native VT plus full GL path
  end note
            

終端膠片為文章復原示意，不是營運後台原圖；marker、結果與邊界來自真實設備證據。

那些「順手」一起補齊的硬骨頭

輸入法composition、xterm 鍵序、觸摸selection、ActionMode copy、native scrollback、background compositor、PixelCopy probe、CPU snapshot、Pad keyboard focus mode……每一項單看都像P3，疊在一起才決定「這是一台終端，還是一張會閃的黑色矩形」。

瀏覽器裡有權限，但沒有一把現成的鑰匙

Play Console 的權限躺在已經登入的Chrome profile 裡；內建Playwright 是乾淨profile，什麼也看不到；CDP 還沒開。最省事的回答是「請使用者手動操作」。Goal 選擇了另一條路：先找出哪個瀏覽器上下文有權限，再把使用者參與壓縮成一次必要consent。

沒有現成橋，就在臨時目錄裡產生一個：MCP SDK + `chrome-devtools-mcp` + 薄stdio client，再用持久PTY 連續發`snapshot → click → snapshot`。它沒有被包裝成“平台能力”，完成後被清理；真正可復用的結論是專用profile、origin allowlist、固定版本和默認脫敏。

sequenceDiagram
  actor U as 使用者
  participant A as Goal Agent
  participant B as Chrome
  participant G as gcloud
  participant P as Play Publisher API
  participant R as RevenueCat API
  A->>B: 發現已有登錄態和目標帳號上下文
  U->>B: 明確允許 remote debugging
  B-->>A: CDP 頁面控制可用
  A->>G: 啟用 API 並建立兩套最小權限身份
  A->>B: 在 Play Console 綁定應用程式權限
  A->>P: 冪等建立 catalog 並上傳 internal AAB
  A->>R: 建立 Android app 與商品映射
  P-->>A: track 與 artifact 狀態
  R-->>A: entitlement 與 offering 狀態
  A-->>U: 只請求業務事實與不可逆發布決策
            

截圖黑了，先別給GPU 寫悼詞

Android 真機驗證最危險的時刻，是第一張截圖看起來非常有說服力。SurfaceView 可能在系統截圖裡全黑；Xiaomi screencap 可能是0 位元組；screenrecord 可能只錄到沒有硬體層的世界。反過來，遠端tmux 看到了marker，也只證明transport 活著，不能證明本地compositor 畫出來了。

於是證據設計成多oracle：唯一marker、UI tree、PixelCopy、CPU raster、PID、dumpsys、logcat、遠端pane。它們必須互相證偽，而不是排隊鼓掌。

flowchart TB
  M["注入唯一 marker"] --> U["UI tree 與控制項狀態"]
  M --> X["Screenshot 或 PixelCopy"]
  M --> S["PID · dumpsys · logcat"]
  M --> T["遠端 SSH/Mosh/tmux 狀態"]
  U --> C{"多個 oracle 一致?"}
  X --> C
  S --> C
  T --> C
  C -- "否" --> A["分類測試工件"]
  A --> N["更換 nonce 與 oracle 重跑"]
  N --> M
  C -- "是" --> B["寫下有邊界的結論"]
            

「全自動」的真相：不是沒人，而是人只出現在值錢的地方

這次Goal 的邏輯長度是21 小時54 分42 秒，但機器uptime 更短。它不是一個神秘進程堅持不睡覺，而是靠Git、tmux、可輪詢工具、計畫狀態、review handoff 和外部系統狀態持續恢復上下文。

本輪使用者實際參與很少：登入RevenueCat，在Chrome/Google 開發者控制台完成少量必須由帳號持有人確認的點擊，並在commit/push 等不可逆動作上給出明確授權。已有登入態發現、絕大多數Play 表單填寫與事實核對、gcloud/權限打通、API 生成、設備驗證、購買/恢復測試、截圖錄影、錯誤恢復和整理，均由Goal 自己閉環。

flowchart TB
  O["穩定 Goal 目標"] --> P["階段計劃與證據門檻"]
  P --> G["Git 原子提交"]
  P --> T["tmux 與可輪詢工具"]
  P --> E["設備和外部服務狀態"]
  P --> R["獨立 reviewer verdict"]
  G --> C["進程或開機變更後繼續"]
  T --> C
  E --> C
  R --> C
  C --> P
            

最後diff 沒告訴你的十件事

下一個App，可以直接抄走什麼？

最後一個反直覺結論

真正有傳播力的AI 工程故事，不是“它連續乾了22 小時”，而是“它知道什麼時候自己幹，什麼時候找證據，什麼時候承認截圖不可信，什麼時候必須讓人點一下”。自動化的上限，不由點擊次數決定，而由邊界感決定。

最好的Agent，不是替你做所有決定；而是把你的參與，壓縮到真正需要拍板的那幾次。