Cách viết whitepaper crypto dựa trên thông tin sản phẩm

Định dạng sách trắng nào phù hợp với độc giả của bạn?

Sách trắng: luận điểm dự án, sản phẩm và thiết kế. Litepaper: giải thích dự án ngắn gọn. Tài liệu kỹ thuật: cơ chế và giả định hệ thống.

Bắt đầu với quyết định mà độc giả của bạn cần đưa ra. Nếu họ cần mục đích và mô hình vận hành của dự án, hãy dùng sách trắng. Nếu họ cần ý tưởng chính nhanh chóng, litepaper có thể phù hợp hơn. Nếu họ cần chi tiết triển khai, hãy lên kế hoạch cho một tài liệu kỹ thuật hoặc phụ lục.

Các định dạng này có thể hỗ trợ lẫn nhau. Chúng không được mâu thuẫn với nhau. Giữ một bộ thông tin sản phẩm đã được phê duyệt, sau đó điều chỉnh độ sâu cho từng độc giả. Một dịch vụ viết sách trắng có thể giúp biến tài liệu nguồn thành bản nháp mà không thay đổi thông tin.

7 khối giúp lập luận dễ theo dõi

Một sách trắng crypto hữu ích đi từ vấn đề của độc giả đến câu trả lời của dự án. Sau đó, nó cho thấy câu trả lời đó hoạt động như thế nào. Đặt nội dung liên quan đến quyết định ở gần đầu. Đừng chôn nó dưới một phần giới thiệu dài.

• Vấn đề: nêu tên ai gặp phải và điều gì còn thiếu sót.
• Dự án: giải thích câu trả lời được đề xuất bằng ngôn ngữ đơn giản.
• Sản phẩm: tách biệt các tính năng hiện có khỏi công việc đã lên kế hoạch.
• Hệ thống: hiển thị các thành phần, hành động của người dùng và phụ thuộc.
• Token: giải thích các chức năng liên quan và điều khoản nguồn cung, nếu có.
• Rủi ro: nêu rõ các hạn chế, giả định và câu hỏi chưa được giải quyết.
• Nguồn: hướng độc giả đến tài liệu hỗ trợ các tuyên bố chính.

Sử dụng tiêu đề để ai đó có thể quét lập luận. Thêm sơ đồ khi nó làm rõ vai trò hoặc luồng tài sản. Giải thích sơ đồ bằng văn bản nữa. Di chuyển các tính toán dài hoặc chi tiết triển khai vào phụ lục khi chúng làm gián đoạn phần giải thích chính.

Coi đây là một dàn bài làm việc, không phải một mẫu bắt buộc. Một dự án không có token không nên thêm chương về token để lấy hình thức. Một giao thức có thể cần nhiều chi tiết hệ thống hơn một sản phẩm tiêu dùng. Đối với truyền thông ra mắt xung quanh tài liệu, hãy sử dụng danh sách kiểm tra marketing launch token.

5 bước soạn thảo, với bàn giao rõ ràng ở mỗi bước

Năm bước giúp việc thu thập thông tin, viết và phê duyệt tách biệt. Dành cho mỗi bước một khung thời gian và bàn giao rõ ràng.

1. Độc giả và mục đích. Khung thời gian: trước khi lập dàn bài. Xác định độc giả chính và quyết định mà tài liệu nên hỗ trợ.
2. Thu thập nguồn. Khung thời gian: trước khi soạn thảo. Thu thập thông tin sản phẩm, kỹ thuật, token và lộ trình. Đánh dấu các khoảng trống thay vì phỏng đoán.
3. Phê duyệt dàn bài. Khung thời gian: trước khi viết toàn văn. Xác nhận thứ tự các phần. Chỉ định chủ sở hữu cho mỗi tuyên bố kỹ thuật hoặc sản phẩm.
4. Soạn thảo và kiểm tra thông tin. Khung thời gian: khi nguồn còn hiện tại. Viết từ tài liệu đã được phê duyệt. Yêu cầu mỗi chủ sở hữu xác minh các tuyên bố của họ.
5. Biên tập và phát hành. Khung thời gian: sau khi rà soát thông tin. Giải quyết các mâu thuẫn và kiểm tra thuật ngữ. Chỉ định chủ sở hữu cho các bản cập nhật trong tương lai.

Giữ 1 tệp làm việc có phiên bản. Ghi lại các quyết định thay đổi văn bản. Điều này giúp phát hiện các tuyên bố cũ dễ dàng hơn trong quá trình biên tập. Một danh sách kiểm tra launch token có thể giúp căn chỉnh sách trắng với các tài liệu launch khác.

5 kiểm tra tuyên bố nào nên có trong bản nháp?

Kiểm tra bất kỳ tuyên bố nào có thể mô tả một tính năng đang hoạt động, chức năng token hoặc cam kết trong tương lai. Kiểm tra nguồn giúp độc giả phân biệt hành vi đã được xác minh với mục tiêu thiết kế hoặc giả định của nhóm.

Đối với mỗi tuyên bố quan trọng, ghi lại nguồn và trạng thái của nó. Sau đó hỏi:

• Bằng chứng: độc giả có thể kiểm tra tài liệu nguồn không?
• Trạng thái: điều này đang hoạt động, đã lên kế hoạch, có điều kiện hay chưa được giải quyết?
• Ranh giới: các phụ thuộc và ngoại lệ có rõ ràng không?
• Cách diễn đạt: câu có mô tả 1 thông tin có thể quan sát được không?
• Nhất quán: cùng một thông tin có xuất hiện ở nơi khác không?

Trích dẫn nên giải thích sự liên quan của chúng. Đừng để độc giả với một danh sách liên kết trần trụi. Đối với một tuyên bố về hiệu suất, hãy nêu rõ những gì đã được kiểm tra và trong điều kiện nào. Đối với một tính năng đã lên kế hoạch, hãy gắn nhãn là đã lên kế hoạch trong văn bản, sơ đồ và lộ trình.

Chi tiết token cũng cần kỷ luật tương tự. Xác định các điều khoản nguồn cung riêng biệt khi chúng được áp dụng:

• Tổng nguồn cung: nêu thuật ngữ được dự án sử dụng.
• Nguồn cung lưu hành: giải thích con số đại diện cho điều gì.
• Phân bổ: xác định từng danh mục và mục đích đã nêu của nó.
• Điều kiện phát hành: mô tả các điều khoản vesting hoặc phân phối hiện hành.
• Số liệu chưa hoàn thành: đánh dấu là chưa được giải quyết; không ngụ ý tính cuối cùng.

Sử dụng nguồn mà nhóm có thể xác minh. Hướng dẫn listing CoinGecko đề cập đến một quy trình hồ sơ riêng. Nó không thay thế việc kiểm tra nguồn trong tài liệu.

6 lỗi soạn thảo cần loại bỏ trước khi phát hành

Sáu lỗi thường gặp khiến sách trắng khó đánh giá hơn. Sửa chúng khi chủ sở hữu sản phẩm và kỹ thuật vẫn có thể xác nhận thông tin.

• Biệt ngữ trước: giới thiệu vấn đề của độc giả trước các thuật ngữ chuyên môn.
• Mờ trạng thái: đánh dấu các tính năng đã phát hành và đã lên kế hoạch một cách nhất quán.
• Token theo giả định: giải thích một chức năng thực tế hoặc bỏ qua tuyên bố.
• Lộ trình như sự chắc chắn: gắn nhãn kế hoạch và nêu các điều kiện liên quan.
• Thiếu phụ thuộc: nêu tên hợp đồng, nhà cung cấp, quyền hạn hoặc hành động của người dùng.
• Dài mà không có mục đích: giữ chi tiết giúp giải thích hoặc xác minh dự án.

Chạy 1 lần kiểm tra cuối cùng trên toàn bộ tài liệu, trang web và tài liệu token. Đánh dấu các tuyên bố nghe như khả năng hiện tại hoặc cam kết chắc chắn. Yêu cầu người chịu trách nhiệm xác nhận chúng. Thay thế lời khen chung chung bằng các mô tả có thể quan sát được. Loại bỏ các tuyên bố không có hỗ trợ.

Một sách trắng có thể giải thích thiết kế của dự án. Nó không thể kiểm soát các đánh giá listing CoinGecko hoặc CoinMarketCap hoặc trình bày hồ sơ. Các nền tảng đó quyết định kết quả đánh giá và hiển thị. Một tài liệu không thể đảm bảo sự chấp nhận hoặc một hiển thị cụ thể.

3 lần rà soát trước khi tệp được công bố

Ba lần rà soát cung cấp cho nhóm một bản ghi thực tế về những gì đã được kiểm tra. Chúng cũng cho thấy những gì vẫn cần được chú ý. Liên kết mọi nhận xét với văn bản, nguồn và chủ sở hữu cụ thể.

Tại DigitalMedia1, chúng tôi so sánh bản nháp với các tài liệu dự án bạn cung cấp. Chúng tôi đánh dấu các tuyên bố cần bằng chứng hoặc xác nhận của chủ sở hữu kỹ thuật. Bạn nhận được một danh sách chỉnh sửa cụ thể, không phải phản hồi mơ hồ. Nếu bản nháp cần hỗ trợ viết, chúng tôi có thể thảo luận công việc đó riêng.

Gửi bản nháp hiện tại, tài liệu nguồn, độc giả chính và khung thời gian xuất bản dự kiến. Chúng tôi sẽ kiểm tra những gì đã sẵn sàng và xác định các câu hỏi mở. Bạn sẽ nhận được báo giá bằng văn bản trong vòng 2 ngày làm việc.

Cách hoạt động

1. 1. Xác định độc giảViết ra tài liệu phục vụ ai và quyết định nào nó nên hỗ trợ. Sử dụng lựa chọn đó để đặt mức độ chi tiết.
2. 2. Thu thập tài liệu nguồnThu thập thông tin sản phẩm, kỹ thuật, token và lộ trình. Đánh dấu các mục chưa được giải quyết và nêu tên người có thể xác nhận từng mục.
3. 3. Phê duyệt dàn bàiSắp xếp 7 khối chính xung quanh câu hỏi của độc giả. Loại bỏ các phần không phù hợp với dự án.
4. 4. Soạn thảo và xác minhTách biệt khả năng hiện tại khỏi đề xuất. Yêu cầu chủ sở hữu sản phẩm và kỹ thuật xác minh các tuyên bố họ biết.
5. 5. Biên tập và phát hànhGiải quyết các mâu thuẫn, kiểm tra liên kết và thuật ngữ, sau đó chỉ định chủ sở hữu để giữ cho các thông tin thực tế luôn cập nhật.