我一直觉得，大多数人说“手机没法跑代码智能体”，其实是被官方支持列表给框住了。Claude Code（也就是大家常说的CC）、Codex CLI、Cursor，官方确实都优先照顾桌面端，但这不代表安卓就完全没戏。折腾了快一个月，我在安卓上把这几个工具基本都跑通了，CC和Codex能在Termux里直接干活，Cursor则走了远程桌面方案。这篇文章就是把我踩过的坑、试出来的可行路径，从头到尾捋一遍，给想“随时随地掏出手机写代码”的人一个可以照抄的参考。

先说清楚一个容易误会的事：这里的CC指的是Anthropic推出的Claude Code命令行工具，不是网上搜“CC攻击源码”时冒出来的那种东西，那类内容本身也属于网络攻击工具，既不合法也不安全，别混在一起。Codex是OpenAI官方的编程Agent命令行工具，Cursor则是目前很火的AI代码编辑器。这三者的共同点是：都能把大模型接进编程流程，让你用自然语言指挥它读写文件、跑命令、改代码。区别在于，CC和Codex是纯CLI工具，手机跑起来反而相对友好；Cursor是完整IDE，官方又没有Linux ARM版客户端，所以安卓端只能换思路。

我最终定的方案是这样的：在安卓上用Termux跑一个proot的Linux发行版（我用的是Ubuntu 24.04），把CC和Codex装进去；Cursor则改成远程方案，通过移动端访问我在家里PC上运行的Cursor实例。这个组合的好处是，所有PC端已有的项目、缓存、模型配置都能直接复用，手机上只是多了一块“移动屏幕”，而不是重新配一遍环境。接下来我把每一步的关键细节、为什么这么选、以及卡住最多人的联网问题单独展开说。

1. 为什么在安卓上跑Agent这么折腾：先搞清楚三大工具的差异

1.1 三种工具的真实定位差别很大

很多人以为CC、Codex、Cursor是同一类东西，直接套同一个安装方法，结果翻车。实际用下来，这三个的架构完全不同，适配手机的难度也是三个量级。

CC（Claude Code）是Anthropic推出的终端编程Agent，本质是一个Node.js命令行程序。你启动它之后会进入交互式REPL，它能在你的项目目录里读写文件、执行shell命令、调用工具，每一步操作都先征求你的意见。因为它是终端应用，不依赖GUI，所以在Termux里有天然优势，唯一的问题就是手机屏幕太小，交互体验要适应。

Codex CLI是OpenAI官方推出的命令行Agent，同样基于Node.js，交互逻辑和CC类似，但默认更偏向“沙箱执行”：它会在本地临时目录里运行你让它写的代码，然后给你返回结果。这个设计其实很聪明，手机这种环境反而更需要沙箱——就算Agent把代码跑炸了，也不会殃及你的整个文件系统。

Cursor则完全是另一回事。它是一个基于VSCode二次开发的完整IDE，界面、渲染、插件系统全都在GUI层，官方只提供Windows、macOS、Linux（x86_64）版本。安卓是ARM架构，又没有官方App，所以直接安装这条路基本是死的。我能想到的现实方案只有三种：一是用RDP/VNC远程连到一台装好Cursor的PC；二是用网页版IDE替代；三是退而求其次，用Cline、Roo Code这类VSCode插件形态的Agent工具绕开Cursor本身。后面我会详细讲我最终选的是哪条路。

1.2 安卓侧的共同障碍：CLI依赖、文件系统隔离、网络链路易断

不管装哪个工具，安卓上跑Agent都会遇到三个共性障碍，提前知道比踩完坑再回头理解要省事得多。

第一是CLI运行时依赖。CC和Codex都需要Node.js环境，而且对Node版本有要求（Codex要求18+，CC要求18.17+），安卓原生没有Node，必须靠Termux的pkg仓库或者proot里的Linux发行版来解决。第二是文件系统隔离，Termux的文件目录和安卓App私有目录是隔离的，如果你在proot发行版里装工具，它看到的文件系统和安卓本身又是两层，项目文件放在哪里、权限是否可读写，这些都要提前规划。第三也是最大的坎——网络链路，安卓的Wifi、蜂窝网络切换非常频繁，锁屏后系统还会限制后台流量，Agent跑着跑着突然网络断了，那叫一个崩溃。

1.3 我为什么选Termux + proot发行版，而不是容器App

市面上有各种“在安卓上跑Linux”的方案，比如Termux本体、Termux + proot-distro、UserLAnd、Andronix，还有需要root的chroot方案。我全部试过之后，留下来的是Termux + proot-distro，原因有三个。

第一，proot不需要root，这对绝大多数普通用户来说是硬性条件——安卓root不仅麻烦，而且会带来安全风险。第二，proot-distro提供的是完整发行版，apt、gcc、python、node这些依赖装起来非常顺手，比在Termux原生环境里硬怼要省心。第三，它和Termux共享宿主内核，性能损失没有虚拟机那么大，手机跑Node.js项目不至于卡到不能用。代价是proot的IO性能确实比原生差一些，装npm包的时候会明显感觉到慢，但这个可以接受。

1.4 先想清楚：你是要“真用”还是“尝鲜”

动手之前我还得泼一盆冷水。如果你只是想“在手机上试试CC和Codex能不能跑”，那看到这里就可以直接跳到第二章按步骤操作。但如果你是想把手机当成日常的主力开发终端，我建议你先想清楚场景——手机屏幕就那么点大，Agent回复一长串diff的时候阅读起来非常吃力，外部键盘又不可能随身带。我现在的使用场景是通勤路上、会议间隙、出差途中，用来改改bug、补补文档、跑跑小脚本，真到大规模重构，我还是回电脑前干。

2. 让安卓虚拟机先通网：卡住大多数人的第一步

2.1 其实“联不上网”的根本原因不是网络，是DNS和连接跟踪

很多人在Termux里装好proot发行版，一运行发现curl百度都超时，第一反应就是“手机的网络权限不行”。我排查下来发现，绝大多数情况不是权限问题，而是proot环境下网络栈的“半通”状态。

Termux本身跑在Android的应用层，它的网络其实是通的，但proot发行版是独立的用户态，传统上它复用宿主机的网络接口，可它内部的/etc/resolv.conf不会自动生成。你ping一下IP可能通，但一用域名就超时，这就说明系统DNS配置是空的。另外proot环境下 /proc文件系统的网络统计可能不准确，部分工具判断“网络是否可用”会误报。

我遇到的最典型的症状是：apt update报Could not resolve host，但curl一个具体IP地址完全正常。这时别急着去开各种网络权限，先检查发行版内部的DNS配置。

2.2 我实测可用的联网配置步骤

下面这套配置方式我在Ubuntu 24.04 proot环境里验证过，照着做基本能解决90%的联网问题。

先装好Termux和proot-distro，进入Ubuntu发行版：

# 在Termux主机上 pkg update && pkg install proot-distro -y proot-distro install ubuntu proot-distro login ubuntu

进入Ubuntu后，第一件事就是检查并写入DNS：

# 检查当前DNS配置 cat /etc/resolv.conf # 如果内容为空或只有localhost，直接写入可信的DNS服务 echo "nameserver 8.8.8.8" > /etc/resolv.conf echo "nameserver 1.1.1.1" >> /etc/resolv.conf

注意：proot环境下直接修改/etc/resolv.conf不一定会被网络请求读取，有些服务会优先读取/etc/nsswitch.conf里配置的解析方式。如果改完还是不通，再确认一下nsswitch：

# 确认hosts行包含files dns两项 grep hosts /etc/nsswitch.conf # 正确输出类似：hosts: files mdns4_minimal [NOTFOUND=return] dns

还有一个很容易被忽略的点：Android 10以上对应用的后台网络访问做了限制。Termux如果被系统判定为“不活跃应用”，锁屏后网络就会断。我的解决办法是在系统设置里把Termux的“电池优化”设为不限制，同时在Termux里锁定一个wakelock，避免Agent跑一半被系统休眠。

# 在Termux宿主环境执行，防止息屏断网 termux-wake-lock

最后验证一下内外网连接是否正常：

curl -I https://registry.npmjs.org curl -I https://api.openai.com

如果这两条都返回HTTP状态码，恭喜，联网这一步就通了。

2.3 IPv6和连接池问题：两个不太显眼的绊脚石

还有两个比较隐蔽的问题，如果你在proot里跑Agent时偶尔出现“网络明明通但请求偶尔失败”，大概率跟它们有关。

第一个是IPv6。Android的Wifi网络经常同时分配IPv4和IPv6地址，但proot环境下的IPv6路由有时候并不完整。Node.js默认会优先尝试IPv6，如果IPv6半通，请求就会卡在连接超时才回退到IPv4。我选择直接在Ubuntu里禁用IPv6，一了百了：

# 写入sysctl配置，禁用IPv6 cat >> /etc/sysctl.conf << 'EOF' net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 net.ipv6.conf.lo.disable_ipv6 = 1 EOF # 立即生效 sysctl -p

第二个是连接池问题。Node.js的底层网络库会默认复用TCP连接，在手机这种网络环境经常切换的场景下，复用连接很容易拿到一个已经过期的socket，表现就是Agent第一次请求失败、第二次才成功。我用的笨办法是给NODE_OPTIONS加参数，禁用连接复用：

export NODE_OPTIONS="--dns-result-order=ipv4first"

这一行能让Node.js优先解析IPv4，能在源头上减少很多莫名其妙的请求超时。

3. Codex CLI在安卓上的安装与实测记录

3.1 安装本身反而最简单：一条npm命令

Codex的安装过程比我预想的简单得多，它就是一个npm全局包。在proot Ubuntu环境里先把Node装上，然后执行：

# 安装Node.js LTS版本 apt install -y nodejs npm # Codex要求Node 18+，当前版本还要求npm 9+ node -v npm -v # 全局安装Codex CLI npm install -g @openai/codex

装完输入codex --version确认一下。整个安装过程最慢的是npm下载依赖，手机网络差的时候可能要等好几分钟，中间不要切后台，否则Termux的下载进程会被系统挂起。

3.2 登录鉴权是第一个真正的大坑

Codex装好之后，运行codex会进入登录流程。官方默认的登录方式是浏览器授权，这很考验你的耐心——因为手机上没有浏览器能直接和CLI完成本地回调，我在实测时发现它打印出一个授权链接后，需要用手机浏览器打开并登录OpenAI账号，然后还要想办法把授权码传回CLI。

更麻烦的是，Codex的登录凭证默认存在~/.codex/目录下，我登录成功后发现，如果在proot里跑过codex login，凭证文件的所有者是自己，倒没遇到权限问题，但如果你换了proot发行版或者清理了用户目录，凭证就全没了。

有一个相对流畅的方式是用设备码登录：

# 在CLI中初始化登录 codex login # 如果它提供device code选项，优先选它

但说实话，如果你本来就在用OpenAI的API，那么更省事的方式是直接跳过登录流程，走API Key配置。编辑~/.codex/config.toml：

# Codex配置文件示例 model = "gpt-5" model_provider = "openai" [model_providers.openai] name = "OpenAI" base_url = "https://api.openai.com/v1" env_key = "OPENAI_API_KEY"

然后在Shell环境里设置OPENAI_API_KEY，codex就会直接用API Key鉴权，绕开整个浏览器授权流程。这个方式对手机用户非常友好，不用处理任何回调。

3.3 Codex接入DeepSeek：很多人不知道的用法

Codex本身只认OpenAI的API，但它的远端模型是可配置的。这段时间DeepSeek很火，很多人想在Codex里接DeepSeek的模型，操作方法其实就是改config.toml里的model_providers：

model = "deepseek-chat" model_provider = "deepseek" [model_providers.deepseek] name = "DeepSeek" base_url = "https://api.deepseek.com/v1" env_key = "DEEPSEEK_API_KEY"

改完在环境变量里配上DEEPSEEK_API_KEY，再运行codex，就能用DeepSeek的模型驱动它干活。这个能力对安卓场景特别有价值——因为移动端对Token消耗更敏感，DeepSeek这类模型价格比GPT-5便宜很多，手机拿来跑一些日常改代码任务，成本可控得多。

3.4 实测Codex跑任务的典型翻车：agent execution terminated due to error

如果你在安卓proot里跑Codex，会时不时看到一句“agent execution terminated due to error.”，很多人一看到就以为是模型崩了或者API挂了。我查了日志后发现，这个报错的真实触发点大概率是执行环境超时或权限不足。

Codex默认在沙箱目录里执行它写的代码，它会创建临时目录去跑命令。在proot环境下，有些系统调用（如chroot、mount）是被限制的，Codex在检测环境能力时如果遇到它认为“不可用”的项，就会直接终止Agent执行。我的解决办法是给Codex指定一个可写空间，同时降低它的执行权限需求：

# 建一个专门给Codex用的工作目录 mkdir -p ~/codex-workspace chmod 700 ~/codex-workspace export CODEX_WORKSPACE=~/codex-workspace

再跑codex exec的时候加上--full-auto参数前，先跑一个简单任务试试水。实测下来，在proot环境里，Codex跑Python脚本、Node脚本之类的常规任务问题不大，但涉及系统级安装（apt install）时经常因为权限边界报错，这属于正常限制，别太纠结。

4. Claude Code（CC）在安卓上的安装与终端适配

4.1 CC的安装命令和Codex完全同源

CC同样是npm包，安装方式几乎一模一样：

npm install -g @anthropic-ai/claude-code

装完在命令行输入claude，首次运行会提示登录。和Codex不同的是，CC的登录流程更简单一些——它也是浏览器授权，但Anthropic支持API Key方式。你在环境变量里设置：

export ANTHROPIC_API_KEY="sk-ant-xxxx"

这样就不必走交互式登录，直接claude就能进入对话界面。我在手机上强烈建议用API Key方式，因为浏览器授权在移动端实在太容易中断。

4.2 终端渲染：手机上跑CC的最大体验障碍

Codex是标准的CLI程序，对终端渲染要求不高；但CC不一样，它重度依赖终端ANSI转义序列、交互式选择器、彩色输出和Unicode图标。在PC的iTerm2或Windows Terminal上体验很好，但到了手机Termux的默认终端里，文字会乱掉、图标变成方块、长命令换行错乱。

我当时试了好几个安卓终端App，最终体验最稳的是Termux内置的终端配合字体修改。步骤是装一个支持Powerline字体的终端字体，并设置成默认：

# 在Termux中安装Nerd Fonts系列字体 pkg install -y fonts

然后在Termux设置里把字体切换为nerd字体，CC的图标和边框渲染基本就正常了。如果你觉得麻烦，也可以简单粗暴地把CC的终端输出设为纯文本模式：

# 让CC尽量避免ANSI颜色样式 export NO_COLOR=1

4.3 用tmux解决手机锁屏断会话的痛点

手机跑CC最大的麻烦不是装不上，而是“跑了一个长任务之后锁屏，回来发现会话已经断了”。CC是交互式CLI，进程一被系统回收整个对话就没了。我强烈建议配合tmux使用，这才是安卓跑CC的正确姿势：

# 安装tmux apt install -y tmux # 新建一个常驻会话 tmux new -s coding # 在tmux里启动cc（如果是从Termux登录Ubuntu后操作） claude # 锁屏、切走都没关系，回来再附着： tmux attach -t coding

tmux的好处是，即使Termux进程被系统杀掉（这个在安卓上很难完全避免），重启Termux后进到Ubuntu里tmux attach -t coding，你的CC会话还挂在后台。我第一次用这个方案时，锁屏半小时后重新打开，看到Agent还在继续工作，那种感觉确实爽。

4.4 手机跑CC时的模型选择建议

CC在手机上的交互成本高，每一条消息都要仔细看，所以模型本身的稳定性就特别重要。我的实测感受是：Claude Opus系列更适合复杂重构任务，而Sonnet系列在速度和成本上更适合移动场景。日常小改动我直接用Sonnet，只有在处理复杂跨文件改动时才切Opus。CC支持在会话里通过命令切换模型，你没设别名的话，直接/model就能呼出切换菜单。

5. Cursor在安卓上的三条可行路径

5.1 直接装Cursor是死路，别浪费时间

先说结论：Cursor没有Android版客户端，也没有Linux ARM版，哪怕你用proot模拟一个Ubuntu ARM环境，它依然装不上——因为Cursor的安装包是x86_64架构，ARM上连安装器都跑不了。所以如果有人告诉你“在安卓上直接装Cursor”，那就当段子听吧。

但这不代表安卓完全和Cursor无缘，核心思路从“运行Cursor”变成“访问Cursor”。

5.2 路径A：远程桌面访问PC上的Cursor（我最推荐）

我在家里有一台长期开机的PC，用来跑日常开发。我的做法是在这台PC上装好Cursor，然后通过RDP/VNC远程访问到手机。远程桌面App我用的是RD Client（微软自家的，安卓商店有）和另一些支持RDP协议的客户端；网络层用Tailscale建了一个虚拟局域网，这样手机在外面也能直连家里的PC，不需要额外暴露端口。

实际体验下来，Cursor在手机远程桌面里虽然有点延迟，但胜在“一切能力都在”：Cursors索引、代码跳转、AI对话框、插件都能正常用。配合蓝牙键盘，你甚至能比较流畅地写代码。这一条路最适合那些已有主力PC的人。

5.3 路径B：网页版IDE替代，把“编辑器”留在云端

如果你不想依赖家里的PC，另一个思路是直接用开源网页版IDE替代Cursor。我在手机上测过code-server（VS Code的网页版），再配上Cline或Continue插件，获得的能力约等于“70%的Cursor体验”。Cline这个插件我很喜欢，它跟Cursor的Composer/Chat类似，你可以在侧边栏里描述需求，它会调用Claude或OpenAI模型去改代码。

配置方法是：先在PC上跑一个code-server实例，然后手机浏览器访问它的Web界面。由于全程走HTTPS，手机在外面也能连，只要PC端公网可达或者走虚拟组网，体验都还行。不过要提醒一下，code-server的移动端适配比较一般，小屏手机上操作面板略挤，iPad类的大屏会好很多。

5.4 路径C：放下Cursor执念，在Termux里用Cline替代

如果你的核心需求只是“用AI帮我改仓库里的代码”，那还有一个更轻的方案：直接用Termux跑Claude Code或Codex，再加上一个自己的快捷键习惯。我在时间紧的时候，经常直接用CC处理项目里的Issue，而不是打开Cursor——终端的方式虽然看起来朴素，但胜在处理简单任务反而更快，尤其是一句话能讲清楚的改动，终端操作比在IDE里折腾还快。

5.5 关于“Cursor中文怎么设置”的通用答案

最近很多人搜“cursor中文怎么设置”“cursor汉化”，我顺手解释一下：Cursor是基于VSCode的，所以语言设置和VSCode一脉相承。按Ctrl+Shift+P打开命令面板，输入Configure Display Language，选择“Install additional languages”，安装中文语言包，然后切到简体中文重启即可。

如果你是远程桌面连PC上的Cursor，这个操作在PC端完成，手机端看到的界面会自动变成中文。如果你用的是code-server路径，它也是VSCode内核，方法完全一样。

6. CC Switch与Codex网关配置的坑：API转发不是玄学

6.1 CC Switch到底是个什么东西

热词里“cc switch官网”“cc switch下载”出现频率很高，很多人把它当成什么神秘工具。其实CC Switch是一个开源配置切换器，核心功能是让你在多个模型提供商之间快速切换配置，而不用每次改配置文件改到怀疑人生。它同时支持对CC和Codex的配置管理，甚至带了一个本地转发能力，能让不支持某个模型服务的客户端通过本地端口访问到配置好的服务地址。

说实话，在PC端用CC Switch纯属锦上添花，但在安卓Termux场景，CC Switch的价值就大了——因为你手搓配置文件的成本比在PC上高得多。我更愿意直接编辑配置文件，这行是对的；但如果你想用CC Switch管理，就得先解决那个最常见的报错。

6.2 高频报错：cc switch local proxy failed while handling codex endpoint /responses

这个报错在搜索榜上出现了不止一次，当时用户反馈是“cc switch本地转发服务在处理codex endpoint /responses时失败了”。我自己复现过一次，原因是CC Switch启动的本地监听服务（默认跑在某端口），在转发请求到远端模型服务时，远端返回了非预期响应。

排查链路是这样的：

1. 确认本地监听端口是否被占用。在proot环境里执行netstat -tlnp | grep 你配置的端口，如果发现另一个进程占用了该端口，CC Switch会报绑定失败。解决办法是改端口配置，避开冲突。
2. 确认转发目标地址是否正确。CC Switch配置项里的远端地址末尾不能缺/v1，否则Codex按OpenAI规范发请求时会打到错误的路径上。
3. 确认模型名称是否匹配。Codex请求会带“model”字段，如果CC Switch没有把请求里的模型名映射成提供商支持的名字，提供商可能会返回404或400，从而被CC Switch判定为转发失败。

6.3 Critical报错：401 unauthorized的真相

还有一个报错是“unexpected status 401 unauthorized”，这个在CC Switch场景下绝大多数原因是鉴权信息没传对。很多人以为在CC Switch里填一次API Key就万事大吉，但Codex的请求头Authorization要求是Bearer格式，CC Switch在转发时必须原样传递。如果你填的Key里带了多余空格、换行，或者提供商不支持你当前选择的模型，401就会接踵而来。

我的建议是，在安卓proot环境里先不急着用CC Switch，你直接用环境变量方式验证Key有效之后再考虑转发器。比如手动执行一个curl请求：

curl https://api.openai.com/v1/models \ -H "Authorization: Bearer sk-你的key"

如果这个请求通过，说明Key没问题，问题只出在CC Switch到提供商的链路中间。这时候再去检查它的配置映射，而不是反复换Key浪费时间。

6.4 我在安卓上管理多配置的原始但稳定方式

既然CC Switch在移动端偶发问题，我更推荐用一套“环境变量+配置文件模板”的土办法。把常用配置写成多个config文件，比如config.deepseek.toml、config.openai.toml，用的时候用一个软链接切换：

ln -sf ~/.codex/config.deepseek.toml ~/.codex/config.toml

这套办法的好处是，切换配置就一条命令，出错也容易回滚，不需要额外跑一个常驻进程，也自然避免了local proxy类问题。

7. 资源配置与真实体验：手机跑Agent到底行不行

7.1 内存和Swap是决定成功率的底线

我第一台测试手机是8GB内存，跑Codex和CC都能流畅运行；后来又拿4GB内存的旧手机试，Node进程频繁被系统杀死。原因很简单，Node.js运行时本身占用300~500MB内存，Codex/CC进程再加一个大模型响应缓冲区，很容易破1GB，4GB内存的机器在系统层面就会开始回收进程。

解决办法是给proot环境加Swap。在Termux宿主环境里，你可以创建一个swapfile：

# 在Termux宿主环境创建2GB swapfile fallocate -l 2G swapfile chmod 600 swapfile mkswap swapfile swapon swapfile

但要注意，Android本身可能会在后台清理所有swap内容，所以Swap的逻辑更像给进程一个“假寐”机会。真正常态使用的建议是：主力机型至少8GB内存，12GB或以上体验最佳。

7.2 温度与电池：高强度跑Agent，手机真的会烫

我连续让CC处理一个项目的批量重构时，半小时后手机背面明显发热，电池掉电速度肉眼可见。这在物理层面绕不开——所有计算都发生在本地Node进程，大模型推理虽然跑在云端，但编码、流式传输、渲染都要耗费CPU和网络资源。

建议控制单次任务的复杂度，尤其是用CC时别一次性丢一个大项目给它；把任务拆小，每跑一个阶段让手机歇一会儿。如果你真的有长时间跑Agent的需求，散热背夹会明显改善体验。

7.3 5G与Wifi的选择：稳定优先

我在蜂窝网络和Wifi之间测试过，5G网络的延迟更低但频繁切换基站可能造成连接阶段性断开；家用Wifi更稳定但上行带宽限制影响流式响应速度。Agent对网络稳定性要求高于带宽，我在外面跑CC时都会优先固定在比较稳定的5G网络，然后关闭“智能切换WLAN”选项，避免手机在两个网络之间反复横跳导致连接中断。

7.4 安卓跑Agent这件事，未来会越来越多

虽然当前安卓跑CC和Codex还有不少糙点，但方向已经很明确：模型推理往云端迁移，终端Agent越做越轻，Node.js这类跨平台运行时在ARM上的性能也在改善。再过一两年，手机原生跑Agent会像现在手机原生跑代码编辑器一样稀松平常。不过就当下而言，能在一台不带键盘的设备上稳定地用CC改完一个bug，已经不是“能不能”的问题，而是“有没有耐心配置好”的问题。

最后分享一个我自己的习惯：我现在通勤时用的是平板加Termux，做到一半的事情存成项目里的TODO.md，回到电脑前直接claude加上“继续完成这些任务”，上下文无缝衔接。这比任何花哨的同步方案都实在。如果你也想在手机上折腾，耐心点，把这篇文章里的几个关键节点走通，大概率不会卡在半路。