DevRel 当生态系统仍在成形时

Source: Dev.to

在 Midnight 负责开发者关系（DevRel）意味着要从零开始构建生态系统，在产品尚未正式发布、仍在我们脚下成形的阶段就已经开始。

这是一段我职业生涯中最具挑战性且最具启发性的经历之一。这是我第一次在产品正式上线前领导 DevRel，面对真实的用户、真实的激励以及当出现问题时的真实后果。当一切尚未稳定时，关于 DevRel 的每一个假设都会被快速检验。

真正帮助开发者前进的因素会变得非常清晰，而且会非常快地显现。随着我们越来越接近将链路上线，这些模式已经变得不容忽视。

在发布前构建，面向真实的开发者和真实的后果

在2025年初，我写了一篇关于 DevRel at Midnight 作为系统性问题的文章——涉及飞轮、旅程、规模化的脚手架。那种思考方式仍然适用。

改变的是，我们不再抽象地进行设计，而是与真实的开发者、真实的激励以及真实的故障一起运行这些系统。有些假设仍然成立，其他的则迅速崩塌。

本文 不是 对之前策略的替代，而是对现实接触后仍然存活的内容。

作为背景，这里是原始文章：[DevRel in Web3: Building Systems that Scale While the Ecosystem is Still Taking Shape].

1. 参与计划只有在产生方向性进展时才有价值

• 健康的生态系统帮助开发者 前进到某个地方，而不仅仅是参与。
• 任务、奖学金、Discord、活动和内容只有在推动开发者前进时才有价值——从好奇到首次构建，从贡献到真正的所有权。
• 没有进步的活动只是运动，而不是动能。

经验法则： 早期阶段的项目必须教授具体的内容并产生可见的成果。开发者应当离开时比之前了解更多 且 已经构建出昨天没有的东西。

如果一个项目无法回答“接下来会解锁什么？”，它就不是参与策略，而是带有更好品牌包装的营销噪音。

2. 文档、工具和支持正融合为单一的开发者体验

• 开发者感受到你的生态系统是一个 单一的界面，无论背后有多少团队、组织或孤岛。
• 在他们看来，文档、示例、本地工具、错误信息和支持是不可分割的同一体验的一部分。当出现问题时，他们不会去诊断是哪支团队负责——只会决定是否继续前进。

那些让人觉得容易上手的生态系统，是把这些要素设计成 统一的系统，而不是一堆互不关联的交付物。一致性、交接和共享所有权比单个完美组件更重要。

如果开发者感觉顺畅，那是因为组织已经完成了背后的艰苦工作。

3. 早期 DevRel 的可信度来自 一致性，而非规模

• 稳定交付始终胜过大规模发布。
• 每周节奏、可预测的计划、明确的期望以及可见的后续跟进，比任何炫目的宣传更快建立信任。

从外部看可能不够光鲜亮丽，但开发者会注意到，项目按时交付、如描述般运行并持续改进。

早期生态系统本质上是实验。赢得信任的团队并不是避免错误的团队，而是 快速交付、承认失误、修复并持续前进 的团队。动力来源于迭代，而非完美。

结论： 一致性 + 学习每次都胜过打磨。

4. 早期 DevRel 的成功或失败取决于 解除阻碍，而非灵感

• 最有效的 DevRel 团队不一定是最吵的，而是最擅长快速消除摩擦的。
• 在早期阶段，开发者离开并不是因为缺乏动力；而是因为遇到阻碍，而没有人及时清除这些阻碍。

获胜的团队把 DevRel 视为 首先是解除阻碍的职责，其次才是讲故事。

5. 扁平团队在早期生态系统中胜过僵化层级

• 当你从零开始构建生态系统时，实际上没有人知道什么会奏效。
• 进展最快的团队是那些接受来自各方的想法、快速尝试并在没有自负的情况下纠正方向的团队。

我们将 DevRel 视为持续的实验。想法来自团队、构建者以及社区。我们对其进行测试。有些成功，许多则未能实现。我们学习、调整并前进。这不是混乱，而是在不确定性下的有纪律的适应。

去中心化的生态系统需要这种思维方式。最终由社区决定哪些想法会被采纳。DevRel 的角色是 不是去指挥方向，而是创造条件，让好想法浮现、得到测试，并在获得认可后实现规模化。

所有参与者都带来了专业知识。每个人都见过 DevRel 在其他地方做得好或坏。获胜的团队是那些 足够自信倾听、足够谦逊进行转变、且足够有纪律将学习转化为行动 的团队。

---

Source: …

6. 小而精细管理的社区胜过大而缺乏衡量的社区

• 你并不需要更多的开发者。你需要的是对已有开发者的更清晰可见性。

• 早期生态系统的成功在于团队能够回答三个简单的问题：

  1. 谁在取得进展？
  2. 谁卡住了？
  3. 为什么？

• 仅有洞察还不够，关键在于接下来你做了什么。

强大的社区会把反馈转化为行动。当建设者遇到阻力时进行干预， 当动力停滞时开辟新路径，并为开发者提供明确的理由继续构建并深化所有权。

留存不是来源于规模，而是来源于关注。一个拥有紧密反馈回路、清晰进阶路径和可见跟进的小群体，始终会比信号消失在浩瀚空间的大社区迭代得更快。

7. DevRel 正在成为 操作系统，而不是职位名称

现在最有影响力的 DevRel 工作体现在 系统 中，而不是个人。可扩展的不是魅力或英雄主义，而是 工作流、标准、飞轮、工具和反馈回路，这些每周都在持续运行。

(原文在此截断；核心思想是 DevRel 应被视为一种基础设施层，超越任何单个人而持久存在。)

加入午夜对话

我们很期待您加入这个早期生态系统。分享您的反馈和想法——加入 Discord，提交 issue，或 fork 一个仓库并展示您构建的内容。

对同行 DevRel 构建者的邀请

如果您在 web3 生态系统中从事 DevRel，尤其是早期项目，我很想与您联系。
如果您在平台仍在成形时进行 DevRel 构建，我很想与您交流经验。

思考问题

• 哪些东西比预期更快崩溃？
• 哪些在真实使用中表现稳健？
• 您完全停止了哪些做法？

— lolocoding