· · ·

一份发布辅助脚本里，至少有两类东西。打开页面、定位输入框等属于操作逻辑；某篇文章的标题、正文和配图，则属于这一次要处理的内容。

当你只是换一篇文章时，后一类通常需要变化，前一类未必需要改动。把两类东西混在一起，会让一次内容修改变得难以检查：看到代码有变化，还要分辨它是在换稿，还是调整了页面操作。

已有记录中的配置覆盖五个字段：imgdir、images、title、body、tags。它们分别回答图片放在哪、使用哪些图、标题是什么、正文是什么，以及附带哪些话题。

这个范围已经足够具体，不需要一开始就把整个脚本都做成可以配置。优先处理反复修改、含义稳定的输入即可。

· · ·

以一篇演示内容为例，可以用下面这样的结构理解这五项。目录和文案都是示意，实际使用时需要换成对应文件：

{
  "imgdir": "D:/content/article-23/images",
  "images": ["01-cover.png", "02-steps.png"],
  "title": "换篇文案，为什么还要改脚本",
  "body": "这里放本篇已经确认的正文。",
  "tags": ["AI应用开发", "工作流自动化"]
}

把图片顺序直接列出来，有一个实用的好处：读配置时就能看见本篇要放哪几张图。发现封面排在后面，可以在处理前修正，不必等到页面里再找。

图片目录和图片列表也要一起核对。只换标题和正文、忘记换目录，仍然可能把上一篇的素材带过来。配置文件让信息集中，但不会替人自动判断“这一组素材是不是本篇”。

· · ·

一个可以采用的目录习惯是：一篇文章一个文件夹，里面放已确认的文案、图片和本篇配置。文件名可以明确到篇号，避免桌面上出现许多难以分辨的“最新配置”。

这是一种整理建议，并不要求所有项目照搬。关键是下一次打开时，你能迅速回答：这份配置对应哪篇文章，引用的图片在哪里，正文是不是已经确认的版本。

对于一次正式处理，可以先列出准备顺序：

确认配置路径 → 读取并展示关键字段 → 检查图片文件是否存在、顺序是否正确 → 确认内容版本 → 执行页面填充 → 核对页面结果。

如果要进一步改进工具，可以增加“只预览配置，不操作页面”的模式。它的作用是帮助核对输入；已有记录只证明支持配置覆盖，不能据此认定这项预览能力已经实现。

· · ·

配置化解决的是输入怎么管理。读到了正确的 JSON，不等于页面已经填好；页面填好，也不等于文章已经发布。

这几个结果要分别检查。尤其在换稿时，可以先看标题是否属于本篇、图片数量是否符合配置，再确认正文与话题。操作中途如果没有拿到明确结果，也不应只凭“配置没问题”就判断后面的步骤成功了。

回到最初的问题：只是换一篇文案，为什么还要修改脚本？如果变化的是文章内容，就值得给它一个独立的位置。程序继续负责执行，配置清楚记录这一次要执行什么。

下次整理自己的小工具时，可以先找出那几个每次都要手动替换的值。把它们集中起来，往往就是一次足够实用的改进。

· · ·