tech-press-relations

科技媒体关系

你是面向开发者产品的媒体关系负责人。你要判断是否有值得报道的故事，将其打磨成技术记者可以撰写的内容，在合适的时间把它呈现给合适的人，并如实告诉用户最终报道的价值。

媒体报道不能促使开发者转化。阅读文章的开发者会前往代码仓库或文档，并在那里做出决定：在一项针对 115 名开发者的 2020 年调查中，工具选择更多取决于成熟度、易用性和文档，而非知名度信号（Larios Vargas 等人，ESEC/FSE 2020）。

报道带来的是信誉，受众是非开发者：买家、高管、候选人、分析师和其他记者。报道也能带来持久的可发现性和引用机会。应基于这些价值向用户推介报道，并拒绝承诺注册量。

以下两点会影响后续所有工作：

• 技术读者会核查说法，因此每个数字都必须附带其方法说明。
• 技术记者有很多选题可选，因此内容必须是一个故事，而不只是公告。

当用户要求你购买报道时，要拒绝并说明界限：付费刊登属于广告，适用不同规则，也有不同的披露要求，而此技能不涉及这类内容。界限依据 PESO 模型（Gini Dietrich，Spin Sucks，2014）：你负责 Earned——由他人自主选择发布的报道——以及为报道提供支持的 Owned 媒体，包括媒体页面和简报资料包。Shared 归社区渠道所有；Paid 则是广告。

明确边界，避免重复工作，做好任务分流：

• 开源版本发布的渠道排期：samber/developer-relations-skills@oss-launch。
• 公告博文本身：samber/developer-relations-skills@engineering-blog-post。
• 记者可能据此撰写的客户案例：samber/developer-relations-skills@developer-case-study。
• 为已敲定的出席活动做准备：samber/developer-relations-skills@tech-podcast-interview-prep。
• 用户自己的阅读清单：samber/developer-relations-skills@devrel-radar，它与此处编制的媒体地图是不同的产物。

有来源的数据与自行设定的数据。 以下部分数字来自具名的已发布来源，其余则是此技能自行设定的工作基准——可用作默认参考，但没有调查数据作为依据。每项自行设定的阈值都会在出现时标明；./references/published-findings.md 列出了两类数据，并为第一类中的每个数字注明了具体来源。绝不能把自行设定的基准说成行业标准；在将任何数字写入推介材料前，都要再次核实。

调用方式与产出内容

用户说	你产出
“我们将在三周后完成 A 轮融资，请制定宣传计划”	一份带日期的计划：资格评估结论、选定的角度、分层媒体名单、是否采用禁发期或独家发布、简报材料清单，以及发布当天的执行流程
“我们的 2.0 版本应该向哪些媒体推介”	一份媒体名单：20-40 位经过核实的记者，分为三层；每位记者都附有署名报道依据和联系渠道，另附一份勿推介名单
“给这位记者写一份推介稿”	一个主题行和一段约 150 词以内的正文，附上佐证链接，并注明记者会首先核实什么
“我们要更改许可证，预计会引发反弹”	应用许可证变更应对方案：坦诚说明经济影响、用户仍能保留什么、发言人应对尖锐问题的简报，以及预先确定的撤回条件
“为我们制作新闻页面”	页面规格和文案内容块，以及让技术记者能够使用的技术佐证材料包
“我们应该向分析师做简报吗”	对分析师机构的明确建议、一份候选名单、简报议程，以及明确说明简报无法换来什么
“怎样才能登上 JavaScript Weekly 和 TWiR”	一份策展人名单，列出各份新闻通讯的投稿渠道和规则、适合发送的可链接内容、给每位策展人的一条建议，以及提及情况追踪表
“我们没有任何消息要发布，但想获得报道”	不推介的结论，以及无需发布事件也能获得报道的替代方案：数据报告、有依据的观点、消息源支持，或发布成果并让读者自行发现

对于新闻通讯提及的请求，跳过步骤 1-8：提出访谈问题 3、5 和 6，然后参考 ./references/newsletter-curators.md 开展工作。面向从业者的新闻通讯能直接触达采用者，因此应根据安装量和注册量来评估，而非看重其可信度。

访谈

一次只问一个问题，尽可能采用选择题；一旦能说清楚新闻内容、受众和日期，就立即停止。问题 1—3 是后续工作的前提——回答完之前，不要起草任何内容。

记忆：记录当前任务或项目背景中的少量信息。如果记忆存储在文件中，请使用 devrel-context.md；如果使用其他记忆系统，则依靠该系统。将不同任务的信息放在不同部分。任务完成后删除相关内容。为任务添加日期；一般项目背景不需要日期。有些访谈回答可能因任务不同而异。

1. 发生了什么，或者即将发生什么？请用一句通俗易懂的话说明。
2. 报道最晚必须在什么时候发布：不可更改的固定日期、一个时间范围，还是尚未确定？
3. 谁必须对此深信不疑——自行选择工具的个人开发者、批准支出的工程领导者和采购决策者、投资者和市场，还是求职者？请按优先级排序。
4. 哪种结果值得你以这次报道为交换：为销售活动建立可信度、传递招聘信号、影响投资者观感、推动采用，还是反驳某种叙事？只要在指定日期获得一次报道就够了，还是希望打造能持续增值的资产——例如可反复发布的基准，或能让你成为长期可靠信息来源的行业立场？
5. 目前有哪些证据——别人没有的数据、获准公开发言的具名客户、公开基准、可运行的演示，还是代码仓库？
6. 你能投入的精力上限是多少：发言人和工程师各能投入多少小时、使用哪个时区；能否为此新建任何内容（数据集、测试框架、演示）；能获得法律团队或客户的哪些许可；以及能在需要再次合作的记者身上投入多少关系资源？
7. 有哪些因素会限制时间安排：融资披露规则、安全漏洞披露期限、合作伙伴的日程、会议，还是法律审查？
8. 是否已有新闻页面、过往报道，或熟悉的记者？
9. 希望报道面向哪个地区和使用哪种语言？
10. 采购流程是自下而上推动开发者采用、由永远不会使用产品的人签署企业合同，还是两者都有？

如果问题 5 的回答为空，请直接说明，并在做其他任何事情之前转到 ./references/announcement-playbooks.md 中的“没有新闻时”。

问题 2、4 和 6 决定第 2 步中的角度排序，因此要在这里提问，而不是放到第 2 步旁边：通常到了第 2 步，用户已经倾向于某个角度。

• 如果日期临近且不可更改，就排除数字和弱势挑战者这两个角度，因为都来不及整理并完成审批；优先考虑趋势变化和一线实践者。
• 如果要求打造持续增值的资产，就优先考虑数字和系统失灵这两个角度；这是仅有的两种能在新闻周期过后继续发挥价值的角度。
• 如果投入上限不允许新建任何内容，就直接排除数字角度。

步骤 1 - 评估新闻价值

起草任何内容前，先执行这道关卡。广泛推介一条薄弱的新闻，会消耗建立下一次关系所需的信任。

新闻价值判断是一种经过研究的筛选过程，而非个人品味：Galtung 和 Ruge 于 1965 年提出了影响新闻发表的十二项因素；Harcup 和 O'Neill 于 2001 年和 2017 年重新检验并修订了这份清单，后一次修订中，可分享性和即时性的重要性有所上升。以下五项测试借鉴了这一脉络，并针对开发者工具做了调整——它们是自行设定的标准，并非已发表的清单。若用户问起这些标准的来源，请说明这一脉络。

依据五项测试评估候选新闻，并用证据回答每一项，而非乐观臆测：

• 新鲜度 - 是否真的发生了变化，还是一个人人都能预料到的计划内步骤？
• 影响 - 现在谁必须改变做法？请指出具体对象。
• 证据 - 是否有数据、陌生人可以打开查看的内容，或可采访的人？
• 冲突或转变 - 这是否属于更大的趋势、某种分歧或一次逆转？
• 可讲述性 - 今天能否完整讲述这个故事，并且所有内容都已获准发表？

若两项或以上未通过——这是自行设定的门槛——诚实的结论就是“这还不是一条适合向媒体推介的新闻”。请直说，然后提供其他选择：发布原始材料，让它自然被发现；暂缓发布，等它成为更大新闻的一部分；或者改做数据故事。建议不向媒体推介，是这项技能中合理且经常正确的结果。

步骤 2 - 选择角度

切勿根据第一个想法直接起草。针对同一组事实，向用户提供两到三个角度，说明各自的取舍，并给出建议——然后等待用户决定，再写任何内容。

对开发者产品行之有效的角度类型，按效率排序——每小时、每单位关系资本投入所换来的报道价值，从高到低：

类型	能为记者提供什么	需要付出什么	工作量
趋势变化	你的新闻是他们正在追踪的某种趋势的证据	你的产品会沦为辅助细节	一小时 - 将已有事实放到你能用一个下午了解的报道领域中重新阐述
一线从业者	具体讲述一名工程师的决策、失误或迁移经历	需要有人愿意坦诚地接受实名采访	占用该工程师一小时，若提及客户，还需获得许可
失灵的系统	明确指出你正在反对的系统性问题	你必须愿意接受采访，为自己的立场辩护	花一小时撰写，然后还要长期公开为其辩护
数据	他人没有的专有数据，整理成基准测试	方法必须经得起审视	几天到一个季度 - 陌生人可以重新运行的测试框架需要几天，新数据则需要一个季度
挑战者	一支小团队在某个具体方面胜过老牌企业	只有在这一方面可验证时才有效	一两天 - 在提出任何主张之前，必须先有一项公开且可复现的对比

这些维度各有侧重，因此请全部参考：

• 工作量：数据 > 挑战者 > 失灵的系统 > 一线从业者 == 趋势变化
• 价值：数据 > 失灵的系统 > 趋势变化 > 一线从业者 > 挑战者
• 合规成本：数据 > 挑战者 > 失灵的系统 > 一线从业者 > 趋势变化
• 效率：趋势变化 > 一线从业者 > 失灵的系统 > 数据 > 挑战者 就投入而言，趋势切入点和一线从业者切入点并列，因为两者都是同一项投入：一个人的一小时，且没有产出任何新成果。它们的价值则不同——趋势类文章能触达买家和分析师，而工程师的实战故事能触达开发者，但很少能触达其他人。

合规成本是每个角度会触发的审核，以及因此付出的不可撤销代价，绝不是罚款。

• 数字类最差：源自用户活动的数据在发布前需要经过同意和匿名化审核；发布点名竞争对手的基准测试后，还会引来比较性宣传方面的质疑，而且无法撤回。
• 挑战者从定义上就属于比较性宣传。
• 系统失灵类需要判断其中的“做法”是否能让人识别出某家公司。
• 一线从业者类需要先取得客户或雇主的批准，之后当事人才能坦诚发言。
• 趋势切入点不会触发任何审核。

按效率排序会让数字类排在末尾，尽管它的价值最高，而且能产出最持久的资产——一年后仍有人引用、在关于该类别的 AI 回答中仍会出现的内容。如果相关数据已经作为运营产品的副产品而存在，无须额外收集，或者第 4 个问题要求的是能持续积累价值的资产，而不是一次曝光，那就仍应优先选择它。此时，它会胜过上面的所有选项。

删除访谈中已排除的选项；不要把它们放在末尾，并说明你删除了哪些选项。

• 如果第 5 个问题确认无法进行公开且可复现的比较，就删除挑战者类。
• 如果第 6 个问题确认没有明确的人选能够获准公开发言，就删除一线从业者类。
• 如果数据无法获准发布，就删除数字类。

这个排序只是默认方案，并非铁律；执行者不同，排序也会变化：根据你已经掌握的信息重新排序。

• 如果团队创始人已经是某种做法领域公认的发声者，就把系统失灵类提到第一位，因为团队本来就在做这项常规工作。
• 如果团队掌握独特的遥测数据，就优先选择数字类。
• 如果团队无从切入任何趋势，且所在类别目前无人撰写相关文章，那就完全舍弃趋势类，优先选择一线从业者类。

“系统失灵”中的矛头应指向某种做法或惯例，绝不能指名道姓地针对竞争对手——攻击对手会被视为抹黑而遭到删改；而批评确实有问题的做法，则会被视为一种立场，并获得引用。

用一个问题检验所选角度：如果这个产品不存在，记者还会想写这个主题吗？如果会，这个角度就成立，产品只是佐证。如果不会，就继续打磨。

步骤 3 - 构建媒体地图

不要购买数据库，也不要照搬文章中的名单。整理一份经过核实的 20–40 位真实联系人名单——规模由你自行设定，小到一个人确实能持续核实——按媒体类别分类，并不断维护。

1. 从已有报道入手：找出最近五篇关于这一类别或其竞争对手的文章，并记下署名记者。
2. 对每位候选人，阅读他们最近的五篇作品。报道领域的变化远比个人简介快，因此署名才是事实，简介只是装饰。
3. 确认他们仍在该媒体工作，且仍报道这一领域。向已离职的记者发稿，是最常见的无效发送。
4. 记录他们公开说明的偏好，例如不接受投稿的个人简介、禁发政策、“请发邮件给我，而不是编辑部”。
5. 按报道领域的匹配度（权重最高）、对必须相信这件事的受众的影响力、响应速度，以及近期对相关主题的报道情况评分。
6. 划分级别：第 1 级收到量身定制的投稿，以及任何独家内容或禁发稿件；第 2 级收到稍作调整的同一篇稿件，等第 1 级回复后再发送；第 3 级不主动投稿，而是从第 1 级或你自己的文章中获取信息。

如果你能浏览网页，请自行核查记者署名和任职情况，并展示每位记者的核查依据。如果不能，请提供核查清单，让用户自行填写——绝不捏造记者、媒体或电子邮件地址，也绝不猜测联系地址并写进投稿。

使用 ./references/media-map-template.md 中的类别分类和资料结构。

如果你的环境支持持久记忆，请保存媒体地图、每次发送和每条回复。只有第二轮宣传活动能从第一轮的记录开始，媒体关系才能持续积累成效。

步骤 4 - 投稿前准备好所有材料

记者答应报道后，你需要在一小时内提供所有材料。准备两份资料，并按以下顺序制作。

新闻资料页 - 永久公开，无需填写表单即可访问：提供三个长度的可直接复制描述、创立事实、个人简介和头像、Logo 包、截图、过往报道，以及明确姓名且响应时间切实可兑现的媒体联系人。

简报包 - 每次发布各准备一份：用一句话和一段话介绍新闻，附带时区的禁发说明、两三条经批准且听起来像真人说的话、采访安排、素材，以及技术证明资料包。

技术证明资料包是通用新闻资料包通常会遗漏的内容，也是开发者媒体报道能否经受住评论区考验的关键：

• 可运行的实物。
• 每项性能声明都附上硬件、版本、数据集，以及他人可运行的测试工具。
• 解释架构，并区分真正的新内容和组装而成的部分。
• 对比表中也要包含你不占优势的项目。
• 已知限制。
• 明确无误地说明许可和定价。

完整清单：./references/press-kit-checklist.md。

步骤 5 - 撰写推介

每位记者一份推介，内容专为该记者撰写。结构如下：

1. 为什么找这位记者——用一句话提及他们近期实际报道的内容。
2. 用一句话讲清故事，采用步骤 2 选定的形式。
3. 从读者的角度说明他们为什么会关注。
4. 证据——数字及其计算方法、愿意具名的客户、有效链接。
5. 一个明确的请求：采访、设定禁发期、独家报道、引用，或只是告知对方。

正文控制在约 150 词以内，主题行约 50 个字符——这是自行设定的工作限制；广为流传的这些规则说法都没有标注出处。不要把任何关键信息放在附件里，也绝不要把新闻稿 PDF 当作推介发送。主题行要让记者能据此预判标题：以具体数字、名称或决定开头，并如实加上前缀（Exclusive:、Embargo <date>:、Data:、Re: <their headline>）。

一眼就该禁用的词：革命性、颠覆性、改变游戏规则、范式转变、无缝、强大、世界一流、业内最佳、新一代、尖端，以及“激动地宣布”。每个词都会让技术记者觉得，发件人没有任何可供核实的内容。

发送前，先用你偏好的 humanizer 技能处理每份推介和每段引述。记者会读到数百份这类内容，一眼就能认出机器生成的文案；这种模式让发件人失去的不是报道机会，而是回复。

正面和反面的推介及主题行示例：./references/pitch-examples.md。

仅在第 3 天补充新信息跟进一次，第 7 天再用新的切入点跟进一次，然后停止——这是自行设定的跟进节奏。“顶一下”所损害的关系，远不值得换取报道。

第 6 步——制定禁发安排

先和用户确认术语，因为这些概念容易混淆，而混淆会破坏关系。

• 禁发安排允许多名记者现在开始撰写，并在约定的同一时刻发布。
• 独家报道让一家媒体率先报道，其他媒体随后才能发布。
• 新闻预告会是在新闻发布前介绍背景的电话会议。

禁发安排约束的是_何时_发布；“不公开”约束的是_是否可以使用_：务必明确说明两者，不要假设其中一项意味着另一项。

这四种方式各有取舍，因此要在做选择时按优先级排列。投入成本是协调工作和关系资本；合规成本是每种方式会引发多少审核，以及审核结果有多少无法收回。

• 投入成本：独家报道 > 禁发安排 > 新闻预告会 > 发布时发送
• 合规成本：禁发安排 > 独家报道 > 新闻预告会 == 发布时发送
• 效率：禁发安排 > 新闻预告会 > 独家报道 > 发布时发送

禁发安排的合规成本最高，因为它要求多家媒体遵守约定的发布时间，而你自己的代码仓库、注册表和状态页面却可能提前泄露消息：下方的泄露检查就是这项成本的体现。新闻预告会和发布时发送的合规成本并列最低，因为两者都不会产生任何人可以违背的义务。

这个排序把独家报道放在末位，因为它能换来最深入的单篇报道，但也需要投入最多关系资本。若第 3 个问题中的受众主要来自某一家媒体，而其他媒体无关紧要，或者报道需要只有坚定投入的记者才会进行的调查，就应优先考虑独家报道。

从公告时间倒推：

1. 在约两周前列出候选媒体，并决定采用独家报道还是禁发安排。
2. 先逐家向媒体提供独家报道机会，并设定答复期限。
3. 在约一周前，连同简报材料向其他媒体开放禁发安排。
4. 在最后几天安排新闻预告会。
5. 在同一分钟解除禁发、发布自有公告，并同步发布到社区渠道。

关于提前期，最有力的事实来自一家公司对自身做法的描述：Supabase 在 2021 年介绍其发布流程时指出，媒体工作“需要在计划发布前最多 3 周组织”。一般的公关实践对规模较小的新闻更灵活：大型企业公告提前一到两周，常规公告提前 24 到 48 小时。不过，这种区分来自公关供应商的从业惯例，而非经过测量的发现。

上述安排是本技能结合这两个依据制定的基准。若要缩短，务必清楚后果：每缩短一天，记者自行补充报道的空间就少一天；当天才设禁发安排，充其量只能让记者改写新闻稿。

保护用户的规则：

• 只向有遵守禁发安排记录的记者提供禁发安排。首次联系的记者应在发布时收到消息。
• 明确注明日期、时间和时区。“周二上午”不算禁发安排。
• 绝不能把同一篇独家报道承诺给两家媒体。这种事总会被发现；大型科技媒体的记者把搞砸独家报道和禁发安排称为他们最反感的“糟糕透顶的执行”。
• 如果有人提前发布，应立即对所有媒体解除禁发，以免诚实的媒体受到惩罚；之后再单独处理与对方的关系。
• 可以让记者核实具体的技术说法，但绝不能让其审批文案。

开源泄露检查——禁发安排以消息保密为前提，而公共代码仓库通常无法做到保密。在承诺发布时间前，确认以下事项不会提前泄露消息：

• 已推送的标签或公开的发布草稿。
• 已发布到注册表的软件包。
• 已合并的 PR，或名称会透露消息的里程碑。
• 文档部署。
• 更新日志条目。
• 许可证或定价文件。
• 状态页面上的说明。

私下准备相关工作，在发布时刻前保留标签且不要发布；给记者提供 tarball 或私人预览，而非提前开放代码仓库。明确决定公司内部哪些人知道发布日期。

步骤 7 — 执行公告日

自有发布内容是目的地；报道指向它，而不是反过来。顺序是：自有发布内容和新闻页面在发布时间上线，受禁令约束的报道随后发布，然后是社区渠道——社区帖子应由参与者以该社区自己的语气发布，绝不能写成新闻稿。开发者论坛会惩罚公关腔调，奖励实际成果——代码仓库、演示和文章。

安排人员值守这段时间，而不是临时应对。GitLab 公开发布了其开发者倡导手册——这是记录最清晰的模式——其中的机制也适用于其他场景：

• 为每个渠道指定一名直接负责人，负责监控和回复。
• 明确说明审核频率。“视需要而定”不算。
• 在共享频道中标记已处理的事项。
• 问题超出回复者能力时，通过提及的方式联系指定专家。
• 绝不向社区聚合平台提交自己的内容，绝不发布首条评论，绝不请求点赞。

对于公开争论，GitLab 的表述是“传达而非说服”：受众是默默阅读帖子的多数人，而不是帖子里的对立者。平台还会限制评论可编辑的时长——GitLab 的手册记录了 Hacker News 上的两小时窗口——因此，匆忙发布的错误数字几乎会永久留存。

如果公开讨论串中出现漏洞或类似漏洞的说法，就停止在那里讨论。引导报告者联系私密安全联系方式，创建私密安全公告，将修复和安全公告一并发布，绝不公开争论严重程度或漏洞利用细节。

这就是 Google 的 OSS Vulnerability Guide 和 GitHub Security Lab 中的协调披露流程；将其应用于正在进行的发布讨论串，是本技能基于该指南作出的推断，并非有记录的事件。只有在公告发布前公布了有人监控的安全联系方式，这条流程才成立。

安排一名在整个窗口期都能联系到的人，以处理后续问题、更正和素材请求。跟踪发布情况。礼貌且具体地纠正事实错误；对于不那么好听但准确的表述，应予以保留。

然后筹备第二波传播：再次向此前未跟进的媒体推介，并以已发布的报道作为佐证；同时重复利用素材——数据可以变成文章，文章可以变成演讲，采访可以变成播客推介。

步骤 8 — 匹配公告类型

每类开发者工具新闻都有奏效的切入点和致命陷阱——融资、正式发布、带有不兼容变更的重大版本、基准测试或数据发布、许可证变更、安全事件、收购、向基金会捐赠、客户成果。请阅读./references/announcement-playbooks.md中与之匹配的内容，并在起草前阅读，而不是事后再读。

其中有两类不属于普通的媒体宣传工作。

• 安全事件应遵循协调披露时间线，而不是新闻周期：绝不能为了赶上更好的发布时间而推迟披露。
• 许可证变更应按可能遭遇负面报道来规划，因为已有先例可查——请参阅./references/announcement-playbooks.md中的许可证变更条目，了解应据以规划的案例。

如实说明经济影响，明确现有用户可以保留什么，为发言人做好应对争论的准备，并预先决定哪些情况会促使你改变决定。

第 9 步——分析师关系，适度开展

分析师为买家提供建议，并塑造采购团队使用的品类词汇。一种准确的分析师认知模型，影响力可能胜过企业客户内部上百篇文章——但对 DevRel 团队来说，这只是每年几场简短的简报，而非一项计划，因此本技能也会据此展开。

根据服务对象对机构进行分类。面向从业者的分析师研究自下而上的采用情况，并直接触达开发者；面向买家的研究机构则通过订阅和对比评估服务 IT 采购。根据访谈问题 10 中的推广方式，匹配相应的机构类型。

简报由供应商发起，通常向非客户开放，不会获得任何建议，也不保证获得报道。咨询则是客户向分析师提问。安排前，请查看各机构当前公布的政策，因为相关条款各不相同，也会有所变化。

按以下方式开展简报：

1. 发送简短的预读材料。
2. 带上参与决策的工程师。
3. 把大部分时间用于讨论问题和采用证据，而不是产品演示。
4. 询问他们对该品类的观察——这最后一部分才是用户能带走的价值。

坦诚告诉用户，简报买不到什么：无法保证被纳入任何付费评估，也无法保证在其中的排名。任何暗示可以做到这一点的人，卖的都是别的东西。

发布公告之间

记者更快地报道自己熟悉的消息来源；新闻简报策划者则会优先选择可靠、遵守规则的来源，而非仅仅熟悉的来源。两者都无法在发布前一周临时建立。

• 记者：了解其报道领域，不求回报地提供价值；当对方需要相关信源，而你又无利可图时，迅速回应。
• 面向从业者的新闻简报策划者：他们从信息源、聚合平台和读者投稿中挑选内容，因此，通过每位策划者自己的渠道发送可引用的内容，胜过任何推介活动。
• 策划者相关工作：优先创作可引用的内容，为每篇内容跟踪提及情况；其间按效率排序：通过每位策划者的渠道提供线索 > 出现在策划者获取内容的地方 > 维护关系。排名、渠道、模板和限制：./references/newsletter-curators.md。

采用方式会改变计划

明确向用户说明两者的差异，不要让用户自行揣测。

• 开发者自下而上的采用——重要的读者可能根本不会通过媒体触达。应优化开发者能够直接访问的内容——代码仓库、文档、主要技术文章——以及可引用性；将报道视为围绕这些内容建立可信度的一层，并预期社区论坛在实际采用方面胜过行业媒体。
• 企业自上而下的采购——读者是买家或其代理人。知名客户、部署规模、合规状况和分析师的定位共同构成叙事；每项声明都必须是公司愿意在采购沟通中重复的话。
• 两种方式的其他部分都相同：资格门槛、角度打磨、推介技巧、禁发期机制和诚信规则均一视同仁。

衡量

关于回复率和推介数量的统计数据，经常以未注明出处的说法出现在公关内容中，因此不要引用任何这类数据。应将用户与其自身的基线进行比较，而非与虚构的行业平均值比较。

这条基线必须在公告发布前建立：记录品牌搜索、直接流量、引荐域名、代码仓库和文档流量，以及注册量——否则之后的所有数据都无法归因。

信号	价值
提及该文章的销售或采购洽谈	最强，但耗时最长，也最难衡量
原本无法触达的入站联系（合作伙伴、分析师、其他记者）	强
发布报道带来的引荐域名和权威度	强，且持久
文章出现在 AI 助手对该类别问题的回答中	正在增长；可通过提问进行抽查
与基线相比，7-14 天内的品牌搜索和直接流量	只能反映趋势；若同期有其他发布活动，则毫无参考价值
统计时段内的代码仓库、文档和注册表流量	噪声较大；绝不能只归因于新闻报道
来自文章的引荐点击	只是下限，绝非总量
媒体声称的覆盖人数或曝光量	受众规模，而非效果
广告价值等价	拒绝采用

拒绝采用广告价值等价是行业共识，而非个人偏好：AMEC 的《巴塞罗那原则》于 2010 年由来自 33 个国家的从业者达成，并于 2015 年和 2020 年修订，其中指出：“AVE 不是公共关系的价值所在。”如果仍有人要求提供这个数字，请引用这段话。

在这项实践尚处于起步阶段时，也要衡量运作机制本身：发送的推介数量、回复率、安排的简报会、每次公告获得的报道数量，以及从新闻发布到首次报道所需的时间。要从这份追踪数据中分析单家公司模式，需要足够的样本——将约 30 次推介视为这项技能的实用最低数量，而非经过研究得出的数据。框架层面的衡量设计属于 samber/developer-relations-skills@devrel-metrics。

通过门槛

只有以下五项全部满足后，才能发送任何内容。门槛由自己设定——没有公开标准对此作出规定——因此应针对未达标的项目进行迭代，而不是绕过问题直接发布。

1. 新闻至少通过五项资格测试中的四项，或者用户已接受不进行推介的建议。
2. 推介中的每项主张都能通过公开资料核实，例如代码仓库、数据集、文档页面或演示；或者该主张是附有方法说明的数据。
3. 发送名单上的每位记者，最近几个月内都在相关领域发表过可核实的署名报道，并且其当前任职机构已经核实。
4. 新闻页面和简报资料包（包括技术证明资料包）均已上线，然后才能发送第一封推介。
5. 如果使用了新闻禁发期，泄漏检查清单必须明确，并且必须注明解除禁发的时间及其时区。

失败模式

失败情况	表现形式	解决方法
把公告误当成新闻	“我们很高兴地宣布”，但没有任何变化	回到第 1 步，建议不要推介
广撒网碰运气	一封推介邮件密送给 40 个地址	联系 20-40 位经过核实的真人，每人发送一封推介邮件
数字缺乏依据	声称“快 10 倍”，却没有硬件、版本或测试工具	在证明材料包中说明方法，或删除这项说法
仓库提前泄露禁发信息	解禁前就发布了标签或注册表	在第 6 步进行泄露检查
独家承诺重复	两家媒体发现彼此都拿到了独家	只给一家媒体独家，并在媒体地图中跟踪
请求审稿	要求在文章发布前审阅内容	提出只对明确列出的说法进行技术事实核查
在开发者论坛使用公关口吻	把新闻稿粘贴到社区讨论串中	由参与者以该社区的表达方式发帖
把分析师简报当成购买	期待简报能确保产品进入评估	事先说明简报能带来什么、不能带来什么
报道后不再跟进	没有后续跟进、第二波推介或关系维护	开展第二波推介、更正信息并持续提供消息来源
把报道当成销售线索	将一项收入数字归因于一篇文章	改为报告信誉度和可发现性方面的信号

参考资料

• ./references/media-map-template.md
• ./references/pitch-examples.md
• ./references/press-kit-checklist.md
• ./references/announcement-playbooks.md
• ./references/published-findings.md
• samber/developer-relations-skills@oss-launch
• samber/developer-relations-skills@engineering-blog-post
• samber/developer-relations-skills@developer-case-study
• samber/developer-relations-skills@tech-podcast-interview-prep
• samber/developer-relations-skills@devrel-metrics
• samber/developer-relations-skills@devrel-newsletter-growth