一节课改两个包：企业内训讲师怎么把改包全过程摊到投影上

安卓修改大师 · 智改工坊 · 用户故事

一节课里最贵的不是内容，是"学员亲眼看着它改完"的那几分钟

九十分钟一节课 · 现场改两个自有应用 · 全过程并排投在屏幕上

先把这一课的主标语写在最前面：好的演示不是"我改完了"，而是让每个人看清它是怎么被改完的。内训讲师何砚讲移动应用这门课讲了几年，越讲越确信一件事：学员记住的从来不是你念过的定义，而是他在投影上亲眼看到的一段过程——需求怎么被写下去、包怎么被打出来、装到手机上的那一刻是什么样。

他课上用的工具是安卓修改大师智改工坊：一款 Windows 桌面工具，把"改 APK"从技术活变成一句话——拖入安装包，用中文写需求，AI 改包，改完自动回编 / 对齐 / 签名 / 校验，一键装到手机或模拟器看效果。介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网 www.apkeditor.cn。下面这一课，是他去年冬天讲得最顺、也最像"现场手术"的一次。

一、投影仪打开之前：我最怕的不是讲错，是演示卡住

这门课的形式是半天，放在一家做工业设备的公司里讲，学员是信息中心的二十多个人——有做运维的，有做测试的，也有几个平时写内部小工具的开发。何砚把内容切成三段，中间那段留了四十分钟，专门做"从一句需求到一个能装的包"的现场演示。

四十分钟听起来宽裕，但内训讲师都知道，现场演示的时间是被"意外"吃掉的。工具版本不对、路径里带空格、命令敲错一个字母、签名环节报一句看不懂的错——每一样都能把十分钟变成二十分钟，而且学员的表情会从"认真看"变成"看他怎么办"。

• 卡在环境上：换了一台培训教室的电脑，工具链是否齐全全靠运气，课前半小时全用来"求生"。
• 卡在看不见上：命令行滚屏太快，学员只看到一个结果，看不到"哪一步做了什么、为什么这一步不能省"。
• 卡在验证上：包出来了，但装到手机能不能跑、跑起来是不是那个应用，还得靠现场手忙脚乱地插线。
• 卡在复现上：学员下课问"老师刚才那句原话是什么"，你只能凭记忆重复一遍，重点全丢了。

一句实话：教学场景对工具的要求，其实比生产场景更苛刻——生产里出错可以关起门来修，课堂上出错，二十多双眼睛都在等你。

所以何砚给自己定了一条规矩：课上要演示的东西，必须在课上当场做出来，不能放录屏，也不能提前把包准备好。理由很简单——录屏是"结果"，现场是"过程"；如果这门课只让学员看到一个成品包，那教的就只是"这事存在"，而不是"这事怎么做"。

为了把四十分钟用满，他把这半天课的时间分配做成了一张固定的表，从第一次讲到现在基本没动过。这张表后来被好几个学员要走，说是"回去照着给部门做内部分享"。

二、课件里那个应用：公司自己的「设备巡检助手」

这一课用的演示素材，是这家公司自己开发并维护的内网应用——一套给现场工程师用的设备巡检助手，用来扫码登记、拍照留档、上传巡检记录。这是公司自有版权的内部应用，信息中心的负责人当场把安装包和改包授权给课堂使用。这一点何砚每次都讲在最前面：课程里改的，永远是自己或已获授权的应用，这条线不能含糊。

演示前的准备只有一步：把公司给的那个安装包拖进智改工坊。拖入或选择都支持，APK / JAR / APKS / XAPK / APKM / CLASS 这几种形态都能进来，不需要事先转格式。松手之后，程序用工作目录里的 aapt 把包里的关键信息解析出来——图标、应用名、包名、版本号、最低与目标 SDK、启动页，这些正好是课堂上要讲的一张"应用身份证"。

这张"身份证"在教学里的价值，比在生产里更大。何砚会指着屏幕问学员："这个应用名是什么？包名是什么？最低支持到哪个安卓版本？启动页是哪一个组件？"——这些问题在座的运维和测试都能听懂，而它们恰恰是后面每一次判断的依据：改名改的是哪一处、启动页在哪一层被查出来、为什么改完还能照样拉起。

他还特意让学员看了项目目录：每个项目一个 8 位随机字符串目录，程序自动写好 config.ini、拷一份 source.apk 进去，反编译输出放在 apktool 目录下。解析与反编译都跑在后台线程，界面不卡——12MB 的包反编译大约 3 秒，超过 10 分钟会中断并报错。这几个数字他在课上都会念出来，因为它们让"自动化"从概念变成可感知的节拍。

讲项目之前，还有个前置动作他会在课前就做完：导入 APK、编辑项目、充值这些操作需要先登录，登录窗口支持微信扫码、QQ 扫码和账号密码三种方式，底部还能去注册与找回密码。课上他特意提了一句"为什么要有登录"，因为他知道台下的运维会问——除了账号体系本身，登录账号还会被写进出包标记里，谁在哪台机器上出的包，日后可以对上。他自己的账号里累积了一堆演示项目，用户中心那一页能看到项目数量、修改总次数、占用空间以及所在磁盘的剩余，每季度清理一次演示素材时，这个页面比翻文件夹直观。

这里还有一个细节他会专门讲：项目里展示的图标是从包里取出的原图，并按最高密度挑选。aapt 报的 65534 是"任意密度"的哨兵值，程序不会把它当成"挑最小的那张"，所以看到的永远是清晰原图。为什么值得花两分钟讲这个？因为台下坐着做测试的人，他们最反感的就是"工具悄悄替我做了一个我看不见的决定"。

三、课堂第一改：把巡检助手改成「巡检助手 · 培训演示版」

正式演示从一个最"看得见"的需求开始。何砚在课上要做的第一件事，是把公司的巡检助手改成培训专用的演示版本——换一个辨识度更高的图标，名称加后缀，避免学员把自己手机上的公司应用和演示版本搞混。

何砚在课上说了一句把这件事讲透的话："你们看到的'自动'，不是它猜到了我要什么，而是我把要求写清楚了。"他把需求当场念了一遍，然后逐项指出来：改哪里（应用名、图标）、改成什么（具体名字、附件里的图）、范围（各密度都要换，其它不变）——这三样写清楚，AI 做的事就是确定的。台下做测试的学员立刻接了一句："这不就是我们写缺陷单的要求吗？"课堂气氛到这里就活了。

课堂经验：把"一句话"和"随手改改"区分开的最好办法，就是当场把需求读一遍。学员立刻会明白：能被复核的需求，才是可交付的需求。

四、课堂第二改：启动页与弹窗——从"看得见"升级到"讲得清"

第一个包跑完之后，课堂时间过了大约三分之一。第二个需求，何砚特意挑了一个"视觉上更有冲击力"的：把巡检助手的启动页背景换成公司今年的安全生产宣传图，同时把首页那条弹窗文案换成针对这次培训的通知。

选这两个点是有教学考虑的。启动页是每个学员每天都会看到的东西，改前改后的差别一眼就懂；而"弹窗文案"属于典型的轻量级内容改动，改起来没有心理负担，却能展示"范围控制"这件事——只改文案，不动版式，不碰按钮，也不影响任何逻辑。第二点尤其重要，因为企业内训的学员里，很多人以后要做的正是这种"看起来很小、但必须改对"的活儿。

两次演示之间，何砚会把"为什么写清楚范围这么关键"再强调一遍。他用的是同一个类比：给同事写任务单，你写"把首页改好看点"，得到的一定是返工；你写"把首页顶部轮播图的第三张换成新品海报，其它不动"，得到的一定是你要的。AI 改包也是一样——它没有读心术，但它对"边界清晰的要求"极其顺从。

五、让过程看得见：两个窗口并排摊在投影上

这一课之所以讲得顺，有一个非常具体的技术原因：何砚把"写需求"和"AI 改包"这两个窗口并排放在了同一块投影上。

智改工坊有一个双窗口磁吸的设计：AI 改包程序会被吸附在主窗口右侧，两个窗口的高度始终一致，宽度合计固定占屏幕（工作区）的四分之三。用鼠标拖宽主窗口，右边会自动变窄；主窗口最小化，它跟着最小化，还原时一起还原。从任务栏点回主窗口时，右侧那个窗口会被恢复成普通窗口并抬到最前面——但它不会抢走焦点，所以你正在输入的需求不会因为"点了一下任务栏"就断在半句话上。默认启动时会自动挑目标程序，也就是工作目录下的 tools\zcode\zcode.exe，这个路径可以在 settings.ini 里改。

对课堂来说，这个布局的意义是决定性的：左边是"我现在写的这句中文需求"，右边是"它正在为此做事"。学员看到的是同一时刻的一整条链路——需求写下去，右边开始动，改完标志文件出现，打包窗口自动弹出来。没有任何一个时刻需要讲师说"你们等一下，我切个窗口"。

装到手机上那一步，也是他讲得最细的地方，因为这里有三个"工程师会喜欢"的技术点：

1. 拉起用的是 am start，而不是 monkey。他在课上会解释：新版安卓镜像里已经没有 monkey 了，而且它失败的时候退出码还是 0，容易让人误以为"启动成功了"。做测试的学员听到这里一般都会点头——"退出码骗人"是他们最熟悉的坑。
2. 启动页的组件名是分三档查出来的：先看项目 config.ini 里记录的那个启动页，查不到就去问设备 resolve-activity，最后才退回 monkey 兜底。三档的意义是"尽量拿到准确的答案，而不是随便试一个"。
3. 装完还会用 dumpsys 看一眼当前前台应用是不是它。这一步在课堂上被何砚称为"唯一诚实的验证"：装上不等于启动，启动不等于启动了你想的那个应用；只有确认前台是它，才叫演示成功。

他还现场把两种设备都演示了一遍。手机那侧，屏幕通过 scrcpy 投到电脑上，学员看到的是真实的手机画面；模拟器那侧，程序会把模拟器窗口直接提到最前面。国内常见的模拟器（雷电 / MuMu / 夜神这类）如果装了但 adb 没连上，程序会自动扫端口试着连上；如果模拟器装了但没开，它会搜出安装路径，然后问你要不要现在帮你打开；设备没授权，就直接提示你在手机上点「允许 USB 调试」。

课堂上被问得最多的一个问题是："它到底动了什么？"何砚的回答分三层，而且每一层都有看得见的东西可以指。

• 第一层，你说了什么：需求原文和修改日期会被写进项目的历史（history.ini），所以"我要求的是什么"是白纸黑字的，不靠回忆。
• 第二层，链路怎么衔接：需求被送进右侧的 AI 窗口执行，改完在项目目录留下一个标志文件，主窗口每 2 秒轮询一次，读到就自动弹出打包窗口——"自动"的本质是一个可以被指着讲的机制，而不是一个含糊的说法。
• 第三层，机器上留下了什么：项目目录里有自动写好的 config.ini、拷进去的 source.apk，反编译的输出在 apktool 目录，打包全过程写进 pack.log，产物在 build 目录。就算中途反编译失败，项目本身也不会坏，程序会提示原因并给出日志路径（apktool.log）。

这三层讲完，学员手里就有了"出事该翻哪里"的地图。何砚还顺势提了一句排查工具的位置：吸附过程和打包过程记在 %LocalAppData%\ApkGallary\dock.log，异常另有 error.log。台下的运维听到这里就开始记了——对他们来说，"有问题时去哪儿看"比"一切正常时多顺畅"更重要。

课堂上的那句总结：演示的价值不在于"顺利"，而在于每一步的结果都是可以自己确认的。确认得了，学员才敢在自己机器上照着做。

六、教学上的诚实：为什么"多一步校验"必须讲

打包窗口自动弹出来之后，何砚不会急着喊"看，好了"。他会把四步流程一步一步念给学员听：回编（apktool b）→ 对齐（zipalign -p 4）→ 签名（apksigner + testkey）→ 校验（apksigner verify），产物落在项目 build 目录下的 unsigned.apk / aligned.apk / signed.apk，全过程写进项目目录的 pack.log。

他还讲了签名密钥这件事：默认用的是工作目录根目录下的 testkey.pk8 与 testkey.x509.pem，这两个文件可以替换。放在企业场景里讲就很有意义——信息中心如果要求用自己的密钥，把密钥文件换掉就行，出包的动作完全不变。台下负责发布流程的那位学员当场记了笔记，因为"签名要统一"正是他们内部一直在推的规范。

讲到"包怎么落到学员手里"，他还补了两句很实用的话。第一，跑完之后可以「保存 APK」，默认文件名是"应用名_版本号_signed.apk"，也可以直接「打开所在文件夹」——课堂上二十多个人，如果文件名只有一串随机字符，发到群里三分钟就乱了；带着应用名和版本号，谁拿到哪个包一目了然。第二，项目列表是直接读磁盘的，带搜索和刷新，每一条可以编辑、看历史、删除，删除还有防呆设计：只允许删 Project 的直接子目录。他的演示机器上常年躺着几十个历史项目，靠搜索框就能在几秒内定位到"哪个班的哪一版"。

课堂最后十分钟，何砚留给了"可追溯"这个话题。他讲了出包标记的机制：每次出包之前，程序会自动往 res/values/styles.xml 里写入一个 name="info" 的样式，内容是时间、登录账号、机器码、机器名、系统用户名、程序版本、应用名、包名等信息编码后的标记。

为什么不讲别的、偏偏讲这个？他的理由很朴素："在企业里，包是会流转的。三个月后有人拿一个包来问'这是哪一版、谁做的、什么时候做的'，如果没人答得上来，那这个包就变成了一笔糊涂账。"讲到这里，信息中心的负责人当场补了一句："这条我们回去就要用。"

七、学员上手：把"话术库"当教材，把"附件说明"当课堂作业

四十分钟的演示结束后，剩下的是让学员自己在电脑上动手。这一步在内训里最难做，因为企业里二十多个人的岗位差别很大：做运维的平时不碰安卓，做测试的熟悉流程但不动代码，几个开发则可能觉得"这东西我自己也能弄"。何砚的做法是——不让所有人从零写需求，而是从工具箱里挑，再改。

他用的"工具箱"就是话术库：分六大分类——界面美化、弹窗引流、去除限制、常规修改、混淆去毒、插件添加，一共 3000 条成型指令。每条指令都把"要做什么 / 细节要求 / 参数参考 / 范围 / 验收"写全；看中哪条，点「选择」直接填进输入框，也可以点「复制」把正文复制走。

这个设计在教学上有个很妙的效果：它把"怎么写一句合格的需求"变成了可以模仿的样本。学员不是被要求凭空写出结构化需求，而是先看到 3000 条别人写好的样本，理解"原来要写到这个颗粒度"，然后再下手改。何砚给学员的课堂作业就是：从话术库里挑一条最接近你想法的，改三个地方——改成你要的名称、改成你的范围、补上你的验收标准。

作业里还有一条硬要求：必须挂一个附件，并且给附件写一句不少于 10 个字的用途说明。这条规矩来自附件系统的校验逻辑——它只校验两件事：文件现在能不能用（存在、不是目录、不是 0 字节、能读出来），以及说明的完整性（不少于 10 个字）。写完之后，程序会把附件拼成"序号. 文件路径 —— 用途说明"的格式，跟着需求一起发给 AI。

有个学员写了一句"这个图给我用一下"，被系统挡住了，全班哄笑。何砚顺势把这个当成了最好的教学时刻："写清楚用途不是形式主义。你把用途写清楚，自己下次回头看也知道当时想干什么；写不清楚，过两天连你自己都要重新猜。"他顺带提了一句"历史里只留需求原文，附件说明不进历史"这个细节——所以历史列表干净利落，全是当时说过的话。

动手环节最后，他让每个学员把自己那条需求跑一遍，跑完把历史列表拉出来看。历史在项目详情页里直接列出，最新的一条在最上面，每条显示 #序号 + 时间 + 需求原文，而且是完整显示、不截断；右侧点「选择」就能把那条需求填回输入框。项目列表里每条也有一个「历史」按钮，点开是单独的历史窗口。history.ini 里按"记录1、记录2"递增，删掉某一节就等于删掉那一条记录。

做课堂作业时，何砚反复强调一个和"写需求"同样重要的动作：点完之后要回头看结果。因为这门课的目的不是让学员学会"点一个按钮"，而是学会"对自己提的要求负责"——需求写得越清楚，出包后的验证就越简单；需求写得含糊，验证就只能靠运气。他把这句话做成了课堂上的固定提问：每次有学员跑完一遍，他就问一句"你怎么知道这一版是对的？"，直到学员能给出一个具体的答案：桌面图标长什么样、应用名叫什么、启动页是哪张图、弹窗写了什么。

他还用了一招"现场救场"来演示历史的价值：让一个学员故意把需求写错、跑一遍，然后说"我要回到刚才那版"。学员翻到上一条，点「选择」，改掉写错的地方，再跑一遍——五分钟内完成了从错误到修正的全过程。坐在后排的运维组长说了一句："这比我以前在群里翻聊天记录快多了。"

环境部分，何砚没有讲太多，只讲了三个"课堂必备"：启动自动挑盘——按 D → E → F → G → C 的顺序，取第一个能读写且剩余空间 ≥1GB 的盘，拼成 <盘符>:\AiApkEditor 作为工作目录，下面只有 tools 与 Project 两个子目录，tools 里的工具会自动递归搜索、不用登记；工具链体检——在「参数设置」页把 aapt / java / apktool / zipalign / apksigner 逐个检查，明确报出是否就绪以及完整路径；一键更新——环境不齐时点「立刻更新」自动下载并解压工具包（7z 格式），装完重新检测。培训教室的电脑是公用的，这三条让"课前半小时求生"这件事彻底消失。

还有些顺手的细节他也会一带而过：10 套配色主题（极夜蓝 / 深海蓝 / 紫罗兰 / 樱花粉 / 烈焰红 / 落日橙 / 古铜金 / 青柠绿 / 薄荷绿 / 石墨灰）点一下立刻换，投屏时清晰度更好；首页底部有一条使用技巧提示条，每 12 秒轮换一条，内置 112 条，可以在设置里关掉；窗口没有系统标题栏但可以拖动、四边都能缩放，投影时能把窗口拉成适合的比例；如果只是某一次想让两个窗口分开，命令行参数 --dock / --no-dock、--share、--gap 这些只对本次运行生效，改完关掉窗口，下次还是原来的配置。

八、他们说：一堂课之后，二十多个人各自带走了一句

课后收集反馈时，何砚发现不同岗位的学员记住的点完全不同——这恰好说明这次演示的覆盖面是够的。下面这些是课后回访里被提到最多的几句。

课快结束的时候，何砚又念了一遍开头那句主标语：好的演示不是"我改完了"，而是让每个人看清它是怎么被改完的。他这一课能讲顺，靠的不是手快，而是四件事同时成立：需求是当场写下来的、改的过程是并排摊在屏幕上的、出包的四步是能被逐一念出来的、装到设备上的结果是被 dumpsys 确认过的。学员带走的不是"老师很厉害"，而是一条自己回去也能照着走的路径。

产品是安卓修改大师智改工坊：拖入安装包，用中文写需求，AI 改包，改完自动回编 / 对齐 / 签名 / 校验，一键装到手机或模拟器看效果。介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网 www.apkeditor.cn。如果你也要讲这么一课，或者要给团队做一次内部分享，建议的验证方法同样是"当场做一遍"：拿一个自有或已获授权的应用包，拖进去，当着大家的面写一句中文需求，把出包四步和装机验证走完——能被现场复制的演示，才是真正有用的演示。