ARTICLE · 977479
FSE 2026 | 谁来告知文档团队?AI智能体如何破坏文档反馈回路
FSE 2026 | 谁来告知文档团队?AI智能体如何破坏文档反馈回路论文地址：https://dl.acm.org/doi/epdf/10.1145/3803437.3806708 🦄软件文档团队依靠开发者行为来识别并修正文档内容中的问题。随着AI编程助手改变开发者获取信息的方式，其对软件文档反馈渠道造成的影响在很大程度上并未得到关注。当开发者减少阅读文档、不再提出问题时，文档团队便失去了发现和修复问题所需的信号。本文运用系统思维，梳理智能体介导的信息获取行为，是如何破坏当前保障文档质量的平衡回路，以及该破坏过程又会如何形成强化回路，随时间推移不断降低文档与代码质量。本文明确了若干可发力点：研究人员可基于这些发力点，针对智能体介导的使用场景，开发质量度量指标与自校正文档系统；系统设计者则可以把智能体的文档使用模式反馈给文档团队。通过这篇立场论文，我们呼吁研究界开展研究，探究由智能体介导的文档使用行为会如何重塑文档本身及其质量。 1 引言 从系统思维的视角，我们识别出由开发者产生、供文档团队使用的两种平衡回路，并以API文档为例展开说明。第一种是直接反馈回路：当开发者发现API文档内容不全或者存在错误时，会通过开发机构维护的问题追踪器、合并请求等渠道上报该问题。第二种为间接回路，源于开发者跨平台的各类行为。开发者在开展其他工作时遇到API文档相关问题，相关诉求便会出现在开展这些工作的对应平台：内容相关问题会出现在问题追踪器与合并请求中，流程相关问题出现在邮件列表，工具相关问题则出现在Stack Overflow。部分开发者还会自行创作博客文章、视频教程等资料，用以补充官方文档，并整理记录文档缺失的信息。 
2 智能体如何影响反馈回路 开发者通过AI智能体获取信息时，便不再直接查阅文档资料、不在论坛发帖提问，也不再自制补充资料。巴克等人发现，程序员常常直接采纳Copilot给出的代码建议，而不去查阅任何文档；对许多受试者而言，Copilot替代了原本需要去Stack Overflow上搜索的环节。后续研究同样表明，开发者将语言模型当作阅读文档与访问外部论坛的更快替代方案。当智能体承接了上述行为后，那些原本会传递给文档团队的提问、投票与问题报告就不再产生。 在系统思维中，强化回路指每一轮循环都会放大上一轮输出结果的回路。当平衡回路失去校正反馈信号时，就会形成这类回路，致使原本能够被修正的问题持续留存于系统之中。这正是文档被智能体调用时所面临的风险。当智能体读取到表述模糊或内容残缺的文档，这些问题就会传导至它生成的代码里。如果后续模型基于这批代码开展训练，相同的文档缺陷就会在下一代模型中复现同类错误。由此形成强化回路，持续拉低代码与文档的质量。 同样的机制还会在组织层面催生强化回路。智能体承接了原本会引发开发者投诉的各类问题，文档团队收到的问题反馈随之变少。投诉量下降会被误判为文档质量达标，进而成为削减文档维护投入的理由。投入缩减进一步造成文档质量恶化，而智能体继续读取这些存在缺陷的文档，且不会做出任何修正。 3 暗示 面向（智能体）系统设计者：更高层级的发力点在于系统内部的信息流结构。Copilot这类代码助手已经能够记录智能体调取了哪些文档页面，以及开发者接受或是拒绝生成结果。倘若开发者频繁拒绝由某一特定页面生成的输出，该现象就说明这份文档存在歧义或错误。将这类行为模式反馈给文档维护人员，就能够搭建一条全新反馈渠道。已有研究表明，向文档创作者展示文档的使用轨迹，有助于文档质量提升。从业者已经开始为适配智能体的文档制定临时经验规则，而来自工具使用过程的系统化反馈能够为这些规则提供实证支撑。但该方案需要智能体工具厂商予以配合，厂商可能会将文档调用与结果拒绝数据视作私有专有数据。同时，暴露这类模式还会带来隐私风险：拒绝信号与开发者的单次编码会话绑定，开发者并不希望这些信息被大范围公开；因此需要明确约定上报内容、接收方以及数据粒度。因此，设计该反馈渠道需要协调工具厂商、开发者与文档维护方三方利益，而目前这三方均缺少协商的动力与可行机制。 面向研究人员：现有的文档质量评估框架衡量可读性、完整性等指标，这类框架的预设对象是从文本中解读信息的人类读者。面向模型调用场景开展文档评估，需要一套全新的质量指标；该指标体系必须考量智能体误读文档的方式，以及由此引发的后续错误。这套评测基础设施能够支撑前文提到的各类干预手段。长远目标是研发一类文档系统，能够依托智能体的调用行为模式感知自身质量劣化，并自动触发修正流程。这类系统将迈向自组织模式：文档本身参与到平衡回路之中，而不再依赖外部主体完成闭环。