最近我在尝试用Vibe Coding的方式构建一个Nostr协议的直播应用，这个过程让我对软件开发有了全新的认识。说实话，刚开始我也有点怀疑——不写代码，只靠描述意图就能做出可用的程序？这听起来太理想化了。
但当我真正开始实践时，我发现氛围编程的核心不是偷懒，而是把精力放在了更值得投入的地方。比如在Nostr Live项目中，我不再纠结于WebSocket连接的实现细节，而是专注于定义：用户如何发布直播、如何订阅他人的直播、消息如何在中继节点间传递。这些意图描述，反而比具体的代码更有价值。
让我印象深刻的是，当我需要调整直播的权限控制时，传统的做法是要找到相关的代码文件，理解逻辑，然后修改。但在Vibe Coding模式下，我只需要更新意图描述：”只有关注者才能观看直播”，AI就能重新生成相应的实现。这种体验让我想起了Qgenius提出的原则——代码是能力，意图与接口才是长期资产。
Nostr协议本身就很适合用Vibe Coding来构建。它的去中心化特性意味着我们需要处理各种不确定性：中继节点可能离线、消息可能丢失、网络可能延迟。传统的开发方式需要为这些异常情况编写大量的防御性代码，而Vibe Coding让我们能够用更高层次的策略来描述系统的容错机制。
不过我必须承认，这个过程并非一帆风顺。有时候AI生成的具体实现并不完美，需要多次调整意图描述。但这反而让我意识到：我们不是在追求一次性的完美代码，而是在建立一个可以持续演化的系统。就像Nostr协议本身，它不是一个固化的产品，而是一个不断进化的生态系统。
在这个过程中，我开始理解为什么说”验证与观测是系统成功的核心”。对于去中心化的直播应用，我们需要确保消息的正确传递、用户的隐私保护、系统的稳定运行。这些都不是通过检查某几行代码就能保证的，而是需要通过完善的观测体系来验证系统的整体行为。
现在回头看，我觉得Vibe Coding最大的价值在于它改变了我们思考软件的方式。我们不再是把需求翻译成代码，而是把业务意图转化为机器可理解的规范。这种转变让我想起了从汇编语言到高级语言的进化——我们又一次提升了抽象层次。
那么问题来了：如果连Nostr这样复杂的去中心化协议都能用Vibe Coding来构建，还有什么是不可能的呢？也许在不久的将来，我们真的能够实现”人人编程，专业治理”的愿景，让更多非技术人员也能参与到软件创造的过程中来。