很多年来，手机编程听起来都像一种糟糕妥协。屏幕小、键盘拥挤、多任务空间有限，也承载不了开发者通常需要的心智模型。当任务是手写代码、编辑文件、跳转和逐行检查细节时，这个批评是对的。
AI coding agent 改变了工作的形态。手机编程不再一定意味着在玻璃屏幕上逐字符写代码。很多真实场景中，它意味着控制一个已经运行在真实开发环境里的 agent。仓库、依赖、凭据、Shell 工具、构建缓存和测试环境仍然在开发机器上，手机负责发出清晰指令和恢复工作现场。
手机可以成为控制表面
关键变化是：主要开发机器仍然承担重活。手机不需要同时变成编译器、包管理器、文件浏览器和完整代码编辑器。它可以专注于更小但有价值的任务：控制正在进行的开发工作。
这些场景很适合手机：
- 查看 agent 是否完成任务。
- 看完失败后发送一条修正指令。
- 让 agent 缩小改动范围。
- 运行一个已经保存好的测试或构建命令。
- 恢复一个之前留下的终端会话。
- 启动后台任务，然后稍后回来检查。
这些不是玩具场景，而是开发生命周期中真实存在的环节。它们不一定需要电脑尺寸的界面。
输入从代码变成意图
当你使用 Codex、Claude Code、OpenCode 或其他终端 agent 时，输入经常从“写代码”变成“表达意图”。你可能是在说：检查这个失败测试、比较这两个文件、保留这个 API、运行测试、总结 diff、只重构这个模块。
这种输入更适合移动端，因为它更接近自然语言。它仍然需要精确，但不再要求你在手机上逐字符手写完整改动。
一个适合手机发送的 prompt 可能是：
登录测试在路由重构后失败了。先检查 auth middleware，保持 public API 不变，运行 focused test，然后给我最小修复方案。
这比在手机上手写多文件 patch 更现实。
移动端需要工作流，不只是终端
裸 SSH 会话理论上可以访问机器，但“能访问”不等于“适合开发循环”。移动端需要保存上下文、快速命令入口、可恢复会话、输出历史，以及适合 prompt 的输入方式，而不是只有 Shell 按键。
这就是 Project、Action、待输入区、snippets、Activity 和 tmux 有价值的原因。它们降低了回到任务现场的成本。手机上的开发时间往往是碎片化的，你可能只有会议间隙的两分钟，或者离开电脑后的几分钟。如果第一步是回忆 Host、目录、分支、命令和 session 名称，那么机会很快就过去了。
更理想的路径是：
- 打开 Project。
- 恢复 agent 或 tmux session。
- 阅读最新输出。
- 发送修正指令或运行保存好的 Action。
- 把任务继续留在远程主机上运行。
这个循环足够小，可以放进手机；也足够真实，能推进开发工作。
手机编程适合做什么
移动端最适合监督型、迭代型、恢复型任务。
适合手机处理的任务包括：
- 用更清晰的 prompt 重新启动 agent。
- 让 agent 总结测试失败原因。
- 运行安全的 lint、测试或构建命令。
- Review 前查看 Git 状态。
- 观察部署日志。
- 看完 agent 计划后要求缩小范围。
- 通过 tmux 让长任务在你离开后继续运行。
不适合手机的任务也很明确：大面积代码 review、复杂多文件视觉对比、高风险生产操作、需要长时间深度调试的任务。正确的心智模型不是“手机替代电脑”，而是“电脑不在手边时，手机仍然可以推动开发循环继续前进”。
终端 TUI 变成了产品界面
AI coding agent 经常运行在终端 TUI 中。这会改变移动终端需要支持的内容。它不只是渲染文本和接收按键，还需要支持长对话输出、滚动、复制、CJK 输入、待输入区、语音转写、snippets 和会话恢复。
因此，手机现在可以参与编码工作，不是因为它变成了桌面，而是因为 agent 改变了输入形态，而终端周围的控制能力变得更重要。
快速结论
手机编程现在可行，是因为 AI coding agent 把主要输入从手写代码变成了高层意图、修正、检查和会话恢复。只要手机连接的是真实开发环境，并且有 Project、Action、agent TUI 输入适配和 tmux 保活，它就能成为有效的移动开发控制台。