当前位置：首页 > news >正文

AI实战之小程序-别急着写页面，先把Uniapp工程骨架搭稳

news 2026/6/3 7:26:39

摘要：本文强调小程序开发应先搭建工程骨架而非直接堆砌页面。以Uniapp项目为例，核心需先完成：1）规范化目录结构与分包路由；2）统一请求层封装与错误处理；3）明确定义ApiResponse/PageResult类型；4）固定TabBar信息架构。通过pages.json配置和业务域API分层（如modules目录），确保后续开发边界清晰。关键要避免AI常见误区：直接实现业务功能而忽略基础设施统一，最终目标是建立可迭代的工程底座，避免后期因架构问题返工。（98字）

做微信小程序时，第一步不是先堆页面，而是先把基础工程搭稳。Sourcelin Blog 这次的 Uniapp 版本也是一样：如果路由、分包、请求层、统一类型、TabBar 和基础规范没有先定住，后面阅读闭环和互动闭环会越做越乱。

这一层工作看起来没有首页、详情页那么显眼，但它决定了项目后面会不会越来越像“能跑起来的拼装站”。我现在越来越觉得，小程序工程里最值钱的一步，不是某个页面特别好看，而是它是不是已经把后续开发的轨道铺好了。

这个阶段在产品文档里到底要求什么

产品文档里对“基础框架”的定义很明确：要完成 Uniapp 项目目录、pages.json、manifest.json、环境变量配置、统一请求封装、通用类型以及首页/发现/社区/我的四个 TabBar 页面。这一阶段的价值不是“看起来功能很多”，而是让后面的页面、接口和状态管理都有明确边界。

对应到实际工程，就是这几类东西必须先站住：

页面路径和分包结构
TabBar 信息架构
请求层和统一错误处理
ApiResponse<T>/PageResult<T>类型
登录态注入和 401 跳转

当前仓库里哪些东西能证明骨架已经站住

从当前仓库看，M1 的骨架已经具备比较清晰的结构：

src/pages/** # 四个 Tab 页面 src/pages-article/** # 文章详情、列表、搜索 src/pages-user/** # 登录、资料、收藏、关注 src/pages-messages/** # 消息中心 src/modules/** # 业务域 API、types、composables src/utils/request.ts # 统一请求入口 src/shared/types/api.ts # ApiResponse / PageResult

这说明工程底座已经从“新建项目”走到了“可以持续迭代”的状态。

pages.json里也已经把四个主入口和分包页面收住了：

{"pages":[{"path":"pages/home/home"},{"path":"pages/discover/discover"},{"path":"pages/community/community"},{"path":"pages/mine/mine"}]}

这里最重要的不是字段本身，而是首页、发现、社区、我的这条主路径已经固定，后面功能再扩，也不会把信息架构反复推倒重来。

请求层为什么一定要先统一

这一阶段最重要的工程取舍，是坚持按业务域拆目录，而不是把页面、接口、状态和工具函数混在一起。小程序首版功能很多，但真正决定后期维护成本的，往往不是某个页面，而是请求是不是统一走一层、分页是不是统一类型、页面跳转是不是按分包规划来做。如果这些东西前期没定，后面每个里程碑都会返工。

Sourcelin 这里的请求层其实已经写得很明确了：

// src/utils/request.ts// 1. 与后端 ApiResponse<T> 契约严格对齐// 2. 提供请求/响应拦截、错误统一处理// 3. 支持 Token 自动注入、401 登录引导// 4. 业务页面/composables 禁止直连 uni.request

共享类型层也已经单独抽出来了：

exportinterfaceApiResponse<T=unknown>{code:number;message:string;data:T;requestId:string;timestamp:string|number;}exportinterfacePageResult<T=unknown>{items:T[];total:number;page:number;pageSize:number;totalPages:number;}

这种代码其实特别适合拿来写实战文章，因为它直接说明：
这个项目不是“页面凑合能调通”，而是先把协议、错误处理和登录跳转统一收口了。

我现在会怎么让 AI 进入基础框架阶段

这一阶段最容易被 AI 做偏的点，是让它直接开始写业务页面，却不先约束目录结构、请求入口和类型层。这样短期看推进很快，长期会出现页面直接uni.request、到处读取旧分页字段、分包配置和页面路径不一致的问题。M1 的真正意义，就是在业务爆发前把这些坑先堵住。

所以我现在更倾向这样给 AI 下任务：

请先读取 AGENTS.md、rules/api-contract.md、rules/frontend-uniapp.md、 sourcelin-ui/sourcelin-ui-uniapp/AGENTS.md。 本次只处理基础框架，不进入首页功能细节和互动逻辑。 要求： 1. 检查 pages.json、manifest.json 和分包路径 2. 检查请求是否统一经过 src/utils/request.ts 3. 检查 ApiResponse / PageResult 类型是否统一 4. 检查 TabBar 与页面入口是否一致 5. 输出还缺哪些基础框架验收项

这样 AI 的输出就不会一上来给我一堆“顺便把首页做了”的扩展，而是先把骨架打稳。

效果图

开发过程提示词（优化版）

请先读取仓库根 AGENTS.md、rules/api-contract.md、rules/frontend-uniapp.md、 sourcelin-ui/sourcelin-ui-uniapp/AGENTS.md，以及产品文档第 5.2 节 M1 里程碑。 本次只处理 M1：移动端基础工程完成，不要扩展到 M2/M3/M4。 请重点检查并整理： 1. pages.json、manifest.json、分包目录是否和产品方案一致 2. 请求是否统一经过 src/utils/request.ts 3. 共享类型是否统一到 ApiResponse<T>、PageResult<T> 4. 四个 TabBar 与页面路径是否可达 输出时必须说明： 1. 变更了哪些目录或配置 2. 当前工程边界是否清晰 3. 还缺哪些 M1 验收项 4. 应执行哪些验证命令

这类任务里 AI 最容易跑偏的点

直接在页面里写请求，不先统一请求层
分页字段继续读旧的rows/list/records
主包和分包路径不先规划，后面越加越乱
一开始就补首页细节，却没先把类型和错误处理收口

按产品文档的验收口径，M1 不是单纯能跑起来就算结束，还要验证微信开发者工具能启动、/front/home能拉起首页基础数据、401 能触发登录引导，以及主包体积和首屏流程已经有初步记录。也就是说，M1 的核心不是“功能展示”，而是“后续开发不会因为基础设施问题反复返工”。

基础框架之后自然要接的就是内容阅读。只有当工程骨架、页面入口、请求层和类型层已经站稳，首页推荐、文章详情、搜索和分享这些用户真正能感知到的能力，才值得继续往前推。

项目地址

摘要：本文详细介绍了微信小程序开发中基础工程搭建的重要性，强调在开始业务功能前必须先建立稳固的工程骨架。文章以 Sourcelin Blog 的 Uniapp 版本为例，阐述了基础框架阶段需要完成的核心工作：项目目录结构、路由分包配置、统一请求封装、类型定义、TabBar 架构等。通过分析当前仓库的工程结构，展示了如何通过规范的目录划分、统一的请求层和类型层为后续开发铺平道路，避免后期因基础设施问题反复返工。