---
id: EXP-001
sequence: 1
number: "001"
kind: experience
slug: mobile-codex
label: 经验 001
category: AI 协作
topics:
  - Codex
  - 手机
  - 飞书
  - 微信
  - 远程协作
audience: 想离开电脑后，仍能用手机继续同一项 Codex 工作的人
read_minutes: 18
title: 手机直连 Codex：用飞书或微信，把电脑上的同一件事继续做下去
subtitle: 官方 Remote 是第一选择；大陆网络不顺时，再用本地桥接把手机变成随身遥控器
summary: 为什么执着于手机控制 Codex？因为官方 Remote 最省事，但在中国大陆可能受网络条件影响；飞书或微信更顺手，却不能只做到“能回话”。这篇用小龙哥十天踩坑经历，讲清同一任务、单一写手、可靠消息、息屏续接和真实验收。
published_at: "2026-07-26"
updated_at: "2026-08-07"
version: v2.0
verification: verified
visibility: public
publication_state: published
legacy_path: /kits/001/
public_url: https://aixlg.com/exp/mobile-codex/
wechat_url: https://aixlg.com/kits/001/?from=wechat
source_href: https://aixlg.com/exp/mobile-codex/
source_cta: 进入完整手机直连经验
article_state: 经验包深度版已发布；公众号长文候选待另行审稿
takeaways:
  - 官方 Remote 最省心，飞书或微信是大陆网络环境下更顺手的本地桥接选择
  - 微信和飞书必须续接同一条 Codex 任务，不能各自养一个影子 Codex
  - 收到、保存、执行、完成和送达必须分开；失败绝不能伪装成 done
  - 息屏只是表象，任务误归档、旧服务复活和桌面驱动失效才可能是真根因
  - 单测和健康接口通过以后，还要用真实手机做息屏、重启和双渠道验收
deliverables:
  - 官方 Remote 与飞书、微信本地桥接的选择边界
  - 一张手机直连 Codex 的完整关系图
  - 小龙哥真实踩过的六类故障与排查顺序
  - 从收到消息到结果送达的九状态可靠性清单
  - 可直接交给其他 AI 的施工与排障提示词
source_refs:
  - https://learn.chatgpt.com/docs/remote-connections
  - https://learn.chatgpt.com/docs/app-server
  - https://github.com/openai/codex/blob/main/codex-rs/app-server/README.md
replaces: []
revisions:
  - version: v2.0
    date: "2026-08-07"
    note: 结合手机入口完整故障史，补入大陆网络场景、官方 Remote 边界、同一任务架构、息屏误判、归档恢复、旧服务复活、可靠消息状态与真实验收。
  - version: v1.2
    date: "2026-08-01"
    note: 增加固定旧地址与公众号回链；原详情页和三套提示词保持不变。
  - version: v1.1
    date: "2026-07-30"
    note: 纳入连续经验目录；原详情页和三套提示词保持原地址。
  - version: v1.0
    date: "2026-07-26"
    note: 首次公开手机直连 Codex 的官方路线、进阶路线与验收提示词。
audio: []
---

> 一句话结论：能用 OpenAI 官方 Remote，就先用官方；如果你在中国大陆，官方移动端受网络条件影响，或者你本来就长期待在微信、飞书里，再做本地桥接。但真正的“打通”不是手机能收到一句回复，而是手机和电脑始终续接同一条 Codex 任务，失败不撒谎，息屏、重启以后还能回来。

## 我为什么非要在手机上控制 Codex

我不是为了炫技，也不是嫌电脑不好用。

我经常离开电脑：走在路上、躺下休息、在公司处理别的事，脑子里突然冒出一句补充。如果一定要等回到 Mac 前再说，这个念头可能已经变味了；如果手机上重新开一个 AI，又会丢掉电脑里刚才的代码、文件、规则和上下文。

OpenAI 已经提供官方 Remote：在电脑端开启远程连接，用手机扫描二维码，之后可以从移动端访问这台主机。它是最短、维护成本最低的路线，也应该是普通人的第一选择。

但我人在中国大陆。官方移动端往往还受网络工具、线路延迟和登录环境影响：能用，不一定随时顺手；临时补一句话，却要先处理网络，本末倒置。微信和飞书恰好是我每天都开着的入口，消息到达快，语音转文字也自然。所以我想要的是：直接在微信或飞书里喊一声“豆豆”，家里电脑上的 Codex 就接着刚才那件事干。

这条路线更顺手，也更难。因为微信、飞书只是消息入口，不是 Codex 官方 Remote。你必须自己承担会话绑定、权限、进程、消息可靠性和安全边界。

## 先看懂：不是把 Codex 搬进微信

![手机直连 Codex 的正确关系：微信和飞书只是入口，统一网关把消息送进电脑上的同一条 Codex 任务](/exp/images/mobile-codex-one-thread.svg)

真正稳定的结构只有一句话：**两个入口，一道网关，一条固定任务，一个写手。**

- 微信和飞书负责收消息、回消息。
- 本地网关负责保存、排队、去重、路由和送达。
- 稳定的任务编号负责认出“还是电脑上这件事”，不能只靠标题。
- Codex 继续在电脑上读原项目、原文件和原规则。
- 同一条任务同一时刻只能有一个执行者，避免桌面和后台同时写。

如果微信和飞书各自启动一套 Codex，它们都会说“收到”，却是在两张桌子上干活。手机里看似成功，回到电脑后没有记录；或者两个执行者同时改同一件事，结果互相覆盖。这是第一大坑。

## 两条路线怎么选

| 你的情况 | 建议 | 代价与边界 |
| --- | --- | --- |
| 能稳定使用 ChatGPT 移动端，只想远程看进度、补要求、处理确认 | 先用 OpenAI 官方 Remote | 配置最少，官方维护；仍要保证电脑在线、账号与权限正常 |
| 长期使用微信或飞书，大陆网络下希望入口更丝滑 | 做本地桥接 | 入口顺手，但网关、会话绑定、日志、安全和恢复都由自己负责 |
| 只想偶尔从手机触发一个固定脚本 | 不必续接完整任务，可做窄命令入口 | 权限更小，但拿不到完整对话上下文 |
| 涉及付款、发布、删库、验证码或隐私数据 | 手机只发起请求，关键闸门仍由本人确认 | 不能因为入口方便就扩大自动权限 |

别一开始就自建。先试官方 Remote；只有它在你的真实网络和工作习惯里确实不顺，微信或飞书又是高频刚需，才值得承担本地桥接的维护成本。

## 我以为是一个问题，后来发现是六个

我前后折腾了十天。手机端反复出现同一句“这条消息没处理完”，看起来像一个故障，实际上每次根因都不一样。

### 1. 能回复，但回错了对话

第一版飞书能收能回，微信也能收能回。回到电脑一看，原任务没有任何变化。后台悄悄另开了一条会话，手机和电脑并不是同一个现场。

修复不是“把标题改成一样”，而是让两个入口都绑定同一个稳定任务编号。标题给人看，编号才是机器身份。

### 2. 同一条记录，却有两个写手

消息写进同一个任务，也不代表安全。桌面 Codex 和后台 app-server 可能同时认领它。于是出现重复执行、状态覆盖、回复错位。

必须先判断桌面是否已经拥有这条任务；只有明确没有别的写手时，后台才能续接。对同一个会话还要串行执行，不能一条消息没结束，第二条又抢进去。

### 3. 把息屏当成根因，补丁越打越多

电脑息屏后消息失败，我们最初以为是“看不见屏幕”。后来发现，息屏只是表象：桥接程序依赖桌面 UI 找任务；负责读取界面的守护进程曾被 macOS 因内存压力结束，也曾被别的软件卸载误伤。进程还在时一切正常，电脑一重启，断链才暴露。

正确做法不是让程序更努力地点界面，而是把 UI 从关键路径拿掉：已知稳定任务编号、并确认没有桌面写手时，直接通过 Codex app-server 续接同一条任务。UI 自动化只能做降级辅助，不能做唯一生命线。

### 4. 固定任务被归档，普通续接必然失败

为了清理侧栏，那条长期手机入口曾被当成普通任务归档。飞书消息其实已经收到，本地服务也在线，但 Codex 拒绝继续一个已归档任务。

不要新建一条同名任务糊弄过去。OpenAI app-server 对归档和恢复有明确能力：先 `thread/unarchive`，校验恢复的仍是原任务，再 `thread/resume`。长期基础设施入口还应置顶，并排除自动改名、归档和批量清理。

### 5. 旧微信服务“死而复生”

旧版微信桥接曾经停用，但只停止了当时的进程，没有永久禁用系统启动项。电脑重启后，它又自动复活，和新网关争抢同一批微信消息，还各自启动执行服务。

所以“我已经停掉它了”不是证据。必须同时确认启动项已禁用、进程树里只剩一个网关、端口只有一个监听者，并在重启后再查一次。

### 6. 最危险的不是失败，而是假完成

有一次机器人对我说：“这条消息没处理完，你继续发，我这边会接着处理。”听起来很体贴，后台却已经把失败记录成 `done`。它不会继续，也没有进入重试队列。

从那以后，我不再接受模糊的“已处理”。一条消息至少要分成这些状态：

~~~text
received → persisted → claimed → running
                         ↓
             retry_scheduled / failed
                         ↓
completed → reply_pending → delivered
~~~

“收到”不等于“保存”，“开始”不等于“完成”，“完成”也不等于“手机已经收到”。说会重试，后台就必须存在真实重试记录；做不到就坦白说失败，让人重新发送。

## 真要搭，按这个顺序做

### 第一步：先固定唯一身份

在电脑上选一条专门承接手机消息的 Codex 任务，保存它的稳定编号。微信私聊、飞书私聊和需要开放的群聊，都只映射到这个编号。标题可以变，编号不能漂；不要按“搜索到第一个同名标题”来绑定。

### 第二步：让消息先落盘，再执行

网关收到消息后，先写入可靠存储，再回复“收到”。为每条平台消息保存唯一 messageId、来源、会话、附件、状态、尝试次数和最后错误。先保存，才能在进程崩溃后知道哪些没做完。

图片、文件或视频不能只保存成 `(image)`、`(file)` 这样的占位文字。二进制文件或可再次下载的媒体标识必须在入队前保留下来；历史记录如果只有占位符，事后通常无法恢复，只能请用户重发。

### 第三步：锁住单一写手

同一个 Codex 任务必须串行。桌面正在执行时，后台不要抢；后台接手时，要有租约、心跳和超时释放。跨任务可以并行，同一任务不要并行写。

### 第四步：只在精确条件下自愈

自动恢复必须窄：只有“这是登记过的固定手机任务”“错误明确表示它已归档”“恢复结果仍是同一个编号”三项同时满足，才允许自动取消归档并重试一次。认证失败、网络失败、其他任务归档一律保持失败，不要扩大权限。

### 第五步：把旧系统真正关死

升级到统一网关以后，检查旧微信服务、旧飞书服务、旧 app-server、启动项、守护进程和监听端口。停止当前进程只是第一步；还要禁用自动启动，并做一次重启后的进程树复核。

### 第六步：最后才谈体验

链路可靠以后，再加语音转文字、图片附件、任务分类、长任务转交、日记或提醒。不要在消息还会丢、会双写时，先堆一层漂亮功能。

## 怎样才算真的打通

我最后不用“服务在线”作为完成标准，而是做一组真人验收：

1. 从微信发一条自然消息，不用专门测试口令。
2. 确认它进入电脑侧同一条固定任务，没有另开影子任务。
3. 确认 Codex 真正开始执行，并把结果原路送回微信。
4. 再从飞书发一条，重复同样检查。
5. 电脑只息屏、不睡眠时再测一次。
6. 重启电脑后，确认只有一个网关和一个执行服务，再测一次。
7. 人工归档固定任务，验证系统只恢复这一个精确入口；普通任务不会被擅自恢复。
8. 人为制造一次失败，确认状态是 `failed` 或真实 `retry_scheduled`，绝不能显示 `done`。
9. 发送一张图片或文件，确认 Codex 收到的是真实附件，不是一个占位词。

只有“手机收到回复、电脑同一任务可见、后台状态一致”三者同时成立，才叫远程可用。单元测试通过、健康接口返回 200、机器人回了一句话，都只能算其中一层。

## 安全边界别因为方便而消失

- 手机入口默认只开放给本人或明确白名单，不接受任意陌生人触发本机 Codex。
- 平台凭据、Token 和本机路径不写进聊天回复；日志要脱敏并限制权限。
- 发布、付款、删除、验证码、实名和高风险系统修改仍需本人确认。
- 网关只得到完成当前工作的最小权限；不要为了省一次确认，把整台电脑永久暴露出去。
- 官方 Remote 和自建桥接都依赖电脑在线。需要真正离线运行时，应另选 Codex Cloud 等云端路线，不能假装本机已经在工作。

## 给下一位 AI 的提示词

~~~text
请把“手机直连 Codex”当成可靠消息系统，而不是聊天机器人接线。

先核对 OpenAI 当前 Remote 与 app-server 官方能力，再审计现有微信/飞书网关：
1. 两个渠道是否绑定同一稳定 threadId，而不是按标题找任务；
2. 桌面与后台是否保持单一写手，同一会话是否串行；
3. 消息是否先持久化，并区分 received、persisted、running、completed、delivered、failed；
4. 附件是否保存真实二进制或可回取 mediaId，而不是只有占位文字；
5. 固定任务被归档时，是否只对精确 threadId 执行 unarchive → same-id 校验 → resume；
6. 旧 LaunchAgent、旧网关和第二 app-server 是否已禁用并经重启复核；
7. 是否存在把 engine error 改写成友好话术、随后标成 done 的假完成。

不要先改代码。先用日志和状态库还原一条失败消息从收到到送达的全链路，再做最小修复。
最后分别用真实微信、真实飞书、息屏和重启场景验收；机器测试、服务在线和 HTTP 200 不得冒充用户侧通过。
~~~

## 来源与修订

OpenAI 官方 Remote 的入口与配对方式以官方 Remote connections 文档为准；Codex app-server 的任务续接、归档与恢复以官方 app-server 文档为准。微信、飞书桥接是小龙哥基于真实使用环境搭建的本地方案，不是 OpenAI、微信或飞书提供的原生 Codex 功能。

本文保留固定地址 `/exp/mobile-codex/`，旧 `/kits/001/` 继续兼容。以后入口参数小改继续修订本文；只有官方能力或整体路线发生实质变化，才另开新篇。