一组具有代表性的 B2B 线索发现情境，展示 AI 如何从典型业务交流中识别值得人工核实的销售机会。
P95 延迟从 280ms 跳到 1.8s：一场事故怎样触发可观测性平台选型？
通过新加坡 API 团队的一段故障讨论，说明延迟、客户影响、证据缺口与上线期限如何共同形成开发者工具采购 Signal。
以下是一个典型场景演示，用于说明产品的判断逻辑，不代表真实客户案例、客户证言、合同、收入结果或转化数据。
01场景描述
02Signal 判断
03可信度与优先级
04人工下一步
判断时关注的线索
- P95 延迟从 280ms 升至 1.8s
- 团队无法跨服务定位瓶颈
- 两个企业客户已经暂停集成测试
- 季度发布前需要统一日志与分布式追踪
本文为典型场景演示，所有团队、指标和业务结果均非真实客户数据。
三条连续消息，比一句“求推荐 APM”更有价值
新加坡一个 API 工程群里，一位平台负责人在 18 分钟内连续发了三条消息：
P95 latency went from 280ms to 1.8s after the last release.
We have logs in three places but still cannot see which service is causing the queue. Two enterprise customers paused integration testing.
We need one tracing and log workflow before our quarterly release. What are teams using for a Kubernetes stack at our volume?
如果只看第一条，这是一次技术事故；第二条暴露了现有工具缺口；第三条才让采购动作和期限浮现出来。三条消息的顺序，比任何一个单独关键词更能说明团队为什么开始选型。
Signal 解剖：从性能指标到预算讨论之前
| 观察到的事实 | 商业意义 |
|---|---|
| P95 从 280ms 升至 1.8s | 问题可量化，不是主观抱怨 |
| 日志分散且无法定位队列 | 现有流程无法完成诊断 |
| 两个企业客户暂停测试 | 故障已经影响收入路径 |
| 季度发布前需统一方案 | 有明确决策时间窗 |
| 主动询问 Kubernetes 方案 | 已进入供应商研究阶段 |
TOP Prospect 可以将这三条跨时间的消息合并成一条 Signal，而不是分别发送三个低上下文提醒。
为什么优先级高，可信度却不能写成 95%
优先级高，是因为客户影响和发布期限都在逼近；可信度仍需核实，因为发言人可能只是做技术调研，预算、采购权限、数据保留和部署方式都未公开。
两种分数必须分开：
- 优先级回答“现在要不要看”。
- 可信度回答“现有证据有多完整”。
它们都不是成交概率。
第一次回复不应是一张功能对比表
真正需要确认的是：
- 延迟发生在哪些路径和地区？
- 现有日志、指标和 Trace ID 能否关联？
- Kubernetes 集群、事件量和保留周期多大？
- 是否允许 SaaS，还是必须私有部署？
- 季度发布前必须完成诊断、PoC 还是生产切换？
建议回复：
The customer impact makes this worth triaging quickly. Before comparing tools, can you trace one affected request across services today, and is the quarterly deadline for a PoC or a production cutover?
本篇要点
开发者工具需求往往不从采购部门开始，而是从一次工程团队无法解释的事故开始。TOP Prospect 将性能异常、工具缺口、客户影响和交付期限连接起来，帮助 APM、日志和技术服务团队在选型讨论刚形成时进入人工核实。
常见问题
技术故障为什么可能代表采购需求？
当现有工具无法定位问题、故障已影响客户，并且团队明确提出评估和时间要求时，事故才可能推动选型。
AI 能判断应该买哪个 APM 吗？
不能。AI 可以整理需求和优先级，最终方案仍需工程团队验证架构、数据量、成本和安全要求。
场景中的指标来自真实客户吗？
不是。所有指标均为典型场景演示数据。