我是 Java 程序员，不会 PHP，却用 WordPress + Codex 在 2 天里做出了官网 SEO 自动化项目

因为官网不是核心业务系统，官网首先要解决的是获客、展示、内容承接和 SEO，而不是证明我会不会写底层框架。

很多程序员做官网，容易下意识把这件事看成“我该用什么技术栈来实现”。但从业务角度看，官网更像一个运营系统，不像一个要高并发、强事务、复杂领域建模的后台平台。这个时候，生态、交付速度、内容可维护性，往往比“是不是我最熟的语言”更重要。

我自己的官网 https://www.hm-sj.cn，定位就是围绕软件外包、兼职 CTO、AI 落地、数字化转型这些方向去承接内容和咨询。这个站点后面要长期发文章、做栏目、做 SEO、做案例、做服务页。如果这些能力都要我自己从零写，技术上当然不是做不了，但性价比太低。

所以我最后的判断很明确：

• 官网和 CMS 场景，WordPress 值得用。
• SEO 内容运营场景，WordPress 也值得用。
• 我不懂 PHP，不代表我不能把它用好。

真正要解决的，不是“我要不要会 PHP”，而是“我能不能把 WordPress 变成一套符合我自己业务和工作方式的系统”。

如果今天还是靠每天手工写文章、手工改标题、手工配图、手工发文、手工检查 SEO 结构，那这件事很快就会变成负担。

一开始很多人觉得，SEO 不就是持续发文章吗？但你真自己做过就知道，麻烦不在“写一篇”本身，而在后面的整条链路：

• 今天到底写什么；
• 这篇应该归哪个栏目；
• 标题、关键词、描述怎么配；
• 图片要不要做，怎么压缩；
• 发文前要不要检查 AI 味和模板腔；
• 已经发过什么，怎么避免重复；
• 老文章有没有结构问题，H1、分类、摘要、归档有没有坑；
• 以后能不能定时跑、批量跑、出错还能继续跑。

如果这些都靠手工，那不是做 SEO，那是在给自己制造第二份工作。

所以我后来给自己的要求就很明确：我不是要一个“会写文章”的小工具，我要的是一套能持续跑的内容运营系统。

这个项目目前放在本地仓库里，核心不是堆几个 prompt，而是把整个流程拆成了一条明确的流水线。大概两天时间，我先把一版能用的骨架和主流程做出来，后面再逐步补能力。

我现在这套项目，已经不是“生成一篇文章”这么简单，而是把这些事情串起来了：

• 站点规则配置化。把官网定位、栏目结构、SEO 规则、图片规则、质量红线统一收口到 site/hmsj。
• 内容流水线分阶段。按 topics -> brief -> outline -> draft -> polish -> seo -> image -> quality -> publish 往下走。
• 自动运营入口。支持 ops -> batch -> pipeline -> publish 这样的主链路。
• 内容记忆和去重。先同步已有文章，再决定接下来写什么，避免重复选题和重复表述。
• 日历和队列。不是想到什么写什么，而是先做排期，再形成可执行队列。
• SEO 打包和主题字段写回。文章 SEO 标题、关键词、描述，以及页面和分类归档 SEO 都能纳入处理范围。
• 图片计划和压缩。后面可以继续自动处理配图，不用每次手工折腾。
• 质量门禁。不是写完就发，而是先过质量检查，保留人工 review。
• 巡检和修复。包括老文章巡检、页面结构修复、计划任务和运营报表。

换句话说，这个项目已经开始具备“自动写文、做 SEO、做图、质检、发布、复盘”的基础能力了。现在还不是终点，但已经不是 demo，而是一套真能继续迭代的工程骨架。

很多人一说“我用 Codex 做出来的”，外行听起来像是跟 AI 随便聊几句，系统自己就长出来了。实际完全不是这样。

真正有效的做法，不是对 Codex 说一句“帮我做个自动发文系统”，而是像带一个很强但需要明确边界的工程同事一样，把问题拆开，一步一步让它落地。

我这次比较核心的做法，大概是这样：

1. 先讲目标，不先讲技术实现

我先告诉 Codex：这个项目不是通用博客工具，而是 https://www.hm-sj.cn 这个站点专用的内容操作系统。

这样它一开始就知道，目标不是炫技术，而是服务官网获客、内容运营和 SEO。

2. 先定规则中心，再写命令

我没有让它一开始就把逻辑散落在脚本里，而是先做站点规则层，把品牌定位、栏目结构、内容边界、SEO 规则、图片规则、质量规则、工作流全部收进配置里。

这样后面我如果要改栏目、改文风、改流程，不是到处翻代码，而是先改规则。

3. 不追求一步成稿，而是强制分阶段

这是程序员思维里很重要的一点。系统只要是一口气做到底，后面就很难查问题，也很难复用中间结果。所以我让它把流程拆成：

• topics
• brief
• outline
• draft
• polish
• seo
• image
• quality
• publish

每一步都留产物，每一步都能单独重跑，这样才像工程，不像运气。

4. 先做 dry-run，再接真 WordPress

这个顺序很重要。

很多人让 AI 接口一配好，就急着真发文章。这样一旦字段错了、分类错了、正文结构错了，线上很快就乱掉。我这边先让它本地生成中间产物，确认流程对了，再逐步接 WordPress API、接主题 SEO 字段、接分类归档 SEO。

5. 发现问题就补维护层，而不是硬撑主流程

这也是程序员和纯外行用 AI 的一个明显区别。纯外行一般只盯着“当前功能能不能跑通”，但程序员会知道，系统一旦开始长期用，维护层比主流程还重要。

所以我后面又继续补了这些东西：

• 内容记忆同步；
• 运营报表；
• 队列和批处理；
• 断点续跑；
• 老文章巡检；
• 页面 SEO 结构修复；
• Windows 定时任务。

这类东西写出来，不一定最炫，但它们决定了这套系统后面到底能不能持续用。

下面这几句，反而比“帮我做一个 XXX”更接近有效用法：

这是一个官网专用的 WordPress 内容自动化项目，不是通用博客工具。
请先把站点定位、栏目分类、SEO 规则、质量红线做成单独配置，不要散落在脚本里。

内容生成不要一步到位，请拆成 topics -> brief -> outline -> draft -> polish -> seo -> image -> quality -> publish。
每一步都要保留中间产物，支持失败后继续跑。

默认先 dry-run，不要直接发到 WordPress。
人工 review 通过之后，再进入 publish。

除了写文流程，还要补 memory、queue、batch、report、audit、schedule 这些能力，
因为我要的是一套长期运营系统，不是一次性脚本。

你会发现，真正关键的不是 prompt 多么花哨，而是你有没有把需求说清楚：

• • 目标是什么；

• • 边界是什么；

• • 目录结构怎么分；

• • 哪些东西必须配置化；

• • 哪些阶段必须可回放；

• • 哪些地方必须先人工确认。

说白了，AI 很强，但它最擅长的是执行和展开，不是替你做架构判断。

官网地址：https://www.hm-sj.cn

首页我已经实际截了一张图。从现在的站点看，首页已经把“软件开发与数字化转型解决方案”的定位、关于我们、特点介绍和精选案例放到了一个完整入口里。

核心服务页也已经是单独的结构页了，里面把西安 MVP 快速上线、西安小程序/官网/管理系统定制、旧系统重构、AI 落地、兼职 CTO 等服务做了拆分。

精选文章页和精选案例页也已经有内容在承接了，这也是我为什么一定要把后面的内容自动化和 SEO 流程补上。因为站点一旦开始长内容，靠手工就很快会被拖慢。

另外，这张图是我自己画的项目结构图。

很多人说 AI 会代替程序员。我现在的看法是：是，也不是。

说“是”，是因为 AI 确实在代替一部分程序员过去亲手敲代码、查资料、搭样板、写胶水逻辑的工作。这一点没必要自欺欺人，变化已经发生了。

但说“不是”，是因为真正决定项目能不能做成的那些东西，还没有被替代：

• 需求到底是不是合理；
• 架构怎么拆才不容易烂；
• 哪些地方该快，哪些地方该稳；
• 哪些规则必须提前钉死；
• 哪些功能现在先不要做；
• 哪些风险一开始就要防。

这些东西，外行很难天然具备。

一个完全不懂工程的人，确实也能让 AI 帮他“写出代码”。但问题在于，他往往不知道哪里是边界，哪里是耦合，哪里是短期能跑、长期会炸的地方。AI 默认会优先满足你眼前的功能，这没错，但如果前期架构搭得不好，代码很快就会长成一座屎山，而且越往后越难扩展。

所以我反而觉得，当下最适合吃到 AI 红利的一批人，恰恰是程序员。

因为程序员懂系统、懂抽象、懂依赖、懂边界、懂维护。只要再学会怎么正确跟 AI 协作，就能比过去快很多地跨进自己原本不熟的领域。

这次对我来说，最大的收获不是“我终于用 WordPress 做了一个官网”，也不是“我用 Codex 写了多少代码”，而是我更确定了一件事：

AI 真的非常适合程序员做跨界。

我不会 PHP，不影响我用 WordPress 做官网；我以前如果手工做 SEO，会被内容生产、发布、配图、维护拖住；但现在借助 Codex，我可以把这些事情逐步做成系统，而且不是做一个临时能跑的脚本，而是一套后面还能继续扩展、继续修、继续自动化的工程。

如果你也是程序员，我真心建议你不要把 AI 只当成“自动补全”或者“问答工具”。更好的方式是，把它当成一个执行力很强的工程搭子，但前提是你得负责目标、规则、结构和边界。