TraceX

Hey Product Hunt 👋

每个工程团队都懂这句话：“我的退款一直没到账。”有人放下手头的事，打开数据库，grep 代码，翻上周的 deploy，查 Sentry，一个下午过去后才发现：某次 migration 重命名了一个状态，而退款 worker 还在按旧状态过滤。

我们做了 TraceX，替你完成这类排查。

工作方式：问题通过 email、Slack、Jira 或 dashboard 里的提问进来。TraceX 会规划检查步骤，像你最好的工程师那样，把你的数据库、代码和日志一路查下去。整个过程你都能实时看到每一步。最后它会给出：

• 根因，附带置信度和每项结论的证据，以及它排除了哪些假设 • 修复方案，给出确切的代码修改，一键开成 pull request • 给客户的回复，基于事实草拟好

我们最在意的是：

• 只读。数据库连接使用只读凭证，写查询在运行前就会被拒绝，代码变更只会以你能审查的 pull request 形式出现。 • 不留存。TraceX 实时读取你的系统，只记录它查过什么，不保存你的数据行。它从不用你的数据训练。 • 答案可核查。在你看到之前，第二个模型会拿证据核对每一个答案。

它也可以作为整个团队的聊天工具（“有多少退款卡住了，从什么时候开始？”），能结合你的代码库上下文审查 pull request，还有一个 CLI，能在终端里直接回答，也能作为编码智能体，在每次修改前先问你。

private beta 期间免费。不用注册就能试 sandbox：https://app.tracexpro.com/sandbox

我很想听听你的真实反馈，尤其是 TraceX 哪里会出错。我会一整天在这里回答问题。

每项结论都有证据这一点，最打动我。一个我核查不了的根因答案，不过是另一个自信的猜测；而它排除掉的假设，才是我真正想摆到客户面前的部分——它展示的是过程，而不只是结论。我很好奇，当证据指向两个方向时它会怎么做；或者它提出的修复会碰到 migration 时——它还会照常开 PR，还是会收手先问？

只读凭证很好，但在 prod 上不只是写操作的问题。我们遇到过一次事故，连接池被打满，那时候我最不想的就是再有个智能体往 primary 上发更多查询。我能让它指向 replica 或 Neon branch 吗？