Mintlify 上线 Autopilot：文档落后于代码时，agent 自己提 PR 来补

Mintlify 10 月 20 日发布 Autopilot，目前在 Pro 与 Enterprise 计划的 beta 中。它是一个常驻 agent：读取代码仓库，以及 Slack、项目跟踪工具、支持工单和 feature flag 等周边系统，在检测到变化时起草文档更新并开 pull request，然后 @ 相关同事并发邮件提醒。触发场景包括代码合并、同一个支持问题反复出现、以及有人在 Slack 里指出文档与实际不符。它不会直接发布文档，仍需人工合并 PR；Pro 版接 GitHub 与 Slack，更广的集成在 Enterprise。

发布内容

Mintlify 10 月 20 日发布 Autopilot，目前在 Pro 与 Enterprise 计划内以 beta 形式提供。官方给它的定位是「常驻 agent」：读取代码与代码周围的上下文，在内容发生变化时起草文档更新，并开一个 pull request 等团队审阅。

三类触发

代码合并：读取 diff，起草对应的文档改动；
同一个支持问题反复出现：写出能回答它的页面并持续维护；
有人在 Slack 里指出文档与实际不符：接住线程，直接开 PR。

开完 PR 后，Autopilot 会 @ 相关同事并发邮件提醒，把审阅责任落到具体的人，而不是丢进一个没人看的队列。

边界与计费

它不会自己发布文档，最终仍要人合并 PR。Pro 版接 GitHub 与 Slack，更广的集成范围在 Enterprise。Autopilot 的更新会消耗 credits，超出套餐要额外付费；没有找到需要更新的内容时，这次运行不收费。Pro 包含不限数量的编辑席位和每月一定的 credits 额度。

为什么现在做

Mintlify 引用 2026 年的一份知识管理报告：只有 24% 的团队能在产品变更当天把内容更新进文档，22% 要等一个月以上。当代码越来越多由 agent 产出，合并速度加快，文档缺口只会更大——这也是「让 agent 写文档」比「让 agent 写代码」更早落地的原因：判断标准清楚，改错了也不至于让服务宕机。

判断

这类工具最大的风险不是写错，而是制造大量低价值 PR，把审阅成本转移给最忙的人。上线前应该先定触发阈值：哪些目录的改动必须写文档、哪些只是内部重构不需要；否则 agent 越勤奋，团队越不愿意看。

自动写文档不难，难的是决定哪些改动根本不值得写。