1. 项目概述Context-Mode 不是玄学而是可落地的上下文调度机制“Context-mode”这个词最近在开发者社区里频繁出现尤其和 MCP、SQLite、FTS5、BM25 这几个关键词绑在一起。它不是某个开源库的官方命名也不是某家大厂刚发布的黑科技产品而是一种面向智能体Agent运行时环境的上下文组织与调度范式。我第一次在蓝湖、Figma、MasterGo 的插件文档里看到它后来在 Cursor、Yakit、Codex 的扩展配置中反复撞见——它总出现在“如何让 AI 工具精准读取本地数据库”“怎样让 Agent 理解当前设计稿语义”“为什么同一个 prompt 在不同项目里效果差一倍”这类真实卡点场景里。简单说context-mode 解决的是当 AI 不再是孤立调用 API 的“答题机器”而是嵌入到你日常开发/设计/运维工作流中的“协作者”时它该以什么结构、什么粒度、什么优先级去加载和理解你此刻正在处理的上下文它不是模型层的技术而是连接模型能力与真实工作场景的“上下文中间件”。核心不在于“有没有上下文”而在于“上下文怎么组织、怎么索引、怎么裁剪、怎么保鲜”。这正是 SQLite FTS5 BM25 组合被高频选用的原因——它们共同构成了一套轻量、可靠、可嵌入、可调试的本地上下文引擎。适合前端工程师快速接入设计系统语义适合后端开发者为内部工具注入知识检索能力也适合安全研究员把 Burp Suite 的历史请求自动构建成可检索的上下文空间。它不依赖云服务不绑定特定模型甚至能在 Windows 下用 Delphi 调用虽然乱码问题得手动处理编码真正做到了“写进项目 README 就能跑起来”。2. Context-Mode 的底层逻辑与架构选型解析2.1 为什么不是 Redis 或 Elasticsearch——轻量级上下文的刚性约束很多人第一反应是“上下文存储用 Redis 缓存不香吗或者直接上 ES 做全文检索” 我试过两种方案结果很明确Redis 适合临时会话状态但撑不起结构化上下文Elasticsearch 强大但重且与本地开发流割裂。Context-mode 的本质需求有四个硬约束第一嵌入性——必须能随主程序比如一个 Figma 插件、一个 Cursor 扩展、一个 Kingscada 工程一起打包分发不能要求用户额外装 Java 环境或 Docker第二原子性——上下文更新比如设计稿变更、代码文件保存必须与主程序操作强一致不能出现“改了文件但检索没刷新”的错位第三可调试性——开发者需要随时打开 DB Browser for SQLite 查看当前上下文长什么样而不是对着 Kibana 一堆 JSON 发呆第四零配置启动——一个sqlite3 context.db命令就能建库比配 ES 的elasticsearch.yml和jvm.options省心十倍。SQLite 完美命中这四点。它不是一个“简陋的玩具数据库”而是经过 20 年工业验证的嵌入式引擎。它的 WAL 模式支持高并发读写它的.db文件就是单个二进制文件复制即备份删除即清理。更重要的是SQLite 从 3.34.0 版本起原生支持 FTS5Full-Text Search 5这是它能扛起 context-mode 大旗的关键。FTS5 不是简单的 LIKE 模糊匹配而是实现了BM25 排序算法——这个算法正是现代搜索引擎包括大模型 RAG 中的检索模块的核心排序逻辑。它会根据词频TF、逆文档频率IDF、字段长度归一化等因子给每个匹配结果打分确保“当前编辑的 Sketch 文件名”比“三年前某次会议纪要里的同名词汇”排得更靠前。这种排序能力让 context-mode 从“能搜到”升级为“搜得准”。2.2 FTS5 与 BM25为什么不用 Lucene 或 Whoosh——本地检索的精度与速度平衡有人会问“Python 里不是有 Whoosh、Haystack 这些纯 Python 的全文检索库吗为什么非要用 SQLite 的 FTS5” 关键在于跨语言兼容性与执行效率。Context-mode 的典型场景是Figma 插件用 JavaScript 写但上下文数据存在本地 SQLiteBlender 的 MCP 插件用 Python却要读取同一份 SQLiteJava 写的 Kingscada 工程也要接入。如果用纯 Python 库JavaScript 端就得重写一套Java 端又得再适配维护成本爆炸。而 SQLite 是真正的“一次写入处处可用”——所有主流语言都有成熟、稳定的 SQLite 绑定Delphi 用 SQLite3.pasJava 用 sqlite-jdbcPython 用内置 sqlite3JavaScript 用 sql.js 或 sqlite-wasm。FTS5 的 BM25 实现是 C 语言写的直接编译进 SQLite 核心没有 Python 解释器的 GIL 拖累也没有 JVM 的 GC 停顿。我实测过在一个 50MB 的设计系统元数据 SQLite 库含 20 万条组件描述上执行SELECT * FROM components_fts WHERE components_fts MATCH button primary ORDER BY rank;平均响应时间是 8.3msSSD而同等数据量下 Python Whoosh 的平均响应是 42ms。这 34ms 的差距在 UI 交互中就是“卡顿”和“丝滑”的区别。BM25 的公式本身并不复杂score(Q, D) Σ (tf * (k1 1)) / (tf k1 * (1 - b b * |D|/avgdl)) * idf其中tf是词在文档中出现次数idf是逆文档频率|D|是文档长度avgdl是平均文档长度k1和b是可调参数SQLite 默认k11.2,b0.75。FTS5 把这些计算全压在 C 层完成应用层只管发 SQL。这种“数据库内核级优化”带来的性能红利是任何应用层封装无法替代的。2.3 MCP 协议Context-Mode 的通信契约——不是 API而是约定MCPModel Context Protocol这个词在热词列表里高频出现但它常被误解为一个具体的技术栈。实际上MCP 是一套轻量级通信协议规范定义了“智能体Agent”如何向“上下文服务Context Service”发起查询、如何接收结构化结果、如何声明自己的上下文需求。它不规定传输层用 HTTP 还是 WebSocket也不限定序列化格式是 JSON 还是 Protobuf核心只约定了三个东西上下文源标识Context Source ID比如figma://project/12345、github://repo/owner/repo/tree/main/src、local://path/to/workspace。这个 ID 让 Agent 能区分“当前在 Figma 里编辑的画板”和“本地 Git 仓库里的源码”避免混淆查询表达式Query Expression不是原始字符串而是带语义的结构体。例如{ type: fts, query: primary button, fields: [name, description], limit: 10 }。这比裸 SQL 更安全也更易被不同语言解析结果 SchemaResult Schema返回的数据必须包含source_id、relevance_scoreBM25 分、content原始文本、metadata如文件路径、修改时间、作者。这个 Schema 让 Agent 无需解析 HTML 或 Markdown直接拿到结构化上下文片段。MCP 的价值在于“解耦”。一个 Figma 插件Client不需要知道背后是 SQLite 还是 PostgreSQL只要按 MCP 规范发请求一个 SQLite 上下文服务Server也不关心前端是 React 还是 Vue只要按 MCP 规范返回 JSON。我在 Codex MCP Demo 里看到过最朴素的实现一个 Python 脚本监听本地context.mcp文件变化一旦有新查询写入就执行 SQLite 查询把结果写回同名文件。整个协议连网络都不用纯粹靠文件轮询——这就是 MCP 的哲学够用、简单、可降级。它不像 gRPC 那样追求极致性能也不像 REST 那样强调资源抽象而是为“本地智能体协作”量身定制的最小公约数。3. Context-Mode 的核心实现细节与实操要点3.1 SQLite 数据库结构设计不止是建表而是构建上下文图谱Context-mode 的 SQLite 数据库绝不是简单建个contexts表塞文本就完事。我见过太多失败案例把所有设计稿描述、代码注释、会议记录全塞进一个raw_text字段结果检索慢、更新难、调试懵。正确的做法是构建一个三层结构的上下文图谱第一层源实体表Source Entities这是上下文的“锚点”每条记录代表一个不可分割的语义单元。例如Figma 插件figma_components表字段包括idFigma node ID、name组件名、typebutton|input|card、project_id、last_modified代码工程code_files表字段包括file_path、languagetypescript|python、class_name、function_namesJSON 数组、git_commit_hash设计文档markdown_docs表字段包括doc_id、title、section_hierarchyUI/Buttons/Primary、author、created_at。关键点每个源实体必须有唯一、稳定、可追溯的标识符ID。Figma 的 node ID、Git 的 commit hash、文件的绝对路径或 SHA256 哈希都是好选择。避免用自增 ID因为上下文可能跨设备同步。第二层FTS5 虚拟表Full-Text Search Tables为每个源实体表创建对应的 FTS5 虚拟表这是 BM25 检索的引擎。例如CREATE VIRTUAL TABLE components_fts USING fts5( name, description, tags, contentfigma_components, content_rowidid, tokenizeunicode61 );这里contentfigma_components表示此虚拟表的内容来自figma_components表content_rowidid表示用figma_components.id作为关联键tokenizeunicode61启用 Unicode 分词支持中文、日文等。切记不要在 FTS5 表里存冗余字段——components_fts只负责检索name和description字段只是索引入口实际内容仍存在figma_components表里。这样更新时只需改源表FTS5 会自动同步。第三层上下文关系表Context Relations这是让 context-mode “活起来”的关键。它记录不同源实体间的语义关联。例如component_to_code表记录某个 Figma 组件component_id对应哪些代码文件file_path字段包括confidence_score人工标注或 LLM 生成的匹配置信度doc_to_component表记录某篇设计文档doc_id引用了哪些组件component_id字段包括reference_typeimplements|references|contradicts。这些关系表让检索结果不再孤立。当你搜索“primary button”时FTS5 返回匹配的组件再 JOINcomponent_to_code表就能立刻拿到对应的 React 组件源码路径——这才是真正的“上下文感知”。提示Delphi 调用 SQLite 时常见的乱码问题根源在于 Delphi 的AnsiString和 SQLite 的 UTF-8 编码不兼容。解决方案不是改数据库编码SQLite 内部强制 UTF-8而是统一用UTF8Encode()和UTF8Decode()转换字符串或直接使用WideString类型Delphi 2009 支持 Unicode。3.2 BM25 参数调优实战不是调参玄学而是业务语义映射FTS5 的 BM25 参数k1和b默认值1.2 和 0.75是通用设置但在 context-mode 场景下往往需要调整。我拿 Figma 组件库做过实测当k11.2时搜索 “icon” 会把所有含 “icon” 的组件都排前面包括 “icon-button”、“icon-list”、“icon-font-settings”当k10.5时短词权重降低“icon-button” 因为整体匹配度更高而胜出当b0.3时低于默认 0.75文档长度归一化影响变小长描述的组件如详细设计规范不会因长度吃亏当b0.9时短小精悍的组件名如 “Button”会获得显著加权。调参的本质是把业务规则翻译成数学参数。如果你的上下文以短命名为主如组件名、API 端点就调低b如果上下文以长文档为主如设计规范、技术白皮书就调高b。k1控制词频饱和度k1越小单个词出现多次带来的增益越小更适合“关键词精准匹配”场景k1越大词频影响越强更适合“语义相关性”场景。我在 Cursor 开发 Skill 时为代码片段检索设k12.0, b0.5因为函数名重复出现如handleClick确实意味着高相关性而在蓝湖设计系统里为组件名检索设k10.8, b0.2因为“Button” 出现 10 次和出现 1 次对匹配质量影响不大。调参没有银弹唯一方法是用真实业务查询语句做 A/B 测试统计 top-3 结果的相关率。我写了个 Python 脚本自动遍历queries.txt里的 100 条搜索词对比不同参数下人工标注的“前 3 名是否相关”生成 CSV 报告。这才是工程师该有的调参姿势不是拍脑袋。3.3 MCP Server 的极简实现50 行 Python 足够跑通MCP Server 不需要 Spring Boot 或 FastAPI。一个基于watchdog和sqlite3的 50 行脚本就能满足绝大多数本地场景。核心逻辑只有三步监听上下文变更用watchdog监控./context_sources/目录当 Figma 导出的 JSON、Git 的git log --oneline输出、Markdown 文档被修改时触发更新增量更新 SQLite解析变更文件提取结构化数据执行INSERT OR REPLACE INTO figma_components ...并触发INSERT INTO components_fts(content) VALUES(rowid)刷新索引响应 MCP 查询监听本地 Unix Socket或 TCP 端口收到 MCP JSON 请求后解析query字段拼接 SQLite 查询返回带relevance_score的结果数组。以下是一个可直接运行的简化版 MCP ServerPython 3.8import sqlite3 import json import socket import threading from pathlib import Path DB_PATH context.db SOCKET_PATH /tmp/mcp.sock def handle_query(query_data): conn sqlite3.connect(DB_PATH) conn.row_factory sqlite3.Row cur conn.cursor() # 解析 MCP 查询 query_type query_data.get(type) if query_type fts: search_term query_data[query] limit query_data.get(limit, 10) # 构建 BM25 查询显式指定 rank sql f SELECT c.*, c_fts.rank AS relevance_score FROM figma_components c JOIN components_fts c_fts ON c.id c_fts.rowid WHERE c_fts MATCH ? ORDER BY c_fts.rank LIMIT ? cur.execute(sql, (search_term, limit)) results [dict(row) for row in cur.fetchall()] return {results: results} return {error: unsupported query type} def mcp_server(): sock socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) sock.bind(SOCKET_PATH) sock.listen(1) print(fMCP Server listening on {SOCKET_PATH}) while True: conn, _ sock.accept() try: data conn.recv(4096).decode(utf-8) if not data: continue query_data json.loads(data) response handle_query(query_data) conn.send(json.dumps(response).encode(utf-8)) except Exception as e: conn.send(json.dumps({error: str(e)}).encode(utf-8)) finally: conn.close() if __name__ __main__: # 初始化数据库仅首次运行 init_db() # 启动服务器线程 server_thread threading.Thread(targetmcp_server, daemonTrue) server_thread.start() # 主线程可做文件监听... input(Press Enter to exit...)这个脚本的妙处在于它把 MCP 协议降维到了文件系统和 Socket 层。Figma 插件只需echo {type:fts,query:dialog} | nc -U /tmp/mcp.sock就能拿到结果Java 程序用UnixDomainSocketAddress连接甚至 Bash 脚本都能调用。没有 HTTP 的 header 开销没有 TLS 握手延迟这就是 context-mode 追求的“零摩擦集成”。4. Context-Mode 的完整实操流程从零搭建一个 Figma 插件上下文服务4.1 环境准备与工具链确认Windows 下的 SQLite 安装不是噩梦很多开发者卡在第一步Windows 下怎么装 SQLite网上教程动辄让你下载sqlite-tools-win32-x86-*.zip解压后还要配 PATH。其实最稳的方案是直接用 DB Browser for SQLite。它不只是“查看工具”它自带最新版 SQLite 引擎和图形化建表界面安装即用。下载地址是官网https://sqlitebrowser.org/安装时勾选“Add to PATH”它会自动把sqlite3.exe加到系统变量。验证是否成功C:\ sqlite3 --version 3.45.1如果报错重启命令行窗口。接着用 DB Browser 创建figma_context.db然后切换到 “Execute SQL” 标签页粘贴建表语句-- 源实体表 CREATE TABLE figma_components ( id TEXT PRIMARY KEY, name TEXT NOT NULL, description TEXT, type TEXT, project_id TEXT, last_modified INTEGER ); -- FTS5 虚拟表 CREATE VIRTUAL TABLE components_fts USING fts5( name, description, contentfigma_components, content_rowidid, tokenizeunicode61 ); -- 关系表 CREATE TABLE component_to_code ( component_id TEXT, file_path TEXT, confidence_score REAL DEFAULT 0.0, FOREIGN KEY(component_id) REFERENCES figma_components(id) );点击 “Execute” 即可。DB Browser 会实时显示表结构比敲命令行直观十倍。对于 Delphi 开发者推荐用SQLite3.pas单元GitHub 搜索 “delphi sqlite3 pas”它封装了所有 C API支持 Unicode且无第三方 DLL 依赖。4.2 数据注入如何把 Figma 设计稿变成可检索的上下文Figma 插件导出的 JSON 是扁平的但 context-mode 需要结构化。假设你导出的components.json长这样[ { id: 123:456, name: Primary Button, description: A bold call-to-action button with hover states., type: BUTTON, project: design-system-v2 } ]你需要一个注入脚本Python 示例import json import sqlite3 from datetime import datetime def inject_figma_data(json_path): conn sqlite3.connect(figma_context.db) cur conn.cursor() with open(json_path, r, encodingutf-8) as f: components json.load(f) for comp in components: # 插入源实体 cur.execute( INSERT OR REPLACE INTO figma_components (id, name, description, type, project_id, last_modified) VALUES (?, ?, ?, ?, ?, ?) , ( comp[id], comp[name].strip(), comp.get(description, ).strip(), comp[type], comp[project], int(datetime.now().timestamp()) )) # 刷新 FTS5 索引关键 cur.execute(INSERT INTO components_fts(rowid) VALUES(?), (comp[id],)) conn.commit() print(fInjected {len(components)} components.) if __name__ __main__: inject_figma_data(components.json)注意INSERT INTO components_fts(rowid) VALUES(?)这一行——它告诉 FTS5 “请为这个 rowid 重新索引源表对应行”。如果不执行这步FTS5 表还是空的检索永远返回 0 条。这个脚本可以做成 Figma 插件的“导出后钩子”每次点击导出就自动更新本地上下文库。4.3 检索测试用 BM25 验证上下文质量建库和注入完成后别急着写前端先用 SQLite 命令行验证检索效果。打开sqlite3 figma_context.db执行-- 查看 FTS5 是否生效 SELECT count(*) FROM components_fts; -- 执行 BM25 检索注意rank 是 FTS5 的内置列 SELECT name, description, rank FROM components_fts WHERE components_fts MATCH primary button ORDER BY rank LIMIT 5;你会看到类似这样的结果Primary Button|A bold call-to-action button...|0.123456 Secondary Button|A less prominent action button...|0.098765 Button Group|A container for multiple buttons...|0.087654rank值越小相关性越高BM25 是负分SQLite 显示为正数数值越小越好。如果rank全是 0说明 FTS5 没索引到数据检查INSERT INTO components_fts(rowid)是否执行如果count(*)是 0说明虚拟表没建好。这个 CLI 测试是 debug 的黄金步骤比在浏览器里看空白页面高效百倍。4.4 前端集成Figma 插件如何调用 MCP ServerFigma 插件JavaScript调用本地 MCP Server 的代码极其简单// figma-plugin-main.ts async function searchContext(query: string): Promiseany[] { try { // 构造 MCP 查询 const mcpRequest { type: fts, query: query, fields: [name, description], limit: 5 }; // 发送请求Node.js 环境下用 net.Socket const { Socket } require(net); const client new Socket(); client.connect(/tmp/mcp.sock, () { client.write(JSON.stringify(mcpRequest)); }); return new Promise((resolve, reject) { client.on(data, (data) { try { const response JSON.parse(data.toString()); resolve(response.results || []); } catch (e) { reject(e); } }); client.on(error, reject); }); } catch (e) { console.error(MCP search failed:, e); return []; } } // 在插件 UI 中调用 figma.showUI(__html__, { width: 400, height: 300 }); figma.ui.onmessage async (msg) { if (msg.type SEARCH) { const results await searchContext(msg.query); figma.ui.postMessage({ type: SEARCH_RESULTS, results }); } };关键点Figma 插件运行在 Node.js 环境通过figma-plugin-draft或figma/plugin-sandbox所以可以直接用net.Socket连 Unix Socket。如果是在浏览器环境如 Web 版 Figma则需用fetch调 HTTP MCP Server。这个集成过程把 Figma 的视觉编辑和 SQLite 的语义检索无缝缝合——当你在画布上拖拽一个按钮时右侧面板已列出所有相关的代码实现、设计规范、历史迭代记录。这才是 context-mode 的终极体验。5. 常见问题与排查技巧实录那些文档里不会写的坑5.1 SQLite FTS5 中文检索失效——分词器与编码的双重陷阱现象插入中文数据后MATCH 按钮返回空但MATCH button正常。原因有两个分词器未启用 UnicodeSQLite 默认tokenizenone对中文就是按字节切分。必须显式指定tokenizeunicode61支持 UTF-8 的 Unicode 分词数据编码不一致Python 用open(..., encodinggbk)读取文件但 SQLite 期望 UTF-8。解决方案所有文本输入必须str.encode(utf-8).decode(utf-8)强制标准化。实测修复步骤删除旧 FTS5 表DROP TABLE components_fts;重建时指定分词器CREATE VIRTUAL TABLE components_fts USING fts5(name, description, tokenizeunicode61);插入数据前统一编码text text.encode(utf-8).decode(utf-8)。注意unicode61分词器对中文是“按字分词”不是“按词分词”。如果需要“按钮”作为一个词而非“按”“钮”得用porter或自定义分词器但 context-mode 场景下按字分词已足够——因为设计稿里“按钮”通常就是独立命名的组件。5.2 BM25 排序结果与直觉不符——理解 rank 的物理意义现象搜索 “loading spinner”一个描述为 “Loading spinner component for async operations” 的记录 rank 是 0.23另一个只有 “spinner” 二字的记录 rank 是 0.18后者排在前面但前者明显更相关。原因BM25 的rank是综合得分但k1和b参数让短文本在某些情况下占优。这不是 bug是算法特性。解决方法不是改算法而是用上下文关系二次排序。例如-- 先用 BM25 初筛 WITH ranked AS ( SELECT c.*, c_fts.rank AS bm25_rank FROM figma_components c JOIN components_fts c_fts ON c.id c_fts.rowid WHERE c_fts.MATCH loading spinner ) -- 再用关系表置信度加权 SELECT *, bm25_rank * (1 - COALESCE(r.confidence_score, 0.0)) AS final_score FROM ranked c LEFT JOIN component_to_code r ON c.id r.component_id ORDER BY final_score LIMIT 5;这里用confidence_score人工标注或 LLM 生成对 BM25 分做衰减让“有代码实现的 spinner”天然比“纯设计稿 spinner”得分更高。这才是 context-mode 的精髓BM25 是基础检索关系图谱才是智能排序。5.3 MCP Server 响应超时——Socket 连接与缓冲区的隐形杀手现象Figma 插件调用 MCP Server 时偶尔卡住 30 秒后报 timeout。排查发现nc -U /tmp/mcp.sock手动测试正常但插件里不稳定。根本原因Unix Socket 的send()和recv()是阻塞的且默认缓冲区小。当插件发送的 JSON 超过 4KB或 Server 返回结果超过 8KB就可能卡住。解决方案Client 端插件设置 socket timeout并用setEncoding(utf8)Server 端增大 socket 缓冲区或改用socket.setNoDelay(true)关闭 Nagle 算法最稳妥方案在 MCP 协议里加 length header。发送前先发 4 字节的Uint32BE表示 JSON 长度Server 先读 4 字节再读对应长度数据。这增加了 4 字节开销但彻底解决粘包问题。我在 Yakit MCP 的源码里看到过这种实现值得借鉴。5.4 多个上下文源冲突——Source ID 的设计哲学现象Figma 插件和 Cursor 插件都往同一个context.db写数据结果figma_components表里混进了代码文件路径。原因没有严格隔离Source ID。正确做法是每个上下文源Figma、Git、Docs使用独立的源实体表figma_components、code_files、markdown_docs每个源实体表对应独立的 FTS5 表components_fts、files_fts、docs_ftsMCP 查询必须指定source_idServer 根据source_id路由到对应表。例如MCP 查询{ source_id: figma://project/abc123, type: fts, query: modal }Server 解析source_id前缀figma://就知道该查components_fts表。这种设计让 context-mode 天然支持多源融合又避免数据污染。我在 MasterGo MCP 的文档里看到过类似实践他们用mastergo://前缀隔离设计稿上下文。5.5 性能瓶颈在哪儿——SQLite 的 WAL 模式与写入锁现象当 Figma 插件高频导出每秒 1 次MCP Server 的检索响应变慢甚至超时。原因SQLite 默认的DELETE模式在写入时会锁整个数据库读操作被阻塞。解决方案启用 WALWrite-Ahead Logging模式。在建库后立即执行PRAGMA journal_mode WAL; PRAGMA synchronous NORMAL; PRAGMA temp_store MEMORY;WAL 模式允许多个读操作并发写操作只锁住 WAL 文件不影响读。synchronous NORMAL降低 fsync 频率牺牲极小数据安全性换取速度temp_store MEMORY把临时表放内存。这三项设置能让 SQLite 在高并发读写下保持亚毫秒级响应。我在 Blender MCP 插件的性能报告里看到过数据启用 WAL 后100 并发检索的 P99 延迟从 120ms 降到 8ms。6. Context-Mode 的延展与未来不止于 SQLite但始于 SQLiteContext-mode 的核心价值从来不在技术栈本身而在于它把“上下文”从一个模糊的概念变成了一个可版本化、可调试、可协作的工程实体。SQLite FTS5 BM25 是它的最佳起点因为它们足够轻、足够稳、足够透明。但这不是终点。我看到的几个自然延展方向是向量化扩展当 BM25 遇到语义鸿沟比如搜索 “让用户感到安心的 UI”BM25 找不到“安心”这个词可以引入轻量级 embedding 模型如all-MiniLM-L6-v2用 SQLite 的json1扩展存向量用cosine_similarity函数做混合检索。这不是取代 BM25而是补充——BM25 处理关键词向量处理语义两者分数加权。分布式同步workbudyy mcp gitee项目展示了用 Git 作为上下文同步协议的思路。每个开发者本地 SQLite 库就是一个 Git 仓库git push/pull就是上下文同步。这比中心化服务更符合开发者心智。技能Skill集成agent skill 和 mcp有什么区别这个热词揭示了趋势——MCP 是上下文供给协议Skill 是动作执行协议。一个 Skill 可以调用 MCP 获取上下文再调用另一个 Skill 执行代码生成。它们不是竞争关系而是流水线上的上下游。最后分享一个小技巧永远用sqlite3CLI 作为你的第一调试工具。当 Figma 插件报错时别急着翻 Chrome DevTools先打开终端sqlite3 context.dbSELECT * FROM figma_components LIMIT 5;SELECT * FROM components_fts WHERE components_fts MATCH xxx;。90% 的问题都能在 30 秒