苑强距离 COSCon'25 的日子越来越近，鲸智社区一周年活动的议程也赶在大会前正式发布了。作为从社区筹备阶段就泡在里面的一员，看到这份议程的时候还挺感慨的——从去年在展台前临时拉横幅合影的草台班子，到今天能把一整天的活动安排得井井有条，这个变化本身就值得聊一聊。这篇文章不打算只把议程复述一遍，而是想把这份议程掰开揉碎讲清楚：每个环节为什么这么排、参与者应该怎么用这份清单、主办方在发布之后还有哪些事要做。准备来现场的朋友可以拿它当行动指南，在开源圈子里混了很久想了解社区运作的人，也能从中看到一场社区周年活动背后的设计逻辑。
1. 一周年聚会的分量：为什么社区要把仪式感做足
1.1 COSCon'25 的社区团聚，到底是怎样一个场子
COSCon 一直是国内开源圈绕不开的年度聚会，每年都会把各个技术方向、各家社区、各路独立开发者聚集到同一片场地上。过去的参会体验里，最让我觉得有价值的往往不是那些大而全的主题演讲，而是展区里的社区交流——你在某个社区展位前站十分钟，就有可能认识接下来一年一起写代码的搭子。今年大会专门设计了"社区团聚"这个板块，把很多开源社区聚拢到一起，让每个社区有机会在正式会议之外拥有自己的时间与空间。鲸智社区一周年活动就是在这个背景下落地的。
社区团聚这个安排，解决的其实是开源社区线上活跃、线下陌生的老问题。平时大家在一个群里聊得热热闹闹，见面却可能连对方长什么样都对不上号。大会提供了一个天然的线下集合点，社区的周年活动再借这个集合点做一次深度的交流和庆祝，正好把线上关系往线下推进了一步。这也是为什么我们一开始讨论周年活动办在哪时，几乎没犹豫就选了 COSCon'25 的社区团聚环节——既能借大会的人流让更多人认识社区，又能给老成员一个名正言顺聚在一起的由头。
1.2 对开源社区来说，周年庆不只是一场热闹
很多对社区不太熟悉的朋友会问：一个开源社区搞周年活动，不就是找一群熟人社聊几句、切个蛋糕吗？实际远不止这些。开源社区本质上是一个非常松散的协作网络，成员之间没有严格的雇佣关系，全靠共同兴趣和一点点责任感维持运转。这种组织形态下，周年庆是少有的能够把所有人拉到同一时间、同一地点的机会，它的仪式感本身就有实际的运营价值。
仪式感首先解决的是"归属感"问题。日常参与代码贡献、文档翻译、问题解答的成员，很多时候是在单独面对电脑屏幕，很难感受到自己的工作被看见。但周年活动上，当项目负责人当着几十人念出贡献者的名字，或者把这一年的提交记录做成视频放出来，那种被认可的感觉是线上点赞给不了的。仪式感的另一个作用是给外界释放信号：这个社区还活着，而且在稳定迭代。开源社区的存续与否，很大程度上取决于外部开发者愿不愿意信任你、参与你，一个能正经办出周年活动的社区，天然比一个只在群里冒泡的社区更有公信力。
即便只是"发布议程"这个动作，本身也有意义。议程一旦公开发布，就相当于社区对参与者做了一个承诺，承诺哪些环节值得你期待、哪些时间点会有什么内容。这会让愿意来参加的人提前规划行程，也会让潜在的新人提前了解社区的调性，降低迈出第一步的心理门槛。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 鲸智社区这一年的成长切片：从零到一的开源路径
2.1 能留下存档才算数：社区的基础设施建设
趁着周年活动这个节点往回看，过去一年社区做的最重要的一件事，不是某个项目的代码量涨了多少，而是终于把基础协作设施搭完整了。GitHub 组织建起来了，文档站从一个临时共享文档搬到了正式站点，微信群之外有了按话题区分的讨论渠道，周会从"有人想起来就开"变成了固定节奏。这些听着不酷，甚至有点琐碎，但恰恰是这些琐碎决定了一个社区能不能持续运转。
举一个过去一年高频被讨论的问题：开源许可证到底怎么选。社区里好几个新项目在开源前都卡在这一步，Gitee、GitHub 上托管代码时到底选 MIT、Apache-2.0 还是 GPL，新手很容易被绕晕。我们后来的做法是整理了一份内部指南，简单粗暴地把选择逻辑讲明白：想让别人放心用就选 MIT 或 Apache-2.0，想要求衍生项目也保持开源就选 GPL 系。这个坑之所以值得说，是因为很多社区项目上线半年后才发现许可证选得不对，改起来一脸尴尬。周年活动上我们安排了不少与项目相关的内容，但基础建设的经验会穿插在交流中，毕竟没有这些底子，一周年站不住。
2.2 开源项目的从无到有：my_ai_town 的孵化路径
社区一年里最拿得出手的项目，当属 AI 小镇 my_ai_town。这个项目一开始只是发起人脑子里一个有点游戏性质的想法：能不能让一群 AI 角色在一个虚拟小镇里生活、互动、发展出类似人类社会的活动轨迹。最初版本非常粗糙，渲染简陋、逻辑单薄，跑起来像一堆机器人偶在念台词。但开源社区最神奇的地方就在于，只要代码公开在 GitHub 上，就会有人基于自己的兴趣帮你添砖加瓦。
项目在 github.com/mewamew/my_ai_town 开源后，陆陆续续收到了不少有意思的 PR：有人给角色加了更自然的对话切换，有人优化了场景渲染，还有人把打包流程理顺了，让 mac 和 windows 用户都能通过一键下载直接运行游戏。这种从"个人 demo"到"社区协作项目"的转变，正是开源社区存在价值最直观的体现。这次的周年活动上，my_ai_town 会在项目路演环节做一次公开发布，同时提供最新版本的 ai_town 游戏下载体验。说实话，从第一行代码到能在大会现场让路过的人点开玩一局，这个进步速度是我一开始没预料到的。
2.3 社区成员层的滚雪球效应
社群这类组织，最难的从来不是技术问题，而是人的问题。过去一年，社区成员结构经历了从"一个核心小圈子"到"多层漏斗"的变化：最核心的发起人几个，外层是稳定参与周会和项目开发的活跃成员，再往外是偶尔帮忙提 issue、改文档的贡献者，最外圈是上千个在群里潜水、偶尔冒泡的围观者。每层之间的转化都需要契机，而周年活动就是这个契机里最重要的一次。
一个数据让我印象很深：社区从建立到现在，累计收到的 PR 数量已经超过一百，提交的 issue 也有几百条，虽然和头部大项目不能比，但对一个刚满一岁的社区来说，已经证明了自己具备持续吸引外部贡献的能力。周年活动上，我们希望让每个层级的成员都能找到自己的位置：核心成员负责深度的圆桌讨论，活跃成员有机会上台做闪电演讲，围观群众可以先从工作坊里提交人生第一个 PR 开始。社区想滚雪球，就必须让每个层级的人都能感受到"我也能参与"。
3. COSCon'25 团聚议程全解读：六个环节背后的设计逻辑
3.1 一份可参考的周年活动议程表
很多社区办活动，议程都是想到哪排到哪，最后不是冷场就是超时。这次我们提前一个月做了完整设计，整套议程按照"上午建立共识、下午深度互动、晚上情感连接"的逻辑来铺，下面是最终发布版本：
| 时间 | 环节 | 内容方向 | 设计目的 |
|---|---|---|---|
| 10:00-10:30 | 开场 | 社区一周年回顾视频、冷启动破冰 | 让早到的人快速进入状态，建立共同记忆 |
| 10:30-11:15 | 主旨分享 | 创始人/核心维护者复盘一年路径 | 让所有人站在同一信息面上，了解社区从哪来到哪去 |
| 11:15-12:00 | 项目路演 | my_ai_town 等三个社区项目公开演示 | 展示社区硬产出，让技术人看到具体成果 |
| 14:00-15:30 | 闪电演讲 | 6个5分钟短分享，覆盖工具、踩坑、开源心得 | 给普通成员舞台，保持下午开场的信息密度 |
| 15:30-16:30 | 圆桌论坛 | 开源社区如何保持长期活跃 | 把大家共同关心的问题摊开讨论，不回避矛盾 |
| 16:30-17:30 | 开源工作坊 | 手把手提交第一个PR、本地环境搭建 | 让新人当场获得成就感，完成从围观到参与的第一步 |
| 19:00-21:00 | 社区之夜 | 晚餐、颁奖、自由交流 | 非正式场景下深度的关系连接，颁奖让贡献被看见 |
3.2 主旨分享和年度报告为什么要放在开头
这里有个小经验：上午时段人的注意力最集中，但也最容易被"无意义的开场"浪费掉。很多活动开场就是领导致辞、嘉宾介绍，二十分钟过去观众已经玩手机了。我们把开场压缩到半小时内，视频和破冰环节穿插进行，让早到的成员在轻松氛围里互相认识，为主旨分享铺垫好情绪。
主旨分享放第二个，是因为它承担着"对齐信息"的功能。社区一年里发生了很多事：项目方向调整过、成员有过离开也有过加入、有些计划做成了有些做砸了。这些信息平时散落在各个群聊记录里，新人根本看不全。周年活动如果一上来就聊具体项目，新来的朋友会一头雾水。所以先用一场复盘把这一年的大事件、关键决策、数据变化讲清楚，等于给所有人画了一张地图，接下来不管听路演还是参与圆桌，都能把内容放进正确的上下文里。
3.3 路演、闪电演讲与圆桌：节奏上的松紧搭配
下午的安排我们刻意做了"松紧交替"。14 点前大家刚吃完午饭，最困，如果上来就是一个小时的圆桌长谈，现场准睡倒一片。所以第一段安排的是密集型的闪电演讲，每人 5 分钟，节奏快、信息密度高，内容是具体的工具使用、踩坑记录和开源心得，比如怎么把一个个人项目运营成社区项目、怎么处理 PR 里的意见冲突。5 分钟的限制逼着讲者只留干货，观众也不容易走神。
闪电演讲结束后的圆桌论坛，讨论的是"开源社区如何保持长期活跃"这个话题。为什么选这个主题？因为它对所有社区成员都有切身关系，无论你是维护者还是贡献者，都会面对社区冷热不均的问题。圆桌不追求给出标准答案，而是把社区一年里真实遇到的分歧摊开讲，比如该不该接受低质量 PR、要不要花钱做推广。这种坦诚反而更容易引发共鸣，现场观众在 15:30 到 16:30 这个区间通常是最投入的。
工作坊放在下午最后一段，是故意安排的。经过一天的听讲和讨论，新手脑子里积攒了大量"我是不是也可以搞"的冲动，这时候趁热打铁，让志愿者带着大家走一遍提交 PR 的流程，比任何鼓励都管用。以前很多社区活动没有这部分，结果新人回去三天后就忘了热情；工作坊的价值就是当场把热情转成一次具体的提交，哪怕只是一个文档修订，都意味着一次真实的贡献。
3.4 晚间环节：社区之夜的功能不只是聚餐
不少人对社区之夜的期待就是吃饭。确实有饭，但它的核心功能是给非正式交流留足时间。白天的议程再精彩，多少都有点"表演"成分，人与人之间真正打开话匣子，往往发生在晚上不那么正式的场合。很多跨项目合作、甚至找工作的机会，都是在喝点东西闲聊时聊出来的。
社区之夜还安排了颁奖环节。这个环节我给很多社区朋友安利过，成本不高但效果极好：准备一些定制的贴纸、徽章、小周边，把一年里给社区做过实质性贡献的人点名感谢一遍。不用搞得很隆重，就是聚在一起时认真念出他们的名字。开源社区缺的不是奖品，而是被看见的瞬间。颁奖会让被感谢的人获得荣誉感，也会让围观的人产生"明年我也想站在那儿"的期待。
4. 从议程表到现场体验：主办方与参与者的双向准备
4.1 参与者：别只当观众，把议程变成自己的行动清单
对准备来大会现场的朋友，我的建议是别把这份议程当成一份"观看时间表"，而是当成一份行动清单。看到项目路演环节，提前去 GitHub 仓库把 my_ai_town 的代码拉下来跑一遍，带着具体问题到现场问维护者，效率远高于现场临时看。看到闪电演讲环节，问问自己有没有想分享的话题，就算这次没报名，也可以在现场找机会和讲者交流。
有个大多数人都忽略的准备动作：提前把自己的自我介绍和项目链接整理好，可以是一个网页、一个 GitHub 主页、或者简单的一张二维码卡片。开源社区的社交带有非常强的"项目导向"，你和别人聊十分钟，最后大概率会落到"你最近在做什么项目"上。现场临时翻手机找链接，远不如提前准备一张小卡片来得从容。行动清单的最高优先级，是锁定至少三个你想认识的人，提前在社区群里约好见面时间，否则现场人多嘈杂，错过就真的错过了。
4.2 主办方：议程发布只是开始，执行才是大头
作为一个办过好几次社区活动的人，我要实话说：议程发布那一刻，工作才完成了一半。真正容易翻车的地方全在落地环节。第一个坑是时间控制，闪电演讲最怕超时，5 分钟的分享拖到 10 分钟，后面整个下午的节奏都会崩。我们这次的做法是安排专门的志愿者做提示牌，分别在 1 分钟和 30 秒时举牌，不靠主持人喊话打断，减少讲者的尴尬。
第二个坑是场地和设备的检查。社区之夜看起来只是吃饭聊天，但要提前确认场地有没有音响、投影能不能用、插座够不够。之前见过一次社区活动，圆桌环节发现话筒只有一支，四个人轮着传，现场体验大打折扣。第三个坑是分工不清。签到处、直播控制台、现场记录、应急处理，每件事都要有一个明确的负责人，而不是"谁有空谁去顶"。我们这次在活动前一周做了两次线上分工会和一次现场踩点，就是为了把不确定性降到最低。
4.3 线上与线下：混合办会最容易翻车的三个细节
现在的社区活动很少有纯线下的，线上直播和线下场子的配合质量直接影响活动传播效果。第一次混合办会的人最容易在三个细节上翻车。第一个是音频，线下会场的嘈杂声会通过直播话筒传出去，如果现场没有专门的收音设备，线上观众听到的往往是模糊的。我们这次的要求是发言人在圆桌之外尽量用手持麦或领夹麦，宁可现场声音小一点，也要保证直播声轨干净。
第二个是线上互动怎么桥接到线下。很多活动直播时，线上观众在弹幕里提了问题，主持人根本看不到，因为没人负责盯屏幕。我们的做法是指定一位线上主持人，专门在直播评论区筛选问题，通过手机传到现场主持人手上。这样线上观众才真的有参与感，而不是单纯看一场直播。
第三个是网络。大会现场众多人共用 WiFi，直播推流和现场演示极其容易卡顿。靠谱的做法是提前备好独立热点，至少保证演示设备的网络稳定。别看这些都是小事，任何一环出问题，都会让一整天精心安排的议程印象分大打折扣。
5. 一周年之后：活动如何沉淀为社区的长线资产
5.1 议程结束后的第一件事：整理归档
周年活动办完，最忌"活动结束一切结束"。当天晚上我们就会启动整理工作：录播回放、讲者幻灯片、现场照片、文字纪要、线上讨论的链接，全部统一归档到社区 GitHub 仓库下的指定目录。为什么要这样做？因为对没到场的社区成员来说，这些资料就是他们参与活动的方式；对后期加入的新人来说，这些资料是了解社区历史的入口；对社区本身来说，这是长期资产，下一次办活动可以直接复用流程。
归档这件事听起来简单，但非常容易拖延。我见过有些社区活动结束三个月后，PPT 还零散存在个人网盘里，慢慢就丢了。我们的做法是直接写进分工表：活动第二天必须把原始素材汇总给文档志愿者，一周内完成剪辑和索引更新。没有截止时间的归档都是空话。
5.2 把临时贡献者转成持续贡献者
周年活动最直接的增长来源，是那些在活动上第一次认识社区、甚至第一次提交 PR 的人。他们在现场处于高热情状态，但这种热情衰减得很快，通常两三天后就忘了这回事。所以活动一结束，就要马上跟进：当天加了群的参与者，群内发欢迎信息和新手任务列表；工作坊里提交过 PR 的人，维护者在合并请求时专门回复一句感谢并引导认领下一个 issue；交换过联系方式的人，尽快发一条个性化的后续消息。
给新人的第一个任务一定要"小"。不要上来就让他们写复杂功能，而是让他们修一个文档链接、补一个测试用例、或者回复一个现有 issue 的复现步骤。难度越低，完成概率越高，完成后的正反馈也越强。这比天天在群里喊"欢迎新人，有问题随时问"有效得多，因为大部分人不会主动提问，但会在明确的指引下行动。
5.3 感恩名单与激励机制
最后一个部分，也是我个人觉得最容易被社区忽视的：活动结束后要有一份公开的感恩名单，而不是只在现场口头感谢一次。把贡献者、志愿者、讲者、赞助人员的名字和贡献写清楚，发在社区网站和群里。这既是对当事人的尊重，也是给社区立规矩——在这里付出会被看见。
激励机制可以做得轻量化：贡献证书用一张设计好看的电子图片就行，社区周边可以把只有现场参与者才有的贴纸寄给线上活跃贡献者。重点是"及时"和"具体"。如果拖到两个月后再发，感谢的温度已经凉了。明年能不能再办周年活动，很大程度上就取决于这一轮有没有把人在热乎劲里接住，并且让他们感觉到自己的名字被认真记住。
我在社区里待了这一年，最大的体会就是：开源社区的所有问题最终都会回到"人的连接"上。写代码只是连接的一种方式，办活动是另一种，而且往往更直接。所以这份周年活动议程发布之后，我特别希望大家不是看完就关掉页面，而是真的去现场坐一坐，哪怕只是找一个陌生人聊聊你最近在折腾什么。也许一年之后，你会发现自己也成了一个社区故事里的一部分。