网站构建技能：流程
本技能依据一份简报为单个客户构建一个网站。每个客户将获得一份已批准的站点计划、一个代码库和一个检查脚本。批准的站点计划决定了路由、标题、描述、标题和站点地图。
在本文档中，<skill-dir> 是包含此文件的文件夹，<client-folder> 是为此客户创建的文件夹。如果用户没有文件夹命名规范，则使用 clients/<client>/。
前置要求
- 阅读此客户的笔记（如果存在）。用2-3行向用户说明适用的规则。
- 找到简报、公司简介、Logo和照片。
- 确保 Node.js、Python 3 和
rsync可用。
警告：如果简报未提供某个事实，切勿将其放在网站上。虚构的证书、客户名称、数据或评价会给客户带来法律和信任风险。
阶段 1：事实
- 阅读
references/brief-intake.md。 - 完整阅读每个源文件。
- 编写
<client-folder>/site-brief/facts.md。 - 如果客户有现有网站，则爬取其当前站点。记录每个URL用于重定向映射。
- 如果缺少事实，则编写
<client-folder>/site-brief/questions-for-client.md。
关卡 1. 向用户展示事实清单摘要和缺失信息列表。等待用户回复。仅在用户同意的情况下处理缺失信息。缺少必需事实的页面将不会出现在站点计划中，或者在计划中保留但缺失该事实。
阶段 2：站点计划
- 阅读
references/site-plan.md。 - 为客户所在市场进行关键词研究。
- 复制
<skill-dir>/assets/site-plan.template.json到<client-folder>/site-brief/site-plan.json。 - 为每个页面填写一项。
- 将计划与提案（如果存在）进行比较。范围中的每个项目都必须对应一个页面或功能。范围中的表单需要
server托管或一个约定的替代方案。 - 运行计划检查关卡。修正每个失败项。
python3 <skill-dir>/scripts/site_gate.py plan <client-folder>/site-brief/site-plan.json
关卡 2. 向用户展示一个包含以下列的表格：URL、主要关键词、月搜索量、标题。同时说明托管选择。等待用户批准。然后在计划中记录批准信息为 "approved_by" 和 "approved_on"。没有这些字段，构建关卡将失败。
阶段 3：脚手架
- 选择文件夹
<client-folder>/website/。 - 运行脚手架脚本。该脚本支持路径中包含空格和大写字母。
bash <skill-dir>/scripts/scaffold.sh "<client-folder>/website" static
- 仅在计划需要服务器端功能时使用
server替代static（参见references/launch.md）。 - 将批准的
site-plan.json复制到src/lib/site-plan.json。 - 用事实清单中的值替换
src/lib/site.ts中的每个__FILL值。 - 阅读
node_modules/next/dist/docs/01-app/中关于元数据、图片、字体和静态导出的指南。
注意：Next.js 在主要版本之间会发生变化。node_modules 中的指南与已安装的版本匹配。您的训练数据可能不匹配。
阶段 4：设计方向
- 阅读
references/design-and-copy.md。 - 根据Logo创建颜色和排版令牌。将它们放入
globals.css。 - 从Logo生成
public/logo.webp、public/og.webp（1200 x 630 像素）和src/app/icon.png。 - 仅构建页眉、页脚和首页。
- 启动预览。对于静态站点，在构建后使用
npx serve out -l 3210。对于需要服务端渲染的站点，使用npm run dev。 - 在浏览器中打开
http://127.0.0.1:3210。分别在375、768和1280像素宽度下检查页面。
注意：嵌入式浏览器可能对 localhost 返回 HTTP 431 错误。地址 127.0.0.1 没有此问题。
关卡 3. 向用户展示首页。等待用户批准设计。所有其他页面都将使用此设计。
注意：在通过关卡 3 之前，切勿构建其他页面。后期的设计变更将导致所有页面的迁移。
阶段 5：页面
- 阅读
references/seo-build-spec.md。 - 将内容放置在
src/lib/下的类型化数据文件中（例如services.ts）。保持页面文件简洁。 - 对每种重复的页面类型使用带有
generateStaticParams的动态路由。 - 使用
pageMetadata()和getPage()从计划中获取每个页面的标题、描述和H1。 - 以客户的口吻为买家撰写文案。只能使用
facts.md中的事实。 - 按照规范添加内部链接。
- 构建站点。
npm run build
- 运行构建检查关卡。修正每个失败的根本原因。不要为了通过而修改检查关卡。
python3 <skill-dir>/scripts/site_gate.py build <client-folder>/website
- 运行
npx tsc --noEmit和npm run lint。
阶段 6：审查
- 在浏览器中检查每种页面类型在375、768和1280像素宽度下的显示。
- 检查每个行动号召（CTA）：电话、WhatsApp、电子邮件和表单。
- 如果用户需要，将页面文案整理到一个文档中。遵循
references/design-and-copy.md。 - 仅当用户指示时部署预览版本。预览构建不应被搜索引擎索引。
关卡 4. 向用户提供预览URL和检查结果。等待用户批准发布。
阶段 7：发布
- 阅读
references/launch.md。 - 使用
SITE_INDEXABLE=1构建。 - 使用
--release参数运行构建检查关卡。检查必须通过。 - 执行
references/launch.md中的发布步骤。
警告：未经当前会话中的批准，请勿连接域名或推送到生产环境。在线域名会影响客户的业务。
收尾
- 向用户提供仍需客户执行的行动清单。
- 将路径、决策和经验记录到此客户的笔记中。
- 告知用户网站已准备好进行SEO内容工作。
固定规则
| 规则 | 原因 |
|---|---|
| 每个服务一个URL | 单页网站无法为某个服务提供可排名的URL |
| 每个URL一个主要关键词 | 针对同一个关键词的两个页面会相互竞争 |
| 计划是标题和路由的唯一来源 | 检查关卡会将构建的HTML与计划进行对比 |
| 无动画统计计数器 | HTML在脚本运行前显示为0 |
| 关卡是脚本 | 脚本捕获的每个错误都曾经是人类遗漏的 |
参考资料
| 文件 | 在哪个阶段阅读 |
|---|---|
references/brief-intake.md | 阶段 1 |
references/site-plan.md | 阶段 2 |
references/design-and-copy.md | 阶段 4 和 阶段 6 |
references/seo-build-spec.md | 阶段 5 |
references/launch.md | 阶段 2（托管）和阶段 7 |