用 Codex 做长推文项目落地
很多人用 Codex，只把它当成写代码工具。
这其实低估了它。Codex 最适合做的，不只是“帮你写几行代码”，而是把一个模糊任务落地成一组可以直接使用的项目资产。
作者这次的测试，不是做 App，也不是写网站，而是用 Codex 做一篇可以直接发到 X 平台的长推文。目标不是只生成正文，而是交付一套可发布资产。
交付目标
一篇能发到 X 的长推文，不只是正文，还至少包括：
- 原始素材整理
- 标题重构
- 正文改写
- 结构调整
- 封面图
- 正文插图
- 图片尺寸
- 文件命名
- 素材目录
- 发布前检查
第一步：把原始素材交给 Codex
素材是一篇关于 AI 工作流的草稿，里面包含：
- SaaS 创意
- 目标用户
- 产品流程
- 市场洞察
- 7 个 Agent 分工
- MVP 范围
- 评分体系
- QA 清单
- 增长文案
作者给 Codex 的明确目标是：把这篇素材改成可直接发送到 X 平台的长文。
关键点：不给交付标准，Codex 只会给内容；给了交付标准，Codex 才会按项目处理。
第二步：让 Codex 读取工作区规则
项目目录里有一个 AGENTS.md，里面写了文章风格：
- 先抛问题，再拆机制
- 少讲空话，多讲因果链
- 不要过度文艺化
- 结尾要清醒但有余味
这样 Codex 每次写长推文时，会先看项目规则，再开始动手。普通聊天工具需要每次重讲风格，Codex 可以把偏好沉淀在项目里。
第三步：先做计划，不急着写
作者强调，很多人用 AI 的问题是一上来就让它写，结果后面返工。
Codex 先把任务拆开：
- 正文怎么改
- 封面怎么做
- 插图怎么做
- 文件放哪里
- 怎么命名
- 怎么验证
这能避免文章写完了图没做、图做完了尺寸不对、尺寸对了路径又乱。
第四步：重写正文，而不是简单润色
Codex 会重新组织整篇长推文：
- 开头先讲痛点：为什么很多人用 AI 做内容，最后只得到一堆半成品
- 中段拆机制：一篇能发布的长推文，本质是一套交付流程
- 然后进入案例：读取素材、理解风格、改写正文、生成图片、保存文件、检查结果
- 最后收束到判断：真正值钱的不是 AI 帮你写几句话，而是能不能把内容变成可复用、可发布、可管理的资产
第五步：把结果写进项目文件
Codex 会直接把文章写进当前工作区，生成一个 Markdown 文件，并在顶部写清楚：
- 封面图位置
- 正文插图位置
- 建议插入段落
- 可直接复制发布的正文
这就不是一次性回答，而是内容资产。后续可以继续改标题、换封面、复用结构、做成系列。
第六步：同时生成封面图和正文插图
作者要求非常明确：
- 封面图和插图都要
2000 x 800 - 封面要有中文标题
- 正文插图要表达工作流
一个关键细节：中文标题不要直接交给图片模型生成。更稳的方式是：
- 图片模型负责底图
- Codex 用本机字体叠加准确中文
- 最后再检查尺寸
这是工具链思维：不要让一个环节硬做所有事，让每个环节做最擅长的事。
第七步：做发布前检查
作者特别强调发布前检查，避免在小细节上翻车：
- 图片是不是
2000 x 800 - 文件路径是不是写对了
- 正文有没有结尾引导
- 封面标题有没有遮挡
- 插图是不是横向构图
- Markdown 文件是不是保存成功
Codex 会把这些检查跑一遍，确认完再交付。
最终交付
这次流程跑完后，作者得到的是：
- 一篇 X 平台长文
- 一张封面图
- 一张正文插图
- 一个素材目录
- 清楚的插图位置
- 统一的图片规格
- 发布前检查结果
这些东西放在一起，才叫交付。
核心结论
Codex 不只是开发工具，更像一个项目型内容助理。
普通 AI 聊天工具帮你回答；Codex 帮你落地。回答是一次性的，落地是可以复用的。
作者最后给出的可复用提问方式是：
帮我把这篇素材落地成一套 X 长推文发布资产，包括正文、封面、插图、文件、路径、尺寸检查和结尾互动引导。
这样问，结果会完全不一样。