文档跟不上代码，是所有开发者工具团队都熟悉的问题。Mintlify 给的数字是：只有 24% 的团队能在产品变更当天把文档改完，22% 要等一个月以上。Autopilot 的产品判断很直接——与其做一个「帮你写文档」的对话框，不如让 agent 常驻在代码和反馈流里，发现变化就开 PR。
它盯的不是日历，是三个信号
官方列出的触发条件有三类：代码合并后读 diff 起草更新；同一个客服问题反复出现时，补一页能回答它的文档；有人在 Slack 里指出文档和实现对不上时，顺着 thread 开 PR。这三种都属于「已经发生的事实」，不需要 agent 猜你下一步要写什么，也比按周生成更新日志更接近真实需求。
连接范围包括代码仓库、Slack、项目跟踪、客服工单和 feature flag。它会给相关同事打 tag 并发邮件，PR 仍然走正常的 review 流程。Mintlify 强调没有自定义 prompt 要维护，agent 从你 review 过的 PR 里学语气，以及团队是「每次发版都更新」还是「有变化就更新」。
收费按 PR，不按 token
定价方式是 outcome-based：每开或更新一个 PR 收 250 credits，运行了但没找到要改的内容不收费。这个设计对买方有利的一面是「没结果不付钱」，不利的一面是 credits 与美元的换算没有直接写在发布页上，PR 量一大就要单独算账。对文档更新频繁的团队，成本会随代码合并次数上升，而不是随人数上升。
它也不是「生成即上线」：所有改动都以 PR 形式出现，必须有人合并。这既是安全阀，也是成本——review 文档 PR 的时间和写文档的时间，未必差很多，尤其是当 agent 对业务背景理解不够时。
适合谁，不适合谁
最适合的是已经把文档托管在 Mintlify、API 或 SDK 变更频繁、并且有固定 review 流程的团队。Autopilot 的价值在于把「文档该改了」从一句提醒变成队列里的一个 diff，减少的是遗漏，不是写作本身。
不太适合三类团队：文档不在 Mintlify 上的（迁移成本可能高于收益）；文档属于合规材料、对外承诺，改动需要法务或产品逐字确认的；以及代码合并频率很低、文档一年改不了几次的。对这些团队，250 credits 一个 PR 的模型很难跑正。
还有一个容易被忽略的风险：agent 写的代码越多，需要同步的文档就越多，Autopilot 的 PR 也会越多。它解决的是「同步」问题，不解决「文档是否值得写」的问题；如果文档结构本身冗余，它只会更快地生产更多需要 review 的文字。
beta 阶段还有两件事没落地：从 reviewer 的修改中学习，以及展示 Autopilot 工作情况的仪表盘。现在评估它，最好自己记录「开了多少 PR、合并多少、平均改多少」，而不是只看发布博客里的演示。