AI を使ったサイト構築が最近話題になっています。Naiba もしばらく AI 開発を試用してきました。この記事では、AI ツールを使って自分の WordPress テーマを開発する方法を紹介します。注意点として、一般ユーザーにとって、AI 開発には依然として難しさがあります。本チュートリアルに従っても、必ずしも WordPress テーマを完全に開発できるとは限りません。
以前、Naiba は「AI建站真的比WordPress好吗？我用Claude、DeepSeek、Codex实测后的结论」を共有しました。この記事はその続編です。AI を使って WordPress テーマを開発し、WordPress でサイトの記事や製品データを管理することで、AI と WordPress を組み合わせたサイト構築を実現します。
開発前の準備
始める前に、AI ツールと WordPress 環境を準備する必要があります。初心者の方で、サイト構築を始めたばかりの場合は、ドメインとサーバーを購入してからサーバー上で開発することをお勧めします。ローカル開発環境のバグを避けるためです。
AI ツール
AIツールはたくさんあります。Claude Code、Codex、Qoder、TRAE、CodeBuddyなどです。
多くのユーザーがCodexやClaudeのアカウントを取得できないことを考慮し、Naibaはこの記事ではテンセントのCodeBuddyをデモとして使用します。他のAI開発ツールの流れもほぼ同じなので、同様の考え方で操作できます。
無料のAIツールで開発しようとせず、時間と労力を無駄にしないでください。直接有料プランを購入することをお勧めします。
WordPress開発環境
WordPressテーマを開発するには、テーマの効果をテストするためのWordPressサイトが必要です。直接ドメインとサーバーを購入して実際の環境を構築して開発することをお勧めします。ローカル開発は避けてください。初心者がローカル開発を行うと、解決できない環境問題に遭遇する可能性があります。
ここでは、テーマ開発用にVPSを購入することをお勧めします。SiteGroundのようなサーバーを購入した場合は、手動でアップロードしてテストするしかありません。
AIによるWordPressテーマ開発の流れ
1. コンピューター上にフォルダーを作成し、英語で名前を付けます。
2. CodeBuddyを開き、左上の「ファイル」→「開く」→「フォルダーを開く」を選択し、先ほど作成したフォルダーを選択します。
右下隅にモデル切り替えがあります。この記事の公開時点ではHy3モデルは無料ですが、作業効率を考えると、GLM、Kimi、DeepSeekを選択することをお勧めします。具体的には、モデルを切り替えてタスクを実行し、感触を確かめてください。タスクを完了できるモデルであればどれでも構いません。デフォルトはAutoで、タスクに応じてモデルを自動選択します。
3. ウェブサイトの基本的な構築資料をフォルダーに保存します。Naibaは直接„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にどのように要件を伝えればよいかなどです。
誰かと一緒にサイトを実際に作り上げたい場合は、NaibaのWordPress サイト構築伴走サービス。
伴走サービスはAIでのテーマ開発に限らず、実際の状況に合わせてより適切なサイト構築方法を選択できます。例えば：
- AIを使ってWordPressテーマをゼロから開発
- Elementorを使用してページを構築・調整
- WordPressブロックエディター/ブロックテーマでサイトを完成
- プラグイン、テーマ、技術ソリューションが適切かどうかの判断を支援
- 問題が発生した際に一緒に調査し、次の対処方法を指示
伴走サービスの重点は、サイトをすべて代わりに作ることではなく、実際のサイト構築プロセスで遠回りを避け、徐々にサイトを自分で維持管理する方法を身につけることです。