vibecoder.date

我坐在这里，弯腰驼背地靠着一台发热的笔记本。工程开发确实令人筋疲力尽——尤其是当真正投入其中的时候。我从未体验过感受式编程的魔力。虽然它的能力令我惊叹，一次又一次地给我惊喜和欣喜，但我从未感受到那种氛围感。我在规划、思考规范、约束，只是高于代码一层或两层的抽象思维。 我突然意识到，感受式编程之所以流行起来，是因为终于可以直接说出期望的结果——比如"给我做个应用来组织我的日程"——然后通过对话就能实现。虽然有局限，但这本身就很神奇了。 作为在技术领域多个部门呆过的人——支持、QA、后端等——这些对我来说从未是魔法。或者说，魔法在于看到它如何工作，而非它确实能工作。 这一开始只是朋友间的玩笑。"要不咱们做个程序员版的 Tinder？"为什么不呢。我在深夜一时兴起买了这个域名。大家都觉得很搞笑。它就这么闲置了一段时间。 说实话，我从事开发已经很久了。这很孤独。没法用正常话题开启对话说"对了，昨天我在想做个 Python 库来通过遍历执行路径自动生成单元测试"。你可以说，但即使对技术人来说也感觉像噪音。工程开发正逐渐变得愤世嫉俗。 但我一直在想这个概念。这个笑话很有趣，它驱动着我。 如果能在 Cursor 里聊天呢？或者就是连接呢？约会的部分会是焦点，因为它很有趣。顺其自然。 我开始构建。没有特别的工程专业知识或美学方向，除了"我在感受式编程"。当然一些最佳实践还是混进去了——反复检查、审查工作、考虑后端提供商——但即便如此，付诸行动的时间也少得多。我看到了这种转变。虽然企业还没跟上，但在 Twitter 社区里。人们在做曾经我们认为太耗时而无关紧要的项目。 甚至这篇博客也是感受式写的。我通常避免在非纯功能性的写作中使用 AI，但...这就是人们谈论的氛围感。混乱的输入，结构化的输出。复杂的问题，软件解决方案，反复迭代，逐步完善。 现在的选择处于功能性和可用性层面，而不是架构层面。我没有先验地选择用 React，我问了一下，这是编码模型做得很好的东西。我用 Supabase 是因为它的 MCP 不错，我不用担心手工完成任何东西。 我故意放弃了通常的软件框架思维。不像工程师、产品经理或技术中的任何正式角色那样思考。现在是：我想让应用做 X，怎么做，好的，用 Y 方式做吧，好的现在检查安全性。 注意：我从未考虑过设计模式、框架或技术债。原则变得非常以用户为中心——可用性、体验、交互感受。 感受式编程某种程度上消除了提前规划的需要。不是说不负责任地冲进去，而是我不再需要从第一天起就确保代码库能扩展且具有可伸缩性。现在当需要时我们可以大幅重建。我们不需要规划编码速度或入职培训。至少对这类应用来说不需要。 规划不是为了从一开始就能扩展。是为了在需要扩展时能够充分重建。当这个应用有足够用户开始产生性能问题时，我知道我可以让它扩展——不是因为我是好工程师，而是因为我会有足够的数据来感受式架构以达到所需的吞吐量。 所有软件都会这样工作吗？绝对不会。有些软件总是需要确定性的、手动检查的，也需要机器帮助。有些需要可靠性。但这里的一次 20 分钟宕机不会杀死任何人。不会让半个互联网崩溃或造成财产损失。只是会被修补。 我通常非常谨慎地写作，但这次完全是凭感觉。没有结构，什么都没有。我表达了想表达的，我甚至可能不看格式化的输出。 在 YOLO 之前是及时行乐，更早之前，管他呢。但那现在已经不重要了。 这生活不止是程序化的愤世嫉俗。