两次MCP调用，Claude Code自己找到了共享契约

一个全新的Claude Code会话，打开在一个上周刚搭好的系统上。你让它加个小功能，它做的第一件事是重新认识你自己的架构：哪个服务持有数据，哪个前端调用它，两边共享的是哪个类型。解释这一切的那段对话已经没了，或者被压缩成一段摘要。源文件能告诉你有什么，但不会告诉你什么依赖什么。

目前的解法主要是记忆。Claude Code每次会话开始时会加载CLAUDE.md指令和它自己的自动记忆笔记。从9月17日起，改版后的Projects在Claude Code云会话中进入测试，它让记忆可以跨线程共享，于是Claude能记得"发布推迟到了周五"，或者"动计费服务之前该先找谁确认"。

但还有另一个上下文来源值得一试：构建平台在创建每个组件版本时写下的依赖记录。

空工作区里的两次调用

测试对象是一个小型支持控制台，之前用Claude Code搭的。它由四个组件组成：一个React应用、一个由MongoDB支撑的Express服务、一个共享的工单实体，以及一个把应用和服务放到同一个网关后面的平台组件。四个组件都在公开作用域bit-oss.support里做了版本管理，控制台通过HTTPS在生产环境运行。

为了测试记录本身能承载多少信息，我在一个空工作区里开了全新的Claude Code会话，没有对话历史，没有本地代码，然后提出请求：给bit-oss.support里的支持控制台加上按工单状态和负责人过滤的功能。

Claude检查了工作区，没找到本地组件。它接下来的话是："工作区是空的，所以支持控制台在远端。让我通过MCP读取bit-oss.support作用域。"它调用了read_scope，返回了四个组件及其依赖关系。接着它调用read_components读取应用、服务和工单实体，在导入源码或改代码之前，先拿到了API引用和文件清单。

应用和服务依赖的是同一个版本的工单实体。它的类文档写着"在支持服务和面向代理的应用之间共享"，API引用里也包含这句话。项目能提供这个上下文，不需要原始对话。

Claude用bit import导入了全部四个组件，检查源码，在应用内部实现了客户端过滤。验证报告显示41个测试通过，其中包括9个新增的过滤测试。MCP帮它发现了系统；源码检查和测试确定了怎么改。改动留在应用内部，共享的工单实体和服务都没动。知道什么是共享的，也就等于告诉代理什么不该碰。

记录在哪里断掉了

断在行为上。应用的API引用确实列出了它调用的路由——GET /tickets、POST /tickets、PATCH /tickets/:id和POST /tickets/:id/comments——但那是在它测试时用的假服务的文档里，没有任何东西拿这份清单去和真实服务核对。记录告诉Claude哪些组件共享工单契约；两边路由是否还对得上，得手动读、手动测。

一次绿色的构建也比看上去证明得少。MongoDB集成测试在临时数据库无法在CI运行器上启动时会跳过，所以构建通过并不说明它们跑过了。我手动验证了持久化：创建一张工单，加一条评论，对着同一个数据库重启平台，确认两者都还在。

而且这是个演示，有预定义的演示账号和公开的签名密钥。并发控制、迁移、恢复流程、强制性的数据库测试，全都还没做。这些是普通的工程工作，也正是我希望工程师把时间花上去的地方。

记忆文件还是依赖记录

记忆保存的是有人选择写下来的东西。在Claude Code里，这指的是人写的CLAUDE.md（或AGENTS.md）指令，以及Claude从纠正和偏好中写下的自动记忆笔记；改版后的Projects还会加入决策，比如为什么砍掉了某个导出功能——这是任何构建系统都不会记录的。每条笔记在写下的那一刻是准确的。Claude Code会记录每个记忆文件的写入时间，它的文档解释了原因："时间戳显示了这个事实有多新。"

构建系统在创建组件版本时写下依赖记录，它是那个版本的一部分。支持应用做版本管理时，构建系统记录下它对工单实体某个特定版本的依赖，没有人决定这值不值得记，而这条记录不会偏离它所描述的版本。又因为read_scope返回的是每个组件的最新版本，Claude读到的记录是当前的。一条记忆笔记带着它被写下的时间，但没有任何东西把它绑到某个代码版本上。

测试中，会话没有对话，没有本地代码。工作区里唯一的记忆是bit new写下的通用AGENTS.md，它告诉代理去平台上查东西，剩下的由记录完成：它们足以找到那份共享契约。

两者覆盖的范围不同，最好一起用：记忆负责意图，比如发布日期、该找谁、或者某个功能为什么被砍；记录负责结构，比如谁依赖谁、依赖的是哪个版本。前者需要有人主动写，后者在版本创建时自动产生。一个会随时间漂移，一个绑死在它描述的版本上。