很多人第一次使用 AI 编程工具时，会把它当成一个更快的聊天窗口：提出需求，等待代码，然后复制粘贴。这样的方式可以解决零散问题，却很难形成长期能力。

我更愿意把 Codex 放在一张“工作台”上理解。它连接问题、资料、文件和发布环节，帮助我们把一个模糊想法逐步变成可检查的结果。真正重要的不是让 AI 替我们做完所有事情，而是让每一步都留下依据、状态和下一步。

一、从问题开始，而不是从工具开始

使用 Codex 前，先用一两句话写清楚目标：要解决什么问题，交付物是什么，什么结果算完成。例如，“在工具箱主题增加一篇介绍 Codex 的文章，并在测试站验证图片和分类显示”就比“帮我更新网站”更容易执行。

一个完整的问题通常包括三部分：

• 背景：当前项目是什么，已有的约束是什么；
• 结果：希望出现什么文件、页面或版本；
• 边界：哪些内容不能公开，哪些操作需要确认。

这一步看似简单，却决定了后续工作是一次性修改，还是能够被复用的流程。

二、让资料进入同一个上下文

Codex 的优势不只在写代码，也在于能把分散在仓库、文章、日志和检查脚本里的信息放在一起。一个稳定的工作区，至少应该有以下几类内容：

1. 内容源：以 Markdown 保存文章、说明和计划，便于在 Obsidian 中继续编辑；
2. 实现文件：主题模板、样式和脚本，记录网站真正如何运行；
3. 检查工具：内容检查、链接检查和部署检查，避免每次都从头判断；
4. 工作日志：记录版本、环境、变更和结果，让以后能够回看。

当这些信息位于同一项目中，Codex 就能先阅读现状，再提出修改，而不是凭空生成一段看似正确的代码。

三、把一次修改拆成四个可检查的阶段

适合网站内容更新的流程，可以压缩成四个阶段：

1. 准备

在 Markdown 的 frontmatter 中写明标题、栏目、主题、标签和隐私检查状态。图片放在内容目录内，并使用相对路径引用。这样文章既能在 Obsidian 中阅读，也能被发布脚本识别。

2. 转换

发布脚本将 Markdown 转成 WordPress 内容，同时创建或复用分类、标签，并把本地图片上传到媒体库。图片不会依赖电脑本地路径，文章发布后仍然可以正常访问。

3. 测试

先发布到测试站，检查四件事：文章是否出现在正确的三级主题、图片是否加载、移动端排版是否可读、返回主题和相关文章链接是否正确。发现问题时，优先回到源文件修改，再重新发布。

4. 发布与记录

测试通过后，再同步到正式站。版本记录需要写明文章 ID、媒体 ID、发布时间和备份位置。以后如果要撤回或迁移，仍然有清晰的依据。

四、哪些工作适合交给 Codex

Codex 适合承担有明确输入和检查标准的工作，例如：

• 将一篇结构化 Markdown 转换成网站文章；
• 检查分类、标签、链接和图片引用；
• 根据已有视觉系统调整页面间距、字体和响应式布局；
• 生成发布清单、版本说明和工作日志；
• 在测试环境运行检查，并汇总需要人工确认的差异。

这些任务的共同点是：结果可以被观察，过程可以被记录，错误可以被回滚。

五、哪些判断仍然要留给人

AI 可以加快整理和实现，但不应该替代最终判断。涉及事实准确性、来源可靠性、职业边界、隐私和公开表达时，仍需要人工复核。尤其是金融、政策和市场相关内容，应明确资料范围和使用边界，避免把一般知识介绍误读为具体建议。

一个简单的复核顺序是：先看事实，再看语境；先看是否准确，再看是否适合公开；最后才是语言和视觉上的润色。

六、把工具变成长期能力

当一篇文章、一张图片或一次部署完成后，不要只保留最终页面。把用过的模板、检查清单和决策理由留下来，下一次就可以从更高的起点开始。

对我而言，Codex 的价值正在这里：它让“想法—资料—实现—发布”之间的距离变短，也让每次工作都更容易回看、复用和改进。工具本身会变化，但这条从问题出发、以证据校验、用记录收尾的路径，可以一直保留下来。

好的 AI 工作流，不是把人从过程中拿掉，而是让人的判断出现在更关键的位置。