安卓修改大师 · 智改工坊

改完就发包，等于把麻烦留给三个月后的自己

五个交付物 · 一套归档习惯 · 两个自家应用实例

先把主标语放在最显眼处：改包本身不难，难的是三个月后你还说得出——这个包是谁、什么时候、按哪条需求改的。交付的门槛从来不在手上，而在你有没有把过程留下来。

本文主角是安卓修改大师智改工坊：一款 Windows 桌面工具，把"改 APK"从技术活变成一句话——拖入安装包，用中文写需求，AI 改包，改完自动回编 / 对齐 / 签名 / 校验，一键装到手机或模拟器看效果。介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网 www.apkeditor.cn。

这篇不聊怎么改，只聊改完之后那一步：交付。很多人把"发包"当终点，其实那只是半程。一个能被追溯、能被复现的包，和一堆"我发你微信了"的文件，三个月后会变成两种完全不同的处境。

一、为什么"改完就发出去"迟早会出事

先看三种几乎必然会碰上的情况。第一种：测试问"这是最新那版吗"——你和同事手上各有一个同名 signed.apk，界面看起来一样，谁新谁旧只能靠文件时间猜，猜错就是一次无效测试。第二种：领导说"还是上一版好，改回来"——你打开项目目录，发现只有最新的包，上一版早被覆盖，于是从头再改一遍。第三种：装上去闪退——你心里知道大概是签名或资源的问题，但手上没有证据，只能重跑，跑好了也不知道上次为什么坏。

一句话总结：改包是技术活，交付是管理活。技术活可以靠手感，管理活只能靠清单。

所以"一个改包任务该交什么"，答案不是"一个 APK"，而是一组能自证清白的文件。下面五样，缺任何一样，交付都是残缺的。

二、五个交付物总览

清单如下。注意这五样在智改工坊里都是改包过程中自然产生的，你不需要额外做记录，只要知道去哪拿。这一点很关键：交付经常残缺不是因为懒，而是因为"记录"和"干活"是两套动作，人一忙就漏；工具替你把记录做掉，残缺的概率就低得多。

三、签名包：唯一能直接交给别人的文件

先用一句常识开场：回编出来的包不能直接安装。Android 要求每个安装包都带签名，而反编译再回编会破坏原签名，所以"能装"的包必须走完整条流水线。在智改工坊里，这条流水线是打包窗口里的四步：

第三步和第四步的关系值得单独说。前三步只看退出码——命令跑完就算过，但"命令跑完了"和"签名确实生效"不是一回事。多做一步 verify 的意义就在这：它是唯一能回答"这个包到底能不能装"的那句话。对交付而言，这一步不是锦上添花，而是分界线。

四步跑完，项目目录的 build 子目录里会留下三样东西：unsigned.apk、aligned.apk、signed.apk。交付时只发 signed.apk，另外两个留在自己机器上——它们是过程件，发出去只会让人分不清该装哪个。还有三个细节决定交付好不好用：

• 打包过程中窗口不给关。这是防呆：中途关掉容易让人以为"没在跑"，重复点一次就出来两个包，又分不清哪个是哪个。
• 跑完可「保存 APK」，默认名是 应用名_版本号_signed.apk，也可以「打开所在文件夹」自己去拿。默认名等于把命名替你定了：一看就知道是哪个应用、哪一版、能不能装。
• 签名密钥放在工作目录根目录下的 testkey.pk8 与 testkey.x509.pem，可以替换。企业内部若统一用一把自己的密钥，把这两个文件换掉即可，交付出去的包签名就一致了。

四、源包与需求记录：想改回去，靠这两样

很多人把源包理解为"以防万一"，其实它是交付的地基。没有源包，每一次改动都不可逆；有了源包，任何改动都能重来一遍。智改工坊在建立项目时就做了这件事：每导入一个包，程序建一个 8 位随机字符串命名的项目目录，自动写一份 config.ini，并拷一份 source.apk 进目录。从项目建好的那刻起，源包就被固定住了。反编译输出放在 apktool 目录；而且反编译失败不影响项目本身——配置、图标、源包都已落地，程序只会提示原因并给出日志路径 apktool.log，交付链条不会断。

第二样是需求记录，它的价值在"照上次那条再改一遍"时会变得极其具体。项目详情页直接列出修改历史，最新一条在最上面，每条显示 #序号 + 时间 + 需求原文，而且原文完整显示、不截断——你当初怎么写，它就怎么记着。想复用，点一下右侧「选择」，那条需求就回到输入框里。

一个小习惯：需求写得越具体，记录越值钱。写"界面好看一点"，三个月后你自己也看不懂；写"把首页顶部背景换成附件里的新宣传图，其他不动"，记录就变成了可以照着执行的操作说明。

五、打包日志与打包标记：证据链的另一半

第四样是 pack.log。它不发给客户，却是你自己最该留下的一份文件：打包每一步都会写进这个日志。为什么强调"过程"？因为改包出问题时，现象往往离原因很远：包装不上、装上闪退、装了但界面是旧的，三种现象可能分别指向签名、资源、回编三个不同环节。有日志可以直接定位；没有日志就只能重跑，而重跑如果好了，你依然不知道上次为什么坏。

除了日志，还有一个专为追溯设计的东西：打包标记。每次出包前，程序自动往 res/values/styles.xml 写入一个 name="info" 的样式，内容是把时间、登录账号、机器码、机器名、系统用户名、程序版本、应用名、包名等信息编码后的标记。它解决的问题非常朴素：当一堆包散在不同人的手机上时，你需要一个不依赖文件名、也不依赖口头记忆的身份信息。文件名会被改、聊天记录会丢，但标记是写在包里的：出包时间、出包账号与机器、程序版本、应用名与包名，回头都能查。

再加上四步里最后那次 verify 的结论，证据链就闭合了：谁（账号 + 机器）、何时（时间）、改了什么（history.ini）、怎么做的（pack.log）、结果如何（verify + signed.apk）。这五问答得上来，交付就是专业的；答不上来，包本身即使没问题，也随时可能被一个简单追问打回。

六、版本说明与归档：最后一页纸，和放东西的习惯

第五样是版本说明。它不是工具产出的文件，而是你写给自己团队的一页纸，只需要三段：这版改了什么（例如"桌面图标换成新 logo；启动页背景换成夏季宣传图"）、怎么验证（例如"装到测试机上打开一次，看启动页与图标"）、基线是哪一版（基于哪份 source.apk）。第一段让测试知道该看哪里，第二段把验收从"感觉"变成"动作"，第三段让回退有据可依。

归档四条建议。第一，不要自己另起目录树：项目目录已经是天然的组织单位，源包、改动、历史、日志、产物全在里面，项目列表还直接读磁盘、可搜索可刷新；把 signed.apk 单独拷到桌面、把源包挪进别的文件夹，看着像整理，实则是在破坏关联。第二，命名跟着默认名走：在 应用名_版本号_signed.apk 后面追加日期或批次即可，别改成"最终版2""真的最终版"——这类命名的问题不在不专业，而在于不携带任何可核对的信息。第三，定一个"留几份"的规则：每个项目留最新签名包加最近两版，源包永远留，history.ini 与 pack.log 永远留；正在进行的项目本就不多，留下的量很小，却能在"回退一版"和"对比两版"这两种最常见需求里救你一次。第四，看得到磁盘余量：用户中心的项目统计会显示项目数量、修改总次数、占用空间与所在磁盘剩余空间，习惯能不能长期维持，很大程度取决于你能否一眼看到"这块盘还剩多少"。最后是清理：项目列表里每条可编辑、看历史、删除，而删除做了防呆，只允许删除 Project 目录的直接子目录——归档的另一半是"敢删"，敢删的前提是工具替你把边界划死了。

七、两个自家应用：从"发个包"到"交一套东西"

道理讲完，看两个我们自己真实做过的场景，都发生在自有应用上。

两个例子的共同点很清楚：以前省下的是"记录"的时间，后来花掉的是"追溯"的时间，而后者往往贵得多。把交付物清单当本能，返工率会明显下降——不是因为改得更快，而是因为不用重做。

八、他们说：交付这件事，用过就回不去了

把全文收一句：一次改包真正交付的，不是那一个 APK，而是一条能被别人接手的证据链——签名包负责"能装"，源包负责"能退"，需求记录负责"能复现"，打包日志与打包标记负责"能追溯"，版本说明负责"能被验收"。工具已把前四样自动放进你的项目目录，你只差最后那三行字。回头再看开头那句主标语：改包本身不难，难的是三个月后你还说得出——这个包是谁、什么时候、按哪条需求改的。

产品是安卓修改大师智改工坊，介绍页：https://www.apkeditor.cn/ai-version.aspx；官网 www.apkeditor.cn。想验证这份清单到底省不省事，拿一个自家的包走一遍最直接：拖入安装包 → 写一句中文需求 → 看它自动回编 / 对齐 / 签名 / 校验 → 一键装到手机或模拟器看效果。