Prelint

Hi Product Hunt，我是 Wojtek，Prelint 的创始人之一。

现在的编码智能体产出的代码，比多数团队能好好审查的还要多。显而易见的风险是写出烂代码，但更危险的是写出好代码，却在悄悄构建错的产品。

我们在大型生产项目里刚开始用智能体时就反复遇到这种情况：一次变更通过了技术审查、过了 CI，却依然跳过了事务性 outbox 模式、引入未经批准的依赖、改了权限规则、或者凭空捏造了一个业务需求。没人做过这个决定，但它已经成了产品的一部分。

Prelint 会在这些决定上线之前抓住它们。它把每次变更和你的规范、工单以及现有产品上下文一起读，然后解释智能体做了什么决定、后果是什么、以及回滚这个选择有多难。你的团队可以批准、纠正或替换这个决定，Prelint 会把上下文带到下一步工作中。

如果你在用 ADR，我们的客户说这是他们找到的最好的工具，用在这些代理上强制执行 ADR。在同时运行 Prelint 和其他 AI 审查的团队里，大约 40% 实际被修复的审查意见来自 Prelint。

我们从 GitHub 起步，现在支持 CLI 和 MCP，让智能体在工作时就能检查产品决策，而不是等到最后才由人类发现问题。

Prelint 不是另一个技术代码审查工具。那些工具告诉你代码能不能跑起来。Prelint 告诉你这个东西该不该建。

如果编码智能体正在为你的产品做贡献，请到 https://prelint.com 注册，连接一个 GitHub repo，看看它们已经替你做了哪些决定。然后告诉我们你喜欢什么，以及你还希望在上面看到什么！

使用优惠码：PH100 可额外获得 100 美元免费额度

诚实问一句：这东西需要多少前期配置才能用起来？很多“根据你的文档来审查 PR”的工具听上去很牛，直到你发现文档结构必须先弄得近乎完美才能生效。

多个 AI 审查者分别抓不同类型的问题是有道理的，毕竟没有哪个单一模型能看清一个快速迭代的代码库真正需要的一切。

那个“在已经运行多个 AI 审查者的团队中能捕获 40% 的预合并问题”的统计数据，我很想再拆细看看。具体是哪种类型的问题？风格违规本来就容易抓到。真正的架构意图偏离是完全不同、更难的一类，我赌那才是真正的价值所在。

我好奇实际用起来噪音有多大。文档和 ADR 经常过时，你们怎么保证真相源本身不会变陈旧？

40%这个数据是我想要压力测试而不是单纯欣赏的那种统计数据。这个数字是在拥有成熟且维护良好的ADR的团队中测量的，还是即使在文档不齐全（更常见的情况）时也成立？我问这个问题是因为这个领域很多工具在演示中表现很好，但一旦真实文档不一致或过时就开始挣扎。真的很想看到详细分类。