news 2026/9/29 21:05:37

十年同行解码女性开源论坛:从参与到贡献的进阶路径

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
十年同行解码女性开源论坛:从参与到贡献的进阶路径

每年一到大会季,我都有个固定动作:把COSCon的议程从头翻一遍,划出自己想听的场次,再对着时间表做取舍。今年最先让我停下来的是那句发布文案——“十年同行,为她发声”。在开源这个以代码、Commit记录和技术话语为主的世界里,一个关注女性参与者的论坛能连续走到第十年,本身就值得认真看一看。这篇文章不打算做议程的搬运工,而是想用这些年在开源社区参会、组织活动、观察参与的视角,拆解这份女性开源论坛议程里真正值得关注的东西:它为什么存在、今年在聊什么、一场论坛是怎么跑起来的,以及如果你也想参与开源,可以从这里拿到什么。无论你是混迹开源多年的老熟人,还是第一次听说COSCon的新人,希望都能从这里找到适合自己的入口。

1. 十年同行:为什么女性开源论坛值得被认真对待

1.1 从“被鼓励”到“被信任”的十年

有人可能会问:开源不是技术中立、能力说话吗,为什么非要搞一个“女性专场”?我早年也这么想过。直到自己参与了好几年的社区运营,见了太多明明技术不错、却总在自我怀疑的贡献者之后,才慢慢明白:这类论坛的本质不是“特殊照顾”,而是把那些本来就在发生、却总被忽略的声音,放到一个所有人能看见的位置上。所谓“为她发声”,真正的含义也不是“代表她说话”,而是把话筒递过去,让她自己发出声音。

如果你翻看COSCon女性开源论坛这些年的议题变化,会看到一个很有意思的轨迹。早期更多是“如何鼓励女性进入开源”“女性适合做什么方向”这类启蒙式话题;近几年,明显转向了“女性维护者在大型项目中的治理经验”“开源商业化中的女性创业者”“跨时区远程协作中的沟通与领导力”这些非常具体的能力型议题。这个转变说明什么?说明讨论的重心已经从“能不能进来”,变成了“进来了如何做得更好、走得更远”。一个议题库走向成熟的标志,就是它不再满足于喊口号,而是开始回答“然后呢”。

第十年还在做这件事,代表它不是一个昙花一现的项目,而是一群真的在上面持续投入的人的长期工程。我用一个不太恰当的类比:开源社区像是公共图书馆,理论上谁都可以进来借书,但如果你从来没有被引导过、没有熟人带路、不知道分类规则,你很可能在门口转两圈就走了。女性开源论坛做的事,一部分是把“门口的路牌”做得更清晰,另一部分是让已经在馆里的人被看见、被信任,愿意留下来成为志愿者甚至馆长。

1.2 议程设计背后要回答的三个问题

看一份论坛议程,很多人只看时间、看嘉宾,其实一份好的议程设置,背后是在回答三个问题。你把这三个问题带到任何一场技术论坛去套用,都能看懂七七八八。

第一个问题:议题覆盖面够不够多元?如果整场全是励志故事,没有技术实践和管理经验,那只是一场“分享会”,称不上“论坛”。以我这些年看到的女性开源论坛的通用做法来说,主题分享一般会刻意拉开梯度:有人讲项目经历,有人讲代码细节,有人讲社区治理,有人讲商业观察。这种“故事+方法+技术”的混搭,是评估一份议程成不成熟的关键指标。如果全场只能让你“感动”而不能让你“带走点什么”,那这议程在水准上就是有欠缺的。

第二个问题:参与者能不能从“听众”变成“行动者”?一场会如果只让人“听”,价值至少砍掉一半。所以我一直很关注议程里有没有工作坊、破冰、现场结对、文档贡献实战这类环节。这些环节的设计意图很简单:让你别光坐着记笔记,而是当场找到一个小任务,在导师或志愿者的协助下完成第一次提交。哪怕只是改一个文档里的错别字,那种“我也能参与开源”的正反馈,比任何口号都管用。

第三个问题:男性在这个话题里有没有位置?我见过不少开发者觉得“女性论坛跟我没关系”,这其实是个误区。开源协作的根基是多元视角,一个团队如果只有一种声音,代码评审都容易漏掉盲区。所以一份成熟的女性论坛议程里,一定会留出共建者、团队负责人、男性维护者的对话空间,讨论如何建设更包容的社区环境——这不只是“尊重”,更关乎项目能不能吸引到足够多不同背景的贡献者。今年如果看到有圆桌邀请男性嘉宾一起聊“如何做一名好的开源队友”,别觉得违和,这恰恰是论坛走向务实的一个信号。

2. 议程亮点拆解:今年论坛究竟在聊什么

2.1 主题分享:技术实力与个人叙事并重

我不太确定这次最终版议程的每一个细节,但从发布信息和近年的论坛构成来看,主题分享大致会往三个方向铺。

第一类是“从零到一”的项目复盘。比如一位女性维护者讲自己把一个开源项目从几个issue做到几百个Star、从个人维护到建立核心贡献者团队的过程。这类内容最打动人的地方在于:它会把那些只能事后复盘才能看清的决策节点摊开——什么时候该删掉不靠谱的功能、什么时候要开始写贡献者文档、怎么面对“只有你一个人在干活”的疲惫期。这些经验不因为分享者是女性就没有普适性,恰恰相反,它讲的正是每个小型开源项目都会遇到的真实问题。

第二类是新手路径。比如“如何选对你的第一个开源项目”,这类实操型分享会教你怎么用GitHub的issue标签找新手任务、怎么判断一个项目是否活跃、怎么在提PR之前跟维护者打招呼。我听过太多“第一次提PR被冷落”的故事,绝大多数不是因为技术不行,而是不清楚开源协作的沟通规则。这类分享就是把规则讲透,帮新人省掉好几个月弯路。

第三类是“能力升维”的内容,比如开源项目的治理、远程团队的异步协作、维护者的精力管理。这类内容越来越受关注,因为很多人进开源是当作兴趣爱好,结果项目一火,变成了“没有薪水的第二份工作”。如何拒绝不合理的需求、如何在公司里申请开源工作时间、如何从“写代码的人”变成“带团队的人”,这些才是让贡献者长期留下来的关键。今年如果有一场主题是“请停止美化熬夜维护开源项目”,我一定是第一批冲进去听的。

2.2 圆桌对话:讨论那些“桌面之下”的真实处境

圆桌环节通常是论坛里气氛最微妙的时段,因为很多内容不是技术问题,而是人与组织的问题。从历年的议题和今年预告的方向来看,圆桌大概率会围绕社区里的隐形偏见、女性维护者的时间分配、以及开源参与与个人职业发展的关系这几个话题展开。

我举几个实际场景:群里大家讨论一个技术方案,女性成员的方案得到的是“再想想”,男性成员提出同样的方案,大家开始认真讨论;社区里总有人把女性成员的代码风格归因于“性格”而不是“专业判断”;一个女性维护者在做社区决策时,被质疑的声音往往比男维护者多一倍。这些都是所谓“桌面之下”的东西——不写在行为准则里,却真实消耗着人的精力。圆桌的价值,就是把这些模糊的感受变成可以讨论的公共话题,让没遇到过的人知道“原来这不是我的错觉”,让遇到过的人知道“原来我并不孤单”。

另一个我很期待的方向是“时间从哪来”。开源的现实是:大部分贡献者都有自己的全职工作,女性还常常承担更多家庭事务。圆桌如果能请几位真实处在不同人生阶段的维护者,聊聊她们如何在加班、带娃、通勤和GitHub之间腾挪出时间,这种“如何安排生活”的讨论,比单纯喊“加油”有用得多。毕竟,嘴上说“欢迎参与开源”很容易,但一个人如果没有可支配的整块时间,什么欢迎都是空话。

2.3 闪电演讲与工作坊:把“倾听”转化为“行动”

这几年大型开源大会普遍会设置闪电演讲和动手工作坊,女性开源论坛也会把这类环节当作重头戏。闪电演讲的魅力在于门槛低:5分钟、一页PPT甚至没有PPT,讲一个具体的小技巧、一个小故事或者一次失败的尝试。对新人来说,这是建立表达信心成本最低的方式;对听众来说,5分钟一个话题的密度其实很适合捕捉陌生领域的概貌。我会建议第一次来参加的人,哪怕没勇气上台,也一定要去听一场闪电演讲,那个场子里你能看到各种非典型开源的活法。

工作坊环节则是从“听”到“做”的转折点。常见形式包括:现场教你提人生第一个PR、GitHub Actions入门、文档写作与Markdown排版、项目Logo与视觉设计等。哪怕是完全不懂代码的同学,也能在文档工作坊里找到自己的位置。前几年有一组数字让我印象很深:一场工作坊结束,参与者现场提交的文档类PR数量,比很多项目一周收到的还多。这说明机会是被设计出来的——只要有人愿意把门槛铺平、把流程拆细,新人是完全愿意动手的。

如果你是第一次参加这类论坛,我的建议是:至少给自己安排一场工作坊。哪怕你自认为“什么都不会”,文档类、翻译类、社区协作类的工作坊大概率是零基础友好的。你带着一台能联网的电脑去就行,剩下的,现场志愿者会帮你。

3. 一场开源论坛是怎么跑起来的(组织者视角)

3.1 议程排布的节奏与细节

“议程正式发布”这六个字,外行人看是排期,内行人看是承诺。一旦发布,就意味着嘉宾全部确认、场地动线基本敲定、直播链路准备就绪,社区也终于可以拿着这张纸去约人、拉群、组织线下观会了。我曾经在社区做过几年志愿者,最深的体会是:观众看到的是“内容”,组织者操心的其实是“节奏”。一个论坛半天到一天的时间,怎么分配主题演讲、圆桌、工作坊、茶歇,是非常讲究的。

一般来说,开场半小时内不会安排硬核技术内容,而是先让参与者暖场,建立基本认同。紧接着的一两个主题分享会放在“精力最好的黄金时段”,这类演讲通常信息密度高、适合全神贯注听。午餐前后的时段人会犯困,如果安排高密度内容,现场效果一定不好,所以很多组织者会把工作坊、圆桌这类互动性强的内容放在下午,用“动手”对抗“犯困”。茶歇和休息区也不是可有可无的,开源圈很多合作都是茶歇时谈成的,这部分隐性的“社交议程”同样是议程的一部分。

还有一个很容易被忽略的细节:线上转播与线下互动的协调。COSCon一直有很成熟的线上直播体系,线上观众的数量常常比线下还要多。所以组织者要提前约定Q&A环节怎么从线上取问题、直播延迟大概多少、PPT如何在会后统一分享。这些不是光鲜的事,但没有这些琐碎安排,一场论坛的信息传达到位率会大打折扣。你看一份议程时,如果发现Q&A时间被明确标注出来了,通常说明这个团队是有经验的。

3.2 演讲者邀请与内容打磨:什么样的议题会被选中

很多人好奇,论坛是怎么选嘉宾的?我观察到的通用逻辑是:先定议题方向,再找那个方向里真正做过事的人,而不是先定“名人”。组织者会优先邀请那些在具体项目里有长期commit记录或社区治理经验的贡献者,因为只有亲身做过,才能讲出“文档里不会写”的细节。议题方向怎么来?一部分来自社区问卷和往届反馈,一部分来自志愿者团队的头脑风暴。每年大会议题征集通道会开放很久,就是希望收集到足够多来自一线的真实需求,而不是组织者拍脑袋定主题。

即使邀请到了合适的讲者,内容也要打磨。成熟的论坛在演讲前会提供Speaker Kit(讲者指南),包括演讲时长、PPT尺寸、现场设备情况、评审时间线等,甚至会安排一次线上彩排。彩排时最常发现的问题是:讲者什么都懂,但不知道怎么在20分钟内讲完。这个过程里,组织者会帮讲者做减法,告诉他们哪部分可以略过、哪部分必须展开。说实话,公开演讲对不少工程师出身的人来说是比写代码更难的挑战,因为代码面对的是逻辑,演讲面对的是人心。所以一个负责任的论坛,通常也会提供“为女性讲者准备的表达辅导”这类配套支持。

我见过最好的主题分享,往往不是技术最深的那一个,而是“只讲清楚一件事”的那一个。一个演讲能让人记住一个观点、带走一个方法,已经非常成功了。如果你自己有一天被邀请去做分享,请记住这句话:你的目标不是展示全部,而是让听众在回去的路上,大脑里能留下一个清晰的小钩子。

3.3 线上线下联动与会后跟进

一场论坛的真正价值,不只在那几天。现在多数开源社区会把议程、PPT和视频回看整理发布,但更重要的,是会后有没有把参与者导入日常的社区渠道。议程发布时看到这个论坛,形成期待;现场听完之后怎么把热度留住,才是组织者真正要解决的长期问题。

我观察到女性开源论坛这几年做得越来越好的地方,是“会议只是入口”的意识。论坛结束后,参与者可以通过社区即时通讯群组、邮件列表等方式继续交流,还可以报名参加后续的导师计划、文档义诊、新手任务认领等活动。也就是说,论坛不是终点,而是一个带人进入长期贡献通道的起点。这种“会前有预热、会中有体验、会后有承接”的节奏,才是现代社区活动该有的样子。

如果你的公司或社区也想办类似的活动,我的建议是:不管规模大小,一定要在会后48小时内发布一份“行动清单”,比如列出五个可以参与的开源项目、三个可以联系到的导师、两个本周就能完成的新手任务。行动清单越具体,参与者转化成贡献者的比例越高。这也是我从组织活动里学到的最有价值的一条经验,到现在每次复盘项目社区冷启动,都会把这条拿出来用。

4. 女性参与开源的真实门槛与破局方法

4.1 最常见的三个“我不行”瞬间

跟很多想要参与开源但迟迟没有行动的人聊过之后,我发现大家卡住的关口其实高度一致,可以总结成三个“我不行”。

第一个是“我的代码不够好,提PR会不会被骂”。这大概是所有新手共同的恐惧。开源社区的代码评审确实有直来直去的一面,但绝大多数维护者都在意新人的体验,很多项目特意设置了“新手友好”标签来照顾第一次贡献的人。退一步说,代码评审本身就是开源的价值之一,被指出问题不等于被否定,反而是最有针对性的免费指导。你想想,平时去培训班学技术要花钱,而在开源社区,有经验的人免费帮你看代码、提建议,这账怎么算都不亏。

第二个是“我好像不够资深,没什么能贡献的”。有一种误解是“只有大神才能参与开源”。但一个成熟开源项目,代码只占工作的一部分,Issue梳理、文档撰写、翻译、设计、社区运营、测试反馈,全都是贡献。很多项目最缺的恰恰不是高端代码,而是文档维护和社区运营。你用不上“会写编译器”的本事,能把自己日常遇到的坑整理成一篇清晰的文档,就已经是很有价值的贡献了。换句话说,你不需要先成为大神才能参与开源;恰恰相反,你正是通过参与开源,才一步一步成为大神的。

第三个是“不知道从哪开始,怕坚持不下来”。这个问题的答案很简单:别一上来就立“长期贡献”的Flag,先完成一个小任务再说。你完全可以当“游客”开始——修一个错别字、改一处过时的安装说明、给一个新功能提交一次使用反馈。等到你跟维护者在issue里来回对话过几次,自然就找到留下来的理由了。如果那个项目氛围友好、维护者回复及时,你大概率会想继续做;如果体验不好,你也能借此看清楚自己不喜欢什么样的社区,及时止损。开源是一场双向选择,你也在面试它们。

4.2 走出第一步:文档、翻译与社区事务

如果你现在想参与开源,问我从哪里开始,我会推荐一个几乎不会被拒绝的路径:从文档入手。

大多数开源项目的文档都存在两个问题:要么不完整,要么更新滞后。而文档贡献的门槛极低——你只需要会读文档、能发现问题、愿意提一个Pull Request。以我自己的经历为例,我第一次给一个开源项目提交贡献,就是在使用过程中发现安装步骤少了一步依赖配置,于是按自己的踩坑记录提交了一个修改。维护者很快合入,还专门在release notes里提了一句。那种“我的名字出现在别人项目里”的感觉,是会上瘾的。

类似地,翻译工作也很有价值。很多优秀项目的文档没有中文版,或者只有机翻质量很差的版本,你可以利用自己的双语能力填补这个空白;翻译不仅能帮你吃透项目原理,还会让你在社区里快速刷脸。社区事务方面,帮忙回答新手问题、整理issue模板、维护活动日历,同样是把“路人”变成“熟人”的路径。女性开源论坛的志愿者团队里,有大量从参会者变成组织者的人,她们最初做的事情往往就是“在会场帮忙递话筒”这种小事,但小事做久了,就变成了对社区的归属感。

给一个再具体不过的起步公式:找一个你平时就在用的开源工具,打开它的仓库,在“Issues”里搜标签为good first issue的条目,挑一个你能力范围内的,先评论“我想试试”,再按贡献指南动手。整个过程不要求你写多惊艳的代码,但要求你学会读文档、提问题、遵守规范——而这恰恰是开源协作最核心的软技能。等你走完这一轮,下次再看到“女性不适合搞开源”这类论调,自己心里就有答案了。

4.3 社区、企业与导师制度能做些什么

个人能做的有限,环境才是决定留存率的关键。一个社区如果只有代码、没有行为准则,新人在缺乏安全感的情况下很难深入参与。这也是为什么成熟的国际开源项目普遍会有行为准则和举报处理机制,这不是“麻烦”,而是为不同类型的人提供安全参与的基础设施。在开源大会的语境下,“是否提供友好场次”“是否设置无歧视的Q&A规则”“是否鼓励多样化的讲者阵容”,都是这类基础设施的延伸。

在女性开源论坛的生态里,导师制度特别值得多说两句。简单说,就是给新人配一位有经验的贡献者,定期交流、答疑、结对提交任务。导师不一定要是“大神”,比新人多走了半年的普通人反而往往更合适,因为他的经验刚刚经过“可复述”的阶段,更能理解新人的困惑点。很多国际开源社区都有官方的导师计划,把“mentoring”写进项目文档,你作为新手甚至可以直接在issue里请求 mentorship;如果社区还没有这个机制,也可以主动在社区群里问一句“有没有人愿意带我提第一个PR”,通常都会有热心人回应。

企业侧也一样。越来越多的科技公司设有开源办公室,鼓励员工用工作时间的固定比例参与开源,并承认外部开源贡献在晋升评估里的价值。如果你的公司有这样的政策,大胆去用;如果没有,也可以联合几位同事向管理层提案,拿“开源贡献能带来技术影响力、招聘吸引力和社区反馈”来说服决策者。这条路径,我在不止一家公司验证过,比想象中更容易被认可,关键是你要先把话说出来,而不是默认“公司肯定不批”。

5. 参会前你需要知道的几件事

5.1 议程信息与选场建议

一旦最终版议程公布,面对几十上百场分享,怎么选场是门学问。我的建议是先按“目的”选,而不是按“名气”选。

如果你是想找项目或找伙伴,优先选择工作坊和闪电演讲,因为这两个环节互动密集,最容易认识人。如果你是带着具体的技术问题来的,优先选择主题分享,因为系统化讲述能把一个话题从头到尾讲透。如果你是管理者或社区运营者,圆桌和专题讨论一定不要错过,这类场合的信息密度和信息增量往往是最高的。另外,议程页面上通常标注了每个场次的难度等级或受众标签,看到“新手友好”“零基础可参加”这类字样的场次,放心大胆往里面坐,那些内容就是专门为你准备的。

还有一个常被忽略的小技巧:同一时段有多场分享时,不要只看嘉宾title,要看演讲的“题目写法”。讲“我踩过的坑”和“最佳实践”的演讲,通常比“XXX项目介绍”更有学习价值。前者是真实经验的浓缩,后者更像宣传材料。一份好的日程表本身就带信息量——如果一个论坛的议程里有大量“how we did it”式的标题,这个论坛的内容质量大概率不会差。

5.2 第一次参加开源大会的实操清单

我第一次参加开源大会时,犯了两个典型的错误:一是把日程排得太满,二是光顾着听,没怎么跟人说话。所以这次给你一份可以直接用的清单:

  • 提前一天乘客地熟悉会场动线,找到论坛所在的分会场和休息区。
  • 包里带好电脑和充电宝。工作坊需要动手,充电口在人多时永远是稀缺资源。
  • 提前准备一段30秒的自我介绍,说清楚“我是谁、我在做什么、我对什么感兴趣”,遇到想认识的人就能自然地开启对话。
  • 在Q&A环节勇敢举手,哪怕只问一个很简单的问题,提问本身就是最好的破冰方式。
  • 会后当天把想跟进的人记下来,48小时内发一条消息,附上你们聊到的具体话题,不然过两天你大概率会忘记。

前面几条都很直白,只有最后一条,我多说两句。我见过太多人参加完一天的会,手机里多了几十个好友,但一个都没深聊。问题不是认识的人不够多,而是没有“及时跟进”。你当天晚上发一条“今天听你讲XX那段很有共鸣,下次可以聊聊”的消息,成本极低,效果却比过了一个月再假装偶遇好上一百倍。开源圈的社交不是维护人脉,而是真的找到聊得来的人一起干活。

5.3 一些我踩过的坑和观察

最后分享几条观察。第一,参加女性开源论坛不一定非得是女性,我见过很多男性维护者在这里学到了如何更好地带新人、如何建设包容性的社区氛围,回到自己的项目里实践,效果立竿见影。第二,别被嘉宾的“大厂title”迷惑,很多最有价值的分享恰恰来自那些中小项目的维护者,他们的经验离普通开发者的日常更近。第三,线上参会的体验在逐年变好,但如果你有条件,尽量到现场,因为茶歇和晚场交流才是开源大会的灵魂所在,这些是直播无法替代的。

针对第一次参会的朋友,这里附一张常见问题速查表,都是我这些年被问过最多的问题:

问题我的建议
线上参会还是现场参会?有条件优先线下,茶歇与晚场交流信息量极大;线上适合事后回看硬核内容。
议程太满怎么办?一天至少留出两段空档,别为了多听一场牺牲跟人交流的机会。
听不太懂怎么办?优先去新手友好场次和工作坊,不懂就问身边的人,开源会场的开放度比想象中高。
社恐如何破冰?从工作坊和志愿者服务切入,有共同任务是破冰的最好方式。
会后如何持续跟进?48小时内给认识的人发消息,并列出“本周可完成的一个开源小任务”。

还有一点,也算是我自己这些年最大的体会:开源社区里的“被看见”,从来都不是靠等来的。它需要你主动写一份文档、提一个issue、在一次活动中举起手,也需要社区和组织者为这些行动搭建台阶。女性开源论坛做了十年,本质上就是在搭这些台阶。搭台阶的人不全是女性,走台阶的人也不全是女性,但台阶本身是给所有人用的。

我个人在实际参与中最大的收获是:开源这件事,比的从来不是谁一开始就厉害,而是谁愿意在“还不够好”的时候先动手。女性开源论坛十年同行,把很多这样的人聚在了一起,也让更多还在门口观望的人,有勇气迈出第一步。如果你今年有机会到现场,我很建议去女性开源论坛坐坐,哪怕只听一场、只问一个问题、只提交一个小文档修改,你都会发现一个和想象中不太一样的开源。十年之后再回头看,今天迈出的每一小步,都会成为后来者脚下的台阶。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/9/29 21:05:36

ISP、ICP与IAP:芯片烧录的通道哲学与实战避坑指南

1. 芯片烧录的本质:从 Flash 的视角看问题很多新手第一次接触单片机时,总会被一套陌生的说法搞懵:“给芯片烧录一下”“用 ISP 下载”“需要 ICP 烧写”“做了 IAP 才能远程升级”。听起来像三个完全不相关的操作,实际上它们都是同…

作者头像 李华
网站建设 2026/9/29 21:04:15

2026年专访杭州亨得利售后:哪些腕表养护项目不建议盲目做?

引言杭州地处江南,梅雨季湿度高,常年温润多雨,本地表主在腕表佩戴与养护上面临着和北方城市截然不同的环境挑战。很多腕表爱好者在社交平台看到各类腕表养护推荐,从深度清洗、表壳抛光到机芯油泥清洁,五花八门的项目让…

作者头像 李华
网站建设 2026/9/29 21:03:48

Python 操作 MySQL 建表与插入数据:TaoToken 统一 Key 配置实战

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

作者头像 李华
网站建设 2026/9/29 21:02:47

【信息科学与工程学】【通信工程】第一百八十七篇 5G-A/6G行业应用场景及对网络的需求01

编号 类型 领域 应用场景 5G-A组网/承载网所有需求列表 数学方程式列表 算法设计 拓扑设计 参数设计 数值设计 关联知识和标准法律法规 01 大规模MIMO与波束赋形优化 无线空口/多天线理论 5G-A万兆下行、千兆上行、毫米波热点、6G太赫兹与XL-MIMO 需求包括:频谱…

作者头像 李华
网站建设 2026/9/29 21:02:33

DeepSeek Harness 深度调研报告:Agent 插件机制与 Cordis 配置实战

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

作者头像 李华
网站建设 2026/9/29 21:01:05

【在Linux上升级nginx】

1.查看生产环境nginx版本 cd /usr/local/nginx/sbin/ (后边这个地址是nginx启动的地址) ./nginx -V 1.解压下载的nginx包(我的是源代码编译版用于内网安装) tar -zxvf nginx-1.30.5.tar.gz cd /home/software/nginx-1.30.5/ 3.对新版本的nginx进行配置 …

作者头像 李华