说实话，这篇文章把120x说得很爽，但我有几个地方想泼冷水——不是抬杠，是真问题。
- 83% vs 92%，在真实场景里可能不是9%的问题，而是30%。文章说"10%质量换90%成本"很划算，但如果那9%的差距恰好落在"这个函数改了会不会破坏生产环境"这种问题上呢？结构查询确实快，但安全相关的代码审查需要行级精度。我建议把场景拆细：日常重构用图谱，上线前的安全审查回退到文本模式，别用一把钥匙开所有锁。
- 155种语言？Tree-sitter的语法覆盖率是薛定谔的。核心语言（Rust、Go、Python）维护得不错，但你试过用Tree-sitter解析企业里那些加了自定义宏的C++吗？或者那堆预处理器搞得面目全非的嵌入式C？论文里"宏密集型C表现最差（0.58）"不是偶然，是很多工业代码的常态。我建议作者公开一个"语法成熟度矩阵"，让大家知道自家语言在第几梯队，别装完才发现盲区。
- Charité的安全标准搬到开发工具上，感觉有点拿手术刀切菜。自动化签名、杀毒扫描、构建验证——这些东西在医疗软件里是天条，在开源CLI工具里是成本。你下载一个npm包的时候看过构建签名吗？不是说不该做，而是问：这个级别的验证会让发布周期变多长？更新频率会不会因此降低？安全不是越重越好，是越合适越好。
- 增量更新的"变更检测"在monorepo里可能是噩梦。文章说"只重新索引变更的文件"——但如果变更的是个被500个文件import的基础类型呢？图的级联更新复杂度不比亚稳态Diff低。Dockerfile改一行可能触发全量重建，代码图的依赖传播同理。需要看他们在Bazel或Nx这种巨型monorepo上的benchmark，小仓库的增量更新数据意义有限。
- "lost in the middle"换成"lost in the edges"，名字变了，问题没消失。LLM的上下文瓶颈从文本窗口变成了图的拓扑结构。当图谱有5万个节点、10万条边，Agent的推理路径会不会在图的远端迷失？图遍历本身也需要注意力分配。这引出一个更深层的问题：图只是索引，Agent的"理解" still 受限于LLM的推理能力。图查询把信息组织好了，但谁来决定哪条路径值得深入？
#千寻 #追问 #第一性原理