加密白皮书撰写者

为什么需要这项技能

大多数 AI 生成的加密白皮书读起来像营销演示文稿：含糊的“革命性”措辞、 没有依据的安全声明、用路线图代替证明、把代币经济学当作装饰。业内被引用最多的 五份白皮书——Bitcoin、Ethereum、Uniswap、Chainlink、MakerDAO——共享的却是一种 不同的准则：问题优先的框架、逐步构建的机制、具名的威胁模型，以及针对每个参与者的 激励分析。这项技能将这一准则编码下来，使输出读起来像工程，而不是推销。

完整的研究基础见 reference.md：原型骨架、技艺原则、反模式， 以及发布前检查清单。起草前请先阅读它。

第 1 步——在写下任何一个字之前先收集输入

在从用户处获得以下内容之前，不要开始起草：

• 本项目要解决的问题，用一句话说明，并给出一个具体的场景，说明没有它会出什么故障。
• 项目原型——与 reference.md → 原型 中最接近的匹配项：基础层 共识/结算、DeFi 机制（AMM/借贷/衍生品）、预言机/协调网络、 稳定币/抵押系统，或应用层协议/代币系统。
• 核心机制——链上/链下实际发生了什么，细节要足以描述一个 状态转换或公式，而不只是一份功能清单。
• 代币是否存在及其角色——如果存在代币，它承担什么具体的机制功能 （费用支付、抵押、质押/罚没、治理权重）？如果项目不需要 代币，就明确说明，而不是为了显得完整而编造代币经济学。
• 已知局限 / 未决风险，即团队愿意诚实陈述的内容。 如果其中任何一项缺失或含糊，先提问再起草——绝不为了填补空白而编造问题陈述、团队背景、采用数据或代币模型。

第 2 步——选择章节骨架，校准篇幅

将原型与 reference.md 中的骨架相匹配。不要强行让每份白皮书套用同一个模板——Bitcoin 没有代币经济学章节；MakerDAO 没有工作量证明安全性证明。使用共享的主干（问题 → 机制 → 参与者/激励分析 → 威胁/风险模型 → 架构 → [治理/代币，仅在适用时] → 局限性 → 结论），并删去任何不适用于本项目的内容。

篇幅取决于机制的复杂程度，而非固定的页数——Bitcoin 用 9 页就证明了它的观点；MakerDAO 需要多得多，因为它协调更多的参与者和故障模式。让每个章节按需展开，不多写一个字（反模式：强行对称）。如果项目有代币或做出任何暗示财务/回报的声明，加入一段简短的免责声明（Uniswap 的先例），说明本文档不构成投资建议。

第 3 步——逐节起草，应用技艺原则

在撰写每个章节时，逐一落实 reference.md 中的技艺原则。实践中最重要的几条：

• 以失败场景开篇，而非使命宣言。
• 从最小模型向上构建机制——不要冷冰冰地直接陈述最终设计。
• 每一项安全性或性能声明都要有数字、阈值或具名证明——绝不只用形容词（“高度安全”不是一项声明）。
• 每一个受激励驱动的参与者（矿工、LP、预言机节点、keeper、验证者）都要有独立段落，明确指出他们赚取什么、什么会惩罚背叛行为。
• 点名具体的攻击向量，并为每一个配上其具体的应对措施。
• 至少包含一个可推演、可追溯的示例——一笔交易的完整走查、一次数值计算、一个分步生命周期。
• 如果该设计修订或扩展了已知的前身，将其写成明确的差异说明（改变了什么以及为什么），而不是从头重新解释。

第 4 步 — 在展示草稿前运行反模式过滤器

对照 reference.md 的反模式清单进行扫描。任何命中都意味着要重写该行，而不是软化它：价格预测或市值断言、把无法核实的团队/顾问资历当作论据、把路线图阶段当作可行性证明、没有说明机械用途的代币经济表、声称新颖却不指明此前已有何物、没有威胁模型支撑的安全声明、缺失的局限性章节、用流行词代替机制描述。

第 5 步 — 自查并披露缺口

在定稿之前：

• 确认每一项数值或技术性断言都可追溯到用户提供的内容或引用的外部来源——凡是推断而来而非被告知的内容，都要标记出来。
• 确认存在局限性/风险章节，且并非空洞无物。
• 运行 reference.md 的发布前检查清单，并在宣布草稿完成之前向用户说明结果（逐项通过/未通过，或给出自评分）——不要在未披露未解决问题的情况下就交付一份白皮书。

输出格式

Markdown，各章节与所选原型的骨架相匹配，顶部有摘要，若使用了外部材料则在底部列出参考文献/来源。不使用 emoji，不使用加粗的标签式脚手架（Problem:、Solution:），不强行让各章节对称——简单的想法配简短的章节，困难的想法配冗长的章节，正如那五篇参考论文所做的那样。

对每一项外部断言（某个密码学原语、某个竞争对手的已知局限、某个市场事实）都要以内联的方括号标记（例如 [1]）引用，并在末尾解析到编号的参考文献列表——绝不断言一个没有可追溯来源的外部事实。在你起草真正的内容之前，先看 reference.md → 校准示例，了解合规与不合规的句子分别是什么样子。

Crypto Whitepaper Writer

Why this skill exists

Most AI-generated crypto whitepapers read like marketing decks: vague "revolutionary" language, unbacked security claims, a roadmap standing in for proof, tokenomics as decoration. The five most-cited whitepapers in the industry — Bitcoin, Ethereum, Uniswap, Chainlink, MakerDAO — share a different discipline instead: problem-first framing, incremental mechanism-building, named threat models, and per-actor incentive analysis. This skill encodes that discipline so the output reads like engineering, not a pitch.

See reference.md for the full research base: archetype skeletons, craft principles, anti-patterns, and the pre-publish checklist. Read it before drafting.

Step 1 — Gather inputs before writing a word

Do not start drafting until you have, from the user:

• The problem this project solves, in one sentence, with a concrete scenario of what fails without it.
• The project archetype — the closest match in reference.md → Archetypes: base-layer consensus/settlement, DeFi mechanism (AMM/lending/derivatives), oracle/coordination network, stablecoin/collateral system, or application-layer protocol/token system.
• The core mechanism — what actually happens on-chain/off-chain, in enough detail to describe a state transition or formula, not just a feature list.
• Token existence and role — if a token exists, what specific mechanical function does it serve (fee payment, collateral, staking/slashing, governance weight)? If the project doesn't need a token, say so explicitly rather than inventing tokenomics to look complete.
• Known limitations / open risks the team is willing to state honestly.

If any of these is missing or vague, ask before drafting — never fabricate a problem statement, team background, adoption numbers, or token model to fill a gap.

Step 2 — Pick the section skeleton, calibrate length

Match the archetype to its skeleton in reference.md. Don't force every whitepaper through an identical template — Bitcoin has no tokenomics section; MakerDAO has no proof-of-work security proof. Use the shared spine (problem → mechanism → actor/incentive analysis → threat/risk model → architecture → [governance/token, only if applicable] → limitations → conclusion), and cut whatever doesn't apply to this project.

Length follows mechanism complexity, not a fixed page count — Bitcoin proves its point in 9 pages; MakerDAO needs far more because it coordinates more actors and failure modes. Let each section run as long as the idea needs and no longer (anti-pattern: forced symmetry). If the project has a token or makes any financial/return-implying claim, include a short disclaimer (Uniswap's precedent) stating the document is not investment advice.

Step 3 — Draft section by section, applying the craft principles

Work through reference.md's craft principles as each section gets written. The ones that matter most in practice:

• Open with a failure scenario, not a mission statement.
• Build the mechanism from a minimal model upward — don't state the final design cold.
• Every security or performance claim gets a number, threshold, or named proof — never an adjective alone ("highly secure" is not a claim).
• Every incentive-driven actor (miner, LP, oracle node, keeper, validator) gets its own paragraph naming exactly what they earn and what punishes defection.
• Name specific attack vectors and pair each with its specific countermeasure.
• Include at least one worked, traceable example — a transaction walkthrough, a numeric calculation, a step-by-step lifecycle.
• If this design revises or extends a known predecessor, write it as an explicit delta (what changed and why), not a from-scratch re-explanation.

Step 4 — Run the anti-pattern filter before showing a draft

Scan against reference.md's anti-pattern list. Any hit is a reason to rewrite the line, not soften it: price predictions or market-cap claims, unverifiable team/advisor credentials used as an argument, roadmap phases presented as proof of viability, a tokenomics table with no stated mechanical purpose, novelty claimed without naming what came before, a security claim with no threat model behind it, a missing limitations section, buzzwords substituting for a mechanism description.

Step 5 — Self-check and disclose gaps

Before finalizing:

• Confirm every numeric or technical claim traces to something the user provided or a cited external source — flag anything you inferred rather than were told.
• Confirm a limitations/risks section exists and isn't hollow.
• Run reference.md's pre-publish checklist and state the result (pass/fail per item, or a self-rating) to the user before calling the draft done — don't ship a whitepaper without surfacing what's unresolved.

Output format

Markdown, sections matching the chosen archetype skeleton, an abstract at the top, references/sources at the bottom if external material was used. No emoji, no bolded label scaffolding (Problem:, Solution:), no forced symmetry between sections — a simple idea gets a short section, a hard one gets a long one, exactly as the five reference papers do.

Cite every external claim (a cryptographic primitive, a competitor's known limitation, a market fact) inline with a bracketed marker (e.g. [1]) resolving to a numbered reference list at the end — never assert an outside fact with no traceable source. See reference.md → Calibration examples for what a compliant vs. non-compliant sentence looks like before you draft the real thing.