第 29 章 · Crypto BD 到底在连接什么
BD 的产出是联系人,还是资源网络?
- 练习的能力
- ResearchSystem Thinking
- 动手
- 给一个协议画出它的资源网络图:链、钱包、交易所、做市商、基金会与开发者各在什么位置。
- AI Lab
- 让 AI 起草一封合作提案,你负责补上对方凭什么答应的那一段。
一个现实问题
两个 BD,同一个协议,同一个季度。
第一个人的季度汇报是这样的:新增联系人 400 多个,参加了六场行业会议,谈了 30 多个合作意向,其中 12 个发了联合公告。每一条公告下面都有「战略合作」四个字,配图做得很好看。
第二个人的汇报只有三行:
一个钱包在它的资产页面里加了我们协议的入口
一家做市商在两个交易对上开始持续提供报价
一个被广泛使用的基础设施把我们的数据接口集成了三件事,一个季度。汇报会上,第一个人的材料显然更厚。
半年后回头看:第一个人的 12 份公告,没有一份能对应到任何一条可测量的曲线变化。 用第 23 章的方法去查,公告发布日前后的活跃地址、交易量、资金流入,全部没有可辨识的变化。
第二个人的三件事,每一件都对应一条曲线:钱包入口上线后,来自那个钱包的调用成为新增用户的主要来源之一;做市商进场后,典型交易规模下的滑点下降了一个量级;数据接口被集成后,三个新的产品在不需要沟通的情况下接了进来。
同一个职位,同一段时间,两种完全不同的产出。
所以这一章要问的是:BD 的产出到底是什么?如果不是联系人的数量,那是什么,以及怎样知道它有没有发生?
思想实验
你在一个陌生城市开了一家面包店。开业第一周,你决定给自己列一张「我需要谁」的清单。
你很快会发现,这张清单上的人分成几类,而且每一类想要的东西完全不同:
供货的人。 面粉、黄油、包装。他们要的是稳定的订单量和按时付款。你能给的是可预期的采购,以及「这家店会长期开下去」的判断依据。
帮你卖的人。 外卖平台、隔壁的咖啡馆、写字楼的前台。他们要的是能让自己的客人满意的东西,而且不给自己添麻烦。你能给的是一个稳定的品质和一个不需要他操心的交接流程。
让你被看到的人。 商场把你的招牌放在一楼入口,还是放在地下二层的角落。他要的是入口处的店铺能带来人流,不要砸自己的场子。
借钱给你的人。 他要的是这笔钱能回来。你能给的是一份说得通的账。
教你手艺、给你背书的人。 一个有名的师傅愿意在你这里挂名,他要的是不被这家店拖累名声。
列完你会注意到一件事:你想要的是「合作」,但没有一个人想要「合作」。 他们各自想要一件具体的、和自己的考核有关的事。
于是任何一次谈判都可以写成同一个三行格式:
我要什么: (对我哪条曲线有影响)
我给什么: (对他哪条曲线有影响)
他凭什么答应:(他的考核里,这件事排第几)第三行写不出来的合作,不会发生;即使发生了,也不会被执行。
最后再加一层。假设你和商场谈成了,签了一份「战略合作协议」,双方都发了公告。但商场最终把你放在了地下二层。
公告是真的,合作是假的。 区别在哪里?区别在于有没有一件具体的事被做完了,而且这件事可以被第三方看到。
把面包店换成协议,这套东西一字不改地成立。区别只有一个:在链上,「有没有一件具体的事被做完」这个问题,通常可以被第三方直接验证。
你来决定
一个新协议,只有一个 BD,三个月。四条线,选一条先做。
观察结果
四条线看起来在做不同的事,但它们的产出都可以归进三类:
BD 连接的是流动性、分发与集成,不是通讯录的长度。
| 产出类型 | 它改变什么 | 典型对象 | 怎么验证它真的发生了 |
|---|---|---|---|
| 流动性 | 用户的实际成交体验 | 做市商、流动性提供方、交易场所 | 深度和滑点的变化,可在链上和盘口直接测 |
| 分发 | 有多少人能顺手用上 | 钱包、聚合入口、生态推广位 | 按调用来源拆分的新增用户曲线 |
| 集成 | 别人能不能把你当零件用 | 基础设施、其他协议、开发者 | 有多少外部合约在调用你,调用量多少 |
三类产出有一个共同点,也是这一章最实用的一条:它们全部可以被第三方验证,而且大部分可以在链上验证。
这给了一个判断合作真假的固定方法。任何一次「合作」,过四个问题:
| 检查项 | 问什么 | 答不上来说明什么 |
|---|---|---|
| 链上能不能看到 | 有没有一个合约、一笔交易、一个地址对应这件事 | 可能只是一份公告 |
| 产品里能不能点到 | 打开对方的产品,能不能找到这个入口 | 可能还在路线图里 |
| 文档里有没有 | 对方的官方文档提不提这件事 | 对方未必认为这是一次合作 |
| 有没有一个数字变了 | 哪条曲线、变了多少、什么时候开始 | 这件事对业务没有影响 |
四个问题全部答不上来的合作,行业里有一个不太客气但很准确的说法:公告即交付。
而公告本身不是没有价值的——它对招聘、融资和社群情绪有真实作用。问题只在于把它当成 BD 的产出来考核。它是一次合作的副产品,不是合作本身。
建立模型
资源网络:六类角色
把一个协议周围的资源画成一张图,六类角色各在什么位置:
- 链与生态
- 钱包与入口
- 做市与流动性
- 交易场所
- 基金会与资助方
- 开发者与集成方
逐类展开。这张表是这一章的核心,建议抄进笔记:
| 角色 | 他有什么 | 他要什么 | 你能给什么 | 成交的最小单位 |
|---|---|---|---|---|
| 链与生态 | 用户、开发者、技术支持、推广位 | 生态里有活跃的应用和真实使用量 | 部署在这条链上,带来真实交易 | 一次正式的生态收录 |
| 钱包与入口 | 每天打开的分发位 | 用户资产安全、体验一致、自己的收入 | 稳定的产品、清晰的权限结构、分成 | 一个可点击的入口上线 |
| 做市与流动性 | 资金、报价能力、跨场所的库存 | 可预期的收益与可控的风险 | 费用、借币额度、数据与合约支持 | 一个交易对开始持续报价 |
| 交易场所 | 用户、价格发现、认知扩散 | 有交易量、有真实项目、合规上说得通 | 流动性配合、市场活动、信息披露 | 一个交易对上线 |
| 基金会与资助方 | 资金、技术支持、背书、推广 | 生态繁荣、有可展示的案例 | 一个真实运行的项目和可引用的数据 | 一笔资助到账并公开 |
| 开发者与集成方 | 把你接进别人产品的能力 | 稳定的接口、好的文档、可预测的行为 | 接口、文档、示例、技术支持、有时是分成 | 一个外部合约开始调用你 |
第四列(你能给什么)是大多数 BD 做得最弱的一列。 因为它需要你对自己的产品足够了解——知道自己的深度是多少、权限结构长什么样、接口稳不稳定、数据能不能开放。
这也是为什么这个课程把 BD 放在第五阶段而不是更早:不懂第 15 章的流动性、不懂第 24 章的权限结构、不懂第 26 章的收入分配,第四列就填不出来,而填不出第四列的 BD 只能去谈第一列。
交换模型:三问
任何一次合作,在写第一封邮件之前先回答三个问题:
1. 对方的考核指标是什么?(不是他的愿景,是他年底被问的那个数字)
2. 我能不能直接推动这个指标?(能,说出怎么推动;不能,换一个切入点)
3. 如果不能,这次合作到底是什么?(大概率是公关,那就按公关来做,不要按 BD 来考核)第一问是整个模型的重心,也是最容易被跳过的一问。
六类角色的考核指标差别极大:钱包看的是用户留存和自己的收入,做市商看的是风险调整后的收益,基金会看的是生态里的项目数量和使用量,交易场所看的是交易量和合规风险,而一个集成方的开发者看的可能只是「接你会不会给我添麻烦」。
把同一份材料发给六类角色,是这一行最常见的低效动作。
优先级:按「效果依不依赖市场情绪」排
BD 的资源永远不够,所以顺序很重要。有一个比「先做大的」更好的排序标准:
| 优先级 | 做什么 | 为什么排在这里 |
|---|---|---|
| 第一梯队 | 集成、钱包入口、开发者接入 | 效果持续,不依赖市场情绪,活动结束不会消失 |
| 第二梯队 | 做市、深度、交易场所 | 效果明确,但依赖持续投入,也依赖市场状态 |
| 第三梯队 | 联合公告、联名活动、会议露出 | 效果短暂,而且高度依赖当下的注意力环境 |
这个排序的依据是第 28 章那个漏斗:第一梯队作用在分发层,而且它的效果不会在任何一天结束;第三梯队作用在注意力层,注意力的半衰期以天计。
有一个例外要说清楚:在冷启动期,第二梯队经常是第一梯队的前置条件。 深度不够,钱包不会把你放进入口,集成方也不敢接。所以早期的正确顺序常常是:先把深度做到及格线,再去谈分发。
提案的结构
一封有效的合作提案,四段,控制在一屏之内:
第一段:我们是谁,一句话,带一个可验证的数字
(不是「领先的」,是「过去 30 天有 X 个地址完成了 Y 笔交易,
数据可在某处核对」)
第二段:我们想做的那一件具体的事
(不是「探讨合作可能」,是「在你们的兑换页面里增加我们这条路径」)
第三段:这件事对你的哪个指标有帮助,为什么
(这一段是整封信的核心,也是最常缺失的一段)
第四段:我们已经准备好了什么
(接口文档、审计报告、测试网环境、联系人、时间表)第三段是唯一不能外包给模板的一段。 它需要你真的知道对方在被什么考核,而这件事只能靠研究对方的产品、公开材料和过往的合作来获得。
第四段的作用是降低对方的启动成本。 很多合作不是被拒绝的,是被无限期搁置的——因为对方要做的准备工作太多。把这些工作提前做完,你就从「一个请求」变成了「一个已经准备好的选项」。
它叫什么
两方各自拿出一样东西,换取对方的一样东西,并且有一件具体的事因此被做完了。
定义里的「具体的事」是全部重点。检验方法就是那四个问题:链上能不能看到、产品里能不能点到、文档里有没有、有没有一个数字变了。
四个都答不上来的,是公关,不是合作。这不是贬义——公关有真实价值,只是不该按 BD 的标准来考核它。
在买卖两侧持续报价、靠价差赚钱的专业机构。
它和流动性提供方的区别值得分清:流动性提供方是被动的(把钱放进池子,按公式成交);做市商是主动的(持续调整报价,管理库存和风险)。
和做市商的合作有两类常见结构:按服务收费(付费换取约定的价差和深度承诺),以及借币加认购权(把代币借给对方,对方在约定期内有权按某价格买下)。
第二类必须自己算明白。 它不是免费的服务,成本藏在那个认购权里,而且这个成本随价格上涨而增加。谈这类条款之前,先把「在几种价格情形下,我们各自得到什么」列成一张表。 算不出来就不要签。
代币在一个交易场所开始交易。
它带来的是价格发现和认知扩散,不是产品使用量。这句话要经常提醒自己和团队:一个人在交易所买了你的代币,不等于他用了你的协议。
评估这条线时要把成本列全:相关费用、需要投入的做市资产、持续的运营与信息披露配合。而且很多条款不公开,所以尽可能找已经做过的人问一手情况。
生态方、基金会或协议金库拿出一笔钱,支持某个项目或某件具体的事。
它通常是三样东西的打包:资金、技术支持、背书。后两样常常更值钱。
申请时最有效的做法是把它当成一次交付而不是一次申请:说清楚你要做的那件具体的事、交付物是什么、什么时候交、做完之后对方的生态多了什么可以展示的东西。
它的隐含成本是绑定,而绑定应该是一个被明确做出的选择。
动手
选协议的标准:它上线至少半年,而且发过若干合作公告。 你要做的事情之一就是检验这些公告。
先把六类角色的格子列出来,逐格填。
| 角色 | 具体是谁 | 这件事发生了吗 | 我怎么验证的 |
|---|---|---|---|
| 链与生态 | |||
| 钱包与入口 | |||
| 做市与流动性 | |||
| 交易场所 | |||
| 基金会与资助方 | |||
| 开发者与集成方 |
材料来源按优先级:对方的产品界面 > 对方的官方文档 > 链上记录 > 双方的公告。 注意这个顺序把公告放在了最后。
逐条检验公告。
把这个协议过去半年的合作公告列出来,每一条过那四个问题:
| 公告 | 链上看得到吗 | 产品里点得到吗 | 对方文档提了吗 | 哪个数字变了 |
|---|---|---|---|---|
第二列最容易做也最有效:打开对方的产品,自己找一遍。找不到就是找不到。
统计一下:几条公告四项全中,几条一项都没中。这个比例就是这个协议 BD 工作的真实成色。
查集成:谁在调用这个协议。
这是六格里最能用链上数据回答的一格。
select
tx_from as caller,
count(*) as calls,
count(distinct tx_hash) as txs
from <平台的事件表>
where contract_address = <协议主合约>
and block_time >= now() - interval '30' day
group by 1
order by 2 desc
limit 50把排在前面的调用方地址拿到区块浏览器上查,判断哪些是合约、哪些是个人。合约调用方就是集成方,去查它们属于哪个产品。
这一步经常会发现一件事:贡献了大量调用量的集成方,从来没有出现在任何一份公告里。 反过来,公告里最醒目的那个合作方,调用量可能是零。
查流动性:深度和滑点。
找到这个协议的主要交易对,记录两个数字:池子深度,以及一笔典型规模的交易会产生多少滑点。
多数产品界面会直接显示预估滑点,输入一个数量就能看到。分别试三个量级(小额、中额、大额),记下来。
这三个数字就是这个协议在流动性这一格的真实成绩,比任何一份做市合作公告都准确。
画图。
把协议放在中心,六类角色围在四周。每一条连线上标三样东西:
连线上写: 这一格具体是谁
线的粗细: 这条连接带来的实际量(调用量、深度、用户来源占比)
线的颜色: 已验证 / 只有公告 / 查不到画完之后,看哪几条线是粗的、哪几条是虚的。 一张典型的图会呈现出这样的特征:公告最多的那几条线最细,而最粗的那条线可能从来没被宣传过。
写三条结论。
这个协议目前最强的一类资源连接是:______,依据是 ______
最弱的一类是:______,依据是 ______
如果我是它的 BD,下个季度我会先做:______,因为 ______第三条要给出理由,而理由要落在那张优先级表上:它作用在哪一层,效果依不依赖市场情绪。
这个 Lab 的图可以直接用在两个地方:研究报告里的「生态位置」一节,以及你自己做 BD 时的第一份工作计划。
AI Lab
这个任务的分工和前两章一样清晰:模型写得出结构,写不出对方的动机。
原因很直接——对方的考核指标不在任何公开语料里。 它需要你去读对方的产品、公开材料、过往合作和招聘岗位描述,然后做推断。这件事模型帮不上忙,而它恰好是一封提案里唯一重要的部分。
请起草一封合作提案,四段,总长不超过一屏。
我方:<协议名称,做什么,一个可验证的数据点及其出处>
对方:<对方是谁,属于六类角色里的哪一类>
我想做的具体的事:<一句话,要有交付物>
第一段:我们是谁。一句话,必须带一个可验证的数字和查证位置。
第二段:我们想做的那一件具体的事,包含交付物和时间。
第三段:这件事对你的哪个指标有帮助。
先写出你认为对方的核心考核指标是什么,再说这件事怎么推动它。
如果你不知道对方的考核指标,直接写「我不知道」,不要编。
第四段:我们已经准备好了什么(文档、审计、测试环境、联系人、时间表)。
规则:
- 不要用「领先的」「革命性的」「战略合作」这类词。
- 不要出现我方无法兑现的承诺。
- 不要编造合作先例或数据。任何数字都要标注出处。
- 第三段如果写不出来,明确说明缺什么信息。拿到之后,直接跳到第三段。 这封信的成败全在这一段。
模型在这一段会有三种表现,对应三种不同的动作:
| 它写了什么 | 说明什么 | 你要做什么 |
|---|---|---|
| 「这会为贵方用户带来更多选择」 | 它把我方的好处换了个说法 | 整段重写 |
| 「贵方的考核可能包括 X,本次合作能推动 X」 | 它做了一个推断 | 去验证这个推断对不对 |
| 「我不知道对方的考核指标」 | 它诚实了 | 自己去查,这是本来就该你做的事 |
第三种是最好的结果。 它说明提示词里那条规则起了作用,也说明你接下来该做的事很清楚。
自己补这一段的方法,三步:
- 去读对方的产品。 他们最近上了什么功能?首页上突出的是什么?这些通常直接反映当下的重点。
- 去读对方的公开材料。 博客、治理提案、季度更新。生态方和协议的年度目标常常是公开的。
- 去看对方在招什么人。 这是最被低估的一个信息源——一个团队在招什么人,就是它接下来要做什么。
这类任务上模型有四个高频错误,按危险程度排序:
- 把我方的好处写成对方的好处。 最常见,也最难自己发现,因为那句话读起来完全通顺。检验方法:把「贵方」两个字去掉,看这句话是不是在夸自己。
- 编造合作先例。 「我们已经与多家头部钱包完成集成」这类句子,模型写得毫不犹豫。发出去之后被对方核对到,这次合作就结束了。
- 承诺无法兑现的东西。 分成比例、技术支持的响应时间、数据接口的开放范围——这些必须回到自己团队确认。
- 篇幅失控。 它倾向于写得很完整,而完整在这里是缺点。超过一屏的提案,第三段之后基本不会被读。
进阶做法:让它为同一件事写三个版本,分别面向钱包、做市商和生态基金会。把三份并排放,如果第三段的内容高度相似,那就说明它根本没有在考虑对方是谁——而这正是把同一份材料群发给所有人的那种做法的本质。
AI 说完之后,你必须自己验证
- 第一段那个「可验证的数字」,它给的是真实数据还是占位符?你自己核对过吗
- 第二段是一件具体的事,还是「探讨合作可能性」这类没有交付物的话
- 最关键的一条:第三段它写的是对方的考核指标,还是我方的好处换了个说法
- 它有没有说出对方的具体考核指标是什么?说不出来就不要发这封信
- 它承诺的任何东西(分成、数据、技术支持),我方真的能兑现吗
- 它有没有编造合作先例:「我们已经和某某合作」这类句子必须逐条核对
- 第四段列的准备材料,是不是真的已经准备好了
- 整封信超过一屏了吗?超过的部分通常是在说我们自己
真实案例
一个协议被某个常用钱包放进了内置入口。上线之后,按调用来源拆分新增用户,会看到一个明显的结构变化:来自那个入口的地址成为新增的主要来源之一,而且这个占比在之后的几个月里保持稳定。
和激励活动的曲线对比,差别非常清楚:激励活动的曲线是一个尖峰加一道断崖(第 28 章),而这条曲线是一个台阶。
台阶的意思是:它不会在任何一天结束,除非对方把入口撤掉。
这个案例解释了为什么集成和入口该排在优先级的第一梯队。同样一份预算,买来的注意力会消失,接好的分发不会。
要补一句:这类合作的门槛通常很高,而门槛主要不在关系上,在产品上——对方要为放进入口的东西承担声誉责任,所以它会认真看审计、权限结构和历史事故。BD 在这条线上真正的工作,一半是在自己团队里推动这些事。
一个项目和做市商签了「借币加认购权」结构的协议:项目方把一批代币借给做市商,做市商负责提供报价,并在约定期限内有权按某个价格买下这批代币。
签的时候,项目方关注的是「不用付现金」。但这个结构不是免费的:如果价格涨到认购价之上,做市商会行权,项目方相当于在那个价位卖出了这批代币;如果价格一直很低,做市商不行权,还回代币,项目方付出的是这段时间的流动性成本和可能的市场影响。
问题不在于这个结构本身——它在行业里是常见且合法的安排。 问题在于很多项目方签的时候没有把「在几种价格情形下我们各自得到什么」算一遍。
这个案例的教训很具体:BD 岗位需要看得懂条款的结构。 看不懂的时候,正确的做法是把它变成一张表:列出几个价格区间,逐格填「我方得到什么、对方得到什么」。填不出来就不签——这和第 24 章里「未评估」那三个字是同一个原则。
一个协议的代币在一个新场所上线,公告发出,价格出现波动,社群情绪高涨。
但把链上的深度拉出来看,上线后的几周里,原本在链上的流动性反而变薄了:一部分做市资源被调去支持新场所的盘口,而链上的池子是被动的、没有人主动补。
结果是:交易场所多了一个,但用户在协议里实际交易的体验变差了。
这件事说明的是一个结构问题:流动性是一种有限资源,它在不同场所之间是分配关系,不是叠加关系。 第 18 章讲过「分散在不同场所并不构成分散」,在 BD 语境里它的另一面是:每开一个新场所,都要问一句这些资源从哪来。
所以上所这类合作的正确评估方式,不是看公告当天的价格,是看三十天后链上的深度和滑点。
用链上数据统计一个协议 30 天内的调用来源,把排名前列的合约地址一个个查出来,经常会发现一件事:贡献调用量最大的那几个集成方,从来没有出现在任何一份合作公告里。
原因很简单:他们不需要谈。协议是开放的,他们读文档、写代码、接上去,整个过程不需要和任何人打招呼——第 27 章那第三个约束在这里是一个礼物。
这个现象有两个很实际的含义。
第一,BD 的工作里有一部分不是谈判,是降低接入成本。 文档写清楚、示例给全、接口稳定、有一个能回答问题的地方——这些做好了,集成会自己发生。
第二,你应该定期去查谁在调用你。 那张调用来源表里排在前面而你不认识的名字,是最高质量的 BD 线索:他们已经在用你了,接下来的对话从第二步开始。
改一个变量
一半的谈判筹码消失了:不能用代币做激励、不能用代币和做市商换服务、交易场所那条线整个不存在。
但另一半会变得更清晰,而且这一半更耐用。没有代币的合作只能靠两样东西:你的产品对对方真的有用,或者你能给对方带来真实的量。
这反而是一个筛选器:在这个约束下还能谈成的合作,通常是真实的。 因为对方答应的理由里没有「代币可能会涨」这一项。
实践中这类项目的优先顺序通常是:先做集成和开发者(这两类要的是接口和文档,不是代币),再做生态资助(生态方乐于支持还没发币的项目),最后才考虑流动性那条线。
第 30 章会把这件事讲透:先证明没有 Token 也有人用,再决定要不要发。 在 BD 这一层,它对应的是先把集成和分发做起来。
独家意味着你放弃了一整类的其他合作,换取对方更大的投入。它在一种情况下值得:对方的投入确实需要独家才能收回,而且这个投入足够大。
判断方法有三个问题:独家的范围有多大(是这个品类独家还是全部独家,是这条链上独家还是所有链)、期限多长(三个月和三年是完全不同的两件事)、对方的承诺有没有可验证的交付(「优先推广」不是交付,「在首页某位置展示六个月」是)。
第三个问题最重要。独家是你确定要付出的,而对方的投入常常是模糊的。 这种不对称是独家条款的主要风险。
一个实用的做法:把独家和交付绑定——对方达到某个可验证的指标,独家继续;达不到,自动解除。这把一个信任问题变成了一个条款问题。
这个约束比看起来的小,因为六类角色里有三类基本不依赖人脉。
开发者与集成方:他们要的是文档和接口,把这些做好,集成会自己发生。基金会与资助方:申请流程通常是公开的,评审看的是项目本身。链与生态:早期生态方的考核目标就是「生态里有多少项目」,他们在主动找人。
真正依赖关系和信任积累的是钱包入口、做市商和交易场所这三类,而这三类的前置条件恰好也不是人脉——是你的产品够不够稳、深度够不够、权限结构经不经得起看。
所以一个没有人脉的 BD,第一个季度最好的工作可能根本不是去认识人,而是:把接入文档写好、把第 24 章的十项自查一遍、把链上调用来源表拉出来找到已经在用你的人。 最后那件事尤其被低估。
汇报会立刻变得难看:一个季度可能只有两三行内容,而且其中一行还是「没有变化」。
但三件事会开始改变。目标变得可验证:每一条产出都要附上一条曲线和一个验证方法。优先级自动重排:公告类的工作会自然往后退,因为它在这个考核里得不到分。跨职能的协作变多:因为第一梯队的合作(集成、钱包入口)的前置条件在产品和安全那边,BD 必须去推动它们。
第三点是这个改动最大的收益,也是最少被预见到的。按「合作数量」考核的 BD 会被推向那些不需要内部配合的合作——而那恰好是效果最弱的一类。
代价也要说清楚:这个指标体系在短期内会让 BD 这个岗位看起来产出很低。 撑不撑得过这个阶段,取决于团队是不是真的相信第一梯队的价值。
带走的问题
这一问在这一章有一个具体的查法:去链上看谁在调用你。
调用来源表里排在前面的合约地址,就是你真实的集成方;而其中你不认识的那些名字,是质量最高的 BD 线索——他们已经在用你了,对话可以从第二步开始。 这个动作大多数团队从来没做过。
BD 场景下这一问有一个特别的形式:这次合作里,谁在承担成本?
很多合作看起来双赢,成本藏在不显眼的地方:做市条款里的认购权、上所需要投入的做市资产、生态资助带来的绑定、独家条款放弃的其他机会。把每一项合作的成本明确写出来,是 BD 工作里最有价值的一个习惯。
这一问在这一章从「研究别人」变成了「建设自己」:你的流动性从哪来,提供的人为什么留下。
第 15 章讲过他们承担的是什么风险。BD 的工作是把这个问题变成可谈的条件:费率、激励、以及你能不能把他们的风险降下来。而最重要的一条是记住他们跟着收益走,所以「合作关系好」不构成他们留下的理由。
这一问在 BD 里的形式是:你的合作伙伴的激励是什么?
不是他的愿景,是他年底被问的那个数字。六类角色的考核指标差别极大,把同一份材料发给所有人,本质上是在假设他们的激励相同。而这个假设几乎总是错的。
本章自测
流动性、分发、集成。
- 流动性改变用户的实际成交体验,验证方法是看深度和典型规模下的滑点。
- 分发改变有多少人能顺手用上,验证方法是按调用来源拆分新增用户曲线。
- 集成改变别人能不能把你当零件用,验证方法是查有多少外部合约在调用你、调用量多少。
三类的共同点是都可以被第三方验证,而且大部分可以在链上验证。
由此得到一个判断合作真假的固定方法,四个问题:链上能不能看到、产品里能不能点到、对方文档里有没有、有没有一个数字变了。四个都答不上来的,是公关,不是合作。
公关本身有价值(对招聘、融资、社群情绪都有用),问题只在于把它当成 BD 的产出来考核。
因为它是唯一一段关于对方的内容,其余三段都在说我方。
难写是因为它需要一个不在任何公开语料里的信息:对方的考核指标——不是他的愿景,是他年底被问的那个数字。这件事只能靠研究对方的产品、公开材料和招聘岗位来推断。
三个具体的查法:读对方的产品(最近上了什么功能,首页突出什么)、读对方的公开材料(博客、治理提案、季度更新)、看对方在招什么人(一个团队在招什么人,就是它接下来要做什么)。
有一个简单的自检:把提案第三段里的「贵方」两个字去掉,如果这句话读起来是在夸自己,那这一段就是白写的。
因为它们的效果持续,而且不依赖市场情绪。
用第 28 章的漏斗看:集成和入口作用在分发层,它们的曲线是一个台阶——除非对方撤掉入口,否则不会在任何一天结束。而联合公告作用在注意力层,注意力的半衰期以天计,它的曲线是一个尖峰加一道回落。
排在第二梯队的是做市和交易场所:效果明确,但依赖持续投入,也依赖市场状态。
有一个重要的例外:冷启动期,第二梯队经常是第一梯队的前置条件。 深度不够,钱包不会把你放进入口,集成方也不敢接。所以早期的正确顺序常常是先把深度做到及格线,再去谈分发。
把它变成一张表:列出几个价格区间,逐格填「我方得到什么、对方得到什么」。
这个结构不是免费服务。价格涨到认购价之上,对方会行权,相当于你在那个价位卖出了这批代币;价格一直很低,对方还回代币,你付出的是这段时间的成本和可能的市场影响。
这个结构在行业里常见且合法,问题从来不是它本身,是签的人有没有算过。
填不出这张表就不要签——这和第 24 章那句「查不到就写未评估」是同一个原则:把不懂的东西当成没有风险,是这一行最贵的习惯。
更一般的结论是:BD 岗位需要财务和机制的基本功。 这也是这个课程把 BD 放在第五阶段的原因——前面四个阶段的内容,在这里都是工具。
没有标准答案,检查这几件事:
- 六格你是逐格填的,还是只填了有公告的那几格?
- 每一格的依据,是对方的产品界面、对方的文档、链上记录,还是双方的公告?公告应该排在最后。
- 你有没有真的打开对方的产品去找那个入口?找不到就是找不到。
- 集成那一格,你拉过调用来源表吗?排在前面的地址你查了吗?
- 流动性那一格,你记了深度和三个量级的滑点吗?
- 你逐条检验过它的合作公告吗?四项全中的有几条,一项都没中的有几条?
一个很常见的结果:公告最多的那几条线最细,而最粗的那条线从来没被宣传过。 看到这个不要意外——它说明的是这个协议的真实价值可能在它自己都没意识到的地方。
做完之后再做一件事:把同样的图画给你自己的项目。 如果你现在不在做 BD,画完你会知道该找谁;如果你在做,画完你会知道下个季度的第一件事是什么。
一句话带走
BD 连接的是流动性、分发与集成,不是通讯录的长度。