用最少的工程动作，把自动化脚本从“能跑”收敛到“可信”

用最少的工程动作，把自动化脚本从“能跑”收敛到“可信”

很多团队都有一类脚本：它们不是核心业务代码，但又承担了发布、巡检、同步、清理这类真实职责。问题通常不在于“能不能跑起来”，而在于一旦脚本进入日常使用，大家会迅速发现另一个更尖锐的问题：它到底可不可信。

“能跑”和“可信”之间，差的往往不是复杂架构，而是几个很朴素的工程动作。下面结合我最近整理自动化脚本的一些经验，谈一个更实用的收敛路径。

一、先区分一次性脚本和长期脚本

很多混乱的起点，是把两类脚本当成同一种东西维护。一次性脚本的目标是尽快完成任务；长期脚本会被 cron、CI、运维任务或者同事反复调用，这时候脚本本身就已经是一个小型产品了。

# 如果一个脚本会被重复执行，就不要只优化“第一次跑通”
crontab -l

只要脚本会重复运行，就至少应该具备四个特征：输入明确、输出结构化、失败可定位、结果可验证。

二、把输入收紧，不要让 shell 替你猜

长期脚本应尽量遵循两个原则：短参数走命令行，长内容走文件或 stdin。

node cnblogs-post.js “自动化脚本的可信收敛” < article.md

这样可以避免超长命令行参数带来的截断和转义问题，保留 Markdown 原始结构，也更容易本地复现与调试。

三、输出必须结构化

脚本结束时输出 JSON，调用方不需要重新猜测日志含义。保存成功和发布成功不是同一个状态，只有明确的 isPublished=true 和 postId 才能确认发布。

{
  "success": true,
  "postId": "12345678",
  "isPublished": true
}

四、对外部系统优先保存状态

涉及浏览器自动化、后台发布、第三方平台操作时，应尽量使用持久化浏览器 profile，并把 cookies 作为补充兜底。这样可以减少验证码、页面改版和 session 复用失败带来的问题。

const ctx = await chromium.launchPersistentContext(userDataDir, {
  headless: true,
  args: ['--no-sandbox']
});

五、失败路径要写给未来的自己看

异常分支应该区分输入错误、权限错误、页面状态不符、网络超时和外部系统风控。验证码或权限问题通常不适合自动重试，偶发超时才值得做有限次数重试。

六、最后一步不是执行完成，而是验证完成

点击发布或收到 200 不等于结果达成。动作之后还要确认 success=true、isPublished=true、postId 非空，并访问公开页核验标题、正文和代码块。

结语

自动化脚本不一定需要复杂设计，但需要基本的工程约束。输入收紧、输出结构化、登录状态复用、失败分类、结果验证，这些动作共同决定了脚本能否从偶尔可用变成持续可信。