把演讲想法变成可提交的会议 CFP 提案（含选题、标题…

当你要向某个会议提交演讲提案（CFP），或需要挑选目标会议并规划一整个 CFP 季度的投稿日历，用这套流程逐字段产出可直接粘贴进表单的提案包。

适用场景

解决思路

1. 先做访谈：一次只问一个问题，尽量用选择题，已答过的跳过；第 1-5 题是前置门槛，未答完不要起草标题。问题包括：目标会议及 CFP 页面链接；目标形式与时长（lightning/标准/长场/工作坊/panel）；用对同事说话的口吻描述演讲内容；支撑它的第一手经验（跑过的系统、处理过的事故、收集的数据、主导的迁移）并给出一个数字；目标听众的职位、处境和当天想做成什么（“开发者”不算答案）；你代表谁（雇主产品、自己的开源项目还是仅个人）；这个演讲或近似版本是否在别处讲过、何时何地；是否讲过且有录像；截止日期、向该会议投几份、演讲本身是否有必须落地的日期（发布、招聘、融资节点）；这是一次性目标还是可复用资产（讲五次、变成录像/文章/引用）；截止前的时间上限（写作小时数、能否现场为观点辩护、能否构建新材料）；主题的购买路径是 B2B 还是自助式个人采用。第 9-11 题会重排第 2 步的角度优先级，所以要在给出任何建议前问。若第 4 题答不出，直接停下并说明：没有第一手材料，提案会变成综述型演讲。
2. 若用户还没有目标会议，先执行第 0 步：把选会议当作组合决策而非单场名气判断，按以下标准给候选会议打分排序——track/主题契合度（会议是否发布过匹配的 track 描述或办过该主题）、听众契合度（典型参会者是否匹配访谈 Q5）、厂商中立 vs 厂商自办、历史记录（是否投过、结果如何；首次投旗舰会议要面对有该会议履历的讲者，地区或社区会议是更低风险的积累方式）、合规前置时间（主题是否需要雇主批准、客户签字或安全审查）、差旅与形式契合（时区、差旅预算、是否提供目标形式）。按满足项数排序，不要只看名气。
3. 规划投稿季：一旦找到 CFP 页面，就把每个候选会议的截止日、通知日和举办日拉进同一个文件；不要向审稿窗口重叠的两个会议投同一材料，除非先决定两个都中会去哪个；把首次或低把握的角度排在截止更早的地区/社区会议，等材料在舞台或 meetup 上讲过一遍再投旗舰会议；两个目标截止接近时，先投低投入角度（按第 2 步的效率顺序），这样被拒后仍有时间准备高投入角度投下一个截止日。
4. 第 1 步，动笔前先读会议：能联网就读 CFP 页面、行为准则或讲者条款、track 列表和去年日程；不能联网就让用户粘贴 CFP 页面和上一届五个已接受演讲标题。提取硬约束：字段列表、字符或词数上限、形式与时长、每人投稿上限、截止日、是否匿名评审、是否报销差旅。提取软信号：哪些 track 描述匹配、上一届已覆盖什么、会议说想要更多什么、会场是否厂商中立。动笔前先用一小段把约束复述给用户。
5. 读真实提案而不只是规则：speakerline.io 发布完整投稿文本并标注 Accepted/Rejected，还附审稿人可见的 pitch。目标会议的三篇已接受提案比任何建议页更能说明其风格；该站覆盖偏向 Ruby 会议，缺某会议属正常，可回退到去年公布的日程。
6. 注意匿名首轮评审会改变文案：PyCon US 声明首轮评审不显示作者信息，因此标题、描述和大纲不得出现讲者或其雇主名字；Write the Docs 等会议则有意实名评审以平衡视角。不要猜，CFP 页面会写明。若环境有持久记忆，按会议名存储会议档案和用户提案，会议每年重复、CFP 会复用到下个城市，第二次投稿应从第一次的文件开始。
7. 第 2 步，找到角度并先获批准：问用户“关于这件事，你相信什么而房间里大多数人不同意？”然后按排序给出候选角度，说出排序理由，推荐存活下来的第一名，等用户选择后再写文案。角度分三类：战争故事（提交前投入约一小时，前提是失败与数字已属于用户；换来审稿人可核实的可信度和别人无法复制的原创性，以及现场注意力和信任；当用户没有自己拥有且可公开的失败时不适用）；反主流论点（投入约一周，多用于收集证据和排练辩护；在四十份雷同提案中拿到最高 standout 分，换来记忆点和后续邀请；当立场在 Q&A 现场崩塌时不适用）；实用手册（投入约一周，把一个案例泛化成适用于别人技术栈的步骤；原创性得分最低、是审稿人见得最多的形态，但现场评分最高、是唯一会被人周一就落地的角度；当标题含糊时会在评审表上先死掉）。
8. 按不同维度排序并如实呈现：效率 战争故事 > 反主流论点 > 实用手册；评审表价值 反主流论点 > 战争故事 > 实用手册；现场价值 实用手册 > 战争故事 > 反主流论点；投入 实用手册 > 反主流论点 > 战争故事；合规成本 战争故事 > 反主流论点 > 实用手册。两条价值线要分开说，不要合成一个排名，因为“被接受”和“值得讲”是两回事。合规成本细说：涉及雇主事故的战争故事需要雇主批准、客户匿名化，常常还要安全审查，且日程公布后无法撤回；点名竞品的反主流论点在厂商中立会议上有较轻的同类风险；基于公开材料的实用手册没有这类成本。
9. 主动提升实用手册：当 track 描述明确要求实践者或 how-to 内容时；当目标是现场评分和该会议的再次邀请时；当访谈给出“可复用资产”答案时（手册是唯一能撑过五场会议、一份录像和一篇文字版的角度）；当步骤已作为内部 runbook 存在时（投入骤降到一小时，直接排到第一）。
10. 被用户约束排除的角度要直接删除并说明删了哪个、为什么，而不是列出来让用户选：没有自己拥有且可公开的失败就没有战争故事；没有排练辩护的能力就没有反主流论点。排序是默认值不是铁律，要按会议和讲者重新排序：已有录像和公众地位的讲者能撑起首次讲者撑不起的反主流论点；已发表的事故复盘让战争故事接近零投入；上一届同一 track 办过三场战争故事则把前两名对调。
11. 用上一届日程压力测试选定的角度：如果会议去年办过几乎相同的演讲，提案需要新视角（新数据、不同规模、失败案例或反主流解读）才值得占用投稿名额。
12. 第 3 步，标题：给五个按序排列的选项，从具体平实到有力。标题唯一职责是让审稿人读摘要、让参会者点开页面。可用模式：规模化的具体问题（“Cutting Cross-Region Egress in a 400-Service Estate”）、旅程（“From Cron to Workflows Without a Freeze”）、反主流主张、真实数字、承诺的失败（“The Migration That Passed Every Test and Still Lost Data”）。规则：遵守字符上限并逐字计数；具体优于含糊；去掉问号（几乎总比陈述句弱）；去掉需要解释的双关；厂商中立会议上去掉产品名；避免左半是含糊类别的冒号（“Developer Experience: A Deep Dive”）。
13. 第 4 步，摘要：这段文字会发布在日程上，要写给在五个房间之间做选择的参会者，而不是写给委员会。结构分三部分：钩子（一到两句点出读者立刻能认出的问题）、承诺（两到三句说明session里发生什么：案例、方法、结构）、回报（一到两句具体收获）。人称：会议逐字发布摘要时用第三人称，否则匹配去年日程可见的风格。用完整句子，不用标题，除非表单允许否则不用项目符号。把访谈第 4 题的真实数字写进去，具体数字是最便宜的 credibility。禁用开头：雇主名字；演讲从不回答的反问句；讲者个人心路；听众已知术语的定义。每次修改后报告相对上限的字符数，先删形容词、模糊限定词和堆叠修饰语。
14. 第 5 步，收获点：两到四条，动词开头，每条都是参会者事后会执行的动作（diagnose、instrument、audit、size、migrate、choose、measure）。“Understand X”和“appreciate the importance of Y”读起来像承认演讲还没有结构。按时长裁剪：lightning 一个想法一条收获；标准 session 一个问题两到三条收获。25 分钟讲八条收获等于告诉审稿人一条都落不了地。
15. 第 6 步，审稿人专属字段：多数表单有参会者看不到的字段（给审稿人的备注、对生态或社区的益处、大纲、前置要求、听众水平）。把摘要重复进去是浪费唯一能为自己辩护的地方。大纲：带分钟估算的流程，两层深——PyCon US 要求“枚举你打算讲的内容并附时间估算”，并说“两层项目符号列表格式最好”，它是演讲存在的证明。给审稿人的备注：为什么是这位讲者、已经做出来什么、demo 如何降低风险、这个角度在此处新在哪里。对生态的益处：房间之外谁受益、填补今年日程的什么空白、为什么是现在。前置要求：参会者必须已知或已安装什么。听众水平：如实填写，标错为高级会清空房间。Track：选描述匹配的 track，因为主席在 track 内排名，好提案投错 track 会输给更弱的对手。表单没有备注字段时，把最强的一句审稿人专属话并入摘要的回报部分，其余删掉。
16. 第 7 步，可信度包：审稿人会被问这位讲者能否交付这场具体演讲，具体性就是证据，热情不是。过往演讲录像是单一最强信号；没有的话，一段会议长度的录制练习或同材料的文字版也能让审稿人有东西可查。链接仓库、文章、基准测试和事故复盘，展示演讲背后的工作。简介用第三人称，两到三句，其中一句要把讲者与这个主题连起来，而不是罗列资历。只有在联合讲者带来不同视角（客户、迁移的另一方）时才加；承诺任何人之前先确认表单的讲者上限和 panel 组成规则。
17. 第 8 步，提交规则与 AI 政策检查：每条都可能让一份本来能赢的提案作废。以下规则读自 PyCon US 和 KubeCon + CloudNativeCon North America（Linux Foundation）的 CFP 页面，当作“该找什么”的示例，要读目标会议当前页面而非假设通用，因为上限和政策会随届次变化。每人投稿上限：多个大型会议限制每人投稿数，超限者所有投稿都会被移除——PyCon US 上限三份，“若个人提交超过三份，其所有投稿都不会被评审”；KubeCon 同样上限，并限制每位讲者每个会议只能一个 panel 加一个非 panel session。回收内容：归档演讲的会议会检查同一 session 近期是否在其旗下办过。禁止推销：厂商中立会议上产品形态的提案“几乎总会被拒”——Linux Foundation CFP 的原话；产品可以是教训来源的背景，不能是主题。Panel 组成：允许 panel 的形式会有公布规则——提交时列出所有 panelist、代表不止一家公司、不得有三位及以上自我认同为男性的讲者；点名任何人前先确认。AI 政策：读它并告诉用户内容。PyCon US 拒绝“完全或大部分由大语言模型生成文本撰写或包含此类文本”的提案，且没有第二次提交机会；CNCF 允许辅助但拒绝“低质量或明显 AI 生成的 slop”，并禁止惯犯参加未来 CFP。Humanizer 处理：最终文案跑一遍你惯用的 humanizer 技能，模型味正是审稿人现在会模式匹配的东西，会在想法被读到之前就毁掉可信度。披露：表单要求时说明雇主或项目隶属关系，审稿人反正会知道，隐瞒比申报更糟。无论政策如何，这里产出的一切都是草稿，用户必须用自己的声音和具体细节重写——要把这句话说出来，不要假设他们知道。
18. 第 9 步，按委员会标准自评：用四个轴给完成的提案包打分（1-5），每项写理由，用审稿人而非作者的口气。Content：连贯、有结构、可交付吗？1 分是有主题没形状，5 分是有分钟数和清晰弧线的大纲。Originality：有新想法、角度或数据吗？1 分是这个会议去年办过的演讲，5 分是别人无法描述的失败。Relevance：会议、track 和时机对吗？1 分是泛泛可放任何地方，5 分是回答这个社区当下正在争论的问题。Speaker：是对的人且有证据吗？1 分是“我对此充满热情”，5 分是有录像加生产数字。
19. 通过阈值：这个门槛由本技能设定，不是任何委员会发布的（没有会议公布审稿人的数字及格线），它是工作基线，用来强制在审稿人最容易走神的地方重写。六条全部满足前不要提交，针对不满足项迭代：1) 第 9 步没有任何轴低于 3，且 Content 和 Originality 至少 4；2) 摘要至少包含一个用户能溯源的数字、系统或规模；3) 每条收获都以动作动词开头且符合时长；4) 每个字段都在字符上限内，是数出来的不是估的；5) 审稿人专属字段说了摘要没说的东西；6) 完全不了解用户的读者也能看出为什么由这位讲者来讲。第 8 步的硬规则是另一类约束：投稿上限、推销禁令、AI 政策和 panel 规则由会议自己发布；用户对分数有异议时，告诉他们是在跟哪一类争论——自设阈值可谈，公布的上限不可谈。
20. 第 10 步，结果之后：被接受则交接给 samber/developer-relations-skills@tech-talk-outline，并兑现摘要里的承诺（参会者会引用回来）。被拒则索取反馈再改投：提案是可复用材料而非一次性票，改 track、改框架或改会议，趁材料新鲜在本季度内重投。无回复则把截止日加公布的通知日视为最终结果，把提案转投别处。
21. 注意会议类型与听众会改变文案，要明确告诉用户而不是留作隐含。社区/基金会会议是厂商中立的：产品只作为故事背景出现，公平点名竞品，开源项目附链接；厂商自办会议规则相反——产品深度才是重点，提案靠客户成果和实现的具体性竞争。为一种写的提案投给另一种，两个方向都会显得不合时宜。B2B 主题：房间里部分人在替别人评估，摘要应点出组织成本（迁移工作量、运维负担、团队因此停做的事），并停留在公司已公布的数字内。个人自助采用：参会者自己决定，如实写出免费路径、首次见效时间和限制。其余内容（角度、标题机制、摘要形态、收获动词、可信度）对两者完全相同。
22. 度量：一份提案投一个会议是抛硬币。大型会议每份提案有多位审稿人，然后主席排名，再做主题分布、讲者多样性和首次讲者的平衡调整，所以强提案也可能因作者无法影响的原因落选。不要向用户引用接受率：PyCon US 和 KubeCon 的 CFP 页面都不公布投稿或接受数量，流传的“约十分之一”没有一手来源。判断练习质量而非单次尝试。信号：一个季度投稿的接受率（唯一诚实的质量信号，且只在 8-10 份投稿上才有意义，这是本技能设定的工作样本量而非公布值）；同一提案被哪些会议接受/拒绝（是契合度不是质量，应改投而非重写）；书面审稿反馈（可得时价值最高，每次被拒后都去要）；候补或“很强但没位置”的备注（提案是有效的，原样改投别处）；lightning 还是主 track 被接受（是形式策略不是想法强度）。用一个文件记录投稿：会议、形式、角度、结果和任何反馈，下个 CFP 季从这个文件开始。
23. 把反复入选的讲者做法明确告诉用户：Nina Zakharenko 说“不要害怕被拒。尽可能多投提案。被拒的演讲一定要索取反馈。”投入要比感觉合理的更多：swyx 为他的第一次会议演讲在 CFP 上花了一个月。首次提案建议先在 meetup 上讲一遍再投会议：Alaina Kafkes 认为这验证了演讲收窄后的范围，这个模式在实践者叙述中反复出现。
24. 避开失败模式：产品推销伪装（标题或首句出现产品名——围绕问题重写，产品变成背景）；书一样大的范围（“我们会覆盖 REST、GraphQL 和 gRPC 以及如何选择”——只留一个角度，或申请更长形式）；可互换的标题（能套五十个别的演讲——加上系统、数字或张力）；以讲者为中心的摘要（“我会带你们走过我们的旅程”——每句都从参会者一侧重写）；understand 类动词（“理解可观测性如何契合你的技术栈”——换成参会者执行的动作）；字段复制粘贴（给审稿人的备注重复摘要——写不属于公开文案的辩护）；超上限（摘要 1800 字符对 1300 上限——每次编辑后计数，先删模糊限定词）；投错 track（投给名字最好听的 track——匹配 track 描述而非氛围）；无法核实的声明（“巨大的性能提升”——换成用户能溯源的数字，否则删掉）；模型文风（节奏均匀、无具体细节、无个人声音——跑 humanizer 并让用户自己重写）。

适用边界 · 注意事项

• 不要用于组织已被接受的演讲结构（应交给 samber/developer-relations-skills@tech-talk-outline）或设计其 demo（应交给 samber/developer-relations-skills@developer-live-demo-design）。
• 本技能范围止于提交；用户想要幻灯片或叙事弧线时应交接，不要越界。
• 用户答不出访谈第 4 题（没有第一手经验）时不要继续：没有第一手材料，提案会变成综述型演讲，属于反复出现的被拒模式。