企业官网建设流程全解析

把个人网站从 Framer 迁到 Claude Code 重新设计了一遍，我的结论是：这条路可行，但不是简单的“换工具”，而是把整套建站工作流换掉。Claude Code 不是 Framer 那种可视化编辑器，它是跑在终端里的编程智能体，会直接读项目文件、创建页面、改样式、跑命令。迁移完成后，网站从 Framer 托管的页面变成了一组可以由 Git 管理的静态文件，样式、SEO、响应式布局都回到自己手上。

这篇记录适合正在用 Framer、但觉得模板和订阅限制越来越难受的人，也适合想用 Claude Code 做真实项目、还没想清楚从哪下手的人。我会按实际执行的顺序写：迁移前怎么判断、Claude Code 怎么装怎么配、从 Framer 迁到静态站点时怎么拆任务、部署和验收要看哪些指标，最后是报错排查和边界提醒。

1. 迁移前先想明白：Framer 和 Claude Code 到底谁取代谁

1.1 Framer 解决什么问题，Claude Code 解决什么问题

Framer 是可视化网页设计和发布平台，优点是拖拽、模板、动效、一键发布，适合不想碰代码的人快速做一个品牌站或落地页。但缺点同样明显：想改一个超出模板范围的交互，得研究它的内置逻辑；网站托管在平台体系里，SEO、性能、代码控制力、数据导出都会受限。

Claude Code 是 Anthropic 推出的命令行编程智能体。你可以把它理解为一个能在终端里读项目、写文件、执行命令的“结对程序员”。它本身不是网页设计工具，但能直接生成 HTML、CSS、JavaScript、Markdown 和各类配置文件。对这次迁移来说，它的价值不是“比 Framer 更会拖拽”，而是“所有页面都能以代码形式被版本管理”。

所以这里说的“取代”，更准确的说法是：把个人网站的生成方式，从可视化平台迁移到代码工作流。Claude Code 负责把页面代码写出来，你自己做决策和验收。

1.2 适合迁移的人和不适合迁移的人

先说适合的画像：

• 能接受命令行操作，至少跑过 npm 或 git 命令。
• 会写一点 Markdown，能看懂 HTML 结构大概长什么样。
• 网站以内容呈现为主，比如个人介绍、作品集、博客、项目展示。
• 对站点有长期维护计划，想要样式可控、部署独立。

不适合的情况：

• 完全没碰过代码，连终端是什么都不知道。Claude Code 能写代码，但不能替你判断设计好坏和部署环境。
• 只是需要一个两三天就能上线的活动页，Framer 和模板站仍然更快。
• 网站重度依赖后端逻辑，比如用户登录、支付、数据库读写。Claude Code 能生成部分后端代码，但整体工程复杂度会立刻上升。

我的建议是：如果你只是想做一个展示型个人站，而且愿意学一点点命令行和 Git，Claude Code 这条路可以走；如果目标只是“先有个页面”，就别折腾迁移。

1.3 迁移前后网站形态对比

做个简单的对比，方便判断自己是否真的需要迁移：

不是说 Framer 不好，而是它更适合“不想维护代码”的场景。如果你已经开始在意代码可控性，那就能理解为什么有人会选择迁出来。

2. 安装和配置 Claude Code：先把最小任务跑通

2.1 前置条件和机器要求

Claude Code 本质上是 Node.js 命令行工具，所以先确认机器上有可用的 Node.js 环境。建议安装 LTS 版本，Windows、macOS、Ubuntu 都可以跑。Windows 上建议用 PowerShell 或 Windows Terminal，macOS 用自带终端，Ubuntu 习惯用哪款都行。

配置方面不用对硬件有太高要求。CPU 不差、内存 8GB 以上就够平时使用。它不是一个本地大模型工具，真正负责推理的是云端模型服务，本地主要负责文件读写和命令执行。这也是为什么不少人误以为装完 Claude Code 就能离线用——它还是需要可靠的模型接口和账号权限的。

如果你没有对应账号或可用的订阅、API 权限，VSCode 插件、桌面端同样无法正常工作。这和工具本身无关，是模型服务账号的问题。

2.2 安装命令与常见路径问题

常见的安装方式是通过 npm 全局安装：

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

安装完成后，在终端里进入你的项目目录，执行：

claude

第一次运行会提示你登录或绑定账号，按指引完成即可。安装后如果提示could not locate the claude cli on path，通常不是工具坏了，而是终端找不到claude这个命令：

1. 先确认 npm 全局安装目录在哪。
2. 确认该目录已经加入系统的 PATH。
3. 重启终端再试。
4. 如果是 Windows，还要注意 npm 全局目录路径是否包含中文字符或空格。

我建议装好后先在一个空目录里跑一次claude，随便问一句“你好，请确认你能读取当前目录下的文件”。能正常回复，再进后面的站点迁移，不要一上来就拿真实网站测试。

2.3 模型接入配置和模型名识别

Claude Code 默认使用官方模型服务。也有开发者会把它接到其他模型供应商，这时候最常碰到的报错是：

"some-model-name" is not a model this version of claude code recognizes

这句话看起来吓人，实际上多数是配置里的模型名写错了，或者当前 Claude Code 版本不认识这个模型名。默认模型服务的场景里，问题通常出在本地配置或环境变量覆盖；第三方模型服务的场景里，要重点检查三样东西：

• 模型名是否填成了对话界面里的“别名”，而不是接口层面的模型标识。
• BaseURL 是否正确，是否写成了带多余路径的地址。
• 工具版本是否太新或太旧，导致模型名单不匹配。

还有开发者会借助配置切换工具（比如社区里常见的 CCSwitch）在不同供应商之间切换。这类工具真正管理的是接口地址、模型名、密钥等配置，切换后能不能跑通，仍然取决于供应商接口和模型名是否匹配。

如果你在官方账号下也遇到模型名不识别，我的排查顺序是：先看启动日志里的模型名，再看环境变量，再看全局配置文件，最后看工具版本。

2.4 第一次对话测试

配置完成后的最小验证，我建议这样做：

claude

然后让它做一件小事，比如“在当前目录创建一个 readme.md，内容是一段项目介绍”。做完检查文件是否真的存在、内容是否正常。这一步能同时验证：

• 命令能启动。
• 模型能正常响应。
• Claude Code 有权限写文件。
• 当前目录的路径没问题。

如果这一步都过不了，先不要思考网站重构的问题，回到环境和权限验证。

3. 从 Framer 迁到静态站点：我是怎么拆任务的

3.1 盘点旧站，别直接复制代码

很多人迁移的第一步是“把 Framer 页面的代码复制出来”，实际上大多数 Framer 页面并不能直接导出成一份干净可维护的静态代码。可视化平台生成的代码往往和平台运行时深度绑定，直接复制到静态站里会有一堆依赖问题。

更稳的做法是盘点内容资产：

• 有哪些页面：首页、关于、作品集、博客、联系方式，逐个列出来。
• 每页有哪些模块：导航、主视觉、正文、案例卡片、页脚。
• 有哪些资源：图片、文件、字体、SEO 标题和描述。
• 哪些内容是长期不变的，哪些需要持续更新。

把这份清单整理成一个 Markdown 文件，放在项目目录里。后面给 Claude Code 描述任务时，直接告诉它“参考 site-map.md 来生成页面结构”，比在对话里反复描述更省事。

3.2 用 Claude Code 生成站点骨架

我给个人站选的是静态站生成器，这类工具能把组件和页面内容编译成纯静态 HTML。Claude Code 在这个阶段能帮你做：

• 初始化项目依赖。
• 创建统一的目录结构。
• 配置基础路由和页面集合。
• 把 Tailwind 之类的样式方案接入项目。

你可以直接对 Claude Code 说：

“在当前目录初始化一个静态网站项目，页面包括首页、关于、博客、作品集。使用响应式布局，移动端优先。导航包含四个入口，页脚包含社交媒体链接。”

第一次运行时，先让它在本地启动开发服务器：

npm run dev

然后打开浏览器看页面是否正常显示。这个阶段不需要追求设计效果，只要证明“项目能跑起来、页面能打开、文件结构能看懂”就够了。

3.3 页面迁移顺序：主页、内容页、详情页

我一般不会一次性让 Claude Code 生成全部页面，而是按依赖关系拆：

1. 先做全局布局：导航、页脚、公共样式。
2. 再做列表页：博客列表、作品集列表，因为结构重复度高，最容易验证模板逻辑。
3. 再做详情页：博客文章详情、作品详情。
4. 最后做首页：首页通常包含多个功能块，信息层级最复杂。

每完成一个页面，就打开浏览器看一眼，确认结构没乱再继续。如果一口气让 Claude Code 生成 10 个页面，后面排查哪里错会很痛苦。

3.4 内容迁移和资源整理

文本内容迁移相对简单。把旧站页面上需要保留的文字复制出来，整理成 Markdown 文件。图片和文件资源单独放在public或assets目录，命名规则建议用英文小写加连字符，避免中文文件名引发编码问题。

这里最容易忽略的是 SEO 信息。Framer 里可能配置了不少页面的标题、描述、分享图，迁移到静态站时要逐个页面检查。你可以让 Claude Code 为每个页面生成统一的 SEO 信息格式，再把旧站的标题、描述填进去。

实操提示：迁移内容时不要直接把旧站页面抓取出来的全文粘贴到一个大文件里。最好按类型拆分，比如 posts 目录存文章，projects 目录存作品，数据层和 UI 层分开，后面改版会省很多事。

4. 重新设计的关键步骤：描述需求、检查输出、迭代

4.1 把设计目标写成 Claude Code 能理解的任务

Claude Code 能听懂自然语言，但描述越具体，输出越接近预期。比如“把首页做得高级一点”这种话，运行结果很难判断。更好的描述是：

• 主视觉区域需要一句话介绍 + 两个按钮，按钮分别指向“作品集”和“联系我”。
• 作品卡片显示图片、项目名称、年份、一句话描述。
• 导航在桌面端显示完整文字，移动端显示汉堡按钮。
• 页面间距、圆角、颜色风格尽量统一。

我会把设计目标先列成清单，再让 Claude Code 逐个实现。每改完一个点，看一次页面效果，不要同时铺很多改动。

4.2 响应式布局、导航、SEO 的检查标准

设计完成后直接“感觉还行”是不够的。我通常会检查这几个点：

• 浏览器宽度分别拉成 375px、768px、1440px，看内容是否溢出。
• 导航在移动端是否可用，按钮点击区域是否足够大。
• 每个页面的<title>和 meta description 是否唯一。
• 图片有没有设置宽高比，避免加载时布局跳动。
• 文章页的正文阅读宽度是否合理，行高和字号是否适合长时间阅读。

这些检查不复杂，但能拦住 80% 的“看起来好用、实际很别扭”的情况。

4.3 批量修改组件的做法

页面多起来之后，逐页改会很累。正确做法是把重复模块抽成组件，让 Claude Code 只改组件文件，所有引用它的页面自动更新。

比如导航栏，只需要维护一个组件文件。需要加一个链接时，让 Claude Code 修改组件并检查所有页面是否仍然正常。改完后跑一次构建命令，确认没有编译错误。

如果 Claude Code 在一次修改中动了很多文件，我会让它先列出改动清单，再执行。你可以直接问它“这次改动会影响哪些文件”，然后扫一眼清单，判断改动范围是否合理。

4.4 验证：本地预览、Lighthouse、浏览器尺寸

本地预览没问题后，我会用浏览器开发者工具跑一轮性能检查，也会看 Lighthouse 的分数，重点不是分数本身，而是有没有明显的性能问题，比如：

• 首屏图片过大。
• 第三方脚本阻塞渲染。
• CSS 文件体积异常。
• 没有做基础缓存和压缩。

静态站生成器一般会把 CSS、JS 压缩好，但图片压缩往往需要额外处理。遇到单张图片几 MB 的情况，先压缩图片，再调代码。

5. 部署与验收：从本地到线上

5.1 构建命令和输出目录

本地开发跑通，不代表线上没问题。发布前先确认构建命令。静态站项目一般会在package.json里配置：

npm run build

构建完成后，会输出一个静态目录，常见的是dist，也有项目直接输出到public。具体以你项目的构建配置为准。

我会在部署前先执行一次构建，把输出目录里的文件数量和体积扫一遍，确认没有异常大的文件。接着把构建产物放到本地预览里再点一轮主要页面，确保不是“开发模式正常，构建后样式丢失”。

5.2 部署到静态托管平台

静态站可以部署到各种静态托管平台，比如 GitHub Pages、Netlify、Vercel、Cloudflare Pages 等。流程基本相似：

1. 把项目推送到 Git 仓库。
2. 在托管平台导入仓库。
3. 配置构建命令和输出目录。
4. 平台自动部署，生成访问地址。
5. 绑定自己的域名，更新 DNS 记录。

第一次部署时，最容易出错的点是构建命令或输出目录没写对，导致部署成功后打开是空白页或 404。我会在部署日志里先看构建步骤是否成功，再看访问路径和资源路径是否正确。

5.3 验收清单

部署完成后，我建议按这个顺序验收：

• 域名能正常打开，强制刷新后没有样式丢失。
• 从首页点击导航进入每个主要页面。
• 博客列表能跳转到文章详情。
• 移动端和桌面端分别操作一遍。
• 浏览器地址栏输入旧站网址，确认旧站是否还需要保留跳转。
• 看托管平台有没有部署失败警告。
• 检查 SEO 信息是否生效，比如搜索站点标题是否会显示成预期文字。

如果迁移前旧站已经有一定的访问量，建议保留旧站一段时间，或把旧站根路径设置为公共通知页面，告诉访问者网站已经搬家。直接在线上删除旧站，容易丢失老链接的访问入口。

6. 常见报错和排查顺序

6.1 claude CLI 找不到

报错样例是：

failed to run claude code: error: could not locate the claude cli on path

这个报错在 VSCode 插件里也比较常见。原因基本都是终端找不到claude命令。排查顺序：

1. 在终端里执行where claude或which claude，看路径是否存在。
2. 检查 npm 全局安装目录是否在 PATH 里。
3. 重启终端或编辑器，让新的 PATH 生效。
4. 如果之前用非 npm 方式安装，确认路径冲突。

这类问题跟模型能力没有任何关系，先改路径，再重启，通常能解决。

6.2 模型名不被识别

报错格式类似：

"deepseek-v4-pro" is not a model this version of claude code recognizes

看到这个提示先不用慌。它表示当前版本认识不到这个模型名。我会按顺序查：

1. 当前 Claude Code 版本是多少，用claude --version查看。
2. 配置文件里的模型名是不是拼写错误。
3. 环境变量里是否设置了覆盖模型名。
4. 第三方模型接口的 BaseURL 是否正确。
5. 如果模型名是对的但版本太旧，升级 Claude Code 后再试。

不要把这个问题当成“工具坏了”，它更像是配置漂移。

6.3 529 和请求超时

运行过程中有时会看到类似 529 或请求超时的提示。这通常说明模型服务端负载较高，或当前网络状态不够稳定。我的处理方式：

• 先等几分钟重试一次，不要连续重发同一请求。
• 把单次任务拆小，比如从“生成整个站点”改成“只生成主页结构”。
• 检查是不是同时跑了多个长任务，导致请求排队。
• 如果频繁出现，需要考虑网络环境是否稳定，或者换到更空闲的时间段再操作。

6.4 订阅和权限提示

有些团队环境会提示：

your organization has disabled claude subscription access for claude code

这说明账号或组织策略限制了 Claude Code 的使用。个人用户先查自己的订阅状态；团队用户需要找管理员确认是否允许启用 Claude Code。这个问题在工具层面解决不了。

遇到账号、权限、订阅相关提示时，最有效的动作是确认三件事：账号是否有对应服务权限、模型服务是否可用、本地配置是否指向了正确的账号。

6.5 输出质量不稳定怎么办

页面代码生成出来但没有达到预期，最常见的不是工具问题，而是任务描述太宽。比如“设计一个美观的首页”这种描述，生成结果随机性很大。

我会做三件事：

• 把任务拆小，一次只改一个区域，比如“只改 hero 区域的标题字号和间距”。
• 给 Claude Code 提供参考结构，比如“在 projects 文件夹已有 3 篇 markdown，请按日期倒序生成列表”。
• 让 Claude Code 先输出修改方案，确认思路后再写入文件。

这样能大幅减少来回返工的时间。

7. 哪些场景不要急着用 Claude Code 取代 Framer

7.1 零基础用户

如果你完全不了解命令行、npm、Git，也没有意愿去学，Claude Code 很难成为主力建站工具。它能生成代码，但遇到路径问题、部署问题、样式问题时，你还是需要理解基础概念才能排查。零基础用户建议先用可视化工具把几个页面做起来，同时慢慢学一点 HTML 和命令行，再考虑迁移。

7.2 对像素级视觉要求高

Claude Code 擅长生成结构清晰、复用性好的代码，但很精细的视觉设计，比如惊艳的动效、复杂的排版细节、品牌级设计系统，还是需要人工调优。它能提高“从零到可用”的速度，但不能替你做“从可用到惊艳”的设计判断。

7.3 需要复杂后端逻辑

个人介绍站和博客用静态站生成器非常合适。但如果是会员系统、电商、多用户内容管理这类站点，工程复杂度会明显提升。Claude Code 可以生成部分后端代码，但数据库设计、权限、支付、部署监控都需要专业开发和维护，不要指望一条命令解决。

7.4 内容量大且没有规范

如果网站有几百篇文章，而旧站内容结构混乱、大量页面缺失标题、图片链接失效，直接迁移会非常痛苦。我的建议是先花时间把内容整理成结构化格式，再迁移到新站。否则 Claude Code 生成的代码再干净，内容层也是乱的，后期维护还是寸步难行。

整个迁移跑下来，我最深的感受是：真正值得替代的不是 Framer 这个工具，而是过去那种“页面改版要重新拖一遍”的工作方式。Claude Code 把工作重心从视觉编辑挪到了需求描述和结果验收上，网站也从此变成了可版本管理、可编译、可部署的代码项目。

如果你也想试一试，不要一上来就试图把整个网站迁完。先装好 Claude Code，跑通一个最小页面，再把旧站内容慢慢搬过来。个人网站的价值始终在内容和表达上，工具只是负责把输出这件事变轻。