AI coding agent 進入手機遙控時代，工程師真正該學的是工作階段設計

以前我們說「讓 AI 幫我寫 code」，畫面大多還是很桌面。

你坐在電腦前，打開 repo，丟 prompt，等它讀檔、改檔、跑測試。它卡住的時候，你在旁邊補一句；它要執行命令的時候，你按同意。這種互動雖然已經跟傳統寫程式差很多，但至少注意力還在同一個地方。

現在這個前提正在鬆動。

Codex 可以從 ChatGPT mobile app 遠端控制。Copilot CLI session 也可以透過 GitHub Mobile、網頁和 IDE 遙控。手機不再只是拿來看通知或回覆 PR comment，而是變成一個批准、回答、轉向、接管 AI 工作階段的控制面板。

這件事表面上很方便。通勤時看一下 agent 卡在哪裡，開會前批准它跑測試，離開電腦後還能回覆它的問題。對獨立開發者或小團隊來說，這確實有吸引力。專案不必完全被桌前時間綁住。

但我更在意另一件事：當 agent 可以在你不坐在電腦前時繼續工作，開發者真正要設計的就從 prompt 擴大成工作階段。它要能安全暫停、審查、批准，也要能被乾淨地收尾。

寫程式的單位正在變小，也正在變長

以前開發工作的單位比較清楚。你今天要修一個 bug、補一個功能、開一個 PR。中間雖然也會查資料、跑測試、改來改去，但主要節奏還是人握在手上。

AI coding agent 讓這個單位變得有點奇怪。

一方面，任務可以切得更小。你可以請 agent 只掃一個模組、只補測試、只更新文件、只找出某段錯誤的可能原因。它可以很快接手這些窄任務。

另一方面，session 反而變長了。因為真正有價值的 agent 工作不是一次回答，而是一連串讀檔、計畫、修改、驗證、修錯、再驗證。它不像 chat response 那樣結束在一段文字裡，而是像一個背景程序，會在你的機器上持續推進。

手機遙控把這個特性放大了。

你可能早上在筆電上啟動一個重構 session，走出門之後用手機看它要求批准某個命令。中午它問你某個 API 行為要不要保留，晚上你回到電腦前再看完整 diff。這不是「AI 幫我回答問題」，而是「我管理一個正在跑的工作階段」。

這兩者差很多。

如果你只是問問題，錯了大不了重問。如果你管理 session，錯的可能已經變成檔案變更、測試狀態、分支歷史，甚至被你在手機上快速按下批准。

遙控不是自由，是新的責任邊界

手機批准功能最容易被浪漫化成「隨時隨地都能寫程式」。我覺得這個說法只講了一半。

更精準地說，它讓你隨時隨地都可能需要做工程判斷。

這不是壞事，但也不是純粹的生產力紅利。你在捷運上看到 agent 問「要不要刪掉這個舊的 helper？」你真的有足夠脈絡判斷嗎？你在會議空檔收到它要求跑一個會改動資料庫狀態的命令，你會不會只是因為想讓它繼續往下跑就按了同意？

遠端控制最危險的地方，不是 agent 變得太強，而是我們把一些本來需要完整注意力的決策，搬到碎片時間裡處理。

所以工作階段設計要先回答幾個很務實的問題。

這個 session 可以改哪些檔案？哪些目錄只能讀不能寫？它可以自己跑哪些命令？哪些命令一定要等人回到電腦前看完整上下文？如果遇到不確定的產品決策，它應該停下來問，還是先做一個保守假設？如果它改動超過某個範圍，是否必須自動停止並整理摘要？

這些問題聽起來不像 prompt engineering，比較像工程管理。可是 agent 一旦能遠端跑，這些就是安全介面。

好的 session 應該知道何時停下來

很多人期待 agent 越自動越好。我不反對自動化，但我越來越覺得，好的 coding agent workflow 不是「一路做到底」，而是「在正確的地方停下來」。

停下來不是失敗。

如果 agent 發現需求跟現有架構衝突，停下來是好的。如果它需要碰到 auth、付款、資料刪除，停下來是好的。如果它的 diff 開始擴散到不相關模組，停下來也是好的。

真正麻煩的是它沒有停。

它可能很努力地把一個小問題補成一個大 patch。它可能為了通過測試，順手改掉測試本身。它可能把缺少產品決策的地方填上自己的猜測，然後看起來很合理。

當你坐在電腦前，這些問題已經夠難抓了。當你只用手機看幾行摘要，風險會更高。

所以我會把 session 設計成幾個明確階段。

先讓 agent 讀 repo 和提出計畫，不准改檔。計畫通過後，才允許它在指定範圍內修改。修改完先自己跑測試和整理風險，不要直接進入下一輪擴張。最後交回來的不是「我完成了」，而是「我改了什麼、我驗證了什麼、我沒有驗證什麼、哪些地方需要人看」。

這種流程會慢一點。可是它讓你可以在手機上做比較合理的判斷。你不是在盲按批准，而是在看一個預先設計好的 checkpoint。

碎片時間可以推進工作，但不能替代深度審查

我理解為什麼這類功能會讓人興奮。

很多獨立開發者的時間本來就破碎。白天有正職，晚上才做 side project。小團隊也常常一個人同時管產品、客服、部署和開發。如果 agent 可以在你不坐在桌前時先跑一段，專案確實比較不容易停住。

但碎片時間適合推進，不適合定案。

適合在手機上做的事情，大概是回答 agent 的澄清問題、批准低風險命令、確認它下一步應該走哪個方向、要求它停下來整理狀態。這些動作像是在維持工作流的呼吸。

不適合在手機上做的事情，是批准大範圍重構、接受牽涉安全或資料的 diff、決定有爭議的產品行為，或在沒看完整上下文時讓 agent 繼續擴大 scope。

這個分界很重要。

如果我們把手機遙控當成「隨時都能把工作做完」，很容易把注意力不足包裝成效率。如果把它當成「讓 session 不必因小問題完全停住」，它就比較健康。

下一代工程能力是管理背景中的工作

AI coding agent 變強之後，開發者的工作並沒有消失，只是換了位置。

以前你要把很多細節親手寫出來。現在你更常要決定哪些細節可以交給 agent、哪些地方必須先由人定義清楚、哪些結果可以接受、哪些看起來能跑但其實不該合併。

手機遙控讓這個轉變更明顯。因為它把 agent 從桌面工具變成背景中的工作者。它可以在你吃飯、搭車、開會時等你的決策。它也會在你注意力最薄的時候，要求你做一些看似很小、其實會影響後續路徑的批准。

所以新的能力不是更會下 prompt 而已。

你要會切 session。知道一個任務多大才適合丟給 agent。你要會設 checkpoint。知道什麼地方該讓它停，什麼地方可以讓它自己跑。你要會寫邊界。知道哪些檔案、命令、決策不能在背景中被順手處理。你也要會收尾。看懂它交回來的 diff、測試、風險和未驗證假設。

這些能力很不像 demo 裡的魔法。

但產品真的要交付，靠的往往就是這些不魔法的部分。

能把視線移開，才是真的自動化

「把電腦開著讓 AI 跑」聽起來很美好。對很多人來說，也確實會變成日常。

可是我不覺得真正的問題是 agent 能不能跑。它們會越來越能跑。真正的問題是，你能不能安心地把視線移開。

安心不是相信工具永遠不會錯。安心是你知道它錯的時候會停在哪裡，知道它能碰到什麼、不能碰到什麼，知道回來接手時可以從哪些資訊判斷狀態。

手機遙控讓 AI 開發變得更自由，也讓工程責任變得更分散。未來我們可能會在 IDE、手機和瀏覽器之間，管理一串長短不一的 agent session。

到那時，會寫 prompt 當然還有用。但更重要的是會設計工作階段。

因為你真正交出去的不是一句指令，而是一段可以在你不盯著看的時候繼續前進的工作。