专题目录

Memory Center:AI 编程上下文与记忆系统工程实践
问题与设计思想 5
  1. 01为什么 AI 编程助手需要一个项目记忆中心
  2. 02上下文工程:如何提供下一步真正需要的信息
  3. 03事实、推断和未知:为 AI 的工程判断划定边界
  4. 04代码、文档、任务和长期知识应该如何分工
  5. 05从设计原则到架构约束:如何记录真正有用的 ADR
服务架构与项目边界 5
  1. 06从单项目工具演进为多项目常驻服务
  2. 07管理 API 与 MCP 如何共用应用层
  3. 08FastAPI 与 MCP 如何共同管理服务生命周期
  4. 09项目名称和目录为什么不应该成为项目身份
  5. 10本机模式与令牌模式:多项目访问边界怎么设计
索引与代码事实 5
  1. 11一份源码如何变成可查询的工程事实
  2. 12用 Tree-sitter 理解多语言代码的结构与局限
  3. 13如何用节点和边表达类、方法、接口与服务
  4. 14Java 与 Spring 的跨服务关系为什么需要专用分析
  5. 15增量索引如何复用旧事实,又避免复用损坏结果
检索与证据组合 5
  1. 16代码和文档怎样分块,才能保留可追溯来源
  2. 17BM25 如何把关键词匹配变成相关性排序
  3. 18向量检索如何处理模型档案、范围与缓存
  4. 19混合检索:召回、RRF 与重排如何配合
  5. 20如何返回可信证据:权限、新鲜度与覆盖范围
任务记忆与长期知识 5
  1. 21开始、恢复和结束:给 AI 任务设计完整生命周期
  2. 22项目记忆为什么不能只是追加一段文本
  3. 23Wiki 为什么需要稳定记录、修订与冲突检测
  4. 24从任务经验到长期知识:如何控制晋升过程
  5. 25从文档到 Skill:可复用经验如何形成工件
可靠后台任务 5
  1. 26为什么索引任务需要独立 Worker
  2. 27一个后台任务的排队、执行、取消与中断恢复
  3. 28新索引构建失败,怎样保住旧索引的查询能力
  4. 29在途任务遇到配置变更,如何拒绝过期结果
  5. 30如何协调项目并发、文件 Worker 与外部模型请求
存储与运维治理 5
  1. 31SQLite 与 PostgreSQL:根据负载选择存储形态
  2. 32SQLite 流式 Top-K 与 pgvector 距离检索
  3. 33项目空间统计为什么不等于实际磁盘占用
  4. 34历史索引清理:从直接删除到预览与复核
  5. 35如何部署与维护一个本地优先的 AI 服务
验证与完整实践 5
  1. 36MCP 调用为什么需要分阶段执行轨迹
  2. 37如何测试 MCP、HTTP 与应用层的共同契约
  3. 38检索效果怎样评估,哪些指标容易误导
  4. 39一次实际开发任务如何使用 Memory Center
  5. 40复盘:哪些设计值得保留,哪些需要重新判断

第 12 篇

工程技术

用 Tree-sitter 理解多语言代码的结构与局限

结合实际开发项目,讨论用 Tree-sitter 理解多语言代码的结构与局限,说明设计理由、关键源码、验证方法及适用边界。

起源未来约 7 分钟阅读#Memory Center#索引与代码事实#工程实践
我的阅读
Memory Center 索引与代码事实 工程实践

本文目录 · 7 节

本文属于 Memory Center:AI 编程上下文与记忆系统工程实践,第 12 篇,位于“索引与代码事实”模块。案例背景统一采用实际开发项目;复现步骤使用脱敏教学样例,不代表特定生产事故。

从实际问题出发

正则表达式容易把注释中的函数名当成代码,也难以稳定区分嵌套声明。语法树提供结构基础,但从语法节点到“这个调用最终执行哪个实现”,仍需要额外语义分析。

解析与解析目标分两步

Tree-sitter 帮助识别声明和调用位置,模块解析、继承与接收者类型用于进一步消歧。解析成功只表示语法层面取得结构,不能推出每个调用都已链接到唯一目标。

用 Tree-sitter 理解多语言代码的结构与局限:设计链路示意

图中展示的是本篇关注的职责和顺序。正常流程之外,还要结合下面的源码与实验检查失败分支;它不是对某次线上调用的运行时追踪。

多语言意味着多种边界

不同语言的导出、别名、方法绑定和组件语义并不相同。共用节点模型能统一查询,但不能抹掉差异。解析缓存还必须包含解析器或结构版本,避免升级规则后继续使用旧结构。

关键源码与阅读方法

源码基线为 Memory Center 6e90553(文档标注 5.0.0b24)。定位:memory_center/platform/code_graph.py,函数 parse_file_unit,起始行 27。

以下为源码节选,省略后续分支;不能作为独立脚本执行。

def parse_file_unit(item: tuple[str, str, str, ParseCache | None]):
    """解析单个文件——工作池任务,故必须是模块级函数(spawn 按引用 pickle)。

    ``item`` 为 ``(relative, abspath, digest, cache)``。``digest`` 是调用方
    (扫描/切块阶段)已经算好的内容 sha256;为空串时本函数自行读文件并计算。
    返回 ``(relative, language, status, content_hash, result)``。
    单文件异常在此兜住并返回 ``status='failed:<ExcType>'`` + ``result=None``,
    使一个坏文件只影响自己的覆盖状态,不牵连同批其余文件。
    串行与池化两条路径调用的是同一个函数,这是等价性门槛的落点。

    读取尽量不发生:``digest`` 由调用方提供且缓存命中时直接解码返回,完全不碰文件
    系统——同一份源码因此不再被「切块」与「解析」各读一遍。``digest`` 的提供方保证
    该文件在本次索引内已被成功读取,故命中路径不必再确认文件是否仍在。未提供
    ``digest`` 时退回旧行为:读文件、算哈希,再查一次缓存(命中则跳过 tree-sitter)。

    ``cache`` 非空时按(语言, 内容 sha256)取用解析结果;命中与未命中返回**逐值相等**
    的对象,故缓存只影响速度(见 parse_cache 模块)。解析器不可用(未装 tree-sitter、
    语言无绑定)时**不落缓存**——否则「缺绑定」会被固化成持久结果,装上绑定后仍读回空解析。
    """
    relative, abspath, digest, cache = item
    spec = get_language_spec_for_extension(Path(abspath).suffix)
    if spec is None:
        return relative, '', 'unsupported', '', None
    try:
        parser = _CHILD_PARSERS.get(spec.name)
        if parser is None:
            parser = TreeSitterStructuralParser(spec.name)
            _CHILD_PARSERS[spec.name] = parser
        hit = _structural_cache_hit(cache, parser, spec.name, digest)
        if hit is not None:
            return relative, spec.name, hit.raw.get('parse_status', 'unavailable'), digest, hit
        text = Path(abspath).read_text(encoding='utf-8', errors='replace')
        if not digest:
            digest = hashlib.sha256(text.encode()).hexdigest()
            hit = _structural_cache_hit(cache, parser, spec.name, digest)
            if hit is not None:

阅读时先找输入由谁提供,再区分纯计算、读取和写入;遇到异常或提前返回,追问调用方会得到什么,以及已有状态是否仍然有效。上面的代码只证明展示范围内的实现,跨模块行为应继续查看调用处和相应测试。

用一个小实验核对设计

建议在独立临时目录和隔离数据中操作,使用虚构的接口、文档与项目名称。

  1. 准备同名函数、别名导入与损坏语法三个样例。
  2. 比较结构提取和调用解析结果。
  3. 检查 partial 状态。

**要核对的结果:**完整声明与未解析调用可以同时存在,覆盖信息必须表达两者。

可把观察记录为下表;没有执行的项写“未执行”,不能用设计预期冒充实测结果。

核对项 应保留的证据
使用条件 源码版本、配置、输入与项目范围
正常行为 实际返回、来源位置或状态变化
关键失败分支 错误码、可见结果与原状态是否保留
结论范围 已覆盖、未覆盖和需要进一步验证的条件

适用边界与继续阅读

本篇以静态源码与项目设计为依据,给出可执行的核对方法,未据此宣称已经完成新的性能或生产环境测试。不同版本的入口、默认值和底层实现可能变化,应先核对当前合同,再把方法用于自己的实际开发项目。

理解这一节后,可以回到专题总导航,沿同一模块继续阅读;顺序学习时使用专栏内的上一篇和下一篇。涉及具体技术选择,应连同本篇的代价与限制一起采用。