我最近把开发主力从 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 三件套。
