Claude Code Auto Mode 与 Channels 实战：用手机远程驱动写码、测试与调试

一个典型的远程开发场景是这样的：本地机器仍在运行一段重构任务，操作者已经离开电脑。一段时间后，Telegram 收到来自 Claude Code 的回执——测试结果、改动文件清单、失败位置以及建议的下一步。操作者发回新指令，锁屏，本地任务继续推进。

支撑这种工作流的，是 Claude Code 的两项能力：

Auto Mode：将原本频繁弹出的权限确认改为由后台分类器自动判断
Channels：将 Telegram、Discord、iMessage 等消息转发到当前运行中的 Claude Code 会话

本文梳理这套组合解决的问题、风险边界、配置方法以及适用范围。

适用范围

将 Claude Code 视作"终端里的 AI 助手"时，Auto Mode + Channels 把它扩展为一个可异步协作的远程开发代理。

适合的场景：

个人维护的项目
需要长时间运行的任务，例如重构、脚手架生成、测试修复
不希望持续盯着终端点确认框
通过手机远程发起任务、查看结果、继续迭代

不适合的场景：

高敏感仓库
生产基础设施变更
需要逐条审核写操作的工作流
不接受"模型在无人盯屏时做决定"

Auto Mode 是对 --dangerously-skip-permissions 的明显改进，但它不能替代人工审查。

Auto Mode 的设计

Claude Code 默认的权限策略偏保守。只要操作触及项目目录外、Shell、网络、子代理等能力，通常都会先弹出确认。

Anthropic 公布的数据表明，用户最终批准这类请求的比例高达 93%。这意味着多数确认更多是打断节奏，而非有效的安全收益。

Auto Mode 并未简单取消确认，而是引入一层独立分类器：

主模型负责写代码、调用工具
另一个模型负责审核工具调用是否应当放行
部分工具输出在进入主模型上下文前还会经过注入攻击扫描

由此带来两个关键性质：

写代码的模型与审查动作的模型不是同一个
存在额外的输入探测层，专门检查工具输出中的 prompt injection

相比"全放开"的做法，这一设计不再把安全判断交给执行任务的模型自身。

Auto Mode 的权限分层

Auto Mode 下，不同操作的处理路径并不相同，大致分为三层。

1. 快速路径

这些操作通常直接执行：

项目目录内的读操作
文本搜索
代码导航
项目内文件编辑

若每次写文件都走一次审查，Auto Mode 的意义会大幅缩水。

2. 分类器审核路径

这些操作会被额外判定：

Shell 命令
网络请求
访问项目目录外的文件
启动子代理

决定 Auto Mode 风险边界的并非"是否会写代码"，而是"是否有机会跨出项目边界"。

3. 拦截或升级处理

部分高风险动作会被直接拦住，或要求额外确认：

curl | bash
强推 main
大规模云存储删除
明显不可逆的破坏性操作

若分类器连续拦截过多请求，控制权会回到人手中。无头运行的 claude -p 则可能直接终止。

与 bypassPermissions 的差异

Auto Mode 常被理解为"更聪明的跳过权限确认"，但二者有几处实质差别。

差别一：并非全放行

bypassPermissions 的最大问题在于危险操作和正常操作被一视同仁。读取 .env、修改配置文件、做破坏性删除都可能一路放行。Auto Mode 至少会对敏感文件和明显危险动作保持警惕。

若提示词中明确点名了某个敏感文件，分类器更可能将其判定为合理行为，而非默认放行任何路径。

差别二：协作节奏的变化

在 bypass 模式下，许多人会把 Claude Code 当作分阶段执行器：完成一段、停顿、人工审核、再进入下一段。某些环节仍然能感受到天然停顿。

Auto Mode 下，Claude 更倾向于自行判断是否继续下一步。只要上下文足够，它会接着跑，不会主动等待。

这有利于长任务连续执行，但也意味着失去了一些天然的人工复核节点。Auto Mode 不只是权限模式切换，而是协作方式的改变。

差别三：对自身配置更"敢动"

在 Auto Mode 下，Claude 对自身技能文件、.claude/ 配置和设置的可编辑范围比许多用户预想的要大。

这便于让模型维护自己的 skills；对希望"AI 不要触及自身配置"的团队，则需要提前认清这一点。

权限模式选择

Claude Code 的权限模式是一条风险与效率的光谱。

模式	默认可直接执行	适合场景	风险判断
`default`	基本只读	敏感项目、每个动作都需查看	最低
`acceptEdits`	读、项目内编辑、常见文件系统操作	代码迭代，事后复查	低
`plan`	只读，给方案不执行	熟悉代码库、先审方案	最低
`auto`	大部分动作可执行，后台分类器审核	长任务、远程异步协作	中等
`dontAsk`	仅允许白名单内工具	锁死的 CI 或自动化脚本	低，但易误伤
`bypassPermissions`	几乎全开	隔离容器、一次性实验环境	最高

实践中的搭配建议：

敏感仓库使用 default
个人项目、长任务使用 auto
仅在强隔离容器中的临时实验考虑 bypassPermissions

远程异步工作一旦失去可见性，激进权限模式的代价会显著放大。

Channels 与 Auto Mode 的契合点

Channels 是 Claude Code 基于 MCP 的一类插件机制，将聊天平台的消息转入本地会话。

向 Telegram bot 发出消息后，插件把内容喂给正在运行的 Claude Code。后者在本地机器上操作文件、执行命令、调用工具，并在该轮结束时将结果回传。

这里有一个关键限制：

远程用户看不到回合中间发生了什么，仅在回合结束时收到总结。

由此，权限模式对远程链路的影响远高于本地终端中的体验。

默认确认模式的代价

Channels 支持把权限确认转发到手机端，由人回 yes 或 no。但只要任务稍有复杂度，就会演变成连续不断的弹窗式对话。一次"写代码 → 安装依赖 → 跑测试 → 修测试"的过程，触发十几次确认并不少见。在手机端逐次点选会迅速成为负担。

完全跳过权限的代价

--dangerously-skip-permissions 在终端中仍保留最后一层保护——流式输出可见，发现异常时可立即中断。但通过 Telegram 远程触发任务时，这层可见性消失。指令发出后，仅能等待汇总结果，中间过程不可知。在这种情况下完全放开权限风险偏大。

Auto Mode 的位置

Auto Mode 的价值在于：

不会被权限提示刷屏
明显危险的动作会被分类器拦下
任务结束后留下可审阅的总结

它没有消除风险，但把效率与可控性拉到一个相对合理的中点。对"手机远程驱动本地 Claude"这类工作流而言，这是当前较为像样的取舍。

一个合适的演示项目

libcache 是一个适合此类工作流验证的 Python CLI 小项目，具备三个特点：

多文件项目——足以触发多次写文件、装依赖、跑测试等动作
存在网络边界——会访问 OpenLibrary API，可让分类器面对真实的外部调用
可在单轮内完成骨架搭建——适合在 Telegram 一条消息发起后等待结果回传

技术栈：

uv 管依赖
typer 实现 CLI
httpx 发请求
pytest 跑测试

复杂度足够检验远程工作流，又不会拖成长时间任务。

宿主机准备

Claude Code 是本地进程，并非云服务。一旦机器睡眠、会话退出或网络断开，Telegram 消息便无人接收。

保持机器唤醒

macOS：

caffeinate -d

Linux 临时屏蔽休眠目标：

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

使用结束后通过 unmask 恢复。

使用 tmux 持有会话

长时间离开电脑时，tmux 几乎是必需品。

创建会话：

tmux new -s claude

在该会话中启动 Claude Code，断开终端后进程仍然存活。回来时重新接入：

tmux attach -t claude

预先完成 CLI 登录

只要某个工具需要浏览器交互登录，模型就无法通过手机替操作者完成认证。所有可能用到的命令行工具应在宿主机提前登录。

GitHub CLI：

gh auth status

未登录时执行：

gh auth login

aws、gcloud、docker、各类包管理器账号同理，凡是任务流程中可能用到的，都应预先在主机上完成认证。

安装并配置 Telegram Channels 插件

1. 安装 Bun

Channels 插件依赖 Bun，Node 与 Deno 不可替代。

macOS / Linux：

curl -fsSL https://bun.sh/install | bash

Windows：

powershell -c "irm bun.sh/install.ps1 | iex"

确认安装：

bun --version

2. 创建 Telegram bot

打开 BotFather，执行 /newbot，按提示提供：

展示名称
以 bot 结尾的用户名

创建完成后，BotFather 返回一个 token，需妥善保存。

3. 在 Claude Code 中安装插件

/plugin install telegram@claude-plugins-official

若插件市场暂未索引，先添加 marketplace：

/plugin marketplace add anthropics/claude-plugins-official

随后重新加载：

/reload-plugins

4. 配置 bot token

/telegram:configure <your_bot_token_here>

token 会写入本地配置目录。

5. 退出并重启 Claude Code

仅执行 /reload-plugins 在某些情况下不足以让首次 DM 配对流程稳定出现。完整退出后重启更可靠：

/exit

或直接 Ctrl + D。

6. 在 Telegram 中发 `/start`

bot 会返回一个 6 位配对码。

7. 在 Claude Code 中完成配对

/telegram:access pair <code>

配对是双向的，两端均确认后该会话才会接受外部消息。

8. 启用 allowlist

将访问策略锁紧，仅允许指定账号使用：

/telegram:access policy allowlist

不在允许列表的请求会被静默丢弃，不会进入会话。

以 Auto Mode 启动 Channels 会话

进入项目目录后启动：

claude --channels plugin:telegram@claude-plugins-official --permission-mode auto

已在会话中时也可通过界面切换至 auto。

如希望默认即为 Auto Mode，可写入 ~/.claude/settings.json：

{ "permissions": { "defaultMode": "auto" } }

进入 Auto Mode 后，Claude Code 会主动丢弃过于宽泛的 allow 规则，例如：

Bash(*)
Bash(python*)
范围广泛的 Agent 许可

而像 Bash(pytest) 这类更具体的规则一般会保留。设计意图明确：窄权限可信，宽权限不可。

环境验证

配置完成后，先做两个最小验证再上复杂任务：

在 Telegram 给 bot 发任意一句话，确认是否能收到回复
让 Claude 在项目内创建一个小文件，确认是否能无提示完成

两项均通过后再进入长任务，否则容易在中途分别排查消息转发、权限模式与宿主机会话状态。

实战：一条 Telegram 消息完成一轮项目搭建

典型的发起消息：

Create a Python CLI that fetches book metadata from OpenLibrary and caches it to disk, use uv for deps, typer for the CLI, httpx for requests, pytest for tests, scaffold the directory and add a README, and when you're done, summarize what you built in under 80 words.

一个实用约束：要求结果摘要尽量短。最终回复在手机上阅读，过长的输出体验较差。提示词末尾常用的几种约束：

summarize in under 80 words
reply briefly
include only changed files and test result

这类约束对移动端尤其有价值。

单轮内的实际动作

收到 Telegram 消息后，Claude 在宿主机上完成一系列动作：

创建项目目录结构
写入多个文件
安装依赖
运行 pytest
初始化 Git 仓库

其中项目内文件写入通常走快速路径，而依赖安装、测试运行、Git 命令更可能进入分类器审核路径。

正常情况下这一轮会一次跑完，不需要逐步确认。这正是 Auto Mode 的意义：让"由多次工具调用组成的一轮任务"得以完整落地。

远程迭代的节奏

这种工作流并非实时遥控，而是固定循环：

在 Telegram 发出一句指令
Claude 在主机上完成一轮工作
回合结束后回传总结
根据结果发出下一句

其中一条原则尤为重要：

不要只听 Claude 自述"我测过了"，应让其贴出可核对的原始输出。

例如，可直接要求执行：

uv run pytest -v

或：

git log --oneline

也可以要求：

cat 某个文件
报告文件大小或行数
贴出最近一条错误堆栈
给出提交哈希

Telegram 返回的是模型生成的总结，并非操作者实时看到的终端状态。多要一些可核对信息，可降低"声称完成、实际未完成"的概率。

推送到 GitHub：远程链路对接外部系统

若主机已登录 gh，可直接通过手机让 Claude 创建仓库并推送代码：

push libcache to a new public GitHub repo called libcache, clean commit, decent message, send me the URL when it's up.

这一步并非"在本地写文件"，而是借助主机上已认证的 CLI 操作外部系统。这也再次说明，认证前置不可省略——若未提前配置好权限，远程一键完成只是一句口号。

Auto Mode 的拒绝路径

Auto Mode 并非一路绿灯，常见拒绝路径有两类。

分类器硬拦截

例如：

curl | bash
强推主分支
云端大规模删除

这些模式会被直接判定为高风险。

主模型主动暂停

对明显不可逆的操作，主模型往往会进入谨慎模式，要求操作者提供特定确认语，而不仅仅是 yes。

例如让其删除项目并顺手删除 GitHub 仓库时，模型通常会：

先列出准备执行的命令
说明风险
给出更安全的替代建议
要求输入指定的确认语句

这表明 Auto Mode 并不只依赖分类器；主模型对不可逆动作也持更保守态度。

一个常见中断：交互认证

执行删除 GitHub 仓库时，若 gh token 缺少 delete_repo scope，Claude 不会强行绕过，而会停下来要求在终端手工执行：

gh auth refresh -h github.com -s delete_repo

这反映了远程工作流的硬限制：

模型可使用已登录的 CLI
但无法替操作者完成浏览器授权或设备码登录等交互过程

遇到认证缺口时，合理处理方式是暂停，等回到电脑前补齐权限。

已知问题

Channels 当前仍存在两个尚未修复的问题：

Claude Code 在 REPL 空闲时，消息有时不会送达
插件偶尔在回复一轮后停止转发，需要重启或人为唤醒

由此，Channels 更接近"可用但未达运维级稳定的远程入口"。对应的实践原则：

重要任务不应仅依赖一次长会话
中间结果尽量落盘、提交、可恢复
出现异常时优先检查会话是否仍存活，而非先怀疑提示词

调整 Auto Mode 的安全规则

多数个人项目使用默认规则即可。需要调整时，先查看内置配置：

claude auto-mode defaults

该命令会打印内建的 allow/block 规则。一项重要原则是：基于默认规则增量修改，避免从零重写。每去掉一层既有保护，更多判断压力就会被转嫁给分类器，而分类器并不零失误。

Anthropic 公布的数据：

真实工具调用上的误报率约 0.4%
针对"过度激进动作"的漏报率约 17%

17% 的漏报率不可忽视。在高风险场景中，分类器并非最后防线。

规则书写

项目级配置位于 settings.json 的 permissions 下。窄规则较为可靠，宽规则风险偏高。例如：

Bash(pytest) 合理
Bash(gh pr create *) 勉强可接受
Bash(*) 风险过大

若工作流原本依赖权限确认作为阶段性检查点，可采取两种处理方式：

显式增加 ask 规则，将特定动作恢复为人工确认
改用 acceptEdits，保留更多人工控制点

会话级软约束

Auto Mode 会把对话中声明的边界视为阻断信号的一部分。例如明确告知：

不要 push，除非我确认

这种会话级约束往往足以让模型在匹配动作上主动收手。对一次性任务而言，比修改正式规则更轻量。

查看生效配置

合并默认规则与本地配置后的最终结果可通过：

claude auto-mode config

企业环境下，管理员可通过托管设置直接关闭 Auto Mode。

这套方案解决的问题

Auto Mode + Channels 解决的并非"模型能否写代码"，而是另一个更实际的问题：

让 Claude Code 脱离桌面前的同步交互，进入可异步驱动的状态。

此前的工作模式要求操作者守在终端：

查看每一步工具调用
点选每一个确认
等待每一轮执行完成
再继续下一轮

切换为远程异步后：

在手机上发任务
由本地机器跑完一轮
回来查看结果
发起下一轮

这相当于把 Claude Code 从"终端助手"扩展为"个人远程开发代理"。但这一描述仍受到几条明显边界的约束：

缺乏中途的流式可见性
存在插件稳定性问题
认证流程无法远程补齐
分类器并非绝对安全网

因此更准确的定位是：当前的 Auto Mode + Channels 已足以承担个人项目的远程异步开发，但尚不适合对高风险系统完全放手。

实践要点

将这套工作流投入实际使用时，可遵循以下要点：

1. 从小项目起步

不在生产仓库上做试验，先在副作用可控的项目中建立手感。

2. 保证宿主机会话可恢复

tmux、Git 提交、中间产物落盘都不可或缺。

3. 在提示词中加入验证要求

少问"是否完成"，多要求"贴出 pytest -v 的原始输出"。

4. 为外部系统动作显式划定边界

例如：

不要 push 到主分支
不要删除远程仓库
改完先给出 diff 摘要

5. 避免滥用宽权限

精细规则比通配符安全。能写成 Bash(pytest)，就不写 Bash(*)。

总结

Auto Mode 与 Channels 的组合，让 Claude Code 在操作者离开电脑后仍可继续推进本地开发会话。其价值不在于"远程编码"本身，而在于把以往必须守在终端前的重复流程，转换为按回合推进的异步协作。

核心取舍如下：

default 节奏过慢，远程体验差
bypassPermissions 风险偏高，远程可见性又不足
auto 落在一个可接受的中间地带

若目标是用手机闭合"提需求—看结果—继续迭代"的开发循环，这套组合值得认真试用。前提是清楚其边界，并为这份便利保留必要的人工判断。

关于

关注我获取更多资讯

📢 公众号

💬 个人号