코인 백서 작성법: 구조와 검토 가이드

암호화폐 백서는 독자가 무엇을 결정하는 데 도움을 줘야 하나요?

암호화폐 백서는 의도된 독자가 프로젝트를 이해하고, 주장을 평가하며, 불확실한 부분을 식별할 수 있도록 해야 합니다. 초안을 작성하기 전에 그 역할을 정의하세요. 그렇지 않으면 문서가 제품 개요, 기술 사양, 자금 조달 제안 및 사용자 가이드를 혼합하여 어느 하나도 제대로 제공하지 못할 수 있습니다.

1. 주요 독자를 지정하세요: 사용자, 개발자, 생태계 파트너 또는 토큰 참여자.
2. 독자의 결정을 한 문장으로 작성하세요. 예: "이 프로토콜이 트랜잭션을 어떻게 처리하는지 이해할 수 있나요?"
3. 해당 독자가 필요로 하는 증거를 나열하세요. 예: 아키텍처 다이어그램, 수수료 설명 또는 현재 제품 상태 설명.
4. 게시할 준비가 되지 않은 정보를 표시하고 이를 확인할 담당자를 지정하세요.

하나의 주요 청중을 사용하여 깊이와 어휘를 설정하세요. 문서가 다양한 독자를 대상으로 해야 하는 경우 각각에게 명확한 경로를 제공하세요: 먼저 간결한 개요, 그 다음 기술적 또는 경제적 세부 사항. 제품 설명의 공백을 메우기 위해 투자자 언어를 사용하지 마세요. 독자는 존재하는 것, 구축 중인 것, 그리고 단지 고려 중인 것을 구분할 수 있어야 합니다. 증거가 필요한 주장과 홍보 자료를 분리하여 유지하세요.

어떤 구조가 암호화폐 백서를 평가하기 쉽게 만드나요?

유용한 구조는 문제에서 시스템, 증거, 경제학, 그리고 미해결 질문으로 이동합니다. 논리적 순서를 유지하세요: 독자는 설계 선택을 평가하기 전에 프로젝트 맥락이 필요합니다.

이것을 고정된 템플릿이 아닌 작업 개요로 취급하세요. 프로토콜 백서는 더 많은 아키텍처 및 보안 세부 정보가 필요할 수 있습니다. 소비자 제품은 더 명확한 사용자 흐름이 필요할 수 있습니다. 정의는 첫 사용처 근처에 배치하세요. 긴 문서의 경우 목차를 추가하고 "세부 사항"과 같은 일반적인 레이블 대신 주제를 명시하는 제목을 사용하세요. 코인 백서 작성법을 따를 때, 백서와 함께 런칭 자료를 준비하는 경우, 공개 설명이 일관되도록 토큰 런칭 마케팅 체크리스트와 연결하세요.

프로토콜 메커니즘과 토큰 설계를 어떻게 설명하나요?

독자가 접하는 순서대로 시스템을 설명하세요: 입력, 동작, 출력 및 종속성. 그런 다음 해당 시스템에서의 역할이 명확해질 때만 토큰을 설명하세요. 이렇게 하면 토큰 섹션이 추상적인 이점 목록이 되는 것을 방지할 수 있습니다.

1. 프로세스를 시작하는 사용자 또는 계약 동작을 설명하세요.
2. 관련된 구성 요소와 각각의 책임을 식별하세요.
3. 상태가 어떻게 변경되고, 가치가 어떻게 이동하며, 결정이 어떻게 기록되는지 보여주세요.
4. 실패 경로와 관리자 또는 기타 운영자의 역할을 설명하세요.
5. 토큰이 무엇을 가능하게 하는지, 누가 사용할 수 있는지, 어떤 조건이 적용되는지 명시하세요.

다이어그램은 순서나 관계를 보여줄 수 있지만, 서면 설명과 함께 제공하세요. 전문 용어는 한 번 정의한 후 일관되게 사용하세요. 토큰 공급 및 할당의 경우 모든 수치를 표, 산문 및 차트에서 조정하세요. 해당되는 경우 베스팅 또는 해제 조건을 평이한 언어로 설명하세요. 효용과 거버넌스 권한을 분리하고, 프로젝트의 설계와 문서가 해당 진술을 뒷받침하지 않는 한 토큰 보유가 권리를 부여한다고 암시하지 마세요. 공급 언어 및 기록에 대한 집중 점검은 CoinGecko에서 공급 확인 방법을 참조하세요.

어떤 주장과 증거가 문서에 포함되어야 하나요?

독자가 설계를 평가하는 데 도움이 되는 주장을 포함하고, 그 상태를 명확히 하세요. 정확한 백서는 구현된 기능, 테스트된 결과, 계획된 작업 및 가정을 동등하게 확립된 것으로 제시하지 않고 구분합니다.

• 라이브 기능의 경우, 독자가 검사할 수 있는 것(예: 제품 문서 또는 공개 계약 주소)을 식별하세요.
• 테스트 결과의 경우, 범위와 조건을 설명하여 독자가 그것이 무엇을 입증하는지 해석할 수 있도록 하세요.
• 계획된 기능의 경우, 계획됨으로 표시하고 이를 변경할 수 있는 종속성 또는 결정을 명명하세요.
• 비교 주장의 경우, 비교 기준을 명시하고 뒷받침되지 않는 최상급 표현을 피하세요.
• 숫자의 경우, 출처, 확인 날짜 및 확인 책임자를 기록하세요.

초안 작성 중에 주장 등록부를 유지하세요. 주장, 상태, 출처, 소유자 및 승인 상태가 포함된 간단한 테이블은 레이아웃 전에 불일치를 발견합니다. 외부 기술 자료에 대한 인용 또는 직접 참조를 사용하고, 독자가 어떤 진술이 자신의 시스템을 설명하는지 식별할 수 있는지 확인하세요. 단지 문서를 완성해 보이기 위해 시장 추정치나 성과 주장을 추가하지 마세요. 증거를 사용할 수 없는 경우, 알려진 내용을 말하고 검토될 수 있을 때까지 주장을 남겨두세요.

팀은 어떻게 백서를 초안 작성하고 검토해야 하나요?

검증된 프로젝트 자료를 바탕으로 백서를 초안 작성한 다음, 정확성, 이해도 및 일관성을 위해 별도의 패스로 검토하세요. 이는 여러 검토자가 한 번에 모든 문장을 편집하도록 요청하는 것보다 효율적입니다.

1. 킥오프 체크리스트: 제품 요약, 아키텍처 노트, 토큰 문서, 로드맵, 현재 상태 및 승인된 용어를 수집하세요.
2. 개요 검토: 창업자 또는 제품 리더가 산문이 작성되기 전에 청중, 범위 및 섹션 순서를 확인하도록 하세요.
3. 기술 초안: 관련 엔지니어 또는 프로토콜 소유자에게 메커니즘, 종속성 및 시스템 다이어그램을 확인하도록 요청하세요.
4. 편집 패스: 반복을 제거하고, 용어를 정의하며, 각 주장이 현재, 계획 또는 가정으로 명확하게 표시되었는지 확인하세요.
5. 최종 조정: 백서와 런칭 자료 전반에 걸쳐 토큰 세부 정보, 이름, 날짜 및 공개 링크를 비교하세요.

AEOTech에서 편집 검토는 주장 등록부를 사용합니다: 각 실질적인 진술은 최종 카피가 승인되기 전에 출처 또는 명명된 프로젝트 소유자와 연결됩니다. 피드백을 통합할 책임자 한 명을 지정하고, 검토자에게 사실 수정과 스타일 선호도를 별도로 표시하도록 요청하세요. 백서 작성 지원은 프로젝트당 $1,320부터입니다. 범위는 자료 및 검토 요구 사항에 따라 확인됩니다. 전체 초안 작성 브리핑은 백서 및 라이트페이퍼 작성을 참조하세요.

암호화폐 백서에서 어떤 실수를 초기에 잡아야 하나요?

가장 해로운 실수는 프로젝트가 실제로 무엇을 하는지 또는 주장이 뒷받침되는지 파악하기 어렵게 만듭니다. 개요 및 검토 단계에서 잡아내세요. 레이아웃이 수정 속도를 늦추기 전에 말이죠.

• 슬로건으로 시작하기: 광범위한 주장을 사용자 문제와 시스템 응답에 대한 설명으로 대체하세요.
• 설명되지 않은 용어 사용: 해당 용어가 처음 중요해지는 곳에서 정의하세요. 결정에 유용한 세부 정보를 추가하지 않으면 제거하세요.
• 계획과 출시된 기능 혼합: 텍스트에 상태를 표시하고 로드맵 언어를 전체적으로 일관되게 유지하세요.
• 토큰 할당을 자명한 것으로 취급: 카테고리, 조건 및 관련 해제 메커니즘을 명시하세요.
• 설명 없이 다이어그램 사용: 훑어보거나 시각적 자료를 해석할 수 없는 독자를 위해 작동하는 텍스트 설명을 추가하세요.
• 위험을 끝까지 남겨두기: 종속성 및 설계 한계를 해당 주장 근처에서 식별한 다음 명확한 위험 섹션에 수집하세요.

실용적인 편집은 약속, 비교, 기술적 주장 또는 토큰 세부 정보를 포함하는 모든 문장을 강조 표시하는 것입니다. 질문하세요: 누가 이것을 검증할 수 있으며, 뒷받침 자료는 어디에 있습니까? 답변이 불명확하면 문장을 수정하고, 출처를 추가하거나 제거하세요. 권위를 나타내기 위해 문서를 부풀리지 마세요. 완전성은 독자가 이해해야 하는 결정을 다루는 것을 의미하며, 길이를 최대화하는 것이 아닙니다.

암호화폐 백서를 게시하기 전에 무엇을 확인해야 하나요?

게시 전에 백서가 내부적으로 일관되고, 비공개 맥락 없이 읽을 수 있으며, 프로젝트의 현재 공개 자료와 일치하는지 확인하세요. 최종 검토는 팀이 작성한 방식이 아닌 독자가 사용할 방식으로 문서를 테스트해야 합니다.

• 새로운 독자가 개요를 읽은 후 제품과 의도된 사용자를 요약할 수 있습니까?
• 다이어그램, 토큰 테이블 및 산문이 동일한 시스템과 수치를 설명합니까?
• 현재 기능, 계획된 작업, 가정 및 종속성을 구분할 수 있습니까?
• 링크가 작동하고, 참조가 출처를 식별하며, 정의된 용어가 일관되게 유지됩니까?
• 프로젝트 소유자가 기술 설명과 최신 토큰 세부 정보를 승인했습니까?

백서는 코드 검토나 법적 조언을 대체할 수 없습니다. 출시된 기능, 토큰 권리 및 규정 준수에 대한 주장은 책임 있는 전문가가 확인해야 합니다. 우리는 가정을 명확히 할 수 있지만, 프로젝트 소유자와 자격을 갖춘 고문만이 이를 검증할 수 있습니다.

관련 투자자 대상 문서의 경우, 암호화폐 피치덱 가이드와 범위를 비교하세요. 백서 검토를 시작하려면 현재 개요, 소스 문서, 토큰 자료 및 기술 승인 책임자를 백서 작성 팀으로 보내주세요. 자료를 섹션 계획에 매핑하고 초안 작성 전에 확인이 필요한 사항을 식별하겠습니다.

가격

USD 기준 시작 가격입니다. 맞춤 번들 및 볼륨 할인은 요청 시 제공됩니다. USDT, USDC, BTC, ETH, SOL, TON 또는 프로젝트 토큰으로 결제 가능합니다.

이용 방법

1. 독자와 목적 설정주요 청중과 문서가 지원해야 할 결정을 지정하세요. 해당 독자가 프로젝트를 평가하는 데 필요한 자료를 수집하세요.
2. 섹션 개요 생성문제와 제품부터 시스템, 토큰 설계, 상태 및 위험까지 섹션을 정렬하세요. 프로젝트 소유자와 개요를 확인하세요.
3. 검증된 출처에서 초안 작성프로젝트 문서와 명명된 소유자를 사용하여 기술, 경제 및 로드맵 주장을 뒷받침하세요. 계획과 가정을 명확히 표시하세요.
4. 주장과 명확성 검토별도의 기술 및 편집 패스를 실행하세요. 주장 등록부, 다이어그램, 토큰 설명 및 용어를 조정하세요.
5. 게시용 카피 승인링크, 참조, 일관성 및 최종 승인의 소유권을 확인하세요. 책임 있는 검토자가 콘텐츠를 확인한 후에만 게시하세요.