鱼皮AI导航
鱼皮AI导航
  • 主页
  • 社区
  • AI工具
  • AI知识库
  • AI提示词
  • MCP
  • Skills
  • AI学习资源
  • AI资讯
  • GitHub开源
登录/注册
站长:程序员鱼皮 老鱼简历 商务合作 增值电信业务经营许可证
2026 鱼皮AI导航 | 沪ICP备19026706号-6
32
26
43

我把 AI 零代码项目上线并改造了

千夜之詩
千夜之詩
2026-06-05 01:00
阅读 6400
千夜之詩
2026-06-05 01:00
阅读 6400

我把 AI 零代码项目上线并改造了

半年多前,我跟着 AI 零代码应用生成平台 完成了项目的大部分功能并上线了。教程版本已经跑通了从自然语言描述到代码生成、预览和部署的基本流程。最近闲来无事,我又重新捡起这个项目,从界面、生成过程、代码查看、React 构建和线上稳定性等方面做了几轮改造。

在线体验:https://zerocode.1000ye.top

GitHub 后端仓库:https://github.com/X1aoM1ngTX/zerocode-backend

Vexor-HomePage.png

Vexor 首页:输入一段应用描述,就可以开始生成项目。

这篇文章不准备逐行讲代码,主要记录我为什么要做这些改动、具体是怎么处理的,以及项目从“能运行”到“能上线”过程中遇到的一些实际问题。


先把前端界面重新整理了一遍

最早的页面主要围绕功能实现,能用,但整体比较像后台管理系统。不同页面的布局、颜色和交互方式也不够统一,用户从首页进入应用生成页面时,会有比较明显的割裂感。

这次调整前端时,我没有一开始就让 AI 直接修改代码,而是先整理了一张比较粗糙的草图。草图里不关注字体、颜色和间距,主要标出每个页面需要展示什么,以及不同区域之间的关系:

  • 首页需要突出应用描述输入框和常用模板
  • 登录、注册和重置密码页面保持统一
  • 应用生成页面采用左右布局,左侧负责对话,右侧负责预览和代码
  • “我的作品”和“精选案例”复用相同的卡片布局
  • 顶部导航在主要页面中保持一致

Vexor-PreDesign.png

最开始整理的页面草图,重点是确定信息结构和功能区域。

有了草图后,我把它交给 ChatGPT,让它根据现有品牌 Logo、蓝紫色主色调和 AI 产品的定位生成一版更完整的视觉设计。生成的设计图补充了字体层级、卡片样式、背景效果和深色应用工作区,也让我能在真正改代码前先判断整体方向是否合适。

Vexor-ChatGPT-Design.png

ChatGPT 根据草图生成的视觉方案,包含首页、认证页面和应用工作区。

设计方向确定后,我再把草图、设计图和现有项目代码一起交给 Codex,让它按照 Vue 3 和 Ant Design Vue 的现有结构逐步落地。这个过程中并不是直接照着图片还原,而是需要结合真实功能继续调整:

  • 将设计图中的颜色、圆角和阴影整理成全局 CSS 变量
  • 保留已有接口、权限判断和页面路由,避免只改外观却破坏功能
  • 把重复的加载状态、空状态和错误处理整理成公共组件与组合式函数
  • 根据真实内容长度调整布局,并补充移动端适配
  • 将应用生成页的对话、预览和代码区域接入实际数据

这套流程里,草图负责表达我的想法,ChatGPT 帮助探索视觉方向,Codex 则负责结合现有代码完成实现。最终页面没有完全照搬设计图,但整体布局和视觉风格有了统一的参考,也减少了边写代码边反复试样式的时间。


增加提示词优化和文生图

很多用户第一次使用 AI 生成应用时,只会输入一句比较简单的描述,比如“帮我做一个个人博客”。这种表达没有问题,但里面缺少页面结构、视觉风格和具体功能,模型只能自行猜测,最后生成的结果往往比较普通,也未必符合用户真正想要的方向。

所以我在首页和应用对话页增加了提示词优化功能。用户输入简单想法后,可以先让单独的提示词优化模型补充页面组成、交互方式和设计要求,再决定是否使用优化后的内容开始生成。

例如,“帮我做一个个人博客”可以被补充为包含首页、文章列表、文章详情、分类筛选、响应式布局和视觉风格的完整需求。它不是替用户决定所有细节,而是帮助用户把脑海里比较模糊的想法表达清楚。

这部分使用了独立的系统提示词和模型配置,没有直接占用代码生成模型的上下文。优化完成后,结果会回填到输入框中,用户仍然可以继续修改,而不是立刻开始生成。

相关实现主要在:

▼
text
复制代码
vexor-frontend/src/pages/HomePage.vue vexor-frontend/src/pages/app/AppChatPage.vue vexor-backend/src/main/java/com/xm/vexorbackend/ai/PromptOptimizerService.java vexor-backend/src/main/resources/prompt/prompt-optimizer-system-prompt.txt

除此之外,项目还接入了阿里云 Z-Image-Turbo,增加了单独的文生图页面。除了正向提示词,页面还支持负向提示词、图片尺寸和随机种子等参数,方便重复生成或控制结果。

Vexor-ImageGen.png

文生图页面会同时展示当前提示词、生成参数和最终图片。

文生图接口调用成本比较高,也容易被频繁请求,因此后端给这个接口增加了登录校验和 IP 限流。目前同一个 IP 每小时最多生成 8 张图片,避免接口被持续调用后产生不可控的费用。


让代码生成过程真正“看得见”

最近一次改动最大的地方,是应用生成页面。

之前生成代码时,如果生成的是 Vue 或 React 项目,AI 的回答和代码内容会混在一起返回。一条消息中可能同时包含项目说明、十几个文件的路径以及完整代码,数据量很容易超过 MySQL TEXT 字段的存储上限,最终导致聊天内容被截断或保存失败。

即使成功保存,把所有代码都塞进聊天记录也不方便使用。用户需要在一段很长的 Markdown 中反复滚动,才能找到某个组件;刷新页面后,前端还要重新渲染整段代码,消息越多,页面越容易卡顿。

这次改造的思路,是把“聊天内容”和“项目文件”分开处理:

  • 聊天区域只展示生成计划、执行过程和简短说明
  • AI 生成的代码直接保存到对应应用的项目目录
  • 前端需要查看代码时,再通过文件接口按需读取
  • 文件发生创建、修改或删除时,通过流式事件及时更新页面

这样一来,数据库不再承担保存整套项目源码的工作,聊天记录也更容易阅读。代码则按照真实项目结构保存在磁盘中,后续构建、部署和下载都可以直接复用这些文件。

现在应用页面增加了独立的代码工作区。左侧文件树展示项目目录结构,右侧显示当前选中的文件内容。点击不同文件时,前端只请求对应文件,并根据 .vue、.tsx、.css 等扩展名判断语言,再通过 highlight.js 进行语法高亮。

Vexor-Chat-Code.png

应用生成页面可以同时查看 AI 回复、项目文件树和具体代码。

前端的文件树使用递归组件实现。目录节点可以展开和收起,文件节点会记录完整相对路径;图标则按照文件名、扩展名和目录名称匹配,让 Vue、React、TypeScript、样式文件和配置文件更容易区分:

▼
text
复制代码
vexor-frontend/src/components/AppFileTreeNode.vue vexor-frontend/src/pages/app/AppChatPage.vue

后端则增加了单独的文件服务,用来扫描应用目录、组装树形结构和获取文件内容:

▼
text
复制代码
vexor-backend/src/main/java/com/xm/vexorbackend/service/AppFileService.java vexor-backend/src/main/java/com/xm/vexorbackend/service/impl/AppFileServiceImpl.java vexor-backend/src/main/java/com/xm/vexorbackend/model/vo/AppFileNodeVO.java vexor-backend/src/main/java/com/xm/vexorbackend/model/vo/AppFileContentVO.java

读取文件看起来很简单,但实际还需要处理一些边界问题:

  • 校验当前用户是否有权查看对应应用
  • 将用户传入的相对路径解析到应用目录下
  • 阻止 ../ 等路径穿越,避免读取服务器上的其他文件
  • 忽略 node_modules、构建产物等没有必要展示的目录
  • 对文件不存在、读取失败等情况返回明确错误

拆分之后,聊天、代码查看、项目构建和部署各自负责自己的事情,整个生成页面也更接近一个简单的在线开发环境,而不再只是一个展示 AI 回复的聊天窗口。


把流式回复改成更明确的生成事件

AI 生成一个完整项目通常需要几十秒,复杂项目还要等待依赖安装和构建。如果前端在这段时间里只显示一个加载动画,用户很难判断 AI 还在工作、构建正在进行,还是连接已经断开。

为了解决这个问题,我没有只把回复文本逐字推送到前端,而是在原来的 SSE 流式接口上增加了一套生成事件。后端在执行不同操作时发送对应消息,前端则根据事件类型更新聊天区域、代码内容、文件树和预览状态。

目前主要包括这些事件:

▼
text
复制代码
assistant_message AI 正在回复 tool_call AI 正在调用工具 file_start 开始生成文件 file_delta 文件内容更新 file_done 文件生成完成 file_delete 删除文件 build_status 项目构建状态 preview_ready 预览已经可用 generation_error 生成失败 done 全部完成

Vue 和 React 项目主要通过文件工具创建和修改代码,工具执行时可以直接转换成对应事件。HTML 和原生多文件项目的返回格式不同,代码仍然包含在模型持续输出的 Markdown 文件块中,因此后端又增加了一个文件块流式解析器。

这个解析器不能简单地按每次收到的字符串查找代码块,因为模型返回的一个 chunk 可能只包含半行内容,甚至刚好截断在文件路径或代码块标记中间。它需要保留尚未解析完成的内容,识别完整文件块后,再依次生成 file_start、file_delta 和 file_done 事件,并把代码保存到磁盘。

这部分主要修改了:

▼
text
复制代码
vexor-backend/src/main/java/com/xm/vexorbackend/ai/model/message/ vexor-backend/src/main/java/com/xm/vexorbackend/core/AiCodeGeneratorFacade.java vexor-backend/src/main/java/com/xm/vexorbackend/core/handler/FileBlockStreamParser.java

前端收到文件事件后,会实时更新当前代码和已生成文件列表;收到构建状态后,会提示正在构建 Vue 或 React 项目;收到 preview_ready 后,再刷新右侧预览。连接异常和业务异常也会单独处理,避免把正常结束误判成生成失败。

改完以后,用户不需要一直盯着加载动画,可以看到 AI 正在创建哪个文件、项目是否正在构建,以及预览什么时候可以打开。对我自己来说,这套事件也让排查生成失败变得简单了很多,因为问题发生在哪个阶段会更加清楚。


增加 React 项目支持,也遇到了真实的构建问题

项目原本支持 HTML、原生多文件和 Vue 项目,后来我又增加了 React 项目支持。用户不需要手动选择所有情况,后端会先根据需求判断合适的生成类型,再调用对应的系统提示词、文件工具和构建器。

Vexor-Chat-Preview.png

AI 生成并构建完成的 React 2048 项目,可以直接在右侧预览。

React 支持涉及的主要目录包括:

▼
text
复制代码
vexor-backend/src/main/resources/prompt/codegen-react-project-system-prompt.txt vexor-backend/src/main/java/com/xm/vexorbackend/core/builder/ReactProjectBuilder.java vexor-backend/src/main/java/com/xm/vexorbackend/ai/tools/

Vue 和 React 与普通 HTML 最大的区别,是代码生成完成并不代表可以立即预览。后端还需要在项目目录中执行 npm install 和 npm run build,确认生成了 dist 目录后,才能提供静态预览。

这部分在本地开发时比较顺利,但部署到 2 核 2G 的服务器后,问题很快出现了。

有一次生产环境中 AI 生成的数学函数网站 React 项目引入了体积较大的 mathjs。安装依赖和打包过程持续占用 CPU 与内存,不仅连续触发构建超时,还让同一台机器上的 Spring Boot、Redis 和 MySQL 得不到足够资源,最终导致整个后端响应异常。

针对这个问题,我对 React 构建流程做了几项调整:

  • 将安装和构建超时时间都增加到 10 分钟
  • 通过 NODE_OPTIONS=--max-old-space-size=512 限制 Node.js 内存
  • 构建完成后检查 dist 目录是否真的生成
  • 兼容 Windows 下的 npm.cmd

这些调整缓解了当前服务器上的问题,但并没有彻底解决资源竞争。AI 生成项目和普通业务接口不太一样,它会执行依赖和复杂度都不完全可控的构建任务,资源消耗可能突然变大。长期来看,构建任务最好进入独立队列,并与业务服务分开部署。


上线以后,开始处理稳定性问题

本地开发时,请求基本都来自自己,很多问题不容易暴露。项目真正部署到公网后,创建应用、生成代码、部署、下载和文生图等接口都有可能被连续调用,而这些操作背后的成本差别很大。

为此,我在后端增加了基于 Redisson 的注解式限流。接口可以按照 API、用户或 IP 三种维度设置频率,例如限制单个用户短时间内创建应用和部署的次数,也可以按照 IP 控制文生图调用量。

▼
java
复制代码
@RateLimit( limitType = RateLimitType.USER, rate = 2, rateInterval = 600, message = "部署过于频繁,请10分钟后再试" )

使用注解的好处是限制规则能够直接写在接口旁边,不需要在每个 Controller 中重复处理。创建应用、提示词优化、代码生成、部署、下载和文生图接口目前都根据实际消耗设置了不同规则。

除了限流,最近几次修改还处理了全局异常返回、网页截图和 AI 流式响应中的稳定性问题。它们没有新页面那么直观,但上线以后,错误能否被正确捕获、连接能否正常结束、服务会不会被单个高消耗任务拖垮,反而更影响实际体验。


从 ZeroCode 改名为 Vexor

项目最开始直接使用 ZeroCode 作为名称。随着界面和功能逐渐形成自己的样子,所以我又使用 ChatGPT 重新设计了 Logo,并把项目名称改成了 Vexor。前后端包名、页面文案、图标和相关配置也做了对应调整。

Vexor-LOGO.png

不过线上域名目前仍然使用:

zerocode.1000ye.top

域名暂时保留了项目最开始的名字,一方面避免重新调整已经部署好的地址,另一方面也算记录了它从项目一路改造过来的过程。


最后

这次改造让我感受最深的一点是:把功能做出来和把项目真正上线,中间还有很长一段距离。

模型调用只是整个流程中的一部分。用户能不能理解当前生成进度、代码应该保存在哪里、文件接口是否安全、构建任务会不会拖垮服务器、失败时能不能给出明确提示,这些看起来不那么亮眼的小细节,最后都会直接影响项目是否真的可用。

目前 Vexor 还在继续完善,可视化编辑、构建隔离、生成质量和部署流程都有优化空间。不过相比最初只能生成和预览代码的版本,它现在已经更接近一个可以实际使用的 AI 应用生成平台。

如果你对它感兴趣,可以直接打开 zerocode.1000ye.top 体验,也欢迎查看 GitHub 后端仓库 和 GitHub 前端仓库。

1000ye.png

Java
AI
AI 零代码应用生成平台
AI编程
32
43
分享
操作
评论
相关内容
0个评论
全部评论
点击登录,快来和大家讨论吧~
表情
图片

目录

🔥 热门文章
1
离谱,DeepSeek 崩了 5 小时,大家却喊:梁圣恩情还不完??
450
2
B 站上 DeepSeek 闹鱼灾了,我发起《大肥鱼清除计划》!
410
3
DeepSeek 全新模型发布,性价比最高的一集!
410
4
自己学习ai,直接买cursor 的套餐,还是买gpt 或者claude 的套餐?
370
5
又一个国产版 Codex 神器,也来卷办公了!
340
6
Vibe Coding 实战:从零构建现代专业级 AI 搜索引擎
330
7
day3-如何写出一个高质量的 Skill(组内分享) 高质量 Skill 不是“一个调得很顺的巨型 Prompt”,而是一个可验证、可回归、可维护的能力包。 先定义“什么算好”,再实现“怎么做好”。评估体系先于 Skill 本身成型。 下面用“故障诊断 Markdown 转 YAML”作为例子,但方法是通用的。 --- 一、先想清楚:Skill 到底是什么 一个 Skill 至少包含四部分: 部分 作用 接口 输入什么、输出什么、边界在哪 流程 分几步做,每步的产物是什么 规则 硬约束、经验规则、失败模式 降级策略 不确定时怎么办,而不是硬编一个看似合理的结果 高质量 Skill 的共同点:职责单一、接口清晰、规则可定位、输出可验证。 反例:把几十条经验全塞进一个主 Prompt,改一条规则要重调整个 Prompt,评估时也不知道是哪条规则退化。 --- 二、核心方法:先建评估,再写 Skill 不要先写转换器再补测试。正确顺序是: 1. 定义输出契约:什么算合法、什么算合格; 2. 建金标准集:一小批人工认可“可放行”的样本; 3. 先写评估 Skill:让它在金标准集上跑出基线; 4. 再迭代生成 Skill:每次修改跑同一套评估,无退化且目标维度提升才算正向。 这就是评估驱动开发:评估是 Skill 的单元测试,金标准集是回归锚点。 --- 三、评估 Skill:三层门禁,逐层递进 前一层不过,后一层不跑。每层留可追溯证据。 第 1 层:确定性硬门禁 用解析器、Schema、校验器完成,不消耗模型成本。 · 输出可解析; · 必填字段齐全,类型/枚举合法; · 引用目标存在,无悬空引用、无不可达节点; · 关键路径至少有一条能到达预期出口。 不通过直接打回。 第 2 层:语义断言 用脚本 + 结构遍历检查“逻辑对不对”,仍然保持确定性。 通用检查项: · 覆盖率:源材料里的关键步骤、分支、条件,输出里是否都有对应? · 完整性:每个判断节点是否都有明确出口?有没有死胡同? · 可达性:每条路径是否都能到达预期终点?有没有无出口循环? · 顺序与依赖:有先后依赖的操作,是否保留了顺序?有没有被拍平成无序列表? 例子:故障诊断转换中,检查“每个判断项是否有是/否/异常出口”“每条路径是否能到根因”。 第 3 层:LLM-as-Judge 只处理解析器表达不了的维度:忠实度、完整性、可执行性。 但 Judge 会漂移,不能单独放行,必须建立在第 1、2 层之上。Judge 的 Prompt、rubric、模型版本都要版本化,换模型必须用金标准集重新校准。 通用 Judge 维度: 维度 问什么 忠实度 输出是否忠实源材料意图?有没有自行发明内容? 完整性 关键步骤、条件、证据是否保留?隐式知识有没有被压成空话? 收敛性 输出是否仍指向原目标,而不是发散? 可执行性 下游不依赖源材料能否直接使用? --- 四、金标准集:回归测试的锚点 不需要一开始就标注几百份。用已认可的样本当种子,扩到 15~30 份,覆盖失败模式而非随机抽样: · 完整正例:典型流程; · 边界/异常分支:异常路径、循环、前置失败回退; · 已知易错模式:实际踩过的坑; · 留出集:不参与调优,只用于最终验收,防过拟合。 金标准不需要完美,只需要当前标准下认可可放行。 回归指标:关键路径用 pass^k(k 次全过),稳定性用 pass@k。 --- 五、工程约束:让批量产出可重放 · 幂等:同输入 + 同 Skill 版本 + 同规则 → 输出一致,否则无法判断变好是 Skill 改了还是随机波动; · 隔离不阻断:单份失败进隔离队列,记录失败层和原因,不阻塞其余; · 版本绑定:规则、rubric、金标准集进 Git;每份报告绑定“源版本 + 生成 Skill 版本 + 评估 Skill 版本 + Judge 模型版本”; · 抽样人工复核:Judge 临界样本 + 易错模式,人工抽检结果反过来校准 rubric。 --- 六、Skill 本身怎么写 · SKILL.md 控制篇幅,写清:输入约定、输出契约、分步流程、硬规则、降级策略; · 经验规则放 references/ 或 rules/,按失败模式分类,不要全塞进主 Prompt; · 不确定时标 needs_review: true,不要硬编看似合理的结果; · 迭代由评估报告驱动:报告告诉你哪层挂了、哪类失败模式,你改对应规则文件,而不是漫无目的调 Prompt。 --- 七、落地顺序(不要反过来) 1. 固化输出契约:Schema + 结构约束; 2. 建金标准集:从已认可的 + 最易出错的样本开始; 3. 先写评估 Skill:跑出基线报告; 4. 再迭代生成 Skill:每次修改对比逐项通过率,无退化且目标提升才算正向; 5. 批量运行 + 隔离回放:失败进队列,结束后人工抽检; 6. 评估 Skill 自身版本化:换 Judge 模型必须重新校准。 --- 八、给组员的三条硬要求 1. 不许凭感觉说“变好了”:每次修改必须附评估报告对比,逐项通过率说话。 2. 不许跳过确定性门禁直接看 Judge 分数:前两层挂了,Judge 分数没有意义。 3. 不许把规则堆进主 Prompt:规则按失败模式分文件,评估报告要能定位到具体文件。 --- 一句话收尾 生成 Skill 决定“能不能做”,评估 Skill 决定“敢不敢用”。 先让评估体系站稳,再让生成器迭代。这样交付的不是一堆“看起来还行”的产出,而是一套可证明、可回归、可交接的 Skill 质量体系。
320
8
我的第一个出海产品!7 天 2 万
310
9
WorkBuddy 本地 API 桥 + dsh 插件:把你的 WorkBuddy 额度,变成手边随手可用的模型
310
10
什么是LLM
300
🔥热门工具
朱雀AI检测朱雀AI检测
朱雀AI检测助手朱雀AI检测助手
LovartLovart
老鱼简历老鱼简历
WritePass官网WritePass官网
面多多面多多
CursorCursor
星月写作星月写作
零感AI零感AI
墨得问题墨得问题