On-chain 数据需求听起来很明确，直到没人能说清到底要查什么
一套典型 Web3 客户工作流：区分真正的数据 API 项目、研究提问、模糊分析兴趣，以及暂时无法交付的需求。
基准方法框架 · 典型工作流本文记录这一类团队可采用的典型运营方式，不代表具名客户、客户证言、合同、收入结果或已核实转化。
重点监测信号
- 明确应用需要历史、实时、跨链、实体关系或告警数据
- 讨论包含链覆盖、数据新鲜度、延迟、查询形态或交付约束
- 当前数据源不完整、速度慢、不稳定、成本过高或维护困难
- 产品上线、客户承诺、迁移或内部决定形成真实交付里程碑
典型行业案例。 本文用复合工作流说明一种反复出现的 On-chain 数据需求判断模式，不代表真实客户、数据集、合同、商业结果或客户证言。
“需要区块链数据”只是兴趣，还不是项目
对 On-chain 数据服务商来说，群里出现“钱包活动数据”“实时交易”或“多链分析”时，看起来与产品高度匹配。对方有问题，术语也完全正确，很容易被立即转给销售。
但大量讨论仍然停留在研究阶段。团队可能不知道要查询哪些实体、需要多长历史、所谓“实时”究竟是多少秒，也说不清数据会进入哪一个产品决定。缺少这些信息，覆盖范围、延迟、成本和交付风险都无法估算。
一条真正值得核实的线索，需要从宽泛的数据兴趣，走到可以定义的查询，以及依赖这个查询的业务流程。
用“查询到交付缺口”判断需求成熟度
“查询到交付缺口”指的是：对方口头表达的需求，与数据团队稳定交付所需要的信息之间，还隔着多远。
1. 业务问题
数据最终支持什么决定？例如更新产品界面、触发内部告警、调查账户行为、生成客户报告，或衡量某条应用流程。
如果答案不会影响任何决定，这个请求更可能是探索，而不是活跃项目。
2. 查询定义
需要哪些地址、合约、事件、实体、时间范围和关系？“钱包活动”可能指余额、转账、授权、交互、标签、对手方，也可能指一连串事件。
3. 覆盖范围
涉及哪些链、网络、协议、历史周期和数据类型？“多链”不是一个单独需求，每条网络都可能带来不同 Schema、确认逻辑和索引工作。
4. 新鲜度与延迟
“实时”是几秒、几分钟，还是下一个报告周期？可以接受暂定状态，还是必须等待明确确认？
5. 交付与负责人
结果通过 API、Webhook、数据库导出、Dashboard 还是托管 Pipeline 提供？谁维护 Schema、发现缺口、处理重组与重试，并在上游变化时响应？
6. 用途与边界
使用目的是否合法、获得授权，并符合相关平台、隐私和法律要求？技术上能查到，不代表一定适合使用。
讨论填补的缺口越多，它越适合进入人工资格判断。
三种看似相似的消息，处理方式完全不同
学习提问
有人为课程作业寻找显示近期 Token 转账的工具。主题相关，但没有运营流程、负责人或交付里程碑，适合教育或低优先级观察。
产品假设
团队想在 Dashboard 增加钱包活动，但还没决定哪些事件重要。项目可能存在，下一步应该做需求发现，而不是直接报价。
有交付约束的要求
产品团队能够说明网络、历史窗口、新鲜度目标、输出格式、当前故障，以及客户或上线里程碑。它仍然不能证明预算与权限，但已经足够交给技术评估。
三者的区别不在于用了多少 Web3 术语，而在于为真实交付消除了多少不确定性。
哪些内容必须留给人工核实
一段讨论可以支持项目假设，却不能确认：
- 发言者负责数据决定；
- 数据能够按所述目的获得授权和使用；
- 当前数据源确实是瓶颈；
- 所有链都必须在第一版上线；
- 延迟目标在技术和成本上可行；
- 已经存在预算、合同或采购流程。
这些问题应该进入核实记录，而不是被乐观假设悄悄填满。
第一条问题要把数据连接到业务决定
一个有效的开场问题是：
这批数据最终会触发什么产品动作或业务决定？第一版必须覆盖哪条链、什么事件、多久历史和怎样的新鲜度？
答案能够快速区分：对方需要的是学习、需求发现、原型，还是生产级数据服务；也让技术团队有明确依据判断范围是否过早或不在覆盖能力内。
TOP Prospect 在这里负责什么
TOP Prospect 可以从用户主动连接的相关 Telegram 社群中整理讨论，保留上下文，并区分泛泛的数据提及与包含业务问题、当前约束、查询形态和交付里程碑的需求。
它无法替团队验证数据集、测试覆盖、保证准确性、批准用途或确认买方权限。它负责把一句“需要区块链数据”整理成可复核的查询到交付 Brief，或者清楚记录为什么现在还不成熟。
Telegram 采购意向识别指南解释了具体性和时间的重要性；信号源质量评估帮助团队优先关注持续产生有效语境的社群。相关的开发者服务案例还可以参考AI SaaS 自动化项目工作流。