DeepSite V2实战：AI Agent驱动的可运行源码生成与部署

简介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 dockerLinux或在 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 serverup -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 208000是后端的默认端口/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_URLhttp://127.0.0.1:8000/v1 LLM_API_KEYsk-local-key LLM_MODELmy-model-tag LLM_TEMPERATURE0.2LLM_BASE_URL必须以/v1结尾因为兼容协议的所有接口都挂在/v1下比如/v1/chat/completionsLLM_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.2top_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 建站这件事最需要的不是更聪明的模型而是一套让你能复现、能回滚、能对比的工作流。希望帮到你。本文还有配套的精品资源点击获取