如何撰写出色的KotlinConf演讲提案？
KotlinConf 2027 演讲征集现已开启！我们邀请 Kotlin 社区各地的开发者，将你们的想法、经验和专业知识带到克拉科夫的舞台上。
你是否有一个能帮助其他开发者的 Kotlin 经验或发现？也许你解决了一个棘手的技术问题，将 Kotlin 引入现有代码库，构建了某个意想不到的东西，或者从一次未按计划推进的尝试中吸取了宝贵教训。
那段经历可以成为一场 KotlinConf 演讲。
然而，把一个想法变成有说服力的会议提案可能并不容易，尤其是当你从未提交过提案时。你如何知道自己的经历是否值得分享？评审最先注意到什么？摘要应该写多详细？又该如何让一个熟悉的话题脱颖而出？
为了帮助你准备提交内容，我们询问了 Kotlin 开发者、开发者布道师、经验丰富的演讲者以及 KotlinConf 程序委员会成员，请他们分享什么样的提案才算有力。除了关于如何打磨标题、摘要和关键收获的实用建议外，我们还新增了一个章节，回答一个尤其重要的问题：评审打开一份提案时，最先注意到什么？
首次演讲？也请提交你的想法！
人们很容易认为，一场 KotlinConf 演讲必须始于突破性发现、大型生产系统，或者多年演讲经验。但实际上，一场有价值的演讲可以始于一个简单的想法，或是在解决日常开发问题时学到的一课。
你不需要了解 Kotlin 的一切——你需要的是有值得分享的实用内容，并清楚它可能帮助到谁。
[LOADING...]
Pamela Hill-Galloway，开发者布道师、KotlinConf 程序委员会成员、KotlinConf 演讲嘉宾
无论如何，提交你的想法！KotlinConf 上有一些非常成功的演讲，最初也只是源于一个简单的想法。
如果你不确定自己的话题是否有人感兴趣，就和身边的人聊聊。向同事、朋友、用户组成员或 Kotlin 社区中的人解释你的想法。他们的问题和反应，可以帮助你理解哪些部分最有价值。
[LOADING...]
Marcin Mycek，Kotlin 构建工具产品经理
如果你能找到一个人感兴趣，那很可能还有更多人会感兴趣！如果你身边至少有两个觉得这个话题有趣、并且能听你讲五分钟以上的人，它就已经是一个不错的候选了。
不需要有会议演讲经验。一个清晰、真实、基于你理解并在意之事的提案，可能比一个打磨得很精致却缺乏实质内容的提案更有说服力。
从你想讲的故事开始
在写标题或打开提交表单之前，先确定演讲背后的核心故事。
“一场关于协程的演讲”或“一个关于 Kotlin Multiplatform 的分享”描述的是一个主题，但没有说明这场演讲为什么有价值。
问问自己：
- 你遇到了什么问题、疑问或机会？
- 它为什么重要或困难？
- 你尝试了什么？
- 什么让你感到意外？
- 哪些成功了，哪些没有？
- 你学到了什么，其他开发者可以如何应用？
你的故事不必来自大公司，也不必来自服务数百万用户的系统。如果一个小项目中的具体经验能提供独到见解，或清晰地解释一个困难主题，它同样有用。
试着用一句话概括想法，例如：
这场演讲将向 [受众] 展示我们如何 [解决或探索了某件事]、我们学到了什么，以及他们可以如何应用这些经验。
如果你无法清楚地补全这句话，那么这个想法可能还需要再打磨一下，然后才开始写提案。
评审最先注意到什么？
标题可能是评审读到的第一行，但整体用心程度很快就会显现出来。
评审不仅会考虑话题是否有趣，还会考虑演讲者能否把它解释清楚。一个经过思考的标题、聚焦的描述、具体的收获和仔细的格式，都能表明你花时间打磨了自己的想法。
[LOADING...]
Pamela Hill-Galloway，开发者布道师、KotlinConf 程序委员会成员、KotlinConf 演讲嘉宾
我可以总结为：你在撰写提案时付出的用心，可能比你想象的更明显。如果我能看出你花了时间想出一个与内容契合、朗朗上口或描述准确的标题，我就更愿意支持你在 KotlinConf 演讲。如果你的描述太短、太长，或者明显是 AI 生成的，以至于无法清晰、简洁地表达你的想法，我大概率不会投票支持你的演讲。
这并不意味着你需要使用复杂语言，或打造完美的营销话术。它意味着要给评审足够的信息来理解你的想法，并表明这份提案代表了你自己的经验和声音。
Marcin Moskała 的 Taming Asynchronous Beasts: Debugging and Performance Tuning in a Coroutine World（驯服异步猛兽：协程世界中的调试与性能调优）就是一个精准承诺的好例子：“你将学会如何有效使用内置工具、识别有问题的模式，并实施经过验证的优化策略。”
写一个清晰且信息量充足的标题
一个有力的标题应该让评审，最终也让参会者，准确了解演讲会涵盖什么内容。
创意可以让标题令人难忘，但清晰应该放在第一位。避免那些完全依赖玩笑、梗或隐喻，却不解释主题的标题。
[LOADING...]
Pamela Hill-Galloway，开发者布道师、KotlinConf 程序委员会成员、KotlinConf 演讲嘉宾
精心选择的标题可能带来很大不同！参会者在决定是否参加一场演讲时，往往没有时间或耐心阅读标题以外的内容。与其用一个朗朗上口或有趣、却不能让人一眼了解演讲内容的标题，不如优先保证清晰。
比较以下标题示例：
过于宽泛：
我们的多平台之旅
信息更充分：
我们将移动应用迁移到 Kotlin Multiplatform 中学到了什么
过于模糊：
失控的协程
信息更充分：
在生产环境中调试协程性能问题
过于笼统：
构建更好的 API
信息更充分：
设计难以被误用的类型安全 Kotlin API
一个好的标题通常至少传达以下两项：
- 主要主题
- 问题或疑问
- 探索该问题的背景
- 参会者能获得的实际收益
- 预期的经验水平
你仍然可以使用幽默或文字游戏，但要确保标题不会掩盖这场演讲真正要讲的内容。
围绕一条清晰的脉络来撰写摘要
你的摘要不需要包含整场演讲。但它应该提供足够细节，让评审理解问题、演讲方向和价值。
两到三个聚焦的段落，通常比一句含糊的话或一段覆盖所有细节的超长描述更能说明问题。
[LOADING...]
Sebastian Sellmair，软件开发者、KotlinConf 演讲嘉宾
在 KotlinConf 演讲是一次很棒的体验，对任何 Kotlin 开发者来说都是巨大成就。选择一个好标题、制作高度精致的动画、收集高质量梗图，或许都能提升你的演讲，但最重要的是有一个值得讲的故事。你有没有新颖且技术上有趣的内容可以展示？你能不能以一种引人入胜、真正有趣的方式拆解一个主题？你能不能启发其他开发者？
[LOADING...]
Márton Braun，开发者布道师、KotlinConf 程序委员会成员、KotlinConf 演讲嘉宾
虽然我们不需要把整篇演讲稿当作摘要提交，但我们也不太可能接受摘要只有一句话的演讲。两到三段通常就足以提供有意义的细节。
一个简单的结构会很有帮助：
背景
介绍情境，以及可能对这一情境有共鸣的受众。
挑战
解释推动这项工作的那个问题、限制或疑问。
[LOADING...]
Jodie Burchell，开发者布道师、数据科学家
通过告诉观众你要解决的问题来吸引他们。人们喜欢悬疑小说是有原因的，因为它们会在进入解决方案之前先制造一点悬念。一份出色的提案也会这样做。
方法
描述你探索、实现、比较或发现了什么。
结果
说明参会者将学到什么，以及他们可以如何运用。
一个有力的收获可以像 Tadeas Kriz 的 Dependencies and Kotlin/Native（依赖与 Kotlin/Native）那样具体：“了解原生依赖如何交互、如何加载，以及原生世界中那些意想不到的复杂性。”
[LOADING...]
Chantal Loncle，软件开发者，Exposed，JetBrains
避免含糊的承诺。相反，使用动作动词和具体结果来描述观众将获得的确切能力和转变。他们听完你的演讲后，会觉得时间花得值吗？如果会，他们会带走哪些实用知识、可立即应用的技能或高价值工具？
例如：
分别维护 Android 和 iOS 实现让我们的团队能够独立推进，但这也导致了业务逻辑重复，以及两个应用之间行为不一致。
在这场演讲中，我们将探讨如何逐步引入 Kotlin Multiplatform：从一个共享功能开始，而不是尝试一次性完整迁移。我们会讨论如何选择第一个组件、如何组织共享代码、如何跨平台测试，以及如何与现有原生应用协作。
你将获得一个实用框架，用来评估在哪里引入共享代码、会遇到哪些挑战，以及如何规划渐进式 Kotlin Multiplatform 采用，而不必重建整个应用。
这个例子确立了问题，解释了演讲会涵盖什么，并给观众一个参加的理由。它没有透露所有细节，但做出了具体承诺。
像参会者一样思考
一份有力的提案不会只关注演讲者想讲什么。它还会解释观众能获得什么。
问问自己：
- 这场演讲面向谁？
- 参会者应该已经具备哪些知识？
- 这场演讲会帮他们解决什么问题？
- 听完之后，他们会理解什么，或能够做什么？
- 他们为什么应该选择这场演讲，而不是同一时间举办的其他演讲？
[LOADING...]
Svetlana Isakova，Kotlin 开发者布道团队负责人、KotlinConf 程序委员会成员、KotlinConf 演讲嘉宾
提交演讲时，要像参会者一样思考。你会愿意坐下来听完这场演讲吗？观众能从中得到什么？这就是为什么我们会询问关键收获。你希望人们学到什么、尝试什么、做什么，或者受到什么启发？
避免宽泛的承诺，例如：
- “你将学习最佳实践。”
- “我们将探索 Kotlin Multiplatform。”
- “这场演讲将涵盖协程。”
相反，描述具体结果：
- 参会者将学会如何识别和调试三种常见的协程性能问题。
- 参会者将理解我们如何组织 Android 和 iOS 之间的共享代码。
- 参会者将能够评估这种方法是否适合自己的项目。
- 参会者将了解我们的迁移中哪些部分有效、哪些无效，以及我们今天会做出哪些改变。
具体的收获让提案更容易评估。如果演讲入选，它们还能帮助参会者判断这场演讲是否与自己相关。
让熟悉的话题焕然一新
你的主题不必完全新颖。许多有价值的会议演讲，都会从以前未被同样探索过的视角重新审视成熟技术。
如果你要提交一个热门话题，先找出你的版本有什么独特之处。它可以是：
- 一个真实的生产案例
- 不寻常的规模或环境
- 一个令人惊讶的结果
- 一次失败的方法及其教训
- 多种可能解决方案之间的比较
- 渐进式迁移，而不是从零开始的全新实现
- Kotlin 的非传统用法
- 挑战常见假设的个人经历
- 对困难概念的特别清晰的解释方式
例如，“Kotlin Multiplatform 简介”宽泛而常见。“当我们将 Kotlin Multiplatform 引入一个已有七年历史的移动应用时，什么崩了”则提供了具体背景，并引发好奇心。
要诚实面对权衡取舍。演讲不需要呈现一个完美无缺的成功故事。解释哪些失败了、哪些改变了，以及你会如何做得不同，对其他开发者可能特别有用。
[LOADING...]
Chantal Loncle，软件开发者，Exposed，JetBrains
把一个真实、实用的叙事带到熟悉话题中，可以增强提案。诚实面对哪里出了问题、什么让你的团队不开心，或者如果时光倒流你会怎么做。一个熟悉的问题，从明天将第一次遇到同样问题的人的视角来看，也会显得新鲜。
与其再提供一份泛泛概述，不如围绕一个具体痛点或发现来构建演讲，只在有助于这个故事时才引入更广泛的主题。一个参会者能立即应用到工作中的收获，也能帮助这份提案区别于基础教程。
让提案与 KotlinConf 保持相关
KotlinConf 欢迎关于后端开发、Android、多平台开发、Web、桌面、AI、语言设计、工具、库、开发者体验，以及 Kotlin 生态系统其他部分的演讲。
无论你属于哪个领域，Kotlin 在故事中扮演的角色都应该清晰。
[LOADING...]
Márton Braun，开发者布道师、KotlinConf 程序委员会成员、KotlinConf 演讲嘉宾
请记住，你的演讲应该与 Kotlin 相关！例如，并不是每一场 Android 演讲都一定适合 KotlinConf 观众。或者关于 Jetpack Compose 的演讲，常常涉及的内容在 Compose Multiplatform 中运作方式完全相同，而后者被 KotlinConf 接受的可能性要大得多！
例如，一个 Android 话题并不自动等于 KotlinConf 话题。当提案解释 Kotlin 如何影响了解决方案、探讨了 Kotlin 特有的技术决策，或提供了 Kotlin 开发者可以应用的经验时，它就会变得更有相关性。
问问自己：
- 为什么这是一个 Kotlin 故事？
- 这段经历中哪些部分与 Kotlin 开发者尤其相关？
- 如果从提案中移除 Kotlin，它是否仍然基本一样？
如果最后一个问题的答案是肯定的，那么在提交前先加强它与 Kotlin 的联系。
Anshika Koul 的 Kotlin Multiplatform's Cross-Platform Brilliance at Norway's 377-Year-Old National Postal Service（Kotlin Multiplatform 在挪威 377 年历史的国家邮政服务中的跨平台卓越表现）提供了一个以 Kotlin 为中心的清晰收获示例：“我们将了解 KMP 如何提供一个统一框架，用于跨各种平台共享和执行代码，从而解决不同代码库面向不同运行时的挑战。”## 听起来自信，但保持真实的自己
你的提案应该表明你清楚自己想分享什么，以及为什么它重要。
这并不意味着夸大你的专业能力，或假装自己毫无疑虑。它意味着把想法作为一个清晰的陈述呈现出来，而不是反复质疑它的价值。
[LOADING...]
Marcin Mycek，Kotlin 构建工具产品经理
让陈述保持为陈述，让问题保持为问题。怀疑自己很正常；人人都会这样，但一个常见错误是让这种怀疑在文字中显露出来，比如把陈述改成问题。读一读你的投稿，或者更好的是，请别人读一读，然后问自己：这个人听起来相信自己想讲的内容吗？
例如：
不确定：
Kotlin Multiplatform 是否可能帮助团队减少重复的业务逻辑？在这次演讲中，我们也许会找到答案。
更自信：
在这次演讲中，我将展示我们团队如何使用 Kotlin Multiplatform 减少重复的业务逻辑，包括共享代码在哪些方面有帮助，在哪些方面没有。
自信不应抹去你的个性。提案仍然应该听起来像你本人。
[LOADING...]
Marcin Mycek，Kotlin 构建工具产品经理
保持真实的自己！确保别人能理解你的投稿很重要。一个很好的做法是把它交给几位你信任的人，问问他们从中理解了什么，以及它给他们带来了什么感受。不过，要在其中保留你的灵魂。很多精彩的演讲都很古怪，并不遵循每一条最佳实践，而人们正是为此而来。
建议和模板可以帮助你组织思路，但它们不应该让每一份提案都千篇一律。你的视角、语言、幽默感和热情，正是让投稿令人难忘的一部分。
向评审展示你的沟通方式
以往演讲的示例可以帮助评审了解你的演讲风格和能量。如果你有来自会议、聚会、网络研讨会或直播的录像，请附上最相关的那些。
如果你是第一次演讲，没有正式录像，你可以录下自己讲解拟议演讲的一部分。用笔记本电脑简单录制就够了。不需要专业的灯光、剪辑或制作。
[LOADING...]
Svetlana Isakova，Kotlin 开发者关系团队负责人，KotlinConf 项目委员会成员，KotlinConf 演讲者
你的演讲示例能帮助我们做出更好的选择。如果你是第一次演讲，没有录像，别担心！你只需用笔记本电脑录下自己（哪怕只是拟议演讲的一部分），然后分享链接即可。我们会非常感激。
根据主题，你也可以附上：
- 一篇技术文章
- 一个开源项目
- 你撰写的文档
- 一个简短的技术演示
- 一次播客或聚会亮相
- 与拟议演讲相关的其他作品
这些材料可以支持你的提案，但不能替代清晰的标题、摘要和一组要点。评审仍然应该能够仅凭投稿本身理解这场演讲。
选择适合想法的形式
并非每个主题都需要一场完整时长的演讲。
一个聚焦的课程、实验、副项目或令人惊讶的发现，可能更适合作为闪电演讲。一个涉及大量技术背景、若干相互关联的课程或详细演示的主题，则可能需要常规演讲。
根据你有多少有意义的材料来选择形式。如果你需要重复自己，或添加不必要的内容来填满一场常规演讲，不妨考虑改投闪电演讲。
[LOADING...]
Márton Braun，开发者布道师，KotlinConf 项目委员会成员，KotlinConf 演讲者
别忘了，我们也接受闪电演讲！如果你觉得自己的内容必须被填充才能撑满一场常规演讲，那么它作为闪电演讲可能更令人愉快。
如果你有几个不同的想法，也可以提交多份提案。每份投稿都应该有自己的故事、受众和要点，而不是另一份提案的细微变体。
[LOADING...]
Pamela Hill-Galloway，开发者布道师，KotlinConf 项目委员会成员，KotlinConf 演讲者
提交不止一场演讲！这会给你更多机会参与 KotlinConf 的乐趣。
提交前审查提案
完成草稿后，先放一放，稍后再以第一次接触这个想法的人的视角回来看它。
检查你的提案是否回答了以下问题：
- 别人能从标题理解主题吗？
- 与 Kotlin 的关联清楚吗？
- 摘要是否指出了一个真实的问题、疑问或故事？
- 这场演讲面向谁，是否清楚？
- 要点具体吗？
- 提案是否解释了你的视角有何不同？
- 范围对于所选形式来说现实吗？
- 文字听起来自信且真实吗？
- 你检查过拼写、语法、链接和格式了吗？
- 提案听起来像将要发表演讲的那个人吗？
也请别人帮你审阅。不要只问他们喜不喜欢，而是让他们描述他们认为这场演讲会涵盖什么，以及他们期望学到什么。他们的回答会显示提案是否传达了你想要表达的内容。
[LOADING...]
Chantal Loncle，软件开发工程师，Exposed，JetBrains
再次确认目标受众水平与描述及预期要点一致。站在你希望出现在观众席中的人的视角来审阅提案。它按现在这样讲得通吗，还是缺少了一些对你来说显而易见、但对评审或他们心中未来观众却不明显的背景？
AI 工具也许能帮你检查语法或组织思路，但最终的提案应该反映你自己的经验、想法和声音。一份打磨光鲜却缺乏具体或真实见解的摘要，不会比一份清楚体现其背后演讲者的摘要更有说服力。
[LOADING...]
Márton Braun，开发者布道师，KotlinConf 项目委员会成员，KotlinConf 演讲者
你的投稿应该表明你为准备它投入了思考和精力。检查投稿中的格式问题和拼写错误，请不要提交由大语言模型生成的摘要。
你的 Kotlin 故事可以登上舞台
你不需要了解 Kotlin 的一切，也不需要多年会议经验才能提交提案。你需要的是一个有用的故事、对它能够帮助谁的理解，以及清楚说明它为什么重要。
并非每一份优秀的提案都能被选中。会议日程必须在主题、形式、经验水平和观众兴趣之间取得平衡。如果你的投稿未被接受，请继续打磨这个想法、分享你的知识，并寻找其他展示它的机会。
你的经验可能正是另一位 Kotlin 开发者需要听到的。
KotlinConf 2027 征稿现已开启！在克拉科夫与社区分享你的经验、想法和 Kotlin 专长。