Chuyên Gia Viết Sách Trắng (Whitepaper) Tiền Mã Hóa

1---
2name: crypto-whitepaper-writer
3description: Viết một bản sách trắng (whitepaper) đáng tin cậy, có cấu trúc chặt chẽ cho bất kỳ dự án tiền mã hóa/blockchain nào (chuỗi L1, giao thức DeFi, mạng lưới oracle, stablecoin, hệ thống token) — dựa trên các khuôn mẫu cấu trúc và lập luận của Bitcoin, Ethereum, Uniswap, Chainlink và MakerDAO, thay vì các mẫu thổi phồng ICO chung chung. Sử dụng bất cứ khi nào được yêu cầu soạn thảo, lập dàn ý hoặc đánh giá một bản sách trắng tiền mã hóa/Web3.
4---
5
6# Chuyên Gia Viết Sách Trắng (Whitepaper) Tiền Mã Hóa
7
8## Tại sao kỹ năng này tồn tại
9
10Hầu hết các bản sách trắng tiền mã hóa do AI tạo ra đều đọc giống như các bài thuyết trình tiếp thị: ngôn từ "mang tính cách mạng" mơ hồ,
11những tuyên bố bảo mật không có căn cứ, một lộ trình phát triển (roadmap) đóng vai trò thay cho bằng chứng chứng minh, và mô hình kinh tế token (tokenomics) chỉ để trang trí. Năm
12bản sách trắng được trích dẫn nhiều nhất trong ngành — Bitcoin, Ethereum, Uniswap, Chainlink, MakerDAO — lại cùng chia sẻ một
13kỷ luật hoàn toàn khác: đặt vấn đề lên trước tiên, xây dựng cơ chế tăng dần từng bước, gọi tên rõ các mô hình mối đe dọa (threat models),
14và phân tích động lực khuyến khích theo từng tác nhân tham gia. Kỹ năng này mã hóa kỷ luật đó để văn bản đầu ra mang văn phong
15của một tài liệu kỹ thuật chứ không phải một bài chào mời đầu tư.
16
17Xem tệp `reference.md` để nắm toàn bộ nền tảng nghiên cứu: các khung sườn nguyên mẫu (archetype skeletons), nguyên tắc rèn giũa nội dung, các phản mẫu (anti-patterns),
18và danh sách kiểm tra trước khi xuất bản. Hãy đọc tệp đó trước khi bắt đầu soạn thảo.
19
20## Bước 1 — Thu thập thông tin đầu vào trước khi viết bất kỳ chữ nào
21
22Không bắt đầu soạn thảo cho đến khi bạn có được các thông tin sau từ người dùng:
23
24- **Vấn đề** mà dự án này giải quyết, tóm gọn trong một câu, kèm theo một kịch bản cụ thể về những gì sẽ thất bại
25  nếu không có nó.
26- **Nguyên mẫu dự án (project archetype)** — khuôn mẫu khớp nhất trong `reference.md` → Archetypes: lớp nền tảng
27  đồng thuận/thanh toán (base-layer consensus/settlement), cơ chế DeFi (AMM/cho vay/phái sinh), mạng lưới oracle/điều phối,
28  hệ thống stablecoin/tài sản thế chấp, hoặc giao thức lớp ứng dụng/hệ thống token.
29- **Cơ chế cốt lõi** — những gì thực sự diễn ra trên chuỗi (on-chain) và ngoài chuỗi (off-chain), đủ chi tiết để mô tả một
30  quá trình chuyển đổi trạng thái hoặc công thức toán học, chứ không chỉ là một danh sách tính năng.
31- **Sự tồn tại và vai trò của token** — nếu có token, nó phục vụ chức năng cơ học cụ thể nào
32  (thanh toán phí, tài sản thế chấp, đặt cược/cắt phạt staking/slashing, trọng số quản trị)? Nếu dự án không cần
33  token, hãy nêu rõ điều đó thay vì tự bịa ra mô hình kinh tế token (tokenomics) chỉ để trông cho có vẻ đầy đủ.
34- **Các hạn chế đã biết / rủi ro còn bỏ ngỏ** mà nhóm phát triển sẵn sàng trình bày một cách trung thực.
35
36Nếu bất kỳ thông tin nào trong số này còn thiếu hoặc mơ hồ, hãy hỏi lại trước khi soạn thảo — không bao giờ tự bịa ra tuyên bố vấn đề, hồ sơ
37nhóm phát triển, số liệu người dùng chấp nhận, hoặc mô hình token để lấp vào chỗ trống.
38
39## Bước 2 — Chọn khung sườn các mục, cân chỉnh độ dài
40
41Đối chiếu nguyên mẫu dự án với khung sườn tương ứng trong `reference.md`. Đừng ép mọi bản sách trắng phải đi theo một
42khuôn mẫu giống hệt nhau — Bitcoin không hề có mục tokenomics; MakerDAO không có phần chứng minh bảo mật bằng chứng công việc (proof-of-work).
43Hãy sử dụng trục xương sống chung (vấn đề → cơ chế → phân tích tác nhân/động lực khuyến khích → mô hình mối đe dọa/rủi ro →
44kiến trúc → [quản trị/token, chỉ khi có áp dụng] → các hạn chế → kết luận), và cắt bỏ bất kỳ phần nào
45không áp dụng cho dự án này.
46
47Độ dài phụ thuộc vào độ phức tạp của cơ chế, chứ không phải một số trang cố định — Bitcoin chứng minh luận điểm của mình trong 9 trang;
48MakerDAO cần nhiều hơn thế rất nhiều vì nó điều phối nhiều tác nhân và nhiều kịch bản lỗi hơn. Hãy để mỗi mục kéo dài đúng bằng
49nhu cầu diễn đạt của ý tưởng và không dài hơn (phản mẫu: ép buộc tính đối xứng). Nếu dự án có token hoặc
50đưa ra bất kỳ tuyên bố nào ngụ ý về tài chính/lợi nhuận, hãy đưa vào một tuyên bố miễn trừ trách nhiệm ngắn (theo tiền lệ của Uniswap) nêu rõ rằng
51tài liệu này không phải là lời khuyên đầu tư.
52
53## Bước 3 — Soạn thảo từng mục một, áp dụng các nguyên tắc rèn giũa nội dung
54
55Thực hiện tuần tự theo các nguyên tắc rèn giũa nội dung trong `reference.md` khi viết từng mục. Những nguyên tắc quan trọng
56nhất trên thực tế gồm:
57
58- Mở đầu bằng một kịch bản thất bại, không phải bằng một tuyên bố sứ mệnh sáo rỗng.
59- Xây dựng cơ chế từ một mô hình tối giản rồi nâng dần lên — đừng trình bày ngay thiết kế cuối cùng một cách đột ngột.
60- Mọi tuyên bố về bảo mật hoặc hiệu năng đều phải đi kèm một con số, ngưỡng giới hạn hoặc bằng chứng có tên gọi cụ thể — không bao giờ chỉ dùng một tính từ
61  đơn độc ("bảo mật cao" không phải là một tuyên bố kỹ thuật).
62- Mọi tác nhân hoạt động theo động lực khuyến khích (thợ đào, nhà cung cấp thanh khoản LP, nút oracle, người giữ kho keeper, trình xác thực validator) đều có một đoạn văn riêng
63  nêu chính xác những gì họ kiếm được và hình phạt nào sẽ giáng xuống nếu họ làm trái quy tắc.
64- Gọi tên các hướng tấn công (attack vectors) cụ thể và ghép nối từng hướng với biện pháp đối phó tương ứng.
65- Bao gồm ít nhất một ví dụ thực tế có thể truy vết từng bước — một luồng chạy giao dịch, một phép tính bằng số cụ thể,
66  hoặc một vòng đời hoạt động theo từng bước.
67- Nếu thiết kế này sửa đổi hoặc mở rộng từ một hệ thống tiền nhiệm đã biết, hãy viết nó dưới dạng một phần chênh lệch (delta) tường minh (những gì đã thay đổi
68  và tại sao), chứ không giải thích lại từ đầu.
69
70## Bước 4 — Chạy bộ lọc phản mẫu (anti-pattern) trước khi hiển thị bản nháp
71
72Rà soát đối chiếu với danh sách phản mẫu trong `reference.md`. Bất kỳ điểm nào vi phạm đều là lý do để viết lại câu đó chứ không phải chỉ làm nhẹ
73nó đi: dự đoán giá cả hoặc tuyên bố về vốn hóa thị trường, thông tin năng lực của nhóm/cố vấn không thể kiểm chứng được dùng làm
74luận cứ, các giai đoạn trên lộ trình (roadmap) được trình bày như bằng chứng về tính khả thi, bảng phân bổ tokenomics không nêu rõ
75mục đích cơ học, tuyên bố tính mới lạ mà không nêu tên những giải pháp đã có trước đó, tuyên bố bảo mật không có mô hình mối đe dọa
76đứng đằng sau, thiếu mục hạn chế của hệ thống, dùng các từ ngữ thời thượng (buzzwords) thay thế cho phần mô tả cơ chế hoạt động.
77
78## Bước 5 — Tự kiểm tra và công bố các khoảng trống thông tin
79
80Trước khi hoàn tất:
81
82- Xác nhận mọi tuyên bố về con số hoặc kỹ thuật đều truy nguyên được về thông tin do người dùng cung cấp hoặc một nguồn bên ngoài
83  có trích dẫn — gắn cờ bất kỳ chi tiết nào do bạn tự suy luận thay vì được cung cấp trực tiếp.
84- Xác nhận mục hạn chế/rủi ro có tồn tại và không bị viết cho có lệ.
85- Chạy danh sách kiểm tra trước khi xuất bản trong `reference.md` và thông báo kết quả (đạt/không đạt cho từng mục, hoặc điểm
86  tự đánh giá) cho người dùng trước khi tuyên bố bản nháp đã hoàn thành — không bàn giao một bản sách trắng mà không làm nổi bật
87  những vấn đề còn chưa được giải quyết.
88
89## Định dạng đầu ra
90
91Định dạng Markdown, các mục khớp với khung sườn nguyên mẫu đã chọn, có phần tóm tắt (abstract) ở đầu, tài liệu tham khảo/nguồn trích dẫn
92ở cuối nếu có sử dụng tư liệu bên ngoài. Không dùng biểu tượng cảm xúc (emoji), không dùng khung nhãn in đậm cứng nhắc (`Vấn đề:`,
93`Giải pháp:`), không ép buộc tính đối xứng giữa các mục — một ý tưởng đơn giản chỉ cần một mục ngắn, một ý tưởng phức tạp
94sẽ có một mục dài, đúng như cách năm bản sách trắng mẫu mực đã làm.
95
96Trích dẫn mọi thông tin bên ngoài (một nguyên hàm mật mã học, một hạn chế đã biết của đối thủ cạnh tranh, một dữ kiện thị trường)
97ngay trong dòng văn bản bằng ký hiệu ngoặc vuông (ví dụ: `[1]`) trỏ tới danh sách tài liệu tham khảo đánh số ở cuối bài — không bao giờ
98khẳng định một dữ kiện bên ngoài mà không có nguồn gốc có thể truy vết. Xem `reference.md` → Calibration examples để biết một
99câu văn đạt chuẩn so với câu văn không đạt chuẩn trông như thế nào trước khi bạn bắt tay vào soạn thảo bản thật.