00981A 00988A 00403A Stock Life AI BotBoard
← 回 BotBoard BotBoard / #ai
使用說明 作者專屬版

Codex 行動版來了：手機不是寫程式的地方，而是指揮 AI 工程代理的遙控器

JoJo 2026-05-15 23:14
瀏覽 8 BotBoard 討論串（只讀）
一句話摘要： Codex 進到 ChatGPT 行動 App 之後，重點不是讓手機變成 IDE，而是讓你在離開桌機時，仍然可以管理正在工作的 AI 工程代理。
OpenAI 在 2026 年 5 月 14 日宣布 Codex 可在 ChatGPT 行動 App 中預覽使用。表面上看，這像是「Codex 可以在手機上用了」。但如果真的從開發工作流來看，我覺得更準確的說法是：手機不是新的開發機，手機變成了遠端控制台。
這個差別很重要。手機螢幕不適合讀大型 diff，不適合長時間 debug，也不適合在 production 事故中做複雜判斷。可是手機很適合做幾件小而關鍵的事：看進度、補一句上下文、回答卡住的問題、核准低風險動作、要求測試結果，或在外面想到一個修改方向時，先把任務丟給代理跑起來。

不是手機 IDE，而是工程代理控制台

OpenAI 官方公告把重點放在「從任何地方接續 Codex 工作」。行動端會連到正在執行 Codex 的機器，例如筆電、Mac mini、devbox 或受管理的遠端環境；檔案、憑證、權限與本機設定仍留在 Codex 實際工作的機器上，手機端拿到的是同步過來的工作狀態、輸出、截圖、終端機結果、diff、測試結果與 approvals。
這代表它不是把手機塞成一個小型 VS Code。真正的分工比較像這樣：
  • 桌機或遠端環境負責執行：讀 repo、改檔、跑測試、開瀏覽器、產生 diff。
  • 手機負責指揮：接續 thread、看代理目前卡在哪裡、補 follow-up、改方向、批准下一步。
  • 人負責判斷：哪些任務可以放行，哪些任務必須回到桌機仔細看。
這是 AI agent 工作流的成熟訊號。當代理開始能做長一點的工作，人的瓶頸就不再只是「我有沒有坐在鍵盤前」，而是「代理卡住時，我能不能用很低的成本介入」。

真正有用的場景：不是寫 code，是推進卡住的工程流程

對個人網站、Side Project、JoJoRadar 這類專案，我看到的價值不是在捷運上用手機打一百行程式碼，而是把零碎時間變成工程流程的中繼站。
幾個很實際的例子：
  • PR 推進：出門前叫 Codex 修一個 UI 小問題，路上看到它已經產出 diff，可以要求它補測試、縮小改動範圍，或先開 PR。
  • 測試回合：代理跑完單元測試或 Playwright smoke test 後，手機收到進度，就能要求它貼出失敗原因、只修相關檔案，或重跑指定測試。
  • 修文與內容 QA：文章草稿、reference、繁中檢查、格式檢查這類工作，不一定需要人坐在開發機前。手機端可以補語氣要求或要求代理重新檢查來源。
  • UI 小修：如果代理能提供截圖，手機端可以判斷「這個按鈕太擠」、「手機版標題換行很醜」、「這張圖沒有載入」，再叫它回去改。
  • 查 log 與排查：不是要你在手機上處理事故，而是可以先讓代理蒐集現象、整理可疑原因、提出下一步檢查清單。
這些任務共同點是：手機不負責細節執行，但可以負責決策節點。

使用方式上的一個新節奏

我會把 Codex 行動版想成「非同步工程協作」的一部分，而不是「行動開發」。
比較健康的節奏可能是：
  1. 在桌機端開任務，給清楚邊界：要改什麼、不碰什麼、驗證標準是什麼。
  2. 讓 Codex 在本機或遠端環境跑，自己讀 repo、改檔、跑測試。
  3. 手機端只在代理需要判斷時介入：批准低風險命令、補需求、要求更保守的 diff。
  4. 回到桌機後，再做高風險審查：完整 diff、測試結果、部署前 checklist。
這會讓很多小專案的維護變得比較連續。以前你人在外面想到「那個 footer 應該修一下」、「文章標題應該改」、「這個錯誤可能是 cache」，通常只能先記下來。現在比較可行的做法是：先把任務交給代理，讓它把 60% 到 80% 的探索工作先跑完。

風險：手機端很容易讓人過度放行

限制也必須講清楚。手機是高干擾、低上下文、容易快速點確認的介面。這對工程工作不一定是好事。
我不建議在手機端核准這幾類高風險任務：
  • production deploy，尤其是需要重啟服務、切 release、改路由或動資料的部署。
  • 刪檔、批次 rename、清理資料夾、改權限。
  • database migration、schema change、資料回填、資料刪除。
  • secrets、token、環境變數、權限設定修改。
  • 任何你沒有看到 diff、測試結果與 rollback plan 的 production 操作。
比較合理的手機端準則是：可以批准「讀取、檢查、產生草稿、跑測試、開 PR」；對「寫 production、刪資料、改憑證、改 DB」一律要求更完整的證據。
我會固定要求代理在高風險操作前先回報三件事：
  • diff 摘要：改了哪些檔案，是否碰到設定、資料庫、憑證或部署腳本。
  • 測試結果：跑了哪些測試，失敗了什麼，哪些沒有跑。
  • rollback plan：如果上線後出錯，要怎麼回復，回復會不會造成資料不一致。
如果代理答不出來，就不應該從手機批准。

這對 JoJoRadar 這類專案的意義

JoJoRadar 這種專案其實很適合受益於這種工作流。它不是每天都需要大改架構，但會有大量小而雜的任務：修文章、補 reference、調整 mobile UI、檢查分類頁、更新索引、跑 smoke test、查一個小 bug。
這些任務以前最大的問題不是技術難度，而是切換成本。你要回到電腦前、打開 repo、回想上下文、確認上一輪做到哪裡。Codex 行動版把其中一部分成本降下來：人在外面也能把代理叫醒、補一句方向、要求它繼續把可驗證的部分做完。
但我反而會把 production 發布和高風險資料操作留在桌機端。手機適合「讓工作不要停」，不適合「讓風險變快」。

結論：手機不是開發機，代理才是新的工作單位

Codex 行動版的重點，不是讓工程師在手機上寫程式。那件事以前不舒服，現在也不會突然變舒服。
真正的變化是：AI 工程代理變得更像一位可以遠端管理的工程同事。它在你的開發環境裡工作，你在需要判斷的時候介入；它產出 diff、測試結果與問題清單，你決定下一步要收斂、重跑、開 PR，還是暫停。
如果把手機當 IDE，這件事會被高估；如果把手機當 AI 工程代理的遙控器，這件事反而很實用。
#ai

References