这场分享讲的是一支非典型团队的工作方式。蒋豪群从 2018 年起全职参与开源；按他在片中的介绍，当时公司全职成员很少，项目协作网络却包括来自不同国家、以兼职或志愿方式参与的开发者。因此，他的经验同时涉及受雇工作和开放社区，不能直接当作所有远程公司的制度样本。
录播开场时，他介绍自己在 Vue Technology LLC 工作约四年。全职雇员当时只有他和项目创始人两人，但围绕项目工作的协作者有数十位，分布在许多时区。一个会议里既可能有全职成员，也可能有兼职或志愿维护者；讨论任务、协调时间和确认责任，都不能照搬普通单一办公室团队的节奏。
蒋豪群的分享录播发布于 2023 年 3 月 8 日，活动举办日期未确认。成员规模、工具选择、收入与合同安排均为当时情况。
从招聘启事到长期工具链维护
蒋豪群是在社区看到招聘文章后投递简历，经过面试加入，并非先长期给 Vue 提交代码才获得工作。作为早期全职成员，他与团队一起逐步磨合流程，一直以个人贡献者的身份参与，没有承担管理岗位。
他看到招聘文章时，判断全职远程工作与自己的处境相合，便抱着“试一下也没有损失”的想法投递。经历筛选和面试后加入，他是公司最早的成员之一，因此后来讨论到的协作方式并非入职前就有一份完整手册，而是在处理真实问题的几年里逐步形成。这个路径与问答中“先大量给项目提交代码，再被吸纳进维护团队”的路径不同。
工作内容也不是招聘文案的静态清单：初期偏向具体功能实现，后来更多投入工具链维护。这类事务可能琐碎、枯燥，却需要持续投入和大量沟通。初入职时，他也并非每项工作都能立即独立完成，仍需要指导；原先设想的功能可能缩小、换一种实现，或者因更好方案出现而取消。因此，他鼓励有一定匹配度的人尝试投递，不必把招聘描述理解为入职第一天就要掌握的全部能力。
他进一步解释工作重心为何变化：招聘时列出的若干功能完成一部分后，项目并不会停止产生新的需求。构建工具、维护工作、与不同贡献者沟通，变成需要全职投入的日常。他始终是 individual contributor，而非通过管理别人完成任务。外部参与者若只看 GitHub 讨论，也未必知道他是一名全职雇员。
英语首先服务于把事情讲清楚
全球协作要求基本的英语读写能力，但团队大量沟通通过文字异步完成。他认为，表达意愿、工具使用能力，以及能否先想清楚自己要说什么，往往比一开始就写出流利英文更关键。他刚加入时，英文回复也需要憋很久；在反复处理真实问题的过程中，常用表达才逐渐熟练。
进入全英语环境后，他发现自以为够用的读写能力仍有缺口。在 GitHub 上回复一个 issue，刚开始要想很久才能写出一段文字；但技术问题本身想清楚后，可以先用熟悉的语言列出要点，再把英文表达整理好。重复处理同类问题，常用语法和词汇才慢慢变成工作习惯。他没有要求求职者一开始便能即兴用英语长篇演讲。
片中提到翻译、语法检查和当时的新一代 AI 写作工具，都是帮助降低语言摩擦的手段。他自己的做法是先写出要点，再根据工具提示修改语法与用词。这里记录的是其使用经验，不是对这些工具当前准确率的评测，也不能据此把技术事实判断交给生成工具。
他曾购买 Grammarly 的付费版，先把想说的话写出来，再按提示检查语法和措辞。翻译工具和当时刚出现的 AI 写作工具，也可以帮忙整理正式邮件。但发信者必须知道中心意思是什么：工具能改善英文外形，不能替自己判断一段技术讨论究竟要达成什么结论。
同步会议则需要另一层准备：预先确定议程，提前写下要讲的内容，必要时准备完整发言稿。这样即使临场发挥有限，也能完成沟通；同时要能听懂对方，愿意开口。片中对 AI 生成正式英文邮件的展示，也落在同一前提上：本人先明确中心意思。
蒋豪群把线上英语会议比作一场有题目的发言：若议程提前给出，就先写下要报告的问题、希望别人作出的决定和可能追问，必要时写逐字稿。这样不擅长临场组织英语的人仍能参与；同时他特别强调听力，因为准备好的稿子不能覆盖其他人的即时回应。“敢说”在他看来比追求每一句都完美更重要。
时间自由不等于工作自动减少
团队按任务完成情况交流，不以在线时长作为主要汇报内容。他描述自己的工作量仍接近正常全职工作；生活节奏较平衡，在他看来更多来自公司文化，而不是远程办公这个形式本身。
他给出的量级是一周约四十小时。团队关心的是计划中的事情是否完成，因此白天去医院、体检或处理手续并非凭空多出一段休息；工作若被打断，仍要另外找时间完成。这个自由要求自己能预估任务，也能在需要时停止工作。
他经历过两个容易失控的阶段。刚开始，海外同事在自己下班后讨论技术，他忍不住看消息、开电脑，工作时间反而变长。后来，白天可以自由出门办事，但任务仍要完成，晚上补做时又容易因为身边缺少共同作息而一直工作下去。频繁打断再补偿，不一定比稳定工作更轻松，也会妨碍协作。
第一阶段的问题不是公司要求加班，而是全球团队的消息始终有人在发：轮到海外同事上班时，他已下班；手机里看到技术讨论或被提及，便又打开电脑看代码。到第二阶段，他学会白天去办私事，却发现每周任务不会因此减少。下午外出、晚上补做，再加上没有与周围人一致的下班时间，常常一做就做到深夜。这样的节奏不仅使自己疲惫，也让同事难以预测何时能与他协作。
后来的调整是参照家人的正常作息，尽量建立可掌控的工作时段。地点也需要主动选择：他发现安静的咖啡馆或共享办公空间有时比家里更适合自己，建议寻找稳定、少干扰的工作环境。片中对在家和在外效率的比较是个人体感，不能当作所有人的量化结论；当时涉及疫情的出行顾虑也属于历史背景。
他的办法不是把日程排得毫无弹性，而是让主要工作时段尽量与家人正常上下班的节奏重合，到点能比较安心地停下来。空间上，他也发现“能在任何地方工作”不等于“家里总是效率最高”。按他个人经验，在家可能从早忙到晚饭后，完成的工作量却不如在安静咖啡馆集中做几个小时。远程工作仍需要一个可靠的工作场所，只是这个场所不一定是雇主的办公楼。
异步讨论要带着主题和方案
跨城市、跨时区协作，很难靠连续追问逐步拼出问题。蒋豪群强调，每次讨论最好有明确主题，并带上自己的方案。否则一句话与下一句之间可能隔几个小时，沟通链路会被放大。
他解释为什么随手丢一句“这个怎么做”不够：同在办公室时，几轮口头追问可以在几分钟内补齐背景；不同城市的人可能隔几个小时才回复一条消息。于是发起讨论时，最好把目标、当前做法、卡住的点和自己的建议放在一起。对方上线后可以直接处理同一个问题，而不必先用半天问出问题是什么。
团队最初围绕 GitHub issue 讨论，也使用 Slack 的话题线程；后来进一步利用 GitHub Discussions，并迁到 Discord。选择背后的考虑包括话题组织、开放参与和当时的成本：一个总问题可以展开多个子讨论，彼此不必打断；同时在线时可以直接聊天，需要深入讨论时则另开主题。具体产品和收费条件可能变化，可延续的做法是让讨论有上下文、能回看、能分支。
issue 适合围绕具体问题形成可追踪的记录，但较大设计议题一旦同时出现几个子问题，线性的评论就不好阅读。Discussions 更像论坛，能容纳较长的讨论；Slack 和后来使用的 Discord 则提供话题线程，让正在进行的日常聊天不被一场深入辩论淹没。迁移工具时，团队也考虑了费用和社区参与的便利。蒋豪群关注的不是某款软件本身，而是选一个能让异步成员找到背景、接上讨论的结构。
把进度同步、共同讨论和感情交流分开安排
因许多成员不是全职，片中的团队约两周开一次视频会。最初会议主要同步进度，后来发现隔两周逐人念一遍周报的投入产出有限，纯进度信息完全可以书面传递。
双周会若只让每个人汇报两周里做了什么，听到的信息已晚于 GitHub 上的记录，也难激发参与。团队于是把进度放在文字中，把珍贵的同时在线窗口留给新的特性设计、难定位的问题，以及需要几个参与者一起决定的事项。这比简单增加会议频率更符合兼职维护者难以随时到场的情况。
调整后的正式会议更多用于新特性设计、难以解决的问题和需要多人协调的事项；另设共同在线工作的时段，让大家开着摄像头各做各的事，偶尔聊天，模拟线下共处。这种 co-working session 承担的是关系与情感交流，不能替代需要形成决定的正式讨论。
co-working session 则不要求每个人都围着同一份议程发言。成员选一个共同空闲的时间，开着摄像头各自写代码、处理其他工作，偶尔聊上几句。这填补了全远程团队缺少“坐在一起”的一面；真正需要确定方案的议题，仍在正式会议或可回看的文字讨论中处理。
跨时区排会则采用可用时间投票和日历预约工具：大团队先汇总各自当地的空闲区间，小范围沟通再预约具体时间，并在夏令时切换时调整。实际体验并非完全自由——他的会议经常落在东八区晚上，有时更晚。问答进一步说明，排期也会照顾成员的家庭安排，而不是只按职位决定谁迁就谁。
具体做法是：要协调十几个人的双周会时，用 Doodle 收集各人在本地时区可参加的时间段，再选大多数人能到的时刻；与一两名同事或外部人员约谈时，用 Calendly 直接开放预约。夏令时变化后，团队还需重新找重叠时间。他通常在晚上九、十点开会，偶尔到十一点；工具能减少来回确认，却不能创造不存在的时区交集。
生活选择与团队关系
对蒋豪群而言，远程工作让他可以住在家乡、陪伴家人。但他没有把这种生活写成唯一优解：在城市、线下活动和业余娱乐方面，他也观察到一些正常上下班的朋友拥有更丰富的选择。应比较的是自己需要的生活，而不是用远程标签直接判断自由程度。
被问到如何增进团队感情时，他认为条件允许时线下见面、参加大会仍有帮助。片中提到过去几年线下见面很少，是当时的实际经历，不能延伸成永久只在线协作的规则。
问答：如何进入开源、团队靠什么运行
从什么贡献开始？他列出的入口不只有写代码：翻译文档、回答 issue、帮助用户解决核心成员来不及处理的问题，都能创造价值。相较偶尔出现一次的高水平贡献，持续、可靠的输出更容易让团队认识你。他举出持续投入几个月后被团队注意到的可能性，但这不是固定考核周期或录用承诺。
主持人问怎样进入开源项目，蒋豪群把“知道办法”与“坚持去做”分开。他说文档总有可以改善或翻译的部分，用户问题也远多于核心维护者能及时回答的数量；一个人即使尚未准备好改核心代码，也可能知道某个问题的解决办法。团队也见过能力很强却只偶尔出现的贡献者。能在一段时间里持续答疑、修文档或提交代码，别人才能逐渐判断他是否可靠。
必须先成为深度贡献者才能应聘吗？他的个人路径并非如此：加入前使用 Vue 做过项目，但没有为其提交过代码。招聘进入全职岗位与通过社区贡献加入维护团队，是不同路径，不宜混为一个门槛。
开源项目怎样获得收入？按他当时对 Vue 的介绍，主要是社区捐赠，另有网站广告和少量合作。这个回答只说明该项目当时的构成，不能推出开源项目普遍依靠同一种商业模式。
年龄与加入团队的流程呢？他描述团队更关注在线技术讨论中的可靠性、能力与持续贡献，不会先了解每个人年龄。加入也没有统一的固定考察期：成员注意到持续贡献后，可以提出邀请或提名，再征求团队意见。这是该团队的实践，不代表远程行业不存在年龄门槛。
追问具体的“考察期”时，他没有给出几个月的硬线。团队看到一位仍在读大学的贡献者近来频繁提交代码，认为其技术和投入都可信，就有人提名、与其他成员商量，再把他加进来。维护者之间原本很少线下见面，年龄并非他们做决定时首先掌握的信息。这说明公开的技术讨论和持续交付如何替代一部分线下熟识，并不等于每个组织都以相同方式招人。
合同、结算和税务如何处理？最后的问答讨论了他当时采用的跨境合作安排，也提到由境内名义雇主参与的另一种模式，以及个人申报境外收入的经历。他同时指出具体法律关系因人而异。他自己的合同与申报方式只能说明当时的个人实践；实际安排还要按所在地、合同和届时规则核实。