摘要：本文详细介绍了Uniapp小程序开发中基础工程搭建的重要性。强调在开发业务页面之前，必须先建立稳定的工程骨架，包括路由配置、分包结构、统一请求层、类型定义和TabBar架构。通过Sourcelin Blog项目实例，展示了如何规划目录结构、统一API响应格式、封装请求拦截器，并提供了优化后的AI开发提示词，确保项目从"能运行"升级到"可维护、可扩展"的工程化水平。

做微信小程序时，第一步不是先堆页面，而是先把基础工程搭稳。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

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

export interface ApiResponse<T = unknown> {
  code: number;
  message: string;
  data: T;
  requestId: string;
  timestamp: string | number;
}

export interface PageResult<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 的输出就不会一上来给我一堆“顺便把首页做了”的扩展，而是先把骨架打稳。

下面是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 最容易跑偏的点

下面是AI开发中常见跑偏路径与正确路径的对比：

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

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

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

项目地址

• 在线演示：https://sourcelin.cn
• Gitee：https://gitee.com/my_lyq/sourcelin-cloud-blog
• GitHub：https://github.com/SourceLin/sourcelin-cloud-blog