2025 年 6 月 5 日，我参加了在莫斯科 T Bank 举办的 MoscowJS 65。那时我已经 使用 JavaScript 工作了六年。所以我去 meetup，并不是想让别人告诉我下一个应该用什么 framework 或 tool。真正吸引我的是另一件在独自工作时更难获得的东西：用几个小时专注于少数具体的技术主题，并和同样关心这些问题的人待在同一个空间里。
这次活动的内容明显围绕 AI 展开。根据 MoscowJS 65 官方议程，四场分享分别涉及基于 LLM 的 assistant、现代 AI 的工作方式和局限、使用 vision-language models 进行 UI testing，以及在使用 NPM 时与 AI 相关的安全风险。议程并不长，但同一个大主题被放在了非常不同的工程视角下讨论。
真正留在我脑海里的东西
分享本身在技术上很有意思，但现场氛围对我来说同样重要。讲者确实带着热情，整个活动也不是单纯被动听讲，而是有一种真实的参与感。这也是我到现在仍然喜欢本地开发者 meetup 的原因之一。
Documentation、技术文章和 source code，我随时都可以读；conference recording 也可以随时看。这些都不可替代。但 meetup 会形成另一种专注：一个晚上、有限的几个主题，以及一群对这些问题足够感兴趣、愿意亲自到场讨论的人。对于 niche topic，这种 context 往往能让观点更容易记住，也更容易被批判性地思考。
Talk 是起点，不是证明
这里也有一个重要限制。Conference talk 不是 documentation，不是 benchmark，也不能证明展示出来的方法已经适合我的 production code。一个很好的 demo 可以有启发性，但它并不能说明同样的方案在不同 constraint、edge case、maintenance cost 或 security assumption 下依然成立。
在 AI 话题上，这个区别尤其重要。问题不应该只是“demo 能不能跑”。我还会关心：真正被证明的是什么，哪些 assumption 没有展开，结果能否 reproduce，会出现哪些新的 failure mode，以及这个 tool 到底是在减少复杂度，还是只是把复杂度转移到了别的地方。
这才是 meetup 之后真正开始的 engineering 工作。活动可以让我注意到一个新想法，但 verification 仍然要单独完成。
为什么我还会继续去
JavaScript 的范围足够广，一个开发者完全可能连续几个月只待在某个 project 所需要的那一小部分里。Meetup 会短暂打破这种惯性。在 MoscowJS 65 上，一个 AI 主题把 developer tooling、model behavior、testing 和 package security 串在了一起。我不需要把听到的每个想法都采用，那个晚上依然可以有价值。
这次活动最后提醒我的，其实是一件更简单的事：即使已经和 JavaScript 打了六年交道，我还是喜欢深入研究具体主题，也喜欢和有相同兴趣的人讨论。Ecosystem 会变，流行的 tool 会变，talk 的主题也会变。这个部分不会。
对我来说，这仍然是继续参加本地开发者活动的充分理由。