代码审查对于维护标准和强调项目中代码的最佳实践始终至关重要。这不是一篇关于开发人员应该如何审查代码的文章，更多的是关于将一​​部分代码委托给 AI。

正如 Michael Lynch 在他的文章“如何像人类一样进行代码审查”中提到的那样——我们应该让计算机处理代码审查的无聊部分。虽然迈克尔强调格式化工具，但我想更进一步，让人工智能来解决这个问题。我的意思是，为什么不利用行业中人工智能的繁荣呢？

现在我并不是说应该使用人工智能来代替格式化工具和 linter。相反，它是用来捕捉人类可能错过的琐碎的东西。

这就是为什么我决定创建一个 github 操作，该操作的代码会审查拉取请求差异并使用 AI 生成建议。让我带您了解一下。

？笔记

• 此 GitHub 操作现已在 GitHub 市场上提供。
• 这是一个 javascript 操作 - 了解有关创建 javascript github 操作的更多信息。

获取差异

为了与 github API 交互，我使用了 octokit，它是一种 SDK 或客户端库，用于以惯用的方式与 github API 交互。

为了获得提出的拉取请求的差异，您需要传递带有值 application/vnd.github.diff 的 Accept 标头以及所需的参数。

async function getPullRequestDetails(octokit, { mode }) {
    let AcceptFormat = "application/vnd.github.raw json";

    if (mode === "diff") AcceptFormat = "application/vnd.github.diff";
    if (mode === "json") AcceptFormat = "application/vnd.github.raw json";

    return await octokit.rest.pulls.get({
        owner: github.context.repo.owner,
        repo: github.context.repo.repo,
        pull_number: github.context.payload.pull_request.number,
        headers: {
            accept: AcceptFormat,
        },
    });
}

如果您根本不熟悉 github actions，这里有 Victoria Lo 的 github actions 101 系列，这是一个很好的开始。

一旦获得差异，我就会解析它并删除不需要的更改，然后以如下所示的模式返回它：

/** using zod */
schema = z.object({
    path: z.string(),
    position: z.number(),
    line: z.number(),
    change: z.object({
        type: z.string(),
        add: z.boolean(),
        ln: z.number(),
        content: z.string(),
        relativePosition: z.number(),
    }),
    previously: z.string().optional(),
    suggestions: z.string().optional(),
})

忽略文件

忽略文件非常简单。用户输入列表需要以分号分隔的 glob 模式字符串。然后对其进行解析，与默认的忽略文件列表连接并进行重复数据删除。

**/*.md; **/*.env; **/*.lock;

const filesToIgnoreList = [
    ...new Set(
        filesToIgnore
            .split(";")
            .map(file => file.trim())
            .filter(file => file !== "")
            .concat(FILES_IGNORED_BY_DEFAULT)
    ),
];

然后使用忽略的文件列表来删除引用这些忽略的文件的差异更改。这为您提供了一个仅包含您想要的更改的原始有效负载。

生成建议

解析差异后获得原始有效负载后，我将其传递给平台 API。这是 OpenAI API 的实现。

async function useOpenAI({ rawComments, openAI, rules, modelName, pullRequestContext }) {
    const result = await openAI.beta.chat.completions.parse({
        model: getModelName(modelName, "openai"),
        messages: [
            {
                role: "system",
                content: COMMON_SYSTEM_PROMPT,
            },
            {
                role: "user",
                content: getUserPrompt(rules, rawComments, pullRequestContext),
            },
        ],
        response_format: zodResponseFormat(diffPayloadSchema, "json_diff_response"),
    });

    const { message } = result.choices[0];

    if (message.refusal) {
        throw new Error(`the model refused to generate suggestions - ${message.refusal}`);
    }

    return message.parsed;
}

您可能会注意到 API 实现中响应格式的使用。这是许多 LLM 平台提供的功能，它允许您告诉模型以特定模式/格式生成响应。在这种情况下，它特别有用，因为我不希望模型产生幻觉并为拉取请求中的错误文件或位置生成建议，或者向响应负载添加新属性。

系统提示为模型提供了更多关于如何进行代码审查以及需要记住的事项的背景信息。你可以在这里查看系统提示 github.com/murtuzaalisurti/better.

用户提示包含拉取请求的实际差异、规则和上下文。这就是代码审查的开始。

此 github 操作支持 OpenAI 和 Anthropic 模型。以下是它如何实现 Anthropic API：

async function useAnthropic({ rawComments, anthropic, rules, modelName, pullRequestContext }) {
    const { definitions } = zodToJsonSchema(diffPayloadSchema, "diffPayloadSchema");
    const result = await anthropic.messages.create({
        max_tokens: 8192,
        model: getModelName(modelName, "anthropic"),
        system: COMMON_SYSTEM_PROMPT,
        tools: [
            {
                name: "structuredOutput",
                description: "Structured Output",
                input_schema: definitions["diffPayloadSchema"],
            },
        ],
        tool_choice: {
            type: "tool",
            name: "structuredOutput",
        },
        messages: [
            {
                role: "user",
                content: getUserPrompt(rules, rawComments, pullRequestContext),
            },
        ],
    });

    let parsed = null;
    for (const block of result.content) {
        if (block.type === "tool_use") {
            parsed = block.input;
            break;
        }
    }

    return parsed;
}

添加评论

最后，在检索到建议后，我会对它们进行清理并将其传递给 github API 以添加评论作为审核的一部分。

我选择以下方式添加评论，因为通过创建新评论，您可以一次性添加所有评论，而不是一次添加一条评论。逐条添加评论也可能会触发速率限制，因为添加评论会触发通知，而您不希望向用户发送垃圾邮件通知。

function filterPositionsNotPresentInRawPayload(rawComments, comments) {
    return comments.filter(comment =>
        rawComments.some(rawComment => rawComment.path === comment.path && rawComment.line === comment.line)
    );
}

async function addReviewComments(suggestions, octokit, rawComments, modelName) {
    const { info } = log({ withTimestamp: true }); // eslint-disable-line no-use-before-define
    const comments = filterPositionsNotPresentInRawPayload(rawComments, extractComments().comments(suggestions));

    try {
        await octokit.rest.pulls.createReview({
            owner: github.context.repo.owner,
            repo: github.context.repo.repo,
            pull_number: github.context.payload.pull_request.number,
            body: `Code Review by ${modelName}`,
            event: "COMMENT",
            comments,
        });
    } catch (error) {
        info(`Failed to add review comments: ${JSON.stringify(comments, null, 2)}`);
        throw error;
    }
}

结论

我想让 github 操作保持开放性并开放集成，这就是为什么您可以使用您选择的任何模型 （请参阅支持的模型列表），或者您可以微调和构建您自己的自定义模型位于受支持的基本模型之上，并将其与此 github 操作一起使用。

如果您遇到任何代币问题或速率限制，您可能需要参考相应平台的文档来升级模型限制。

所以，你还在等什么？如果您在 github 上有存储库，请立即尝试该操作 - 它位于 github 操作市场上。

name: Code Review
on
    pull_request:
        types: [opened, reopened, synchronize, ready_for_review]
        branches:
            - main # change this to your target branch
    workflow_dispatch: # Allows you to run the workflow manually from the Actions tab

permissions: # necessary permissions
    pull-requests: write
    contents: read

jobs:
    your-job-name:
        runs-on: ubuntu-latest
        name: your-job-name
        steps:
            - name: step-name
              id: step-id
              uses: murtuzaalisurti/better@v2 # this is