面向开发者产品做科技媒体公关时，如何判断新闻价值、选角度…

当你要为开发者产品争取科技媒体报道（融资、发布、数据报告、许可证变更等）时，用这套流程完成从新闻资格判断到发布日执行的全过程。

适用场景

解决思路

1. 先做访谈：一次只问一个问题，尽量用多选题，一旦能说清 news、audience 和 date 就停止。问题 1-3 是前置门槛，未回答前不要起草任何内容：1) 用一句话平实说明发生了什么或即将发生什么；2) 报道必须何时落地（不可移动的固定日期、时间窗口，还是不定时）；3) 谁必须相信这件事（自选工具的开发者、批准预算的工程负责人/买家、投资人与市场，还是候选人），并排序；4) 你愿意用报道换取什么结果（销售动作的可信度、招聘信号、投资人观感、采用量，还是防御某种叙事），以及一次发布是否足够，还是想要可复利的资产（可重复发布基准、让你成为常驻信源的位置）；5) 今天已有哪些证据（别人没有的数据、获准发声的具名客户、公开基准、可运行 demo、代码仓库）；6) 你的投入上限：发言人和工程师能投入多少小时、在哪个时区，能否为此新建东西（数据集、测试框架、demo），能从法务或客户拿到什么许可，以及能消耗多少与记者之间的关系资本；7) 时间限制：融资披露规则、安全披露截止日、合作伙伴日程、会议、法务审查；8) 是否已有 press page、过往报道或认识的记者；9) 报道应落在哪个地区和语言；10) 购买动因是自下而上的开发者采用、由不会使用产品的人签署的企业交易，还是两者兼有。若问题 5 答案为空，直接说明并先走 announcement-playbooks 中的“When there is no news”。
2. 用五道测试给新闻打分，每项都要用证据而非乐观回答：Newness（是否真的发生了变化，还是可预测的例行步骤）、Consequence（现在谁必须改变做法，点名）、Evidence（是否有数字、陌生人可打开的东西或可采访的人）、Conflict or shift（是否属于更大趋势、分歧或反转）、Tellability（今天能否完整讲述且全部获准发布）。失败两项及以上（自设门槛），诚实回答“这还不是 press story”，并给出替代方案：发布主要产物让其被找到、把新闻留到并入更大事件时、或改为做数据故事。推荐不 pitch 是合法且常常正确的结果。
3. 选角度时绝不要直接写第一个想法。针对同一组事实给用户两到三个角度，各自说明取舍并给出推荐，等用户决定后再动笔。开发者产品常用角度形态按效率排序（每小时和每单位关系资本换来的报道量，从高到低）：The shift（你的新闻是记者已在跟踪的趋势的证据；代价是产品沦为佐证细节；约一小时，把已有事实对照一个下午就能读懂的 beat 重新框定）、The practitioner（工程师的决策、错误或迁移，具体讲述；需要有人愿意具名坦率；约该工程师一小时，若点名客户还需许可）、The broken system（你明确站队反对的具名系统性问题；你必须愿意被引用并公开为其辩护；约一小时写作，之后长期公开辩护）、The number（别人没有的专有数据，打包成基准；方法论必须经得起审视；一周到一季度，收集数据并构建陌生人可重跑的测试框架）、The underdog（小团队在某一具体点上击败在位者；只有该点可验证时才成立；约一周，需要公开可重跑的比较）。
4. 读四个轴：effort（number > underdog > broken system > practitioner == shift）、value（number > broken system > shift > practitioner > underdog）、compliance cost（number > underdog > broken system > practitioner > shift）、efficiency（shift > practitioner > broken system > number > underdog）。compliance cost 指每个角度触发的审查及其不可逆程度，不是罚款：number 最差（用户活动数据需先做同意与匿名化审查，点名竞品的基准会招致无法撤回的比较性主张挑战）；underdog 本质就是比较性主张；broken system 需审查“做法”是否可被识别到某家公司；practitioner 需客户或雇主在坦率发言前签字；shift 不触发任何审查。
5. 效率排序会饿死 number，但它在 value 上领先且产出最持久资产（一年后仍被引用、仍出现在 AI 关于该品类的回答中）。当数据已作为产品运行的副产品存在（无需收集工作），或问题 4 要求的是可复利资产而非一次发布时，仍应把它提到最前，此时它胜过一切。
6. 删除访谈已排除的角度，不要放在底部，并说明删了哪些：问题 5 没有公开可重跑比较则删 underdog；问题 6 没有可获准具名发声的人则删 practitioner；数据无法获准发布则删 number。
7. 该排序是默认而非定律，会随执行者变化：创始人已是某做法公认声音的团队把 broken system 提到第一；坐拥独特遥测数据的团队把 number 提前；没有趋势可依附、所在品类当前无人报道的团队完全失去 shift，由 practitioner 领先。
8. “The broken system”的敌人是做法或规范，绝不是具名竞品——攻击对手读起来像抹黑会被删，攻击真正有问题的做法读起来像立场会被引用。
9. 用一个问题压力测试所选角度：如果产品不存在，记者还会想写这个吗？会，则角度真实、产品是证据；不会，则继续打磨。
10. 建媒体地图：不要买数据库，也不要复用文章里的名单。构建 20-40 个已验证真人的地图（自设规模，小到一个人能持续验证），按 outlet 类别组织并保持更新：1) 从已有报道向外扩展，找该品类或竞品最近五篇文章的署名；2) 对每个候选人读其最近五篇作品——beat 漂移远快于 bio，署名是真相、bio 是装饰；3) 确认他们仍在职且仍报道此领域，pitch 给已离职记者是最常见的浪费；4) 记录他们公开声明的偏好（no-pitch bio、embargo 政策、“email me not the desk”）；5) 按 beat 匹配度（权重最重）、对必须相信此事的受众的触达、响应度、话题近期性打分；6) 分层：tier 1 给定制 pitch 及任何独家或 embargo；tier 2 在 tier 1 回复后给轻度改写的同一故事；tier 3 不 pitch，从 tier 1 或你自己的帖子获取。
11. 若能浏览网页，自己完成署名与在职核查并逐记者展示证据；若不能，把清单交给用户填写——绝不编造记者、outlet 或邮箱，绝不把猜测的联系地址写进 pitch。使用 media-map-template 中的类别分类与产物形态。若环境有持久记忆，存储媒体地图、每次发送和每次回复；公关只有第二次活动从第一次记录出发才会复利。
12. 在 pitch 前先交付资产：记者答应后需要一小时内拿到一切。按顺序构建两个产物。Press page——永久、公开、前面无表单：三种长度的可复制描述、创立事实、bio 与头像、logo 包、截图、过往报道、具名 press contact 及你真正会遵守的响应时间。Briefing pack——每次发布一份：一句话和一段话的新闻、含时区的 embargo 行、两三条听起来像真人的获准引语、采访可用性、资产、技术证据包。技术证据包是通用 press kit 遗漏、却决定开发者媒体故事能否挺过评论区的那部分：可运行产物；每项性能主张附硬件、版本、数据集和他人可运行的测试框架；区分真正新东西与拼装部分的架构说明；包含你输掉那些行的比较表；已知局限；明确的许可证与定价声明。完整清单见 press-kit-checklist。
13. 写 pitch：每个记者一封，为该记者而写。结构：1) 为什么是他——一句关于其近期实际工作；2) 一句话讲清故事，用第 2 步选定的形态；3) 为什么其读者关心，从读者一侧陈述；4) 证据——数字及其方法论、将具名的客户、可用的链接；5) 一个明确请求：采访、embargo、独家、引语，或只是告知。正文控制在约 150 词以内，标题约 50 字符（自设工作上限；广泛流传的版本无出处）。不要把关键内容放在附件里，绝不把新闻稿 PDF 当 pitch 发。标题要让记者能预测出 headline：以具体数字、名字或决策开头，并诚实加前缀（Exclusive:、Embargo <date>:、Data:、Re: <their headline>）。
14. 禁用词：revolutionary、disruptive、game-changing、paradigm shift、seamless、robust、world-class、best-in-class、next-generation、cutting-edge 以及“excited to announce”。每个词都在告诉技术记者发件人没有可核查的东西。发送前把每封 pitch 和每条引语过一遍你惯用的人类化技能；记者读几百封这类信，一眼认出生成文本，这种模式会让发件人失去回复而不只是故事。
15. 跟进：第 3 天只在有新信息时跟进一次，第 7 天用新钩子再跟一次，然后停止（自设节奏）。“Bumping this”消耗的关系比这次发布值得的更多。
16. 先与用户统一 embargo 词汇，因为混淆会破坏关系：embargo 让多家记者现在写、在指定时刻发布；exclusive 给一家先发、其余之后拿到；pre-briefing 是新闻前的背景通话。Embargo 管“何时”，“off the record”管“能否被使用”：两者都要明确说明，绝不假设其一隐含另一。
17. 排序选择：effort（exclusive > embargo > pre-briefing > lift-time send）、compliance cost（embargo > exclusive > pre-briefing == lift-time send）、efficiency（embargo > pre-briefing > exclusive > lift-time send）。Embargo 居 compliance cost 之首，因为它把多家 outlet 绑定到指定时刻，而你自己的仓库、registry 和状态页可能替你破坏它——即下面的泄露检查。Pre-briefing 与 lift-time send 并列为零审查，因为都不产生可被违反的义务。该排序饿死 exclusive，它买到最深的单篇却花最多资本；当某家 outlet 的读者正是问题 3 的受众、其余都是噪音，或故事需要只有承诺的记者才会投入的报道时间时，把它提前。
18. 从发布日倒推：1) 约两周前确定候选并决定 exclusive 还是 embargo；2) 先一次一家提供 exclusive，给出答复截止时间；3) 约一周前向其余开放 embargo 并附 briefing pack；4) 最后几天做 briefing；5) 同一分钟解除 embargo、发布自有帖子并推送社区渠道。可用的最强提前期事实来自公司自述：Supabase 2021 年关于其发布方式的说明称 press“需要在你计划 Launch 前最多 3 周组织好”。一般 PR 实践对小新闻更宽松——大型企业公告提前一到两周，标准公告 24 到 48 小时——但该划分是 PR 供应商的从业惯例，不是实测发现。上述日程是本技能基于两个锚点的基线。要有意识地缩短：每去掉一天都从记者自行补充报道的能力中扣除，同日 embargo 最多产出改写过的新闻稿。
19. 保护用户的规则：只向有遵守 embargo 记录的记者提供 embargo，首次接触者在 lift time 才拿到新闻；说明日期、钟点和时区，“Tuesday morning”不是 embargo；绝不把同一独家承诺两次，这总会被发现，大型科技媒体的记者把搞砸的独家与 embargo 描述为他们最反感的“piss-poor execution”；若有人破坏，立即对所有人解除，使诚实 outlet 不受惩罚，再单独处理关系；提供对具体技术主张的事实核查，绝不授予稿件审批权。
20. 开源泄露检查——embargo 假设保密，而公开仓库很少提供保密。在承诺 lift time 前，确认以下都不会提前泄露新闻：已推送的 tag 或公开的 release draft；发布到 registry 的包；已合并的 PR 或名称泄露故事的 milestone；docs 部署；changelog 条目；许可证或定价文件；状态页说明。私下暂存工作，把 tag 和发布留到 lift，给记者 tarball 或私有预览而非早期仓库访问。明确决定内部谁知道日期。
21. 运行发布日：自有帖子是目的地，报道指向它而非相反。顺序：lift time 时自有帖子与 press page 上线，embargo 报道出现，然后社区渠道——社区帖子由参与者用该社区自己的语域发布，绝不作为新闻稿。开发者论坛惩罚 PR 语言、奖励工作本身（仓库、demo、文章）。
22. 为窗口配备人员而非临时应付。GitLab 公开其 developer-advocacy playbook——记录最清晰的模型——其机制可推广：每个渠道指定一名直接负责人监控与回应；说明审查节奏，“as needed”不算；在共享渠道标记已处理项；当问题超出回应者能力时用 mention 激活具名专家；绝不向社区聚合器提交自己的内容，绝不发第一条评论，绝不拉票。
23. 公开争论时，GitLab 的框架是“conveying without convincing”：受众是读帖的沉默多数，不是帖中的对手。平台还限制评论可编辑时长——GitLab 手册记录 Hacker News 为两小时窗口——所以匆忙发错的数字几乎永久。
24. 若公开帖中出现漏洞或形似漏洞的主张，停止在那里讨论。把记者转到私有安全联系渠道，开私有 advisory，修复与 advisory 一起发布，绝不在公开场合辩论严重性或利用细节。这是 Google OSS Vulnerability Guide 与 GitHub Security Lab 的协调披露路径；把它用于实时发布帖是本技能从该指南的推断，不是有记录的事件。该路径只有在发布前已公布受监控的安全联系渠道时才存在。
25. 整个窗口保持有人可联系，以应对追问、更正和资产请求。跟踪发布了什么。礼貌且具体地更正事实错误；让不中听但准确的表述留着。然后做第二波：把报道作为证据再次 pitch 给此前拒绝的 outlet，并复用素材——数据变成帖子，帖子变成演讲，采访变成播客 pitch。
26. 按公告类型匹配：每类 devtool 新闻都有有效的钩子和致命的陷阱——融资、GA、含破坏性变更的大版本、基准或数据发布、许可证变更、安全事件、收购、捐赠给基金会、客户成果。动笔前先读 announcement-playbooks 中匹配的那一篇。其中两类不是普通公关工作：安全事件遵循协调披露时间线而非新闻周期，绝不为了更好的档期推迟披露；许可证变更应按预期遭遇敌意报道来规划，因为先例有记录——见 announcement-playbooks 中的许可证变更条目，据此规划。诚实写清经济账，说明现有用户保留什么，为发言人准备应对争论，并提前决定什么会让你反转。
27. 分析师关系从轻处理：分析师为买家提供建议并设定采购团队使用的品类词汇。一个准确的分析师心智模型在企业客户内部可能比一百篇文章活得更久——但对 DevRel 团队来说这是每年几次 briefing，不是一套项目。按服务对象划分机构：面向从业者的分析师研究自下而上的采用并直接触达开发者；买方研究机构通过订阅和比较性评估服务 IT 采购。把机构家族与访谈问题 10 的动因匹配。Briefing 是厂商发起、通常对非客户开放，不返回建议也不承诺报道；inquiry 是客户向分析师提问。安排前查各机构当前公开政策，因为条款不同且会变。这样运行 briefing：1) 发简短 pre-read；2) 带上做决策的工程师；3) 大部分时间讲问题和采用证据而非 demo；4) 问他们在该品类看到什么——最后这部分是用户带回家的价值。明确告诉用户 briefing 买不到什么：任何付费评估中的入选或位置。暗示否则的人是在卖别的东西。
28. 两次公告之间：记者认识发件人时报道来得更快，所以保持小的持续实践：读 beat、无请求地提供价值、记者需要某话题信源且对你无利时快速回应。可靠性把联系人变成关系，且无法在发布前一周临时拼凑。
29. 向用户说明采用动因的差异而非留作隐含：自下而上的开发者采用——重要的读者可能根本接触不到 press。优化开发者能打开的东西（仓库、docs、主要技术文章）和引用面；把报道当作其周围的信誉层，并预期社区论坛在实际采用上胜过行业媒体。企业自上而下购买——读者是买家或其代理。具名客户、部署规模、合规姿态和分析师框架承载故事，每项主张都必须是公司在采购对话中会重复的。两种动因共享其余一切：资格门槛、角度工作、pitch 技艺、embargo 机制和诚实规则完全相同。
30. 衡量：回复率和 pitch 量统计在 PR 内容中广泛流传但归因无出处，不要引用任何一条。把用户与其自身基线比较，而非虚构的行业平均。基线必须在公告前存在：捕获品牌搜索、直接流量、引用域、仓库与 docs 流量、注册量——否则之后每个数字都无法归因。信号价值：销售或采购对话引用该文章（最强、最慢、最难测量）；你原本无法触达的 inbound（合作伙伴、分析师、其他记者）（强）；来自该报道的引用域与权威度（强且持久）；文章出现在 AI 助手关于该品类的回答中（增长中，通过提问抽查）；品牌搜索与直接流量，7-14 天对比基线（方向性；若与其他发布重叠则无用）；窗口内仓库、docs 和 registry 流量（噪音大；绝不单独归因于 press）；文章带来的 referral 点击（下限，绝非总量）；outlet 引用的触达或曝光（受众规模，不是效果）；广告价值等价（拒绝）。拒绝 AVE 是行业共识而非偏好：AMEC 的 Barcelona Principles 于 2010 年由 33 国从业者达成、2015 和 2020 年修订，声明“AVEs are not the value of Public Relations”。有人仍要这个数字时引用它。实践尚年轻时也测量机器：发送的 pitch 数、回复率、预约的 briefing、每次公告的报道量、从新闻到首次发布的时间。从该追踪器读出单公司模式需要足够样本——把约 30 封 pitch 当作本技能的工作下限，不是研究数字。框架级测量设计属于 samber/developer-relations-skills@devrel-metrics。
31. 通过门槛：五项全部满足前不要发送任何东西。该门槛是自设的——没有公开标准覆盖它——所以针对未通过项迭代，而不是绕过它发布：1) 新闻通过五道资格测试中至少四道，或用户已接受不 pitch 的建议；2) pitch 中每项主张都可从公开物（仓库、数据集、docs 页、demo）核查，或是附方法论的数字；3) 发送名单上每位记者都有近几个月在该 beat 的已验证署名和已验证的当前雇主；4) press page 和 briefing pack（含技术证据包）在第一封 pitch 发出前已上线；5) 若使用 embargo，泄露清单已清空且 lift time 含时区。
32. 避免失败模式：把公告误当新闻（“We are pleased to announce”却无变化——回到第 1 步并建议不 pitch）；spray and pray（一封 pitch BCC 给四十个地址——20-40 个已验证真人，每人一封）；无依据的数字（“10x faster”无硬件、版本或测试框架——在证据包中给方法论或删掉主张）；仓库泄露 embargo（tag 或 registry 发布早于 lift——在第 6 步运行泄露检查）；独家双重承诺（两家 outlet 发现都有——一个独家，在媒体地图中跟踪）；要求稿件审批（提出对具名主张做技术事实核查）；开发者论坛中的 PR 腔（参与者用该社区语域发帖）；把分析师 briefing 当购买（事先说明 briefing 买得到和买不到什么）；报道后沉默（第二波 pitch、更正、持续信源工作）；把报道当销售管道（改为报告信誉与可发现性信号）。

适用边界 · 注意事项

• 用户要求购买报道时：付费投放是广告，规则与披露不同，本技能不涉及（PESO 模型中的 Paid 属于广告，Shared 属于社区渠道）。
• 当用户要的是公告帖本身、开源发布渠道排序、客户案例、已预约的播客/采访准备或自己的阅读列表时，应路由到对应技能（engineering-blog-post、oss-launch、developer-case-study、tech-podcast-interview-prep、devrel-radar），不要用本技能重复处理。
• 当问题 5（今天已有哪些证据）答案为空时，先走 announcement-playbooks 中的“When there is no news”，不要直接起草 pitch。