type
Post
status
Published
date
Sep 5, 2026
slug
summary
最近我在搭一套内容创作的工作流。中间走了段弯路，但它不是白走的——它让我把一件以前一直模糊的事想清楚了：AI 不是一块万能砖，每个工具都有自己的长板，关键是得给它们分对工。
tags
Write
category
Messy
icon
password
url
最近我在搭一套内容创作的工作流。中间走了段弯路，但它不是白走的——它让我把一件以前一直模糊的事想清楚了：AI 不是一块万能砖，每个工具都有自己的长板，关键是得给它们分对工。
一、一开始，我想用一套流程把内容「固定」下来
我最早的思路特别省事：把小红书、公众号这种创作，固定成一套 skill 流程走下来，以后就不用重复生成了。说白了，就是想做个一次性的自动化，把「生成」这件事往后一扔，让自己从此省心。
于是我把方向押在 Codex 上，想让它把整个创作链路包下来。那会儿我盯的是「流程」，只要链路能跑通、能复用，好像就成功了。
二、跑了几天，发现方向错了
结果跟预期差得挺远。我用 DeepSeek 去生成，发现它实际调用的是 Codex cli 的链路，效果并不好。
问题在哪？停下来想明白之后，我写了一句很直接的话：之前的方向是错的。
原因在于 Codex 的底子偏工程化。它的生图，主要用来做网页创作、识图、给工程项目出素材；可我要做的是小红书、公众号这种偏前端的内容创作，需要的是有创意的生图、有网感、能反复沟通调整的视觉。这一块，GPT 的生图是 Image 2.0 版本，明显更对路。
工具没有好坏，是用错了地方。被 Codex 拉去干内容，等于让一个工程师去当总编，拧着劲。
三、真正让我想通的，是给每个工具分好工
错了一次之后，我没急着再换工具，而是停下来把每个 AI 到底擅长什么，认认真真捋了一遍。捋完，框架就清楚了：
- ChatGPT = 内容总编 + 创意设计
- Codex = 数据工程师 + 开发工程师
做内容、做创意视觉，优先用 ChatGPT 网页版：
- 选题、找角度、写文案
- 标题与表达优化
- 信息图构思
- 生图、改图、多轮视觉调整
- 需要审美判断和反复沟通的任务
Codex 更适合：
- 数据抓取、清洗、计算
- Python 批处理
- 自动生成图表/素材
- 开发网站和内容工具
- GitHub、代码、部署
- 把已经确定的内容流程工程化、自动化
为什么 ChatGPT 生图通常更好？我记下一个解释：就算底层的图像模型接近，最终效果也取决于「模型能力 + 上下文理解 + Prompt 处理 + 推理规划 + 产品侧优化」。ChatGPT 的生图链路更偏向「把最终视觉作品做好」，而 Codex 的生图更偏向「为工程项目生成所需素材」。
一句话记住：做「内容」优先 ChatGPT，做「工程」优先 Codex。
这其实也是我想明白的一件事：AI 再强，也只是「执行层」。真正决定怎么用、用哪个的，是那个在背后拍板的人。工具负责干活，人负责判断哪个活该交给哪个工具。
四、V1.0 工作流，就这么跑通了
分好工之后，我的内容生产流程变成了这样：
- Codex：数据获取/处理
- ChatGPT：分析/创意/文案
- ChatGPT Images：最终视觉
顺带，我还把内容命名、归档、配图这一整套也都定下来了——统一的命名规则、系列文件夹、一套状态管理，再沉淀成可复用的 skill。核心的一条是：小红书这类需要网感和审美的创意首图，走 ChatGPT 网页版真生图，不再用工程口子的工具硬凑。
跑到今天，内容生成、配图生成都已经能完成，也能存进对应的位置，初步算是通了。这一步，我叫它 V1.0。
接下来的 V1.5 或 V2.0，还有两件事要补：
- 风格训练：把账号里已有的笔记都爬下来，交给 AI 去读，相当于拿历史数据训练出一个「我的风格」，让后续生成都能照着来，保持一致性。
- 发布测试：测试通过网页版的 MCP 方式，去做内容发布。
收尾
这趟弯路给我的最大收获，不是「某个工具更好用」，而是把 AI 分对工。
以前我总觉得 AI 是万能的，碰到需求就想着「用哪台机器一刀切」。可真跑起来才发现，内容创作和工程实现，根本是两件不同的事：一个要审美、要网感、要反复沟通；一个要稳定、要可复用、要能自动化。用错工具，不是不好用，是压根拧着劲。
工具越来越强这件事本身不值得焦虑。值得留意的是：知道哪个活儿该交给哪个工具，比「会不会用 AI」更值钱。真正拉开差距的，不是你会不会调模型，而是你有没有那个「判断」——判断这件事该用哪个、怎么用、做到什么程度。
这大概就是我一直说的，AI 是执行层，而判断和方向，得握在自己手里。