一次改几十处文案：三层分布摸底、分批推进与逐批验机的工程方法

先说清楚我们在解决什么。安卓修改大师智改工坊是一款 Windows 桌面工具，把"改 APK"这件事压缩成一句话：拖入安装包，用中文写需求，AI 改 smali 与资源，改完自动回编、对齐、签名、校验，最后一键装到手机或模拟器上看效果。产品介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。

现在假设一个真实场景：自家应用要换一套文案规范 —— 按钮上的"确定"统一成"保存"，"取消"统一成"暂不"，再加上十几处提示语、七八个 Toast、两三个弹窗标题。粗粗一数，四五十处。这种活看起来是"查找替换"，做起来却完全是另一回事：文案不是集中在一个文件里，而是散在三层结构里；而"一次全改"比"分三次改"更容易翻车。

这篇文章不谈"能不能改"，谈"怎么改不返工"。我们会讲清三件事：反编译出来的工程里，文案到底分布在哪三层；"批量"这个词在 AI 改包的语境下意味着什么风险；以及这套工具为什么把修改历史设计成"只留用户原话"、还要在每条记录旁边放一个「选择」按钮 —— 这三件事合起来，就是文案批量替换的工程方法。

一、文案其实住在三层楼里：先摸底，再动手

导入一个安装包、建好项目之后，反编译产物就在项目目录的 apktool 子目录里。它的结构是固定的几个部分：apktool.yml（回编时用的元信息）、AndroidManifest.xml（清单）、smali（代码）、res（资源，含布局与字符串）。要改的文字，就分住在其中三处：

为什么要先摸这一遍底？因为漏层的症状极其误导人：你在资源层把所有"确定"都改成了"保存"，装机一看，主界面的按钮变了，可弹窗里还是"确定" —— 于是你以为"改没生效"，其实是那个弹窗的按钮文字本来就写在布局里。三层楼的比喻不是修辞，它决定了"改哪里"和"怎么验收"。

层级	位置	影响面	主要风险
资源层	res/values/strings.xml（含多语言目录）	最大，改一处全局生效	多语言目录漏改；键名被多个界面共用，改完语义变味
布局层	res/layout 下的 XML 内联文本	中等，一处只影响一个界面	在资源里搜不到，容易整层漏掉
代码层	smali 里的常量字符串	最分散，提示语与拼接串为主	关键字搜不全；改错上下文会伤到逻辑

这里有个很实用的用法：把"摸底"本身当成一条需求发出去。 你可以先不改任何东西，在需求框里写"先不要改，请扫描整个工程，列出所有出现『确定』『取消』这两个词的文件路径与所在层级，按资源层 / 布局层 / 代码层分组给我"。AI 在项目工作目录里干活，读文件、列清单是它最擅长的事。这份清单拿到手，接下来的"批次"就有了划分依据 —— 而不是拍脑袋决定这一批改哪里。

摸底还有一个副作用是好的：它会顺手回答"哪些不能改"。 有些"确定"出现在资源键名里、有些出现在协议字段、有些出现在日志里 —— 这些地方改了没意义甚至有害。清单里看到上下文，你才知道该给 AI 圈多小的范围。

二、"批量"在 AI 改包语境下的真实含义：改动面 = 排查成本

在别的工具里，"批量替换"的默认心智模型是"一次全改最省事"。在 AI 改包的语境下，这个直觉要反过来：一次改动的面越大，出问题时定位的成本越高。 原因不在工具有没有"撤销键"，而在于改动的形态。

先看回滚这件事的层次。这个工具给每个项目准备了一个存档点：导入时会把原始包复制成项目目录下的 source.apk，改坏了想重来，靠的就是它。但它是"整包级"的回滚 —— 回到导入那一刻，中间所有的批次一起作废。真正省时间的回滚粒度，是"这一批作废，前几批保留"，而要做到这一点，靠的不是某个按钮，而是批次切得足够小、并且每一批都有据可查。

再看 AI 这一侧。一次需求发出去，AI 会在工程里连做十几个文件改动，它是一个整体：字符串改了、引用它的布局改了、拼接逻辑也顺手调了。这一整套动作里只要有一处判断错（比如把日志里的关键字也一起换了），你拿到的不是"一处小错"，而是一个需要重新逐个确认的改动集合。改动面越大，这个集合越大，逐个复核的成本就越高。

这也是为什么这套工具把"重来"的成本刻意压低。工作目录是启动时自动挑的盘：按 D → E → F → G 的顺序找第一个能读写、且剩余空间不少于 1GB 的盘，都不行才退回 C 盘 —— 系统盘权限限制多，所以放在最后。1GB 这条线不是摆设：反编译产物加上打包的中间文件很占地方，盘快满的时候先换一个盘，免得解压到一半失败留下半套环境。项目之间存在物理隔离：每个项目一个 8 位随机字符串目录，各装各的 config.ini、history.ini、source.apk 与反编译产物，删掉一个项目不会碰到别的。磁盘剩余空间在用户中心的统计里能直接看到，装不下这件事你提前就知道。

顺带说一个让"放开手试"更轻松的设计：大师币不够时，导入安装包、编辑项目都不受影响，只有详情页点「立刻修改」和「去打包」才会提示。也就是说，摸底、翻历史、改需求这些动作可以放心做，成本只在真正发起改动的那一刻产生。这个卡口位置是刻意的：把限制放在"改动"上，而不是放在"准备"上，用户就不会因为担心消耗而不敢先摸清楚情况。

三、批次的两件事：怎么切、怎么管

先切：四种切法与一个上限

有了摸底清单，切批次就是一道选择题。以下是四种常用切法，按"什么时候用"来组织：

切法	适合场景	优点	陷阱
按层级切	同一个词在多层都出现（最常见的"确定/取消"）	每批的搜索范围明确，漏没漏一眼可查	验机时要把三层都对一遍，别只看主界面
按模块切	文案按业务分块（登录、订单、设置各一套）	验收路径短，点几下就能走完一个模块	同一个字符串被多个模块共用时，归属要想清楚
按风险切	先改纯显示文本，后改带占位符的格式化字符串	风险的改动单独成批，出问题不受牵连	批次数量会变多，需要历史记录配合管理
按语言切	多语言包里只改中文，或中英一起改	语言目录互不干扰，出问题范围清晰	只改默认目录会留下"切语言就露馅"的隐患

四种切法都要遵守同一个上限：一批只围绕一个主题，并且这一批是你今天能改完、能验完的量。 几十处文案按层级切就是三批，每批十几处 —— 这个量级的好处是，AI 改完之后你有耐心逐处看一眼；如果一口气发五十处，改完大概率是"翻一翻、感觉没问题"，而"感觉没问题"在装机之前不算数。

还有一个细节值得单独提醒：带占位符的字符串要单独对待。 "还剩 %1$d 次"这类字符串里，%1$d 是参数占位，改动时如果把占位符弄丢或弄乱顺序，轻则该处显示异常，重则整段文字错位。把它单独成批、单独验收，是成本最低的保险。

再管：修改历史与「选择」回填

批次切好了，接下来是管理问题：做到第三批的时候，你还记得第一批当初是怎么写的需求吗？下一轮改的时候，怎么把某批"照原样再来一遍"？这套工具给的答案是修改历史。

每次点「立刻修改」，程序会把这句需求原文连同修改日期写进项目目录下的 history.ini，按"记录1、记录2……"递增。详情页里直接列出这些历史，最新的一条在最上面，每条显示序号、时间和需求原文 —— 原文完整显示，不截断；项目列表里每条记录的「历史」按钮打开的是同一个历史窗口。想删掉某条历史，把 history.ini 里对应的那一节删掉就行。

这里有一个设计决定值得展开讲，因为它直接决定了历史列表在批量任务里好不好用：history.ini 里只留用户自己写的原话。 你对外发出去的那段文本其实是三部分拼起来的 —— 你的原话 + 附件说明 + 一段固定的环境说明（告诉 AI 切到哪个工作目录改、改完怎么留标志文件、不要在它自己那边打包）。后两部分都不进历史：附件说明属于"这次要改什么"的临时细节，环境说明是给 AI 的操作约定，逐字逐句都一样。如果它们也写进历史，回看时满屏都是重复的模板句，真正有用的"那一批改了什么"反而被淹没。

每条历史右边的「选择」按钮，则是批量任务里省时间最多的一处：点一下就把它填回需求输入框。它的正确用法不是"重复劳动"，而是"承接上一批" —— 比如上一批的原话是"把资源和布局里所有『确定』『取消』改成『保存』『暂不』"，这一批你点「选择」把它填回来，然后在后面补一句"这次只管 smali 里的硬编码提示语"，就是一条边界清晰的新需求。填回来的是文本，历史记录本身不会被改动；新提交的需求会作为新的一条记录追加进去，旧的记录一直在。

把这两件事合起来，你会发现"批次"在工具里是有实体的：一条历史记录 = 一个批次。记录序号就是批次顺序，记录原文就是批次边界，「选择」就是"接着上一批往下做"。不需要在记事本里另开一个进度表 —— 台账就在项目目录里，换个项目也不会串（从项目列表的「历史」进来时，会先把那个项目的详情页打开，再回填那条需求）。

顺着这个思路，一条"批次需求"该怎么写就清楚了。它和随手写的需求不一样，要写全四件事：范围（这一批只动哪里）、目标（改成什么）、例外（哪些不要动）、验收（改完怎么算过）。

要素	这一批可以怎么写	反例（容易翻车的写法）
范围	"只改 res/values 下的字符串资源，不要动布局和代码"	"把所有确定都改了"（没说改哪里，AI 只能自己发挥）
目标	"『确定』改成『保存』，『取消』改成『暂不』，保持原有标点"	"文案优化一下"（没有可比对的验收标准）
例外	"日志、协议字段、键名里的同名词不要动"	只字不提例外，等于允许全局替换
验收	"改完列出所有被改的文件与位置，方便我逐个对照"	不要求输出清单，全靠自己翻

如果你一时不知道该怎么说全这四件事，还有一个起点：详情页的「选择话术」里有六大分类、共 3000 条成型指令（界面美化 / 弹窗引流 / 去除限制 / 常规修改 / 混淆去毒 / 插件添加），每条都把"要做什么、细节要求、参数参考、范围、验收"写全了。挑一条填进输入框，再按自己这一批的边界改几句即可 —— 这套结构的价值不在于话术本身，而在于它示范了"一条能落地的需求长什么样"。这些话术存在程序目录的 Resources\话术库.xml 里，可以手改，改完点刷新重新读。

四、每批改完立刻验机：把"等"的时间换成"查"的确定性

批次推进的最后一环是验收。工具在这条链路上做了一次很关键的自动化：AI 改完，主窗口会自己知道。 具体机制是这样 —— 发给 AI 的那段环境说明里约定了"确认全部改完之后，在项目工作目录下生成一个名为 ai_done.flag 的标志文件"；主窗口每 2 秒轮询一次，读到这个文件就认为改完了，并且立刻把它删掉，然后自动弹出打包窗口。开始等待之前还会先清一次同名的残留文件，保证等到的是这一轮、而不是上一轮留下的；等待上限是一小时，超时会明确停止等待，不会永远挂着一个"等待中"。

为什么会用"写文件"这种朴素的方式当信号？因为 AI 那边是一个聊天窗口，没法直接回调主程序。写文件、读文件这个约定最简单也最可靠：AI 容易照做，文件读不到也不会把谁卡住。它的工程含义是：你不需要盯着看，改完那一刻，打包窗口自己会弹出来。

接下来是打包四步：回编（apktool b -f -o build\unsigned.apk）、对齐（zipalign -f -p 4）、签名（apksigner + testkey）、校验（apksigner verify --print-certs）。前三个产物依次落在项目目录的 build 子目录里：unsigned.apk → aligned.apk → signed.apk，全过程写进项目目录下的 pack.log。这里为什么要多做第四步？因为前三步只看退出码，而"到底签没签上"要 verify 说了算 —— 密钥格式不对（pk8 不是 DER、pem 不是 X.509）这类问题，只有这一步会明确报出来。校验通过时会打印签名证书信息，拿这一行就能确认"确实签上了"。

打包完成之后，勾上"打包后自动运行"，程序会用 adb 找到手机或模拟器，把包装上并拉起应用。这里有两个细节都是"照实说"的产物：拉起用的是 am start 而不是 monkey —— 新版 Android 镜像里已经没有了 monkey，而且它失败时退出码依然是 0，只看退出码会把失败当成功；装完之后还会用 dumpsys 看一眼前台应用到底是不是它 —— "命令返回成功"和"应用真的显示出来了"是两回事。手机走 scrcpy 把屏幕投到电脑上，模拟器则把窗口提到最前面。

五、两个自家实例：分批改文案，改完就验

下面两个例子都来自我们自己和同事的日常改包场景，用的都是自家应用与自家素材，重点看"以前怎么做、现在一句话怎么做、改完怎么验证"这三步。

实例一：自家「记账助手」的 40 多处按钮与提示统一

背景：自家记账助手的安卓版要上线一套新的文案规范 —— 界面上的"确定"统一改成"保存"，"取消"统一改成"暂不"，同时把十几处提示语的口吻统一。粗数下来四十多处，散落在三个层级里。

以前的做法：反编译之后自己上手翻。先在 res/values 里搜一轮，改完回编、签名、装机；发现弹窗里的按钮没变，回头再翻 res/layout；又发现有几个 Toast 没变，再进 smali 里一个个找。最要命的是最后一步：四十多处一次改完，装机之后你只能靠"翻一翻界面"来确认，弹窗、Toast 这类一闪而过的地方根本没法确认全 —— 往往要靠测试同事在某个犄角旮旯里截图反馈，才发现漏了一处。整件事的返工率不低，而且每次返工都是从头再来一轮。

现在的做法是切成三批。 第一批：在需求框里写"只改 res/values 下的字符串资源，把『确定』改成『保存』、『取消』改成『暂不』，日志与键名里的同名词不要动，改完列出被改的文件清单"，点「立刻修改」。AI 在项目目录里改完，留下 ai_done.flag，主窗口读到后自动弹出打包窗口；四步打包跑完，勾上"打包后自动运行"，装机拉起，走到主界面点几下按钮看一眼 —— 资源层的改动会同时体现在所有引用它的界面上。

第二批：点历史列表里第一条记录右边的「选择」，把它填回输入框，补一句"这一批只管 res/layout 里内联的按钮文字，范围和改法照上一条"。第三批同理，把范围收窄到 smali 里的硬编码提示语与 Toast。每一批都走"改 → 自动打包 → 装机 → 点到那个界面看"的同一套流程，每批结束之后历史里就多一条记录，三个批次的边界一眼可查。

改完怎么验证？ 除了逐批装机看界面，还有一个"对账"动作：第二批和第三批的需求里都要求"改完列出被改的文件清单"，拿这份清单去和第一批摸底时列的清单对一遍，两层楼的清单加起来覆盖了全部候选位置，才算改完。最后再跑一次整包装机，把弹窗、提示、Toast 都触发一遍 —— 因为每一批都单独验过，这一轮回归更像盖章，而不是提心吊胆的抽奖。万一某一批出了纰漏，处理方式也很直接：那一批作废，回到上一批的状态重做，前面两批的结果不受影响。

实例二：内部「巡检打卡」工具的一次半中半英整改

背景：公司内部给巡检同事用的打卡工具，界面主体是中文，但历史遗留了一批英文残留：几个第三方组件自带的提示、几处错误信息、还有两处拼接出来的"XX failed"。数量不多，但分布极散 —— 这正是"代码层"文案的典型形态。

以前的做法：按关键字在反编译产物里搜，搜到什么改什么。问题在于：英文残留没有统一的关键字 —— 有的是 "Failed"，有的是 "Error"，有的干脆只有一个 "Retry"。你搜不全，就只能遇到一处补一处；而"遇到"这件事依赖你把每个功能都点一遍，内部工具的边角功能又恰恰是平时没人点的那些。这个活拖了三轮都没收干净。

现在的做法：先摸底、再切批。 第一条需求不要求改动："先不要改任何东西，扫描整个工程，把所有面向用户的英文提示（字符串资源、布局内联、smali 常量）列出来，给出文件路径、原文和它出现的上下文。" 拿到的清单比预想的长 —— 有几处根本不在"界面"上，而在组件的默认提示里。按清单切成两批：第一批改资源层与布局层（改动直观、验收快），第二批专门处理 smali 里的常量，改动时逐条对着清单走，要求"改完把每一条对应的文件位置列出来"。

改完怎么验证？ 内部工具的验收方式和商业应用不一样：不求界面好看，求"点到的每个角落都不再蹦英文"。做法是拿清单当验收脚本，一条一条在真机上触发对应场景 —— 因为清单里连"这句话在哪个场景出现"都记了，验收从"翻遍整个应用"变成了"照着清单打勾"。第二批里改的是 smali 常量，风险比前两批高一点，所以这一批的验证格外具体：装机之后先把主流程完整走一遍（打卡、上传、查看记录），确认没有因为改字符串伤到逻辑，再开始逐条点边角场景。

这两个实例放在一起看，方法论其实只有一条：摸底把不确定变成清单，分批把清单变成可验收的小块，逐批验机把"验收"固定在每一次改动之后。 工具在其中的角色不是替你决定切几批，而是让"切批"这件事没有额外成本 —— 历史记得住每一批说过什么，「选择」能把上一批原话拿回来，改完打包装机全自动。批次管理真正贵的地方从来不是切多细，而是每切一刀之后要不要额外做一堆手工活；这些手工活被压掉之后，批次才切得动、切得起。

六、一个补充：附件在批量任务里的正确用法

批量文案替换里有一类"不能写在正文里"的信息，需要靠附件传过去：比如一份术语对照表、一张要照着改的界面截图、一份新文案的 Excel 导出。点「选择附件」可以一次挑多个文件，并且必须为每个文件写一句"它是干什么用的" —— 说明不少于 10 个字，这个下限不是为难人，而是防止"只甩一串路径"：AI 拿到一个文件路径，并不知道你是要"替换成它"还是"照它里面的格式改"。

选附件时程序会当场校验两件事：文件现在能不能用（存在、不是目录、不是 0 字节、能读出来），以及说明够不够 10 个字。前者尤其值得说一句 —— "能读出来"意味着被别的程序独占锁住的文件也会被拒收，因为那种文件发给 AI 同样是读不到的。确认之后，附件会拼成"1. 文件路径 —— 用途说明"的格式跟在需求后面发出去，同一路径重复选择会自动去重（同一份文件在一句话里出现两次，AI 反而不知道该听哪条说明）。

回到批次管理：附件说明不进 history.ini。这一点在批量任务里很有用 —— 你可以在每一批里挂不同的附件（这一批挂术语表、下一批挂截图），而历史列表里永远只有你写的那句"原话"，干净、可读、可回填。术语表这类"一批用得到、下批用不到"的东西，不会把台账弄乱。

七、用户评价：他们是怎么分批改的

八、结语：把"批量"从一个动作变成一个过程

把这篇的方法收成三句话：先摸底 —— 用一条只扫描不改的需求，把文案在三层里的分布变成清单；再分批 —— 按层级、按模块、按风险或按语言切，一批一个主题，一批一个边界，交给修改历史去记；每批验机 —— 改完自动打包、装机拉起、走到那个界面看一眼，让问题只可能落在最后一批里。

于是你打开安卓修改大师智改工坊改这几十处文案时，看到的就是那句口号描述的样子：只需说话，就能让应用变成你想要的样子 —— 你在左边写"这一批只改哪里、改成什么、哪些别动"，AI 在右边改工程，改完自己通知主窗口打包，装到设备上等你验收。几十处文案不再是一次赌博式的全量替换，而是一条可记录、可回填、可回滚的推进线。

产品介绍页与下载入口：https://www.apkeditor.cn/ai-version.aspx（官网 www.apkeditor.cn）。