测试全绿了，但合并还是让人不踏实
你把一个小改动交给 AI 编码代理，却发现它修改的文件比预期多得多。测试和 lint 都通过了，但仔细一看，它绕过了现有的数据流，甚至改动了你并未要求修改的业务规则。
这时，常规自动检查或许能发现语法错误或类型问题，却未必能回答“我们是否仍在构建团队一致同意的产品？”。代码能够运行，与代码符合产品意图，是两种不同的审查。
Prelint 专注于第二个问题。它是一个产品一致性审查层，将仓库中的产品规格、ADR 和业务规则与 PR 变更内容进行比对，以发现范围偏离和违反既定决策的情况。它并不是用来替代 linter、类型检查器或安全扫描器的工具。
区别不在于发现 Bug，而在于审查标准
Prelint 审查的标准不是代码的外观，而是代码本应遵循的决策。根据官方文档，它审查产品规格违规、ADR 遵循情况、业务逻辑以及任务范围偏离；代码风格和一般安全漏洞检查则交给专用工具。
| 审查层 | 提出的问题 | 典型依据 |
|---|---|---|
| CI · 静态分析 | 能否构建并通过测试？ | 测试、类型、lint 规则 |
| 安全检查 | 是否存在已知漏洞或高风险模式？ | 安全规则、依赖项数据 |
| 产品一致性审查 | 是否遵循已达成一致的需求和设计？ | 产品规格、ADR、业务规则 |
例如，假设文档写着“所有发票的默认付款期限为开票日起 30 天”，而某个 PR 将默认值改成了 60 天。代码可能运行正常，但它与文档化的业务规则发生了冲突。这正是 Prelint 希望捕捉的变更。
不要从安装开始，先用一条规则和一个 PR 试验
首次审查的目标不是记录整个仓库。加入一条当前有效的规则，然后确认在违反该规则的小型 PR 中，是否会出现关联依据的 finding 即可。目前公开的通用入门路径是 GitHub App，你需要拥有批准安装的组织或仓库权限。
- 在Prelint 应用中使用 GitHub 进行认证。 安装 GitHub App 时，请只选择要试验的仓库，而不是整个组织。Prelint 会读取审查所需的代码和 PR 数据，但不会直接执行仓库代码。
- 以 Markdown 形式在仓库中加入一条当前有效的规则。 例如，在
specs/billing.md中写下“所有发票的默认付款期限为开票日起 30 天”。首次审查不强制需要单独的配置文件。 - 创建一个将默认付款期限改为 60 天的小型 PR。 在独立分支中进行修改，并将其转换为非草稿 PR。草稿 PR、默认排除的机器人创建的 PR，以及没有相关文件变更的 PR，可能会被跳过审查。
- 查看 PR 的 check run 摘要和 diff 中的内联评论。 成功的标准是：当变更与文档冲突时，相关行会发布关联依据的 finding。若变更没有冲突，结果将显示当前 PR 版本没有活跃 finding。
- 修正被指出的值，并推送新的提交。 在更新后的结果中确认原有 finding 是否消失。创建、重新打开 PR、将 PR 设为可审查，以及推送新提交，都可能触发审查。
- 在扩大试验前先检查 Billing。 每次完成的审查收费 1 美元，失败、取消或超时的审查不收费。注册时会提供 10 美元额度，公开仓库审查免费；但新提交后的已完成重新审查也会按单独一次计算。请先检查自动充值状态和每月支出上限。
第一次试验要故意制造一个明确的冲突。
相比模糊的设计原则，像“将 30 天改为 60 天”这样让人能立刻判断文档与 diff 冲突的案例更合适。当结果异常时，也更容易区分是工具判断的问题，还是原始文档本身含糊不清。
放入更多文档，并不意味着审查得更好
Prelint 会自动索引仓库中的 Markdown 规格和 ADR，但一次审查所构建的上下文最多为 80K 个字符。它会根据组织、项目、仓库文档等优先级构建上下文；超过限制时，优先级较低的资料可能会被截断。
因此，与其加入所有过往会议记录，不如明确决策的状态。请简明清楚地写明：做了什么决策、适用于哪些范围、现在是否仍然有效，以及有哪些例外。彼此冲突，或未标明是否已废弃的文档，不仅会让 AI 困惑，也会让人工审查者困惑。
先查看将被纳入审查的文档和代码。
Prelint 不会执行仓库代码，但会为审查读取代码和 PR 数据，并在 AWS 环境中处理它们。若存在敏感文件，在连接仓库之前，应确认访问范围、排除设置以及组织的数据处理标准。
36.6% 不是效果，而是审查范围改变的信号
Prelint 的自研研究在 331 个公开仓库中，分别在有文档和无文档的条件下审查了 56,706 个 PR。没有文档时，标记率为 13.3%；纳入文档后为 36.6%。报告称，因拥有上下文才发现的项目有 979 个；反过来，上下文抑制了原本不必要警告的情况有 232 个。
这一结果支持了文档会改变审查对象这一假设。不过，标记率上升并不意味着实际缺陷或故障按同样幅度减少。 该研究由产品供应商进行，模型评分使用了 Opus 4.6，而仓库抽样、人工复核流程和原始结果并未公开到足以支持独立复现的程度。
团队评估时，不要只看 finding 数量，而要看三件事：finding 是否确实有效，是否指出了人工可能遗漏的产品决策，以及修复后同类违规是否消失。只有确认这三点，产品一致性审查才会成为帮助合并决策的一层，而不只是增加评论的工具。
是否采用，可以通过前五个案例来判断
Prelint 的价值不在于取消现有代码审查，而在于保留测试和安全检查的同时，再增加一个比对文档化意图的问题。
不要一开始就应用到整个仓库。请从一条结论明确的规则和五个小型 PR 开始。将每个 finding 分类为有效违规、文档含糊、错误警告，下一步行动就会清晰起来。若有效违规反复出现，就扩大应用范围；若文档问题很多，就先整理 ADR；若错误警告很多，则不宜将它用作自动合并门禁。
如果想进一步了解
Documentation - Prelint 可以查看连接 GitHub App、索引文档和进行首次审查所需的官方入门步骤。 prelint.com
How reviews work - Prelint 说明从 PR 事件、上下文构建、二次验证到发布内联评论的审查流程。 prelint.com
AI Code Pulse — 56,706 PRs Analyzed 可以在原文中查看不同文档条件下的标记率和研究范围。阅读时请同时注意，这是供应商自行开展的研究。 prelint.com
