上周搞了一个小版本用来参赛，但感觉样式不好看，所以重新设计了一版。从Logo设计，到原型图，到html界面交互，再到前端界面，花了不少时间。虽然AI的出现带来了便利，但如何设计良好的界面，界面之间如何交互，还是需要我们自己去思考。原型图初步生成的时候，也需要继续打磨修改。对于logo，原型图生成，建议使用chatgpt。之前在设计logo的时候我用过豆包，用过即梦等，但生成的图片总感觉差强人意，即便是gemini生图，也感觉差了一点意思。使用chatgpt感觉好了很多。但chatgpt官网对于免费用户每天有少量额度，超过了要到第二天同一时间再使用，我是用免费额度生成的。原型图设计好后，可以通过gemini根据原型图生成html交互页面，但是感觉gemini对生成的html长度有限制，超过一定大小比如41kb就会影响其他功能了,可能是因为我是免费用户有关。html页面生成好后，需要把html转为前端界面。由于我是开发小程序，需要考虑是用原生技术框架还是使用unibest框架，想着以后便于其他终端扩展，所以决定使用unibest框架。其实原型图和html交互设计好后，后面的前后端基本都可以交给AI工具来完成了。为此，昨天忍痛充了20刀使用cursor，希望借助cursor来完成编码。之前使用qoder比较多一些，qoder分国际版和国内版，国际版可以使用国外大模型，国内版就只能使用国内模型。qoder国际版感觉还可以，国内版感觉一般般。但是qoder国际版现在pro会员也是20刀/月，和cursor一样，所以我充了cursor体验一番。其他编程工具比如codebuddy也使用过，量大管饱，之前使用GLM-5.1比较多，感觉用来做普通编码问题不大。cusor我使用composer 2.5模型让它根据我提供的html原型，使用unibest框架给我生成小程序。在此之前，需要先安装node,pnpm,然后通过pnpm初始化一个unibest的脚手架，后续基于脚手架进行开发，这些在unibest官网有介绍:https://www.unibest.tech/base/2-start
让cusor使用unibest脚手架生成小程序的提示词如下（可以借助豆包帮忙生成）：我当前项目是基于 unibest 搭建的微信小程序，你现在需要基于 unibest 企业级脚手架，直接在现有项目架构下开发即可。把我提供的HTML原型页面完整复刻为小程序页面，实现视觉1:1还原、交互完全对齐、代码工程化、预留后端接口对接能力，请严格遵守下面所有规则：# 一、项目基础信息 & 固定技术栈项目：XXXX微信小程序框架：unibest（底层 uni-app）技术栈：Vue3 + TypeScript + Vite5 + Pinia + uView Plus 组件库 + UnoCSS 原子样式运行目标：仅微信小程序，使用 unibest 原有工程配置、目录结构、请求工具，不新增额外依赖。# 二、样式&视觉复刻要求（对标HTML原型）1. 严格 1:1 还原 HTML 原型的布局、配色、尺寸、圆角、阴影、字体、间距、图标、排版；2. 布局使用 uni-app 标准标签 + Flex，全面适配移动端不同机型；3. 样式优先使用 UnoCSS 原子类，自定义样式统一写在 scoped 内，尽量精简4. 弹窗、浮层、底部操作栏、进度条等特殊组件样式完全对齐原型。# 三、目录与文件规范（必须遵循 unibest 现有结构）1. 页面：src/pages/[页面名]/index.vue，文件路由遵循 unibest 自动路由规则；2. 公共组件：可复用的题目卡片、选项组件、解析弹窗、底部按钮栏，全部抽离到 src/components/；3. 类型定义：在 src/types/ 新建对应 ts 文件，统一接口返回等所有 TS 类型；4. 全局状态：页面全局数据XXXX，全部使用 Pinia 管理，Store 文件放置 src/stores/；5. 接口层：所有网络请求统一放到 src/api/，按业务拆分（首页接口、用户接口、内容展示接口等）。# 四、业务逻辑要求1. 支持XXXX逻辑：2. 实现功能：XXXX；3. 支持查看XXXX功能；4. 页面切换、数据变更逻辑统一交给 Pinia 管理，保证多页面数据共享不丢失；5. 所有业务数据先用本地 Mock 数据调试，数据结构和后端接口出参保持一致。# 五、后端接口对接规范（核心，方便后续联调）1. 复用项目自带 src/utils/http 统一请求实例，使用已有的请求拦截、响应拦截；2. 所有接口拆分到 src/api 下，每个接口单独编写 TS 入参、出参类型；3. 接口语义化命名：获取题库列表、提交答题答案、获取错题、获取收藏题目等；4. 请求方式规范：查询类用 GET，提交、保存、操作类用 POST；5. 代码中**明确预留接口调用位置**，添加注释说明接口地址、作用、字段含义，后续只需替换接口地址即可对接真实后端；6. 接口返回统一约定格式：包含 code、message、data 三层结构，做基础状态判断。格式如下：{ "code": number, // 状态码：200成功 / 非200失败 "msg": string, // 提示信息 "data": any // 业务数据主体}# 六、编码语法与规范1. 全部使用 Vue3 <scriptsetuplang="ts"> 组合式语法，禁止旧式选项式API；2. 命名规范：文件、变量、函数均使用小驼峰，命名语义清晰；3. 复杂逻辑、接口位置、状态处理添加中文注释；4. 代码分层清晰：模板层、状态层、接口层、工具层分离；5. 代码具备可扩展性。# 七、输出内容要求1. 依次输出：TS 类型文件、Pinia 状态仓库文件、API 接口文件、公共组件文件、主页面 vue 文件；2. 每段代码标明文件存放路径；3. 生成Read.md文档，说明：启动方式、用到的技术栈，Mock 数据替换为真实接口的步骤、重点交互说明。4. 生成API.md文档，说明用到的接口名称、参数、参数类型、请求方式等，方便后续后端联调统一文档结构：接口名称、请求地址、请求方式、请求参数、返回示例、字段说明、业务备注
编译后，即可使用微信自带的工具打开生成的项目代码看效果。在调试界面的时候，有的样式不好看，想着换其他模型，发现有的模型有限制使用区域不能用，当时想那我岂不是白充了20刀。后来通过界面设置（将HTTP/2改为HTTP/1.1）：重启cursor，施展一下爱的魔力转圈圈，然后就可以使用了：目前主要完成了原型设计、交互，到前端界面生成，后端还未完成。等全部完成后再来看一下效果。技术工具一直在迭代，AI 确实大幅降低了开发与设计的门槛，但创意、审美和逻辑思考，依旧是无法被替代的核心。整个项目改版下来，试过不少工具，也踩了大大小小的坑，好在最后都顺利解决。AI 是很好的帮手，但想要做出满意的作品，还是离不开自己反复打磨。如果大家也在用这些工具做开发，有问题或者好用的技巧，欢迎在评论区留言交流呀！
夜雨聆风
