很多新手对“AI 改包”的想象是：拖进去，说一句话，等一会儿，桌面上就多了一个新应用。真正第一次操作时，问题往往出在更朴素的地方：工具链有没有装全，工作目录选在哪里，APK 有没有解析成功，项目名和目录是什么关系，需求写得够不够具体，AI 改完没有，签名有没有签上，装到手机上是哪个环节失败。这篇文章不讨论概念，只按你会在界面上遇到的顺序，把七个步骤拆开，逐步说明点哪里、正常会看到什么、失败时先查什么。

阅读之前先约定三件事。第一，示例里的 APK 都是团队自家开发或已获得授权的应用，文中不会教你去改别人的商业应用，也不会教你绕过付费与安全机制。第二，教程假设你有一台 Windows 电脑、一部开启开发者选项的安卓手机，或者一个可用的模拟器。第三，所有操作都以“能安装、能启动、能复核”为终点，不以“界面上出现完成提示”为终点。把这三条放在心里，后面的每一步都会更稳。

一、七步路线图：先知道自己正站在哪一步

把第一次改包拆成七步，不是为了把简单事情复杂化，而是因为这条链路里每一段都有独立的输入、输出和失败方式。工具链没准备好，后面所有按钮都可能点不动；APK 没解析成功，项目卡片上的图标和包名就是错的；项目没建好，AI 没有可以修改的工程树；需求写偏了，AI 会在错误的位置努力；附件说明不清，它可能把启动图当成图标；完成信号没等到就重复点击， history 里会多出几条互相冲突的记录；打包和装机没有逐段核对，最后只能看到一个笼统的“失败”。

下面的表把七步、每一步的产物、以及失败时最该看的证据放在一起。第一次操作时建议把这张表当作路线图：每完成一步，确认这一行的“你会看到”真的出现了，再进入下一步。不要因为界面上有动画、有进度条，就默认事情已经成功；也不要因为某一步慢了一点，就立刻重复点击。改包是一条流水线，流水线最怕的不是慢，而是同一道工序被并行触发两次。

这张表里最容易被忽略的是“产物”这一列。新手常常只盯着界面上的状态文字，而老手会直接打开项目目录，看文件是不是按时出现、内容是不是合理。比如拖入 APK 之后，真正被解析出来的是图标、包名、版本这些结构化信息；填完项目名之后，真正被创建的是磁盘上的项目目录和原始包副本；点“立刻修改”之后，真正被传递的是写进文件的原文和日期；AI 干完活之后，真正可靠的完成信号是项目目录里的一个标志文件，而不是聊天区最后一句“完成了”。理解这一点，你就不会在错误的地方等待。

给第一次操作的你：把每一步都当成一次“交接”。上一步没有交出合格的产物，下一步就不要开始。改包链路里最贵的不是时间，而是一次失败之后你不知道该回退到哪一步。

二、第一步：准备工具链与登录，别让环境背锅

第一步看起来最没有技术含量，却决定了后面六步的稳定性。安卓修改大师电脑版的安装包约 6.86 MB，双击安装后启动。第一次运行，程序会优先替你把工作目录定下来：按 D、E、F、G、C 的顺序找盘，取第一个可读写、剩余空间不少于 1 GB 的位置，然后在里面建立 tools 和 Project 两个子目录。tools 用来放工具链，Project 用来放每一个改包项目。这个自动选择很实用，但你要知道它选了哪里，因为后面所有“文件去哪了”的问题，答案都在这里。

如果你希望项目放在指定位置，可以打开参数设置，在工作目录一项里改。改完之后，建议重新跑一次工具链体检，确认新目录下工具仍然能被找到。电脑版会在工作目录和常见位置递归搜索工具链，换目录本身不会破坏工具，但如果你把目录指到了一个权限受限、空间不足或者会被同步盘频繁占用的位置，后面的反编译和打包就可能变慢甚至失败。对第一次操作的人来说，最稳妥的选择是本机固定磁盘上的一个短路径，例如 D:\ApkWork，不要放在桌面同步目录、网络盘或压缩包挂载出来的临时盘里。

参数设置里还有两项值得第一次就确认。一是配色主题，电脑版提供极夜蓝、深海蓝、紫罗兰、樱花粉、烈焰红、落日橙、古铜金、青柠绿、薄荷绿、石墨灰十套配色，它只影响界面观感，不影响产物，但选一个你能长时间盯着看的主题，会让排错舒服很多。二是首页提示条开关，如果你已经把流程记熟，可以关掉；第一次操作建议保留，它会提醒你工作目录和工具链状态。

关于登录，第一次启动时按界面上的登录提示完成即可。这里要建立一个正确预期：登录解决的是“当前使用者是谁”和“功能是否可用”，不会把你的项目上传到某个你看不见的地方。项目本身仍然落在你设置的工作目录里，源码工程、原始包、打包产物和日志都在本机。也正因为如此，换电脑、重装系统之前，要像备份普通文件一样备份 Project 目录，而不是指望登录之后自动回来。

工具链体检是这一步的核心动作。点开体检，你会看到 aapt、apktool、zipalign、apksigner、adb 以及 Java 运行环境等条目，每一项通常会显示是否可用、版本号或路径。第一次安装后如果出现缺失，先不要急着重装整个软件：打开工作目录下的 tools，看对应工具是否存在；再打开工作目录旁的 error.log，看程序在搜索工具链时是否遇到了权限或路径问题。电脑版支持自动搜索，但自动搜索也有边界，放在受保护目录、被杀毒软件隔离、或者路径里含有特殊字符时，它可能找不到。

设备准备同样属于第一步。手机进入设置，连续点击版本号打开开发者选项，再打开 USB 调试；用数据线连接电脑，手机上弹出授权对话框时勾选“始终允许”。然后在终端里执行 adb devices，正常会看到一行序列号加 device。如果显示 unauthorized，说明授权没有点；如果完全为空，先换线、换 USB 口，再检查驱动。模拟器也可以作为验收设备，电脑版在打包后会优先把模拟器窗口提到最前，手机则通过 scrcpy 投屏，让你在电脑上直接看启动效果。

这一步失败怎么查？把问题分成三类。第一类是“工具找不到”，看体检里具体缺哪一项，去 tools 目录确认文件是否存在，再看 error.log 里的搜索路径；如果是杀毒软件误隔离，把工作目录加入信任列表后重启程序。第二类是“目录不可写”，表现通常是项目创建到一半失败，或者日志写不出来，换一个本机固定磁盘的短路径即可。第三类是“设备连不上”，先看 adb devices 的输出，再换线换口，最后才考虑驱动；不要在没有确认设备状态的情况下反复点安装，那只会让你误以为打包失败。

还有一个小细节值得在第一轮就养成：给工作目录做一个简单的约定，例如 Project 下只放改包项目，不往里塞截图、文档和临时压缩包。电脑版删除项目时只允许删除 Project 的直接子目录，这是保护机制；你放进去的杂物不会被当成项目，但会让目录看起来混乱。第一次改包时保持目录干净，后面翻日志、找产物会快很多。

三、第二步：拖入 APK，先让 aapt 把包看明白

环境准备好之后，第二步只有一个动作：把 APK 拖进主窗口。电脑版支持的导入格式不止 APK，还包括 JAR、APKS、XAPK、APKM 和 CLASS；第一次练手建议只用普通的单 APK，因为分包容器涉及 base 包与 split 包的选择，等单包流程走通之后再碰会更稳。拖入的瞬间，程序不会立刻开始修改，而是先调用 aapt 读取这个包，把“它是什么”弄清楚。你可以把这一步理解为挂号：先登记应用名、包名、版本和启动入口，后面的医生才知道该看哪一科。

aapt 读出来的信息会填进项目卡片，通常包括应用图标、应用名、包名、版本名、版本号、目标 SDK、最小 SDK，以及启动页对应的组件。应用名和包名是最容易被混淆的一对：应用名是桌面上显示给人看的文字，包名是系统里唯一的身份标识。版本名是给人看的，例如 2.3.1；版本号是给系统比较新旧的整数，升级安装时系统只认版本号。启动页则是点击图标后最先被拉起的 Activity，后面打包完成自动拉起、以及你手动执行 am start，都依赖这个组件名。

图标这一项值得单独讲，因为它是新手第一次改包最容易翻车的地方。一个 APK 里往往不止一套图标：mipmap-mdpi、hdpi、xhdpi、xxhdpi、xxxhdpi 各有一份，有的应用还会提供 anydpi 的自适应图标。电脑版的做法是取最高密度的原图，这样你在卡片上看到的是清晰版本，后续替换时也有足够的像素可用。但这里有一个 aapt 的历史细节：在某些资源表里，密度的数值 65534 是一个“任意密度”的哨兵值，意思是这张图不按固定密度归档，而不是“比 xxxhdpi 更高”。如果把它当成最高密度直接排序，就会选错图，甚至选到一张占位图或矢量定义。程序对这种情况做了单独处理，不会把 65534 当作密度冠军。

为什么这个细节对你有用？因为当你在项目卡片上看到一张模糊的、空白的或者明显不对的图标时，你就能判断问题出在“资源解析”而不是“你拖错了文件”。先确认 APK 里到底有没有高分辨率图标，再决定是换一个包、还是接受当前图标并在后续用附件替换。第一次改包时，建议打开项目卡片里的图标预览，和手机上原应用的桌面图标对比一下；如果两者一致，说明解析没问题，可以继续。如果不一致，先不要急着写需求，否则 AI 可能会在一个错误的基准上替换资源。

拖入之后还会发生一件看不见的事：程序开始为反编译做准备。事实数据里，一个 12 MB 左右的包实测大约 3 秒完成反编译；如果超过 10 分钟还没有结束，程序会中断并报错。这个上限不是为难你，而是防止一个损坏的包、一个异常的资源或者一个卡死的子进程把界面永远挂住。第一次操作时，请把“等待反编译”当成正常步骤，不要在进度没有变化时连续拖入同一个包；重复拖入只会产生多个项目，让后面的项目列表和日志更难辨认。

如果卡片没有出现，或者出现的是空白卡片，按下面的顺序查。先看文件本身：APK 是否完整下载，能不能用系统工具正常打开，文件大小是否明显偏小。再看格式：APKS、XAPK、APKM 是容器，里面可能包含多个 split，第一次操作建议换成普通 APK；JAR 和 CLASS 属于另一条处理路径，不适合拿来练“拖入 APK”的流程。然后看工具链：回到参数设置跑一次体检，确认 aapt 可用。最后看日志：打开工作目录下的 error.log，程序在解析阶段抛出的异常通常会写在这里，比界面上的“导入失败”具体得多。

还有一种失败不报错，但结果不对：包能解析，应用名和图标也读出来了，可启动页是空的。这通常说明 APK 的清单里没有常规的 LAUNCHER 入口，或者入口写在了动态加载的组件里。对于自家应用，你可以回到工程里确认启动 Activity 是否声明了 MAIN 与 LAUNCHER；如果这是你第一次改包，最省事的做法是换一个启动入口明确的包来练手。启动页为空并不影响你改图标和名字，但会影响第七步的自动拉起和验收，所以最好在第二步就发现它。

判断解析是否成功，不看动画，看字段。图标清晰、应用名正确、包名与手机上一致、版本号能对上、启动页不为空，这五项都成立，才算真的读明白了。

四、第三步：填项目名，建好一个能回退的项目

解析完成后，界面会让你给这次改包起一个项目名。项目名首先是一个标签，方便你在项目列表里认出它；它不是你应用的包名，也不是最终 APK 的文件名，更不会因为写错就让应用装不上。电脑版会为每个项目单独建一个 8 位随机目录，项目名只用于展示和检索。这个设计有两个好处：不同项目的目录不会因为重名互相覆盖；目录名保持短而安全，不会把你输入的中文、空格或特殊符号带进命令行工具的工作路径。

虽然是标签，命名仍然值得花十秒钟。推荐的结构是“应用简称 + 版本 + 用途 + 日期”，例如 jizhang-231-neice-1021。用英文、数字和短横线，是为了在任何界面、日志和终端里都不容易看错；把用途写进去，是为了三天后你还能分清哪一版是“只换图标”、哪一版是“加了启动页”。如果你习惯用中文，也完全可以，只要自己认得出来即可。真正要避免的是“新建项目 1”“测试”“最终版”这类名字，它们会在项目列表里迅速变成一堆无法区分的卡片。

确认创建之后，程序会做三件事：在 Project 下建立随机目录，把原始 APK 复制成 source.apk，然后调用 apktool 把包反编译成可读的工程树。日志写在 apktool.log。这个阶段你不需要操作，但要知道它正在做什么，因为后面所有“工程文件在哪”“为什么 AI 改的地方和我看到的不一样”的问题，都要回到这个目录里找答案。一个成熟的项目目录大致包含下面这些内容，具体文件会随版本和包结构略有差异，但核心几项是稳定的。

重点说 config.ini。它不是给你天天编辑的配置，而是项目的“身份证存根”。程序需要记住这个项目对应哪个包、什么版本、图标在哪里、启动组件叫什么，尤其是启动组件的名字，后面打包完成自动拉起时要用。电脑版在查找组件名时有三档策略：先读 config.ini 里记录的 LaunchableActivity；读不到就用系统的包管理命令去解析；再不行才走旧方式兜底。这个顺序意味着，如果你在改包过程中把启动 Activity 的名字改了、却没有同步更新项目信息，自动拉起就可能找不到入口。第一次操作时，尽量不要改启动组件的类名，只改它显示的内容和样式。

history.ini 的作用常被低估。它保存的是你每次提交需求的原文和日期，而且只保留用户原话，不包含附件与附件说明。这个设计很务实：历史记录应该忠实反映“我说过什么”，而不是把系统拼装后的长文本也塞进去。但它也带来一个操作习惯：如果你上一轮用了附件，想原样复现，不能只点历史里的“选择”回填文字，还要重新挂上同样的附件。第一次改包时，建议每轮需求都写得足够完整，这样历史回填才有意义；不要写“同上”“按刚才那个改”，几天后连你自己都不知道“刚才”是什么。

source.apk 则是你的安全绳。所有修改都发生在反编译出来的工程目录里，原始包一直躺在项目根目录。如果某一轮改完发现应用起不来，最干脆的排查方式不是继续在工程里猜，而是新建一个项目、重新拖入同一个 source.apk，用最小需求再跑一遍。这样你能立刻判断问题来自“这一轮改动”还是“这个包本身”。第一次操作时，建议在改之前就把 source.apk 复制一份到项目目录之外，作为双重保险。

创建项目失败怎么查？先看项目列表有没有出现卡片。如果卡片出现了但一直不可进入，打开项目目录看 apktool.log 的最后几十行，常见原因是资源表异常、包内文件损坏、或者反编译超时。如果连目录都没有生成，回到第一步检查工作目录是否可写、剩余空间是否足够。如果目录生成了但 source.apk 是 0 字节，说明复制阶段就失败了，通常是磁盘空间或权限问题。电脑版允许删除项目，但只允许删除 Project 的直接子目录，这是为了避免误删工作目录之外的东西；所以清理项目时，从项目列表里删，不要手动去删上层目录。

五、第四步：进详情页写需求，把“一句话”说清楚

项目卡片就绪后，点开它进入详情页。详情页是你和 AI 之间的工作台：一边是项目信息与需求输入区，另一边是右侧的 AI 工作区。电脑版会把两个窗口做成高度一致、可以磁吸的布局，你拖动主窗口时，工作区会跟着贴合，避免一边写需求一边找窗口。第一次进入时，先不要急着点“立刻修改”，花一分钟看清楚三个区域：项目基本信息、需求输入框、历史记录。信息确认无误，再开始写。

“只需说话，就能让应用变成你想要的样子”这句话，容易让人以为随便说一句就行。实际体验中，说得越具体，返工越少。一个对新手最友好的需求结构是五段式：目标、位置、效果、约束、验收。目标回答“改什么”，位置回答“在哪个页面或哪个资源”，效果回答“改成什么样”，约束回答“什么不能动”，验收回答“装好之后我该看到什么”。五段不需要写成公文，每段一两句话即可，但它能显著减少 AI 的猜测空间。

举个例子。你要给自家记账应用换图标和名字，不要只写“换个图标，改个名”。可以写成：“目标：替换桌面图标，修改应用显示名。位置：桌面图标与应用信息里的名称。效果：图标使用我附件里的 logo.png，保留透明边距；名称改为‘记账本 内测版’。约束：不要改包名、版本号和启动页，不要改应用内的任何文案。验收：安装后桌面图标为新图，设置里的应用名称为新名字，打开应用数据仍在。”这段话没有技术黑话，但把 AI 需要的信息都给全了。

位置描述是新手最容易省掉、也最容易出错的部分。你说“改首页”，AI 需要知道首页对应哪个 Activity、哪个布局、哪个字符串资源；你说“改标题”，它需要知道是桌面名称、应用内标题栏，还是关于页面里的版本标题。一个实用的办法是打开手机上的原应用，截图你要改的页面，把截图作为附件，并在说明里写“这是要改的页面，顶部标题栏文字要换成某某”。图片加文字，比单纯说“首页”精确得多。附件怎么加、说明怎么写，下一步会详细讲。

约束段同样重要。改包不是只改一个像素，工程树里有很多相互引用的地方。你不希望包名变，就要明确说；你不希望版本号变，就要明确说；你不希望动某个页面，也要明确说。对于第一次操作，建议固定写上三句：“不要改包名”“不要改版本号”“不要改启动组件名”。这三句能避免大部分“装不上”“覆盖不了”“自动拉起失败”的连锁问题。等你熟悉流程后，再根据实际需要放宽。

验收段是给自己看的，不是给 AI 看的。写清楚“装好之后我该看到什么”，你在第七步就有一张现成的检查表。比如“桌面图标为新图”“应用信息里的名字为新名”“打开应用后账本数据还在”“版本号仍然是 2.3.1”。如果验收项写不出来，说明你对这次改动的边界还不清楚，先想清楚再提交，比改完再猜要省时间。

详情页的历史记录默认最新在上，保留完整原文，右侧有“选择”可以把某条历史回填到输入框。这个功能适合“上一轮只差一点”的场景：点回填，再补一句“上次的图标位置偏下，这次向上移动一点”。但不要把它当成版本管理，历史只记录文字，不记录附件，也不记录每一轮工程树的状态。真正要对比版本，还是复制项目目录，或者用 source.apk 重建一个项目。第一次操作时，建议每轮只改一个主题，历史看起来会非常清楚。

如果输入框写了却没反应，先确认项目是否真的就绪。项目还在反编译时，详情页可能能打开，但执行按钮不可用；这时候回到项目列表等状态变化，而不是反复点。还有一种情况是需求太长、包含多个目标，AI 在第一轮只完成了其中一部分。这不是失败，而是你把多个任务塞进了一次提交。拆成两轮：第一轮改图标和名称，第二轮改启动页和颜色，每轮都单独验收，成功率会高很多。

一句话不等于一句话说完所有事。把“改什么、在哪改、改成什么样、什么不能动、怎么算成功”说全，才是真正的“说人话”。

六、第五步：用话术和附件，把模糊想法补成可执行约束

需求输入框旁边提供了话术入口。电脑版内置 3000 条话术，分成六类，每类 500 条：界面美化、弹窗引流、去除限制、常规修改、混淆去毒、插件添加。它们不是自动执行按钮，而是表达模板。你点一条，文字会填进输入框，你再按自己的应用情况改成具体描述。对第一次改包的人来说，话术最大的价值不是“替你写”，而是“提醒你还有哪些维度没说”：图标、名称、启动页、主题色、文案、弹窗、版本号、内置地址，这些都属于常见改动，但新手往往只想到其中一两个。

六类话术的用法差别很大，边界也不一样。界面美化适合换图标、换背景、调颜色、调圆角；常规修改适合改应用名、版本号、内置配置、WebView 地址；插件添加适合在自家应用里接入内部组件；弹窗引流适合自家运营活动；去除限制只适用于你自己应用里由你设置的限制，例如内部试用版的次数限制；混淆去毒只适用于清理你自己构建产物里的异常内容。后两类尤其要克制：它们描述的是“处理自家产物”的能力，不是绕过他人付费、破解他人应用的工具。任何时候，改包对象都应当是你拥有版权或已获得授权的应用。

点选话术之后，最重要的工作是“落地”。模板里通常有占位描述，你要把占位内容替换成你的应用里真实存在的名字。例如模板写“将首页顶部标题改为某某”，你要把它改成“将 MainActivity 顶部标题栏的文字改为‘记账本 内测版’”。如果你不知道 Activity 叫什么，就用截图加页面描述；如果你知道颜色值，就写十六进制；如果你有素材，就挂附件。话术是骨架，具体信息才是血肉。第一次使用时，建议只选一条最接近的模板，改完再提交，不要在一个输入框里堆五六条不同类别的话术。

附件区是第五步的另一半。电脑版支持一次多选文件，每个文件都要写用途说明，说明不少于 10 个字。这个限制看起来繁琐，实际是在逼你把“这个文件是干什么的”说清楚。附件不是随便丢进去的素材堆，它会和需求一起被整理成“序号 + 路径 + 说明”的形式送给 AI。序号让 AI 能引用具体文件，路径让它知道文件在哪，说明让它知道这个文件该用在哪。三者缺一，AI 就只能猜。比如同时放了图标、启动图、活动 banner，却只写“素材”，它很可能把启动图当成图标。

附件在送进需求之前会做校验：文件必须存在、不能是目录、不能是 0 字节、必须可读。四条里任何一条不满足，附件都不会被带上。这个校验很基础，但能挡住最常见的错误：从聊天软件里拖出来一个还没下载完的占位文件、把整个文件夹当成图片拖进来、复制了一个空文件、或者文件被其他程序占用导致不可读。第一次操作时，建议在添加附件之前先在资源管理器里双击打开看一眼，确认图片能显示、文本能打开，再挂上去。

还有一个容易踩的坑：history.ini 只保留用户原话，不保存附件和附件说明。也就是说，你在历史记录里点“选择”回填的只有文字，附件不会跟着回来。这个设计的初衷是让历史忠实记录“你说过什么”，但使用时必须记住：复现上一轮改动时，要重新挂附件、重新写说明。第一次改包时，最好把附件放在一个固定文件夹里，命名成 icon-1024.png、splash-1080x1920.jpg 这种一眼能看懂的名字，下次回填时不容易拿错。

以自家记账 App 为例，第一轮只换图标和名字，附件只需要一个 1024 像素的 PNG 图标，说明写“这是新版桌面图标，用于替换应用启动图标，保留透明边距”。第二轮如果要换启动页，再加一张 1080×1920 的背景图，说明写“这是启动页背景，用于第一屏全屏显示，请居中裁切”。第三轮如果要统一主题色，可以附一个文本文件写清色值，或者直接在需求里写十六进制。附件越少、角色越单一，AI 越不容易混用。新手常见的错误是一次挂十个文件，每个都写“素材”，结果 AI 只能按文件名猜，返工率反而更高。

这一步失败怎么查？如果附件加不进去，先按四条校验逐一排除：路径是否存在、是不是目录、大小是否为 0、当前用户是否有读权限。如果附件加进去了但 AI 用错了图，回到说明文字，检查有没有写清“角色”和“位置”；必要时把文件名也改成能表达角色的名字，再重新提交。如果话术点选后没有填入输入框，先看输入框是否处于只读状态、项目是否还在准备中；不要在项目未就绪时反复点话术，那不会加快任何东西。

七、第六步：点“立刻修改”，等一个文件信号而不是等一句回复

需求、话术、附件都准备好之后，点“立刻修改”。这一下会做两件事：把你输入的原文和当前日期写进 history.ini，然后把需求送进右侧的 AI 工作区执行。注意顺序：先落历史，再执行。这样即使执行过程中程序崩溃、窗口被关掉，你仍然能在 history.ini 里找到自己说过什么。对第一次操作的人来说，这个顺序还有一个实际好处：你可以在点之前先截个图，点之后对照历史，确认送进去的确实是你写的那段话，而不是上一次的残留内容。

执行期间，右侧工作区会显示 AI 的工作过程。你不需要盯着每一行输出，但要留意它是否在向你提问。有些需求天然存在歧义，例如“把启动页换成新图”，而附件里有两张图；或者“把颜色改成品牌色”，但没有给色值。AI 可能会在工作区里要求补充信息，这时候你应该直接回答，而不是关掉窗口重新提交。重新提交会新增一条历史，并把同一件事再执行一遍，既浪费时间，也让后面的日志更难读。

AI 完成后，会在项目目录里留下一个名为 ai_done.flag 的标志文件。主窗口每隔 2 秒轮询一次项目目录，读到这个文件就说明这一轮修改结束，随后删除标志并进入打包流程。等待上限是 1 小时。这个设计看起来朴素，却比“在内存里等一个回调”稳得多：文件是跨进程、跨窗口、跨重启都能看见的凭据；即使 AI 工作区窗口被最小化、被拖走，主窗口仍然能通过目录变化知道任务结束了。2 秒的间隔对用户来说几乎无感，对磁盘来说也足够轻。

为什么是标志文件，而不是让 AI 在聊天里说一句“完成了”？因为聊天内容可能被截断、可能被后续消息覆盖，也可能因为界面卡住而没有渲染出来；文件则只有“存在”和“不存在”两种状态，判断简单、可追溯。主窗口读到标志后会把它删掉，这样下一轮任务可以复用同一个文件名，不会把上一轮的完成误判成这一轮的完成。第一次操作时，如果你好奇，可以在执行期间打开项目目录，亲眼看它从无到有出现，再在打包开始后消失。这个观察会让你对整条链路的节奏有直观感受。

如果等了很久没有动静，按这个顺序查。第一，看右侧工作区最后几行，是在正常执行、在提问，还是已经报错。第二，看项目目录里有没有 ai_done.flag；如果有但主窗口没反应，可能是主窗口被其它模态窗口挡住、或者程序已经失去响应，试着把主窗口切到前台。第三，看工作目录下的 error.log，有没有未处理异常。第四，确认自己没有在等待期间关闭过 AI 工作区；关闭窗口不一定会终止任务，但会让你看不到它的提问。第五，确认等待时间没有超过 1 小时上限；超过之后，主窗口会按失败处理，不会无限等下去。

这里要特别提醒一个新手常见动作：看到没反应就连点“立刻修改”。每点一次，history.ini 就多一条记录，AI 工作区就多一轮任务，项目目录里可能出现多个完成信号交错。最后你既不知道哪一轮改了什么，也不知道打包的是哪一版工程。正确的做法是点一次，然后观察；确实要重来，先在项目列表里确认当前任务已经结束，再决定是补一条更精确的需求，还是用 source.apk 新建项目重跑。把“一次只跑一轮”当成纪律，第一次改包的成功率会高很多。

还要建立一个预期：AI 完成不等于改包成功。ai_done.flag 只说明“这一轮修改动作结束了”，不说明“改得对”，更不说明“编译得过、签得上、装得进”。真正的成功要等第七步的四段打包和设备复核。很多新手看到工作区说“已完成”就以为结束了，结果在安装时遇到签名冲突，又回头怀疑 AI。把完成信号当成“交接单”，而不是“合格证”，你就不会在错误的地方下结论。

文件信号是这条链路里最可靠的“完成”定义。它在，说明这一轮结束了；它不在，说明还没结束。不要用聊天区最后一句话代替它。

八、第七步：回编、对齐、签名、装机，一段都不能跳

AI 结束后，电脑版自动进入打包。打包不是“重新压缩一下”这么简单，它由四段确定性的命令组成，任何一段失败，产物都不能用。四段依次是：用 apktool 把工程回编成未签名 APK；用 zipalign 做字节对齐；用 apksigner 签名；再用 apksigner 校验签名。全过程写入 pack.log。第一次操作时，你不需要手动敲这些命令，但必须知道每一段在做什么，因为失败时 pack.log 会明确停在某一段，而不同段的失败原因完全不同。

第一段 apktool b 是把工程树编译回二进制。你在详情页说的每一句话，最终都要在这里变成资源表、清单和字节码。这一段最常见的失败是资源引用错误：AI 删了一张图，却在布局里还引用它；或者改了一个颜色名，却在另一个文件里拼错了。其次是图片格式问题：把 WebP 当成 PNG 改名、把九宫格图改成普通 PNG，都可能在编译时暴露。再次是 smali 语法：少一个寄存器、错一个分支标签，编译就会停。遇到这一段失败，先看 pack.log 里最后一条错误指向哪个文件，再打开 apktool 工程核对，不要盲目重跑。

第二段 zipalign 处理的是压缩包内部的对齐。Android 在读取未压缩资源时，希望它们落在 4 字节边界上；共享库则希望按页对齐，所以命令里带 -p 4，也就是常说的 zipalign -p 4；命令里的 -f 表示覆盖已有输出文件。对齐不是可有可无的优化，它直接影响安装和运行时的读取效率，某些系统版本对未对齐的包还会直接拒绝。顺序也很关键：必须先对齐、再签名。因为签名会覆盖文件内容，如果先签名再对齐，签名就会失效。电脑版把四段固定成这个顺序，就是为了避免这种“看起来都做了，其实白做”的错误。

第三段 apksigner sign 是真正让包“能被系统接受”的一步。电脑版提供四选一的密钥方式：默认签名、JKS 或 keystore 文件、PEM 加 PK8、随机签名。签名方案支持 v1、v2、v3、v4，默认组合是 v1+v2+v3。口令通过环境变量传入，不会拼进命令行，也不会写进日志，这一点对团队协作很重要。第一次改包，如果你只是自己装到测试机上看看效果，用默认签名最省事；如果你要让新包覆盖手机上已安装的旧版，必须使用和旧版相同的签名密钥，否则系统会以签名不一致为由拒绝安装。这不是工具的问题，而是 Android 的安全模型。

第四段 apksigner verify --print-certs 是很多人会省掉、但电脑版坚持保留的一步。签名的命令返回成功，不代表签名真的有效：密钥格式不对、别名不对、证书链不完整，都可能在签名时没有立刻暴露，直到安装时才报错。verify 会把证书主题、颁发者、有效期和指纹打印出来，让“到底签没签上”变成可核对的事实。第一次操作时，建议把 verify 输出的 SHA-256 指纹复制下来，和上一版对比；如果你们团队用固定密钥，指纹应该完全一致。这个习惯能帮你提前发现“拿错密钥”这种低级但致命的错误。

四段都完成后，电脑版会尝试自动装机。它先用 adb 找设备，找到后安装，再执行 am start -W -n 包名/Activity 拉起应用。这里的组件名不是猜的，电脑版按三档查找：先读 config.ini 里记录的 LaunchableActivity；读不到就用 cmd package resolve-activity --brief 向系统查询；再不行才走旧方式兜底。拉起之后，它还会用 dumpsys 复核当前前台应用，确认屏幕上真的是你刚装的那个包，而不是启动失败后退回桌面。手机通过 scrcpy 投屏到电脑，模拟器则会被提到最前，方便你直接看。

如果你想自己复核，可以在终端里按顺序执行几条命令。先 adb devices 确认设备在线；再 adb install -r 你的产物.apk 覆盖安装；然后 adb shell am start -W -n 包名/.MainActivity 拉起并等待结果。am start 的 -W 会打印 Status、LaunchState、ThisTime、TotalTime，Status 为 ok 说明启动成功。最后用 adb shell dumpsys window | findstr mCurrentFocus 看前台窗口，或者用 adb shell dumpsys activity activities | findstr mResumedActivity 看当前 resumed 的 Activity。Windows 的 findstr 区分大小写参数可用 /i，命令本身不复杂，关键是知道该看哪一行。

装机失败时，错误码比“安装失败”四个字有用得多。签名不一致通常报 INSTALL_FAILED_UPDATE_INCOMPATIBLE，解决办法是用同一把钥匙重签，或者先卸载旧版再装，但卸载会清掉应用数据；版本号比已装版本低会报 INSTALL_FAILED_VERSION_DOWNGRADE，要么升版本号，要么卸载旧版；包没有证书会报 INSTALL_PARSE_FAILED_NO_CERTIFICATES，回到 verify 看签名；空间不足会报 INSTALL_FAILED_INSUFFICIENT_STORAGE，清理设备；am start 报 Error type 3，通常是组件名写错或应用没有该入口，回到 config.ini 和 resolve-activity 对照。把这些错误码记在便签上，第一次排错会快很多。

最后给出一张验收清单。它比任何“完成”提示都可靠，建议每次改包都照着走一遍。清单不需要一次全做，但第一次改包时，至少把前六项做完；后面几项随着你对应用和团队的熟悉程度逐步加上。验收的目的不是挑剔，而是把“我觉得可以了”变成“我能证明它可以了”。当你能把包名、版本、签名指纹、启动组件和核心功能逐项说清楚，这次改包才算真正闭环。

九、两个自家实例：从“以前怎么熬”到“现在怎么验”

前面七步讲的是通用流程，真正让人有体感的，是两个具体应用。下面两个实例都来自团队自家开发的应用，拥有完整自有版权，一个是最常见的“换图标 + 改内测名”，一个是稍复杂一点的“换启动页 + 换主题色”。每个实例都按“以前怎么做、现在怎么做、改完怎么验证”三段写，你可以对照自己的应用，挑一个最接近的场景先练手。

实例一：自家记账 App，换图标并改成内测名

这个记账 App 是团队自己维护的，包名固定，版本 2.3.1，已经装在几台测试机上。新一轮内测想换一个更醒目的图标，同时把桌面名称改成“记账本 内测版”，方便测试同事一眼区分正式版和内测版。需求仅此两项，包名、版本号、启动页、应用内文案都不动。看起来是最简单的改包，但以前每次做，都要花掉半个下午。

以前怎么做。设计师先导出五套密度的 PNG，再单独给自适应图标准备前景和背景；开发打开 Android Studio，在 mipmap-mdpi 到 mipmap-xxxhdpi 之间逐个替换，检查自适应图标的前景留白，改 strings 里的应用名，然后打一个签名包。打完还要用 adb 装到测试机，手动确认桌面图标、应用信息、设置列表三处都变了。最容易出的问题是漏掉某一个密度，或者启动器缓存没刷新，桌面还是旧图；其次是内测名太长，在桌面上被截断。一个下午里，真正改图的时间不到十分钟，剩下都花在找图、打包、装机、对比上。

现在怎么做。打开安卓修改大师电脑版，把现有的 2.3.1 发布包拖进主窗口，等 aapt 解析出图标、包名、版本和启动页；项目名填 jizhang-231-neice，进入详情页；把一个 1024 像素、带透明边距的 PNG 作为附件，说明写“这是新版桌面图标，用于替换应用启动图标，保留透明边距”；需求按五段式写清楚，然后点“立刻修改”。AI 改完留下 ai_done.flag，主窗口进入打包，回编、对齐、签名、校验依次跑完，最后自动装到连着的那台测试机上。

这一轮实际使用的需求原文：“目标：替换桌面图标，修改应用显示名。位置：桌面图标与应用信息里的名称。效果：图标使用附件 1 的 logo，保留透明边距，不要加底板；名称改为‘记账本 内测版’。约束：不要改包名 com.example.jizhang，不要改版本号 2.3.1，不要改启动页和应用内文案。验收：安装后桌面图标为新图，应用信息名称为新名字，打开应用后原有账本数据还在。”

改完怎么验证。先在测试机桌面看图标，再长按图标进入应用信息，确认名称和版本；然后打开系统设置里的应用列表，看名称是否同步；接着打开应用，确认原来的账本、分类和设置都还在；最后用 adb shell dumpsys package com.example.jizhang | findstr versionName 核对版本仍然是 2.3.1，用 adb shell dumpsys window | findstr mCurrentFocus 确认前台包名没有变成别的应用。如果桌面还是旧图，先重启启动器或重新安装一次，排除缓存；如果图标出现白边，回到附件检查透明边距是否足够；如果名称被截断，把内测名再缩短两个字。

这个实例的价值在于“最小闭环”。它只改了两个显示层的东西，不碰代码逻辑，不改包名和版本，因此安装、启动、数据保留都能一次验证完。第一次改包的人，建议就用这种需求跑通七步；跑通之后，你再换启动页、换颜色，心里会有底。不要一上来就同时改图标、名称、启动页、主题色和接口地址，那样即使成功了，你也不知道是哪一步起了作用，失败时更不知道该回退到哪。

实例二：自家内部工具，换启动页与主题色

第二个例子是团队内部的巡检工具，只在内网使用，包名固定，接口地址分测试和正式两套。这一轮想把启动页换成新的品牌图，把主题色从原来的蓝色改成更沉稳的绿色，同时保持接口地址、包名和业务逻辑不变。相比记账 App，这个需求会碰到布局、颜色资源和启动页 Activity，失败面更宽，但也更能体现“附件 + 明确约束”的价值。

以前怎么做。开发先在工程里找启动页对应的 Activity，替换背景 drawable，再改颜色资源里的主色和强调色；如果某些页面把颜色写死在布局里，还要逐页搜十六进制值。改完打一个测试包，发到同事群里，同事下载、安装、冷启动、截图反馈。常见问题是启动图被拉伸、某些按钮还是旧颜色、测试包和正式包混在一起分不清。为了区分环境，有时还要打两个变体，版本号一乱，谁都说不清群里那个包是哪一版。

现在怎么做。把内部工具的现有 APK 拖进电脑版，项目名用 xunjian-splash-green；附件挂一张 1080×1920 的启动图，说明写“这是启动页背景图，用于进入应用后的第一屏全屏显示，请居中裁切，不要拉伸”；需求里写清主题色的十六进制值、要覆盖的页面范围，以及“不要改接口地址、不要改包名”的约束；点“立刻修改”，等自动打包和安装。为了让同事分得清，这一轮还把 versionCode 升了一版，versionName 只加内测后缀。

这一轮实际使用的需求原文：“目标：更换启动页背景，统一主题色。位置：冷启动第一屏，以及首页、巡检列表、设置页的顶部栏和主按钮。效果：启动页使用附件 1 的背景图，居中裁切不拉伸；主题色从 #2F6BFF 改为 #0E7C66，按钮按下态用 #0B5F4E。约束：不要改包名，不要改接口地址，不要改业务逻辑；versionCode 升到 204，versionName 改为 2.0.4-内测。验收：冷启动能看到新背景，三个页面的顶部栏和主按钮为新绿色，接口仍指向正式环境。”

改完怎么验证。先执行 adb shell am force-stop 包名 彻底停掉应用，再用 adb shell am start -W -n 包名/启动Activity 冷启动，观察第一屏是否完整显示、有没有拉伸或黑边；然后依次打开首页、巡检列表、设置页，对比顶部栏、主按钮、进度条的颜色是否一致；再从设置里的环境信息或日志确认接口仍然指向正式环境；最后看版本号和签名指纹，确认同事装的是这一版。启动页停留很短，建议用 scrcpy 投屏后录屏，或者连续冷启动两次再看，避免“还没看清就过去了”。

这个实例最容易返工的地方是“颜色没有全覆盖”。有些应用把颜色写在颜色资源里，有些直接写在布局或代码里，AI 第一轮通常能改到资源引用的部分，写死的十六进制值可能漏掉。验证时如果发现某个按钮还是蓝色，不要笼统地说“颜色没改完”，而要指出具体页面和控件，例如“巡检列表页右上角的筛选按钮还是旧蓝色，请一并改为 #0E7C66”。第二轮只补这一处，成功率会高很多。启动页拉伸则要回到附件，确认图片比例和裁切方式，而不是让 AI 反复猜。

两个实例放在一起看，会发现一个共同点：真正的难点不在“点按钮”，而在“把边界说清楚”和“把结果验到位”。记账 App 的边界是“只动显示层”，内部工具的边界是“只动启动页和颜色，不动接口和包名”。边界说清楚了，AI 才不会越界；验收项写清楚了，你才知道该看哪里。至于工具链怎么回编、怎么对齐、怎么签名，电脑版已经把它们收进自动流程，你只需要在失败时知道去 pack.log 的哪一段找原因。

十、收尾：失败排查、用户评价与合规边界

第一次改包不可能一次就完美。更现实的场景是：某一步看起来完成了，下一步却没有按预期发生。下面的排查表按阶段整理，左侧是你看到的现象，中间是它最可能所属的阶段，右侧是第一时间该打开的日志或文件。把这张表和第七步的验收清单放在一起，基本覆盖了新手会遇到的大部分问题。遇到没列出来的情况，也先按“阶段—证据—动作”的顺序想，不要一上来就重装软件或重做整个项目。

排查时还有一个通用原则：一次只改一个变量。如果你在失败之后同时换了 APK、换了工作目录、换了签名密钥、又改了需求，那么即使问题消失了，你也不知道是哪一项起了作用。正确做法是回到最后一个已知正常的节点：用 source.apk 新建项目，用最小需求（只改应用名）重跑一遍。如果最小需求能成功，说明工具链和签名都没问题，问题在上一轮的改动内容；如果最小需求也失败，问题在环境或包本身。这个“最小复现”思路，比反复重装软件有效得多。

用户评价

回到最初的七步。准备工具链与登录，是为了让后面每一步都有可用的环境和设备；拖入 APK，是让 aapt 把包读明白，尤其是图标密度与 65534 这个哨兵值；填项目名，是建立一个带 source.apk、config.ini、history.ini 的可回退项目；进详情页写需求，是把模糊想法变成目标、位置、效果、约束、验收五段；话术与附件，是补上表达维度和素材约束；点“立刻修改”，是让 AI 在工程树里执行，并用 ai_done.flag 这个文件信号把完成交接给主窗口；回编、对齐、签名、校验与装机复核，是把改动变成真正能安装、能启动、能验收的 APK。七步各有各的失败方式，也各有各的证据。

如果你是第一次操作，建议今天只做一件事：挑一个自家的小应用，只改应用显示名，把七步完整跑一遍。看到桌面上的名字变了、应用还能正常打开、dumpsys 里的版本没变，你就算真正入门了。明天再换图标，后天再加启动页和主题色。每一次只增加一个变量，每一次都用 pack.log 和验收清单收尾。等这套节奏变成习惯，你再回头看“只需说话，就能让应用变成你想要的样子”这句话，会发现它说的不是魔法，而是把复杂的工具链收进一条可理解、可验证的流程里。

想开始的话，入口在「安卓修改大师智改工坊」的产品页：https://www.apkeditor.cn/ai-version.aspx。安卓修改大师电脑版负责桌面上的完整改包链路，官网 www.apkeditor.cn 上还有版本说明与下载入口。把这篇文章当成第一次操作的手册，按七步走，遇到问题先看证据，再决定下一步。

本文基于电脑版公开可核实的功能与团队自家应用的实测流程撰写。不同应用的结构、保护方式、设备系统版本与签名配置会影响实际结果，请以项目目录中的日志、pack.log 与设备复核为准；仅在自有版权或已获授权的应用上操作。