第 27 章 · Crypto Product 为什么不同于 Web2 Product

一个现实问题

一个做了八年 Web2 产品的人，加入了一个链上团队。

他接到的第一个需求很简单：做一个「一键买入」按钮。用户点一下，把稳定币换成另一种资产。他照着自己最熟的流程做了一遍——加载态、进度条、成功页、失败重试、埋点、A/B 测试入口，一应俱全。

上线两周，客服和数据里冒出来六件事：

1. 有人点了按钮完全没反应。查下来是钱包里没有用来付手续费的原生代币——他有钱买东西，但没钱发起这笔交易。
2. 有人点了三次。第一次点完等了四十秒没动静，以为卡了，又点了两次。三笔交易全部上链，全部成交。
3. 有人在成功页出来之后来问：「我什么时候能取消？」
4. 有人转错了地址，来找客服退款。
5. 有人在钱包里看到一个弹窗，上面是一串十六进制，他点了「确认」。三周后钱没了。查下来，他那次点的是一个无限额度的授权。
6. 有人抱怨：「我看到的价格是 1.02，成交价是 0.97。」 中间发生了什么，界面上什么都没写。

六件事在 Web2 里都有标准解法：预检余额、按钮防抖、撤单接口、客服退款、权限弹窗写人话、价格锁定。这里一个都不成立。

不是因为这个人不够好，而是因为他熟悉的那套流程建立在三个前提上，而这三个前提在链上全部不成立。

这一章要解决的问题是：这三个前提分别是什么，它们不成立之后，产品设计要改哪些地方。

思想实验

不要一次性想 Crypto。一次拿掉一个前提，看产品会变成什么样。

第一步：把「撤销」从你的产品里删掉。

不是隐藏这个按钮，是让它在物理上不存在。用户点了确认，事情就发生了，任何人都无法逆转——包括你、包括你的数据库、包括法院。

你会发现很多设计开始塌方：

• 确认页从一个过场变成了主界面。 在可撤销的世界里，确认页是礼貌；在不可撤销的世界里，它是最后一道防线。
• 客服从「解决问题」变成「解释问题」。 你的客服话术库里有一半在讲怎么帮用户补救，这一半全部作废。
• 你不能用线上流量做试错。 Web2 产品经理最依赖的工具之一是小流量灰度：出问题就回滚。这里回滚不了，出问题的那部分用户的钱是真的没了。
• 新手引导必须前置。 不能让用户「先试试看，不对再改」。

第二步：让每一个动作都需要用户掏出一把钥匙，当场签名。

这把钥匙不在你这里，你无法代替他，也无法替他保管。每一次签名，钱包会弹出一个窗口，显示一段他多半看不懂的内容，让他自己决定按不按。

于是又塌了几处：

• 步骤数变成了一个必须被压缩的成本。 在 Web2 里多一步是体验问题，在这里多一次签名是流失点加风险点。
• 你写的文案不一定是用户看到的文案。 弹窗是钱包渲染的，不是你的界面。你只能影响它，不能控制它。
• 「记住我的选择」这个设计变得极度危险。 它在链上对应的是「一次授权，永久有效，额度无限」。

第三步：允许任何人在你不知情的情况下，把别人的产品接到你的产品上。

不需要申请，不需要签合同，不需要你同意。他读你的合约接口，写一段代码调用它，就接上了。

这一步塌得最有意思，因为它同时带来最大的好处和最大的麻烦：

• 分发可以在你不做任何事的情况下发生。 别人把你接进他的产品，他的用户就成了你的用户。
• 你的使用假设会被打破。 你以为用户是一个人，实际来的是一个合约；你以为调用是一笔一笔来的，实际是一次交易里连续来一百笔。
• 你无法单方面改接口。 改了，接在你上面的那些东西会一起坏，而你不知道有谁接了。

三步做完，你手上的已经不是一个「加了区块链的 Web2 产品」，而是一个约束完全不同的产品。

你来决定

现在做一个具体功能：一键复投。用户在你的产品里有一笔收益，点一下，把收益重新投进去。链上要做三件事：领取、授权、存入。

观察结果

四个选项指向同一句话：

链上产品的难点不在功能，在状态与信任的边界被重新划过一次。

Web2 产品的很多默认设计，其实是建立在三个隐含前提上的。把它们和链上现实并排放：

第四行和第五行是两个额外的落差，很容易被漏掉。

第四行：Web2 的请求要么成功要么失败，中间态只是「加载中」。链上的一笔交易可以处于「已签名未广播」「在内存池里等」「被打包了但还没最终确定」「被重排掉了」几种状态，每一种对用户意味着不同的事。

第五行：链上没有免费操作。这意味着「随便试试」这个行为在你的产品里是有价格的，而定价会改变用户的行为：他们会犹豫、会攒着一起做、会在手续费高的时候不来。

建立模型

三个不可协商的约束

第三个约束最容易被当成纯技术问题，它其实是一个产品定位问题。可组合意味着你的产品既可能是别人的入口，也可能是别人的零件。 这两种定位需要完全不同的东西：做入口要好用，做零件要接口稳定、文档清楚、行为可预测。多数团队没想清楚自己要做哪一个，结果两头都不够好。

一笔交易的六种状态

这是产品侧必须内化的状态机。每一格都要有对应的界面和文案，漏掉任何一格，用户就会自己脑补，而他脑补的通常是最坏的那种。

第四格要单独说。在确认数不足时显示「成功」，等于向用户做了一个你无法保证的承诺。 第 1 章讲结算时说过：「显示到账」和「完成结算」经常不是同一个时间点，而这个差值在链上是产品要负责表达的。

失败路径清单

这是这一章最该被抄走的一张表。 任何一个涉及交易的功能，做 PRD 时逐条过一遍：

十条里有七条可以在用户签名之前被拦下来。而「在签名前多做一次检查」是链上产品投入产出比最高的一件事——它同时降低流失、降低损失、降低客服量。

签名的四种类型

用户在钱包里点「确认」时，他可能在做四件完全不同的事。产品要在自己的界面上把它们区分开，因为钱包弹窗未必会区分。

第二类是第 24 章那条「你自己签了名」的风险路径的入口。产品侧有三个具体动作可以把它压到最小：按需授权而不是无限授权、给授权设有效期、在产品里提供一个能看到并撤销历史授权的地方。

第四类最容易被误解，因为它「不花钱、不上链」，看起来像消息签名。但它是一份可以被执行的授权，而且执行的时机不由用户决定。任何让用户签这类内容的功能，都必须在自己的界面上写清楚有效期和作废方式。

它叫什么

动手

这个产品做得好的三件事：
这个产品漏掉的三条失败路径：
如果我来改，第一个要改的是：

AI Lab

请为下面这个功能写一份 PRD 草稿：
<功能描述，例如：用户把持有的 A 资产换成 B 资产，一次完成>

目标链：<链名>。目标用户：<第一次用这类产品的人 / 老手>。

第一部分，主流程。逐步写，每一步标明：
- 用户看到什么
- 这一步是否需要签名，如果需要，属于哪一类（转账 / 授权 / 消息 / 离线订单）
- 如果是授权，额度和有效期分别设成什么，为什么

第二部分，交易状态。按「构造 / 待签名 / 已广播 / 待确认 / 已确认 / 最终」
六个状态，分别写界面显示什么文案、用户可以做什么。
明确写出：在第几个状态才显示「成功」，判断标准是什么。

第三部分，失败路径。逐条写，每条包含触发条件、用户看到什么、产品怎么处理：
没有原生代币 / 余额不足 / 授权额度不足 / 滑点超限 / 被抢先执行 /
卡在内存池 / 合约执行失败 / 用户主动取消 / 网络拥堵 / 链重组

第四部分，单独列出你不确定的地方。

规则：
- 不要写任何「撤销」「回滚」「退款」逻辑，除非你能说清它在链上怎么实现。
- 每一条失败路径都要有具体的界面文案，不要写「给出友好提示」。

真实案例

改一个变量

带走的问题

本章自测