这项研究关注一个容易被忽略的问题：当越来越多软件变更由自主代码智能体完成时，它们究竟查阅哪些文档、在什么时机查阅，以及查阅之后会做什么。作者没有从文档设计原则出发推测，而是基于智能体行为进行分析，使用了 SWE-chat 和 AIDev 两组公开数据。
智能体首先读取的不是 API 参考
SWE-chat 包含 557 次智能体编码会话、94,813 个开发事件，其中记录了 3,033 次文档交互；AIDev 则包含 33,097 个智能体提交的拉取请求，以及 690,260 条文件级变更记录。
研究最明确的发现，是智能体的文档工作高度集中在面向智能体的材料上。指令文件和工作笔记合计占全部文档交互的 60.5%，传统技术文档占 10.6%，API 参考仅占 1.3%。这说明，当前软件仓库中对代码智能体最有存在感的文档，可能不是面向人类读者整理得最完整的那一类，而是直接规定工作方式、记录当前上下文的文件。
查阅文档不等于马上修改代码
文档查阅与代码编辑之间的关系并不简单。相邻事件直接从查阅文档转向编辑代码的概率只有 0.002，未经调整的三事件提升值为 1.05；在进行阶段调整后，模型给出的优势比为 1.33，区间为 1.09 到 1.62。作者因此没有把文档查阅直接解释为代码修改的原因。
文档创建在未经调整时呈现较高的提升值，为 1.67，但调整后的区间包含 1，说明这一关联仍不足以支持稳定结论。研究还没有观察到明确的“查阅文档、据此验证”的序列。相反，查阅文档与较少的即时测试相关：提升值为 0.23，聚类置信区间为 0.08 到 0.45；调整后的优势比为 0.39，区间为 0.25 到 0.60。
文档需求更多来自主动行为
从触发方式看，70.2% 的文档查阅由智能体主动发起，失败驱动的查阅仅占 7.5%。这意味着文档并不只是出错后的补救材料，也可能是智能体在执行任务过程中主动寻找上下文的一部分。不过，材料显示研究还指出文档会滞后于代码，后续具体分析在摘要中并未完整展开，因此不宜据此推导更强的因果关系。
我的判断
这项研究的价值，在于把“文档是否适合智能体”从经验判断推进到了行为观察：仓库维护者需要关注指令文件和工作笔记的可发现性，而不能只维护传统 API 文档。但它的结果主要描述交互关联，不能证明某类文档一定带来更好的代码或测试结果。尤其是文档查阅与即时测试减少的关系，可能受到任务阶段等因素影响。对工程团队而言，较稳妥的做法是把智能体指令、工作上下文和验证流程分开设计，并通过实际任务继续检验它们的作用。