How do I use MCP Code Review Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Code Review Server Generate a code review for my feature branch against main" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

MCP Code Review Server

by xlian-fe

Overview Schema Related Servers Score Discussions

JavaScript

Local

MCP Code Review Server

一个基于 MCP (Model Context Protocol) 的代码审查工具，帮助前端开发者在迭代结束后自动生成详细的代码 Review 文档（HTML 格式），方便在小组内分享和讲解代码改动。

功能特性

🔍 分支对比: 对比开发分支与目标分支（如 main/master/develop）的代码差异
🔗 Commit Hash 模式: 支持指定起始 commit hash，无需目标分支即可获取变更
👤 作者筛选: 根据 Git 提交作者筛选出你自己的改动（多人协作场景下非常有用）
📊 智能分析: 自动分析代码变更类型、复杂度、关键改动点
📋 文件功能描述: 通过 LLM 根据文件路径批量生成文件功能描述（50字以内），展示在报告中
📄 HTML 报告: 生成美观的 HTML 格式 Review 文档，包含代码差异高亮
📋 提交时间线: 展示完整的提交记录
🚫 智能过滤: 自动排除图片、字体等二进制资源文件，以及无实际代码差异的文件

Related MCP server: MCP Review Server

安装

# 克隆或进入项目目录
cd mcp-xl-code-review

# 安装依赖
npm install

# 构建项目
npm run build

配置 MCP Server

在 Claude Desktop 中配置

编辑 Claude Desktop 配置文件：

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json

添加以下配置：

{
  "mcpServers": {
    "code-review": {
      "command": "node",
      "args": ["/path/to/mcp-xl-code-review/build/index.js"]
    }
  }
}

在 Cursor 中配置

在 Cursor 的 MCP 设置中添加：

{
  "mcpServers": {
    "code-review": {
      "command": "node",
      "args": ["/path/to/mcp-xl-code-review/build/index.js"]
    }
  }
}

使用 npx 运行（无需全局安装）

{
  "mcpServers": {
    "code-review": {
      "command": "npx",
      "args": ["-y", "mcp-xl-code-review"]
    }
  }
}

工具说明

本 MCP Server 提供 3 个工具和 3 个提示词模板：

所有工具均支持两种使用模式：

分支对比模式: 提供 target_branch，对比开发分支与目标分支的差异
Commit Hash 模式: 提供 from_commit，获取该 commit 之后到开发分支的所有变更，无需指定目标分支

提示词模板（Prompts）

在 MCP 面板中可以直接看到以下提示词模板，点击即可快速使用：

模板名称	说明
`generate-review`	生成代码Review报告（分支对比模式）
`generate-review-from-commit`	生成代码Review报告（Commit Hash模式）
`list-authors`	查看提交作者列表

使用方式：在 MCP 面板的 Prompts 区域选择对应模板，填入参数即可自动生成提示词并执行。

1. `list_branch_authors`

列出变更范围内所有提交的作者信息，帮助用户确认自己的 Git 用户名。

2. `get_changed_files`

获取变更文件的路径列表。用于：

了解本次迭代涉及哪些文件
根据文件路径让 LLM 批量生成文件功能描述

3. `generate_code_review`

生成代码 Review 报告（HTML 格式）。支持接收文件功能描述参数，在报告中展示。

使用方式

配置完成后，在 AI 助手中使用以下指令：

一句话生成 Review 报告（推荐）

直接告诉 AI 你要生成代码 Review 报告，AI 会自动完成以下流程：

分支对比模式：

"帮我生成代码 Review 报告，仓库路径是 /path/to/my-project，开发分支是 feature/my-branch，目标分支是 main，作者是 Zhang San"

Commit Hash 模式：

"帮我生成代码 Review 报告，仓库路径是 /path/to/my-project，开发分支是 feature/my-branch，从 commit abc1234 开始，作者是 Zhang San"

AI 会自动：

调用 generate_code_review 获取变更文件列表
根据每个文件的完整路径理解其功能，生成简短的中文功能描述（50字以内）
再次调用 generate_code_review 传入文件描述，生成完整的 HTML 报告

整个过程在一轮对话中自动完成，无需手动干预。

文件功能描述示例

AI 会根据文件路径智能生成功能描述，例如：

src/api/settlement.ts → "结算管理API接口"
src/views/Settlement/Corporate.vue → "结算列表页面"
src/utils/date.ts → "日期格式化工具函数"
src/store/user.ts → "用户状态管理"
src/components/UploadFile.vue → "文件上传组件"

查看提交作者列表

当你不确定自己的 Git 用户名时：

"帮我查看 /path/to/my-project 仓库中 feature/my-branch 分支相对于 main 分支的所有提交作者"

`generate_code_review` 参数说明

参数	必填	说明
`repo_path`	✅	Git 仓库的本地绝对路径
`dev_branch`	✅	开发分支名称（你的工作分支）
`target_branch`	⚠️	目标对比分支（如 main、master、develop），与 `from_commit` 二选一
`from_commit`	⚠️	起始 commit hash，与 `target_branch` 二选一
`author`	❌	Git 提交作者名称或邮箱，用于筛选特定作者的提交
`output_path`	❌	HTML 报告输出路径，默认生成在仓库根目录
`file_descriptions`	❌	文件功能描述列表，每个元素包含 `path`（文件路径）和 `description`（功能描述，50字以内）

`get_changed_files` 参数说明

参数	必填	说明
`repo_path`	✅	Git 仓库的本地绝对路径
`dev_branch`	✅	开发分支名称
`target_branch`	⚠️	目标对比分支（如 main、master、develop），与 `from_commit` 二选一
`from_commit`	⚠️	起始 commit hash，与 `target_branch` 二选一
`author`	❌	Git 提交作者名称或邮箱，用于筛选特定作者的提交

`list_branch_authors` 参数说明

参数	必填	说明
`repo_path`	✅	Git 仓库的本地绝对路径
`dev_branch`	✅	开发分支名称
`target_branch`	⚠️	目标对比分支，与 `from_commit` 二选一
`from_commit`	⚠️	起始 commit hash，与 `target_branch` 二选一

报告内容

生成的 HTML 报告包含以下内容：

变更概览: 统计信息（文件数、提交数、新增/删除行数）、参与开发者列表
文件功能描述: 每个文件的功能描述（由 LLM 根据文件路径生成，50字以内）
文件变更详情: 每个文件的关键改动点、代码差异
代码差异高亮: 带语法高亮的 diff 视图，支持 Vue SFC 多段语言高亮
文件目录导航: 左侧固定目录栏，展示文件名和功能描述，支持快速跳转

项目结构

mcp-xl-code-review/
├── src/
│   ├── index.ts            # MCP Server 入口
│   ├── git-utils.ts        # Git 操作工具类
│   ├── analyzer.ts         # 代码分析器
│   └── report-generator.ts # HTML 报告生成器
├── build/                  # 编译输出目录
├── package.json
├── tsconfig.json
└── README.md

技术栈

TypeScript: 主要开发语言
MCP SDK: Model Context Protocol 服务端 SDK
Git: 通过 child_process 调用 Git 命令
Node.js: 运行环境

开发

# 开发模式（监听文件变化）
npm run dev

# 构建
npm run build

# 清理构建产物
npm run clean

注意事项

确保本地已安装 Git 并且可以在命令行中使用
仓库路径必须是本地已克隆的 Git 仓库
分支名称需要是本地已存在的分支（如果远程分支未拉取，请先 git fetch）
作者名称匹配使用 Git 的 --author 参数，支持部分匹配
图片、字体、压缩包等二进制资源文件会被自动过滤，不会出现在报告中
无实际代码差异的文件（如仅格式变更）也会被自动排除

License

MIT

Available Tools

3 tools

generate_code_reviewA

生成代码Review报告。支持两种模式：

模式一：分支对比模式（需要 target_branch）对比开发分支与目标分支的代码差异。

模式二：Commit Hash 模式（需要 from_commit，不需要 target_branch）指定一个起始 commit hash，获取该 commit 之后到开发分支的所有变更并生成报告。

使用场景：

迭代结束后，需要在小组内分享代码改动
代码评审会议前准备Review材料
记录本次迭代的技术细节

使用方式：直接调用此工具即可。如果不传 file_descriptions，系统会返回变更文件列表，你需要根据每个文件的完整路径理解其功能，生成简短的中文功能描述（50字以内），然后再次调用此工具传入 file_descriptions 参数。

参数说明：

repo_path: Git仓库的本地路径
dev_branch: 开发分支名称（你的工作分支）
target_branch: 目标对比分支（通常是main/master/develop），使用 from_commit 模式时可不传
from_commit: 起始 commit hash，指定后无需 target_branch
author: 你的Git用户名或邮箱（用于筛选你的提交，可选）
output_path: HTML报告输出路径（可选，默认生成在仓库根目录）
file_descriptions: 文件功能描述列表（可选，不传则返回文件列表供你生成描述）

ParametersJSON Schema

Name	Required	Description
`author`	No	Git提交作者名称或邮箱（用于筛选特定作者的提交，可选）
`repo_path`	Yes	Git仓库的本地路径
`ai_summary`	No	AI生成的代码审查总结（可选）。当传入 file_descriptions 后，系统会返回所有文件的diff内容，你需要分析这些diff并生成符合Code Review规范的技术总结，包括：技术思路、疑难解决、特殊说明、关键改动细节等。生成后通过此参数传入，系统会将其展示在报告中。
`dev_branch`	Yes	开发分支名称
`from_commit`	No	起始 commit hash。指定后，将获取该 commit 之后到 dev_branch 的所有变更，无需指定 target_branch。
`output_path`	No	HTML报告输出路径（可选，默认在仓库根目录生成）
`target_branch`	No	目标对比分支（如main、master、develop）。使用 from_commit 模式时可不传。
`file_descriptions`	No	文件功能描述列表（可选），每个元素包含文件路径和对应的功能描述。如果不传，系统会返回变更文件列表，你需要根据每个文件的完整路径理解其功能，生成简短的中文描述（50字以内），然后再次调用此工具传入。

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of disclosing behavior. It clearly explains the interactive two-step process (returning changed files when file_descriptions is omitted, then requiring a second call with descriptions) and the mode-selection rules. This goes beyond a simple purpose statement, though it does not cover every potential edge case.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear headings for modes, use cases, usage, and parameters. While lengthy, every section provides necessary context for a complex tool, and the purpose is front-loaded. No redundant or filler sentences are present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (two modes, interactive workflow, 8 parameters, no output schema), the description is remarkably complete. It covers mode selection, the file_descriptions round-trip, output path behavior, and usage scenarios, giving an agent everything needed to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description includes a dedicated parameter section that explains the role of each parameter and adds semantic context beyond the schema. It clarifies the mutually exclusive relationship between target_branch and from_commit, which is not fully evident from the schema alone. With 100% schema coverage, the baseline is 3, but the added mode logic raises it to 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with '生成代码Review报告', a specific verb and resource that clearly states the tool's purpose. It further distinguishes itself from sibling tools like get_changed_files and list_branch_authors by focusing on report generation, not just listing files or authors.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage scenarios (end-of-iteration sharing, code review preparation, technical record keeping) and explains the two operation modes. However, it does not explicitly mention when not to use this tool or direct users to alternative sibling tools, stopping short of a perfect score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_changed_filesA

获取变更文件的路径列表。支持两种模式：

模式一：分支对比模式（需要 target_branch）对比开发分支与目标分支之间的代码差异。

模式二：Commit Hash 模式（需要 from_commit，不需要 target_branch）指定一个起始 commit hash，获取该 commit 之后到开发分支的所有变更。适用于不想指定目标分支的场景。

使用流程：

调用此工具获取变更文件路径列表
根据每个文件的完整路径名称，生成简短的中文功能描述（10-20字）
将描述通过 file_descriptions 参数传给 generate_code_review 工具

描述示例：

src/api/settlement.ts -> "结算管理API接口"
src/views/Settlement/Corporate.vue -> "结算列表页面"
src/utils/date.ts -> "日期格式化工具函数"
src/store/user.ts -> "用户状态管理"
src/components/UploadFile.vue -> "文件上传组件"

ParametersJSON Schema

Name	Required	Description
`author`	No	Git提交作者名称或邮箱（用于筛选特定作者的提交，可选）
`repo_path`	Yes	Git仓库的本地路径
`dev_branch`	Yes	开发分支名称
`from_commit`	No	起始 commit hash。指定后，将获取该 commit 之后到 dev_branch 的所有变更，无需指定 target_branch。
`target_branch`	No	目标对比分支（如main、master、develop）。使用 from_commit 模式时可不传。

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses the two operational modes and the output as a list of file paths. However, it stops short of detailing the exact return format, edge cases (e.g., deleted files, untracked files), or ordering, which would be valuable for full transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear headings for two modes and a numbered usage workflow. It includes practical examples of generated descriptions, all of which are relevant to downstream usage. The length is justified given the complexity of the two modes and the integration guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity and the absence of an output schema, the description is remarkably complete. It explains both input modes, the return value (list of paths), and the intended integration with generate_code_review, including example filename-to-description mappings. This is more than sufficient for an agent to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers all parameters (100% coverage), so the baseline is 3. The description adds value by explaining the roles of target_branch and from_commit within the two modes, going beyond the schema's individual descriptions. It also implies the relationship between dev_branch and the modes, enriching parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it '获取变更文件的路径列表' (gets the list of changed file paths) with a specific verb and resource. It distinguishes two modes (branch comparison and commit hash) that further clarify the tool's scope, and the workflow differentiates it from sibling tools like generate_code_review and list_branch_authors.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly explains when to use each mode: branch comparison mode requires target_branch, while commit hash mode is for when you don't want to specify a target branch. It also provides a step-by-step usage flow, connecting this tool to generate_code_review, making it clear how it fits into the overall review process.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_branch_authorsA

列出变更范围内所有提交的作者信息，帮助用户确认自己的Git用户名。支持两种模式：

模式一：分支对比模式（需要 target_branch）模式二：Commit Hash 模式（需要 from_commit，不需要 target_branch）

使用场景：

不确定自己的Git用户名时，先查看提交作者列表
了解本次迭代有哪些人参与了代码提交

ParametersJSON Schema

Name	Required	Description
`repo_path`	Yes	Git仓库的本地路径
`dev_branch`	Yes	开发分支名称
`from_commit`	No	起始 commit hash。指定后，将获取该 commit 之后到 dev_branch 的所有提交作者，无需指定 target_branch。
`target_branch`	No	目标对比分支。使用 from_commit 模式时可不传。

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It explains scope and parameter modes but does not disclose whether the operation is read-only, what the output looks like, or any ordering/dedup behavior. This is adequate but leaves room for more transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with a brief intro, numbered modes, and a bulleted use-case list. Every sentence adds useful information; there is no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With four parameters, two modes, no output schema, and no annotations, the description adequately explains parameter interplay and usage context. The main gap is the lack of detail about exact returned fields (e.g., names, emails), but this is not critical for tool selection/invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds meaningful mode-based semantics beyond the schema: it clarifies which parameters are needed in each mode and elaborates that from_commit captures all commits after it up to dev_branch. This extra value justifies a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action: '列出变更范围内所有提交的作者信息' (list author info of all commits in the change range). This clearly identifies the tool's resource and purpose, and distinguishes it from siblings get_changed_files and generate_code_review, which deal with files and reviews rather than authors.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context with two explicit modes (branch comparison and commit hash mode) and concrete use cases (confirming own Git username, seeing participants in this iteration). It does not explicitly state when not to use the tool or name alternatives, but the mode guidance is solid, so it earns a 4.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.5/5.0

Disambiguation4/5

The three tools have distinct primary purposes (list changed files, generate review, list authors), but generate_code_review can also return a changed file list when file_descriptions is omitted, creating a slight functional overlap with get_changed_files. This overlap is minor because the intended workflow is clearly described, but it could cause an agent to call the wrong tool first.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: get_changed_files, generate_code_review, list_branch_authors. The naming is uniform in style and clearly communicates each tool's action and target.

Tool Count5/5

Three tools are appropriate for a specialized code review server. Each tool serves a distinct step in the workflow (identify files, generate review, identify authors), and no tool feels redundant or excessive for the scope.

Completeness5/5

The tool surface covers the essential workflow for generating code reviews: retrieving changed files, generating the review report, and listing authors for context. There are no obvious gaps within the stated purpose of the server.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

MarkupBase AOAuthDeprecated
com.markupbase
Versioned artifact review for people and AI agents, with contextual comments and human control.
Developer Tools Project Management Workplace & Productivity
121
GitLumen MCP A
io.github.gitlumen-team
Screens public GitHub repos and PRs to generate risk maps, findings, and merge-readiness signals.
Version Control Code Analysis
52
XRay-Vision
com.emtailabs
AI-powered codebase analysis — call graphs, security, dead code, complexity. 150+ tools.
Code Analysis Developer Tools Autonomous Agents
2
github-mcp-server A
com.thenextgennexus
GitHub repo analytics: stars, trending, code search, contributor maps for project research.
Version Control Developer Tools
42

Related MCP Servers

PR Reviewer
Version Control Note Taking Developer Tools
KalyankumarKonduru
F
license
Not graded
quality
D
maintenance
A tool that integrates with GitHub and Notion to analyze and review pull requests, enabling automated code reviews and documentation in Notion.
Updated a year ago (2025-04-08 20:28 UTC)
MCP Review Server
Code Analysis Developer Tools
jonels-msft
F
license
Not graded
quality
F
maintenance
A specialized code review service that provides 36+ critics for different programming aspects and 3 fixing strategies to automatically address identified issues in a two-step workflow.
Updated 7 months ago (2026-02-05 17:14 UTC)
MCP Merge Request Summarizer
Version Control Developer Tools Text Summarization
sonicjoy
A
license
Not graded
quality
D
maintenance
Automatically generates comprehensive merge request summaries from git logs, analyzing commit history and categorizing changes into structured descriptions. Provides tools to analyze git repositories, compare branches, and create detailed summaries with change categorization, impact analysis, and review time estimates.
Updated a year ago (2025-08-29 16:31 UTC)
1
MIT
Batch Review
Version Control Developer Tools Code Analysis
hevangel
A
license
Not graded
quality
A
maintenance
A collaborative code and markdown review tool that bridges human reviewers and AI agents, enabling both to browse files, inspect git diffs, leave structured comments, and save a final review report from the same UI in real time.
Updated 25 days ago (2026-08-09 06:11 UTC)
2
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/xlian-fe/mcp-xl-code-review'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

MCP Code Review Server

功能特性

安装

配置 MCP Server

在 Claude Desktop 中配置

在 Cursor 中配置

使用 npx 运行（无需全局安装）

工具说明

提示词模板（Prompts）

1. list_branch_authors

2. get_changed_files

3. generate_code_review

使用方式

一句话生成 Review 报告（推荐）

文件功能描述示例

查看提交作者列表

generate_code_review 参数说明

get_changed_files 参数说明

list_branch_authors 参数说明

报告内容

项目结构

技术栈

开发

注意事项

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `list_branch_authors`

2. `get_changed_files`

3. `generate_code_review`

`generate_code_review` 参数说明

`get_changed_files` 参数说明

`list_branch_authors` 参数说明