企业官网建设流程全解析

简介：DeepSite V2是一款基于DeepSeek大语言模型的开源AI建站工具，用户只需输入一句话或一组需求描述，即可在数秒内生成包含HTML、CSS与JavaScript的完整页面，极大降低网站开发门槛，适合前端开发者、产品原型设计师及零基础内容创作者使用。该工具集成了实时预览、细粒度局部修改、增量差异补丁、多模态素材支持和模型灵活切换等能力，从静态展示页到动态交互、3D动画均能应对。本次分享为可运行源码压缩包，zip格式共包含3个文件，主要以HTML网页源文件、inscode环境配置和gitignore版本控制文件构成，整体大小仅6KB，轻量易于部署和二次修改。读者可直接打开页面文件查看AI生成效果，也可结合源码结构理解自然语言到代码的转换实现，作为基于DeepSeek做前端应用开发的实战参考。当前已有297人学习下载，适合对AI辅助编程感兴趣的人群快速上手体验。

1. DeepSite V2 是什么：一套把"AI 生成网页"变成可运行源码的完整闭环

DeepSite V2 是一套开源的 AI 建站方案，它的核心不是"让模型写一段 HTML"，而是跑通"用户一句话 → 模型生成整站代码 → 沙箱真实验证 → 可预览可部署源码"这条流水线。你拿到的不只是效果截图，而是能改、能部署、能二次开发的真实工程，所以它被叫"可运行源码"是有道理的。它和你在聊天框里向 AI 要代码、再自己粘到编辑器的流程不同：这套系统把"生成、运行、报错反馈、再生成"全部自动化了，本质上是一个典型的 AI Agent 搭建案例。适合三类人：想快速验证产品想法但不想从零写脚手架的前端工程师；做外包时需要 AI 建站教程加速出 demo 的团队；以及想研究 Agent 闭环逻辑、打算自己封装类似工具的开发者。如果你只想看几眼炫酷的演示动画，那用不到它；如果你想在半小时内本地跑起来、并搞清楚背后每一条请求是怎么流转的，这篇可以带你走通全程。

2. 拉源码与本地跑通：先把 Docker 镜像和网络问题摆平

这一步的常见做法是两条路：一条是直接用 docker compose 把前后端和推理服务编排起来，另一条是先只拉源码包、在本地手动起。我的建议是先拉源码包而不是先拉镜像。原因很简单：源码建站项目里，镜像只是"运行态"，源码才是你能真正调试和改逻辑的地方。把目录结构读明白，后面所有排错都能按图索骥。

2.1 先解决镜像源与网络：pull 不动时从哪里绕

如果你选择先拉镜像，大概率会遇到 docker pull 卡住的问题。报错长这样：

error response from daemon: Get "https://registry-1.docker.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

这个报错的意思是 Docker daemon 访问默认的公共镜像仓库时，网络链路不通或 DNS 解析出来的地址不可达。常见解法是在 Docker daemon 配置里加镜像加速地址。修改/etc/docker/daemon.json：

{ "registry-mirrors": [ "https://docker.m.daocloud.io", "https://dockerproxy.com" ], "debug": false }

改完执行systemctl restart docker（Linux）或在 Docker Desktop 设置里重新加载。注意一点：镜像加速地址的可用性经常变动，不能用"配了就能永久用"的心态，长期不稳定时换一个即可。如果你在内网环境，优先确认能访问外网的出口，或者干脆绕过镜像、直接拉源码本地跑。

2.2 源码包结构：认清前端脚手架与后端任务循环

把源码包解压之后，用tree -L 2看一层结构，大致是这样：

deepsite-v2/ ├── docker-compose.yml ├── .env.example ├── server/ │ ├── app.py │ ├── agent/ │ │ ├── loop.py │ │ ├── prompts.py │ │ └── llm_client.py │ └── verify/ │ ├── check_html.py │ └── run_tests.sh ├── web/ │ ├── src/ │ ├── public/ │ └── vite.config.ts ├── sites/ └── README.md

具体文件名在各个 Release 里会有差异，但"前端脚手架 + 后端任务循环 + 落盘目录"这个结构在这类源码建站项目里基本是固定的。server/agent/是整个系统的核心：llm_client.py负责请求推理服务，loop.py是"生成-验证-反馈-再生成"的主循环，prompts.py里就是给模型看的系统提示词。web/是一个标准的前端构建工程，负责提供建站交互界面和预览沙箱。sites/是每次生成结果的输出目录。动手之前先把这三块认清楚，后面调试就知道该去哪一层看。

2.3 最小启动：环境变量、构建、启动一条龙

复制环境变量模板并编辑：

cd deepsite-v2 cp .env.example .env # 编辑 .env，至少改三处：LLM_API_KEY、LLM_BASE_URL、LLM_MODEL

.env里那三处是硬性要求：LLM_BASE_URL是推理服务的地址，注意要以/v1结尾；LLM_API_KEY填你推理服务的密钥，本地服务随意填一个非空字符串即可；LLM_MODEL填实际部署的模型名称。这三项不对，后面整个生成循环都跑不起来。

然后启动：

docker compose up -d --build docker compose logs -f server

up -d --build的作用是构建镜像并在后台启动容器。第一次构建会花几分钟，因为要装依赖；logs -f server是跟进后端日志，看到类似Uvicorn running on 0.0.0.0:8000的日志才说明后端起来了。如果在这一步就要等很久，多半是基础镜像拉取时卡在网络上，回到 2.1 节处理。

2.4 验证：端口探活、后端健康检查、进预览页

容器起来后不要急着在浏览器里操作，先用两条命令确认服务真实可用：

curl -s http://127.0.0.1:8000/health curl -s http://127.0.0.1:5173/ | head -n 20

8000是后端的默认端口，/health探活接口如果能返回{"status":"ok"}之类的内容，说明后端进程正常；5173是前端开发服务器的默认端口，返回 HTML 文本就是通的。此时再打开浏览器输入一句需求，比如"做一个深色风格的个人作品集首页"，观察是否出现"生成中 → 预览 → 可下载源码"的完整流程。如果卡在生成中，回到终端看后端日志，多数是推理服务地址不通或者模型名填错。

3. 任务循环与推理参数：AI 建站的"生成-验证-修正"是怎么转起来的

很多人在聊天框里让 AI 写代码时都遇到过"第一次生成很惊艳，一运行全是错"的情况。DeepSite V2 这类系统把这一步自动化了，靠的是任务循环：生成代码 → 沙箱运行 → 收集报错 → 带着报错再次请求模型 → 直到通过。这个循环不是玄学，它由几个明确的技术决策组成。

3.1 一次"写代码 + 自测"的完整数据流

整个流程从你按下"生成"开始，后端向推理服务发送一次标准的 chat/completions 请求。把请求体打印出来看，messages 结构大概是这样的：

[ { "role": "system", "content": "你是站点生成引擎。只输出可运行代码。" }, { "role": "user", "content": "做一个简洁的个人作品集首页，深色风格，包含头像、项目列表、联系方式" }, { "role": "assistant", "content": "```html\n<!DOCTYPE html>...上一轮生成的完整代码...\n```" }, { "role": "user", "content": "运行报错：Uncaught TypeError: Cannot read properties of null (reading 'appendChild')。请修复。" } ]

这里的逻辑要点是：第二轮请求把上一轮的代码原样塞回assistant角色，把运行时报错拼进新的user消息。这样模型能看到"自己写了什么"和"什么地方崩了"，修复才有依据。如果不回传代码，只传报错文本，模型会因为不知道当前代码长什么样而开始瞎猜，翻车概率大幅上升。

3.2 system prompt：让模型生成可运行代码的三条硬约束

任务循环的效果好坏，一半由系统提示词决定。我见过很多人在调这套源码时只改模型参数、不动 prompt，结果模型自由发挥，生成了依赖外部 CDN 的页面，沙箱一断网就白屏。常见做法是在prompts.py里写清楚几条不可妥协的约束：

You are a site generator. Strict rules: 1. Return a single HTML file with all CSS and JS inline. 2. Do NOT reference external images, fonts, or CDN resources. 3. Do NOT use experimental browser APIs or frameworks that require build steps. 4. If the task is ambiguous, pick a reasonable default and explain it in an HTML comment.

第一条约束单文件内联是沙箱能挂载运行的前提；第二条约束避免"生成时好看、离线就跑不动"；第三条约束防止模型生成依赖构建工具的 React/Vue 代码，因为沙箱里没有 node_modules；第四条注释约束能让你在出问题时知道模型的意图。这四条是血泪经验攒出来的：少一条，都可能遇到"生成了但永远跑不起来"的死循环。

3.3 参数怎么调：代码生成不是"越随机越好"

调用推理服务时，参数一般是这样的：

{ "temperature": 0.2, "top_p": 0.9, "max_tokens": 8192, "presence_penalty": 0, "frequency_penalty": 0 }

逐个解释：temperature是代码生成里最该压住的参数。调高了模型会"更有创造力"，但对代码生成来说就是灾难，它会编造不存在的标准库函数和属性。我一般把它压到 0.2 以下，保证每次生成风格稳定、可复现。top_p保留 0.9 就好，给模型留一点多样性，避免同一 bug 反复用同一种错误方式修复；max_tokens至少给 8192，一个带完整 CSS 和 JS 的页面很容易超过 4096 个 token，给短了会被截断成残缺文件，连 HTML 标签都闭合不了；presence_penalty和frequency_penalty必须设成 0，这两个惩罚项在文本创作里有用，在代码生成里会让模型刻意换词写变量名，导致上一轮报错里提到的变量在下一轮被改名，越修越乱。

3.4 会话与上下文截断：别把十五轮历史全塞给模型

任务循环跑了几轮之后，最直接的想法是把所有历史消息都发给模型，让它"吸取教训"。实际这么做会让效果断崖式下跌。模型上下文窗口是固定的，塞进去的旧内容越多，留给新代码和报错的空间越少；而且早期几轮的错误代码对修复当前 bug 没有参考价值。常见做法是只保留最近两轮往返外加当前报错：

def build_messages(system_prompt, history, last_error): recent = history[-4:] # 最近两轮：assistant 代码 + user 报错，共四条消息 return [ {"role": "system", "content": system_prompt}, *recent, {"role": "user", "content": f"当前运行报错：\n{last_error}\n请基于上一次的代码修复。"}, ]

这样做的另一个好处是省 token。接入付费推理服务后，上下文越长成本越高，而大部分历史对话都是噪音。一个干净的上下文就等于更快的响应速度和更精准的修复。

4. 换模型、换 API：兼容 OpenAI 协议的推理服务接入与鉴权配置

DeepSite V2 这类源码建站工具在设计上不会绑定某个特定厂商的模型，而是面向"兼容 OpenAI 协议"的推理服务做接入。这意味着你既可以用在线服务，也可以连本地部署的开源模型。切换模型不是改代码，而是改配置和做一轮连通性验证。

4.1 config 里到底要改哪几项

打开.env，真正影响推理的只有下面四项：

LLM_BASE_URL=http://127.0.0.1:8000/v1 LLM_API_KEY=sk-local-key LLM_MODEL=my-model-tag LLM_TEMPERATURE=0.2

LLM_BASE_URL必须以/v1结尾，因为兼容协议的所有接口都挂在/v1下，比如/v1/chat/completions；LLM_API_KEY不能留空，本地服务一般不做鉴权，但你随便填一个非空值即可，避免代码里因空字符串走异常分支；LLM_MODEL必须和推理服务里实际注册的模型名完全一致，不一致时推理服务会直接返回model not found。注意一个最常踩的坑：把密钥直接写死在 web 端的请求代码里。正确做法是密钥只放在后端环境变量中，前端只请求后端接口，绝不把LLM_API_KEY暴露到浏览器网络请求里。

4.2 本地模型服务的接入方式

如果你想把整套系统完全跑在内网，做法是先用一个本地推理服务把模型加载起来，再用上面的配置指向它。常见做法是直接用 Docker 起一个模型服务容器：

docker run -d --name local-llm \ -v $(pwd)/models:/models \ -p 8000:8000 \ your-local-inference-image \ --model /models/your-model-tag

-v把宿主机模型文件目录挂载进容器，-p 8000:8000把推理服务端口暴露出来，最后的参数指定实际要加载的模型权重。跑起来后不要急着接 DeepSite，先用 curl 验证协议层是通的：

curl -s -X POST http://127.0.0.1:8000/v1/chat/completions \ -H "Authorization: Bearer sk-local-key" \ -H "Content-Type: application/json" \ -d '{ "model": "my-model-tag", "messages": [{"role": "user", "content": "ping"}], "max_tokens": 32 }'

如果返回内容里带choices字段，说明协议兼容没有问题；如果返回 404 或not found，检查模型 tag 是否注册正确。这里我建议先在命令行把这一步调通再改 DeepSite 的配置，否则出了问题你很难判断是配置问题还是服务本身没起来。

4.3 交叉验证：同一个 prompt，两个模型跑一遍

接入多个模型之后，最值得做的一件事是交叉验证。不同模型在代码生成任务上的表现差异很大，有的擅长 HTML/CSS，有的在 JS 逻辑上靠谱。常见做法是把同一个 prompt 分别发给两个模型，结果存成不同文件做对比：

for m in model-a model-b; do LLM_MODEL=$m docker compose up -d server sleep 5 curl -s -X POST http://127.0.0.1:8000/generate \ -H "Content-Type: application/json" \ -d '{"prompt": "做一个三栏的 landing page，包含导航和联系表单"}' \ -o "result-$m.json" done

对比时的维度有三个：生成耗时、代码是否一次就能通过沙箱验证、报错后第二次修复的成功率。不要只看生成速度，一个"生成快但三句话就把它问倒"的模型远不如"生成慢但一次成型"的模型实用。我自己长期用下来的习惯是：主模型选生成稳的，备模型选速度快的，把温度参数分开调，不要一刀切。

5. 排错与避坑：我在这套源码上翻过的五个车

这一章把我在实际部署和调参过程中遇到的高频问题记下来。每一条都按"现象 → 原因 → 解决"的顺序写，你可以直接在终端对照排查。

5.1 docker pull 卡在 registry-1.docker.io/v2/，镜像一直拉不下来

现象：执行docker compose up后，构建过程反复卡住，日志里出现error response from daemon: Get "https://registry-1.docker.io/v2/": net/http: request canceled while waiting for connection。

原因：Docker daemon 访问默认公共镜像仓库的网络链路不可达，或者本机 DNS 把registry-1.docker.io解析到了不可用的地址。

解决：修改/etc/docker/daemon.json，加入镜像加速地址，然后重启 Docker：

{ "registry-mirrors": [ "https://docker.m.daocloud.io", "https://dockerproxy.com" ] }

改完执行systemctl restart docker，再重新docker pull试一次。如果依然失败，用nslookup registry-1.docker.io看解析结果，解析异常时换公共 DNS 再试。这个坑在内网机器上尤其常见，不要反复重试硬等，改配置比重试效率高得多。

5.2 内网推镜像到私有仓库失败：harbor 报 dial tcp /v2/ 连接失败

现象：执行docker push 192.168.x.x/library/ai-site:v1时报错：Get "https://192.168.x.x/v2/": dial tcp 192.168.x.x:443: connect: connection refused。

原因：Docker 客户端默认对仓库地址使用 HTTPS 协议，而内网私有仓库通常只提供 HTTP 服务，或者证书还没配置好。连接被拒绝不是网络不通，而是协议不匹配。

解决：把该仓库地址加入 Docker 的不安全仓库列表，在/etc/docker/daemon.json增加：

{ "insecure-registries": ["192.168.x.x:5000"] }

注意把x.x换成你实际的仓库 IP 和端口。修改后重启 Docker，重新docker login 192.168.x.x:5000再 push。如果公司要求走 HTTPS，则需要给仓库配置有效证书，然后把地址从insecure-registries里移除。这个坑验证了一件事：报错里带/v2/不代表仓库有问题，多数时候是客户端和仓库之间的协议协商失败。

5.3 容器起来了，前端预览一直 502

现象：docker compose ps显示所有容器都是 Up 状态，但浏览器打开前端页面后，预览区域一直转圈，接口请求返回 502。

原因：后端服务在容器内只监听了127.0.0.1，没有监听0.0.0.0。容器里的 127.0.0.1 是容器自己，宿主机和前端容器访问不到。

解决：检查后端启动命令，确保监听地址是0.0.0.0。在docker-compose.yml里对应服务的启动命令改为：

services: server: command: > uvicorn app:app --host 0.0.0.0 --port 8000

改完重启容器再访问。这里也建议顺手加一条healthcheck，在 compose 里用 curl 探活，容器起来了但端口不通的情况在日志里就能提前暴露。

5.4 生成结果在沙箱能跑，部署到服务器就白屏

现象：AI 生成的页面在 DeepSite 的预览沙箱里显示完全正常，下载源码后部署到自己的服务器，打开是白屏，控制台报一堆资源加载失败。

原因：生成代码里把资源地址写死成了localhost或沙箱环境的绝对路径，换到服务器后自然全部失效。

解决：这类问题要从源头堵。在系统提示词中强制加一条约束："所有资源引用必须使用相对路径，禁止硬编码主机名和端口号"。同时配合 Nginx 做同源反向代理，把前端和 API 放在同一个域名下：

location /api/ { proxy_pass http://127.0.0.1:8000/; proxy_set_header Host $host; }

这样生成代码里的/api/xxx请求走 Nginx 转发到后端，不依赖具体 IP 和端口。预览沙箱和真实部署环境的差异是这类源码建站工具永远存在的边界，部署前先确认资源路径这一条能省掉你大量排查时间。

5.5 越想让它"聪明"，结果反而越差

现象：生成效果不理想，于是把temperature从 0.2 调到 0.8，又把对话历史从最近 4 条改成全部发送。结果页面风格变乱了，JS 逻辑开始出现低级错误，修了三轮都没把一个空白页的问题解决掉。

原因：参数调整方向错了。代码生成任务需要的是稳定性和确定性，不是"多样性"和"创造力"。高温会让模型在变量命名、函数调用上开始"自由发挥"，破坏之前代码的上下文一致性；全量历史则把上下文窗口撑满，导致最近一次报错信息被截断丢弃。

解决：把temperature拉回 0.2，top_p保持 0.9，上下文按 3.4 节的"最近 N 轮 + 当前报错"方式截断。改完对比同一 prompt 的生成结果，质量会明显回稳。记住这条经验：当 AI 建站效果变差时，先检查上下文有没有被截断，再检查温度有没有被调高，而不是盲目换更大的模型——参数玄学的根源往往是这两处的叠加。

6. 让 AI 建站结果更可用的三个小技巧

第一个技巧是用"骨架 + 分块"代替"一句话整站"。"做一个电商网站"这种 prompt 生成的结果一定是大杂烩：布局、文案、交互全都塞在一起，任何一个环节出错都得整站重来。我现在的做法是拆成三轮：第一轮只生成页面骨架，包括布局结构和样式变量；第二轮填业务内容和交互逻辑；第三轮做视觉润色。每轮结果都单独落盘，翻车时只需要重跑对应的一块，不用从零再来。

第二个技巧是给生成结果加一道自动自测。预览沙箱能跑通不代表逻辑完全正确，把生成代码保存后，用脚本做静态检查：

#!/usr/bin/env bash # verify.sh：对生成结果做基础可运行性检查 for f in sites/*/index.html; do echo "check $f" grep -q "</html>" "$f" || echo "WARN: missing closing html tag in $f" node --check "${f%.html}.js" 2>/dev/null || true done

这个脚本不做魔法级验证，只查两个底线：HTML 标签闭合，以及 JS 语法能通过解析。脚本输出有 WARN 的文件，再去人工看具体问题。这个小习惯能拦住大量"看着正常、部署必挂"的翻车现场。

第三个技巧是把每次生成的 prompt、参数和输出一起存档。我会按时间戳建目录，记录本轮用的模型、温度和 system prompt 版本：

mkdir -p archives/$(date +%Y%m%d-%H%M) cp .env "archives/$(date +%Y%m%d-%H%M)/env-backup" cp -r sites/* "archives/$(date +%Y%m%d-%H%M)/output/"

事后对比存档，往往能发现"效果好的那次"和"效果差的那次"只差了一个参数。我最初觉得这很麻烦，但连续三次因为找不到当时的配置而被迫重跑之后，这个存档习惯就成了固定动作。回头看，AI 建站这件事最需要的不是更聪明的模型，而是一套让你能复现、能回滚、能对比的工作流。希望帮到你。

本文还有配套的精品资源，点击获取