小聲說一句：首款產品《》已上架，安卓包和產品開發的知識庫，公眾號私信「樓里」獲取。

合適比合理重要，追求精簡好維護。

一、簡介

后端開發做了十年，見過各種或簡單或復雜的技術選型和架構，大多數的設計，都是為了適配一定時期內的業務需求。

業務在變化中，技術也要隨之擴展。

工作三五年的時候，討論技術選型總會問：如果業務做復雜用戶量大怎么辦？當產品和業務能展現出價值的時候，什么事情都好辦，因為公司的資金和資源會迅速跟上。

招聘更有經驗的專家，購買更昂貴的服務器。

難辦的是業務孵化階段，經典的幻想邏輯：用時少成本低，還想看到好的效果。項目起步階段效果差，兩三個月團隊解散，要是效果好會在加班漩渦里匍匐向前。

轉獨立開發后，自己做產品，走到原來想法的對立面。

二、系統框架

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倉庫有類似的開源工程，需要的朋友可以自行下載。

五、最后聊一聊

對大部分開發者來說，職場工作五年以后，通常都會面對技術選型和系統架構的問題，普遍存在一個心態：

組件搭配全面，架構設計有格調，支持高并發，可擴展，安全性等。

實際上這種方案很難短期落地，除非公司領導層有意識預留做框架的時間。

后端開發十年時間，只做過一次大規模技術重構，

公司預留初版改造時間，其它的組件和細枝末節，都是放在業務版本中迭代，最后超過半年才讓框架符合最初的設計。

問題來了：為什么公司愿意預留時間做技術？因為簽了好多業務合同，迎來爆發期已經是確定的事情，后來也證實那次重構的合理性。

三五個開發者，在超級復雜的分布式系統上，可以快速迭代業務。