多数 AI 评审工具只看到一个 diff。Hedy 带着项目上下文评审合并请求——近期决策、相关模块、您的编码约定——并发出一条人可据以行动的草稿优先评论。合并始终由人完成；写操作按仓库白名单授权。
Hedy 以私有 AI 员工的身份评审 merge request 与 pull request，运行在您自己的基础设施上，而不是住在别人聊天工具里的云端机器人。它阅读您的仓库以获取真实项目上下文，在 GitLab 和 GitHub 上发表行内评审评论，且从不合并。所有写操作都草稿优先、经白名单把关：允许评论与草稿备注，而批准、合并、推送保护分支默认拒绝。治理就是产品本身——只增不改审计、L0/L1/L2 审批分级、经证据门把关的发现。
最后更新：2026 年 7 月 20 日
Hedy 拉取 diff 及周边源码、被改动文件的近期提交，以及来自其记忆的项目上下文。
就正确性、隐藏耦合与遗漏场景发表评论——引用的是您的代码库，而非泛泛的 lint 建议。
它只能在白名单内的仓库发表评论，从不批准、从不合并。合并按钮始终握在您的团队手里。
每次评审都连同链接写入活动台账——是可见的产出，不是感觉。
Hedy 评审代码时带着项目上下文，而不只是 diff。因为它经 Docker 或 Kubernetes 部署在您的基础设施内部，并可在气隙网络中运行，它会阅读周边仓库——编码约定、相邻模块、既往决策——因此评审评论引用的是您的代码库的实际运作方式，而非泛泛的 lint 规则。它通过双适配器同时适配 GitLab merge request 与 GitHub pull request，在两个平台上使用相同的评审行为与相同的治理控制。
默认姿态是草稿优先、仅评论。Hedy 只留下行内评审评论与草稿备注；它不批准、不合并、也不推送保护分支。这不是提示词层面的请求——它在配置与代码层强制执行，因为只写在系统提示词里的限制等于不存在。合并、批准与强制推送都在写白名单之外，默认被拒绝，因此一次评审绝不可能悄悄改变您仓库的状态。
这正是 Hedy 与住在 Slack 或 Teams 里的云端 AI 员工分道扬镳之处。那些工具大多只做总结和记录；Hedy 承担的是评审工程师的产出，同时保持受治理状态。写操作遵循默认拒绝的白名单，敏感动作经 L0/L1/L2 审批分级逐级升级，每条发现都要过证据门——Hedy 必须引用它所针对的确切代码行与来源，人可以据此核验评论，而不是相信一个无出处的断言。
这一切都运行在您的治理栈之下。审计日志只增不改，没有更新或删除路径，Hedy 评审过什么、发表过什么的完整历史得以保留。您使用自己的模型 key——包括本地 vLLM 或 Ollama——代码与 diff 绝不离开您的边界，没有数据次级处理方（sub-processors），许可通过 Ed25519 离线校验。部署是约 30 分钟的 compose 安装，Lark/飞书与 Slack 是通知与审批的一级渠道。