一套工具，多套吸附方案：用命令行参数给智改工坊开分身

「安卓修改大师智改工坊」的核心动作很朴素：拖入安装包，用中文写清需求，AI 改 smali 与资源，改完自动回编 / 对齐 / 签名 / 校验，最后一键装到手机或模拟器看效果。产品介绍页在这里：https://www.apkeditor.cn/ai-version.aspx。

而这篇要聊的是它的另一面：它允许你用命令行参数，给「这一次运行」单独下命令。九个别扭但有用的开关——吸附目标、窗口标题、窗口宽高、两窗占比、间隙、是否吸附、详细日志——都可以在启动的那一瞬间指定，并且只对本次运行生效，不写回 settings.ini。这意味着同一台电脑上，你可以同时拥有好几套「工作姿势」，点哪个入口，就是哪套姿势。

一句话理解这件事：settings.ini 是「我平时的样子」，命令行参数是「我这一次的样子」。前者是长期习惯，后者是一次性指令——两者不打架，因为是后者说了算。

一、为什么需要「这一次的参数」：一个人就有好几种工作模式

先把问题说清楚。你打开这个工具的场景，其实不止一种：

• 赶内测包的时候：你要连续出好几个包，两个窗口必须稳稳并排，越少动作越好。这是「流水线模式」。
• 坐在自己工位慢慢改的时候：你可能会一边改一边查资料、看文档，希望两个窗口占屏小一点，给别的窗口留位置。这是「工位模式」。
• 录屏、做演示的时候：画面的尺寸必须固定，观众才不会看得云里雾里；有时候还要故意让两个窗口同时出现。这是「演示模式」。
• 只想导个包、看一眼历史的时候：你压根不需要旁边的窗口，干干净净只开一个就好。这是「单窗模式」。

如果用 settings.ini 来管这四种模式，你会发现一个尴尬：它是存下来的。为了让「演示模式」生效，你得改配置、重启；演示完想回到平时的样子，还得再改回来、再重启。改一次两次可以忍，一天切换四五次，配置就成了负担。

命令行参数解决的正是这件事。它把「这一次怎么运行」变成启动命令的一部分——用完即弃，不留下任何痕迹。你平时是什么姿势，还是什么姿势；这几次特殊的需求，交给那几条参数。

这也是「多套吸附配置」这个说法的来历：方案不用存在程序里，存在你自己的脑袋和快捷方式里就行。想做几套姿势，就准备几个入口，每个入口带一组参数。

有人会问：为什么不干脆把这些做成界面上的几套「方案按钮」，点了就切换？答案藏在「谁来决定」这件事上。方案按钮意味着程序要替你定义「方案」是什么、有几种、每一项叫什么名字；而命令行参数把这层抽象交给你——你觉得有几套，就有几套；你想怎么组合，就怎么组合。程序只提供零件，不规定成品。

再往细里说，一次运行要指定的事情其实分两类：一类是「长什么样」——窗口多宽、两窗占多少屏、缝留多宽、吸不吸；另一类是「盯住谁、说多细」——吸附哪个程序、认哪个标题、日志要不要详细。这九参数正好把这两类事覆盖到了，多一个显得臃肿，少一个就会缺一块。理解了这层分类，用起来就不容易乱：先想清楚「这次的画面要什么样」，再想「这次临时换个目标试试」。

二、九个参数逐个拆：它们各自管什么

先看总表。参数名与 settings.ini 里的项基本一一对应——配置里能长期设的，这里能临时指定。没写的项就沿用配置值，所以一条命令通常只会用上其中两三个。

这里有个很好用的习惯：只写差异。你的 settings.ini 里已经把日常姿势定好了（比如占比 3/4、间隙留一点、启动吸附）；今天想让两窗铺得更满，就只加一句比例；今天只是想导个包，就只加 --no-dock。参数写得越少，读起来越清楚，也越不容易和配置里的长期值互相干扰——记住顺序：参数优先，其余照旧。

第一组：跟「目标」有关的两个

--target 决定这次吸附谁。默认情况下，程序启动时会自动挑工作目录下的 tools\zcode\zcode.exe 作为目标程序（这一项本身也可以在 settings.ini 里长期改）。用 --target 的好处是「试一次」：你不用为了试一个新目标去动配置文件，试完不满意，下次不带这个参数就是老样子。

--title 管的是「认哪个窗口」。同类程序开多个窗口是常事（比如两个同名的对话窗口），标题就是它们的身份证。这个参数存在的意义是让吸附更准确：目标找对了，后面所有窗口姿势才有意义。

第二组：跟「尺寸与占比」有关的四个

--width 与 --height 直接给主窗口定尺寸，适合「画面要固定」的场合：录教程、做演示、给同事复现一个问题。配合的无边框窗口可以拖动、四边可缩放，所以就算你觉得这次定得偏小，也能当场拉大——参数定的是起点，不是牢笼。

--share 是四个里最值得记住的一个：它管两窗宽度合计占屏幕工作区的比例。默认是 3/4——两窗一共吃掉四分之三，剩下的留给桌面。这次想铺满，就把比例往上给；这次想留出小半屏方便查资料，就往下调。

--gap 管两窗之间那条缝。缝小，两个窗口看起来像一整块连续的工作区；缝大一点，边界更清楚，鼠标不容易点错边。演示的时候留一条缝通常更好看，干活的时候贴合更顺手——正好可以用参数按场合切换，不必每次都去改配置。

第三组：跟「吸不吸」有关的两个（互斥开关）

--dock 与 --no-dock 是一对反义词，作用是把这次运行的态度说清楚：带上 --dock，这次启动就把目标程序吸到主窗口右侧；带上 --no-dock，这次就老老实实单窗运行，谁也不打扰谁。

它们之所以有用，是因为「要不要吸附」这件事跟当天的任务强相关。你今天只是导包、看历史、把上次的需求填回来再跑一遍——这种时候旁边多一个窗口纯粹是干扰；你今天要连着出三四个内测包，那两窗并排就是刚需。与其去改配置、重启、再改回来，不如给两种场合各做一个入口。

顺带说一句吸附之后的行为，免得你第一次用吓一跳：吸附状态下，两窗高度始终一致，宽度合计按比例固定；你拖宽主窗口，右侧自动变窄；主窗口最小化它跟着最小化，还原时一起还原；你从任务栏点回主窗口时，右侧窗口会被恢复成普通窗口并抬到最前，但不会抢焦点——你正在敲的需求不会被弹上来的窗口打断。

第四组：只有一个，但最有用 —— --verbose

--verbose 让这次运行输出更详细的过程信息。它的最佳用武之地是「这次怎么没吸上」「这次窗口怎么怪怪的」这类偶发问题。程序本来就有过程日志：吸附过程与打包过程写在 %LocalAppData%\ApkGallary\dock.log，异常写进同目录的 error.log，单个包的出包全过程写在项目目录下的 pack.log。带上 --verbose 跑一次，再去看 dock.log，通常一眼就能看出卡在哪一步。

排查完就把这个参数去掉——详细日志是诊断工具，不是日常配置。这也是命令行参数的可爱之处：用完就没了，不会在你平时的使用里留下噪音。

再交代一句优先级，免得你心里没底：参数优先于配置。带了参数的项按参数走，没带的项照旧读 settings.ini。所以「带参数」不是「换一套配置」，而是「在这次运行上打几个补丁」。也正因为如此，你永远不会出现「带了一次参数，以后全变了」的情况——下一次不带参数的启动，仍是你的日常姿势。

三、把方案装进入口：三个快捷方式，三套姿势

参数写在命令行里，但如果每次都要手敲一遍，那就没人会用。真正的用法是把命令做成入口——在 Windows 上最顺手的做法就是快捷方式：把参数追加在目标（主程序路径）后面，双击哪个快捷方式，就是哪套姿势。

这件事本身属于 Windows 的常规操作，不是程序特有的功能：右键快捷方式 → 属性 → 在「目标」一栏的程序路径后面空一格，把你需要的那几个参数接上去就行。做完之后，你的桌面上就可以同时摆着几个「不同性格」的智改工坊。

有了这三个入口，你在机器上就同时有了三套「吸附配置」——但它们没有占用任何配置文件的条目，也没有把 settings.ini 改脏。方案是「在入口上」的，不是「在程序里」的。这一点在多人共用一台电脑、或者你自己白天晚上两副工作状态时，差别特别明显。

上手时有三个小习惯值得提前养成。第一，参数写完先只加一个，跑起来确认行为符合预期，再往上叠——一次加五个，出问题你也不知道是哪一条的锅。第二，把每条命令在自己心里翻译成一句中文，比如「这次铺满屏、贴紧一点、启动就吸附」，读起来顺了，说明你想清楚了。第三，路径类的值（比如 --target）用引号包住，Windows 下的反斜杠与空格最容易在这里出岔子；能不能吸上，往往就取决于这个细节。

还有一条经验：别把入口做得太多。三到四个足够覆盖你 90% 的场合；做了十几个入口，最后你会记不清哪个是哪个。方案的价值在于「不用想」，一旦选择本身变成负担，就该合并了。

再补一个便利之处：如果你习惯把常用命令记在便签里，可以把这几条参数抄下来，需要时直接粘到「运行」框里或者命令行窗口里执行。参数是纯文本，抄写零成本；而「打开设置 → 找到那一项 → 改数值 → 保存 → 重启 → 用完后改回来」这一串动作，显然不适合一天做五遍。

顺带说，纯文本还有一个隐性好处：它能被写进文档、写进团队的内部说明里。比如你们团队的内部规范可以写一行「做内测包请使用 --dock --share 0.9 --gap 4 启动」，新同事照着做，得到的画面和你的一模一样。而那些只存在于界面里的开关，就没法这样精确传递——「你把那个拖到大概这么宽」永远比不上一条命令准确。

如果你更习惯「点一下就跑」，也可以把命令写成一个小脚本文件放在项目目录旁边，或者干脆记在项目的改动说明里，下次复制粘贴。命令行参数不要求你必须会写脚本，它只是一串文本——你怎么舒服怎么来。

四、「不写回配置」这四个字，价值在哪

这一节专门讲一个看起来最技术、实际上最省心的设定：命令行参数只对本次运行生效，不写回 settings.ini。很多人第一反应是「那多麻烦，为什么不直接存下来」——恰恰相反，不存才是它的价值。

往大一点说，这体现的是同一种设计态度：把「长期习惯」和「一次性需求」分开对待。长期的东西值得沉淀（所以有 settings.ini、有 history.ini、有项目目录）；一次性的东西不该留痕（所以命令行参数用完即弃）。很多工具让人越用越乱，就是因为把这两类需求混在一起——临时改一次，永久生效，最后没人说得清当前是什么状态。

你可以把这条原则用到自己的改包习惯上：一次性的试验，用命令行参数；确定下来的偏好，才写进 settings.ini。两边各司其职，随时都能说清「现在是什么姿势、为什么是这个姿势」。

这套「长期 / 一次性」的分工，其实贯穿在这个工具的很多地方，只是形态不同：项目目录是长期的（每个项目一个 8 位随机字符串目录，自动写 config.ini、拷一份 source.apk），修改历史是长期的（history.ini 按记录1、记录2 递增，删某一节即删那条记录），出包记录是长期的（build 目录里的三份产物 + pack.log），而这次运行带的那几个参数，是一次性的。你越清楚哪样东西该被留下、哪样该被丢掉，工作台就越不容易变成一团乱麻。

换个角度说：工具愿意在「不写回」这件事上克制，恰恰说明它把配置当作你的东西，而不是它的东西。你的 settings.ini 应该只记录你真正认可的长期偏好；任何一次临时实验，都不该在背后偷偷改掉它。

验证方法也很简单：带上参数启动一次、看一眼姿势；关掉程序，不带参数再启动一次——如果回到了你 settings.ini 里的老样子，就说明参数确实没有写回配置。想看得更细，加一次 --verbose，再去 %LocalAppData%\ApkGallary\dock.log 对照这一次的吸附过程记录。

五、参数之外，姿势里面：这套工具本身长什么样

既然这篇讲的是「姿势」，不妨把与姿势关系最紧的几处细节一次说清，方便你判断哪一套方案适合自己。

窗口是无边框的。没有系统标题栏，但可以拖动、四边可缩放——省下来的那一条高度还给内容，改包界面信息密度高，多一行日志就是多一行信息。也正因为无边框，「两窗贴合像一整块」这种效果才成立：不会出现两条系统标题栏叠在一起的横杠。

吸附行为是「有礼貌」的。两窗高度始终一致、宽度合计按比例固定、主窗口最小化它跟着最小化、还原一起还原；从任务栏点回主窗口时，被吸附窗口会恢复成普通窗口并抬到最前，但不会抢焦点。这些细节决定了并排工作时，你会觉得「它俩是一套的」，而不是「两个窗口在互相较劲」。

设备预览不需要你操心。包打完之后，工具用 adb 找手机 / 模拟器，装上并拉起应用：拉起用的是 am start（而不是 monkey——新版安卓镜像里已经没有了，且它失败时退出码还是 0，容易误判成功）；启动页组件名按三档查找，先看项目 config.ini 里的 LaunchableActivity，再问设备 resolve-activity，最后才退回 monkey；装完还会用 dumpsys 看一眼前台应用是不是它。手机可以走 scrcpy 投屏到电脑，模拟器则把窗口提到最前面。常见的国内模拟器（雷电 / MuMu / 夜神等）装了但 adb 没连上时，会自动扫端口连上；模拟器装了没开，会搜出安装路径并问你要不要现在帮你打开；设备没授权，会提示你在手机上点「允许 USB 调试」。

打包这条线是完整的四步。回编（apktool b）→ 对齐（zipalign -p 4）→ 签名（apksigner + testkey）→ 校验（apksigner verify）。多做一步 verify 的意义在于：前三步只看退出码，「到底签没签上」要 verify 说了算。产物分三份落在 build 目录（unsigned.apk / aligned.apk / signed.apk），全过程写进 pack.log；打包过程中窗口不给关，避免你误以为它没在跑；跑完可以「保存 APK」（默认名是 应用名_版本号_signed.apk）或「打开所在文件夹」。签名密钥默认用工作目录根目录下的 testkey.pk8 / testkey.x509.pem，可以替换成你自己的。

「姿势」之外，「内容」这条线也值得顺一遍，因为它们是一起用的。导入这一步支持拖入或选择，APK / JAR / APKS / XAPK / APKM / CLASS 都能进来；解析用工作目录里的 aapt，读出图标、应用名、包名、版本号、最低与目标 SDK、启动页，解析与反编译都跑在后台线程，界面不卡；反编译失败也不影响项目本身——配置、图标、源包已经落地，程序会提示原因并给出日志路径（apktool.log）。写需求时，话术库的六大分类（界面美化 / 弹窗引流 / 去除限制 / 常规修改 / 混淆去毒 / 插件添加）里有成型指令可以点「选择」直接填进输入框，也可以点「复制」把正文拿走；需要带素材就点「选择附件」，一次挑多个文件并各写一句用途说明。

这些动作和你选的「方案」是配套的：方案决定画面怎么摆、多久提醒一次、出包后设备怎么装；内容那条线决定这一个包被改成什么样。两条线都很顺的时候，你才真正感觉不到工具的存在。

六、把「多套方案」用起来：两个自家应用的实例

讲了这么多参数，最终还是要落到「改包」这件事上。下面两个例子改的都是自己的 / 内部的应用，重点看每一步「以前怎么做 / 现在一句话怎么做 / 改完怎么验证」，以及方案切换在这里起了什么作用。两个例子的共同点是：真正决定效率的并不是参数本身，而是参数让「这一次」不再需要你去想窗口的事，注意力可以整段留给需求与验收。

实例一：三个自有应用一起换品牌主色（内测流水线方案）

以前怎么做：品牌换了主色，三个自有 App 都要跟上。手工路子是把三个包分别解开，各自去找颜色资源与主题样式，逐处改完再回编、对齐、签名，最后一个个装到手机上看。三个包意味着三遍同样的收尾动作；更麻烦的是「对照」——你希望一边改一边看着改前改后的截图，窗口摆布就得来回折腾，注意力被切成好几段。

现在一句话怎么做：先用「内测流水线」入口打开本次运行（--dock --share 0.9 --gap 4），两窗铺开贴合，左边主窗口、右边 AI 窗口。然后把第一个包拖进来建项目（每个项目一个 8 位随机字符串目录，自动写 config.ini、拷一份 source.apk），在输入框里写一句范围清楚的需求：

点「立刻修改」之后，需求原文进 history.ini，AI 改完在项目目录留下 ai_done.flag，主窗口按轮询间隔读到它，自动弹出打包窗口，接着四步走完。这个包出完，切到下一个项目，把同一条需求从历史里点「选择」填回来（历史按最新在最上排列，显示序号 + 时间 + 需求原文，完整不截断），再跑一遍——三个包，同一套姿势，一气到底。

改完怎么验证：每个包都走同一条验收线——verify 已经由流水线自动跑过；打包完成后 adb 装上并拉起；然后按屏幕逐个核对首页、列表、详情、设置，确认没有漏网的旧色。三个包都验完，再来一次整体对照：三个应用摆在一起，主色应该是一致的——这正是「统一品牌色」这件事的验收标准。

实例二：给演示用的自家包换启动图（录屏演示方案）

以前怎么做：要给内部同事演示新版启动效果，得先准备演示包：把自家应用的启动图替换成演示素材，回编、对齐、签名，再装到演示机上。除此之外还有一件容易被忽略的事——录屏画面的稳定性：每次录之前你都要手动把窗口拖成差不多的大小，录出来每一段的构图却总有出入，观众看着就会分神。

现在一句话怎么做：用「录屏演示」入口打开本次运行（--dock --width 1366 --height 820 --gap 12），画面尺寸与两窗间距就此定死，每一段录制都一致。然后拖入自家的演示包建项目，把新的启动图当附件选上——点「选择附件」可以一次挑多个文件，并给每个文件写一句「它是干什么用的」，工具会校验文件能不能用（存在、不是目录、不是 0 字节、能读出来）与说明不少于 10 个字，校验通过后拼成「序号. 文件路径 —— 用途说明」跟着需求发出去。需求写：

改完怎么验证：出包后工具自动装到手机 / 模拟器并拉起（手机可以走 scrcpy 投屏到电脑，方便一边讲一边看），确认启动那一屏是新素材、进入首页正常；然后正式录屏。录完回放检查每个片段的窗口构图是否一致——这是参数带来的附加收益：画面稳定，讲的人省心，看的人专心。

再补一个「一天之内怎么切换方案」的真实剧本，你可以对照自己的节奏看看像不像：

• 上午十点，赶内测包：点「内测流水线」入口，两窗铺开贴合；把三个自有应用的改动一条条写下去，出包、装机、核对，一气做完。
• 中午，临时看一眼历史：点「工位单窗」入口，单窗打开，翻项目列表、看看上周那条需求怎么写的，把需要复用的那条点「选择」记下来。
• 下午三点，给同事演示：点「录屏演示」入口，画面尺寸固定，两窗同时在场，讲一遍「从拖包到装机」的完整链路。
• 下班前，遇到一个偶发问题：给入口临时加上 --verbose，跑一次，翻 dock.log 找到原因，把参数去掉，收工。

注意这套剧本里，settings.ini 从头到尾没有被动过一次。你切换了四次姿势，但每次都是「点一个入口」的动作量。这就是把方案放在入口上、而不是放在配置里的意义：切换成本越低，你越愿意按场合用对的姿势。

七、用户评价：他们把哪几套方案留了下来

最后照例放几条使用者的话。有意思的是，提到命令行参数的人，夸的往往不是「功能多」，而是「试错不怕留痕」——不怕试，才会真的去试；而一个工具的顺手程度，恰恰是被「你愿意试多少次」决定的。

另一个反复出现的评价是关于「稳定」：参数固定之后，同一个人在不同时间、不同心情下做同一件事，做出来的画面是一样的。对需要给同事演示、需要录教程、需要写内部文档的人来说，这种可复现性本身就是价值——你要的不只是「这次顺手」，而是「每次都能顺手」。

八、合规提醒、上手顺序与结尾

这套用法适合谁？简单说三类人：第一类是每天都在连续出包的自研团队（测试、运营、产品），你们的诉求是「姿势固定、动作最少」；第二类是需要在不同场合切换的人——白天办公、偶尔演示、还要录点教程，一台机器要顶三种用途；第三类是喜欢把环境捏成自己形状的独立开发者与爱好者，你们不满足于「默认能用」，希望每一处都能解释清楚。如果你只是偶尔改一个包，那就记住 --no-dock 和 --verbose 这两条，也够用了。

如果你想把「多套方案」用起来，按这个顺序最省事：

1. 先定日常：把平时最常用的姿势写进 settings.ini（占比、间隙、轮询间隔、最小宽高、启动是否吸附、退出是否关闭被吸附程序），这就是你的「默认值」。
2. 再建入口：为两三种特殊场合各建一个带参数的快捷方式，比如「内测流水线」「录屏演示」「单窗导包」。
3. 试一次目标：想换吸附对象时先用 --target（必要时配 --title）试，满意了再考虑写进配置。
4. 出问题加日志：带 --verbose 跑一次，去看 %LocalAppData%\ApkGallary\dock.log，别靠猜。
5. 跑通一条链路：拖入自有的包，写一句范围清楚的需求，走完「AI 改包 → 回编 / 对齐 / 签名 / 校验 → 装机看效果」。
6. 把好东西攒下来：确定下来的偏好进 settings.ini，验证过的需求留在 history.ini，一次性的试验交给命令行参数。

---

安卓修改大师智改工坊想做到的，是让「改一个包」这件事变成一句话；而这些参数想做到的，是让「这一次怎么工作」也由你说了算——这次怎么摆，参数说了算；而改包本身，交给那一句中文就够了。

产品介绍页：https://www.apkeditor.cn/ai-version.aspx　官网：www.apkeditor.cn

今晚就先加一个参数试一次：把 --verbose 带上，看看你的工具平时到底在做些什么。