把「去掉开屏广告」写成一条 AI 能准确执行的需求

「帮我把开屏广告去掉」——这句话大概是被改包里最常出现、也最容易被改错的一句。原因不在于工具不聪明，而在于这句话本身信息量太少：哪一类广告、从哪个环节去掉、去掉之后启动流程变成什么样、怎么算改好了，一个都没说。执行方只能靠猜，猜就有概率猜偏。

这篇不打算讨论「广告为什么存在」这种话题，而是把注意力放在一件更实际的事上：把你的诉求翻译成一条可执行、可验收的需求。过程中你会看到开屏广告通常是怎么实现的、需求里的哪些词会让执行结果跑偏、以及改完之后该按什么顺序确认它真的不再弹。

一句话结论先放在这里：去开屏广告的难点不在「删」而在「说清楚删什么、删到什么程度、怎么证明删干净了」。需求写对了，剩下的是流程问题。

一、冷启动那几秒里，开屏广告都做了什么

先把一次冷启动拆开看。你点开图标之后，系统会先启动应用的入口组件，应用完成初始化，然后进入主界面。开屏广告通常就插在「入口组件启动」到「主界面出现」之间这段空隙里：入口组件起来之后不直接进主页，而是先跳到一个展示广告的地方，展示 3 秒左右的倒计时，要么自动跳过，要么等用户点跳过，然后才进入真正的首页。

这就是为什么它「看起来像启动页的一部分，实际上未必是」：

• 有的应用专门写了一个广告页，作为独立的界面存在；
• 有的应用没有独立页面，而是在启动页上放了一块展示区域，广告来了就显示、没来就显示品牌图；
• 有的应用把广告展示交给第三方 SDK，代码里只留初始化与拉取调用，展示时机由 SDK 自己决定；
• 还有的把「拉广告」和「页面跳转」绑在一起，倒计时没走完就不许进主界面。

把这几种放在一起看，就能理解为什么「去掉开屏广告」这几个字不足以指导执行：不同实现方式下，要动的位置完全不一样，验收的方式也不一样。

二、常见实现路径盘点：它决定了你的需求怎么写

这张表其实是一份需求清单的雏形：你先确认现象属于哪一类，再把对应那一列的「该点明的信息」写进需求，执行方向就不容易偏。

三、三种最常写错的需求，问题出在哪

同一件事，写成不同的话，执行结果差别很大。下面三种写法在实操中最常见：

三行对比下来，规律很清楚：需求里要同时出现「现象」「目标」「边界」。现象让执行方知道去哪个环节找，目标告诉它改成什么样，边界防止它顺手改多。

写需求时值得养成一个习惯：把「广告」这个词拆开。它可能指开屏、插屏、横幅、信息流，也可能是推送或其他形式的推广位。你只说「广告」，执行方就得替你决定去哪个。

四、一条能被准确执行的需求：模板、示例与附件

在智改工坊里，写需求的地方就是项目详情页中间的输入框，写完点「立刻修改」，需求会被送进右侧的 AI 窗口执行；AI 改完会在项目目录留下标志文件 ai_done.flag，主窗口每 2 秒轮询一次，读到就自动弹出打包窗口。所以你只需要把精力花在「怎么把话写清楚」上。

一条完整的去开屏广告需求，建议按五段来写：

可以直接照着改的示例需求：
「我的应用冷启动时会先显示一个开屏广告页，大约 3 秒后自动跳过，也可以点跳过按钮。请把这个开屏广告下线：冷启动后直接进入主界面，不再请求、不再展示任何开屏广告内容；广告相关的初始化与拉取调用一并处理；如果启动页本来有品牌展示，请保留；不要再保留固定等待时间。范围只限开屏广告，插屏、横幅、推送都不要动，登录与其它业务逻辑保持原样。验收标准：连续冷启动 3 次都不出现广告页；断网状态下冷启动也能直接进主界面；启动过程无报错弹窗。」

如果懒得从头写，可以先去话术库挑一条相近的：内置 6 大分类共 3000 条成型指令，每条都把「要做什么、细节要求、参数参考、范围、验收」写全，点「选择」直接填进输入框，点「复制」复制正文，去开屏广告这类需求通常能在「去除限制」或「弹窗引流」分类下找到接近的模板，改两句就能用。话术库内容来自程序目录下的 Resources\话术库.xml，可以自己补充条目，改完点刷新重新读取。

另外两个细节值得知道：一是大师币不足时，导入 APK 与编辑项目都不受影响，只有点「立刻修改」和「去打包」时才会提示充值；二是需求原文会写进 history.ini 作为历史记录，而附件说明不进历史，历史里只留用户原话。

五、把「证据」交给 AI：附件怎么写用途

需求之外，还有一类东西能明显提高一次改对的概率：附件。点「选择附件」可以一次挑多个文件，每个文件都要写一句「它是干什么用的」。工具会校验两件事——文件现在能不能用（存在、不是目录、不是 0 字节、能读出来），以及说明不少于 10 个字；两部分都通过，才会拼成「序号. 文件路径 —— 用途说明」跟着需求一起发给 AI。

去开屏广告这件事上，适合当附件的有：

• 广告出现时的界面截图，用途可以写成「冷启动 3 秒内出现的开屏广告页截图」；
• 广告消失后主界面的截图，用途写成「广告结束后进入的主界面截图，作为目标形态参考」；
• 反编译目录里的相关文件路径说明（如果你自己已经定位过位置），用途写成「开屏广告相关代码所在文件路径清单」；
• 一份现象记录，比如「冷启动时广告出现与消失的时间点记录」。

附件说明为什么要写到 10 个字以上？因为「截图」「日志」这种两个字的说明对执行方没有任何信息量，而「冷启动 3 秒内出现的开屏广告页截图」直接说明了它在流程里的位置与作用。写得越具体，AI 越不容易把附件用错地方。

六、改完怎么验证「真的不再弹」

去广告这类改动的特点是「少了一个环节」，看起来一切正常，实际上可能只是这次没触发。所以验证不能只看一次。建议按下面这张清单走一遍，每一项都不费什么时间：

设备这层工具已经铺好了路：打包后可以直接自动运行，用 adb 找到手机或模拟器，把包装上并拉起应用；拉起用的是 am start，应用起来之后能用 dumpsys 看一眼前台应用是不是它。启动组件名有三档查找——先读项目 config.ini 里的 LaunchableActivity，读不到就问设备 resolve-activity，再不行退回 monkey，所以即使配置里没写全，也能拉得起来。手机可以通过 scrcpy 投屏到电脑上观察，模拟器则会被提到最前面；常见国内模拟器（雷电 / MuMu / 夜神等）出现「装了但 adb 没连上」时会自动扫端口连上，模拟器装了没开还会搜出安装路径问你要不要帮你打开，设备没授权则提示你去手机上点「允许 USB 调试」。

顺序建议：先用模拟器把三轮冷启动快速过一遍，再用真机确认一次。模拟器方便反复重装，真机更能反映实际网络与启动速度的差别。

七、出错、回退与历史记录迭代

如果结果不理想，先分清是「改得不对」还是「包没打出来」：

• 反编译失败：不影响项目本身——配置、图标、源包都已经落地保存，程序会提示失败原因并给出 apktool.log 的路径，把环境更新后再重新导入即可。实测 12MB 的包反编译约 3 秒；超过 10 分钟会中断并报错，这时多半是包本身有异常。
• 打包失败：打包按四步走——回编（apktool b）、对齐（zipalign -p 4）、签名（apksigner，配合工作目录根目录下可替换的 testkey.pk8 与 testkey.x509.pem）、校验（apksigner verify）。四个步骤的全部输出都写在项目目录的 pack.log 里，哪一步断的，翻日志就能看到。三个产物分别在 build 目录下的 unsigned.apk、aligned.apk、signed.apk。打包过程中窗口不给关，避免误以为没在跑。
• 改得不到位：先回看需求是不是漏了环节，比如只写了「不展示」，没写「不再拉取」，断网时就会留个占位。

迭代的工具是历史记录：项目详情页直接列出修改历史（最新在最上），每条显示 #序号 + 时间 + 需求原文，完整显示不截断，右侧「选择」可以把那条需求填回输入框——「照上次那条再改一遍」只需要补一句差异。历史同时落盘在 history.ini，按记录1、记录2 递增，删掉某一节就等于删掉那条记录；项目列表里每条也带「历史」按钮可直接打开历史窗口，列表本身带搜索与刷新，可编辑、可删除（删除有防呆：只允许删 Project 的直接子目录）。

一个常见的三轮迭代节奏：第一版只处理展示，第二版把初始化与拉取补掉，第三版调整启动页的展示保留策略。每轮一条历史，随时能回看改过什么。

八、用户评价

「我以前写需求就一句『把广告去掉』，改出来总差一点。后来按五段式写，把验收标准也写进去，基本一次就到位。」
—— 小南 · 手游二改工作室

「截图当附件太有用了：我把广告页和主界面各截一张，写清用途，AI 一眼就知道这包该长什么样。」
—— 老周 · 安卓逆向爱好者

「我们内部包会先过一个固定清单：三次冷启动、断网启动、首启。改完不用再靠印象判断有没有弹。」
—— 林工 · 企业内测打包

「有次改完只有断网时留了个空白占位，就是需求里没写『不再拉取』。补了一句，第二轮就干净了。」
—— 阿凯 · 独立开发者

换句话说：给自己的应用下线已停用的推广位、做内测包、做教学演示，都是正路；拿它去处理不属于你的应用，不行。

本文流程与细节来自开发机实测；用户反馈已获授权并脱敏处理。