Cách viết whitepaper crypto: Cấu trúc và lỗi thường gặp

Bắt đầu với quyết định mà sách trắng của bạn phải hỗ trợ

Một sách trắng crypto hữu ích giúp một người đọc cụ thể hiểu dự án làm gì, nó được thiết kế như thế nào và điều gì vẫn còn chưa chắc chắn. Trước khi soạn thảo, hãy quyết định xem người đọc chính là người dùng, nhà phát triển, người tham gia token, đối tác hay người đánh giá; tài liệu có thể phục vụ nhiều đối tượng, nhưng không nên bắt mỗi người phải tự tìm câu trả lời của họ.

Viết một câu mục đích cho tài liệu, sau đó trả lời các câu hỏi này:

• Dự án giải quyết vấn đề gì và cho ai?
• Vai trò của hệ thống được đề xuất trong việc giải quyết vấn đề đó là gì?
• Người đọc có thể kiểm tra hoặc sử dụng điều gì hôm nay, và điều gì vẫn đang được lên kế hoạch?
• Những quyết định nào mà tài liệu giải thích mà không rõ ràng từ sản phẩm hoặc hợp đồng?

Các câu trả lời giúp thiết lập phạm vi. Một giao thức có thiết kế kỹ thuật mới lạ có thể cần chi tiết kiến trúc đáng kể; một ứng dụng được xây dựng trên cơ sở hạ tầng đã được thiết lập có thể cần nhiều không gian hơn cho luồng người dùng, phụ thuộc và tiện ích token. Đừng sử dụng độ sâu kỹ thuật như một sự thay thế cho việc giải thích sự liên quan.

Sách trắng cũng không phải là một pitch deck được mở rộng thành các đoạn văn. Một deck giới thiệu một trường hợp để thu hút sự chú ý; một sách trắng nên làm cho trường hợp đó có thể kiểm tra được, bao gồm các giả định và ràng buộc. Nếu nhóm cần cả hai, hãy giữ các sự kiện trung tâm được thống nhất trong khi cho mỗi định dạng công việc riêng của nó. Xem hướng dẫn pitch deck crypto để biết vai trò của tài liệu đồng hành.

Cấu trúc nào mà một sách trắng crypto nên tuân theo?

Một sách trắng crypto cần một trình tự đưa người đọc từ vấn đề đến thiết kế và các hàm ý của nó. Thứ tự dưới đây là một khung bắt đầu, không phải là một mục lục bắt buộc; chỉ giữ lại một phần khi nó trả lời một câu hỏi thực sự của người đọc.

Sử dụng phần tổng quan để cung cấp cho người đọc một bản đồ đáng tin cậy, không phải một bài chào hàng nén. Trong các phần kỹ thuật, hãy định nghĩa các thuật ngữ trước khi dựa vào chúng và kết nối mỗi thành phần với chức năng của nó. Một sơ đồ có thể làm cho một luồng dễ theo dõi hơn, nhưng các nhãn và ranh giới của nó phải đồng nhất với văn xuôi.

Giải thích token chỉ khi dự án có một vai trò xác định cho nó. Phân biệt tiện ích, quản trị và chi tiết phân bổ thay vì ngụ ý rằng cái này tự động tạo ra cái kia. Để kiểm tra kỹ hơn dữ liệu token, hãy sử dụng hướng dẫn cung ứng token. Nếu một chủ đề không liên quan đến dự án, hãy nói ngắn gọn hoặc bỏ qua nó; thêm một phần chung chung có thể tạo ra các câu hỏi mà sản phẩm không trả lời.

Làm thế nào để làm cho các tuyên bố kỹ thuật và token trở nên đáng tin cậy?

Các tuyên bố đáng tin cậy đủ cụ thể để người đọc có thể xem xét và đủ hạn chế để phù hợp với trạng thái thực tế của dự án. Đối với mọi tuyên bố quan trọng, hãy xác định nguồn, chủ sở hữu và trạng thái của nó trước khi nó được đưa vào bản thảo.

Một đánh giá tuyên bố có thể sử dụng ba nhãn:

• Hiện tại: được hỗ trợ bởi một sản phẩm trực tiếp, mã đã xuất bản, quy trình đã được ghi chép hoặc quyết định đã được xác nhận.
• Đã lên kế hoạch: một khả năng hoặc cột mốc dự định chưa được giao; mô tả nó như một kế hoạch.
• Giả định: một điều kiện mà thiết kế dựa vào nhưng nhóm chưa thiết lập như một sự thật.

Sau đó kiểm tra cách diễn đạt. Thay thế các cụm từ rộng như "hoàn toàn phi tập trung" bằng một lời giải thích về quyết định nào được phân phối, vai trò nào giữ quyền hạn và cơ chế nào chi phối sự thay đổi. Mô tả công việc bảo mật theo trạng thái và phạm vi thực tế của nó. Đừng ngụ ý rằng một audit, thử nghiệm hoặc tích hợp bao phủ nhiều hơn thực tế.

Các phần token cũng cần kỷ luật tương tự. Kiểm tra rằng tên, đơn vị, phân bổ, mô tả vesting và tuyên bố cung ứng khớp với các tài liệu đã được phê duyệt của dự án. Khi một con số hoặc chính sách chưa được xác định, hãy đánh dấu nó cho nhóm chịu trách nhiệm thay vì lấp đầy khoảng trống bằng một câu trả lời bịa đặt. Một danh sách kiểm tra launch token có thể giúp xác định các tài liệu liên quan nên sử dụng ngôn ngữ nhất quán.

Đánh giá này không chỉ là biên tập. Hãy yêu cầu trưởng bộ phận kỹ thuật xác minh mô tả hệ thống, chủ sở hữu token xác nhận chi tiết token và trưởng dự án giải quyết các tuyên bố về lộ trình hoặc quản trị. Ghi lại sự chấp thuận đối với phần cụ thể, để người đánh giá có thể tập trung vào các quyết định thay vì đọc lại toàn bộ tài liệu.

Nhóm nên chuẩn bị gì trước khi soạn thảo?

Nhóm nên chuẩn bị một gói nguồn cho phép người viết phân biệt các sự kiện đã được xác nhận với các câu hỏi mở. Một bộ tài liệu ngắn gọn, được tổ chức tốt sẽ hữu ích hơn một thư mục lớn không có chỉ dẫn về những gì hiện tại.

Bao gồm, nếu có:

• Một hướng dẫn sản phẩm hoặc mô tả luồng người dùng dự định.
• Ghi chú kiến trúc, sơ đồ và một người đánh giá kỹ thuật đã được chỉ định.
• Mô hình token hiện tại và người được ủy quyền xác nhận nó.
• Các quyết định về lộ trình, phụ thuộc đã biết và các mục chưa được giải quyết.
• Trang web hiện tại, pitch deck, tài liệu và các tuyên bố công khai.
• Ưu tiên của đối tượng, thuật ngữ ưa thích và bất kỳ ranh giới confidentiality nào.

Buổi làm việc đầu tiên nên thiết lập phạm vi: đối tượng nào quan trọng nhất, tài liệu phải giải thích điều gì, bằng chứng nào tồn tại và tuyên bố nào cần theo dõi. Người viết nên trả lại một nhật ký câu hỏi thay vì âm thầm đưa ra các giả định. Nhật ký đó cung cấp cho nhóm một cách thực tế để giải quyết các khoảng trống và gán mỗi câu trả lời cho người có đủ năng lực cung cấp nó.

Sau đó, việc soạn thảo chuyển từ dàn ý sang các phần, với đánh giá kỹ thuật và dự án tại các điểm đã lên kế hoạch thay vì chỉ ở lần giao cuối cùng. Một lượt biên tập hạn chế nên loại bỏ sự lặp lại, định nghĩa các thuật ngữ một cách nhất quán và phân biệt các sự kiện sản phẩm với kế hoạch. Các định dạng sách trắng và litepaper cũng phục vụ các mức độ chi tiết khác nhau; sự lựa chọn đúng đắn phụ thuộc vào việc người đọc cần một lời giải thích đầy đủ hay một định hướng ngắn gọn. Để được hỗ trợ viết chuyên dụng, xem dịch vụ viết sách trắng và litepaper, và so sánh phạm vi tại bảng giá sách trắng crypto.

Những lỗi sách trắng nào làm suy yếu lòng tin của người đọc?

Những lỗi sách trắng gây hại nhất thường là sự không khớp: giữa tuyên bố và bằng chứng, tham vọng và khả năng hiện tại, hoặc ngôn ngữ token và thực tế dự án. Một lần đọc cuối cùng nên tìm kiếm những sự không khớp này trước khi trau chuốt nhịp điệu câu.

Các vấn đề phổ biến bao gồm:

• Bắt đầu bằng những tuyên bố lớn: Người đọc cần một vấn đề cụ thể và một lời giải thích rõ ràng về phản ứng được đề xuất trước tiên.
• Sử dụng ngôn ngữ kỹ thuật không giải thích: Định nghĩa các thuật ngữ ở lần sử dụng đầu tiên và giải thích tại sao một lựa chọn thiết kế lại quan trọng.
• Coi lộ trình như một lời hứa: Gắn nhãn công việc đã lên kế hoạch là đã lên kế hoạch, xác định các phụ thuộc và tránh trình bày ý định như các tính năng đã hoàn thành.
• Đưa ra chi tiết token mà không có bối cảnh: Giải thích từng chức năng đã nêu và giữ ngôn ngữ cung ứng hoặc phân bổ nhất quán với các tài liệu dự án đã được phê duyệt.
• Điền vào một mẫu một cách máy móc: Loại bỏ các phần không phù hợp với dự án thay vì đưa ra các tuyên bố chung chung để lấp đầy chúng.
• Để sơ đồ và văn xuôi không đồng bộ: Yêu cầu cùng một người đánh giá kỹ thuật kiểm tra cả hai biểu diễn của hệ thống.

Cũng kiểm tra các mâu thuẫn nội bộ. Tìm kiếm các thuật ngữ, ngày tháng, mô tả cung ứng và tên sản phẩm lặp lại; so sánh chúng với trang web và tài liệu hiện tại. Chỉ định một người duy trì các sự kiện chuẩn trong quá trình chỉnh sửa, bởi vì một sửa chữa được thực hiện trong một đoạn văn có thể để lại một tuyên bố lỗi thời ở nơi khác.

Một tài liệu ngắn gọn có thể đầy đủ nếu nó trả lời các câu hỏi thiết yếu mà không che giấu các giả định. Độ dài một mình không làm cho một lập luận trở nên chặt chẽ. Khi một điểm chưa thể được chứng minh, hãy nêu rõ giới hạn hoặc để nó cho một bản sửa đổi sau.

Làm thế nào để đánh giá một sách trắng crypto trước khi xuất bản?

Một đánh giá trước khi xuất bản nên xác nhận tính chính xác, nhất quán và khả năng đọc theo thứ tự đó. Bắt đầu với những người chịu trách nhiệm về các sự kiện cơ bản, sau đó đánh giá xem một người đọc không quen thuộc có thể theo dõi lời giải thích mà không cần một cuộc họp trực tiếp hay không.

Sử dụng trình tự đánh giá này:

1. Đánh giá kỹ thuật: Kiểm tra kiến trúc, thuật ngữ, ranh giới hệ thống và sơ đồ với chủ sở hữu kỹ thuật.
2. Đánh giá token và vận hành: Xác nhận mô tả token, ngôn ngữ quản trị, vai trò và chi tiết vận hành với các chủ sở hữu dự án liên quan.
3. Đánh giá người đọc: Yêu cầu một người bên ngoài nhóm soạn thảo tóm tắt vấn đề, cơ chế, vai trò token và trạng thái hiện tại sau khi đọc.
4. Đánh giá tính nhất quán: So sánh các tuyên bố với trang web, tài liệu, deck và các tài liệu công khai khác; giải quyết sự khác biệt tại nguồn.
5. Đánh giá sao chép và bố cục: Kiểm tra tiêu đề, định nghĩa, liên kết, bảng, chi tiết phiên bản và liệu tài liệu có còn dễ đọc trên màn hình hay không.

Giữ một nhật ký thay đổi cho các chỉnh sửa quan trọng và đánh dấu ai đã phê duyệt phiên bản thực tế cuối cùng. Điều này làm cho các bản cập nhật sau này dễ dàng hơn khi sản phẩm, mô hình token hoặc lộ trình thay đổi. Coi sách trắng như một tài liệu tham khảo được duy trì, không phải một bản ghi vĩnh viễn không bao giờ có thể sửa đổi.

Người viết có thể tổ chức và làm rõ thông tin của dự án, nhưng không thể quyết định các sự kiện kỹ thuật thay mặt cho nhóm. Nhóm cũng kiểm soát liệu tài liệu có đáp ứng các nghĩa vụ pháp lý và tiết lộ của riêng mình hay không; bản thân sách trắng không đảm bảo sự chấp thuận, listing hoặc chấp nhận của người đọc. Tại MediaStrategy, bước đánh giá được đặt tên là một lượt tuyên bố và nguồn: chúng tôi đánh dấu các tuyên bố không được hỗ trợ, gán các câu hỏi mở cho chủ sở hữu phù hợp và đối chiếu bản thảo cuối cùng với các tài liệu bạn phê duyệt. Gửi cho chúng tôi tài liệu hiện tại, tài liệu token và người đọc dự định của bạn; chúng tôi sẽ trả lại một dàn ý có phạm vi và các câu hỏi cần giải quyết trước khi soạn thảo.

Bảng giá

Giá khởi điểm bằng USD. Gói tùy chỉnh và chiết khấu theo số lượng theo yêu cầu. Thanh toán bằng USDT, USDC, BTC, ETH, SOL, TON hoặc token dự án của bạn.

Cách hoạt động

1. Xác định công việc của tài liệuNêu tên người đọc chính và các câu hỏi mà sách trắng phải trả lời. Sử dụng phạm vi đó để quyết định những gì thuộc về tài liệu.
2. Tập hợp các nguồn đã được phê duyệtThu thập các tài liệu sản phẩm, kỹ thuật, token và lộ trình hiện tại, và xác định chủ sở hữu cho mỗi lĩnh vực thực tế.
3. Soạn thảo dàn ýSắp xếp các phần theo trình tự dẫn dắt người đọc và đánh dấu bằng chứng còn thiếu hoặc các quyết định chưa được giải quyết trước khi soạn thảo đầy đủ.
4. Viết và đánh giá theo chủ đềPhát triển các phần, sau đó chuyển các tuyên bố kỹ thuật, token và dự án đến những người có đủ năng lực xác minh chúng.
5. Đối chiếu và xuất bảnGiải quyết các nhận xét, thống nhất tài liệu với các tài liệu công khai khác và ghi lại sự chấp thuận của phiên bản thực tế cuối cùng.