课堂上现场改一个包：智改工坊当教学演示与实训素材的用法

如果你是职业院校的移动开发讲师、企业内训的带队工程师，或者正带着几个新人做客户端的负责人，大概都经历过同一种尴尬：备了一节课讲「Android 应用是怎么被改出来的」，真开始演示时先花十分钟装 JDK，再花十分钟解释 apktool 的报错，等要讲「到底改了什么」的时候，下课铃响了。不是内容不好，是演示被工具链卡住了。这篇文章想讲清楚一件事：把课堂上那个「需要现场改的包」交给安卓修改大师智改工坊，演示会变成什么样。它是一款 Windows 桌面工具，把改 APK 变成一句话——拖入安装包，用中文写需求，AI 改 smali 与资源，改完自动回编、对齐、签名、校验，一键装到手机或模拟器看效果。工具的介绍页在这里：https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn，可以先打开对照本文看。

还有一个前情提要值得说明：整篇讲的练习对象，都是学校或团队自己开发的应用、自己做的实训 Demo、自己内部用的工具包。教学场景里这条边界必须先立起来——课堂要教的是「改包这件事的链路与规范」，不是去动别人的商业应用。这一点在最后还会再强调一次。

一、课堂演示改包，到底卡在哪四个地方

把痛点说透，后面的方案才有意义。带过课的人都知道，现场演示翻车往往不是「知识没讲清楚」，而是被四件事打断：环境、命令、报错、时间。它们依次出现，每一样都能让一节课的节奏散掉，而散掉的注意力很难再收回来。

• 环境各不相同。机房电脑装没装 Java、装的是哪个版本，授课前你并不确定；学生自带的笔记本更是五花八门。等到命令行回一句「java 不是内部或外部命令」，这节课的开场就变成了装环境。
• 命令记不住，也讲不完。解包、回编、对齐、签名、验证，每一步都是一串参数，光是把 zipalign 与 apksigner 的子命令写对，就要占掉半块板书，写错一个符号还要重来。
• 报错看不懂，还看不出卡在哪一步。反编译失败、回编失败、签名看似成功其实没签上——这三类问题在现场的表现都是一行红字，学生只会记住「改包很难」。
• 时间不可控。等待本身就是演示的一部分，但你没有把握它要等多久。学生低头看手机的那三十秒，注意力就再也回不来了。
• 演示一次就没了。课后想复现课上那一步，只能靠学生自己的笔记；笔记里少一个参数，回家就卡住。

智改工坊对这四个点的处理方式很朴素：环境交给「体检 + 一键更新」，命令收进一条自动链路，报错给原因提示加日志路径，时间靠可见的衔接来稳住；而「复现」这件事，交给了项目目录与历史记录。下面几节逐条拆开讲，尽量按「课上怎么用」的顺序来。

二、把一场演示压缩成五步：屏幕上依次出现什么

教学的第一个要求是「每一步都能被看见」。这套流程恰好是五段式，每一段都有明确的视觉反馈，投影出来学生跟得上。安装包拖进窗口那一刻就开始了，支持拖入或选择 APK / JAR / APKS / XAPK / APKM / CLASS 这些格式，导入后用的是工作目录里的 aapt 来解析，界面直接给出图标、应用名、包名、版本号、最低与目标 SDK、启动页。

步骤	你做的动作	屏幕上看到什么
一、导入	把包拖进窗口	图标、应用名、包名、版本号、SDK 与启动页一起出现
二、写需求	在输入框写中文，或去话术库点「选择」	需求原文完整看得见，学生知道正在改哪一句
三、改包	点「立刻修改」	需求送进右侧 AI 窗口执行，改完自动弹出打包窗口
四、出包	不用操作，四步自动跑	回编 → 对齐 → 签名 → 校验，产物与 pack.log 落盘
五、看效果	什么都不用点	应用自动装到手机或模拟器并拉起，手机可投屏到电脑

建议把这张表印成讲义第一页，让学生对着表看演示。演示到第三步时，右侧的 AI 窗口与主窗口是并排吸在一起的：两窗高度始终一致，宽度合计固定占屏幕的四分之三；主窗口拖宽，右侧自动变窄，主窗口最小化它跟着最小化，还原时一起还原。这在课堂上有实际意义——投影面积有限，你不需要在窗口之间反复切换，学生一眼能同时看到「需求」和「它在做什么」。有学生提问时也不用慌，从任务栏点回主窗口，右侧窗口会被恢复并抬到最前，但不会抢走输入焦点。

第四步的四连动作值得单独讲一分钟，因为它是整条链路里最容易被想当然的部分：回编（apktool b）只看退出码，对齐（zipalign -p 4）只看退出码，签名（apksigner 配合 testkey）也只看退出码，而「到底签没签上」这件事，要由最后一步 verify 说了算。这正好能当堂追问：前三步都返回成功，包就一定能装吗？答案是不一定。这样的知识点，比让学生抄十条命令有用得多。产物也留在项目目录里：build\unsigned.apk、aligned.apk、signed.apk 三份，加上一份 pack.log，谁想课后复盘，顺着日志就能往回找。

课前还有一件必须提前说清的事：导入 APK、编辑项目、充值都需要先登录，登录窗口支持微信扫码 / QQ 扫码 / 账号密码三种方式，底部也可以去注册与找回密码。为什么要在开课前强调？因为它决定了学生的机位准备顺序：账号先登好、包先导进来、需求先写好、附件先挑齐，课堂上真正花时间的部分就只剩「判断」——判断需求写得对不对、判断结果符不符合预期。另外有个容易被误解的点，正好可以在课上当作一个说明：大师币不足时，导入 APK 与编辑项目不受影响，只有详情页点「立刻修改」和「去打包」才会提示充值；充值套餐来自服务端，支付是在外部浏览器里打开支付宝 / 微信完成的，程序每 3 秒轮询一次付款结果。教研组那边还可以让学生看一眼用户中心里的项目统计（项目数量 / 修改总次数 / 占用空间 / 所在磁盘剩余），机房磁盘紧张时，这是一份现成的用量说明。

三、话术库：为什么它天生就是教学素材

这是最想推荐给同行的部分。备课最耗时的一环，是把「我想让学生做的事」翻译成可执行、可检验的任务描述；而话术库里，这件事已经被写好了三千遍——六大分类（界面美化 / 弹窗引流 / 去除限制 / 常规修改 / 混淆去毒 / 插件添加），共 3000 条成型指令，每条都按同一个结构写全：要做什么、细节要求、参数参考、范围、验收。

把这五个字段翻译成教学语言，它就是一张标准的实训任务单：要做什么是任务目标，细节要求是约束条件，参数参考是给学生的示例输入，范围是「改动边界」这条安全线，验收就是评分标准。学生写作业最常犯的错是「需求说不清」，而库里的每一条都是一份正例，示范了什么叫说清楚；老师也不必再凭记忆写任务书，选一条改几个字就能用。

• 点「选择」，话术正文直接填进输入框，学生可以在原句上改动，直观感受「换一个词，结果怎么变」。
• 点「复制」，正文进剪贴板，讲师可以贴进课件、作业文档与班级群。
• 可改：话术内容来自程序目录下的 Resources\话术库.xml，是个可以手改的文件，改完点一下刷新就重新读取。
• 可校本化：教研组可以把措辞换成自己课程的说法，把课堂作业直接写进话术库，学生上机时从库里选。

从节奏上看，六个分类恰好能撑起六次实训课：前两次解决「看得见」的问题（改名字、换图标、换背景），中间两次解决「讲得清」的问题（弹窗与启动流程、去除限制与范围界定），后两次解决「可复现」的问题（改前留底与回退意识、附件系统与多文件协作）。这个排法在第五节展开成一张课表，可以直接拿走用。

还有一种用法，考试或者随堂测时特别好用：从话术库里挑五条出来，把「范围」和「验收」两段删掉，让学生补全，再逐条对照原文讲评缺点在哪。为什么这样出题？因为改包这件事在工程里翻车，绝大多数不是"不会改"，而是"没说清改了哪儿、怎么算改好了"。让学生先练"把话说全"，再练"把活干完"，顺序反过来，返工率会明显低一些。教研组也可以把这种题目固化成一张评分表：现象写清了没有、范围有没有边界、验收能不能照着点——三项各占几分，评起来比"看起来做得不错"公平得多。

四、两个实训实例：从「讲一遍」到「做一遍」

下面两个例子都用自家的包，并且都按「以前怎么做 / 现在一句话怎么做 / 改完怎么验证」三段写，方便你直接搬进讲义。它们恰好覆盖两类教学重点：一类是「看得见的改动」，一类是「说得清的改动」。

实例一：给自家实训 Demo 换应用名与图标，把「这一讲」写进包里。背景很简单：我们自己开发了一个课堂练习应用《智改实训 Demo》，每讲一次课就把它改成当讲的版本，名字带上讲次，图标换成这一讲的封面图，学生在手机上能一眼认出来。

以前要这么做：先 apktool 解包，在 res/values/strings.xml 里找到 app_name 改掉，还要确认 AndroidManifest 里引用的就是这一项；接着把封面图按不同密度切成好几套尺寸，替换 res/mipmap-* 下的启动图标；改完回编、对齐、签名、验证，最后 adb install 到手机上看。整套动作里真正跟这节课知识点相关的时间只有几分钟，其余都花在找文件与敲参数上，学生记住的是「麻烦」三个字。

现在一句话怎么做：把 Demo 包拖进智改工坊，在详情页点「选择附件」，一次把封面图和一张说明文本挑进去，给每个文件写清用途（这一步有校验：文件要能用——存在、不是目录、不是 0 字节、能读出来，说明不少于 10 个字），再在输入框里写：「把应用名改成『智改实训 Demo · 第 3 讲』，桌面图标换成附件里的封面图，其余保持原样。」点「立刻修改」，剩下的交给链路：附件会按「序号. 文件路径 —— 用途说明」拼在需求后面一起送过去，AI 不会猜错哪张图是干什么用的；改完在项目目录留下标志文件，主窗口每隔 2 秒轮询一次，读到就自动弹出打包窗口。

改完怎么验证：分三层，正好让学生一人查一层。第一层看详情页——导入时的图标是直接从包里取出的原图、按最高密度挑选（aapt 报出的 65534 是「任意密度」的哨兵值，不会被挑成小图），应用名也会跟着新值走；第二层看设备——打包后应用会自动装上并拉起，模拟器窗口被提到最前，手机则通过 scrcpy 投屏到电脑，教室大屏上直接能看见新图标、新名字；第三层看产物——项目目录里的三份 apk 与 pack.log 都在，装完还会用 dumpsys 看一眼前台应用是不是它。

实例二：去掉自家示例应用的开屏推广位，顺便教会「范围与验收」。背景：我们的示例应用里内置了一个开屏推广弹窗，本意是演示弹窗模块的写法，但上机练习时它会挡住操作，学生第一件事都是手动点掉。课堂上把它去掉，既让练习更顺，也顺势讲一个工程知识点——范围怎么写。

以前要这么做：先在反编译出的资源与 smali 里找到这个弹窗的布局和它的调用位置，判断删掉布局会不会引发空指针，再决定是删调用还是删资源；改完回编、签名、验证，装上去点两次确认不再出现。这套判断对新手并不友好，而且一旦删多了应用起不来，排查又是半小时，课上根本耗不起。

现在一句话怎么做：在输入框里把四件事写全——现象、目标、范围、验收：「这个应用启动时会弹出一个推广弹窗（现象），去掉它（目标），只改启动流程里的这个弹窗逻辑，其余页面与功能一律不动（范围），改完连续启动两次确认不再出现、其他页面都能正常进入（验收）。」这句话本身就是一份合格的任务书。让学生照着念一遍，他们就能明白「范围」两个字在工程里意味着什么，也能理解为什么库里每条话术都要写「范围」和「验收」。

改完怎么验证：验证动作已经写进需求里了。打包完成后应用会自动装到模拟器，连着启动两次，看弹窗是否消失、主流程是否可用。如果发现异常，详情页的历史记录里那条需求还在（每条显示 #序号、时间与完整的需求原文，不截断），点右侧「选择」把它填回输入框，改一改再跑一次——这就是迭代最朴素的形态。学生也能看到工程中真实的改法：不是一次写对，而是可重复地逼近。

有了这两个实例，作业就可以分层布置了，这也是我们在实际课堂上试过之后固定下来的做法。基础层只改一处、只求看得见：把自家实训 Demo 的应用名或版本号改掉。进阶层要带附件、要写清用途：给自家 Demo 换一张启动页背景图，并在需求里说明这张图要用在哪一页。挑战层要求范围与验收都写全：把自家 Demo 的开屏弹窗去掉，同时写清"哪些不许动"和"连续启动两次确认"这样的验收动作。三层作业用的是同一个包、同一套流程，区别只在需求的严谨程度，评分也就能落在"需求写得好不好"上，而不是"结果能不能用"这种主观判断上。

三层作业的需求原话可以是这样：
基础层——"把应用名改成『智改实训 Demo · 第 3 讲』，其余不动。"
进阶层——"启动页背景换成附件里的图片，只改启动页这一处，其它页面保持原样。"
挑战层——"去掉启动时的推广弹窗，只改弹窗逻辑，其它页面与功能一律不动，改完连续启动两次确认不再出现。"

五、把六个分类排成六次课：可以直接拿走的课表

很多老师问过同一个问题：资源有了、工具有了，课怎么排？我的建议是按话术库的六个分类走，一节课一个分类，每次都留出「老师演示十分钟 + 学生上机三十分钟 + 验收十分钟」的结构。理由很实在：分类本身就是难度梯度，越往后越依赖判断力，而不是越往后越依赖手速。下面这张课表是我们自己在用的版本，你可以按课时长度自行拆分或合并。

• 第 1 课 · 常规修改：先让学生读懂一个包。导入后看图标、应用名、包名、版本号、最低与目标 SDK、启动页，再改一个最直观的东西——版本号或应用名。验收就是详情页上那几行信息发生了变化。
• 第 2 课 · 界面美化：资源与素材替换。用附件把图片交给 AI，讲清「哪张图用在哪里」，学生第一次体会到「说清楚用途」有多重要。
• 第 3 课 · 弹窗引流：启动流程与组件。让学生观察启动页信息是怎么来的，理解应用启动时都发生了什么，再动手加一个自己写的提示弹窗。
• 第 4 课 · 去除限制：专讲范围界定。这节课的重点不是「删掉什么」，而是「只删什么、什么不许动」，把上节课学到的范围写法用一遍，并强调只对自有应用使用。
• 第 5 课 · 混淆去毒：讲改前留底与回退意识。每个项目一个 8 位随机字符串目录，自动写入 config.ini 并拷一份 source.apk，反编译输出在 apktool 目录，学生由此理解「原始包与产物要分开存放」。
• 第 6 课 · 插件添加：附件系统与多文件协作。一次挑多个文件、给每个文件写用途，理解依赖关系与顺序，最后交一份能复现的作业。

课表之外还有一件小事，对教学管理帮助很大：作业怎么收、怎么对比。详情页会直接列出这个项目的修改历史，最新的一条在最上面，每条显示 #序号、时间与完整的需求原文（不截断），右侧的「选择」可以把那条需求填回输入框。于是同一道题，学生的第一版与第三版可以并排对比；老师收作业时也不需要额外的文档，看一眼历史就知道这个包被改了几轮、每轮写了什么。历史存在 history.ini 里，按「记录1、记录2」递增，删掉某一节就删掉那条记录，学生自己也能维护。

上机环节建议两人一组：一人写需求，另一人当验收员，对照需求里那句「验收」逐条点一遍，然后交换角色。这个安排会让课堂气氛明显不一样——写需求的人开始主动把「范围」和「验收」补全，因为验收员会照着字面查；而验收员也不再只看"能不能打开"，而是学会照着条件判断。老师在这一轮里不需要逐个机位盯，只需要挑两三条需求当众点评，讲清"为什么这条写得可执行、那条写得没法验收"。话术库里那三千条之所以每条都写全五要素，就是为了让这种对照有参照物。

还有两个细节值得写进课堂约定：其一，历史里只保留用户原话，附件说明不会进历史，所以复现一次作业时，记得把附件一起带上；其二，如果同一节课要同时演示「改前」和「改后」，可以给两个版本各建一个项目——项目之间互不干扰，切换演示时不会因为共用目录而互相污染。

六、把「意外」挡在课堂之外：机房环境的稳

教学场景对稳定性的要求，其实比工程场景更高：工程里你可以说「等我五分钟配一下环境」，课堂上你只有一次机会。智改工坊在这件事上做了几层兜底，值得在开课前逐条过一遍，把它们写进《上课前检查清单》。

• 工作目录不用你操心。程序启动时会自动挑盘：D → E → F → G → C，取第一个能读写且剩余空间不少于 1GB 的盘，拼成 <盘符>:\AiApkEditor；下面两个子目录 tools 与 Project 分工明确，tools 里的工具会自动递归搜索，不需要登记每一个可执行文件的路径。
• 开课前先做一次体检。「参数设置」页里有工具链体检，aapt、java、apktool、zipalign、apksigner 会逐个报是否就绪以及完整路径，一眼看出这台机器缺什么。
• 缺了就点「立刻更新」。环境不齐时点击它会自动下载并解压工具包（7z 格式），装完重新检测一遍。机房电脑是还原卡环境也不怕，课前跑一遍就行。
• 反编译失败不等于演示失败。如果遇到不支持的包，反编译失败并不影响项目本身——配置、图标、源包都已经落地，程序会提示原因并给出日志路径（apktool.log）。这本身就是一堂排错课的好素材：带学生一起看日志，比直接给答案有用。另外实测 12MB 左右的包反编译约 3 秒，超过 10 分钟会中断并报错，不会让课堂无限等待。
• 界面不会卡住学生。解析与反编译跑在后台线程，演示时界面始终可操作；打包过程中窗口不给关，学生能明确看到「它正在跑」，而不是怀疑自己点错了。

设备侧的准备同样值得写进清单。教室里用模拟器更方便：如果模拟器装了但没开，程序会搜出它的安装路径并问你要不要现在帮你打开；常见国内模拟器（雷电 / MuMu / 夜神等）装了但 adb 没连上时，会自动扫端口连上；连上后窗口会被提到最前面，投影里一目了然。如果是用真机演示，手机走 scrcpy 投屏到电脑，学生在大屏上能看到每一次点击的效果；遇到设备没授权，程序会提示你在手机上点「允许 USB 调试」，这句话本身就是个知识点。

最后是场地适配：投影仪对比度不够时，可以在「参数设置」里换配色主题，内置 10 套（极夜蓝 / 深海蓝 / 紫罗兰 / 樱花粉 / 烈焰红 / 落日橙 / 古铜金 / 青柠绿 / 薄荷绿 / 石墨灰），点一下立刻生效，教室灯光明亮就换成深色主题，灯光偏暗就换浅色主题。如果你希望每次打开就是固定的演示布局，还可以用命令行参数预置本次运行的外观，比如 --target 指定右侧要吸附的程序、--width 与 --height 指定窗口尺寸、--gap 指定两窗间隙、--dock 或 --no-dock 决定启动时是否吸附，这些参数只对本次运行生效，不会改坏学生的日常设置。

如果离上课还有五分钟，别急着讲内容，先让学生自己看首页底部那条提示：使用技巧提示条每 12 秒轮换一条，内置 112 条，都是操作层面的小提醒，觉得吵也可以在设置里关掉。让它自己滚上两分钟，学生往往会先问出三四个问题，这节课的互动就有了起点。真遇到疑难杂症，还有诊断日志可以看：吸附过程与打包过程写在 %LocalAppData%\ApkGallary\dock.log 里，异常会记到 error.log；教学生学会提供日志路径而不是只描述"它坏了"，是这门课之外的一项通用素养。

七、课前最常见的五个问题，一次答完

问：学生机器上环境不全怎么办？答：让学生打开「参数设置」页做一次工具链体检，aapt、java、apktool、zipalign、apksigner 会逐个报是否就绪与完整路径；缺哪一项就点「立刻更新」，程序会自动下载并解压工具包（7z 格式），装完重新检测。tools 目录本身是自动递归搜索的，不需要逐台机器登记可执行文件路径，这一条对机房特别友好。

问：反编译失败了，这节课的实验是不是就废了？答：不会。反编译失败不影响项目本身——配置、图标、源包都已经落地，程序会提示原因并给出日志路径（apktool.log），你可以直接带着学生一起看日志找原因。另外，分包 apks、加密包、jar、class 这类解析不出包信息的文件，会以文件名继续建项目，页面上给一句说明，学生至少能看到"包与包之间是有差别的"这件事，不至于卡在导入这一步。

问：怎么证明这一次改动真的生效了？答：三个证据链一起看。第一，打包四步里最后一步是校验（apksigner verify），它回答的是"到底签没签上"，只看前三步的退出码是不够的；第二，应用会自动装到设备并拉起，装完还会用 dumpsys 看一眼前台应用是不是它，屏幕上就能确认；第三，产物与日志都在项目目录里——build\unsigned.apk、aligned.apk、signed.apk 与 pack.log，学生可以随时回看。

问：一个班几十个机位、几十个不同的包，会不会互相串？答：不会。每个项目独占一个 8 位随机字符串目录，程序会自动写入 config.ini 并拷一份 source.apk，反编译输出放在该项目的 apktool 目录里；项目列表直接读磁盘，带搜索与刷新，每条都能编辑、看历史、删除，删除还有防呆——只允许删 Project 的直接子目录，手滑也伤不到别的东西。

问：签名能不能换成学校或公司自己的？答：可以。签名用的密钥就是工作目录根目录下的 testkey.pk8 与 testkey.x509.pem，替换掉即可；如果课程涉及分发环节，正好可以借这一步讲"密钥要自己管好"。还有一件事必须在课上说明白：每次出包前，程序会自动往 res/values/styles.xml 写入一个 name="info" 的样式，里面是用时间、登录账号、机器码、机器名、系统用户名、程序版本、应用名、包名等信息编码后的标记，也就是说产物里会带出包痕迹。教学场景下这反而是个优点——谁的作业、什么时间出的包，一查就知道；但同时也要讲清楚它的存在，不能让学生以为产物是"干净"的。

八、用户评价：讲师、教研与学生怎么说

下面这些反馈来自我们接触过的几位使用者，身份各不相同，但提到最多的都不是「功能多」，而是「演示不中断」和「作业能复现」这两件事。

合规提醒：本工具面向自有版权或已获授权的应用，用于学习研究与企业内测等合法场景，请勿用于破解他人付费应用或绕过安全机制。课堂上请把这条边界讲在学生动手之前：练习对象只能是学校或团队自己的应用、自己的 Demo。

如果你所在的教研组准备把这条路走下去，有三件事我建议按顺序做。第一件，把话术库改成校本版本：打开程序目录下的 Resources\话术库.xml，把「要做什么、细节要求」换成自己课程的说法，把每节课的作业写进去，改完点刷新重新读取，之后新老师上手只需要选条目。第二件，把第二节那张五步表印成讲义第一页，让学生对着表看演示、对着表做上机，减少"我下一步该干嘛"的提问。第三件，把项目历史当作业档案：同一道题的三次迭代都留在项目里，期末讲评时直接调出来，比翻学生笔记可靠得多。三件事加起来，把一个"每次都要重新准备"的演示课，变成了可以交接、可以复用的常规课。

第一次把它带进课堂，可以按三步走：课前用自己的练习包完整跑一遍（导入、写需求、出包、装机看效果），把可能出现的提示先看全；课上只演示一次全流程，然后立刻让学生上手，演示越长，学生动手的时间越少；课后把这条需求留在历史里，下次上课直接点「选择」填回输入框，把更多时间留给点评与讨论。这三步不需要额外准备材料，边界也很清楚——只用自己团队或学校自己的应用练习，把"改包这件事该怎么做、该在什么前提下做"同时教给学生。

所以回到那句口号

：课堂上不用背命令，说清需求，包就改好了。老师省下的是折腾环境与解释报错的时间，学生拿到的是一份写清了范围与验收的任务单，以及一次从导入到装机、全程看得见结果的完整实践。这些正是安卓修改大师智改工坊想在教学场景里帮上的忙；如果你打算下节课就试，建议先拿自己团队那个练习包走上一次全流程，介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网 www.apkeditor.cn 上也有其它用法可以对照。

---