AI website building has been very popular recently. Naiba has also been using AI development for a while. This article will introduce how to use AI tools to develop your own WordPress theme. It should be noted thatFor ordinary users, AI development is still difficult, and we cannot guarantee that you can fully develop your WordPress theme by following this tutorial.
Previously, Naiba shared "Is AI website building really better than WordPress? My conclusion after testing with Claude, DeepSeek, and Codex". This article is a follow-up to that article, using AI to develop WordPress themes and WordPress to manage website articles and product data, achieving a combination of AI and WordPress for website building.
Preparation Before Development
Before you start, you need to prepare an AI tool and a WordPress environment. For beginners, if you are just starting to build a website, it is recommended to directly purchase a domain name and server and develop on the server, avoiding some bugs in the local development environment.
AI Tools
There are many AI tools, such as Claude Code, Codex, Qoder, TRAE, and CodeBuddy.
Considering that most users cannot handle Codex and Claude accounts, Naiba uses Tencent's CodeBuddy as a demonstration in this article. The processes for other AI development tools are similar, and you can operate following similar ideas.
Don't think about using free AI tools for development; it wastes time and energy. It is recommended to directly purchase a paid plan.
WordPress Development Environment
To develop a WordPress theme, you need a WordPress website to test the theme's effects. It is recommended to directly purchase a domain name and server to set up a real environment for development, and not to develop locally. Beginners may encounter some environment issues that they cannot solve when developing locally.
Here, it is recommended that you purchase a VPS to develop themes. If you purchase a server like SiteGround, you can only manually upload and test.
AI Development WordPress Theme Process
1. Create a folder on your computer and name it in English.
2. Open CodeBuddy, click File in the top left corner, then Open, then Open Folder, and select the folder you just created.
In the bottom right corner, there is a model switcher. At the time of writing, the Hy3 model is free, but for better results, it is recommended to choose GLM, Kimi, or DeepSeek. You can switch models and assign tasks to feel the difference. As long as it can complete your tasks, any model is fine. The default is Auto, which automatically selects the model based on your task.
3. Save some basic website building materials to the folder. Naiba directly created a „Company Information“ folder.
4. Enter the following conversation in the chat box in the bottom right corner (you can also improvise).
这是一个空白项目文件夹，我希望你协助我从零开发一个 WordPress 主题。
我不懂具体的 WordPress 主题开发技术，因此这个项目中请你承担主要的技术负责人角色：负责技术路线、主题架构、代码规范、安全性、兼容性、可维护性以及开发过程中的技术判断。
我的职责主要是确认网站前台的页面结构、视觉设计、内容展示方式和功能需求。
当前项目文件夹中有一个 `Company Information` 文件夹，里面保存了我们公司的相关资料。
## 当前阶段的任务
现在不要直接开始创建主题文件或编写正式代码。
请先完成以下工作：
1. 阅读 `Company Information` 文件夹中的全部资料。
2. 根据资料总结你对以下内容的理解：
* 公司主要业务
* 目标客户
* 核心产品或服务
* 网站主要目标
* 网站需要重点展示的信息
3. 基于这些资料，提出一个合理的网站页面结构和信息架构方案。
4. 将页面结构方案与我讨论并确认。
页面结构确认之前，不要进入具体页面设计，也不要开始主题开发。
## 后续流程
整个项目按照下面的顺序推进：
公司资料理解
→ 网站页面结构确认
→ 页面视觉风格与设计方案确认
→ WordPress 主题技术方案确认
→ 开始开发
→ 页面逐项实现和确认
→ 测试与完善
不要跳过前面的确认阶段直接进入后面的工作。
## 技术决策原则
因为我不熟悉 WordPress 主题开发技术，因此：
* 纯技术问题由你主动分析并给出你认为合适的方案。
* 不要把 PHP 架构、目录结构、WordPress API 使用方式、代码组织方式等纯技术问题简单反问给我决定。
* 如果存在多个技术方案，请说明主要差异，并给出你推荐的方案和理由。
* 涉及网站前台视觉、页面结构、用户体验、展示内容、业务功能的决定，需要先和我确认。
* 不要因为我不懂技术，就自行替我决定网站前台应该是什么样子。
开发时应优先遵循 WordPress 官方推荐方式和当前主流最佳实践，避免为了实现功能而使用不必要的复杂方案。
## 项目文档
由于项目会持续多轮讨论和开发，请你从项目开始就建立并持续维护项目文档。
建议至少维护一个项目核心文档，例如：
`PROJECT.md`
其中记录：
* 项目目标
* 公司和网站定位
* 已确认的网站页面结构
* 已确认的设计方向
* 重要功能需求
* 技术架构和关键技术决策
* 已完成的工作
* 当前开发进度
* 待处理事项
* 重要讨论结论
如果后续内容较多，可以自行拆分到 `docs/` 目录中，但需要保持结构清晰。
每当我们确认一个重要决定后，请同步更新项目文档，保证即使后续上下文丢失，也可以通过项目文档恢复项目状态。
## 当前请先做
现在请先阅读 `Company Information` 文件夹中的资料。
阅读完成后，先告诉我：
1. 你对公司和网站目标的理解。
2. 你建议的网站整体页面结构。
3. 每个主要页面承担什么作用。
先和我确认这些内容，不要开始写主题代码。
After sending, CodeBuddy will communicate back and forth with you and finally confirm the website structure.
5. After multiple rounds of communication to confirm the website page structure, begin confirming the web design:
CodeBuddy tends to give you some options each time, but since we have our own prompts, we'll skip that here.
Enter the following prompt:
我们已经完成了公司资料分析和网站页面结构确认，现在进入网站视觉设计方案确认阶段。
请先读取并参考当前项目中的 `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 和整体页面观感上的主要差异。
先和我确认整体视觉方向。
在整体方向确认之前，不要开始逐页设计，也不要开始编写主题代码。
When discussing the design, if you're not sure how to express yourself, you can also directly send screenshots of reference websites to it.
Once a proposal appears, you can ask the AI to directly generate HTML code for you to review. If you're not satisfied, have it adjust, and finally decide on the design option.
6. After confirming the visual design, start confirming the website's technical details.
Enter the following prompt (again, ignore CodeBuddy's own pop-ups and follow our prompts):
我们已经完成了公司资料分析、网站页面结构确认，以及整体视觉设计方案确认。
现在进入正式开发前的最后一个规划阶段：**确认网站内容管理方式和 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. 等我确认技术方案之后，再进入正式开发阶段。
After confirming these technical details, you can officially start developing the theme.
Common prompts during development
Prompt to start official theme development
我们已经完成了公司资料分析、网站页面结构确认、视觉设计方案确认，以及内容模型和主题技术方案确认。
现在可以开始正式开发 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. 完成必要的基础检查。
当前不要直接一次性完成所有页面。
完成后请告诉我：
* 创建了哪些核心文件
* 当前已经完成哪些功能
* 是否存在需要我确认的问题
* 下一步建议开发哪个页面
同时更新项目文档中的当前开发进度。
Prompt to modify existing pages or visual effects
我需要对当前已经开发好的 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. 是否需要同步更新设计文档。
完成后请告诉我：
* 修改了哪些内容
* 涉及哪些文件
* 是否存在其他页面受到影响
* 是否建议我重点检查某些页面或设备尺寸
如果这是已经确认的正式修改，请同步更新项目开发记录。
暂时不要主动发布新版本，除非我明确要求。
Prompt to release a new theme version
当前这一轮主题开发或修改已经完成，并且我已经确认前台效果可以接受。
现在请准备发布新的 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 文件位置
* 是否存在需要我特别注意的升级事项
如果主题可以直接覆盖安装，请明确告诉我。
如果本次升级存在任何可能影响网站数据或现有内容的风险，也必须明确说明。
Theme testing and website launch
As mentioned in the preparation phase, the most convenient way to test the theme is to directly send your VPS root account and password to the AI and let it connect and test on its own. If you don't have a VPS yet, you can go toVPS Recommendationsto buy a cheap machine for practice.
If you don't have a VPS, you can also ask the AI to guide you in setting up a local test environment, or you can simply have the AI package the current theme and upload it to the theme section of your website backend for testing.
If the test passes, the theme development is complete. The content is basically filled in, and you only need to add articles and product data yourself.
Once you've added the website content, the site is essentially built, and you can proceed with SEO settings and then allow indexing.
For any future adjustments, just give the AI commands, have it modify and repackage the theme, and then you can overwrite-install it.
Website Building Coaching
Developing WordPress themes with AI may seem low-barrier, but once you actually start, beginners often encounter many issues that tutorials can't fully cover, such as development environment configuration, page effect adjustments, theme errors, plugin selection, content structure, responsive adaptation, and not knowing how to continue making requests to the AI.
If you want someone to accompany you in actually building the website, you can also consider Naiba'sNaibabiji WordPress Website Building Coaching Service。
The coaching is not limited to AI theme development; you can also choose a more suitable website building method based on your actual situation, for example:
- Using AI to develop a WordPress theme from scratch
- Using Elementor to build and adjust pages
- Using the WordPress block editor / block theme to complete the website
- Helping you determine whether plugins, themes, and technical solutions are suitable
- Troubleshooting issues together when problems arise and telling you how to proceed next
The focus of the coaching is not to build the entire website for you, but to help you avoid detours during the actual building process, while gradually enabling you to master the methods for maintaining the website yourself in the future.