我曾经把“剪辑软件完全不占前台”当成一个应该继续攻克的工程目标。那天我准备把一套桌面自动化流程再往前推，第一反应是盘点还有哪些地方会激活窗口，然后继续寻找更隐蔽的点击方式。只要任务还会短暂跳出一个窗口，我就觉得它还不够自动化。
后来我把每条链路拆开，才发现这个目标本身有问题。建草稿、注册、字幕和封面，已经可以在文件层完成；文字成片注入和导出，只需要一次很短的激活；原生文字转语音则仍然需要一次短促的真实人机操作。再往后，我又把留活进程接上，第一份稿件保留冷启动成本，后续稿件则在同一个进程里继续工作，实跑结果是稿 A 的激活次数为 1，稿 B 为 0。
这次经历让我重新理解“零前台”。它不是一句把所有窗口都藏起来的口号，而是一笔要按链路、按次数、按证据算清楚的账。
先把“前台”拆成几种不同的事
一开始看桌面自动化，最容易看到的是窗口有没有出现在眼前。但窗口出现，只是结果，不是原因。一个流程可能因为创建应用进程而激活，也可能因为操作系统创建第一个窗口而激活，还可能因为某个功能必须依赖真实的选区和面板。
我先按动作重新登记了一遍。建草稿，本质上是写入结构化文件；注册，是准备素材之间的关系；字幕和封面，也可以先生成对应文件。这些步骤不需要打开编辑器，更不需要把窗口置于前台。它们的共同点不是“脚本很快”，而是数据在文件层已经足够表达目标。
文字成片注入则不同。它需要把已有文本送进应用内部的编辑链路，代码级测得约 0.233 秒。导出链路约 175–635 毫秒。这里仍然有一次激活，但时间很短，而且发生在冷启动阶段。原生文字转语音约需 220–250 毫秒的 HID 操作，因为它必须选中活的字幕段，再打开朗读面板。这个动作不是简单写文件可以替代的。
判断自动化程度，不能只问“有没有窗口”，还要问这次窗口出现究竟是在传递数据，还是在满足应用的物理入口。
如果不先这样拆分，后面很容易把所有时间都归罪于代码不够快。于是继续堆坐标点击、压缩等待、尝试各种启动参数，最后得到一套越来越脆弱的流程，却没有改变真正的约束。
文件能表达的，就不要交给界面
这次最确定的结论，是文件级处理应该尽量独立出来。建草稿、注册、字幕和封面之所以能够做到零前台，不是因为找到了某个神秘开关，而是因为这些动作的输入和输出都能被稳定地保存、读取和校验。
这会改变设计顺序。以前可能是先打开应用，再想办法把材料逐个塞进去；现在则是先把稿件、字幕、封面和关联信息准备完整，最后才把必须进入应用的部分作为一个窄入口。应用不再承载整个流程，只承载它确实拥有的那段能力。
这样做的好处不只是一点时间。文件可以重复检查，可以在失败后重新投递，也可以在应用没有启动时提前准备。如果不处理这一步，所有小错误都会变成一次完整的前台操作：窗口要重新打开，材料要重新选择，失败位置也难以判断。最后浪费的不是几百毫秒，而是人的注意力和对流程状态的信任。
我选择先做文件化，是因为它同时降低了前台次数和状态复杂度。一个文件写错，通常可以定位到输入；一个界面操作失败，则可能留下半成品、焦点漂移和不可见的中间状态。前者更容易恢复，后者更依赖当时屏幕究竟处于什么样子。
物理下限不是优化失败
剩下的激活为什么不能继续用技巧消掉？冷启动是一个关键例子。应用第一次创建窗口时，操作系统和窗口系统会介入，把应用提升到前台。进程内部并不能可靠地读出“我现在是不是前台”，所以只能在进程外完成启动与事后归还。这段往返带来的约 0.15–0.6 秒，不是业务代码正在等待某个明显的按钮。
我曾经考虑过吞掉激活、修改应用策略、改变启动时机等方向。后来这些方向逐一被活体条件挡住，才接受了一个不太讨喜但更准确的判断：如果目标是“每一份任务都从冷启动开始”，那一次激活就是当前架构的物理下限。继续把它描述成“还有优化空间”，反而会误导下一轮工作。
原生文字转语音也是类似的边界。它不是普通的导出调用，而是“选中哪一段字幕、使用哪种声音、打开哪个面板”的组合。为了绕开这次操作而改走云端接口，还会引入合规和能力一致性问题。我没有这么做，是因为省下 220–250 毫秒，并不值得把一个清楚的本地边界换成不可控的外部依赖。
真正成熟的优化，不是把每个剩余数字都说成可消除，而是把能消除的成本和不能消除的边界分开。
这件事让我重新意识到，工程判断有时不是找到更聪明的办法，而是停止追逐错误的目标。知道哪里已经到底，和知道哪里还没有验证，是同一张账上的两列。
留活进程，把一次冷启摊到后续任务
冷启动不能消除，并不意味着每一份稿件都必须重新冷启动。于是我把问题换了一个问法：能不能让第一次启动承担唯一的激活，之后让已经注入、停在首页的进程继续工作？
这里不能简单地说“不要退出应用”。原来的进程退出后，下一份任务还要重新打开；如果只是强行保活，却没有可靠的回首页动作，下一次任务就可能接在上一份稿件的编辑状态上。那样看起来激活少了，实际却把数据串稿的风险藏了起来。
留活方案因此包含几个必须同时成立的条件：第一次冷启仍然计 1 次激活；进程保持在可识别的首页状态；下一份稿件能够在同一个进程里打开和导出；导出完成后，通过进程内动作关闭稿件并回到首页；每一轮都有独立序号，不能把上一轮的日志误认成这一轮的成功。
这次实现的关键变化，是把“关稿回首页”从可能短暂置前台的外部操作，换成应用进程内部的入口。代码级检查确认了这条路径，用户随后在有图形会话的终端里实跑，得到稿 A 激活 1、稿 B 激活 0。这个结果说明后续复用路径成立，但它不等于所有场景都已经永远零前台；它依赖进程仍然活着、状态仍然正确，而且第一份稿件的冷启动成本依旧存在。
代码验证和实机验证必须分开
这次还有一个很容易被忽略的限制：后台 shell 能编译、跑测试、检查符号和验证命令契约，却不能凭这些动作生成真实的前台证据。没有处在图形会话里的 shell，启动注入车道时可能直接退出；换成另一种启动方式，又可能丢失注入环境。
所以我把证据分成两层。第一层是代码和测试证据：文件级链路是否没有打开界面，留活车道是否保留旧行为，日志序号是否隔离，回首页入口是否存在。第二层是活体证据：在真正有桌面会话的终端里跑两份稿件，确认第 1 份冷启为 1，第 2 份复用为 0，并检查两份导出结果都完整。
如果不区分这两层，就会出现一种危险的“全绿”：测试都通过了，于是文章或报告顺手写成“已经完全零前台”。这句话既超出了代码能证明的范围，也掩盖了必须由用户设备完成的最后一步。没有产生真实前台状态的环境，不能替代真实前台状态的验收。
这里最容易误判的，是把“预期为 0”当成“已经测得为 0”。留活方案在设计上确实以 0 为目标，代码级复核也通过了，但目标、预测和实测是 3 个不同的词。只有稿 A/B 的独立运行结果，才足以把它们连接起来。
下次我会怎么做
下次遇到类似的桌面自动化问题，我会先建立一张最小账本：每条链路的输入是什么，是否能纯文件处理，是否需要冷启动，是否需要真实选区或 HID，预期激活次数是多少，最后由什么环境来验收。
然后我会按 3 个顺序推进。第一，把能文件化的动作全部移出界面，并为输入和输出留下可检查的文件。第二，对必须进应用的动作测时、数激活，并判断它是冷启动成本、业务入口成本，还是可以通过进程复用摊薄的成本。第三，把代码测试和实机测试分开报告：前者证明结构没有明显回退，后者证明真实桌面上的状态确实发生了。
我还会给每个结论加上范围。比如，“建稿、注册、字幕和封面已是零前台”是文件链路结论；“文字成片注入约 0.233 秒、导出约 175–635 毫秒”是测量结论；“首次激活 1、后续激活 0”是特定留活方案下的实跑结论；至于无法在当前 shell 产生的前台证据，就明确标成待验证。
一个流程成熟的标志，不是它能在演示里跑通一次，而是下一份任务不必重新支付同一笔冷启动成本，也不必靠操作者记住上一次窗口停在哪里。零前台的价值，最终不在于把一个窗口藏起来，而在于把物理下限、可复用的复用路径和还没有验证的地方，都诚实地写进流程里。