技术分享准备：把工程笔记变成工程师能跟上的论证

把论点写成一句同事可以反对的话：

• “我们的重试策略会让故障更糟，因为它在最糟糕的时刻增加负载。”
• “迁移卡住的原因是数据所有权，不是数据库。”
• “仪表盘数字是准的，但和账单不一致，所以没用。”

如果你有两个论点，很可能应该做两场分享。选一个对这场听众最重要的，另一个放进附录。

不要从“这是架构图”开始。先讲什么会坏、代价是什么、为什么显而易见的做法不够。工程师需要先有理由在意，才需要看架构图。

前两分钟应该建立约束。在展示真正的设计之前，听众要先理解为什么朴素修法不够。

大多数技术分享会跳过替代方案，因为讲者已经知道答案。这恰恰删掉了最有意思的部分。展示显而易见的做法、它的失败模式，以及让你否定它的证据。信任就是在这里建立的。

如果听众说不清你的选择为什么必要，他们只会记住技术栈，记不住决策。

每个技术决策都买到一些东西，也在别处付出代价。两边都要说：

• 更低延迟，更高运维复杂度；
• 更少组件，更少灵活性；
• 更快交付，更弱隔离。

然后说明你会测量什么，来判断这个取舍是否正确。没有测量的技术分享，通常只是品味故事。

函数名、队列配置、完整 schema 和长代码路径，除非会改变论证，否则都属于附录。现场稿要留出提问和思考的空间。

讲者备注可以放那些“被问到再讲”的细节。这不是作弊，而是让分享保持在场。

你不需要背下每一页。你需要知道每一页如何引向下一页。有用的排练是：

1. 说出这一页的主张；
2. 说出你要指出的证据；
3. 说出你预期的异议；
4. 说出到下一页的过渡。

pastedeck 的讲者备注也按这个结构组织：要点、过渡、最可能的问题。目标不是逐字稿，而是不看幻灯片也能讲的分享。

pastedeck 可以把技术笔记重新组织成现场稿，让论证可见，把细节放进备注或附录。它不会运行代码、核对引用、重画架构图，也不会从 PDF 里还原复杂图表。

如果分享依赖架构图、实时 demo 或基准测试图，这些仍然需要单独准备。演示稿可以承载论证，但不能替代证据。