手机编码新体验：用AI优化移动开发工作流

简而言之——我想升级用手机编程的工作流。我找到了 Paseo，fork 了一份，然后使用 AI Agent 改进了自己在意的部分，让它更适合我的需求。

最近几周，我一直在思考使用 AI Agent 编程的具体流程。不只是“哪个模型最好”或“哪个 Agent harness 表现最佳”，而是我实际采用的操作方式：日常如何使用这些工具，session 保存在哪里，以及当我没有盯着同一个终端时，怎样知道 Agent 正在做什么。

在笔记本电脑和台式机上，我正在逐步理顺这套流程。目前缺失的一环是手机。不得不承认，我非常痴迷 vibe coding，但走到哪里都带着笔记本电脑，多少有点不合社交礼仪。至少我自己是这么觉得的。

我希望即使面前没有电脑，也能查看 Agent 的状态、回答 prompt、推动任务继续进行，偶尔还能发起一项工作。

我想要的工具必须符合自己的实际工作方式：

• 在本地编程，而不是使用云服务或 SaaS

• 支持我已经在使用的 Agent，尤其是 OpenCode

• 能够从我真实的开发环境中继续或查看 session

严格来说，手机上确实可以使用 SSH，但那不是我想要的工作流。我想要的是一个控制平面，而不是一个狭小又难用的终端。

Paseo 是我找到的第一个真正契合实际问题形态的工具。

这个领域还有其他应用。我也看过 Emdash、SoloTerm，以及其他一些项目。我猜 Google、Anthropic、OpenAI 和其他提供商会继续开发各自的手机端衔接工作流。但我想要的是一个能够横跨不同 Agent 的统一层。

Paseo 是一款 local-first 应用，可用于远程监控和控制 coding Agent。你的电脑上会运行一个 daemon，移动端应用则与它通信。你不需要仅仅为了躺在沙发上操作一下 Agent，就把代码迁移到云端工作区。这一点对我很重要。我不想再要一套独立的移动端编程环境，而是想远程控制自己已经拥有的环境。

Paseo 还是开源的。事实证明，正是这一点，让“这个工具已经很接近了”变成了“我大概能让它真正可用”。

Paseo 已经解决了移动端应用能用、好用的问题。

那些缺口，正是我的缺口

Paseo 的设计已经相当用心，在移动端看起来也很出色。它支持我所关注的核心 Agent，但我的 OpenCode 工作流还是暴露出了一些不够顺滑的地方。

最大的问题是 session 衔接。我会先在终端版 OpenCode 中启动一个 session，之后再想通过 Paseo 接着处理。不是启动一个新的 Agent，也不是开始一段全新的对话，而是继续同一个 session，保留完全相同的上下文。这里的细节非常重要：当前究竟由谁控制这个 session？如果终端和 Paseo 同时尝试操作它，又会发生什么？

此外，还有一些细小但烦人的问题。斜杠命令自动补全的体验不太像 OpenCode。输入 /q 显然应该表示退出，但应用中的排序和视觉排列可能让这件事显得并不直观。工作区默认设置也很重要。如果 OpenCode 已经知道某个项目应该使用什么模型或模式，Paseo 就不该随意用自己的偏好覆盖它。

然后是 subagent。OpenCode 可以生成 subagent，但它们在 Paseo 中可能看起来只是一些普通的长时间运行 tool call。在手机上看，这给人的感觉就是“这东西是不是卡住了？”，即使 Agent 实际上正在正确执行任务。

Gemini CLI 支持也在我的计划清单上，但那大概是以后才会深入探索的另一个无底洞。

Paseo 目前还不能为 OpenCode subagent 提供丰富的支持。

我大概能修好它

事实证明，只要我能把问题说清楚，Agent 就能解决它。于是，我 fork 了 Paseo，并使用 AI coding Agent 改进 Paseo，使其更好地满足我的需求。

大部分工作并不是我坐下来，先写出一份完美的设计文档，再亲手敲代码。更多时候，我是在用自然语言引导：

“我想恢复一个在 Paseo 之外启动的 OpenCode session。”

“恢复后的 session 看起来是空的，但我知道它有历史记录。”

“让 /q 的行为更像终端版 OpenCode。”

“subagent 看起来像是莫名其妙地卡住了。到底怎么回事？”

Agent 调查了代码库、进行了修改、编写了测试，偶尔也会像 Agent 经常做的那样，一头撞进死胡同。我仍然需要做决定并审查结果。与其说我是在“实现一个功能”，不如说我是在不断描述自己想要的工作流，直到软件最终跟上我的需求。

我担心专业开发者看到我的部分做法会感到不适。但我也认为，自己代表了一类很有意思、值得软件从业者关注的人：技术能力足以写出高质量 prompt、检查结果并克服各种粗糙之处，但面对每个问题时，未必都会采用传统开发者的方式。

这并不能取代工程纪律，但它为塑造软件提供了一条新的入门路径。

我认为自己的 fork 现在已经拥有了一套好得多的 OpenCode 衔接方案。不过，我实际上只专注于三个“移动端缺口”对我而言最痛的领域：

零摩擦衔接： 应用现在可以发现任意工作区中处于活跃状态的 OpenCode session。我可以恢复一个 session，并立即看到最近历史记录的预览，让从笔记本电脑切换到手机的过程真正无缝，而不是像进行了一次上下文切换。

零摩擦衔接： 应用现在可以发现任意工作区中处于活跃状态的 OpenCode session。我可以恢复一个 session，并立即看到最近历史记录的预览，让从笔记本电脑切换到手机的过程真正无缝，而不是像进行了一次上下文切换。

强有力的默认设置： 我们调整了 UX，使其尊重 OpenCode 的工作区设置，并重新排列斜杠命令，让 /q 或 /exit 这类常见操作始终排在最前面。移动端键盘本身已经是一个障碍，软件就不应该再增加额外阻力。

强有力的默认设置： 我们调整了 UX，使其尊重 OpenCode 的工作区设置，并重新排列斜杠命令，让 /q 或 /exit 这类常见操作始终排在最前面。移动端键盘本身已经是一个障碍，软件就不应该再增加额外阻力。

提高 subagent 透明度： subagent 不再显示为含义模糊的“tool call”，而是会直接在时间线中报告自己的身份和当前任务状态。如果我看不到 subagent 正在做什么，就很容易认为它卡住了。把它的意图呈现出来，便能将一次神秘的“卡死”变成一项清晰可见、正在有效推进的任务。

提高 subagent 透明度： subagent 不再显示为含义模糊的“tool call”，而是会直接在时间线中报告自己的身份和当前任务状态。如果我看不到 subagent 正在做什么，就很容易认为它卡住了。把它的意图呈现出来，便能将一次神秘的“卡死”变成一项清晰可见、正在有效推进的任务。

为 OpenCode subagent 提供更好的内联支持。

我现在对个人软件非常感兴趣。在合适的情况下，我会把一些小改动贡献回 Paseo 的主分支，但如果我的 fork 继续走向不同的方向，我也完全不会感到意外。某种意义上，这正是重点所在。我想让它真正适合自己和自己的工作流。

接下来可能会做 Gemini CLI 集成。我也对跨提供商的用量追踪很感兴趣。我希望 Paseo 能够成为某种大本营，用来汇总我的可用额度、活跃项目，以及能够分配给这些项目的 Agent。它会成为我的 Agent 与项目的控制平面。

开源软件与 coding Agent 的结合，大幅缩小了“这个工具已经很接近了”和“这个工具真正适合我”之间的差距。开源软件一直都在邀请人们动手折腾，而 AI Agent 降低了这种折腾的成本。

而现在，显然有些折腾甚至可以直接在手机上完成。这要么非常酷，要么说明我该出去摸摸草了。

部分评论可能只有登录后的访客才能看到。请登录以查看所有评论。

如果需要采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。