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