Skip to main content

Command Palette

Search for a command to run...

用 ChatGPT 评审 PR

Updated
1 min read

前些天写了个脚本,用 ChatGPT 给 FloMesh 的 Pipy 项目做了个代码评审,生成的结果还挺有意思的,例如下面这段结果:

评价:

1. 代码没有明确的介绍具体的功能和作用,缺乏注释和文档说明。
2. 使用了一些不必要的注释,如版权声明和许可条款,应该将这些内容放入独立的文档中。
3. 引用了一些外部库文件,在没有说明的情况下建议在头文件中添加相关介绍。
4. 没有遵循统一的命名规范,建议遵循某种命名规范,如 Google C++ Style Guide。
5. 代码风格和排版统一,清晰易读。

改进意见:


#ifndef THREAD_HPP
#define THREAD_HPP

#include "pjs/pjs.hpp"
#include "worker-thread.hpp"

namespace pipy {

// 在代码开头添加注释,介绍文件的作用和功能
// ...

// 添加版本信息或其他相关说明
// ...

// 可以将所有依赖的外部库文件进行汇总说明
// ...

// 建议统一的命名规范,如使用 Google C++ Style Guide。
class Thread : public pjs::ObjectTemplate<Thread> {
public:
  // 在函数上添加注释,说明函数的功能和参数含义
  auto index() const -> int { return m_worker_thread->index(); }

private:
  // 在变量上添加注释,说明变量的作用和类型
  Thread(WorkerThread *worker_thread) : m_worker_thread(worker_thread) {}

  WorkerThread* m_worker_thread;

  friend class pjs::ObjectTemplate<Thread>;
};

} // namespace pipy

// 添加结尾注释
// ...

// 推荐加上 #endif 前的空格
#endif // THREAD_HPP

自然而然就产生了个想法——如果项目每个 PR 都能这样自动 Review 一下岂不妙哉?结果——好点子总会有人比你先想到,已经有人编写了一个 Github Action 了,于是试用了一下,记录一下这个试用过程。

首先在目标项目的设置中加入 OpenAI 的 API_KEY,也就是在项目的 Settings->Security->Secrets and variables->Actions 菜单中,加入 Repository Secret,Key 设置为 OPENAI_API_KEY

接下来,在 Github Action 中加入如下代码:

name: Code Review

permissions:
  contents: read
  pull-requests: write

on:
  pull_request:
    types: [opened, reopened]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: anc95/ChatGPT-CodeReview@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
          LANGUAGE: Chinese

上面代码尝试在创建 PR 时候对变更内容进行评审动作。

我们尝试给项目新建一个 PR,其中包含一段新的输出代码,并删除了一行注释,结果收到了如下的评审记录:

从结果看来,ChatGPT 对 PR 的目的进行了识别,并给出了讲解和建议。不过前面 Action 定义的语言并没有生效,应该后续还会有提升空间——或者用这个思路再做一个也是不错的想法。

另外,受到 Token 上限的影响,代码文件只能接受 4K 以下的文件,传说新的 GPT 4.0 API 能够支持更大的 Token 上限,也许就能支持更大的代码文件了。

More from this blog

龙虾恐慌:AIOps 又要改名了?

ChatGPT 开始,把 AI 拉近到普罗大众的面前,让无数人感受到 AI 的亲民魅力。而龙虾,则把大模型驱动的自动化能力,突然间变得水灵灵、活泼泼地走进千家万户。它不只是“风口上的猪”,而是风口本身。热度高到让 Mac mini 一度断货,不知道这在不在库克的预料之内。 每代人都有每代人的鸡蛋,春节期间,我就领了我的鸡蛋。翻出古老的 MacBook Air M1,充值各种大模型。当然了,这个工具

Mar 9, 20261 min read

再见 2025

我猜不少人以为这个号废了吧?并没有,只是今年变化有点大,一直有种抄起键盘,无从说起的感觉,所以一直偷懒到今天,2025 的最后一天。 今年是我的第四个本命年,去年末一期播客里,大内说本命年不是灾年,是变化年,有危也有机。可是讲真啊,只看到危,没看到机。 各种因缘际会,从鹅厂跳槽到前东家,已经接近四年,第一个合同期已经进入尾声。除了前两年还在云原生领域嗷嗷叫,后两年基本都是些鸡零狗碎的东西了,用老东家的术语说是——偏离主航道,可谓是前景暗淡了。 一旦确定要滚蛋,反倒心思轻松起来,每天骑着我的小红车...

Jan 5, 20261 min read

辅助编程?dora 说:我知道你很急可是请你别急

从 OpenGPT 把大模型的火烧旺了之后,这三年来,相信很多组织或摩拳擦掌、或躬身入局,希望借助聪明能干的大模型,或想偿还技术宅,或想降本增效,或想弯道超车。一时间,沉寂许久的 AIxx 又活过来了,LLM Ops、Vibe Coding、中医大模型、GPT 算命等等,全都老树发新芽,焕发了勃勃生机。那么视角拉回从业者最关注的饭碗相关的领域之一——AI 辅助开发,产生了什么触动,应该如何拥抱呢? DORA 的年度报告中给出了很有意思的结论——强者恒强。 执行摘要部分总结了几个有趣的点: 问题...

Oct 6, 20251 min read

[译]dora:ai 辅助软件开发状态报告

执行摘要 在 2025 年,科技领导者面临的核心问题已不再是“是否要采用 AI”,而是“如何实现其价值”。 DORA 的研究基于超过 100 小时的定性访谈和来自全球近 5,000 名技术专业人士的问卷调查。研究揭示了一个关键事实:AI 在软件开发中的主要角色是“放大器”。它会放大高效能组织的优势,也会凸显组织的缺陷。 关键结论:AI 是放大器 AI 投资的最大回报并非来自工具本身,而是来自组织底层系统的战略性建设: 高质量的内部平台 清晰的工作流 团队的协同能力 缺少这些基础,AI ...

Oct 2, 202514 min read

僭越了,有人在用 Rust 写 Kubernetes

一个新语言问世,最爱做的事情之一,就是重写存量软件了。 云原生喝酒 SIG 重点扶持项目——rk8s(https://github.com/rk8s-dev/rk8s) 也可以归在这个范畴里,只不过这个项目重写的东西比较大,是 Kubernetes。 从 2025 年 1 月第一个 Commit 开始,到现在有了 200 多次 Commit,十几万行代码。当然距离 Kubernetes 的几百万行代码还差得远——老马就是喜欢整这种大无畏项目。 另外该项目也是国内第一个脱离 Cargo 转向使用 ...

Sep 27, 20253 min read

【伪】架构师

342 posts