我一开始想做的不是一个“博客模板”。
博客模板太容易了。找个主题，改个标题，塞几篇文章，半天就能上线。但那种东西很快会变成另一个没人维护的文件夹。真正难的是：我到底要长期写什么？哪些内容该放进来？以后新增文章时，怎么不把网站越写越乱？
这就是 Codex 第一个有用的地方。它不是先帮我写页面，而是先逼我把边界写下来。
现在这个网站叫“知行栈”，长期围绕两条主线：一条是大模型应用，一条是养生与站桩。公众号文章只是归档入口，不是第三条主线。这个判断看起来简单，但它决定了后面所有内容怎么进站。
如果没有这一步，网站很容易变成一个万能收纳箱。今天放 AI，明天放站桩，后天放读书笔记，再过几天放项目复盘。东西都在，但没有入口，也没有气质。
我是怎么一步步做的
这件事不是从写代码开始的。
第一步，我先把“我不要什么”说清楚。不要营销风，不要大面积色块，不要泛化 AI 视觉，不要把公众号文章做成第三条主线。这个排除清单后来进了 AGENTS.md，变成 Codex 每次修改前都要读的规则。
第二步，我让 Codex 把网站拆成内容问题，而不是页面问题。两条主线分别是什么？文章要有哪些字段？公众号文章怎么兼容？于是才有了 source、category、tags、originalUrl 这些字段。
第三步，才进入工程。它用 Astro 做静态站，用 src/content/articles/ 收 Markdown，用动态路由生成文章页、分类页和标签页。这里没有引入后端，也没有做复杂 CMS，因为我的真实需求就是“能长期写，能清楚归档”。
第四步，补入口。首页展示两条主线，/agent/ 收大模型应用和产品方法，/standing/ 收站桩，/wechat/ 只做公众号归档。每个入口都要能回答一个问题：下次有新文章时，它应该去哪。
第五步，跑检查和构建。这个动作看起来小，但很重要。个人网站最怕“写着写着坏了”，所以每次内容模型或路由变动，都要让 Codex 跑一遍 npm run check 和 npm run build。
所以它不是“帮我生成一个网站”。
更准确地说，是我先把长期维护规则说出来，Codex 再把这些规则编译成一个能运行的站。
Codex 在这里做的不是“生成网页”
它做了几件更基础的事。
第一件事，是把维护规则写成 AGENTS.md。比如新增文章优先归入两条主线之一，产品方法类内容归入大模型应用，站桩内容只写个人经验，不写成医疗建议。这样每次打开项目，Codex 都先读规则，不靠临时记忆。
第二件事，是把文章变成结构化内容。每篇文章都有 title、description、date、category、tags、source、originalUrl 和 draft。文章不是散落的 Markdown，而是可以被栏目页、分类页、标签页自动收起来的内容对象。
第三件事，是保持站点轻。整个网站用 Astro、TypeScript 和 Tailwind CSS 做静态构建，不依赖后端数据库。对一个个人知识主页来说，这个选择很舒服。写文章就是新增 Markdown，构建通过就能发布。
这类用法适合什么场景
如果只是做一次性页面，Codex 当然也能写代码。但我觉得更值得用的是这种场景：
你有一个会长期增长的东西，它需要规则，需要入口，需要未来的自己还能接得上。
个人网站就是这样。真正麻烦的不是第一页怎么好看，而是三个月后新增第 30 篇文章时，系统还没有散。Codex 的价值不在于替你“灵感爆发”，而在于把维护动作变成规约，把内容入口变成模型，把每次新增都放回同一个秩序里。
这个网站最后没有做成花哨的作品集。它是白底、克制、适合长期阅读的样子。墨绿色只用来做少量强调，图片只是区分主线，不制造营销感。
这也挺符合我现在对 Codex 的理解。
它不该只是一个会写代码的工具。用得好的时候，它更像一个有耐心的共同维护者：先读规则，再看结构，然后小步更新。
个人网站不是一次建成的。
它是被一次次维护出来的。