修到一半怎么办：源码还原的断点续修与三个按钮

一、先复原场景：这个功能到底在干什么

快速过一遍背景。应用详情页「立刻修改」旁边有一个「生成源代码项目」按钮，只在 APK 项目上显示。点下去之后，工具先用 jadx 把 APK 导出成一个 Android Studio 工程，放到项目的 source 目录里；然后把源码路径、smali 路径和一份修复要求一起送进右侧的 AI 工作台，让 AI 把这个「导出来还编译不过」的工程修到 Gradle 可编译、可打包。AI 修好了，会在项目根目录写一个成功标志，主窗口看到就提示「源代码还原成功」，并把 source 压成 ZIP 让你保存。

理想路径就是这样，一次点击、一条直线。但现实里这条直线经常被打断：jadx 导出用了几分钟，AI 修复可能要更久，中途任何一个环节停下来——不管是人主动停的还是意外停的——工程就处于「修了一半」的状态。下次再点「生成源代码项目」，工具检测到 source 目录已经存在，就会弹出那三个按钮：继续生成、重新生成、取消。默认高亮的是「继续生成」。

这三个按钮是这篇故事的真正主角。选错了，可能丢掉 AI 已经修好的几十处代码；选对了，上次中断的位置原样接上。围绕它们，工具做了一整套「断点续修」的机制——进度盘点、提示词档案、续作纪律。下面从第一次点击开始，把整条链路慢慢展开。

二、第一次点下去：jadx 从哪儿来

整条链路的第一环是反编译工具 jadx。工具的检查逻辑很宽容：先看工作目录里有没有——jadx 的可执行文件、批处理、jar 包，任何一种形态都认，环境变量和 PATH 里配了的也算；实在没有，就自动从官方下载地址拉一个约 69MB 的压缩包下来，用程序自带的解压工具解到工作目录里。下载和解压的进度都显示在生成窗口里，随时可以取消。

这个「没有就下」的设计延续了整个工具链的哲学：环境的事工具自己扛，人只管业务。第一次用这个功能要多等一段下载时间，之后 jadx 就常驻工作目录，再点就是秒进。对内网受限的环境，也可以提前手动把 jadx 放进工具目录——工具认得出，不强求联网。

启动 jadx 还有个不起眼但很见功力的细节：自动下载的那个 jadx 主程序是个图形界面程序，直接跑它会弹出窗口。工具的解决办法是不走它的主入口，而是用命令行方式启动里面的命令行模块——图形界面压根不出来。为什么要较这个劲？因为整个生成过程应该只有「生成窗口」这一个界面在动，用户眼前多弹一个陌生的 jadx 窗口，只会制造「这是卡了吗」的恐慌。界面的安静，也是功能的一部分。

三、先写临时目录，再正式替换：上次的成果为什么不会丢

jadx 开始导出时，产物先落在一个临时目录里，只有导出成功，才会正式替换项目的 source 目录。如果 jadx 失败、或者你点了取消，source 目录一动不动——上一次已经修好的工程完好如初。

这个顺序设计看似只是工程习惯，实际上直接决定了三按钮弹窗里你能有多少底气。设想反过来：先删 source 再导出，一旦导出失败，之前 AI 修了几十处的工程就没了，三个按钮直接变成一个「重新生成」。有了临时目录这道闸，「继续生成」这个选项才永远有东西可续。所有断点续修的可靠性，追到源头都是这一行代码的顺序。

顺带一提，jadx 的完整输出——包括每个失败的方法名——都会写进项目里的 jadx 日志文件。生成窗口本身不展示这些逐行日志，只显示下载进度、阶段和错误，因为你真正需要逐行看日志的场景很少，但需要的时候它一定在。界面上做减法、文件里做加法，这是整个工具日志体系的统一风格。

四、jadx 也会「半途而废」：部分失败的宽容处理

很多人不知道的是：jadx 遇到个别棘手的方法会反编译失败——抛出栈溢出一类的异常，然后整个进程返回非零退出码。如果工具死板地「非零即失败」，一个几千个方法的大包只要有一个方法解不出来，整个源码生成就报废了，这显然不合理。

工具的判定标准因此改成了看产出：只要 Java 源码和 Gradle 工程生成了，就算部分方法失败，也保留全部输出继续走流程。失败的方法数量和名字会被写进送给 AI 的提示词里，附上一条明确的指令：这几个方法解不出来，去 apktool 反编译出来的 smali 目录里对照着修复。也就是说，jadx 干不了的活，不是当成错误扔回给用户，而是打包转交给 AI——用另一份更底层的产物（smali 是反编译的另一个视角，虽然可读性差但几乎不会失败）作为兜底材料。

只有一种情况算彻底失败：一个 Java 源码都没解出来。那时候才报错、才需要人介入。这套「宽容到产出层面、严格到结果层面」的判定，让源码还原的成功率从「看 jadx 脸色」变成「几乎总能往下走」。多个工具接力、互相兜底，是这个功能在工程上最漂亮的一笔。

五、提示词是怎么拼的：一段不进历史记录的话

jadx 导出成功后，主窗口要给 AI 写一份「任务书」。这份任务书的内容相当扎实：source 目录的路径、原始 APK 的路径、apktool 反编译产物里 smali 和 res 的路径、java、jadx、apktool 各自的路径，再加上一段修复要求。所有路径都是绝对路径，AI 拿到就能直接干活，不需要猜任何东西。

注意一个细节：这份任务书不写进 history.ini。修改历史里只留用户亲手写的需求原话，是整个工具的一条铁律——历史是给你自己回看的账本，机器之间交接的技术文档不该混进人的账本。你在历史列表里永远只会看到自己说过的话，这份洁癖保证了几个月后翻历史时它依然可读。

修复要求本身是这份任务书的灵魂，大概包含这么几件事：把 Gradle 工程补齐到能编译；把反编译出来的第三方库源码替换成标准依赖、删掉重复的类；修复资源和资源引用；解不出来的 Java 代码用 smali 对照补上；最后，跑一次 Gradle 的构建命令验证——构建成功，才算修完。这一段要求里最关键的是最后一句：「修完」的定义不是「我觉得改好了」，而是「构建命令跑通了」。把验收标准写进任务书，AI 的输出就有了硬约束。

六、成功标志与 ZIP：收尾的两个动作

AI 构建成功后，会在项目根目录写一个成功标志文件。主窗口有一个独立的监视器盯这个文件，两秒看一次；重新打开项目的时候也会先查一次——所以哪怕你关了程序隔天再开，上次修成功没来得及保存的事不会被遗忘。看到了标志，主窗口收起等候提示、把自己提到前台、弹「源代码还原成功」，然后在后台把 source 压成 ZIP。

ZIP 的打包规则值得一提：保留 source 顶层目录，排除 build、.gradle、.idea、local.properties 这些构建产物和本机配置。为什么排除它们？因为这些目录的内容在你机器上生成，到别人机器上不但没用还可能碍事——本地配置里的路径、缓存里的旧产物，都是「搬过去就得删」的东西。干净源码加工程文件，才是能进版本库、能发给同事的形态。工具替你做了这个「发出去之前先打扫」的动作。

保存环节也留了后手：弹出的「另存为」如果你点了取消，什么都不会丢——ZIP 还留在项目目录里，详情页的状态行上有一个可以直接点开的路径。工具对「用户改变主意」的态度从来都是留东西，而不是删东西。凡是辛苦生成的东西，至少给两次反悔的机会。

七、三个按钮的时刻：灵魂三问

现在回到主场景：source 目录已存在，三按钮弹窗出现。默认选中的是「继续生成」——主按钮、敲回车就直接走。这个默认值本身就是一种表态：大多数时候，续上是对的。什么时候它不对？我们一个个看。

「继续生成」：不删 source、不重跑 jadx。工具会读出上次发给 AI 的提示词原话，追加一段「当前进度说明」，重新送进 AI 工作台，让它从上次的位置接着修。适合：上次中断在半路、工程还有修复价值、你没有理由推倒重来。这是成本最低、收益最稳的选项。

「重新生成」：删掉现有 source，从 jadx 导出重新走一遍。注意提示里写得明白——上次 AI 修的内容会丢失。适合两种情况：一是上次修的方向本身错了，越修越歪，不如从干净的导出重来；二是原始 APK 变了（比如你重新导入了新版本），source 对应的已经不是这个包了。除此之外，慎点。

「取消」：什么都不动。适合你只是想看看 source 目录在不在、或者临时想起来先干别的。三按钮弹窗的「取消」永远是最安全的不作为——它给了你反悔的出口，也让前两个按钮的「有作为」变得可以放心选。

八、进度盘点：续修前的一次「施工现场巡查」

「继续生成」背后有一个设计得非常讲究的动作：在把提示词重新送出去之前，工具会替 AI 做一次施工现场盘点。盘点的内容包括：source 里 Java 文件、XML 文件、资源文件各有多少个；最近一次修改是什么时候；有没有 Gradle 工程文件；有没有构建目录和 APK 产物；jadx 日志里记录了多少个解不出的方法；成功标志文件存在不存在。

这些数字拼成一段话，追加在上次提示词的后面。为什么要这么做？因为 AI 重新接手时，最危险的不是「不知道要干什么」——上次的话写得很清楚——而是不知道现场已经干到哪了。没有这段盘点，AI 可能会重复修已经修好的文件，甚至把修好的又改回去；有了这段盘点，它接手的第一件事就是核对现场，而不是凭想象动工。

这个设计对普通用户的启示是：续修的可靠性不取决于 AI 有多聪明，取决于交给它的现场信息有多完整。文件数量说明工程规模，修改时间说明上次干到什么时候，构建目录说明上次是否已经跑到验证阶段，成功标志说明是否其实已经完成——六七个数字，把「半成品」这个模糊状态翻译成了一组精确坐标。断点续修的全部秘密，就是把状态说清楚。

九、续作纪律：不要推翻已有修复

续修提示词里有一条纪律值得单独抄出来：先检查现状、不要推翻已有修复，从上次的位置接着做。这条纪律防的是 AI 续修时最常见的灾难——「热心过度」。想象一个修了一半的工程，AI 接手后觉得某几处「不够优雅」，把已经修好的代码推倒重来：不仅浪费时间，还可能把本来能编译的部分改出新问题。

「不要推翻」四个字，本质上是在定义续修的任务边界：你是一个接班的工匠，不是新来的总设计师。前任做到哪里，你从哪里接；哪些地方要改，以「能不能编译通过」为唯一标准。这种约束让 AI 的行为从「发挥」变成「施工」，可靠性随之可控。

给使用者的对应建议是：续修时自己也守同样的纪律。续修跑完一轮，先验证（能不能构建、能不能打包），再决定要不要下一轮；不要在 AI 续修的间隙手工大改 source 里的代码——你改的那些和 AI 改的那些会互相踩踏，盘点信息也失真了。要么全交给 AI，要么全手工，混着来是断点续修场景里最容易翻车的做法。

十、source_prompt.txt：一份可以打开看的档案

上面提到的「上次发给 AI 的提示词原话」，存在项目目录里一个叫 source_prompt.txt 的纯文本文件中。它是 UTF-8 编码的普通文本，记事本打开就能看。这意味着一件事：你和 AI 之间的每一次任务交接，都有一份人可读的档案。

这份档案的价值在两个时刻体现。第一个时刻是排查：「AI 到底被要求干了什么？」——与其猜，不如打开文件看原文，所有路径、所有要求、上次追加的进度盘点，一字不落。第二个时刻是学习：想看懂这个功能的工作原理，读三份 source_prompt.txt 比读十篇教程都直观——第一次的、续修一次的、再续修一次的，三份对比着看，断点续修的机制就全在自己眼前了。

还有一个兼容细节：老项目可能没有这个文件——那个年代的功能还不存档。工具的处理是：按当前的项目路径和 jadx 日志现场重新拼一份，存好，再走续修流程。也就是说，续修能力向后兼容，老项目第一次续修时会自动补建档案。你不需要知道自己的项目是「新是老」，机制自己兜底。

十一、实战例一：接手离职同事的内部工具

讲一个真实感强的场景。公司一款内部报修工具，开发的同事离职了，源码没交接清楚，手里只有一个 APK。现在要把它改成新版工单流程。以前怎么做？先网上找反编译工具、配 Java 环境、学 jadx 命令行，解出来一堆编译不过的源码，再花一两周手工修到能编译——这个门槛把大多数运维和测试挡在门外。现在怎么做？把包拖进智改工坊建项目，点「生成源代码项目」，第一次点了之后下班合上电脑（AI 还没修完），第二天打开项目再点一次，弹三按钮，选「继续生成」。工具盘点现场：一千多个 Java 文件、上次修到昨晚十一点、还没有构建目录——续修从昨晚的断点接着走。修完提示「源代码还原成功」，保存 ZIP，用 Android Studio 打开，能编译、能打包。验证方式最硬核：构建命令跑通、产物能装机，就说明工程是真的可用，而不是「看起来像源码」。

这个例子里最值钱的是「继续生成」那一下。如果没有断点续修，昨晚 AI 修到一半的进度就要作废重来；有了它，中断只是暂停，不是清零。长任务工具的分水岭，从来不在顺利的时候，在被打断的时候。

十二、实战例二：把自家应用变成教学工程

第二个例子换个身份：培训讲师。带新人学安卓开发，最好的教材其实是公司自家的真实应用——比任何教科书项目都复杂、都真实。以前怎么做？只能给新人一个 APK 让他装手机上看，代码层面完全黑盒。现在怎么做？拿自家应用（有版权、可授权）建项目，生成源代码工程，AI 修复完成后保存 ZIP，导入 Android Studio——新人面前摊开的就是一个能编译、能跑、能改的真实工程。第一课的作业都可以很实在：把启动页文案改掉、构建、装机、看效果。一次课就把「改一行代码到看到效果」的完整回路走通了。

这个场景里断点续修同样关键：讲师白天演示生成、晚上关机，第二天上课前点「继续生成」把工程修完——教学节奏不会被一次没跑完的任务打乱。而 source_prompt.txt 还能当教具：打开给学员看，AI 收到的任务书长什么样、路径怎么给、验收标准怎么写——这本身就是一堂「如何给 AI 交代任务」的课。

十三、什么时候忍心推倒重来

「重新生成」按下去就是清空重修，所以值得一段专门的论述：什么情况真的该推倒重来？给三个判断信号。

信号一：源包变了。你重新导入了一个新版本的 APK，或者发现当初导错了包——source 对应的已经不是现在的源包，续修修的是一个过时的现场。此时必须重新生成，让 source 和源包重新对齐。信号二：方向性错误。第一轮修复的要求本身写歪了（比如让 AI 把第三方库全部内联，后来发现应该依赖化），越续修越远——这不是续修能救的，改提示词重来更干净。信号三：现场被污染。有人手工在 source 里大改过、或者 AI 上一轮把工程改得面目全非，盘点信息已经说明不了什么——干净的起点比混乱的续修便宜。

三个信号之外的任何情况，都请优先「继续生成」。一个朴素的成本账：续修只花「剩余工作量」，重修要花「全部工作量」再加「已修复内容的损失」。除非剩余工作量里包含「纠正方向」的成本，否则续修永远划算。推倒重来是战略决定，不该是默认动作。

十四、取消的姿势：随时能停，停了能续

生成窗口的下载、解压阶段都是可以取消的，取消的实现也讲究：结束进程时是整棵进程树一起结束——外层命令、解释器、里面的 Java 进程，一个不留。为什么要强调「树」？因为只杀外层进程的话，里面的 Java 还在后台默默跑着，占着内存、锁着文件，用户却以为已经停了。这种「僵尸干活」状态是长任务工具的经典暗坑。

取消之后的现场同样遵循「先临时后正式」的保护：临时目录里的半成品会被放弃，正式的 source 目录不动。下次再点，三按钮照常出现，「继续生成」照常可用。整条链路上任何一个点停下来，恢复的成本都不会高于「从头再来」——这是断点续修给用户的底层承诺。

把这条承诺和修改历史对照着看更有意思：改包需求有 history.ini 留原话，源码任务有 source_prompt.txt 留全文，工程现场有盘点信息留坐标。三个「留痕」拼在一起，意味着这个工具里没有任何长任务是非黑即白的——没有「必须一次跑完，否则作废」的悬崖，只有「修到哪、续到哪」的缓坡。对一个可能跑几十分钟的功能来说，这个性质比快慢重要得多。

十五、一张时间轴：从点击到交付的完整地图

把全流程按时间顺序铺开，任何一个环节中断后的去向一目了然：

阶段	干了什么	此时中断，下次点按钮会怎样
准备 jadx	已有就用，没有自动下载解压	从头走准备，已完成的不用重下
jadx 导出	先写临时目录，成功才替换 source	source 未被破坏；重来一遍导出
AI 修复中	按提示词修到构建通过，写成功标志	三按钮弹窗，选「继续生成」从断点接修
已修成未保存	提示成功，ZIP 已在项目目录	重开项目也会查标志，状态行有 ZIP 路径
已保存交付	ZIP 已另存，可进版本库	三按钮弹窗，一般选「取消」即可

看表的一个诀窍：第三列里没有一格写着「损失进度」。这就是设计的胜利——任何时刻停下，代价都只是时间，不是成果。拿着这张表，你可以放心地在任何环节去开会、吃饭、下班。

十六、关于期望管理：还原的源码长什么样

最后做一次期望管理，免得「源码还原」四个字造成误解。还原出来的工程，和「原作者手里的那份源码」不是一回事：变量名是 jadx 根据字节码推出来的，可能和原名不同；注释早就在编译时就丢光了；个别复杂方法可能来自 smali 对照修复，风格偏底层。它是「能编译、能修改、能再打包」的工程，不是「和原版一字不差」的工程。

这个定位对使用姿势影响很大。正确的用法是：把它当成「可以继续开发的新家底」——改名、改文案、换图、调逻辑、加功能，都在这个工程上做，改完构建出包，和智改工坊的改包链路无缝衔接。不正确的用法是：拿它去做和原作者源码的逐行比对，或者指望注释帮你理解业务——那一层信息在编译成 APK 的时候就已经不存在了，任何工具都变不出来。

期望摆正之后，这个功能的性价比就非常清楚了：你付出的是一次点击加一段等待，得到的是一个真实可维护的工程起点。对交接、教学、二次开发这些场景，这个起点已经足够好——毕竟在它出现之前，多数人的选择是「没有起点」。

十九、AI 到底在修什么：五件事逐条展开

提示词里的修复要求，展开来是五件具体的活。第一件，补齐 Gradle 工程：jadx 导出的工程只有源码和资源的骨架，构建脚本残缺、模块配置不全，AI 要把它补成一个标准的、可以构建的工程结构。第二件，第三方库依赖化：反编译会把 App 里打进来的第三方库也一起解成源码，和 Gradle 依赖引用撞出大量重复类——AI 要识别出这些库，把源码形态换成标准依赖声明，再删掉重复的部分。

第三件，修资源和资源引用：反编译导出的资源文件常有引用断裂——某个资源 ID 在代码里被引用、资源表里却对不上，编译就报错。AI 对照着 apktool 的 res 目录逐个理顺。第四件，smali 补缺：jadx 解不出来的那批方法（就是写进提示词的失败清单），拿 apktool 的 smali 产物对照着补出 Java 实现。第五件，也是压轴的，跑构建命令验证——修没修好不由感觉说了算，构建通过才算数。

这五件事的顺序本身就是一条流水线：工程结构先立起来、依赖清理干净、资源理顺、缺口补上、最后统一验收。理解了这个结构，你就明白为什么修复要花不少时间——这不是改几行文案的量级，而是把一个「散装的工程」重新组织成「能活的工程」。同理你也明白了断点续修为什么值得专门设计：这么长的流水线，中断概率天然就高。

给进阶读者的观察建议：续修两三轮之后，打开 source_prompt.txt 看每次追加的进度盘点，对比「有没有构建目录」「错误数变化」这些字段的演变——你能清楚地看到修复在这条流水线上走到了哪一站。这比盯着 AI 窗口等结果要心里有数得多。

二十、和「立刻修改」怎么分工：两条路的选法

详情页上「立刻修改」和「生成源代码项目」并排摆着，新手常问：什么时候走哪条路？给一个简单的判断框架。「立刻修改」是改包，目标是一个改好的 APK：换图标、改文案、调配置、去自家推广位，一次一件事，改完自动打包，快进快出。「生成源代码项目」是还原工程，目标是一个能继续开发的源码工程：适合后续要持续改很多轮、要进版本库、要交接给开发的场景。

打个比方：改包是「让裁缝改这件衣服」，源码还原是「把这件衣服的版型画下来，以后自己开厂」。改一两处的活找裁缝最划算；要长期做衣服，就得有版型。两条路不互斥——很多人先改几轮包验证想法，想法坐实了再还原源码正式开工，这个顺序性价比最高。

还有一条隐性规则值得点破：两条路的产物会合在同一个项目目录里。你完全可以先「生成源代码项目」，再在还原出的工程上继续用「立刻修改」改包——AI 拿到的现场更完整，改起来更有的放矢。反过来，纯改包攒了历史记录再还原源码，也不冲突。项目目录是同一个，历史、提示词、产物各归各位。

二十一、进了版本库之后：还原工程的交接建议

还原出的 ZIP 解开就是标准工程，进 Git 之类的版本库毫无障碍。但第一次提交前有几个建议动作，能省掉团队后来的很多扯皮。第一，首提交用「初始还原」单独打标签：把 AI 修复完成的原始状态定格成一个标签，之后任何人改坏了都能一键回到这个「出厂状态」。第二，README 里写一句来源：注明这个工程由哪个 APK 的哪个版本还原而来、还原日期——半年后没人记得这些，但排查「为什么这个工程和线上包行为不一样」的时候全靠它。

第三，把构建验证纳入交接流程：新接手的同事第一件事不是改代码，是拉下来跑一次构建——构建通过，说明交接成立；构建不过，立刻回查环境而不是怀疑人生。还原工程的可靠性是以「能构建」定义的，这个定义要一路传递下去。

这些不是软件功能，是围绕功能的使用纪律。工具把工程还原到「能编译」，版本库和实践把它维持在「能协作」——两段接力，缺一不可。带团队的朋友值得花十分钟把这个流程写成一段 Wiki，它带来的秩序感远超这十分钟的成本。

二十二、问答五连：使用中的小疑问

问一：续修会不会重复扣资源？续修走的是「继续生成」路径，它复用已有的 source 和档案，不重跑 jadx 导出，也就不会把已经做完的阶段重来一遍。中断的时间成本主要是「AI 重新读现场」的那一小段。

问二：我能手工看进度吗，还是只能干等？能看，而且很直接：打开项目目录的 source 文件夹，看文件修改时间是不是在推进；打开 jadx 日志看失败方法数；打开 source_prompt.txt 看最近一次盘点的现场数字。三个文件就是三块仪表盘。

问三：修好的工程想再改包，用哪条路？都可以。工程在项目里的话，「立刻修改」直接接着用，AI 对现场知根知底；工程已经拷走到别处开发的，改完打新 APK 重新导入建项目也行。项目目录的容纳能力比想象中大。

问四：为什么我的三按钮弹窗默认选的不是继续生成？默认就是继续生成，而且是回车直通的默认键。如果你看到别的组合，多半是 source 目录状态特殊（比如刚导入新包），按第三列的判断信号选就行——工具给的默认值在绝大多数场景里都是对的。

问五：这个功能对包的大小和复杂度有要求吗？包越大、越复杂，jadx 导出和 AI 修复的时间越长，但机制上没有硬门槛。真要说经验：第一次跑大包，选一个不着急的时间段（比如午休、会议），让它慢慢修——反正中断了也能续，时间上你并不被它绑死。

二十三、断点续修的普适价值：一个设计思想的展开

跳出这个功能本身，「断点续修」其实是整个安卓修改大师工具家族的一条底层思想。你会在很多地方撞见它的变体：改包需求写进历史、每条记录可回填，这是「需求层」的断点——哪天想照上次的再改一遍，一句话都不用重想；修改历史里原文完整显示不截断，这是「记录层」的断点；源码任务的提示词存档、进度盘点、成功标志文件，这是「工程层」的断点。三层断点指向同一个信念：用户的时间和成果，不应该因为一次中断而蒸发。

为什么这个思想值得专门讲？因为软件行业里反面教材太多：任务一中断全部作废、窗口一关配置全丢、进度条走完发现白跑。每遇一次，用户就被训练得更加不敢信任工具——只能用「一次跑完、全程盯守」的原始姿势使用一切长任务，人的时间被工具绑架。断点续修把这种关系倒了过来：工具迁就人的节奏，而不是人伺候工具的脾气。你可以开会、吃饭、下班，任务停在你的文件里等你。

识别一个工具有没有这种品质，有个简单的试金石：随便找个长任务，中途关掉它，再打开看现场。成果还在、状态可读、能从断点继续——及格；一切清零从头再来——不及格。安卓修改大师在这个测试里，从改包历史到源码还原，处处及格。这不是某个单点功能的功劳，是设计哲学的一致性。

二十四、还原不成功时：三层排查路线图

假设最坏情况发生了：续修几轮，构建始终不过，或者干脆报「生成失败」。别急着重装，按三层从外往内排查。

第一层，看生成窗口和 jadx 日志：失败发生在导出阶段还是修复阶段？导出阶段的问题看 jadx 日志的完整输出，里面连失败的方法名都有；修复阶段的问题进入第二层。

第二层，看 source_prompt.txt 与现场盘点：对照两轮续修的盘点数字——文件数在涨吗？构建目录出现过吗？错误数在降吗？如果三轮下来这些数字纹丝不动，说明 AI 在原地打转，续修已经失去意义，这时候「重新生成」才真正登上舞台：换个干净现场，或者调整你的要求再跑。

第三层，看原始材料：源包本身是不是特殊形态——加固过的、极度混淆的、资源加密的包，还原难度会成倍上升。这一层如果命中，最理性的选择是降低期望：改用「立刻修改」的改包路线完成手头的事，源码还原留给常规的包。工具的边界诚实地摆在那里，绕开边界比撞墙聪明。

三层的共同点是「有文件可看、有数字可比」。这个功能在可观测性上的投入，让失败也变成可推理的过程——你永远不是面对一个黑盒喊「为什么不work」，而是拿着三份材料做排除法。

二十五、把它嵌进一天：使用节奏建议

最后给一段实操节奏。早上到工位，先点「生成源代码项目」（如果昨天有断点，直接续），然后去泡茶——前几分钟是 jadx 导出的时间，人不在场最合适。回来瞄一眼进度，进 AI 修复阶段，就可以正常干别的活了：改包、开会、写文档，工具在自己的窗口里干活，互不打扰。

中午吃完饭看一眼：修复在推进就继续放着；下午三四点通常能等到「源代码还原成功」的提示，顺手保存 ZIP、打个版本库标签，这事就算落袋。如果中途任何环节卡住，按上一节的排查路线走一轮，五分钟内有结论。全天你真正花在这个功能上的注意力，大概就是「三次看一眼」。

这个节奏的要点不在效率，在于正确的注意力分配：长任务本该后台化，人的注意力应该留给判断——要不要续修、要不要重修、还原出的工程接下来怎么用。工具把执行层的焦虑都吸收掉了，判断层的事，才是人真正该操心的，也是目前阶段只有人能做好的。

再补一个团队协作的变奏：如果是几个项目都要还原，可以错峰排队——上午让甲项目的任务跑，中午续乙项目的，下午收两个。断点机制保证了排错了顺序也无损，最坏情况不过是某个项目晚半天拿到工程。相比「一台机器一次只能伺候一个大活」的传统模式，这种错峰玩法把等待时间叠掉了大半。

还有一个容易被忽略的小习惯：每次还原成功之后，花三十秒把「源包版本、还原日期、构建结果」记进项目备注或者团队表。这三十秒在半年后你翻出这个工程、想确认「它对应线上哪个版本」的时候，会显得价值连城。档案工作永远是当下最廉价、未来最感激的投入。

至此，断点续修的机制、纪律、排查与节奏都讲完了。它看似只是一个小弹窗上的三个按钮，背后却是一整套关于「如何对待中断」的工程答案。愿你的每一个长任务，都停得起、续得上、收得回。

愿它也改变你对「长任务」这个词的感觉：从今往后，再看到进度条慢慢走的窗口，你想到的不再是「千万别断」，而是「断了也无非续一次」。这份从容，才是工具在效率之外，真正交付给使用者的东西。

二十六、用户怎么说

从收到的反馈看，评价最集中的三点恰好是本篇的三个主角：断点续修让长任务敢中断、进度盘点让续修不返工、提示词档案让一切可回溯。用户用脚投票投出来的，从来都是这些「出事时刻」的体验。

二十七、写在最后

一个功能靠不靠谱，顺境里看不出来，看它怎么对待「没跑完」。临时目录保护上次的成果，进度盘点告诉 AI 现场在哪，续作纪律防止推倒重来，提示词档案让一切有据可查——四个机制围出一个结论：中断不是事故，只是暂停。下次三按钮弹窗出现时，希望你已经知道该点哪一个，以及为什么。

安卓修改大师智改工坊家族还有两位成员：智能修改安卓版装在手机和平板上，走到哪儿改到哪儿；经典版把反编译树完整摊开，资深玩家逐层动手。产品介绍页：https://www.apkeditor.cn/ai-version.aspx。只需说话，就能让应用变成你想要的样子。