主标语放在最显眼处：文件名是交付的一部分——谁的应用、第几版、签没签过名，理应一眼看完。改包改到最后一步，技术活已经干完；真正容易出岔子的，是"我发给同事的到底是哪一个文件"。

本文主角是「安卓修改大师智改工坊」：一款 Windows 桌面工具，把"改 APK"变成一句话——拖入安装包，用中文写需求，AI 改包，改完自动回编 / 对齐 / 签名 / 校验，一键装到手机或模拟器看效果。介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网 www.apkeditor.cn。今天我们只聊其中最容易被忽略、又最影响协作的一环：产物怎么命名、怎么发出去。

一、先看看"发错包"的现场

做过一阵子内部应用分发的人，大概都见过这样一份交付目录：巡检_最终版.apk、巡检_最终版2.apk、巡检_最终版(改好).apk、巡检_这次真的最终.apk。这不是笑话，这是很多人第一次做"改包分发"时的真实状态。

问题出在文件名没有携带信息。「最终版」三个字不告诉你是谁的应用、是哪个版本、能不能直接安装。等到三周后回头找"区域经理说登录页有问题的那一版"，只能在四个"最终版"里挨个试——时间就是这么被消耗掉的。

更麻烦的是发错版本。同一款应用可能同时有好几条线在跑：一条给一部做内测，一条给二部做试用。文件名不区分版本，发错几乎是必然的；而且要等对方装上、点开、觉得不对劲，才会回来问"你给我的是哪一版"。

一句话说清楚：交付事故里真正的技术故障很少，绝大多数都发生在"人"这一侧——拿错文件、发错版本、说不清是哪一版。而这三件事，一个规规矩矩的文件名就能带走大半。

二、拆开看：应用名_版本号_signed.apk 三段各管什么

智改工坊打包结束后点「保存 APK」，默认给出的文件名是这样的：应用名_版本号_signed.apk。三段用下划线连接，看着朴素，但每一段都有明确分工。

段位	回答的问题	为什么这样定
应用名	这是谁的应用	来自建项目时 aapt 解析出的应用名，与你设备上看到的名字对得上，不依赖内部代号
版本号	这是第几版	同样来自解析结果，与包内版本信息一致，多个包放一个文件夹里也分得清
signed	这个包能不能直接装	打包目录里同时存在未签名与已签名产物，后缀把"可以直接装"的那一个单独标出来

三段的顺序是从粗到细：应用名先定位是哪款应用，版本号在同一款应用里区分批次，signed 是最后一层"能不能直接用"的状态标识。而且它不依赖任何额外说明文档——发到群里、邮件里、U 盘里，信息都还在。

三、为什么是版本号，而不是"最终版"或时间戳

有人会问：用时间戳命名行不行？用"日期+序号"呢？都能用，但在多版本并存的场景里各有短板。把三种常见思路摆开对比一下就清楚了。

• "最终版 / 最终版2 / 最终版(修)"。没有结构化信息，还自带"下一次又会推翻"的暗示，名字里没有版本概念，无法跟应用内部版本号对上。
• 纯时间戳，比如 20260512_1430.apk。时间很精确，但打开包依然不知道它是哪一版内容。它回答的是"什么时候出的"，不是"第几版"。
• 应用名_版本号_signed.apk。版本号与包内信息一致，"名字里的版本"与"装到手机上看到的版本"能对上；后缀又把签名状态说清楚。信息量最完整，同时又最短。

说到底，版本号是唯一一个"包内包外都能对得上"的标识：你在设备上看到的版本是它，在文件名里看到的也是它。出现"这版到底装没装上"的疑问时，两边一对，结论立刻出来。这些信息也不用手动记：建项目时工具就用 aapt 解析出图标、应用名、包名、版本号、最低与目标 SDK 与启动页，解析与反编译跑在后台线程，界面不卡。

四、一次打包，为什么会有三个产物

signed 这个后缀值得单独占一段，是因为一次打包其实产出三样东西。智改工坊的打包是四步连着走的：回编（apktool b）→ 对齐（zipalign -p 4）→ 签名（apksigner + testkey）→ 校验（apksigner verify）。全过程写进项目目录的 pack.log，产物落在项目的 build 目录里。

产物	处在哪一步 · 能不能装
build\unsigned.apk	回编完成，还没对齐、没签名，装不上
build\aligned.apk	对齐完成，还没签名，装不上
build\signed.apk	签名并通过校验，能装，就是交付用的那一个

三个文件的体积可能很接近，图标也一样，肉眼分不出差别——这就是 signed 后缀存在的全部理由：让"能装的"和"不能装的"在文件名上分开。否则你把 unsigned.apk 发给同事，他装不上，然后你们花半小时讨论"是不是包改坏了"，而真正的原因只是发错了文件。

最后一步的校验也值得说一句：前三步只看退出码，退出码为 0 不代表签名真的写进去了；"到底签没签上"要 apksigner verify 说了算。所以四步里刻意多留了一步 verify，校验通过才会把 signed.apk 视作可交付产物。命名口诀：名字里要有"谁、第几版、签没签"。

五、多版本并存时，靠什么不拿错

文件名只是第一道防线。真正让"多版本并存"变轻松的，是背后这一整套结构——下面几条，都是智改工坊已经在替你做的事。

• 每个项目一个独立目录。目录名是 8 位随机字符串，项目之间物理隔离、互不覆盖；目录里自动写好 config.ini 并保留一份 source.apk。哪怕反编译失败项目本身也不会坏——配置、图标、源包都已落地，工具会提示原因并给出日志路径 apktool.log，source.apk 就是随时可回的干净起点。
• 历史记录写需求原文。点「立刻修改」时，需求原文与修改日期写进 history.ini；详情页列出修改历史（最新在最上），每条显示 #序号 + 时间 + 完整需求原文，不截断。想照上次再改一遍，点右侧「选择」把需求填回输入框即可。
• 每个包自带一枚"打包标记"。每次出包前，工具自动往 res/values/styles.xml 写入一个 name="info" 的样式，内容是把时间、登录账号、机器码、机器名、系统用户名、程序版本、应用名、包名等编码后的标记。拿到包，来源有据可查。
• 打包过程全量留痕。四步的每一步都写进 pack.log；出问题时先看日志，再谈怀疑。

把这些放到一起，一个"多版本并存不拿错"的工作流就成型了：项目目录做隔离，文件名做标识，打包标记做溯源，历史记录做对账。四层下来，几乎不会再出现"这是哪一版"的争论。

六、两个自家应用的交付实例

讲规范不如讲动作。下面两个例子都是我们自己的应用，恰好代表"多版本并存"最常见的两种麻烦。

七、用户评价、合规提醒与结语

把全文收一下：默认的 应用名_版本号_signed.apk 把"谁、第几版、签没签"压进一个文件名；三个产物摆在一起时，后缀让能装的那一个自己站出来；多版本并行时，项目目录、打包标记、历史记录再补上三层层保险。文件名是交付的一部分。

产品是安卓修改大师智改工坊，介绍页：https://www.apkeditor.cn/ai-version.aspx；官网 www.apkeditor.cn。想验证这套规范顺不顺手，最直接的方式是拿一个自家的包跑一次：拖入安装包 → 中文写一句需求 → 看它自动回编 / 对齐 / 签名 / 校验 → 收下那个名字规规矩矩的 signed.apk。