摘要
昨天我讨论了一个配图生成问题：如果用户不停点击“生成”，系统应该怎么处理？
表面看，这是一个按钮防抖问题。再深一点，是任务排队问题。但从内容生产的角度看，它其实是版本管理问题。重复生成通常不是用户手滑，而是用户对上一版不满意。
这篇文章讲的是为什么生成类功能不能只管“再跑一次”，还要让版本关系变清楚。
目录
- 重复点击背后的真实意图
- 为什么不能默默生成一堆文件
- 我希望的生成版本逻辑
- 配图跑偏时怎么追溯
- 长期收益
- FAQ
重复点击背后的真实意图
如果一篇文章已经生成了一套配图，用户又点了一次生成，通常有两种可能。
一种是误点。这个靠按钮状态和任务提示可以解决。
另一种是用户不满意上一版，想重做。这就不是简单防抖能解决的。
如果系统只把每次点击都当成新任务，就会生成很多相似文件。用户不知道哪一版正在使用，也不知道旧版还能不能删。
最后，内容目录会变乱，正文引用也可能乱。
为什么不能默默生成一堆文件
生成类功能最容易制造“看起来很多，实际不知道用哪个”的结果。
一套配图生成完以后，它和正文应该有关系：哪些图被引用了，插在什么位置，是当前版本还是历史版本。
如果系统默默生成第二套、第三套，却不说明版本关系，用户就会被迫自己判断。这个判断成本很高，而且很容易错。
所以我觉得，重复生成不应该只是“再来一次”，而应该是“重做当前版本”。
我希望的生成版本逻辑
理想状态下，系统应该显示当前版本。
用户如果要重做，系统要问清楚：新版本生成后是否替换当前引用？旧版本是否保留？是否需要回滚？
如果只是补生成缺失图片，就应该只补缺失部分。如果是完全重做，就应该建立新的版本记录。
这样用户的动作就从“我又点了一下”变成“我要重做这一版”。这两种语义差别很大。
配图跑偏时怎么追溯
昨天还遇到一次配图跑偏。用户看到图不对，第一反应是怀疑当前截图流程。但排查后发现，图片来自另一个旧配图流程。
这件事提醒我：内容系统里只要有多个生成链路，就必须能追溯每张图从哪里来。
一张图应该能回答这些问题：它是哪篇文章生成的？用的是哪条流程？对应哪段内容？有没有被正文引用？
如果回答不了，排查就会变成猜。
长期收益
把重复生成做成版本管理，长期收益很明显。
用户更敢重做，因为知道旧版不会莫名消失。系统更容易清理，因为知道哪些文件是当前版本。排查也更快，因为知道每张图的来源。
生成能力越强，越需要版本秩序。否则自动化越多，现场越乱。
FAQ
重复生成一定要禁止吗？
不一定。重复生成是合理需求，但应该有版本语义，而不是无限堆文件。
用户不满意上一版怎么办？
应该提供“重做当前版本”或“生成新版本并替换”的明确入口。
为什么要记录图片来源？
因为内容系统可能同时有截图、卡片、插画等多条生成链路。没有来源记录，出了问题很难查。