多数人判断一个 AI 编程工具值不值，靠的是感觉。

这周用得顺手，就觉得它行；哪次把项目改崩了，又觉得它不行。至于它到底替你做完了多少件一直没做完的事，说不清。

mofei.life 的作者做了一件更笨也更靠谱的事：他让 Codex 去读自己的记录，把过去一个月的 git 历史、工具调用、PR、issue、worktree、部署日志全部翻出来，逐项统计。一个月，100 美元的订阅，5 个个人项目仓库。

结果比他预想的更有意思。

一个月的数据长什么样#

先把账摆出来：

指标数值
提交数461
新增行数290,314
删除行数244,371
代码变动总量534,685
工具调用39,056
子代理启动500
高层任务记录98
工作类别35

这组数字里最容易被误读的，是那 53 万行变动。作者自己先点破了：里面混着锁文件、SQL、迁移脚本、文档、生成内容、合并、删除和重构。把 534,685 行 churn 说成 534,685 行生产力，是句没有内容的空话。

这个自觉比数字本身重要。行数从来就不是产出。

钱花在哪：那些没人愿意做的碎活#

461 次提交里，mofei-life 一个仓库占了 396 次，其中 108 次是合并提交。68 次合并提交带着 Codex 的分支或 PR 痕迹，对应大约 111 个去重后的分支提交。

扣掉合并，还剩 288 次非合并提交。它们没有堆在一个大功能上，而是散在一堆麻烦的小地方：网站、后台、SEO/AEO、隐私政策、评论、可视化故事、部署回归、内容清理。

这些活的共同点是单件价值不大，攒着不做就会发烂。Search Console 报了个 canonical 问题要看，旧 URL 要处理，软 404 要排查，中间件、sitemap、robots 得一一对比，cookie 同意凭证要写进 D1，PR 要看，测试要跑，Cloudflare 的检查要等，生产环境的冒烟测试还得确认。

一个人面对这份清单，通常的反应是先把标签页关掉。交给 agent 之后，作者的说法是：把问题先丢给 Codex，让它读代码、找上下文、把能跑的先跑一遍。等他回来，至少不再是白纸一张。

80% 的提交发生在周末和早晚#

461 次提交里，有 369 次发生在周末、清晨或深夜，接近八成。

这个分布挺说明问题。它的意思不是「AI 帮我加班」，而更像是：这些活在白天永远排不上号，因为白天有更需要人在场的事。agent 的价值不在它快，而在它能接住那些你一直排不进日程的活儿。

39,056 次工具调用长什么样#

作者翻出的工具调用记录，画风是这样的：先用 rg 找线索，再用 sed、nl、cat 读上下文，然后 git diff、git status、git show 看改动，跑 pnpm test，用 gh 查 PR、更新 issue、等检查，必要时上 wrangler 查 Cloudflare、跑 D1、验生产环境。

它看起来更像一个非常勤恳的人在终端里干活。

这是作者的原话。它之所以值得单独拎出来，是因为这解释了 agent 为什么会烧掉几万次工具调用：它不是在「生成代码」，它是在做工程。找线索、读上下文、验证改动，这些步骤在人的工作里本来就占了大部分时间，agent 只是把它们的边际成本压低了。

然后他开始给它写规矩#

用了一个月，作者的注意力从「让 AI 写代码」转到了「管理 AI 怎么干活」。

AGENTS.md 被他当成正式文件维护：哪些命令不能乱跑，什么时候必须先开分支，什么时候必须跑测试，PR 描述怎么写，哪些目录不许碰，什么时候该停下来问他。

UI 是最典型的例子。起初每次都要重新解释「我的 UI 该长什么样」，效果忽好忽坏。后来他写了 design.md，把颜色、间距、层级、按钮、卡片、页面结构的规则写清楚，让 AI 动手前先读一遍。再往后，他把 UI 抽成真正的组件库，AI 就不必每次从零理解，而是在既有组件和约束里工作。

再往后，Codex 把这条线一路推到了独立仓库、npm 发布、dev dist-tag、生产发布、Trusted Publishing、README、docs/API.md，以及消费者端的回归测试。

作者特别强调，这里最值钱的不是「发到 npm 了」，而是补上了那些让事情以后不容易坏的机制。举例来说，共享 UI 在本地 workspace 里看着没问题，一旦作为 npm 包发出去，消费项目未必生成同样的 Tailwind 类。于是 Codex 加了 fallback 测试，盯着 footer、导航、AI 聊天浮窗这些关键布局在消费环境里别出问题。

他还让 Codex 整理个人知识库：扫一个目录，按现有内容分组，重新命名，最后把改动列给他看。按他的说法，这不算编程，但这类没人愿意干的收尾工作，agent 确实很擅长。

手写的代码确实少了#

到这里可以说句实话：这个月，作者亲手写的代码变少了。

腾出来的时间去了哪？读 diff、读测试结果、读 PR 描述，判断 Codex 有没有误解他、有没有碰不该碰的文件、有没有把环境问题当成代码问题。

他写了一句挺扎人的对比：

我自己写代码，出错通常是我的错。读 Codex 写的代码，我得先判断它到底有没有听懂我。

这是 agent 时代最容易被低估的一笔成本。审查别人写的代码，比审查自己写的更费脑子，因为你不掌握它的推理路径。作者的应对方式是不断把工作往前端挪：把任务边界说清楚，把不许碰的地方写死，把「什么算完成」定义好，然后再让它动手。

那 100 美元买到的是什么#

如果只用来补全代码，这笔钱不值。

但如果手上堆着一批个人项目、工具、博客、文档、发布流程和文件系统，一直等着有人把它们往前挪一挪，那买到的就是另一种东西。它不会替你想出宏大方向，它更像一台推力装置：把东西一路推到你能检查的位置。

作者自己给的结论是：

我付了 100 美元，最后意识到我买的不是编程助手，我在慢慢训练一套属于我自己的工程系统。它取代不了程序员，但它能把程序员从一部分执行细节里推出去。前提是你得会管它。

「会管它」不是指会写提示词，而是指把工程约束、验收标准、边界和流程沉淀成文件，让 agent 有东西可依。他这一个月里做的 AGENTS.md、design.md、组件化、fallback 测试，本质上是同一件事：把脑子里的隐性规则变成显式的、可复用的约束。

先做完这件事，agent 的效率才有意义。不做，你只是在碰运气。

一个附带收获#

有个细节比数据本身更值得学：作者是让 Codex 自己去读日志，才统计出这些数字的。

这把审计的成本压到了接近零。以前你想知道自己一个月到底干了什么，得靠翻 git log 加记忆拼凑。现在可以直接问 agent：把这一个月的提交、工具调用、PR、部署记录翻一遍，按类别给我统计。

对个人开发者来说，这是个便宜且值得养成的习惯。数字不会告诉你该做什么，但它能告诉你时间和钱到底花到了哪里。而这件事，大部分人从来没真正量过。

参考来源：Mofei，Codex at $100/Month: How I Used It as a Software Engineer Over the Past Month