Codex 100 美刀订阅体验：作为程序员，这一个月我是怎么用它的？

我居然真的把 Codex 升级到了 100 美刀一个月。

这件事放在几个月前，我自己应该也不会信。

我以前对个人工具订阅还挺开放：20 美刀一个月，我可以理解。它帮我少查一点文档，少写一点样板代码，在我卡住的时候推我一把，这个钱还算正常。

但是 100 美刀一个月就不一样了。

这已经不是“买一个顺手的工具”了。

它贵到我必须认真问自己：这个东西到底替我做了什么？为什么值这 100 美刀？

所以我做了一件很符合程序员习惯的事。

我让 Codex 和我一起翻过去一个月的记录。

git history、工具调用、PR、issue、worktree、deploy、D1、npm，全翻了一遍。

翻完以后，我第一反应是：这东西好像真的没那么简单。

1 个月
5 个个人项目 repo
461 个 commits
仅 mofei-life（我的博客）就有约 111 个 commits 可直接归到 Codex PR 工作流
290,314 行新增代码
244,371 行删除代码
534,685 行代码 churn
39,056 次工具调用
500 次 subagent 启动
98 个高层任务记录
35 类工作主题

这些数字当然不能直接说明“AI 帮我写了多少有用的代码”。

这里面有 lockfile，有 SQL，有迁移，有文档，有生成内容，有 merge，有删除，也有重构。把 53 万行 churn 说成 53 万行生产力，太虚了。

但这些数字还是让我停了一下。

因为它说明这个月 Codex 不是只在某个文件里补几行代码。它一直混在我的真实项目里，跟着我做开发、重构、迁移、文档、发布、验证、归档。

这和我一开始想象里的 AI 写代码不太一样。

我原来以为它主要是在那里大段大段生成代码。

结果日志里最多的东西，是翻文件、找上下文、看 diff、跑命令。

一个博客为什么会被我搞成这样

这一个月，commit 主要集中在几个个人项目里：

mofei-life          396 commits
mofei-dev-tools      30 commits
mofei-life-ui        20 commits
mofei-skills          9 commits
weird-skills-lab      7 commits

最大的还是我的博客本体 mofei-life。

它名义上是我的个人博客，但早就不只是一个放文章的地方了。现在里面有 web、admin、api、workers、D1、Cloudflare、评论、订阅、图片、搜索，还有一堆历史迁移。

有时候我自己看这个 repo 都会想：一个博客为什么会被我搞成这样。然后下一秒继续往里面加东西。

这个 repo 一个月里有 396 个 commits，其中 108 个是 merge commits。能看出 Codex 分支或者 PR 痕迹的 merge 有 68 个，对应大约 111 个去重后的实际分支提交。

GitHub commit history / PR list - Codex 很努力的提交各种 PR

去掉 merge 以后，还有 288 个非 merge commits。它们不是集中在某一个大功能上，而是散在一堆很烦的小地方：网站、后台、SEO/AEO、隐私、评论、视觉故事、部署回归、内容整理。

这些活单独拿出来都不像什么大项目，但它们会吃时间。

比如 Search Console 报 canonical，要查；旧 URL 要处理；soft 404 要看；middleware、sitemap、robots 都要对一下；cookie consent receipt 要进 D1；PR 要 review；测试要跑；Cloudflare check 要等；线上 smoke 还要确认。

这些事情不难。

真的，不难。

但你要一件一件做完。

我以前也不是不会做。

很多时候只是打开电脑，看一下 issue，看一下报错，看一下 GitHub 里那些没关的 tab，然后心里说一句：算了，下次吧。

有时候不是不想做。

就是那点时间刚好不够我进入状态。

现在有些事情会不太一样。

我把问题先丢给 Codex，让它去翻代码、找上下文、跑一遍能跑的东西。等我回来看的时候，至少已经不是一张白纸了。

可能只是一个小 diff。

可能是一个失败的测试结果。

也可能是一个 PR，或者一次 migration。

都不是什么大事。

但它们真的会留在项目里。

这点对我很重要。

那些早上和晚上留下来的东西

我后来又看了一下时间分布。

461 个 commits 里，有 369 个发生在周末、早晨或者晚上。大概 80%。

08:00   59 commits
22:00   40 commits
21:00   37 commits
07:00   32 commits
09:00   32 commits
20:00   24 commits
23:00   24 commits

这个分布我一看就觉得很像我。

早上起来一点时间。

晚上孩子睡了以后一点时间。

周末如果运气好，会有一整块时间。

以前这些时间也在，但经常碎得很尴尬。

你说它完全不能干活吧，也不是。

但它经常刚好不够我把一个问题从头看到尾。

现在这些碎时间更容易变成实际东西。

有时候只是一个 commit。

有时候是把一个拖了很久的 issue 关掉。

有时候只是让 Codex 先查，查完告诉我：这个不是代码问题，是环境或者配置问题。

这比“AI 写代码很快”更接近我真实感受到的价值。

它在 terminal 里像个很勤快的人

最让我意外的是工具调用。

这个月 Codex 的工具调用很夸张：

tool calls:     39,056
终端命令:        33,253
subagent 启动:    500
wait agent:      410
close agent:     252

最常出现的命令模式是：

sed        13,351
git         6,425
rg          4,694
pnpm        2,884
gh          1,696
wrangler    1,413
node          739
curl          225

这组数据我看了挺久。

因为它看起来不像“AI 在写代码”。

它更像一个人在 terminal 里很勤快地干活。

先 rg 找线索。

再 sed、nl、cat 读上下文。

然后 git diff、git status、git show 看改动。

接着跑 pnpm test。

再用 gh 查 PR、改 issue、等 check。

需要的时候用 wrangler 查 Cloudflare、跑 D1、验证线上（对，我是 Cloudflare 的无脑粉丝）。

Codex 可以去查看我的Staging的数据，以协助自己的其他任务

我以前问 AI，经常是：“帮我写这个函数。”

现在更常说的是：“你把这个问题处理完，验证以后告诉我。”

写函数当然也有用。

但说实话，我现在更缺的是后面那种。

4 月 26 日那天有点离谱

这个月最夸张的一天是 2026-04-26。

那天有 124 个 commits。

光看数字会觉得离谱。但回头看那天发生的事情，它不是一直在写新功能。

那天 Codex 在 mofei-life 里处理了很多工程杂活：

milestone
issue
PR linkage
Project v2 字段
postdeploy workflow
smoke test
merge
tag
review
conflict resolution

这些事情以前很容易变成 GitHub 里一堆半开的 tab。

我知道它们应该处理。

但它们不总是有一个清楚的“现在就做完”的动力。

Codex 很适合这种活。它可以一条一条查，一条一条改，一条一条验证，然后把状态更新回 GitHub。

那天给我的感觉很明显。

一个人做个人项目，最累的很多时候不是想法，也不是代码。

是那些没人替你收尾的工程杂活。

我开始写规则给它看

这个月还有一个变化，是我以前不会想到的。

我开始认真维护 AGENTS.md。

以前我管理项目，主要是管代码本身：目录怎么分、接口怎么设计、测试怎么跑。

现在我还要管理“AI 应该怎么工作”。

哪些命令不能乱跑，什么时候必须先开 branch，什么时候必须跑测试，PR 描述怎么写，哪些目录不能碰，什么情况下要停下来问我。

这些都得写进去。

这件事很奇怪。

我原来以为自己是在维护一个博客。

后来发现，我还在维护一个会干活、但需要被约束的工程助手。

UI 这条线最能说明问题

UI 是这个月最能代表变化的一条线。

最早我用 AI 做 UI，方式很直接。

“这个颜色不太对，帮我调一下。”

“这个页面不好看，帮我优化一下。”

结果当然能变好一点。

但不稳定。

有时候它会调对，有时候它会突然换一种风格。有时候一个页面看着还行，另一个页面又跑偏。

后来我开始使用 design.md。

把颜色、间距、层级、按钮、卡片、页面结构这些规则写下来，让 AI 每次做 UI 之前先读。

这一步之后，效果稳定了很多。

至少它不会每次都像从零开始发挥。

但 design.md 也有问题。

它能控制方向，却很难控制细节。

AI 知道“应该简洁”，但具体到一个按钮的 hover、一个 sidebar 的折叠状态、一个 footer 在不同项目里的布局一致性，还是容易飘。

直到我把 UI 提取成真正的 component，才开始稳定。

这样我就不用每次都让 AI 重新理解“我的 UI 应该长什么样”。它可以直接在已有组件和约束里工作。

Codex 最后把这条线推成了独立 repo、npm publish、dev dist-tag、production release、Trusted Publishing、README、docs/API.md、consumer fallback tests，还有 web/admin 的消费者迁移。

Codex 甚至帮我管理我的UI的NPM包，看里面Codex甚至知道dev tag和latest tag

这里最有价值的倒不是“发到了 npm”。

最有价值的是，它补上了一些以后不容易坏的机制。

比如 shared UI 在本地 workspace 里看起来正常，但发布成 npm 包以后，消费者项目不一定生成同样的 Tailwind class。Codex 后来补了 fallback tests，确保 footer、nav、AI chat dock 这些关键布局在消费者环境里也不会崩。

这个让我体会到，AI 做 UI 不能只靠一句“好看一点”。

你得把一些原来只存在于感觉里的东西，写成它能执行的规则。

比如哪个地方不能乱动，组件之间怎么复用，什么状态必须保留，发布出去以后消费者项目还会不会崩。

如果有机会，我应该会单独写一篇，聊聊我是怎么从“让 AI 调颜色”，慢慢走到“用 AI 管理一套 UI 系统”的。

后来它连我的文件也开始整理

这个月还有一些事情，放在技术文章里看起来有点怪。

比如我让 Codex 整理过个人知识库，也让它帮我重新归档一些长期堆在一起的资料。

这种活以前我也会拖。

文件名不统一，目录放得随手，东西混在一起。每次想整理，都觉得先算了，反正也还能找到。

但它很适合干这种事。

它不会嫌烦。

让它先扫一遍目录，按现有内容分组，补一些更清楚的名字，再把改动列出来给我看。

这不算写代码。

但它和写代码又很像。

本质上都是把一堆乱东西变得稍微有秩序一点。

我真的越来越少手写代码了

这句话写出来，我自己也觉得有点突然。

但这段时间，我确实越来越少手写代码。

不是说我不看代码。

我看得更多了。

只是看的方式变了。

我现在更多是在看 diff、看测试结果、看 PR 描述，看它有没有理解错我的意思，有没有顺手改了不该改的文件，有没有把环境问题当成代码问题。

以前问题来了，我就进去写。

前端、后端、脚本、bug、部署，能修就修。

说难听一点，就是 IT 民工。

现在有时候我会有一种很奇怪的感觉：我像从 IT 民工，变成了 IT 包工头。

这个说法不太好听，但很贴切。

我不是真的变高级了，也不是不写代码了。

只是很多时候，我先要说清楚这件事要做到什么程度，哪些地方不能碰，跑哪些检查才算结束。

然后让 Codex 去干。

它干完以后，我再回来挑毛病。

这个过程没有想象中轻松。

有时候我看它的 diff，比自己写还累。

因为自己写的时候，错误一般是自己的；看它写的时候，你要先判断它到底有没有理解你。

我现在花在“这段代码该不该存在”上的时间，明显比以前多。

这可能才是最奇怪的地方。

代码好像不是我一行一行敲出来的了。

但我要为它负责。

所以这 100 美刀到底值在哪

如果只是买代码补全，不值。

至少对我不值。

但如果你像我一样，有一堆长期没人推进的个人项目、工具、博客、文档、发布流程和资料系统，它买到的东西就不太一样了。

它不是替你想一个宏大的方向。

它更像是把事情往前推到一个能检查的地方。

一个 commit。

一个 PR。

一个测试结果。

一个 D1 migration。

一个 npm version。

一个 README。

一个 smoke check。

一个整理好的目录。

这些东西听起来都不怎么厉害，但它们会留在项目里。

这个月我最后记住的不是“AI 写代码很快”。

而是我花 100 美刀买了一个东西，最后发现自己不是在买一个代码助手。

我是在慢慢训练一套个人工程系统。

它不能替代程序员。

但它会把程序员从一部分执行细节里往外推一点。

前提是，你得知道怎么管理它。

当然，也有点贵！