最近又认真用了几轮 Codex，感觉它已经不太像一个“帮你补几行代码”的工具，而更像一个能坐在项目旁边的协作搭子：会先翻目录、看约定、跑命令、改文件，最后还能把提交推上去。
这事有点微妙。以前折腾静态博客，常见流程是：自己想清楚、翻文档、复制配置、试错、构建、提交。现在变成了把问题讲清楚，让 Codex 先把仓库摸一遍，再让它按现有结构动手。中间我盯着它的操作，它负责把琐碎的步骤串起来。
比如这次重建 Pages CMS 配置，.pages.yml 已经坏成只剩 111。如果自己来，也就是查文档、看 Hugo 内容结构、对照 JSON 数据、写 YAML、构建验证。Codex 做这类活的好处不是“神奇”，而是它不会嫌烦：它可以一边读 content/posts 下的分类，一边看根页面的 front matter，再把 static/goods/goods.json 和 static/friends.json 这种结构化数据也纳入编辑范围。
现在我觉得好用的几个点
第一是能真正贴着仓库干活。不是只给一段建议，而是会看现有文件怎么写，尽量沿用原来的习惯。像这个博客的文章基本就是 title/date/tags/feature 加 Markdown 正文，它就应该继续保留这种写法，而不是突然发明一套“更标准”的内容模型。
第二是权限边界更明确。Codex 会区分读文件、改仓库、开本地服务、联网查文档、推送代码这些动作。需要越过沙盒时会停下来问一声，这点让我比较放心。工具越能干，越需要知道它什么时候该刹车。
第三是上下文可以沉淀。官方推荐用 AGENTS.md 写仓库规则，这很适合静态博客：比如“用中文回答”“文章放到哪个分类”“构建命令是什么”“不要提交生成目录”。这些小规矩一旦写进去，下次就不用重复念叨。
第四是它不只会写代码。对我这种博客型仓库来说，很多工作其实是半内容半工程：写文章、改配置、跑 Hugo、检查 JSON、推 Git。Codex 能把这些步骤放在同一条线上处理，体验比在几个工具之间来回切要顺。
但也别太放飞
我现在更愿意把 Codex 当成“会动手的编辑器”，不是全自动代驾。越是要改发布链路、数据结构、模板逻辑，越应该让它先解释改动范围，再跑构建验证。尤其是静态站，一处 front matter 或 YAML 缩进错了，页面可能就悄悄没了。
比较舒服的用法大概是这样：
- 先把目标说具体：要改什么、不要改什么、完成后怎么验证。
- 让它先读项目结构，不急着写。
- 小步改，小步看 diff。
- 本地构建通过后再提交。
- 生成文件、锁文件、缓存文件，别顺手推上去。
后话
工具进化到这个阶段，最值钱的反而不是“替你写”，而是“懂得在你的现场里写”。它要知道这是 Hugo，不是随便一个博客；知道我习惯把折腾类文章放在 content/posts/coding/；知道正文里可能有短代码、HTML、<!--more-->。
写代码如此，写博客也差不多。人负责意图、取舍和审美，Codex 负责把那些细密的小步骤稳稳接住。这样想想，倒不是偷懒，更像是给自己的折腾欲找了个不嫌麻烦的帮手。