一句话看懂：Anthropic 的 Claude Code 被曝出桌面应用与命令行界面在同一项目中使用 @ 提及搜索时结果不一致，用户提交的 GitHub issue 也因低活动被关闭。事件暴露出 AI 编程工具在上下文管理和跨端一致性上的真实短板。
事件核心：发生了什么
在 Hacker News 讨论中，一名开发者反映：对同一个项目输入相同的查询 “@ephem”，Claude Code 的 CLI 版本能返回相关结果，桌面应用却给出不相关内容。该用户随后在 anthropics/claude-code 仓库提交了编号 71421 的 issue，但等待约 17 天后因低活动被关闭。评论区有用户澄清，这并非“自动”关闭，而是长时间无人互动所致，发布评论即可重置计时器。
围绕这一投诉，多名用户补充了两个关联问题：一是 @ 搜索可能采用整文件读取方式，对大型文件会造成不必要的 token 消耗；二是 /context 命令耗时过长，通常需要数秒，某些情况下超过一分钟，用户希望能常驻显示类似 “120K/200K tokens” 的上下文占用状态，而不是每次手动输入命令查询。
为什么重要
这个案例的意义不在于单个 bug，而在于 AI 编程助手从“能写代码”走向“能管理复杂工程”时暴露的一致性短板。同一查询在 CLI 和桌面端结果不同，意味着 Claude Code 内部的检索逻辑没有对齐，这会直接影响开发者从 IDE 或命令行迁移到桌面端的信任感。同时，关于 /context 慢和缺少 token 状态条的抱怨，反映出开发者对 AI 工具“成本可见性”的需求正在上升——他们不想在看不见模型上下文占用的情况下盲目对话。
目前公开信息显示，Anthropic 尚未对此事作出正式回应。
对用户/开发者/创作者的影响
对日常开发者而言，如果工作流依赖 @ 提及精准定位目标文件，桌面端的不一致会打断操作节奏；在大型代码库中，整文件读取还可能推高 API 费用。对工具链开发者来说，这个 feedback 提供了一个值得警惕的信号：当同款产品拥有多个前端入口时，功能行为必须保持可预测的一致。用户要求“token 状态行常驻”，本质上不是在提功能建议，而是在要求 AI 编程工具提供与编辑器同等级的可见性和可控性。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
接下来值得观察三点：第一，Anthropic 是否会修复桌面端 @ 搜索、使其与 CLI 对齐；第二，/context 的响应速度是否被优化，或者是否会在桌面界面中直接加入上下文占用的常驻显示；第三，第三方插件生态会不会抢先补位，以满足开发者对 token 可视化的需求——这将间接验证官方产品在“上下文管理”这一环节上的缺口到底有多大。
来源：hackernews
