生成源码工程还是保存源码：jadx 导出 AS 工程与源码 ZIP 的差别

把包改完、装到手机上，图标换了、名字换了、启动页也换了，一切看起来都对。这时候很多人会多问一句：源码呢？打开智能修改电脑版的详情页，和源码有关的入口有两个，一个叫「生成源码工程」，一个叫「保存源码」。两个名字只差两个字，点下去出来的东西却完全不是一回事。

一个是把现成的 APK 反推回 Android Studio 工程，另一个是把工具自己生成的源码目录压成一个 ZIP。选错了，轻则白折腾半天，重则以为工具坏了、把一份能用的源码当成垃圾删掉。这篇文章就把这两条路掰开讲清楚：它们各自处理什么、产出什么、适合谁用、最容易在哪一步想歪。

先把结论摆在前面。如果你要长期维护、二次开发、把改动固化成一份能继续迭代的工程，你要的是「生成源码工程」；如果你只是想把某个应用——尤其是用网址打包出来的应用——的源码留个档、备份一份、换台电脑接着用，你要的是「保存源码」。前者是逆向，产物是反推出来的工程，往往要补齐依赖才能编译；后者是正向，产物本来就能编译，压缩只是为了搬运和归档。

本文用智能修改电脑版演示整条链路。它运行在 Windows 10/11 64 位环境，安装包约 6.86 MB，需要 .NET Framework 4.6.2 以上；把 APK 拖进主窗口后自动反编译，按自然语言需求修改工程，再回编、对齐、签名、校验，并能自动装到手机或模拟器预览。我们要用的入口是详情页、项目目录、打包完成窗和打包日志，把「拿源码」这件事拆成可判断、可验收的步骤。

范围先说清楚：只处理自有版权或已获授权的应用。给自家应用换品牌、给内部工具换环境、给自己做的网址打包应用留源码，都是正常的技术工作；请勿用于破解他人付费应用、去除授权校验或绕过安全机制。越清楚这两条路的差别，越知道该在什么场景用它、不该在什么场景用它。

两个入口长得很像，产物却完全不同

打开智能修改电脑版的详情页，和源码有关的动作其实分成两组。一组针对你导入的那个 APK：把包里的代码和资源反推出来，整理成一个能在 Android Studio 里打开的工程目录。另一组针对工具自己生成的产物：把 AI 改完、并且已经打包成功的那个应用，它的源码目录原样压成一个 ZIP。

从名字上很难区分，因为它们都叫「源码」。但源码这两个字在这里有两种含义。对导入的 APK 来说，源码是「猜出来的」——工具看到的是编译后的字节码和二进制资源，它要做的是逆着编译的方向走一遍：把字节码翻译成可读的代码形式，把资源还原成可编辑的文件，再拼出一个工程骨架。对工具自己生成的应用来说，源码是「本来就有的」——它先是按你的需求生成了一份源码，再把它编译成 APK；ZIP 只是把那份已经存在、已经能编译的源码目录复制出来打包。

把这两件事放在一张表里对照，差别就清楚了。表格里每一行都对应一个实际会遇到的判断点，尤其是「能否直接编译」这一行，决定了你后面要走的是「修工程」还是「搬源码」。

对照项	生成源码工程	保存源码
动作对象	你导入的那个 APK	工具生成并已打包成功的应用
产物形态	一份 Android Studio 工程目录	一个 ZIP 压缩包
方向	逆向：APK 到工程	正向：源码到归档
能否直接编译	通常不能，要先补依赖和配置	能，本来就是可编译的源码
主要用途	长期维护、二次开发、固化改动	留档、备份、转移到别的机器
常见入口	详情页的工程导出	打包完成窗、成品详情页

图 1：同样叫「源码」，一个是反推出来的工程，一个是原样打好的归档包。

表格里最后一行值得单独说。「保存源码」用的不是反编译工具，就是普通的打包压缩，默认文件名会带上应用名，方便你在文件夹里一眼认出是哪个应用的源码；它的入口有两个，打包完成窗和成品详情页都能点。也就是说，你刚打完一个包，在「打好了」的那个窗口里就能顺手把源码存下来；过几天想起来要备份，也可以回到成品详情页再存一次。

而「生成源码工程」这件事，主角是 jadx 这类反编译工具。它面对的是别人编译好的 APK，输出的是一份需要你再动手的工程。这两条路的差别，本质上是「还原」和「搬运」的差别：还原要面对信息丢失，搬运只是换个地方放。

顺带说一个判断小技巧。当你看到「源码」两个字时，先问自己一个问题：这份源码是工具「猜出来」的，还是工具「本来就有」的？答案决定了你下一步该不该去修构建配置。猜出来的，一定要修；本来就有的，直接搬。

再补一句关于「预期管理」的话。很多人对「拿源码」的期待是「一键拿到一份能直接开发的完整工程」，但现实里，逆向永远有代价，正向永远要你先有源码。把期待调成「逆向给你一个能修的起点，正向给你一份能搬的存档」，你就不会在第一次编译报错时以为工具坏了，也不会在拿到 ZIP 时以为能直接导入 Android Studio。

「生成源码工程」：用 jadx 把 APK 反推成 Android Studio 工程

先说「生成源码工程」。它面向普通 APK 项目：你手上有一个 APK，想看它的代码、想改它、想把改动变成一份能继续开发的工程，就走这条路径。工具会用 jadx 把 APK 反编译，导出成一个 Android Studio 工程。这里的反编译其实包含两件事：一件是把编译后的字节码翻译回可读的源码形式，jadx 做的主要是这件事；另一件是把包里的资源、清单、原生库、assets 等一并还原，并摆成工程该有的目录结构。

导出的工程长什么样？大体上是 Android Studio 熟悉的那套：模块目录下有清单文件、有源码包、有资源目录、有 assets、有 libs；区别在于，源码是反推出来的，不是人写出来的，所以变量名可能是 a、b、c，注释基本没有，控制流也可能被打散，嵌套的匿名类会变成一堆带数字后缀的文件。这就是逆向产物的本来面目，不是工具没做好，而是编译这个过程本来就丢掉了这些信息。

更关键的一点是：导出的工程通常不能一打开就编译通过。原因有好几个，而且都很具体。第一，APK 里用的是编译过的资源索引和二进制资源，还原成可编辑资源之后，引用关系需要重新对上；第二，第三方依赖在 APK 里是「成品」，反推时只能拿到引用，拿不到原始的依赖声明，构建脚本里要手动补齐；第三，有些代码是从别的语言编译过去的，反推回来会留下不自然的写法，编译时可能报错；第四，清单里的某些属性、资源里的某些引用，属于「打包之后」的形态，需要按工程规范调整。

所以「生成源码工程」的正确定位是：它是一个起点，不是终点。它把 APK 拆成一份「结构对了、内容还要修」的工程，接下来的一步是把这份工程交给 AI 继续修，修到能编译、能打包。智能修改电脑版的价值也正在这里——它不是只给你一个导出的工程文件夹就结束，而是可以在这个工程上继续按你的需求迭代，把编译错误一条条消掉，直到重新打出包来。

适合谁用？主要是三类人。第一类是要长期维护的人：手上的应用已经没有原始工程了，只剩一个 APK，但业务还要继续跑，需要一份能改、能发版的工程。第二类是要做二次开发的人：在已有应用基础上加功能、换界面、接自家服务，需要把已有代码变成可编译的工程底座。第三类是要把改动固化成工程的人：不希望每次改动都从成品包上打补丁，而是希望有一份源码工程，改完直接编译出包，可追溯、可复用。

把「生成源码工程」这条路的几个关键点列一下，方便对照自己的情况。

一句话记住「生成源码工程」：它是从 APK 反推工程，产物是逆向的结果，需要补齐依赖、修好编译，才谈得上继续开发。别期待它开箱即用，要期待它给你一个能修的起点。

还有一个和「生成源码工程」常被一起问到的问题：导出的工程能不能直接拿去做加固或者上架？答案要看具体情况。导出的工程是反推产物，能不能通过后续的合规检查、能不能满足渠道的上架要求，取决于原应用本身的资质和你自己的授权范围，而不是取决于工具。工具负责把工程还原出来，授权和合规的判断在你手上。所以走这条路之前，先确认这个应用是你自己的、或者你已经拿到了明确的授权，再谈技术实现。

「保存源码」：把 AI 生成的源码目录压成 ZIP 留档

再说「保存源码」。这条路径和反编译没关系，它处理的是工具自己生成的应用。比如你用网址打包功能，把一个网站打成一个 Android 应用，工具先按你的配置生成一份应用源码，再把它编译、打包成 APK。这份源码是正向产生的，本来就完整、就能编译；「保存源码」做的事情，就是把这个源码目录原样压缩成一个 ZIP 保存下来。

它的入口有两个，这一点很实用。一个是打包完成窗：你刚打完包，窗口里会给出成品信息，也给出保存源码的按钮，顺手点一下就把源码存下来了，不用再回项目里翻。另一个是成品详情页：过几天你想起来要备份，或者要换台电脑接着改，回到成品详情页也能再存一次。两个入口指向同一件事，不会因为「当时没点」就彻底丢掉机会。

默认文件名带应用名，是为了让你少想一步。存源码最容易出的问题是「存了一堆 ZIP，过一阵不知道哪个是哪个」。文件名里带上应用名，再配合打包时间，基本上一眼就能认出来。如果你同时维护多个应用，建议在保存之后按「应用名加日期」再整理一层目录，或者干脆连打包日志一起归档，后面找起来更快。

这条路径最适合三种场景。第一是留档：把网址打包出来的应用源码留一份，将来要改文案、换图标、改内嵌地址，都有源码可改，不用从 APK 反推。第二是备份：源码是比 APK 更根本的东西，APK 丢了可以重打，源码丢了就真的没了。第三是转移：换电脑、交接给同事、搬到另一台机器上继续做，一个 ZIP 拷过去就能接着用。

• 要留档：以后还要改文案、换图标、改内嵌地址，有源码就不用从 APK 反推
• 要备份：源码比成品包更根本，成品丢了能重打，源码丢了就真没了
• 要转移：换机器、交接同事，一个 ZIP 拷过去就能接着做

这里要强调一个前提：「保存源码」保存的是「工具生成的源码」，不是「任意 APK 反推出来的工程」。它不解决「手上只有一个 APK、没有源码」的问题，那个问题要用「生成源码工程」。两者的输入完全不同：一个需要你有源码，一个需要你能接受反推。这一点在下一节会再展开。

还有一个细节值得注意：ZIP 里装的是源码目录，不是成品 APK。有些朋友存完之后只记得「我存过一个包」，下次直接拿 ZIP 当成品发给别人，别人解压一看是源码，还得自己编译。归档时最好把「源码 ZIP」和「成品 APK」放在同一个目录里，文件名都带上应用名和版本，别人拿到就清楚哪份是源码、哪份是能装的包。

再补一个实用习惯：保存源码的时候，顺手把「生成时用的配置」也记一笔。比如网址打包用的入口地址、应用名、图标来源、版本号，这些信息在源码里不一定都显眼，写在一张随源码一起归档的说明里，将来别人接手或者自己回头改，都不用重新猜。说明不用长，几行字就够，但能省掉很多来回确认。

图 2：保存源码的入口就在手边——打包完成窗和成品详情页都能点。

一条是逆向、一条是正向：差别到底在哪

把两条路并排走一遍，差别会更直观。假设你手上有两个东西：一个是别人给你的、或者很久以前做的 APK，已经没有源码了；另一个是你今天用网址打包功能刚做出来的应用，源码就在工具手里。前者对应「生成源码工程」，后者对应「保存源码」。

逆向那条路的关键词是「还原」和「补齐」。工具要从编译产物里把信息挖出来，凡是编译时被丢掉的东西，比如原始变量名、注释、依赖声明、构建配置，它都只能猜或者留空。所以逆向产物一定带着「需要修」的标记：能编译最好，不能编译是常态，需要你补依赖、调引用、改配置。这条路的价值不在于「一步到位」，而在于「把不可能变成可能」——一个只有 APK 的项目，从没有源码变成有一份可以继续开发的工程。

正向那条路的关键词是「搬运」和「归档」。源码本来就是完整的，工具只是把它复制出来、压成一个包。所以正向产物一定是「能编译的」，因为它本来就是编译过的。这条路的价值不在于「把不能变成能」，而在于「把已有的东西妥善保存」——源码不丢、随时可改、换机可用。

还有一个容易被忽略的差别：版本对应关系。逆向出来的工程，对应的是「你导入的那个 APK 的当前状态」。如果那个 APK 已经被别人改过、加固过、或者做过混淆，导出的工程就带着这些痕迹。正向保存的源码，对应的是「你最后一次生成时的配置」。如果之后你又在工具里改了需求、重新打了一次包，那旧的 ZIP 就落后了，要重新保存一次。两条路都要求你清楚「这份源码对应的是哪一版」。

下面这张表把两条路最容易踩的坑也一并列出来。你会发现，坑的位置刚好和产物形态对应：逆向的坑在「能不能编译」，正向的坑在「能不能当工程用」。

维度	生成源码工程	保存源码
输入	你导入的 APK，须自有版权或已授权	工具生成并已打包成功的应用
用到的工具	jadx 等反编译工具	普通压缩，无外部依赖
产物能否直接编译	通常不能，要补依赖与配置	能，本来就是可编译源码
典型后续动作	交给 AI 修到能编译、能打包	归档、备份、拷到别的机器
最容易踩的坑	以为导出即可编译	以为 ZIP 能导入 Android Studio
对应的验证方式	先编译一次，记下基线报错	解压后目录完整、能在别处继续生成

判断自己该走哪条路，有一个很简单的问法：你手上有没有「能编译的源码」？有，就走「保存源码」，把它存好、备份好；没有，只有一个 APK，就走「生成源码工程」，先把工程反推出来。如果两个都有，那通常是要做长期维护，两条路配合用：先保存源码存档，再在工程上迭代，一个管「不丢」，一个管「能改」。

两条路还有一个使用节奏上的差别。逆向那条路是「一次性投入大、后面省」，因为补齐依赖和清基线要花时间，但一旦工程能编译，后面每次改动都很轻。正向那条路是「每次都很轻」，打包完顺手存一份，几秒钟的事，但它的前提是你确实有源码。所以对同一个项目，比较理想的组合是：先用网址打包或源码方式把应用做出来，每次打包都存一份源码归档；等到哪天源码真的丢了、只剩一个 APK，再用「生成源码工程」把工程反推回来。前者是日常，后者是补救。

还有一种情况值得单独提：你手上既有源码，也有一个已经发布出去的旧版 APK，而源码和旧版对不上。这时候不要急着反推，先把源码和成品对齐一次，确认「源码能编译出和线上行为一致的包」，再谈改动。反推是最后手段，不是第一选择。能用源码解决的问题，就不要用逆向去解决，因为逆向产物永远带着信息丢失的代价。

三个最常见的误区：ZIP、开箱即编译、跳过首次编译

说完差别，说三个真实高频的误区。它们不复杂，但几乎每个新手都会踩一次，因为两个入口的名字实在太像，而「源码」这个词又太笼统。

误区一：把源码 ZIP 当成可以导入 Android Studio 的工程。有人拿到「保存源码」产出的 ZIP，直接在 Android Studio 里选「导入工程」，结果当然不行。因为要导入的是「生成源码工程」产出的那份工程目录，ZIP 只是源码的归档包，解压出来是给你看、给你改、给你搬家的，不是给你当工程导入的。正确做法是：要导入工程，先走「生成源码工程」；要留档备份，走「保存源码」。两个包长得都很像「源码」，但一个不该往 Android Studio 里塞。

误区二：把导出的工程当成开箱即编译。逆向产物不能编译，是常态而不是故障。有人导出工程，打开 Android Studio 点一下编译，看到几十条红色错误，第一反应是「工具坏了」。其实那些错误大多集中在三类：缺依赖、资源引用对不上、反推代码里有不合法的写法。这些都是「补齐」的活儿，不是「导出失败」。判断导出是否成功，看的是工程结构是否完整、代码是否可读，而不是第一次编译有没有过。

误区三：导出工程后，没有先跑一次编译就继续改。这是最贵的一个误区。很多人导出工程后直接开始改需求，改了一大堆，最后编译，报错几百条，这时候根本分不清哪些错是「导出时本来就有的」，哪些错是「自己改出来的」。正确顺序是先编译一次、把导出自带的问题摸清楚、记下来，再动需求。这样后面每加一处改动，出错都能立刻定位。

顺序比技巧重要：先导出、再编译、把自带问题清一遍，然后才进入 AI 迭代。跳过中间那一步，后面所有报错都会变成一笔糊涂账，你连「是自己改坏的还是本来就这样」都说不清。

图 3：归档包不是工程，导出工程也不是开箱即编译，改之前先建立编译基线。

这三个误区其实指向同一件事：把「逆向产物」和「正向产物」混为一谈。ZIP 是正向产物，别当工程用；导出的工程是逆向产物，别期待它开箱即用；改之前先编译，是为了给逆向产物定一个基线。想通这一点，三个坑就都绕开了。

再补一个容易被当成「误区」的正常现象：导出的工程里，有些类会集中在一个很长的文件里，有些方法名是纯字母编号，这不是导出出错，而是反推时找不到原始结构。你不需要把所有名字都改回「好看」，只需要保证编译通过、行为正确。把精力花在功能上，不要花在给变量重新起名上。

还有一个细节值得提醒：不要把「导出工程」和「保存源码」混在同一次操作里做。有些朋友导出工程之后，顺手把工程目录压成一个 ZIP，然后就管它叫「保存源码」。这样做不是不行，但它和工具里的「保存源码」不是同一件事：工具里的保存源码针对的是生成的应用源码，本来就是能编译的；你自己压的工程 ZIP 是逆向产物，解压出来还是要先修编译。归档时最好把两者分开命名，一个叫「工程导出」，一个叫「源码归档」，避免以后自己都分不清哪份是哪份。

导出工程后的第一件事：先在本地编译一次

前面反复提到「先编译一次」，这里把它写成可以照着做的步骤。目的很单纯：在动手改之前，先知道这份导出的工程「自带哪些问题」。这个基线一旦建立，后面每改一处，你都能判断是自己改出来的还是本来就有的。

1. 确认工程结构完整。打开导出的工程目录，检查清单文件、源码包、资源目录、assets、libs 是否都在。缺目录说明导出不完整，先重新导出一次，不要在残缺的工程上继续改。预期结果是目录齐整、能看出模块划分；失败通常是导出中断，重新跑一遍即可。
2. 补齐依赖声明。看构建脚本里声明了哪些依赖，对照源码里引用到的第三方库，把缺失的补上。补依赖的原则是「版本对齐」：尽量选与被反推 APK 时代接近的版本，避免接口不兼容。预期结果是构建脚本能解析通过；失败就逐个库去对，不要一次补十几个。
3. 配置构建环境。确认 JDK、构建工具、编译 SDK 版本与工程要求一致。版本不匹配的报错往往出现在编译最开始，比如找不到某个构建插件、或者语法不支持，这类错误先解决，别急着改业务代码。
4. 跑一次完整编译。不要只编译单个模块，跑一次能出包的完整编译。把报错按类型分组：缺依赖、资源引用、代码写法、清单属性。分组之后你会发现，同类的错往往一个改法能解决一批，效率比逐条修高得多。
5. 记录基线。把「第一次编译的报错清单」和「解决每个报错做了什么」记成一份文档，放在工程根目录。这份文档就是后面 AI 迭代的对照表，也是交给同事的交接材料，比口头说明可靠得多。
6. 确认能出包再继续。基线清完之后，确认工程能打出一个能安装的包，再进入需求修改。如果暂时打不出包，也要记录「卡在哪一步」，不要带着一堆未知错误继续往上加改动。预期结果是产出一个能装能开的包；失败就回到前一步，先把编译问题解决干净。

基线清完之后，还有一个动作建议一起做：把工程里「明显是反推痕迹」的地方标注一下。比如某个类文件特别长、某些方法名是纯字母，或者某处代码写着明显是编译器生成的写法。不用改，只要在基线文档里记下位置，将来改动碰到这些地方时心里有数——它们不是写得差，而是反推的必然结果。区分「反推痕迹」和「真的错误」，能省下大量无谓的重构时间。

把常见报错和对应的处理方向整理成一张表，第一次做的时候可以照着对。你会发现，绝大多数报错都属于这五类，真正需要「想很久」的很少。

报错类型	典型表现	处理方向
缺依赖	找不到符号、找不到类	补构建脚本里的依赖声明，版本对齐
资源引用	找不到资源、资源标识不匹配	核对资源名与引用，按工程规范调整
代码写法	语法错误、类型不匹配	修反推代码里不合法的写法
清单属性	清单报错、属性不认识	按当前编译 SDK 的要求调整清单
环境问题	插件缺失、SDK 版本不符	对齐 JDK、构建工具、编译 SDK 版本

图 4：第一次编译的意义是建立基线，把报错分组，而不是逐条硬啃。

关于「能不能出包」，有个实用建议：不要等到全部改完才第一次打包。基线清完，就先打一个包、装一次、跑一遍，确认「这份工程本身是能用的」。这一步花的时间不多，但能让你后面所有改动都站在一个可靠的地基上。反过来，如果地基都没验过，后面每出一个问题你都要怀疑两层：是工程本身不行，还是自己改坏了。

还有一点：不要用「改成品包」代替「改工程」。有些人嫌补依赖麻烦，就直接在成品 APK 上打补丁，改一次打一次补丁，越改越乱，最后没人知道线上那一版是怎么来的。工程的意义就是让改动有迹可循，改完能重新编译出包。既然走了「生成源码工程」这条路，就把工程修好，别绕回去做一次性补丁。

把基线文档和工程一起放进版本库，还能解决一个长期痛点：换人接手。同事拿到工程时，先看基线文档，就知道「这份工程哪些地方是反推来的、哪些地方被改过、哪些坑已经踩过」，不用从零摸一遍。一份好的基线文档，能省掉后来者好几天的时间。

改完仍然走打包四步，产物写进 pack.log

不管是哪条路拿到的源码，最后要变成能装的应用，都得经过打包。智能修改电脑版的打包是固定的四步：先把工程编回 APK，再对包做对齐，然后用选定的方式签名，最后校验签名是否真的生效。全过程写进 pack.log，哪一步失败、失败在哪，翻日志就能看到。

为什么要有第四步校验？因为前三步只告诉你「命令执行完了」，不告诉你「到底签上没有」。密钥格式写错、别名填错、口令不对，这些错误前三步可能只给一句含糊提示，而校验那一步会明确报出来。多这一步，是为了在把包发给别人之前，先自己确认签名是真的生效了，而不是以为生效了。

四步的分工和排查入口列在下面。养成「失败先看对应日志」的习惯，比反复重试有效得多。

步骤	做什么	失败时先看什么
回编	把工程编回未签名的 APK	工程里的资源与代码错误，看反编译日志
对齐	对包做 4 字节对齐	输入包是否存在、上一步是否真的成功
签名	按选定方式给包签名	密钥格式、别名、口令是否正确
校验	打印证书，确认签名生效	证书摘要是否与预期一致

签名有四选一：默认签名、JKS 或 keystore、PEM 加 PK8、随机签名；支持 v1/v2/v3/v4，默认签 v1 加 v2 加 v3。做长期维护时，建议固定用同一份 JKS 或 keystore，并把密钥文件和口令妥善备份。换密钥会导致覆盖安装失败，用户看到的是「应用未安装」，而且这个错误在改包阶段完全看不出来，只有装的时候才暴露。口令通过环境变量传入，不会拼进命令行和日志，这一点在团队协作里尤其重要，不要把口令写进需求文本或项目说明里。

打包日志要和源码一起归档。源码对应「怎么做的」，日志对应「做出来的是什么」。两者放在一起，出了问题能快速回溯：是工程改动引入的，还是打包环境变了。养成「一份源码、一份日志、一份成品」一起存的习惯，比事后靠记忆强得多。时间一长你会发现，最值钱的不是那一次成功的包，而是那份能复现的记录。

如果是团队协作，建议给打包产物定一条命名规则，比如「应用名、版本号、日期」，源码 ZIP 用同一套前缀。这样即使过了一年，翻归档目录也能一眼看出「这个包对应哪份源码」。规则不用复杂，关键是全队都按同一套来，别各写各的。

顺带说一个常被忽略的点：打包失败时不要急着换参数重试。先看日志定位到是哪一步，再决定改什么。回编失败大多是工程内容问题，改参数没用；签名失败大多是密钥或口令问题，重试也不会自己好；对齐失败往往是上一步没成功，先确认输入包存在。一次只改一个变量，改完重跑，这样每次失败都在告诉你一点信息；反过来，同时改三四个参数再重试，即使成功了也不知道是哪个改对了。

每个项目一个独立目录，source.apk 是最后的退路

智能修改电脑版给每个项目建一个独立目录，目录名是一串 8 位随机字符，里面写配置文件和历史文件，并把原始包复制成 source.apk。反编译在专门的目录里进行，日志也写在那里。项目之间互不干扰，一个项目改坏了，不影响另一个，这一点在做多条产品线的时候很重要。

source.apk 这个设计值得单独讲。它是你导入时那份原始包的副本，从项目建立的那一刻起就一直在那里，不会被后续的反编译、修改、打包覆盖掉。它的意义是「最后的退路」：不管工程改成什么样、打包失败多少次，你都可以回到 source.apk，重新开始，或者把改动前后的产物对比着看。

因此有两条纪律。第一，不要手动去改 source.apk，也不要拿它当成品包用——它是基线，不是产物。第二，发布时认准打包产物目录里的那个文件，不要从临时目录、也不要从 source.apk 里拿包发出去。发布前核对文件名、大小和版本，避免把原始包当成品发出去这种看起来低级、实际上很容易犯的错误。

项目历史记录的是你的改动，只保留用户原话。它的用处是「复现」：某个改动是在哪一次需求里做的，翻历史就能找到。配合历史查看和回填功能，你可以把上一次的需求调出来改一改再跑，不用重新描述一遍。对于反复迭代同一个应用的人，这个功能省下的时间比想象中多。

还有一点和源码导出直接相关：既然每个项目是独立目录，那「生成源码工程」导出的工程、以及反编译产生的中间产物，都会落在项目目录里。整理归档时，按项目目录整体打包，比零散地拷文件可靠得多。删项目时工具只允许删项目目录下的直接子目录，这个限制看起来麻烦，其实是在防止误删工作目录里的其他东西——宁可多一步确认，也不要一次手滑删掉别人的数据。

图 5：原始包始终保留，是改坏了之后唯一的退路；产物认准打包目录。

把这几件事连起来看，逻辑很清楚：项目目录保证「不互相污染」，原始包保证「有退路」，日志保证「可追溯」，源码导出保证「能继续开发」。四样凑齐，一个改包项目才算是可持续的，而不是一次性的。

如果项目比较多，建议在项目之外再建一层自己的归档目录，按应用分文件夹，每个应用下面放「源码」「日志」「成品」三个子目录。工具的项目目录是工作区，会随着改动不断变化；你自己的归档目录是档案区，只放确认过的版本。两者分开的好处是：工作区改坏了不影响档案区，档案区也不会因为清理工作区而丢东西。这个习惯听起来普通，但它是「源码不丢」最实际的保障。

实例一：自家教学 App 从成品包到可维护工程

第一个实例是自家的教学 App，包名 com.example.course，只在校内平板分发。它是一个早期项目，原始工程早就找不到了，只剩一个 APK；现在要把界面文案统一成新品牌名，把英文界面做中文本地化，还要加一个内部才有的登录入口。这种情况就是典型的「只有一个 APK，但要继续开发」，走的是「生成源码工程」这条路。

以前怎么做：手工反编译，把包里的字节码转成可读源码，再手动拼一个工程目录。最麻烦的是依赖——打包进去的第三方库只能看到引用，看不到依赖声明，构建脚本要一条条试。最耗时间的是资源引用，界面里几百个引用要逐个对。前后折腾了一个多星期，中间放弃过两次，最后交出来的工程还是不能编译，只能靠改小段代码打补丁，改一次、装一次、验一次，效率极低。

现在怎么做：用智能修改电脑版导入这个 APK，走「生成源码工程」，用 jadx 把包反推成 Android Studio 工程。拿到工程后，先在本地编译一次，把导出自带的问题分组清掉——补依赖、对资源引用、修不合法的代码写法，并把报错清单记成一份基线文档。基线清完，再在详情页写需求：把界面文案统一成新品牌名、把英文界面做中文本地化、加内部登录入口，然后交给 AI 迭代，改完重新走打包四步出包。

改完怎么验证：第一，工程能在本地编译出包，且打包四步在 pack.log 里都有成功记录，最后一步打印出的证书摘要与预期一致；第二，装到平板上，系统设置里应用名和包名与预期一致，没有出现「应用未安装」；第三，逐个页面走一遍，确认文案是新品牌名、界面是中文；第四，从内部登录入口进得去，退出后不影响原有功能；第五，把成品包与 source.apk 并存归档，工程目录连同基线文档一起存进版本库，交给同事也能接着做。

这个实例最值得记住的是「基线」这一步。以前没有基线，改一处、编译一次、报一堆错，根本分不清是谁的问题；现在先编译一次、把自带问题清掉、记成文档，后面每加一个改动，出问题都能立刻定位。工程能不能长期维护，很大程度上就取决于有没有这份基线，而不取决于工具多快。

实例二：自家记账 App 的源码留档与转移

第二个实例是自家的记账 App，包名 com.example.ledger。它本来是用网址打包功能做出来的——把自家的记账网页打成一个 Android 应用，配好图标、应用名和启动页，编译打包后装在自己和同事的机器上用。现在要做两件事：一是把源码留档，二是换台电脑继续维护。这种情况走的是「保存源码」这条路。

以前怎么做：源码散在生成目录里，没有统一归档。想改个文案，得找到当时那台电脑上的工作目录；换电脑时整目录拷过去，路径一变又跑不起来；有两次因为清理磁盘，把源码目录删了，只能从 APK 反推，白白多花了好几天。问题的根子不是工具不行，而是「源码没有一份明确的归档」——东西都在，但没人知道它在哪、哪一份才是最新的。

现在怎么做：打完包之后，在打包完成窗里直接点「保存源码」，把 AI 生成的源码目录压成一个 ZIP，默认文件名带应用名，一眼能认出是哪个应用。过几天想起来要备份，回到成品详情页还能再存一次。存完之后按「应用名加日期」整理目录，把源码 ZIP、打包日志和成品 APK 放在一起，换电脑时整个目录拷过去就能接着改。因为这份源码本来就是能编译的，新机器上只要环境一致，就能继续生成和打包。

改完怎么验证：第一，ZIP 解压后是完整的源码目录，包含清单、源码、资源和配置，目录结构没有缺项；第二，在另一台电脑上解压这份源码，能按同一套环境继续生成和打包，产物行为一致，说明这份归档是可用的而不是死档；第三，把成品包与源码放在同一归档目录，从源码到成品这条链路可追溯；第四，确认归档里同时有源码、日志和成品，三样齐全才算一份完整的留档。

这个实例最值得记住的是「入口就在手边」。保存源码不需要额外找工具、不需要记命令，打包完成窗和成品详情页都能点。很多源码丢失并不是因为没打算保存，而是因为「当时懒得去找」，等到需要时已经晚了。把保存源码变成打包流程的固定一步，这类问题就自然消失了。

两个实例放在一起看，刚好覆盖了两条路：一个是「没有源码、要从 APK 反推工程」，一个是「本来就有源码、要把它存好搬走」。它们用的入口不同、面对的难点不同、验收的方式也不同。分清楚自己在哪一边，比记住任何一个操作步骤都重要。

图 6：一个从 APK 反推工程，一个把已有源码留档，两条路的验收标准完全不同。

最后给一张可以照着做的对照清单。下次打开工具，先在这张清单上选一条路，再动手，能省掉大量返工。

用户评价：用过这两条路的人怎么说

安卓修改大师智改工坊把「拿源码」这件事分成两条清晰的路。要长期维护、二次开发，就用「生成源码工程」，把 APK 反推成 Android Studio 工程，补齐依赖、先编译一次，再交给 AI 迭代；要留档、备份、转移，就用「保存源码」，把生成的应用源码压成带应用名的 ZIP，打包完成窗和成品详情页都能存。两条路的差别、用法和常见误区，官网介绍页 www.apkeditor.cn 上有更完整的说明，也可以直接看 安卓修改大师智改工坊的介绍与下载页。

只需说话，就能让应用变成你想要的样子。把源码这件事想清楚，改包就不再是一次性的手艺活，而是一条能反复走、能交接、能追溯的路。