如果你和我一樣平時會在微信里隨手記點想法、讀書摘抄和工作要點大概率也遇到過同一個煩惱記的時候很爽找的時候就傻眼了。我最近基于 Python 和微信小程序做了個智能筆記核心思路一句話小程序負責(zé)快速記錄和展示Python 后端負責(zé)把碎片化內(nèi)容自動整理成帶關(guān)鍵詞、能摘要、可全文搜索的結(jié)構(gòu)化數(shù)據(jù)。項目從想法到跑通花了兩三周踩了不少坑也沉淀了一些經(jīng)驗。這篇文章不寫空泛的概念直接把需求和選型、關(guān)鍵詞和摘要的落地代碼、小程序端的翻頁與搜索交互、以及真機聯(lián)調(diào)和體驗版的完整鏈路從頭捋一遍。適合誰看呢想用 Python 給小程序做后端能力的開發(fā)者、想做個人知識庫工具的業(yè)余玩家以及正卡在“開發(fā)環(huán)境調(diào)通、一上真機就出問題”階段的朋友。1. 為什么把“智能”放在 Python 后端而不是塞進小程序1.1 筆記應(yīng)用里的“智能”到底指哪幾件事很多人一聽到“智能筆記”第一反應(yīng)就是上大模型。但我實際做下來覺得個人筆記這個場景真正的痛點不是“生成”而是“召回”——你記了一百條散裝筆記能不能在需要的時候快速找到對的那一條。所以我把“智能”拆成了這么幾個具體能力自動打標(biāo)簽碎片筆記不需要手動歸類系統(tǒng)根據(jù)內(nèi)容自動歸入“工作”“學(xué)習(xí)”“Python”“閱讀”等分類。關(guān)鍵詞抽取列表頁不用翻正文掃一眼關(guān)鍵詞就知道這篇筆記講了什么。自動摘要長文筆記在列表里不能只從頭截取需要用算法把真正有信息量的句子撈出來。全文搜索搜“FastAPI”能把所有相關(guān)筆記都找出來而不是只靠標(biāo)題匹配。相似筆記關(guān)聯(lián)這個我放在二期不阻塞主體功能。把這些需求翻譯成技術(shù)就是一個典型的 NLP 小項目分詞、停用詞過濾、TF-IDF / TextRank 抽取、標(biāo)簽規(guī)則引擎、全文檢索。這些東西如果全塞進小程序端基本是折磨自己——小程序代碼包有體積限制開發(fā)者工具里的 JavaScript 環(huán)境跑分詞詞典都有點吃力更別提換模型了。所以第一版架構(gòu)就直接定了Python 做后端小程序只做前端的殼。1.2 技術(shù)選型對比為什么是 Python 后端 原生小程序我先對比了幾條路線下面的表格是我當(dāng)時做的選型記錄實現(xiàn)方案優(yōu)點缺點我的結(jié)論純小程序端實現(xiàn)全部功能部署簡單不用租服務(wù)器分詞性能差、代碼包體積受限、算法升級要發(fā)版不推薦Python 后端 原生小程序NLP 生態(tài)成熟、算法可隨時升級、小程序保持輕量需要服務(wù)器、域名備案和 HTTPS最終采用App體驗完整、能力不受限安裝成本高、分發(fā)難不適合個人工具H5開發(fā)快、更新方便入口不夠輕、微信原生能力弱只作為兜底Python 的優(yōu)勢不用多說生態(tài)里有 jieba、scikit-learn、FastAPI 這些東西一個人開發(fā)的時候效率很重要。Java 或者 Go 寫接口也不難但 NLP 這一塊明顯還是 Python 順手。Web 框架我在 FastAPI 和 Flask 之間猶豫過最后選了 FastAPI。原因是 FastAPI 自帶 OpenAPI 文檔聯(lián)調(diào)的時候直接打開/docs頁面就能測接口Pydantic 做參數(shù)校驗也省了我不少事異步支持讓后面接入后臺任務(wù)變得很干凈。如果你的項目只有三五個接口用 Flask 也行但一旦涉及請求體校驗和異步任務(wù)FastAPI 的體驗會好很多。1.3 鏈路設(shè)計與分層一次保存請求的完整旅途整個系統(tǒng)的調(diào)用鏈路大致是這樣的小程序頁面發(fā)起請求 → Nginx 反向代理HTTPS→ FastAPI 接口層 → 文本清洗與分詞 → 關(guān)鍵詞和摘要抽取 → 標(biāo)簽規(guī)則引擎 → 數(shù)據(jù)庫寫入 → 返回結(jié)構(gòu)化 JSON。我在設(shè)計的時候特意把“NLP 處理”和“接口返回”解耦。用戶點保存筆記后端先把筆記基礎(chǔ)數(shù)據(jù)寫入數(shù)據(jù)庫返回一個“已接收”的狀態(tài)然后后臺異步跑分詞和摘要處理完再回填到記錄里。如果同步去跑第一次加載 jieba 詞典就要一秒鐘左右用戶會明顯感覺到卡頓。還有一個好處是只要接口協(xié)議穩(wěn)定同一個后端可以服務(wù)多條業(yè)務(wù)線——小程序只是入口未來如果想加一個每周筆記郵件推送或者做一個 Web 端訪問入口后端基本不用重寫。2. 智能筆記的“智能”部分從原始文本到結(jié)構(gòu)化信息需求捋清楚之后下一步就是把“智能”拆成能落地的代碼。這一塊是整個項目里最有意思的部分。先說一下環(huán)境準備。如果你還在裝 Python 的階段就去官網(wǎng)下載 3.10 以上的安裝包裝的時候記得勾選“Add Python to PATH”。裝好之后在終端敲python --version能看到版本號就說明環(huán)境通了。項目依賴只需要幾個庫pip install jieba fastapi uvicorn2.1 先清理再分詞臟文本會毀掉所有統(tǒng)計我見過不少新手直接拿原始文本做分詞結(jié)果詞頻統(tǒng)計里全是被截斷的 URL、亂七八糟的符號和無意義的虛詞。筆記文本還有一個特點就是從微信復(fù)制過來的內(nèi)容經(jīng)常帶一堆換行、空格和特殊符號不清洗的話后面所有統(tǒng)計都會偏。所以清洗這一步比算法本身更重要。我的清洗邏輯大概是這樣的import re import jieba STOPWORDS set() def load_stopwords(pathstopwords.txt): 加載中文停用詞表 with open(path, encodingutf-8) as f: for line in f: word line.strip() if word: STOPWORDS.add(word) def clean_text(raw: str) - str: # 去掉 URL、話題標(biāo)簽 text re.sub(rhttps?://\S, , raw) text re.sub(r#\S, , text) # 壓縮連續(xù)空白 text re.sub(r\s, , text) text text.strip(。、,.!? ) return text def tokenize(text: str) - list[str]: return [ w for w in jieba.lcut(text) if w.strip() and len(w) 1 and w not in STOPWORDS ]停用詞表建議自己準備一份中文的。網(wǎng)上搜“中文停用詞表”能找到但我實際用下來還要自己過濾掉“我們”“就是”“一個”“這種”這類口語詞因為個人筆記里這類詞出現(xiàn)的頻率特別高不濾掉關(guān)鍵詞就會被它們占滿。這里有一個特別容易被忽略的坑jieba 對計算機領(lǐng)域的新詞識別不準。比如“大模型”默認可能被切成“大/模型”對 AI 主題筆記來說這種錯切會直接影響標(biāo)簽和摘要質(zhì)量。解決辦法是準備自定義詞典大模型 50 n 私有化部署 30 nz RAG 20 nz Fine-tuning 20 nz然后在代碼里加載jieba.load_userdict(userdict.txt)這個自定義詞典一定要在分詞之前配置好否則后面所有關(guān)鍵詞結(jié)果都會偏離再回頭排查的時候很難意識到是分詞器的問題。2.2 關(guān)鍵詞和摘要TF-IDF 與 TextRank 雙管齊下關(guān)鍵詞抽取我直接用 jieba 自帶的analyse.extract_tags它本質(zhì)上是 TF-IDF 的實現(xiàn)。核心思想用大白話說就是如果一個詞在你這一篇筆記里出現(xiàn)得多但在你所有筆記里很少出現(xiàn)那它就很有可能是這篇筆記的主題詞。就像一群人聊天只有你這兒反復(fù)提“FastAPI”那這次聊天十有八九跟 FastAPI 有關(guān)。摘要我用了jieba.analyse.textrankTextRank 算法類似于網(wǎng)頁排名。把句子看成節(jié)點句子之間如果共用了某些關(guān)鍵詞就建立一條邊然后迭代計算每個句子的得分最后取分數(shù)最高的幾個句子作為摘要。實際使用代碼很短from jieba.analyse import extract_tags, textrank def extract_info(text: str, top_k: int 5): keywords extract_tags(text, topKtop_k, withWeightTrue) summary_sentences textrank(text, topK3) return keywords, summary_sentences拿一段真實示例文本跑一下大概是這個效果demo_text FastAPI是一個現(xiàn)代的Python Web框架基于Starlette和Pydantic構(gòu)建 支持異步接口和自動生成API文檔。我在智能筆記項目中使用FastAPI提供后端服務(wù) 同時結(jié)合jieba分詞庫實現(xiàn)了關(guān)鍵詞抽取和自動摘要功能。 keywords, summaries extract_info(demo_text) print(keywords) # [(FastAPI, 0.356), (摘要, 0.233), (關(guān)鍵詞, 0.201), (后端, 0.175), (分詞, 0.152)] print(summaries) # [我在智能筆記項目中使用FastAPI提供后端服務(wù)同時結(jié)合jieba分詞庫實現(xiàn)了關(guān)鍵詞抽取和自動摘要功能。]這里要提醒一下TF-IDF 里的 IDF 是整個語料庫的統(tǒng)計值。如果筆記很少IDF 計算就不穩(wěn)定。我的方案是把所有筆記合并成一個語料池定期重算一遍 IDF新筆記寫入后會觸發(fā)一次后臺任務(wù)更新語料統(tǒng)計這樣關(guān)鍵詞抽取會隨著筆記增多越來越準。2.3 自動標(biāo)簽規(guī)則保底、關(guān)鍵詞補充標(biāo)簽是整個筆記列表里最直觀的分類入口也是用戶感知“智能”最強烈的一個點。我做自動標(biāo)簽用了兩層策略規(guī)則層加關(guān)鍵詞層。規(guī)則層本質(zhì)是一組關(guān)鍵詞映射表LABEL_RULES { 工作: [會議, 需求, 驗收, 日報, 周報], 學(xué)習(xí): [課程, 教程, 學(xué)習(xí), 筆記], Python: [python, flask, fastapi, django, 爬蟲, venv], 閱讀: [閱讀, 讀完, 書摘, 章節(jié)], } def auto_labels(text: str, keywords: list[tuple[str, float]]) - list[str]: labels set() lower_text text.lower() for label, words in LABEL_RULES.items(): if any(w in lower_text for w in words): labels.add(label) for word, _ in keywords: if len(word) 4: labels.add(word) return list(labels)[:5]規(guī)則層保證“工作筆記”不會莫名其妙被歸到“閱讀”類關(guān)鍵詞層則負責(zé)補充個性化標(biāo)簽。我當(dāng)時也試過完全用聚類算法用 KMeans 把筆記向量化再分組效果很一般——個人筆記主題太分散聚類中心不穩(wěn)定遠不如“規(guī)則 關(guān)鍵詞”直觀可控。2.4 FastAPI 接口把能力包成可調(diào)用的 API現(xiàn)在把這些能力包成接口小程序端只需要 POST 一條筆記就能拿回關(guān)鍵詞、摘要和標(biāo)簽。from fastapi import FastAPI, BackgroundTasks from pydantic import BaseModel from typing import Optional app FastAPI() class NoteIn(BaseModel): title: str content: str tags: Optional[list[str]] [] class NoteOut(BaseModel): id: int title: str keywords: list[str] summary: str labels: list[str] def process_note(note_id: int): 后臺處理清洗文本、抽關(guān)鍵詞、生成摘要、打標(biāo)簽 # 這里省略數(shù)據(jù)庫讀取邏輯 raw_text 從數(shù)據(jù)庫讀取的筆記正文 cleaned clean_text(raw_text) keywords, summaries extract_info(cleaned) labels auto_labels(cleaned, keywords) # 回填數(shù)據(jù)庫字段keywords、summary、labels、statusdone # update_note(note_id, keywordskeywords, summary..., labelslabels) app.post(/api/note, response_modelNoteOut) async def create_note(note: NoteIn, background_tasks: BackgroundTasks): # 先快速寫入基礎(chǔ)數(shù)據(jù)statuspending # note_id insert_note(titlenote.title, contentnote.content) background_tasks.add_task(process_note, note_id) return NoteOut( idnote_id, titlenote.title, keywords[], summarynote.content[:50], labelsnote.tags )開發(fā)階段數(shù)據(jù)庫用 SQLite 就夠了一行sqlite3.connect就能跑起來。生產(chǎn)環(huán)境建議換 MySQL 或者 PostgreSQL至少用 SQLAlchemy 做 ORM否則后面表結(jié)構(gòu)變更會非常痛苦。我當(dāng)時的做法是先用 SQLite 把整個流程跑通確認所有功能沒問題后再切 MySQL切換成本主要就是改數(shù)據(jù)庫連接配置。3. 小程序端的核心交互列表翻頁、搜索防抖和接口封裝后端接口搞定前端這些頁面就好做多了。但小程序端的交互不是簡單渲染數(shù)據(jù)有幾個細節(jié)直接影響體驗。3.1 頁面規(guī)劃減少頁面的心智負擔(dān)整個小程序我控制在三個頁面首頁筆記列表、編輯頁、搜索頁。首頁卡片列表每張卡片顯示標(biāo)題、摘要、標(biāo)簽和時間。編輯頁標(biāo)題輸入框加正文 textarea底部放一個“保存”按鈕。搜索頁輸入框加搜索結(jié)果列表頂部幾個標(biāo)簽快捷篩選。這里有一個前端適配細節(jié)不同機型的頂部導(dǎo)航欄高度不一樣寫自定義導(dǎo)航欄時不要寫死數(shù)值用微信提供的膠囊按鈕位置做動態(tài)計算不然劉海屏和全面屏?xí)霈F(xiàn)明顯的錯位。我選擇用原生小程序而不是 uni-app 或 Taro是因為項目就三個頁面前端很輕沒必要引入跨端框架的構(gòu)建鏈路。如果你打算將來同時發(fā)布到支付寶小程序或百度小程序再考慮跨端框架也不遲。3.2 列表加載更多onReachBottom 與翻頁參數(shù)列表頁最核心的問題就是分頁。微信小程序的onReachBottom會在頁面滾動到底部時觸發(fā)但觸發(fā)時機可能比預(yù)期頻繁如果不加鎖會連續(xù)發(fā)出多個重復(fù)請求。我的實現(xiàn)如下// pages/index/index.js Page({ data: { list: [], page: 1, pageSize: 10, hasMore: true, loading: false }, onLoad() { this.loadList(true); }, onReachBottom() { if (this.data.loading || !this.data.hasMore) return; this.loadList(false); }, loadList(reset) { if (this.data.loading) return; this.setData({ loading: true }); const page reset ? 1 : this.data.page; wx.request({ url: ${BASE_URL}/api/notes, data: { page, pageSize: this.data.pageSize }, success: (res) { const rows res.data.rows || []; this.setData({ list: reset ? rows : this.data.list.concat(rows), page: page 1, hasMore: rows.length this.data.pageSize, loading: false }); }, fail: () { this.setData({ loading: false }); } }); } });兩個細節(jié)說明一下。第一loading字段的主要作用不是給用戶看加載動畫而是鎖住并發(fā)請求——觸底事件可能連續(xù)觸發(fā)如果沒有鎖同一頁數(shù)據(jù)會被請求十幾次。第二hasMore的判定用rows.length pageSize如果返回不足一頁就說明沒有更多數(shù)據(jù)了。后端接口也要記得給列表字段加索引不然數(shù)據(jù)量上來了全表掃描會很慢。后端對應(yīng)的分頁接口可以按這個思路寫app.get(/api/notes) def list_notes(page: int 1, pageSize: int 10): # 按創(chuàng)建時間倒序返回 rows 和 total rows get_notes_page(page, pageSize) return {rows: rows, page: page, pageSize: pageSize}3.3 搜索防抖不只是性能還有結(jié)果亂序搜索框要防抖這個很多朋友都知道。但防抖還有一個容易被忽略的附帶作用避免結(jié)果亂序。具體來說用戶輸入“Python”后停頓了一下然后改成“人工智能”。如果不做防抖剛才那個“Python”請求可能還沒返回用戶就已經(jīng)發(fā)起了“人工智能”請求。網(wǎng)絡(luò)情況一波動先發(fā)出的請求可能后返回最終頁面上顯示的是上一次搜索的結(jié)果這時候用戶會以為系統(tǒng)壞了。我的代碼里用一個requestSeq變量來解決這個問題// pages/search/search.js let searchTimer null; let requestSeq 0; Page({ data: { keyword: , results: [], searching: false }, onInput(e) { const keyword e.detail.value.trim(); this.setData({ keyword }); clearTimeout(searchTimer); if (!keyword) { this.setData({ results: [] }); return; } searchTimer setTimeout(() { this.doSearch(keyword); }, 400); }, doSearch(keyword) { const seq requestSeq; this.setData({ searching: true }); wx.request({ url: ${BASE_URL}/api/search?q${encodeURIComponent(keyword)}, success: (res) { if (seq ! requestSeq) return; // 丟棄過期的響應(yīng) this.setData({ results: res.data.items || [], searching: false }); }, fail: () { if (seq requestSeq) this.setData({ searching: false }); } }); } });這個seq ! requestSeq判斷非常關(guān)鍵。我第一次做的時候沒加這個設(shè)施結(jié)果就是“Python”的結(jié)果晚于“人工智能”返回頁面顯示的是舊關(guān)鍵詞的搜索結(jié)果。排查了半天最后發(fā)現(xiàn)是響應(yīng)亂序?qū)е碌募由闲蛱柵袛嗪髥栴}立刻消失。搜索接口本身也要做一點處理。個人筆記場景數(shù)據(jù)量不大用數(shù)據(jù)庫的 LIKE 查詢就夠但關(guān)鍵詞最好做分詞拆解把分詞結(jié)果用 OR 組合這樣匹配范圍更合理。3.4 封裝 request 與用戶身份綁定所有請求都直接寫wx.request會導(dǎo)致大量重復(fù)代碼。我封裝了一個簡單的 Promise 版本const BASE_URL https://api.example.com/api; function request(path, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL path, method, data, header: { content-type: application/json, Authorization: Bearer (wx.getStorageSync(token) || ) }, success: (res) { if (res.statusCode 200 res.statusCode 300) { resolve(res.data); } else if (res.statusCode 401) { // token 失效引導(dǎo)重新登錄 wx.navigateTo({ url: /pages/login/login }); reject(res); } else { reject(res); } }, fail: reject }); }); } module.exports { request };用戶身份綁定走的是標(biāo)準微信登錄流程小程序端wx.login()拿到臨時 code發(fā)給后端后端用 code 調(diào)用微信的jscode2session接口換 openid再生成自己的 token 返回給小程序。小程序把 token 存到wx.setStorageSync后續(xù)所有請求帶上 token。這里要注意不要在客戶端拿 code 當(dāng)身份憑證。code 有時效性而且按微信的規(guī)范必須由后端換 openid小程序端不應(yīng)該感知 openid 的存在。3.5 草稿保存監(jiān)聽 onHide 和 onUnload編輯頁有一個很實際的場景用戶寫了一大段筆記切到微信回了個消息回來發(fā)現(xiàn)草稿丟了。這時候就需要監(jiān)聽頁面隱藏和卸載事件。小程序頁面生命周期里有onHide和onUnload分別在頁面切到后臺和頁面銷毀時觸發(fā)。我在這兩個事件里把編輯框內(nèi)容寫入本地 storage// pages/edit/edit.js Page({ data: { title: , content: }, onTitleInput(e) { this.setData({ title: e.detail.value }); }, onContentInput(e) { this.setData({ content: e.detail.value }); }, onHide() { this.saveDraft(); }, onUnload() { this.saveDraft(); }, saveDraft() { if (!this.data.title !this.data.content) return; wx.setStorageSync(draft_note, { title: this.data.title, content: this.data.content, time: Date.now() }); } });下次進入編輯頁時讀取本地草稿并提示用戶是否恢復(fù)。這個功能雖然不起眼但實際用起來非常提升好感度——筆記類工具最怕丟內(nèi)容一次丟失就可能讓用戶直接放棄整個產(chǎn)品。4. 真機聯(lián)調(diào)、抓包和體驗版連接開發(fā)與真實用戶到這里開發(fā)層面的功能基本齊了。真正折磨人的是聯(lián)調(diào)階段——本機跑得好好的一到真機就各種翻車。這塊我踩坑最多單獨拿出來寫。4.1 本機能跑、手機就崩先解決本地聯(lián)調(diào)開發(fā)者工具里可以勾選“不校驗合法域名”所以后端跑在http://127.0.0.1:8000時開發(fā)者工具里能正常請求。一旦用真機預(yù)覽請求大概率直接失敗。原因很簡單手機上的微信根本不認識127.0.0.1這個地址在手機上看指代的是手機自己。解決辦法分幾步后端啟動時監(jiān)聽所有網(wǎng)卡uvicorn main:app --host 0.0.0.0 --port 8000。手機和電腦連同一個 Wi-Fi。電腦 IP 用ipconfigWindows或者ifconfigMac/Linux查看假設(shè)是192.168.1.10。小程序里BASE_URL臨時改成http://192.168.1.10:8000/api。微信開發(fā)者工具的“預(yù)覽”彈層里勾選“啟用開發(fā)調(diào)試模式”手機端才允許訪問 http 域名。這一步我當(dāng)時卡了差不多一個晚上最后發(fā)現(xiàn)就是手機微信的域名校驗在搗鬼。注意這只能是開發(fā)階段的臨時方案正式發(fā)布必須換成有備案的 HTTPS 域名。4.2 用 Charles 抓包看真實請求一次難忘的 401真機上接口報錯但開發(fā)者工具里一切正常這種情況下最有效的排查方式就是用抓包工具看真實請求。Charles 是我常用的選擇。操作流程電腦打開 Charles默認代理端口 8888。手機 Wi-Fi 設(shè)置里把 HTTP 代理指向電腦 IP:8888。手機瀏覽器訪問chls.pro/ssl下載并安裝 Charles 的 SSL 證書。重新打開小程序Charles 里就能看到所有wx.request請求的完整鏈路請求地址、請求頭、請求體、響應(yīng)體。抓包能定位到很多真機上才暴露的問題。我印象最深的一次是搜索接口在真機上始終返回 401開發(fā)者工具里卻完全正常。抓包一開發(fā)現(xiàn)手機端請求頭里的 token 是空的——原因是頁面跳轉(zhuǎn)太快wx.login的回調(diào)還沒執(zhí)行完頁面就已經(jīng)發(fā)出了請求。這類時序問題不看真實請求很難定位。需要強調(diào)一下Charles 抓包是用來做正常開發(fā)調(diào)試的不要繞過任何證書校驗機制也不要拿它做非法用途。常規(guī)的抓包分析完全可以滿足聯(lián)調(diào)需求。4.3 體驗版分發(fā)收集試用反饋的正確姿勢功能寫完想喊幾個朋友試用這時候不需要提審上線走體驗版通道就行。具體流程微信開發(fā)者工具右上角點“上傳”填版本號和備注。登錄微信公眾平臺進入“版本管理”。在“開發(fā)版本”里找到剛上傳的版本點“設(shè)為體驗版”。在“成員管理”里添加體驗成員填朋友的微信號。朋友在微信里直接打開你的小程序體驗版就能正常使用。這里有個關(guān)鍵決策體驗版一定要把后端部署到有正式 HTTPS 域名的服務(wù)器上不要讓朋友連你的筆記本局域網(wǎng)。最簡單的低成本方案是買一臺云服務(wù)器裝好 Nginx 和 TLS 證書FastAPI 跑在 8000 端口Nginx 反向代理到 443。然后在微信公眾平臺配置 request 合法域名。這里還要提醒兩件事。第一微信小程序的正式版和體驗版都會強制校驗 TLS證書不能是自簽的必須機構(gòu)簽發(fā)。第二域名備案要提前處理不然配置合法域名時會被卡住。個人主體的小程序每隔一年要做一次年審這個時間節(jié)點也值得記在日歷里過期了會影響服務(wù)。我當(dāng)時的做法是在小程序里加一個簡單的“反饋”入口試用者可以直接提交使用感受。這樣收集到的反饋會比口頭溝通完整得多也方便后續(xù)迭代。4.4 上線前檢查清單別讓細節(jié)毀掉體驗最后整理一份上線前檢查清單都是我吃過虧之后總結(jié)出來的檢查項說明HTTPS 域名request 合法域名必須配置證書有效且非自簽接口鑒權(quán)token 過期處理、越權(quán)訪問、openid 綁定數(shù)據(jù)備份每天定時 dump 數(shù)據(jù)庫備份文件放對象存儲或異地隱私協(xié)議小程序?qū)徍诵枰f明收集了哪些用戶數(shù)據(jù)分頁索引列表和搜索接口的字段加數(shù)據(jù)庫索引日志監(jiān)控后端接口打印 request_id出錯能快速定位到具體請求連接池數(shù)據(jù)庫連接用連接池避免短連接在高并發(fā)下崩潰日志這里多說一句不要打印用戶筆記的完整正文一方面涉及隱私另一方面日志文件很快就會膨脹。打印長度截斷后的摘要字段就夠了。這套項目做到最后我最大的感受是所謂“智能”并不是一開始就要上多復(fù)雜的東西。先把分詞、關(guān)鍵詞、摘要這些基礎(chǔ)能力跑通用戶就已經(jīng)能感受到明顯差異了。后續(xù)如果想做相似筆記推薦可以考慮向量數(shù)據(jù)庫加文本嵌入模型把關(guān)鍵詞階段的輸出作為一個特征喂進去這是另一個話題了。給同樣想試試的朋友一個建議別一上來就追求完整產(chǎn)品先把“保存一條筆記自動返回關(guān)鍵詞和標(biāo)簽”這條鏈路跑通再逐步加列表翻頁、搜索防抖和體驗版分發(fā)。功能是慢慢長出來的鏈路通了后面每一步都很快。如果你也在折騰類似的小程序加 Python 項目歡迎分享一下你踩過的那些坑。