你一定参加过这样的技术分享：演讲者打开一个布满代码的 IDE，对着屏幕一行一行地念，台下的人一半在刷手机，一半已经睡着了。45 分钟过去，你唯一的收获是知道了这个人的代码写得不错。
这不是技术分享，这是代码朗读会。
做一场好的技术分享，核心不在于你懂多少，而在于听众能带走什么。
选题：不要讲"你做了什么"，讲"别人能学到什么"
最常见的错误选题是："我们最近做了一个 XX 系统，我来分享一下"。这听起来像是在炫耀——而听众来参加分享，不是为了听你炫耀的。
好的选题公式是：一个具体的问题 + 一个可复用的方法。比如把"我们做了 XX 系统"改成"如何在 3 天内搭建一个高可用的 XX 系统"。前者是汇报，后者是教学。
还有一个检验选题的好方法：如果你的分享内容只能对你当前项目的人有用，那就不是一个好选题。好的选题应该让不同团队、不同背景的人都能从中得到启发。
结构：用"三幕剧"框架
一场 30-45 分钟的技术分享，最有效的结构是：
- 问题（5 分钟）：我们遇到了什么问题？为什么现有的方案不行？用具体的场景和痛苦唤起听众的共鸣。
- 方案（20 分钟）：我们是怎么解决的？这里不是展示代码，而是展示决策过程——为什么选 A 而不是 B？当时的约束条件是什么？犯过什么错误？
- 总结（5 分钟）：听众可以带走的三点收获。不要超过三点，超过三点等于没有。
这个结构的魔力在于：听众不需要知道所有细节，他们只需要知道"遇到了什么问题，怎么想的，结果怎样"。
表达：三个原则
原则一：一个人，一个故事
技术分享最容易犯的错误是信息过载。你想把所有你知道的都讲出来，结果听众什么都记不住。克制，只讲一个主线故事。其他的细节，可以放在 Q&A 环节被动回答。
原则二：图比文字好，Demo 比图好
没有人来参加技术分享是为了读 PPT 上的文字。能画图就画图，能跑 Demo 就跑 Demo。一个 30 秒的 live demo 比 10 张 PPT 更有说服力。
原则三：准备"失败预案"
Demo 会崩。网络会断。投影仪会不兼容。这是技术分享的常态。提前录好一个 Demo 的视频备份，或者准备几张截图作为 fallback。当意外发生时，你淡定的处理方式，反而会让听众觉得你更专业。
一点心态建议
很多人害怕做技术分享，因为怕被质疑、怕讲得不好、怕被人发现"其实我也不太懂"。但真相是：听众来参加分享，不是来 judge 你的，是来学习的。即使你只比听众多懂 20%，你也有资格分享。
而且，准备一场技术分享的过程本身就是最好的学习方式。当你试图把一件事讲清楚，你会发现自己之前理解中的漏洞。从这个角度说，做分享最大的受益者其实是你自己。