从 Claude Code 切到 Codex：我用 Agent、Skills、MCP 做完了一个内容运营工具

我最近把开发主力从 Claude Code 换到了 Codex。

不是 Claude Code 不好用。相反，它在终端里一直很顺手，改代码也快。只是我慢慢发现一个问题：很多需求在终端里聊得热火朝天，最后总停在八成。

页面有了，接口通了，演示也能跑。

但数据是真是假、流程能不能接着走、发布失败怎么办、代码到底验证到哪一步，这些麻烦事，最后还是得我自己一点点收拾。

这次让我真正感觉到差别的，是一个给自己用的小红书内容运营工具。

它最开始只是个很普通的想法：输入一段经历，让 AI 帮我整理成标题和正文。

结果做着做着，内容生成反而成了最不重要的功能。

我真正需要的是：素材有出处，AI 写到一半能恢复，改过正文后旧检查自动失效，排期不等于发布，没有拿到数据就老实显示缺失。

这套东西最后能落地，靠的不是某一条神奇提示词，而是我现在最常用的 Codex 三件套：

多 Agent 负责争论和做决定，Skills 负责记住规矩，MCP 负责真的动手和验收。

这也是我从 Claude Code 切过来以后，感受最明显的地方。

最先让我觉得不一样的，是它真的会操作电脑找问题

以前我让 AI "看看这个页面为什么不对"，它通常会从代码里猜：可能是状态没更新，可能是接口缓存，也可能是前端判断写错了。

这次我没有先告诉 Codex 应该看哪个文件，只说页面上的发布稿突然不能用了。

它先检查本地服务是否真的启动，确认当前运行的是哪一份目录和数据库；接着打开浏览器，进入内容页和发布跟进页，看页面实际显示的状态；然后再拿着页面上的提示回到代码里搜索。

浏览器里给出的线索是：

发布稿在检查后发生过变化，请重新检查。

顺着这句话继续查，最后定位到的并不是按钮问题，而是发布包的内容指纹已经变化。正文、图片或者证据只要改过一处，之前的检查快照就应该失效。

整个排查过程更像我自己处理 Bug：先复现页面，确认现在看到的现象，再从页面文案和状态回到接口、服务层和数据库，而不是打开仓库后先猜一个最像答案的地方。

后面它又做了几件很实在的事：

• 在终端里确认启动进程和实际工作目录；
• 打开真实页面，而不是根据组件代码脑补效果；
• 从页面提示反查状态来源和数据链路；
• 修改后重新打开页面，确认展示已经符合预期；
• 跑测试、类型检查和代码检查，最后再截取脱敏后的页面证据。

这也是我后来越来越依赖 Codex Desktop 的原因。它不只是住在终端里，还能把终端、代码、浏览器和本地文件接到同一个任务里。

第一次评审，几个 Agent 先把我的方案否了

一开始我给的需求很贪心。

自动找选题、自动生成、自动配图、自动发布、自动记录数据，最好再算一下什么时间发最容易爆。

如果直接进入开发，这个需求能做出一大堆页面，而且看起来会很厉害。

我没有马上开工，而是让产品、运营、工程、设计和验收几个 Agent 先讨论，再让总工程师 Agent 做最后决策。

这轮讨论挺像一次小型需求评审。

产品 Agent 想把链路做完整；运营 Agent 一直追问数据从哪来；工程 Agent 提醒自动发布的稳定性和账号风险；验收 Agent 更直接------如果系统没有看到真实发布结果，凭什么显示"已发布"？

最后，第一版方案被砍掉了一大半。

这里不是五个 Agent 各写一份看起来都正确的建议就结束了。我让它们把冲突直接摆出来，再由总工程师 Agent 收口：产品想提高自动化程度，运营和验收坚持真实回执，工程则要控制首版复杂度。最后形成了一份很明确的决定：首版只做本地单人使用，坚持人工发布，所有指标从真实发布时间开始计算。

不自动发布，不自动点赞评论，不预测爆款，也不拿计划发布时间冒充实际发布时间。工具只负责把内容准备好、检查好、排好时间，真正发布仍然由我完成。

说实话，刚看到这个结论时，我还有点不爽。

我本来是想做一个"全自动运营助手"，怎么讨论完以后，自动化反而少了？

但用过几天后，我发现这恰恰是做得最对的一次取舍。

以前我用 Claude Code，通常是我想好了方案，它帮我实现。速度很快，但前提是我的方案本身没跑偏。

多 Agent 给我的提升不是"同时找几个人写代码"，而是在开工前就让不同角色互相挑刺。尤其是这种产品和业务边界混在一起的需求，一个 Agent 顺着写，很容易越写越兴奋；几个角色互相反驳，反而更接近真实开发。

工具首页最后只剩下一件事：告诉我下一步

最早的首页被我塞了不少东西。

数据看板、选题趋势、竞品入口、内容数量，几乎所有常见后台组件都想放上去。单独看每块都没问题，合在一起却有一种很熟悉的感觉：功能很多，但我打开后还是不知道今天先干什么。

后来我把要求改成了一句话：

我不想重新回忆上次做到哪里。每篇内容只告诉我现在能做的下一步。

Codex 沿着这句话重新检查了页面、内容状态和操作入口。

最后页面变得很简单。写新内容时只有一个输入框；已有内容则根据当前状态提示下一步，是继续修改、发布前检查，还是安排时间。

这张图没什么"AI 感"，甚至有点普通。

但它是我愿意第二天继续打开这个工具的原因。

我现在给 Codex 提需求，也越来越少写"这里放三个卡片，右边加一个按钮"。我更喜欢先说清楚完成标准，再让它自己去追代码和数据。

比如：

没有真实发布记录，任何页面都不能显示发布成功。

这种要求比一张页面草图更有用。因为它会影响的不只是按钮文案，还包括接口、数据模型、状态流转和测试。

Skills 不是插件收藏夹，而是让它别再犯同一种错

刚开始用 AI 编程时，我最常做的一件事就是重复提醒。

不要顺手重构。

不要拿空值补 0。

不要把构建通过说成页面已经验收。

不要在没有证据的时候编一个看起来合理的结果。

每次开新会话都得再讲一遍。漏讲一句，它就可能按"通常做法"帮我优化掉。

这也是 Skills 开始对我有价值的地方。

我理解的 Skill，不是下载以后放着看的功能说明，而是一份可以反复执行的工作规矩。像这次工具开发，我把最重要的边界固化了下来：

• AI 流式输出没有完整结束，只能保留临时草稿，不能保存成正式版本；
• 正文、图片或证据发生变化，之前的发布检查必须失效；
• 指标为 0 和指标没拿到，是两种完全不同的状态；
• 计划时间只能表示排期，不能自动生成真实发布时间；
• 页面没在浏览器里验收，就只能说代码和构建通过；
• 截图、账号、目录、业务编号等信息，交付前必须再做一次脱敏检查。

这些规则的价值，通常不是第一次开发时体现出来的。

真正省事的是第二次、第三次。换个任务，Codex 仍然知道应该先检查什么、做到哪里才能算完成。

Claude Code 当然也可以靠项目说明文件实现类似效果，但我以前的使用方式更偏临时会话：当前任务讲清楚，当前任务做完。到了 Codex 里，我更容易把这些规则独立成 Skill，让它们参与后面的每一次工作。

这种变化很难截图，却是我觉得最值钱的一部分。

MCP 让"帮我看看"变成真的打开页面看

如果只有 Agent 和 Skills，这套工具最后大概率还是会停在"代码写完了"。

MCP 补上的是最后一段：让 Codex 真正接触终端、浏览器、文档和其他工具。对我来说，最有感知的不是"支持多少 MCP"，而是我可以直接说"打开页面看看""把这个状态查清楚""修改后截张图给我"。

这次开发里，它不是只看代码猜页面效果，而是启动本地服务，打开真实页面，顺着内容入口、发布前检查、发布登记一路走下来。

有一次本地开发服务报写入失败，它没有直接把问题归到代码上，而是继续检查运行方式和环境限制，最后换成另一条构建路径完成验证。另一次页面显示发布稿失效，它也没有先改前端提示，而是沿着页面状态找到内容指纹变化。能把"电脑上现在到底发生了什么"纳入排查，是我觉得 Codex 相比以前最大的提升之一。

发布前检查页，我原本只准备放几个复选框。

实际打开页面后才发现，这里才是整套流程的中心：标题和封面有没有夸大，事实和数字能不能回到素材，图片和隐私有没有检查，整篇内容读起来像不像我本人，都要在这里确认。

有一个细节我很喜欢。

只要发布内容发生变化，系统就会要求重新检查。不是改个状态字段，而是根据当时的正文、图片和证据生成一份内容指纹。换一张图、改一个数字，原来的检查结果就不能继续用。

这个功能横跨数据库、服务层、页面和测试。如果只盯着某个文件改，很容易做成一个表面上的"已失效"。

Codex 在这里的优势，是它能围绕同一个任务继续往下做：先梳理状态，再改数据结构，补接口逻辑，最后把拒绝条件写进测试。

页面只是最后露出来的那一层。

底层没有上什么复杂架构，就是 Next.js、Prisma 和 SQLite。真正费时间的是把几个容易混淆的状态拆开。下面是简化后的门禁逻辑，不是为了展示代码多高级，而是防止页面自己把流程演完：

// AI 只生成了一半，先留在本机，不能进入正式内容版本
if (!generationComplete) return saveAsLocalDraft()

// 当前发布包和上次检查的内容已经不同，旧检查作废
if (review.packageHash !== currentPackageHash) return requireReviewAgain()

// 只有存在真实发布时间，才算已经发布
const published = publication?.publishedAt != null

// 没拿到数据就保持缺失，并记录原因；不能自动补成 0
const metric = value == null ? { value: null, missingReason } : { value }

这些判断最后都进了自动化测试。这样我第二天改页面时，不会因为一个看似无关的状态调整，把之前定好的运营边界悄悄绕过去。

我最满意的页面，反而是那个不肯说"成功"的页面

这套工具没有自动发布。

到了排期时间，页面只会提醒我该发布了。只有我在小红书里亲眼看到平台显示发布成功，才能回来登记。

如果没有作品链接，可以暂时不填，但要说明为什么拿不到。

如果还没取得点赞数据，就保持缺失，不能因为表格不好看而补一个 0。

后续 24 小时、3 天、7 天的数据窗口，也必须从实际发布时间开始计算，不能沿用原来的排期时间。

这一段实现起来不花哨，甚至显得有点死板。

但做内容运营最怕的就是系统自己把故事讲圆了：计划发布等于已经发布，没有数据等于数据为零，AI 生成等于人工确认。

我不需要一个总告诉我"已完成"的助手。

我更需要它在没完成的时候，敢把任务留在那里。

三件套真正怎么配合

做到这里以后，我对 Agent、Skills 和 MCP 的分工也越来越清楚。

Agent 适合处理"到底应该怎么做"。我会让产品、运营、工程和验收分别提出意见，再由一个主 Agent 收敛方案。它解决的是单个视角容易跑偏的问题。

Skills 适合处理"以后都必须这么做"。分支规范、敏感信息检查、测试边界、截图验收，这些不用每次重新解释，应该变成可重复执行的规则。

MCP 适合处理"别只给建议，去操作并拿结果回来"。打开浏览器、读取页面状态、运行测试、生成截图、整理文档，这些都要落到真实工具上。

三件套不是三个独立卖点。

更像一条流水线：

Agent 决定方向，Skills 守住习惯，MCP 把事情落地。

这次项目重新检查时，68 个自动化测试全部通过，ESLint 和 TypeScript 检查也通过。

tests 68
pass  68
fail  0

eslint       passed
tsc --noEmit passed

更重要的是，浏览器里的三个关键页面也真的打开检查过。这和"理论上应该能运行"还是有区别的。

Claude Code 现在被我放到了更适合它的位置

换到 Codex 后，我没有卸载 Claude Code。

它依然是一个很好用的终端搭档。需求边界清楚、需要快速改代码时，我还是会用。做大量公开网页采集时，我甚至会优先让 Claude Code 配合浏览器工具执行。

这次项目前期要整理一批公开内容，我现在的做法是：

Claude Code 负责按字段浏览、采集、保留来源，最后输出 JSONL 或 Markdown；Codex 负责先定数据结构和证据要求，拿到结果后再做导入、产品判断、代码实现和验收。

以前我会让两个工具重复研究同一批页面，额度花了不少，结果还很难对齐。

现在我更愿意把它们当成不同工种。

Claude Code 快，适合在明确边界里执行。

Codex 更像工作台，适合把需求、代码、浏览器、测试和交付物串成一个长任务。

如果只比生成一个函数，我不觉得差距有多夸张。真正拉开体验的，是任务做到后半程：要不要砍功能，状态能不能成立，页面有没有打开，测试是不是覆盖了失败情况，交付截图有没有泄露信息。

这些事以前大多在我脑子里。

现在至少有一部分，可以交给 Codex 三件套了。

写在最后

这个工具现在还是本地运行，只有我一个人用，也不会替我自动发布。

它不承诺爆款，不预测流量，甚至经常因为少一个真实数据，宁愿把流程卡住。

但它已经不是一个只能演示的 AI 文案页面。

我可以随手写下一段真实经历，沿着素材、成稿、检查、发布和复盘继续做下去。中间哪一步没发生，系统就停在哪一步。

从 Claude Code 转到 Codex 后，最大的变化不是我少写了多少代码。

是我第一次把 AI 从"终端里很会写代码的人"，变成了一套能讨论、能记规矩、还能真正动手验收的工作方式。

这套方式对我来说，就是 Agent、Skills、MCP 三件套。