等AI改完的工程学：标志文件、2秒轮询与1小时等待上限

先说清楚我们要讲的这件事。你在安卓修改大师智改工坊（电脑版）的主窗口里写好一句中文需求，点下「立刻修改」，然后呢？主窗口不会把自己锁死在那儿干等，而是把需求送进右侧的 AI 工作区窗口去执行；AI 在那边一行一行改 smali、改资源，主窗口这边安安静静地等。问题来了：主窗口凭什么知道 AI 改完了？ 它又不能钻进 AI 工作区里去看屏幕。这个"通知"是怎么发出来的，就是本文要拆的工程学。它的介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。

答案说出来很朴素：AI 改完之后，会在当前项目的目录里留下一个叫 ai_done.flag 的标志文件；主窗口这边每 2 秒 去看一眼这个文件在不在，一看到就立刻删掉它、自动弹出打包窗口；如果等了 1 个小时 还没等到，就主动中断等待并提示你。为了防止上一次的残留标志把这一次误触发，每次开始等待之前还会先把这个同名文件清理掉一次。

听起来全是"小细节"，但每一个数字、每一个动作背后都有取舍。这篇文章就把这套异步协作机制从入口讲到收尾：一次「立刻修改」背后的完整链路、为什么标志文件比"直接等 AI 进程退出"可靠得多、2 秒轮询和"读到即删"各自在防什么、1 小时上限为什么是这个量级、开始等待前先清残留防的是哪一种误触发、右侧 AI 工作区窗口从启动到退出的两段式生命周期、history.ini 是怎么给每一次修改留痕的，最后配两个我们自家应用的改包实例，说明这套机制在真实工作流里到底帮了什么忙。

一、一次「立刻修改」背后发生了什么

要理解标志文件，先得把整条流水线在脑子里跑一遍。你点下「立刻修改」的那一下，主窗口做的第一件事不是发包，而是留痕：把你写的需求原文和当前的修改日期一起写进项目目录里的 history.ini，然后才把这条需求送进右侧的 AI 工作区窗口开始执行。为什么先写历史？因为这是"你说过这句话"的凭证 —— 后面无论 AI 改成功、改失败、还是程序意外退出，这条需求都已经躺在磁盘上，详情页随时能翻出来看，也能一键填回输入框"照这条再改一遍"。

接下来就是等待期。AI 工作区窗口拿到需求后开始干活：切到当前项目的反编译目录，理解需求，改对应的 smali 与资源文件。这个过程对主窗口是黑盒 —— 主窗口不知道 AI 具体改到第几步了，它只关心一件事：活干完了没有？ 干完的标志就是项目目录里多出那个 ai_done.flag。主窗口以 2 秒一次的频率去检查它，一旦发现它出现，立刻删掉，然后弹出打包窗口，进入固定的四步打包链路。

步骤	谁在动	具体动作	留下什么
1	主窗口	需求原文+日期写入 history.ini，再把需求送进 AI 工作区	历史里新增一条记录
2	AI 工作区	切到项目反编译目录，改 smali 与资源	被改动的源码文件
3	AI 工作区	改完，在项目目录留 ai_done.flag	标志文件出现
4	主窗口	2 秒轮询读到 flag，立刻删除，弹打包窗口	进入四步打包
5	打包链路	回编→对齐→签名→校验，全过程写日志	build 目录三个产物 + pack.log

四步跑完，build 子目录里依次留下 unsigned、aligned、signed 三个中间产物，全过程写进项目目录的 pack.log —— 每次出包生成完整打包日志 pack.log，产物可追溯。跑完后你可以点「保存 APK」（默认命名是 应用名_版本号_signed.apk）或者「打开所在文件夹」。如果勾了打包后自动运行，程序会用 adb 找手机或模拟器，把包装上并拉起应用，再用系统命令复核一次前台应用是不是它，避免"装上了但没起来、以为改失败"的误判。

还有一个细节要补：你真正发出去的内容，并不只是你写的那一句原话。发出去的 = 你的原话 + 你给附件写的用途说明 + 一段固定的环境说明。环境说明里会告诉 AI：要切换到哪个工作目录（发送时把实际路径替换进去）、改完之后要在项目目录里留标志文件、回编打包这些事统一由主程序完成，你不用自己打。这段环境说明是写给 AI 看的"交接手册"，它保证了 AI 只负责"改"，主窗口只负责"等和打"，两边的职责从发需求那一刻就划清了。

看到这里，你应该已经意识到一个关键事实：主窗口和 AI 工作区是两个各自独立运行的程序。它们不共享内存，不开互相回调的接口，中间没有一条"专用通信管道"。它们之间的全部协作，就浓缩在项目目录里那一个会出现、会被删掉的小文件上。这不是图省事，而是一种刻意选择 —— 下一节就讲为什么这么选。

二、为什么用标志文件做信令，而不是"等 AI 进程退出"

很多人第一反应是：主窗口要等 AI 改完，最简单的做法难道不是"等 AI 工作区进程退出"吗？AI 一干完活，把窗口一关、进程一退，主窗口这边不就知道了？这个方案在"一次性命令行工具"里确实成立，但放到智改工坊的场景里有一个致命问题：AI 工作区窗口是常驻的，它改完包之后根本不退出。

你想想自己的使用节奏：改完弹窗文案，点「立刻修改」，等出包；看完效果不满意，回到主窗口把需求改两个字，再点一次「立刻修改」。这期间 AI 工作区窗口一直开着，它还要接着执行你的下一条需求。"进程退出"在这个工作流里代表的是"你把整个程序关了"，而不是"这条需求改完了"。把"进程退出"当完成信号，语义从根上就是错的 —— 它把"会话结束"和"任务结束"混为一谈了。

那再换一个方案：主窗口和 AI 工作区之间直接开一条通信通道（管道、本地端口、共享内存之类），AI 干完活主动发一条消息过来。这个方案技术上更"正规"，但代价是两个程序被死死绑在一起：消息协议要双方版本一致，AI 工作区崩溃时主窗口可能永远等不到那条消息，主窗口崩溃后重开也接不上历史会话。更麻烦的是排障：通信消息是留不下痕迹的，出了问题你只能猜。

标志文件方案的本质，是把两个程序之间的"实时通信"降级成"通过文件系统留便条"。写的人写完便条就去忙下一件事，读的人想看就自己去翻信箱。谁也不等谁，谁崩了都不影响对方下一次来翻信箱。

标志文件好在三件事上。第一，天然按项目隔离。 智改工坊每个项目都有自己独立的目录（每个项目一个 8 位随机字符串命名的文件夹，里面放 config.ini、拷一份 source.apk、反编译输出在 apktool 子目录）。AI 改哪个项目，就在哪个项目的目录里写 flag；主窗口等待的也是当前打开的这个项目。同时开两个项目改包，两个 flag 各写各的目录，谁也不会打扰谁。第二，可观察、可人工介入。 你怀疑"AI 到底改完没有"，直接打开项目目录看一眼那个文件在不在就行 —— 它是一个真实存在的磁盘文件。第三，抗崩溃。 主窗口中途自己崩了、重启之后，AI 写下的 flag 还在磁盘上，主窗口回来轮询一眼就能补上这一跳，不需要重放任何会话。

方案	语义对不对	抗崩溃	能不能人工查
等 AI 进程退出	不对：窗口常驻不退出	—	—
专用通信管道	对，但绑死两端	差：消息易丢	不能：不留痕
标志文件（现在）	对：按项目写	好：磁盘持久	能：直接看文件

当然，标志文件也不是没有代价：它只能表达"完成了"这一个布尔信号，表达不了"改到一半""遇到什么问题"。这些更细的信息走另一条路 —— AI 工作区窗口自己的输出面板里实时可见。主窗口要的只是一个点火信号，剩下的细节你瞄一眼右侧窗口就知道了。信号简单，职责才清楚。这也是所有跨进程协作里被反复验证的一条经验：信令越单一越好，单一到"存在与否"这一个状态就够了，复杂信息走别的通道。

三、2 秒轮询与"读到即删"：两个动作各防一件事

主窗口怎么发现 flag 出现了？不是实时监听文件系统事件，而是每 2 秒主动去项目目录看一眼。为什么是 2 秒而不是 0.2 秒，也不是 10 秒？这是一个在"响应速度"和"系统开销"之间取的中点。改包本身是分钟级的操作 —— AI 理解需求、改 smali、改资源，再快也不是秒级的事；flag 早 1 秒晚 1 秒被读到，用户完全无感。但如果轮询间隔压到毫秒级，等于每毫秒都在做一次磁盘目录查询，轮询还跑在后台线程里，纯属给硬盘和 CPU 添乱。反过来，间隔拉到 10 秒以上，AI 明明改完了，主窗口却要慢吞吞地过好几轮才反应过来，用户坐在那儿盯着"等待中"，体感就像卡了。

2 秒是个很克制的选择：人眼察觉不到这两秒的延迟，机器付出的代价又可以忽略。 顺带说一句，这个间隔本身是配置化的 —— settings.ini 里有"轮询间隔"这一项，属于留给你手调的参数之一。你在一台特别慢的机械硬盘机器上觉得目录查询拖慢界面，可以把它放大；你想体验更跟手，也可以往小调，但我们不建议低于 1 秒，理由就是上面这笔账。

为什么不用"文件系统实时监听"呢？那不是更省、更及时吗？实时监听确实更优雅，但它依赖系统的监听服务，多一层依赖就多一层出错的可能 —— 监听挂了、路径被移走了、权限变了，主窗口就再也等不到那个事件，而你还不知道监听已经死了。轮询是"主动去问"，哪怕系统监听全挂了，只要磁盘能读，2 秒一次的检查就一直在工作。对这种必须可靠、不要求实时的信号，轮询反而是更结实的选择。

另一个动作更讲究：读到 flag 之后立刻把它删掉，然后才弹打包窗口。这个"读到即删"看起来不起眼，其实是整个机制里最关键的一环。想一下不删会怎样：flag 一直在目录里躺着，主窗口下一轮（2 秒后）轮询又看到它，再弹一次打包窗口；再下一轮，再弹一次…… 用户会被没完没了的弹窗淹没。文件系统不会因为"你已经读过它了"就自动把它藏起来 —— 文件的存在性是一个客观状态，它不会自己表达"我已经被消费过了"。 所以"消费"这个动作必须由读的人手动完成：删文件 = 告诉系统"这张便条我收了"。

时刻	项目目录里的 flag	主窗口在做什么
点「立刻修改」前	（上一轮残留会被先删掉）	写 history.ini，把需求送进 AI 工作区
第 0 ~ N 秒	不存在	每 2 秒轮询一次，界面不卡
AI 改完	刚出现	下一轮轮询读到它
读到的同一轮	立刻被删除	停止轮询，弹打包窗口，走四步打包
打包期间	不存在（不会重复触发）	打包过程窗口不给关

"读到即删"还有一个隐含好处：它让 flag 永远只有一个消费者、一次消费。哪怕主窗口的轮询因为某种异常重复读到了同一状态，文件已经没了，第二次读什么都不会发生。这就是用文件做"信箱"的朴素之处 —— 信箱里的信被拿走之后，信箱就是空的，下一个人再拿也不会拿到重复的信。整个机制不需要分布式锁、不需要序号、不需要状态机，一个"存在即触发、触发即删除"的小循环就把并发问题规避掉了。

四、1 小时等待上限：兜底为什么必须有

现在把机制推到极端情况：如果 AI 那边出了岔子 —— 比如它理解错了需求在空转、网络异常卡住了、或者它干脆崩溃了 —— flag 就永远不会出现。主窗口的轮询循环如果没有上限，会发生什么？界面永远挂着"等待 AI 完成"的状态，打包窗口永远不弹，用户也不知道是该继续等还是该放弃。这是所有"轮询等待"类程序最经典的死法：不是崩溃，而是体面地永远卡住。

所以智改工坊给等待设了一个硬上限：从点下「立刻修改」开始算，连续等待 1 小时还没读到 flag，就主动中断这次等待并提示你。 1 小时这个量级不是拍脑袋：正常改一个应用包，AI 理解需求加改代码，绝大多数情况是几分钟到十几分钟的事；反编译一个 12MB 的包实测约 3 秒，超过 10 分钟还反不出来系统都会先报一次错。也就是说，真正"健康"的等待几乎不可能逼近 1 小时 —— 一旦逼近，大概率是真的哪里卡住了，这时候宁可叫醒用户人工介入，也不要让程序在那儿体面地无限等下去。

超时中断之后用户怎么办？三条路：去右侧 AI 工作区窗口看一眼它卡在哪（它的输出面板是开着的，问题往往一目了然）；把这条需求删掉重写一版（history.ini 里删对应的一节就等于删了那条记录，详情页的历史列表随手就能再填回来）；或者检查项目目录里是不是有什么异常文件。无论哪条路，程序都把诊断的主动权交回给你，而不是自己闷头等到天荒地老。

这里其实藏着一条通用的工程原则：任何"等别人"的循环，都必须给自己留一个上限。 因为"别人"是你控制不了的 —— AI 工作区、外部服务、被调用的命令行工具，它们各自的生死你说了不算。你能控制的只有自己：等多久是我规定的，到点了我必须有动作。1 小时就是这个自我约束的具体数字。把它写进配置思路里你会发现，这种"兜底"思想贯穿了整个等待机制 —— 清残留是兜底、读到即删是兜底、两段式退出也是兜底（第六节讲）。

五、先清残留：防止旧标志误触发的一个小细节

上一节说等待有上限，这一节说等待开始前的一个动作。你有没有想过这样一个场景：上一次你点了「立刻修改」，AI 改完了、flag 出现了，主窗口也读到、删掉了 —— 这是干净的一轮。但如果上一轮在"中途"出了岔子呢？比如 AI 已经把 flag 写出来了，主窗口还没轮询到，你手动把程序关了 —— 那个 flag 就作为残留留在了项目目录里。下次你打开程序、换个需求再点「立刻修改」，主窗口一开始轮询，第一眼就看到那个上一轮留下的旧 flag —— 然后它会怎么做？按规则，它会删掉这个 flag、立刻弹打包窗口。

问题就在这里：这一次你什么都还没改呢，它打包的是哪门子包？ 它打包的是"上一轮 AI 留下的那堆改动"，但你心里记的是"这一轮的新需求还没开始"。标志文件的语义被错位了 —— 一个属于上一轮的信号，被当成这一轮的完成信号消费掉了。轻则白跑一遍打包流程，重则你把错误的产物当成这一轮的结果装到测试机上，排查半天。

残留还有别的来路：AI 写 flag 的那一步因为异常没走完、项目目录在两轮之间被人手动拷来拷去、上一轮打包窗口弹出来后你直接关了程序。这些来路共同的特点是 —— flag 该被消费的时候没被消费，于是它躺到了下一轮。 防这个错位的办法简单到极点：每次点下「立刻修改」、开始这一轮等待之前，先把项目目录里那个同名的 ai_done.flag 删一次，然后才开始轮询。 这一手"先清场再上场"，把"现在开始"这个时刻明确地切出来了：旧信号全部作废，只认从这一刻之后新写出来的 flag。就像等电梯之前先把所有旧的按铃记录清掉，只听这一次的呼叫。

这个动作只有一行删除命令，但它解决的是一类很难查的 bug：症状是"我明明刚点修改，打包窗口自己弹出来了"。没有这一步，这类 bug 永远会在你最忙的时候冷不丁来一次。

顺着这个思路再想想轮询的整个语义闭环，你会发现它其实是一个非常干净的状态机：清空（开始等待前删一次）→ 等待（轮询不存在）→ 触发（发现出现）→ 消费（读到即删）。四个动作首尾相接，任何时候 flag 的"存在"都只可能对应一种含义 —— 从上次清空之后，AI 真的改完了一轮。含义单一，bug 就无处藏身。这也是为什么这套机制看上去全是小动作，却几乎不会在真实使用里闹"误触发"的脾气。

六、AI 工作区窗口的生命周期：干净加载与两段式退出

标志文件是"协作"，那 AI 工作区窗口本身呢？它不是你手动开的 —— 智改工坊主程序一启动，它就跟着加载好了，默认排在主窗口右侧待命。这里也藏着两层生命周期管理，都是为了同一件事：让这一次加载的 AI 工作区永远是干净的一份，退出的时候永远不留后台进程。

先说启动侧。 每次启动主程序、拉起 AI 工作区窗口之前，程序会先清理上一轮可能残留的进程。为什么要清？因为正常退出的 AI 工作区当然没有残留，但"不正常退出"才是常态 —— 程序崩溃、任务管理器被人顺手结束、电脑直接断电重启，这些场景都可能让 AI 工作区进程以"僵尸"形态留在系统里。下一次启动如果不管它，就可能出现两份 AI 工作区同时跑的局面：新的一份在听你说话，旧的一份在后台占着内存、甚至攥着项目目录里某些文件的句柄。文件被旧进程占着，AI 改包要写文件时就会报"文件被占用"。先清一遍残留进程，保证这次加载的是干净的一份，就是在拆这个雷。

再说退出侧。 关主程序的时候，AI 工作区窗口怎么办？这里用的是两段式退出：第一步先优雅关闭 —— 通知它自己关，并给它一个从容的收尾时间（给它一点时间把手上的事情收掉、把临时文件写干净）；等这个等待时间过去了它还没退干净，第二步再彻底结束它的进程。两段式的意思是：先给它体面，给不了体面再动刀，最终保证一件事 —— 你关了主程序之后，任务栏里、任务管理器里都不会有一个 AI 工作区进程在后台空跑。

阶段	做什么	防住的问题
主程序启动时	先清理上一轮残留的 AI 工作区进程	两份窗口同跑、旧进程占文件句柄
主程序退出时（第一步）	优雅关闭，等它自己收尾到超时	硬杀导致临时文件没写干净
主程序退出时（第二步）	超时未退则彻底结束进程	后台残留进程空占资源
偏好设置	settings.ini 里可设"退出是否关闭 AI 工作区进程"	想保留窗口下次接着用的人可自选

注意最后一行：这套退出策略是可以在设置里改的。settings.ini 里有一项"退出是否关闭 AI 工作区进程"，如果你属于那种"改包改一上午、中间只想把主窗口收一收、下午接着干"的重度用户，可以让它退出主程序时保留 AI 工作区，下次打开直接接上；默认则是干干净净全退。这个开关存在的理由和整个机制的设计哲学一致：默认行为服务大多数人，可选项服务知道自己在做什么的人。

七、history.ini：每一次修改都留痕，话还能原样说回去

回到开头那个动作：点「立刻修改」的第一件事，是把需求原文 + 修改日期写进项目目录的 history.ini。这份文件在等待机制里看似只是个"附属动作"，实际上它是整个异步协作能让人放心的另一半理由 —— 因为"什么时候说过什么话"被完整记录下来了。

history.ini 的记法很朴素：按记录 1、记录 2、记录 3……一节一节递增，每节里存那条需求的原文和时间。你在详情页看到的"修改历史"列表就是它读出来的：最新的排在最上面，每条显示 #序号 + 时间 + 需求原文完整显示、不截断。每条右边有个「选择」按钮，点一下就把那条需求原文填回输入框 —— 这就是"照上次那条再改一遍"的功能来源。想删某一条？把 history.ini 里对应的那一节整节删掉即可，历史列表里那条就没了，干干净净。

还有一个分层细节值得讲：history.ini 里只留你说的原话。 你真正发给 AI 的内容 = 你的原话 + 你给附件写的用途说明 + 一段固定的环境说明（告诉 AI 该切换到哪个工作目录、改完后留标志文件、打包这些事统一由主程序完成，其中工作目录位置会在发送时替换进去）。附件说明不进历史，历史里只存用户原话。为什么这么分？因为历史是给人看的回忆 —— 三个月后你翻回来，想看到的是"我当初说要改什么"，而不是一堆给 AI 看的格式化上下文。发出去的可以很工程化，留下来的必须是人话。

再加上出包侧的留痕：每次出包都会生成完整的打包日志 pack.log，回编、对齐、签名、校验四步的全过程都写在里面，产物可追溯。于是一次完整改包在磁盘上留下了三样东西 —— history.ini 里的一句话、build 目录里的三个 APK 中间件、pack.log 里的全程记录。几个月后你翻出来，能完整复现出"谁说了什么、机器做了什么、结果是什么"。这对我们这种自己改自家应用的工作流来说，是比任何宣传词都实在的东西。

八、等待期间怎么用：界面表现、实用技巧与两个实战实例

机制讲完了，落到怎么用。等待期间主窗口的状态设计也有几个讲究，知道它们你用起来会更顺。

第一，轮询不卡界面。 目录检查跑在后台线程，等待期间你在主窗口里该干嘛干嘛：翻项目列表、搜历史、改另一个项目的需求都不受影响。这一点很关键 —— 如果等待把主线程堵死，你只能盯着屏幕干等，体感就是"软件卡死了"。现在它的表现是"在后台安安静静等，你随便忙别的"。

第二，打包窗口不给关。 一旦 flag 触发、四步打包开始，打包过程窗口是不让关闭的。这是个故意的"烦人"设计 —— 因为打包是分钟级的连续动作，如果你中途把窗口关了，很容易误以为"没在跑、卡住了"，然后去手动重做一遍。留着窗口、跑给你看，比什么解释都管用。跑完之后你再操作「保存 APK」或「打开所在文件夹」。

第三，出问题先看三处日志。 等待卡住或打包失败时，按这个顺序查最快：项目目录里的 pack.log（打包全过程，看到底是回编、对齐、签名还是校验哪一环出的错）；反编译输出 apktool.log（如果是反编译阶段的问题）；主程序的诊断日志目录里有 dock.log（窗口布局与打包过程自检）和 error.log（未处理异常）。标志文件本身也可以人工去看 —— 打开当前项目目录，flag 在不在、什么时候出现的，一眼就知道。

机制说到底都是为干活服务的。下面两个例子都来自我们自家应用和内部工具的日常改包，严格按"以前怎么做 / 现在一句话怎么做 / 改完怎么验证"三步讲。

实例一：给自家「内部报销助手」改一个弹窗的文案。 这个应用是公司内部报销用的，设置页有个"退出确认"弹窗，标题和正文是去年随手写的，新同事反馈看不懂。以前的做法：反编译整包，在几百个 smali 文件和资源里搜弹窗那两段字符串的位置，改完再回编、对齐、手动签名，然后 adb 装到测试机上，点开设置、点退出，等弹窗跳出来确认文案 —— 一来一回十来分钟，中间还怕改错了字符串引用。

现在一句话：把自家安装包拖进智改工坊，在需求框里写"把设置页退出确认弹窗的标题改成『再想想？』，正文改成『确定要退出报销助手吗？』"，点「立刻修改」。需求原文和日期先落进 history.ini，然后右侧 AI 工作区开始改。我们这边就去忙别的 —— 2 秒一次的轮询在后台跑着，flag 一出现就自动删掉、弹打包窗口，回编、对齐、签名（用内置签名，可在项目里换成自己的签名）、校验四步跑完。

改完怎么验证？不用再手忙脚乱：勾选打包后自动运行，程序用 adb 把包装到测试机并拉起，我们进设置页点一下退出 —— 弹窗标题和正文就是新写的那两句。整个验证过程和打包是连着的一条流水线。出问题也不怕查：build 目录里 signed.apk 是最终产物，pack.log 里四步每一步的输出都在，history.ini 里这条 #序号 记录着当时原话，想"照这条再改一遍"随时点「选择」。

实例二：连续改两个自家应用，看标志文件怎么避免"串包"。 那天我们要连续处理两个内部应用：先给「巡检打卡工具」改开屏提示文案，再给「资产盘点 APP」改一个按钮文字。如果两个项目的完成信号混在一起，就会出现"改 A 的时候，B 的打包窗口弹出来了"这种串台事故。

实际上不会发生，原因就在机制里：每个项目是独立目录，改巡检打卡时，flag 写在巡检打卡那个项目的目录里；改资产盘点时，flag 写在资产盘点的目录里。主窗口等待谁，就只盯着谁的目录轮询。点第二个项目的「立刻修改」之前，开始等待前那一手"先清同名残留"也兜住了跨项目干扰 —— 两个 flag 文件名相同，但躺在不同目录里，谁也看不见谁的。于是两个改包任务一前一后，各自触发各自的打包窗口，产物分别落在各自项目的 build 目录，日志也各自成一份，收尾时一个都不会乱。

这两个例子放在一起看，你就能明白这套"标志文件 + 2 秒轮询 + 读到即删 + 1 小时上限 + 先清残留"的组合到底好在哪：它不追求实时、不追求炫技，它追求的是"每一次都能对上号"。 谁的需求、谁的标志、谁的包、谁的日志，四个"谁"永远指同一个项目。异步协作做到这个份上，你才敢把多轮改包放心地丢给它排队跑。

九、用户评价、合规提醒与结语

把这篇的技术部分收成一张清单：一个标志文件做信令、2 秒轮询找它、读到即删消费它、1 小时上限兜底它、开始前清残留防住旧它、AI 工作区干净加载两段式退出、history.ini 给每句话留痕。七个动作各自都不复杂，合起来却回答了一个很难的问题 —— 两个独立程序之间，怎么把"我改完了"这件事传得准、传得不重不漏、传完还查得到账。

这正是安卓修改大师智改工坊想让你感受到的状态：只需说话，就能让应用变成你想要的样子 —— 你负责说那句话，剩下的等待、触发、打包、留痕，都交给这套工程学自己跑。产品介绍页与下载入口：https://www.apkeditor.cn/ai-version.aspx（官网 www.apkeditor.cn）。