摘要本文强调小程序开发应先搭建工程骨架而非直接堆砌页面。以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 信息架构请求层和统一错误处理ApiResponseT/PageResultT类型登录态注入和 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. 与后端 ApiResponseT 契约严格对齐// 2. 提供请求/响应拦截、错误统一处理// 3. 支持 Token 自动注入、401 登录引导// 4. 业务页面/composables 禁止直连 uni.request共享类型层也已经单独抽出来了exportinterfaceApiResponseTunknown{code:number;message:string;data:T;requestId:string;timestamp:string|number;}exportinterfacePageResultTunknown{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. 共享类型是否统一到 ApiResponseT、PageResultT 4. 四个 TabBar 与页面路径是否可达 输出时必须说明 1. 变更了哪些目录或配置 2. 当前工程边界是否清晰 3. 还缺哪些 M1 验收项 4. 应执行哪些验证命令这类任务里 AI 最容易跑偏的点直接在页面里写请求不先统一请求层分页字段继续读旧的rows/list/records主包和分包路径不先规划后面越加越乱一开始就补首页细节却没先把类型和错误处理收口按产品文档的验收口径M1 不是单纯能跑起来就算结束还要验证微信开发者工具能启动、/front/home能拉起首页基础数据、401 能触发登录引导以及主包体积和首屏流程已经有初步记录。也就是说M1 的核心不是“功能展示”而是“后续开发不会因为基础设施问题反复返工”。基础框架之后自然要接的就是内容阅读。只有当工程骨架、页面入口、请求层和类型层已经站稳首页推荐、文章详情、搜索和分享这些用户真正能感知到的能力才值得继续往前推。项目地址摘要本文详细介绍了微信小程序开发中基础工程搭建的重要性强调在开始业务功能前必须先建立稳固的工程骨架。文章以 Sourcelin Blog 的 Uniapp 版本为例阐述了基础框架阶段需要完成的核心工作项目目录结构、路由分包配置、统一请求封装、类型定义、TabBar 架构等。通过分析当前仓库的工程结构展示了如何通过规范的目录划分、统一的请求层和类型层为后续开发铺平道路避免后期因基础设施问题反复返工。在线演示https://sourcelin.cnGiteehttps://gitee.com/my_lyq/sourcelin-cloud-blogGitHubhttps://github.com/SourceLin/sourcelin-cloud-blog