Cách viết whitepaper crypto mà người đọc hoài nghi có thể theo dõi

Người đọc nên có thể quyết định điều gì?

Kiểm tra nhanh: Đưa bản thảo của bạn cho người ngoài nhóm và yêu cầu họ gạch dưới mọi tuyên bố mà họ không thể kiểm tra. Bạn sẽ thấy ngay phần nào cần bằng chứng.

Sách trắng crypto nên giúp người đọc hiểu dự án đề xuất gì, cách nó dự kiến hoạt động và điều gì còn chưa chắc chắn. Trước khi viết, hãy quyết định ai cần tài liệu và họ nên có thể đánh giá điều gì sau khi đọc. Một nhà phát triển có thể cần chi tiết kiến trúc; một người nắm giữ token tiềm năng có thể cần thông tin rõ ràng về tiện ích và phân phối; một đối tác có thể cần hiểu mô hình vận hành của dự án.

Viết một brief ngắn cho nhóm trước khi soạn thảo. Bao gồm:

• Người đọc chính và các câu hỏi họ có thể mang đến.
• Vấn đề dự án giải quyết, được diễn đạt mà không có tuyên bố quảng cáo.
• Những gì tài liệu đề cập và những gì thuộc về một tài liệu kỹ thuật, lộ trình hoặc tài liệu pháp lý riêng.
• Hành động người đọc có thể thực hiện tiếp theo, chẳng hạn như xem xét tài liệu hoặc liên hệ với nhóm.

Một brief như vậy là một kiểm tra kế hoạch hữu ích: nếu một phần được đề xuất không trả lời câu hỏi của người đọc hoặc chứng minh tuyên bố của dự án, hãy loại bỏ nó hoặc giải thích tại sao nó thuộc về. Sách trắng không nên cố gắng phục vụ mọi đối tượng như nhau. Khi dự án cần một tổng quan ngắn gọn cho các cuộc trò chuyện ban đầu, litepaper có thể là một lựa chọn tốt hơn; hai tài liệu có thể có vai trò riêng biệt thay vì lặp lại nhau.

Một cấu trúc dễ theo dõi

Một cấu trúc mạnh mẽ đi từ vấn đề của người đọc đến giải pháp được đề xuất của dự án, sau đó cung cấp đủ chi tiết để đánh giá thiết kế và hạn chế của nó. Không có dàn ý bắt buộc cho mọi dự án, nhưng một trình tự có thể dự đoán giúp người đọc tìm thấy thông tin họ cần.

Cân nhắc sắp xếp tài liệu theo thứ tự này:

• Tóm tắt: nêu vấn đề, cách tiếp cận được đề xuất và người dùng dự kiến.
• Bối cảnh và nhu cầu: giải thích khó khăn hiện tại và tại sao nó quan trọng.
• Giải pháp và sản phẩm: mô tả trải nghiệm người dùng và các thành phần chính của hệ thống.
• Thiết kế kỹ thuật: giải thích kiến trúc liên quan, các phụ thuộc và cách các thành phần tương tác.
• Thiết kế token: nêu rõ liệu token có tồn tại không, vai trò của nó là gì và cách cung ứng và phân bổ được mô tả.
• Lộ trình và quản trị: phân biệt khả năng hiện tại với công việc đã lên kế hoạch và giải thích ai đưa ra quyết định.
• Rủi ro và giả định: nêu tên các phụ thuộc quan trọng, câu hỏi mở và các ràng buộc có thể có.

Điều chỉnh dàn ý cho dự án, không phải ngược lại. Một tài liệu về giao thức cần giải thích kỹ thuật nhiều hơn tổng quan về ứng dụng tiêu dùng. Chỉ thêm sơ đồ khi chúng làm rõ mối quan hệ hoặc quy trình, và đảm bảo văn bản giải thích chúng cho những người đọc không thể hiểu hình ảnh ngay lập tức. Để có danh sách kiểm tra tập trung vào thông tin token, hãy xem cách xác minh nguồn cung trên CoinGecko; giữ các tuyên bố về nguồn cung trong sách trắng nhất quán với hồ sơ dự án.

Làm cho các tuyên bố kỹ thuật và token có thể kiểm tra được

Làm cho mỗi tuyên bố quan trọng đủ cụ thể để người đọc có thể biết điều gì hỗ trợ nó. Các tuyên bố chung chung như "phi tập trung hoàn toàn" hoặc "an toàn theo thiết kế" không giải thích thuộc tính hệ thống nào được đề cập, bằng chứng nào hỗ trợ chúng hoặc những đánh đổi nào còn lại.

Đối với mỗi tuyên bố quan trọng, hãy ghi lại nguồn và người chịu trách nhiệm xác nhận nó. Nguồn đó có thể là một tính năng đã triển khai, tài liệu kỹ thuật, audit đã công bố, phân bổ token được nhóm phê duyệt hoặc một giả định được dán nhãn rõ ràng. Đừng trình bày một kế hoạch như một khả năng hiện có. Nếu một chi tiết chưa được quyết định, hãy nói rõ và xác định ai sở hữu quyết định đó.

Đặc biệt chú ý đến các lĩnh vực này:

• Kiến trúc: đặt tên các thành phần và mô tả cách thông tin hoặc tài sản di chuyển giữa chúng.
• Bảo mật: nêu rõ những gì đã được đánh giá và những gì chưa; tránh ngụ ý rằng đánh giá loại bỏ mọi rủi ro.
• Vai trò token: giải thích chức năng trong sản phẩm thay vì dựa vào các mô tả trừu tượng.
• Cung ứng và phân bổ: hiển thị các danh mục, thời gian và bất kỳ điều kiện nào nhóm thực sự đã phê duyệt.
• Quản trị: xác định quyền ra quyết định và mô tả cách các thay đổi được đề xuất được xử lý.

Giữ một bảng bằng chứng trong bản thảo làm việc với tuyên bố, nguồn, chủ sở hữu và trạng thái đánh giá. Bảng này là một công cụ biên tập, không phải bằng chứng tự thân. Đối với phiên bản công khai, dịch thuật ngữ kỹ thuật nếu có thể và định nghĩa các thuật ngữ cần thiết khi sử dụng lần đầu. Người đọc nên có thể truy tìm một tuyên bố mà không cần phải đoán ý của nhóm.

Soạn thảo và đánh giá tài liệu

Soạn thảo tài liệu theo từng lượt, với chủ sở hữu chủ đề kiểm tra các tuyên bố trước khi văn bản được trau chuốt. Điều này giảm các bản viết lại không cần thiết: một người viết có thể cải thiện sự rõ ràng, nhưng không thể giải quyết quyết định về token hoặc xác minh kiến trúc mà nhóm chưa thống nhất.

Một trình tự thực tế là:

1. Thu thập tài liệu nguồn. Tập hợp tài liệu sản phẩm, ghi chú kiến trúc, thông tin token đã được phê duyệt, chi tiết lộ trình và các tuyên bố công khai hiện có.
2. Đặt dàn ý. Ánh xạ mỗi câu hỏi của người đọc vào một phần và đánh dấu bất kỳ chủ đề nào thiếu chủ sở hữu hoặc câu trả lời đã được xác nhận.
3. Soạn thảo cho ý nghĩa. Viết các giải thích trực tiếp trước. Giữ thuật ngữ dự án nhất quán và định nghĩa các thuật ngữ khi chúng xuất hiện.
4. Thực hiện đánh giá chủ đề. Yêu cầu chủ sở hữu kỹ thuật, sản phẩm và thiết kế token xác minh các phần của họ dựa trên các quyết định và nguồn hiện tại.
5. Chỉnh sửa và phê duyệt. Kiểm tra cấu trúc, tính nhất quán, sơ đồ, chi tiết phiên bản và bất kỳ đánh giá pháp lý hoặc tuân thủ nào mà dự án yêu cầu.

Đưa ra các yêu cầu tập trung cho người đánh giá thay vì yêu cầu "xem qua" chung chung. Ví dụ, yêu cầu trưởng bộ phận kỹ thuật xác minh mô tả thành phần và yêu cầu chủ sở hữu thiết kế token kiểm tra ngôn ngữ phân bổ so với mô hình đã được phê duyệt. Giữ một bản sao chính và ghi lại những thay đổi nào được chấp nhận, hoãn lại hoặc chưa được giải quyết. Nếu bạn cần hỗ trợ viết bên ngoài, dịch vụ viết sách trắng và litepaper có thể giúp biến tài liệu dự án thành tài liệu sẵn sàng cho người đọc; chuẩn bị gói nguồn và chủ sở hữu quyết định trước khi bắt đầu.

Danh sách kiểm tra 7 điểm cho sách trắng của bạn

Kiểm tra mỗi bản thảo dựa trên 7 điểm này trước khi bất kỳ ai bên ngoài nhóm của bạn nhìn thấy nó. Nếu tài liệu của bạn vượt qua cả 7 điểm, bạn sẽ dễ dàng bảo vệ nó trong phần Hỏi & Đáp và dễ dàng cắt giảm thành các định dạng khác.

• Nêu người đọc và mục đích trên trang 1.
• Định nghĩa vấn đề trong 3 câu hoặc ít hơn.
• Mô tả sản phẩm và công nghệ bằng từ ngữ đơn giản.
• Giải thích chức năng, nguồn cung và phân phối của token.
• Thêm phần rủi ro một cách trung thực.
• Liên kết mọi con số với một nguồn hoặc một hợp đồng.
• Có 2 người đánh giá ký xác nhận: một kỹ thuật, một pháp lý.

Thuật ngữ trong một dòng

Sách trắng (theo nghĩa đơn giản: một tài liệu dài giải thích công nghệ, token và kế hoạch của dự án).

Litepaper có nghĩa là một bản tóm tắt ngắn của sách trắng dành cho những người đọc muốn nắm ý chính.

Những sai lầm khiến bạn mất lòng tin

Sai lầm phổ biến: Pha trộn ngôn ngữ tiếp thị vào các phần kỹ thuật. Hãy giữ các tuyên bố và nội dung bán hàng riêng biệt, và để người đọc tự quyết định.

Những sai lầm sách trắng gây hại nhất thường là sự thiếu nhất quán, sự chắc chắn không có cơ sở và chi tiết che khuất thay vì giải thích dự án. Một bố cục đẹp không thể sửa chữa các tuyên bố mâu thuẫn với sản phẩm hoặc với nhau.

Hãy chú ý đến những vấn đề này trong quá trình đánh giá:

• Sao chép một dàn ý chung chung: các phần về tính năng mà dự án không có làm cho tài liệu khó tin cậy hơn. Hãy loại bỏ chúng hoặc giải thích sự liên quan của chúng.
• Trộn lẫn thì hiện tại và tương lai: phân biệt rõ ràng những gì có sẵn, đang được xây dựng và chỉ mới được đề xuất.
• Sử dụng thuật ngữ token mà không định nghĩa chúng: giải thích cách token liên quan đến việc sử dụng sản phẩm, quản trị hoặc một chức năng đã nêu khác.
• Để ngôn ngữ phân bổ mơ hồ: người đọc cần các danh mục nhất quán và giải thích về các điều kiện liên quan, không phải là thuật ngữ quảng cáo viết tắt.
• Đưa ra các tuyên bố tuyệt đối về bảo mật hoặc hiệu suất: mô tả thiết kế và bằng chứng thay vì khẳng định kết quả mà tài liệu không thể thiết lập.
• Lặp lại lời chào hàng: sách trắng nên trả lời các câu hỏi thực chất, không lặp lại các khẩu hiệu trong mọi phần.
• Để sơ đồ mâu thuẫn với văn bản: chỉ định một chủ sở hữu để kiểm tra nhãn, luồng và phiên bản so với giải thích bằng văn bản.

Một lượt kiểm tra tính nhất quán cuối cùng nên so sánh sách trắng với trang web, tài liệu, tài liệu token và trạng thái sản phẩm hiện tại. Nếu một chi tiết khác nhau, hãy giải quyết nguồn nào là hiện tại và cập nhật các nguồn khác. Đối với một chuỗi ra mắt dự án rộng hơn, hãy sử dụng danh sách kiểm tra tiếp thị launch token cùng với việc đánh giá tài liệu.

Sách trắng có thể chứng minh điều gì và điều gì cần đánh giá thêm

Sách trắng có thể giải thích thiết kế của dự án và tiết lộ cơ sở cho các tuyên bố của nó; nó không thể làm cho một thiết kế chưa được quyết định trở nên hoàn chỉnh hoặc thay thế đánh giá chuyên gia. Hãy coi nó như một tài liệu dự án được duy trì, không phải là sự thay thế cho xác nhận kỹ thuật, tư vấn pháp lý hoặc hồ sơ sản phẩm chính xác.

Giới hạn và rủi ro: Các mô tả kỹ thuật có thể trở nên lỗi thời khi triển khai thay đổi, trong khi các câu hỏi về token và tuân thủ yêu cầu xác nhận từ chủ sở hữu dự án có trách nhiệm và các cố vấn có thẩm quyền. Một tài liệu rõ ràng giúp người đọc kiểm tra thông tin đã nêu, nhưng nó không thể chứng nhận rằng một hệ thống sẽ hoạt động như mô tả hoặc giải quyết cách một bên bên ngoài sẽ giải thích nó.

Trước khi xuất bản, chỉ định một chủ sở hữu để duy trì tài liệu và đặt một tác nhân kích hoạt đánh giá. Các tác nhân kích hoạt hữu ích bao gồm một thay đổi quan trọng đối với sản phẩm, kiến trúc, thiết kế token, quản trị hoặc lộ trình. Ghi lại ngày phiên bản và tóm tắt những gì đã thay đổi để người đọc có thể phân biệt thông tin hiện tại với các bản thảo trước đó. Giữ các tệp nguồn cho sơ đồ và bảo quản bằng chứng được sử dụng để phê duyệt các tuyên bố.

Nếu sách trắng hỗ trợ một ứng dụng lên sàn giao dịch hoặc nền tảng dữ liệu, hãy giữ các chi tiết thực tế của nó phù hợp với tài liệu đã nộp của dự án; bản thân tài liệu không quyết định kết quả đánh giá của nền tảng. Xem các hướng dẫn riêng về listing CoinMarketCap và listing CoinGecko cho các quy trình ứng dụng đó. Một tài liệu nguồn ngắn gọn, nhất quán giúp nhóm dễ dàng giải thích dự án hơn, nhưng mỗi nền tảng tự xử lý các quyết định của riêng mình.

Khi nào litepaper là lựa chọn tốt hơn?

Litepaper phù hợp hơn khi mục tiêu trước mắt là cung cấp cho người đọc một giới thiệu ngắn gọn, trong khi sách trắng đầy đủ hữu ích khi người đọc cần giải thích sâu hơn về thiết kế và các giả định của nó. Bản thân tên gọi không xác định kế hoạch: hãy quyết định dựa trên những gì người đọc cần đánh giá và lượng tài liệu có cơ sở mà nhóm đã sẵn sàng.

Litepaper có thể giới thiệu vấn đề, sản phẩm, vai trò token và các bước tiếp theo mà không cố gắng ghi lại mọi lựa chọn kỹ thuật. Một sách trắng đầy đủ hơn có thể mở rộng về kiến trúc, quản trị, nguồn cung, phụ thuộc và rủi ro. Định dạng ngắn hơn không nên che giấu các lưu ý quan trọng hoặc ngụ ý rằng các kế hoạch chưa được giải quyết đã được ấn định. Nếu cả hai tài liệu tồn tại, hãy quyết định tài liệu nào là nguồn sự thật cho từng chi tiết và cập nhật chúng cùng nhau khi các quyết định thay đổi.

Sử dụng kiểm tra quyết định này trước khi chọn định dạng:

• Người đọc dự kiến có cần chi tiết triển khai để hiểu đề xuất không?
• Các tuyên bố trung tâm của dự án có được hỗ trợ bởi tài liệu nguồn và đánh giá của chủ sở hữu không?
• Nhóm có sẵn sàng duy trì mức độ chi tiết mà họ dự định xuất bản không?
• Một tổng quan ngắn gọn có hữu ích hơn ngay bây giờ, với một tài liệu sâu hơn sau đó không?

Nếu bạn đang chuẩn bị một bản thảo, hãy gửi cho MarketingExtra phiên bản hiện tại, tài liệu dự án, thông tin token đã được phê duyệt và tên của những người có thể xác minh các tuyên bố kỹ thuật và sản phẩm. Chúng tôi có thể đánh giá tài liệu để tìm ra các lỗ hổng và giúp định hình một kế hoạch sách trắng hoặc litepaper rõ ràng; bắt đầu với tổng quan về viết sách trắng.

Cách hoạt động

1. Xác định người đọc và mục đíchViết ra tài liệu phục vụ ai và họ cần hiểu điều gì. Sử dụng điều này để quyết định những gì thuộc về sách trắng.
2. Thu thập các nguồn dự án hiện tạiThu thập tài liệu kỹ thuật, sản phẩm, token, lộ trình và quản trị. Đánh dấu các quyết định còn thiếu và chỉ định chủ sở hữu cho mỗi quyết định.
3. Ánh xạ tuyên bố với bằng chứngGhi lại nguồn và người xác minh cho các tuyên bố quan trọng. Phân biệt các khả năng đã triển khai với kế hoạch và giả định.
4. Soạn thảo, sau đó thực hiện đánh giá tập trungViết theo thứ tự thân thiện với người đọc và yêu cầu chủ sở hữu chủ đề liên quan kiểm tra các phần họ kiểm soát.
5. Phê duyệt và duy trì tài liệuKiểm tra tính nhất quán, chi tiết phiên bản, sơ đồ và các đánh giá chuyên gia cần thiết trước khi xuất bản. Chỉ định chủ sở hữu cho các bản cập nhật trong tương lai.