只拷一个 exe 过去能用吗：安卓修改大师电脑版绿色版与安装包的文件契约

有一个问题在用了半年之后一定会出现：我要把它装到另一台机器上。

场景都不复杂——换了新笔记本、给同事装一份、装到公司那台专门用来出包的台式机上、或者干脆想同时留两套互相不干扰的环境。但真正动手的时候，一堆小问题会集中冒出来：拷哪个文件夹？只拷 exe 行不行？要不要管理员？装到 D 盘还是 C 盘？目标机器上没装 .NET 怎么办？以后卸载会不会把项目一起删掉？

这些问题单独看都很小，但它们有一个共同点：答案都写在文件怎么摆放上，而不是写在界面上。界面里看不到"我需要 7z.exe 在我旁边"这件事，直到那个功能弹出一句提示。

所以这篇讲的不是操作步骤，而是一份目录契约：哪些文件必须在一起、哪些可以分开、装到哪里最省事、卸载时什么会留下。理解这份契约之后，你搬到任何一台 Windows 机器上都不会踩坑。

一、先理解一件事：这不是一个 exe

很多人对"绿色软件"的印象是：一个 exe，双击就跑，拷走就能用。这个概念在十年前基本成立，但对这套工具不成立，原因是它身上挂了三样外部依赖。

第一样是运行库。它是 .NET Framework 4.6.2 及以上编译的桌面程序。Windows 10 1607 之后的系统自带 .NET 4.x，所以绝大多数机器不用管；但 Windows 7 SP1、8.1、以及一些精简版系统上，这个前提不成立，双击会直接报缺少运行库。

第二样是解压工具。「更新反编译环境」这个功能要解服务端下发的 7z 格式工具包，而它只从程序目录里找 7z.exe，不会去系统里搜。所以这两个文件（7z.exe 和 7z.dll）必须和主程序躺在同一个文件夹里。少了它们，那个功能会明确弹一句「程序目录里没有 7z.exe」——注意，除这个功能之外，其余功能不受影响。

第三样是若干第三方 DLL。「循环打包去毒」里要用到一堆云存储 SDK，它们是随程序一起编译进来的独立 DLL 文件（阿里云、腾讯云、七牛、Minio、S3 兼容等等各自一套）。这些 DLL 只在主程序旁边才被找到。

顺带说一个容易被忽略的细节：目录里还有一个 Resources\话术库.xml，3000 条话术都在这一个文件里，是纯文本，可以用记事本直接改。这意味着它天然是可以定制的——你可以把自己团队常用的那几十条加到前面，也可以删掉用不上的分类，改完在界面上点一下刷新就生效，不需要重新安装。

二、绿色版清单：哪些必须有，哪些可以有

把绿色目录摊开看，文件其实分三类：必须有、缺了会损失某个功能、以及运行时自己生成的。分清这三类，你就知道搬家时什么不能漏。

文件 / 目录	类别	缺了会怎样
ApkGallary.exe	必须有	没有主程序，无从谈起
*.dll（云存储 SDK 及依赖）	必须有	「循环打包」发布到云存储那一步会失败
7z.exe / 7z.dll	必须有	「更新反编译环境」会提示找不到 7z.exe
ApkGallary.exe.config	建议保留	运行配置缺失，个别行为会回落到默认值
Resources\话术库.xml	建议保留	话术列表空着，只能自己现写需求
settings.ini	可自动生成	首次运行会自己生成一份带注释的默认配置
使用说明.txt	可有可无	不影响运行，只是少了份随包说明书

这张表里最值得记住的是中间那两行：DLL 和 7z 不是"可选配件"，它们决定了两块功能可用不可用。而它们恰恰是最容易在搬家时被漏掉的——因为资源管理器默认不显示扩展名的情况下，一堆 dll 看起来像系统垃圾。

一个实用的检查方法：搬家之后先打开「参数设置」，看「工具检测」那一块。它会把 aapt、java、apktool、7z、zipalign、签名工具逐个列出来，显示找到没有、完整路径是什么。哪一项空着，就说明那一块搬家时漏了或者路径变了。这比"用到的时候才发现"要省事得多。

还有一件事值得提前知道：工具目录是自动搜索的，不需要手工登记。程序会在 tools 目录下递归查找 java 环境、aapt、apktool、zipalign、签名工具。这意味着你完全可以按自己的习惯组织子目录——比如按版本号分层、或者把不同来源的工具分开放——只要它们在 tools 底下，就能被找到。换一套工具包时，把新的解压进去、旧的挪走，重启程序即可，不用改任何配置。

这种"扫而不是登记"的设计有一个隐性好处：它让工具链是可以整体替换的。你想试试更新版本的 apktool，不需要在界面里改路径，把它放进去就行；试完不满意，删掉换回旧的。整个过程中程序配置一个字都不变，出问题也容易回退。

三、安装包的两条路：轻量版与离线版

如果你不想手工拷贝目录，或者要装到一台自己不太能控制的机器上，安装包更省心。它装的东西和绿色版完全一样，区别只在一件事：运行库是现场下载还是随身带。

模式	体积	缺运行库时	适合谁
轻量版（默认）	约 6 MB 级别	内嵌微软官方 web 安装器（约 1.4 MB），联网按需下载	绝大多数人。Win10 1607 之后系统自带 .NET 4.x，根本走不到下载这一步
离线版	约 118 MB	内嵌完整离线运行库（约 121 MB），不联网也能装完	内网机器、不能联网的工位、要装几十台的场合

这里有一个很多人会误判的地方：两种模式都只在目标机器确实缺运行库时才会去装。已经够用的机器直接跳过，不下载、不联网。所以离线版并不会"白装一遍运行库"，它只是把那份包随身带着备用。反过来说，如果你确定目标机器是 Win10 之后的系统，选轻量版就是最优解——带着 121 MB 去装一台本来就不需要的机器，纯粹是拖慢传输。

判断"缺不缺"的方式很具体：读注册表里 .NET Framework 的版本号，低于 394802 才装。这个数字是 .NET Framework 4.6.2 的最低版本值。为什么不用 394271？因为那是 4.6.1 的值——如果用它当门槛，只装了 4.6.1 的机器会被判定为"够了"直接跳过，然后程序跑不起来。这类"门槛取错一位，漏掉一整类机器"的坑，在部署脚本里非常常见。

四、装到哪个目录，为什么是英文名

默认装在盘根下一个叫 AiApkEditor 的目录里，向导里可以改。D 盘不能用就自动退到 C 盘的同名目录。判断"能不能用"有四条，任何一条不满足就算不能用：

① 盘存不存在（比如你把 U 盘拔了，或者那个分区被删了）；

② 盘有没有就绪（有些移动硬盘、加密盘需要先解锁）；

③ 剩余空间够不够（门槛是 1 GB）；

④ 能不能在里面建目录并写文件（权限问题往往卡在这里，而不是空间）。

顺序是 D → E → F → G，四个都不行才用 C。把系统盘放最后不是偏心，而是经验：盘根目录下的文件夹会从盘根继承权限，而系统盘上这类位置经常被 UAC 和政策管着，往里写东西失败的概率明显更高。而程序恰恰需要在自己的目录里写配置文件，这一条不满足，后面全是麻烦。

目录名用英文，是为了避开中文路径在个别环节上的麻烦。这一点值得多说一句：中文路径本身不是错误，但它会让某些工具链的报错信息变得难以阅读——路径被转义成一串乱码，你在日志里看到的不是"哪个文件找不到"，而是一堆百分号。英文目录直接把这类噪音消掉了。

还有一个设计上的巧合，用起来很顺：这个目录名和程序自己挑工作目录时用的名字是同一个。所以当你装在默认位置时，"程序目录"和"工作目录"是同一层——exe、tools\、Project\ 全在一个文件夹里。整个产品只占一个英文目录，备份、迁移、打包带着走，都是一次复制的事。

如果你手工改过工作目录（在「参数设置」里保存路径），这个巧合就断了：程序在一处、项目在另一处。这本身完全没问题，但你要知道备份的时候得备两个地方。保存自定义路径时，程序会自动把配置里"自动挑盘"那一项改成关闭，之后不再自动挑——这是对的，否则你每次启动都会被搬回去一次。

五、必须管理员，以及装完之后那两个权限细节

安装包要求管理员权限，很多人会本能地觉得"又是一个要权限的软件"。但在这套工具上，这条要求有两个非常具体的原因，都不是习惯性的。

第一个原因是运行库。.NET Framework 是整机安装的组件，写注册表、装到系统目录、注册程序集，这些操作没有管理员权限做不了。而安装包里恰好带了"缺就装"的能力，所以它必须先拿到这个权限，才有可能在需要的时候用上。

第二个原因更微妙：在盘根建目录并设权限。在 D 盘根下创建一个文件夹，本身可能不需要管理员；但要让这个文件夹有正确的权限继承关系（尤其是后面那句"给普通用户修改权"），就需要。这两件事连在一起，只能整体要求管理员。

装完之后有一个细节特别值得知道：安装目录给普通用户开了修改权限。这个动作看起来是"放松安全"，实际上是为了让软件能正常工作——因为程序要在 exe 同目录写 settings.ini，而 Resources\话术库.xml 也需要你手工改完之后能保存。

这一点如果不做，会表现成一个很难理解的现象：你在记事本里改好话术库，点保存，提示"拒绝访问"。很多人会以为是文件被占用，其实是权限问题。盘根目录下的文件夹从盘根继承的权限，默认并不允许普通用户修改已存在的文件——新建可以，改动不行。安装程序把这条放开，就是为了避免这种"看起来像 bug 的权限问题"。

六、卸载：它刻意留下了三样东西

卸载行为是判断一个工具"懂不懂自己的用户"的关键指标。这套工具卸载时只删自己的程序文件，三样东西会留下：

① tools\ —— 工具链，包括 java 环境、apktool、aapt、签名工具，往往几百兆；

② Project\ —— 你所有的项目和原始包；

③ %LocalAppData%\ApkGallary\ —— 登录缓存。

实现方式是不删目录、只删空目录（目录非空就跳过）。所以重装之后，你的项目和工具链全都还在，登录状态也在，打开就是熟悉的界面。这个行为的意义不是"省事"，而是消除一个心理负担：你不需要在卸载前做一次"要不要备份"的挣扎。

反过来说，如果你是真的想清理干净（比如要把机器交出去），那需要手工删这三处。这时候顺序建议是：先在界面上把项目逐个删掉（它有防呆，只删工作目录下的直接子目录），再删 Project 和 tools，最后卸载程序。不要反过来——先卸载再手工删，容易因为记不清哪些是程序的、哪些是自己的，删错东西。

静默部署：给要装很多台的人

安装包支持静默安装，参数是标准的那一套：/VERYSILENT /SUPPRESSMSGBOXES /NORESTART。三个参数各管一件事：不显示界面、不弹任何框、装完不自动重启。

想跳过桌面图标，后面加一个 /MERGETASKS="!desktopicon"。这个写法有点反直觉（前面有感叹号是"取消这一项"的意思），但它是标准语法，照抄即可。

静默部署还要注意一件事：装完不会自动启动，也不会自动登录。所以批量部署的流程应该是"装完 → 各台机器第一次打开 → 登录一次"，而不是指望装完就能用。登录状态是存在每台机器本地的 local.ini 里的，无法通过复制安装目录带过去——这是账号体系的性质决定的，不是部署方式的问题。

七、搬完之后，先跑一遍最小闭环

环境装好了、界面能打开了，很多人到这一步就认为"搬完了"。但真正的验证标准是另一件事：能不能完整地改一个包、打出来、装到设备上、看到改动生效。这条链路上有四个环节，任何一个断了，你都会在真正急着出包的那天才发现。

所以搬完之后的第一件事，建议拿一个自己的小应用跑一遍完整闭环，而且刻意选一个"改了立刻能看出来"的改动。下面两个是我们自己在换机器后固定会做的两次验证。

这两次验证加起来不到十分钟，但它确认的东西很多：工具链在不在、aapt 能不能解析、反编译能不能跑完、签名能不能过、设备能不能连上、装完能不能拉起。任何一项在新机器上出问题，都会在这十分钟里暴露，而不是在你赶着交付的那天。

八、三个真实的迁移现场

上面讲的是原则，下面三个现场是我们自己碰到过的，每个都对应一种不同的选择。

现场一：换笔记本，想连项目一起带走。这种情况其实最简单——因为默认位置下程序目录就是工作目录，整个文件夹复制过去就全带走了：exe、工具链、话术库、所有项目、所有历史。新机器上唯一要重做的是登录（登录缓存存在用户目录，不在程序目录里）。复制完之后建议先把旧机器的目录改名留一份，别急着删，等新机器跑通两周再说。

现场二：给同事装一份，但不该把你的项目给他。这种要用安装包，而且装完要把 Project 清空（如果是拷目录的方式装的话）。同时值得把定制过的话术库一起带过去——如果你们团队有几条固定写法，把它们放进 Resources\话术库.xml，对方一上手就能用你们的表达方式，而不是从零摸索。这是最便宜的一次"团队标准化"。

现场三：内网机房，十几台机器不能联网。这里有两个决定：用离线版安装包（否则缺运行库的机器装不上），以及先把工具链备好再分发。因为工具链有几百兆，每台机器都从网上下一次，在受限网络里会非常难受。做法是先在一台机器上把环境更完，把 tools 目录打包，跟着安装包一起分发，装完之后直接覆盖进去。这样每台机器打开就能干活。

九、八种现场现象，一句一句对上原因

部署类问题有一个共同特点：现象看起来像软件坏了，原因几乎都在文件的位置上。下面这张表是按实际遇到频率排的，从上往下越来越少见。

看到的	真实原因	怎么处理
双击没反应或报缺少运行库	目标机器没有 .NET Framework 4.6.2+	用安装包（会自动补齐），或手工装运行库
「更新反编译环境」提示找不到 7z.exe	只拷了 exe，没拷 7z.exe / 7z.dll	把这两个文件放进 exe 同目录
循环打包发布那一步失败	缺少云存储 SDK 的 DLL	改用整目录复制，别只拷 exe
配置改完保存不了、话术库不让改	盘根目录权限没放开（常见于绿色版）	换位置，或手工给目录加修改权限
导入 apk 解析不出包信息	aapt 不在 tools 里，或工具目录没被找到	看「工具检测」，缺的点「下载反编译环境」
项目列表是空的	工作目录变了（比如从 D 退到了 C）	看「参数设置」里的实际路径，把旧目录内容挪过来
装完打不开、提示未登录	登录缓存不随目录迁移	在新机器上登录一次即可
卸载之后项目全没了	多半是先手工清空了 Project，不是卸载删的	卸载本身只删程序文件；项目丢失要找备份或回收站

这张表里第六行值得多看一眼：「项目列表是空的」最常见的真实原因是工作目录变了。比如你把 D 盘那个分区腾空或者改了盘符，程序下次启动自动挑盘时就会落到 E 盘，建一个新的空目录。你的项目还在 D 盘上好好躺着，只是程序现在看的是 E 盘。

这类"东西都还在，就是找不到"的情况，处理原则只有一条：先去「参数设置」看它现在认为工作目录是哪，再决定是把项目挪过去，还是把路径改回去。不要急着重新导入——重新导入会建新项目，历史就断了。

十、九个常被问到的问题

问一：能装在 U 盘里带着走吗？可以，绿色版整目录复制到 U 盘就能跑。但要注意两件事：U 盘拔掉之后程序会报错，而且工作目录也会跟着消失，项目就一起带走了——这既是优点也是风险。真要这么用，建议把工作目录固定在 U 盘上并在「参数设置」里显式指定，避免它偶尔挑到别的盘。

问二：能同时装两套、各用各的项目吗？能。装到两个不同目录，各自的工作目录就分开。想做"一套正式、一套试验"这种隔离，这是最干净的做法——试验那套改坏了，删掉重来，正式那套一点不受影响。

问三：装的时候能不能不装到盘根？能，向导里可以改，装到任意可写目录都行。但要注意"程序目录 == 工作目录"这个便利只有在默认位置下才成立；装到别处之后，项目会另外建在工作目录下，备份时记得两处都看。

问四：为什么有的机器上第一次导入特别慢？因为要建缓存、要拆包。这是第一次的成本，不是每次都这样。同一个项目再改就快了。不要因为第一次慢就以为环境有问题——判断标准是"第二次是不是快了"。

问五：工具链必须用自带的那份吗？不需要。程序在 tools 目录里递归搜索，你把别的版本放进去，它就用新的。唯一例外是 7z：那个必须跟 exe 放在一起。

问六：能不能把话术库换成我们自己的？能，而且这是最值得做的一次定制。它是纯文本 XML，六个分类各 500 条的结构可以改，加自己的条目也行，改完在界面上点刷新即生效。团队里有固定的表达习惯时，这一步比任何培训都直接。

问七：绿色版和安装版能不能混用？可以，但别指向同一个工作目录。两套程序同时操作同一个项目目录，配置和历史会互相覆盖——这不是谁的问题，是两个进程同时写同一份文件的必然结果。

问八：卸载之后重装，项目还在吗？在。卸载只删程序文件，tools 和 Project 都留着。这也是为什么"先卸载再手工清理"这个顺序需要小心——很容易把还想留的东西一起删掉。

问九：公司电脑有安全软件，会不会拦？可能会。这类工具本身会调用外部程序（java、aapt、adb），在比较严格的环境里可能被拦。处理办法不是关掉安全软件，而是把工具目录加进白名单，并且不要放在会被定期清理的临时目录里。这一点在受管机器上尤其重要。

问十：机器上已经有一份旧版本，直接覆盖升级可以吗？可以。安装包会覆盖程序文件，但不会动 tools 和 Project。唯一建议你先做的是：把 settings.ini 复制一份留底——如果你在里面改过不少参数，覆盖安装有可能把它换成新版本自带的默认配置，而你不一定记得原来那些值。这一条属于"几分钟换一份心安"。

另外补一个容易被问到的：升级之后工具链会不会跟着变？不会自动变。工具链是独立的一套文件，升级程序不等于升级工具。如果新版需要更新的工具，会通过「更新反编译环境」这条路径提示你，它有自己的节奏，和主程序的升级是两件事。

十一、交接时该留下的一页纸

部署这件事有一个特点：做的人当下清楚，接手的人永远不清楚。你自己装的那台机器，凭手感就能找到东西；换成同事、换成三个月后的你，全靠猜。所以装完之后花两分钟写一页纸，是整个流程里投入产出比最高的一步。

这一页纸不需要长，四行就够，但四行都必须写具体路径，不能写"默认位置"这种模糊说法。

第三行最容易被省略，也最容易在交接时出事。因为"环境状态"往往包含一些只有你自己知道的改动：某次为了试一个老包，把 apktool 换成了旧版本；某次为了过一个签名校验，在项目里指定了 jks；某个项目用了随机签名，重打一次签名就变了。这些都不写在界面上，但它们决定了产物能不能覆盖安装。

第四行则关系到最坏情况下的恢复能力。备份这件事在部署阶段做一次，成本几乎为零；等到数据丢了再补，成本是不可估量的。建议的备份粒度是"整个工作目录根"——因为它包含了程序、工具链、所有项目、所有历史，一次复制就完整。如果你只想备最重要的部分，那顺序是：Project 优先（不可再生），其次是话术库（可定制），最后才是工具链（可重新下载）。

这页纸放在哪也有讲究。放在项目目录里最自然，因为需要它的人一定会在那里找东西；放在聊天记录里最容易被淹没。更稳的做法是两边都放一份——项目目录里那份是给人找的，聊天记录里那份是给已经找不到项目目录的人找的。

为什么这页纸能省掉后面所有麻烦

写这四行的过程本身，就是一次自检。你必须去确认程序到底在哪、项目到底在哪、工具链到底齐不齐、备份到底有没有做——这四个问题里，任何一个你自己答不上来，就说明那里埋着一个还没爆的问题。

我们碰到过最典型的一次：一位同事在交接时写不出项目路径，因为他一直用的是默认位置，从没看过具体是哪个盘。结果那天他打开「参数设置」才发现，程序因为 D 盘被临时挪用过，已经把工作目录切到了 E 盘——他这一个月改的项目全在 E 盘，而他以为在 D 盘、并且在 D 盘上做过一次"备份"。备份的是一个月前的旧目录。

这件事没有任何技术难度，纯粹是因为"路径"从来没被写下来过。而它造成的损失是：需要重新找一遍这个月的改动。如果当时有那四行字，问题会在第一次备份时就被发现。

所以这页纸的价值不在"给别人看"，而在逼自己把隐含的状态说出来。凡是能说清楚的东西，就能被检查；凡是说不清楚的，迟早会以故障的形式重新出现一次。这条规律在部署上成立，在改包上同样成立——需求写得清不清楚，决定的是同一件事。

十二、从这些细节能看出三个取舍

把上面这些规则放在一起看，会发现它们不是零散拍出来的，背后有三个一致的取向。理解这三个取向，比记住具体条目有用——因为遇到没写在文档里的新情况时，你可以按同样的逻辑推。

第一个取舍：宁可多留，不可误删。卸载不删项目和工具链、删项目只删工作目录下的直接子目录、删之前要确认——这一整套都是同一个原则的延伸。在"清理干净"和"不要误删"之间，它稳定地站在后者。理由很实在：多留一点东西的代价是几百兆磁盘，误删一次的代价是不可恢复。

第二个取舍：把依赖摆在明处，而不是藏进系统。7z 必须放在 exe 旁边、工具链只从 tools 里找、配置写在程序目录而不是注册表——这些都是"不藏"的做法。好处是可移植、可备份、可整目录带走；代价是文件看起来多。这套工具选了多，而不是藏。

第三个取舍：判断放在前面，提示放在后面。缺运行库先判断再装、盘不能用先逐条判定再退、工具缺失在「工具检测」里提前列出来、参数设置页上直接显示"自动挑选：D 盘可用"——所有这些都是在做之前先判断，判断完再说清，而不是做了之后给一个含糊的失败。这也是为什么它的报错往往能直接指出下一步该干什么。

这三个取舍还会带来一个不那么明显的好处：问题变得可以定位。当一切都摆在明处时，"哪里不对"通常能一步找到；当依赖藏进系统注册表、配置散在用户目录、缓存放在临时文件夹时，同一个现象可能有七八个来源，排查就变成了猜测。部署这件事的舒适感，本质上来自这种可定位性，而不是来自文件多不多。

也要承认代价。文件摆在明处的代价是"看起来乱"，尤其是第一次打开那个目录，会看到十几个 dll 和几个不认识的 exe。有些人的第一反应是想整理一下——把 dll 收进一个子目录、把 7z 挪到 tools 里。请不要这么做。这些文件的位置是被依赖的，挪走之后程序就找不到它们了。理解了这一点，那个"乱"其实是可读的：主程序、它的依赖、它的工具，各就各位。

最后补一句关于"环境"这件事的看法。很多人把装环境当成杂事，觉得它跟"改包"这件事无关，能跳过就跳过。但实际上它决定了你后面每一次改包的下限：环境干净，出问题一定是需求或包的问题；环境糊着，每次出问题你都要先排除一遍"是不是环境的问题"。前者的排查是收敛的，后者是发散的。

所以这十分钟的部署验证，本质上是给自己买了一份"以后不用怀疑环境"的底气。它不产出任何交付物，但它让后面所有的产出都更可信。

还有一点值得记下来：部署完成后最好刻意"用一次完整的流程"，而不是零散地点几下。因为零散点击只会碰到你已经熟悉的那几条路径，而完整流程会把你平时容易跳过的地方都走一遍——建项目、写需求、等它改完、打包、装机、确认。这中间任何一处在新机器上不成立，都会立刻显形。

我们内部的习惯是：新机器部署完，先改一个"名字"，再改一个"图标"，然后把这个包真正装到一台手机上看一眼。三件事加起来不到十五分钟，但它们覆盖了整条链路。这十五分钟花掉之后，接下来一个月你都不用再想环境的事。

最后提醒一句：部署这件事做完就该被忘掉。如果你每天都在想"我这环境是不是有问题"，那说明它还没做好；做好的环境是那种你想不起来的、安静待在后台的东西。它不抢戏，但它让每一次开口都算数。

反过来，如果一台机器的环境让你每次都要先猜一遍，那它其实一直在向你收税——每一笔都不多，但一年下来是很大一笔。把税停掉的办法，就是回到那份目录契约上，一条一条对一遍。

十三、搬过家的人怎么说

顺便说一句，上面五条评价里提到的四个场景，其实都指向同一件事：部署的难点不在安装本身，在"装完之后你知不知道它在哪"。知道路径、知道缺什么、知道哪些会留下，这三件事解决了，任何人都能在半小时内接手一套环境。

这套流程还有一个隐形收益：当你把环境做成"任何人半小时能接手"的样子，你自己也就不再是那个不可替代的瓶颈。在团队里，这往往比省下多少时间更重要——它意味着你可以休假，可以请假，可以让别人替你做一单。

回到最开始那句话：只需说话，就能让应用变成你想要的样子。这句话能成立，前提是那套环境先在某个地方稳稳地站住——工具在、依赖在、项目在、记录在。这些东西平时不出声，但它们决定了你说的每一句话能不能真的变成一个能装进手机的包。

所以搬家这件事值得认真做一次。不是为了今天，是为了三个月后某台机器突然开不了机、或者你要在一台陌生电脑上赶一个交付的时候，你能只花十分钟就回到工作状态。工具在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn，安卓修改大师智改工坊把该带的东西都放在一个目录里，就是为了让你搬起来不用想太多。

---