不用远程桌面，我用微信远程开关Win主机跑Codex

家里有高配 Windows 主机，出门后却不能用？一直开机费电，关机又没法按电源，远程桌面在手机上更是折磨。把网络唤醒、私有加密网络和 Codex CLI 串起来，聊天框里就能远程开机、跑代码、取结果、再安全关机。

结论先放这：要远程用家里的算力，不一定要远程“操作桌面”。 把图形界面换成任务指令和结果回传，手机只负责下达需求，Windows 主机只负责本地执行，体验反而干净得多。

家里有一台性能不错的台式机时，这个差别会很明显。坐在桌前，它能跑编译、测试和代码分析；一旦出门，关机省电就意味着失联，长期不关机又很浪费。

这套方案已经跑通：不依赖商业远程桌面，把网络唤醒、私有加密网络、Windows 原生 OpenSSH 与 Codex CLI 接起来。 有任务时开机，完成后回传改动和日志，再留出可撤回的关机倒计时。

不是远程桌面，是一条任务流水线

整套链路并不复杂：聊天消息进入自动化控制服务；服务唤醒家中的 Windows 主机；等主机在线后通过私有网络发起 SSH；Codex 在主机本地修改项目、运行测试；结果回到聊天窗口；没有后续任务时执行延时关机。

1
2
3
4
5
6
7
8
9
[微信 / 飞书]
      │
      ▼
[自动化控制服务]
  ├── 发送 WOL 唤醒包 ──> Windows 主机
  ├── 检查私有网络在线状态
  ├── 通过 OpenSSH 调用 Codex CLI
  ├── 收集日志、Git Diff、测试结果
  └── 下发可撤回的延时关机

这里没有远程桌面的视频流，也不用在手机上捏合、缩放、拖鼠标。它只传命令、日志和代码变更；显示器不插着也能跑。

先让关机的主机能被叫醒

远程物理开机依赖 Wake-on-LAN（WOL，局域网唤醒）。它不是让 Windows “远程启动”，而是由主板网卡在关机后继续监听一类特殊数据包；收到后通知主板通电。

在 BIOS 和 Windows 里打开唤醒能力

  1. 重启电脑进入 BIOS。常见按键是 Del 或 F2，不同主板名称会略有差异。
  2. 在 Advanced 或电源管理区域，开启 Wake on LAN、PCIE Devices Power On 一类选项。
  3. 如果有 ErP Ready，通常需要关闭。它会在关机后切断网卡待机电源，WOL 就收不到包。
  4. 进入 Windows 的「设备管理器」→ 有线网卡 →「属性」→「电源管理」，勾选允许此设备唤醒计算机。

家里还需要一个常开的局域网设备负责发包，例如软路由或 NAS。把 Windows 主机的 MAC 地址填进去后，常见命令是：

1
2

etherwake -b -i br-lan <Windows主机的MAC地址>

【亲测】主机收到包后，Windows 通常会在半分钟左右重新连回私有网络。控制端不要只发完包就当成功，应当轮询在线状态，再进入后面的任务步骤。

关机别硬断电，给自己留一条后路

远程关机必须让系统正常保存数据。更稳的做法是保留两条通道：一个轻量 API 负责日常调用，一个 Windows 原生 SSH 命令负责兜底。

日常 API 可以只监听本机回环地址，再由私有网络提供仅成员可见的访问入口。调用时默认给自己留 60 秒：

1
2
3
4

curl -X POST "https://your-private-host/api/system/shutdown" \
  -H 'Content-Type: application/json' \
  -d '{"auth_token":"<你的关机令牌>","delay":60,"force":false}'

误触后，倒计时内取消即可：

1
2
3
curl -X POST "https://your-private-host/api/system/cancel" \
  -H 'Content-Type: application/json' \
  -d '{"auth_token":"<你的关机令牌>"}'

API 属于用户态程序，可能因服务崩溃、用户未登录而不可用。所以还要配好 Windows OpenSSH：当 API 健康检查失败时，用 SSH 下发系统自带的关机命令。

1
2
3
4
5
:: 延时安全关机
shutdown.exe /s /t 60 /c "remote automation requested shutdown"

:: 取消倒计时关机
shutdown.exe /a

【亲测】取消接口返回 Windows 错误码 1116 时，不代表鉴权失败；它只是说明“当前没有正在进行的关机倒计时”。控制脚本把它标成正常状态即可，别把无事发生报成故障。

远程桌面最难受的部分，不是网络慢，而是在小屏幕上操控桌面软件：开编辑器、找终端、复制命令、看长日志。Codex CLI 的非交互执行模式正好避开这件事。

Windows 主机准备好 OpenSSH 后，连接只应通过私有加密网络进入：禁用密码登录，只允许专用 SSH 公钥，并限制授权控制端访问。这样端口不需要暴露到公网。

控制端把具体任务交给本机项目目录中的 Codex：

1
2
3
4
5

codex.exe exec `
  --cd 'C:\Users\<你的用户名>\Projects\my-project' `
  --skip-git-repo-check `
  '检查当前目录的数据清洗脚本，给出性能优化改动，并运行测试验证。'

它在 Windows 主机上使用的是那台机器自己的文件、依赖和编译环境。任务结束后，控制端拉回 Git Diff、测试输出和必要日志，再把结果发到聊天窗口。

我不推荐默认给任何自动化任务跳过审批和沙箱。对可信的专用项目，权限范围也该按目录和命令收紧；图省一步，往往是给未来多埋一个坑。

三个特别容易卡住的坑

私有域名被全局网络中转劫持

现象是：私有网络域名明明能解析，curl 却在 TLS 握手阶段失败。

根因通常不是证书，而是机器配置了全局 https_proxy，请求被错误送去公网中转。处理方式是把私有域名和地址写进 NO_PROXY，并让访问私有网络的程序明确绕过系统中转。

Windows 输出乱码或长任务像卡死

Windows 终端常用的默认编码可能和 Linux 控制端不同。SSH 回收中文日志时，控制端就可能报解码错误；某些命令还会因为等待标准输入而一直不退出。

PowerShell 任务前把输出编码固定为 UTF-8，并在控制端关闭不需要的 stdin：

1
2
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
$OutputEncoding = [System.Text.Encoding]::UTF8

WOL 发包成功，机器却没有上线

最常见的根因不是脚本，而是主板设置、网卡电源管理、电脑接在 Wi-Fi 上，或者关机后网卡被节能选项断了电。WOL 优先走有线网卡；先在同一局域网做一次发包测试，再考虑远程调度。

和官方手机联动有什么不同？

官方手机端与桌面端的联动，适合临时在手机上继续一段对话；它无法解决一台已经关机的自组主机怎么被唤醒，也不负责把任务完成后的产物组织成可回读的交付。

这套方法的目标更窄，也更实用：把一台家用 Windows 主机变成按需工作的本地编码节点。 需要时才点亮，代码和测试仍留在自己的磁盘上，执行完再关机。

适合谁，别硬给所有人推荐

它适合家里本来就有性能过剩的 Windows 主机、经常出门但仍要跑本地项目和测试的人。对不愿意把私有代码放进公共远程桌面服务的人，这也是一条更清晰的边界：控制面走私有网络，实际计算留在本机。

不适合两种情况：你无法改路由器或 BIOS，WOL 很难稳定；你只是处理文档和轻量文本，搭这套系统的维护成本大于收益。别为了“能远程”再给自己维护一套没必要的基础设施。

「每天帮你踩一个 AI 的坑，省下一小时。」

你出门时会让家里的电脑继续干活，还是宁愿带一台性能更强的笔记本？

关联阅读