我是如何用 Codex 把个人博客彻底改头换面
这次整理个人博客，我没有把它当成一次简单的页面美化。
一开始只是想做一点小小的更新。后来做着做着，我发现这件事很适合用来测试 Codex 的工作边界：它能不能理解一个已有项目，能不能在反复变化的需求里保持方向，能不能把内容、设计、代码、验证和部署串起来，而不是只回答几个孤立问题。
这轮更新被我拆成了几条线同时推进：站点设计、文章整理、交互修复、路由验证、GitHub 和 Cloudflare 发布链路，还有后续可复用的工作流 Skill 沉淀。
如果只看结果，它仅仅只是一个基于 VuePress 的个人博客网页。如果看过程，它更像一次小型的 AI assisted engineering 实验。
先让 Codex 读懂项目，而不是直接改页面
我不太喜欢一上来就让 AI “重新设计一下”。这种指令通常会得到一个看起来完整、但和项目本身关系不大的结果。
所以第一步是让 Codex 先读我原有的代码。
这个博客用的是 VuePress 和 vuepress-theme-hope。实际项目目录在：
.\vuepress-theme-hope\my-docs我主要修改的文件：
src/.vuepress/config.ts
src/.vuepress/theme.ts
src/.vuepress/navbar.ts
src/.vuepress/client.ts
src/.vuepress/layouts/Blog.vue
src/.vuepress/styles/index.scss
src/posts/*.mdCodex 需要先分清哪些页面是我自己写的，哪些页面是主题自动生成的。比如首页可以在 Blog.vue 里自定义，但 /article/、/category/、/tag/、/timeline/ 很多内容来自 Hope 的 blog 插件。这个边界如果弄错，后面会一直返工。
如果没弄清楚这点，很容易去改 .temp 目录里的生成文件。那种改法当下可能有效，下一次构建就会被覆盖。
我让 Codex 做的第一件事，其实是确认项目结构和路由生成方式。后面所有改动都建立在这个基础上。
反复修改的设计需求
页面设计经历了好几轮。
第一轮，Codex 试图把站点做成很强概念感的“数字档案馆”。视觉上有记忆点，但我很快否掉了。这个博客还是个人博客，不需要套一个过重的叙事，不需要一个全是 AI 味道的网页。
第二轮，我给了一个参考站点。Codex 借用了它的个人主页结构，包括大号介绍、文章区域、分类入口、profile 卡片和留白节奏。这个方向比第一版接近，但新的问题又出现了：它有点像参考站的外壳。
于是后面几轮不是继续加东西，而是删东西。
我和 Codex 一起删掉了这些内容：
- 不真实的照片墙。
- 重复的阅读入口。
- 没有实际意义的英文区块标题。
example.com这种假链接。- 过重的多列页脚。
- 只为了装饰存在的标签。
- 和主题组件行为不一致的自定义 profile。
这里 Codex 的价值不是“审美比我好”。更有用的是它能把页面当成产品来审：这个入口有没有用，用户点了会去哪里，这个模块是不是只是为了好看，和其他页面的交互是否一致。
比如首页右侧 profile 卡片，一开始我让它做成和时间线页面右侧类似的样式。Codex 先手写了一套，表面上差不多，但字体、描述、底部 icon 都不一致。后来我明确要求直接复用时间线的相同组件，它才改成 vuepress-theme-hope/blog 里的 InfoPanel。
这个修改看起来小，其实是一次正确的工程判断：能复用主题原生组件，就不要维护一套长得相似但行为不同的组件。
Skill 不是装饰，它改变了任务的执行方式
这轮我用了几个不同的 skill。用下来以后，我觉得 skill 的意义不是“多一个工具”，而是让 Codex 在特定任务里进入固定工作模式。
做页面时，我用 frontend-design 、 ui-ux-pro-max 以及 design-taste-frontend。
frontend-design 更适合处理具体页面，比如字号、色调、布局、按钮状态、响应式细节。ui-ux-pro-max 更适合从产品角度看信息架构。比如首页哪些区块多余，导航为什么不应该把分类放成顶层入口，profile 点击行为为什么要和 timeline 页面保持一致，最后用design-taste-frontend杜绝平庸与套路化设计，交付绝无“ AI 模板感”的界面。
写文章时，我用 humanizer。
这个 skill 对我最大的帮助不是把句子润色得更漂亮，而是把 AI 味去掉。它会提醒我删掉很多看似高级但没信息量的表达。那些词放在博客里会很虚。
查热点时，可以用 last30days。不过这类工具我不会直接把结果写进博客，因为社交平台和网页检索容易有覆盖不足的问题。更稳的用法是拿它做方向判断，再回到自己的经历里写。
在logo的设计以及生成每篇文章的封面图时，利用了Codex自带生图能力超强的 image-gen。
Bug 修复
这次最典型的 bug 有几类。
第一类是构建问题。Windows PowerShell 里直接跑 npm 容易被执行策略拦住，所以在这个项目里统一用：
npm.cmd run docs:build
npm.cmd run docs:verify后来 VuePress 生成 .temp 时也多次遇到 EPERM。这个错误不是 Vue 模板写错，也不是 Sass 语法问题，而是 Windows 下临时文件写入被拦住。解决方式不是乱改代码，而是先判断失败层级，再用同一条命令重跑验证。
第二类是路由问题。分类改成英文后，按钮显示是 Work / Life / Tech，但 VuePress 实际生成的路由是小写：
/category/work/
/category/life/
/category/tech/一开始按钮链接写成 /category/Work/，点击就会 404。
第三类是主题组件误用。首页 profile 最初手写了一个类似时间线右侧 profile 的卡片，但字体、描述、底部 icon 都不一致。后来才改成直接引用 vuepress-theme-hope 的 InfoPanel。这比手写一个“差不多”的组件更稳，也减少了后续维护成本。
第四类是交互一致性。首页、分类、标签、时间线页面右侧 profile 里的 Articles / Categories / Tags / Timeline 一开始行为不一致，有的跳转，有的展开。后来把点击拦截放到 client.ts 里，通过 .vp-blog-count 找到同一个 profile 里的 .vp-blog-type-button，复用主题原生的切换器。
这些 bug 的处理方式其实很一致：先找真实来源，再做最小修改，再把验证补上。
文章审阅
这篇文章不是我直接丢一句“帮我写一篇博客”给 Codex 得到的。
我先做的是拆任务。文章要写 Codex，但不能写成工具测评；要讲博客更新过程，但不能变成流水账。我希望它写清楚一件事：我是怎么把 Codex 放进一个真实项目里，让它读上下文、改文件、跑验证、再根据反馈继续调整。
所以我给它的要求不是“润色一下”，而是一步一步收敛：
先回看这次博客更新的对话和代码改动。
把文章主线定成“我如何组织 Codex 完成一次项目更新”。
每一段都要能落到具体动作：读文件、改页面、用 skill、修 bug、跑验证、梳理部署。
删掉像宣传稿的句子。
删掉像工具说明书的段落。
保留我如何提要求、如何纠偏、如何验收的过程。这个过程里，Codex 的第一版并不合格。它会本能地把文章写得很完整，把背景、过程、结果都交代清楚，但问题是太像一篇通用经验总结。句子顺，结构也完整，可读完以后看不出我具体是怎么使用 Codex 的。于是我要求它重写，把抽象描述撤掉，把操作过程放到前面。
后面我又继续调整角度。文章不能只说“我用了 Codex”，而要写清楚我是怎么用的。我会把原文片段直接贴进去，再用标签把任务拆开，比如 <article> 放当前稿子，<background> 放项目背景，<rewrite_goal> 写这次要改的方向，<avoid> 写不能出现的表达。这样 Codex 不需要猜我在说哪一段，也不容易把上下文混在一起。
审稿时，我不会只让它“检查一下”。我会明确让它 role play 成两个角色：一个是资深工程师，专门看文章里有没有错误的表述、命令、错误和修改理由；另一个是 AI 内容审稿人，专门挑哪些句子像套话、像工具说明书。
我还会用一种简单的 loop 让它反复审阅：先改一版，再按同样的两个角色继续检查；如果还有问题，就继续改，直到这一轮审阅没有新的明显问题为止。这个循环不是为了把文字磨得更漂亮，而是为了逼它不断回到证据、上下文和具体操作上。
这一节后来能成型，靠的也不是 Codex 一次写对。前面我会先描述背景，告诉它这篇文章来自一次真实的博客更新过程；再让它去查我们之前的对话、代码改动和验证记录，从里面找能支撑文章的素材。如果它找不到证据，或者某个细节缺上下文，我会要求它停下来问我，而不是自己补一个看似合理的解释。
对我来说，这才是使用 Codex 的重点。不是让它替我表达，而是先给它计划、背景、边界和审阅规则，再让它在这些约束里工作。该找证据的时候找证据，该删空话的时候删空话，该补细节的时候补细节。最后留下来的，才像一篇能被别人读懂的复盘。
MCP 串起编译、部署和公网验证
这次用 Codex，我对 MCP 和 connector 的感受更直接了。
以前我理解 MCP，容易把它看成“多接了几个工具”。这次做博客更新以后，我对它的理解更具体：MCP 的价值不是某一个按钮，而是把外部系统变成 Codex 能读取、能操作、能验证的上下文。
在这条发布链路里，Codex 不是只靠我复制粘贴信息来判断。它可以通过不同入口拿到不同层面的状态：
本地文件入口：读 VuePress 配置、文章 frontmatter、封面资源、构建脚本。
Shell 入口：执行 build、verify、git status，拿到真实命令输出。
GitHub connector：检查仓库改动、提交范围、远端发布前后的代码状态。
Cloudflare connector：对应 Pages 项目、构建命令、输出目录、部署状态、域名配置。
Browser connector：打开公网地址，按真实访问路径检查首页和文章路由。这就是 MCP 在这里的作用。它把“我告诉 Codex 结果”变成“Codex 自己去看结果”。差别很大。
比如编译阶段，Codex 先读 package.json，确认构建命令不是凭空猜的，而是项目里真实存在的脚本。这个项目里本地构建命令是：
npm.cmd run docs:build构建结束后，它不会只看“success”两个字，还会继续跑：
npm.cmd run docs:verify这个验证脚本会检查 VuePress 生成的路由，确认首页、文章、分类、标签、时间线这些页面都能返回 HTML。这里用到的是本地命令和项目文件上下文，不需要我口头判断“应该没问题”。
到了部署阶段，MCP/connector 的作用换了一层。GitHub 负责源码状态，Cloudflare Pages 负责从仓库拉代码并构建。Codex 要确认这两个系统之间有没有对齐：
GitHub 里有哪些新增、删除和修改。
Cloudflare Pages 连接的是不是同一个仓库。
Cloudflare 使用的构建命令是不是和本地一致。
Cloudflare 的输出目录是不是 VuePress 的静态产物目录。
部署完成后，公网路由是否真的能访问。VuePress 的构建产物目录是：
src/.vuepress/dist这个目录如果在 Cloudflare 里填错，构建可能成功，但上线结果仍然是空页面或 404。以前这种问题很容易靠人工来回切页面排查；现在我会让 Codex 把它写成检查项：本地构建产物是什么，Cloudflare 读取的目录是什么，线上访问到的页面是不是同一份产物。
最后一步是公网验证。这里浏览器 connector 的意义很直接：不要只相信部署状态，要打开真实地址。首页能访问以后，再点文章页、分类页、标签页和时间线。因为静态站最常见的问题不是首页挂掉，而是二级路由、资源路径或重定向规则出问题。
所以这条链路里，MCP 不是一个被单独展示的功能点。它更像胶水：本地文件、Shell、GitHub、Cloudflare、浏览器都通过不同 connector 进入 Codex 的工作上下文。Codex 才能从“改完代码”继续往后走到“构建通过、部署配置正确、公网可以访问”。
沉淀成自己的 skill
做完这一轮以后，我发现值得保留下来的不是某一次页面改动，而是这一套做事方式。
以后我还会继续改页面、整理复盘、部署站点。如果每次都重新告诉 Codex 一遍“先确认上下文、不要编造、跑构建、保护路由、注意隐私”，成本太高，也容易漏。
所以这件事还应该再往前走一步：把这套流程创建成自己的 skill。
这个 skill 不是写“替我完成所有内容”。它应该更像一个工作协议：
读取真实上下文。
先判断能不能公开。
公开表达要克制，避免把过程写成自我说明。
技术判断要经得起追问。
文风不能像工具生成稿。
页面修改要保护路由。
构建要跑 docs:build。
路由要跑 docs:verify。
涉及部署要拆 GitHub 和 Cloudflare 链路。
无法验证的事情必须说清楚。它不会替我自动完成所有事情，但它能让 Codex 每次进入同一套工作习惯。
对我来说，这比单次生成一篇文章更有价值。
写在后面
这轮更新让我对 Codex 的使用方式有了一个更清楚的判断。
如果只把它当成问答工具，它能提供很多建议。把它放进真实项目里，让它读代码、改文件、跑命令、查错误、审文章、接部署链路，它才开始像一个能参与交付的人。
它也会犯错。它会把设计做得过度，会把文章写成说明书，会手写一个本该复用的组件，会在文章里放一些听起来正确但没有现场感的句子。
这些问题不能靠一次提示解决，只能靠持续校正。
我现在更愿意把 Codex 当成一个需要被管理的工程协作者。给它上下文，给它边界，让它产出证据，再把有用的过程沉淀成 skill。这样用下来，它帮我改了博客，也让我重新整理了一遍自己的工作方法。