有血有肉

Source: Dev.to

为什么我要写这篇

给自己的一个提醒：停止解释技术，开始用技术构建。我是个相当幸运的人。好奇心让我在一生中经历了许多不可思议的情境。我学会了语言，住过有趣的地方，大约六年前，我决定想了解互联网是如何运作的。这份好奇心转化为我在 DevOps、云和 Kubernetes 领域的职业，我对此感到非常自豪。

如今，作为一名 DevRel，好奇心驱动着我的一切工作。这个角色在不同公司之间乃至每周都有很大差异。某一周，我在为博客文章或会议演讲准备新的用例；下一周，我则与同事合作进行网络研讨会和内容项目，或在营销、产品和客户成功之间搭建桥梁。这是一份好奇的人能够茁壮成长的工作，我的经历也是如此。

解释与构建之间的鸿沟

至少对我而言，这有一个缺点。我的职业生涯没有经历一个漫长、明确的“开发者阶段”。我没有花多年时间从零开始构建产品、发布、破坏并承担后果。这并不是在技术领域拥有有意义职业的前提，但它是我日益意识到的一个缺口。

随着我对基础设施、Kubernetes 和云原生工具的好奇心加深，我也更加意识到自己视角的局限性。我可以解释系统、模式和权衡，但并不总是亲身感受它们。我离工作很近，却不总是身处其中。

当我在演讲中需要商业案例时，这个缺口最为明显。当我探索新的 Kubernetes 架构或有趣的开发者工具时，我会回归同样安全的演示——待办事项列表、投票应用、习惯追踪器。它们熟悉、风险低、易于解释，但也缺乏趣味，过于理论化。

MetalBear 和 mirrord

我在 MetalBear 工作，MetalBear 是 mirrord 背后的公司，这是一款从根本上改变开发者使用 Kubernetes 方式的工具。它让本地进程能够与远程 Kubernetes 环境中的真实系统、真实流量和真实依赖进行交互——无需容器化或触发 CI/CD。然而，我经常使用那些老旧的示例应用来演示它。给一个简单的轮询应用添加暗黑模式并不能体现出这款为复杂、高风险环境设计的工具的价值。

有时，这让我感觉自己不像是实践者，倒像是历史导游，被动地解释事物是如何运作的、他人是如何使用它们的，以及可以构建什么——却没有积极塑造当下的实际情况。说实话，谁愿意成为上周发生的事的历史学家，而不是帮助影响接下来会发生的事情呢？

行动倾向

我现在的目标很简单：成为一名具有行动倾向的 DevRel。如今信息、资源和 AI 工具的数量惊人，创意到可运行项目的距离前所未有地缩短。反馈回路更紧凑，工具更完善，尝试和失败的成本也比以往更低。

我想停止仅仅以评论者的身份谈论 Kubernetes 和云原生工具，而是以身有实干的姿态参与其中。不只是作为开发者，而是作为一个负责识别真实问题、阐述解决方案、挑选合适工具，并从构思到交付全程跟进的人。我想构建的项目不仅能在会议演讲中站得住脚，更能经受真实用户、真实约束和真实权衡的考验。

其中一些项目会失败，一些会停滞，一些可能意外成功。没关系。关键不是成功，而是参与、真正投入实干，并在日常谈论的工具中，去追求对某人真正有用、且可能实现的事物。

公开构建

要完全站在开发者或产品负责人的角度并不容易，这正是关键所在。我不会仅仅因为会议的需求就把某个工具或技术栈硬塞进项目。我会从制作者的视角出发，为每个项目决定最合适的前进方式。

我并不在乎这会给我贴上什么标签——开发者、开发者关系、DevOps 工程师。那些都不重要。重要的是选择行动，构建对某些人有意义的东西，在想法尚未完全打磨之前就把它们推向世界，并通过面对现实而非被保护来学习。

公开构建是实现这一点最诚实的方式。它提升了风险，增强了我对真实同理心的能力，并迫使我保持清晰。如果我想更好地理解开发者，最好的办法不是提供更多解释，而是共享经验。

行动号召

我计划公开且定期分享这段旅程：我在构建的东西、哪些有效、哪些无效，以及我在过程中学到的东西。如果这与你产生共鸣，我真诚地希望听到你的声音。如果你也感受到想要多做少说的冲动，请告诉我你正在考虑构建什么。你想验证什么，以及希望为世界带来什么价值？

祝大家2026年快乐！