我 30 分钟做了一个 AI 代码审查机器人——做法在这

• 「当谁都能写代码、谁都能上手、谁都能凭感觉 vibe 出一堆东西推到 GitHub，结果就是我们很多人手里堆着一长队等着评审的 pull request。」她说这个问题被问了无数遍：我们已经搞明白怎么跟 AI 一起写代码了，那这么多 PR 怎么办？ → 详细
• 她给的答案很反直觉：「你根本不需要把所有 PR 都评审一遍。」 本期就是手把手搭一个「PR 评审 + 风险打分 + 自动批准」机器人，把低风险的从你盘子里端走、直接送生产，人只看真正需要专业判断的那些。→ 详细
• 灵感来自 Intercom 的 Brian（How I AI 往期嘉宾），他在 PR 自动打分和自动批准上走在最前面。→ 详细

• Intercom 的 PR 吞吐量翻了 2–3 倍，评审量随之爆炸，于是他们做了一个给 PR 打分再自动批准的评审 agent。→ 详细
• 她最欣赏的一点不是速度：他们用 AI 落地验证的是「AI 批准的 PR、以及 AI 写出来的代码，整体上可以比只有人类在环时更安全、质量更高」——把 AI 当成安全与质量上的优势，而不是隐患。→ 详细
• 三个具体结果：① AI 批准的 PR 通过速度是人类评审的 5 倍；② 回滚率（上生产之后还得撤回返工的代码比例）在用 AI 写代码之后低得多；③ 他们搞定了给所有变更和批准打标签、留痕、可审计，能对上 SOC 2、HIPAA 之类的合规框架。→ 详细

• SOC 2（面向 SaaS 公司的安全合规审计标准，核心要求是关键动作有据可查）、HIPAA（美国医疗数据隐私法规）常被当成挡箭牌。她的回应：是有成熟框架的——只要它写进了你的风险政策、写进了你的代码评审政策，只要整个过程可审计、可查询、说得清来龙去脉，你完全可以在合规框架内做这件事。 → 详细
• 她没有拍胸脯打包票，明确加了一句：具体怎么落地，得和你自己公司的安全与合规团队一起敲定。 → 详细

• 另一篇更偏技术实现的博客来自 Rewind Bot（他们同样受 Intercom 启发），bot 名叫 Diff Vader（她说这名字太爱了）。他们打风险分看的几个维度是：blast radius（爆炸半径，即这次改动一旦出事波及面有多大）、代码正确性、所有 action 有没有跑完等。→ 详细
• 两篇博客加起来就是她搭 agent 的起点——这也说明这类内部工具不需要原创方法论，抄两篇公开的实践就够开工。 → 详细

• ChatPRD（她的公司/产品）积压了一大堆低风险 PR，因为她和同事一直腾不出手——「说实话审起来还挺无聊的，尤其是一堆 Devin 写的 PR。」（Devin 是一款会自己写代码提 PR 的 AI 工程师产品。）→ 详细
• 她的选题逻辑值得注意：这件事同时满足「确定高价值」+「我能做出来」+「顺便能试个新框架」，三条齐了才动手。→ 详细

这是全片最值钱的一段。读完代码之后 agent 开始打分，她原话是「它一共看六件事」：

• ① 改动面有多大（change surface）：这次动了多少地方、铺得多开。→ 详细
• ② 爆炸半径有多大（blast radius）：万一这次改动出问题，会波及到哪些东西、影响面能扩散多远。它和「改动面」被她放在同一句里说，但属于两件事——改了几行是一回事，改的那几行牵动多少下游是另一回事。→ 详细
• ③ 是不是容易回滚（reversibility）：她给的例子非常具体——「比如一次大规模的数据迁移，撤回起来可能就麻烦得多。」 同样大小的改动，能一键撤回的和撤不回来的，风险完全不是一个量级。→ 详细
• ④ 有没有碰到数据安全 / 有没有把数据安全覆盖到：注意这是两问——一问「这次改动是不是碰了敏感数据这条线」，二问「碰了的话，该做的防护有没有一并做到位」。→ 详细
• ⑤ 有没有改动运维相关的东西（operations）：会不会影响线上系统怎么跑、怎么部署、怎么监控。→ 详细
• ⑥ 验证缺口（verification gap）：她的原话是「测试是不是完整、CI 有没有跑完、我们能不能用几种方式真正验证这事儿是对的」。这一维度衡量的不是代码本身，而是「我们凭什么相信它是对的」的证据够不够——同一段代码，有测试覆盖和没有，风险分应该不一样。→ 详细

⚠️ 转写含糊处（如实标注）：她说「六件事」，但口播里 ① 和 ② 是连在一句话里说出来的（原话 "how big is the change surface and blast radius"），字面数下来只有五项；要凑够六条，必须把「改动面」和「爆炸半径」当成两条来拆。她也没逐条给权重和计分公式，只说了「它有一段脚本，跑一下算出总分」。

打分之后怎么分流，是这套机制真正吃力气的地方。三层规则叠在一起：

• 第一层：分数段分流（她反复强调「这些阈值不是我定的」，是 AI 自己给的）——低于 24 分＝低风险 → agent 直接自动批准；25 到 64 分＝中风险；65 分及以上＝高风险；中风险和高风险的 PR 必须人工批准。（她原话是「24 分以下算低风险」而中风险从 25 起，正好卡在 24 分这个点她没说清。）→ 详细
• 第二层：这个仓库专属的风险分类（写死在 skill 里的领域常识）——文档改动算低风险，功能逻辑算中风险，认证和计费相关算高风险。这三条不是通用真理，是「在 ChatPRD 这个 repo 里，什么地方最容易出事」的经验沉淀，换个业务就该换一套。→ 详细
• 第三层也是最反直觉的一条：diff 的大小不作为风险依据。 改了 3 行还是 300 行，本身不加分也不减分——规模不等于风险，真正决定风险的是碰了哪里、能不能撤回、验证够不够。→ 详细
• 硬阻断项与风险分是两套逻辑，必须分开看：实测里那个纯文档 PR 拿了很低的风险分，但依然没被自动批准，理由是「这条 PR 有 merge 冲突」（merge 冲突＝两条分支改了同一处代码，系统没法自动合并）。她明确说「这也是它评分时必须检查的一项」——也就是说，低风险 ≠ 自动放行，还要过一遍阻断清单。 → 详细
• 还有一条降噪逻辑她挺满意：agent 里有一小段规则，只审查最新的改动，不重复审已经看过的历史提交。→ 详细

• 她把「如果你要做一个 PR 评审 agent，我建议你就这么做」压成一条极短的流程：它读取 PR，看具体的 diff，给风险打分，并把打分依据一并写出来（原话 "publishes the evidence to the risk"）。打分必须附证据这一条，是它能被信任、也能被审计的前提。→ 详细
• 出路只有三条，界限非常干净：① 判定低风险 → 直接在 PR 上提交批准；② 需要人看 → 升级交给人；③ 碰到阻断性问题 → 停下来，提出 request changes（GitHub 上的「打回、要求修改」）。她的评价是：「逻辑跟人做 code review 非常像。」 → 详细
• 最终输出物是三件套：一个结论标记（点赞通过 / 需要修改）+ 一条评论 + 一次 Slack 通知——评审做完后它会在 Slack 里 @ 她和同事，说「这个 PR 可以看了」或者「这个 PR 需要人帮忙」。→ 详细

• 触发链路：她装了一个 GitHub app，监听「PR 所有变更完成之后」的那个事件 → Vercel 的 GitHub 集成在 GitHub-Vercel 通道里接到事件，传一小段信息给 agent → Vercel 拉起 sandbox（隔离的临时运行环境），把 repo（代码仓库）checkout 下来、跑起来、看 diff → 跑几个 skill 和工具评估风险与质量 → 输出结论 + 评论。→ 详细
• 组件清单短到可以背下来：一个 GitHub channel + 一份 instructions（指令）+ 一个用来评审 PR 的 skill（skill＝一段写给 agent 的可复用操作说明）+ 两个工具（一个读 PR 相关的所有文件和信息，一个把风险判定结果写回去）+ 一个 Slack 通知器。「所以文件真没多少，非常简单。」 → 详细

• GitHub app 需要的权限就四类：能访问 pull request、能访问文件内容、能看 CI 检查和 action 检查、再加一点元数据。这些她全交给 Vercel 配好了。→ 详细
• 触发规则要专门降噪：「你肯定不想每来一个 PR、在 checks 还没跑完的时候就触发它」——所以她在 PR 规则那儿做了限制，等检查全绿了才让 agent 出手。→ 详细

• 她把 instructions 摊开给观众看，全文是：「这是 ChatPRD 的工程 agent，它评审 PR，它调用风险上下文，它打分」＋ 几条指令。就这些。连滚动条都不用拖，大概四五段话、几个要点，就能跑了。」 她的结论掷地有声：「你完全不需要过度设计这个东西，而且它跑得非常非常好。」 → 详细
• 评审 skill 也一样短——读 PR、评审 PR、几条仓库专属风险分类、几句关于「评审意见怎么写」的指令，加起来大概就一页文字。而这一页是 AI 写的，她只做了打磨。→ 详细
• 由此她反复强调的那句总纲：「写这类 agent 一点都不难，本质上就是写指令和写 skills。造一个这样的 agent，需要的就是这些。」 很多东西直接用 markdown 就能搞定。→ 详细

• 起手就一句话（她自嘲满屏错别字）：「我想做一个内部 GitHub bot / app，在所有 CI 检查都变绿之后去评审 PR，把风险分成低、中、高三档，然后自动批准低风险的那些。」她没给任何关于打分的指示，没给任何关于配置的指示，也没给任何关于风险的指示——「就相当于一次成型、顶多几次成型，直接推上了生产。」→ 详细
• 中途只拨了一次方向：她打断 Codex 说「如果你愿意，我们可以把它设计成一个 Vercel Eve agent」，对方说「好啊，这主意不错」，然后一路狂奔。整个过程「来回了几轮，但真的没几轮」。→ 详细
• 她说真正惊艳的不是写代码，而是配置：配 Slack bot 和 GitHub app 意味着点开一堆页面、勾各种权限。她用了「我最爱的一个偏方」——让 Codex 用 Chrome 的 browser use（让 AI 直接操作浏览器点页面）自己去走完 Slack 和 GitHub 的配置流程，她只负责点几下按钮、过双因子认证、核对结果，唯一卡壳的是「它点保存那一步有点费劲」。她把这条拎出来当通用心得：要在别人家的第三方服务里把一个应用配起来时，「写代码我没问题，但我真不想去点配置」——browser use 就是那个偏方。 → 详细

• Eve agent 本质上就是一个目录——装着指令、skills、代码，跟 OpenClaw 很像，但能直接在 Vercel 开箱即用的渠道里对话，还能带一个 sandbox 执行代码。→ 详细
• 她最看重的是接线成本归零：Vercel connectors 是账号里的托管连接，「点一个小向导」就把 Slack 接上、再点一个把 GitHub 接上，refresh token（自动续期的授权凭证）之类全不用管。→ 详细
• 底层是开源的 Chat SDK——它抹平了多渠道 agent 的复杂度、包办 Slack 配置、直接生成 Slack manifest（描述应用配置的清单文件）；ChatPRD 自己的 Slack bot 和 Teams bot 就跑在它上面。她特意声明「他们没给我钱让我夸」，现在新做的内部 Slack agent 一律迁到 Eve。→ 详细

bot 名叫 Merge Mommy——「我们没有 Diff Vader，我们有 Merge Mommy，因为我们 ChatPRD 就是这么会玩。」她自己每次念都绷不住。→ 详细

• PR ①（Devin 提的纯文档更新）：Merge Mommy 给 6 分（满分 10 分），风险非常低（只动了文档），但没有自动批准——阻塞原因是这条 PR 有 merge 冲突，下面还附了一段详细说明讲清楚为什么被卡住。→ 详细
• PR ②（干净例子，已 merge）：7 分（满分 10 分），低风险，自动批准，页面上方 Merge Mommy 打了个小勾表示已批准；随后推到 Slack 频道：「你们俩谁来都行，批一下。风险低，检查全绿。你只要点 approve 然后 merge 就完事了。」→ 详细
• PR ③（废弃清理，Merge Mommy 拒批）：ChatPRD 从 Chat V1 迁到 Chat V2，旧代码留在 feature flag（功能开关，把旧代码留在线上但不生效）后面，现在可以删了——35 处改动、一大片红色的 diff。Merge Mommy 给 45 分（满分 100 分）、中风险、不自动放行，理由有两条：一是它发现了一些代码问题，二是按策略判定这次改动动了服务端 API 的行为、改动面又大，所以是中风险不是低风险，它就不能批。→ 详细

⚠️ 转写存疑处（照原话保留、不替她统一）：她在讲阈值时用的是 100 分制（<24 低 / 25–64 中 / 65+ 高），演示 PR ③ 时也说的是「45 out of 100」；但演示 PR ① 和 ② 时她说的是「6 out of 10」「7 out of 10」。同一套机制在同一期里出现了 10 分制和 100 分制两种口径，视频里没有解释。若换算成同一把尺（6/10 ≈ 60 分、7/10 ≈ 70 分）会和「低于 24 分才算低风险」直接打架，所以这里如实记两种说法，不做统一。另注：PR ③ 里「改动面又大」与第七节「diff 大小不作为风险依据」并不矛盾——前者说的是改动面/影响面，后者说的是行数规模，但她口播里两者贴得很近，容易混。

• bot 满足不了 repo 规则里「必须有人批准」这一条，所以它打出来的勾是灰色的。她列了三个选项：跳过规则、hack 绕过、或者接受它。她们选了第三个——把这个灰勾当成一个信号：「我们的人可以不用真去细看就批准，然后想 merge 的时候直接 merge。」 → 详细
• 保留人类那一下点击，恰恰是为了合规：她们的 repo 规则要求 GitHub 里必须有一次 review 才能对上 SOC 2 的要求，「审计和合规管理起来也特别省事」。她试过好几种让 bot「装成人类」去 review 的路子，「感觉都不太划算」，于是放弃。→ 详细
• 结果是一套顺手内建进去的运作流程：Slack 里那条消息＋两次点击（approve → merge），把「谁该看、看到什么程度、什么时候可以放行」全写死在流程里，而不是靠人的自觉。→ 详细

• 她爱说的那句话在这里正好两头兑现：「我让 AI 干活：这个 Eve agent 帮我 review、给 PR 打分、替我当那双盯细节的眼睛；然后我又让 AI 支使我干活：它把事情升级到 Slack，让我来做最后一步，把上线变成一个点两下就完成的动作。」 → 详细
• 心理门槛比技术门槛高：「这东西本来是我特别怵、特别不敢动手做的。我以为得花上好几天好几天。我当时想的是：我可不想去配那个 GitHub app。」她以前真的试过一次，那是在 Codex 的 browser use 好用之前、Eve 出来之前——当时就是做不动。→ 详细
• 收尾五步配方：Eve agent → 一套指令 + 一个读 PR、按几个维度算分的 skill → 接上 GitHub 和 Slack → 从 GitHub 读信息、打一个灰色批准勾 → Slack 里 @ 你完成最后的 review 和 merge。她的承诺是「周期时间会快得飞起，PR 吞吐速度一路冲上天」。→ 详细

• 她没演示、但明确点名 Intercom 在做的一步：每次 review 跑完，结果都被记进一个内部 eval 平台（eval＝评测集，用一批带标准答案的样例给 AI 打分），由工程师去看：这次 agent 判对了吗？判错了吗？我们对这套打分机制满意吗？ → 详细
• 她的结论是一条通用原则：「跟你用 evals 去改进面向客户的 AI 产品是一个道理，你也会想用 evals 来改进面向内部的 AI bot，尤其是那些碰到代码这类要害东西的。」——越是内部的、越是碰要害的 agent，越需要评测集，而不是相反。 → 详细

闪电问答：（本期无）——这是 Claire Vo 自述式的 30 分钟迷你集，没有嘉宾、没有 lightning round。

收尾：她把问题抛回给观众——「这事儿是不是疯了？在你们公司能落地吗？还有哪些维度是我没想到、你会加进风险打分里的？」 以及 「我特别想知道你们觉得这是疯了，还是未来的方向。」 → 详细

本期无嘉宾，故无嘉宾联系方式。节目侧信息（原视频提到的）：

• How I AI 官网 / 全部往期：howiaipod.com → 详细
• 收听渠道：Apple Podcasts、Spotify，或常用播客 App；YouTube 频道 How I AI。→ 详细
• 主持人：Claire Vo（ChatPRD 创始人，本期即她本人的建造实录）。片中提到的两个灵感来源：Intercom 的 Brian（AI 批准 PR 的实践）、Rewind Bot 的 Diff Vader。→ 详细