把改包过程做成可复查的交付档案：日志、历史、签名指纹

很多新手把“改完能装”当成终点：APK 能装到手机上，图标出来了，名字也变了，就觉得交付完成。等到一周后客户说“上次那个版本有个问题，你帮我改回来”，或者同事在群里问“现在测试的是哪一版”，你打开文件夹，看到三个都叫“成品”的 APK，时间戳还差不多，就很难给出一个干脆的答案。

改包本身并不神秘，它是一次有输入、有处理、有输出的工程活动。输入是原始 APK 和一句明确的需求，处理是反编译、修改、回编、对齐、签名，输出是新的 APK，以及一份能解释“它从哪来、改了什么、由谁签出”的记录。前几步智能修改电脑版已经替你做了，最后这一步“留痕”，需要你主动补上。

交付档案不是给工具看的，是给未来的自己、给客户、给接手项目的同事看的。它至少要能回答四个问题：

1. 这个包是从哪个原始 APK 改出来的，原始包还在不在。
2. 这一版提了什么需求，需求原文是什么，谁在什么时候确认的。
3. 打包过程有没有报错，签名用的是哪把密钥，证书指纹是什么。
4. 成品装到哪台设备上试过，看到的结果和需求是否一致。

能回答这四个问题，档案就及格了。剩下的篇幅，会把每一个环节拆开，告诉你文件在哪、怎么看、记什么、怎么验证。即使你以前只会拖一个 APK 进去点按钮，也可以照着顺序做下来。

档案的价值不在厚，而在能对上号：一个包、一条需求、一份日志、一枚指纹，四样东西能互相对上，就够了。

图 1：交付档案不是一堆文件，而是一条能互相对上的证据链。

为什么交付要留档案：三个最容易说不清的瞬间

第一个瞬间是版本对不上。客户要的是上周三那版，你发的是昨天顺手又改的那版，两个包都叫“成品”，只能靠聊天记录猜。猜错一次，就要重新打包、重新签名、重新安装，时间全花在返工上。

第二个瞬间是签名来源不明。用哪把密钥签的，往往只有当时那台电脑知道。等到要发更新，发现找不到密钥，或者同事用了默认签名，新包就装不上去，只能让用户卸载重装，本地数据也跟着丢。签名不是打包的最后一步装饰，它是应用能否被系统当成“同一个应用”的关键。

第三个瞬间是改动范围说不清。客户问“你到底改了哪几处”，你只能凭记忆列，漏了一处，验收时就变成扯皮。更麻烦的是，有些改动是资源替换，看起来没有代码变化，实际却影响了启动页和页面文案，没有记录就很难复查。

以前的做法，是在桌面上建一个“最终版”文件夹，再建“最终版2”“最终版-改”“最终版-真的改”。这种命名靠人的记忆维持，换一个人就断线。现在的做法，是让工具把过程写进项目目录，再由你把这些文件整理成固定的交付结构。验证方式也很简单：随便抽一个成品，两分钟内说清它的原始包、需求原文、打包日志和签名指纹，说不清就说明档案缺东西。

本文所有操作都在 Windows 10/11 64 位环境里完成，使用智能修改电脑版。它把反编译、回编、对齐、签名和校验串成一条流水线，项目目录里会自然留下配置文件、需求历史、原始包、工程目录、成品和日志。我们要做的，是认识这些文件、读懂它们，再把它们整理成别人也能看懂的档案。

合规先说在前面：本教程只讨论自有版权或已经获得授权的应用。请勿用于破解、绕过付费、去除他人应用的限制，也不要修改来源不明的商业软件。改包能力本身是中性的，用它做什么，取决于授权边界。给客户做交付时，最好把授权说明也放进档案，哪怕只是一封邮件截图或一句书面确认。

如果你只是给自己改一个图标，档案可以简化；一旦涉及交付，哪怕接收人只是同组同事，也建议按本文的结构走一遍。因为返工的成本，永远比留档高。一个二十兆的安装包，复制一份只要几秒；重新找回一周前的需求原文，可能要翻半小时聊天记录。

还有一点要提前说清：档案里的“历史”不是工作日志，不需要写“今天研究了半天”。它只记录可核对的事实：什么时候、对哪个包、提了什么需求、得到什么结果。形容词越少，复查时越好用。

只需说话，就能让应用变成你想要的样子——这句话说的是操作方式；而交付档案，说的是这份结果能不能被信任。两者合在一起，才是一次完整的改包交付。

先认清项目目录：一个项目一个八位目录

第一次打开智能修改电脑版，先别急着把 APK 拖进去。点开参数设置，看一眼工作目录。程序会按 D→E→F→G→C 的顺序自动挑盘，选第一个可读写、剩余空间不少于 1GB 的盘。工作目录下有两个子目录：tools 放工具链，Project 放项目。把这件事弄清楚，后面的日志和成品才找得到。

每导入一个 APK，Project 下会新建一个 8 位随机字符的目录。名字看起来像乱码，但这正是它的优点：不会重名，不依赖应用名，也不会因为中文名或空格在命令行里出问题。目录里的常见内容，可以按下面这张表理解。

文件或目录	作用	交付时怎么处理
config.ini	项目的基本配置与入口信息	随项目保留，不必给客户
history.ini	每次提交的需求原话与日期	复制一份作为需求证据
source.apk	导入时的原始包	保持不动，单独归档
apktool 目录	反编译得到的工程目录	内部留存，按需清理
build 目录	回编产物与签名后的成品	只取最终成品
apktool.log	反编译过程的输出	随日志一起归档
pack.log	打包四步的完整记录	必须归档
ai_done.flag	AI 完成一次修改后的信号文件	程序读到即删，无需归档

source.apk 是导入时的原始包，建议永远不要覆盖。它有两个作用：一是对照，改坏了可以重新来；二是证明，交付时能说清“从哪个包改的”。如果原始包本身会被替换，宁可新建一个项目，也不要在旧项目里覆盖。覆盖之后，history.ini 里的需求还在，但“改前样本”没了，复查链条就断了一半。

apktool 目录是反编译出来的工程，AI 的修改就落在这里。build 目录放回编产物，既有未签名的包，也有签名后的成品。apktool.log 记录反编译输出，pack.log 记录打包四步。ai_done.flag 只是 AI 完成一次修改后的信号文件，主窗口每 2 秒轮询一次，读到就删，不需要归档。

交付时不要把整个 Project 目录打包发给客户。原因很实际：里面有工具链路径、临时文件、未签名包，体积大，还夹着内部信息。正确做法是在 Project 之外另建一个交付目录，只放最终成品、日志、需求历史和验收记录。项目目录是工作现场，交付目录是展厅，两者不要混。

还有一个容易被忽略的小习惯：导入前，把原始 APK 的文件名、大小、来源、获取日期记在交付说明里。来源可以写“客户提供”“内部构建”“由客户授权后从其官网下载”等。这句话在出现争议时，比任何聊天记录都直接。

图 2：工作现场与交付展厅分开，项目目录只负责生产，交付目录只负责证明。

找项目的顺序也固定下来，养成肌肉记忆：

1. 打开参数设置，确认当前工作目录落在哪个盘。
2. 进入 Project，按修改时间排序，最近的排在最前。
3. 点进 8 位目录，先看 config.ini 确认应用名和包名。
4. 回到主界面的项目列表，用历史记录对照需求，不要只凭目录名猜。

项目列表能看到每个项目的历史，也能删除项目。删除只允许删 Project 的直接子目录，这是一个安全边界。它同时提醒我们：归档要在删除之前完成。改坏的项目可以先留着，等成品验收通过、档案齐全，再清理。清理时也只删目录，不要手动去删 tools 里的工具链，否则下一次打包会找不到命令。

如果你经常做同类项目，可以在 Project 之外维护一个“模板目录”，里面放空的 01_源包、02_需求、03_日志、04_成品、05_验收。每次交付复制一份，改个名字就能用。模板不要放进 Project，免得被当成项目误删；模板里也不要放任何真实密钥或客户资料，保持空白最安全。

目录认清楚之后，你会发现后面所有工作都有落点：需求进 history.ini，过程进两份日志，结果进 build，证据进交付目录。接下来从需求开始，把“原话”这件事讲透。

history.ini 只留原话：需求怎么写才可复查

history.ini 的规则很简单：只留你的原话，加上日期。它不记录 AI 的回复，也不记录工具做了哪些步骤。这个设计看似“信息少”，其实很重要——它保证历史里保存的是人的意图，而不是机器的解释。以后回看时，你能准确知道当时要求了什么，而不会被一段自动生成的总结带偏。

点“立刻修改”时，输入框里的原文和日期会写进 history.ini，需求同时送进右侧 AI 工作区执行。详情页的历史最新在上，显示完整原文，右侧有“选择”可以把旧需求回填到输入框。项目列表里也能看历史。这个设计对复查很友好：你不需要翻聊天记录，只要打开项目，就能看到每一次要求的原话。

因为只留原话，原话的质量就决定了档案的质量。新手最常见的写法是“帮我美化一下”“改得好看点”，这类话在当时能理解，过两周就变成谜语。可复查的需求至少包含四件事：对象、位置、期望、验收。四件事不必写成公文，但一定要具体到别人照着做也不会做错。

1. 对象：改哪个应用、哪个页面、哪个资源，最好带上包名或项目名。
2. 位置：图标、应用名、启动页、首页横幅、网页地址、主题色，点到具体位置。
3. 期望：改成什么，给出文案、色值、图片文件名，不要只说“高级一点”。
4. 验收：装好之后看哪里，怎么判断成功，失败时保留什么现象。

对比两个例子，差别很明显。差的写法是：“把首页改一下，颜色好看点，顺便把名字也换了。”好的写法是：“把应用名改成‘青禾记事 内测版’；首页顶部横幅换成附件 banner-1021.png；主色从蓝色改为 #2E7D5B；启动页背景用同色；装好后检查桌面名称、启动页颜色和首页横幅三处。”后者可能多打三十个字，却能让 history.ini 在三个月后仍然可读。

模糊写法	可复查写法	差别在哪
美化一下界面	首页背景换成浅米色，按钮圆角加大，标题字号保持原样	有对象、有范围、有保留项
名字改一下	把桌面显示名改为“青禾记事 内测版”，包名不动	明确改哪里、哪里不改
接口换成正式的	把设置页里的接口地址从测试域名改为内网正式域名，保留端口	有新旧对照和保留条件
加个内测标志	启动页底部加一行“内部测试版”文字，颜色白色，不遮挡图标	有位置、有内容、有约束

智能修改电脑版内置了 3000 条话术，分 6 类、每类 500 条，点选就能填入输入框。话术的作用是帮你把口语变成可执行的描述，不是让你偷懒只点一句。点进去之后，仍然要把自家应用的具体页面、具体文案补上。话术是骨架，你的项目信息才是血肉。

附件也要留说明。一次可以多选文件，但每个文件都要写用途，且不少于 10 个字。程序会校验文件是否存在、不是目录、不是 0 字节、可读，然后把“序号 + 路径 + 说明”拼在需求后面一起发出。这个校验看似琐碎，实际能挡掉很多低级错误：附件没选上、路径是快捷方式、图片是空文件，都会在提交前被拦下来。

这里有个细节：history.ini 只留原话，附件路径和说明不会写进历史。所以附件多的项目，建议在项目外的交付说明里另记一份清单，写清每个附件的文件名、用途、尺寸和来源。否则三个月后你只看到需求里说“用附件里的图”，却不知道当时附的是哪一张。

需求写完后，点“立刻修改”，AI 完成后会在项目目录留一个 ai_done.flag，主窗口每 2 秒轮询一次，读到就删，最长等 1 小时。这个标记只是流程信号，不是交付物。真正要归档的是 history.ini 里的原话，以及你自己补的“需求说明”。需求说明不用长，半页纸即可：客户是谁、授权范围、改哪几处、哪些地方明确不动。

把需求写成“别人照着做也不会做错”的样子，history.ini 才有复查价值。原话不是随口一说，而是交付链条的起点。

图 3：一句可执行的原话，胜过十段事后的解释。

还有一条实用建议：重要项目的第一条需求，先写“边界”，再写“改动”。比如“本次只改应用名、图标、启动页和首页横幅，包名、权限、登录逻辑、支付流程全部保持原样”。这句话会作为第一条历史留下，后面无论谁接手，都能先看到“不许动什么”。边界清楚，验收时也更容易判断有没有越界。

需求确认之后，就可以进入打包。打包过程会写进 pack.log，四个步骤一环扣一环，下面逐段拆开。

pack.log 四步：从 apktool b 到 apksigner verify

打包不是“点一下就完”，它内部按固定顺序走四步。每一步都可能失败，pack.log 把每一步的命令、输出、错误都记下来。读懂这四步，你就有了排查问题的地图；读不懂也没关系，至少要知道每一步成功时应该看到什么，失败时先去哪一行找原因。

1. 回编：用 apktool 把工程目录重新编译成未签名的 APK，输出到 build 目录。
2. 对齐：用 zipalign 按 4 字节边界对齐资源，让系统读取更高效。
3. 签名：用 apksigner 写入签名，按设置生成 v1、v2、v3 或 v4 签名。
4. 校验：再用 apksigner verify 读回证书，确认签名真的写上了。

apktool b -f -o build\unsigned.apk
zipalign -f -p 4 build\unsigned.apk build\aligned.apk
apksigner sign --ks 自己的密钥.jks --out build\release.apk build\aligned.apk
apksigner verify --print-certs build\release.apk

第一步回编，成功时 build 目录会出现 unsigned.apk。这一步最怕两类错误：资源引用找不到、smali 语法不对。apktool.log 会给出文件和行号，先看最后几十行，通常原因就在那里。12 MB 左右的包实测约 3 秒反编译；如果超过 10 分钟，程序会中断并报错，这时不要硬等，先检查环境是否完整。

第二步对齐，-p 参数表示按页对齐共享库，4 表示 4 字节边界。对齐后的包通常和未对齐包大小接近，但内部偏移变了。未对齐的包有时也能安装，却可能在部分设备上更耗内存，或者被应用市场拒收。所以这一步不能省，也不要用“能装就行”来判断。

第三步签名，工具支持四种方式：默认签名、JKS 或 keystore、PEM 加 PK8、随机签名；签名方案支持 v1、v2、v3、v4，默认写入 v1、v2、v3。密钥口令走环境变量，不拼进命令行，也不写进日志。这个细节很关键：命令行会被日志记录，如果口令直接写在命令里，等于把钥匙贴在档案上。

第四步是最容易被忽略的一步。很多工具签完就结束，这里多跑一次 verify，是为了确认“到底签没签上”。密钥格式错误、别名不对、口令错误，有时在签名阶段只给一个含糊的结果，verify 会明确报出来。pack.log 里这一段的输出，就是交付档案里的“签名体检结果”。没有它，你只能说“我点过签名”，不能说“这个包确实带着有效签名”。

步骤	成功时看什么	常见失败	处理方向
回编	build 目录出现 unsigned.apk	资源找不到、语法错误	按 apktool.log 的文件行号定位
对齐	生成 aligned.apk，无报错	找不到命令、路径含空格	检查工具链体检，路径加引号
签名	生成 release.apk	密钥格式、别名、口令错误	用密钥工具核对别名，口令走环境变量
校验	Verifies 通过，方案为 true	未签名、方案缺失、证书链异常	回看签名步骤，换密钥格式重试

日志里还有 apktool.log，记录反编译输出。它和 pack.log 分工不同：前者管“改得进去”，后者管“打得出来”。遇到回编失败，先看 apktool.log 的末尾；遇到签名失败，先看 pack.log 的第三、四步。不要把两份日志混着看，否则容易被无关的警告带偏。

pack.log 不要只留在项目里。交付时把它复制到“03_日志”目录，文件名带上版本号，例如 pack-v1.2.3-20261021.log。日志是纯文本，体积小，价值高。客户不需要看懂每一行，但需要知道这份日志存在，并且能和成品对上。

打包成功后，程序还可以自动找设备、装包、拉起应用，并用系统状态复核前台页面；手机走投屏预览，模拟器提到最前。这些动作方便验收，但不会自动变成档案。验收时看到的画面、设备型号、系统版本，仍然要你自己记下来。

签名指纹：用 apksigner verify 的证书指纹做身份条码

APK 的签名证书有一枚指纹，通常看 SHA-256。它不是 APK 文件的哈希，而是证书的哈希。文件重新打包、换一个图标、改一行文案，只要还用同一把密钥签，证书指纹就不变；反过来，换了密钥，指纹一定变。交付档案里记下它，等于给这个应用的“签名身份”留了一个条码。

verify 的典型输出像下面这样。不同版本的 apksigner 字段顺序可能略有差异，但核心信息一致：有没有验过、用了哪些方案、签名者证书是谁、指纹是多少。

Verifies
Verified using v1 scheme (JAR signing): true
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): true
Signer #1 certificate DN: CN=Qinghe, OU=Delivery, O=Example
Signer #1 certificate SHA-256 digest: 3f9a...（完整 64 位十六进制）
Signer #1 certificate SHA-1 digest: ...
Signer #1 certificate MD5 digest: ...

字段	含义	档案里怎么用
Verifies	校验命令的整体结论	必须为通过，否则成品不算完成
v1、v2、v3	各签名方案是否验证成功	记下具体为 true 的方案
certificate DN	证书主体信息	确认是不是自家或客户指定的证书
SHA-256 digest	证书的唯一指纹	跨版本比对，判断能否覆盖升级

看输出时先看 Verifies 和三个 true。如果 v2 或 v3 是 false，先别急着交付，回看签名参数是不是只写了 v1。然后把 SHA-256 digest 完整复制下来，共 64 位十六进制。大小写不影响比对，但档案里要统一：要么全大写，要么全小写；冒号分隔符要去掉。很多人从屏幕复制时带上了空格或换行，下一次比对怎么都不一致，问题就出在这里。

签名方式四选一，各有适用场景。默认签名适合自用和临时预览；正式交付建议用团队或客户提供的 JKS、keystore。原因很实际：Android 只允许同签名的包覆盖安装，后续升级必须用同一把密钥。PEM 加 PK8 适合已经有一对密钥文件的情况；随机签名适合一次性演示，不适合长期维护。选错方式，包本身可能没问题，但下一次升级就会卡住。

密钥保管有三条底线。第一，密钥文件不随 APK 一起发给客户，交付包里只放成品、日志、哈希和指纹，不放密钥。第二，口令走环境变量，不写进命令行、不贴到聊天记录、不放进交付说明。第三，档案里只记指纹、别名和证书主题，不记口令。做到这三条，即使交付包被转发，别人也无法用你的身份继续签包。

验证方法很直接：对旧版和新版分别执行 verify，比对 SHA-256 指纹。一致，说明可以覆盖升级；不一致，要提前提醒客户先备份数据再卸载安装。如果客户自己指定了证书，交付前把指纹发给对方核对，让对方确认“这就是我们家的证书”，比交付后解释半天更省事。

指纹是签名的身份证，哈希是文件的身份证，两者不能互相替代。下一节把文件哈希、大小和命名放在一起讲，因为它们共同决定“这个包是不是你以为的那个包”。

APK 哈希、大小与文件命名：给成品做一张体检单

哈希解决“文件有没有被换过”，大小解决“是不是漏了资源”，命名解决“这是哪一版”。三件事加起来，才是一个能自证的成品。它们都不难，难的是每次都做。把它们写进交付模板，变成固定动作，就不会漏。

Windows 自带 certutil，不用装额外工具。打开命令提示符，把路径换成你的成品路径，执行下面这一行。输出会给出 SHA-256 的哈希值，以及“CertUtil: -hashfile 命令成功完成”的提示。

certutil -hashfile D:\交付\JZAssistant-v1.2.3-123-CustomerA-20261021.apk SHA256

如果你习惯用 PowerShell，也可以用 Get-FileHash，结果等价。命令更长一点，但方便把结果直接导成文本。两种方式算出来的值必须一致，如果不一致，先检查是不是拿错了文件，而不是怀疑算法。

Get-FileHash -Algorithm SHA256 "D:\交付\JZAssistant-v1.2.3-123-CustomerA-20261021.apk"

把结果记下来，连同文件大小。大小建议同时记字节数和约数，例如 13,245,678 字节，约 12.6 MB。只记“12.6 MB”不够精确，因为不同工具显示的单位和四舍五入方式不同；只记字节数又不好读。两个都写，验收时一眼就能判断是不是同一个文件。

字段	示例	说明
文件名	JZAssistant-v1.2.3-123-CustomerA-20261021.apk	应用标识、版本、渠道、日期齐全
版本	versionName 1.2.3，versionCode 123	两个都要记，系统只认后者
大小	13,245,678 字节，约 12.6 MB	和源包对比，判断资源是否异常
SHA-256	3F9A 开头的一组 64 位十六进制（示例）	文件指纹，用于传输后核对
签名指纹	verify 输出里的 SHA-256 digest	证书身份，用于升级核对
构建时间	2026-10-21 14:32	和日志、聊天记录对时间线

示例表里的哈希是占位内容，不要照抄。真正要记的是你自己算出来的值。复制哈希时容易带上换行和空格，记完最好再算一次，确认两次一致。文件一旦被重新打包，哪怕只改了一个像素，哈希都会变，所以哈希必须和成品同时生成，不能拿旧值凑数。

文件命名建议用固定格式：应用标识-版本名-版本号-渠道-日期-签名标识.apk。全部使用半角字母、数字和连字符，不用空格、括号、中文标点。这样在命令行、网盘、聊天工具和跨系统传输时都不容易出问题。日期用八位数字，例如 20261021，按年、月、日排列，文件排序天然就是时间顺序。

JZAssistant-v1.2.3-123-CustomerA-20261021-ownkey.apk
JZAssistant-v1.2.4-124-Internal-20261028-ownkey.apk
JZAssistant-v1.2.5-125-Release-20261105-ownkey.apk

命名不要用“最终”“最新”“修改后”这类词。它们今天是真的，明天就过期。也不要用“新建文件夹”“副本”这种系统默认名，过一周谁也认不出来。如果担心文件名太长，可以缩短应用标识，但版本号、渠道、日期这三段不要省，它们是排错时最常用的线索。

大小也要看一眼。源包 12.4 MB，成品 12.6 MB，通常正常，因为替换的图片、资源和签名块会带来少量变化。如果成品突然变成 6 MB，或者涨到 30 MB，先别交付，打开 build 目录确认是不是拿错了包，或者资源被重复打包。大小异常往往比报错更早暴露问题。

还有一个细节：签名后的 APK 不能再改。只要用压缩工具往里塞一个文件，签名就会失效，安装时可能被拒绝，或者 verify 直接报错。所有修改都应该在工程目录里完成，再走回编、对齐、签名。把这条规则写在交付说明里，能避免客户“顺手换个图标”导致包坏掉。

图 4：哈希、大小和命名，构成成品的体检单。

哈希、大小、命名都齐了，还差一条“版本与渠道”的对应关系。下一节把这条线接上，让文件名、版本号和分发对象三者一致。

版本与渠道对应：别让 versionCode 说谎

versionName 是给人看的，versionCode 是给系统看的。覆盖安装时，系统只认 versionCode，必须比已安装的大。哪怕你只改了一个图标，只要这个包要发出去，versionCode 就应该加一。复用旧版本号，会出现“装不上”“装完还是旧界面”的怪现象，最后浪费的是排查时间。

渠道是“这个包给谁、从哪条路径发出去”。渠道不一定改代码。很多渠道包内容完全一样，只是分发给不同对象；这种情况在文件名和交付清单里标清楚即可。只有确实需要不同接口地址、不同启动页、不同文案时，才在需求里写明白，并让 versionCode 独立递增。

渠道	用途	包名	签名	文件名标识
内测	团队自测、功能验证	与正式一致	团队密钥	-beta
客户验收	客户确认效果	与正式一致	客户或项目密钥	-customerA
正式	官网、应用市场、正式分发	与正式一致	正式密钥	-release
演示	展会、售前展示	可加后缀区分	一次性密钥	-demo

给已授权应用改包，不要随意改包名。包名是应用的身份证，改了会影响推送、登录、数据迁移和覆盖安装。确需改包名时，先在测试设备上验证登录、缓存、文件目录和升级路径，再把结果写进验收记录。包名一栏建议在交付清单里单独列出，写成“改前”和“改后”两列，空着也比含糊强。

维护一张版本对照表，一行一个交付版本。字段不用多：versionName、versionCode、渠道、需求摘要、签名指纹前八位、成品哈希前八位、交付日期、接收人。前八位足够日常比对，完整值放在各自的体检单里。这样有人问“客户 A 上次装的是哪版”，你查一行就能回答。

versionName	versionCode	需求摘要	渠道	交付日期
1.2.2	122	换图标、改应用名	内测	2026-10-12
1.2.3	123	首页横幅、网页地址	客户验收	2026-10-21
1.2.4	124	主题色、内测标识	内测	2026-10-28

以前的做法，是文件名写“最终版2”，版本号靠记忆，渠道靠聊天记录。现在的做法，是命名规则加对照表，工具负责生成，人负责填表。验证方式：随机抽一个成品，三十秒内说出它对应哪条需求、哪个渠道、哪把密钥。说不出来，就回到命名和对照表补课。

版本线清楚之后，就可以进入两个具体实例。一个是给客户的授权交付，一个是团队内部的版本归档。两者的目录结构相似，但侧重点不同：前者重“证明”，后者重“可追溯”。

实例一：给客户授权应用的交付包

场景设定：客户拥有“青禾记事”这款展示类应用的完整版权，书面授权你做三处修改——把应用名改成“青禾记事 内测版”，把首页横幅换成新活动图，把应用内网页入口指向客户自己的活动页。包名、权限、登录流程都不动。这是典型的授权改包，边界清楚，适合拿来练交付档案。

以前怎么做：在命令行里反编译，手动替换图片和字符串，回编后凭经验选签名，成品放在桌面，文件名写“青禾-新”。客户问改了哪里，就翻聊天记录截图；问签名对不对，只能说“应该没问题”。一旦客户把包转给同事，同事再装到旧版本上失败，问题就会绕一圈回到你这里。

现在怎么做：把客户给的原始 APK 拖进智能修改电脑版，等 aapt 解析出图标、应用名、包名、版本和启动页，确认信息无误再建项目。进入详情页，把三处要求写成一段可执行的原话，附上新横幅图片，文件用途写清楚，点“立刻修改”。AI 在右侧工作区完成后，项目目录会出现完成标记，主窗口轮询读到即删。接着打包，四步走完，verify 通过，成品落到 build 目录。

1. 核对源包：记录文件名、大小、SHA-256、来源和客户授权日期。
2. 写需求：应用名、横幅位置、网页地址、明确不动的部分，一次写全。
3. 打包：回编、对齐、用客户提供的密钥签名、verify 读回证书。
4. 自检：装到一台测试机，检查桌面名称、启动页、横幅和网页入口。
5. 算哈希：对成品执行 certutil，记录 SHA-256 和字节数。
6. 整档案：按 01 到 05 的目录结构复制文件，填写交付清单。
7. 发交付：只发交付目录，不发项目目录，不发密钥，不发口令。

交付目录建议固定成下面这个样子。名字可以换，层级不要乱。客户收到压缩包，打开第一层就知道先看什么。

交付_客户A_20261021/
  01_源包/
    source-original.apk
    源包信息.txt
  02_需求/
    history-20261021.ini
    需求说明.txt
  03_日志/
    apktool-20261021.log
    pack-20261021.log
    verify-20261021.txt
  04_成品/
    JZAssistant-v1.2.3-123-CustomerA-20261021.apk
    成品体检单.txt
  05_验收/
    安装记录.txt
    截图/

01 目录放原始包和来源说明。来源说明不用长，写清客户名称、授权方式、原始包从哪来、导入日期。02 目录放 history.ini 的副本和一份需求说明。history.ini 是工具写的，需求说明是你写的，两者互相补充：前者是原话，后者解释背景和边界。03 目录放两份日志和 verify 的输出，verify 输出可以直接重定向成文本，方便客户用记事本打开。

04 目录只放最终成品和体检单。体检单包含文件名、版本、大小、SHA-256、证书主题、证书 SHA-256 指纹、构建时间。05 目录放安装记录和关键页面截图。截图不要只拍桌面图标，至少三张：启动页、改动页面、关于或版本信息页面。这样客户不安装也能先看一眼改成了什么样。

图 5：交付包的五个目录，对应五类证据，缺一类都不完整。

验证分两层。第一层是工具层的验证：pack.log 四步都有成功记录，verify 输出 Verifies 通过，v1、v2、v3 至少 v2 为 true，成品哈希和体检单一致。第二层是使用层的验证：把成品装到测试机，用 am start 拉起主界面，确认前台应用确实是它；看桌面名称、启动页、横幅、网页入口四处；再进系统设置看应用版本号，和体检单对上。

客户验收时，最容易忽略的是“旧版覆盖安装”。如果客户手机上已经装了旧版，你要先确认新旧包的签名指纹一致，再让客户直接覆盖安装。指纹不一致，安装会被系统拒绝，客户会以为包坏了。提前把这条写进交付说明，能省掉一轮解释。

最后提醒一句：交付包里不要放密钥文件、口令文本、内部工具路径截图。客户需要的是能安装的成品和能核对的证据，不是你的工作现场。授权文件可以放一份扫描件或邮件确认，但涉及客户商业信息的材料，按合同约定处理。

实例二：团队内部版本归档

场景设定：团队内部有一款自研工具，需要把接口地址从测试环境切到内网正式环境，版本号从 2.0.7 升到 2.1.0，换一套主题色，并在启动页加一行“内部测试版”。这类改动频繁，几乎每周都有，单个包不重要，重要的是半年后还能找回任意一版。

以前怎么做：共享盘里建“工具_新”“工具_最新”“工具_真的最新”，谁改完谁上传，文件名随缘。测试同事装了新包，发现接口不对，想回退，却找不到上一版的原包和签名密钥。最后只能重新改一遍，时间花在重复劳动上。

现在怎么做：按版本号建目录，一条版本线从旧到新，永不覆盖。每个版本目录固定放六样东西：源包、需求历史、打包日志、成品、哈希文本、verify 输出。根目录放一个 INDEX.txt，一行一个版本，写清版本号、日期、改动摘要、成品文件名、哈希前八位、签名指纹前八位。新同事进来，先看 INDEX，再看目录，十分钟能上手。

Archive/InternalTool/
  INDEX.txt
  v2.0.7/
    source.apk
    history.ini
    pack.log
    InternalTool-v2.0.7-207-Internal-20260930.apk
    SHA256.txt
    verify.txt
  v2.1.0/
    source.apk
    history.ini
    pack.log
    InternalTool-v2.1.0-210-Internal-20261021.apk
    SHA256.txt
    verify.txt

文件	内容	谁维护
source.apk	该版本导入的原始包	改包人
history.ini	该版本的需求原话与日期	工具自动生成
pack.log	四步打包记录	工具自动生成
release.apk	最终成品	改包人
SHA256.txt	文件哈希与字节数	改包人
verify.txt	apksigner verify 的完整输出	改包人

图 6：按版本号排列的归档目录，让任何一版都能被找回。

归档不是把文件堆进文件夹就结束了。真正的检验，是有人需要回退时，能不能在几分钟内拿到可安装、可核对、可解释的旧版本。建议每月做一次小型恢复演练：从归档里随机抽一个版本，把成品拷到测试机，重新计算哈希，再跑一次 verify，最后安装启动。整个过程记录在一行里即可，写清版本号、核对结果和演练日期。演练会发现一些平时想不到的问题，比如某个版本的源包被误删、日志只剩半截、哈希文本和成品对不上。早发现，比真出事时手忙脚乱要好得多。

INDEX.txt 是这套归档的目录页。建议一行一个版本，用竖线分隔，不用表格，方便全文搜索。字段顺序固定：版本号、日期、改动摘要、渠道、成品文件名、哈希前八位、签名指纹前八位、验收人。改动摘要控制在二十字以内，例如“接口切正式环境、改主题色”。写不下就另起一行缩进，别把一行撑得太长。

团队归档要约定三条规则。第一，版本目录只增不改，发布后不再往里替换文件；发现错误，发新版本并在 INDEX 里注明废弃关系。第二，签名统一用团队密钥，密钥由固定的人保管，其他人只拿指纹核对。第三，每月抽一个版本做恢复演练：从归档目录取出成品，核对哈希和指纹，装到测试机，确认能启动。演练记录可以只有一行，但要有。

验证方式：让一位没参与改包的同事，只看 INDEX 和目录，完成三件事——找到指定版本、核对哈希、确认签名指纹。三件事都能在十分钟内完成，说明归档合格；任何一件卡住，就把缺失的信息补回模板。归档不是给自己看的，是给下一个接手的人看的。

与客户交付相比，内部归档可以少一些对外说明，但不能少证据。客户交付重“证明这次改了什么”，内部归档重“任何时候都能回到某一版”。两者共用同一套文件，只是目录命名和交付范围不同。

交付清单、验收记录与用户评价

最后把交付动作固定成一张清单。清单不用复杂，能一项项打勾就行。建议打印出来，或者在交付目录里放一份文本版，每次复制、每次勾选。清单的作用不是形式，而是防止“以为做了、其实漏了”。

安装验收记录建议包含下面这些字段。设备型号和系统版本不能省，因为同一个包在不同系统上的表现可能不同；安装方式和启动结果要写“成功”或“失败”，不要写“应该可以”；关键页面逐项列，看到什么写什么；签名核对与哈希核对写“一致”或“不一致”，不一致就暂停交付。

记录项	填写内容
设备与系统	手机或平板型号、Android 版本、是否为模拟器
安装方式	全新安装或覆盖安装，安装耗时，是否被系统拦截
启动结果	首次启动是否成功，前台应用是否为该包，启动页是否正常
关键页面	逐项列出改动位置，记录实际看到的结果
核对结果	哈希是否一致，证书指纹是否一致，版本号是否一致
遗留问题	未解决的现象、复现步骤、影响范围、计划处理时间
验收人与日期	实际验收人姓名或代号，以及验收完成的日期

档案做好之后，交付就不再靠口头解释。下面是几位使用者的真实感受，他们各自面对的场景不同，但都提到了同一件事：记录让沟通变短了。

用户评价

“以前客户问版本，我要翻半天聊天记录；现在交付目录一打开，源包、需求、日志、成品排得整整齐齐，连签名指纹都写好了，沟通成本低了很多。” —— 老周 · 独立开发者

“我们三个人轮流改同一个应用，最怕互相覆盖。按版本号建归档目录之后，谁改的、改了什么、用哪把密钥签的，都能查到，回退也有依据。” —— 阿岚 · 小团队负责人

“内部工具的接口地址经常切，以前发错环境要查一下午。现在 pack.log 和体检单跟着包走，装之前先对一眼哈希和指纹，心里有底。” —— 陈工 · 企业信息化专员

“我接的都是客户授权的展示类应用，交付时把验收记录和截图一起发过去，对方很少再追问‘到底改了哪里’，尾款也结得干脆。” —— 小满 · 接单设计师

“社团的应用只是换名字和图标，我原本觉得没必要留档。后来换电脑，旧项目找不回来，才知道 history.ini 和源包有多重要，现在每个版本都老老实实归档。” —— 李同学 · 校园社团技术负责人

再说一次合规边界：本文所有操作都以自有版权或已获得授权的应用为前提。请勿用于破解、绕过付费、去除他人应用的限制，也不要把改包能力用在来源不明的商业软件上。交付档案里保留授权说明，不是为了形式，而是为了让每一次修改都有据可依。涉及客户数据的项目，截图和安装记录也要按约定脱敏。

写档案的顺序，建议从后往前想：客户最后要拿到什么，验收时要看什么，出问题时先查什么。把这三件事倒推成文件，目录结构自然就出来了。不要为了“看起来专业”堆一堆用不上的材料，能对上号的文件才有价值。

安卓修改大师智改工坊一直建议使用者养成两个习惯：改之前先备份，交付之前先核对。前者保护源包，后者保护信誉。工具可以替你完成反编译、回编、对齐、签名和校验，但“这是哪一版、谁签的、改了什么”这三个问题，最终要由你的档案来回答。官网是 www.apkeditor.cn，需要了解完整流程可以到介绍页看看。

只需说话，就能让应用变成你想要的样子。把这句话落在操作上，是省事；把改包过程落在档案上，是省心。两者都做到，交付才算真正完成。

下次交付前，不妨先打开项目目录，照本文的清单走一遍。你会发现，多花的十几分钟，换来的是后面几天都不用反复解释。