如何用Dify调用GitHub API自动审查代码提交

先说说几个容易踩坑的关键点：OAuth授权、Webhook监听与API调用链路这三步环环相扣，任何一步配置不当都可能导致PR自动审查静默失败。很多人遗漏了Token权限配置，或者忘记了校验Webhook Secret，结果调用链在后台悄然中断，前端却毫无异常表现。

等真正运行起来才发现，回调URL多了一个或少了一个斜杠、Token权限设置得过于保守，都会直接让审查流程中断。因此，动手之前最好先把核心配置项逐一核对清楚。

具体来说，要在Dify中对接GitHub API，让工作流自动拉取PR内容并调用大模型进行代码审查，需要完成OAuth授权、Webhook事件监听与API调用链路三个环节。其中，未正确配置Personal Access Token权限，或者漏掉了Webhook Secret校验，审查任务会直接静默失败——这是最容易忽略的细节。

配置GitHub OAuth应用并获取Client ID与Secret

先从GitHub侧开始操作：登录 GitHub → Settings → Developer settings → OAuth Apps → New OAuth App。

Application name填写"Dify-Code-Review"，Homepage URL填写你的Dify应用公网地址（例如https://dify.yourdomain.com）。最关键的一步是Authorization callback URL必须严格匹配Dify后端回调路径，原样填写【https://dify.yourdomain.com/oauth/github/callback】——少一个斜杠都会导致授权流程中断。

填写完成后点击Register application，记录下生成的Client ID和Client secrets。这两个值后续需填入Dify的环境变量，注意切勿泄露。

为Dify服务配置GitHub Personal Access Token

接下来在GitHub账户中新建一个fine-grained token，权限勾选以下几项：contents:read、pull_requests:read、pull_requests:write（用于后续自动评论）、repository:read（用于获取仓库元信息）。

生成好的token通过环境变量注入Dify服务：GITHUB_TOKEN=ghp_xxx...。注意这个token必须绑定到拥有目标仓库写权限的GitHub账户，否则PR评论会返回403错误。

这一步操作简单，直接将token字符串粘贴到docker-compose.yml的environment区块即可生效。

设置GitHub Webhook监听Pull Request事件

进入目标仓库 → Settings → Webhooks → Add webhook。

Payload URL填写Dify工作流暴露的HTTP接口地址，例如：【https://dify.yourdomain.com/api/workflows/run/code-review】；Content type选择application/json；Secret填写自定义随机字符串（比如k8s-gh-webhook-2024），这个值必须与Dify工作流中webhook节点的secret字段完全一致，否则请求会被拒绝。

在Which events would you like to trigger this webhook?处勾选Pull request，最后确认Active处于开启状态。

在Dify中构建代码审查工作流

第一步：在Dify控制台创建新工作流，选择"Webhook"作为触发器节点，填写与上一步完全相同的Secret值。此处填错，请求就无法进入，两边必须严格保持一致。

第二步：添加"HTTP请求"节点，Method选择GET，URL拼接为：https://api.github.com/repos/{{inputs.owner}}/{{inputs.repo}}/pulls/{{inputs.pull_number}}，Headers中添加Authorization: Bearer {{env.GITHUB_TOKEN}}。这一步用于拉取PR原始数据。

第三步：添加"代码"节点，使用Python提取diff内容并做截断处理。对于单文件diff超过2000行的场景，跳过该文件但保留"[SKIPPED: too long]"标记，避免大模型token超限，同时确保整个PR不被丢弃。

如上所示，核心逻辑是：diff_text从inputs.pr_data['diff_url']获取→用requests.get拿到原始diff→正则过滤掉二进制文件标记→按文件切分→逐一判断文件diff长度→超过阈值则添加标记而非丢弃整个PR。

第四步：将清洗后的diff文本传入LLM节点，系统提示词要明确要求输出JSON格式，包含review_comments数组字段，每项需有path、line、comment四个键。这一步决定了最终审查结果的结构与质量。

第五步：再接一个"HTTP请求"节点，POST到https://api.github.com/repos/{{inputs.owner}}/{{inputs.repo}}/issues/{{inputs.pull_number}}/comments，Body为：{"body": "? 自动审查结果：n" + json.dumps(llm_output.review_comments, indent=2)}，Headers同样携带Authorization。这样大模型分析后的结果就能自动回写到PR评论区。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：如何用Dify调用GitHub API自动审查代码提交要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题