Claude Code 通过两次 MCP 调用找到了我应用的共享契约。然后记录就用完了。
内容提要
Claude Code每次会话都从零开始，需重新理解系统架构。作者尝试用构建平台自动生成的依赖记录作为上下文来源：在空工作区中，Claude通过MCP读取远程组件及其依赖，成功为支持控制台添加筛选功能，41项测试通过。依赖记录随版本自动生成、不会漂移，与人工记忆互补——记忆承载意图，记录承载结构与依赖关系。
延伸解读
依赖记录与记忆的互补关系
文章指出，记忆（如CLAUDE.md和自动记忆笔记）承载意图，例如发布日期、联系人、功能被砍原因，而依赖记录承载结构与依赖关系，如哪个版本的组件依赖哪个版本。两者覆盖不同领域，配合使用效果最佳。记忆笔记带有写入时间，但未与代码版本绑定；依赖记录随版本自动生成，不会漂移，且通过read_scope返回最新版本，确保Claude读取的上下文是当前的。
测试通过不等于一切正常
作者提醒，绿色构建可能掩盖问题。例如，MongoDB集成测试在CI运行器无法启动临时数据库时会跳过，因此通过的构建并不证明这些测试实际运行。作者手动验证了持久化：创建工单、添加评论、重启平台后数据仍在。此外，该项目是演示，使用预定义演示账户和公开签名密钥，并发控制、迁移、恢复流程和强制数据库测试都尚未完成。
共享契约的发现与边界
Claude通过MCP读取远程组件及其依赖，发现应用和服务依赖同一版本的工单实体，其类文档注明“在支持服务和面向代理的应用之间共享”。这帮助Claude将修改限制在应用内，不触碰共享实体和服务。但记录只告诉哪些组件共享契约，并未验证路由是否匹配。应用API参考列出了调用的路由，但无检查机制确保与实际服务一致，需人工阅读和测试。
记录成本与早期建立的优势
依赖记录在创建每个组件版本时自动生成，因此没有额外成本，从第一天就开始积累。作者用bit new创建工作区，提供了MCP连接和AGENTS.md指令，原始构建中Claude利用该连接查找可复用组件，最终四个组件依赖16个已有组件，其中10个来自设计系统。若等到团队重命名字段、另一团队从错误日志才发现时再重建依赖图，成本会高得多。
Q&A
Claude Code 每次新会话为什么需要重新理解系统架构？
因为每次会话都从零开始，之前的对话历史要么丢失，要么被压缩成摘要，而源代码文件只显示存在什么，不说明依赖关系。
作者尝试用哪种新的上下文来源来帮助 Claude 理解系统？
作者尝试使用构建平台在创建组件版本时自动生成的依赖记录作为上下文来源。
在空工作区测试中，Claude 通过 MCP 调用了哪些方法？
Claude 首先调用 `read_scope` 读取 `bit-oss.support` 范围，然后调用 `read_components` 获取应用、服务和工单实体的 API 参考和文件清单。
依赖记录和记忆（如 CLAUDE.md）在提供上下文方面有什么不同？
记忆承载意图，如发布日期、联系人、功能被砍原因，由人编写且有时效性；依赖记录承载结构和依赖关系，随版本自动生成，不会漂移，与代码版本绑定。
测试中 Claude 成功添加筛选功能后，验证结果如何？
验证报告显示 41 项测试通过，其中包括 9 项新的筛选测试。
依赖记录方法有哪些局限性？
依赖记录无法验证行为，例如 API 路由是否匹配需要手动检查；绿色构建可能因 MongoDB 集成测试跳过而不可靠；演示项目还有并发控制、迁移、恢复程序等未完成。
