6.3 API文档与开源社区的“另类尽调”

2022年，一家硅谷当红的API初创公司在Hacker News上被一个开发者发帖吐槽。帖子的标题叫《你们家文档是不是实习生写的》。发帖人在集成这家公司的支付API时，发现文档里有三个不同版本的接口说明互相矛盾，SDK的示例代码跑不通，报错信息只有一个孤零零的“Error 500”没有任何payload。他花了整整两天时间反复调试，最后发现是文档里有一行必填参数被错误地标注成了可选。

这条帖子在Hacker News首页挂了整整一天，下面的评论区变成了开发者们集体倒苦水的现场。有人贴出了另一家竞品的API文档链接，说“你看看人家怎么写的，每个接口都有curl示例，每个错误码都有详细的故障排查步骤”。两周之后，这家被吐槽的公司的CTO亲自在帖子里回复，说已经重组了技术文档团队。

但有意思的不是这条帖子本身。有意思的是这家公司当时的市值在那两周里毫无变化。市场根本不关心API文档写得好不好。基金经理不会去读API文档，券商分析师不会把SDK的示例代码跑一遍，投资决策依赖的数据源里完全没有“开发者体验”这个维度。而这些你每天被折磨得死去活来的东西，恰恰是你能比市场更早发现一家公司质量好坏的地方。

文档是第一印象：一本破用户手册能暴露一家公司的全部工程管理能力

你选一个开源组件的时候会怎么做？你不会先看它的架构设计文档，也不会先去研究它的融资背景。你打开它的文档首页，点进Quick Start指南，复制粘贴第一段示例代码，跑一下。跑通了，继续往下翻。跑不通，关掉页面换下一个。

你手里这套判断标准，用在上市公司尽调上，比你花三天读一份招股书还有用。

一个技术公司怎么对待它的文档，就是它怎么对待它的客户。API文档里的每一个参数说明、每一段示例代码、每一个错误码的解释，都是这家公司的工程师和外部开发者之间唯一的界面。如果这个界面是粗糙的、敷衍的、长期不更新的，那说明这家公司内部至少存在下面三种问题中的一种。第一种，它的工程团队严重缺人，连文档都顾不上维护，那它的产品迭代速度大概率也快不到哪里去。第二种，它的管理层认为文档不重要，只要销售能把客户签进来，文档差一点无所谓——这种思路在短期冲合同额的时候是有效的，但长期看，每一个因为文档差而流失的开发者，都是它未来生态里的负口碑节点。第三种，也是最致命的一种：它的产品架构本身就不稳定，接口三天两头在变，文档团队根本跟不上工程团队的修改节奏，文档和实际产品行为之间已经出现了系统性的不一致。

这三种问题，你作为一个每天调用各种SDK的开发者，在五分钟之内就能感知到。基金经理可能持有一家公司的股票好几年都没有读过它的API文档。他的尽调清单里没有这一项，但你的有。

这个信息差可以转化为投资决策吗？当然可以。但不是让你一看到文档差就直接做空——那太简单粗暴了。正确的方式是把文档质量作为一个前置筛选条件。在你考虑买入任何一家以开发者为主要客户的技术公司之前，先去跑一遍它的Quick Start，读一遍它核心API的参考文档。如果这个过程让你产生了“这家公司的工程管理可能有问题”的判断，那就把这条判断写进你的投资日志里，给它一个权重。如果后续其他信号——比如季度财报里客户留存率下降、销售费用率异常攀升、或者你在Stack Overflow上看到大量未解决的技术问题——和你的文档判断形成了交叉验证，那你就有足够的理由把这家公司从候选池里剔除，或者对你已经持有的仓位做减仓处理。

你不需要文档做到满分才能投。你只需要文档做到能让你跑通Quick Start、能让你在不求助客服的情况下独立完成一次完整的功能集成。这个标准，已经可以淘汰掉相当一部分看起来估值很高但实际上工程地基在沙子上面的公司。

开源社区的活跃度，骗外行可以，骗你不行

2018年，一家国内的AI芯片创业公司在GitHub上开源了它的推理框架。发布第一天就冲上了GitHub Trending榜首，不到一周攒了超过一万个Star。如果你是做技术选型的工程师，看到这个数据可能会犹豫一下，但如果你看一眼它的Commit记录和Issue区的真实互动，你会立刻发现这张Star榜的成色不太对。

一万个Star，但Contributor除了这家公司自己的员工之外几乎为零。所有PR都是内部开发者在互相Merge。Issue区确实有一些外部用户提的使用问题，但回复者永远是那两三个挂着公司badge的人，而且回复周期普遍超过一周，回复质量也参差不齐——有些问题被简单地标记为“by design”就关掉了，没有任何解释和讨论。

这种项目在开源圈有一个精确的术语，叫“假开源”。它的Star数量是市场活动的一部分，和产品的技术质量、社区的健康发展、以及生态的第三方参与程度没有因果关系。它只是一家公司把私有代码仓库设置成了公开可见，然后把GitHub当成另一个发布渠道。真正的开源生态，必须有第三方贡献者持续提交有质量的PR，必须有不同公司的开发者在Issue区互相回答彼此的问题，必须有Fork出去的衍生项目在被独立维护。这些指标没有一个是可以用营销预算买来的，它们只能靠产品本身对开发者的真实价值一点一点地挣。

你作为每天在GitHub上逛的工程师，对这两种状态的区分几乎是一种肌肉记忆。你看到一个项目，扫一眼它的Contributor列表的域名分布，看一眼它的Issue响应模式，翻一下它的PR合并记录里有多少来自非本公司员工的提交，你就能大概判断出这是一个真正有生命力的开源生态，还是一个公司市场部运营的展示页面。这个判断力，放到投资上，就是你的独家尽调能力。

如果你看到一家以开源为核心战略的技术公司，它的核心开源项目的Contributor来源高度单一，第三方PR的合并率极低，Issue区大量外部提问被长期搁置，那么它声称的“开放生态”可能只是一个营销概念。这不意味着它一定是一个烂公司，但它一定不是一个在按照开放生态的逻辑创造价值。它的价值创造方式可能更接近传统的专有软件公司——靠销售团队签大客户，靠锁定效应留住客户，开源只是获客漏斗最顶端的一层低成本广告。你按照这个逻辑去定价它，大概率比市场上那些看到GitHub Star数量就激动的投资者要准确得多。

去Stack Overflow和V2EX蹲点：真实开发者的抱怨，是最干净的产品信号

你在排查一个技术问题的时候，有没有过这样的经历：官方文档给不出答案，GitHub Issue里没人回复，最后你在Stack Overflow上找到了一个三年前的提问，底下有一个只有两个赞的回答，那个回答精准地解决了你的问题。你对这家公司的好感度在那个瞬间涨了还是跌了？你没有感觉。但你对它的产品可靠性的信任度，在那个瞬间发生了某种无法量化的微妙偏移。

你在Stack Overflow、V2EX、Reddit的r/programming、甚至知乎的技术话题下面看到的真实开发者讨论，是这个世界上最干净的尽调信息来源。没有一家公司能控制这些平台上的内容。PR团队可以写新闻稿，市场部可以运营公众号，开发者关系团队可以在GitHub上Star自己的仓库，但他们没有办法阻止一个被他们SDK折磨了三天的开发者在Stack Overflow上发帖抱怨，也没有办法阻止另一个用了竞品之后发现体验好很多的开发者在回复里贴上对比链接。

你在这些平台上蹲点的时候，需要注意的不是那些极端的赞美或者极端的辱骂——那些通常是个别用户的情绪化反应，样本量太小，没什么参考价值。你需要关注的是重复出现的模式。如果十个提问里有七八个都在问同一个问题，比如某个错误码的文档缺失、某个平台的兼容性迟迟没有支持、某个版本的迁移过程极其痛苦，那这个问题一定不是个例。它反映了这家公司在某个技术决策或者工程投入上的系统性短板，而这个短板迟早会体现在客户流失率和销售成本上。

你常年泡在这些论坛里，这些模式对你来说是潜移默化的背景信息。你平时可能不会刻意去总结它们，但当你需要做一笔投资决策的时候，你只需要花一个下午，把这家公司相关的技术标签下的最近一百条帖子扫一遍。你能读到的信息密度，远远超过任何一份付费的尽调报告。那些付费报告是卖方分析师写的，而卖方分析师不用集成这家公司的SDK。你在用。

这一节的最后，我给你一个能直接用的三件套尽调流程。下次你看中一家以技术为核心竞争力、以开发者为主要客户群体的上市公司，在你的季度评审日或者买入决策之前，花两个小时做下面三件事：把它的Quick Start跑通，记录下从克隆仓库到第一次成功调用API的时间，以及过程中遇到的所有阻碍；打开它的核心开源仓库，统计过去三个月里合并的非本公司员工PR数量，以及平均Issue首次响应时长；在Stack Overflow和V2EX上搜索这家公司的产品名和技术栈关键词，浏览最近五十条相关内容，看有没有反复出现的技术投诉模式。

这三个步骤做完，你对这家公司的了解已经超过了市场上绝大多数持有它股票的人。你不一定每次都能据此做出正确的买卖决策，但你能避免被那些只有Star数量和营销文章撑起来的“技术光环”所迷惑。你能看到技术光环底下真正的工程地基有多深。而地基的深度，最终决定了一家技术公司能在这个市场上站多久。