Hướng dẫn viết Whitepaper Crypto: Cấu trúc và Quy trình

Sách trắng crypto nên giúp người đọc quyết định điều gì?

Một sách trắng crypto nên cho phép người đọc mục tiêu hiểu về dự án, đánh giá các tuyên bố của nó và xác định những gì còn chưa chắc chắn. Xác định công việc đó trước khi soạn thảo; nếu không, tài liệu có xu hướng pha trộn tổng quan sản phẩm, đặc tả kỹ thuật, bài gọi vốn và hướng dẫn sử dụng mà không phục vụ tốt bất kỳ mục đích nào.

1. Đặt tên cho người đọc chính: người dùng, nhà phát triển, đối tác hệ sinh thái hoặc người tham gia token.
2. Viết quyết định của người đọc trong một câu. Ví dụ: “Tôi có thể hiểu cách giao thức này xử lý một giao dịch không?”
3. Liệt kê bằng chứng mà người đọc đó cần, chẳng hạn như sơ đồ kiến trúc, giải thích về phí hoặc mô tả trạng thái sản phẩm hiện tại.
4. Đánh dấu thông tin chưa sẵn sàng để công bố và chỉ định một chủ sở hữu để xác nhận nó.

Sử dụng một đối tượng chính để thiết lập độ sâu và từ vựng. Nếu tài liệu phải phục vụ nhiều đối tượng khác nhau, hãy cung cấp cho mỗi người một lộ trình rõ ràng xuyên suốt tài liệu: tổng quan ngắn gọn trước, sau đó là chi tiết kỹ thuật hoặc kinh tế. Không sử dụng ngôn ngữ nhà đầu tư để che đậy những khoảng trống trong giải thích sản phẩm. Người đọc nên có thể phân biệt những gì tồn tại, những gì đang được xây dựng và những gì chỉ đang được xem xét. Giữ tài liệu quảng cáo tách biệt khỏi các tuyên bố yêu cầu bằng chứng.

Cấu trúc nào làm cho sách trắng crypto dễ đánh giá?

Một cấu trúc hữu ích di chuyển từ vấn đề đến hệ thống, sau đó đến bằng chứng, kinh tế và các câu hỏi mở. Giữ thứ tự logic: người đọc cần bối cảnh dự án trước khi họ có thể đánh giá các lựa chọn thiết kế của nó.

Coi đây là một dàn ý làm việc, không phải một mẫu cố định. Một bài báo về giao thức có thể cần thêm chi tiết kiến trúc và bảo mật; một sản phẩm tiêu dùng có thể cần luồng người dùng rõ ràng hơn. Đặt định nghĩa gần lần sử dụng đầu tiên của chúng. Thêm danh sách nội dung cho tài liệu dài và sử dụng tiêu đề nêu chủ đề thay vì các nhãn chung chung như “Chi tiết”. Nếu bạn đang chuẩn bị tài liệu launch cùng với bài báo, hãy kết nối nó với danh sách kiểm tra marketing launch token để các mô tả công khai vẫn nhất quán.

Làm thế nào để giải thích cơ chế giao thức và thiết kế token?

Giải thích hệ thống theo thứ tự người đọc gặp nó: đầu vào, hành động, đầu ra và các phụ thuộc. Sau đó mô tả token chỉ khi vai trò của nó trong hệ thống đó rõ ràng. Điều này ngăn phần token trở thành một danh sách các lợi ích trừu tượng.

1. Mô tả hành động của người dùng hoặc hợp đồng bắt đầu quy trình.
2. Xác định các thành phần liên quan và trách nhiệm của mỗi thành phần.
3. Cho thấy trạng thái thay đổi, giá trị di chuyển hoặc quyết định được ghi lại như thế nào.
4. Giải thích các đường dẫn thất bại và vai trò của quản trị viên hoặc các nhà điều hành khác.
5. Nêu rõ token cho phép điều gì, ai có thể sử dụng nó và những điều kiện nào áp dụng.

Một sơ đồ có thể hiển thị trình tự hoặc mối quan hệ, nhưng hãy kết hợp nó với một hướng dẫn bằng văn bản. Xác định các thuật ngữ chuyên ngành một lần, sau đó sử dụng chúng một cách nhất quán. Đối với nguồn cung và phân bổ token, hãy đối chiếu mọi con số trên các bảng, văn xuôi và biểu đồ; giải thích các điều kiện vesting hoặc phát hành bằng ngôn ngữ đơn giản nếu có liên quan. Tách biệt tiện ích khỏi quyền quản trị và không ngụ ý rằng việc nắm giữ token cấp quyền trừ khi thiết kế và tài liệu của dự án hỗ trợ tuyên bố đó. Để kiểm tra tập trung về ngôn ngữ và hồ sơ nguồn cung, hãy xem cách xác minh nguồn cung trên CoinGecko.

Những tuyên bố và bằng chứng nào nên có trong tài liệu?

Bao gồm các tuyên bố giúp người đọc đánh giá thiết kế và làm cho trạng thái của chúng hiện rõ. Một sách trắng chính xác phân biệt các tính năng đã triển khai, kết quả đã kiểm tra, công việc đã lên kế hoạch và các giả định thay vì trình bày chúng như nhau.

• Đối với một tính năng đang hoạt động, hãy xác định những gì người đọc có thể kiểm tra, chẳng hạn như tài liệu sản phẩm hoặc địa chỉ hợp đồng công khai.
• Đối với một kết quả thử nghiệm, hãy mô tả phạm vi và điều kiện để người đọc có thể giải thích những gì nó chứng minh.
• Đố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 và nêu tên sự phụ thuộc hoặc quyết định có thể thay đổi nó.
• Đối với một tuyên bố so sánh, hãy nêu rõ cơ sở so sánh và tránh các từ so sánh nhất không được hỗ trợ.
• Đối với một con số, hãy ghi lại nguồn, ngày xác minh và người chịu trách nhiệm xác nhận nó.

Duy trì một sổ đăng ký tuyên bố trong khi soạn thảo. Một bảng đơn giản với tuyên bố, trạng thái, nguồn, chủ sở hữu và trạng thái phê duyệt sẽ phát hiện sự khác biệt trước khi trình bày. Sử dụng các trích dẫn hoặc tham chiếu trực tiếp cho tài liệu kỹ thuật bên ngoài và đảm bảo người đọc có thể xác định tuyên bố nào mô tả hệ thống của riêng bạn. Không thêm ước tính thị trường hoặc tuyên bố hiệu suất chỉ để làm cho bài báo có vẻ hoàn chỉnh. Nếu bằng chứng không có sẵn, hãy nói những gì được biết và bỏ qua khẳng định cho đến khi nó có thể được xem xét.

Nhóm nên soạn thảo và xem xét sách trắng như thế nào?

Soạn thảo sách trắng từ các tài liệu dự án đã được xác minh, sau đó xem xét nó trong các lần riêng biệt về độ chính xác, khả năng hiểu và tính nhất quán. Điều này hiệu quả hơn là yêu cầu nhiều người đánh giá chỉnh sửa mọi câu cùng một lúc.

1. Danh sách kiểm tra khởi động: thu thập tóm tắt sản phẩm, ghi chú kiến trúc, tài liệu token, lộ trình, trạng thái hiện tại và thuật ngữ đã được phê duyệt.
2. Đánh giá dàn ý: yêu cầu founder hoặc trưởng nhóm sản phẩm xác nhận đối tượng, phạm vi và thứ tự phần trước khi văn xuôi được viết.
3. Bản nháp kỹ thuật: yêu cầu kỹ sư hoặc chủ sở hữu giao thức liên quan xác minh các cơ chế, phụ thuộc và sơ đồ hệ thống.
4. Lần biên tập: loại bỏ sự lặp lại, xác định thuật ngữ và kiểm tra xem mỗi tuyên bố đã được dán nhãn rõ ràng là hiện tại, đã lên kế hoạch hay giả định chưa.
5. Đối chiếu cuối cùng: so sánh chi tiết token, tên, ngày tháng và liên kết công khai trên toàn bộ bài báo và tài liệu launch.

Tại AEOTech, đánh giá biên tập sử dụng sổ đăng ký tuyên bố: mỗi tuyên bố quan trọng được ghép nối với một nguồn hoặc chủ sở hữu dự án được nêu tên trước khi bản sao cuối cùng được phê duyệt. Giữ một người chịu trách nhiệm tổng hợp phản hồi và yêu cầu người đánh giá gắn cờ sửa chữa thực tế riêng biệt với sở thích về phong cách. Hỗ trợ viết sách trắng từ $1.320 / dự án; phạm vi được xác nhận dựa trên tài liệu và nhu cầu đánh giá. Để có brief soạn thảo đầy đủ, hãy xem viết sách trắng và litepaper.

Những sai lầm về sách trắng crypto nào bạn nên phát hiện sớm?

Những sai lầm có hại nhất khiến người đọc khó biết dự án thực sự làm gì hoặc liệu các tuyên bố của nó có được hỗ trợ hay không. Hãy phát hiện chúng ở giai đoạn dàn ý và đánh giá, trước khi trình bày làm cho việc chỉnh sửa chậm hơn.

• Bắt đầu bằng khẩu hiệu: thay thế các tuyên bố rộng bằng mô tả về vấn đề người dùng và phản hồi của hệ thống.
• Sử dụng thuật ngữ không giải thích: xác định thuật ngữ ở nơi nó quan trọng lần đầu tiên; loại bỏ nó nếu nó không thêm chi tiết hữu ích cho quyết định.
• Pha trộn kế hoạch với tính năng đã phát hành: dán nhãn trạng thái trong văn bản và giữ ngôn ngữ lộ trình nhất quán trong suốt.
• Coi phân bổ token là tự giải thích: nêu rõ danh mục, điều kiện và bất kỳ cơ chế phát hành có liên quan nào.
• Sử dụng sơ đồ mà không có hướng dẫn: thêm giải thích bằng văn bản hoạt động cho người đọc lướt qua hoặc không thể hiểu hình ảnh.
• Để rủi ro ở cuối: xác định các phụ thuộc và giới hạn thiết kế gần các tuyên bố mà chúng đủ điều kiện, sau đó thu thập chúng trong một phần rủi ro rõ ràng.

Một chỉnh sửa thực tế là làm nổi bật mọi câu có chứa lời hứa, so sánh, khẳng định kỹ thuật hoặc chi tiết token. Hỏi: ai có thể xác minh điều này và hỗ trợ ở đâu? Nếu câu trả lời không rõ ràng, hãy sửa lại câu, thêm nguồn hoặc loại bỏ nó. Tránh làm phình tài liệu để báo hiệu uy quyền. Tính đầy đủ có nghĩa là bao gồm các quyết định người đọc cần hiểu, không phải tối đa hóa độ dài.

Bạn nên kiểm tra điều gì trước khi xuất bản sách trắng crypto?

Trước khi xuất bản, hãy kiểm tra xem bài báo có nhất quán nội bộ, có thể đọc được mà không cần ngữ cảnh riêng tư và phù hợp với các tài liệu công khai hiện tại của dự án. Một đánh giá cuối cùng nên kiểm tra tài liệu như cách người đọc sẽ sử dụng nó, không chỉ như nhóm nhớ đã viết nó.

• Người đọc mới có thể tóm tắt sản phẩm và người dùng mục tiêu của nó sau khi đọc tổng quan không?
• Các sơ đồ, bảng token và văn xuôi có mô tả cùng một hệ thống và số liệu không?
• Chức năng hiện tại, công việc đã lên kế hoạch, giả định và phụ thuộc có thể phân biệt được không?
• Các liên kết có hoạt động, tài liệu tham khảo có xác định nguồn của chúng và các thuật ngữ đã xác định có nhất quán không?
• Chủ sở hữu dự án đã phê duyệt mô tả kỹ thuật và chi tiết token mới nhất chưa?

Một sách trắng không thể thay thế cho việc đánh giá mã hoặc tư vấn pháp lý; các tuyên bố về tính năng đã phát hành, quyền token và tuân thủ phải được kiểm tra bởi các chuyên gia chịu trách nhiệm. Chúng tôi có thể làm cho các giả định hiện rõ, nhưng chỉ chủ sở hữu dự án và cố vấn có thẩm quyền mới có thể xác nhận chúng.

Để có tài liệu hướng tới nhà đầu tư liên quan, hãy so sánh phạm vi với hướng dẫn pitch deck crypto. Để bắt đầu đánh giá sách trắng, hãy gửi dàn ý hiện tại, tài liệu nguồn, tài liệu token và người chịu trách nhiệm phê duyệt kỹ thuật đến nhóm viết sách trắng. Chúng tôi sẽ ánh xạ tài liệu vào một kế hoạch phần và xác định những gì cần xác nhận 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 người đọc và mục đíchĐặt tên cho đối tượng chính và quyết định mà tài liệu nên hỗ trợ. Thu thập các tài liệu mà người đọc đó cần để đánh giá dự án.
2. Tạo dàn ý phầnSắp xếp các phần từ vấn đề và sản phẩm qua hệ thống, thiết kế token, trạng thái và rủi ro. Xác nhận dàn ý với chủ sở hữu dự án.
3. Soạn thảo từ các nguồn đã xác minhSử dụng tài liệu dự án và chủ sở hữu được nêu tên để hỗ trợ các tuyên bố kỹ thuật, kinh tế và lộ trình. Dán nhãn kế hoạch và giả định rõ ràng.
4. Đánh giá tuyên bố và sự rõ ràngChạy các lần đánh giá kỹ thuật và biên tập riêng biệt. Đối chiếu sổ đăng ký tuyên bố, sơ đồ, mô tả token và thuật ngữ.
5. Phê duyệt bản sao xuất bảnKiểm tra liên kết, tài liệu tham khảo, tính nhất quán và quyền sở hữu của các phê duyệt cuối cùng. Chỉ xuất bản sau khi người đánh giá chịu trách nhiệm xác nhận nội dung.