AI 代码可读性度量代码库对语言模型是否可读：代码是否携带机器可校验的类型信息，文件是否能够从容地放入模型的工作上下文。帮助人类驾驭陌生代码库的那些属性同样帮助模型——但对模型而言，过大的文件是硬性约束，而非仅仅令人不快。
- 类别：AI 就绪度（类别内占 15%）
- 在总指数中的权重：0%——属于独立的 AI 就绪度徽章
- 指标键：
ai_code_legibility - 对于检测不到源文件的仓库为
null——纯文档项目不受罚分
数值如何计算
| 组成部分 | 权重 | 判定标准 |
|---|---|---|
| 可类型检查的代码 | 45 | 静态类型语言 → 45 分；动态类型语言但配置了类型检查 → 27 分；两者皆无 → 0 分 |
| 可控的文件大小 | 55 | (1 − oversized / total) × 55，其中超过约 60 KB（约 1,500 行）的源文件计为过大；第三方内嵌（vendored）与生成的路径被排除 |
为什么是这两个信号
- 类型是压缩后的文档。带类型的签名让模型无需阅读函数体即可知晓其接受与返回什么——类型检查器则把模型的误解转化为即时、机械化的错误，而非潜伏的缺陷。为配置了检查器（mypy、pyright、tsconfig）的动态类型项目给予部分分值，反映了渐进式类型化已能捕获大部分收益。
- 文件大小分布决定模型能否将一个代码单元完整置于上下文之中。由聚焦模块组成的代码库可以分块阅读；一个 5,000 行的文件迫使截断，而截断正是代理错误集中出现之处。
第三方内嵌与生成的代码被排除在外，以免提交入库的 vendor/ 目录树或生成的绑定扭曲测量结果。
如何解读结果
- 该指标读取的是结构而非风格——命名、注释与架构不参与评分（参见 AI 就绪度中的诚实规则）。
- 文件大小组成部分按比例计算：五十个文件中有一个过大代价甚微；由庞然大物构成的代码库则相应地读数偏低。
如何提升数值
- 采用类型检查器；在动态语言中，即使是宽松的初始配置也能获得部分分值，并形成持续收紧的棘轮。
- 沿自然边界拆分接近约 1,500 行的文件。
- 将生成代码与第三方内嵌代码置于约定俗成命名的路径下，使其被排除在测量之外。