小声说一句 ：首款产品《楼里-IOS版 》已上架，安卓包和产品开发的知识库，公众号私信「楼里」获取。
合适比合理重要，追求精简好维护。
一、简介
后端开发做了十年，见过各种或简单或复杂的技术选型和架构，大多数的设计，都是为了适配一定时期内的业务需求。
业务在变化中，技术也要随之扩展。
工作三五年的时候，讨论技术选型总会问：如果业务做复杂用户量大怎么办？当产品和业务能展现出价值的时候，什么事情都好办，因为公司的资金和资源会迅速跟上。
招聘更有经验的专家，购买更昂贵的服务器。
难办的是业务孵化阶段，经典的幻想逻辑：用时少成本低，还想看到好的效果。项目起步阶段效果差，两三个月团队解散，要是效果好会在加班漩涡里匍匐向前。
转独立开发后，自己做产品，走到原来想法的对立面。
二、系统框架
2.1 组件选型
首先看一下开发用到的核心组件，主要涉及前端，服务端，数据库，大模型四个维度，都是比较常规的选择。
选型思路非常简单直接，自己熟悉擅长的优先选择，不会的尽量选通用和省时的；避免使用冷门组件，遇到无法解决的问题，很难搜索参考案例，不但会浪费时间，甚至会影响心态。
2.2 系统设计图
开始做独立开发的时候，在准备阶段就有朋友说过，自己做开发为啥还要做设计？直接写代码不就好了。
个人习惯：把复杂事情的规划落在文档上，另一方面，这个过程也有利于聚焦和深入的思考问题。
在设计图中，可以非常清晰的把握整体功能，同时聚焦系统的核心模块，并且有助于思考开发流程。自己制作一张全局视图，可以高效理解系统和各个组件的关系，这样更有利于对整体节奏的把握。
三、 前端工程
苹果比安卓的应用生态更标准，所以产品初期先发布IOS商店，在前端技术选型这块纠结过，专业的前端都倾向于使用苹果原生语言。
最终还是选择vue3和uni-app两款框架，使用vite构建工具，开发语言主要使用TypeScript语法。至于具体的页面开发交给AI工具，其中cursor和augment是主力，各家大模型都有参与。
- seven-front: 项目根目录。
-
dist: 打包后的输出目录，通常包含构建后的静态资源文件。
-
node_modules: Node.js 项目的依赖包目录，由pnpm或yarn或npm自动生成。
-
src: 源代码目录，是项目的主要开发区域。
*
- components: 存放可复用的 Vue 组件。
- config: 配置文件目录，包含环境配置、路由配置等。
- pages: 页面目录，每个子目录代表一个页面，如 index 页面。
- static: 静态资源目录，存放图片、字体等静态文件。
- store: 状态管理目录，使用 Vuex 或 Pinia 进行状态管理。
- utils: 工具函数目录，存放常用的工具方法。
- App.vue: 应用的入口组件。
- main.ts: 应用的主入口文件，进行初始化操作。
- env.d.ts: TypeScript 环境声明文件。
- manifest.json: 应用的清单文件，可能用于 PWA（Progressive Web App）配置。
- package.json: Node.js 项目的配置文件，包含项目依赖、脚本等信息。
- index.html: HTML 入口文件，用于加载应用。
- tsconfig.json: TypeScript 配置文件。
- vite.config.ts: Vite 配置文件，用于配置构建工具 Vite。
-
前端应用形式，个人更倾向选择Web网站的模式，可以减少上下架的时间和成本，直接在服务器部署即可，更适配人工智能赛道灵活多变的场景。
但是「楼里」作为自己开发的第一款应用，还是想给这款App足够的重视，所以想带着它试试苹果和安卓商店的差异，条件允许的话还会扩展到Web网站。
四、服务端选型
十年Java的后端码农，技术博客还写了好几年，技术栈和常规封装都熟门熟路。
在最初的想法中，后端代码工程直接使用一个包管理，做好各个端口和模块分层就行，但是考虑后续复用脚手架，索性针对AI项目搭建一个。
- 模型对接：
qh-model管理接入的大模型，封装客户端调用，请求交互的基础方法，提示词的包装等。 - 接入层：
qh-facade产品端请求处理，qh-admin后台管理的请求处理。 - 共享层：
qh-shared存放数据库映射表结构，定义接口和实现类，编写业务工程的逻辑。 - 框架层：
qh-frame管理SpringBoot3项目基础配置，qh-third管理第三方API请求。
之所以捏着鼻子搭建后端工程，主要还是考虑后续的复用，这个轻量级的脚手架模板，在自己的Git仓库有类似的开源工程，需要的朋友可以自行下载。
五、最后聊一聊
对大部分开发者来说，职场工作五年以后，通常都会面对技术选型和系统架构的问题，普遍存在一个心态：
组件搭配全面，架构设计有格调，支持高并发，可扩展，安全性等。
实际上这种方案很难短期落地，除非公司领导层有意识预留做框架的时间。
后端开发十年时间，只做过一次大规模技术重构，
公司预留初版改造时间，其它的组件和细枝末节，都是放在业务版本中迭代，最后超过半年才让框架符合最初的设计。
问题来了：为什么公司愿意预留时间做技术？因为签了好多业务合同，迎来爆发期已经是确定的事情，后来也证实那次重构的合理性。
三五个开发者，在超级复杂的分布式系统上，可以快速迭代业务。