配置必须和代码分离
脚本里硬编码账号、路径、API 地址和开关，是后期维护的主要问题。推荐使用环境变量保存密钥， 用 YAML 或 TOML 保存普通配置，用命令行参数覆盖临时选项。配置加载后要做 schema 校验，启动时就发现问题。
python run.py \
--config configs/prod.toml \
--limit 200 \
--dry-run日志要为排障服务
好日志要能回答三件事：脚本处理了什么、成功了多少、失败在哪里。日志建议使用 JSON lines 或结构化字段， 至少包含 timestamp、level、job_id、action、target、duration_ms 和 error_code。敏感字段必须脱敏。
不要只写 print("done")。当脚本跑了 3 小时后失败，你需要知道最后一个成功对象和第一个失败对象。
错误处理要分级
网络超时、数据格式错误、权限不足和业务校验失败不是同一种错误。可重试错误进入重试队列，不可重试错误写入失败表， 高风险错误立即停止任务并告警。这样脚本才能在无人值守时安全运行。
- retryable：请求超时、连接中断、临时 5xx。
- skippable：单条数据格式错误，不影响整体任务。
- fatal：认证失败、权限不足、配置缺失。
- risk：触发频控、账号异常、数据量突然偏离。
交付时给出运行手册
README 写清安装、配置、运行、回滚和常见错误。
提供 dry-run 模式，先看将要执行的动作。
输出结果文件和失败文件，方便二次处理。
给脚本加版本号，日志里记录当前版本。
只要做到这些，临时脚本就开始具备工具属性。后续加 GUI、定时任务或 Web 控制台时，也不会被早期混乱结构拖住。