AI 代理上下文度量仓库是否为 AI 编码代理提供指引与机器可读的文档。进入陌生代码库的代理面临与新入职工程师相同的问题——不同之处在于，它在每个会话中都能于毫秒之间读完全部入职材料。将这些材料成文写下的项目，其代理产出可测地更好。
- 类别：AI 就绪度（类别内占 30%）
- 在总指数中的权重：1.2%
- 指标键：
ai_agent_context
数值如何计算
| 组成部分 | 权重 | 证据 |
|---|---|---|
| 代理指令 | 45 | CLAUDE.md、AGENTS.md、.cursor/rules、Copilot 指令、GEMINI.md 或等效文件；小于约 200 字节的文件被视为占位文件（stub），仅获部分分值 |
| 机器可读文档 | 15 | 存在 llms.txt 或 llms-full.txt |
| 可读的提交历史 | 40 | 由人类撰写、且说明了自身意图的提交所占比例；达到 75% 及以上即得满分 |
提交历史为何计入
书面指引是某个人必须主动决定去创建的文件，而多数项目从未拥有它。提交历史则不同：每个项目本就会产生提交历史，代理在改动陌生代码之前会先查阅它——为的是弄清周围的决策为何如此，而不只是代码做了什么。
当一条提交的标题具有结构时——采用 conventional commit 形式，或引用改动背后的 issue 或 pull request——或者其正文解释了改动而非复述标题，即视为说明了意图。两种形式均可计分，因为单独要求任何一种都失之偏狭：Linux 内核不写 conventional 前缀，却几乎总是自我解释；而另一些项目维持完全 conventional 的历史，消息只有一行。两者都可读；两者都计入。
由自动化产生的提交不计入，因为机器生成的标题格式一律工整，无法说明项目自身的实践。
良好的代理上下文包含什么
一份有效的指令文件向代理传达 README 向人类传达的内容，外加只有维护者才知道的信息：如何构建与测试、哪些目录重要、项目约定，以及各种陷阱（“容器提供的是已构建的镜像——编辑后需要重新构建”）。llms.txt 约定与之互补，为语言模型提供项目文档的精选索引。
占位文件规则之所以存在，是因为存在性信号可能被刻意操纵：为获取徽章而创建的空 CLAUDE.md 与真实文件之间的差异是可检测的，方法论在检测成本低的环节对实质内容加权。
如何解读结果
- 信号基于文件树中的存在性与文件大小；内容本身不参与评分——这是 AI 就绪度类别通篇申明的诚实边界。
- 任何一种被认可的指令约定均可计分；方法论在代理工具层面保持供应商中立，与安全态势的工具无关立场一致。
如何提升数值
- 撰写有实质内容的
CLAUDE.md或AGENTS.md：构建与测试命令、目录布局、约定以及已知陷阱。保持其时效——这是一份面向可执行读者的文档。 - 添加
llms.txt，为语言模型消费建立项目文档索引。 - 在提交标题中引用 issue 或 pull request，或在正文中解释改动。两者都是寻常的评审纪律；两者都能让历史对下一个维护项目的人——或程序——保持可读。