一台电脑一部手机：安卓修改大师三版本组合改包流实录

周四晚上九点，我把这一周的东西摊在桌上复盘：一台笔记本、一部手机、一张写着六个包名的便签。便签上的六个包，没有一个是在同一个工具里从头改到尾的——有的在电脑上批量出，有的在客户会议室用手机现场改，还有一个加固过的旧包，绕了一圈回到工位，脱完壳才动的手。

这就是我想写这篇实录的原因。市面上讲改包的文章，大多在回答"该选哪个版本"；但真实的一周里，问题从来不是选一个用到底，而是这一棒该交给谁。三个版本各有各的物理形态：一个是要坐着用的桌面车间，一个是装在口袋里的随身工具箱，一个是把工程全摊开的精密台。它们不是替代关系，是接力关系。

先报家门。这篇文章讲的是安卓修改大师智改工坊：智能修改电脑版（Windows 桌面端，V1.9.0.0）、智能修改安卓版（手机 / 平板端，V50.07.00.00）、修改大师经典版（Windows 手动精修版，V11.27.00.00）。介绍与下载入口都在 https://www.apkeditor.cn/ai-version.aspx，官网 www.apkeditor.cn。三个版本能同时待在你的设备上：电脑版与经典版装在同一台电脑，各管各的项目、互不冲突；安卓版的项目在手机里，谁也不用给谁让位。

一、一个需求在三个版本之间走了一圈

先说这一周真实压过来的三个需求。第一个：自家记账应用"小账本"要出六个渠道的活动包，同一套改动（换图标、换开屏图、改两句活动文案），但六个包各有各的渠道标识，命名要统一，每一份都得装上去看一眼。第二个：内部工具"巡检助手"的内测版要改个名字、换个图标，客户在周二下午的会上就要看到实物。第三个：两年前一个自家旧包，当时交给第三方做过加固，现在要改启动图和一句文案，还得留一份能给人看的工程存档。

三个需求，三种形状。第一个是"量"的问题：改一次，出六份，命名不能乱，验证不能漏。第二个是"时"的问题：需求发生在会议室里，等回到工位，那个"当场看一眼"的机会已经没了。第三个是"深"的问题：壳还在那儿，不脱开就什么都看不见，改哪一行都得先有得看。

如果一个版本硬扛这三个，会怎样？只靠电脑版，第三个需求能做（它能用 jadx 把包导出成 Android Studio 工程，再由 AI 修到 Gradle 可编译），但"脱壳"这一步它不做，壳打不开，后面全是空谈；只靠手机版，第一个需求就难受，六个包逐份核对、命名、比对截图，小屏幕上全是瓶颈；只靠经典版，第二个需求虽然也能做，可一个人在外面，工位上的那台机器够不着。

接力不是打比方。三次交接，每次交出去的东西都是同一套：一个成品 APK、一份需求原文、一条验证记录。这三样东西在三个版本之间都认得，因为三个版本产出的都是能装的 APK，读的都是同一类包体结构。这也是这套组合成立的技术前提——如果三个工具各自产出各自格式的中间件，接力这件事根本无从谈起。

二、为什么不用一个版本打天下

先纠正一个常见的误解：三个版本并存，不是因为每个版本都有短板所以要互相补台，而是因为改包这件事本身就包含三种完全不同的工作量。把三种工作量压到一个工具上，压不下去的部分就会变成人的消耗。

第一种是"量"。批量出包的难处不在改，在重复中的一致性：六个包要改得一模一样，命名要排得整齐，每一份都要装上去确认没崩。这种活要键盘、大屏、多窗口、能挂机的循环，以及一份能翻回去的日志。第二种是"时"。需求从别人嘴里出来的那一刻价值最高，过了半天再交已经打折，这种活要的是开机门槛足够低——低到"人在、手机有电"就能开工。第三种是"深"。加固包、混淆过的代码、要逐行看的逻辑，要的是可见性：资源、Manifest、smali 全摊在眼前。

用电脑版去扛"时"，失败的方式很具体。人在客户会议室，需求当场提出来，你只能答"回去改"。有人会想：远程连回工位那台电脑不就行了？先不说网络和唤醒，单是手机小屏上看那套双窗口界面、拖动、点选，效率就打了个对折；更麻烦的是，对方要的是"现在看到效果"，而远程桌面给不了"递过去一台手机"的那种确定感。

用手机版去扛"量"，失败的方式也很具体。六个包不是六个文件那么简单：每个包要改三处、要按渠道命名、要装到对应环境里确认。手机屏幕上一屏只能看一个项目，来回切、对着截图比、手动改名，眼睛和手指都是瓶颈。批量这件事的本质是"守夜"——让它自己跑，人只在关键节点看一眼。守夜的活，桌面端更合适。

用经典版去扛"日常"，则是另一种浪费。经典版是一张精密台：资源、AndroidManifest、smali 全部摊开在本地，改什么、改哪里由你决定。这种"全都看得见"的代价，是每一步都需要你自己判断。拿它去改一句弹窗文案，就像拿卡尺去量一块布——能量，但没必要。

工作量的形状	它真正难在哪	这一棒交给谁
量：一批包、同一套改动	重复中的一致性、命名、逐份验证	智能修改电脑版（循环打包 + 设备预览）
时：需求突然发生	开工门槛、当场验证、当场交付	智能修改安卓版（一句话 + 装机 + 分享）
深：壳、混淆、逐行逻辑	可见性、可控性、可回溯	修改大师经典版（脱壳 + smali + 导工程）

组合能成立，还有三个很朴素的前提。第一，产物同构：三个版本交出来的都是标准 APK，谁都能接手。第二，项目各自管理：电脑版每个项目是一个 8 位随机字符串目录，里面有 config.ini、source.apk 和 apktool 反编译输出；经典版有自己的工程；安卓版的项目在应用内部，还能在应用里浏览与手工编辑项目文件。第三，可以同机共存：电脑版和经典版装在同一台 Windows 上，各开各的窗口，不会因为装了另一个就认不出自己的活儿。

三、周一上午：电脑版把一批包推出去

周一早上九点十分到工位，第一个动作不是打开包，是打开工具。电脑版启动前会做一次工具链体检：aapt、java、apktool、7z、zipalign、apksigner 逐个报"是否就绪"和完整路径。这一步看起来像形式主义，实际上是把"改到一半发现缺工具"这种事故提前到了零成本的位置。哪一项没就绪，点「立刻更新」，它会自动下载并解压工具包；工具放在工作目录的 tools 子目录里，程序会递归搜索，不依赖系统环境变量。

工作目录也是自动的：启动时按 D→E→F→G→C 挑盘，取第一个可读写且剩余不少于 1GB 的盘，拼成 <盘符>:\AiApkEditor，下分 tools 与 Project。九个包（六个渠道活动包 + 三个待改的备选）一起拖进窗口，解析交给 aapt：图标、应用名、包名、版本号、创建日期一次读出来。图标取包内原图、按最高密度挑选——aapt 有时报的 65534 是"任意密度"的哨兵值，不是真有个超高清图标。解析与反编译在后台线程跑，界面不卡，12MB 的包约 3 秒解完；超过 10 分钟会中断并把原因写进 apktool.log。

写需求这一步，我用的是"话术打底 + 自己改字"。话术库六大分类（界面美化、弹窗引流、去除限制、常规修改、混淆去毒、插件添加），共 3000 条，每条 280 到 425 字，结构固定：一句目标，然后是【要做什么】【细节要求】【参数参考】【范围】验收【约束】。点「选择」直接填进输入框，我把文案换成这次活动那两句，再补一句"六个渠道包只改这三处，其余不动"。话术库是明文文件，团队可以自己加常用模板，改完点刷新重新读。

附件是这次的关键。六个包的图标三种尺寸、渠道文案在一张表里，我把它们一起挂上去，每个文件后面写一句用途。附件系统校验两件事：文件本身能不能用（存在、不是目录、不是 0 字节、能读），说明写没写清（不少于 10 个字）。所有附件会拼成"序号. 文件路径 —— 用途说明"发给 AI。别小看这 10 个字，它逼你在发出去之前想清楚"这个文件是干嘛的"，返工率会明显下降。

点「立刻修改」，需求原文和修改日期一起写进项目的 history.ini，需求被送进右侧的 AI 工作台执行。AI 改完会在项目目录留一个 ai_done.flag 标志文件，主窗口每 2 秒轮询一次，读到就删掉并弹出打包窗口；等待上限是 1 小时，超时会明确告诉你"已停止等待"，而不是让你盯着一个不动的界面猜。这个设计很像快递的到件通知：你不用一直刷物流，它会来敲你。

打包是四步：回编（apktool b -f）→ 对齐（zipalign -f -p 4）→ 签名（apksigner + 内置签名）→ 校验（apksigner verify --print-certs）。产物落在 build 目录的 unsigned、aligned、signed 三个 APK，全过程写进 pack.log。第四步为什么不能省？前三步只看退出码，"到底签没签上"要 verify 说了算——密钥格式不对、证书与私钥不配套这类问题，前面都"跑完了"，只有这一步会明确报出来。批量出包最怕"看起来成功"，这一步就是那个不肯给你面子的环节。

签名我提前配好了：默认签名、自己的 jks / keystore、pem + pk8 证书私钥、随机签名四种可选，v1 / v2 / v3 / v4 都能勾（v4 主要用于增量安装，默认不勾）。配置存进项目 config.ini，之后每次打包直接用，不用一遍遍选文件。这一步在批量场景里是硬要求——六个包如果签名不一致，装到同一台机器上就会互相打架。

打包完自动进设备预览：adb 找手机或模拟器 → 装包 → am start -W -n 拉起 → 再 dumpsys 复核前台到底是不是它。特意不用 monkey：新版安卓镜像里已经没有它，而且它失败时退出码还是 0，最容易给出"装成功了"的假象。组件名三档查找：项目 config.ini 的 LaunchableActivity → 问设备 resolve-activity → 最后才退回 monkey 兜底。手机走 scrcpy 投屏，模拟器窗口自动提到最前。

六个包如果一个个手动点，一上午就没了。这次我勾了循环打包：AI 每改完一轮就自动打包、按规则命名存进发布目录、上传云存储，再开始下一轮。命名规则四种：沿用原名、固定名同名覆盖、毫秒时间戳、数字后缀循环（可补零），还能转大写。计数器存在 loop_task.ini，重启能接着轮；云通道覆盖阿里云 OSS、S3、腾讯云 COS、华为云 OBS、百度云 BOS、Minio、金山云 KS3、七牛云、FTP，也能只存本地。两个窗口都有「停止任务」，当前轮收尾，不留半个包。

四、周二下午：手机上接住那个突然来的需求

周二下午两点二十，客户会议室。会开到一半，对方指着投影说："这个内部工具的名字能不能改成'巡检助手 · 内测'，图标也换一下，我们下午要发给试点同事。"这句话的重量我太熟悉了——两年前听到它，我只能在笔记本上记一笔，然后回一句"明天给您"。这一次我掏出手机，说："给我十分钟。"

手机上的第一步是导入。安卓版支持 APK / JAR / APKS / XAPK / APKM，也支持直接从「已安装应用」里挑一个——这一条在会议室里太好用了：这个内部工具就装在我手机上，点一下就是它，不用找文件、不用数据线、不用让别人发一遍。项目建好，解析完成，图标、应用名、包名、版本号都在，和电脑上是同一套真实信息。

第二步是写需求。安装包只有约 7MB，因为运行环境没有塞进安装包——首次启动时按需下载一次运行环境组件，之后不用重复下载。我这个包是上周在 Wi-Fi 下完成首次启动的，所以今天打开就能直接干活。需求框里我写："把应用名改成'巡检助手 · 内测'，桌面图标换成附件里这张深蓝色的；启动页中间的 logo 一起换掉，其他界面和逻辑都不要动；改完我要装到这台手机上，看桌面名字、图标和启动页三处。"

写不出这么完整也没关系，点开内置的 3000 条话术模板，六大分类里挑一条，点一下自动填进需求框，再把具体文字换掉。手机屏幕小，打字慢，这个"打底稿"的机制能省掉一半的输入时间。点「立刻修改」，AI 开始动手；接下来回编、zipalign 对齐、v1 / v2 / v3 签名、校验，四步全在手机上本地跑，不依赖电脑，也不用把包传来传去。

两点三十八分，包出来了。直接安装到本机，桌面上的名字变成了"巡检助手 · 内测"，图标是那个深蓝色，点开，启动页的 logo 也换了。我把手机递给对面的负责人，他点开看了两眼，抬头说："就这个。"从需求提出到递过去，十八分钟。第三步是交付：一键分享到微信，试点群的同事当场就收到了；也可以另存到「下载」，走别的渠道发。

这个包的需求原文自动记进了项目 history，第几条、什么时间、原话是什么，都在。晚上回酒店我翻了一眼，把原文复制到工作群，配一句"今天下午那版，需求原文如上"。客户第二天问"到底改的哪几处"，我不用回忆，直接把记录甩过去。手机改包最容易被低估的价值，是它把需求发生的那一刻和交付的那一刻压在了同一个地点。

五、周三：经典版啃硬骨头

周三上午，那个加固包摆到了桌上。这是两年前一个自家旧版应用，当时为了防反编译交给第三方加固过，现在要改启动图和一句文案，还要留一份能给合作方看的工程存档。加固包的特点是：直接反编译出来是一堆看不懂的东西，资源可能被藏起来，代码被抽走或加密，你用常规方式打开，看到的不是原来的工程。

经典版里这一步叫自动脱壳修复：对各种加固壳做自动化脱壳修复，跟着向导一步步走。这里必须说一句实话——加固越复杂，成功率越低；工具会尽力而为，也会如实告诉你结果，不会给你一个"看起来成功"的假象。这个态度我很认：脱壳这件事本来就没有百分之百，能明确告诉你"这个壳没搞定"，比让你对着一个坏工程改半天要值钱得多。

壳脱开之后，经典版的价值才真正显出来：工程文件全可见。资源、AndroidManifest、smali 都在本地目录里，随时可以打开检查。想换启动图，就去 res 里找那张图，看清它有几个密度版本、分别放在哪个 drawable 目录；想改文案，就在 strings 里搜，看看是被引用了还是写死在布局里。这不是"高级功能"，这是"看得见"本身——很多改包的坑，都是因为看不见才踩的。

这次我动了两处。第一处是启动图，换了三张不同密度的资源，命名对齐原文件，不新增不删除，避免打包时资源表对不上。第二处是一句文案，它不在 strings 里，而是硬编码在一个界面的 smali 里，用 SMALI 代码级修改把那个常量换掉。改 smali 的好处是：改了什么、改在哪里，都是你自己下的手，出了问题能一行一行看回去。

改完不敢直接交，先连手机看日志。经典版的小工具集里，手机连上电脑就能看手机信息、实时日志、安装和管理应用、管理手机文件。装上去，点开，走一遍关键界面，日志里没有异常堆栈，才算过。这一步在深度修改里几乎是必须的：smali 改错一个寄存器、资源换错一个密度，表现可能只是某个界面白屏，光看截图看不出来，日志会直接告诉你崩在哪。

最后是导出工程。经典版的智能向导能把反编译出来的资源文件和配置自动生成一个完整的 Android Studio 工程；如果这个项目没有被混淆，导出的 Java 代码少量修改就能正常打包运行。这次的旧包混淆得不重，导出的工程结构清楚，我把它和改好的 APK 一起归档——APK 是给合作方验的实物，工程是给后面接手的人看的底稿。

六、接力表：什么场景交给谁

把这一周的场景摊开，会发现"交给谁"其实有很稳定的规律。下面这张表不是选型表（选型是"我只有一个人、一种习惯，该装哪个"），而是接力表——假设三个版本都在手边，这一棒该递给谁。区别在于：选型表帮你做减法，接力表帮你做分工。

场景	这一棒交给	为什么是它	交货时带什么
同一套改动出五到十个包	智能修改电脑版	循环打包 + 命名规则 + 云通道，能挂机	发布目录 + pack.log
会议室、展会、路上突然提需求	智能修改安卓版	开机门槛最低，改完当场装、当场分享	成品 APK + history 原文
对方给的是加固包	修改大师经典版	脱壳修复向导，壳不开什么都看不见	脱壳结果说明 + 工程目录
要逐行看逻辑、改 smali、加日志	修改大师经典版	工程全可见，改哪儿自己说了算	改动清单 + 日志截图
只改一句文案、换个图，当场要看	智能修改安卓版	一句话就够，四步打包全在本地	装机截图 + 版本号
批量装机验证、模拟器多开比对	智能修改电脑版	adb 装、am start 拉起、dumpsys 复核	每台设备的验证记录
渠道包要随机包名、定时重打	修改大师经典版	无源码多渠道，一批一批出	渠道清单 + 包名对照
网址变成 APP	电脑版或安卓版都行	两边都有网址打包，参数都能配	配置清单 + 成品

七、交接清单：源包、需求、产物、验证怎么传

接力最怕的不是技术问题，是信息在换手的地方掉了。同一句话，从会议室到工位，从手机到电脑，经过三个人的嘴，往往就变了味。我的做法是：任何一次换手，都按四条线交接，一条都不能省。

第一条线：源包。永远用同一份原始包作为起点。电脑版建项目时会自动拷一份 source.apk 进项目目录，这就是那一轮的唯一源；手机导入时同样是一份原始包进项目。千万不要出现"电脑上改过一版、手机上又拿另一个来源的包改一版"的情况——两个源包的版本号可能差一个，签名可能不一样，最后两个产物放在一起，谁也说不清哪个是对的。命名上我统一成 应用名-版本号-渠道-src.apk，看到 src 就知道这是源，不是成品。

第二条线：需求原文。原话照抄，不转述。电脑版把需求原文和修改日期写进 history.ini，详情页下半部分直接列出来，最新在最上，每条带 #序号和时间，原文完整显示不截断，右侧「选择」能把那条填回输入框。安卓版每次需求也记进项目 history。所以交接时我不是"回忆当时怎么说的"，而是把那行原文复制出来原样发过去——原话里往往藏着最关键的半句，"别动启动页"一转述就没了。

第三条线：产物。成品 APK 的命名要能自己说话。我用 应用名-版本号-渠道-日期-轮次.apk，比如"小账本-2.4.1-huawei-1027-r2.apk"。产品里也提供了几种自动命名规则（固定名、毫秒时间戳、数字后缀循环、转大写），本质都是让文件名承担一部分台账功能。最忌"最终版""最终版2"——一周之后这几个名字对你没有任何区别。交接时再带上 pack.log 和一张改前改后的对照截图。

第四条线：验证结果。不要只说"我试过了，没问题"。要说清四件事：装在哪台设备上（品牌型号、系统版本）、启动是否正常（有没有闪退、白屏）、改了哪几处（逐条对应需求）、没动哪几处（这是"范围"的兑现）。批量场景下，这一条还要按包记录——六个包六条记录，不能写"六个都正常"了事，因为"正常"的标准不一样：有的包重点是图标，有的包重点是开屏图。

• 源包是不是那份唯一的源，文件名里有没有 src 和版本号？
• 需求原文是不是原话，范围和"不要动"的那半句还在不在？
• 产物带没带 pack.log，验证记录是不是一包一条？

交接物	从哪里拿	怎么传	必须一起带
源包	项目目录里的 source.apk	直接传文件，不要传截图	版本号、包名、签名来源
需求原文	history.ini / 项目 history	复制原文，不改一个字	时间、序号、范围与验收
产物	build 目录 / 发布目录	按统一命名，一个包一个文件	pack.log、改前改后截图
验证结果	预览记录、实机截图	一条记录对应一个包	设备型号、系统版本、未动项

举个反例。上个月有人把一个改好的包装到群里，只说了句"改完了"。两天后对方问"上次那版到底改的哪几处"，翻了半天，最后只能重新改一版。做对了是什么样：源包文件名带版本号和 src，需求原文贴在消息里，产物命名带日期和轮次，两张截图一左一右，最后一句"只改了启动图和那句文案，装在小米 13 / Android 14 上验证过"。

八、组合使用的三条纪律

三个版本一起用，最怕的是"越用越乱"。乱不是乱在技术上，是乱在谁改的、改到哪一版、哪个是最终产物这三件事说不清。这一周我把纪律压到了三条，每一条都用具体动作来落地。

• 纪律一：版本别混用产物。接力传的是成品 APK，不是半成品工程。经典版脱壳改好后打出来的 APK，可以拿到电脑版新建项目继续用 AI 改；但不能反过来塞回电脑版原来的项目目录去覆盖 apktool 输出——那不是接力，是把上一棒的现场砸了。手机上改过的包要回电脑，也走"导入 APK 新建项目"，而不是搬工程目录。
• 纪律二：命名统一。三个版本的默认命名各不相同：电脑版有四种自动规则，手机上是改完另存或分享，经典版的多渠道打包还会按渠道生成。不人为统一，一周后文件夹里就会出现"小账本_new.apk""小账本 2.4.1(1).apk"。我的规则全局一套：应用名-版本号-渠道-日期-轮次，任何版本出包都按这个改名再归档。
• 纪律三：每步留痕。电脑版有 history.ini（需求原文 + 修改日期）、pack.log（打包四步全过程）、apktool.log（反编译输出）；安卓版把每次需求记进项目 history；经典版留下的是工程目录本身和日志。留痕的关键不是"有没有"，而是换手的时候有没有跟着走——每次交接都把记录一起发出去，哪怕对方只看一眼。

三条纪律之外，还有一条隐形的：签名要统一。三个版本都支持自定义签名（电脑版可存进项目 config.ini，安卓版支持 JKS / keystore 或 PEM / PK8 加证书），团队里最好只用一个 jks，密码由一个人管。签名不一致的后果不是"打包失败"，而是"装不上"——UPDATE_INCOMPATIBLE，系统只会告诉你签名不同，解决办法是卸载重装，而卸载会清数据。这一条踩过一次就够记一辈子。

组合使用的本质，是把"一个人干完全程"改成"每一段交给最合适的那个"，然后用三条纪律保证换手不丢东西。工具越多越要讲纪律，否则组合就是混乱的另一种说法。

九、三个实例：一周里的三次接力

下面三个例子都来自自家或已获授权的应用，按这一周的时间顺序排。每个例子写三段：以前怎么做、这次怎么做、改完怎么验证。

实例一（周一 · 电脑版）：自家记账应用出六个渠道活动包

以前：六个渠道包，我是在经典版里一个个改的。改图标、改开屏图、改两句活动文案，改完打包，再手动改名，再一个个装到模拟器里看。六个包，一整天。最难受的不是慢，是改到第四个的时候，已经记不清第一个包换的是哪张图——只能翻回去重新比一遍，比完再确认一遍。

这次：电脑版里九个包一起导入，六个要改的建项目，三张图标和一张渠道文案表作为附件挂上去，每个附件写清用途。需求用话术打底，补上"只改这三处、其余不动、六个包按渠道命名"。签名提前配好同一个 jks，命名规则选"前缀 + 数字后缀循环（补零）"，勾上循环打包。然后我去开站会，回来时六轮已经跑完，发布目录里躺着六个包，名字是 小账本-2.4.1-01 到 -06。

验证：六个包分两批装进两个模拟器，每个包都走一遍"装 → am start -W 拉起 → dumpsys 复核前台"，再点开活动页看那两句文案。六条验证记录写在一张表里，每条带设备、系统版本、三处改动的确认结果。有一个包第一次装报 VERSION_DOWNGRADE，工具自动加了 -d 允许降级，重装通过——如果没有这条记录，我事后根本想不起来哪个包降过级。

实例二（周二 · 安卓版）：内部工具改名换图标，会议室里十八分钟

以前：这种需求的标准答案是"明天给您"。回工位、开电脑、导包、改、打包、装机、发微信，最快也要两个小时，而且客户当场看不到。有一次对方等不及，直接拿旧版发给试点同事，结果试点群里一片"名字还是老的"的反馈，后面又解释了半天。

这次：手机上从「已安装应用」里直接选那个内部工具，建项目；需求写清三处（应用名、桌面图标、启动页 logo）和一句"其他界面和逻辑都不要动"；附件里挂上那张深蓝色图标；点「立刻修改」，四步本地跑完，直接装到本机。整个过程十八分钟，包括把手机递给对方看效果。

验证：三处逐一核对：桌面上名字是"巡检助手 · 内测"，图标是新的深蓝色，点开启动页 logo 已换；再往下点两层界面，确认没被顺手改动；最后看一眼版本号，还是原来的。确认完一键分享到微信试点群，群里同事当场装了一份，反馈"图标清了"。需求原文留在项目 history 里，晚上复制到工作群存档。

实例三（周三 · 经典版）：加固旧包脱壳、改两处、导出工程存档

以前：这种包我们内部叫"硬骨头"。加固过的包，直接反编译出来的东西看不成样子，早些年只能放弃，或者找原作者要未加固的版本。后来有了脱壳工具，但命令行一套套，参数记不住，脱完还得自己拼工程，一个包折腾半天是常事。

这次：经典版里跟向导走自动脱壳修复，工具会告诉你这个壳处理到什么程度——加固越复杂成功率越低，它不会假装成功。这次脱得比较干净，工程在本地摊开：res 里找到启动图的三套密度资源逐一套换，命名与原文件一致；那句文案硬编码在某个界面的 smali 中，用 SMALI 代码级修改把常量换掉。

验证：手机连电脑，装包，看实时日志，把启动页和那句文案所在的界面各走两遍，日志里没有异常堆栈。再检查工程能否正常打开、资源引用有没有断。最后把"改了哪两处、没动什么、脱壳处理结果"写成一段说明，跟着 APK 和工程目录一起交出去——这份说明比包本身更能让人放心。

十、安卓客户端：这套组合里的"手"

如果把这套组合比作一个人，电脑版是车间，经典版是精密台，而安卓版是手——它不一定最有力量，但它是唯一能伸到现场去的那只。这一周里，它干的活其实只有一单，可如果没有它，那一单就得等到第二天，客户当场的那句"就这个"也就不会发生。

安卓客户端的便利性集中在四件事上。第一，导入几乎没有成本：APK、JAR、APKS、XAPK、APKM 都能导，更关键的是能从「已安装应用」里直接选——手机上装着的自家应用、内部工具、调试版，点一下就是它。第二，开工门槛低到只剩"有电"：不用开机、不用连线、不用找插座，反编译、改包、回编、对齐、签名全在手机本地完成。

第三，交付出口就在手边。改完可以直接装到本机，可以一键分享到微信 / QQ，也可以另存到「下载」。客户要的从来不是文件，是效果；效果在手机上，手机就在手上。第四，痕迹跟着项目走：每次需求记进项目 history，可追溯，项目文件能在应用内浏览，必要时还能手工编辑。

十一、FAQ：关于三版本组合的七个问题

1. 三个版本都要装吗？
不必。组合的前提是"手边有什么就用什么"。只有电脑的人，用电脑版加经典版就能覆盖绝大多数场景；常在外面跑的人，加一个安卓版，等于给自己多了一双手。装三个不冲突：电脑版与经典版可同机共存，各自管理各自的项目。

2. 两个版本签名不一样，装的时候会不会出问题？
会。系统只认签名一致的同包名安装，不一致会报 UPDATE_INCOMPATIBLE，只能卸载重装，而卸载会清数据。所以团队里最好统一用一个 jks；电脑版可以把它存进项目 config.ini，之后每次打包直接用。

3. 手机上能不能也批量出包？
能做，但不建议当成主力。手机屏幕一屏看一个项目，批量命名、逐份比对截图、多设备并行验证都很吃力。批量的活交给电脑版的循环打包：AI 改完一轮自动打包、按规则命名、上传云存储，人只在关键节点看一眼。

4. 为什么加固包一定要回工位？
因为要"看得见"。加固包得先脱壳，脱完还要在资源、Manifest、smali 里逐处确认，改错了要靠实时日志定位。这些都需要大屏和完整工程目录，手机做不了这一层。经典版的脱壳向导会如实告诉你处理结果，加固越复杂成功率越低，这点要有预期。

5. 三个版本的项目会不会互相覆盖？
不会。电脑版每个项目是一个独立的 8 位随机字符串目录，里面放 config.ini、source.apk 和 apktool 输出；经典版有自己的工程目录；安卓版的项目在应用内部管理。它们各管各的，跨版本只通过 APK 交接。

6. 交接时最少要带哪几样东西？
四样：源包（带版本号和 src 标记）、需求原文（照抄不转述）、产物（统一命名 + pack.log）、验证结果（设备、系统版本、改了哪几处、没动哪几处）。四样加起来不到十分钟，能省掉后面几天的来回。

7. 登录和大师币是怎么回事？
导入 APK、编辑项目、充值这些动作需要先登录（微信扫码、QQ 扫码或账号密码都行）。大师币不足时，导入 APK 和编辑项目不受影响，只有点「立刻修改」和「去打包」时会提示充值。任务中心有每日签到、邀请好友、分享推广、每日体验等，奖励即时到账。具体套餐以应用内展示为准。

十二、用户怎么说：三种姿势，同一根接力棒

"以前我总觉得工具要选一个用到熟，后来发现根本不是。批量出包在电脑上挂机，客户临时要一版在手机上改，两个东西同时开着，谁也不碍谁。"

—— 老周 · 安卓逆向爱好者

"循环打包救了我的周一。六个渠道包，命名规则一配，我去开会，回来六个包整整齐齐躺在发布目录里，日志一份不少。"

—— 阿柯 · 小团队开发者

"手机版最值钱的地方是'当场'。客户在会上提一句，我十八分钟把包递过去，那个表情比什么方案都管用。"

—— 阿枣 · 电商运营

"经典版的工程全可见是我最看重的。壳脱开之后，资源在哪、smali 长什么样，全在本地，改错了能一行行看回去。这种掌控感别的工具给不了。"

—— 河马 · 独立开发者

"我们工作室的规矩是：批量在电脑、现场在手机、硬骨头回工位。三个人照着这个分工跑了一个季度，返工少了一半，吵架也少了。"

—— 大头 · 工作室主理人

"我把内部工具的图标和名字在手机上改完，直接微信发给试点同事。以前这套流程要走一天，现在趁着等电梯的时间就做完了。"

—— 青柠 · 内测分发负责人

"课堂上我让学生分三段做：先用手机改一句文案，再用电脑批量出三个包，最后在经典版里看 smali。三种工具一起讲，比讲十遍原理都清楚。"

—— 谢老师 · 高校实训讲师

"接手别人的活最怕没记录。现在交接必须带 history 原文和 pack.log，翻一眼就知道上一版改了什么，不用猜，也不用重新做一遍。"

—— 小鹿 · 客户成功经理

这些反馈指向的是同一件事：工具的分工一旦清楚，人的选择成本就消失了。剩下的只是判断"这一棒给谁"，而不是纠结"我到底该用哪个"。

周五傍晚，便签上的六个包名全划掉了。这一周我一共打开了三个工具，走了三次接力，没有一棒掉在地上。回头看，最值钱的不是哪个功能，而是那种"随时能开工"的踏实：在工位有工位的一套，在路上有路上的一套，遇到硬骨头有硬骨头的一套。工具不再是"你得迁就它"的东西，而是"它能跟上你"的东西。

所以如果你也在一周里被三种不同形状的需求拉扯，我的建议不是"选一个最强的"，而是把三个都备上，然后练熟交接。练熟的标准很简单：换手的时候不用想、不会丢、交出去的包谁都能接着改。做到这三点，你会发现改包这件事的节奏变了——不是变快了，是变顺了。

这一周的实录来自安卓修改大师智改工坊。智能修改电脑版（V1.9.0.0）、智能修改安卓版（V50.07.00.00）、修改大师经典版（V11.27.00.00）的介绍与下载入口都在 https://www.apkeditor.cn/ai-version.aspx，官网 www.apkeditor.cn。找一个你手边自有或已授权的包，从最顺手的那一棒开始——只需说话，就能让应用变成你想要的样子。