企业官网建设流程全解析

过去一段时间，我越来越明显地感觉到一个问题：

AI 写代码变快了，但 review 没有变轻松。

它一次能改很多文件，代码看起来也常常“像是对的”。真正麻烦的是，reviewer 很难快速判断：

• 哪几处是真的高风险？
• 哪些只是 AI review 常见的废话？
• 有没有权限、金额、状态机这类业务规则被偷偷破坏？
• CI 里如果工具没审完，到底是应该放行，还是应该停下来？

所以我做了ReviewGate。

它是一个用于 PR 合并前的 AI 代码质量闸口，目标不是替代人工 review，而是先帮 reviewer 做一轮过滤：

把高风险问题推到前面，把低价值噪音压下去。

ReviewGate 会按多个维度并行审查改动，例如：

• security：注入、越权、密钥泄露
• logic：边界条件、空值、错误路径、并发问题
• perf：N+1、热路径复杂度、阻塞调用
• ai_smell：幻觉 API、复制后未适配、看似合理但实际错误
• business：团队自己的权限、金额、状态机等业务规则

它的几个设计原则：

1. 不静默假通过
   超时、上下文过大、请求失败、未审完，都会降级成 WARN，不会伪装成 PASS。

2. 低置信默认折叠
   AI review 最大的问题不是找不到评论，而是评论太多太散。ReviewGate 会做去重、证伪和置信度过滤，默认只把更值得看的问题推出来。

3. 默认只读
   审查链路不写工作区、不跑任意 shell。--fix也需要逐条确认，并做锚点校验，避免行号漂移改错位置。

4. 可以接入真实团队规则
   你可以把“金额必须用整数分”“用户资源必须校验 owner_id”“订单状态只能按某个状态机流转”这类规则写进配置，让每个 PR 都自动检查。

5. 支持 intent / 技术评审
   如果你传入需求、设计或验收标准，ReviewGate 可以额外检查“实现是否符合这次本来要做的事”，并输出验收清单。

目前它已经可以用于真实 PR 和 CI。推荐接入方式是先让它以 WARN / 评论模式跑一段时间，观察稳定性，再把 BLOCK 接入强制合并闸口。

安装很简单：

curl-fsSLhttps://raw.githubusercontent.com/dengmengmian/ReviewGate/main/install.sh|sh

配置一个 OpenAI 兼容或 Anthropic 端点：

provider = "deepseek" [providers.deepseek] protocol = "openai" base_url = "https://api.deepseek.com/v1" model = "deepseek-v4-pro"

密钥建议用环境变量：

exportREVIEWGATE_API_KEY="你的 key"

然后在任意有改动的 Git 仓库里运行：

reviewgate review

GitHub Action 也可以这样接：

-uses:dengmengmian/ReviewGate/integrations/github-action@v0env:REVIEWGATE_API_KEY:${{secrets.REVIEWGATE_API_KEY}}with:dimensions:allfail-on:blockcomment:"true"

@v0会跟随 0.x 兼容更新；如果团队需要可复现 CI，也可以用：

with:version:"v0.2.0"

把 CLI 引擎钉死到指定版本。

项目地址：

https://github.com/dengmengmian/ReviewGate

我也把公开评测记录放在了仓库里，包括真实 PR、revert 金标准、大 PR、45 种语言规则、intent review 等。它不是“准确率承诺”，但至少不是空口说工具有用。

ReviewGate 适合这样的团队：

• AI 参与代码越来越多
• PR 改动越来越大
• reviewer 时间变得更贵
• 不想被 AI review 的低价值评论淹没
• 希望在 CI 里加一道“高风险优先”的闸口

它不适合替代测试，也不适合替代人工 review。

它更像是一个合并前的过滤层：

先把最值得人看的东西挑出来。