AI建站最近很火，奶爸也使用了一段时间的AI开发，本文给大家介绍下如何使用AI工具来开发自己的WordPress主题，需要提醒的是，对于普通用户来说，AI开发依然有难度，不保证你跟着本教程就可以完整的开发出你的WordPress主题。
之前奶爸分享过《AI建站真的比WordPress好吗？我用Claude、DeepSeek、Codex实测后的结论》，本文算是这篇文章的后续内容，使用AI开发WordPress主题，WordPress来管理网站文章和产品数据，实现AI和WordPress组合建站。
开发前准备
在开始前，你需要准备一个AI工具和一个WordPress环境，对于新手用户来说，如果你是刚开始建站，建议直接购买好域名和服务器后在服务器上开发，避开本地开发环境的一些bug。
AI工具
AI工具有很多，像Claude Code、Codex、Qoder、TRAE和CodeBuddy等。
考虑到大多数用户搞不定Codex和Claude的账号，奶爸本文以腾讯家的CodeBuddy为演示，其他AI开发工具的流程都是差不多的，可以按照类似思路操作。
不要想着用免费的AI工具来开发，浪费时间和精力，建议直接付费购买套餐。
WordPress开发环境
开发WordPress主题，你需要有一个WordPress网站用来测试主题效果，建议直接购买域名和服务器搭建真实环境来开发，不要在本地开发。新手本地开发时可能会碰到一些环境问题解决不了。
这里就建议大家购买VPS来开发主题，如果你是购买的SiteGround这种服务器，就只能自己手动上传测试了。
AI开发WordPress主题流程
1、在电脑上创建一个文件夹，用英文命名。
2、打开CodeBuddy，左上角，文件，打开，打开文件夹，选择刚才创建的文件夹。
右下角有模型切换，本文发布时Hy3模型免费，不过要干活效果好，还是建议选择GLM、Kimi或者DeepSeek，具体的你可以自己切换模型后安排任务感受，只要能完成你的任务，哪个模型都可以，默认是Auto，根据你任务自动选择模型。
3、把网站的一些基础建站资料保存到文件夹里面，奶爸直接创建的一个“Company Information”文件夹
4、在右下角聊天框输入下面的对话（你也可以自由发挥）
这是一个空白项目文件夹，我希望你协助我从零开发一个 WordPress 主题。
我不懂具体的 WordPress 主题开发技术，因此这个项目中请你承担主要的技术负责人角色：负责技术路线、主题架构、代码规范、安全性、兼容性、可维护性以及开发过程中的技术判断。
我的职责主要是确认网站前台的页面结构、视觉设计、内容展示方式和功能需求。
当前项目文件夹中有一个 `Company Information` 文件夹，里面保存了我们公司的相关资料。
## 当前阶段的任务
现在不要直接开始创建主题文件或编写正式代码。
请先完成以下工作：
1. 阅读 `Company Information` 文件夹中的全部资料。
2. 根据资料总结你对以下内容的理解：
* 公司主要业务
* 目标客户
* 核心产品或服务
* 网站主要目标
* 网站需要重点展示的信息
3. 基于这些资料，提出一个合理的网站页面结构和信息架构方案。
4. 将页面结构方案与我讨论并确认。
页面结构确认之前，不要进入具体页面设计，也不要开始主题开发。
## 后续流程
整个项目按照下面的顺序推进：
公司资料理解
→ 网站页面结构确认
→ 页面视觉风格与设计方案确认
→ WordPress 主题技术方案确认
→ 开始开发
→ 页面逐项实现和确认
→ 测试与完善
不要跳过前面的确认阶段直接进入后面的工作。
## 技术决策原则
因为我不熟悉 WordPress 主题开发技术，因此：
* 纯技术问题由你主动分析并给出你认为合适的方案。
* 不要把 PHP 架构、目录结构、WordPress API 使用方式、代码组织方式等纯技术问题简单反问给我决定。
* 如果存在多个技术方案，请说明主要差异，并给出你推荐的方案和理由。
* 涉及网站前台视觉、页面结构、用户体验、展示内容、业务功能的决定，需要先和我确认。
* 不要因为我不懂技术，就自行替我决定网站前台应该是什么样子。
开发时应优先遵循 WordPress 官方推荐方式和当前主流最佳实践，避免为了实现功能而使用不必要的复杂方案。
## 项目文档
由于项目会持续多轮讨论和开发，请你从项目开始就建立并持续维护项目文档。
建议至少维护一个项目核心文档，例如：
`PROJECT.md`
其中记录：
* 项目目标
* 公司和网站定位
* 已确认的网站页面结构
* 已确认的设计方向
* 重要功能需求
* 技术架构和关键技术决策
* 已完成的工作
* 当前开发进度
* 待处理事项
* 重要讨论结论
如果后续内容较多，可以自行拆分到 `docs/` 目录中，但需要保持结构清晰。
每当我们确认一个重要决定后，请同步更新项目文档，保证即使后续上下文丢失，也可以通过项目文档恢复项目状态。
## 当前请先做
现在请先阅读 `Company Information` 文件夹中的资料。
阅读完成后，先告诉我：
1. 你对公司和网站目标的理解。
2. 你建议的网站整体页面结构。
3. 每个主要页面承担什么作用。
先和我确认这些内容，不要开始写主题代码。
发送完毕后，CodeBuddy会跟你来回沟通，最终确认网站的结构。
5、多轮沟通确认好网站页面结构后，开始确认网页设计：
CodeBuddy习惯每次给你一些选项，因为我们有自己的提示词，所以这里跳过。
输入下面的提示词：
我们已经完成了公司资料分析和网站页面结构确认，现在进入网站视觉设计方案确认阶段。
请先读取并参考当前项目中的 `PROJECT.md` 以及已经确认的页面结构和讨论记录，确保你的设计建议与前面已经确定的内容一致。
当前阶段仍然不要开始正式编写 WordPress 主题代码，先和我把网站的整体视觉方向、主要页面布局和设计规则确认清楚。
## 你的任务
请根据已经确认的：
* 公司定位
* 目标客户
* 核心产品或服务
* 网站目标
* 页面结构
* 页面承担的业务作用
为网站提出合适的视觉设计方案。
我负责判断页面看起来是否符合预期，你负责把设计思路整理成可以后续真正落地开发的设计规则。
## 先确定整体设计方向
请先提出你推荐的网站整体设计方向，包括但不限于：
* 整体视觉风格
* 品牌气质
* 页面宽度和整体布局方式
* 内容密度
* 留白方式
* 圆角、阴影、边框等 UI 风格
* 主色、辅助色、背景色、文字颜色
* 字体和字号层级
* 标题、正文、按钮等基础视觉规则
* Header 风格
* Footer 风格
* 图片使用方式
* 图标风格
* 卡片和内容区块风格
* 桌面端与移动端整体设计策略
如果存在几种不同方向，可以给我 2～3 个明显不同的设计方案供我选择，但请同时告诉我你最推荐哪一种，以及为什么它更适合这个网站。
不要只使用“现代、高端、简洁、专业”这类泛化描述，需要尽量把视觉特征说具体。
## 页面设计
整体设计方向确认后，再根据已经确认的网站页面结构，逐个讨论主要页面的设计。
对于每个页面，请重点说明：
1. 页面首屏应该展示什么。
2. 页面从上到下建议包含哪些主要区块。
3. 每个区块的主要内容和作用。
4. 推荐使用什么布局方式。
5. 哪些内容应该作为视觉重点。
6. 哪些位置适合放 CTA。
7. 页面在桌面端和移动端的大致布局变化。
目前只需要讨论主要布局和设计逻辑，不需要提前设计每一个像素级细节。
## 设计决策原则
请遵守以下原则：
* 设计首先服务于公司业务和目标客户，而不是单纯追求视觉效果。
* 不要为了“看起来高级”而加入没有业务意义的复杂动画和交互。
* 优先保证信息清晰、浏览效率、可信度和转化路径。
* 页面之间要保持统一的设计语言。
* 相同类型的区块尽量复用统一样式。
* 设计方案需要考虑后续 WordPress 内容编辑和维护成本。
* 不要设计只能依赖大量硬编码才能实现的页面。
* 需要考虑响应式设计，而不是开发完成后再单独处理手机端。
* 如果某个设计方案会明显增加开发复杂度或后期维护成本，请主动指出。
## 关于参考网站
如果项目资料中已经有参考网站、品牌资料或现有视觉素材，请优先结合这些内容。
如果没有足够的视觉参考，不要自行假设我一定喜欢某一种风格。
你可以先提出几种适合该公司的方向，让我进行选择和调整。
如果我后续提供参考网站、截图或设计图片，请分析我真正想参考的是哪些部分，例如：
* 配色
* 页面结构
* 排版
* 留白
* Header
* Hero
* 卡片
* 产品展示方式
* 动效
* 整体气质
不要简单复制参考网站。
## 设计系统
在整体视觉方案逐步确认后，请把确认结果整理成一个基础设计系统，至少包括：
* 颜色系统
* Typography
* Spacing
* 页面最大宽度
* 栅格或主要布局规则
* Border Radius
* Button
* Card
* Section
* Header
* Footer
* 图片比例和使用规则
* 响应式断点原则
这些规则后续会用于 WordPress 主题开发，并尽量映射到 `theme.json` 和主题公共样式中。
现在不要提前创建 `theme.json`，先把设计规则确认清楚。
## 项目文档
每当我们确认一个重要设计决定后，请同步更新项目文档。
如果设计内容逐渐较多，可以建立例如：
`docs/design-system.md`
用于记录最终确认的设计规则。
`PROJECT.md` 中只需要保留设计方向摘要和对应文档位置，避免核心项目文档变得过于臃肿。
## 当前请先做
现在请根据已经确认的项目资料和网站结构：
1. 总结你认为这个网站应该传递的视觉气质。
2. 提出 2～3 个适合的整体视觉设计方向。
3. 明确告诉我你最推荐哪个方向，并说明理由。
4. 给出每个方向在配色、字体、布局、留白、卡片、Header 和整体页面观感上的主要差异。
先和我确认整体视觉方向。
在整体方向确认之前，不要开始逐页设计，也不要开始编写主题代码。
讨论设计时如果你不会表达，也可以直接发送参考网站的截图给他。
最终出现方案后，你可以让AI直接生成HTML代码给你查看，不满意就让他调整，最终敲定选择哪个设计方案。
6、确认完视觉设计后，开始确认网站技术细节。
输入下面的提示词（同样不要理会CodeBuddy自己弹出来的内容，要跟着我们提示词走）：
我们已经完成了公司资料分析、网站页面结构确认，以及整体视觉设计方案确认。
现在进入正式开发前的最后一个规划阶段：**确认网站内容管理方式和 WordPress 主题技术方案。**
请先阅读并参考当前项目中的：
* `PROJECT.md`
* 已确认的网站页面结构
* 已确认的设计方案
* `docs/design-system.md`（如果已经建立）
* 之前的重要讨论记录
确保接下来的技术方案与前面已经确认的业务需求和设计方案保持一致。
当前阶段仍然不要直接开始正式编写主题代码。
---
## 一、先确认哪些内容需要长期管理
这个网站不是所有内容都必须通过 WordPress 后台编辑。
对于首页、公司介绍、固定 CTA、固定品牌文案、页面布局、装饰图片等不会频繁变化的内容，可以直接作为主题源码的一部分进行维护。
后期如果这些内容需要修改，可以由 AI 修改主题代码、更新版本号并重新生成主题安装包，不需要专门为普通用户开发大量后台设置功能。
但是，对于用户后期会持续新增、修改、分类、搜索或管理的内容，需要使用 WordPress 合适的内容管理方式。
因此，请先根据当前已经确认的网站结构，主动判断并和我确认：
* 产品
* 案例 / Projects / Case Studies
* 新闻 / Blog / Articles
* FAQ
* 团队成员
* 证书
* 下载资料
* 客户评价
* 服务项目
* Solutions / Applications
* 其他可能需要长期维护的内容
不要只问我“要不要 CPT”“要不要 WooCommerce”“要不要 ACF”这类技术问题。
我不熟悉这些技术概念。
你应该先询问我实际业务需求，例如：
* 这种内容以后是否会持续增加？
* 是否需要分类？
* 是否需要独立详情页？
* 是否需要搜索和筛选？
* 是否需要用户自己在 WordPress 后台新增？
* 是否需要价格？
* 是否需要购物车？
* 是否需要在线付款？
* 是否需要库存和订单管理？
* 是否只是产品展示和询盘？
然后由你负责根据业务需求判断应该采用什么技术实现。
---
## 二、产品内容需要单独判断
如果网站需要展示产品，请不要默认使用 WooCommerce。
请先确认产品属于哪种场景。
### 如果是 B2B 展示和询盘型网站
例如只需要：
* 产品分类
* 产品列表
* 产品详情
* 产品图片
* 产品参数
* 产品介绍
* 询盘按钮或询盘表单
而不需要：
* 在线支付
* 购物车
* Checkout
* 订单管理
* 库存管理
* 优惠券
* 物流
这种情况下，请优先考虑更加轻量的 B2B 产品展示方案。
对于绝大多数 B2B 企业网站，可以优先评估使用：
**Naibabiji B2B Product Showcase**
https://wordpress.org/plugins/naibabiji-b2b-product-showcase/
如果它能够满足当前项目需求，请优先推荐使用该插件，并由主题负责对应的产品列表、产品详情以及视觉样式适配。
如果它不能满足需求，请说明原因，再推荐更合适的方案。
### 如果网站需要真正的电商功能
例如需要：
* 产品价格
* 购物车
* 在线支付
* 订单
* 库存
* 优惠券
* 物流
则可以考虑 WooCommerce。
不要因为网站存在“产品”就自动安装 WooCommerce。
---
## 三、案例和其他内容的实现原则
对于案例、Projects、Solutions、Applications 等内容，请根据实际使用方式判断。
如果这类内容：
* 会持续新增
* 需要分类
* 需要独立详情页
* 需要筛选或搜索
那么通常应该使用独立的 WordPress 内容类型，例如 Custom Post Type 和必要的 Taxonomy。
如果只有少量固定内容，并且未来几乎不会新增，也可以直接作为主题固定页面内容，不需要为了“可配置”而增加额外复杂度。
文章、新闻、博客等常规内容，除非存在特殊需求，优先直接使用 WordPress 自带的 Posts 系统。
请始终遵循一个原则：
**只有真正需要长期管理的数据，才建立内容管理结构。**
不要为了“以后可能有用”而过度设计。
---
## 四、这个主题的整体开发理念
这个项目是一个：
**由 AI 协助开发，并且后续主要由 AI 继续维护和迭代的定制 WordPress 主题。**
它不是一个准备出售给大量用户、要求每个用户都能自行设置所有内容的通用商业主题。
因此技术设计时请遵循以下原则：
* 不需要为了让普通用户自己修改每个页面元素，而开发大量 Theme Options。
* 不需要为了固定文案创建大量后台设置字段。
* 不需要为了固定布局创建复杂的配置系统。
* 不要无必要引入 ACF、页面构建器或大型框架。
* 固定的页面文案、图片、布局和设计可以直接维护在主题源码中。
* 后期需要修改固定内容时，由 AI 修改主题源码并发布新的主题版本。
* 真正需要长期新增和管理的数据，才交给 WordPress 数据库和后台管理。
优先追求：
* 简单
* 清晰
* 易于 AI 理解
* 易于维护
* 易于升级
* 较少技术债
* 良好性能
* WordPress 官方兼容性
---
## 五、确认主题技术路线
在内容模型确认之后，请根据当前项目需求主动设计 WordPress 主题技术方案。
请至少分析并确定：
### 1. 主题类型
判断这个项目更适合：
* Block Theme / Full Site Editing
* Classic Theme
* 或其他合理方式
请直接给出你推荐的方案和理由。
不要把这个技术选择直接交给我决定。
---
### 2. WordPress 和 PHP 版本
给出合理的：
* WordPress 最低支持版本
* PHP 最低支持版本
优先考虑当前主流版本和未来维护成本，不需要为了兼容非常老的 WordPress / PHP 版本增加大量代码。
---
### 3. 主题目录和代码组织
规划合理的主题目录结构，例如：
* `theme.json`
* `templates/`
* `parts/`
* `patterns/`
* `assets/`
* `inc/`
* CSS
* JavaScript
* PHP 功能代码
实际结构由你根据项目决定，不必机械使用上面的全部目录。
要求：
* 结构简单清晰
* 避免过度抽象
* 方便 AI 后续读取和修改
* 不要为了所谓“架构高级”增加没有必要的层级
---
### 4. theme.json
如果采用 Block Theme，请说明：
* 哪些设计规则放进 `theme.json`
* 哪些样式保留在 CSS
* 颜色
* 字体
* spacing
* layout
* button
* block styles
尽量让已经确认的 Design System 与 `theme.json` 保持一致。
---
### 5. 页面和模板结构
根据已经确认的网站页面结构和动态内容类型，规划：
* 首页
* 普通页面
* 产品归档
* 产品详情
* 产品分类
* 案例归档
* 案例详情
* Blog
* 单篇文章
* 搜索
* 404
* Header
* Footer
只需要规划项目真正需要的模板。
---
### 6. CSS 策略
请确定：
* 全局样式如何组织
* 页面专属样式如何组织
* 是否需要按组件拆分
* 是否需要构建工具
* 是否使用原生 CSS
* 如何避免重复 CSS
* 如何处理响应式
如果项目规模不需要 Sass、Tailwind、Webpack 等工具，不要为了技术栈看起来复杂而引入。
---
### 7. JavaScript 策略
只在真正需要交互时使用 JavaScript。
例如：
* 移动端菜单
* Slider
* Accordion
* Tabs
* 筛选
* Modal
优先使用原生 JavaScript 或 WordPress 官方已有能力。
不要为了简单功能引入大型 JS 框架。
---
### 8. 图片和静态资源
固定的品牌和页面设计图片可以直接放在主题：
`assets/images/`
用户以后通过后台上传的产品图片、文章图片等仍然使用 WordPress Media Library。
不要将用户动态上传的数据保存到主题目录中，因为主题后续会整体更新覆盖。
---
### 9. 性能
技术方案需要主动考虑：
* CSS 和 JS 请求数量
* 无用依赖
* 图片加载
* Lazy Loading
* 字体
* Core Web Vitals
* 页面 DOM 复杂度
不要为了视觉效果增加明显影响性能的动画和依赖。
---
### 10. SEO
主题需要遵守基本 SEO 友好原则，包括：
* 正确的 HTML 语义结构
* Heading 层级
* 图片 alt 支持
* WordPress 标准 title 支持
* Archive / Single 结构
* Breadcrumb 是否需要
* Schema 是否应由主题实现，还是交给 SEO 插件
不要重复实现成熟 SEO 插件已经负责的功能。
---
### 11. 安全和 WordPress Coding Standards
开发时必须主动考虑：
* escaping
* sanitization
* nonce
* capability check
* 正确使用 WordPress API
* 不直接操作 WordPress Core
* 避免不安全的自定义 SQL
* 避免直接信任用户输入
---
### 12. 国际化
请判断这个项目是否需要：
* Translation Ready
* Text Domain
* `.pot`
* 多语言插件兼容
如果目前网站只有单语言，也要避免明显阻碍未来国际化的代码结构。
---
## 六、主题版本和 AI 更新机制
这个主题后续主要通过 AI 修改源码并重新发布主题版本。
因此请设计简单明确的版本管理机制。
例如：
`1.0.0`
后续修改：
`1.0.1`
`1.0.2`
`1.1.0`
请维护：
`CHANGELOG.md`
记录每次版本的重要变化。
以后每次完成正式修改时，应至少进行：
1. 完成代码修改。
2. 执行必要的检查和测试。
3. 更新主题版本号。
4. 更新 `CHANGELOG.md`。
5. 检查是否存在可能在主题覆盖升级时丢失的数据。
6. 生成新的主题 ZIP 安装包。
主题源码中不得保存运行过程中产生的用户数据。
用户数据应该继续保存在：
* WordPress 数据库
* Media Library
* `uploads`
* 相关插件数据
保证未来主题整体覆盖更新不会导致网站业务数据丢失。
---
## 七、不要过度开发后台配置
请特别注意：
这个项目的目标不是让一个完全不懂技术的用户进入 WordPress 后台后自行配置整个主题。
因此不要主动开发：
* 大量 Theme Options
* 大量 Customizer 设置
* 每个标题对应一个后台字段
* 每张固定图片对应一个后台上传选项
* 复杂页面构建器
* 没有明确需求的 ACF 字段
* 没有业务意义的“高度可定制”功能
如果某项配置一年可能只修改一两次，更倾向于直接由 AI 修改主题源码。
---
## 八、输出你推荐的技术方案
在开始编码之前，请最终整理一份完整方案，并告诉我：
### A. 内容模型
逐项列出：
* 哪些内容直接写在主题中
* 哪些内容使用 WordPress Page
* 哪些内容使用 Posts
* 哪些内容使用独立 CPT
* 产品使用什么方案
* 是否需要 Taxonomy
* 是否需要额外插件
每一项都简要说明理由。
### B. 主题架构
说明：
* 主题类型
* 核心目录结构
* 模板体系
* CSS / JS 方案
* `theme.json` 策略
* 动态内容如何接入主题
### C. 插件依赖
列出项目需要的插件，并区分：
* 必须
* 推荐
* 可选
尽量减少必须依赖。
### D. 开发和更新方式
说明：
* 本地开发方式
* 测试方式
* Git / 版本管理
* Theme Version
* CHANGELOG
* ZIP 发布流程
---
## 九、项目文档
确认方案后，请建立：
`docs/technical-design.md`
记录：
* 内容模型
* 插件选择
* 主题技术架构
* 模板规划
* CSS / JS 策略
* 性能原则
* SEO 原则
* 安全原则
* 版本和更新机制
同时更新：
`PROJECT.md`
只保留重要技术方案摘要，并链接到 `docs/technical-design.md`，避免 `PROJECT.md` 过于臃肿。
---
## 当前请先做
现在先不要创建正式主题代码。
请：
1. 根据已经确认的网站页面结构，列出你认为可能需要长期管理的内容类型。
2. 对每一种内容向我确认必要的业务需求。
3. 不要直接问我 CPT、ACF、WooCommerce 等技术选型，而是问实际使用需求。
4. 根据我的回答，给出你推荐的实现方式和理由。
5. 内容模型确认后，再提出完整的 WordPress 主题技术方案。
6. 等我确认技术方案之后，再进入正式开发阶段。
确认这些技术细节后，就可以正式开发主题了。
开发过程中常用提示词
开始正式开发主题提示词
我们已经完成了公司资料分析、网站页面结构确认、视觉设计方案确认，以及内容模型和主题技术方案确认。
现在可以开始正式开发 WordPress 主题。
请先完整阅读并确认当前项目中的：
* `PROJECT.md`
* `docs/design-system.md`
* `docs/technical-design.md`
* 其他已经存在的重要项目文档
确保你理解已经确认的：
* 网站目标
* 页面结构
* 内容模型
* 设计系统
* 主题技术路线
* 插件依赖
* 模板规划
* 性能和安全要求
* 版本管理方式
不要重新推翻已经确认的方案，除非你在正式开发前发现明显的技术冲突或无法实现的问题。如果发现问题，请先告诉我原因和建议，不要直接擅自改变架构。
## 开发原则
请按照已经确认的技术方案开始搭建主题。
开发过程中遵守以下原则：
* 优先使用 WordPress 官方推荐方式和标准 API。
* 保持代码结构简单、清晰、易维护。
* 不要为了“可配置”而增加没有明确需求的后台设置。
* 固定页面的文案、图片、布局和设计可以直接维护在主题源码中。
* 需要长期管理的数据继续使用已经确认的 WordPress 内容模型。
* 不要安装或引入没有必要的框架和依赖。
* 不要修改 WordPress Core。
* 注意 escaping、sanitization、nonce、capability check 等 WordPress 安全规范。
* 遵循已经确认的响应式设计原则。
* 不要为了视觉效果明显牺牲性能。
* 不要一次性进行与当前任务无关的大规模重构。
## 开发方式
请不要一次性把整个主题全部写完。
按照合理顺序分阶段开发，例如：
1. 创建主题基础结构。
2. 实现全局设计系统。
3. 实现 Header 和 Footer。
4. 实现首页。
5. 实现其他主要页面。
6. 实现动态内容模板。
7. 实现响应式细节。
8. 完成全站测试和收尾。
每完成一个明显阶段后，请先自行检查当前实现，再继续下一阶段。
如果某个阶段需要我的视觉或功能确认，请停下来说明当前完成内容，并告诉我需要确认什么。
## 当前任务
现在请先完成：
1. 检查当前项目文档是否足以开始开发。
2. 根据技术方案建立主题基础目录和必要文件。
3. 实现主题的基础设计系统和全局样式框架。
4. 实现 Header 和 Footer 的第一版。
5. 确认基础主题能够在 WordPress 中正常启用和运行。
6. 完成必要的基础检查。
当前不要直接一次性完成所有页面。
完成后请告诉我：
* 创建了哪些核心文件
* 当前已经完成哪些功能
* 是否存在需要我确认的问题
* 下一步建议开发哪个页面
同时更新项目文档中的当前开发进度。
修改现有页面或视觉效果提示词
我需要对当前已经开发好的 WordPress 主题进行修改。
请先阅读当前项目中的：
* `PROJECT.md`
* `docs/design-system.md`
* `docs/technical-design.md`
* 当前相关页面的实现代码
先理解当前设计和技术结构，再进行修改。
本次修改需求如下：
**【在这里描述你的修改需求】**
例如：
* 首页 Hero 区域高度太高，希望整体降低。
* 产品卡片之间的间距太小。
* 手机端标题字号太大。
* Header 在桌面端希望更紧凑。
* 某个页面的 CTA 不够突出。
* 某一区块整体视觉效果不符合预期。
## 修改原则
请遵守以下要求：
* 先找到真正负责该效果的代码，不要通过随意增加覆盖 CSS 来快速解决。
* 优先修改现有设计系统或组件实现，而不是不断叠加临时补丁。
* 只修改与本次需求直接相关的内容。
* 不要无故改变其他已经确认的页面和组件。
* 保持与现有 Design System 一致。
* 检查修改是否会影响桌面端、平板端和移动端。
* 如果修改某个公共组件可能影响多个页面，请先说明影响范围。
* 不要为了完成一个小改动进行大规模重构。
* 如果我描述的是视觉感受而不是具体数值，请你根据当前设计系统给出合理实现，不需要把 CSS 技术细节反问给我。
## 修改完成后
请自行检查：
1. 本次需求是否已经实现。
2. 是否影响其他页面。
3. 是否产生新的响应式问题。
4. 是否增加重复 CSS 或无效代码。
5. 是否破坏现有功能。
6. 是否需要同步更新设计文档。
完成后请告诉我：
* 修改了哪些内容
* 涉及哪些文件
* 是否存在其他页面受到影响
* 是否建议我重点检查某些页面或设备尺寸
如果这是已经确认的正式修改，请同步更新项目开发记录。
暂时不要主动发布新版本，除非我明确要求。
发布新的主题版本提示词
当前这一轮主题开发或修改已经完成，并且我已经确认前台效果可以接受。
现在请准备发布新的 WordPress 主题版本。
请先读取：
* `PROJECT.md`
* `docs/technical-design.md`
* `CHANGELOG.md`
* 当前主题版本信息
* 本轮代码改动
然后完成一次正式发布前检查。
## 发布前检查
请重点检查：
* 是否存在 PHP 语法错误
* 是否存在明显 JavaScript 错误
* 是否存在临时调试代码
* 是否存在 `console.log`
* 是否存在测试文件或不应该进入正式包的文件
* 是否存在无用代码
* 是否存在明显的重复 CSS
* 是否存在错误的资源路径
* 是否存在可能导致主题启用失败的问题
* 是否存在明显的 WordPress 安全规范问题
* 是否存在主题更新覆盖后会丢失用户数据的设计
* 是否存在当前版本应该修复但遗漏的问题
不要为了发布版本主动进行与本轮修改无关的大规模重构。
如果发现严重问题，请先修复并重新检查。
## 版本号
根据本次修改内容合理更新主题版本号。
遵循 Semantic Versioning 的基本思路：
* 小 Bug、文字、样式等兼容性修改：Patch，例如 `1.0.0 → 1.0.1`
* 新增功能、页面或明显能力，但保持兼容：Minor，例如 `1.0.1 → 1.1.0`
* 存在重大不兼容变化时才考虑 Major，例如 `1.x → 2.0.0`
请自行判断本次修改适合什么版本号，并告诉我原因。
## 更新 CHANGELOG
更新：
`CHANGELOG.md`
记录：
* 新增内容
* 修改内容
* Bug 修复
* 性能优化
* 其他重要变化
只记录用户真正有必要知道的内容，不要把每个内部代码调整都写进去。
## 更新项目记录
同步更新：
`PROJECT.md`
记录当前：
* 最新主题版本
* 当前开发状态
* 已完成内容
* 尚未完成的事项
如果其他技术文档需要同步更新，也一并处理。
## 打包主题
完成检查后：
1. 生成正式主题 ZIP 安装包。
2. ZIP 内只包含 WordPress 运行所需的主题文件。
3. 不要把 Git 数据、开发缓存、临时文件、测试产物等无关内容打包进去。
4. 确保解压后目录结构正确，可以直接作为 WordPress 主题安装。
5. 文件名中包含主题名称和版本号，例如：
`my-theme-1.1.0.zip`
## 最终告诉我
发布完成后请给我一个简洁的发布说明，包括：
* 新版本号
* 本次主要变化
* 是否通过检查
* 生成的 ZIP 文件位置
* 是否存在需要我特别注意的升级事项
如果主题可以直接覆盖安装，请明确告诉我。
如果本次升级存在任何可能影响网站数据或现有内容的风险，也必须明确说明。
主题测试和网站上线
主题测试前面准备阶段已经说了，最方便的是直接把你VPS的root账号和密码发给AI，让他自己连接上去进行测试。如果你还没有VPS，可以到VPS推荐里面购买一台便宜的机器练手。
如果你没有VPS，也可以让AI指导你在本地安装测试环境，或者你直接让AI把当前主题打包，你上传到网站后台主题处测试。
测试没问题，主题开发就算完毕了。内容基本上也都填充完毕，自己最多补充文章和产品数据。
当你补充完网站内容，网站也就搭建完毕，可以做SEO方面的设置后开放收录了。
以后有什么调整，都直接给AI命令，让他修改后重新打包，你覆盖安装主题即可。
建站陪跑
AI 开发 WordPress 主题看起来门槛已经很低了，但真正开始动手以后，新手通常还是会遇到很多教程里很难全部覆盖的问题，比如开发环境配置、页面效果调整、主题报错、插件选择、内容结构、响应式适配，以及不知道该怎么继续向 AI 提需求。
如果你希望有人陪着一起把网站真正做出来，也可以考虑奶爸的 WordPress 建站陪跑服务。
陪跑不局限于 AI 开发主题，也可以根据你的实际情况选择更合适的建站方式，例如：
- 使用 AI 从零开发 WordPress 主题
- 使用 Elementor 搭建和调整页面
- 使用 WordPress 区块编辑器 / 区块主题完成网站
- 帮你判断插件、主题和技术方案是否合适
- 遇到问题时一起排查，并告诉你下一步怎么处理
陪跑的重点不是替你把网站全部做好，而是在实际建站过程中帮你少走弯路，同时让你逐渐掌握后续自己维护网站的方法。