Mintlify Autopilot是什么：代码一合并就自动起草文档PR，按PR收250积分，Pro和企业版能接哪些来源

写过技术文档的人都知道，文档落后于代码几乎是常态。接口加了个参数，CLI多了个flag，代码当天就合了，文档要等到有用户在群里问「这个参数文档里怎么没有」才有人想起来补。

做文档托管的Mintlify在2026年10月20日发了一个叫Autopilot的功能，想解决的就是这件事。它现在是测试版，只开给Pro和Enterprise（企业版）用户。

它是什么

官方的定义是「一个常驻的智能体」：读你的代码和代码周边的上下文，发现有变化时起草文档更新，然后开一个Pull Request让你审。

注意开PR这一步。Autopilot不会直接把改动发布到线上文档。官方FAQ说得很清楚：它开PR、在PR里标记团队成员去审核、再给审核人发邮件，只要团队里没人合并，什么都不会上线。

什么时候会触发

官方举了三类典型情况：

触发场景	Autopilot做什么
代码合并	读diff，起草对应的文档更新
同一个客服问题反复出现	写一篇专门回答这个问题的页面，并持续维护
有人在Slack里指出文档和产品不一致	接住那个讨论串，开PR修正

第二条我觉得最有意思。很多团队的FAQ页面是客服攒了半年才想起来整理的，如果它能从工单里自动发现「这个问题已经被问了二十次」，对支持团队是实打实的减负。不过这依赖你把工单系统接进来，下面会说到套餐限制。

能接哪些来源，Pro和企业版不一样

官方列出的来源有：代码仓库、Slack、项目管理工具、客服工单、功能开关（feature flags）。

但FAQ里有一句限制很重要：Pro套餐只能接GitHub和Slack，企业版才能接全部集成。所以如果你是Pro用户，「从工单里发现高频问题」这条暂时用不上，能用的是代码合并触发和Slack触发。

怎么收费

Mintlify这次用的是按结果计费：

• Autopilot每开一个或更新一个PR，扣250积分。
• 跑了一圈没发现需要改的，不收费。

这比按调用次数收费更好预估。你大概知道团队每周合并多少个会影响文档的PR，就能算出一周大概消耗多少积分。不过每个套餐包含多少积分、超出后怎么买，官方博文没有写在正文里，需要去看它的积分说明页面。

有个小坑可以提前想到：同一个改动如果Autopilot开了PR、你没合，它后来又更新了这个PR，按规则是「开或更新」都算，可能会被扣两次。我没有实测，建议开通后第一周盯一下积分消耗。

和Mintlify原来的Automations有什么区别

Mintlify之前已经有一个叫Automations的功能，也能自动做一些文档工作。区别在于：

	Automations	Autopilot
配置方式	每个工作流自己设置，自己维护提示词	连好来源后打开开关，由它判断什么需要改
能否学习团队习惯	靠你改提示词	有记忆，会从你审核过的PR里学语气、更新节奏
调整行为	改配置	像跟Mintlify智能体对话一样直接告诉它

两者可以同时开。官方建议大多数团队保留翻译类的Automations，关掉其他的，让Autopilot接手。原因很好理解：两套自动化同时盯着同一份文档，很容易一个改完另一个又改一遍。

开通步骤

按官方说明：

1. 打开Mintlify后台的Autopilot卡片。
2. 打开卡片上的开关。
3. 连接代码仓库，以及你想让它监控的其他来源（Pro只有GitHub和Slack）。
4. 审核它开出来的第一批PR。

第4步别敷衍。官方说它会从你合并或关闭的每个PR里自我调整，前几个PR你怎么处理，基本决定了它以后的风格。语气不对就在PR里改了再合，明显不该改的直接关掉，别都图省事一键合并。

适合谁，不适合谁

适合：已经用Mintlify托管文档、代码迭代快、文档维护人手不够的团队，尤其是API产品和开发者工具。

不太适合：文档需要法务或合规逐字审核的行业；或者团队本身就没人看PR，Autopilot开出的PR只会越堆越多。还有一种情况，代码仓库里有不想让第三方读到的内容，接之前先确认权限范围。

官方说接下来会让Autopilot学习审核人合并前做的修改，并加一个仪表盘显示它在做什么。10月27日太平洋时间上午10点（新加坡时间10月28日凌晨1点）还有一场直播演示。

值不值，可以先算一笔账

官方没给积分和美元的换算，我就不替它编数字了，只给一个估算思路。

假设你们团队每周合并40个PR，其中真正影响用户可见行为、需要改文档的大约8个。如果Autopilot每个都开一个文档PR，一周就是8×250=2000积分。再加上Slack里有人指出文档问题、它顺手修的几次，按每周2500积分左右估。拿这个数去对照你套餐里每月包含的积分，就知道够不够用、超出部分大概要多花多少。

另一边算省下的人力：一个文档PR，工程师自己写，加上来回确认，少说半小时。8个就是四个小时左右。如果Autopilot起草的质量能做到「改几个字就能合」，这笔账大概率是划算的；如果每个PR都要重写一半，那就只是把写文档变成了审文档。

和写代码的AI工具是什么关系

现在不少团队用Copilot、Claude Code、Cursor这类工具写代码，代码产出更快，文档缺口反而更大。Mintlify博文开头就引用了它自己的2026年知识报告：只有24%的团队能在产品变化当天更新文档，22%要等一个月甚至更久。Autopilot可以理解为站在合并之后的那一环，代码工具管写，它管把变化同步到文档。两者不冲突，但都需要人在PR这一关把住质量。

其他选择

不用Mintlify的话，开源方案Docusaurus、Read the Docs，以及GitBook都是常见的文档托管方式，代码托管和文档联动可以参考GitHub和GitHub Docs的做法。团队沟通常用Slack。站内相关：GitHub AI Scan for PR、GitHub智能体自动修复、Claude Code并行会话。更多见开发文档分类、团队知识库分类和AI编程分类。

来源与核查日期

• Mintlify Blog：Autopilot: Always-on agent for self-updating docs（2026-10-20）

核查日期：2026-10-20（新加坡时间）。测试版功能和计费可能调整，以Mintlify官方文档为准。