每月2000万开发者在使用Mintlify查阅文档，但99%的人不知道，这些文档已经不只是写给人看的了。
如果你的产品文档还在用「方便开发者阅读」作为唯一标准，你可能正在用书信时代的逻辑应对电报时代的竞争。Anthropic、Microsoft、Coinbase的工程师们早已把文档当作训练AI Agent的数据源，而非给人类看的说明书。
Han Zhang和Honbe Wang花了一年半时间，经历八次方向调整，才意识到这个显而易见的真相。
Han十一岁拿到第一台MacBook Pro。没有老师，没有课程，他在YouTube视频和「糟糕透顶的文档」里自学编程。2023年底，当他和合伙人Honbe决定为开发者做点什么时，第一反应不是文档——那个市场看起来太拥挤了，到处都是成熟产品。
他们尝试了用AI自动注释代码，尝试了把静态内容关联到代码库，还尝试了其他六个「糟糕到不好意思拿出来讲」的想法。每一个方向都围绕着同一个执念：让开发者学得更快，构建得更顺。但每次拿着原型去找用户，得到的反应都是「下周再聊」「我们考虑一下」「发个账单给我」——然后账单石沉大海。
20美元都没人愿意付。
转折发生在2024年初的某个周末。
Han和Honbe决定只给自己两天时间，验证最后一个想法：做一个他们自己想用的文档平台。周六开工，周日上线。他们把原型拿给室友的创业公司Hyperbeam看——那是一家刚转型做API产品的团队，正头疼怎么给开发者写清楚接口文档。
「嘿，你们的文档现在好看多了，在Mintlify上。去看看？」
对方的回答不是「下周聊」，而是「能现在就开始用吗？」
Han记得当时对方催得很急：「我现在就想配置，把你们Cloudflare的DNS访问权限给我。」他当场接入，十分钟搞定。Hyperbeam成了第一个付费客户。
方法论拆解：从周末原型到月活2000万的三个关键决策
决策一：用「不可扩展」的方式服务前100个客户
Mintlify早期没有自动化迁移工具，没有AI辅助编辑，甚至没有像样的客服系统。Han和Honbe做的事情听起来完全违背创业常识：他们手动帮每个客户迁移文档，逐行检查语法错误，重新调整内容结构。
这件事持续了大半年。当他们拿着这个困境去问YC创始人Paul Graham，能不能想点办法规模化，Paul的回答很直接：「你们现在做的事，就是你们以后要一直做的事。接受它。」
Han当时觉得这简直是噩梦。但正是这些「做不了规模」的细节，让早期客户产生了超出预期的好感。开发者们发现，Mintlify不只是提供工具，还真的在乎他们的文档质量——这在SaaS工具里几乎见不到。
后来团队扩张了，他们开发了辅助工具，AI也加入了工作流。但那种「愿意为用户多走一步」的基因留了下来。直到今天，如果有客户在周六凌晨两点发消息到Slack社区，依然会在几分钟内得到回复。Anthropic的工程师曾经专门问他们：「你们是不是设置了值班制度？」
没有。只是所有人都在线。
决策二：把失败当作校准器，而非打击
一年半，八次方向调整。这听起来像是创业失败的典型症状，但Han的理解完全相反。
「失败教会我的，是识别什么东西真的有效。」当你见过太多「下周再聊」的敷衍，当你发过太多没人付款的账单，当某个产品让用户在十分钟内主动要求接入时，那种反差会让你无法忽视。
大多数创始人把失败当作需要避免的耻辱，Han把它当作提高判断力的训练。每一次被拒绝，都是在收集数据：这个方向不成立，那个需求不够强。等到真正有效的想法出现时，他不需要说服自己「这次应该可以吧」——答案会主动跳出来。
这种心态后来延续到了产品迭代里。Mintlify在2025年推出了自动更新文档的功能，但在此之前，他们已经尝试了好几个月。团队不断调整，直到Claude Opus 4.5发布，模型能力终于匹配上了他们的产品设想。如果他们在早期就因为「AI还不够好」而放弃，就不会在正确的时机抓住机会。
决策三：重新定义客户是谁
2024年初，Mintlify的目标用户是「写代码的工程师」。到了2025年，这个定义已经不够用了。
现在使用Mintlify的人里，有客服团队用它管理内部知识库，有HR部门用它整理医保政策，有AI研究员用它训练代码助手。Han自己的公司也把所有内部文档迁移到了Mintlify，通过Slack里的AI Bot随时查询和更新内容。
更大的变化是：文档的「读者」不再只是人类。
AI Agent成了Mintlify的隐形用户。这些Agent需要准确、结构化、实时更新的内容作为上下文，才能正确回答问题或生成代码。如果文档里的定价信息过期了，依赖这些文档训练的客服Agent就会给出错误答案——而且会以成千上万次的规模出错。
Han发现，企业愿意把核心代码库和内部文档交给LLM处理的速度，比他预想的快得多。两年前，这种事想都不敢想。现在，信任环境、模型能力和业务需求同时成熟了，自动更新文档从「科幻概念」变成了「必需品」。
但这不是重点。
重点是Mintlify没有为了迎合趋势去追逐AI功能，而是始终在解决同一个问题：让知识更容易被使用。只是「使用者」的定义变了——从人类扩展到了Agent，从外部开发者扩展到了内部团队。
产品的本质没变，但服务的对象扩大了十倍。
理论升华
想想你上次买电钻的场景。你不是在买电钻本身，你是在买墙上那个洞。文档就是那个电钻，而开发者、AI Agent、客服团队需要的，是「理解产品如何工作」这个洞。
Mintlify最初只想卖更好的电钻，后来发现客户真正需要的是各种规格的洞——有的要给人类看，有的要喂给AI，有的要实时更新。工具可以变，但需求始终存在。
这也是为什么Han不担心「AI会不会让文档消失」。书籍没有因为视频而消失，文档也不会因为AI而消亡。只是阅读文档的「人」，有90%变成了Agent而已。
局限性提醒
Mintlify的策略有一个前提：你的客户足够在乎文档质量。如果你的产品复杂到需要详细说明，如果你的用户会因为文档不清楚而流失，这套打法才有效。
对于那些产品简单到不需要文档的公司，或者根本不打算认真对待开发者体验的团队，Mintlify解决的问题可能根本不存在。这不是贬低，只是承认：不是所有生意都需要好文档。
余韵收尾
Han记得他十一岁时对着糟糕的文档一边骂一边学代码的样子。现在每个月有2000万人在使用Mintlify支持的文档，其中一定有无数个「十一岁的Han」。
他们大概也不知道，自己看的那些清晰、准确、随时更新的文档，背后有多少是AI Agent在维护。