Navigara

{"translation":"嘿，Product Hunt ✋，

我是 Jirka，Navigara 的联合创始人。

我当了多年 CTO，一直相信速度图表、周期时间这些指标，直到我意识到它们讲的故事我根本无法佐证。后来 CFO 问我 Claude 每月花近 $150k 到底带来了真实价值，还是只是产出账单，老实说只能回答"我们觉得是的"。当你开口要更多 token 预算时，试着把这句话说出来。

于是我们打造了 Navigara。它读取你的提交历史，使用 LLM 理解代码库并解释每次变更做了什么，然后对合并工作的复杂度打分。打分的依据不是代码行数，也不是提交次数。把 400 行重构到 40 行，你的分数反而比再堆 400 行更高。关于 Engineering Throughput Value（工程吞吐价值）的完整方法论请见：https://500.navigara.com/methodology。ETV 拆分为 Features、Maintenance 和 Documentation 三部分，我们会用你自己的 AI 之前的基线来衡量。

我们首先在开源项目上验证，并就此撰写了一份白皮书。结果如何？在 Microsoft、Google、Cloudflare、OpenAI、Meta 和 Vercel 的公开提交历史中，2025 年 Q1 到 2026 年 Q1 之间，人均 ETV 提升了 116%，共覆盖 676 位贡献者。

随后我们发现，许多公司内部产生的性能数据和代码与公司路线图并不对齐。花费很高、PR 产出很多，但路线图推进速度并没有相应加快。于是我们把 token 消耗与路线图（initiative、epic 和 ticket）关联起来，看哪些工作对齐了路线图、哪些只是挂着 ticket 但没有 initiative、哪些与路线图完全不对齐，并把金额标注在旁边。

以下是我最在意的部分：用数据来引领工程。我的工程团队相比我们自己的 AI 前基线，人均 ETV 提升了 4 倍。我们逐渐意识到，epic、ticket、AI 支出和代码之间的流程问题，才是团队在人员扩张过程中效率下降的根源。如果你也关心这件事，不妨看看"Process Checks"。它就像 Sentry，但是是为工程流程而生的。

你可以开始 14 天试用，或者先去 navigara.com 随便看看。如果你认为我们的衡量方式不对→ 这正是我最想听到的反馈。

Jirka

"}