经典版能力全览：从导入解析到历史管理的一站式改包

如果你一直想找一个「打开就能用、不用凑工具链」的改包环境，这篇文章就是为你写的。它要介绍的是 安卓修改大师智改工坊 的经典版——一个装在 Windows 电脑上的桌面工具。介绍页可点击直达：https://www.apkeditor.cn/ai-version.aspx，官网是 https://www.apkeditor.cn/。

这篇文章不聊概念，只做一次完整的能力全览：它能接什么格式的包、拖进去之后它替你看懂什么、每个项目在硬盘上长什么样、反编译到底快不快、历史记录怎么帮你「照上次再改一遍」、出包时签名与校验是怎么走的、以及那些影响每天手感的界面细节。看完这篇，你应该能判断它是不是你要的那台「改包工作台」。

一、一台电脑上的改包工作台：打开它，就是一条流水线

传统改包流程里，一个人电脑上往往同时开着五六个东西：解包工具、反编译工具、资源编辑器、签名工具、还有一个连着手机的命令行窗口。工具散在不同目录，版本各不相同，开工之前先得花时间确认「今天这套环境还能不能用」。经典版要解决的第一件事，就是把这些收进同一个工作台里。

它对工作目录的安排很直白：启动时自动挑盘，按 D → E → F → G → C 的顺序，取第一个能读写且剩余空间不小于 1GB 的盘，拼成 <盘符>:\AiApkEditor 作为工作目录。目录下固定两个子目录：一个是 tools，里面放 java、aapt、apktool、7z、zipalign、apksigner 等工具，程序会自动递归搜索，不用你登记每一个可执行文件的路径；另一个是 Project，所有改过的包都在这里面安家。

第一次打开，你大概会先去「参数设置」页转一圈。那里有三样东西值得看：工作目录在哪、10 套配色主题点一下立刻换、以及工具链体检——aapt、java、apktool、zipalign、apksigner 逐个报是否就绪、完整路径是什么。哪一项不齐，点「立刻更新」会自动下载并解压工具包（7z 格式），装完重新检测。也就是说，环境这件事在这个工作台里是「看得见、修得好」的，而不是「出了问题再猜」。

为什么要把「登录了才能干什么」说清楚？因为它决定了你的使用节奏：你可以先把包导进来、翻一翻解析结果、写好需求、看一眼历史，这些都不卡你；真正消耗资源的「立刻修改」才需要余额。这种设计让人很容易把它当成日常工作台开着，而不是用完就删的一次性脚本。

tools 目录的「自动递归搜索」也值得展开说一句。手工凑环境时，最烦的不是装某个工具，而是版本之间要互相认识：apktool 依赖什么版本的 java、apksigner 和 zipalign 是不是同一套构建产物里的兄弟，这些关系没人写在一张纸上，全靠踩坑踩出来。经典版把这堆工具收在同一个 tools 目录下，程序自己去找、自己去体检，你要操心的从「这堆工具搭不搭」变成了「体检页是不是全绿」。环境不齐时点一次「立刻更新」，工具包自动下载、自动解压、自动复检——对一台新电脑来说，从开箱到能改第一个包，中间没有手动找依赖这一环。

用户中心里的项目统计也值得常看一眼：项目数量、修改总次数、占用空间、所在磁盘剩余，四项一目了然。天天开包的人都会遇到「哪个盘快满了」的问题，把它摆在用户中心里，比你自己隔三差五去资源管理器里盘点要省心。充值套餐来自服务端，支付用外部浏览器打开支付宝或微信，程序每 3 秒轮询一次付款结果——付完款切回来，额度已经到账，不需要手动刷新。

二、什么文件都能接：六种格式一张表

改包人最常遇到的第一个问题，其实不是「怎么改」，而是「这个包能不能直接拖进来」。市场上的安装包形态很杂：有单文件 APK，有商店分发用的 APKS/XAPK/APKM 分包，有开发调试时遇到的 JAR，还有直接拿 CLASS 文件做实验的场景。经典版的导入策略是：不挑格式，能拖就拖，能选就选。

格式	典型来源	导入后的处理方式
APK	单文件安装包，最常见	完整解析包信息，正常建项目
APKS	按 ABI / 屏幕密度拆分的分包	解析不出包信息时以文件名建项目，并给一句说明
XAPK / APKM	第三方商店的扩展包格式	同上，能解析就解析，解析不出也不拦你
JAR	Java 库包，调试与学习场景	以文件名继续建项目，页面上给一句说明
CLASS	单个类文件，做代码实验	同上，先把项目立起来再说

「拖入」和「选择」两种入口进的是同一条流程：拖入适合从桌面或下载目录里一把拽进来，选择文件对话框适合翻目录挑一个刚拿到的包。建出来的项目结构完全一致，所以你不用为「从哪儿进」做额外决定。

这里有个设计哲学值得点出来：解析不出包信息，不等于不能建项目。分包 apks、加密包、jar、class 这类形态，很多时候 aapt 读不出应用名、版本号，程序不会因此把你拦在门外，而是以文件名继续建项目，页面上给一句说明。对做技术研究的人来说，这种「先让项目落地，再谈改不改得动」的态度，比一堆格式报错弹窗友好得多。

从实操角度补一句：拖入的目标位置其实很宽，不必精准瞄准某个按钮——把文件从资源管理器里拽进程序窗口的主要区域即可，松手就开始走流程。这种宽容的导入设计在批量操作时尤其顺手：一天要处理十几个包的人，省下来的不是哪一秒钟，而是「每次都要精确点对位置」的那点心神。建完的项目立刻出现在项目列表里，图标、应用名（或文件名）、建项时间摆在一起，找刚才那个包不用翻目录。

反过来想，如果工作台只收 APK 单文件，会逼你在导入前先做一轮格式转换：把 XAPK 拆开、把 APKS 拼回去，这些前置动作每一步都可能出错。把「能接什么」的边界放宽，等于把格式兼容的责任从你身上挪到了程序身上——你只需要关心「这个包我要改成什么样」，而不是「这个包我先得变成什么样」。

三、拖进去就知道了：aapt 解析的那一瞬间

包一落地，程序就用工作目录里的 aapt 把它读一遍，然后在详情页把关键信息摆出来：图标、应用名、包名、版本号、最低与目标 SDK、启动页。这几项看着朴素，实际上正好是后续判断「这个包是什么、能不能改、改完怎么拉起」的全部依据。手工流程里这些信息你得自己敲一条 aapt 命令去查，在这里它已经摆在你眼前。

图标这一项有个细节，用过的人都会夸一句：它是从包里取出的原图，并且按最高密度挑选。aapt 报的 65534 是「任意密度」的哨兵值，程序不会把它当成「随便挑一张」来处理，所以你在项目列表里看到的图标是清晰原图，而不是一张被降级过的缩略图。对经常要「先看一眼图标认包」的人来说，这个细节直接决定了项目列表扫一眼能不能认对人。

另一个体感很强的点：解析与反编译都跑在后台线程，界面不卡。听起来像套话，但它决定了你在等包解开的同时，还能不能切回项目列表翻上一个包的历史、能不能先把下一条需求的关键词想好。大一点的包解析要等十几秒，这十几秒里工作台始终是活的——这种「等待不占屏」的设计，在天天重复开包的人那里，是会被写进使用习惯的。

最低 SDK 与目标 SDK 这两个字段也不是摆设：它告诉你这个包的「年龄」和「脾气」。目标 SDK 高的包对签名方案、对安装时的校验更敏感，出包时四步流水线就一步都不能省；了解了这一点，你就明白为什么后面要单独做一步 verify——高版本目标包的装机校验只会更严。

启动页信息也被一并解析了出来，这一项直接关系到「改完怎么看效果」。程序知道这个包从哪个 Activity 拉起，后面装机预览时就能直接把它送到前台，而不是装完还要你自己满抽屉找图标点。包名同理：渠道包批量出包时，包名没变、图标变了，靠包名确认「这个项目对应哪个正在分发的包」，比凭记忆靠谱得多。版本号则是你判断「手上这个包是迭代到哪一轮」的第一手信息——和后面默认出包命名「应用名_版本号_signed.apk」一对照，版本脉络清清楚楚。

把这几项合起来看，aapt 解析的本质是给这个包办了一张身份证：它是谁（应用名、包名）、多大年纪（SDK 范围）、长什么样（图标原图）、从哪进门（启动页）、叫哪一版（版本号）。有了这张身份证，后面写需求、出包、装机、翻历史，每一步引用的都是同一个身份，不会出现「改了半天不知道改的是哪个版本」的混乱。

四、项目体系：每个包都有自己的档案

改包最乱的时候是什么样？是桌面上十几个「改好的.apk」「新版_最终.apk」「真的最终版.apk」，过两周没人记得哪个是哪个。经典版从建项目的第一天起，就用目录结构把这件事管住了。

• 每个项目一个 8 位随机字符串目录，不靠你起名，自然不重名、不串味。
• 自动写 config.ini：包信息、启动页配置都固化在文件里，而不是你的脑子里。
• 自动拷一份 source.apk 留底：原始包始终在手边，改崩了随时能回到起点。
• 反编译输出落在项目里的 apktool 目录：改了什么、基于什么改的，全在同一个文件夹。
• 出包产物在 build 目录，全过程写进 pack.log：三份中间产物加一份日志，可复盘、可追溯。

反编译失败了怎么办？这是很多人第一次用会担心的问题。答案是：反编译失败不影响项目本身。因为建项目时，配置、图标、源包已经先一步落地了，反编译只是其中一道工序。失败时程序会提示原因，并给出日志路径 apktool.log——你拿着这份日志去看，比在黑窗口里干瞪眼强得多。换句话说，这里的失败是「被设计过的失败」：失败了项目还在、信息还在，知道为什么失败，而不是整个目录白建。

项目列表本身也像一个小文件管理器：它直接读磁盘，带搜索和刷新；每条项目可以编辑、看历史、删除。删除有一道防呆——只允许删 Project 的直接子目录。这条约束看着小，用意很实在：你不会因为一次手抖，把工作目录本身或者 tools 工具目录删掉。对天天在同一个盘里干活的人来说，这种「想错都错不到哪儿去」的边界感，就是安全感。

项目攒到几十个之后，搜索就变成了高频动作。记得「上周改过那个记账类的包」，但不记得目录名？在搜索框里敲应用名或者包名片段，列表立刻过滤出来。刷新按钮则保证：你在外面动过 Project 目录，这里能一眼看到最新状态。这两个小功能单看都不性感，但项目一多，它们就是「找得到」和「找不到」的区别。

再细看 config.ini 的作用，会发现它是这个项目档案的「总索引」。包里解析出来的各项身份信息、启动页配置，都会固化在这里面；后面装机预览时程序要拉起哪个 Activity，先查的就是它。把配置从内存挪到文件，意味着项目关掉重开，世界还是原来那个世界：上次看到哪、改到哪、用的哪套签名配置，全都还在。手工流程里靠编辑器标签页和自己的记性维持的状态，在这里是写在文件里的。

source.apk 留底这一条，对需要反复试错的场景尤其重要。同一条需求可能要试两三遍才满意，每一次试错都建立在原始包之上；只要 source.apk 还在，你随时能把项目「还原出厂状态」重来。没有这份留底，改到第三轮时资源引用已经一团乱，你只能回去翻下载记录找原始包——而那份原始包，很可能已经被你清理掉了。

五、反编译快不快：一组实测数字与它的边界

聊工作台绕不开一个最实际的问题：等不等得起？这里有一组可以直接记住的实测：

为什么要主动中断？因为「挂着不动」是最耗人耐心的状态：你不知道它是在慢慢跑，还是已经卡死，走开怕它刚好跑完，盯着又什么都不发生。设一个十分钟的硬边界，失败也给个痛快——这比让你对着进度条玄学等待要负责任得多。中断之后配合 apktool.log，原因基本能定位个大概。

边界也要说清楚：反编译快不快，和包的大小、结构、有没有加壳加密直接相关。3 秒是 12MB 常规包的实测体感，不是对所有包的承诺；特别大、特别复杂的包，时间自然会更长。但即便在这种情况下，你的体验也是「后台在跑、界面不卡、十分钟有交代」，而不是「软件像死了一样」。

把视角拉长一点看这段：导入、解析、反编译这三步，在手工时代是三个独立的等待窗口——先开解包工具等一遍，再开反编译工具等一遍，中间还要自己确认产物落在哪儿。在经典版里，它们是一条后台自动走完的链路，你只在导入那一下动手，其余时间该干嘛干嘛。这种「等待被集中收编」的感觉，是工作台类工具最核心的体验提升。

把这三步的等待放在一天的工作流里算笔账：假设你每天开 10 个包，手工流程里光是「等工具就绪 + 确认产物」的心智切换就要十几次，每次切换都要把注意力重新拉回来。集中收编之后，你的注意力只需要用在两件事上——导入那一下、以及写需求那一刻。其余的等待是后台的，不占用你的判断力。对天天做这件事的人来说，注意力才是真正最贵的成本。

还有一点：反编译失败时，你手里依然有全部家当。前面说过，配置、图标、源包在反编译之前就已落地，所以哪怕这个包因为加壳、加密或者结构异常解不开，项目档案并没有白建——你至少拿到了这个包的身份信息和原始文件，知道它是什么、长什么样，研究它从哪里下手也有了起点。这种「最坏情况也不空手而归」的兜底，比单纯的快更耐用。

六、一句话怎么说才够准：话术库与附件系统

包解析完、项目立起来，接下来就是这个工作台的核心动作——在详情页中间的输入框里，用中文写下你的需求。这个输入框就是你和 AI 对话的入口：你说清楚要什么，AI 去动资源与代码。但写需求这件事，很多人第一次会犯难：「我该怎么说，它才能一次做对？」

答案是话术库。经典版内置了 6 大分类、共 3000 条成型指令，分类分别是：界面美化、弹窗引流、去除限制、常规修改、混淆去毒、插件添加。每一条都不是敷衍的一句「改一下」，而是把五件事写全：要做什么 / 细节要求 / 参数参考 / 范围 / 验收标准。点「选择」直接填进输入框，点「复制」复制正文，自己再改两个字也行。内容来自程序目录下 Resources\话术库.xml，可以手工修改，点刷新重新读——团队可以把自己的规范写进去，全组用同一套表述。

需要换素材的场景，就要用到附件系统。点「选择附件」可以一次挑多个文件，并给每个文件写一句「它是干什么用的」。这里有两道校验很有意思：一是文件现在能不能用——存在、不是目录、不是 0 字节、能读出来；二是用途说明不少于 10 个字。看着严厉，实际是在逼你把「这个文件要放在哪、替代谁」说清楚。附件会被拼成「序号. 文件路径 —— 用途说明」跟着需求一起发给 AI。

为什么附件说明非要写满 10 个字？因为「换图标」这种需求，光给一张图不给说明，AI 只能猜你要替换的是桌面图标、启动页图、还是应用内的某个装饰图。10 个字的门槛，逼你至少写出「这是新的桌面图标，替换全部分辨率」这样一句可用的指引。需求发出去的那一刻，歧义就已经被你自己消掉了一大半——返工率高不高，往往在写需求这一下就决定了。

话术库的五要素拆开看，其实就是一张验收单：「要做什么」定方向，「细节要求」定精度，「参数参考」给参照，「范围」划边界，「验收标准」定义什么算完。手工沟通里最常见的返工，不是做错了，而是双方对「做完」的理解不一样——你以为改两处，他以为改全部。话术把验收提前写进需求里，等于工单和验收单是同一张纸。这也是为什么说它覆盖的不是句型、而是场景：3000 条背后是 3000 个被描述完整的场景，你总能在里面找到自己那一个，然后改两个字变成自己的。

历史里只留你的原话：需求原文会进 history.ini，但附件说明不进历史。回头翻记录时，你看到的是自己当初说的那句话，而不是工具拼装的一堆路径——这让「照上次再改一遍」变得可信。

实例一：批量给自家应用换图标、改版本号，出渠道包

假设你负责自家一款内部应用的渠道分发，市场部说：新 logo 来了，五个渠道包的图标都要换，版本号统一升到 2.4.0，明天要。以前怎么做？你得在解包工具里把五个包分别解开，找到图标所在的分辨率目录，逐个替换对应尺寸的图片，再记着别漏了 ldpi、hdpi、xxhdpi 里的不同文件，然后回编、对齐、签名，五道工序重复五遍，任何一步手抖就得重来。

现在一句话怎么做：把五个包依次拖进工作台，每个项目里附上新 logo 图片（并写明「这是新的应用图标，替换全部分辨率」），输入框写：「把图标准换成附件里的新 logo，把版本号显示改成 2.4.0，其余不动」。点「立刻修改」，AI 改完自动进入打包流程，回编、对齐、签名、校验四步跑完，每个项目里留下一个签好名的 signed 包。

改完怎么验证：看两样——一是出包目录里 build\signed.apk 已经生成，pack.log 里四步全绿，verify 校验通过；二是把包装到测试机上，桌面图标已经是新 logo，应用信息里版本号是 2.4.0。五个渠道包用的是同一套需求表述，换汤不换药，第二批图标再来时，连话术都不用重写。

这个例子里最值钱的不是「快了几分钟」，而是表述被固定下来之后，批量才成立。手工时代做五个渠道包，五次都可能因为描述不一致而出现细微差别；用同一条需求原话走五遍，出来的五个包行为是对齐的。这也是话术库和附件系统存在的根本理由——它让「一次说清楚」可以「反复用得上」。

七、修改历史：照上次那条需求，再改一遍

改同一个包第二次的时候，才是这个工作台真正显本事的时候。点「立刻修改」的那一刻，需求原文和修改日期就写进了 history.ini；详情页直接列出这个项目的全部修改历史，最新在最上，每条显示 #序号 + 时间 + 需求原文——注意是完整显示、不截断。每条右侧有个「选择」按钮，点一下，那条需求就填回输入框。

• 项目列表每条还有个「历史」按钮，可以单独打开历史窗口，一屏对比这个包被改过的几轮诉求。
• history.ini 按 记录1、记录2 递增记录，删掉某一节就等于删掉那条记录——想清理痕迹也很直接。
• 附件说明不进历史，历史里只有你的原话，回头认得出当时想干嘛。

实例二：翻历史记录，照上次需求再改一遍内测包

假设你们团队有一个内部测试包，上周你刚让它「把启动页顶部的内测提醒条改成黄色、文字改成『仅限内部测试使用』」。这周产品说：提醒条的文字要换成新版本的口号，但样式保持不变。以前怎么做？你得翻聊天记录找上周那句话，或者干脆凭记忆重写一遍需求——凭记忆重写的结果，往往和上次对不上，改出来又是一个新偏差。

现在一句话怎么做：打开这个项目的详情页，修改历史里最新那条就是上周那句需求，完整显示不截断。点右侧「选择」，原话填回输入框，只把口号那几个字改掉，其余不动。点「立刻修改」，后续全自动。

改完怎么验证：装到测试机上，提醒条还是黄色、位置还是那个位置，只有文字变成了新口号——和你预期的「样式不变、只换文案」完全一致。这就是历史回填的价值：第二次改，不需要重新描述，只需要改两个字。

往深了想一层：一个项目攒上十几条历史之后，这份记录本身就成了这个包的改动说明书。新同事接手这个包，先翻一遍历史，就知道这包被谁、什么时候、因为什么需求动过。手工改包时代，这份知识往往只存在于某个人的脑子里——人一走，知识就清零。历史记录把它从「记忆」变成了「文件」，这是可追溯和「留了个日志」之间的本质区别。

历史窗口和详情页内嵌历史这两个入口，分工也很清楚：正在干活时，你在详情页就地翻就地填，视线不用离开当前项目；要横向对比「这个包前几次都改了啥」，就用项目列表每条的「历史」按钮单独开窗，一屏看全几轮诉求。记录是死的，能快速浏览才是活的——如果历史只能一行行往下翻、还被截断半句，那它的复用价值就大打折扣。所以「完整显示不截断」这一条，看似不起眼，实则是「历史能不能真的被翻出来再用」的分水岭。

删掉某一节即删某条记录的设计，也让历史保持干净可控。内测包改了十几轮，其中几条是当时试错用的废需求，留在列表里反而干扰视线；找到对应那节删掉，列表立刻清爽。history.ini 按 记录1、记录2 递增，结构简单到你直接看文件也看得懂——不黑盒、可整理，这份坦荡对长期使用的人很重要。

八、打包签名：出正式包的底气，来自这四步

AI 改完，项目目录里会留下一个完成标志，主窗口每 2 秒轮询一次，读到就自动弹出打包窗口——你不用守在屏幕前判断「它到底改完没有」。接下来是固定四步，一步不多、一步不少：

步骤	做什么	为什么不能省
① 回编	apktool b，把改动写回一个可继续处理的包	资源引用对不对，最早在这一步现形
② 对齐	zipalign -p 4，包内资源按 4 字节边界对齐	手工最容易觉得「没必要」跳过的一步
③ 签名	apksigner 配合内置签名完成签名	没签名的包装机即拒，这条没有商量余地
④ 校验	apksigner verify，确认签名真的生效	前三步只看退出码，签没签上要 verify 说了算

第四步 verify 值得单独强调。手工流程里最常见的幻觉就是：命令跑完了、终端没红字，于是默认成功；等到装机报错，才发现签名压根没写进去。前三步都只看退出码，而「到底签没签上」要 verify 说了算。多花几秒钟换一个确认成功，这笔账怎么算都划算。

产物也是分层的：build 目录里留下 unsigned.apk、aligned.apk、signed.apk 三份文件，全过程写进项目目录的 pack.log。每次出包都会生成完整的打包日志 pack.log，产物可追溯——哪天包装不上，你可以顺着日志回到具体某一步，而不是从头再改一遍、再赌一次。跑完可以「保存 APK」，默认名是「应用名_版本号_signed.apk」，一看就知道是谁、哪版、什么状态；也可以直接「打开所在文件夹」。

签名这一块给了足够的灵活度：程序内置一套签名，可以在项目里换成自己的签名文件。详情页「设置签名」里可以选打包用哪套：默认签名、自己的 jks / keystore、或者自己的证书加私钥（pem、pk8）。签名文件从磁盘上挑，设置存进项目配置，之后每次打包直接用，不用重填。对需要对外统一签名身份的团队来说，这一条意味着新包和你们现有的分发体系是对齐的，而不是每次都要人工再签一遍。

打包过程中窗口不给关——这是个看起来琐碎、实际救过很多人的设计：防止你以为它没在跑、顺手把窗口关了，前功尽弃。出包之后用 adb 找手机或模拟器，装上并拉起应用：拉起用 am start 而不是 monkey，启动页组件名分三档查找（项目 config.ini 的 LaunchableActivity → 问设备 resolve-activity → 兜底），装完还用 dumpsys 看一眼前台应用是不是它。手机走 scrcpy 投屏到电脑，模拟器则把窗口提到最前；常见国内模拟器装了但 adb 没连上会自动扫端口连上，模拟器装了没开会问你要不要现在帮它打开，设备没授权会提示你在手机上点「允许 USB 调试」。

为什么拉起应用要专门写 am start、还要三档查找？因为「装上了」和「起来了」是两回事。新版安卓镜像里已经没有 monkey，而且它失败时退出码还是 0——你以为它拉起来了，其实它什么都没干。三档查找从项目配置里最准的启动页开始，逐级兜底；装完再用 dumpsys 确认前台应用真的是它。这套组合拳解决的是内测分发里最憋屈的一种事故：包装上了、你以为成功了，其实它闪退在启动页，而你不知道。

对模拟器用户，这套兜底同样体贴：雷电、MuMu、夜神这类常见模拟器，很多时候你装是装了，但 adb 就是连不上——程序会自动扫端口帮你连上；要是模拟器压根没启动，它会搜出安装路径，问你要不要现在帮你打开。手机没开 USB 调试也不慌，提示你在手机上点一下「允许 USB 调试」就行。设备预览这段的设计哲学和整个工作台一致：把「连不上、拉不起、没授权」这些手工时代要自己查半天的小事故，变成窗口里一句明确的提示。

九、界面与细节：主题、提示条与 AI 工作区窗口

改包是重复性工作，重复性工作里最值钱的优化，是「不需要想」。经典版在界面细节上的投入，全是冲着这个目标去的。

• 10 套配色主题：极夜蓝、深海蓝、紫罗兰、樱花粉、烈焰红、落日橙、古铜金、青柠绿、薄荷绿、石墨灰，点一下立刻换，长时间盯屏不容易疲劳。
• 首页底部使用技巧提示条：每 12 秒轮换一条，内置 191 条「怎么用这个软件」的技巧，可在设置里关掉——把常见用法摊开给你看，而不是等你踩坑。
• 窗口无系统标题栏但可拖动、四边可缩放：窗口能贴着屏幕边缘排布，想怎么摆就怎么摆。
• 双窗口磁吸：AI 工作区窗口停靠在主窗口右侧，两窗高度始终一致，宽度合计固定占屏幕工作区的 3/4；拖宽主窗口，右侧自动变窄；主窗口最小化它跟着最小化，还原一起还原；从任务栏点回主窗口时，右侧窗口会恢复成普通窗口并抬到最前，但不抢焦点——随时能顺手看，又不打断你。

settings.ini 还留给了你自己调的余地：两窗口宽度合计占屏比例、间隙、轮询间隔、最小宽高、启动是否自动停靠、退出是否关闭 AI 工作区进程等，都可以改。命令行参数（--target / --title / --width / --height / --share / --gap / --dock / --no-dock / --verbose 等）只对本次运行生效，适合你临时调整布局。诊断日志也留好了：吸附过程与打包过程记录在 %LocalAppData%\ApkGallary\dock.log，异常进 error.log——出问题先看这两份，比重装一遍程序有效得多。

把这些细节串起来看，会发现它们都指向同一个取舍：把「需要你想」的部分尽量收进程序，把「需要你调」的部分留给配置文件。默认布局适合大多数人，拿来即用；真的不合手，settings.ini 和命令行参数永远向你敞开。无系统标题栏但可拖动、四边可缩放，意味着窗口尺寸没有固定教条，你可以把主窗口拉宽、把对话窗压窄，贴满自己的那块屏幕。10 套主题轮流换，其实也是在照顾长时间盯屏的人——改包是一坐半天的活，颜色舒服不疲劳，本身就是效率。

191 条使用技巧提示条，是另一种「把文档摊开」的思路。新手最怕的不是学不会，而是不知道有什么可学——功能藏在菜单深处，你不知道它存在，自然用不上。提示条每 12 秒轮换一条，每次瞄到一两句，用不了几天，常用技巧就眼熟了。哪天你想起来「上次看到过有这么个功能」，去设置里关掉提示条、按图索骥找过去就行。这种把「说明书」拆成碎片、喂给日常视线的做法，比让你啃一份长文档友好得多。

左边看项目与历史，右边和 AI 对话，两边高度一致意味着滚动和视线不需要重新适应——这个细节，是「天天用」和「偶尔用」之间的分界线。

写在最后：把第一个包拖进来，这条链路就通了

回顾这台工作台的完整链路：自动挑盘建好工作目录 → 拖入六种格式之一 → aapt 报出图标、应用名、包名、版本号、SDK 与启动页 → 8 位随机目录里落下 config.ini 与 source.apk → 后台反编译（12MB 约 3 秒）→ 中文写需求（可从 3000 条话术库里挑）→ 可附多个素材文件并写明用途 → AI 动手 → 完成标志触发自动打包 → 回编、对齐、签名、校验四步 → signed.apk 与 pack.log 落袋 → 装回设备看效果。只需说话，就能让应用变成你想要的样子——这句话对应的，就是这条被收进同一个窗口的流水线。

下面是几位使用者的反馈，他们说得最多的是「链路顺」和「出包有底」，而不是某个花哨功能：

合规提醒：本工具面向自有版权或已获授权的应用，用于学习研究与企业内测等合法场景，请勿用于破解他人付费应用或绕过安全机制。签名密钥可在项目中换成你自己的，请妥善保管。

---

把手上第一个自家包拖进 安卓修改大师智改工坊，写一句话试一次——只需说话，就能让应用变成你想要的样子。

官网：https://www.apkeditor.cn/ · 经典版把导入、解析、改包、出包、留痕收进同一个工作台。