我記得很清楚第一次意識到上下文重要性的場景是在寫一個小型終端助手的時候。這個工具需要用戶連續(xù)完成幾步操作先選擇數(shù)據(jù)源再指定處理方式最后輸出報告。但每次命令跑完它就什么都不記得了用戶下一步如果漏掉某個參數(shù)只能重新敲一遍。那一刻我意識到?jīng)]有上下文的工具就像一個每次都重新認(rèn)識你的柜臺服務(wù)員你不得不一遍遍重復(fù)自己的需求。context-mode就是為解決這類問題設(shè)計的。簡單來說它是一種讓軟件在多次操作或多次會話之間自動保存、讀取并利用歷史上下文信息的運行模式。它解決的問題很具體減少重復(fù)輸入、保持操作連續(xù)性、讓程序能根據(jù)之前發(fā)生了什么做出更合理的判斷。如果你是做CLI工具、自動化腳本、編輯器插件或者自己在折騰AI助手相關(guān)的東西這篇文章值得看完——我會從設(shè)計思路講到代碼實現(xiàn)再分享實測中踩過的三個坑。1. context-mode是什么先從一次尷尬的失憶說起1.1 沒有上下文的世界你每天都在重復(fù)填表先想想你平時用的命令行工具尤其是那些要傳一堆參數(shù)的工具。比如一個數(shù)據(jù)遷移腳本你可能要寫成這樣python migrate.py --source /data/old --target /data/new --format csv --encoding utf-8如果跑到一半掛了或者你想換個格式再跑一次你大概率會把這條命令翻出來改一改或者按一下上箭頭重新編輯。這在單次操作里問題不大但如果是連續(xù)幾十條命令呢比如你要依次做預(yù)處理、清洗、校驗、導(dǎo)入、導(dǎo)出每一步都要重復(fù)指定路徑、編碼、分隔符時間一長忘參數(shù)幾乎是必然的。沒有上下文的世界本質(zhì)上是把本該由程序記住的信息全壓在了用戶身上。這就像你每天去同一個快遞點取件每次都報一遍姓名、電話、地址?？爝f點的工作人員不是不想記住你而是他的系統(tǒng)沒這個能力。context-mode要做的就是給程序加上這個記憶能力。1.2 context-mode的定位讓工具記住剛才發(fā)生了什么那么context-mode具體指什么我傾向于給它一個精確的定義一種運行模式在這種模式下程序會將用戶當(dāng)前的操作、輸入?yún)?shù)、選中項、臨時狀態(tài)等信息記錄下來并在后續(xù)操作中自動讀取和套用從而形成連續(xù)的操作體驗。它和普通的日志、緩存有本質(zhì)區(qū)別。日志是寫給開發(fā)者調(diào)試用的緩存是為了加速重復(fù)讀取而context-mode關(guān)心的是語義上的連續(xù)性。舉個例子你在一個文件管理器里選中了一個文件然后準(zhǔn)備執(zhí)行壓縮操作——壓縮工具預(yù)先把當(dāng)前選中了哪個文件這個信息記下來這就是上下文。再比如AI聊天助手它能記得你五分鐘前問過什么這個記得就是上下文模式在起作用。我見過的context-mode實現(xiàn)有很多種形態(tài)基于會話服務(wù)器端為每個連接維護(hù)獨立上下文比如SSH會話。基于項目目錄進(jìn)入某個項目目錄后自動加載該項目相關(guān)的偏好設(shè)置。基于全局用戶級別的默認(rèn)配置任何地方都能訪問?；跁r間窗口只記錄最近N分鐘或N條操作形成滾動上下文。這里面的核心難點不是記錄數(shù)據(jù)而是決定哪些數(shù)據(jù)值得記錄、什么時候該遺忘、上下文沖突時怎么處理。1.3 什么場景真正需要它三個最典型的應(yīng)用場景我在實際項目里總結(jié)出三類最需要context-mode的場景你可以對照自己的需求來判斷。第一類是多步驟CLI工具。我之前寫過一個批量圖片處理工具包含導(dǎo)入、去重、壓縮、重命名、導(dǎo)出五個步驟。如果每一步都要求用戶重新輸入輸入目錄、輸出目錄、質(zhì)量參數(shù)用起來會非常痛苦。加上context-mode之后用戶只需要在第一次運行時提供完整參數(shù)后續(xù)跑任何單步操作都會自動帶上省事很多。第二類是IDE和編輯器插件。比如你正在編輯一個Python文件然后按下快捷鍵跳到一個工具函數(shù)定義處改完之后返回原來的位置——編輯器記住了你剛才在哪里。這種上下文記錄已經(jīng)非常普遍了我們在做插件開發(fā)時也常常需要記錄光標(biāo)位置、當(dāng)前文件路徑、最近打開的文件列表這就是一種典型的window-level context。第三類是AI助手的連續(xù)對話。當(dāng)前所有主流AI對話產(chǎn)品都在做上下文管理因為把整段歷史全部塞給模型既浪費tokens又會超出模型的上下文窗口。實際工程中我們往往需要保留最近幾輪對話而對更久之前的內(nèi)容做摘要或裁剪。這個保留多少、裁剪多少的策略本質(zhì)上是context-mode的策略選擇。除此之外運維自動化、構(gòu)建系統(tǒng)、數(shù)據(jù)管道調(diào)度等領(lǐng)域也大量依賴上下文。判斷一個系統(tǒng)適不適合引入context-mode我有個簡單的經(jīng)驗如果你發(fā)現(xiàn)使用者在反復(fù)輸入或反復(fù)選擇相同的信息并且這些信息跟上一次操作強相關(guān)那這個系統(tǒng)就值得改造。2. 設(shè)計一個合理的上下文模型數(shù)據(jù)結(jié)構(gòu)和生命周期2.1 上下文粒度全局、會話、項目三層的取舍在動手寫代碼之前必須先想清楚上下文數(shù)據(jù)要分成幾層。如果不分層所有數(shù)據(jù)混在一起很快就會出現(xiàn)張三的項目配置被李四帶走了這種問題。我在context-mode項目里設(shè)計了三個層級非常夠用層級作用范圍典型內(nèi)容生命周期global當(dāng)前用戶所有操作用戶名、默認(rèn)編輯器、常用路徑長期保留session一次工具進(jìn)程的運行周期當(dāng)前打開的臨時文件、臨時的token會話結(jié)束即刪除project當(dāng)前項目/工作目錄項目根路徑、依賴目錄、構(gòu)建命令項目存在期間這套設(shè)計解決了兩個關(guān)鍵問題。一個是隔離性不同項目的上下文不會互相污染即使是同一個工具在項目A和項目B下會自動加載各自的設(shè)置。另一個是時效性session里的狀態(tài)本來就該用完即焚比如某次登錄產(chǎn)生的臨時憑證如果放到了global里那就是給自己埋雷。有人可能會問為什么不做成數(shù)據(jù)庫表用外鍵關(guān)聯(lián)我的答案是對于大部分工具型項目三層結(jié)構(gòu)用嵌套字典就夠了。數(shù)據(jù)庫適合海量數(shù)據(jù)檢索而context數(shù)據(jù)通常單用戶、低并發(fā)、量也不大用樹狀結(jié)構(gòu)反而更直觀調(diào)試時候一眼就能看到當(dāng)前上下文里有什么。2.2 持久化選型為什么用JSON加內(nèi)存兩級緩存確定層級結(jié)構(gòu)后接下來要考慮數(shù)據(jù)存哪。我先說結(jié)論我采用了內(nèi)存字典做熱存儲 JSON文件做冷持久化的組合而不是直接上SQLite。內(nèi)存字典的好處是快讀寫都在納秒級適合高頻訪問。JSON文件的好處是方便調(diào)試——你可以直接用vim或cat打開來看如果用了SQLite還得裝個客戶端才能查。對于context-mode這種偏工具性質(zhì)的組件易調(diào)試比查詢性能重要得多。具體做法是啟動時把JSON文件加載進(jìn)內(nèi)存形成一個三層嵌套字典。每次set操作先更新內(nèi)存再決定是否寫盤。寫盤不能每次set都做否則高頻操作時IO會成為瓶頸。我的做法是做一個臟標(biāo)記在程序退出、或者每隔一段時間批量落盤。下面是我最初的存儲結(jié)構(gòu)設(shè)計示意{ global: { default_editor: vim }, session: { login_time: 1700000000 }, project: { /home/user/myapp: { build_command: make, last_output: Build OK } } }這里把project的鍵設(shè)計成了項目絕對路徑天然實現(xiàn)了項目級隔離。后來又發(fā)現(xiàn)一個細(xì)節(jié)值得注意路徑里可能含有特殊字符所以我在加載時對路徑做了規(guī)范化處理去掉末尾斜杠、解析符號鏈接避免同一個項目因為路徑寫法不同出現(xiàn)兩個上下文副本。2.3 上下文有效期過期策略與自動清理機(jī)制上下文不是無限堆積的否則用戶會發(fā)現(xiàn)三個月前的一次操作記錄還影響了今天的執(zhí)行結(jié)果這反而變成了一種困擾。我設(shè)計的過期策略是給每條上下文數(shù)據(jù)附加元信息{ value: data, created_at: 1700000000, updated_at: 1700000000, ttl: 3600 }created_at和updated_at分別記錄創(chuàng)建時間和最后更新時間。ttl是存活時間秒例如3600表示1小時后過期。讀取時如果now - updated_at ttl就認(rèn)為這條數(shù)據(jù)已過期不返回給調(diào)用方。這里我要強調(diào)一個容易犯的錯很多人把TTL只寫在層級上比如整個session層1小時過期這會引發(fā)連鎖問題——一個長任務(wù)可能只需要某些字段長期有效但整個層級過期會把它一并殺掉。正確的做法是字段級TTL不同字段可以單獨指定有效期。比如當(dāng)前登錄用戶可以永久上次選中的文件只需要5分鐘。清理機(jī)制我用的是惰性刪除 定期掃描雙保險。惰性刪除是在get時發(fā)現(xiàn)過期就順便刪掉定期掃描是每隔10分鐘把過期數(shù)據(jù)批量清掉避免臟數(shù)據(jù)堆積占內(nèi)存。這樣既保證實時性又不至于每次操作都觸發(fā)大量刪除。3. 動手實現(xiàn)一個可用的context-mode模塊Python版3.1 核心類設(shè)計ContextManager的接口定義設(shè)計完成后實現(xiàn)階段需要用代碼把想法固定下來。這一節(jié)我用Python來寫一個可直接運行的context-mode模塊語言無關(guān)性很好你換成Go、Node.js也是一樣的思路。先定義核心類的接口。我習(xí)慣先寫注釋再寫實現(xiàn)因為這樣能逼自己把接口想清楚import json import os import threading import time from pathlib import Path class ContextManager: Manage context data at global/session/project levels with TTL support. def __init__(self, storage_path): self.storage_path Path(storage_path) self._lock threading.Lock() self._context {global: {}, session: {}, project: {}} self._load() def _load(self): if self.storage_path.exists(): with open(self.storage_path, r, encodingutf-8) as f: loaded json.load(f) self._context.update(loaded) def set(self, level, key, value, ttlNone): Set a value in the given level. level: global | session | project key: string key value: any JSON-serializable value ttl: optional time-to-live in seconds with self._lock: meta { value: value, created_at: time.time(), updated_at: time.time(), ttl: ttl, } self._context.setdefault(level, {})[key] meta def get(self, level, key): Get a value. Return None if key doesnt exist or is expired. with self._lock: meta self._context.get(level, {}).get(key) if meta is None: return None if meta[ttl] is not None: if time.time() - meta[updated_at] meta[ttl]: del self._context[level][key] return None return meta[value] def save(self): Persist current context to disk. with self._lock: tmp_file self.storage_path.with_suffix(.tmp) with open(tmp_file, w, encodingutf-8) as f: json.dump(self._context, f, ensure_asciiFalse, indent2) tmp_file.replace(self.storage_path)這個類雖然只有幾十行但已經(jīng)包含了最核心的能力設(shè)置、讀取、過期判斷、落盤。其中save用了一個臨時文件加原子替換的技巧避免直接寫原文件時如果程序崩潰導(dǎo)致文件損壞。這是一個我踩過坑后的經(jīng)驗后面第4節(jié)還會詳細(xì)說。3.2 一個簡單的CLI集成示例從保存到讀取光有類還不夠我把它集成進(jìn)一個真實的CLI場景來演示。假設(shè)我們要做一個圖片壓縮工具壓縮之前需要用戶指定輸入目錄和質(zhì)量參數(shù)。我用argparse來解析命令命令行沒有提供時就從上下文讀取import argparse from pathlib import Path ctx ContextManager(~/.myapp/context.json) def require_dir(arg_valueNone): Return provided arg value, or read from context if available. if arg_value: ctx.set(project, input_dir, arg_value) return arg_value cached ctx.get(project, input_dir) if cached: return cached raise SystemExit(請輸入輸入目錄或者先設(shè)置過context-mode) if __name__ __main__: parser argparse.ArgumentParser() parser.add_argument(--input-dir, defaultNone) parser.add_argument(--quality, typeint, defaultNone) args parser.parse_args() input_dir require_dir(args.input_dir) quality args.quality if quality is None: quality ctx.get(project, quality) or 85 ctx.set(project, quality, quality) ctx.save() print(f開始壓縮輸入目錄{input_dir}質(zhì)量{quality})注意require_dir的設(shè)計如果用戶傳了新參數(shù)就會更新上下文如果沒傳就嘗試從上下文取值。這就是context-mode的核心體驗——今天少敲幾個參數(shù)明天少敲更多越用越順手。3.3 代碼走讀關(guān)鍵的邊界條件處理這幾十行代碼里有幾個邊界條件是實際跑起來之后才會發(fā)現(xiàn)的。第一個是存儲路徑的擴(kuò)展符處理。Path(~/.myapp/context.json)在Python中不會自動展開波浪號必須調(diào)用Path.expanduser()。我在最初版本里漏了這一步導(dǎo)致一直找不到文件后來排查了很久。正確寫法是self.storage_path Path(storage_path).expanduser()第二個是過期數(shù)據(jù)在get之后才刪除。我的實現(xiàn)里如果get時發(fā)現(xiàn)TTL過期會先把數(shù)據(jù)刪掉再返回None。但如果在刪除之前另一個線程正好也在讀同一個key就會出現(xiàn)競態(tài)。我在get外層加了線程鎖這就是_lock的作用。不過對單文件來說這個鎖只在進(jìn)程內(nèi)有效如果多個進(jìn)程同時讀寫同一個JSON文件還需要加文件鎖這個坑我第4節(jié)會專門講。第三個是set的值必須可JSON序列化。如果你存了個自定義對象json.dump時會直接拋TypeError。更隱蔽的是如果存的是tuplejson會把它變成list下次讀出來類型就變了。如果想保留類型信息必須在set時做轉(zhuǎn)換檢查。我在實際項目中加了這樣一個斷言def _ensure_json_serializable(self, value): try: json.dumps(value) except TypeError: raise TypeError(f值 {value} 無法序列化為JSON)這些邊界條件看起來不復(fù)雜但往往就是能用和好用之間的差距。4. 實測中的坑與排查過程數(shù)據(jù)覆蓋、過期混亂和隱私泄漏4.1 坑一并發(fā)寫入導(dǎo)致上下文互相覆蓋代碼看起來沒問題的部分一上實測就暴露了第一個大坑。我的工具支持并行處理多個任務(wù)于是會同時跑多個進(jìn)程每個進(jìn)程都會調(diào)用ctx.save()結(jié)果經(jīng)常出現(xiàn)進(jìn)程A把上下文寫到一半進(jìn)程B也寫過來了最終文件里數(shù)據(jù)錯亂甚至JSON解析直接失敗。排查過程是這樣的我先檢查了代碼里的線程鎖_lock發(fā)現(xiàn)它只能鎖住當(dāng)前進(jìn)程內(nèi)的線程進(jìn)程之間完全不管用。兩個進(jìn)程同時執(zhí)行tmp_file.replace(self.storage_path)時雖然臨時文件是各自獨立的但替換操作本身不是原子的關(guān)聯(lián)操作集合——A替換成功B替換成功后面的覆蓋了前面的無法合并。解決辦法是讓進(jìn)程間也能串行化。我引入了一個簡單的文件鎖基于操作系統(tǒng)層面的fcntlimport fcntl def save(self): with open(self.storage_path, a) as lock_file: fcntl.flock(lock_file.fileno(), fcntl.LOCK_EX) # 原子寫入內(nèi)容 with open(tmp_file, w, ...): json.dump(...) tmp_file.replace(self.storage_path) fcntl.flock(lock_file.fileno(), fcntl.LOCK_UN)但這里還有個微妙的問題鎖的競爭粒度是整個文件的寫入如果多個進(jìn)程同時修改的是不同層級的數(shù)據(jù)理論上是可以合并的。我圖省事直接全文件互斥了實測下來因為context本身寫得不頻繁性能損失可以忽略。如果你的項目寫得很頻繁就需要把鎖粒度細(xì)化到字段級。4.2 坑二單字段過期機(jī)制導(dǎo)致的連鎖混亂第二個坑是在我加字段級TTL之后才浮現(xiàn)的。最初版本我把TTL放到了level層級也就是session層整體2小時過期。后來改成字段級TTL后我發(fā)現(xiàn)一個新的問題決定是否過期的時間基準(zhǔn)有問題。一開始我給的邏輯是now - created_at ttl就過期但這有個反例用戶在一個長任務(wù)的剛開始設(shè)置了待處理文件列表這個列表的created_at是一個小時前但任務(wù)還沒跑完。按created_at算它已經(jīng)過期了可實際上它一直被正常使用著。后來我改成now - updated_at ttl每次get命中就刷新updated_at這樣只要這個字段還在被持續(xù)使用它就會一直存活。這個邏輯目前驗證下來比較合理但它也有代價一個長期不用的上下文永遠(yuǎn)不會被徹底清掉因為每次get都會給它續(xù)命。所以我加了一個上限當(dāng)now - created_at超過某個最大值比如7天時強制認(rèn)為過期防止數(shù)據(jù)無限膨脹。實際排查過程中我用了一段腳本模擬了反復(fù)讀取同一個舊字段的情況確認(rèn)了updated_at確實被刷新也發(fā)現(xiàn)了created_at一直沒變。這類問題只有在把預(yù)期行為和實際行為對照著看才容易暴露單純看代碼很難發(fā)現(xiàn)。4.3 坑三上下文日志里存了不該存的密鑰第三個坑比較嚇人。我在調(diào)試context-mode時經(jīng)常打印整個上下文看看數(shù)據(jù)對不對有一次發(fā)現(xiàn)打印內(nèi)容里包含了用戶臨時輸入的數(shù)據(jù)庫密碼。最開始沒在意覺得反正本地開發(fā)后來才意識到一旦這個模塊被集成到線上的自動化腳本里并且開啟debug日志就等于把密鑰明文寫到了日志文件里如果日志被上傳到日志中心那就是事故。修復(fù)方案是加一個脫敏層。具體在打印和序列化時需要識別常見的敏感字段名SENSITIVE_KEYS {password, secret, token, api_key} def safe_dump(data): if isinstance(data, dict): return {k: (*** if k.lower() in SENSITIVE_KEYS else safe_dump(v)) for k, v in data.items()} if isinstance(data, list): return [safe_dump(i) for i in data] return data然后把所有對外輸出改成走safe_dump底層的存量數(shù)據(jù)保持原樣。這里關(guān)鍵在于展示層脫敏存儲層不脫敏——如果你把存儲層的值都改了那后續(xù)需要用真實密碼時就會出錯。這個坑給我一個更深的教訓(xùn)context-mode這類工具天然就是什么數(shù)據(jù)都往里塞的類型所以必須在設(shè)計階段就明確哪些數(shù)據(jù)碰都不能碰對于高敏感數(shù)據(jù)寧可完全不放進(jìn)去。4.4 修復(fù)后的驗證方案我是怎么確認(rèn)問題真解決的修完三個坑之后我整理了一組回歸測試用例專門用來驗證context-mode模塊的穩(wěn)定性。這組用例現(xiàn)在被我放在項目的tests目錄下每次改動后都會跑一遍并發(fā)測試同時啟動8個進(jìn)程每個進(jìn)程往context里寫入不同的key重復(fù)100輪最后檢查JSON文件里是否所有key都完整存在。過期測試創(chuàng)建一條TTL為1秒的數(shù)據(jù)sleep 1.2秒后讀取確認(rèn)返回None并且該key從存儲中刪除。隱私測試用一個包含了password的假上下文跑一次打印確認(rèn)輸出中對應(yīng)字段是***。邊界測試key名稱為空字符串、value為None、value為中文和帶Unicode的字符都要能正常寫入和讀取。這些測試全部通過的時候心里才踏實下來。尤其是并發(fā)測試第一次跑就失敗后來加上進(jìn)程鎖才通過那種測試救了一命的感覺寫代碼的人都懂。5. 從context-mode到智能化在LLM會話場景中的擴(kuò)展5.1 把context-mode用在大模型交互上滑動窗口和摘要搞定了基礎(chǔ)模塊之后我把它用在了另一個更貼近當(dāng)前熱點的場景大語言模型LLM會話的上下文管理。很多人問為什么AI聊天工具不能無限記住所有對話核心原因就是上下文窗口有上限。context-mode在這里的價值是可以設(shè)計一種滑動窗口 摘要的組合策略。具體做法是維護(hù)一個會話歷史列表新消息不斷加入。當(dāng)列表長度超過N條或者總token數(shù)超過閾值時我們?nèi)∏懊嫒舾蓷l消息做一次摘要然后把摘要作為一個新的系統(tǒng)消息再丟掉最老的消息。這樣實際上形成了一種滾動上下文。我把這個邏輯復(fù)用了之前的ContextManager只是在session層里存了一個chat_historyMAX_HISTORY 10 def append_message(role, content): history ctx.get(session, chat_history) or [] history.append({role: role, content: content}) if len(history) MAX_HISTORY: old_part history[:-MAX_HISTORY // 2] recent_part history[-MAX_HISTORY // 2:] old_text \n.join(f{m[role]}: {m[content]} for m in old_part) summary llm_summarize(old_text) # 調(diào)用模型生成摘要 ctx.set(session, chat_summary, summary) ctx.set(session, chat_history, recent_part) else: ctx.set(session, chat_history, history)這套方案的關(guān)鍵是摘要的更新時機(jī)。如果每來一條新消息就跑一次摘要成本太高我的經(jīng)驗是等舊部分累計超過閾值時再整體生成一次摘要。另外要注意摘要本身也應(yīng)該有TTL因為它保存的是會話的臨時狀態(tài)會話結(jié)束或被新摘要替代后就不再需要了。5.2 后續(xù)還能怎么擴(kuò)展共享上下文、權(quán)限控制、可視化調(diào)試現(xiàn)在這個context-mode模塊已經(jīng)能穩(wěn)定運行了但還談不上完善。我自己整理了三個明確的擴(kuò)展方向如果你也在做類似項目可以參考。第一個方向是共享上下文。目前每個用戶各自維護(hù)一份context文件如果想在團(tuán)隊里共享項目級上下文就需要引入同步機(jī)制。我的初步思路是給每條context記錄加一個owner字段拉取時先檢查權(quán)限只返回自己有權(quán)限的部分。這樣可以做到項目組共享構(gòu)建參數(shù)個人私有配置不泄露。第二個方向是權(quán)限控制。這跟上面的共享是配套的。context里往往包含敏感信息比如數(shù)據(jù)庫連接串、臨時密鑰。改造方向是在set/get的接口中加入一個權(quán)限校驗層按照用戶角色判斷當(dāng)前操作是否被允許。最簡單的實現(xiàn)是建一個權(quán)限表每個key對應(yīng)一個可訪問的角色列表復(fù)雜一點的方向是做成與現(xiàn)有SSO/身份系統(tǒng)對接。第三個方向是可視化調(diào)試。前端工程師調(diào)試時最想看的是上下文樹的實時變化。我已經(jīng)用Python做了個簡單的Web頁面把ContextManager暴露成一個HTTP接口用WebSocket推送變更事件界面上能看到global/session/project三層的數(shù)據(jù)新增、過期、刪除。這個擴(kuò)展對排查為什么某次操作行為異常特別有用因為你能看到程序到底記住了什么。把context-mode從一個小模塊擴(kuò)展成完整的上下文管理框架這條路其實很長。但至少起步階段的方向是清晰的先保證數(shù)據(jù)結(jié)構(gòu)合理再確保并發(fā)安全最后再往智能化和協(xié)作方向走。我在實際項目中體會最深的一點是context-mode看起來像是個不起眼的輔助功能但對用戶體驗的提升是實實在在的。它讓工具從一個每次都要重新認(rèn)識你的陌生人變成了記得你習(xí)慣的同事。開發(fā)過程中踩過的這三個坑——并發(fā)覆蓋、過期混亂、隱私泄漏——幾乎每一個都值得單獨寫篇文章但總結(jié)下來核心原則也就三條上下文要分層、過期要按字段、敏感要脫敏。記住這三點你也能做出一個穩(wěn)定好用的context-mode。