为什么 AI 编程助手需要一个项目记忆中心

本文属于 Memory Center：AI 编程上下文与记忆系统工程实践，第 01 篇，位于“问题与设计思想”模块。案例背景统一采用实际开发项目；复现步骤使用脱敏教学样例，不代表特定生产事故。

从实际问题出发

开发者问“修改这个接口会影响哪些服务”，助手找到了接口声明，却漏掉跨服务消费者；换一个会话，又要重复同样的探索。问题同时涉及结构关系、任务历史和团队约束，单靠扩大上下文窗口无法保证它们始终正确。

记忆中心要保存什么

把可从源码重建的结构事实，与需要人为确认的经验分开。代码事实关注声明和关系，知识记录关注来源和修订，任务会话关注本次意图与结果。它们可以共同支持决策，但不能因为放进同一个检索入口就变成同等可信的事实。

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

为什么采用任务级入口

mc_lookup 接收明确项目和查询模式，使服务能统一检查范围、选择引擎并返回证据。工具的价值在于减少调用方必须重复组合的步骤。它不能替代编译、测试和人工业务判断；静态图没有解析出的动态调用仍然是边界。

关键源码与阅读方法

源码基线为 Memory Center 6e90553（文档标注 5.0.0b24）。定位：memory_center/service/platform_mcp.py，函数 mc_lookup，起始行 90。

以下为当前基线中的函数代码；依赖项目模块，不能作为独立脚本执行。

    async def mc_lookup(workspace_id: str, query: str, mode: str = 'hybrid', limit: int = 10, session_id: str = '') -> dict[str, Any]:
        """按显式项目查询：keyword/vector/hybrid/symbol/callers/callees/context，返回来源与私有引用。"""
        if len(query) > 1000 or not 1 <= limit <= 50:
            raise CatalogError('QUERY_INVALID', '查询参数超出范围')
        return await anyio.to_thread.run_sync(lambda: service().lookup(mcp.actor(), workspace_id, query, mode, limit, session_id))

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

用一个小实验核对设计

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

1. 建立一个含接口与消费者的微型项目。
2. 先只搜索接口名，再查询结构关系。
3. 修改消费者后重新核对来源修订。

**要核对的结果：**比较两种方式遗漏了什么，而不是凭一次演示宣称节省了多少成本。

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

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

适用边界与继续阅读

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

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