你一会儿在浏览器搜资料，一会儿回聊天框补背景，一会儿再回编辑器改几行代码。
最容易做错的，是DeusData / codebase-memory-mcp；代价往往是如果把它们都当成同一种工具，你会在最该省事的地方继续手动搬运上下文，最后多一轮返工。；我先给一个保守判断：AI 编码的瓶颈不是模型，是 repo 检索。。
You search in the browser, jump back to chat to restate the background, then return to the editor to change three lines. By the end, you are still the busiest part of the system. That is the cost of treating DeusData / codebase-memory-mcp like just another chat tool: you keep manually hauling context around and buy yourself one more round of rework.
What changed my mind is the framing. It treats code understanding as a structure problem, not a bigger-context problem: build a graph first, then ask which function calls which, what depends on what, and where module boundaries sit.
That is why the numbers matter. On the project site, five structural questions dropped from about 412,000 tokens to 3,400 with the graph-first approach [S001]. In the paper's 31-repo evaluation, answer quality reached 83% with 10x fewer tokens and 2.1x fewer tool calls [S002].
That does not mean models stopped mattering. These published results are bounded to structure-heavy repo questions in a 31-repo evaluation and a five-question 演示（demo）, not every debugging or code-generation 工作流程（workflow）. But the direction is hard to ignore: AI tools are starting to take not just code work, but the fragmented time you lose switching windows.
Many teams think they need a stronger model. Actually they need fewer window switches. If you are evaluating tools this quarter, share this with the person who keeps paying the context-copy tax and ask one question first: where are you still manually re-explaining repo context to the model?
真正该讨论的是：AI 工具真正开始抢的，不只是代码活，而是你来回切换的那些碎时间。