llm-code-scorer

这是去年9月份受两个实习生小伙伴讨论代码启发而做的一个小项目，这周五他们回学校了，我也把这个在草稿箱躺了11个月的文章改了改，发出来作为纪念。

背景介绍

为了找出开源代码仓库存在的问题（缺少证书，缺少文档，缺少测试，代码质量不高）并加以改进，我搭建了一个基于 LLM 来自动分析代码仓库并打分的网站，可以在这里体验

实现细节

Clone 仓库
将仓库中的代码、文档、证书、测试例子等按照固定的格式，写成一个总结文档
设计给大模型的 PROMPT 提示词规范
将 PROMPT+总结文档喂给大模型（这里用的是智谱的免费模型 GLM-4-Flash)，大模型返回 json 格式的打分结果
网页渲染 json 结果，得到最终的输出

Features

打分维度考虑全面，包括代码质量、仓库大小、Git Commit 规范、文档、测试、开源证书等方面
基于大模型的打分并给出了建议，可以根据建议来改进代码质量
有结果保存成图片的功能，方便记录
代码开源，源代码地址: https://github.com/vra/llm-code-scorer
下面是这个网站制作的详细说明，希望能给想做简单好玩AI应用的朋友们提供一个参考。

起因

有一次想到某个仓库的代码，逻辑非常绕，很不直观。要是有办法能让作者意识到这里的问题，进行优化改进，对使用者也是极好的。

然后联想到有一次团队的一个小伙伴提到某个开源代码，评价其是“一坨狗屎”，突然灵光一现：能不能做一个大模型来对代码进行分析的工具，给出0-10分的打分，最差的0分，锐评就是“一坨狗屎”，把这个梗用上去。

然后整体评估了下，整体上是可行的，大模型见过了那么多的代码，肯定知道哪些代码是好的，哪些代码是烂的。

方案设计

然后一个核心问题出现了：GitHub上的开源代码仓库有大有小，包含文档、配置、测试和真正的有用源代码，如何将这么多东西喂给大模型输出一个总体的评分呢？想起了之前看过的LLM的项目，我设计了一个模板，将内容按照源码、配置项、README、证书，是否有测试等情况进行分类，按照一个模板，汇总成输入给到大模型。

打分的时候，也是设计了Prompt，根据不同的维度进行考察，Prompt如下：

PROMPT = """
---
已将一个 Git 仓库的所有信息按照概要格式组织，请仔细阅读概要信息，尤其是一定一定要对[Code Snapshot]部分的代码风格、逻辑、规范进行仔细查阅，然后结合具体的例子，给出下面6个维度的0-10分的打分（打分标准见下): 代码质量、文档规范、配置规范、提交规范、大小规范、测试规范，最后完整全面地总结代码的优点和待改进点，给出总结和建议。

### 概要格式

[.gitignore]:
[Git Commit]:
[Code Snapshot]:
[Test Files]:
[Binary Files]:
[Repo Size]:
[Total Files]:

### 评分维度说明

#### 1. 代码质量（0-10）
- **0-3**: 代码不易读，逻辑混乱，缺乏注释, 命名不规范，风格不一致，难以理解，存在多个严重的潜在错误。
- **4-6**: 代码可读性一般，有部分注释，存在一些逻辑问题和不规范命名，风格混合（例如驼峰和下划线命名混用）,偶尔有潜在错误。
- **7-8**: 代码整体清晰，注释较为充分，逻辑严谨通顺，命名统一规范，潜在错误较少。
- **9-10**: 代码结构良好，规范一贯，逻辑清晰，易于理解，命名准确一致，几乎没有潜在错误。
- 如果[Code Snapshot]部分内容为空，说明没有任何源代码，代码质量直接为0分，评分理由是没有任何源代码，

#### 2. 文档规范（0-10）
- **0-3**: 文档缺失(例如没有README)或只包含极少信息(README没有使用说明)，无法帮助用户理解和使用。
- **4-6**: 文档不完整，有部分信息缺失，用户可能需要额外查找信息。
- **7-8**: 文档较为完整，提供了大部分所需信息，少量细节需要完善。
- **9-10**: 文档非常详尽，覆盖所有重要细节，除了README，还有BUILD,CONTRIBUTING，faq，trobuleshooting，docs等专门的文档或目录，用户能够轻松理解和上手。

#### 3. 配置规范（0-10）
- **0-3**: 项目配置混乱，缺少必要的配置文件（如 .gitignore, LICENSE）。
- **4-6**: 项目配置一般，有一些配置文件，但不充分，例如虽然有.gitignore，但是没有忽略.pyc，.DS_Store, .out，.so等中间结果。
- **7-8**: 项目配置良好，包含必要的配置文件，结构清晰，忽略了常见的非源码文件。
- **9-10**: 优化的项目配置，包含所有必要文件(如.gitignore, LICENSE, setup.cfg等)，并遵循最佳实践，忽略了全部的非源码文件，已经不需要的数据目录等。
- 如果[LICENSE]部分或者[.gitignore]部分内容为空，说明没有证书或者忽略规则，配置规范直接为0分，没有证书和gitignore规则是很不专业的开源方式

#### 4. 提交规范（0-10）
- **0-3**: 提交信息极其简单，完全无法理解提交的目的(例如简单的update, upload等)。
- **4-6**: 提交信息有一定描述，但描述不够详细或含糊。
- **7-8**: 提交信息清晰，能够理解修改的内容和目的，同时有固定的格式如angular规范等。
- **9-10**: 提交信息详细且准确，充分解释每次提交的变更和背景，详细内容通过空行再详细说明的形式提交。

#### 5. 大小规范（0-10）
- **0-3**: 计算[Repo Size] / [Total Files]，也就是平均每个文件的大小，超过1M，越小分值越高
- **4-6**: 平均每个文件大小超过500K，越小分值越高
- **7-8**: 平均每个文件大小超过100K，越小分值越高
- **9-10**: 平均每个文件大小小于100K，越小分值越高, 如果小于30K，则为10分
- 如果[Code Snapshot]部分内容为空，但[Size]部分超过10M，大小规范直接为0分，没有源码但size超大说明保存的是二进制文件而不是代码

#### 6. 测试规范（0-10）
- **0-3**: 没有任何的单元测试或者集成测试，也没有任何文档说明 。
- **4-6**: 有默认的mock测试文件，但没有真正代码的测试例子。
- **7-8**: 有一些实际代码的测试例子，但测试覆盖率很低，没有说明怎么进行测试。
- **9-10**: 如果[Test Files]中的测试文件数目/[Total Files] 超过10%，说明测试覆盖率高，这个占比越高分值也越高，同时有详细的说明进行如何测试。
- 如果[Test Files]部分内容为空，说明没有任何的测试，测试规范直接为0分

重要的附加说明：打分一定要有区分度，例如[Test Files]，[LICENSE], [.gitignore] 或 [Code Snapshot] 如果为空，则对应的评分维度就果断打0分，这样最终的结果才有警示意义和区分度，如果做的很好就果断给10分，不要中庸地给8分或者9分.

由于智谱提供了免费的LLM API，因此打分模型基于这个免费的API来构建。

思路定了后，就想找一些网页效果比较酷炫的网站来看看，因为模仿也是写代码中很重要的一个部分（看看国内各大大模型的上传图片的UI就知道了）。 之前王登科分享过一个文字风格测试的网站（已经无法使用），想参考其做网站页面。 最后参考了之前体验的 Year in code的网站，渐变的色彩 https://year-in-code.com/

既然想做一个稍微正式点的Side Project，还是值得花点钱准备一些必须要的软硬件。

首先是申请域名时发现， 因为之前调查过，各家云厂商都有100块左右一年的低配机器，而阿里云目前在国内还是做的比较好，又是一个系统的，因此下单了99年一年的机器。

所以这个Side Project的总支出是7+99=106元，算是低成本了。

之前看过一个大佬的博客，说他50%的时间花在Coding上， 50%的时间花在Marketing，因此推广自己的作品和写代码一样重要，不要觉得推广自己的东西很羞耻，如果你做的东西很棒，那就应该让更多的人知道，毕竟在这个信息爆炸的时代，酒香也怕巷子深。

关于这个项目，我的定位还是低成本的Side Project，因此做的推广并不多。具体来说，在网站搭建好，域名还没有备案完成时，先在几个好友之间共享，收集他们的评论和反馈意见。然后网址完成备案后，在v2ex上进行了分享，源码在GitHub上开源，所有人都可以自己跑，然后修改。

它真的有用吗？

平心而论，我觉得目前这个版本用处有限，可能最大的用处是让开发者能知道格式上的问题，例如代码没有README，没有写测试，提交不规范等等，对代码逻辑是否通顺、写法是否优雅这种细致到代码实现细节的方面，它能做的不多。

那么问题在哪里呢？一方面是采用的免费模型还有改进空间，采用更强大的付费模型肯定会有提升，但按token数计算的支出可能是个无底洞，已经超出了这个Side Project的经费上限。

另一方面，Prompt可能还有改进的空间，通过几个版本Prompt的表现来看，修改Prompt是最有效的提升效果的方法，未来我可能也会优化Prompt来更新这个网站。

其实在设计评分结果展示方案的时候，还考虑过用AI生成梗图的方式，例如锐评是“你写的代码比雷军还优雅”，就生成一张类似雷军的点赞的图片，但实际尝试后发现有几个问题： 1. 首先是AI生成的图片中文字效果还做不好，例如下面采用可灵的图片， 然后考虑到AI生图与代码评分本身关系不是很大，即使做好了也只是在戏剧和传播效果有一些作用，对程序员真正地发现代码中的问题并无直接帮助，因此也就去掉了这部分比较耗时的工作。

因为我不懂前端，Vue和css的代码全部是GPT生成的，因此现在的效果展示部分还比较简单。我尝试了让Vue调用D3.js来生成蜘蛛图，显示6个考察的维度，但最终没有成功。另外想做一个生成分享页面的功能，将所有信息都展示到一张图片上，再加上网站的二维码，可以进行社交媒体的分享，因为不熟悉前端也没能搞定。后来实习的小伙伴帮忙优化了网页展示，这里也表示感谢。

其实刚开始我也想过微信或者支付宝小程序，因为它们的传播效应会很明显，万一这个东西做的出色，出圈了，小程序能够做到快速地社群传播。 但小程序也有问题，开发难度比一个网站大，而且又得专门学自有的一台编程语言和工具系统，同时不太开放，而且之前看到小程序也要备案，难度又增大了。 这里我还是考虑Side Project的短平快属性与小程序较高的学习成本与漫长的合法审核周期不契合，因此果断放弃这个思路。如果未来有个创业团队将这种AI打分App当作一个严肃的产品来对待，那小程序还是值得做的平台。

总体上，我认为代码打分这个方向未来肯定会有更专业的人做出一个合格的产品出来，这里因为各方面的原因，我目前能提供的就是这个版本了。