一次改动的记录方法：改了什么、原始包在哪、怎么验证、还欠什么

这篇文章讲的是"改完之后"的事。安卓修改大师智改工坊是一款 Windows 桌面工具：拖入安装包，用中文写一句需求，AI 去改 smali 与资源，改完自动回编、对齐、签名、校验，再一键装到手机或模拟器上看效果。它的介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。

工具把"改包"这件事变快了，但快不等于清楚。改包真正会埋雷的地方，往往不是改错，而是改完说不清：三个月后老板问"现在发出去的这版和上个月那版差在哪"，你说不上来；同事接手你的项目，翻遍电脑只找到一堆叫 signed.apk 的文件，不知道该装哪一个；线上出问题想退回上一版，却发现原始包在谁手上都没记录。

这篇我们就讲一件事：一次改动，应该留下什么记录。先讲清要留哪四类信息、为什么"只记得改过"是最常见的坑；再拆开工具已经替你留好的那几份凭据，告诉你哪些不用管、哪些必须人工补；最后给一份可以直接抄走的简版模板，配两个自家应用的改包实例。

一、最贵的坑不是改错，是说不出改了什么

先还原一个几乎每个团队都发生过的场景。你们有一个自研的内部应用，比如「巡检打卡」，这半年陆续改过七八次：换过一次图标、改过一次启动页背景、把首页文案里的部门名换了、版本号跳了两级。某天有位同事反馈"新版点开就白屏"，你想回退到上一次那版先顶一天 —— 然后发现：原始包在最初接手的那台电脑上，中间几版只存在于某几个人的桌面上，谁改的、基于哪版改的、改完有没有验证，全靠回忆。

这类事故的共同点，是它的成本不是发生在改动的时候，而是发生在三个月后。改的时候人是有动力的（需求在手、目标明确），回头看的时候人是没有动力的（只想知道一个答案）。所以"记录"这件事，天然是逆着惰性走的：越省事的记录方式，才越有可能被真的坚持下来。

把常见的"记录方式"摆在一起看，失败的原因其实是三种不同的漏：

常见做法	当时看着没问题	三个月后漏在哪
改完在群里说一句"好了"	在场的人立刻知道	不在场的人不知道；记录随聊天记录一起被刷走
在本地新建一个"改动记录.txt"	开始两周填得很勤	依赖自觉，一旦忙起来就断更，断更之后再也接不上
把包发给同事时口头交代	接收的人当场明白	转手一次就失真一次，第二个人手里只剩一个 apk 文件
只留最终成品包	交付时最干净	原始包、改动范围、验证结论全部丢失，无法回退对比

注意第四行："只留成品包"是最容易被当成好习惯的做法，其实它是记录缺失最彻底的一种。 成品包能证明"有这么个版本"，但它不能回答"从哪儿来、改了什么、验没验过"。所以下面要讲的两件事就顺理成章了：一是要留哪几类东西，二是哪些能让程序自动留。

这四个问题里，前两个是"凭据"，后两个是"判断"。凭据可以自动留、可以查文件；判断只能靠人写下来。后面你会看到，这也是这套工具在设计上的一条分界线：凡是机器能记的，绝不让用户手抄；凡是只有人知道的，也不假装记了。

二、一份改动记录的最小字段集（可直接照抄）

大部分团队的记录失败，不是因为不够详细，而是因为"太详细所以没人写"。所以模板要小到能在两分钟内填完。下面这份是我们自己在用的简版，字段分三块：身份（这是哪个项目哪一版）、依据（基于什么包、什么授权）、结果（改了什么、验了什么、欠什么）。

注意里面有两行是"抄来的"而不是"写出来"的：需求原话直接照抄历史记录里的那句，打包产物和证书行直接照抄打包日志 —— 这两行一旦靠回忆写，就容易和实际对不上。下面就把"哪里抄"讲清楚。

2.1 字段是怎么选的：三块、十二行、两分钟

这份模板的字段不是想当然凑的，而是按"将来谁会来问"倒推的。身份三行（项目、包名与版本、原始包）回答"这是哪个东西"；依据三行（来源与授权、需求原话、附件清单）回答"凭什么改、改的哪一句话"；结果三行（改动摘要、打包产物、验证记录）回答"变成了什么、验过没有"；最后两行（遗留问题、记录人）回答"谁负责、还欠什么"。加起来十二行，写得快的人两分钟能填完 —— 这个长度是刻意的：字段一多，人就不填；字段一少，将来就答不上。

真正拉开差距的是写法。同一件事，下面左列这种写法几乎等于没写，右列才是能用的记录：

没用的写法	能用的写法	差在哪
"改了下界面"	"首页顶部文案由『欢迎使用』改为『欢迎使用巡检打卡（内测）』"	前者无法验证，后者可以照着点进去核对
"优化了图标"	"应用图标整体替换为 logo_1024.png（各密度一致）"	素材来源与范围都写明了
"测过了，没问题"	"模拟器 Android 12：桌面图标与名称正确、启动正常，判定通过"	设备和验证点都可复现
"还有一点小问题"	"英文语言包下应用名仍是旧名，下一版处理"	遗留问题要能直接变成下一条需求

三、工具已经替你留好的：四类凭据与四份日志

这套工具在设计时有一个明确取舍：项目的落盘结构要能自证。也就是说，只要你没删项目目录，关于"改了什么、基于什么包、跑过什么命令"这三件事，绝大部分信息本来就在磁盘上，不需要你额外记。逐层拆开看。

3.1 项目目录：一个 8 位随机目录里装着全部凭据

导入一个包，程序会在工作目录的 Project 下面建一个8 位随机字符串目录（小写字母加数字），这个目录就是"这一次改动"的容器。它里面固定有这些东西：

文件 / 目录	它替你记了什么	什么时候翻它
source.apk	导入时从原文件复制的一份原始包	要"从头再来"或做对比时
config.ini	项目名、创建日期、工作目录、图标文件、源包名、应用名、包名、版本名与版本号、最低与目标 SDK、启动页组件、原始文件路径	要知道"这是哪个包、哪一版"时
history.ini	每一次点「立刻修改」时你写的需求原话 + 时间	要"照上次那条再改一遍"时
apktool\ 与 apktool.log	反编译出来的工程与 apktool 的完整输出	反编译失败、想确认解包完整性时
build\ 与 pack.log	三个中间产物（未签名 / 已对齐 / 已签名）与打包全过程日志	要交包、要核对签名时

其中有两个细节值得单独说，因为它们直接决定了"凭据可不可信"。

第一，原始包是导入时就复制进来的，不是你后来手动归档的。这意味着项目目录一旦建立，"基于哪个包改的"就已经被固定住了；而且 config.ini 里那一行记录的是相对文件名，所以整个项目目录可以打包拷给同事，图标、源包、历史、日志一起过去，不会出现"拷了一半、图标找不到"的情况。当然也有个前提要知道：复制成功才会写进配置，万一当时复制失败（比如磁盘满），这一行会是空的 —— 所以交接前顺手看一眼那行有没有值，是个好习惯。

第二，反编译失败不等于项目白建。配置、图标、源包这三样在反编译之前就已经落地了，所以哪怕 apktool 当天不配合，你的"原始包在哪"这条凭据依然成立；程序会告诉你失败原因，并给出 apktool.log 的路径让你自己去翻。这一点看着不起眼，但它保证了"记录"不会因为某一步失败而整段丢失。

还需要知道一种"记录天生就残缺"的情况：分包包（apks / xapk / apkm）、加密包、jar 或 class 这类文件，可能解析不出包名与版本，程序会以文件名继续把项目建起来，并在页面上给一句说明。遇到这类项目，记录里"包名 / 版本"那两行八成是要空着的 —— 别为了填满而瞎写，直接写"解析不出，以文件名建项目"更诚实，也更方便后来人理解为什么对不上。

3.2 history.ini：故意只留你的原话

点「立刻修改」时，程序会把你写在输入框里的那句需求原文和当前时间追加进项目目录的 history.ini，按"记录1、记录2、记录3……"的顺序递增。你在详情页或者「历史」窗口看到的每一条，就是 #序号 + 时间 + 需求原文，而且原文是完整显示的，不做截断。

这里有一个刻意的设计：历史里只留你写的那句原话，附件说明和那段固定的环境说明都不进历史。为什么不进？因为环境说明是每次发送都一模一样的固定文字（切工作目录、改完留标志文件、不要自动打包），如果它也跟着进历史，你翻历史时看到的会是同一段话重复几十遍，真正属于你的那两句需求反倒被淹没了。附件说明的处理逻辑同理：它是"这一次"的施工细节，不是"这次改了什么"的一句话总结。

这个设计带来一个非常好用的副作用：历史天然就是你的"需求索引"。每条记录右侧都有一个「选择」，点一下就把那条需求填回输入框，你可以基于上次那句话稍作修改再发一次。迭代改包的正确姿势，往往就是"选历史 → 改几个字 → 立刻修改"，而不是每次从零开始组织语言。

历史还有两个配套入口值得知道。项目列表是直接读磁盘的，带搜索和刷新，每一条都能编辑、看历史、删除；点某一条的「历史」按钮会打开历史窗口。而详情页里本来就直接列着修改历史，最新的一条在最上面，每条都是"#序号 + 时间 + 需求原文"，所以日常根本不用专门去开窗口翻。配合"按记录号递增、删掉某一节就等于删掉那条记录"的存储方式，你也可以直接手改这个 ini 文件 —— 比如把测试期那些写着"随便试试"的临时记录清掉，历史就干净了。

3.3 pack.log：一次打包的完整"作业过程"

改完之后 AI 会在项目目录留一个标志文件，主窗口把它收走（读到就删，然后弹出打包窗口），打包按四步走：回编 → 对齐 → 签名 → 校验。这四步的分工是：回编把工程重新编成 apk；对齐解决资源在包内的对齐问题（对齐过的包在设备上读取更顺）；签名给包盖上证书，让它具备可安装的身份；校验回头确认"确实签上了、签名是有效的"。从回编那一刻起，每一次命令都在往项目目录的 pack.log 里写，写的内容包括：

• 日志表头：打包时间、项目工作目录、当前工具链信息、签名私钥与签名证书的完整路径；
• 打包标记那一行（写没写进 res/values/styles.xml、写成了什么状态）；
• 四步里每一条命令的原文（含参数）以及它的输出；
• 最后一步校验读出的签名证书信息。

为什么要多一步 verify？因为前三步只看退出码：命令没报错，不代表"签名真的签上了"。校验这一步会把签名者信息打印出来，你拿这一行（例如 Signer #1 certificate SHA-256 digest: ...）就能确认手里这个包是用哪张证书签的。把这一行抄进改动记录，就是最硬的一条"验过"凭据。

还有一点很多人不知道：打包失败也会把日志写完整。不管是回编报错、对齐失败还是签名没通过，日志文件都会落盘，并且失败提示里会带上日志尾部的几行。所以"这次没打出来"本身也是可追溯的 —— 记录里写一句"某日打包失败，原因见 pack.log 第几段"，三个月后你自己能看懂。

为什么日志里要连命令原文一起记？因为"打包失败"这四个字提供不了任何线索，而"哪一步、用什么参数、退出码是多少、工具输出了什么"才能定位问题。举个常见对比：同样是回编失败，一种情况是工程本身有问题，另一种情况是磁盘上那个中间文件被别的东西占用 —— 前者要回到工程里改，后者只要等一会儿重试。日志里有了命令和输出，你才能分辨这两种；只记一句"打包失败了"，下次遇到还得再猜一遍。

3.4 四份日志的分工：别翻错文件

工具一共会写四份日志，很多人第一次找问题时会在四个文件之间乱翻。记住它们的分工，排查效率会高很多：

日志	记什么	放在哪
history.ini	你每次写的需求原话 + 时间（这不是日志，是索引）	项目目录
apktool.log	反编译全过程（源文件、输出目录、apktool 的每一行输出）	项目目录
pack.log	回编 / 对齐 / 签名 / 校验四步的命令与输出	项目目录
dock.log / error.log	窗口吸附与布局自检、打包的关键节点；以及程序未处理异常	%LocalAppData%\ApkGallary\

规律很好记：跟你这一次改动绑定的日志（需求、反编译、打包）都躺在项目目录里，跟这台电脑的程序状态绑定的日志（吸附、异常）躺在系统用户目录里。前两份里的东西，会随着项目目录一起被拷给同事；后两份不会，它们只回答"这台机器上程序当时干了什么"。交接项目时如果现场看到过异常，记得顺手把 error.log 里那一段也抄进记录。

四、工具故意没记的三件事，以及为什么

讲完自动的部分，必须讲清楚哪些必须人工补。否则你会误以为"翻文件就能解答一切"，然后在真正需要答案的那天扑空。下面三件事，工具不会替你记，也不该替你记。

4.1 那份需求"为什么提"：业务原因

历史里能查到"把首页文案从 A 改成 B"，但查不到"因为公司改名了"还是"因为客户投诉这句话有歧义"。原因这类信息只存在于人的脑子里，而它恰恰是三个月后最值钱的那部分 —— 因为它决定了下一次该不该改回去。

补法的成本极低：在需求原话里带一句依据。比如写成"（依据：公司品牌升级，2026-03 新 VI）把应用图标换成附件里的新 logo" —— 这句话本身成了历史记录，你既没多开文档，也没多填表。

4.2 验收标准与验证结论：这次算不算改对了

程序能替你验证"包打出来了、签名校验通过了、装到设备上起来了"，但"首页那句话换得对不对、图标换的是不是设计稿那一版"只能人眼看。这一步的结论必须写下来，因为它是最容易在交接时丢失的信息：下一个接手的人只能看到一个包，看不到"上一版我们判断它是合格的"。

写的时候给三个要素就够了：在哪看的（设备/机型）、看了哪几处、结论。例如"雷电机型 Android 12：桌面图标与新名称正确、启动页新图完整无拉伸、关于页版本号为 2.4.0-内测，判定通过"。

4.3 授权与来源：这个包能不能改、能不能发

这一条不是"给工具记的"，是给团队记的。改动记录里应该有一行写清这个包是谁的、改它是为了什么场景：自研应用、内部工具、已获得授权的客户应用，用于内部测试、学习研究这类合法用途。这一行将来会救你很多次：它能解释"为什么会有这个包"，也能在别人问起时给出明确边界。

顺便把这件事的另一半说清楚：请勿把这类工具用在破解他人付费应用、绕过他人应用的安全机制或未获授权的分发上。记录里的授权那一行写不实，本身就是个危险信号。

为什么附件说明不进历史（以及怎么补）

这一条最容易被误解成"工具少记了"。事实是：附件说明会跟着需求发出去（拼成"序号. 文件绝对路径 —— 用途说明"附在需求后面），但不写进 history.ini。原因是历史要当"一句话索引"用，一条需求下面挂五行附件路径，索引就不好读了。

补法也很直接：把附件里最容易丢的信息写进需求原话。比如附件是新 logo，就在需求里写"图标换成附件里的 logo_1024.png（2026-03 新版 VI）"。将来别人翻历史，即使附件那个文件早被挪走了，他也能从原话里知道当时用的什么素材、哪一版设计。

顺带说清楚"发出去的那段话"到底是什么结构，这决定了你写需求时该往哪里使劲。点「立刻修改」之后，送到 AI 那边的是三段拼起来的文本：

第三层里那个"标志文件"的约定，正是"改完了自动弹打包窗口"的机制来源：主窗口每 2 秒看一次项目目录里有没有这个文件，读到就删掉并开始打包；开始等之前还会先清一次同名残留，避免上一轮的残留被误判成本轮改完。所以有一条使用纪律要记住：别在项目目录里手动造这个标志文件，否则你会看到打包窗口莫名其妙地弹出来。

4.4 一个刻意的取舍：为什么不把记录做成"必填表单"

看到这里你可能会想：既然记录这么重要，为什么不在主界面上加一个"改动记录"表单，每次点「立刻修改」都强制填完？毕竟强制才有效。答案是：强制表单会把成本加到每一次改动上，而收益只在极少数时候兑现。 一个每天要改五六次的小团队，很快就会学会用"1""11""111"来敷衍必填项，表单填满了，信息还是零。

所以这里的选择是分层：程序只强制两件"不填就没法干活"的事 —— 需求不能为空、附件的用途说明不能少于 10 个字（后者下面还会细说）；其余信息一律不拦，但都替你落盘成"可查的凭据"。记录的责任交给人，代价是团队要养成一个两分钟的习惯；好处是你不会被一个为了合规而存在的表单逼着手脚发僵，也不会因为表单没填完而完不成正事。这个取舍不一定适合所有团队，但它至少是明说的：工具负责让记录变便宜，不负责替你做决定。

五、两个自家改包实例：记录怎么留，验证怎么做

下面两个例子都来自我们自己和同事的日常场景，用的全是自家应用与自有素材。重点看每一步"留了什么"。

实例一：内部「巡检打卡」工具改名 + 换图标，把"原始包在哪"从口口相传变成一条路径。

以前的做法：图标是设计同事发在群里的一张图，改包的人在命令行里 apktool 反编译、按密度替换、回编、签名，装到手机上确认一下，然后往群里发一句"新图标好了"。问题出在半年后：这个包被人转了几手，"最初那版"到底长什么样没人拿得出来，只能去翻聊天记录里那张图。

现在的做法：把自家这个安装包拖进安卓修改大师智改工坊，程序建好项目那一刻，原始包就已经复制进项目目录了。需求框里写"把应用显示名称改成『巡检打卡 2.0』，同时把应用图标换成附件里的新 logo"，把新 logo 作为附件加进去、写清用途（这一栏要求不少于 10 个字，就是为了避免"附件是干什么的"只能靠猜），点「立刻修改」。需求原话和时间进了历史，附件路径和用途跟着需求发给了 AI。

改完怎么验证、又留了什么：AI 改完会留标志文件，打包窗口自动弹出来，四步跑完之后勾上"打包后自动运行"，程序会用 adb 把包装到手机或模拟器上并把它拉起来，拉起来之后还会复核一次前台应用是不是它 —— 省掉了"装没装上、起没起来"这类来回确认。最后我们在记录模板里填的"原始包"那一行，直接抄的是项目目录里的 source.apk 路径；"验证结论"那一行写的是"模拟器 Android 12：桌面图标与新名称正确，可正常启动"。半年后再问"原始包在哪"，答案是一条能点开的路径，而不是一段回忆。

实例二：自家「记账助手」安卓版换启动页背景图，用打包日志当验证凭据。

以前的做法：改启动页背景图，走的是同一条手工流水线 —— 找资源文件名、替换、回编、签名、装机。最麻烦的其实是"说不清"：改完之后手里只剩一个签名包，具体覆盖了哪张图、图是从哪个素材版本导出的、当时签名用的哪张证书，全靠记忆；有一次同事拿错了包，装上去发现启动页还是旧的，只好从头再跑一遍。

现在一句话："把启动页背景图换成附件里这张新版宣传图，保持原来的显示比例，不要拉伸变形"，附上新图并写明用途。改完自动打包，四步的命令与输出全部写进项目目录的打包日志，最后一步校验打印出签名证书信息 —— 这一行直接抄进记录，就等于把"这个包确实是这次打出来的"钉死了。验证启动页有个现实难点：它一闪就过去了，所以我们习惯开"打包后自动运行"多看一两次，确认新图完整、没有变形，然后把结论写成一句话存档。

这个例子里"以前"的痛点其实不在改，而在确认：启动页太快、包太多、凭据太少。现在的做法是把确认这一步做成流水线的固定收尾 —— 打包产物在项目目录的 build 子目录里依次留下未签名、已对齐、已签名三个中间件，全过程写进日志，签名校验打印证书行。改的是哪张图、装的哪个包，全程都在同一个项目目录里，不存在"我到底装的哪个版本"的疑问。

两个例子摆在一起看，会发现记录带来的最大好处其实不是"省事"，而是把口头交接变成了文件交接。同事来接手时，你不必讲一段故事，只要把项目目录指给他：源包在这儿、每次改什么写在历史里、打包过什么看日志、最后一个包在 build 目录 —— 他十分钟就能进入状态。反过来，如果你要跟别人交接一个"只留了成品包"的改动，那就只能靠嘴说，而嘴说的东西，走了就没了。

六、六个让记录省力的习惯（以及排查顺序）

记录这件事要靠习惯，不靠觉悟。下面六条是我们自己用下来最省力的：

1. 一句需求只装一件事的主语。历史是索引，"改图标 + 改名字 + 顺手调一下配色"写成一句，将来想引用其中一件就得整句复制再删改。宁可分两次改，也别把三件事挤进一条记录。
2. 把依据写进原话。历史里留的就是你写的那句，所以"因为什么"最好也在这句里 —— 这是唯一一个不用另开文档就能留下的地方。
3. 附件说明当记录写。用途那栏别写"用这个"，写成"应用图标换成这个文件（新 VI 版）"，让三个月后的自己也能看懂。
4. 用历史回填做迭代。要微调上次的改动，直接在历史里点「选择」把那条填回来，改几个字再发 —— 比重新组织语言更快，也让同类需求的写法自然收敛成一致口径。
5. 交接就整个目录拷走。项目目录里的图标用的是相对路径、源包和历史都在里面，整个目录打包发出去，对方接上就能继续；系统用户目录下的诊断日志不跟着走，该抄的段落记得先抄。
6. 删项目用程序删。删除有防呆：只允许删项目根目录的直接子目录，路径万一被改坏也删不到别处去；而且删掉之后，这条改动就真的只剩回忆了 —— 删除之前，先确认记录和交付包都已经在别处留了一份。

如果只能记住一条，记这条：把"这次要改什么"写成一句将来能被复述的话。 因为这句原话会原样进历史、原样成为你三个月后的索引、也原样成为同事接手时看到的第一行说明。语言上的小习惯会带来很大差别：先说位置（哪个页面、哪个入口、哪一段文字），再说结果（改成什么），最后说边界（别的不要动、保持原比例、只改中文简体）。这三件事凑齐，改写、复核、交接三个环节都会顺很多。

最后是排查顺序 —— 出问题时按这个顺序翻，基本不会白翻：

现象	先翻哪份	看什么
这个包是谁改的、改的哪一版	history.ini + config.ini	需求原话条目顺序、包名与版本字段
包打不出来 / 打出来不对	pack.log	四步里是哪一步退出码不对，命令原文对不对
签名到底有没有签上	pack.log 的校验段	证书信息那一行（可抄进记录）
项目建了但工程不完整	apktool.log	反编译失败原因与输出目录
程序本身行为异常	dock.log / error.log	吸附与打包节点、未处理异常

七、用户评价：他们是怎么留记录的

八、结语：把"记得"变成"查得到"

把这篇的技术部分收成一句话：程序负责把能自动记的都记满 —— 源包、配置、需求原话与时间、四步打包的命令与输出、包里的打包标记；人只负责补三件机器不知道的事 —— 为什么改、验没验过、能不能发。 一次改动做完的标志，不是"包装出来了"，而是半年后有人问起时，你能在十秒内给出四个答案。

于是你打开安卓修改大师智改工坊时看到的，就是那句口号描述的样子：只需说话，就能让应用变成你想要的样子 —— 需求写进历史成为索引，过程写进日志成为凭据，结论写进模板成为交接；改包这件事，从此不只快，而且留得住痕。

产品介绍页与下载入口：https://www.apkeditor.cn/ai-version.aspx（官网 www.apkeditor.cn）。