COSCon‘25首日实况：AI与开源成主旋律，云原生走向务实治理

周六早上的地铁上，我一路看到好几个胸前别着参会胸牌的人，方向一致。出站后跟着人流走到会场门口，签到队伍已经绕了两个弯，志愿者举着指示牌不断引导分流。COSCon‘25，第十届中国开源年会，第一天的开场比我预想的还要热闹——主会场很多位置坐满了，后来的不少人干脆站在过道和后排，两边的通道也挤满了人。这篇文章就当我把现场看到、听到的东西整理成一份实录，给没能到场的朋友做个参考，也顺便帮明天要来的同行们提前踩一遍点。如果你的主要目的是了解今年开源圈到底在聊什么、哪些话题真的被讨论、第二天还有哪些值得蹲守的议程，这篇应该能帮上忙。

1. 首日现场的真实氛围：人气、节奏与开场演讲里的高价值观点

1.1 从签到到主会场：一场超出预期的"早高峰"

我九点出头到签到处，队伍已经很长了。扫码、核对信息、领胸牌，流程本身很利落，志愿者分成几组，把普通参会、讲者、赞助商分到不同通道，避免所有人都堵在一个口。排队的过程中我翻了下当天的日程，发现很多热门分论坛在上午就排得满满当当，从AI基础设施到社区治理，跨度非常大。

穿过展区往主会场走的时候，两侧的易拉宝和项目宣传板前已经围了不少人。有几个人直接靠在墙边看项目文档，还有人一边走一边跟同伴确认下一场去哪儿。主会场门口的屏幕上滚动着整天的议程，我注意到一个明显的变化：今年AI相关场次的标注格外多，几乎每个时段都有两三场并行的选择。

进到主会场后，座位已经剩得不多。我找了个靠边的位置坐下，后面陆陆续续进来的人只能站着。台上开场的内容比较简短，没有太多拖沓，很快就进入正题。现场观众反应用一个词形容就是"务实"：遇到有信息量的观点，不少人低头记笔记；遇到比较泛的表述，大家明显安静许多。这种氛围其实挺能说明问题的——来参会的开发者想知道的是具体怎么做，而不是听概念层面的展望。

1.2 开场演讲里最让我记住的三个提法

第一个让我印象深刻的观点是：开源的代码资产固然重要，但真正值钱的，是围绕代码形成的协作网络。演讲者举了一个很形象的例子：一个跨国维护的项目，凌晨三点有人提交issue报告，早晨六点另一个时区的人已经把复现步骤补充完整，下午第三个时区的维护者直接提交了修复补丁。这种跨时区的"接力式协作"，在公司内部项目里几乎不可能出现。开源项目的竞争力不在于代码仓库本身，而在于这个网络能否持续运转。

第二个提法跟AI有关：AI已经不只是写代码的辅助工具，而开始成为开源社区里"最勤奋的贡献者"。现场讲到不少实践，比如用AI自动补文档、翻译issue、修CI配置、做初步的代码评审。但讲者也提出了一个很现实的问题：AI生成的PR数量暴涨之后，维护者的审核压力反而更大了。工具提高了产出速度，却没有同步提高信任速度，这个矛盾在接下来的分论坛里被反复提及。

第三个观点关于项目治理，原话我记不太准，大意是：治理规则要写在一个项目还很小的时候。很多人以为社区壮大了再定规则也来得及，但实际上，一旦参与者变多、利益变复杂，再想推动治理改革就难得多。退出机制、决策透明度、负责人轮换，这些听起来很"制度"的东西，恰恰是一个项目能否长期活下去的关键。这句话后来在我跟几位维护者聊天时也被多次印证。

2. 技术风向观察：分论坛热度背后的三个确定趋势

今年分论坛数量很多，我优先听了AI、云原生和社区治理三个方向。走过几个会场之后有一个很明显的感觉：分论坛的热度本身就是风向标。某些前几年还挺热闹的话题，今年上座率明显下降；而另外一些看起来不够"炫"的话题，反倒挤满了人。这说明开源圈正在从追逐概念转向解决实际问题。

2.1 AI与开源：从"工具化"走向"基础设施化"

AI相关议题几乎遍布全天议程，从上午的主论坛到下午的技术专场，每个会场都能听到"模型""训练""推理"这些词。我在现场观察到三个比较确定的信号。

第一个信号是模型本身的开源化正在变成一种底层共识。很多讲师在分享技术方案时，默认以开源模型作为基础来展开讨论，闭源方案反而成了需要特别说明的例外。这意味着AI技术栈的选型逻辑正在发生变化——从"哪个效果好选哪个"逐渐转向"哪个可以自主可控、可以修改和再分发"。

第二个信号是AI辅助开发从个人尝鲜走向团队规范。有讲师展示了团队内部如何用AI做代码的初步审查、单元测试生成和文档补全，并且把这些能力接入到日常的PR流程里。和两年前那种"AI能写代码"的展示不同，今年的分享更关注工程化落地：怎么接入CI、怎么设定审核标准、怎么处理误报。

第三个信号是围绕AI的治理问题开始被公开讨论。AI生成代码以什么许可证发布？训练数据的合规边界在哪里？模型偏差会不会通过开源数据集扩散？这些问题在现场引起了很长的问答互动。成熟度体现在什么地方？就是大家不再只讨论"能不能做"，而是开始讨论"这样做了之后会有什么后果"。

2.2 云原生与开发者工具：新架构叙事让位于"善后"经验

云原生方向上，今年讲"新架构"的明显少了。前几年大家在聊怎么把一个服务拆成微服务、怎么用容器编排，而今年更多的分享题目是：多集群管理怎么避免混乱、资源成本怎么核算、故障爆炸半径怎么控制、可观测性建设怎么落到指标上。

听了几场之后，我觉得这种转变是技术进入成熟期的正常表现。就像搬家一样，搬进新房子是兴奋的，但真正过起日子来，要处理的是水电煤气、垃圾怎么分类、哪个插座不够用。这些"善后"话题一点也不性感，但恰恰是真实场景里最痛的部分。

有一位讲者的分享让我印象很深：他们在大规模落地容器平台之后，发现最大的成本浪费不是计算资源本身，而是各种无人认领的中间环境和僵尸应用。为了治理这个问题，他们专门写了一整套资源审计工具，并且把清理流程自动化。这种经验在几年前很少有人会讲，因为大家都在忙着"上云"，而现在讲的是"上云之后怎么办"。

开发者工具这边，分享也明显更关注实际体验和效率，比如本地开发环境怎么更接近生产、远程协作时怎么减少反馈周期、调试复杂问题时的工具链整合。观众的提问也都非常具体，很少人问"这个技术未来怎么样"，基本都在问"你们在XX场景下是怎么处理的"。

2.3 商业化、治理与可持续：钱与规则终于被摆上台面

商业化分论坛的座位几乎坐满，这是我没想到的。过去很多开发者一聊"开源赚钱"就觉得有点敏感，但现在大家几乎默认：一个项目要持续发展，必须有清晰的经济模型。现场讨论比较多的是"开放核心"模式——核心功能开源、高级功能收费，边界怎么划才不会破坏社区信任。

有讲者分享了自己项目在划分开源版和企业版功能时的具体案例：最早他们把很多企业用户常用的功能放进了收费版，结果社区用户抱怨剧烈；后来花了很长时间调整边界，把那些"个人开发者其实也需要"的功能重新开放出来，社区氛围才回暖。这个案例说明，商业化不是简单的功能切割，而是一场持续的信任管理。

治理话题同样热门。公司主导的项目，贡献者普遍担心话语权过于集中；社区主导的项目，又常常苦恼没人全职投入。圆桌讨论时，有位嘉宾总结了三种常见困境：有钱没规则、有规则没人执行、有人执行但不透明。解决方案没有标准答案，但大家都认同一个基础条件：决策过程必须公开可追溯，哪怕慢一点，也比背后拍板要好。

还有一个词在多个场合被反复提到："脏活累活"。做文档、维护测试、清理旧issue、发布版本、处理用户提问——这些不被关注的贡献，恰恰决定了一个社区能不能留住人。很多项目不缺写代码的人，缺的是愿意持续做这些基础工作的人。

3. 展区、闪电演讲与现场交流：首日最有"人味"的部分

如果说分会场是内容主战场，那展区就是整个年会最有"人味"的地方。几十个社区和组织在大厅里摆开摊位，人声鼎沸，过道里来来往往全是人。很多演讲里讲不清楚的东西，在展区里一聊就明白了；很多线上聊了很久的ID，在这里终于对上了真实的脸。

3.1 项目展区：贴纸、故障演练和"good first issue"

展区的内容比我预想的要丰富。有个做数据库的社区，直接在展位上做起了故障演练：演示人员把一个节点当场停掉，几秒钟后监控面板显示流量自动切换到其他节点，围观的人里三层外三层。相比只摆几块易拉宝的展位，这种现场演示显然更容易让人停下来了解项目。

另一个做AI工具链的项目，展位上摆了一面大屏幕，让大家用自然语言描述需求，现场生成PR并把改动直接展示出来。他们的工作人员一边演示一边解释底层逻辑，也坦诚地讲了当前模型的局限和失败案例。这种"不吹不黑"的态度反而让大家更愿意扫码进群，我路过的时候，他们桌上已经堆了一叠扫过码的名片。

还有一面墙让我印象很深：某个社区把一堆"good first issue"打印出来贴在展板上，每条都标了"无门槛""适合新手""需要文档能力"等标签。很多学生模样的参会者围在墙前拍照、讨论。展区工作人员说，每年都会借大会招揽新贡献者，而新手任务墙是转化率最高的方式——把活儿摆出来，比单纯讲理念有用得多。

高校社团的摊位也很接地气。某高校的开源社团摆了几块开发板和厚厚一沓课堂笔记，几个学生现场演示他们基于开源项目做的小作品。围观的人问得最多的问题不是"这个项目怎么用"，而是"我们社团也想搞开源，怎么起步"。旁边有个学姐分享的经验也挺实在：先从一个大家都用得上的小工具做起，哪怕只是修一个文档，也能建立起足够的仪式感。

3.2 闪电演讲：五分钟里浓缩的高密度经验

下午我在闪电演讲场待了一阵子。这个环节节奏极快，每个人只有五分钟，主持人掐表，时间一到话筒就被收走。也正因为时间短，讲者必须把最核心的东西提炼出来，反而听到不少直击要害的经验。

有位开发者分享了他从零发起一个微型web框架的经过。他特别强调，这个项目知名度不高，star数也不算多，但他最骄傲的是，除了自己之外，还有两个完全不相关的人愿意长期维护它。他说了一句让我记到现在的话："项目的生命力不在于star数，而在于有没有两个以上不相关的人愿意把时间投进去。"这句话引来了现场一片掌声。

另一位做本地化翻译的志愿者讲了他们社区怎么组织多语言协作。核心经验是"把翻译做成家常便饭"：在文档页面直接内嵌翻译入口，贡献者不用了解Git流程，点点鼠标就能提交译文，再有人工维护者审核。这样降低了参与门槛，许多完全不懂代码的人也能为项目贡献力量。

还有一位负责文档的工程师说，"文档不是写出来的，是对话出来的"。他们团队很少坐在房间里凭空写文档，而是从issue区、用户群、技术支持邮件里提炼真实问题，把回复整理成FAQ，再把FAQ扩展成正式文档。这样写出来的东西，才真正有人看、有人用。

3.3 现场社交：怎么在人群里高效找到同好和维护者

展区到下午成了社交密度最高的地方。我在现场转了几圈，发现真正聊得深入的人都有一个共同点：带着明确的问题来。比如有人直接走到某项目摊位，开口就说"我们公司用了你们的工具，有个XX场景一直调不通"，然后维护者当场开始帮忙排查。这种对话效率远高于闲聊式社交。

我的建议是，如果你有心仪的项目，不要只在展位前扫个码就走。可以先花几分钟看看项目文档，或者在现场先留下一个issue反馈，再去找维护者聊。对方一看你是真的用过、真的有反馈，态度会完全不一样，愿意聊的内容深度也不一样。

还有个值得注意的细节：很多摊位准备了周边贴纸和帆布袋，但真正有心维护社区的人，更希望听到你对项目的中肯建议，而不是领完礼物就走。如果你能说出"你们的文档哪里看不懂""安装步骤哪一步卡住了"，他们会特别感谢，这比你夸一百句"你们项目好棒"更有价值。

现场社交还有一个低门槛的办法：参加闪电演讲和新手工作坊。这类场合对"对方是谁"的要求很低，大家可以纯粹围绕一个问题来讨论。我在闪电演讲场就通过一个关于issue管理的提问认识了几位维护者，后来在展区又碰见，很快就聊开了。

4. 踩坑复盘：首日那些值得明天参会者参考的细节

趁着今天的热乎劲，我想把踩过的坑和观察到的经验一起复盘一下。这些细节在官方攻略里不一定有，但对实际参会体验影响不小，尤其是明天还要继续参会的人，看完应该能省下不少力气。

4.1 赶场教训：A会场到B会场，没你想的那么近

今天我最直接的教训，是在两个会场之间"跑断腿"。下午我计划从A栋的一个分论坛赶到B栋的另一场分享，看着地图觉得十分钟绰绰有余，结果中间不仅要穿过一条室外连廊，还要等电梯。等我赶到会场，前五分钟的分享已经错过，座位也只剩下很靠边的位置。

后来我学乖了，再看日程时先用地图确认两个会场的实际距离，把相邻的场次尽量排在同区域。现场Wi-Fi不错，但人多的区域偶尔会卡，最好提前把日程离线缓存。还有一个小技巧：热门场次最好提前十分钟到场，否则很可能只能站着或坐加座。

另外提醒一点，大会提供的午餐时间比较集中，如果不想跟大部队挤，可以稍微错峰，比如提前十分钟去餐厅，或者晚一点过去。今天中午我看到饭点前排了长队，反而刷新了餐台，所以时间是能调剂的。

4.2 提问与交流：拿到比PPT更有价值信息的几个方法

今天听了好几场分享，我发现现场QA往往是信息密度最高的部分。PPT上的内容后续大概率会公开，但问答环节里那些具体的踩坑细节、作为替代方案提到的工具、甚至讲者无意间说出的一句"其实我们一开始也搞错了"，都只在现场才能听到。

所以如果想高效参会，建议提前为每场想听的分论坛准备一到两个具体问题。提问时尽量问"你们在XX场景下是怎么处理的"，而不是"你怎么看XX的趋势"，前者的回答通常更落地。今天有位观众问"你们在处理XX数量级的数据时出现了性能下降，后来怎么定位的"，讲者当场分享了一个很详细的分析过程，问答持续了快十分钟，比演讲本身还有料。

和展位维护者聊天同理。不要泛泛地问"你们项目是干什么的"，可以试着说"我目前在做XX，遇到了XX问题，看你们项目好像能解决"——对方一听你是真实用户，往往会很主动地帮你分析，甚至拉上旁边的同事一起讨论。今天我就靠这个办法，在某开发者工具展位拿到了一个非常实用的配置建议，这是看文档学不来的。

4.3 装备与体力：一天两万步的参会配置

会议规模大的时候，体力其实是隐形瓶颈。今天我的微信步数轻松超过了两万步，这还是没逛完所有展区的结果。如果你想全程保持状态，一双舒适的鞋比什么都重要，别为了好看穿硬底鞋。会场空调温度偏高，人群密集时更明显，穿方便穿脱的外套比较合适。

背包尽量从简。今天我在会场看到不少人背着全尺寸笔记本到处走，进会场后还得找带电源的位置，折腾半天。如果只是为了听分享，带个轻薄本或手机加纸笔就够用了；如果要参加动手工作坊，再考虑带电脑，但国内插座紧张，最好提前充好电。水杯也建议带上，会场提供的纸杯消耗很快，有杯子的可以顺便减少排队。

还有个小经验：拍照记录不如打字记录。现场PPT翻页很快，拍下来大概率不会再翻相册。我今天是直接用手机备忘录记几个关键词和当时的想法，晚上整理起来反而高效得多。

5. 次日议程前瞻：明天值得蹲守的方向和我的观展路线

第一天的内容已经足够丰富，但很多深度议程明显是安排在第二天的——工作坊需要一整个下午，圆桌需要预留足够的讨论时间，新项目的首次路演也都集中在这天。如果你明天还有一天时间，怎么安排才不浪费，我根据自己的经验和今天看到的情况说说想法。

5.1 明天我最期待的几个方向

第一个方向是动手工作坊。这类环节的参与价值远高于听演讲，因为你可以带着自己的项目问题去现场，在维护者的帮助下实际解决。我打算挑一个跟AI辅助开发相关的工作坊，提前把环境配好，把要跑的场景准备好，到现场直接上手。另外还有一批新晋项目的首次路演，我很好奇他们会怎么定位自己的项目、怎么设计社区路径。

第二个方向是圆桌讨论，尤其是关于社区治理和全球化协作的场次。今天的分论坛里，很多问题是作为观点提出来的，但圆桌上大家可以面对面交锋，比单方面输出更有信息量。我特别想听"公司主导的开源项目如何让外部贡献者产生归属感"这个话题，今天的演讲里点到但没展开。

第三个方向是AI落地真实业务的复盘。今天很多分享停留在方案介绍层面，明天有几场更偏案例分析，讲从零到一的过程、中途踩的坑、最后如何权衡取舍。这种"失败史"往往比成功故事更有含金量。

5.2 明天的动线与准备：上午逛展区，下午蹲工作坊

根据今天的经验，我的明天大致这样安排：上午先逛展区，因为上午人相对少，可以和维护者有更从容的交流；下午集中上工作坊和圆桌，这部分参与感最强。具体场次我会在今天晚上再次确认，把相邻的、同一区域的场次排在一起，避免再次出现下午那种赶场慌乱。

如果明天要参加动手实验，务必提前把依赖装好。现场的网络条件虽然能支撑一般上网，但下载几个G的开发环境镜像就可能很吃力。很多工作坊都会提前给出准备清单，我建议务必认真过一遍，到了现场直接跑代码，否则可能一半时间都花在等下载上。

还有一个容易被忽略的点：明天是会议最后一天，部分展区的周边可能会提前收摊，如果想集章或领取资料，尽量上午搞定。返程的朋友也记得预留足够时间，因为散场的交通压力通常会集中爆发。

5.3 给没到现场的读者的一个建议

如果你没能到现场，也不用太遗憾。按照以往几届的惯例，很多讲师的PPT和部分文字稿件在会后会陆续公开，耐心等上一两周就能看到大部分内容。但有两种东西是线上补不到的：一是现场问答里那些即兴的经验沉淀，二是展区里面对面的深入沟通。

所以我的建议是，如果对某些议题特别感兴趣，可以先把今天和明天被反复提及的关键词记下来，等资料公开后按关键词检索，再顺着讲师的主页去翻他过往的博客和项目记录，往往能找到比会议PPT更系统的知识链路。开源的价值就在于开放，资料总会在某个地方被共享出来，只是需要一点整理的耐心。

最后说一点个人感受。今天在展区跟一个陌生开发者聊了十分钟，他讲自己两年前从某个项目的"good first issue"开始，一步步成了维护者，最近又带了三个新人进来。他说这句话时表情很平静，但我在旁边听着，突然觉得这才是开源年会最值得来的理由——你永远不知道，一个看似普通的贡献入口，会把一个人带向多远的地方。这就是开源社区的传承，也是开源年会最迷人的部分。