从PPT-diff代码阅读看取消操作与PowerPoint资源清理

本文记录对 AI 办公实践中心 PPT-diff 项目的静态代码阅读，聚焦交互式自动化工具的取消路径与资源清理。本文由 AI 辅助整理，未在 Windows + PowerPoint 环境实机复现，不把风险分析当作已经发生的故障。

一、取消按钮也需要设计

交互式工具常把注意力放在接受和拒绝上，但取消也是独立业务状态。用户可能希望退出本轮处理，也可能希望保留窗口继续人工检查。如果界面、输出文件和程序清理逻辑对取消的理解不同，就容易误判执行结果。

二、阅读看到的调用关系

阅读对象为项目 main 分支 scripts/ppt_review.py。脚本通过 win32com.client.Dispatch 获取 PowerPoint.Application 对象，打开新版演示文稿。内部 show() 函数调用 messagebox.askyesnocancel 展示提示；返回 None 的 Cancel 分支执行 pass。随后 main() 在 show() 返回后尝试执行 pres.Close() 和 ppt.Quit()。
这些代码说明取消分支会返回后续清理流程，但单凭静态阅读，不能证明一定会关闭用户其他演示文稿，更不能证明发生了数据丢失。COM 对象的实例关系、已有窗口状态和 PowerPoint 的交互行为需要在目标环境验证。

三、把状态和资源所有权表达清楚

一种供维护者评估的设计是让审阅过程返回 completed、cancelled 或 failed 等明确状态，再由外层决定是否保存输出、关闭本轮文档和退出应用。保存条件与取消条件就能被直接阅读和测试。
同时应明确资源所有权：本轮打开的文档由谁负责关闭，应用实例是否为脚本独立创建，是否可能复用已有会话。如果依赖独立实例，就应核实创建方式能否满足隔离要求；如果复用了用户已有实例，退出应用前应采用更谨慎的策略。具体实现需结合 COM 行为确认。

四、建议验证的场景

准备两份含少量文本差异的测试 PPT，另行打开一份已保存的无关 PPT。分别验证：第一条差异直接取消；处理部分差异后取消；全部审阅结束；处理过程中出现异常。每组记录原有窗口是否保留、本轮文档是否关闭、是否生成输出文件、提示是否与结果一致。
测试使用可丢弃副本，避免拿重要文档做首次验证。README 也应说明取消后保留什么、丢弃什么，以及输出文件何时生成。

五、区分证据与推断

Issue 可以采用代码依据、预期行为、验证办法的结构。没有复现就写明尚未复现，不把可能影响描述成确定故障。提交前搜索已有 Issue，避免重复讨论。这次已发现拒绝修订的讨论，因此只提交取消语义与应用生命周期建议。
项目：https://gitcode.com/agent-best-practices/PPT-diff
源码：https://gitcode.com/agent-best-practices/PPT-diff/blob/main/scripts/ppt_review.py
建议：https://gitcode.com/agent-best-practices/PPT-diff/issues/156
对桌面应用自动化而言，正常完成、用户取消和异常退出都应有清晰的状态与资源边界。