从经典版搬家到智能版：老用户的无痛迁移与两手准备

先把话说在前面：这篇文章不是来劝人换工具的。用惯了修改大师经典版的人，手上那套动作是有肌肉记忆的——APK 拖进来、反编译、资源目录一层层翻、smali 一行行看、改完回编、对齐、签名、装到手机上点一遍、崩溃了再连日志看一眼。这套动作重复几年，闭着眼都能走完。

所以当"一句话改包"这种说法出现时，很多老手的第一反应不是兴奋，是警惕：是不是又要我重学一套？是不是要我把旧工程全都搬过去？是不是以后手动精修就没位置了？这篇文章要回答的正是这三问，而答案比想象中温和：不用搬得那么狠。你完全可以两手准备，让两个工具在同一台电脑上各干各的活。

一、老手为什么舍不得经典版

经典版是 2019 年上线、一路更到今天的 Windows 手动精修版，当前版本 V11.27.00.00，安装包 13.74MB，官网写明需要 ASP.Net 4.5 以上与 JDK 1.8 以上。它的价值不在于"功能多"，而在于过程全部可见：资源、AndroidManifest、smali 都摊在本地，随时打开检查，改了什么、没改什么，一眼就能对上。

对做逆向研究的人来说，"我看得见每一步"本身就是价值。SMALI 代码级修改能做的事，公告里写得很直白：破解、功能增强、逻辑调整，甚至在任何界面加上自己的代码——改什么、改哪里由用户决定。这句话的分量，只有真的在 smali 里找过方法调用、读过混淆后的控制流的人才懂。它不是一个"按钮"，是一种权限。

老手舍不得的还有三样东西，都不在功能列表里。

• 自己的目录习惯：工程放哪个盘、素材放哪个文件夹、哪个目录是"绝对不能动的"，心里有一张地图。
• 自己的签名库：哪套 jks 对应哪个产品、哪个测试 key 只能用在内部包上，这些对应关系是踩过坑换来的。
• 自己的排错路径：装不上先看什么、崩溃先翻哪段日志、改完黑屏是资源问题还是签名问题，一整套判断顺序。

这三样东西不是工具给的，是时间给的。任何一个新工具，如果要求你把这三样推倒重来，那它再快也不值得。好在这一次，不需要推倒。

二、先别卸载：同机共存是官方姿态

先给结论：修改大师经典版与智能修改电脑版可以装在同一台电脑上，各自管理各自的项目，互不冲突。这不是用户自己摸索出来的野路子，是官方在产品定位里就摆明的姿态。换句话说，你不需要在"老人"和"新人"之间做二选一——两个都留着，是允许的，也是被鼓励的。

为什么能共存？因为两套东西在磁盘上是分开的。电脑版每个项目一个 8 位随机字符串目录，自动写 config.ini、拷一份 source.apk，反编译输出放在 apktool 目录里；经典版有自己的工程结构，工程文件同样是本地的。项目目录不同、配置文件不同、签名设置各存各的，谁也不去动谁的文件夹。你不用做任何"隔离"工作，它们天生就是隔离的。

运行时也不打架。电脑版跑在 Windows 10/11 上，.NET Framework 4.6.2+ 系统自带，免安装解压即用；经典版按官网说明需要 ASP.Net 4.5 以上与 JDK 1.8 以上。两套运行时在同一台机器上并存是常态，不是冲突源。更关键的是，电脑版把 java、aapt、apktool、7z、zipalign、apksigner 放在自己工作目录的 tools 下，体检时逐个报是否就绪与完整路径，缺了环境点「立刻更新」就自动下载解压工具包——它用的是自己那一份，不会去改你经典版配好的 JDK。

共存靠的不是"兼容"，是"各过各的"。项目目录分开、工具链分开、签名配置分开，那么一台电脑上放两个改包工具，和放两个浏览器没有本质区别。

共存真正要注意的是习惯，不是技术。第一，别让两个工具指向同一个项目目录，各有各的家；第二，桌面快捷方式改个名，一个叫"经典版"、一个叫"智改"，别在赶时间的时候点错；第三，电脑版启动会自动挑盘，按 D→E→F→G→C 的顺序，取第一个可读写且剩余 ≥1GB 的盘，拼成 <盘符>:\AiApkEditor，参数页可以把路径改掉并固定下来——如果你习惯把改包资料都放在某个数据盘，第一次就固定住，省得以后每次找项目。

所以"先别卸载"不是客套话。卸载经典版省不下多少空间（13.74MB），却可能让你在遇到需要逐行看 smali 的那一天，重新装一遍、重新配一遍环境、重新想起当年那些坑是怎么填的。留着它的成本几乎为零，而它的价值在特定几天会突然变得很高。

三、智能版补的三件事：快、稳、省

说清楚智能修改电脑版补的是什么，比罗列功能清单更有用。它补的不是"更强的改包能力"，而是三种你每天都在消耗、却很少计入成本的东西：时间、可追溯性、注意力。

1. 快：把重复劳动折叠成一句话

快不是"AI 一秒改完"，而是把一串重复动作折叠进一句话。详情页只有一个输入框：「输入您想修改的需求，我来帮你自动修改」。你不知道该怎么措辞也没关系，话术库有 6 大分类——界面美化、弹窗引流、去除限制、常规修改、混淆去毒、插件添加——共 3000 条，每条 280~425 字，结构固定：一句目标→【要做什么】→【细节要求】→【参数参考】→【范围】→验收→【约束】。点「选择」直接填进输入框，改两个词就能用。这一步替掉的，是老手脑子里那段"我得把话说到能被执行的精度"的翻译工作。

素材交付也被折叠了。附件系统一次能选多个文件，每个文件写一句用途，校验两件事：文件本身能用（存在、不是目录、不是 0 字节、能读），说明不少于 10 个字；最后拼成「序号. 文件路径 —— 用途说明」发给 AI。以前你在聊天记录里翻"那张启动图是哪个版本"的时间，这里变成了一行说明；而且这条说明不进 history.ini，历史记录里留下的始终是需求本身，干净。

出包同样被折叠：回编（apktool b -f）→ 对齐（zipalign -f -p 4）→ 签名（apksigner + 内置签名）→ 校验（apksigner verify --print-certs），四步一条龙，产物是 build 目录下的 unsigned.apk、aligned.apk、signed.apk，全过程写进 pack.log。你以前手打四条命令、记四个参数、还容易漏掉 -p 4，现在是等一个窗口走完。

最后一段是装机：打包后自动 adb 找手机或模拟器、装包、用 am start -W -n 拉起、再用 dumpsys 复核前台应用到底是谁；手机走 scrcpy 投屏，模拟器窗口提到最前。以前"签完名发到微信、手机上下载、点安装、点打开、看一眼"这一串，现在你只需要在旁边看着。这里有个细节值得说：它用 am start 而不是 monkey，因为新版安卓镜像里已经没有 monkey，而且 monkey 失败时退出码还是 0，容易误判成功——这种"不骗自己"的选择，是老手会认可的。

2. 稳：产物与日志都能对上号

稳的第一层是产物有序。三级产物摆在那里：unsigned 是回编结果，aligned 是对齐结果，signed 是签名结果。出了问题是哪一步出的，退回去重做哪一步，心里有数，不用整条链重跑。

第二层是多做一步 verify。前三步只看退出码，"到底签没签上"要 verify 说了算——密钥格式不对，只有这一步会明确报出来。很多人觉得"签名不就是签一下"，实际上签名失败最典型的症状不是报错，而是装不上；多花两秒做 verify，省下的是半小时的怀疑人生。

第三层是可追溯。每次点「立刻修改」，需求原文和修改日期会写进 history.ini，详情页下半部分直接把修改历史列出来，最新在最上面，每条是 #序号 + 时间 + 需求原文，完整显示不截断，右侧有个「选择」能把那条需求填回输入框。老手最讨厌的场景是"上周那版到底怎么改的"——靠记忆猜、靠聊天记录翻、靠产物比对。这里不用回忆，翻一下就有。

第四层是有退路、有边界。每个项目里都有一份 source.apk，改坏了重来；反编译超过 10 分钟会中断并报错，apktool.log 里有输出；等待 AI 的上限是 1 小时，超时会明确告诉你"已停止等待"，而不是永远转圈。边界清楚，比"看起来很强"更让人敢用。

3. 省：无人值守与不抢注意力

省的第一层是省人。勾上循环打包去毒，点「立刻修改」就进入无人值守：AI 每改完一轮→自动打包→按命名规则保存到发布目录→上传云存储→立即或等 N 秒开始下一轮。发布文件名规则可选项很细：前缀留空沿用原名、前缀以 .apk 结尾即固定名（同名覆盖）、前缀+毫秒时间戳、前缀+数字后缀循环（可补零）、还可选转大写；计数器存 loop_task.ini，重启能接着轮。云存储支持阿里云 OSS、亚马逊 S3、腾讯云 COS、华为云 OBS、百度云 BOS、Minio、金山云 KS3、七牛云、FTP，也可以只存本地；上云之前还能先选一个文件真实上传一次，把通路试通。打包窗口和 AI 等候窗口都有「停止任务」，当前轮会收尾，不会留下半成品。

省的第二层是省注意力。AI 工作台吸附在主窗口右侧，两窗高度永远相等，宽度合计固定占屏幕工作区的 3/4（Tw = S×0.75 − Gap − W）；拖走 260ms 自动吸回，拖开超过 80px 有吸附动画；主窗口最小化它跟着最小化。左边写需求、右边看着改，这个姿势比来回切窗口省下的注意力，比省下的时间更值钱——你不需要每三十秒确认一次"它还在动吗"。

四、经典版仍坐镇的三件事

把新工具的好处讲完，得把老工具的不可替代讲透，否则"分工"就是一句漂亮话。经典版至少在三件事上，短期内没有替代品。

第一件是代码级的 smali 修改。电脑版把"改什么"交给一句话，经典版把"改哪里"交给你。要在某个回调里插一句日志、要顺着一个方法的调用链往上追三层、要把一段混淆后的控制流理顺、要在指定界面挂上自己的代码——这些活没有"一句话"可写，也不该用一句话去糊。而且工程全可见：资源、AndroidManifest、smali 都在本地，随时打开检查，你可以验证每一个字节是不是你想的那个样。

第二件是脱壳。经典版的自动脱壳修复，是对各种加固壳做自动化脱壳修复，跟着向导一步步走；加固越复杂成功率越低，工具会尽力而为并如实告知结果。这句"尽力而为、如实告知"在老手耳朵里是加分项——它没有承诺"全部搞定"。研究自家加固测试包时，你要的正是这个诚实的过程记录：哪一步过了、哪一步没过、失败在哪，而不是一句"已完成"。

第三件是多渠道打包。无需源代码，直接拿 APK 做多渠道打包：定时重新打包、随机替换包名与应用名、生成指定渠道的新安装包，一批一批出。这件事的本质是"批量地动包名与应用名"，它需要对包结构的完全掌控，交给向导式的批量模块比自己写脚本更稳。同一套体系里还有导出 Android Studio 工程——智能向导把反编译出的资源文件和配置自动生成完整 AS 工程，项目没混淆的话，导出的 Java 代码少量修改即可正常打包运行；以及小工具集与实时日志排错，手机连电脑就能看日志，改完崩溃当场定位。

这三件事的共同点是颗粒度。电脑版处理的是"一类需求"，经典版处理的是"一处代码"。一个是把八成的重复活收走，一个是让你在剩下两成的地方拥有全部权限。这不是新旧之争，是上游与下游的关系：上游负责批量交付，下游负责深度定制。

五、一张分工表：什么活给谁干

把上面几节压缩成一张表，贴在显示器边上就不会点错工具。判断口诀只有一句：能用一句话说清结果的，交给电脑版；需要你决定"改哪一行"的，留给经典版。

手上的活	交给谁	理由
换图标、改应用名、换启动图、改主题色	智能修改电脑版	结果可一句话描述，验收标准明确
批量文案替换、汉化、多语言版本	智能修改电脑版	范围可写清，话术库有现成结构
每周固定出一次内部包	智能修改电脑版	历史记录可回填，命名规则可固定
多轮微调、整夜跑包	智能修改电脑版	循环打包可无人值守，计数器可续轮
网址、本地网页打成 APK 或 EXE	智能修改电脑版	逐项校验参数，成品还能接着改
在 smali 里定位方法、插代码、改逻辑	修改大师经典版	要的是"改哪一行"的权限，不是结果描述
自家加固包的脱壳与修复研究	修改大师经典版	向导式流程 + 如实告知结果，过程可复盘
几十个渠道包批量出、随机包名	修改大师经典版	多渠道模块专为批量动包名与应用名设计
导出可编译的 Android Studio 工程	修改大师经典版	智能向导生成资源与配置，便于继续开发
出门在外临时改一个包	智能修改安卓版	约 7MB，手机上本地完成反编译到签名

再看一张"活法"对照表，你会发现它们的差别不在能力高低，而在你介入的深度。

维度	智能修改电脑版	修改大师经典版
开工方式	写一句需求，点「立刻修改」	反编译后进工程，逐处手动改
颗粒度	一类需求（"把启动图换掉"）	一处代码（"在这个方法里加判断"）
出包	四步自动，产物三级可回退	改完自己回编、对齐、签名
验证	设备预览自动装包拉起，dumpsys 复核	连着手机看实时日志，当场定位
留痕	history.ini 存需求原文，详情页可回填	工程就在本地，改了什么文件一目了然
适合	日常改包、重复出包、批量交付	深度定制、脱壳研究、渠道批量

六、迁移四步：装、试、比、定

"两手准备"不是把它装上就完事，还得有一套自己的迁移流程。建议四步，一步都别省——尤其第三步，很多人跳过了，结果用了两周还是分不清哪个工具更适合哪类活。

第一步：装——十分钟能搞定的事

电脑版是免安装的，解压即用，安装包约 7.01MB。第一次启动会自动挑盘建工作目录，之后进参数页把路径固定下来。打开工具链体检，aapt、java、apktool、7z、zipalign、apksigner 会逐个报是否就绪与完整路径，缺哪个点「立刻更新」自动补齐。这一步和老手以前手工配环境最大的区别是：它不会假装自己好了，每一项都有明确的红绿灯。装完之后不急着改包，先导入一个自家的小包跑一遍完整流程，看四步打包能不能走通、设备预览能不能拉起。

还有一件小事要提前知道：导入 APK、编辑项目、充值需要先登录，支持微信扫码、QQ 扫码、账号密码。大师币不足时，导入 APK 和编辑项目都不受影响，只有点「立刻修改」和「去打包」时才会提示充值。这个设计对试用的老手是友好的——你可以先把项目建起来、把工程翻一遍，再决定要不要跑 AI。

第二步：试——拿自家练手包，同一条需求做两遍

选一个你熟的自家包（内部工具、自家记账应用、调试版都行），挑一条有明确验收标准的需求——"换图标 + 改应用名 + 换启动图"是最合适的，因为它既需要素材、又需要精确指定范围，正好能试出两边的差别。同一份素材、同一条需求，在经典版手动做一遍，在电脑版一句话做一遍。

做的时候留意三件事：一是需求有没有被完整理解（漏改比改错更常见）；二是产物能不能装（签名、对齐这两步最容易被忽略）；三是出了问题能不能回溯（电脑版看 pack.log 与 history.ini，经典版看工程与实时日志）。这一轮走完，你对"哪边适合什么活"就有体感了，比看十篇介绍都管用。

第三步：比——五个维度，记一张小表

比较不要凭感觉，把结论写在纸上。建议记这五项：

对比项	具体看什么	为什么重要
耗时	从导入到装进手机，实际坐在电脑前的时间	这是迁移唯一硬指标，但要算"人在场"的时间
产物	体积变化、能否覆盖安装、签名是否可验	体积暴涨往往是资源没处理对的信号
装机表现	能否正常拉起、启动瞬间有没有黑屏跳变	启动图这类改动，成败就在头两秒
可回退	改坏了能不能三十秒内退回上一版	source.apk 在不在，决定你敢不敢乱试
留痕	一周后能不能说清这次改了什么	内部交付最容易出事的环节，不是改，是说不清

第四步：定——把结论写成三行规矩

比完就把结论固化成规矩，越短越好，三行足够：日常改包与重复出包走电脑版；smali 级定制、脱壳研究、多渠道批量留经典版；应急改包用手机上的安卓版。贴在显示器边上，或者在团队文档里写清"什么活走哪条线"，新人也能照着办。

这一步的价值在于止住摇摆。没有规矩的时候，人会凭心情选工具：今天想快就用 AI，明天想稳就回手动，结果两套流程都不熟。有了规矩，选择成本归零，两边的熟练度还能各自累积。

七、老手最容易踩的三个新误区

迁移过程中真正会让人翻车的，往往不是功能不会用，而是把旧经验套到新工具上。三个误区，我按踩坑频率排序。

误区一：把 AI 当许愿机。写一句"帮我美化一下界面"，然后期待一个能交付的包——这是最常见的失望来源。AI 不是读心术，它执行的是你的文字。需求里没写范围，它可能动到你不想动的地方；没写验收，你没法判断它做对没有；没写约束，它不会知道"这个页面的文案是法务定过的，一个字都不能改"。正确姿势是用话术库那套五段结构：先一句目标，再【要做什么】【细节要求】【参数参考】【范围】，然后写验收和【约束】。多花两分钟写清楚，省下的是一轮返工。

误区二：把电脑版当经典版的新皮肤。有人装上之后第一件事是找"smali 编辑器在哪"，找不到就判定"这工具不行"。它压根不是那个定位：电脑版处理的是"一类需求"，不提供逐行改代码的界面。它也有另一套改法——EXE、JAR、CLASS 这类项目走 raw 模式，不解析不反编译，原文件直接进项目目录（source.exe 等），AI 直接改并自己打包，成品命名 done.原扩展名，主窗口每 2 秒轮询看到就改名成 done_ok.原扩展名 并提示另存为（默认名与原文件同名）；这类项目没有「去打包」按钮，因为打包这步本来就不归它管。知道边界，才不会拿锤子拧螺丝。

误区三：把"迁移"当"搬迁"。以为用了新工具，就得把经典版的老项目全导过去、老环境全拆掉。其实完全不必：老项目留在老地方，需要 AI 批量处理时，把那份 source.apk 复制出来，在电脑版里新建一个项目就行——新项目有自己的 8 位随机目录、自己的 config.ini，动不到原来的工程。唯一要留心的是签名与包名的连续性：同一个应用要覆盖安装，必须用同一套签名；签名不一样时覆盖安装会报 UPDATE_INCOMPATIBLE，工具会弹窗问你是否卸载重装——这一步会清数据，必须你自己点头。所以迁移时先把签名设置配好：默认签名（安卓测试签名）、自己的 jks 或 keystore、自己的 pem+pk8 证书私钥、随机签名，四种任选，支持 v1/v2/v3/v4（v4 只用于增量安装，默认不勾），设置会存进项目 config.ini，之后每次打包直接用它。

顺带说一句第四个"隐形误区"：以为改完就是改好了。设备预览能把包装上、能拉起、能用 dumpsys 确认前台应用是谁，但它不知道"这个图标是不是你要的那一版"。最后一眼必须人来看。

八、两个实例：搬什么、留什么

抽象的"分工"说一百遍，不如看两个真实的活。以下两个场景都来自自家与内部应用，一个适合搬过去，一个适合留下来。

实例一：每周给内部工具换启动图（该搬的活）

背景：我们内部有个巡检工具，测试组每周五要出一个"当周版"，除了版本号，主要变化是启动图——不同项目组配不同底色，方便一眼分清是谁的内测包。这个活以前固定由一个人做，每次大约一小时。

以前（经典版手动）：反编译后在 res 下按密度找启动图，drawable-xxhdpi、drawable-xhdpi 几个目录逐个替换，还要注意有的包用的是 webp、有的是 9-patch，替换时尺寸和留白都要对；然后改版本号，回编、zipalign、apksigner 签名，装到测试机上点开看启动瞬间。最容易出错的地方有两个：漏了某个密度目录，某个机型上还是旧图；签名用错了 key，测试机覆盖安装失败。一小时里有二十分钟是在做重复劳动，二十分钟在等回编，剩下二十分钟在核对。

现在（电脑版一句话）：把三个尺寸的新启动图拖进附件，每个文件写一句用途（不少于 10 个字，比如"1080 宽启动图，用于替换默认启动页"），需求写成："只替换启动图，其他资源与文案保持不动；保留原包名与应用名；版本号加一；输出到发布目录"。点「立刻修改」，等打包窗口四步走完，设备预览自动装包、拉起，手机投屏就在旁边，看一眼启动瞬间是不是新图。整条流程十分钟出头，其中大部分时间是等回编，人可以去做别的事。

怎么验证：四项核对——启动瞬间是不是新图、有没有黑屏跳变；图标与应用名没被顺带改掉；设置页版本号确实加一；pack.log 里最后一步 verify 通过、没有证书告警。第二周同样的活，进详情页翻修改历史，点那条需求右侧的「选择」把原文填回输入框，只改版本号两个字，再点一次。这就是"折叠"的真实含义：不是 AI 比你手快，是它把"重写一遍需求"这件事也省了。

实例二：自家加固测试包继续用经典版啃（该留的活）

背景：我们手上有一个早期版本自家应用，当年为了验证加固方案做过加固，现在留着当"研究样本"——不是为了改它，是为了搞清楚壳的行为、资源分布与启动链路的差异。这个包没有源代码，只有 APK。

以前怎么做：打开经典版，走自动脱壳修复向导，一步步往下；壳越复杂成功率越低，工具会如实告诉你卡在哪一步。拿到可反编译的工程之后，进 smali 定位方法，顺着调用链往上追，把关键路径记在笔记里；需要验证某个判断时，改一处、回编、签名、装到真机，连着电脑看实时日志，崩溃当场定位。这条路慢，但每一步都可解释——研究要的就是可解释。

现在怎么分工：这条主线一步没动，仍然在经典版里做。电脑版接手的是它外围的两件杂活。第一件，脱壳后得到的中间包要做一次"换名 + 换图标 + 加内测标识"，好让测试组能和我们日常用的正式包区分开——这种活一句话就能出包，没必要占用研究时间。第二件，这个样本包每周要跟着主线版本重出一版做兼容性回归，勾上循环打包，设好命名规则（前缀 + 毫秒时间戳），挂到云存储，跑完自己去发布目录取。

分工的边界很清楚：研究与定制留在经典版，交付与批量交给电脑版。两边的项目目录各自独立，电脑版新建项目时复制一份 source.apk 进去，动不到经典版的工程；经典版继续在自己的目录里改 smali，也不会被电脑版的打包动作影响。这就是"两手准备"最实际的样子——不是谁取代谁，是各自把手上的活干到最省力。

九、电脑不在身边：安卓版是应急位

老手的工作台通常在电脑前，但"包出问题"这件事从不挑场合。客户在群里说"这个内测包名字还是老的"，你在饭桌上；演示前一天发现启动图用错了版本，你在地铁上。这种时候，手机上的智能修改安卓版就是应急位。

它的当前版本是 V50.07.00.00，安装包约 7MB，要求 Android 10 及以上，APK 直接安装。安装包之所以小，是因为运行环境不塞进 APK 里，首次启动按需下载一次运行环境组件，之后不用重复下载。反编译、改包、回编、对齐、签名全在手机上本地完成，不依赖电脑。

用起来的路径和电脑版是同一套语言：写一句中文需求，点「立刻修改」，AI 自动动手；内置 3000 条话术模板，分 6 大分类，手机端点一下自动填进需求框——这意味着你在电脑上练熟的那套需求写法，在手机上不用重学。导入可以是 APK、JAR、APKS、XAPK、APKM，也可以直接从「已安装应用」里选一个。改完直接安装到本机，或者一键分享到微信、QQ；也能另存到「下载」目录，等回到电脑前再处理。

它的边界也要说清楚：屏幕小，逐行读 smali 不舒服；多项目并行、批量出包还是电脑更顺手。所以正确的定位是应急与确认——临时改一个包、装上看一眼效果、把成品转给同事，这些它做得很好。真正的重活，回到电脑前再说。

十、FAQ：老手最常问的八个问题

1. 两个都装，会不会互相干扰？
不会。项目目录、工具链、签名配置都是各自独立的，电脑版用自己 tools 里的 java、apktool、apksigner，经典版用你系统里配的 JDK。唯一会"互相影响"的是资源：两个都开着跑重活时，CPU 和磁盘会抢，建议一件一件来。

2. 电脑版会不会把经典版的项目改坏？
只要不手动把两个工具指向同一个项目目录，就不会。电脑版新建项目时会自己建一个 8 位随机字符串目录，拷一份 source.apk 进去，反编译输出在 apktool 目录里。想拿老项目练手，复制一份 source.apk 出来即可，原工程不动。

3. 经典版还要不要单独装 JDK 1.8？
按官网说明，经典版需要 ASP.Net 4.5 以上与 JDK 1.8 以上，这套环境你以前配好了就留着；电脑版不依赖它，它自己带工具链，体检会逐个报是否就绪与完整路径，缺了点「立刻更新」自动补齐。

4. 老项目需要搬过去吗？
不需要。需要 AI 批量处理时，复制 source.apk 在电脑版新建项目，改完对比产物即可。搬工程反而增加风险——两边的目录结构不一样，硬搬容易把配置搞乱。

5. 签名要重新配吗？
要配一次，但只配一次。电脑版支持默认签名、自己的 jks 或 keystore、自己的 pem+pk8 证书私钥、随机签名，v1/v2/v3/v4 可勾（v4 只用于增量安装，默认不勾），设置存进项目 config.ini，之后每次打包直接用。注意：同一个应用要覆盖安装，必须用同一套签名。

6. 哪些活电脑版干不了？
逐行改 smali、脱壳修复、导出可编译的 AS 工程、几十个渠道包批量出——这些留在经典版。电脑版能做的是"结果可描述"的活：换图、改名、改文案、去弹窗、批量重出包、网址打包，以及 EXE/JAR/CLASS 的 raw 项目。

7. 一句话需求怎么写才不返工？
按话术库的五段结构写：目标一句、【要做什么】、【细节要求】、【参数参考】、【范围】，再加验收和【约束】。三条硬规则：范围写清楚（哪些页面、哪些文件）、验收写具体（装上看哪里）、约束写上"不要动什么"。素材走附件，每个文件一句用途，不少于 10 个字。

8. 出了问题看哪个日志？
四个日志各有分工：pack.log 记打包全过程（四步每条命令与结果），apktool.log 记反编译输出（超时会在这里报），项目目录里的 history.ini 记需求原文与时间，软件级还有 dock.log（窗口吸附过程）与 error.log（未处理异常）。先看 pack.log 定位到哪一步，再看对应那一步的日志。

十一、用户怎么说：那些"两个都用"的人

下面是几位老用户的说法，共同点是：他们没有卸载任何一个。

这些反馈里有个共同的判断标准：不是"哪个更强"，而是"哪个更省"。省下的时间用来做只有人能做的事——判断需求、核对结果、决定边界。

十二、合规提醒：工具再好，也有边界

写到这里必须停一下，把边界说清楚，这比任何功能都重要。

再补一句实在话：迁移这件事，最大的风险从来不是"新工具不好用"，而是"用错了地方"。拿 AI 去干需要判断的活，会失望；拿手动去干重复的活，会累。分清边界，两边都舒服。

所以回到最开始那三个问题：要不要重学一套？不用，需求写法就是中文，话术库还给了结构。要不要把旧工程搬过去？不用，老项目留在老地方，复制一份 source.apk 就能试。手动精修还有没有位置？有，而且是最不可替代的那块位置。

两手准备不是骑墙，是成熟的做法：一套负责广度，一套负责深度，一个负责把重复劳动折叠成一句话，一个负责在关键的那几行代码上拥有全部权限。它们装在同一台电脑上，各自管理各自的项目，互不冲突——这句话本身就是官方给的底气。

如果你还没试过，建议就按那四步来：装、试、比、定。找一个自家的小包，挑一条最简单的需求，两边各做一遍，把结论写成三行规矩。做完这一轮，你就不需要任何人劝你"该换工具了"——你自己会知道什么活该给谁。

最后把这句话再放一次，因为它说的就是这件事的方向：只需说话，就能让应用变成你想要的样子。说话的部分交给它，判断的部分留给你自己。

安卓修改大师智改工坊旗下智能修改电脑版（V1.9.0.0 · Windows 10/11 · 安装包约 7.01MB · 免安装解压即用）的详细介绍与下载入口在 https://www.apkeditor.cn/ai-version.aspx，官网 www.apkeditor.cn。想继续手动精修、研究工程细节，同门的修改大师经典版介绍页在 https://www.apkeditor.cn/manual-version.aspx，可与电脑版同机共存；出门在外要应急，智能修改安卓版（约 7MB · Android 10+）在 https://www.apkeditor.cn/ai-android-version.aspx。