ProtoMap ProtoMap 为大型代码库构建 gRPC/Protobuf 依赖图谱并通过 MCP 提供，让工程师和 AI 编码代理直接查询依赖关系，减少重复搜索与 token 消耗。 热门评论 PH 用户嗨，Product Hunt！我是 Amjad，HoundDog.ai 的联合创始人。今天我们推出 ProtoMap。问题所在AI 编程智能体每天都在写越来越多我们的代码，而每一行都会新增服务、调用和字段，下一个智能体又得重新发现它们。在大型 gRPC + Protobuf 代码库中，一个简单的问题，比如“如果我改这个 service、RPC 或字段，什么会坏？”，会让智能体去跨 repo 用 grep 查找并读取文件，试图拼凑出代码里的关系，而这些代码常常根本没 checkout 在开发者机器上。这又慢又贵，答案常常不完整，而且每次运行结果还会变。ProtoMap 有何不同 🚀ProtoMap 不替代你的编程智能体。它给你的智能体补上缺失的上下文。一个确定性的静态分析引擎会映射你所有 monorepo 和微服务中的每个 service、API 和字段，在每次 commit 时刷新这张图，并通过 Web 平台提供给工程师，通过 MCP 提供给编程智能体。🔹 多跳服务依赖：查看一次改动向外最多五跳的影响范围。🔹 方法依赖：找出谁调用了某个 RPC，以及每个调用点及其文件位置。🔹 字段依赖：查看哪些服务和 repo 发送或接收像 credit_card 这样的字段。🔹 代码负责人：查看每个入站服务，以及需要通知的维护者和依赖方。🔹 未使用的 RPC：找出死 RPC、孤立调用，以及同一个 proto message 在两个 repo 中声明不一致的情况。因为智能体查询的是图，而不是重新读代码，所以回答的成本取决于问题本身，而不是代码库大小。对一位拥有数百万行 monorepo 和复杂 gRPC 服务网络的企业客户来说，ProtoMap 将变更规划所需的时间和 token 减少了 8 倍。适合谁？大规模运行 gRPC + Protobuf 的工程团队，以及与之协作的 AI 编程智能体。基准测试在展示视频中，你会看到两个实时 Claude Code 会话（Opus 5.5，high effort）并排运行，在同一时刻收到相同 prompt，并在同一屏幕上录制。prompt 是：“我们想移除 RPC acme.documents.v1.DocumentQueryService/ResolveDocuments。找出每个 repo 中所有调用它的地方，包括通过 helper 的间接调用、由字符串构造的方法名、注册表或反射，并为每一处给出 file:line 和调用方服务，方便我们迁移。”针对这个 prompt，ProtoMap 快了 7 倍、便宜了 36 倍，使用的 token 少了 93 倍：■ 单独使用 Claude Code（无 MCP）：6:01 · $14.44 · 24.5M tokens■ Claude Code + ProtoMap MCP：0:50 · $0.40 · 262K tokens想查看覆盖 9 个 gRPC repo、20 个 prompt 的更详细基准测试，请访问我们的基准测试页面：https://hounddog.ai/protomap-benchmark/在线演示访问 https://hounddog.ai/videos/protomap-demo/ 查看我们在 MozFest 的现场演示，其中包括在 Web 平台中查询服务图，以追踪服务、API 和字段跨多跳的依赖关系，包括调用方、被调用方和调用点。演示还会带你看我们详细的基准测试。🔗 开始使用ProtoMap 可免费在你自己的机器上运行：自托管 Web 平台和 CLI 扫描器。等你准备好在整个组织推广时，Enterprise 方案会让每个 repo 里的图保持最新，支持在每个 pull request 上做 CI 扫描，并集成 GitHub、Bitbucket 和 GitLab。开始在 https://github.com/hounddogai/protomap 使用 我们很期待你的反馈，尤其是管理大型 gRPC 代码库的朋友！PH 用户我很喜欢直接从数据地图里提问这个想法。非技术背景的隐私团队能在没有开发人员帮助的情况下使用吗？PH 用户同一个 proto message 在两个 repo 里声明不一致，这种事太真实了，没人会注意到，直到 prod 出问题既然图谱在每次 commit 时刷新，那么对于只在一个 open branch 上改过的字段，智能体看到的是什么？？？还是说目前只支持 main？PH 用户在依赖图旁边返回实际调用方位置，这个细节很有用。它让工程师在决定谁需要参与某次变更之前，有具体的东西可以检查。PH 用户这戳中了我在几乎每次编程智能体会话里都会感受到的痛点——很大一部分 token 都花在智能体反复读代码上，只是为了搞清楚一次变更会牵涉到什么，然后它才开始干有用的事。一张它可以查询的确定性依赖图谱，而不是去各个 repo 里 grep，感觉就是正确的解法；你们的并排对比也把这点说得很清楚：那个 RPC 移除任务从 24.5M token 降到了 262K。好奇的是，这种收益在不是大型 gRPC 体系的更小代码库上也成立吗，还是说这其实是一个偏规模化的玩法？PH 用户当它说某个改动是安全的时，我能看到智能体实际打开了哪些调用方、又跳过了哪些吗？在相信这个结论之前，我会先检查那份列表。 热门产品Haylli Weintraub2026-11-09原文 打开互动版
问题所在
AI 编程智能体每天都在写越来越多我们的代码，而每一行都会新增服务、调用和字段，下一个智能体又得重新发现它们。在大型 gRPC + Protobuf 代码库中，一个简单的问题，比如“如果我改这个 service、RPC 或字段，什么会坏？”，会让智能体去跨 repo 用 grep 查找并读取文件，试图拼凑出代码里的关系，而这些代码常常根本没 checkout 在开发者机器上。这又慢又贵，答案常常不完整，而且每次运行结果还会变。
ProtoMap 有何不同 🚀
ProtoMap 不替代你的编程智能体。它给你的智能体补上缺失的上下文。一个确定性的静态分析引擎会映射你所有 monorepo 和微服务中的每个 service、API 和字段，在每次 commit 时刷新这张图，并通过 Web 平台提供给工程师，通过 MCP 提供给编程智能体。
🔹 多跳服务依赖：查看一次改动向外最多五跳的影响范围。
🔹 方法依赖：找出谁调用了某个 RPC，以及每个调用点及其文件位置。
🔹 字段依赖：查看哪些服务和 repo 发送或接收像 credit_card 这样的字段。
🔹 代码负责人：查看每个入站服务，以及需要通知的维护者和依赖方。
🔹 未使用的 RPC：找出死 RPC、孤立调用，以及同一个 proto message 在两个 repo 中声明不一致的情况。
因为智能体查询的是图，而不是重新读代码，所以回答的成本取决于问题本身，而不是代码库大小。对一位拥有数百万行 monorepo 和复杂 gRPC 服务网络的企业客户来说，ProtoMap 将变更规划所需的时间和 token 减少了 8 倍。
适合谁？
大规模运行 gRPC + Protobuf 的工程团队，以及与之协作的 AI 编程智能体。
基准测试
在展示视频中，你会看到两个实时 Claude Code 会话（Opus 5.5，high effort）并排运行，在同一时刻收到相同 prompt，并在同一屏幕上录制。
prompt 是：
“我们想移除 RPC acme.documents.v1.DocumentQueryService/ResolveDocuments。找出每个 repo 中所有调用它的地方，包括通过 helper 的间接调用、由字符串构造的方法名、注册表或反射，并为每一处给出 file:line 和调用方服务，方便我们迁移。”
针对这个 prompt，ProtoMap 快了 7 倍、便宜了 36 倍，使用的 token 少了 93 倍：
■ 单独使用 Claude Code（无 MCP）：6:01 · $14.44 · 24.5M tokens
■ Claude Code + ProtoMap MCP：0:50 · $0.40 · 262K tokens
想查看覆盖 9 个 gRPC repo、20 个 prompt 的更详细基准测试，请访问我们的基准测试页面：https://hounddog.ai/protomap-benchmark/
在线演示
访问 https://hounddog.ai/videos/protomap-demo/ 查看我们在 MozFest 的现场演示，其中包括在 Web 平台中查询服务图，以追踪服务、API 和字段跨多跳的依赖关系，包括调用方、被调用方和调用点。演示还会带你看我们详细的基准测试。
🔗 开始使用
ProtoMap 可免费在你自己的机器上运行：自托管 Web 平台和 CLI 扫描器。等你准备好在整个组织推广时，Enterprise 方案会让每个 repo 里的图保持最新，支持在每个 pull request 上做 CI 扫描，并集成 GitHub、Bitbucket 和 GitLab。开始在 https://github.com/hounddogai/protomap 使用
我们很期待你的反馈，尤其是管理大型 gRPC 代码库的朋友！
既然图谱在每次 commit 时刷新，那么对于只在一个 open branch 上改过的字段，智能体看到的是什么？？？还是说目前只支持 main？