手机作为 AI 开发控制面板

我越来越觉得，手机上的 AI 开发工具不应该从“怎么在小屏幕上写代码”开始设计。

这个问题看起来很自然。既然 AI 可以写代码，那我能不能在地铁上、排队时、躺在沙发上，直接用手机让它改一个功能、修一个 bug、发一个版本？

但真正用起来会发现，小屏幕并不适合承载完整工程细节。你很难在手机上舒服地读多文件 diff，也很难长时间判断一个类型系统、一个 API 边界或一次重构是否合理。即使 AI 已经把很多实现工作接过去，人的判断仍然需要上下文，而上下文本身很占屏幕。

所以我更愿意换一个问题：手机不应该成为移动 IDE，它应该成为 AI 开发任务的控制面板。

这个问题为什么值得写

上一篇我写到，AI 编程正在从“生成代码”进入“远程协作”。这会改变开发工具的入口。

过去的开发体验默认人一直坐在电脑前：看编辑器、敲命令、刷新浏览器、读日志、提交代码。工具围绕这个姿势设计，IDE 是中心，终端是中心，浏览器也是中心。

AI agent 进来之后，人的注意力不再必须每一秒都贴着实现细节。很多任务可以被委派出去：读代码、改文件、跑测试、修 lint、查部署状态、根据失败日志继续收窄问题。

这就带来一个新的断点：当人离开电脑时，任务还在继续。

如果没有一个合适的控制面板，离开电脑会变成一种风险。你不知道 agent 正在做什么，不知道它是不是扩大了修改范围，不知道测试失败后它会不会走偏，也不知道什么时候应该补一句约束让它停下来。

手机正好适合补这个断点。它不适合承载全部工程细节，但非常适合承载状态、提醒、摘要和决策。

真实背景：人的注意力已经变成异步资源

我现在越来越少把 AI 当成一个必须实时盯着的补全器。更常见的状态是：我给它一个明确任务，然后让它自己读仓库、修改、验证、汇报。

这时人的注意力变成一种异步资源。

有些时候我在电脑前，可以细看 diff、打开文件、跑本地服务。另一些时候我可能已经离开工位，只能看一眼手机。问题是，AI 的任务并不会因为我离开而自然停在一个“刚好安全”的位置。

所以手机端需要解决的不是完整开发，而是几个更现实的问题：

• 当前任务到底走到哪一步了。
• 它准备改什么，已经改了什么。
• 它跑了哪些验证，失败在哪里。
• 它有没有触碰超出任务边界的东西。
• 它现在需要我批准、拒绝、补充约束，还是继续等待。

这不是聊天窗口能自然解决的问题。聊天窗口擅长表达过程，但不擅长稳定呈现任务状态。AI 开发需要的移动端，应该更像一个任务控制台，而不是一个消息流。

系统设计：电脑执行，AI 推进，手机决策

我会把这个系统拆成三层。

第一层是执行层。它在电脑或远程工作区里，拥有真实仓库、终端、测试环境、浏览器和部署权限。代码真正被修改、验证和发布，都应该发生在这一层。

第二层是协作层。AI agent 在这里读上下文、规划步骤、执行命令、总结结果。它像一个能干活的协作者，但仍然要受到任务边界、权限和验证规则约束。

第三层才是手机控制层。手机不直接承载所有工程细节，而是把执行层和协作层压缩成一组可判断的信息。

电脑 / 工作区
  -> 真实仓库、命令、浏览器、部署环境
 
AI agent
  -> 理解任务、修改代码、运行验证、暴露风险
 
手机
  -> 看状态、读摘要、做决策、补约束、必要时中断

这三层的职责必须分开。手机如果试图变成完整 IDE，就会把最重的部分搬到最不适合的地方。它应该只处理那些小屏幕最擅长的动作：扫一眼、判断、批准、拒绝、提醒、切换。

手机应该显示什么

一个好的 AI 开发控制面板，首页不应该是输入框。

它更应该先显示任务列表和任务状态。每个任务都像一个小型工单，包含目标、当前阶段、最近动作、风险等级和下一步操作。

我希望每个任务至少有这些信息：

这里面最重要的是“验证结果”和“风险”。如果手机只展示“我已经改好了”，它就没有提供控制权。真正有用的是告诉我：它改好了什么，怎么验证的，还有哪里不确定。

决策层级：不是所有事情都需要打扰人

如果每一步都弹通知，手机会很快变成噪音源。一个 AI 开发控制面板必须区分信息、提醒和决策。

我会把状态分成四层：

1. 信息层：任务开始、读取文件、运行命令、生成摘要。这些可以记录，但不需要打扰。
2. 注意层：测试失败、依赖缺失、环境连接不上。它们值得提醒，但不一定需要立刻决策。
3. 决策层：准备修改任务边界、需要访问外部服务、要发布上线、要执行高风险命令。这里必须等人确认。
4. 中断层：发现明显方向错误、反复失败、触碰敏感文件、出现不可解释的大范围改动。这里应该主动暂停。

这套层级很关键。因为手机上的注意力很短，如果所有消息都长得一样，人就会开始忽略它。只有把“需要你看”和“需要你决定”分开，手机才不会变成另一个焦虑入口。

控制面板不是遥控器，而是边界管理器

“控制面板”这个词容易让人想到很多按钮：运行、停止、重试、发布、回滚。

这些按钮当然需要，但它们只是表层。更深一层的能力是边界管理。

AI agent 最容易出问题的地方，不是写不出代码，而是不知道什么时候应该停止。它可能为了修一个小问题顺手重构一片逻辑，可能为了绕过测试失败改掉测试本身，也可能在上下文不够时继续猜。

手机端应该帮助人管理这些边界：

• 这次任务只允许改哪些文件。
• 哪些命令可以自动跑，哪些必须确认。
• 如果测试失败，允许它重试几轮。
• 如果发现需求不清，应该停下来问，而不是继续扩大修改。
• 如果要部署或推送，必须给出验证清单。

type TaskPolicy = {
  allowedPaths: string[];
  blockedActions: string[];
  autoRetryLimit: number;
  requireApprovalFor: Array<"deploy" | "push" | "migration" | "dependency-install">;
  stopWhen: Array<"scope-expanded" | "tests-changed" | "unknown-secret" | "repeated-failure">;
};

这段不是某个具体产品的实现，而是我觉得控制面板需要表达的东西：手机端不是在替代工程判断，而是在帮助工程判断保持清醒。

离开电脑后的任务闭环

最典型的使用场景可能是这样的。

我在电脑前创建一个任务：修复某个页面在移动端的布局问题，并要求最后跑 lint、build 和浏览器检查。AI agent 开始读代码、定位组件、修改 CSS、启动本地服务。

然后我离开电脑。

手机上任务进入“验证中”。几分钟后它提示：lint 通过，build 通过，移动端截图已生成，但发现某个按钮在 390px 宽度下文字换行不自然。它给我两个动作：继续调整，或者先保留当前结果。

这时我不需要打开完整 diff。只要能看到问题截图、修改摘要和验证结果，我就可以做一个高层判断。如果我选择“继续调整”，agent 回到电脑执行。等它再次完成，再把结果推回手机。

这个闭环的核心不是手机做了多少事，而是任务没有因为我离开电脑而失控。

关键取舍

第一，不要把移动端做成桌面 IDE 的缩小版。

完整文件树、完整 diff、完整终端输出都很重要，但它们不应该成为手机端的默认视图。默认视图应该是任务状态和决策摘要。需要深挖时，可以打开某个 diff 片段或跳回电脑。

第二，隐藏噪音，但不能隐藏证据。

AI agent 运行时会产生很多日志、命令输出和内部推理痕迹。大部分不适合直接展示给用户，但最终结果必须可追溯。手机端可以压缩信息，但不能只给一句“完成了”。至少要保留命令、截图、失败原因、未验证项和最终 diff 入口。

第三，默认异步，但关键节点同步。

普通进度可以异步看，失败可以稍后处理，但发布、推送、数据库迁移、删除文件、安装依赖这类动作必须回到明确确认。AI 越能自动执行，权限边界越要清楚。

第四，给人选择，而不是把选择伪装成聊天。

很多移动 AI 产品喜欢把所有交互都放进聊天框。聊天适合补充约束和追问原因，但不适合承载高频决策。真正高频的动作应该是结构化的：批准、拒绝、暂停、继续、重试、打开详情。

结果与验证

这篇文章先把产品判断写清楚：手机端 AI 开发的核心不是“移动写代码”，而是“异步控制真实工程任务”。

如果用它来反推产品，我会用几个问题验证方向是否正确：

• 用户离开电脑后，是否还能知道任务真实状态。
• 用户是否能在 10 秒内判断一个任务需不需要介入。
• 手机端是否清楚区分了信息、提醒和必须确认的动作。
• 每个完成结果是否能回到验证证据。
• 高风险操作是否被权限和确认机制拦住。

这些问题比“能不能在手机上编辑文件”更接近真实价值。

下一步

如果继续把这个方向往前推，我会优先做四件事。

第一，定义任务状态模型。哪些状态是通用的，哪些状态是项目特定的，哪些状态必须阻塞下一步。

第二，设计移动端任务卡片。它要足够短，可以扫一眼；也要足够诚实，不能把风险藏起来。

第三，建立动作权限。哪些操作可以自动执行，哪些必须人确认，哪些永远不应该从手机上点一下就发生。

第四，把验证结果结构化。lint、build、测试、浏览器截图、部署状态、未验证项，都应该变成手机端能稳定展示的对象。

这些听起来不像炫酷功能，但它们决定了 AI 开发能不能从“看起来会写代码”变成“真的能长期协作”。

收尾

手机作为 AI 开发控制面板，本质上是在重新分配人的注意力。

电脑仍然是执行场。AI agent 是推进任务的协作者。手机则是人在不同生活场景里重新接入工程现场的入口。

它不需要让人随时写代码。它要让人随时知道：发生了什么，风险在哪里，现在该不该做决定。

如果未来 AI 开发真的变成一种长期协作方式，移动端不会只是桌面工具的附属屏幕。它会成为人保留判断权、节奏感和边界感的地方。