加密项目白皮书撰写：将项目事实转化为可读文档

开篇应让读者验证什么？

一句宗旨陈述能让读者对整个文档进行检验。它应指明项目、目标读者以及文档所支持的决策或理解。确保该宗旨针对产品本身，而非对市场的宽泛承诺。

在起草前，确定主要读者。开发者可能需要了解组件行为和集成假设。潜在用户可能需要了解产品流程及其当前限制。代币持有者可能需要了解已记录的代币功能和治理规则。文档可以服务于多个群体，但应指明首要受众并据此安排细节顺序。

制作一份包含以下4个提示的简短记录：

• 项目解决了什么问题，为谁解决？
• 用户或开发者目前能做什么？
• 哪些功能仍处于提议或开发阶段？
• 阅读后，读者应能评估什么？

将每个答案标记为已上线、已测试、已规划或未解决。这种状态词汇有助于防止路线图项目被误读为可用功能。如果项目处于早期阶段，请说明哪些尚不明确。然后使用宗旨陈述删除那些无助于目标读者理解或评估项目的段落。

白皮书的文档地图应包含哪些部分？

一个7部分的提纲可以将读者从项目问题引导至其未解决的问题。将其视为一份工作地图，而非必需模板。仅当某个部分能解释本项目的重要事项时才添加。

一个有用的顺序是：

• 摘要： 问题、方法和当前开发状态。
• 问题与背景： 谁面临该问题，现有方法留下了哪些未解决的问题。
• 产品或协议： 组件、用户流程和系统边界。
• 技术设计： 相关架构、依赖关系和安全性假设。
• 代币设计（如适用）： 功能、供应规则、分配和治理机制。
• 路线图与职责： 计划工作、决策负责人和依赖关系。
• 风险与未解决问题： 已知限制和未解决的设计选择。

不要为没有代币的项目添加代币经济学。对于有代币的项目，不要将核心机制埋藏在附录中。将简短说明放在专业细节之前。使用附录来放置支持某个主张但会打断主要解释的材料。

有关超出文档范围的发行规划，请参阅代币发行检查清单。确保其项目事实与白皮书保持一致。有关上线准备的单独概述，请查阅CoinMarketCap上线指南和CoinGecko上线指南。这些资源针对不同任务，不应被用作项目满足平台要求的证据。

读者如何将主张追溯到其来源？

一份主张清单能显示哪些陈述在润色前需要验证。为每个关于产品行为、代币机制、安全性假设或项目状态的重要陈述创建一条记录。该清单能在草稿仍易于修改时让漏洞显现出来。

每条记录使用4个字段：确切主张、来源或陈述的假设、状态和审阅人。我们的默认审阅使用3个检查点：来源匹配、状态匹配和负责人签核。产品手册可以支持用户流程的描述。设计记录可以解释架构决策。预测应被标识为估计，而非作为观察到的结果呈现。如果没有支持材料，请限定该陈述或将其删除。

代币段落需要精确定义。解释每个供应术语的含义以及分配或释放规则如何运作。指明哪些规则已记录在案，哪些可能通过治理或其他既定流程发生变化。除非项目条款支持，否则不要暗示持有代币即授予权利。

该清单还能帮助未来的编辑找到受产品变更影响的文本。将其条目与项目当前材料以及代币发行检查清单进行比较。在GeoMarketing Experts，审阅人可以返回一份标记过的草稿，其中问题按负责人分组。有关撰写合作，请参阅白皮书和精简版白皮书撰写；有关付费工作范围，请参阅加密项目白皮书价格。

主要文档中应包含多少技术细节？

系统图表及其说明应与正文讲述相同的故事。使用技术细节来展示组件如何交互以及它们的行为依赖哪些假设。仅列出链、合约或加密术语是不够的，除非同时说明这些关系。

从通俗易懂的系统概述开始。然后解释每个重要组件的角色、输入、输出和依赖关系。对于多参与者流程，指明谁发起操作、系统检查什么，以及当依赖项不可用时会发生什么。在首次使用时定义专业术语。在整个文档中保持一个术语对应一个含义。

使用图表展示流程、信任边界或数据移动。添加说明，指明图表包含和省略的内容。图表不应暗示链下流程由智能合约强制执行。当读者需要超出文档目的的实现细节时，链接到更深入的技术文档。

对每个重要图表进行2项检查：确认其标签与文本匹配，然后请技术审阅人验证所描绘的行为。为每个图表记录4个字段：目的、组件、边界和审阅人。仅当项目证据支持时，才将组件标记为已测试、已审计或已提议。这些描述不可互换。如果设计正在变化，请指明哪些细节是暂定的，而不是将其作为既定事实来写。

哪些编辑检查能发现加密项目白皮书中的漏洞？

代币描述与路线图之间的矛盾是内容缺陷，而非风格问题。在花时间润色句子之前，先审阅状态、定义和证据。这些检查使草稿更易于评估：

• 没有机制的承诺： 描述系统及其依赖关系，而不是断言结果。
• 将计划写成已交付： 标记未来工作，并将其与可用功能区分开来。
• 模糊的代币功能： 解释代币在系统中的用途。
• 未定义的数字或术语： 说明每个值或标签所指的内容。
• 没有上下文的专业词汇： 定义术语并解释其重要性。
• 冲突的名称或规则： 比较各章节中的供应描述、治理角色和状态标签。
• 通用段落： 删除不描述本项目设计或职责的语言。

对于每个章节，询问细心的读者能从其内容中验证什么。当答案不明确时，添加来源、限定假设或修改陈述。然后单独进行编辑通读，检查顺序和可读性。将事实核查与文案编辑分开，可以降低流畅的措辞掩盖未解决主张的风险。

审阅人应如何在发布前记录变更？

变更日志为团队提供了变更内容和原因的记录。按主题分配审阅：工程师检查系统描述，代币负责人检查机制，编辑审阅人检查结构和一致性。法律顾问应审阅需要法律评估的语言。

使用以下顺序：

• 冻结提纲并收集当前源材料。
• 起草解释并将材料主张映射到证据。
• 将每个主张分派给负责检查的人。
• 解决评论并记录实质性变更的原因。
• 对照最终文本检查链接、图表、术语和版本标签。

一份按负责人分组问题的标记文档为下一次修订提供了清晰的路径。它帮助创始人解决范围和状态问题，同时让技术审阅人专注于系统描述。在发布前保留变更日志，以便审阅人能看到哪些主张发生了变化及其原因。

对于白皮书之外的项目沟通，请将文档与加密营销指南和项目当前的技术材料进行比较。不要将两者中的任何一个用作检查源事实的替代品。在GeoMarketing Experts，草稿审阅将材料主张映射到其证据，并按负责人返回问题。请将当前提纲、产品文档、相关代币材料以及任何需要审阅的主张发送至白皮书撰写支持进行讨论。

已发布的白皮书留下了哪些未证明的内容？

版本标签和指定的负责人有助于读者识别他们正在阅读的文档。保持从文档到当前项目文档的路径。当重要功能、代币规则、治理流程或项目状态发生变化时，审阅该文档。如果它不再反映项目，请更新它或将其标记为过时。

正式文档无法证明实现行为如描述所述，也无法认证安全性。代币和治理条款仍受项目既定规则的约束。在文档中陈述假设和未解决的依赖关系，然后针对这些材料无法解决的问题，寻求合格的技术和法律审阅。

在发布前，检查最终文本是否与产品和治理文档一致。确认图表、术语、版本标签和链接与审阅过的草稿匹配。指定一名团队成员负责未来更新，而不是假设文档会自动保持最新。

要开始起草，请收集提纲、当前产品文档、相关代币材料以及需要审阅的主张列表。将这些项目发送至GeoMarketing Experts。下一步是进行主张到来源的检查，然后为负责解决每个问题的人员生成一份漏洞清单。

如何操作

1. 确定读者和宗旨指明主要受众以及文档应帮助他们评估的内容。将该任务与营销、法律条款和详细技术文档区分开来。
2. 收集并标记当前事实收集产品、架构、代币和路线图材料。将每个项目标记为已上线、已测试、已规划或未解决。
3. 映射章节和主张围绕读者需求安排提纲。为每个重要主张记录来源和审阅人。
4. 起草解释在添加实现细节之前，用通俗语言解释系统。为图表添加说明并指明其限制。
5. 审阅并维护文档将主张分派给正确的审阅人，解决矛盾，并指定一名负责人负责未来更新。