Claude Code两次MCP调用就找到应用的共享契约，之后记录却不够用了

每位Claude Code用户都见过新会话从零开始的情形：在上周刚搭建的系统上请求一个小功能，智能体却要先重新摸清架构，包括哪个服务拥有数据、哪个前端调用它、两者共享哪种类型。解释这些内容的对话已经消失或被压缩成摘要，源文件只能说明存在什么，却说明不了依赖关系。目前主要的解决办法是记忆：Claude Code会在每次会话开始时加载CLAUDE.md指令和自动记忆笔记；自9月17日起，在Claude Code云端会话中处于测试阶段的新版Projects还能在多个线程间共享记忆。作者想测试另一种上下文来源，即构建平台在创建组件各个版本时写下的依赖记录。作者在文中声明，自己是Bit Cloud的工程师，该平台可从第一个组件开始构建、托管和部署应用，并让编程智能体通过MCP参与开发，相关项目和构建记录均已公开。测试对象是作者此前用Claude Code搭建的一个小型客服控制台，由React应用、基于MongoDB的Express服务、共享的工单实体以及将应用和服务置于同一网关后的平台组件四部分构成，均在公开的bit-oss.support作用域中进行版本管理，并已通过HTTPS在生产环境运行。作者在没有对话历史和本地代码的空白工作区中开启新会话，要求为控制台增加按工单状态和负责人筛选的功能。Claude发现工作区为空后，通过MCP调用read_scope读取该作用域，获得四个组件及其依赖关系，再调用read_components获取应用、服务和工单实体的API参考与文件清单。结果显示，应用和服务依赖同一版本的工单实体，其类文档写明该实体由客服服务和面向客服人员的应用共享。随后Claude导入全部组件、检查源码，并在应用内实现客户端筛选，验证结果为41项测试通过，其中包括9项新增的筛选测试。作者总结说，MCP帮助智能体发现系统结构，而源码检查和测试决定了如何修改；此次改动仅限于应用本身，没有触及共享的工单实体和服务，了解哪些部分是共享的，也让智能体知道哪些地方不该动。