别让脚本先动手：我给所有写操作加了 dry-run 和一道影响面闸门

我给自己的下载目录写过一个清理脚本，逻辑简单到不需要注释：扫出超过 30 天没动过的临时文件，删掉。第一次跑之前我特意看过它的输出——"待删除 3 个文件"。执行完，删了 152 个。

原因不复杂：那行打印和真正执行，走的是两段不同的代码。打印是为了让我安心，执行时又用 `rglob` 重新筛了一遍，中间隔了几秒，别的任务正好往目录里塞了一批新文件。查回来的时候才发现，我信任的不是脚本，是那行字。

那次之后我给自己立了条规矩：**凡是不可逆的写操作，脚本必须先"干跑"一遍，把影响面摊开给我看，我看过再决定放行。** 下面是把这条规矩落成代码时，真正起作用的几处设计。

一、plan 与 apply 分离，而且必须是同一条代码路径

很多人做 dry-run 的方式，是加一个 `if not dry_run:` 把 `os.remove` 包起来。这看着像预演，实际上预演和执行算的是两份东西——预演里那套筛选条件，和真正执行时再筛一遍的条件，只要有一处对不上，预演就退化成了安慰剂。

正确做法是把"决定做什么"和"动手做"彻底拆开。先让计划阶段产出一份**冻结的决策清单**：

kind: str                  # delete / move / overwrite / publish

payload: dict = field(default_factory=dict)

RISK = {"delete": "high", "overwrite": "high", "publish": "medium", "move": "low"}

"""纯只读：只产出 Action 清单，一个字节都不写盘。"""

deadline = time.time() - keep_days * 86400

删什么、移到哪、覆盖谁，全部在 `plan` 里定死，写进 `Action`。`apply` 只负责执行这份清单，**绝不在执行时重新计算条件**。这是整套机制里最不起眼、也最要命的一条：预演之所以可信，不是因为它是只读的，而是因为它给后续执行留下了不可协商的决定。

二、预演和真实执行共用唯一入口

清单定好之后，执行器只留一个入口，dry-run 只是"不落盘"的那个分支：

def apply(actions, execute, dry_run=False):

print(f"[dry-run] {a.kind:9} {a.target}  # {a.detail}")

execute(a)          # 全流程唯一一处真正改盘的代码

这样预演看到什么，执行就是什么。执行器里我再补一层落地前复查：target 是否仍然存在、mtime 是否还是 plan 时那个值，对不上就跳过这一条并记账，而不是"既然来了就删吧"。

三、按影响面分档，让异常数量自己亮红灯

预演本身拦不住事故，152 个文件照样能被删掉。真正兜底的是"数量 + 风险等级"组成的闸门：

| low | 移动、重命名 | 50 条 | 打印清单，等待确认 |

LIMITS = {"low": 50, "medium": 10, "high": 0}

over = [(r, c) for r, c in n.items() if c > LIMITS[r]]

return True, "；".join(f"{r} 风险 {c} 条 > 阈值 {LIMITS[r]}" for r, c in over)

注意 high 那一档的阈值是 0，不是"少量就放行"。删除和覆盖没有安全的小批量，一条误删就是一条不可逆。阈值在这里的作用不是省事，而是把**数量异常翻译成"需要人看一眼"**：一个平时删 3 个文件的脚本，突然要删 300 个，那个 300 就是最该被拦下来的信号。

固定阈值之外我还加了一道**基线偏离判断**：每次运行都把影响面数量写进 jsonl，本次数量超过历史中位数 5 倍就无条件要求确认，哪怕绝对值没超阈值。阈值管"绝对量级"，基线管"相对异常"，两者管的根本不是同一类风险。

四、plan 与 apply 之间会漂移，别信那份旧清单

清单确认完，人可能隔十分钟才点执行，这十分钟里目标目录会变。我给计划清单算一个指纹（内容哈希），执行前重算比对，对不上就要求重新 plan。文件整理类工具把这一步做成"蓝图签名"也是同一个思路：**签过名的计划才允许执行，签名失效的清单直接拒绝**，不给人"照着旧地图开新路"的机会。

我一度以为预演天然干净，直到发现某个脚本在预演阶段顺手建了输出目录、写了一行状态文件。第二次预演读到的判断依据，已经被第一次预演改过了——**预演污染了自己的输入**。

所以预演分支里只允许打印和统计，不允许创建、写入、调用外部接口。接口类操作尤其要守这条线：一次"预演"的 POST，可能真的把东西发出去了。

给写操作加预演，成本低得出乎意料：一个 Action 结构、一个只读的 plan、一个带 dry-run 分支的执行器，加起来不到一百行。但它改变的是脚本的定位——从"你说什么它就做什么"，变成"它先说清楚打算做什么，你点头它才动手"。

预演真正的价值不在于拦住了多少次事故，而在于它把一次不可逆的操作，重新变回一个可以复核的决定。

把「决定做什么」和「动手做」拆成 plan / apply 两阶段，用冻结的 Action 清单加影响面阈值与基线偏离判断，让删除、覆盖、发布、批量移动这类不可逆写操作在动手前先摊开影响面。

编程语言

开发工具

架构设计

为写操作设计dry-run与影响面闸门：计划与执行分离、冻结决策清单、按风险分级设阈值（删除类0条自动放行）、基线偏离检测、计划签名校验，确保每次不可逆操作均可复核确认，杜绝脚本误删事故。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

别让脚本先动手：我给所有写操作加了 dry-run 和一道影响面闸门

别让脚本先动手：我给所有写操作加了 dry-run 和一道影响面闸门

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐