在 MoscowJS 66 上，我一共提出了10 多个问题。其中两个被选为“最佳问题”，最后我带着两份奖品离开了 meetup。
这是整件事里最容易被记住的部分。但对我来说，更有价值的是另一点：我没有把 Q&A 当成“正式内容”结束后的附加环节。我尽量主动跟进每个分享，并用问题去澄清那些我觉得最有意思、或者还不确定的地方。
MoscowJS 66 实际讲了什么
这场 meetup 于2025 年 7 月 3 日在莫斯科的 School 21 举办。MoscowJS 66 官方议程列出了四个分享，主题包括 Telegram 机器人和 Web App、LangChain.js 及其 developer experience、网站构建器的架构，以及TypeScript 类型测试。
这样的描述比简单概括为“AI”或“前端架构”更准确。与 AI 相关的分享具体讲的是 LangChain.js，而架构分享则聚焦于构建网站编辑器时的设计决策，以及灵活性与简单性之间的 trade-off。
我把 Q&A 当成技术内容的一部分
整场活动中，我提出了10 多个问题。这让我听分享的方式也发生了变化：只理解主旨还不够，我还需要注意其中的假设、边界情况，以及哪些地方需要更具体的解释。
最终，我的两个问题被选为最佳问题，我也因此拿到了两份奖品。这是我可以确认的亲身经历，但我不会把它包装成“问题问得越多，越容易获奖”这样的普遍规律。
我真正带走的东西
对我来说，更实用的结论很简单：当我主动参与，而不是被动消费内容时，技术 meetup 会更有价值。一个好问题可以暴露某个方案的适用边界，补出分享中没有展开的 trade-off，或者把抽象观点变成具体问题。
如果你也想用这种方式参加技术活动，可以在每个分享过程中记下一个仍未解决的点，再把它整理成一个简短、但上下文足够的问题。目标不是尽可能多地提问，而是离开时比来时少一些未经验证的假设。
感谢 MoscowJS 66 的所有讲者和组织者。我原本是来听分享的，但最后深度参与了 Q&A，并带走了两份奖品，也带走了一种更主动地听技术分享的方式。