一个开发者上午在Cursor里和AI结对编程，下午切换到Claude Code里继续任务，晚上又用Gemini CLI跑原型验证。三款工具都表现不错，但一个奇怪的现象反复出现：每个新开的对话窗口，都像第一次见到这个项目。

AI不知道你昨天改了哪个模块，不清楚上游接口已经重构，更不会记得你们争论后决定放弃的方案。你需要把前因后果再讲一遍，有时还要把整个代码仓重新索引。

打开网易新闻 查看精彩图片

这不是某个模型不够聪明的问题。在单一会话里，对话历史、上下文窗口、提示词工程确实能让代码助手表现惊艳。但只要一换工具，这些对话记忆就像被格式化的硬盘，项目理解立刻断层。

这就是Contorium团队观察到的“上下文问题”。当前主流AI编码工具都把项目理解当成对话记忆——它依附在一个聊天线程上，随着窗口关闭而消失。这种设计在单一工具内是高效的，但当开发者习惯多工具并行时，记忆的宫墙就变成了障碍。

正方观点很直接：单工具的上下文方案已经足够聚焦。一个开发者完全可以把所有工作收敛到一个IDE里，靠插件和定制化让模型长期记住项目。上下文窗口也在不断拉长，几万行的代码可以一次塞入，还有检索增强生成（RAG）技术来补足细节。在这种路径下，与其折腾跨工具的共享层，不如把主编辑器打磨到极致。

反方则搬出真实的开发流水线来反驳。同一个项目，可能产研用Notion做需求管理，前端在Cursor里写组件，后端用Claude Code处理API，测试又轮到Gemini CLI来检查集成。每换一个环节，AI都得从零“了解”项目结构。更麻烦的是，当几个人各自用自己的工具链时，AI在每个人那里的认知可能互相矛盾——它以为某个函数还存在，其实已经被同事删掉三天了。

我的判断是，问题不在于是否应该忠于单一工具，而在于项目理解到底应该属于谁。如果理解只寄生在对话线程里，就必然随着工具切换而丢失。Contorium给出的思路是把理解权还给代码仓本身：构建一个共享的工作区状态层。

它的核心想法是，工作区本身成为事实的单一来源。从开发活动里生成结构化的状态数据，存放在项目侧，然后通过IDE集成、MCP服务器、命令行工作流等不同方式供各个工具消费。这样，一个IDE窗口、一个MCP智能体或一个CLI进程，就不再是各自孤立的记忆系统，而只是同一个工作区状态上的不同视图。这个概念被他们称为“会话视图”。

从最新架构看，Contorium正朝共享工作区状态、跨工具连续性、MCP兼容、IDE无关和多会话工作流这几个方向推进。长期目标很直白：项目理解应该是可移植的——不绑在某个编辑器、某个模型、某段对话上。如果AI开发越来越依赖多工具协同，底层的项目状态就应该是共享的，而不是割裂的。

这条路显然还在探索阶段，但它触碰了一个真实的痛点：当AI编码助手多到让人选择困难时，缺少的也许不是更好的模型，而是一张能跨越工具边界的公共地图。