第2361篇：如何做一次有影响力的技术分享——AI工程主题演讲的准备方法
第2361篇：如何做一次有影响力的技术分享——AI工程主题演讲的准备方法
适读人群：需要做技术分享或对外演讲的工程师 | 阅读时长：约12分钟 | 核心价值：从选题到上台，一套实用的AI工程分享准备方法
第一次做公司内部技术分享是在2020年，主题是一个我在项目里用到的分布式缓存方案。
那次我准备了两周，做了三十张PPT，每张PPT上都是密密麻麻的文字。分享那天，我把PPT上的文字读了一遍，用了45分钟，台下有三个人在看手机。
事后一个同事好心告诉我："你把PPT读了一遍，我自己看PPT就好了，不需要你来读。"
这句话刺激了我，但也让我开始认真思考：一次技术分享的价值到底是什么？为什么有些人的分享让人听完想去试，有些人的分享让人昏昏欲睡？
技术分享失败的常见原因
失败原因一：分享"知识"而不是"洞察"
很多技术分享是这样的结构：介绍这个技术是什么，它有哪些特点，怎么使用，总结。
这个结构本质上是在复述文档。听众自己去读文档也能获得同样的信息，为什么要来听你讲？
有影响力的技术分享，讲的是你的独特洞察——你踩过的坑、你做出的非显而易见的选择、你发现别人容易误解的地方、你在实践中得出的和主流认知不同的结论。这些东西是文档里没有的。
失败原因二：只有"是什么"没有"为什么"
"我们用了A方案，没有用B方案"——这是大多数技术分享的表达方式。
"我们用了A方案，没有用B方案，因为在我们的数据量级下，B方案的写放大问题会导致磁盘I/O成为瓶颈，而A方案的读性能在我们的查询模式下更优，权衡之后选了A"——这才是有价值的分享。
听众真正需要的不只是你做了什么决定，而是你是怎么做这个决定的。决策过程和背后的推理，是分享的核心价值。
失败原因三：对听众缺乏了解
同一个技术主题，给初学者讲和给专家讲是完全不同的内容。给不做AI的业务工程师讲RAG，和给已经在做RAG的工程师讲，深度和侧重点应该完全不同。
很多分享者在准备时没有想清楚"我的听众是谁"，结果内容对高水平的人来说太浅，对低水平的人来说太深，两边都没抓住。
准备一次AI工程分享的完整流程
第一步：找到你真正想说的那一件事
每次分享，聚焦在一个核心观点上。
不是"RAG系统的完整介绍"，而是"为什么RAG系统的检索质量比生成质量更影响最终效果——来自我们项目的数据"。
不是"LLM在企业应用中的实践"，而是"我们把LLM用于客服系统，失败了两次，最终成功的关键原因"。
一个清晰的、带观点的主题，比一个宽泛的概述主题更有力量。
第二步：构建分享的核心叙事
好的技术分享有一条叙事主线，通常是这样的结构：
有效的技术分享叙事结构
├── 设定背景：我们遇到了什么问题，为什么这个问题重要
├── 探索过程：我们尝试了什么，遇到了什么障碍
├── 关键洞察：我们发现了什么非显而易见的东西
├── 解决方案：我们最终怎么做的，为什么这样做
└── 可迁移的经验：听众能从中学到什么，如何用在他们自己的情况注意最后一步：可迁移的经验。听众听完你的分享，要能带走一些可以用在自己工作里的东西。如果听众听完觉得"这是你们的特殊情况，和我没关系"，那这次分享对他们就没有什么价值。
第三步：设计实际的演示
对于AI工程分享，最好有现场演示或者真实的数据截图。
抽象的描述"我们的系统延迟降低了60%"，没有"这是我们优化前后的Grafana监控截图，可以看到P99从800ms降到了320ms"有说服力。
如果能做现场demo，让听众直接看到效果，印象会更深。demo可能会失败，但失败本身有时候也是好的素材——"你们看，这就是边界条件，让我给你们解释为什么会这样"。
第四步：控制内容密度
一次45分钟的分享，能讲清楚三个核心点就很好了。很多人试图在45分钟里讲十件事，结果每件事都只蜻蜓点水，没有深度。
宁可少，讲透彻。
AI工程分享的高分选题
如果你在AI工程领域，什么样的分享主题通常能获得好反响？
真实案例类（最受欢迎）
- 我们RAG系统的评估体系是如何建立的
- 一个AI功能从PoC到生产环境的工程化改造
- 我们的向量数据库选型过程和踩坑经历
这类分享为什么受欢迎？因为AI工程实战案例还比较少，大家都缺乏一手的工程经验，分享真实案例有很高的信息增量。
反常识类（容易出圈）
- 我们发现prompt工程不是我们的RAG系统的瓶颈（真正的瓶颈是检索）
- 为什么我们把自研模型推理服务换回了第三方API
- LLM的token用得越多，不一定效果越好——我们的实验结果
有观点的分享，哪怕观点有争议，也比没有观点的内容更容易被记住。
方法论类（建立影响力）
- 我用什么框架评估一个AI工程项目值不值得做
- AI系统的监控和可观测性，我们是怎么做的
- 如何做好AI系统的成本管理
PPT制作的几个实用原则
一张PPT只有一个核心点
如果你的一张PPT上有三件事，考虑拆成三张。听众的注意力在任何时刻只能聚焦在一件事上。
代码要少但精
技术分享里的代码不要超过10行。超过10行，听众就开始看不过来了。如果需要讲一段复杂的代码，选最关键的几行，把其他的省略号代替。
数字要具体
"大幅提升性能"不如"P99延迟从800ms降到320ms"。"节省了很多成本"不如"每月API调用费用从12万降到了4万"。具体的数字让内容可信，也让听众有具体的感知。
演示用截图或录屏，不要现场操作
技术演示现场操作容易出意外——网络不好，服务出问题，你的手打错了字。提前录好屏，或者准备好截图，万无一失。
现场表达的几个要点
说话慢一点
大多数人紧张时说话会变快。有意识地放慢语速，给听众处理信息的时间。
用停顿强调重点
讲完一个关键点后，停顿两到三秒，不要立刻往下讲。这个停顿让听众有时间处理刚才的信息，也无形中强调了这个点的重要性。
留出问答时间，不要把问答挤到最后五分钟
好的技术分享，问答环节是分享本身的延伸，不是尾声。如果你有45分钟，讲35分钟，留10分钟问答。
不要试图遮掩你不知道的东西
有人提问，你不知道答案，直接说"这个我没有深入研究过，我不确定"。比给一个模糊的答案好得多。承认不知道不会损害你的可信度，胡说一通才会。
一次分享能带来什么
做一次高质量的技术分享，投入和收益是不对等的——收益远大于看起来的投入。
它让你把模糊的理解变成清晰的表达。它让你在同事和行业里建立"这个方向的可信专家"形象。它是简历上无法伪造的能力信号。
如果你在公司里有做分享的机会，认真对待它。如果你所在的公司没有这样的文化，去外部社区、meetup、会议去分享。
表达能力是工程师最容易被低估的竞争力。