「安卓修改大师智改工坊」是一款 Windows 桌面工具，介绍页在这里：https://www.apkeditor.cn/ai-version.aspx。它把改 APK 压缩成一句话——把安装包拖进去，用中文写清需求，AI 去改 smali 与资源，改完自动回编、对齐、签名、校验，最后装到手机或模拟器上看效果。

这篇不讲别的，专门拆一类最「看着简单、做起来最容易返工」的需求：去掉弹窗与广告位。这件事的难点从来不是技术，而是表述——你得先说清楚"砍掉哪几个、留下哪几个、什么时候不该出现"，才谈得上验收。

先说边界：本文所有例子都基于我们自己开发、自己维护或已获授权的应用——自研记账应用的启动推荐位、内部工具自己加的弹窗。去掉弹窗是一种正常的自有产品定制行为；请不要把它用在他人应用上，也不要用它绕过任何安全机制。

另外要说明的是："去掉弹窗"不等于"体验变好"，它是两件事。弹窗存在的理由往往很正当——提醒用户有更新、提示当前环境不安全、告诉用户操作失败了。所以真正专业的做法不是"能删的都删"，而是"把打扰用户的删掉，把帮到用户的留下"。这也是为什么这篇文章的标题里写的是"该去哪些、留哪些"，而不是"怎么把弹窗删光"。带着这个前提往下看，你会发现后面所有技巧其实都在服务同一个目标：让"去"和"留"都变成你主动做出的、可以复述给别人听的决定。

一、「把弹窗去掉」四个字，为什么最容易被改偏

先看一个我们都遇到过的场面：你说"把开屏广告去掉"，改完装到手机上，冷启动确实干净了；但锁屏再进来一次，那个推荐位又冒了出来。于是你又去提一次需求，这次描述成"切后台回来也会弹"，改完发现退出时还剩一个。"改一次、漏两处"，这几乎是弹窗类需求的固定剧本。

把翻车的原因归拢一下，其实是三件事：

反过来看，三种最典型的"一句话需求"是这样写的，它们的共同点是：只有动作，没有范围和验收。

这三种说法背后其实是同一个习惯：把"我以为你懂"当成需求。而在改包这件事上，"我以为"的代价特别具体，通常长成下面三种样子。

这三种后遗症有个共同点：都不难修，但都需要"再走一遍完整流程"。与其事后补，不如在写需求的那一分钟就把它们堵住。另外提醒一句，改这类东西之前，最好先在设备上把现状完整走一遍、截几张图——不是为了给别人看，而是为了改完之后你能一眼比出差别在哪。

记住一句话：弹窗类需求写得好不好，不看形容词有多少，看你有没有把"时机 + 清单 + 验收"三样东西交出去。下面三章就分别讲这三样。

二、第一步不是写需求，是给弹窗分类

很多人上来就写需求，写着写着把自己绕进去。更快的办法是先花两分钟做一件小事：拿一张纸，把你见过的弹窗按"什么时候出现"列出来。因为 AI 改的是代码路径，而"什么时候出现"正好就是路径的坐标——你把时机说清楚，等于替它圈好了搜索范围。

触发时机	典型表现	最容易踩的坑	对应的验证动作
冷启动	开机后第一次点开，闪一个推荐位或升级提示	只管了启动页，没管启动流程里后置的弹窗	杀进程重启 5 次，逐次观察
热启动	切后台再回来，或者从别的应用跳回来时冒出来	和冷启动走的是两条分支，只改一条	切后台停 30 秒以上再回前台
页面停留	在首页/列表页停一会儿，或滑动一段距离后弹出	以为是启动弹窗，其实挂在页面的定时任务上	在首页静置两分钟，边滑边等
退出	连按两次返回键，弹一个"确定要退出吗"	拦在返回键逻辑里，删了弹窗但没处理返回行为	连按返回 3 次，看是否干净退出
网络回调	断网、超时、请求失败后弹提示，或恢复网络后弹推荐	把"提示"和"推荐"混为一谈，一起清掉	飞行模式启动一次，再关掉网络重试一次
定时触发	每隔一段时间、或每次打开某个页面都弹一次	只删了展示代码，定时任务还在跑，白耗电	长时间挂着，隔段时间看一次

这张表的用法很简单：你每写一条"去掉"，后面就跟一个时机；每写一条"保留"，前面也标一个时机。它还有一个额外好处——验收的时候，它直接就是你的测试用例表，不用再临时想"我该点哪里"。

怎么快速盘点：三遍走查法

如果你一时想不全自己应用里到底有几个弹窗，可以用一个很土但很有效的办法——拿着手机，用三种方式各走一遍，边走边记：

1. 第一遍，规规矩矩地走：从点开图标开始，一路走到主要功能页，把路上遇到的每个弹窗记下来，写上"它是在哪一步出现的"；
2. 第二遍，专门走后门：切后台再回来、锁屏解锁、从通知点进来、从别的应用跳回来——这些都属于热启动和恢复路径，弹窗往往和第一遍不是同一批；
3. 第三遍，制造一点异常：断网启动、飞行模式点几下、连续按返回键退出，把异常路径上的提示也记下来——这一遍记到的东西，大多该进"保留清单"而不是"去掉清单"。

三遍走完，你手上就有了一份真实清单，而不是凭印象列出来的三五行。这个过程通常不超过十分钟，却能省下后面反复打包的几个小时。清单记完再写需求，你会发现句子顺得多——因为你要说的东西，已经不再只是脑子里那个"很吵的弹窗"了。

一个容易被忽略的点：描述弹窗时，文案往往比位置更好用。写"标题是'发现新版本'、右边有一个'暂不更新'的按钮"，比写"首页右上角那个弹窗"要准得多——因为位置是你的感觉，文案是包里的原文，后者能被直接搜到。

还有一个实操上的小习惯：给每个弹窗起个短名字。比如"开屏推荐位""更新提示框""退出确认框""断网提示框"——四个字就行。起完名字，你的需求和验收清单都会变得特别好读，团队里其他人接手时也不用再问"你说的是哪一个"。这件事听起来琐碎，但它是把"模糊的口头描述"变成"可执行条目"的第一步，后面写范围、写保留清单、写验收，用的都是这套名字。

小技巧：智改工坊工作目录里的话术库（Resources\话术库.xml）按六大分类整理了大量成型指令，其中「弹窗引流」这一类就是专治这种场景的。每条都把"要做什么 / 细节要求 / 参数参考 / 范围 / 验收"写全了，点「选择」直接填进输入框，点「复制」可以把正文复制到别处改。它是 XML，你可以按自己团队的习惯手改，改完点一下刷新重新读。

三、需求怎么写：去哪些、留哪些、不许动什么

有了分类表，需求就有骨架了。我们把"去掉弹窗"这类需求拆成三个必须回答的问题，再加上原有的五要素，基本不会再跑偏。

保留清单怎么写才算点名

"保留"不是一个态度，而是一份名单。写得越像点名，越不容易出事。常见的保留项和推荐写法如下：

保留项	为什么要留	在需求里怎么点名
安全与合规模块	内网提醒、权限说明、隐私告知，用户需要看到	写清触发页面与文案关键词，注明"必须保持原样"
失败与异常提示	出问题时它是唯一的排错线索	写清"断网/超时后弹出的提示不得改动"
强制升级提示	服务端接口变更时，靠它把老版本挡回去	说明"版本过低时的强制升级提示保留原逻辑"
业务确认框	删除、提交、支付前的二次确认，删了容易误操作	列出按钮文案，注明"与业务操作绑定的确认框不在范围内"

还有一件常被漏掉的事：去掉一个广告位之后，那一块地方怎么处理。是整块收掉让下面的内容上移，还是留白占位保持布局不动？这两种结果完全不一样，而需求里如果不说，就只能看运气。稳妥的写法是把它写成一句话："该区域整块移除，下方内容自然上移，不保留空白占位。"——一句话，省掉一轮返工。

同一件事，两种写法的差距有多大？看这张对比表。

写法	需求原文	改完会发生什么
含糊写法	把开屏广告去掉	冷启动干净了，热启动和退出路径照旧；你只能再提一次需求
可执行写法	去掉冷启动与热启动两种路径下的开屏推荐位；保留网络异常提示与版本过低强制升级提示，保持原样并在结果里说明未改动；验收以杀进程重启 5 次、切后台 30 秒回前台各一次为准	范围明确、保留明确、验收明确，一次到位

如果你要处理的东西比较多，还可以把"清单"做成附件：点「选择附件」一次挑多个文件，给每个文件写一句"它是干什么用的"。系统会校验两件事——文件现在能不能用（存在、不是目录、不是 0 字节、能读出来），以及说明不少于 10 个字；然后把这些拼成「序号. 文件路径 —— 用途说明」，跟着你的需求一起交给 AI。

四、实例一：自家记账应用「企账通」，去掉开屏推荐位与升级弹窗

「企账通」是我们自己维护的公司内部记账应用（版权在我们手里），冷启动时有两个东西：一个是 3 秒的开屏推荐位，一个是"发现新版本"的提示弹窗。内测阶段它们确实有用，但给财务同事用的时候，反馈很一致：每次打开都得先等、再关，太吵。

整个改动里，有几个细节让"以前"和"现在"的差距特别明显。以前我们要先自己把包解开、盯着黑窗口滚动的日志找线索；现在是拖进去就解析——用工作目录里的 aapt 读出图标、应用名、包名、版本号、最低与目标 SDK 和启动页，图标还是从包里取出的原图、按最高密度挑选（aapt 报的 65534 是"任意密度"的哨兵值，不会挑到小图）。解析和反编译都跑在后台线程上，界面不卡，实测 12MB 的包反编译大约 3 秒；即便反编译失败，项目本身也已经落地了——配置、图标、源包都在，会给出失败原因和日志路径（apktool.log），不会让你前面的工作白做。

另一个细节是"对照"。改之前我们把旧版界面截了图，作为附件一起提上去，用途写的是"上一版界面截图，用于比对保留项是否被动过"。改完装机第一件事就是对着这张图看：该没的没了，该在的还在。这比凭印象验收可靠得多。

最省事的还是"不用管打包"。以前改一处就要手动回编、对齐、签名、校验一轮；现在打包窗口自己弹出来，四步跑完还能「保存 APK」——默认文件名就是应用名_版本号_signed.apk，我们那次存下来就是 企账通_1.4.2_signed.apk，给财务同事发过去就能装。打包产物会落在项目目录的 build 文件夹里，从 unsigned.apk、aligned.apk 到 signed.apk 一步一个文件，全过程写进 pack.log——万一哪一步出问题，翻日志就能对上。

五、实例二：内部工具「班组考勤」，只删一个退出弹窗，三种提示一行不许动

第二个例子更能说明"保留清单"的价值。「班组考勤」是我们内部用的打卡工具，退出时会弹一个"确定要退出吗"，同时它身上还有三类提示——内网环境提示、打卡失败原因提示、版本过低强制升级提示。前两个以前都动过手，最怕的就是一次改太多，把不该删的也一起删了。

这次改动还有一个附带的好处：出包变得可追溯了。工坊每次出包前会自动往 res/values/styles.xml 里写一个 name="info" 的样式，把时间、登录账号、机器码、机器名、系统用户名、程序版本、应用名、包名等信息编码进去。对我们这种"同一天给同一个应用打好几个包"的场景很有用——过两天再看到桌面上那个摊开的 APK，看一眼标记就知道那是上午那轮还是下午那轮出的，不用靠文件名猜。

另外提一句打包过程的体验：打包窗口在跑的时候是不给关的，避免你误以为它没在跑而反复点击；四步跑完，可以「保存 APK」，也可以直接「打开所在文件夹」把 build 目录翻出来。签名用的是工作目录根目录下的 testkey.pk8 / testkey.x509.pem，这对内测包够用，需要换成自己团队的密钥时直接替换这两个文件就行。

这两件事做完，我们总结出一条经验：把"留哪些"写得比"去哪些"还细，返工率会明显下降。因为真正让人头疼的从来不是"没删干净"，而是"把不该删的一起删了"——前者再改一次就行，后者得从头收拾。

顺带说一个习惯：我们团队现在给自研应用改包，需求里都会加一句"保留原样并在结果里说明未改动"。这不是客套话，它是验收时唯一能拿出来对的东西——改完先看它说哪几处没动，再自己去点，两下就核对完了。

六、逐条验证：把「感觉没问题」变成「六条路径都走过」

弹窗类改动最容易骗过自己——你随手点两下，一切正常，就以为改好了。真正的验收得按触发路径走一遍。下面这份清单可以直接照抄，我们是把它写进团队文档的。

1. 冷启动：杀掉进程再打开，重复 5 次，一次都不能冒出来；
2. 热启动：切后台停 30 秒以上再回前台，看它是否"复活"；
3. 页面停留：在首页静置两分钟，边等待边滑动，观察定时触发的那一类；
4. 退出路径：连按返回 3 次，确认退出行为与预期一致，没有卡住；
5. 异常网络：飞行模式启动一次、恢复网络再重试一次，异常提示该在的还在、该没的没了；
6. 保留项回归：把你列进"保留清单"的每一个弹窗，手动触发一次，确认它们全都活着。

这六条里，前五条是"减法验收"，最后一条是"加法核对"。很多团队只做减法，结果上线当天才发现安全提示没了。第 6 条花不了两分钟，但能省掉一次紧急发版。

还有一个让验收变轻松的做法：把验收标准提前写进需求里。你在需求最后那一段写下的"杀进程重启 5 次、切后台 30 秒回前台 1 次"，改完之后就直接变成了你的操作清单——你不必再回忆"我上次是怎么验的"，照着念就行。这也是我们坚持在每条需求里都保留"验收"这一节的原因：它不只是给 AI 看的边界，更是给自己的备忘。

至于验收环境，我们通常是"模拟器快速试、真机最后定"。模拟器上跑一轮只要几十秒，用来快速看有没有明显问题；确认没问题了再连上真机走最后一遍。工坊会用 adb 把包装上并拉起应用，拉起用的是 am start 而不是 monkey（新版安卓镜像里已经没有 monkey 了，而且它失败的时候退出码还是 0，容易把失败当成功），启动页的组件名会按三档去找：先读项目 config.ini 里记录的启动页，找不到就问设备 resolve-activity，再不行才退回 monkey。这些细节你不用记，但正是它们让"一键装机"这件事真的可靠。

验证环节	工具里对应的能力	省掉了什么
装到设备	用 adb 找手机或模拟器，装上并拉起应用	手动传包、手动点图标、担心装错版本
确认拉起来的是它	装完用 dumpsys 看一眼前台应用是不是它	"刚才弹的是不是这个应用"这种反复确认
长时间观察	手机走 scrcpy 投屏到电脑，模拟器窗口提到最前面	举着手机盯屏；投屏软件另装一套
边改边看	双窗口磁吸：AI 改包窗口吸附在主窗口右侧，高度一致	两个窗口来回切、调整位置

有一点值得单独说：设备没连上不代表要折腾半天。工具会自动去 adb 里找设备；装完常见国内模拟器（雷电、MuMu、夜神这类）如果 adb 没连上，它会自动扫端口连上；模拟器装了但没开，它会搜出安装路径问你要不要现在打开；手机上没授权，它会提示你去点"允许 USB 调试"。这些琐碎的判断都替你做了，你只需要在弹窗里点一下"是"。

再补一句"假通过"的坑。我们踩过两种：一种是只测了一次冷启动就下结论，结果第二天用户反馈"切回来还是会弹"；另一种是在模拟器上验完就以为手机也一样，可模拟器的启动路径跟真机并不完全一致。所以现在的规矩是——冷启动至少 5 次、热启动至少 1 次，而且最后一次一定在真机上做。真机上的操作也很简单：连上手机，工坊用 adb 装上去并拉起，手机画面用 scrcpy 投到电脑，你坐在键鼠前就能完成整轮点检；模拟器的话它会把窗口提到最前面，直接点。

容易"假通过"的做法	为什么不可靠	把它改成什么
冷启动只看一次	有些逻辑是"几天弹一次""第 N 次启动弹"，一次看不出来	连续杀进程重启 5 次，每次都确认
只在模拟器上验	模拟器与真机的启动路径、系统行为存在差异	最后一轮在真机上做，模拟器只用来快速试
网络一直是好的	推荐位有时是在拿到网络回调后才拉的，好网络反而看不出问题	补一次飞行模式启动、再补一次恢复网络重试
只验"该没的"	保留项没人管，等到用户反馈才知道删多了	加一条"保留项回归"，逐个手动触发一遍

七、用户评价：改弹窗这件事，大家最在意什么

我们收集了一些自研团队与内部工具维护者的反馈，匿名整理如下。看下来大家的痛点高度一致：不是"改不动"，而是"改完不敢确定"。

把这些反馈放在一起看，会得到一个挺有意思的结论：让大家头疼的从来不是"技术难"，而是"说不清"和"验不完"。前者靠清单和模板就能解决，后者靠一份固定的验收路径也能解决——这两个东西加起来，其实才是"一句话改包"真正的含金量：那一句话之所以敢说得那么短，是因为它背后有清单托着、有流水线接着、有历史记着。

八、合规提醒与上手清单

最后照例给一份可以直接照做的清单：

1. 先列清单：把见过的弹窗按触发时机列出来，一眼就能看出漏了哪几条路径；
2. 挑模板起步：到话术库「弹窗引流」分类里找一条最接近的，点「选择」填进输入框再改细节；
3. 写清三问：在哪弹、去哪些、留哪些，一个都别省；
4. 保留清单点名：加一句"保持原样并在结果里说明未改动"；
5. 清单走附件：截图、表格、验收标准都可以带上，每个文件写一句不少于 10 个字的用途；
6. 点一次就好：「立刻修改」之后，需求进 history.ini，改完自动接打包四步；
7. 六条路径验收：冷启动、热启动、页面停留、退出、异常网络、保留项回归；
8. 留痕复改：历史里的原文随时可以填回输入框，照着改一轮新的；
9. 出包留痕：每次出包都会带上 name="info" 标记，出问题能对回是哪一次；
10. 设备先行：手机没授权、模拟器没开、国内模拟器 adb 没连上，工坊都会自己先处理一遍再问你。

如果只让我留一句话给准备动手的人，我会说：先花十分钟盘点，再花一分钟写需求。盘点是为了知道自己在动什么，写需求是为了让别人（包括未来的自己）知道你为什么这么动。这两步做扎实，剩下的回编、对齐、签名、校验、装机、验证，都是可以按部就班走完的流程，没有意外。

如果你也想把这类需求变成一句话就能交付的事，可以从「安卓修改大师智改工坊」的介绍页开始看看：https://www.apkeditor.cn/ai-version.aspx，官网 www.apkeditor.cn 上也能看到版本更新说明。去掉哪些、保留哪些，写在需求里；剩下的，交给它。

本文所述操作均针对自有版权或已获授权的应用；文中应用实例与用户反馈已获授权并做脱敏处理。