慢工出细活：修改大师经典版适合的三种活

先说清楚本文的位置：安卓修改大师家族里，安卓修改大师智改工坊（https://www.apkeditor.cn/ai-version.aspx）走的是"说一句话、机器去干"的路子；而本文的主角是另一条路——修改大师经典版，一个 2019 年上线至今、靠手动精修吃饭的 Windows 桌面工具。它不是旧版本，也不是过渡品，它服务的是一类明确的人：想要"过程"的人。

有些活真的快不了。你要把一处判断改到精确，快不得；你要把一整批文案翻成另一种语言，快不得；你要从一个加固过的安装包里抠出能继续维护的工程，更快不得。这三种活有一个共同点：你不知道中间会发生什么，所以你必须看得见中间发生了什么。

一、先把话说清楚：快和慢不是对立，是分工

改包这件事，最近几年被"快"重新定义了一遍。你写一句中文需求，机器去反编译、去改、去回编、去对齐、去签名，最后给你一个能装的安装包。这条路对绝大多数日常需求是对的：你想换个图标、想改个应用名、想去个开屏页、想给内测包加个标识，这些需求的目标清楚、边界清楚，快就是优点。

但还有一类需求，目标并不清楚。比如"这个按钮点了之后为什么会跳到那个页面"，你自己也不知道答案，你得先看懂它；比如"这批文案一共多少条、散落在哪些文件里"，你不查一遍根本答不上来；比如"这个包加固过，里面到底还有什么"，你得先把它扒开才知道。这类活的本质不是"改"，是"查清楚再改"。查清楚这一步，机器替不了你的判断。

这就是修改大师经典版存在的理由。它把反编译之后的工程完完整整摊在你面前：资源目录、AndroidManifest、smali 代码，全在本地，随时打开检查。你改哪一行、改的是哪个文件、改完之后那个文件变成了什么样，你全都看得见。所谓慢，是把"不知道中间发生了什么"这个风险，换成"每一步都知道自己在干什么"这个确定性。

补一句版本事实，方便你对号入座：修改大师经典版当前版本 V11.27.00.00，大小 13.74MB，简体中文，更新日期 2026-10-04；官网说明的运行环境是 ASP.Net 4.5 以上加 JDK 1.8 以上。它和智能修改电脑版可以装在同一台电脑上，各自管理各自的项目，互不冲突——这不是二选一，是同一张工作台上放两把不同的工具。

二、慢工的三个前提：看得见、回得去、说得出

"慢"这件事本身不值钱。值钱的是慢的过程中你握着什么。判断一个工具配不配叫"精修工具"，看三条就够了。

第一条是看得见。反编译出来的东西是不是真的落在你硬盘上，你能不能用记事本打开它、用搜索工具搜它、用对比工具比对改前改后。如果中间产物是黑盒，你所有的判断都只能靠猜，再慢也没用。修改大师经典版这一条做得直接：工程文件全可见，资源、AndroidManifest、smali 都在本地目录里。

第二条是回得去。改了三处，第二处改错了，你能不能只撤掉第二处？这要求你的改动是"一处一处"的，而不是"一把梭"。精修的纪律从来都是一次只改一处、改完当场验；改错了就回到上一处，而不是推倒重来。为此最朴素也最有效的做法是：动手前先把原包另存一份，工程目录也留一份没动过的副本，这一步花不了十秒钟，能救你一整个下午。

第三条是说得出。改完之后，你能不能讲清楚"我改了哪个文件的哪一处、为什么这么改、改完发生了什么"。这既是给同事交接用的，也是给三个月后的自己用的。工程可见本身就帮你完成了大半：改动落在文件里，文件就在那里，你打开就能说清楚。

三、第一种活：把一处逻辑改到精确（smali）

先说第一种活：在 smali 层把一处逻辑改到精确。

smali 是什么？简单讲，它是安卓应用编译之后的中间形态。你写的 Java 或 Kotlin 代码，先变成字节码，再被打进 dex 里；反编译之后呈现出来的、可以读可以改的那种文本形式，就是 smali。它不像源码那么好读，但它是精确的：一个判断跳不跳转、一个方法调不调用、一个常量是多少，都在那几行里写着，改与不改，结果是确定的。

什么时候必须动到这一层？当你想要的效果，资源层做不出来的时候。换图标、改文字、换图片，这些都在资源层，动不了逻辑。但如果你想让某个入口对内部包可见、想让某处校验在测试环境下放行、想让某个页面的跳转目标换成你新加的页面——这些都是代码里的事，只能到 smali 这一层。

修改大师经典版在这件事上给的定位很明确：SMALI 代码级修改，功能增强、逻辑调整，甚至在任何界面加上自己的代码——改什么、改哪里，由你决定。这句话的重点在后半句，"由你决定"。工具负责把门打开、把灯打开，动刀的还是你。

实例一：自家内部巡检应用的调试面板，改成默认打开

这是我们内部一个真实的小场景。公司有一套自研的巡检应用，给外勤同事用。里面藏了一个调试面板，触发方式是"在关于页连点版本号七次"——当年这么写是为了防止误触，但现在内部测试包每次都要连点七次，测试同学一天要点几十遍，怨气很大。需求很朴素：内部包把这个面板默认打开。

以前要怎么做：标准的做法当然是回源码改。但这份源码的情况有点尴尬——最初写它的同事早就离职了，工程在老电脑的硬盘里，找回来的版本和线上包对不上号，编译环境也换了三茬。走源码路线意味着要先把三年前的环境搭起来，代价远超改这一行代码。另一个办法是让开发同学专门出一个"调试版"，但那要排期，而测试明天就要用。

现在怎么做：用修改大师经典版把安装包反编译，工程落在本地目录里。先定位这件事在哪：从关于页的界面入手，顺着点击事件找到处理连点逻辑的那个方法，看清楚它判断的是什么——是计数达到七次之后跳转，还是某个开关位。看清了再动：把触发条件这一处改掉，让面板入口直接可见。整个过程只动这一个方法的这一处判断，别的地方一行不动。改完走回编，出一个新的安装包。

改完怎么验证：验证分三层。第一层，装到真机上，进关于页，看面板是不是直接就能进；第二层，把手机连上电脑看实时日志，确认启动过程没有异常堆栈、没有资源找不到的报错；第三层，把连点七次这个老路径再走一遍，确认它没被改坏，只是多了一条捷径。三层都过了，再把这个包发给测试同学。整个过程从反编译到出包，比找回三年前的编译环境要快得多，而比"排期等开发"更是快了一大截——但真正省下的不是时间，是那份"不确定能不能搞定"的焦虑。

四、smali 精修的工作台：工程全可见到底意味着什么

很多人第一次看到反编译出来的工程目录会有点懵：一堆文件夹、一堆看不懂后缀的文件。但熟悉之后你会发现，这个目录结构本身就是信息。

AndroidManifest 是地图。应用有哪些页面、哪个是入口、申请了哪些权限、最低支持到哪个系统版本，都写在这一份文件里。想知道"点这个按钮会去哪"，先看 Manifest 里注册了哪些 Activity；想知道"为什么这个包在低版本安卓上装不了"，看它声明的最低版本。很多问题在这一份文件里就有答案，不用往下挖。

资源目录是界面。布局文件、图片、字符串、颜色、尺寸，都在这里。界面上看到的每一个字、每一张图，都能在资源目录里找到对应。这也是为什么"改文字""换图片""做多语言"这类活，都属于资源层，动起来比代码层安全得多——改错了最坏是界面难看，不会让应用崩溃。

smali 目录是逻辑。代码都在这里，按包名一层层铺开。找东西靠搜索：搜界面上出现的那句话，往往能直接定位到定义它的地方；搜类名、搜方法名、搜某个特征值，都能缩小范围。定位这件事没有捷径，但有方法——先搜字符串，再顺着引用往上看调用它的地方，是最常用的一条路径。

所谓"工程全可见"，落到操作上就是四件事：你能用自己习惯的编辑器打开任何一个文件；你能用搜索工具在整个目录里全文检索；你能把改前和改后的两个目录做对比，看清自己动了什么；你能把任何一个中间产物单独拿出来检查。这四件事加在一起，才构成"看得见"。一个只给你最终产物的工具，再快也做不到这四条。

五、第二种活：把一整批文案做成多语言（汉化）

第二种活是批量文案：翻译、汉化、做多语言版本。

这类活的特点和第一种正好相反。第一种是"点很小、很深"——就改一处，但要挖到底；第二种是"点很多、很浅"——每一处都很简单，但数量吓人。一个稍微像样点的应用，界面文案几百条是常事，加上弹窗提示、错误说明、设置项描述，上千条也不稀奇。这种活靠手工一条一条改，不是做不完，是做不稳：你一定会漏，而且漏的地方你自己发现不了。

修改大师经典版对这件事的说法是"汉化 / 多语言：批量替换界面文字，制作多语言版本"。关键词是批量。它意味着你要处理的对象不是"一条文案"，而是"一整批文案"——先把这批东西整体捞出来，整批处理，再整体放回去。

多语言在安卓工程里的存放是有规矩的：中文通常放在 values 目录下的字符串文件里，英文放在对应的英文目录，其他语言各有各的目录。系统按当前语言去对应目录找，找不到就退回默认目录。理解这一点很重要，因为它直接决定了"漏改"的表现形式：漏掉的条目不会报错，它会静悄悄显示成默认语言的那句话。也就是说，你从日志里看不出漏没漏，只能一屏一屏看界面。

实例二：自家内部工具做中英双语

第二个例子还是自家应用。我们有给海外团队用的一套内部工具，界面原本只有中文。海外同事提了好几次，说看不懂。这件事一直拖着，因为大家直觉上觉得"翻译而已，找个人翻一下就行"，但真动手才发现麻烦：谁也不知道到底有多少条文案，也不知道它们散落在哪几个文件里。

以前要怎么做：最原始的办法是让懂中文的同事对着界面截图，一条一条把中文抄下来，翻成英文，再交给开发一条一条填回去。抄的过程中会漏——因为有些文案只在特定状态下才出现，比如"网络连接失败，请重试"这种错误提示，你不触发一次网络异常，根本看不到它。填回去的过程也会错——填错位置、填串行、漏掉占位符，都是常态。整个流程走一遍，来回确认好几轮，最后上线了还不敢保证翻全了。

现在怎么做：反编译之后，字符串资源都在资源目录里，是结构化的文件，一条一条清清楚楚。先把这份清单整体导出来看一眼——到底多少条、都是什么内容，心里先有个数。这第一步看着不起眼，其实是最有价值的：它把"不知道有多少"变成了"一共这么多条，其中这几类"。然后做批量替换：按类处理，界面上固定的标签一批，操作提示一批，错误说明一批。占位符单独对待，遇到带参数的条目（比如"第 %d 项""还有 %s 条"）先标记出来，翻译时保证参数顺序和数量不变。处理完之后整体回灌进对应的英文目录。

改完怎么验证：三条。第一条，把测试机的系统语言切成英文，从启动页开始一屏一屏走一遍，尤其是那些平时不常出现的页面——错误提示页、空状态页、权限申请弹窗，这些地方最容易漏。第二条，专门看长文案：英文通常比中文长，按钮上的字、列表里的标题，看一看有没有被截断、有没有换行把布局撑破。第三条，专门测带参数的条目：触发一次"第 3 项""还剩 5 条"这类动态文案，确认参数和语序都没乱。三条都过，这个双语版本才算能发出去。

六、批量文案的三条纪律，以及一张做法对照表

批量改文案最容易翻车的地方，不是翻得准不准，是流程对不对。三条纪律，都是踩过坑才形成的。

纪律一：先列清单，再动笔。不要一边翻一边找。先把所有条目捞出来，看清楚总数和结构，再决定怎么分批处理。清单本身就是交付物——它让你能回答"翻了多少、还剩多少"，这话在协作里很值钱。

纪律二：占位符是硬约束。带参数的文案里，%s、%d 这类占位符的数量和含义必须原样保留。有些语言的语序和中文不一样，参数在句子里的位置要跟着挪，但数量不能变。改错了不会报错，会在某个特定场景下显示成一句莫名其妙的话，而且很难复现。

纪律三：验收看界面，不看文件。文件里每一条都翻对了，不代表界面上每一处都对。因为有些文案被多个地方引用，有些文案显示在宽度受限的控件里，还有些文案是拼出来的。唯一可靠的验收方式是真机走一遍界面。

做法	适用规模	主要风险	适合谁
对着截图一条条抄、一条条改	十几条以内	漏条目、串行、占位符丢失	只改两三处的临时需求
导出清单 → 批量替换 → 整体回灌	几十条到上千条	长文案撑破布局、参数顺序错乱	做正式多语言版本
导出工程后在开发环境里维护	长期演进的产品	需要编译环境，前期投入大	有源码、要长期迭代的团队

这张表想说的不是"哪种做法更好"，而是"别用错尺子"。三两条文案你非要导清单，是折腾自己；上千条文案你非要对着截图抄，是折腾自己外加埋雷。修改大师经典版提供的是中间那一格的能力：不需要源码、不需要搭编译环境，直接面对打包好的安装包做批量替换。

七、第三种活：把一个加固包抠出工程（脱壳）

第三种活最硬：把一个加固过的安装包，抠出可以看的工程。

加固是什么？简单说，就是给应用套一层外壳。原本明明白白躺在安装包里的代码，被加密、被抽走、被运行时动态加载回来。这样做有它的正当理由——保护自己的代码不被轻易翻看。但从维护者的角度看，麻烦也明摆着：你自己也看不到了。

什么时候会撞上这堵墙？最常见的场景是"要接手一个包，但源码没了"。公司早期找外包做的应用、合作方交付后没给全工程、同事离职后只留下一个安装包——这些情况里，你手里只有一个加固过的文件，而你要改它、要维护它、要搞清楚它到底做了什么。这时候第一步不是改，是先把壳扒开。

修改大师经典版给的是"自动脱壳修复：对各种加固壳做自动化脱壳修复，跟着向导一步步走"。这句话里有两层意思要说清楚。第一层是"跟着向导一步步走"——它不是一个按钮按完等结果的事，是一段需要你参与的过程。第二层是官方也明确说明了边界：加固越复杂成功率越低，工具会尽力而为并如实告知结果。这句话我很欣赏，因为它诚实。脱壳本来就是一件成功率不保证的事，把话说在前面，比事后找借口强。

实例三：接手一个加固过的内部包，抠出工程继续维护

第三个例子，来自一次真正的"接锅"。公司早年有一款内部统计工具，外包做的，交付时只给了一个安装包。最近业务部门要加两个小功能，问能不能改。开发同学打开一看：这个包加固过，反编译出来的东西基本没法读。

以前要怎么做：两条路，都不好走。第一条，找当年的外包公司要源码——时过境迁，联系人换了，报价也不便宜，而且对方未必还留着。第二条，干脆重写一个——功能不算复杂，但要重新对齐业务逻辑、重新过一遍测试，还得让业务部门重新适应界面，算下来是个小项目。两条路的共同点是：都绕开了"直接改这个包"这个选项，因为大家默认加固包改不了。

现在怎么做：用修改大师经典版的自动脱壳修复，跟着向导一步步走。这一步的体验很关键：向导把过程拆成了你能看懂的几步，每一步在做什么、做得成不成，界面上有交代。你不需要理解底层原理，但你需要在每一步看一眼结果——这一步拿到的是什么、下一步要拿什么，心里有数。走完向导之后，得到一个脱壳之后的安装包，再对它做常规反编译，工程就落在本地了。

改完怎么验证：脱壳这件事的验证分两级，别混在一起。第一级验证"抠没抠出来"：看反编译之后的 smali 能不能读——类名是不是正常的包名结构、方法体是不是有内容、能不能顺着调用链读下去。如果读出来是一堆无意义的东西，说明这一步没成，工具也会如实告诉你。第二级验证"抠出来的能不能用"：把脱壳后的包回编、装到手机上，用实时日志看启动过程——能不能起来、关键页面能不能进、有没有明显的异常堆栈。只有第二级也过了，这个工程才值得往下改。我们的那次结果是好的：工程抠出来了，业务加的两个小功能也顺利加进去了，省掉了一次重写。

八、脱壳之后要什么：导出 Android Studio 工程

抠出工程往往不是终点。你真正想要的，通常是一个能在正式开发环境里继续往下走的东西。

修改大师经典版有一个能力正好接在这一步后面：导出 Android Studio 工程——智能向导把反编译出来的资源文件和配置，自动生成完整的 AS 工程。这句话的重点在"完整"：不是给你一堆散文件让你自己拼，是一个能被开发工具打开的结构。

官方对效果的说明也很实在：项目没混淆的话，导出的 Java 代码少量修改即可正常打包运行。注意这里的前提是"没混淆"。混淆过的代码，类名和方法名都变成了 a、b、c 这种短名，逻辑还在，但读起来费劲——你能看懂它在做什么，但你要花很多时间还原"这个函数其实是干什么的"。这不是工具的错，是混淆本身的目的就是这个。所以这一条的现实预期应该是：没混淆的项目，导出来近乎可用；混淆过的项目，导出来是一份需要你投入耐心的材料。

导出工程之后的用法，常见有三种。第一种是继续维护：工程进了开发环境，后面的功能迭代、缺陷修复都走正规流程，这个包从此不再是黑盒。第二种是对照阅读：你并不打算改它，只是想知道某个功能是怎么实现的，导出来在 IDE 里跳着看，比在一堆文本文件里翻舒服得多。第三种是交接：把工程交给接手的同事，配上你记的笔记，下一个人不用从头踩一遍坑。

这三种用法对应三种不同的投入。第一种投入最大、回报也最大；第二种最轻，一次性的事；第三种看似是给别人做的，其实是在给团队攒资产。无论哪一种，前提都一样：你得先有一个看得见的工程。

九、慢的价值：四道可回退的保险

回到开头那个问题：慢到底值在哪？我的答案是可回退。快的东西一旦走错，往往是"从头再来"；慢的东西走错一步，是"退回一步"。

保险一：原包永远留一份。这是最朴素也最容易被跳过的一步。动手之前，把原始安装包另存到一个不会误删的地方，工程目录也复制一份没动过的副本。有了它，任何改动都不是单向的。这一步的成本是十秒钟，收益是"最坏情况不过是从头再来一遍"。

保险二：一次只改一处，改完当场验。这条纪律的价值在出错时才显现：如果你一次改了五处，出问题时你要在五处里找是哪一处；如果你一次只改一处，出问题时答案就是刚才那一处。"改完当场验"是说，不要攒着一起验——回编、装机、看一眼，确认了再动下一处。听起来慢，实际更快，因为你省掉了排查的时间。

保险三：实时日志当场定位。手机连上电脑，改完之后直接看日志。崩溃了，堆栈就在那里，哪一类、哪一行，一目了然。这一条把"改完发现有问题"和"知道问题在哪"之间的时间压缩到几乎为零。很多老手改包的节奏就是：改一处 → 回编 → 装机 → 看日志 → 下一处，一个循环几分钟，一天能稳稳推进很多处。

保险四：工程全可见，随时打开检查。所有中间产物都是本地文件，你随时可以用任何工具打开它、搜索它、对比它。这意味着你对整个过程拥有最终解释权——不需要信任工具的判断，你可以自己看。

慢工出细活这句话，重点其实在"细"不在"慢"。慢只是手段：把改动切到足够小、把验证推到足够近，出错时就能退得足够轻。所谓掌控感，就是这个。

十、另一半节奏：手机和平板上的那把工具

讲完慢工，得说说另一半节奏，因为现实中这两种节奏是同一批人在用。

智能修改安卓版是装在手机上的那一把：当前版本 V50.07.00.00，安装包约 7MB，Android 10 及以上，APK 直接安装。它的卖点不是"把经典版搬到手机上"，而是补上了经典版覆盖不到的场景——你不在电脑前的时候。

它到底有多"不依赖电脑"？反编译、改包、回编、对齐、签名，全部在手机上本地完成。也就是说，你在地铁上、在客户现场、在会议室里等人，掏出手机就能把一个包改完，直接装到本机上看效果。改完之后，可以一键分享到微信或 QQ 把成品发给同事，也可以另存到下载目录。这个闭环里没有任何一步需要你回到工位。

用法上它延续了家族的路子：写一句中文需求，点一下就交给 AI 去改；内置的话术模板点一下自动填进需求框，不用从零措辞。导入方式也给得宽——APK、JAR、APKS、XAPK、APKM 都能导入，还可以直接从"已安装应用"里挑一个正在用的应用来改，连导出的步骤都省了。打包是全自动的：回编、对齐、签名、校验一路走完，直接产出能装的安装包。签名也支持用自己的 JKS、keystore 或证书私钥组合。

两把工具怎么配合？我见过最顺的一种用法是"手机先看效果，电脑再做精修"：在外面用安卓版把改动先做一遍，装到手机上看一眼，确认这个方向是对的、这个效果是要的；回到工位上，再用经典版把同样的改动做到精确——因为你已经知道要什么了，精修时的每一次判断都有依据。反过来也成立：在电脑上把逻辑改到位、把细节抠清楚，出包之后发到手机上，用安卓版在真机环境里看实际表现。

平板在这件事上还有一个额外好处：屏幕大了，需求原文和修改记录能同屏对照，改前改后一眼比对；图标这类细节也不容易看走眼。对经常要对着界面挑毛病的人来说，这个差别是实打实的。

十一、三种活一张表：该慢的时候慢，该快的时候快

把三种活摆到一起看，你会发现它们的"慢点"各不相同——第一种慢在定位，第二种慢在数量，第三种慢在能不能成。认清自己手上这份活慢在哪，比埋头苦干重要。

活	慢在哪	最小改动单位	验收信号
一处逻辑改到精确（smali）	慢在定位：要先读懂调用链才知道改哪	一处判断、一处跳转、一个常量	真机能跑通、实时日志无异常、老路径没被改坏
一整批文案做成多语言（汉化）	慢在数量：先看清总数再分批处理	一类文案（标签 / 提示 / 错误说明）	切系统语言逐屏走查、长文案不截断、参数语序不变
加固包抠出工程（脱壳）	慢在成败：跟着向导走，结果如实告知	一次完整的脱壳修复过程	smali 读得通、能回编成能装的包、启动无异常

还有一张表更有用：什么时候不该慢。判断标准很简单——如果需求的目标和边界你都能一句话说清，就不该慢。换个图标、改个应用名、去个开屏页、给内测包加个标识、一批渠道包换个包名，这些都是"我知道要什么"的活，交给一句话改包的那条路更合适，省下来的时间拿去干别的。

你的状态	推荐的路	理由
知道要什么，只要结果	一句话改包（电脑端 / 手机端）	目标清楚，自动打包四步加校验，快就是优点
还不知道里面是什么，要先看清	修改大师经典版手动精修	工程全可见，改哪一处自己说了算，出错能退一步
不在电脑前，但想马上看到效果	智能修改安卓版	全流程在手机本地完成，改完直接装、直接分享
要长期维护下去	经典版导出工程 → 回到开发环境	一次投入，后面所有迭代都走正规流程

十二、两组技巧：慢工怎么提速，改完怎么交接

慢工不等于磨洋工。能省的地方要省，不该省的地方一秒都不能省。

十三、常见问题：关于经典版，大家最常问的八件事

1. 我不会写代码，能用修改大师经典版吗？

能用一部分，也要承认另一部分用不了。换图标、改应用名、替换界面文字和图片、做多语言版本，这些都属于资源层，不需要写代码，跟着向导走就能做。但 smali 代码级修改确实需要你读得懂基本的逻辑结构，至少要能看懂一个判断、一次跳转。建议从资源层入手，先熟悉工程目录长什么样，再慢慢往下碰代码层。

2. 它和智能修改电脑版是不是重复了？要不要二选一？

不重复，也不用二选一。两者可以装在同一台电脑上，各自管理各自的项目，互不冲突。分工很清楚：目标清楚的需求走一句话改包，要深挖、要精确的场景走手动精修。很多人的实际用法是"AI 打个底，手动收个尾"，或者反过来——先手动看清结构，再让 AI 批量去做。

3. 电脑需要什么环境？装起来麻烦吗？

官网说明的运行要求是 ASP.Net 4.5 以上加 JDK 1.8 以上，Windows 桌面端。安装包 13.74MB，简体中文界面，当前版本 V11.27.00.00，更新日期 2026-10-04。这两项运行环境是 Windows 上很常见的组件，大部分开发用的机器本来就具备；装之前先确认一下版本，省得装完发现跑不起来。

4. 脱壳一定成功吗？成功率大概怎么样？

不保证。官方的说法是"加固越复杂成功率越低，工具会尽力而为并如实告知结果"，这个态度本身值得信任。实际操作上，简单的壳通常走得顺，复杂的壳可能要试几次，也可能最后拿不到可用的工程。建议把脱壳当成"试试看"而不是"一定能"，先花十分钟试一次，成了就赚了，不成也不至于耽误后面的计划。

5. 导出的 Android Studio 工程能直接编译吗？

要看原项目混没混淆。官方的说法是"项目没混淆的话，导出的 Java 代码少量修改即可正常打包运行"——注意"少量修改"这四个字，说明它不是开箱即用，但也不是从零开始。混淆过的项目导出来逻辑还在，但类名方法名都成了短名，读起来费劲，需要你投入耐心去还原含义。

6. 改坏了怎么办？有没有后悔药？

有，但前提是你自己留了。最有效的办法是动手前把原包另存一份、工程目录复制一份未改动的副本，这样任何一步都能退回去。其次是纪律：一次只改一处，改完当场验，出问题就知道是刚才那一处。再加上实时日志——手机连电脑看日志，崩溃当场能定位到哪一类哪一行，比事后猜强得多。

7. 除了改包，它还能干点别的吗？

能干的不少。多渠道打包是另一个常用能力：不需要源代码，直接拿安装包做多渠道打包，定时重新打包、随机替换包名与应用名、生成指定渠道的新包，一批一批出。小工具集则覆盖了日常琐事：查看安装包信息；手机连上电脑之后看手机信息、实时日志，安装和管理应用，管理手机文件；还能直接定制修改手机里已经装好的应用程序。另外还有在线封装 APP 的能力，只需一个网站链接就能在线生成安卓应用。

8. 不用花钱能用吗？

能用。经典版是非 VIP 免费用，全部功能都能用；VIP 的作用是去除升级提示与广告。这一点对想先试试的人很友好——你不需要先做决定才能开始，装上去用两天，看看它适不适合你手上的活，再决定要不要进一步。具体权益以官网介绍页的说明为准。

十四、用户怎么说：八条真实反馈

把大家的反馈归纳一下，出现得最多的几个词是：工程可见、改完能验、出错能退、不用源码也能上手、非 VIP 就能用全套。这些词指向的是同一件事——掌控感。它不承诺你改得更快，它承诺你知道自己在改什么。

十五、合规提醒：能力的边界在哪里

把边界说清楚，其实是在保护使用者。拿自己的应用练手，学到的东西是真本事；拿别人的应用动手，学到的东西迟早要还回去。

十六、写在最后：把快慢都握在手里

回头看这三种活——把一处逻辑改到精确、把一整批文案做成多语言、把一个加固包抠出工程——它们慢的原因各不相同，但对工具的要求是一样的：每一步都看得见，每一处都能回退。

修改大师经典版给的就是这个。工程文件全可见，资源、AndroidManifest、smali 都在本地；改什么、改哪里由你决定；改完有实时日志当场定位；还有多渠道打包、在线封装 APP、小工具集这些顺手的能力。它是 2019 年上线至今的老工具，非 VIP 也能用全套功能，VIP 只是去掉升级提示与广告。

而当你不在电脑前的时候，另一半节奏由手机接上：智能修改安卓版把反编译、改包、回编、对齐、签名全放在手机本地完成，一句话说清需求，改完直接装、直接分享。