HackerNews中文版

在大型 Rust 代码库上工作。Token 问题确实存在——Claude Code 乐于花费 5 美元的上下文费用，仅仅为了理解两个模块之间的关系，却一行代码都不写。而且，一旦上下文压缩开始，情况会变得更糟——代理会完全失去思路，并从头开始重新搜索相同的文件。我尝试过的方法：手动输入 CLAUDE.md / 架构文档——有帮助，但很快就会过时。Cursor 的内置索引——在单体仓库上会崩溃，而且我不喜欢将专有代码发送到他们的服务器。基于 grep 的基本 MCP 服务器——适用于精确匹配，对语义查询无用。最终构建了一些更复杂的东西：一个本地 Tree-sitter 索引器，它构建了文件关系的知识图谱，并通过 MCP 暴露出来，这样代理就可以进行语义查询，而不是盲目地使用 grep。一个工具调用代替 15 次 grep 迭代。在这里发布了它：https://github.com/Muvon/octocode但我真的很好奇其他人都在做什么，然后再深入研究它。三个具体问题：1. 你如何处理“涟漪效应”问题——知道更改一个文件会在语义上影响其他文件，即使它们之间没有明显的链接？2. 你信任闭源索引处理专有代码吗，还是选择了本地优先？3. 有人实际大规模地让 GraphRAG 风格的关系映射工作起来了吗，还是它仍然主要是一种炒作？

查看原文

Working on a large Rust codebase. The token problem is real — Claude Code will happily spend $5 of context just trying to understand how two modules relate before writing a single line. And once context compaction kicks in, it's even worse — the agent loses the thread completely and starts grepping the same files again from scratch.Approaches I've tried:Feeding CLAUDE.md / architecture docs manually — helps, but gets stale fast. Cursor's built-in indexing — breaks on monorepos, and I don't love proprietary code going to their servers. Basic MCP server with grep — works for exact matches, useless for semantic queries.Eventually built something more serious: a local Tree-sitter indexer that builds a knowledge graph of file relationships and exposes it via MCP so agents query semantically instead of grepping blind. One tool call instead of 15 grep iterations. Published it here: https://github.com/Muvon/octocodeBut genuinely curious what others are doing before I go deeper on it.Three specific questions:1. How do you handle the "ripple effect" problem — knowing that changing one file semantically affects others that aren't obviously linked?2. Do you trust closed-source indexing with proprietary code, or have you gone local-first?3. Has anyone gotten GraphRAG-style relationship mapping to work in practice at scale, or is it still mostly hype?

Ask HN：如何为 AI 代理提供真实的 codebase 上下文，同时避免消耗大量 token？