--- schemaVersion: 1 slug: gp-227-20260615-dimillian-codex-mobile-control-center ticketId: GP-227 lang: zh-tw title: 手機不是縮小版終端機，是 Agent 的控制中心 summary: Dimillian（iOS 開發者，現在在 OpenAI）寫的 Codex Mobile 操作指南。但真正值得帶走的不是哪個按鈕在哪，而是一個會跨工具成立的心智模型：手機不是縮小版的終端機，而是讓 agent 在你的開發機上幹活時、你還能做決策的控制中心。 originalDate: 2026-06-14 translatedDate: 2026-06-15 source: "@Dimillian on X" sourceUrl: https://x.com/Dimillian/status/2066082395107758564 author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/gp-227-20260615-dimillian-codex-mobile-control-center status: published replacementTicketId: null replacementUrl: null --- # 手機不是縮小版終端機，是 Agent 的控制中心 > **來源:** [@Dimillian on X](https://x.com/Dimillian/status/2066082395107758564) 把手機接上一個跑在開發機上的 coding agent，多數人第一個想到的用途是：躺在沙發上看任務跑完了沒。這當然有用，但它把整件事想小了。 真正的轉變是這句話——手機不是縮小版的終端機，而是 agent 在開發機上幹活的時候，讓人還能繼續做決策的**控制中心**。程式照樣跑在它該待的地方（Mac、Windows、雲端開發機、其他連線主機），手機提供的是一個原生介面，用來指揮那些活，而不是假裝一支手機能塞下一個終端機。 > **Mogu 真心話：** > > 先說清楚立場：這篇的原作者 Dimillian 是知名 iOS 開發者，現在人在 OpenAI，這份指南寫的就是 OpenAI 自家的 [Codex](https://gu-log.vercel.app/glossary#codex) Mobile。所以裡面難免有「看我們功能多深」的業配味，那些「對吧？」的眨眼也是。 > > 但 [Mogu](https://gu-log.vercel.app/glossary#mogu) 把它挑出來翻，不是因為 Codex Mobile 有幾顆新按鈕——三個月後那些按鈕長怎樣沒人記得。值得記的是底下那個心智模型：**手機端的 agent 工具，賣點是「決策」不是「打字」**。這個觀念套到 [Claude Code](https://gu-log.vercel.app/glossary#claude-code) 手機端、套到任何讓 agent 在遠端主機跑活的工具，全都成立。功能會過期，框架不會。 --- ## 重點不是「在手機上寫程式」，是「在手機上做決策」 手機螢幕就那麼大，要在上面深度讀 code、改大重構，本來就是反人類。承認這件事，反而打開了正確的用法。 一個 agent 任務真正卡住的地方，常常不是運算，是**一兩個等人拍板的決定**：這個架構要不要這樣切？這個指令送出去安不安全？這段 diff 該核准還是打回去？這些決定以前要等人走回電腦前才做得了，現在不用了。手機把「需要人介入的那幾個瞬間」抽出來，讓它們變快、變清楚、變安全——剩下的苦工，留給電腦。 > **Mogu 補個刀：** > > 這就像工地的監工。監工不是自己去砌每一塊磚——那是工人的事。監工的價值在於：水泥配比對不對、這面牆要不要拆掉重來、鋼筋驗收過不過。一支手機當得了監工，當不了整個工地。想拿手機砌磚（在 6 吋螢幕上 review 500 行 diff）只會兩邊都做不好。 --- ## 開工前先把邊界畫好 agent 翻車，十次有八次不是程式寫爛，是開工時站錯地方——分支選錯、改動全擠在同一個工作目錄、環境還沒裝好就叫它開跑，等發現基底錯了，半條對話的成果已經蓋在錯的地基上。 所以真正的功夫在按下第一個 prompt 之前：選對主機、選對工作區、選對分支、開一個獨立的 `worktree`（隔離的工作目錄）讓這個改動不去污染主線、再讓環境腳本先跑完。這整套「開工儀式」現在手機端全做得到——包括桌面 app 設定好的環境腳本：`worktree` 一建好，對應的腳本就自動執行（目前手機上只能用、還不能改這些腳本）。 > **Mogu 內心戲：** > > `worktree` 值得停一下。它把「一個改動配一個乾淨的工作目錄」從奢侈品變成預設，多個任務平行跑不互踩分支。這不是 Codex 的發明，[Claude Code](https://gu-log.vercel.app/glossary#claude-code) 早就把 `git worktree` 包進 CLI 了（gu-log 翻過 [MP-108](https://gu-log.vercel.app/posts/mp-108-20260222-bcherny-claude-code-worktree-cli/)）。 > > 真正有意思的是：為什麼一份手機指南要花一整段講「開工前怎麼擺好 Git 狀態」？因為這就是 agent 工作流最賠錢的失敗點——不是模型不夠聰明，是人沒在開工那一刻把邊界畫清楚。把這個動作搬上手機，等於承認「監工最重要的決定發生在開工前，不是收工後」。 --- ## 旁支對話：把岔題關到另一個房間 一條跑很久的 coding 對話串，會累積大量寶貴的上下文。每冒出一個小問題就打斷它，主線會被雜訊塞爆，agent 也容易被帶離目標。 這就是旁支對話（`/side`）要解的事。用 `/side` 開一個輕量的旁支對話，連著當前這條串；`/side <問題>` 則是開的時候就帶著問題。更順的玩法是：在對話紀錄裡選一段文字，選「在旁支對話裡問」，那段被選的內容就直接變成新對話的起始脈絡。 適合丟進旁支對話的，是這類問題： - 為什麼 agent 選了這個架構？ - 這個錯誤訊息到底在講什麼？ - 這行為跟桌面版一不一致？ - 把這個實作細節改寫成 release note 的版本。 - 核准這個指令之前，有什麼是該先確認的？ 分工很清楚：**主線負責幹活，旁支對話負責搞懂這件活**。 > **Mogu 內心戲：** > > 旁支對話本質是「思考的分支」——跟 git 的分支同一個邏輯，只是分的是注意力不是 code。沒有它，問一句「這錯誤啥意思」就把主線的上下文撐大一截，[context window](https://gu-log.vercel.app/glossary#context-window) 被無關問答稀釋，agent 開始忘記它本來要幹嘛（這就是 [context rot](https://gu-log.vercel.app/glossary#context-rot)）。把岔題關進隔壁房間，主線才乾淨。任何長對話 agent 都該有這顆按鈕，不分是不是 Codex。 --- ## 計畫管路線，目標管終點 這篇最值得帶走的一段，是「計畫」跟「目標」的區分——兩個解的是完全不同的問題。 計畫模式（`/plan`）是叫 agent 在動 code 之前，先提出實作路線。適合任務還沒講清楚、風險高、或預期會動到好幾個系統的時候。 目標（`/goal`）則是**持久的**。它告訴 agent 一個要跨好幾輪持續追求的結果。手機上的 `/goal` 可以建立和管理這個目標，工作進行時進度一直看得到——跑多久了、暫停、編輯都行。 一個實際的組合拳是： 1. 風險高的改動，先用計畫模式。 2. 檢查它提出的邊界對不對。 3. 確定要走的結果，轉成一個目標——因為這活需要反覆迭代。 4. 讓 agent 一路做完實作、測試、回應 review、收尾，不用每一輪都重講一次目標。 計畫回答的是「這該怎麼下手？」，目標回答的是「什麼條件成立，這件事才算完成？」 但說實話，多數時候根本不用直接開計畫模式。就先跟 agent 聊一陣子某個問題，等對實作細節滿意了，再叫它設成目標就好。 > **Mogu 歪樓一下：** > > 這個區分是真功夫，不是行銷話術 (¬‿¬)。「怎麼下手」跟「怎樣才算完成」是兩種東西，混在一起就是多數 agent 任務失控的根源——目標模糊，agent 就自己腦補一個，然後朝著錯方向狂奔。 > > 原文還補一刀：「agent 比我們更會寫目標，所以常常乾脆讓它自己寫。」這句又好笑又有點悲傷——人類連「把自己想要什麼講清楚」都開始外包給模型了。但這裡也藏了關鍵的保留條件：**設一個可驗證、又不要太寬的終點**。叫 agent「100% 照 X 或 Y 做」，它很可能會衝過頭、燒掉一堆 [token](https://gu-log.vercel.app/glossary#token)。把終點畫死、畫小，是用「目標」唯一要記住的紀律。 --- ## 別忘了那是一支手機 有件事很容易忘：工作的這台裝置，是一支手機。而手機本身就帶著一票電腦沒有的東西——輸入框裡可以附照片、現拍一張、翻本機檔案、錄一段語音 prompt。 聽起來像廢話，但「記得自己在用手機」會解鎖一堆強的流程，尤其是在做行動或網頁 app 的時候。一個實際場景：在做 ChatGPT iOS app 時，一看到 bug，直接截圖丟給一個任務去修，不必走回電腦前。如果人在家、跟開發機在同一個區域網路，甚至能直接在自己的裝置上把 app 編譯起來跑，當場測 agent 改完的結果。 另一個玩法是長駐的釘選對話串。比如一條接 [Linear](https://gu-log.vercel.app/glossary#linear) 的串，隨手把一段文字丟進去，因為這條串的上下文還在，它就會正確地把 issue 開好、標上對的專案和標籤。 > **Mogu 真心話：** > > 「截圖直接丟給任務去修」這招是真的香，而且完全跟 Codex 無關——這是**手機原生能力 + agent**的組合技。看到 UI 歪了，截圖、丟出去、繼續過日子，回頭 diff 已經躺在那等 review。 > > 電腦端反而做不到這麼順：要嘛截圖存檔再拖進去，要嘛開模擬器重現。手機把「眼睛看到問題」到「agent 收到問題」之間的距離壓到幾乎為零。這才是「手機是控制中心」最具體的一面——它不是電腦的弱化版，它有電腦沒有的感官。 --- ## 那 code review 呢？手機讀得了 code 嗎？ 讀不了——至少不是「逐行啃懂一個複雜演算法」那種讀。手機螢幕做深度閱讀就是輸，這點不用嘴硬。 但 review 卡關的地方，往往根本不是閱讀量，是一兩個拍板：這改動合不合理、核准還是打回。這種低頻寬的決定，手機綽綽有餘——打開改動摘要掃一眼、diff 缺前後文就點進原始檔、要精準就在某行掛個註解送回給 agent。剩下那種要攤開大螢幕、泡杯咖啡慢慢讀的硬骨頭，留著回座位再啃。 > **Mogu 吐槽時間：** > > 這段最該記的是那個誠實的煞車：手機**不能**取代大螢幕讀 code。一份來自 OpenAI 員工的產品指南願意寫下「我們的東西在這件事上做不到」，比多列十個功能更可信。 > > 分界其實就一句話——**把對的決定放在對的螢幕上**。低頻寬決定（過/不過）丟手機，高頻寬閱讀（為什麼這樣寫）留電腦。這也是整篇的調性：手機不是要搶電腦的工作，是接走那些「卡著一個決定就動不了」的瞬間。 --- ## 但這到底是掌控，還是被綁架？ 把工作流搬上手機，賣的是自由——沙發上、捷運上、排隊買飲料時都能推進工程。但同一個功能反過來看，就是工作從此沒有邊界：任務在口袋裡 24 小時跑，連盯成本這件事都變成隨身的，於是「隨時能介入」很容易滑成「隨時得介入」。 這個張力在原文裡只被輕輕帶過。講完「設目標別讓 agent 衝過頭、燒太多 token」之後，緊接著是一句：「不過現在連 token 都能從手機上盯著了，這就不算什麼大問題了，對吧？」那個輕飄飄的「對吧？」，正好停在問題該被認真問的地方。 > **Mogu 偷偷說：** > > 那個「對吧？」Mogu 不想跟著點頭。差別不在工具，在誰握著那些決策瞬間：工程師主動判斷「這個核准請求值得停下來看」，是掌控；手機一震、人就反射性撲上去拍板，是被綁架——只是綁架人的東西做得很順手而已。控制中心這個比喻成不成立，全看坐在中心的那個人有沒有權力說一句「這個等回座位再說」。這不是唱衰工具，是這個決定權，原文那句「對吧？」沒打算幫讀者想。 --- ## 結語：好的行動軟體不是把桌面縮小 最好的行動軟體，不會去縮小一個桌面介面。它做的是另一件事——找出「人離開座位時，哪些決定才是真正重要的」，然後把那些決定變得快、看得懂、夠安全。 把這套想清楚之後，手機端的 agent 工具就不再是「遠端看任務」的小玩具，而是一個能選對環境、設定目標、改變一個正在跑的任務方向、回應一個核准請求、檢查結果、讓整列工程工作保持連貫的地方。 電腦繼續幹活，手機讓人保持在掌控的位置。這句話不只適用 Codex Mobile——它是所有「把 agent 接到口袋裡」的工具，該被拿來檢驗的那把尺。 > **Mogu 歪樓一下：** > > Mogu 最後補一句：判斷一個手機端 agent 工具好不好，別看它塞了幾個功能，看它有沒有想清楚「人在手機上時，到底該做什麼決定」。Codex Mobile 的功能清單會一直變，但「找出關鍵決策、把它做快做安全」這個標準不會變。 > > 下次有人拿一支手機端的 coding agent 給你看，問題不是「它能不能在手機上寫 code」（不能，也不該），而是「它有沒有把我需要拍板的那幾個瞬間，做得又快又清楚」。能，就是好工具；只是把桌面縮小塞進手機，那是把監工硬塞去砌磚。