ddy-android-dev 云手机上的安卓应用，用对话装好、跑起来、查清楚
时间：2026-11-06 16:05 作者：官方
把 ddy-cli 那一整套命令面，收敛成一套有纪律的操作流程：它知道你连的是哪套系统、哪个环境、哪个账号；它替你选对命令通道；它在删数据、换设备、改机这类动作前停下来问你。
形态：AI 技能（SKILL.md） 依赖：ddy-cli + 多多云账号 通道：本地 / TCP 直连 / ADB 隧道 分发：ddy-android-dev.zip → 各 IDE 技能目录 随附 CLI：三平台二进制，免联网安装
你不是在学一个工具 你只需要会说出意图（“把这个 APK 装到三台云机上”），技能负责环境检查、命令选择、失败兜底。 |
真正省事的是“记性” 系统 × 环境 × 账号三元组被登记成人类可读的名字，按「仓库 + 分支」记住，跨会话、跨 IDE 复用。 |
真正危险的是“安静” 环境对、账号错的写入是最难排查的事故。技能在套用上下文前强制校验账号，不一致就停。 |
目录
1 · 它是什么
2 · 触发边界
3 · 能力地图
4 · 典型场景
5 · 安装（技能 + CLI）
6 · 激活与首用
7 · 多环境与多账号
8 · 安全闸门
9 · 故障速查
10 · 反模式
11 · 参考文件
01 它是什么
一句话：一个跑在 AI 助手里的「云手机操作员 SOP」。
云手机（多多云）上的安卓调试，本身是纯命令行活儿：要登录、要选订单、要判断设备是运行中还是离线、要决定这一条命令该走 TCP 直连还是 ADB 隧道、上传失败要退避重试、改机之后数据不保留得先说清楚。这些步骤每一步都写在文档里，但没人愿意每次都翻。
ddy-android-dev 就是把这份文档变成助手的行为：收到你的请求后，它按固定顺序解析上下文 → 环境就绪检查 → 设备状态预检 → 执行 → 失败走兜底，并且知道哪些动作必须先开口问你。
它替你记住身份 连接身份 = 系统 × 环境 × 账号。这套三元组被写成名字（如 XX应用-线上-手机6721），按仓库和分支登记在本地注册表里。 |
它替你选通道 装应用、看前台、截图、定位走 TCP 直连（轻、快、不需要 adb）；只有端口转发、推文件、改云机 hosts 才拉 ADB 隧道。 |
它替你守住闸门 换机、重置、清数据、卸载、装 Xposed、改机参数——全部先停下说明后果，拿到你明确同意才执行。 |
和“直接问 AI 敲命令”的区别 直接问，AI 会凭记忆造命令（现场出现过整套虚构的 device model set --profile 之类）；技能把命令面钉死在由二进制导出的 commands-reference.md 上，并要求不确定就查该文件或 --help。 |
02 触发边界：什么时候它会出现，什么时候不该
技能的 description 里写死了正向和负向边界。理解这条边界，比背命令更重要。
会触发 · 只要涉及云手机设备或安卓应用调试 云手机 ddy / ddy-cli 远程安卓 云手机调试 / 云端测试 TCP 直连 改机 / 多环境 云机 hosts 典型意图：装 APK、跑 adb shell、看装了哪些应用、截图、设 GPS、授权 Root、装 Xposed、一键新机、切环境、上报故障设备。 |
不触发 · 纯本地工程活儿 编译构建（go build / 编译 APK） 代码开发 / 重构 生成文档 运行单元测试 git 操作 CI/CD 配置 与本云手机无关的配置管理 负向边界是刻意写死的：否则「帮我编译一个 debug 包」这类任务会被技能抢走，反而多绕一圈。 |
灰区怎么判 “编译 + 装到云机上”属于混合任务：前半段是本地构建（不走技能），后半段是设备操作（走技能）。实践中直接说清楚哪一步要技能做，最省事：“已构建好，把这个 APK 装到云手机 12345 上”。 |
03 能力地图
先认清三条命令通道，再看功能域。中高阶用户最容易踩的坑，就是通道选错。
三条通道，各有归属
通道 A | 本地命令 | config / auth / orders ——只动本机与账号，不碰设备 |
通道 B · 推荐 | TCP 直连 | app / device 系列——无需 ADB，更轻更快 |
通道 C · 按需 | ADB 隧道 | 仅用于端口转发（forward/reverse）、文件推送（push/pull）、云机 hosts（adb hosts） |
是不是本机配置或环境准备？
是 → 通道 A。登录、查订单、看当前系统环境都属于这一类，不会动到任何一台云机。
需要端口转发、文件推送，或要改云机里的 hosts？
是 → 通道 C。这是 ADB 隧道唯一的正当用途，别拿它装应用。
其余情况？
→ 通道 B。装包、起停应用、Shell、截图、GPS、Root、改机、守护、备份，全部走 TCP 直连。
硬前提：订单必须支持 ADB orders detail 里的 isSupportADB 为 0 时，端口转发、文件推送、 adb hosts 全部不可用——不是配置问题，是订购规格问题。此时只能改走 TCP 直连，或换一台支持 ADB 的设备。 |
功能域一览
功能域 | 做什么 | 要点 |
应用安装调试 | 装 APK、验证安装、启动、批量装多台 | 首选 app install apk --file（支持单台/批量、自动解析包名）；ADB 直装仅在需要标准 ADB 协议时、且仅单台 |
Shell 调试 | 执行 shell 命令、看日志、模拟按键 | adb exec 便捷模式；或 TCP 的 device shell exec；受限 shell 只放行 Xposed 白名单命令 |
文件与存储 | 上传文件、查配额、列已传文件、清临时文件 | 上传报 5001 走重试 + 指数退避；仍失败才 fallback 到 adb push |
设备状态 | 查订单详情、连通性测试、daemon 状态 | orderStatus 是设备健康的主判据，动手前必看 |
应用管理 | 已装应用列表、前台应用、启动/停止/卸载/清数据 | app list / get-top 是排障第一步；stop 支持逗号分隔多包名 |
设备操作 | 截图、GPS 设置与查询、剪贴板、传感器、发广播、H5 连接 Token | 全部 TCP 直连；截图可 --file 落盘 |
Root / Xposed | 查 Root 状态、授权应用、全局 Root 模式、装卸 Xposed | 属于破坏性操作，先确认；Xposed 可能需要重启设备 |
改机 / 一键新机 | 随机机型、指定机型、预设方案、深层改机 | 两套体系：device params（一键新机）与 device newparams（深层改机），方案 ID 互不通用 |
网络 | 连通性检查、设置 socks5/http 代理、VPN | 代理与 VPN 是设备侧配置，与你这台机器的网络无关 |
应用守护 | 全局开关、守护应用增删改、重启策略 | 适合需要常驻的宿主/助手类应用 |
备份与恢复 | 应用数据备份、恢复 | 恢复必须带与备份时一致的 --scheme-id；恢复会覆盖现有数据 |
端口转发 | 本地→设备（forward）、设备→本地（reverse）、后台模式 | “让云机里的应用访问我本机 3000 端口”是 reverse，方向别弄反 |
多系统 / 多环境 | fork 系统接入、环境切换、让云机 App 也切环境 | CLI 侧映射不影响 App；改云机侧仍需 adb hosts apply，一台云机同一时刻只有一个生效环境位 |
文本输入 | 往云机里输入中文 / emoji / ASCII | 设备端只接受按键命令，input text 会被拒并返回 -1——一律 device paste |
屏幕录制 | 录屏取证、复现问题留证 | 适合给测试/研发留不可辩驳的现场 |
04 典型场景：你说话，它做事
下面每一条都是技能被验证过的真实提问方式。注意“它替你做的事”这一栏——那才是价值所在。
核心流程 你会说 它替你做的事 省掉的麻烦 |
批量 你会说 它替你做的事 注意 |
Shell 调试 你会说 它替你做的事 省掉的麻烦 |
端口转发 你会说 它替你做的事 坑 |
设备排障 你会说 它替你做的事 维护子流程 |
应用巡检 你会说 它替你做的事 |
设备能力 你会说 它替你做的事 |
高风险动作 你会说 它替你做的事 为什么重要 |
企业级 你会说 它替你做的事 |
05 安装
两条路径：把包丢给助手让它装（最快，推荐），或者自己解压到对应目录（可控，可审计）。
路径 A · 一句话安装（推荐）
把 ddy-android-dev.zip 放进 AI 工具能读到的地方——拖进对话框，或拷进当前项目目录——然后对它说一句话就行。
我上传了 ddy-android-dev.zip，这是一个 AI 技能包。请帮我安装到本工具的用户级技能目录，并自检： |
最短也可以只说「帮我安装这个 skill」——但上面那段把“装到哪、层级对不对、执行位、装完怎么验”四件事都说死了，结果更可控。
为什么这条路靠谱 你不需要知道 pi 是 agent/skills 还是 skills、不需要记 6 个 runtime 各自的家目录位置——助手对自己的技能目录比人熟。它查、它解压、它自检，你只负责验收一句“装在哪”。 |
三个前提 • 该工具能读到你放进去的 zip，并且对它自己的技能目录有写权限。 • 如果它跑在沙箱里、写不了家目录，它会直接把命令给你——你复制执行即可，等价于路径 B。 • 装完仍需开一个新会话（WorkBuddy 除外），技能才会被重新扫描到。 |
路径 B · 手动安装
适合要精确控制安装位置、或需要在多台机器上脚本化部署的场景。分三件事，别混为一谈。
第 1 件 | 技能落盘 | 把 ddy-android-dev.zip 解压到 IDE 的用户级技能目录 |
第 2 件 | 对准目录 | 多个 IDE 多份拷贝；pi 是 agent/skills，不是 skills |
第 3 件 | CLI 可达 | 把包内二进制接到 PATH（或直接用绝对路径） |
账号与登录不在安装里，它是使用前的准备——见第 06 节。另外，如果路径 A 已经装好，本节剩下的命令你一次都不用敲。
第 1 件 · 技能落盘（解压 ddy-android-dev.zip）
技能以压缩包形式提供：ddy-android-dev.zip。它就是一个完整技能包，解开即用：
包内路径 | 内容 |
SKILL.md | 技能定义（name + description + 正文流程）—— AI 认的是它 |
references/ | 命令参考、工作流、排障手册 |
scripts/ | 三个平台的 ddy-cli 二进制 + 上下文绑定工具 context_store.py |
安装动作只有一步：把包解开到对应 IDE 的用户级技能目录下。唯一的验收标准是最终路径为 <技能目录>/ddy-android-dev/SKILL.md——包里怎么打包都行，以这条路径为准。
# ① 先看包里带不带外层目录 ddy-android-dev/ |
# Windows PowerShell（与右键“全部解压”等价；以 Claude Code 为例） |
三个装错的高频原因
• 多套了一层目录：解压后变成 skills/ddy-android-dev/ddy-android-dev/SKILL.md，runtime 就找不到技能。以 SKILL.md 的位置为准：它必须直接在 .../skills/ddy-android-dev/ 下，多一层就把内层内容上移一层。
• 二进制没有执行权限：macOS / Linux 解压后默认不可执行，必须 chmod +x。 macOS 若被 Gatekeeper 拦下（提示无法验证开发者），先放行一次或 xattr -d com.apple.quarantine <文件>。
• Windows 的“来自其他计算机”标记：从网络下载的压缩包解出的 exe 可能被 SmartScreen 拦住，右键 exe → 属性 → 勾选“解除锁定”。部分安全软件会对云手机调试工具误报，按公司策略加白名单。
解压后不用装 Python、也不用联网 压缩包里已经是筛过的可分发内容（不含仓库内部维护脚本与测试）。唯一的外部依赖是 context_store.py 需要 Python 3（仅在你使用多环境/多账号绑定时才用得到）。 |
第 2 件 · 各 IDE 的技能目录矩阵
这是“复杂 IDE 环境”最容易错的地方：同一个技能，每个 runtime 各有一份物理拷贝。同时用两个 IDE，就把同一个包往两个目录各解压一次。
工具 | 用户级技能目录 | 备注 |
Claude Code | ~/.claude/skills/ | 最常见的主路径 |
dsh | ~/.dsh/skills/ | 独立目录，与 claude 不共享 |
zcode | ~/.zcode/skills/ | 目录不存在时自行创建 |
codex | ~/.codex/skills/ | 同上 |
pi | ~/.pi/agent/skills/ | ⚠️ 是 agent/skills，不是 ~/.pi/skills |
WorkBuddy | ~/.workbuddy/skills/ | 目录监视即时扫描，解压后无需重启 |
四条手工安装最需要注意的事
• 每个 IDE 各解压一份：技能是物理拷贝、不是共享软链，两个 IDE 不会自动共享同一份文件。装了新版要逐个目录更新。
• 升级时先删旧目录再解压：直接覆盖可能残留旧文件（旧二进制、旧 references），出现“文档说 A、行为是 B”的怪象。
• 备份不要留在 skills 目录里：备份目录同样含 SKILL.md，runtime 会把它当成一个独立技能加载，凭空多出一个触发词重复的重名技能。
• 解压与压缩工具的选择：Windows 用系统自带“全部解压”或 PowerShell，别用会把中文文件名弄乱的第三方工具；中文路径本身没有问题。
安装后看不到技能？先开一个新会话 runtime 一般在会话启动时扫描技能目录。刚解压完的当前会话可能还没扫到；WorkBuddy 例外，它的目录监视会即时收录。 |
第 3 件 · 让 ddy-cli 可用（技能自带二进制，免联网）
技能目录里自带三个平台的二进制，随技能同步一起分发，按「平台-架构」命名：
平台 | 技能内路径（相对技能根） |
Windows x64 | scripts/ddy-cli-windows-amd64.exe |
macOS arm64 | scripts/ddy-cli-darwin-arm64 |
Linux x86-64 | scripts/ddy-cli-linux-amd64 |
两种用法：拷到 PATH（推荐，之后统一按 ddy-cli 调用），或直接用绝对路径。
# 方式一：拷到 PATH（示例为 Linux/macOS 的 ~/bin） |
绝对路径会随 runtime 变 上面示例里 ~/.claude/skills/…只是 Claude Code 的前缀。换成 pi 就是 ~/.pi/agent/skills/ddy-android-dev/scripts/…，其余同理。技能正文里的路径示例也按同样规则替换。 |
版本核对（三步就够）
ddy-cli --version # 应回显 Ddy-Client-CLI v1.3.0-32-g6c8aebf |
dev 构建的命令面会漂移 --version 带 dirty 字样说明是本机 dev 构建，命令面可能与 references/commands-reference.md（对应 v1.3.0-27-g3da8178）不一致。此时以 <命令> --help 的实际输出为准。技能自带的 v1.3.0-32-g6c8aebf 命令面未变。 |
06 激活与首用
“激活”在这个技能里没有隐藏开关：技能侧靠文件被发现，账号侧靠配置与登录。
技能侧：它怎么被“激活”
• 文件落盘到上表的用户级技能目录即可被 runtime 发现，没有插件注册、没有守护进程、没有后台常驻。落盘这个动作可以直接交给助手做（见第 05 节路径 A）。
• 发现依据是 SKILL.md 的 frontmatter name + description；description 里的触发词决定它何时被唤起。
• WorkBuddy 有目录监视，同步后即时生效；其他 runtime 若发现技能未出现，开一个新会话（新会话才会重新扫描技能目录）最稳妥。
• 验证方式：让它做一件明显在能力边界内的小事，例如说「查一下云手机订单列表」。它能调出 orders list 并回话，说明技能与 CLI 都通了。
账号侧：五步走到可操作
# ① 生成配置（首次；密码通过环境变量传，不要贴在对话里） |
会话内它每次都会走的顺序
Step 0 | 解析上下文 | 注册表命中 → 播报；未命中 → 只问一次并登记 |
Step 1 | 环境就绪 | CLI 可用 / config.yaml / 登录 / 系统与环境 / 订单 |
Step 2 | 设备预检 | 按 orderStatus 判断，异常先进维护子流程 |
Step 3 | 执行 | 选对通道，破坏性动作先确认 |
设备状态判据（orderStatus）
值 | 含义 | 技能的处理 |
2 | 运行中 | 继续执行 |
4 | 已结束 | device start → 轮询 |
1 / 3 / 5 | 过渡态 | 等 5 秒重新检查，不硬上 |
其他 | 异常 | 进入设备维护子流程 |
订单过滤时会排除 orderStatus 为 -1（已删除）与 -2（维护中）——这两类出现在列表里不代表可用。
5 分钟验收清单 1. ddy-cli --version 有输出，版本串与技能内二进制一致。 2. 目标技能目录下能看到 SKILL.md、references/ 与 scripts/ddy-cli-<平台>，且没有多套一层目录。 3. macOS / Linux 下二进制已 chmod +x，直接执行能回显版本号。 4. ddy-cli auth whoami -o json 返回你的账号尾号。 5. 你对助手说一句“查一下云手机订单列表”，它调的是 orders list 而不是现编命令。 |
07 中高阶：多环境、多账号、并行会话
这一节是技能真正的护城河。跳过它，你迟早会写错一次用户库。
核心概念：上下文 = 系统 × 环境 × 账号
“我连的是哪套后台”由三件事共同决定，缺一不可。同一账号不同环境是两个上下文；同环境不同账号也是两个上下文。
• 系统：决定连哪个 fork 后台与哪套登录态。
• 环境：决定域名解析到哪儿。
• 账号：决定写进哪个用户库。
技能把三元组登记成一个人类可读的名字。技能给出的命名格式建议是 <系统或默认>-<环境>-尾号<后4位>，但名字最终由你确认，团队里也常见更直白的写法，例如 XX应用-线上-手机6721。
注册表在哪、怎么记
• 位置：~/.ddy/context-bindings.json，始终在用户主目录，不跟随 DDY_HOME。
• 查找顺序：分支级 → 仓库默认 → 未命中才问。所以同一仓库的不同分支可以各用一套环境。
• 完整手机号只存在注册表里，任何输出一律脱敏。
• 只通过脚本读写，手工编辑会绕过校验和锁。
目的 | 命令 |
查当前 | context_store.py resolve --cwd "$PWD" --json |
写入并绑定 | context_store.py set ··· --cwd "$PWD" --default / --branch <分支> |
列出 / 看单条 | context_store.py list / show --name "<名字>" |
改名 / 删除 | rename --old "<旧>" --new "<新>" / remove --name "<名字>" |
账号校验 | auth whoami -o json | context_store.py verify --name "<名字>" --observed - |
context_store.py 随技能分发，路径同样是 <技能根>/scripts/context_store.py。
账号校验的三个返回码，三种处置
返回码 | 含义 | 处置 |
0 | 匹配 | 继续执行 |
1 | 不匹配 | 停止，播报双方脱敏号码，建议修正注册表或切换登录 |
2 | 无法判定 | 停止并询问你，不做猜测 |
为什么账号不一致必须停 “环境对、账号错”会安静地写进另一个用户库。事后排查成本远高于此刻停下来的成本——这是技能里少数不允许继续的硬停止点。 |
你说的话 → 作用域 → 是否落库
你会说 | 作用域 | 落库？ |
“这次用线上” | 仅本回合 | 否 |
“这个会话都用线上” | 本会话 | 否 |
“以后这个分支都用本地” | 该仓库该分支 | 是（set --branch） |
不说话 | 按注册表：分支级 → 仓库默认 → 未命中则问一次 | 首次确认时登记 |
前缀决策表：并行会话的正确姿势
技能每一条命令都靠命令级前缀确定身份，而不是改全局指针。中高阶用户只需记住这张表：
你的诉求 | 用什么 | 为什么 |
只换环境 | DDY_ENV=<env> ddy-cli … | 登录态天然按环境分槽，互不踩 |
只换系统（fork） | DDY_SYSTEM=<system> ddy-cli … | 避免写盘全局默认；需 CLI ≥ v1.3.0-27 |
换登录账号，或要一整套独立身份（含密钥库、隧道/守护状态） | DDY_HOME=<独立目录> ddy-cli … | 主配置只留一个会话写 |
回到默认 | 不设前缀 | 由注册表决定 |
让云机里的 App 也切环境 | ddy-cli adb hosts apply --order <ID> | CLI 侧映射不影响 App；一台云机同一时刻只有一个生效环境位 |
不要用 config env use / config system use 切当前会话 两者都是写盘全局指针，并行会话会互相覆盖。它们只在“单会话 + 你明确要求改全局默认 + 无并行会话”三个条件同时成立时才用；有并行会话时，即使单次会话也不能用。 |
DDY_HOME 隔不掉什么（2026-10-16 实证）
• adb server（tcp:5037）全机单例：任何会话跑 adb doctor --fix 或重启 server，会拆掉所有会话的 forward 与连接。
• 同一台云机同一时刻只归一个会话操作：A 的 disconnect / hosts apply 会拆掉 B 正在这台机上用的隧道和环境位。
• adb forward -l 手动指定端口跨会话共享：两个会话指定同一端口必然相撞。
结论：DDY_HOME 隔离的是账号、密钥库与 CLI 状态，不是物理资源。设备与 adb server 需要你自己协调。
域名访问受限时：切到备用域名
CLI 的所有请求都发往 api.domain 指向的域名，默认是 ddyun.com。若你所在区域访问 .ddyun.com 受限（表现：登录接口连不上、请求超时或提示域名无法访问），把域名切到备用的 .ddyun123.com 即可——两个域名指向同一服务。
# 看当前域名 |
切换后要重新登录一次 域名是登录态的一部分，改完直接跑业务命令往往仍报未登录/登录失效，重新登录一次最稳。如果切到 .ddyun123.com 后提示「错误的账号或密码」，说明这是两个不同的用户库，请切回 .ddyun.com 重试。 |
08 安全闸门
技能把“确认”当成你的决策点，不是流程噪声。下面这些动作，它一定会先停下来说明后果。
必须先拿到你明确同意 • device reset / device change • app clear / app uninstall • xposed install / uninstall • 改机类：device params random|scheme apply、device newparams random|scheme apply|set-baidu-mock • app account restore（覆盖现有数据） • config system remove（连同密钥库条目与 token 槽位一起删除） • adb hosts clear、ADB 里的 rm / pm clear 等破坏性命令 |
不强制确认 • reboot / start（含维护流程内的重启） • 所有查询类命令 • screenshot、app list、app get-top • config get、config env/system current|list|show |
改机与换机不保留数据 确认对话里会明确说明这一点，而不是只说“要重启”。如果你只看到“要重启”，说明当时的说明不充分，值得追问一句。 |
密钥永远不进对话 config system add 是隐藏输入，机密只进加密密钥库 ~/.ddy/system_keys.dat。签名密钥、DES Key、密码一旦以明文出现在对话或文件里，即视为泄露。 |
别为了“跑通流程”加 --yes 交互确认是你的决策点。替它加 --yes，等于替你自己签字。 |
09 故障速查
三段式：先试一线修复，无效再走兜底，别跳步。
现象 / 错误码 | 一线修复 | 仍失败的兜底 |
15 / 1003（登录信息失效 / Token 过期） | ddy-cli auth auto-login | 引导重新 auth login；反复出现则查 config system/env current 是否指向了不对的服务端 |
提示 .ddyun.com 域名无法访问 / 登录接口连不上或超时 | ddy-cli config get api.domain 确认当前域名 | ddy-cli config set api.domain ddyun123.com 后重新登录——部分区域对 .ddyun.com 访问受限，切备用域名即可 |
「错误的账号或密码」，但你确认密码无误 | ddy-cli config get api.domain 看域名是否被人改过 | 切回 ddy-cli config set api.domain ddyun.com 重登；仍不行再试 ddyun123.com |
3002 / 3003，或 orderStatus 异常 | 设备维护子流程：device reboot → 5s × 12 轮询 | 仍未回 status=2 → 停下、说明数据不保留、你确认后 device change |
5001（上传失败） | 重试上传，最多 3 次、指数退避 | 改用 adb push（需 isSupportADB 为 1） |
stderr 含 TCP / connect | device daemon status，必要时 device daemon start；再 device test | 仍不通 → device reboot → 轮询；不恢复按设备异常处理 |
isSupportADB 为 0 | 凡 ADB 类命令（端口转发、推文件、adb hosts）全部改走 TCP 直连 | 确需 ADB 才能做的 → 该订单不支持，需换支持 ADB 的设备 |
adb doctor 报 adb 路径/版本异常 | ddy-cli adb doctor --fix 重启 server 并复检 | ddy-cli adb config set adbPath "<PATH 上的新版>" 后复检 |
想输入文字但报 -1 | 设备端只接受按键命令，停止使用 adb shell input text | 改用 device paste（中文 / emoji / ASCII 一律走它） |
更完整的错误码体系（1xxx 认证、2xxx 订单、3xxx 设备、4xxx 应用、5xxx 文件、6xxx 短信验证）见 references/troubleshooting.md。
10 反模式清单
下面每条都是实测踩过的坑。照着做会直接失败，或者造成损失。
• 不要臆造 ddy-cli 命令。命令面以 references/commands-reference.md（由二进制导出）为准；不确定就查该文件或跑 --help。现场出现过整套虚构命令面。 • 不要用 adb shell input text 输入文字。设备端只接受按键命令，中文 / emoji / ASCII 一律走 device paste。 • 不要混用两套改机体系的方案 ID。device params（一键新机）与 device newparams（深层改机）的方案列表与 ID 各成一套，混用会取错方案或不生效。 • 不要擅自加 --yes。交互确认是用户的决策点，跳过它等于替用户签字。 • 不要让密钥出现在对话里。签名密钥、DES Key、密码只进加密密钥库；明文出现即视为泄露。 • 不要用换机 / 重置代替排查。先把 reboot → 轮询这条链走完，仍异常再向用户确认换机。 • 不要用 config env use / config system use 切当前会话。两者都写盘全局指针，并行会话互踩。 • 不要手工编辑 ~/.ddy/context-bindings.json。一律走 context_store.py，手改会绕过校验和锁。 • 不要假设设备支持 ADB。先看 isSupportADB。 • 账号校验不一致时不要继续。停下报错，比换设备排查便宜。 |
11 参考文件
技能目录内的四份支撑材料；遇到没覆盖的情况，答案通常在其中。
文件 | 内容 | 什么时候看 |
SKILL.md | 技能主体：通道选择、Step 0–4 流程（上下文解析 → 环境就绪 → 设备预检 → 执行 → 维护子流程）、安全规则、反模式 | 想理解“它为什么会这样判断” |
references/commands-reference.md | ddy-cli 完整帮助文档（由 cobra 自动生成），对应 v1.3.0-27-g3da8178 | 要确认某条命令到底存不存在、参数怎么写 |
references/workflows.md | 19 条关键工作流 + 命令速查表（多环境切换、多系统接入、网络、文本输入、录屏、备份、深层改机、adb 诊断） | 要照着做一遍完整流程 |
references/troubleshooting.md | 错误码映射、自动修复策略、常见问题排查 | 报错不知道从哪修 |
scripts/context_store.py | 上下文绑定注册表工具（随技能分发） | 管理多环境 / 多账号绑定 |
路径提醒 以上均为技能目录内的相对路径。实际绝对路径 = <对应 IDE 的技能目录>/ddy-android-dev/…，例如 ~/.claude/skills/ddy-android-dev/references/workflows.md。 |
包里带的 CLI 版本 三个平台的二进制均为 v1.3.0-32-g6c8aebf（2026-10-20 / 21 构建）。拿到新版压缩包时直接覆盖旧目录即可，版本以 ddy-cli --version 回显为准。 |
ddy-android-dev · 云手机安卓开发调试技能 · 产品向使用说明
依据技能当前正文与 references 整理；随附 CLI 版本 v1.3.0-32-g6c8aebf。技能行为变更时，本页需同步更新。
本页为单文件、零外部依赖，可离线打开或直接打印为 PDF，与 ddy-android-dev.zip 一并分发。
