企业官网建设流程全解析

做个人网站这件事，很容易陷入一种纠结：想要速度快，就选 Framer 这类可视化工具；想要自由度，就得自己写代码。Framer 把“上手快”做到了极致，但代价是网站被平台绑定。Claude Code 这类编程代理正在把另一侧的门槛降下来：你不需要手工敲每一行代码，但得到的却是完全属于自己的工程化项目。

这篇文章不是单纯夸某个工具，而是完整记录一次真实的技术选型过程：为什么我要把个人网站从 Framer 迁出去，Claude Code 在迁移中到底承担了什么角色，以及从环境准备、项目重建、内容迁移到上线验证，每一步具体怎么操作。如果你也在“可视化建站”和“代码建站”之间犹豫，读完你会有一个清晰可靠的决策依据。

1. 为什么把个人网站从 Framer 迁出来

先说结论：Framer 不是不好用，而是它优先服务的是“快速上线”，不是“长期拥有”。

个人网站和营销页不一样。营销页做完就上线，改版周期长；个人网站是持续更新的资产，你会频繁改作品、写博客、调整关于页。这种“高频迭代 + 长期维护”的需求，会很快暴露可视化建站工具的四个瓶颈。

第一是所有权问题。Framer 上的页面以项目数据的形式保存在平台里，设计资产和内容都跟平台绑定。你可以在平台上编辑、发布，但要把它变成自己仓库里的一套干净代码，整个流程不算顺畅。从长期看，个人网站是一份需要持续维护的数字资产，代码可控性很重要。

第二是自定义边界来得太快。Framer 的组件、动效和交互模板确实强，但一旦你想做超出它抽象层的事情，比如自定义路由逻辑、接入特殊脚本、精细控制结构化数据，就会感到阻力。这种阻力不是“再写一行代码”就能解决的，而是你得绕开平台本身的封装。

第三是成本结构。Framer 采用订阅制，套餐会对项目数、访问流量和站点数量做限制。对个人网站来说，月付成本不高，但按年累计就不是一笔小开销。相比之下，代码方案的固定成本主要是域名和托管，一年的费用通常更低。

第四是 SEO 与性能的可控性。Framer 能做好基础 SEO，但如果你对日志、结构化数据、CWV 性能指标、路由复用有更高要求，代码方案可以精细到每一个 HTML 标签，而可视化工具只能停留在平台允许的配置范围内。

所以，迁移的核心理由不是“Framer 不好”，而是它被放错了位置。它更适合做原型、营销活动页、品牌落地页这类“短周期、重视觉、不深度依赖代码资产”的项目；而个人网站这种“长周期、高频迭代、追求完全控制权”的项目，更适合交给代码方案。

2. 重新理解 Claude Code：它不是“AI 写代码”，是编程代理

很多文章会把 Claude Code 理解成“一个帮你写代码的命令行工具”，这个说法太浅了。更准确的定义是：Claude Code 是一个运行在终端里的编程代理，它不仅能生成代码，还能读取项目上下文、跨文件修改、执行命令，并在多次尝试中调整自己的方案。

我们不妨对比一下普通 AI 聊天工具和 Claude Code 在工作流程上的区别。

在聊天工具里，你问“请写一个响应式导航栏”，它给你一段代码，你复制，新建文件，粘贴，再手动处理依赖。整个过程中 AI 只负责“产生片段”，其它工程环节全靠你。

在 Claude Code 里，你在某个项目目录下启动它，然后说“帮我给这个 React 项目加一个响应式导航栏，项目用的是 Tailwind”，它会先读取项目结构、找到路由配置和样式总入口，然后动手修改对应的文件，最后运行构建命令来确认没有报错。你做的事从“执行代码”变成了“描述意图 + 审查结果”。

这种工作模式对建站的影响是结构性的：

• 它不再只生成“一次性代码片段”，而是围绕你的项目上下文做增量修改。
• 它可以把一个复杂需求拆成多个小步骤，逐步执行，而不是一次性输出一大堆代码后让你自己整合。
• 它能自己跑命令，比如构建、安装依赖、测试，并把结果反馈到处理流程中。

所以，Claude Code 真正降低的成本，不是“打字成本”，而是“意图到工程实现”的翻译成本。过去你要把设计稿翻译成组件结构、样式方案、路由关系、数据流，现在你可以用自然语言把设计意图描述给它，由它在项目里落地。

这个能力放在个人网站迁移场景里特别合适。个人网站通常规模不大，但涉及页面多、内容杂、设计细节多，如果用传统的“手写代码”方式重建，工作量大；如果用可视化工具，又回到了平台锁定。而编程代理正好填补了中间地带。

3. Framer 与 Claude Code 建站方案对比

在动手之前，有必要把两套方案摆在同一张表格里做一次冷静的对比。

从这张表能看出，两者并不是“谁彻底取代谁”的关系，而是适用场景不同。

如果你需要的是两三天就能上线的营销落地页，Framer 的效率无可替代。它的模板质量高，动效也强，你不用关心构建链路和部署细节。

如果你的目标是做一个持续迭代的个人网站，并且希望拥有全部代码、内容和数据，那么 Claude Code + 代码方案长期来看更合适。它把“从设计到代码”的转化成本压低之后，个人开发者不需要再依赖平台的设计封装。

我在这次迁移中采用的是第二套方案。具体技术栈是 Vite + React + TypeScript，内容放在 Markdown 和 JSON 里，部署到 Vercel。这个组合对个人网站来说足够轻，生态也成熟。

4. 迁移前准备：内容盘点与设计决策

迁移最忌讳的是打开 Claude Code 就直接说“帮我重建网站”。AI 能帮你写代码，但不能替你做产品决策。迁移前，我先把三件事做完。

第一件事：盘点页面和内容。

我把原站面的所有页面列了一遍：首页、关于页、作品集、博客列表、博客详情、联系方式。每一页都记录了核心内容资产，包括文案、图片、视频、外部链接。图片和文件先统一下载到本地，放到一个临时目录，后续迁到新项目的 public 目录。

第二件事：确认平台依赖。

有些内容看似是“网站内容”，但实际上是 Framer 平台特性，比如平台的表单托管、平台的动画预设、平台的 CMS 数据模型。这些不能在代码方案里一键迁移，需要重新实现。我当时把表单改成用现成的表单服务，把动画从“平台预设”改成“CSS 动画或轻量动画库”，把 CMS 列表改成基于 Markdown 文件的数据目录。

第三件事：确定设计语言。

不用追求一比一还原原站，迁移本身就是重新设计的好机会。我把这次迁移要遵守的设计约束提前写成了一份简短说明：主色、辅助色、字体栈、间距节奏、圆角大小、页面布局层级。这份说明后来直接喂给了 Claude Code，作为生成页面时的设计基础。

技术选型方面，我给个人网站定的是：Vite + React + TypeScript 做界面，React Router 做路由，文章内容用 Markdown，站点全局配置用 JSON。这套方案对个人开发者最友好，构建快，生态丰富，部署也简单。

这些都完成后，才进入真正的环境准备。

5. Claude Code 环境安装与基础配置

5.1 安装 Claude Code

Claude Code 的安装方式以官方文档为准，最常见的是通过 npm 全局安装。在终端里执行：

npm install -g @anthropic-ai/claude-code

安装完成后，先检查版本，确认命令可用：

claude --version

如果看到版本号输出，说明安装成功。如果你的机器上没有 Node.js，需要先安装一个较新的 LTS 版本。可以用node -v确认：

node -v

5.2 登录与密钥配置

Claude Code 在工作时需要有对应的账号授权。第一次运行claude命令时，会自动进入登录流程，按提示操作即可。

如果你更习惯用环境变量管理密钥，也可以在启动之前设置：

export ANTHROPIC_API_KEY=你的密钥

注意，密钥不要写进项目仓库，也不要提交到 Git 历史里。个人网站项目通常托管在 GitHub 公开仓库，密钥泄露会造成账号安全问题。

5.3 项目级配置与权限

Claude Code 支持通过配置文件控制权限。用户级配置文件在~/.claude/settings.json，项目级配置文件在项目根目录的.claude/settings.json。

项目级配置的一个实用价值是：限制 Claude Code 在项目中的操作范围。下面是一个常见的权限配置示例：

{ "permissions": { "deny": ["Delete"] } }

这个配置只做了“拒绝删除”这一条约束，目的是防止 Agent 在自动修改过程中误删重要文件。实际可用的权限字段有很多，建议以当前版本的官方文档为准，不要直接照搬网上找不到出处的配置。保持最小权限原则，比全部放开更稳妥。

5.4 关于模型配置的提醒

Claude Code 会默认使用它适配的模型。配置文件中可以指定model字段，但这里有一个非常常见的坑：网上搜索到的配置里，模型名往往是旧版本或者某个教程作者自己填写的，直接复制过来，可能会看到类似这样的报错：

xxx is not a model this version of claude code recognizes

意思是当前版本根本识别不了你写的模型名。解决办法很简单：使用官方文档列出的模型标识，升级 Claude Code 版本，而不是在网上乱抄配置。我是在写博客的时候，才特别体会到这个提示想要表达的底层含义：第三方 API 兼容层、非官方模型名、过时版本，都会让这个工具链变得脆弱。

5.5 最小可用性测试

安装配置完成后，先不用急着写网站。进入一个测试目录，运行：

claude

然后向它提一个小任务：

请查看当前目录下的文件列表，并简述项目结构。

如果它能正常返回结果，说明安装、登录、权限和网络链路都是通的。这一步能提前暴露大部分环境问题，避免在正式迁移中才发现。

6. 用 Claude Code 重构个人网站：核心实操

6.1 初始化项目

我选择在一个全新的空目录里启动迁移，这样能让 Claude Code 从零构建，避免旧文件干扰。

mkdir my-site cd my-site git init

然后启动 Claude Code：

claude

如果你使用的编辑器是 VS Code，也可以在编辑器集成的终端里运行，或者在扩展市场搜索并安装 Claude Code 的官方扩展，把整套工作流放在编辑器里。

6.2 让 Claude Code 初始化项目

我给它下达了第一个完整任务：

请在当前目录初始化一个基于 Vite 的个人网站项目。 技术栈使用 React + TypeScript。 请先安装依赖，并确认项目能在本地启动。

这一步它会帮我们完成npm create、依赖安装、目录初始化等一系列操作。相比手动执行命令，这一步给我节省了不少时间。

初始化完成后，我要求它继续生成页面骨架：

请创建个人网站的页面骨架： - 顶部导航栏 - Hero 首页首屏区域 - 作品展示区域 - 文章列表区域 - 页脚 页面结构使用 React 组件拆分，样式暂时用普通 CSS，主题色使用 #4F46E5， 留白多，整体风格干净简洁。

Claude Code 会根据这个描述生成组件目录和基础样式。

6.3 生成的核心代码示例

以首页 Hero 区域为例。Claude Code 生成的组件，经过我确认后，大致是这样的结构：

// 文件路径：src/components/Hero.tsx export function Hero() { return ( <section className="hero"> <p className="hero__kicker">Frontend Developer</p> <h1 className="hero__title">你好，我是开发者</h1> <p className="hero__desc"> 专注于前端开发与交互设计，记录技术思考与个人项目。 </p> <a className="hero__link" href="/about"> 关于我 </a> </section> ); }

对应的样式片段：

/* 文件路径：src/styles/global.css */ :root { --primary: #4f46e5; --text-main: #1f2937; --text-secondary: #6b7280; --space-page: 64px; } .hero { padding: var(--space-page) 0; max-width: 720px; margin: 0 auto; } .hero__kicker { color: var(--primary); font-size: 14px; letter-spacing: 0.05em; text-transform: uppercase; } .hero__title { font-size: 48px; line-height: 1.2; margin: 16px 0; } .hero__desc { color: var(--text-secondary); font-size: 18px; line-height: 1.7; }

这里有两个关键决策值得说明。

第一，把颜色、间距等设计变量抽成 CSS 变量。这样后续调整主题色时，只改一处即可全局生效。如果不抽变量，每个组件的颜色都写死，改版时会非常痛苦。

第二，数据不要写死在组件里。Hero 文案这种一次性内容可以暂时内联，但博客列表、作品集这类会持续更新的内容，必须抽成数据文件或者 Markdown，否则以后每次更新都要改组件代码。

6.4 分块生成而不是一次性生成

用 Claude Code 做网站时，最容易犯的错误是让它“一次性生成整个网站”。一次任务塞进太多需求，上下文会很长，生成的代码难审查，出错了也不好定位。

我当时的做法是分四步：

• 第一步：搭建项目骨架，确认能启动。
• 第二步：生成首页的布局和样式。
• 第三步：逐个生成关于页、作品页、博客页。
• 第四步：统一处理路由、导航和页脚。

每一步生成完毕后，我都会在当前目录跑一次构建命令，确认没有报错再进入下一步。这种小步快跑的方式，让迁移过程始终处于可控状态。

7. 内容迁移与页面扩展：从首页到博客

首页跑通之后，真正的体力活是内容迁移。个人网站的内容通常分三类：页面文案、图片资源、博客文章。

页面文案可以直接在新页面中重写。图片资源放到public/images目录，并通过相对路径引用。博客文章则是迁移的重头戏。

7.1 把文章转成 Markdown

我在迁移时，把所有博客文章统一转成 Markdown 格式，放在src/content/articles/目录下。每篇文章单独一个文件：

--- title: 用 AI 编程代理重构个人网站 date: 2025-02-10 tags: [Claude Code, 建站] --- 这里是文章正文，支持标准 Markdown 语法。

这种做法的好处是把“内容”和“展示”彻底分离：文章本身就是普通文本文件，不依赖数据库，不依赖内容管理系统，Git 天然能记录每一次修改。

7.2 用数据文件管理文章列表

博客列表页需要读取文章元信息。Claude Code 可以帮你生成一个数据文件：

// 文件路径：src/content/articles/index.ts export interface ArticleMeta { slug: string; title: string; date: string; tags: string[]; excerpt: string; } export const articleList: ArticleMeta[] = [ { slug: "ai-programming-agent-personal-site", title: "用 AI 编程代理重构个人网站", date: "2025-02-10", tags: ["Claude Code", "建站"], excerpt: "从 Framer 迁移到代码方案，Claude Code 改变了整个工作流。" } ];

我把这个数据文件当作“内容索引”，组件只负责渲染，不负责维护内容。以后新增文章时，只需要新增一个 Markdown 文件，并在这个索引里加一条记录。

7.3 让 Claude Code 生成列表页和详情页

我给 Claude Code 下达的下一步指令是：

请创建一个博客列表页，读取 src/content/articles/index.ts 中的文章元信息， 渲染成卡片列表。同时创建一个文章详情页，路由格式为 /blog/:slug， 内容从对应的 Markdown 文件读取。

这一段指令里包含了路由约定、数据来源、页面职责。Claude Code 会把路由配置、列表组件、详情组件都创建好。比我手动从头写一遍快得多。

8. 运行验证与上线发布

网站重建完成后，不能只看“页面能打开”就结束。我按照下面这条链路做完整验证。

8.1 本地运行

npm run dev

浏览器访问终端提示的本地地址，逐个检查页面：

• 首页是否按设计稿展示
• 导航栏跳转是否正常
• 博客列表是否读取到文章
• 文章详情页能否正确渲染 Markdown
• 移动端宽度下布局是否正常

8.2 生产构建验证

开发模式正常，不代表生产构建正常。必须运行：

npm run build npm run preview

build会输出生产产物。如果类型检查有错误、依赖缺少、路径配置不对，都会在这一步暴露。preview可以让你在本地预览构建产物，确认和开发模式表现一致。

8.3 部署到 Vercel

个人网站的部署方案很多，我选用 Vercel，因为配置简单、提供免费 HTTPS、支持持续部署。安装 CLI 后，在项目根目录运行：

npm install -g vercel vercel

Vercel 会自动识别 Vite 项目，我只需要选择绑定自己的域名，之后每次推到 Git 仓库，它都会自动触发部署。

8.4 上线后的检查清单

上线不等于结束。我整理了一份检查清单，你也可以直接复用：

• 自定义域名解析是否生效。
• HTTPS 证书是否自动签发。
• 首页和文章页的 title、description 是否正确。
• OG 分享卡片是否显示正常。
• 移动端访问是否和白屏。
• robots.txt 和 sitemap.xml 是否正确生成。
• 文章中的图片是否全部正常加载。
• 旧站的 301 跳转是否已经配置。

这套检查做完，迁移才算真正完成。

9. 常见问题与排查思路

Claude Code 在个人网站迁移场景中，最常见的几个问题有一定的规律。我把遇到过的高频问题整理成了一张排查表：

这些问题的共同点是：先看日志，再改配置，不要盲目重装。Claude Code 的控制台日志和构建输出本身就会给出足够线索。

10. 从本次迁移总结出的最佳实践

在完整经历过一次从 Framer 到 Claude Code 的迁移后，我总结了六条个人网站建设的最佳实践。

第一，把设计语言写成提示词。不要只说“好看一点”，要给具体约束：主色、字体、间距、页面结构。Claude Code 的生成质量高度依赖需求描述质量。

第二，跨文件修改时先确认影响范围。编程代理会修改多个文件。在让它执行重要改动之前，最好先问它“你准备改哪些文件”，再让它动手。小步提交，每次改动后都确认一次 Git diff。

第三，建立 Git 提交习惯。Claude Code 每完成一个功能，我就在本地提交一次。这样一旦某次生成结果不理想，可以随时回滚，不影响其它页面。

第四，内容与代码分离。博客文章用 Markdown，页面配置用 JSON，组件不和具体内容耦合。这个习惯在迁移和维护阶段都会给你极大自由度。

第五，审查生成的代码，不要无脑信任。AI 生成的代码整体可用，但可能有冗余依赖、缺失的错误处理、不合理的命名。尤其在涉及路由和鉴权逻辑时，必须有开发者人工审查。

第六，把安全和备份放在前面。生产环境不要用匿名密钥，个人网站托管平台要开好回滚能力，本地保留完整备份。小站也不能忽略这些基础工程保障。

如果你目前还在 Framer 和代码方案之间摇摆，我的建议很直接：不要立刻做全站迁移，先挑一页，比如博客列表页或者关于页，用 Claude Code 在本地重建一次。跑通这个最小闭环后，你再判断是否值得把整个站点迁出来。这个成本很低，但获得的判断信息是最真实的。