企业官网建设流程全解析

1. 网站搬迁这件事，为什么值得用 AI 重新做一遍

做过网站搬迁的人都知道，这活儿表面上是“把文件从 A 搬到 B”，实际上是一场涉及数据完整性、URL 映射、SEO 权重传递、缓存刷新、数据库字符集、权限继承的综合性工程。我前后经手过二十多个搬迁项目，小到个人博客换主机，大到几万条内容的独立站整体迁移，踩过的坑能写满一个笔记本。传统做法无非是打包、导出、导入、改配置、批量替换域名，然后祈祷搜索引擎别把排名清零。但现实往往是：搬迁完成后流量断崖式下跌，301 跳转配错导致死链遍地，数据库序列化数据里的旧域名没替换干净，图片路径 404，后台登录白屏。

这次我拿WorkBuddy这个 AI 工作台来重新跑一遍搬迁流程，核心思路是让 AI 承担那些重复、易错、需要全局一致性检查的环节，人只负责决策和验收。标题里提到的“借助 AI 能力，轻松完成新旧网站搬迁”，重点不在“轻松”二字，而在于 AI 能把搬迁过程中那些隐性的、容易遗漏的关联点全部串起来。这篇文章我会把整个实操过程拆开讲，包括 WorkBuddy 的安装配置、搬迁规则的设定、301 映射表的生成逻辑、SEO 权重的保护策略，以及我在实际执行中遇到的典型问题和排查方法。

适合谁看？如果你手头正好有一个网站要换服务器、换域名、换 CMS，或者从旧架构迁到新架构，这篇文章可以直接抄作业。如果你只是想了解 AI 工作台在运维场景里怎么落地，也能从中看到具体的协作模式。我尽量不堆术语，把每一步的操作意图和背后的逻辑都讲清楚。

2. WorkBuddy 的定位与搬迁场景适配

2.1 WorkBuddy 到底是什么，为什么选它做搬迁

WorkBuddy 本质上是一个 AI 工作台，它把多个 AI 能力封装成可编排的“技能”（Skill），你可以理解为一个能调用大模型、能读写文件、能执行脚本、能联网检查的智能代理集合。它和普通的 AI 聊天工具最大的区别在于：它有自己的工作目录、缓存机制、规则系统，可以针对一个具体项目持续工作，而不是每次对话都从零开始。

我选它做网站搬迁，主要看中三点。第一，它能同时处理结构化和非结构化数据，比如一边读数据库导出文件，一边分析日志里的 URL 访问记录。第二，它的规则系统允许我预设搬迁约束，比如“所有旧域名必须 301 到新域名对应路径”“图片目录整体平移不做重命名”，这样 AI 在执行时不会自由发挥。第三，它支持多 AI 协作，我可以让一个实例专门负责 URL 映射，另一个负责内容校验，第三个负责生成 Nginx 配置，分工明确。

注意：WorkBuddy 有国际版和国内版之分，安装后如果界面是英文，在设置里切换语言即可，不影响功能。缓存目录默认在用户目录下，如果 C 盘空间紧张，建议第一时间改到数据盘。

2.2 搬迁项目的核心需求拆解

在动手之前，我把这次搬迁的需求列了一张表，这也是我建议任何搬迁项目开始前必须做的事。需求不明确，后面 AI 再强也白搭。

这张表后来直接变成了 WorkBuddy 里的规则文件。我把每一行写成一条约束，AI 在执行任何操作前都会先读这些规则。实测下来，这一步能避免 80% 的“AI 自作主张”问题。

2.3 新旧站架构差异对搬迁策略的影响

这次搬迁的旧站是 Discuz 论坛架构，新站是独立站加 WordPress。两者差异很大：Discuz 的 URL 是forum.php?mod=viewthread&tid=123这种动态参数形式，WordPress 是/%postname%/这种伪静态。如果直接做 301，必须建立参数到 slug 的映射关系，否则搜索引擎会认为旧链接全部失效。

我的策略是：先从 Discuz 数据库导出所有帖子的 tid 和标题，用 WorkBuddy 的 AI 能力批量生成 slug，然后建立 tid 到 slug 的映射表，最后用 Nginx 的 rewrite 规则把旧动态 URL 重定向到新伪静态 URL。这个过程如果手工做，几千条数据能让人崩溃，但交给 AI 批量处理，半小时就能跑完。

3. 搬迁前的环境准备与 WorkBuddy 配置

3.1 安装 WorkBuddy 与基础环境检查

WorkBuddy 支持 Windows、Linux 和 macOS。我这次是在 Ubuntu 上跑的，因为服务器本身就是 Linux，本地和远程环境一致能减少很多麻烦。安装过程不复杂，下载对应平台的安装包，解压后运行安装脚本即可。安装完成后第一件事是检查依赖：Python 版本、Node 版本、数据库客户端、rsync、curl 这些常用工具是否齐全。

# 检查基础环境 python3 --version node --version mysql --version rsync --version curl --version

如果缺什么就补什么。我遇到过因为缺少 mysql 客户端导致 WorkBuddy 无法读取数据库导出文件的情况，补装后立刻正常。另外建议把 WorkBuddy 的工作目录设在空间充足的分区，搬迁过程中会产生大量临时文件，包括数据库备份、日志、映射表等。

3.2 缓存目录更改与性能调优

WorkBuddy 默认缓存目录在~/.workbuddy/cache，如果搬迁的数据量大，这个目录会迅速膨胀。我的做法是在数据盘建一个专用目录，然后在 WorkBuddy 设置里把缓存路径改过去。

# 创建专用缓存目录 mkdir -p /data/workbuddy_cache # 在 WorkBuddy 设置中修改缓存路径为 /data/workbuddy_cache

改完之后重启 WorkBuddy 生效。这个操作看起来小，但实际影响很大：搬迁一个 2GB 的站点，缓存目录能涨到 5GB 以上，如果放在系统盘，很容易把根分区撑满导致服务异常。我踩过一次这个坑，半夜收到磁盘告警，排查半天才发现是缓存目录没改。

3.3 给 WorkBuddy 定规则：搬迁项目的约束设定

这是整个流程里最关键的一步。WorkBuddy 的规则系统相当于给 AI 画了一个圈，圈内它可以自由发挥，圈外绝对不能碰。我针对搬迁项目定了以下几条规则：

• 所有文件操作必须在项目工作目录内进行，禁止直接修改生产环境文件。
• 任何 URL 重定向必须使用 301，禁止使用 302。
• 数据库导出必须包含完整表结构和数据，字符集统一为 utf8mb4。
• 图片和附件迁移时保持原文件名和目录结构，不做重命名。
• 每次批量操作前先生成操作清单，人工确认后再执行。
• 搬迁完成后必须生成校验报告，包括文件数量、数据库行数、URL 可访问性。

这些规则写在 WorkBuddy 的规则文件里，格式很简单，一行一条。写完之后 AI 在执行任务时会自动读取并遵守。我实测发现，规则越具体，AI 的执行结果越可控。比如“禁止使用 302”这一条，如果没有写，AI 在某些场景下会默认用 302 做临时跳转，这对 SEO 是致命的。

4. 核心搬迁流程的 AI 化实现

4.1 旧站数据导出与完整性校验

旧站是 Discuz，数据导出分两部分：数据库和附件目录。数据库用 mysqldump 导出，附件用 rsync 同步。这两步本身不复杂，但校验很关键。我让 WorkBuddy 在导出完成后自动做三件事：检查 SQL 文件是否完整（有没有截断）、统计附件目录文件数量和总大小、对比数据库中的附件记录数和实际文件数是否一致。

# 数据库导出 mysqldump -u root -p --default-character-set=utf8mb4 discuz > /data/backup/discuz.sql # 附件同步 rsync -avz /var/www/discuz/data/attachment/ /data/backup/attachment/

WorkBuddy 读取 SQL 文件后，会自动解析出所有表名和行数，生成一份校验清单。如果发现某张表的行数为 0 或者附件数量对不上，它会标红提示。这一步帮我发现过一次附件目录权限问题导致部分文件没同步成功的情况，如果没检查，搬迁后用户头像和图片会大面积 404。

4.2 URL 映射表的 AI 批量生成

这是 AI 能力体现最明显的地方。Discuz 的帖子 URL 是forum.php?mod=viewthread&tid=123，新站 WordPress 的 URL 是/%postname%/。我需要把每个 tid 映射到一个 slug。手工做的话，几千条数据要一条条看标题、想 slug、检查重复，没几天做不完。

WorkBuddy 的做法是：读取数据库中的帖子标题，调用 AI 批量生成 slug，然后自动去重、检查长度、替换特殊字符。我只需要设定 slug 的规则，比如“保留中文拼音首字母”“英文单词小写”“用连字符分隔”“不超过 60 个字符”。

# 伪代码示意：WorkBuddy 内部处理逻辑 for post in posts: slug = ai_generate_slug(post.title, rules) slug = deduplicate(slug, existing_slugs) mapping[post.tid] = slug

生成的映射表是一个 CSV 文件，包含 tid、旧 URL、新 URL 三列。我抽查了前 100 条，准确率在 95% 以上，少数不理想的手动调整即可。这个效率比人工高太多了。

4.3 301 重定向规则的自动生成与部署

拿到映射表后，下一步是生成 Nginx 的 rewrite 规则。WorkBuddy 可以直接读取 CSV，输出配置文件。规则的核心逻辑是：把旧动态 URL 中的 tid 参数提取出来，查映射表找到对应的 slug，然后 301 到新 URL。

# 生成的 Nginx 配置片段 rewrite ^/forum\.php\?mod=viewthread&tid=(\d+)$ /$mapping_$1 permanent;

实际部署时，因为 Nginx 不支持直接查 CSV，我的做法是让 WorkBuddy 把映射表转成 Nginx 的 map 指令，或者生成一个 PHP 跳转脚本作为过渡。map 指令适合数据量不大的场景，几万条以内性能没问题。如果数据量特别大，建议用 Lua 或者直接写数据库查询。

提示：301 规则部署后，一定要用 curl 批量测试一批旧 URL，确认返回码是 301 且 Location 头指向正确的新 URL。我写了一个简单的测试脚本，随机抽 200 条旧链接跑一遍，有问题立刻发现。

4.4 数据库内容替换与序列化数据处理

WordPress 和 Discuz 的数据库结构完全不同，直接导入不现实。我的做法是：用 WorkBuddy 写一个转换脚本，把 Discuz 的帖子、用户、评论数据提取出来，按照 WordPress 的表结构重新组织，然后导入。这个过程中最麻烦的是序列化数据，比如 Discuz 的某些配置项和用户字段是 PHP serialize 格式，里面嵌了旧域名，直接文本替换会破坏序列化结构。

WorkBuddy 的处理方式是：先反序列化，替换域名，再重新序列化。这个逻辑它自己能识别，因为规则里写了“序列化数据必须反序列化后替换再序列化”。如果没有这条规则，AI 可能会直接做字符串替换，导致数据损坏。我见过有人搬迁后后台设置全部丢失，就是因为序列化数据被破坏了。

// 正确的序列化数据处理逻辑 $data = unserialize($old_value); $data = str_replace('old-domain.com', 'new-domain.com', $data); $new_value = serialize($data);

4.5 附件与媒体库的路径迁移

附件迁移看似简单，但有个细节容易忽略：数据库里存储的附件路径可能是绝对路径，也可能是相对路径，还可能带旧域名的完整 URL。WorkBuddy 在迁移时会扫描所有包含附件路径的字段，统一替换为新站的路径格式。

我的做法是保持附件目录结构不变，只改域名部分。比如旧站是http://old.com/data/attachment/2019/01/01/abc.jpg，新站是https://new.com/wp-content/uploads/2019/01/abc.jpg。WorkBuddy 会生成一个路径映射表，然后批量更新数据库中的引用。这一步做完后，还要检查一下 .htaccess 或 Nginx 配置，确保旧附件路径也能 301 到新路径，避免外链图片失效。

5. SEO 权重保护与搬迁后的搜索表现

5.1 301 跳转对 SEO 的真实影响

很多人以为做了 301 就万事大吉，其实不然。301 只是告诉搜索引擎“这个页面永久搬家了”，但权重的传递是有损耗的，而且需要时间。根据我的经验，一个正常运行的站点做完 301 后，排名会在 2 到 4 周内逐步恢复，但前提是跳转链路要短、要直接。如果旧 URL 先 301 到一个中间页，再 301 到最终页，权重损耗会加倍。

WorkBuddy 在生成跳转规则时，我特意加了一条约束：“所有跳转必须一步到位，禁止链式跳转。”这条规则帮我避免了一个常见错误：有些人为了省事，把所有旧链接先跳到一个统一页面，再让用户自己找，这对 SEO 是灾难性的。

5.2 独立站谷歌 SEO 的关键设置

新站是独立站，面向谷歌搜索。搬迁后我让 WorkBuddy 检查了以下几项 SEO 要素：

WorkBuddy 会自动抓取新站页面，逐项检查并生成报告。如果发现某页缺 title 或者 canonical 指向旧域名，它会标出来让我修。这个检查如果人工做，几百个页面能看到眼花。

5.3 搬迁后的搜索表现监控与调整

搬迁完成后，我让 WorkBuddy 每天自动抓取谷歌搜索控制台的数据（通过 API），监控点击量、展示量、平均排名和覆盖率。前两周数据会有波动，这是正常的。如果发现某些旧 URL 持续 404，说明 301 规则有遗漏，需要补上。如果发现新 URL 迟迟不被收录，可能是 sitemap 没提交或者 robots.txt 挡了。

我遇到过一个情况：搬迁后一周，某个频道的流量掉了 60%。排查发现是那个频道的旧 URL 规则写错了，tid 参数提取时多了一个字符，导致跳转到了 404 页面。修正规则后，三天内流量恢复。这件事说明，搬迁后的监控不能省，而且要细到每个频道。

6. 常见问题与排查技巧实录

6.1 搬迁后后台登录白屏或无限重定向

这是最常见的问题之一，通常是因为数据库里的站点地址（siteurl 和 home）还是旧域名，导致登录时跳转到旧站，而旧站已经不可访问。解决方法是直接改数据库：

UPDATE wp_options SET option_value = 'https://new.com' WHERE option_name = 'siteurl'; UPDATE wp_options SET option_value = 'https://new.com' WHERE option_name = 'home';

WorkBuddy 在搬迁流程里会自动检查这两个字段，如果发现还是旧域名会提醒。但有时候缓存插件也会导致重定向，所以改完数据库后还要清缓存。

6.2 图片 404 与附件路径错误

图片 404 的原因通常有三种：附件没同步完整、数据库里的路径没替换、Nginx 规则拦截了附件目录。排查顺序是：先看文件在不在，再看数据库里的路径对不对，最后看 Nginx 配置有没有问题。WorkBuddy 的校验报告会列出所有 404 的图片 URL，我拿着这个列表逐个排查，效率很高。

注意：如果旧站的附件目录有防盗链设置，搬迁后新站也要对应配置，否则外站引用你的图片会消耗流量。

6.3 数据库字符集乱码问题

Discuz 默认可能是 GBK 编码，WordPress 是 UTF-8。如果导出导入时没注意字符集，中文会变成乱码。我的做法是在 mysqldump 时指定--default-character-set=utf8mb4，导入时也指定同样的字符集。WorkBuddy 在读取 SQL 文件时会检测编码，如果发现不一致会提示转换。

6.4 WorkBuddy 执行中断与恢复

搬迁过程中如果 WorkBuddy 因为网络或资源问题中断，重新启动后可以从上次的检查点继续，不需要从头再来。它的工作目录里会保存进度文件，包括已处理的文件列表、已生成的映射表、已执行的步骤。我建议在开始前就把工作目录备份一份，万一进度文件损坏还能恢复。

6.5 常见问题速查表

7. 搬迁完成后的验收与长期维护

7.1 全站链接扫描与死链修复

搬迁完成后，我让 WorkBuddy 跑了一次全站链接扫描，包括内部链接和外部链接。内部链接检查新站页面之间的跳转是否正常，外部链接检查引用的其他网站是否还能访问。扫描结果会生成一个死链列表，我逐个修复。这个步骤如果人工做，几千个链接能点到手软，但 AI 跑一遍只要十几分钟。

7.2 性能对比与优化建议

新站的性能不能比旧站差，否则用户体验和 SEO 都会受影响。WorkBuddy 会对比新旧站的首页加载时间、TTFB、页面大小等指标。如果新站更慢，它会分析原因，比如图片没压缩、缓存没开、数据库查询慢等，并给出优化建议。我这次搬迁后新站比旧站快了 40%，主要得益于新服务器配置更好和缓存策略优化。

7.3 给 WorkBuddy 定几条长期规则

搬迁不是一次性工作，后续还有内容更新、插件升级、安全维护等。我给 WorkBuddy 定了几条长期规则，让它持续为站点服务：

• 每周检查一次死链，自动生成报告。
• 每月检查一次 SEO 要素，包括 title、description、canonical。
• 每次内容发布后自动提交 sitemap 到搜索控制台。
• 监控服务器资源使用情况，超过阈值提醒。

这些规则让 WorkBuddy 从一个搬迁工具变成了日常运维助手。我实际用下来，最省心的是死链检查，以前要手动跑工具，现在它自动做，有问题才通知我。

7.4 多 AI 协作在搬迁中的实际应用

这次搬迁我用了三个 WorkBuddy 实例：一个负责数据导出和校验，一个负责 URL 映射和 301 规则生成，一个负责 SEO 检查和监控。它们之间通过共享工作目录交换数据，我只需要在关键节点做决策。这种多 AI 协作的模式在复杂项目里优势明显，每个实例专注自己的任务，不会互相干扰。

提示：多实例运行时要注意资源占用，尤其是数据库连接和内存。如果服务器配置一般，建议串行执行，不要同时跑太多任务。

8. 我个人在实际操作中的几点体会

搬迁这件事，工具再强也替代不了人的判断。WorkBuddy 能帮你批量生成映射表、自动检查死链、生成配置文件，但“哪些 URL 该跳到哪里”“哪些内容该保留”“哪些设置该调整”这些决策，还是得人来定。我的经验是：把 AI 当成一个执行力极强但需要明确指令的助手，规则写得越细，结果越好。

另外，搬迁前的备份一定要做，而且要做两份，一份本地一份远程。我见过太多人因为备份没做好，搬迁失败后数据全丢的案例。WorkBuddy 虽然能回滚，但前提是备份文件在。最后再分享一个小技巧：搬迁完成后，别急着关旧站，让它以 301 的方式继续运行至少一个月，等搜索引擎完全切换后再下线。这样万一有问题，还能快速切回去。