「安卓修改大师智改工坊」是一款 Windows 桌面工具，介绍页在：https://www.apkeditor.cn/ai-version.aspx。它的主线只有一句话——把安装包拖进去，用中文写需求，AI 去改 smali 与资源，改完自动回编、对齐、签名、校验，最后一键装到手机或模拟器上看效果。

这一篇不讲怎么改，专门讲改完之后的事：出包。因为在真实的团队里，"这个包是哪次出的"这个问题，出现的频率比"这个包怎么改"高得多。

原因也不难理解：改包往往是一个人的事，出包却是一群人的事。你自己关起门来改，改错了重来一遍就好；可包一旦发出去，它就同时出现在同事的手机上、合作方的电脑里、测试群的聊天记录中——每个人都握着一个不同的副本，而这些副本看上去一模一样。这时候"它是哪一次出的"就成了一个必须有人能回答的问题，而回答它的人，往往还不是出包的那一个。

先说边界：本文讲的打包标记与溯源，全部针对你自己拥有版权或已获授权的应用包——自研 App、公司内部工具、自己的内测版本。给自家出包留痕是正常的产品管理动作；请不要借此给他人应用植入任何标记，那属于另一回事，我们不建议也坚决不鼓励。

一、出包之后最常见的问题：这包是哪来的

先说三个我们真的遇到过的场面，你大概也遇到过其中一个。

这三个场面听起来像"管理问题"，但换个角度就知道它其实是一个关于文件的问题：APK 就是一个文件，文件名是你起的，改起来不用负责；文件内容里虽然有版本号，可你在同一天给同一个版本出了三次包，这三次在包里长得一模一样——包自己不知道自己是第几次出包的产物。

更麻烦的是，这个问题会随着"改包变快"而放大。过去改一个包要折腾小半天，一天顶多出一版，包少、记忆新，靠脑子就能管住；现在一句话改完、四步自动跑完，一天出三轮是常事，出得越多，版本之间的差别越细——可能只是某句文案、某个提示、某个图标的区别，肉眼根本看不出。这时候"我是谁、我从哪来"就不是哲学问题，而是每天都要回答的具体问题。

再补一个容易被低估的点：这个问题出现的频率，往往和你的出包速度成正比。以前手工改一个包要一两个小时，一天能出一版就不错了，包少自然不容易混；现在改一个包只要写一句话，打包四步自动跑完，"一天出三轮"成了常态——出得越快，越需要给每个包一个身份。这不是工具的副作用，恰恰是效率提升之后必须补上的一环：能快速产出，也要能快速核对。

所以解决方向很清楚：让包自己记住这件事。不是靠你记得改文件名，不是靠群里那句"这个是最新的"，而是让每一次出包都在包里留下一道痕迹——这道痕迹，就是接下来要说的打包标记。

二、传统留痕为什么不够用

当然，大家不是没想过办法。我们自己也用过下面这几种，全都在某个时刻掉过链子。它们的共同问题是：留痕跟包是分开的。

老办法	当时为什么用它	什么时候会失效
改文件名	最快，改完就看得见	包一旦被转发、被重命名、被下载工具加个 (1)，名字就断了；而且名字只在你这台机器上成立
旁边放一个 txt	能写很多说明，看着很规整	文件一移动就分家；别人只拿走 APK，说明就丢了
群里说一句	所有人当场都知道	聊天记录会被刷走、会过期、新人看不到；三天后没人愿意翻
靠记忆	出包的人当时确实记得	换人、请假、隔一个周末，记忆就作废了

这里要澄清一点：不是说这些办法不该用，而是它们不该被当成"唯一的留痕"。改文件名依然是好习惯，群里同步进度也依然有必要，问题在于它们都只是"人这边的记录"，一旦包离开了你熟悉的这台电脑、这个文件夹、这个聊天窗口，记录就断在了原地。真正靠得住的，是那份和包长在一起、拆不开的记录。

把这四种放在一起看，会得到一个很朴素的结论：留痕必须跟着包走。只要痕迹还留在文件名里、留在旁边的 txt 里、留在聊天记录里，它就随时可能和包分开；而只要痕迹写进了包里，谁拿到这个包，谁就能看到它是什么时候、在哪台机器上、用哪个账号出的。

这里还有一个"隐性成本"值得说透：留痕不完整带来的浪费，通常不是显性的返工，而是沟通成本的持续消耗。一个"这包是哪来的"的问题，平均要牵扯三个人：出包的人回忆、测试的人确认、使用的人重装；每传一次包，这个成本就再付一次。而它的解法偏偏很简单——把这件事交给流程，让包自己说。

这正好是"打包标记"要做的事。它不要求你改变任何习惯，也不需要额外维护一份台账——它就是出包流程里自动多出来的一步，而这一步恰好解决了一直以来最烦人的那个问题。

三、打包标记是什么：写进包里的一条 name="info"

在智改工坊里，每次出包前会自动往 res/values/styles.xml 写入一个 name="info" 的样式，内容是把时间、登录账号、机器码、机器名、系统用户名、程序版本、应用名、包名等信息编码后的标记。也就是说，只要这个包是从这台机器、这个账号、这一次出包流程里出来的，它的资源里就一定躺着一条对应的记录。

标记里包含	它能回答的问题
出包时间	"这是上午那轮还是下午那轮？"——一句话就能对上
登录账号	"这个包是谁出的？"——团队里多人轮流出包时尤其有用
机器码 / 机器名 / 系统用户名	"在哪台电脑上打的？"——排查"换台机器结果就不一样"这类问题时，第一眼要看的正是这几个
程序版本	"这个包是哪个版本的工坊出的？"——工具链升级前后出的包，行为可能不一样
应用名 / 包名	"这包真是我以为的那个应用吗？"——同名不同包的情况比想象中多

看到这里，很多人第一反应是"这不就是给包盖个章吗"。对，但它的价值恰恰在于不需要你额外做任何事：不用打开一个台账文件、不用记得改名字、不用在某处登记。你点一次打包，它就写一次；你想核对时，把包反编译开看一眼 res/values/styles.xml 里那条 name="info"，时间、账号、机器都在那儿。

它还有三个顺带的好处，是用了之后才慢慢体会到的：

1. 不会被文件名骗。文件可以被重命名成任何样子，但标记是写在包里的，跟着内容走；
2. 不需要额外维护。台账、登记表、备注都需要有人记得更新，标记是流程的一部分，你不写它会问；
3. 发出去也还在。包转发多少次，标记都不会掉——这一点在"两个团队各拿了一个包"的场景里特别关键。

小提示：标记写在包里的资源文件里，是一条普通样式条目，不参与业务逻辑；你平时完全不用管它，只在需要回溯的时候去看一眼就够了。另外，出包用的签名密钥是工作目录根目录下的 testkey.pk8 / testkey.x509.pem，需要换成自己团队的密钥时直接替换这两个文件即可——这两件事互不影响。

标记的三个常用场景

写完定义，说点实在的。这条标记我们平时真正会用到的地方，其实就三个：

1. 发之前自查：把包发给别人之前，先看一眼标记里的出包时间——确认自己发的是刚刚那一轮，而不是昨天桌面上剩下的那个；这一步只要几秒钟，却能挡掉最常见的低级事故。
2. 收反馈时定位：对方反馈问题，先要他的包。把包反编译开看一眼标记：时间对不对、账号是不是自己、机器是不是常用那台。多数情况下，看完标记就知道该不该往下查。
3. 交接时说明：把项目交接给同事时，让他自己去看标记和时间——"这个包是上周三下午出的，对应历史里第三条需求"，比口头描述"改过一些文案"要清楚得多。

三个场景有个共同点：它们都发生在"出包之后"，也都不需要打开任何额外的软件。标记是包自己带的信息，谁拿到包，谁就能看。这正是它比"旁边的 txt"高明的地方——不是记的东西更多，而是记的地方更对。

可能有人会问：那我在包里塞一个说明文件不就行了？理论上可以，但实操里会碰到两个问题：一是这种"额外塞进去的东西"很容易在后续的流程里被清掉或忘记维护，二是它需要你每次都记得做——而凡是需要"记得做"的事，迟早会有一次被忘掉。打包标记的思路不一样：它挂在出包这个动作上，你本来就要点打包，它就顺带写进去了。不需要额外的意志力，是它最实用的地方。

四、一条标记 + 几份留痕 = 可对齐的证据链

打包标记很强，但它不是孤军奋战。真正让"回溯"这件事变轻松的，是它和工作目录里本来就有的那几份留痕能互相对上。我们把它们列在一张表里，你会发现每份留痕都在回答一个不同的问题。

留痕	在哪	回答什么问题
项目目录	工作目录的 Project 下，每个项目一个 8 位随机字符串目录	这个包是从哪个项目里出来的、当时用的哪一份工程
source.apk	项目目录里自动拷的一份原包	改之前长什么样——想回到原点重来，不用再去找原始安装包
config.ini	项目目录里自动写入	这个项目的基本信息与启动页记录，装机拉起时会用到
history.ini	项目目录里，按"记录1、记录2"递增	这个包对应的是哪一条需求原文、什么时候提的——详情页里就能看到完整原文
ai_done.flag	AI 改完后留在项目目录	改动什么时候完成、是不是已经触发过自动打包
build 目录	unsigned.apk / aligned.apk / signed.apk	四步各产出了什么，哪一步的产物出了问题
pack.log	项目目录里，记录打包全过程	回编、对齐、签名、校验每一步的时间与结果
name="info" 标记	写进包里的 res/values/styles.xml	这个包本身是何时、由谁、在哪台机器上出的——跟着包走，永不分离

把这八行读一遍会发现它们其实分成两类：一类是"跟着工程走"的（项目目录、source.apk、config.ini、history.ini、build、pack.log），它们留在你这台电脑上，帮你回答"我当时做了什么"；另一类是"跟着包走"的（name="info" 标记），它随着包去到任何地方，回答的是"这个包本身是什么"。两类合起来，才既能解释过程，又能证明身份。只有前一类，包一发出去就断了线；只有后一类，你无法还原当时的来龙去脉。

这张表的用法是"两两对齐"。当你手上有一个包、心里有一个疑问，就把它和对应的那份留痕对一下：怀疑改错了版本，看 history.ini 里那条需求原文；怀疑打包没跑完，看 pack.log；怀疑手上这个包不是最新的，看标记里的时间。三个问题各查一处，通常两分钟之内就有答案，不用再展开一轮讨论。

顺带说一个常被问到的细节：打包四步里，前三步（回编、对齐、签名）只看进程退出码，只有第四步的 apksigner verify 会真正告诉你"到底签没签上"。这也是为什么流程里坚持多做一步 verify——签名这一步的性质决定了它不能靠"看起来没报错"来判断。有了这一步，pack.log 里的记录才是可信的，整条证据链才算闭环。

还有一个小小的防呆设计值得一提：项目删除只允许删 Project 的直接子目录。意思是你不会因为手滑，把整个 Project 或者某个深层目录一次清空——留痕这东西，最怕的不是没人看，而是被误删。

再往下说一层：这些留痕之所以可靠，是因为它们不依赖"你记得保存"。项目列表是直接读磁盘的，带搜索、能刷新，每条都可以编辑、看历史、删除；详情页里直接列出这个项目的修改历史，最新的排在最上面，每条显示序号、时间和你当时写的需求原文（完整显示，不截断），右侧一个「选择」按钮可以把那条需求填回输入框，方便"照上次那条再改一遍"。历史文件里是按"记录1、记录2"递增存的，你想删某一条就删对应那一节。这些设计看起来都是小东西，但它们叠在一起，才让"事后能查"这件事真的成立。

顺着"证据链"这个说法再补一句：链条的意义不在于每一环都完美，而在于每一环都还在。真实的工作现场从来不缺意外——反编译报了错、打包卡在某一步、包发出去之后才发现少改了一句——这时候你需要的不是"一切正常"的假象，而是"每一步都留下了痕迹"的踏实。痕迹在，就能复现；能复现，就能修。

还有一个细节值得单独提一下：反编译失败并不影响项目本身。配置、图标、源包都已经落地了，工具会提示原因并给出日志路径（apktool.log）。对于溯源来说这很重要——因为有时候你要回溯的正是"那次没跑成功的出包"，而它至少也留下了一份完整记录，不会变成一团空白。

五、实例一：自家「门店巡店助手」，两个内测包的三方对齐

「门店巡店助手」是我们自己团队做的内部巡店工具，只发给华东、华南两个区域的督导用。那天上午出了一轮，下午又出了一轮——第二轮改了两件事：把首页"巡店任务"的名字改成"门店打分"，顺带去掉了一个启动时的小提示。

这里先交代背景，因为它正是问题产生的土壤：同一个应用、同一个版本号、同一天、两次改动。包名没变、版本号没变、图标也没变，两轮产物的差别只在一行标题和一个小提示上。任何"看文件名"的办法在这种场景下都会失效——不是方法不够聪明，是信息根本不在名字里。

顺带说一下这一整套动作里"出包"是怎么完成的。打包四步是回编、对齐、签名、校验，产物分别是 unsigned.apk、aligned.apk、signed.apk，全都落在项目目录的 build 文件夹里；跑的时候窗口不给关，避免你以为它没在跑；跑完可以「保存 APK」——默认文件名就是应用名_版本号_signed.apk，也可以直接「打开所在文件夹」。出包之后如果想立刻看效果，工具会用 adb 找到手机或模拟器，把包装上并拉起应用，装完用 dumpsys 看一眼前台应用是不是它；手机可以走 scrcpy 投屏到电脑上看，模拟器则会把窗口提到最前面。

还有个小细节对我们这种"边改边看"的节奏帮助很大：AI 改包程序的窗口会吸附在主窗口右侧，两个窗口高度始终一致，宽度合计固定占屏幕工作区的 3/4。左边是项目和历史，右边是 AI 的执行窗口，中间不需要来回切换——出包时间、需求原文、标记信息，都在一眼能看见的范围内。

这件事最值得说的不是"省了多少时间"，而是它把一次可能的扯皮变成了一次查证。以前遇到这种反馈，你需要先说服对方"我这版真的改了"，再去纠结"是不是你装错了"；现在一句话就能收场：把包发来，看一眼标记。

六、实例二：给合作方做演示包，别让"旧包当新包"

第二个例子更贴近对外场景。我们给一家合作方做自家 App 的功能演示，三天里出了三版：第一版给对接人看流程，第二版按他们意见改了两处文案，第三版把演示用的账号信息换了一遍。

说到"演示"这个场景，还有一层现实：演示是给人留下第一印象的场合，出错的成本特别高。一次拿错包的现场演示，可能要花好几倍的精力去修补印象。而避免它的办法并不复杂——出门前花十秒钟，把要演示的那个包反编译看一眼标记时间，确认它就是最后一轮出的那个。这个动作小到可以忽略，但它挡住的是最不该发生的那类事故。

演示包这个场景还有个额外的麻烦：对方也会把包转给别人。对接人拿到之后转给他领导，领导又转给技术同事，传到第三个人的时候，谁也说不清这个包是第几版。以前遇到这种情况，我们只能再发一个"最新版"过去，谁都不知道中间到底发生了什么；现在只需要说一句"看包里的标记时间，比这个时间早的都不是最新的"，对方自己就能判断。

换个角度看，标记解决的其实是信任的传递问题。口头承诺"这是最新的"需要双方都记得住、都认得准；而写在包里的时间不需要任何人记住——它是事实，不是说法。外包、外协、跨部门协作里，这种"不靠人记"的凭据比任何说明都有用。

这一轮下来，我们最大的感受是："最新版"这个词在团队协作里其实是一句空话，除非它能被核对。以前它是靠信任维持的——你说最新就最新；现在它有据可查——标记里的时间戳、pack.log 里的记录、历史里的需求原文，三样东西摆在一起，谁都不用猜。

遇到的情况	以前（没有标记）	现在（有标记）
对方说"还有问题"	先争论，再让对方重装，实在不行重出一个包	看一眼标记时间，判断他拿的是哪一轮，一句话回复
桌面上一堆同名包	靠修改时间猜，猜错就要重做一次演示	每个包都能追回出包时间与出包账号，不用猜
交接给同事继续做	口头交接，靠记忆复述"改过什么"	历史里每条需求原文都在，点「选择」还能填回输入框
想回到最初的版本	到处翻原始安装包，还不一定找得到	项目目录里就有一份 source.apk，随时能回到原点

七、用户评价：大家真正在意的是"出了问题能不能查"

我们问过一些自研团队和内测负责人，他们提得最多的不是"标记有多炫"，而是"终于不用再靠记性了"。

除了上面这些，我们还收到过一些"用法是自己想出来的"反馈。有团队把它当成内测发放的核对动作：发之前把出包时间念给对方，对方收到后自己反编译看一眼标记，确认对得上再装；也有团队把它写进了内测规则里——"任何关于包的反馈，请先提供这个包的出包时间"，听上去有点严格，但确实把大量"是不是最新版"的无效沟通挡在了门外。工具提供了一种可能，怎么用它，各家有不同的答案，这也是我们最愿意看到的部分。

八、合规提醒与上手清单

在动手之前，还有一条"纪律"上的建议：尽量让所有出包都走同一条路径。标记之所以有用，前提是"每一个包都有"。如果有一次你图省事，绕开流程手工拼了个包发出去，那这个包就成了证据链上的一个断点——以后再看它，谁也说不清它经历过什么。统一起点、统一流程，比任何补救措施都有效。

最后是照例的上手清单，按顺序做一遍，你就拥有一条能自查的出包链路：

1. 先建项目：把自有或已授权的包拖进来，解析和反编译在后台跑，界面不卡；
2. 写清需求：把"改什么、留什么、怎么验"写成一段话，附件把对照材料一并带上；
3. 点一次「立刻修改」：原文进 history.ini，改完留 ai_done.flag，自动弹出打包窗口；
4. 让四步跑完：回编、对齐、签名、校验，产物落进 build，全过程记在 pack.log；
5. 出包自动带标记：时间、账号、机器码、机器名、系统用户名、程序版本、应用名、包名都在包里；
6. 发放时写清时间：告诉对方这一版的出包时间，让他自己也能核对；
7. 有问题先对齐：包发回来，看标记、对 pack.log、翻历史原文；
8. 要回原点：项目目录里的 source.apk 随时可用，删项目也别担心误删——只允许删 Project 的直接子目录；
9. 把时间写进交接说明："出包时间 + 对应哪条需求"两句话，比任何形容词都管用；
10. 养成看一眼的习惯：发之前看一眼标记、收回来再看一眼标记，两次加起来不到半分钟；
11. 把规则说给协作方：告诉对方"反馈问题请带上出包时间"，这条小规则能省掉很多来回。

最后提醒一句容易被忽略的纪律问题：标记的价值来自"每一次都写"。只要有一次你绕开流程手工拼了个包发出去，整条证据链就断了——以后再看那个包，谁也说不清它经历了什么。所以最省心的做法不是"需要的时候补一条"，而是"所有出包都走同一条路"：写需求、点一次、等四步跑完、从 build 里拿包。路径统一了，标记自然就全了。

如果你也希望出包这件事从此有据可查，可以先去「安卓修改大师智改工坊」的介绍页看看：https://www.apkeditor.cn/ai-version.aspx；官网 www.apkeditor.cn 上还有版本更新说明与更多使用技巧。把需求写成一句话，把出包交给流水线，把追溯留给时间戳。

本文所述操作均针对自有版权或已获授权的应用；文中应用实例与用户反馈已获授权并做脱敏处理。