夜雨聆风出海兵器谱 · 第 15 篇
「DevRel」这个词，我发现不同的人对它的理解差距很大。
有人觉得 DevRel 就是写技术文档、更新 changelog。有人觉得是出去参加技术大会、发名片。还有人把它和市场营销混在一起，觉得就是给开发者版本的广告。
这三种理解都没错，但都没到本质。
devrel-playbook 里有一条定义我比较认同：DevRel 的核心任务，是让开发者完成从「听说过」→「用起来了」→「推荐给别人」这条路径的转化。
写文档、参加会议、做内容，都是这个路径上的具体动作，但不是目的本身。
三个阶段，三种任务
第一阶段：意识（Awareness）
开发者还不知道你的产品。这个阶段的任务是出现在他们的信息流里——技术博客、Hacker News、GitHub Trending、技术大会演讲。
但这里有一个陷阱：出现得频繁，不等于被记住。开发者的信息密度很高，如果你的内容里没有具体的技术洞察或真实案例，它和其他 100 条内容没有区别。
第二阶段：采用（Adoption）
开发者知道了你的产品，但还没在用。这个阶段的任务是降低第一次使用的门槛。
两个指标最重要：Time to first API call（第一次成功调用 API 需要多长时间） 和 第一次使用的成功率。
devrel-playbook 里的目标是把 Time to first API call 做到 5 分钟以内。超过 10 分钟，相当一部分开发者会在这里放弃，不会继续深入。
这个指标由文档质量、示例代码可用性、快速开始教程的清晰度共同决定。
第三阶段：倡导（Advocacy）
开发者在用，而且开始推荐给别人。这是 DevRel 想要触达的终态。
倡导行为的触发点有一个规律：不是产品「好用」，而是产品在某个具体场景里超出了他的预期。让他觉得「这个东西值得发一条推文给关注我的人看」。
这个体验不会自动发生，需要设计——在产品里找到最容易触发惊喜的功能路径，然后在文档和教程里，主动把用户引导到那个路径上去。
社区不是聊天工具，是产品延伸
做 DevRel 的团队往往把 Discord 当成客服频道——用户来了提问，我们去回答。
但 Discord 对开发者工具有一个更大的价值：它是产品里看不到的使用手册。
当开发者遇到问题，他们会先去 Discord 搜索有没有人问过同样的问题。如果搜到了一条清晰的历史回答，他一分钟就解决了问题，不需要开工单、不需要等支持。
这意味着：在 Discord 里认真回答的每一条问题，都是在创造一个永久有效的解决方案。一年后还有人会找到它。
这种积累，是比发公告更有价值的内容资产。
DevRel 的指标不该只看参与度
很多 DevRel 报告给管理层的指标是：Discord 成员数、活跃用户数、发帖量。
这些都是活动指标，不是结果指标。
devrel-playbook 里建议关注的是：
- 采用率
：看了文档之后，有多少人完成了第一次 API 调用？ - 留存开发者比率
：第一周用了你 API 的开发者，第四周还在用的比例是多少？ - 来自社区的产品反馈
：每月有多少条有价值的功能建议或 bug 报告来自社区？
这三个指标才能说明 DevRel 是否真的在推动业务，而不只是在维持一个活跃的聊天室。
这个工具免费开源，直接用： 🔗 https://gingiris.tools/skills/
如果你在做竞品分析，也可以试试： 🔗 https://www.analook.com
本文配套 AI Agent Skill
把这篇文章的方法论直接装进你的 AI agent，一条命令安装，即刻可用：
npx skills add Gingiris-1031/devrel-playbook更多出海增长 Skill：https://gingiris.tools/skills/