N2 · Crypto Product
在不可逆、要签名、可组合这三个约束下重新学做产品，交出一份连失败路径都能点到的 PRD 与原型。
这条 Track 的对象是产品经理、设计师与想转型的人。
它的全部前提是第 27 章那句话：这不是一个加了区块链的 Web2 产品，这是一个约束完全不同的产品。照抄流程之所以不成立，是因为那些流程的前提不在了。这条 Track 要做的，就是把那三个约束变成你下笔时的默认设置。
这条 Track 适合谁
不看头衔，看你手上正在发生的事。
你做过多年 Web2 产品，第一次接链上需求，发现自己最熟的那套全不管用。 预检、灰度、回滚、客服退款——这些工具在这里要么不存在，要么代价完全不同。你知道哪里不对，但说不清到底缺了什么。
你在链上团队里写 PRD，但每次上线后都会冒出你没写过的失败情况。 用户点了没反应、点了三次、看到成功之后钱没到、签了一个不知道是什么的弹窗。你在事后补文档，永远比问题慢一步。
你在做设计，但你的方案止步于钱包弹窗。 最关键的那一次确认发生在一个你无法控制的界面里，而你的设计稿在那里断掉了。
你想转产品岗，会画原型，但说不清链上产品和一个普通应用的区别在哪。 面试时被问到「这一步失败了怎么办」，答不出具体动作。
有一种情况要提醒：如果你希望这条 Track 教你怎样把链上复杂度全部藏起来，那答案会让你不舒服——藏得掉的部分很有限，剩下的只能翻译，不能隐藏。
前置
Part A 有八章必须读完。它们分成两类：三章是给你世界观的，五章是给你工作方法的。
| 必读章节 | 它在这条 Track 里承担什么 | 缺了它会怎样 |
|---|---|---|
| 第 5 章 · Crypto 到底属于谁 | 私钥、签名与「谁在保管」 | 设计出一个自己没意识到已经变成托管方的功能 |
| 第 6 章 · 一次链上交易发生了什么 | 最终性是一条曲线不是一个瞬间 | 在交易被打包时显示「成功」 |
| 第 9 章 · Smart Contract 改变了什么 | 可组合、可升级与权限 | 把别人接进来当成意外而不是常态 |
| 第 20 章 · Tokenomics | 激励是产品的一部分 | 设计出一个规则奖励了你不想要的行为 |
| 第 23 章 · 链上数据 | 自己取数与口径六问 | 上线后不知道该看哪三个数字 |
| 第 27 章 · Crypto Product 为什么不同 | 这条 Track 的主干：三个约束、六格状态机、失败路径十条、签名四类 | 后面所有内容都没有挂靠点 |
| 第 28 章 · Crypto Growth 的本质 | 留存买不到，前四层才买得到 | 把激励堆到一个接不住人的产品上 |
| 第 30 章 · 如何找到 PMF | 去补贴化之后的四个信号 | 把补贴制造的曲线当成需求证据 |
为什么是这八章。 一份链上 PRD 的每一节都能对应过去：主流程靠第 6、27 章，签名与授权靠第 5、27 章，可组合假设靠第 9 章，激励规则靠第 20、28 章，验收指标靠第 23、30 章。
一个 Lab 必须真的做过：第 27 章的「把一个 DApp 的首次使用流程逐步截图」。尤其是最后那一步——查一遍自己给出去的授权，然后撤销掉。 亲手做过这件事的人，写授权需求时的默认值会和没做过的人完全不同。
你会学什么
十个主题，分成五组。顺序按一个功能从想法到上线的真实过程排。
- 先搞清楚给谁做
- 机制是产品的一部分
- 三个约束下的界面
- 验证与增长
- AI 进入产品
| 分组 | 包含的主题 | 这一组要解决的问题 | 从哪一章接上 |
|---|---|---|---|
| 先搞清楚给谁做 | Market Research、User Research | 这个功能解决谁的什么麻烦，我怎么知道 | 第 25、30 章 |
| 机制是产品的一部分 | Protocol Logic、Tokenomics | 底层规则怎样约束了界面上的每一个选项 | 第 9、20 章 |
| 三个约束下的界面 | Wallet UX、PRD | 不可逆、要签名、可组合之下怎么写需求 | 第 27 章 |
| 验证与增长 | PMF、Growth、Analytics | 上线之后看什么数字，怎样不被补贴骗 | 第 23、28、30 章 |
| AI 进入产品 | AI Product | 哪些环节可以交给模型，边界画在哪 | 第 31、32、34 章 |
这五组里最需要重新学的三件事
机制这一组，是 Web2 产品经理最容易跳过、也最伤人的一组。 在 Web2 里，后端实现细节可以交给工程师；在这里不行——协议的规则就是产品的规则。清算线怎么设、手续费怎么分、参数谁能改、合约能不能升级，这些不是技术选型，它们直接决定了界面上该出现什么、该警告什么、该禁止什么。一个不知道清算怎么触发的产品经理，写不出一个借贷产品的风险提示。
界面这一组的重点，不是把流程做短，是把知情做全。 第 27 章那个「打包成一次签名，同时把授权额度和有效期限死，并在自己界面上翻译成人话」的选项，是这条 Track 的默认姿势：打包可以减少点击，不可以减少知情。 这一组会把六格状态机、十条失败路径、四类签名练成肌肉记忆——写任何涉及交易的需求时，这三张表都要过一遍。
AI 这一组，必须先画边界再谈功能。 产品里引入模型有两类完全不同的用法：解释类（把一段合约调用翻译成人话、把一份文档压成摘要）和执行类（替用户决定做什么、甚至动资金）。前者错了代价是误导，后者错了代价是钱。AI 在 Crypto OS 中的位置那条分级和第 34 章的权限表，在这条 Track 里是需求文档的必填项，不是附录。
第 27 章那张十条表：没有原生代币、余额不足、授权不够、滑点超限、被抢先执行、卡在内存池、合约执行失败、用户主动取消、网络拥堵、链重组。
它在这条 Track 里的地位是每一份 PRD 的强制章节，而不是一个可选的打磨。理由很实际：十条里有七条可以在用户签名之前被拦下来，而「在签名前多做一次检查」是链上产品投入产出比最高的一件事。
有一个已经被验证过的现象：让模型写链上 PRD，它会结构性地漏掉这一节——不是偶尔漏，是它学到的模板里就没有这一节。 所以这张清单必须来自人。
用户为了理解自己正在批准什么而付出的注意力，以及产品为了让他理解而付出的界面空间和步骤。
它和「操作成本」是两个独立的预算，而链上产品最常见的失误是用降低知情成本的方式去降低操作成本：把三次签名打包成一次，却不在自己界面上说清楚这一次包含了什么。
判断一个设计有没有越线，用一个问题：如果用户事后发现自己批准了什么，他会不会觉得被骗了？ 会，就说明省下的那几次点击是从知情里借的。
毕业作品
一份完整 PRD 加可点击原型，覆盖签名、失败与撤销的全部路径。
注意 deliverable 里那三个词——签名、失败、撤销。它们不是「除了主流程之外还要写的部分」，它们就是这份作品被检验的地方。主流程谁都能画。
和毕业项目的区别。 毕业项目的 Technical 方向要求做出一个能被别人点开跑通的系统，它证明的是「这件事能被做出来」。这条 Track 的作品不需要真的实现，但它要求你把所有不美好的路径都设计完——证明的是「你知道这件事在真实世界里会怎样出错」。
验收标准五条：
六个交易状态全部有界面与文案，并写明「成功」出现在哪一状态、判断标准是什么。
构造、待签名、已广播、待确认、已确认、最终，一格不能少。待确认那一格要显示当前确认数与门槛。在确认数不足时显示「成功」的作品，这一条直接不通过。
十条失败路径逐条给出触发条件、用户看到的具体文案、产品的处理动作。
「给出友好提示」不算文案，要写出那句话本身。另外标出哪几条是在签名之前被拦下的——这个数字是这份 PRD 的质量指标。
每一次签名标明类型、额度、有效期，并在自己的界面上有一句人话翻译。
四类签名要分清：转账、授权、消息、离线订单。授权类必须是按需额度加有效期，并且产品里有一个能查看和撤销历史授权的地方。默认无限授权的方案不通过。
原型里失败路径可以被点到，不只是主流程。
至少三条失败路径要能在原型里走通：没有原生代币、用户在钱包里点了取消、交易卡在内存池。只能点通 happy path 的原型，等于没有覆盖这条 Track 要练的东西。
附一页「撤销在这里不存在」的说明，和一页上线后的观测方案。
前一页写清楚：用户会期待哪些撤销、它们在链上为什么不成立、你用什么前置动作替代。后一页写清楚：这个功能上线后看哪三个数字、口径是什么、留存按第几层统计。这两页是把产品能力和研究能力接起来的地方。
怎样判断自己达标了
达标的表现是：对每一次签名，你都能说出它属于四类里的哪一类、额度多少、有效期多久、最坏情况下会损失什么。
不达标的典型表现是：把授权签名和转账签名混为一谈；知道要授权但说不出额度；或者默认了一个无限额度而没有意识到这是一个选择。
第 27 章给过一条硬标准：「用户签下这个名之后，最坏的情况是什么，损失落在谁头上」——这两句话写不出来的功能，不该上线。
达标的表现是：七条左右的量级，而且你能说出每一条是靠什么拦住的——余额预检、额度预检、交易模拟，还是输入框的上限约束。
这一条之所以是核心指标，是因为它同时优化三件事：降低流失、降低损失、降低客服量。 一笔注定失败的交易在签名前被拦下来，用户省下的不只是手续费，还有一次挫败。
不达标的典型表现是把失败处理全部放在事后：交易失败了再弹一个错误提示。这在 Web2 里可以接受，因为那里失败通常免费；在这里失败照样扣费。
达标的表现是：你给的不是活跃地址数，而是第 28 章那四层里的第三或第四层——完成过非激励付费交互的地址，或者活动结束后仍然回来的地址。而且你能说出这个数字怎么取、口径是什么。
不达标的表现是报第一层，或者报一个「使用次数」。这两个数字在任何一次激励活动里都会好看，所以它们不提供信息。
还有一个容易被忽略的指标：首次使用的完成率。 一个功能的失败路径处理得好不好，最直接地体现在这里。
达标的表现是：你能逐条检查自己的产品假设——限流是按地址还是按人、风控规则对批量调用成不成立、数据统计会不会把聚合器算成一个用户、界面侧的前置检查在被绕过时后果是什么。
这一条考的是第三个约束。第 27 章那个案例说得很具体：一个协议上线时假设调用它的是人、通过自己的界面、一次一笔，几个月后被别人接进去，三条假设同时失效。
「如果调用我的是一段代码，这条假设还成立吗」是一句应该写进你自己的 PRD 检查表的话。
没有标准答案，检查这几件事：
- 六个状态的文案是具体的句子，还是「显示加载中」这类描述？
- 十条失败路径里，有没有哪一条的处理动作在链上其实做不到？（最常见的是「自动重试并退还手续费」）
- 授权的额度和有效期，你给了具体取值规则，还是只写了「按需授权」？
- 原型里的失败路径，他点得到吗？
- 你有没有写「这个功能在三个主流钱包里的显示差异要怎么处理」？
- 观测方案里那三个数字，工程师知道该埋在哪吗？
一个很有效的检验：请一个人只读你的 PRD，不问你任何问题，把交易状态机画出来。 他画出来的和你想的不一样，说明缺的那部分正是最容易在上线后变成事故的部分。
常见误区
误区一：把链上产品当成「加了钱包登录的 Web2 产品」。
这是最根本的一个，它会衍生出其他所有问题。表现是：照搬漏斗、照搬灰度、照搬客服流程，然后在每一处不成立的地方打补丁。
它错在把三个约束当成了三个功能差异。它们不是功能，是环境——所有产品决策都在它们划出的空间里做。正确的做法是在动笔之前先过一遍那张对照表：出错可以改吗、服务器能代用户行动吗、我控制我的接口和用户吗。三个答案都是否定的，那么你熟悉的那套流程的前提就都不在了。
误区二：用 Token 和激励去填产品的洞。
表现是：留存不好，那就发积分；转化不好，那就加空投预期。数据会立刻变好看。
它错在第 28 章那条结论上：激励只能买来第一次使用，留存必须靠产品本身。 前四层可以用钱买，第五层买不到。第五层是零的时候，前四层做得越好，断崖就越陡。
正确的做法是顺序问题：先把第五层做到能接住人，再去前四层买人。 对产品岗来说，这意味着你要争取的预算，往往是那些见效慢又不好归因的事——代付第一笔手续费、补上失败路径、把三次签名压成一次。
误区三：原型只画 happy path。
表现是评审会上演示得很顺，上线后客服问题全在演示没覆盖的地方。
它错在一个具体的地方：在链上，不美好的路径不是边缘情况，它们是常态。 手续费不够、授权不足、滑点超限、用户在弹窗前犹豫后取消——这些每天都在发生，而且每一次都对应真实的流失或真实的损失。
正确的做法是把评审的顺序倒过来：先演示三条失败路径，再演示主流程。 这个小改动会立刻暴露出方案里最薄的部分。
误区四：把用户数当成需求证据。
表现是拿着一条上涨的曲线说「用户喜欢这个功能」，而那段时间恰好有激励在跑。
它错在第 30 章讲的那件事：Web2 的每一个 PMF 信号，在这里都可以被补贴伪造。 用户量、留存曲线、自然增长、付费转化，一个都不例外。
正确的做法是永远多做一步去补贴化，然后看四个信号：自费留存、付费意愿、自然来源、留存深度。第四个最难伪造——一个用户愿意把自己的资金在你的合约里放一个星期，比他点一百次按钮更能说明问题。
接下来
先回去做这两件事：第 27 章的截图 Lab（含最后那一步授权体检），以及第 30 章的五次真实对话。前者训练你的默认值，后者训练你不靠猜测立需求。
把毕业项目的 Crypto Research OS 也做一遍。 一个不会自己取数的产品经理，上线之后只能听别人转述发生了什么。研究能力在这条 Track 里不是加分项，是观测方案那一页的前提。
AI 相关的两页要读：AI 在 Crypto OS 中的位置定义了能力分级和安全链路，第 34 章给了权限表的写法。任何一个要让模型碰到资金的产品需求，都从这两页开始写。
可以组合的其他 Track：
| 组合 | 为什么合得来 |
|---|---|
| N3 · Crypto Growth & Operations | 产品负责第五层，增长负责前四层。两边用的是同一张漏斗表，分开做很容易互相甩锅 |
| N1 · Crypto Research & Investment | 观测方案那一页就是研究能力。会自己取数的产品经理，判断竞品时不需要等别人的分析 |
| N5 · Crypto Founder | 创始人要做的第一份文档，就是这条 Track 的毕业作品加一份 Token 必要性论证 |
如果你想把原型真的实现出来，T1 · EVM Engineer 与前端集成相关的 T13、T14 是最近的下一步——很多签名与状态处理的实现细节，在那里才会变得具体。