很多人问过我一个挺扎心的问题一个做消息中间件的开源项目跑去开源集市摆摊到底能有什么效果毕竟集市的画风通常是各种硬件开发板、AI 应用、手工艺品周边谁会在逛展的时候停下来听你讲 Pulsar 的消息保留策略我的答案很简单效果比你想的好得多。这个周末我参与了 COSCon 2025 开源集市以 Apache Pulsar 社区展台志愿者的身份跟形形色色的路人聊了两天 Pulsar。这篇文章不打算写成官方的活动总结而是从我的实际操作角度聊聊开源集市的布道思路、现场准备了什么、怎么跟不同的人介绍 Pulsar、被问得最多的问题有哪些以及我们踩过哪些坑。无论你是在筹备一个开源项目的展位还是单纯想了解开源集市这种线下场景怎么玩这篇文章都应该能给你一些参考。1. 为什么在开源集市摆一个 Pulsar 的展台我的布道逻辑1.1 集市和主论坛是两种完全不同的“信息密度”很多人分不清主论坛和开源集市的区别但对我来说这两个场景的信息传播模型完全不同。主论坛是“一对多”的单向输出听众坐在椅子上PPT 翻页的速度决定了信息密度讲一个小时能覆盖三四个核心主题已经算高效。而开源集市是“多对多”的双向对话每一个展位都是一个微型的交流节点路过的潜在用户自己决定要不要停下来。集市里的交流有一个主论坛不具备的优势访客带着问题来。他们不是在被动接收信息而是真的会凑过来问“你这个项目是干什么的”“能解决我什么问题”。这种主动提问带来的对话效率比会场里听两个小时演讲高得多。哪怕只是三分钟的交流对方离开的时候记住了一个特性这个展台就算成功了。当时团队里有人担心Pulsar 这种偏底层基础软件的项目可能不如 AI 应用或者嵌入式硬件容易吸引路人。但我的判断是逛开源集市的人群结构其实很垂直学生、开发者、企业技术负责人这些恰恰是消息中间件最核心的潜在用户群。他们缺的不是技术资料而是一个能面对面交流的场景。1.2 消息中间件在集市上真的有受众吗先给结论有而且比想象中多。我们展台做过一个简单的统计两天下来主动停下来问“Pulsar 是什么”的访客里大约四成是后端研发或者数据工程师三成是正在学消息队列的学生剩下两成是做技术选型的技术负责人或架构师还有一成纯属好奇被展台上的拓扑图吸引过来的。为什么基础软件在集市上不愁没人听因为逛开源集市的这批人本来就是带着“看看有什么好东西”的心态来的。他们对新技术有好奇心不会因为你讲的是消息系统就绕道走。反倒是我们自己的姿态很重要别摆出一副“我是大佬”的架势而是真的站在对方的角度想一个没听过 Pulsar 的人最先需要知道的是什么。我自己定的开场原则是绝不等对方问“你们是干嘛的”而是主动搭话。看对方是学生模样就先问最近在做哪个方向的项目看到背着双肩包、穿着随意但眼神专注的大概率是工程师直接抛一句“你现在生产环境用的什么消息队列”就能打开话匣子。让对话从对方的处境开始比从 Pulsar 的功能列表开始要自然得多。1.3 展台目标不是加微信而是完成一次有效对话我们内部聊目标的时候出现过两种声音一种觉得集市就是要尽量多收集联系方式另一种觉得派发物料数量就是 KPI。最后我拍板定了一个完全不同的标准让每个停下来的人在离开展台时能够用自己的话复述出 Pulsar 的一个差异化特性。为什么定这个目标因为加微信和拿物料都只能证明“人到过展台”不能证明“人记住了东西”。如果对方离开时能说出“Pulsar 是存储和计算分离的”“Pulsar 可以无限量积压消息而不是把磁盘打爆”“Pulsar 支持分层存储把历史数据丢到对象存储”哪怕只有一句这个对话就是有效的。这种对话积累起来才是社区长期增长的基础。后续复盘也证明这个思路是对的。我们现场收集到的有效需求线索几乎都来自那些临走时能把某个特性复述清楚的访客。他们回去之后真的会在社区群里进一步提问甚至有人第二天又跑回展台接着聊。2. 开展前的准备物料、Demo、分工一个都不能少2.1 没有 Demo 的展位是没有灵魂的逛过开源集市的朋友应该都有同感一个展位如果只放易拉宝和传单基本留不住人。人对静止的文字是免疫的但对屏幕上动起来的东西会多看一眼。所以整个筹备阶段我们把最多的时间花在了 Demo 设计上。我的要求很简单两分钟内能完整演示一遍不能依赖公网环境最好一台笔记本离线就能跑。最终我们采用的方案是在笔记本上跑一个 Pulsar standalone 模式的本地实例整个环境用 Docker 容器打包好。现场演示流程分三步每一步对应一个 Pulsar 的核心卖点。第一步演示基础消息收发用命令行命令行敲入 producer 发送一条消息consumer 立刻在另一个终端打印出来。这个演示对技术小白也友好大家一看就明白“哦这是个消息管道”。第二步演示 Pulsar 的多订阅模式在同一个 topic 上同时启动一个共享订阅的消费组和两个独立消费者让访客亲眼看到消息如何在两种模式之间分流。第三步演示分层存储把一个 topic 的保留时间设得很短再触发 offload 任务展示历史数据自动沉降到对象存储的过程。这个演示的效果最好因为大多数人第一次意识到“消息堆积”原来可以不用堆在本地磁盘上。设备方面多准备了一台备用笔记本和一根 HDMI 线事实证明这个决定救了命。第一天上午我们那台主力笔记本在一个高强度问答之后卡死了备用机十分钟内顶上展台几乎没出现空窗期。我想说的是开源集市的互动强度远高于你坐在办公室演示——围观的人一多机器散热和负载压力都上去了弹幕式的提问还会影响你的操作节奏。所以 Demo 脚本建议提前演练至少五遍做到闭着眼睛也能敲命令。2.2 传单怎么设计才不会被随手扔掉物料是开源集市的第二战场。我的经验是物料要分三个层次准备递给每个人的轻量单页、留给深度对话的技术手册、便于线上持续触达的二维码入口。轻量单页做得克制一点不要试图把所有功能都列上去。我们看到太多展位的宣传单恨不得把 README 上的几百个功能点全印上去访客拿起来看一眼就觉得信息量太大直接放弃。我们选择只讲三个差异化场景旁边配一个小图说明。三句话就能讲完第一句“Pulsar 是 Apache 顶级项目云原生消息流系统”第二句“存储计算分离broker 无状态扩缩容不用搬数据”第三句“原生支持多租户、分层存储、跨地域复制”。剩下的就让访客在展台问这样反而打开了对话空间。深读手册反而要做厚。现场聊得深入的人需要带走实质性的内容比如部署架构参考、核心配置项说明、社区资源列表。我们把社区里几篇高频使用的架构解析文章整理成了一份十来页的小册子现场效果相当不错。第二天甚至碰到一个工程师回来说昨晚把小册子翻完了今天专程来问多租户权限模型的细节。二维码入口也留了但没放在物料显眼位置而是贴在展台侧面和名片背面。集市的访客普遍很排斥“先扫码再聊”的套路所以我们的原则是先聊透了再给对方选择是否扫码而不是见面第一句话就让人家扫码关注。2.3 现场礼品和互动环节的选择集市上送周边的展位很多但大多数互动方式很敷衍——扫码关注就送。这种模式吸引来的人领完东西就走了根本不会跟你聊技术。我们设计了一个小互动把 Pulsar 架构里几个核心概念做成问答卡片答对一道题就能选一个小周边答错也没关系现场工作人员会把正确答案讲给你听。后来发现这个互动天然起到了人群筛选作用。愿意停下来翻卡片的至少是对技术有好奇心的人真正想拿周边的也会因为要答题而不得不在展台前停留几十秒这几十秒就足够我们完成一次有效的技术科普了。题目的难度也做了区分有一两道送分题也有关于 BookKeeper 存储模型的进阶题现场经常出现一个人答对了不过瘾拉着同伴来挑战的情况。互动这部分的投入产出完全值得。周边成本并不高但带来的停留时长和对话深度是单纯发物料比不了的。2.4 人员排班与“值班话术”的统一开源集市的体力消耗很容易被低估。从早上开市到下午闭市被访客围着连续聊上几个小时嗓子和精神状态都会很快下滑。我们团队一共去了六个人排成两组轮班每两小时一轮确保展台前始终有精力充沛的人值守。轮换制度最重要的作用不是保证有人在场而是保证在场的那个人始终是“有状态”的。开市前我们用了一个小时统一话术。不是说要把话说死而是每个值守的人都准备三个不同长度的讲解版本30 秒版本用于吸引路人只讲 Pulsar 是什么、跟 Kafka 比的核心差异3 分钟版本用于基础科普把存储计算分离讲清楚10 分钟版本留给深度技术交流需要能对着架构图把数据写入流程从头到尾讲一遍。这个准备非常有效它保证了不管谁来值守访客得到的信息质量是一致的。这里说一个我们自己总结的经验统一话术不是让所有人背同一段词而是约定“关键信息点”必须覆盖用什么话讲可以自由发挥。如果每个人都自由发挥容易出现讲了半天对方还是没能记住一个核心特性如果完全背词又会显得像机器人。把握好这个度展台的专业感就出来了。3. 两天现场实录我如何跟三类访客聊 Pulsar3.1 学生群体从“这门课作业要用消息队列”聊起学生群体在集市里占比很大也是我们很重视的交流对象。第一天上午来了一个男生背着书包站在展台前看拓扑图看了好一会儿我主动问他平时用什么技术栈他说课程项目里用 Kafka 做过一个简单的日志采集系统但遇到了一些问题。这样的开场就很好聊。我没有上来就列举 Pulsar 的二十个特性而是问他遇到的具体问题是什么。他说数据量一大消费者就追不上生产者的写入速度而且导师建议他处理积压时不要一直加消费者因为分区数上限就摆在那里。这个场景讲 Pulsar 的独立分区和无状态接入层简直再合适不过我让他现场打开我们准备好的 Web 端监控界面把 topic 的分区数改成 8 个再改成 16 个然后演示生产消费的吞吐曲线变化他肉眼就能看出水平扩展带来的效果。对于学生我通常会额外推荐他们去社区把官方文档中的概念解析部分看一遍。学生最需要的是建立起对整个领域的地图感而不是急着学某一项具体技能。Pulsar 的设计理念其实是了解云原生消息系统非常好的切入口因为它把计算、存储、元数据几个层面拆得清清楚楚理解了它的架构回头再看别的消息系统会轻松很多。两天里遇到好几个学生都是这样一开始只是想问“考试会不会考”聊到最后变成了研究架构设计的讨论我觉得这才是集市该有的交流氛围。3.2 后端研发直接上手聊架构细节蹲在展台前不走的多半是真正在生产环境用过消息队列的后端工程师。他们对基础概念基本不陌生关心的是更务实的点怎么迁移、怎么运维、有哪些坑。第二天下午遇到一位工程师他们团队目前用的 Kafka 集群规模不小最近在调研新的技术方向。他在展台前听了大概五分钟直接抛出一个问题“Pulsar 的 IO 隔离到底是怎么做到的”这是行家才问得出的问题。我从数据写入流程讲起生产者先把消息发给 brokerbroker 只会做一次内存拷贝然后写入 BookKeeper实际上写入操作直接发生在存储层。再加上读操作和写操作的流量分别由不同的线程池处理简单说就是读写互相不拖后腿。他听完很感兴趣又问了一个很细的问题BookKeeper 的多副本写入会不会带来额外的网络开销。这问题戳到点上了我直接承认会但告诉他 Pulsar 的做法是把多个分片分布在不同的存储节点上同时通过一致性协议确保读写不丢数据。关键是要理解 Pulsar 追求的不是零开销而是在可接受的范围内换取了极大的弹性和故障隔离能力。这种对话让我很享受因为对方是真的在用工程思维审视方案。跟后端研发沟通我有一条底线原则不吹捧不回避短板。消息中间件的选型从来不是全都要而是在约束条件下的权衡。你来摆展台,如果只挑好的说被问住几个务实问题就露馅了。倒不如一开始就把适合的场景和不适合的场景都摆清楚反而更能建立信任。3.3 企业技术负责人重点讲可控性与运维成本技术负责人逛展台的风格完全不同。他们不太会花时间看命令行演示通常走到展台前先扫一眼易拉宝然后问的几乎都是同一类问题“这东西能扛多少量”“成本高不高”“团队要花多长时间能上手”。面对这类访客我的讲解重点会把特性翻译成经营语言多租户意味着不同业务线可以共用一套集群但是数据完全隔离不用为每条业务线各维护一套分层存储意味着历史消息可以放在对象存储上整体存储成本能降下来一个量级无状态 broker 意味着扩容时不需要搬迁任何分区数据运维操作从“需要申请变更窗口”变成“随时可以做”。这三条解释完对方基本就能理解 Pulsar 长期运维的结构性优势了。有一位做金融科技的技术负责人问得很细他关心的是故障场景下的表现。我说了几个关键点首先是多副本机制数据写入 BookKeeper 就是强一致的其次是故障域感知可以配置把不同副本分散到不同机架甚至不同可用区最后是读数据时的持久性保证只要消息写入成功返回就绝对不丢。他没说信但眼神里我看到的是他在认真评估。集市这种非正式场景有一个好处谈话气氛没有会议室那么严肃聊到后来他甚至主动加了社区群说回去让团队把文档互相传阅一下。这种用户就是典型的“一个顶十个”值得在展台前聊久一点。4. 现场被问得最多的问题五个高频技术话题复盘4.1 Pulsar 和 Kafka 到底怎么选这是被问到次数最多的问题没有之一。学生问工程师问技术负责人也问。我的回答框架基本固定这两个项目的定位在很多时候是重叠的但模型上有本质差异。Kafka 的存储和计算是耦合在同一个 broker 进程里的扩展分区数上限时迁移分区数据是很重的操作。Pulsar 把存储层独立出来broker 变成轻量无状态接入层存储单独扩展不用动数据。为了让人快速理解我喜欢用这个类比Kafka 像一家餐厅厨师同时兼任服务员生意好了想加几张餐桌厨师得先把菜做完才能去摆桌子Pulsar 是后厨和前厅完全分开服务员只管点单传菜厨房要扩灶台就直接扩不影响前厅。这种解释在现场效果极好大部分人听完都会点头。我在对比表里也会列出几个具体维度方便对方拍下来回去研究对比维度PulsarKafka存储模型独立存储层BookKeeper存储内嵌于 broker扩容方式接入层与存储层独立扩容移动分区数据做迁移多租户原生支持需额外构建消息积压支持长时间保留至对象存储受本地磁盘容量限制订阅模式独占、共享、故障转移、键共享以消费组为主协议兼容原生协议 支持 Kafka 协议适配社区采用广泛很多人以为我在推销 Pulsar其实不是。我说得最多的反而是如果你现在的团队已经非常熟悉 Kafka而且你的使用场景没有大规模积压、存储成本和多租户的痛点那你完全不用换。选型迁移本身是有成本的除非新方案带来的结构性收益明显大于迁移成本否则维持现状也完全合理。这种态度在集市上反而很加分不少访客就是听到这段话才决定加群深入观察的。4.2 分层存储为什么能把 BookKeeper 和对象存储结合分层存储这个特性现场演示效果最好但很多人并不理解它的实现原理。有个工程师听完演示后追着问你们把消息 offload 到对象存储之后消费者还能按老的订阅位点继续消费吗能而且是完全透明的。Pulsar 的数据写入先落 BookKeeper当 topic 的数据量或者数据留存时间超过阈值后后台任务会把更早的数据段卸载到对象存储。消费者的读取请求到达 broker 时broker 会根据消息的 ledger 分布信息判断数据在哪个存储层然后去对应的地方读取。这个细节普通用户根本感知不到就像你把旧照片从电脑硬盘转到网盘浏览相册的感觉还是一样的。很多人会关心性能损耗。说实话读历史数据确实比从本地磁盘读要慢但这类访问通常是很低频的日志回放或者离线分析对性能不敏感。而分层存储带来的收益是实实在在的BookKeeper 的存储压力降下来了集群规模可以控制住存储成本按对象存储的费率计算比自建一大堆机械磁盘划算得多。现场我常说的一句话是“消息积压对 Pulsar 来说就是一个配置项的事而不是一个容量焦虑源。”这句话基本上能立刻让人感受到这个特性的价值。4.3 多租户隔离是 Pulsar 的强项但很多人不知道它怎么落地多租户这个词在技术圈已经快被说滥了但真正理解消息系统多租户含义的人不多。Pulsar 的多租户是干在租户、命名空间、主题三层结构之上的。租户是资源隔离的顶层单位命名空间可以配置策略比如保留时间、消息大小限制、无消息时是否自动卸载然后是具体业务用的主题。我们现场用了一个很直观的例子来讲解一家公司内部有交易、风控、日志三条业务线就可以创建三个租户每个租户的数据默认互相完全隔离。某个租户的流量突然暴增它最多只能用到自己被分配的资源配置不会把其他租户的流量挤掉。更细一层同一个租户下的不同命名空间可以按环境或者部门划分策略各自独立。一名做中台架构的访客问到一个很实际的问题“我们这边有多个业务方每个业务方都要配额控制Pulsar 能不能做到细粒度的权限控制”我告诉他Pulsar 对命名空间支持策略继承租户级别设一个默认策略命名空间级别可以覆盖甚至可以做到按主题设置核心参数。授权模型支持 Token 认证接入内置了比较完整的权限维度覆盖生产、消费、函数执行这些操作。他听完当场说回去要在测试环境验证一下。4.4 函数计算与连接器集市访客最容易“哇塞”的演示如果说分层存储是“听完觉得很有道理”的特性那 Pulsar Functions 就是“看演示立刻被吸引”的特性。我在笔记本上预置了几个函数模板用 Python 写的那种一条命令就能把函数部署上去。现场演示时我先往一个 topic 里发送流水数据然后让函数在消费消息的同时做简单的字段提取把处理结果写到另一个 topic整个链路在终端里可视化跑起来很多人看的过程中都会发出“这是真的在处理吧”的感叹。其实 Pulsar Functions 的逻辑很简单把轻量级的事件处理逻辑部署到消息流里执行用户不用再去单独运维一套 Flink 或者 Spark 集群。对不少场景比如数据清洗、字段映射、告警判断直接用函数就够用了。现场有个做 IoT 的工程师说他们之前为了处理设备上报数据专门搭了一套流处理平台运维成本很高看到这个能力他明显心动了。不过我也会诚实地补充边界Pulsar Functions 适合轻量级单消息处理或者简单的流式 ETL如果你要做复杂的窗口计算或者大规模状态管理它还不是 Flink 的替代品。这种诚实反而让后面关于连接器生态的讨论更顺畅大家更愿意相信你说的话。连接器Connector的部分在现场演示场景里体现不多但对有一类访客很关键就是已经有旧系统、需要考虑数据搬移的人。我告诉他们 Pulsar 社区提供了丰富的 Source 和 Sink 适配可以从常见的数据库和消息系统接入、导出迁移路径是存在的。4.5 运维层面的疑问Pulsar 到底难不难运维这个问题我几乎每天都会被问到。问的人也分两种一种是还没用过道听途说觉得组件多、运维难另一种是已经在生产环境跑过一段抱怨某些操作流程上手成本高。对第一种人我的引导方式是讲清楚哪些组件可以用来承担什么职责。Pulsar 集群的核心角色包括 broker、BookKeeper 和元数据服务。听着多但 brood 和 BookKeeper 的职责分离恰恰是它的优势所在我们可以针对性扩容而不必重新分配整块存储。元数据服务保存的是主题的路由策略这些轻量信息规模不大。我们现场用一句话总结运维特点如果你能管理一套普通中间件的集群配置那掌握 Pulsar 的日常运维只是时间问题最陡峭的学习曲线通常在第一次搭建和扩容规划阶段跨过之后日常反而很稳。对第二种人我会认真听他们的抱怨再给出建议。有一位工程师反映集群发生网络分区时恢复流程有些繁琐。我给出的建议是提前把常用恢复命令整理成运维手册并利用 Pulsar 提供的健康检查和监控指标把故障定位前置。现场没有夸大说“完全没有任何问题”因为我们已经跑过很多生产环境太清楚哪里有坑。但这种真诚的交流方式反而让不少原本对 Pulsar 持保留态度的人开始重新审视它。5. 活动复盘这五个坑我下次绝对不再踩5.1 位置和动线决定了你一天要说多少话展位位置这个因素准备阶段怎么强调都不过分。我们在第一天开场时因为布展动线的问题靠近主出入口的位置几乎全是人流盲区访客大多直奔内场直到下午人流才慢慢经过我们展台。这直接影响了第一天的整体互动量。第二天我们迅速调整了易拉宝的摆放角度和展台朝向在主要人流支路方向增加了引导牌情况才明显好转。我建议所有即将参加集市的团队拿到场馆动线图之后一定要事先模拟几遍访客从入口进来沿着展区走视线会先落到哪个位置如果前面几个展位的人气特别旺那你的展台用什么方式去抢注意力。位置一旦定了就很难换所以要尽可能在有限条件下优化朝向和视觉重点。我的经验是视觉上不要跟旁边的展位“平铺”不如做一个稍微高出周围环境的视觉焦点哪怕是立起来的一块大板子都管用。5.2 物料要分“递出去”和“拿在手边”两种这次物料我们准备得不算少但还是出现了一个问题单页很快就发完了小册子却带多了。分析下来倒不是单页需求量真的那么大而是我们习惯性地见到人就递单页递得太轻易对方也不好拒绝拿走了也不会细看。反观那些主动被拿起的小册子互动率高得多。复盘得出的结论是物料投放要做区分。单页适合放在台面上让人自取不主动硬塞小册子放在显眼位置但只在聊到一定深度后才主动介绍给访客带走。这样单页消耗量会大幅下降但留存率应该会提高。我确实看到不少展台发物料像发传单一样覆水难收效果可想而知。与其追求发出去的数量不如在意带走的准确率。5.3 人手的精力分配远比想象中残酷两天展会下来最直观的感受就是嗓子是真的会哑。第一天上午我连续讲了三个小时到中午几乎说不出话嗓子冒火而且因为对话过于密集精神的消耗比身体更严重。每个交流对象都是一张新面孔你要在几秒钟内判断对方的背景和关注点然后调整讲解节奏这个大脑持续高负荷运转的过程比坐办公室写代码累太多了。后面我们加强了轮班制度和任务拆解。值守的两个人一个主要负责主动搭话和重点讲解另一个负责补充细节和操作演示每 40 到 50 分钟就互换角色。同时安排一个“机动人”负责补充物料、拍照、处理突发情况。这种明确分工的执行效果非常明显下午的交流质量明显高于上午。如果这次只来了两三个人我大概会提前压缩讲解深度把 10 分钟的版本砍成 5 分钟确保每个人都能坚持下来。5.4 快速破冰的“十秒钟开场白”需要提前排练展台人员的开场白决定了路人愿不愿意多停三秒。第一天我观察到我们有些伙伴一看到有人靠近就脱口而出“您好我们是 Apache Pulsar您了解过 Pulsar 吗”结果很多人摇头就走。这个开场方式最大的问题是把压力抛给了对方——不了解 Pulsar 的人会觉得这个东西跟自己没关系干脆不停下来。第二天我们统一改成了场景化提问“你在用消息队列吗有没有遇到过消息积压把磁盘打满的事”这个问题几乎每个人都能接住因为大家即使没用过消息系统也多少听说过消息积压的恐怖故事。一旦对方说“确实遇到过”或者“我们就在用”对话自然就开始了。开场白要提前排练反复练到能根据不同对象切换版本。这个看起来很小的细节实际上决定了每天的有效互动量。5.5 布道不是单向输出把访客的问题变成下一版讲解素材两天里我们收集到的问题数量远超预期其中不乏平时在技术文档里看不到的实战疑问。以前我总觉得讲解内容是提前定好的现场只需要照着讲但经历过这次集市之后我把很多访客的提问吸收成了新的讲解素材。比如那个关于 BookKeeper 多副本网络开销的问题我之前讲架构优化时很少提到但现场发现这是很多资深工程师关心的实质问题。还有关于多租户权限细粒度控制的探讨让我意识到很多企业的实际需求不是“要不要多租户”而是“怎么把多租户落到组织架构里”。这些反馈都应该整理成 FAQ 文档沉淀到社区而不是让它们流失在一次性的对话里。我还给自己定了一个原则每次摆展台之后都把现场最精彩的三个问答写成技术博客或者社区帖子。这样一次活动的价值不止于现场那两天它还会持续影响那些没能来到现场的人。开源布道本来就是一个持续累积的过程每次线下活动都是给这个累积过程添加一块砖。这次 COSCon 2025 开源集市让我更确信一件事基础软件项目在线下活动里并不是很难做关键是摆正姿态。你不要觉得自己是在“布道”而要把自己当成一个愿意陪路人多聊几句的技术同路人。准备充足的 Demo、设计好分层物料、统一讲解节奏、认真对待每一个问题再把现场反馈转化成长期内容——这一套组合拳下来哪怕只是周末两天的展位积累到的价值也会远远超出预期。