加密项目危机公关：当FUD、漏洞或下架来袭时，首先该说什么

加密项目危机公关涵盖哪些内容

快速测试： 写下您现在确定的3个事实。暂缓声明只使用确定的内容。

危机公关为项目团队提供了一套在可能影响用户信心、合作伙伴关系或公众理解的事件中进行沟通的规范方法。工作涵盖信息及其协调；它不能替代技术事件响应、法律建议或交易所等其他平台的决定。

我们支持团队应对公开指控、疑似或已确认的漏洞、下架通知或项目更新带来的不确定性。首要任务是确定沟通问题：谁在询问、他们需要知道什么、以及团队可以负责任地确认哪些事实。这就在团队现在可以发布的更新与仍需调查的问题之间划出了有用的界限。

危机响应可以包括：

• 一份承认情况并说明下次更新预计时间的暂缓声明。
• 为领导层和社区管理员准备的谈话要点。
• 一份针对利益相关者可能关心问题的简短问答文档。
• 为项目选定渠道准备的草稿，措辞一致且责任明确。

如需更广泛的传播支持，请参阅 公关与媒体。如果当前需求是发布事实性的公开声明，新闻稿发布 可能是一个单独或后续的步骤。

团队首先应该说什么？

第一条公开信息应承认问题，只陈述团队已核实的内容，并告知读者接下来正在核查什么。一份简短准确的暂缓声明通常比在事实稳定前匆忙拼凑的详细解释更有用。

在起草前，收集团队所了解的事件开始时间、受影响的产品或服务、当前用户影响以及被授权确认技术和运营细节的人员。记录哪些要点已核实、哪些正在审查、哪些尚无法回答。避免使用暗示调查尚未得出结论的措辞。

一份实用的暂缓声明通常回答三个问题：发生了什么或被报告了什么、团队现在在做什么、以及读者应在何处查找下次更新。如果用户需要采取特定行动，请明确说明，并确认该指令已由负责的技术或安全负责人审核。除非团队能支持，否则不要用承诺的解决时间来填补沉默。

MarketingExtra 从逐条声明审查开始：我们将每个拟议句子与证据进行比较，并将其标记为已确认、临时或不可发布。然后团队批准措辞并指定一位发言人或渠道负责人。关于社区处理FUD的指导，请阅读 如何在加密社区处理FUD。

您的6点危机检查清单

在第一个小时内检查这6点。它们将已知与猜测区分开来，这正是冷静声明与第二天必须公开撤回的帖子之间的区别。

1. 写下您确定的3个事实。
2. 指定一名批准声明的人。
3. 选择一个渠道作为唯一真相来源。
4. 暂停已安排发布的帖子。
5. 起草一份暂缓声明。
6. 设定下次更新的时间。

术语一句话解释

暂缓声明（用简单的话说：一条简短的第一条信息，说明已知内容以及何时会有更多信息）。

唯一真相来源 指官方更新首先发布的唯一地点。

针对漏洞、FUD或下架，响应方式有何不同

响应应与事件类型相匹配：漏洞需要谨慎的状态更新，公开指控需要以证据为导向的澄清，下架则需要关于通知和后续步骤的精确措辞。一份通用的声明不太可能回答每种情况提出的不同问题。

对于疑似漏洞，请与调查受影响系统的人员协调沟通。确认用户是否应暂停某项操作、使用替代方案或等待更新；仅在负责团队验证后才发布指令。解释关于影响的已知信息，不要推测原因或计划。随着调查进展，保留变更记录。

对于FUD（恐惧、不确定性和怀疑），将流传的指控分类为具体问题。回应那些可以用证据解决的指控，链接到相关的主要信息，并纠正重大错误，不要放大每条帖子。如果某个点仍未核实，请说明正在核查中。

对于下架，请区分平台声明的行动与项目自身的计划。从通知中确认确切受影响的交易对或产品，准备一份简洁的用户说明，并避免暗示审查或恢复是确定的。如果项目还需要处理长期搜索结果或公开信息，请考虑 在线声誉管理 作为相关工作流。

团队应为危机准备什么

经验法则： 一个渠道是唯一真相来源。在那里置顶声明，并在其他地方链接到它。

当团队在开始时共享源材料、决策责任和清晰的审批路径时，响应更容易被核实。在联系我们之前，您不需要一个精心打磨的叙述；一份事实性的工作文件是更好的起点。

收集您可用的材料，包括事件记录、相关公开通知、已批准发布的技术更新以及现有声明的链接。为可能需要确认细节的每个领域（如安全、产品、法律或合作伙伴）添加指定联系人。标记必须保密的敏感信息，并确定谁可以授权其发布。

一份有用的接收检查清单是：

• 事件是什么，团队何时首次意识到？
• 哪些事实已被核实，由谁核实？
• 哪些用户、合作伙伴或公共渠道可能受到影响？
• 读者现在应采取什么行动（如果有）？
• 谁批准声明，谁发布它？

我们使用这些材料起草一份简洁的信息，识别未回答的问题，并将未决问题返回给相应的负责人。客户保留最终批准和发布的控制权。一旦事实稳定，对于计划中的媒体推广，加密媒体赞助文章 可以与即时响应分开评估。

保持危机信息在各渠道间一致

当每个渠道都从一个批准的真相来源获取信息时，响应就能保持连贯，即使每个渠道需要不同的格式。核心事实和后续步骤应保持一致；长度和详细程度可根据受众进行调整。

我们商定谁拥有中央声明、谁可以批准更改、以及谁负责发布每个版本。然后，我们为项目选择使用的渠道（如其网站、社区频道或社交媒体账户）准备渠道就绪的文案。管理员和支持人员可以收到常见问题的简洁答案，这样他们就不必在已批准信息之外即兴发挥。

在活跃事件期间，一份带有日期的更新日志有助于团队查看更改了什么以及何时更改。每条记录可以包含新事实、其来源、批准的措辞以及发布渠道。这使得在证据发生变化时更容易公开纠正先前的声明，而不是留下相互矛盾的版本不加解释。

合作可以从第一条声明推进到后续更新、媒体回应或事后解释。计划根据团队的即时需求商定。如果后续公告需要新闻室推广，加密媒体投放 可以在信息、证据和时间安排获得批准后进行讨论。

危机公关能控制什么，不能控制什么

危机公关可以提高项目自身沟通的准确性、清晰度和协调性；它不能决定交易所、媒体或社区如何回应。特别是，平台控制其下架审查和任何恢复决定，而技术发现和公众反应可能随着新证据的出现而变化。

就项目自身而言，保持一份已批准的声明易于查找，为每次更新注明日期，并在用于原始信息的相同渠道中更正重大变化。避免在读者可能仍依赖旧信息时，不加解释地删除先前的说明。如果公开声明存在争议，请展示支持项目立场的证据，而不是依赖语气或重复。

在审查危机沟通提案时，确认谁起草、谁批准、计划使用哪些渠道以及如何记录更新。询问团队将如何处理改变先前信息的新事实，以及紧急审批如何到达有权决定的人手中。这些答案将揭示工作安排是否适合该事件。

发送3件事：用5行说明发生了什么、您使用的渠道以及谁可以批准声明。有了这些，我们开始起草暂缓声明，并在任何内容发布前以书面形式确认费用。

如何操作

1. 分享事件背景发送一份简洁的摘要、相关的公开材料以及可以确认事实的联系人。标记任何必须保密的内部信息。
2. 审查声明与证据我们将已确认的细节与未解决的问题分开，并识别需要技术或领导层批准的声明。
3. 起草第一条响应我们准备暂缓声明，并在商定后，准备支持性的谈话要点或特定渠道的文案。
4. 批准与协调您指定的决策者批准措辞。我们协调已批准的版本，并明确谁发布每个版本。
5. 记录与更新我们保留一份带有日期的已批准沟通记录，并帮助在核实信息发生变化时准备后续措辞。