拆解我平时用 ChatGPT、GPT Image 2 和 Codex 制作技术博客的完整流程：先做真实过程，再写正文、规划图片并完成多格式交付。
朋友问我：给博客配图时，怎样让每张图既接得住全文的上下文，又能各自讲清一件事？
我把自己的流程顺了一遍，发现配图只是中间的一环。图片开始生成以前，我已经做完了选题、真实操作和正文草稿；图片完成以后，还要整理文件、导出格式、检查并上线。
这篇文章就把这套流程完整拆开。你现在看到的正文和图片，也是这样一步步做出来的。
1. 先定骨架，别急着要正文
我写教程时，第一步通常是和 ChatGPT 讨论文章结构。
假设要写一篇 Skill 教程，我会先回答这些问题：要做出什么东西，读者需要准备什么，实际步骤有哪些，哪里可能报错，最后怎样确认成功。
讨论结束后，我需要的产物是一份可以照着执行的清单：
明确目标
准备环境
创建并配置
实际测试
处理问题
确认结果这时我不会让它直接生成完整正文。操作还没发生，命令是否可用、页面是否变化、会遇到什么问题都不知道。先写出来的教程看着很顺，实际动手时却可能完全不是那回事。
骨架还有一个很实用的作用：它会提醒我接下来该留下哪些证据。关键命令要保存，界面变化要截图，报错和解决办法也要记录。等实验开始以后，我不必再临时判断什么值得写。
我还会把提纲里的内容分成“必须实测”和“补充解释”。安装、调用、文件生成都要用实际结果证明；概念说明可以等流程跑通后，再结合读者会卡住的位置补上。
2. 边做边留下证据
骨架确定后，我会开一个新的临时聊天，把提纲完整发进去。这样做只是为了给这次实验留一个干净的工作对话。
接下来直接动手：ChatGPT 提示下一步，我在真实环境里操作；成功了就把结果和截图发回去，报错了也把错误原样发回去。它根据当前状态继续往下带。
这个循环会把一条教程实际跑过的轨迹留在对话里：
计划 → 操作 → 结果 → 问题 → 修正 → 下一步教程里最有用的内容经常来自计划之外。某条命令的输出和预期不同，插件装好后没有立即出现，或者一个步骤需要重启才能生效。这些细节如果当场没有保存，写正文时很容易被忘掉。
所以我会把成功结果和失败过程都留下。文章之后可以删掉无关弯路，但不能凭空补出一条没有跑过的路径。
3. 做完以后，再让它写正文
整个任务跑通后，这个对话里已经有了提纲、命令、截图、报错、修改过程和最终结果。我这时才让 ChatGPT 生成正文草稿。
我的要求通常很直接：
根据刚才真实完成的过程整理文章。保留读者需要执行的步骤、预期结果、成功标志和最小排错；删掉对完成任务没有帮助的讨论。
此时它只需要整理已有材料。哪一步先发生，实际输入过什么，错误怎样解决，都能在前面的记录里找到。
草稿出来后，我还会自己核对一遍：命令有没有抄错，产品名称和版本是否准确，截图与段落是否对应，成功标志是否真的出现。AI 可以把零散记录变成文章，技术事实仍要回到实际结果上确认。
4. 正文稳定后，再规划配图
正文基本稳定以后，我会把全文交给 ChatGPT，让它逐段判断视觉需求。问题会具体到：每一段最适合怎样解释？
- 操作已经有清晰界面，就用真实截图；
- 多个角色或步骤容易混在一起，就做流程图；
- 一句话已经讲清楚，就不配图；
- 封面只负责说明主题，不承担教程步骤。
配图这时能看见前后文。它知道读者上一段刚学了什么，也知道下一段要进入哪里，便可以把难懂的关系画出来。
截图里还保留着我当时顺手写下的“Image 2.0”。本文统一使用当前产品名称 GPT Image 2。
我还会给每张图写清楚三个东西：它放在哪一段、要解释什么、读者看完应该得到什么。到这一步，图片数量才算确定。
5. 一张图只解决一个问题
开始生成图片时，我会为每张讲解图单独开一个 GPT Image 2 对话。
每个窗口都拿到两份信息：完整正文，以及当前这张图的任务说明。完整正文提供上下文，单图说明限定这一轮只解决一个问题。
例如，流程总览只负责画清阶段和角色，原理图只负责解释某个关系，封面只负责让人一眼认出主题。它们不在同一个对话里连续生成，各自的修改记录也不会混到下一张图中。
生成后我会先看信息是否准确，再看画面是否好看。文字写错、箭头走反、步骤遗漏，都属于不能使用；风格、颜色和装饰则可以在事实正确以后继续调整。
这也回答了开头那个问题：让配图兼顾上下文，不需要把所有信息都挤进一张图。每个窗口知道全文在讲什么，同时只承担一个清楚的视觉任务。
6. Codex 负责组装，也负责把关
正文、截图和讲解图准备好后，我会把它们放进同一个素材目录，再交给 Codex 处理最终成品。
这一阶段的工作很具体：确认图片对应的段落，写入 Markdown，整理标题和代码块，生成公网图片版与本地图片版，再导出公众号稿、离线 HTML 和 Word。
组装完还要继续检查：
- 原始截图里有没有用户名、绝对路径或其他隐私信息；
- 普通 Markdown 的图片地址能不能公开访问；
- 公众号稿有没有留下发布后不可用的正文链接；
- Word 每一页是否正常，图片有没有溢出或被截断；
- 网站上线后还要核对标题和正文标记，不能把一个返回 200 的首页当成发布成功。
公众号仍由我自己复制、预览和发布。Codex 负责把适合粘贴的稿件准备好，并把网站版本部署到线上。
到这里，整套流程才闭合：
回头看，这套方法里没有哪一条神奇 Prompt。它只是把不同工作放在合适的时间：先定骨架，再做真实操作；根据记录写正文，再根据全文规划图片；最后组装、检查和发布。
Prompt 决定这一轮怎么做，Workflow 决定模型开始前已经知道什么。
而这篇文章本身，刚好就是这套 Workflow 的一次完整样例。