撰写一份让持怀疑态度的读者也能理解的加密货币白皮书

读者应该能够做出什么决定？

快速测试： 将您的草稿交给团队以外的人，请他们划出每一个无法核实的说法。您会立刻知道哪些部分需要证据。

一份加密货币白皮书应帮助读者理解项目提议的内容、预期运作方式以及仍存在哪些不确定性。在动笔之前，先确定谁需要这份文档，以及他们阅读后应能评估什么。开发者可能需要架构细节；潜在代币持有者可能需要清晰的效用和分配信息；合作伙伴可能需要了解项目的运营模式。

在起草前为团队撰写一份简短简报。内容包括：

• 主要读者及其可能提出的问题。
• 项目解决的问题，以非宣传性语言表述。
• 文档涵盖的内容，以及哪些内容属于单独的技术论文、路线图或法律文件。
• 读者下一步可以采取的行动，例如查阅文档或联系团队。

这样的简报是一个有用的计划检查：如果某个拟议章节不能回答读者问题或证实项目主张，就删除它或解释其存在的理由。白皮书不应试图平等地服务于所有受众。当项目需要为早期对话提供简洁概述时，精简白皮书可能是更好的补充；两份文档可以扮演不同的角色，而不是相互重复。

易于遵循的结构

一个强有力的结构从读者的问题出发，过渡到项目提出的解决方案，然后提供足够的细节来评估其设计和局限性。没有适用于每个项目的强制性大纲，但可预测的顺序有助于读者找到所需信息。

考虑按以下顺序组织文档：

• 摘要： 说明问题、拟议方法和目标用户。
• 背景与需求： 解释当前的困难及其重要性。
• 解决方案与产品： 描述用户体验和系统的主要组件。
• 技术设计： 解释相关架构、依赖关系以及组件如何交互。
• 代币设计： 说明是否存在代币、其作用以及供应和分配如何描述。
• 路线图与治理： 区分当前能力与计划工作，并说明谁做决策。
• 风险与假设： 列出重要的依赖关系、未解决的问题和可能的限制。

根据项目调整大纲，而不是反过来。协议论文需要比消费者应用概述更多的技术解释。仅在图表能阐明关系或流程时添加，并确保文字说明能帮助无法一眼看懂视觉信息的读者理解。如需专注于代币信息的清单，请参阅如何在 CoinGecko 上验证供应量；保持白皮书中供应陈述与项目记录一致。

使技术和代币主张可核查

使每个重要主张足够具体，以便读者能判断其支撑依据。诸如“完全去中心化”或“安全设计”之类的宽泛陈述，并未说明指的是哪些系统属性、有何证据支持或存在哪些权衡。

对于每个实质性主张，记录来源和负责确认的人员。该来源可以是已实现的功能、技术文档、已发布的审计报告、经团队批准的代币分配，或明确标注的假设。不要将计划描述为现有能力。如果某个细节尚未决定，请说明并指出谁拥有决策权。

特别关注以下领域：

• 架构： 命名组件并描述信息或资产如何在它们之间移动。
• 安全性： 说明哪些已审查、哪些未审查；避免暗示审查消除了所有风险。
• 代币角色： 解释其在产品中的功能，而不是依赖抽象描述。
• 供应与分配： 显示类别、时间安排以及团队实际批准的任何条件。
• 治理： 明确决策权，并描述如何处理拟议变更。

在工作草稿中保留一个证据表，包含主张、来源、负责人和审阅状态。该表是编辑辅助工具，本身并非证据。对于面向公众的版本，尽可能翻译技术术语，并在首次使用时定义必要术语。读者应能追溯主张，而无需猜测团队意图。

起草与审阅白皮书

分轮次起草文档，在文字润色前由主题负责人检查主张。这可以减少不必要的重写：写作者可以改进清晰度，但无法解决团队尚未确定的代币决策或验证架构。

一个实用的顺序是：

1. 收集源材料。 收集产品文档、架构笔记、已批准的代币信息、路线图细节和现有公开声明。
2. 设定大纲。 将每个读者问题映射到一个章节，并标记任何缺乏负责人或已确认答案的主题。
3. 为意义而草稿。 首先直接解释。保持项目术语一致，并在术语出现时定义。
4. 进行主题审阅。 请技术、产品和代币设计负责人根据当前决策和来源验证其章节。
5. 编辑与批准。 检查结构、一致性、图表、版本细节以及项目所需的任何法律或合规审查。

向审阅者提出具体要求，而不是笼统地要求“看一下”。例如，请工程负责人验证组件描述，请代币设计负责人检查分配语言是否与批准的模型一致。保留一份主副本，并记录哪些更改已接受、推迟或未解决。如果您需要外部写作支持，白皮书和精简白皮书撰写可以帮助将项目材料转化为读者就绪的文档；请在启动前准备好源包和决策负责人。

您的7点白皮书清单

在团队以外任何人看到之前，根据以下7点检查每份草稿。如果您的白皮书通过了全部7点，您会发现它在问答中更容易辩护，也更容易缩减为其他格式。

• 在第1页说明读者和目的。
• 用3句话或更少定义问题。
• 用通俗语言描述产品和技术。
• 解释代币的功能、供应和分配。
• 添加一个诚实的风险部分。
• 将每个数字链接到来源或合约。
• 让2位审阅者签字：一位技术，一位法律。

术语一览

白皮书（通俗地说：一份解释项目技术、代币和计划的冗长文档）。

精简白皮书 指白皮书的简短摘要，供想要了解要点的读者阅读。

让您失去信任的错误

常见错误： 将营销语言混入技术部分。将主张和销售文案分开，让读者自行判断。

最具破坏性的白皮书错误通常是不一致、未经证实的确定性，以及掩盖而非解释项目的细节。精美的排版无法修复与产品或彼此矛盾的主张。

在审阅时注意以下问题：

• 复制通用大纲： 关于项目不具备的功能的章节会使文档更难获得信任。删除它们或解释其相关性。
• 混合现在时和将来时： 清晰区分哪些是已有的、正在构建的和仅提议的。
• 使用代币术语而不定义： 解释代币如何与产品使用、治理或其他既定功能相关。
• 分配语言含糊： 读者需要一致的类别和相关条件的解释，而不是宣传性的简写。
• 做出绝对的安全或性能声明： 描述设计和证据，而不是声称文档无法证明的结果。
• 重复推销： 白皮书应回答实质性问题，而不是在每个部分重复口号。
• 让图表与文字矛盾： 指定负责人检查标签、流程和版本是否与文字说明一致。

最终的一致性检查应将白皮书与网站、文档、代币材料和当前产品状态进行比较。如果存在差异，请确定哪个来源是当前的，并更新其他来源。对于更广泛的项目启动流程，请将代币发行营销清单与文档审阅一起使用。

白皮书能证明什么，以及需要更多审阅的内容

白皮书可以解释项目的设计并披露其主张的依据；它不能使未决定的设计完整或取代专业审阅。将其视为一份维护中的项目文档，而不是技术验证、法律建议或准确产品记录的替代品。

局限与风险： 技术描述可能随着实现变更而过时，而代币和合规问题需要项目负责人和合格顾问的确认。清晰的文档有助于读者检查所述信息，但它不能证明系统将按描述运行，也不能解决外部方将如何解释它。

在发布前，指定一名负责人维护文档并设定审阅触发条件。有用的触发条件包括产品、架构、代币设计、治理或路线图的重大变更。记录版本日期并总结变更内容，以便读者区分当前信息和早期草稿。保留图表的源文件，并保存用于批准主张的证据。

如果白皮书支持交易所或数据平台的申请，请保持其事实细节与项目提交的材料一致；文档本身并不决定平台的审阅结果。请参阅关于 CoinMarketCap 上线和 CoinGecko 上线的单独指南，了解这些申请流程。一份简洁、一致的源文档使团队更容易解释项目，但每个平台自行处理其决策。

什么时候精简白皮书是更好的选择？

当当前目标是给读者一个紧凑的介绍时，精简白皮书是更好的选择；而当读者需要更深入地了解设计及其假设时，完整的白皮书更有用。名称本身并不定义计划：根据读者需要评估的内容以及团队准备好的实质性材料来决定。

精简白皮书可以介绍问题、产品、代币角色和后续步骤，而无需尝试记录每个技术选择。更完整的白皮书可以扩展架构、治理、供应、依赖关系和风险。较短的格式不应隐藏重要的注意事项或暗示未解决的计划已经确定。如果两份文档都存在，请决定每项细节的真相来源，并在决策变更时一起更新。

在选择格式前使用此决策检查：

• 目标读者是否需要实现细节来理解提议？
• 项目的核心主张是否有源材料和负责人审阅支持？
• 团队是否准备好维护其计划发布的详细程度？
• 现在一份简短的概述是否更有用，后续再提供更深入的文档？

如果您正在准备草稿，请将当前版本、项目文档、已批准的代币信息以及能够验证技术和产品主张的人员姓名发送给 MarketingExtra。我们可以审阅材料中的空白，并帮助制定清晰的白皮书或精简白皮书计划；从白皮书撰写概述开始。

如何操作

1. 设定读者和目的写下文档服务于谁以及他们需要理解什么。据此决定白皮书中应包含哪些内容。
2. 收集当前项目来源收集技术、产品、代币、路线图和治理材料。标记缺失的决策并为每个决策指定负责人。
3. 将主张映射到证据记录重要陈述的来源和验证者。将已实现的能力与计划和假设区分开。
4. 起草，然后进行有针对性的审阅以读者友好的顺序写作，并请相关主题负责人检查他们控制的章节。
5. 批准并维护文档在发布前检查一致性、版本细节、图表和所需的专业审阅。指定负责人进行未来更新。