WordPress 转型为定制网站（社区版） 是做什么的？
将现有的 WordPress 网站转变为可维护的自定义网站，而不是将其作为空白画布重新设计。首先保留原始内容，然后将用户期望的设计方向转化为原创的视觉系统，最后构建并验证迁移后的内容一致性。
使用用户的语言。不要重复问题，除非这些问题已经在用户的请求或可用的项目上下文中得到了回答。
从信息收集开始
在爬取源站、创建文件、选择框架或提出视觉设计之前，请先阅读 references/intake.md，并围绕仅剩的未回答的关键问题，进行一次紧凑的提问。
初始提问至少需要明确以下内容：
- 当前的 WordPress URL；
- 迁移范围以及任何非公开内容；
- 期望的风格，可以通过直接描述和/或示例 URL 来说明；
- 预期的交付物及部署目标；
- 所需的功能、语言、品牌和上线限制；
- 确认用户拥有迁移所提供内容和资产的权限。
允许用户对设计和实现选择回复“你来决定”。不能凭空捏造源站 URL、可行的范围以及使用源材料的权限。切勿要求用户粘贴密码、API 密钥、Cookie、数据库凭据或恢复码到聊天中。仅当通过公开方式无法获取足够信息时，才要求用户提供导出文件或经批准的、安全的访问方法。
用户回答后，总结已商定的需求简报、明确的默认项、未解决的未知因素以及排除项。仅当某个问题的答案会实质性影响内容保留、架构、成本或部署时，才进行后续提问。
将发现、构建和启动分离开来
将这些阶段视为不同的授权边界：
- 发现： 检查公开页面、API、站点地图、Feed 以及提供的导出文件，但不得更改源站。
- 构建： 创建或修改目标项目，同时保持源站可用。
- 启动： 仅在用户明确授权时，才进行部署、更改 DNS、更换主机、添加重定向或停用 WordPress。
不得将分析或构建的权限解释为发布的权限。建议使用预览 URL 进行审查。在新网站被接受且存在可恢复的备份之前，切勿删除或禁用 WordPress 网站。
在转换前保存原始内容
在收集内容或媒体之前，请先阅读 references/preservation.md。
在实施之前构建源站清单。尽量使用最可靠的来源：优先使用提供的 WordPress 导出文件或经过身份验证的 API，然后是公开的 REST API、WordPress 站点地图、普通站点地图或 Feed，最后是有范围的 HTML 爬取。当单一来源不完整时，可以合并使用多个来源。
记录范围内每一项内容的迁移状态。涵盖页面、文章、自定义文章类型、分类法、作者信息、日期、别名、内部链接、SEO 字段、结构化数据、附件、特色图片、内嵌媒体、替代文本、标题、可下载文件以及所需的交互功能。
当原始媒体文件可访问且已获授权时，应保留其原始字节。记录原始 URL、目标路径、MIME 类型、适用的尺寸、字节大小、SHA-256 哈希值、引用关系、替代文本、标题以及迁移结果。切勿声称公开爬取包含了草稿、私密文章、未发布修订版、表单提交、用户账户、插件设置或未公开的原始媒体文件。
默认情况下，应将原始导出文件、数据库转储、凭据和私密媒体排除在版本控制之外。不要将用户内容、品牌资产或凭据存储在此已安装的技能文件夹内。
翻译风格而非克隆标识
当用户提供示例 URL、截图、品牌材料或开放式的风格需求时，请先阅读 references/design-direction.md。
将参考内容分析为可复用的特征，例如层级结构、间距、排版角色、调色板行为、图片处理、形状、密度、动效和导航模式。当风格意图不明确时，询问用户喜欢或不喜欢什么。在进行高成本的视觉工作之前，先提供一份简短的设计方向总结。
创建原创设计。未经许可，不得复制其他网站的源代码、文本、Logo、插图、专有资产或独特的商业外观。参考 URL 仅授权进行分析，而非复制。除非用户授权修改，否则应原样保留提供的 Logo 和品牌资产。
根据需求选择架构
不要强行使用热门的技术栈。应根据编辑需求、内容数量、交互性、集成要求、托管方式、可维护性以及用户的技术熟悉度来选择。
- 对于内容量大、重视 SEO 和性能的公开网站，首选静态生成或服务端渲染。
- 仅当需要非技术人员进行编辑时才添加 CMS；并说明上线后由谁编辑什么内容。
- 尽可能保留现有的公开路径。否则，为每个变更范围内的 URL 创建明确且永久的重定向。
- 将可重复的内容建模为结构化数据，而不是将其粘贴到页面组件中。
- 保持导入内容和媒体与源站清单的可追溯性。
- 仅当所需的分析、同意管理、表单、搜索、电子商务、会员系统、嵌入和集成在范围内且可测试时，才予以保留。
不要默默继承存在漏洞的插件、跟踪脚本、过时的短代码或 WordPress 特定的标记。应转换其有用的含义和行为，并报告任何需要替换或手动审查的内容。
分块进行迁移
当项目规模较大时，先实现一个代表性的内容类型或路由。在规模化迁移之前，验证其内容模型、媒体处理方式、样式系统以及响应式行为。
随着工作的推进，保持路由地图以及内容/媒体清单的更新。对于每个跳过的项目，记录原因，例如 out-of-scope（超出范围）、duplicate（重复）、private-unavailable（私密不可用）、broken-at-source（源站已损坏）或 requires-user-decision（需要用户决定）。切勿让缺失的项目从审计追踪中消失。
尊重现有的目标仓库、框架、约定以及用户已有的工作。未经明确指示，不要覆盖非空项目或替换现有实现。
验证内容一致性和质量
在宣布迁移完成之前，请先阅读 references/verification.md。
对照清单验证已构建或已部署的网站，而非凭记忆判断。至少需要证明：
- 每个范围内的源站 URL 都有一个目标页面或一个有意的重定向；
- 标题、有意义的正文内容、日期、作者、分类法和 SEO 元数据按要求得以保留；
- 每个被引用的本地资产都能解析为预期的媒体类型，而不是返回状态码 200 的 HTML 回退；
- 图像的尺寸、替代文本、标题、下载文件、内部链接、规范 URL、站点地图条目以及结构化数据在适用的情况下都是正确的；
- 范围内包含的表单、搜索、分析、同意管理、电子商务、认证、嵌入和集成功能端到端工作正常；
- 代表性的移动端和桌面端页面没有明显的可访问性、内容溢出、控制台错误或性能问题。
当要求保留原始文件时，应使用字节哈希值。对于裁剪、响应式设计、布局和变换等字节比较无法实现的情况，应进行视觉审查。
除非所有范围内的清单项目都有已验证的目标或可接受的例外，否则不要报告“没有任何内容丢失”。应区分本地构建检查、预览验证、生产验证以及无法访问的项目。
交付迁移记录
根据目标项目调整文件名，但应提供以下等价物：
migration-brief.md：范围、设计方向、架构、假设和排除项；source-inventory.csv或.json：源站内容和路由清单；media-manifest.csv或.json：源站/目标媒体映射及哈希值；redirect-map.csv：旧 URL、新 URL、重定向状态和验证结果；- 新网站的源代码和内容；
verification-report.md：内容一致性、浏览器兼容性、功能性、SEO 和可访问性证据；handover.md：编辑、部署、回滚、备份以及剩余的手动工作。
将敏感的导出文件置于公共仓库之外，并记录其安全位置，但不要暴露机密信息。
停止条件
当出现以下情况时，暂停并解释具体的差距：
- 源站 URL 或授权范围未知；
- robots 协议、身份验证、速率限制或主机控制阻止了安全的发现；
- 提供的导出文件中不包含必要且私密的内容；
- 所请求的设计依赖于用户可能无权使用的资产或标识的复制；
- 启动需要凭据、DNS 更改、购买、破坏性替换等尚未授予的权限；
- 无法从可用的来源证明内容一致性。
提出最小的、安全的下一步行动。不要将不完整的爬取、正常运行的主页或一次成功的构建伪装成已完成的迁移。