出问题该看哪份日志：安卓修改大师电脑版的四份记录与可追溯交付

五、dock.log：磁吸不对时看什么

前三份日志对应的是"你主动点了一个按钮，然后等结果"的流程。dock.log 不一样，它对应的是一段你根本没有主动触发的后台循环：双窗并排的几何计算。这一段是整个工具里最难看懂、也最容易误判成故障的部分，因为它的失败表现全是"看起来哪里不对，但又不报错"。

先把这段循环的脾气说清楚。它不是"你拖一下窗口，它算一次"，而是每 5 毫秒醒一次，读一遍主窗和目标窗的位置尺寸，判断这一轮该不该动。也就是说，你手动拖动主窗的那零点几秒里，它已经在你不知道的情况下算了几十上百次。如果不加约束，结果就是窗口一边被你拖、一边被程序改，手感像在跟人抢方向盘。

所以中间加了一道事件稳定性判断：程序不看"窗口变了"，而看"窗口停住了"。当它连续若干轮读到的位置完全一致、并且静止时长大过一个阈值，才判定"用户这一个动作结束了"，然后才开始计算并贴靠。这个设计的代价是会有很短的一段延迟感，好处是拖动过程里窗口不会抖。日志里能看到每一轮的判定结果，这就是排查磁吸问题时唯一的信息来源。

还有一个经常被当成 bug 的现象：两扇窗永远一样高。你把主窗拉高，旁边那个窗口也跟着变高；你把旁边那个拉矮，主窗也被压低。这是设计上刻意的选择——并排看代码和看预览，两扇窗高度错开会非常难看，视线每次跨越都要重新定位。但代价是：如果目标窗口自己带了最大高度限制（有些模拟器窗口就是这样），它顶不住，程序只好反过来压缩主窗。这时候主窗"莫名其妙变矮"，根源不在主窗。

宽度则完全由公式决定。目标窗该有多宽，等于工作区宽度乘上一个占比，再减去两窗之间的缝隙和主窗自身的宽度。默认占比 0.75，缝隙留了一点，所以主窗实际占的地方会比它设定的宽度更大一些。很多人第一次用会去手动拖宽目标窗，拖完发现过一会儿又回去了，然后在日志里看到程序又算了一遍并覆盖了手动尺寸。想让目标窗更宽，正确做法是调那个占比参数，而不是用手拖——手拖是在跟一个每 5 毫秒运行一次的循环较劲，赢不了。

什么时候应该干脆把双窗关掉：目标窗口自己有强制的最大尺寸、或者你习惯把目标窗口拖到另一块屏幕上去。这两种情况下等高和按工作区计算都会持续跟你作对。命令行加一个关掉并排的参数，或者直接在设置里取消勾选，比每天跟它拉扯省事。

六、error.log：它记的是"没被接住"的那一类

前三份日志有一个共同点：它们都是程序主动写的。设计的时候就规定了"这里要写一行"，所以内容整齐、格式一致、能当表格读。error.log 完全不是这个性质，它是被动兜底的那一层——只有当一个异常从代码里漏出去、没被任何一层接住的时候，才会落到这个文件里。

理解这一点，就能理解一个很多人想不通的事：这个文件长期是空的，是好事，不是日志功能坏了。有用户看到另外三份日志都在涨、只有 error.log 一直是 0 字节，怀疑是不是没开。恰恰相反，正常的操作路径上所有可能出错的地方都被显式处理了，剩下真正漏到最外层的极少。

它的格式很朴素：一行时间戳，异常类型，然后是一串调用栈。看栈不需要读懂每一行，只需要看栈顶那几行——那是异常抛出的位置，通常能直接看出是哪个动作触发的。栈底往往是框架层的固定几行，没有信息量，可以略过。

这一段想给一个更重要的判断原则：什么样的故障值得把 error.log 拿给别人看。标准不是"它出错了"，而是"它能稳定重现"。同一个操作连续做三次以上，每次都在同一个位置失败，这时候 error.log 里的那段栈才是有效证据，别人照着你的步骤也能复现。反过来，偶发一次、重开就好、再试又不出现的问题，栈里往往是残缺的现场，发出去也只是互相猜。遇到偶发的情况，正确做法是先记下发生的时间点和你当时在做什么，攒够几次规律再一起看。

七、项目目录本身，就是第五份记录

四份日志解决的是"过程发生了什么"。但真正要追溯的时候，光有过程不够，还得回答另外两个问题：产物在哪、当时提的要求是什么。这两个答案不在日志里，在项目的目录结构里。

工作目录是程序自动挑的，顺序是从 D 盘开始往后找，遇到第一个剩余空间够的盘就用它，空间不足会继续往下走。项目本身按一个短标识建子目录，所以你在硬盘上看到的是一串看不出含义的短名字。不要手动改这些名字，改名会让程序和目录对不上。想认得出来，在软件里看项目列表，那里显示的是应用名加包名。

一个项目的目录里，除了反编译出来的那一堆文件，还有几样东西是专门留给追溯用的：

这里面的 source_prompt.txt 值得单独讲，因为它是整个工具里最被低估的一个文件。很多人对 AI 改包的不信任，本质上是"我不知道它到底看到了什么、我说的话它理解成了什么"。这个文件把这件事摊开了：你可以直接看到，你写的原文后面跟了一段固定格式的环境说明，告诉它这是什么类型的项目、该动哪些文件、不该动哪些。你还可以看到你的附件是怎么带的、每一份附件的用途说明写的是什么。

当结果不符合预期时，先看这个文件，比反复重试有效得多。有三种很典型的落差：一是你以为是"整段重写"，而请求里其实只描述了局部；二是你写了五句话，但其中三句是情绪、只有两句是可执行的要求；三是附件带了一张截图，用途说明只写了"参考"，于是它只能靠猜。这三种都能在这一份文件里直接看出来，改一句话就好，不必去改十几个地方。

而 history.ini 解决的是另一个问题：往回退。改包这件事最怕的是"第二次改坏了，第一次的成果也没了"。因为每一轮都留在历史里，你可以看到第一轮的描述、第二轮的描述，然后判断该回到哪一个状态重新来。它记录的是文字而不是整个目录快照，所以它不会自动帮你还原文件——但至少你知道自己走到过哪里，不会在第五轮的时候完全想不起来第一轮那句话写的是什么。

一个实用习惯：每改到一个自己满意的状态，就把那一轮的描述在 history 里认一下，并且在本地另存一份产物。历史是文字记录，产物是文件，两者都要有。只留历史，等于知道自己做过什么但手里没东西；只留产物，等于有一堆文件但不知道哪个是哪个。

八、两个实例：靠记录两分钟定位

抽象讲结构容易点头，具体看两个场景更容易记住。这两个都是我们自己在做自家应用时真实遇到过的类型，不是编出来的极端情况。

九、一张速查表：七种现象，七个第一落点

前面几节是分头讲，这一节把它们合成一张表。用法很简单：不要从头读，直接找你现在的现象，然后去看它对应的那一个文件。每次只查一处，查完得出一个结论，再决定下一步。同时翻五个文件，只会让线索互相干扰。

表里没写 error.log，因为它不按现象对应，而是按"程序自己没了"对应。真到了那一步，说明前面六条都没机会用，直接看它就行。

再补一个顺序上的建议：从后往前查，不要从前往后查。也就是先确认最终产物对不对，再往上游追。原因很实际——很多问题在最后一环就已经有明确结论了（比如校验通过），如果你从最前面的导入开始查，会白白多走四五步。只有最后一环无法判断时，才需要往前翻。

十、三条习惯，把记录用起来

文件在那儿，不代表会用。观察下来，真正把改包这件事做得又快又稳的人，用的其实只有三个很笨的习惯。这三个习惯跟工具无关，用别的工具也一样成立。

习惯一：一轮只改一件事。这是所有习惯里最省时间的一条。很多人一次提五条要求，改完发现有三处不对，然后完全无法判断是哪条要求引起的。而一轮只改一件事，结果只有两种：成了，或者没成，不需要分析。五轮改完，你手里有五份明确的记录；一次改五条，你手里只有一团浆糊。慢就是快，这句话在改包上体现得特别明显。

习惯二：写历史的时候写"做了什么"，不写"改了一下"。history.ini 里的描述是你未来唯一的线索。三个月后回头看"改了一下"，等于什么都没写。写"把首页顶部横幅文案换成活动主题，保留原按钮"，一眼就知道那一轮动的是哪里。多花十秒，省掉半小时。

习惯三：出问题的第一反应是记录，不是重装。这个反直觉，但极其有效。重装会把现场清掉——日志被覆盖、目录被重建、你刚才那一次操作的痕迹全没了。而记录下来（时间点、你点的是什么、界面当时显示什么）花不到一分钟，之后无论自己查还是找人问，都有依据。

关于清理：改包做多了，工作目录会堆很多项目，一个包解开来动辄几百兆。程序只允许删除工作目录下项目区里的直接子目录，这个限制是刻意加上去的——删错目录的代价太大，宁可让你多选两次。清理之前先确认那个项目你真的不需要了，因为历史记录和产物是一起没的。

十一、五个反复被问到的疑问

问一：日志里会不会有我的包内容、账号密码之类的东西？

不会。日志记的是"做了哪一步、结果如何"，不记包里的具体内容。有一个细节可以佐证这个设计取向：打包时需要用到签名口令，而命令行参数里带明文口令有泄露风险，所以口令是通过环境变量传进去的，并且写进日志之前会统一替换成六个星号。你在 pack.log 里看到的永远是掩码，看不到真实口令。另外配置文件里的签名口令是明文的，那是本地文件、属于你自己的机器，这个取舍是"可读可改"优先于"加密存储"。

问二：为什么别人能贴上去，我这台贴不上？

先看目标窗是不是最小化了。最小化的窗口在系统里坐标会跑到一个极端值，程序识别出来会整轮跳过——这是有意设计的，不是漏判。其次看你用了几块屏幕，多屏情况下工作区是按主屏算的，目标窗如果在副屏上，贴过去的位置就会显得很奇怪。这两条占了绝大多数。剩下的是目标窗自己有强制尺寸，这时候等高和按公式算宽都会跟它冲突，关掉并排更省事。

问三：我什么都没改，为什么两次打出来的文件不一样？

因为签名本身带时间信息，同样的内容每次签出来的字节不会完全一致，这是签名机制的固有特性，不是打包不稳定。判断"改没改到"不能靠比对文件哈希，要靠重新导入之后看具体那一处。真想确认某一次改动，把产物解回来对比那一处资源或那一行代码，这才是有效证据。

问四：日志一直不动，是不是卡住了？

看两件事。第一件是那一步的完成标记有没有出现，出现了就说明这一步结束了，日志不再增长是正常的。第二件是看有没有明确的失败记录。这两样都没有、而界面也确实没进展，才是真的卡住。这时候先看 error.log 有没有新增，没有的话多半是在等一个外部条件——最常见的是等模拟器或者设备响应。

问五：这些文件我能删吗？

日志可以删，删了不影响功能，只是下次出问题时少了线索。目录里的标记文件不要动，它们是流程状态的一部分，删了会让程序以为某一步没做完或者做完了，行为会变得很奇怪。产物可以随意搬走，但搬走之后历史里那条记录就对不上文件了，自己心里要清楚。

十二、可追溯，本身就是交付质量的一部分

写到这里可以把话说透一点。改包这件事，交付的从来不只是一个能装上的文件，而是一整套能说清楚的东西：改了什么、怎么改的、改成了什么、凭什么说它是好的。四个问题都有答案，这个交付才算完整；缺任何一个，出了问题就只能从头再来一遍。

大部分人一开始只关心第四个问题——能不能装上、能不能用。这当然最重要，但它是结果不是过程。真正决定效率的是前三个：知道改了什么，才不会重复劳动；知道怎么改的，才能在失败时定位；知道改成了什么，才能在多个版本之间做选择。而这三件事，恰好就是 history、日志、产物目录各自负责的那一块。

这也是为什么这套工具把"留痕"做成了默认行为而不是可选项。不需要你额外开启什么、配置什么，只要正常用，痕迹就在那里。它的价值不在顺利的时候体现，而在不顺利的时候——那种"界面一切正常、结果就是不对"的时刻，是你唯一能抓住的东西。

顺便说一句诚实的：日志不是万能的。它能告诉你哪一步失败、失败在什么位置，但它不能替你想出下一步该怎么做。有些问题日志里写得清清楚楚，你也只能接受——比如这个包有保护、这个资源加密了、这个类被混淆到无法还原。认出来并接受，比在错误的方向上耗三个小时强。会看日志的人不是不会失败，是失败得更快、更便宜。

还有一个容易被忽略的点：记录的价值是复利的。第一次看 pack.log，你只是在解决眼前这一次失败；看到第十次，你已经能凭第四段的第一行判断这次值不值得往下看。这种判断力不是谁教出来的，是同一个文件反复看出来的。同理，history 写得越清楚，你回头翻得越快；回头翻得越快，就越愿意写清楚，形成正循环。反过来，一次都懒得写，三个月后那个项目在你手里就变成了一堆看不懂的陌生文件。

所以对刚上手的人，我的建议不是"把文档全读一遍"，而是第一次失败的时候，认真把那四个文件各打开看一次。哪怕这次什么结论都没得出来，你对它们长什么样、大致写在哪，已经有印象了。等到第二次、第三次失败，打开它们的动作就不再需要心理建设——而绝大多数人卡住的地方，恰恰是"不知道该打开哪个文件"这一步。

十三、两个自家应用的实际改动，以及日志怎么确认它成了

前面讲的都是方法，这一节给两个具体的改动例子。两个都是我们自己应用上的真实需求，用的是自己有版权、有权修改的包。之所以选这两类需求，是因为它们分别代表了改包里最常见的两种难点：一种是只有一处要动，但找它很费时间；另一种是要动的地方知道在哪，但要动很多次、每次都要动对。

两个例子的共同点：真正省下来的不是"操作步骤"，而是试错的成本。以前改错一次，代价是重新走一遍完整流程；现在改错一次，代价是看一眼 source_prompt.txt 改一句话再来。同一件事从"一晚上"变成"几分钟"，差的就是这个。

十四、用过的人怎么说

回到最开始那句话：只需说话，就能让应用变成你想要的样子。这句话背后其实还有半句没说出来——说完之后，还要能说清楚它究竟变成了什么样。前者是效率，后者是可信。安卓修改大师智改工坊把两件事放在一起做：一边把话变成改动，一边把改动变成记录。

如果你现在正卡在某个"没报错但不对"的状态里，建议先别急着重来一遍。打开项目目录，从最后一份记录往前看，答案大概率已经在里面了。工具在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn，安卓修改大师智改工坊的每一次改动都会留下痕迹，这也是它值得信任的原因。

---