在上一个发布周期中，我们进行了一系列的更改，这些更改都指向同一个方向：使 BillionVerify 更容易被信任、更容易被监控，也更容易被集成。
其中一些更改在产品中立即可见。批量验证体验在文件提交后更加清晰。验证历史页面在任务仍在运行时变得更加有用。进度指示器现在反映用户真正关心的内容，而不是公开内部队列机制。
其中一些更改更深层次。UI 背后的验证状态合约更加丰富和明确。数据模型现在区分了邮箱级别的进度和后端执行进度，这为客户提供了更好的基础来呈现真实的实时状态。
还有一些更改直接影响开发者。BillionVerify MCP 现已完全摒弃了较早的 ?api_key= 设置方式，转向基于 OAuth、受保护资源发现和现代客户端兼容性的托管远程 MCP 模型。我们更新了产品、文档、营销页面和身份验证界面，以适应这一现实。
本文将这些更新整合到一个叙述中，以便客户、开发者和内部团队可以看到它们如何相适应。
如果你想要简短版本，这里是：
- 批量验证现在具有更清晰的上传后流程。
- 异步任务监控更加信息丰富，也更加诚实。
- 后端状态界面针对分布式工作的结构更好。
- BillionVerify MCP 现在有更清晰的长期形状：远程端点加 OAuth，而不是 URL 嵌入式 API 密钥。
如果你想要完整故事，请继续阅读。
快速链接
为什么这些更新应该在一起
乍一看，这个版本似乎包含几个独立的主题：
- 批量验证页面的前端清理
- 更丰富的历史详情屏幕
- 后端状态契约升级
- MCP 身份验证和文档清理
但所有这些背后的主题都是一样的：消除歧义。
歧义在软件产品中以不同的方式出现。
有时它看起来像文件上传后的重复 UI。用户不确定哪个按钮很重要，最好的下一步在哪里，或者系统是否仍在后台执行工作。
有时它看起来像一个显示"29% 完成"的进度条，而周围的数字没有解释该百分比代表什么。是 29% 的邮件已处理？29% 的工作任务已完成？29% 的结果已合并？大多数用户不想仅为了监控一个作业而解析队列架构。
有时歧义出现在开发者入门中。一个产品可能已经在生产中支持一种架构，而其公开文档的部分仍然建议较早的连接模型。这会导致设置失败、混淆和不必要的不信任。
这个版本是我们对这些问题的回答。
我们围绕用户实际需要了解的内容加强了产品用户体验。我们围绕客户实际需要渲染的内容加强了后端接口。我们围绕平台如今的实际工作方式加强了面向开发者的 MCP 故事。
1. 批量验证现在提供了更清爽的上传后体验
此次发布的第一部分重点关注文件提交后的那一刻。
那一刻的重要性比看起来更大。
当有人上传一个大型 CSV 文件进行验证时，他们还没有完成。他们刚刚从输入状态转移到监控状态。界面必须帮助他们回答几个紧迫的问题：
- 我的文件提交成功了吗？
- 处理已经开始了吗？
- 我在哪里可以监控这个特定的任务？
- 我能否信任系统会在完成时通知我？
之前的流程回答了这些问题，但它通过太多重复来实现。成功卡片、周围的状态文本和可用的按钮都以略微不同的方向吸引注意力。
我们清理了这一点。
页面上的变化
提交成功状态现在更加紧凑，更容易扫描。成功图标和标题占用的垂直空间更少，为用户真正关心的详情腾出更多空间：文件名、邮箱数量、预计处理时间和下一步操作。
提交后，现在默认显示实时进度。用户不再需要采取额外步骤来显示该信息。如果任务在进行，页面应该立即显示该信息。
主要提交后 CTA 也以重要的方式改变了。与其将用户发送到通用历史索引，主要操作现在直接链接到确切的任务详情页面。这听起来像是一个小改变，但它消除了不必要的跳转，使工作流感觉更加深思熟虑。
我们还移除了在技术上可行但没有实际意义的元素：
- 上传区域中的重复状态文本
- 成功卡片中的额外"上传另一个文件"按钮
用户仍然可以从主上传界面上传另一个文件。区别在于界面不再与自己竞争。
为什么这在实践中很重要
批量验证通常用于重复性的操作工作流中。用户可能每天上传多个文件，在一个工作会话中监控多个任务，然后稍后返回下载过滤结果。在这种环境中，即使是小的 UI 重复也会累积。
清理提交后状态在三个方面有帮助：
- 它减少了提交后所需的屏幕解析量。
- 它使下一步显而易见。
- 它使 UI 与用户的心智模型保持一致："我的文件已上传。现在我想跟踪这个任务。"
这是一种改进，虽然自身很难拍出引人注目的截图，但它每天都让产品感觉更加平静和连贯。
示例：新的提交后路径
现在的预期用户旅程是：
- 在批量验证流程中上传一个 CSV 文件。
- 看到带有文件名、行数和 ETA 的即时成功状态。
- 看到实时进度，无需手动显示它。
- 单击一个主要按钮打开该任务的确切历史详情页面。
- 稍后通过电子邮件或历史返回以查看结果和导出。
这是一条比以下更简单的路径：
- 上传文件。
- 解析重复的状态区域。
- 单击进入通用历史。
- 找到正确的行。
- 重新打开目标任务。
在单个会话中付出的努力很少，但在重复使用中非常显著。
2. 验证历史现在表现得像真正的监控平台
第二项重大改进是在异步验证历史页面上。
这个页面过去在功能上是可用的，但很基础。它可以显示一个工作任务存在以及它正在进行中，但还没有感觉像一个为主动监控设计的平台。
这与长时间运行的验证工作不匹配。
当客户在文件仍在处理时打开历史详情页面时，他们不仅仅是在寻找一个百分比数字。他们试图了解：
- 这个工作任务指的是哪个文件
- 工作量有多大
- 已经完成了多少工作
- 早期结果的分布是什么样的
- 工作任务可能需要多长时间
我们围绕这个现实重新设计了页面。
稳定的元数据现在首先出现
更新后的历史页面现在从一个稳定的摘要卡片开始。该卡片汇集了最重要的工作任务元数据：
- 原始文件名称
- 总行数
- 唯一邮箱数量
- 估计处理时间
- 开始时间
这些信息不依赖于实时轮询循环。这很重要，因为稳定的上下文应该尽可能快地出现，即使动态状态负载仍在解决或更新。
当用户登陆页面时，他们可以立即定位自己，而不需要等待实时状态响应来完成所有工作。
实时进度区域要丰富得多
在摘要下方，运行状态体验现在显著改善了。
与其说是一个带有有限上下文的简单进度条，页面现在展示：
- 已处理数量
- 剩余数量
- 各种状态的结果分布
- 与主要批量验证流程相匹配的语言和 ETA 语义
同样重要的是，它删除了应该保持内部的内部指标。我们有意停止在用户面向的平台上公开 worker-task 和 chunk 计数。这些值在操作上可能很有用，但当客户问"我的工作任务进行到哪儿了？"时，这不是他们试图测量的。
正确的问题几乎总是以邮箱为中心，而不是以队列为中心。
完成状态工具保持不变
这项工作的设计约束之一是我们不想失去完成工作任务页面的分析深度。
所以我们保留了现有的结果分布图表和导出工具。更新不是关于替换完成状态体验。它是关于加强页面顶部和使运行状态体验值得这个工作流程。
这意味着页面现在做得更好：
- 在处理过程中，它作为监控平台工作
- 完成后，它仍然作为分析和导出平台工作
示例：用户现在可以快速理解什么
一个运行中的工作任务页面现在可以快速回答所有这些问题：
- "这是我之前上传的 19,293 行文件。"
- "其中有 19,010 个唯一邮箱。"
- "系统估计大约需要 33 分钟。"
- "已经验证了 499 个邮箱。"
- "到目前为止，已完成集合中的大部分是有效的，还有较小的无效和未知部分。"
这是一个比单个百分比数字及其不清楚的语义更有用得多的心理模型。
3. 进度语义现在更诚实了
异步产品中最大的教训之一是"进度"并不是单一的概念。
在分布式系统中，有几个东西可以独立移动：
- 工作任务可以完成
- 块可以合并
- 邮箱级别的结果可以累积
- 最终文件可以变成可下载的
如果客户端只接收一个通用的 progress 字段，它必须猜测这个数字代表的是这些含义中的哪一个。这就是你最终会得到在技术上一致但在体验上令人困惑的 UI 状态的方式。
我们想在合约层面修复这个问题。
核心转变
更新后的接口使得可以区分：
email_progresschunk_progressprogress_source
这种区分为客户端提供了更强有力的基础，用于以与用户意图相匹配的方式呈现进度。
例如：
- 大型用户面向的进度条现在可以优先考虑
email_progress - 运营或诊断视图仍然可以使用
chunk_progress - 如果需要回退，
progress_source可以明确表示
这是一个比假装所有进度百分比意思相同要健康得多的模型。
示例有效负载
这是这种方式启用的形状示例：
{
"task_id": "36f68e67-ddcb-441a-a407-22f826e72443",
"status": "processing",
"total_emails": 19010,
"processed_emails": 499,
"valid_emails": 496,
"invalid_emails": 2,
"unknown_emails": 1,
"catchall_emails": 0,
"risky_emails": 0,
"role_emails": 0,
"disposable_emails": 0,
"email_progress": 3,
"chunk_progress": 7,
"progress_source": "email_progress"
}
即使不了解底层队列系统的任何信息，客户端也可以从此响应做出良好决策。
这很重要，因为 API 不仅返回数据。它们定义含义。
为什么这对客户更好
客户不关心工作人员是否完成了 96 个内部任务中的 7 个，如果只有 19,010 封邮件中的 499 封实际上已被处理。暴露错误的进度抽象会造成混乱，而不是安心。
通过将主要 UI 转向 email_progress，产品现在反映了用户实际关心的工作单位。
为什么这对前端团队更好
UI 不再需要从单个模糊的百分比字段推断太多信息。
这减少了一整类产品错误：
- 看起来进度过快的进度条
- 落后于主百分比的摘要块
- 尴尬的状态副本，试图向最终用户解释后端实现细节
它还为前端团队提供了一种更清洁的方式来分离稳定的工作元数据和变化的执行数据，这直接导向发布的下一部分。
4. 后端状态契约现已更好地结构化以支持分布式工作
如果没有后端契约的改进，前端的变更将无法很好地协同工作。
我们在这里做出了两个重要的结构性决策。
首先，我们将稳定的元数据与实时状态分离
某些字段在创建作业后基本不会改变，或者根本不会改变：
- 文件名
- 创建时间
- 总行数
- 唯一邮箱数
- 预计处理时间
其他字段本质上是动态的：
- 当前状态
- 已处理邮箱数
- 实时结果组合
- 进度百分比
试图将这两类数据强制通过相同的轮询路径是导致 UI 笨拙的常见原因。前端最终会等待应该立即可用的数据，同时也会比需要的次数更频繁地重新请求稳定数据。
新模型更简洁：
- 稳定的作业元数据被视为元数据
- 实时作业状态被视为状态
写成白话文时听起来很明显，但它在实现质量上产生了有意义的影响。
历史详情页面现在可以快速呈现稳定的摘要信息，仅轮询需要改变的内容，并在作业运行时保持 UI 平稳。
其次，我们扩展了状态负载本身
实时状态接口现在更适合分布式异步处理，因为它提供了迄今为止发生的更丰富的信息。
这包括以下计数器：
- 已处理
- 有效
- 无效
- 未知
- 风险
- 全捕获
- 角色
- 一次性
- 使用的额度
这些值不仅使该接口对于面向用户的进度表面更有用，而且对于自动化和下游工作流也更有用。理解当前结果组合的客户端可以就警报、通知、导出和后处理做出更好的决策。
示例：为什么这不仅仅关乎 UI
想象一个基于 BillionVerify 构建的面向客户的应用程序，想要：
- 在列表运行时显示实时质量分布
- 如果作业产生异常高的无效率，通知用户
- 一旦存在有用的结果集就提供筛选的导出
- 支持支持或运维仪表板，无需工程师检查原始工作线程状态
当后端状态契约足够明确和丰富时，所有这些用例都变得更容易。
这是为什么后端接口工作很重要，即使第一个可见的变化是"进度条看起来更好"。更好的进度条通常是更好契约的症状。
5. MCP 现已完全进入远程 OAuth 时代
此次更新的最后一个重要部分面向开发者，也是该版本中最重要的长期产品修正之一。
BillionVerify MCP 现在以其应有的现代远程客户端形态呈现和文档化：
- 一个托管的远程端点
- 基于 OAuth 的授权
- 受保护资源发现
- 标准 Bearer 令牌访问
端点为：
https://mcp.billionverify.com/mcp
这很重要，因为较旧的设置模式往往会在平台内部已经迁移很久后仍然存在于公开资料中。在我们的情况下，一些文档和营销页面仍然暗示 MCP 可以通过 URL 嵌入 API 密钥和 curl --stdio 包装器连接。
这不再是 BillionVerify MCP 的正确形态。
旧的思维模型
较旧的模式大致如下：
curl --stdio "https://mcp.billionverify.com/mcp?api_key=YOUR_API_KEY"
该模型将多个关注点混合在一个繁琐的设置步骤中：
- 传输
- 身份验证
- 密钥处理
- 本地包装器行为
它还对现代客户端应如何使用托管远程 MCP 服务器发出了错误的信号。
新的思维模型
当前模型更加清晰。
对于 Claude Code，推荐的设置是：
claude mcp add --transport http billionverify https://mcp.billionverify.com/mcp
然后在 Claude Code 中：
/mcp
从那里开始，客户端在浏览器中完成 OAuth 流程。
对于 ChatGPT 和其他兼容的远程 MCP 客户端，正确的起点就是端点本身：
https://mcp.billionverify.com/mcp
客户端发现受保护资源元数据，遵循授权流程，然后使用 Bearer 访问令牌进行经过身份验证的调用。
最重要的区别：MCP 身份验证不是 REST 身份验证
旧文档需要清理的一个原因是 API 密钥在 BillionVerify 中仍然很重要。但它们不再属于 MCP 引导流程。
清晰的分离是：
- REST API 使用 API 密钥
- 远程 MCP 使用 OAuth
这一区别现在在整个产品中更加清晰。
如果开发者使用：
- ChatGPT
- Claude Code
- 其他支持 OAuth 的远程 MCP 客户端
他们应该使用远程 MCP 路径。
如果他们正在构建：
- 后端到后端的自动化
- API 密钥驱动的脚本
- 仅支持本地 stdio 加 API 密钥的客户端
他们应该使用 API 参考和 REST 流程代替。
这不是一个表面上的区别。这是一个产品边界，文档应该明确指出这一点。
6. 公开文档和营销现在与产品相匹配
架构升级只有在公开材料仍然讲述不同故事时，才能解决问题的一部分。
这就是为什么我们将 MCP 文档和营销清理作为同一版本的一部分。
我们更新了：
- 公开的 MCP 页面
- MCP 指南
- Claude Code 指南
- AI 指南入口点
- 多语言文档变体
- 本地化营销 FAQ 副本
目标很简单：对于"我如何连接 BillionVerify MCP？"这个问题，应该有一个清晰的答案。
现在有了。
为什么这对开发者很重要
当公开文档滞后于实现现实时，开发者需要付出三方面的代价：
- 设置失败尝试
- 对平台失去信心
- 额外的支持负担以澄清本应显而易见的问题
通过将公开界面与实际的远程 OAuth 模型相一致，我们减少了不必要的摩擦，防止它变成支持问题。
为什么这对平台定位很重要
MCP 生态系统发展迅速。随着越来越多的团队通过 ChatGPT、Claude Code 和其他 AI 客户端评估工具，首次集成体验的质量变得更加重要。
一个在协议层面看起来现代，但在公开设置指南中看起来过时的产品会在本应建立信任的地方造成犹豫。
这就是为什么我们还加强了登录和同意界面，提供了更清晰的条款、隐私和支持联系可见性。审查者、开发者和企业评估者都受益于明确的信任信号。
7. 此版本的实际前后对比视图
了解此版本的一个有用方法是比较发布前后的用户和开发者体验。
之前
- 可以成功提交批量验证文件，但提交后的状态仍然存在重复的 UI 和不够明显的后续步骤。
- 历史详情页面显示了活动，但还不像一个完整的监控界面。
- 百分比完成度的值可能存在，但没有清楚地告诉用户它代表的是已处理的邮箱还是内部任务完成情况。
- MCP 公开资料仍然部分反映了遗留的
?api_key=设置流程。
之后
- 提交后的体验更简洁、更紧凑、更直接。
- 实时进度默认出现在批量流程中。
- 提交后的主要 CTA 将用户直接引导到确切的作业详情页面。
- 历史详情页面显示稳定的摘要元数据以及更丰富的实时结果可见性。
- 面向用户的进度现在以邮箱级别的进度语义为中心。
- 内部任务计数不再作为面向客户的指标公开。
- 后端状态接口的结构更好地适配实时客户端和分布式作业。
- MCP 公开资料现在一致地反映了远程 OAuth 架构。
这不是单一功能。这是跨工作流的有意义的质量提升。
8. 这对不同的受众意味着什么
对于运营和增长团队
您可以获得更平顺的批量验证工作流程，减少 UI 摩擦，在任务运行时获得更好的可见性，并更清楚地访问您刚刚启动的确切任务。
对于产品和前端团队
您现在拥有更强大的进度语义和更清晰的元数据与实时状态的分离，这使得进度繁重的屏幕更容易构建和更容易解释。
对于后端和平台团队
您拥有更强大的分布式验证状态契约和更清晰的说明不同进度值实际含义的方式。
对于集成 MCP 的开发者
您现在拥有对设置问题的更清晰答案：对于 MCP 客户端使用远程 MCP 加 OAuth，对于 REST API 使用 API 密钥（如果该模型适用）。
9. 从这里开始
如果您想探索更新后的体验或集成路径，请从这里开始：
- 了解更多产品信息：邮箱验证
- 运行更大规模的工作流：批量邮箱验证
- 理解基础知识：什么是邮箱验证？
- 从支持的客户端连接 MCP：MCP 概述
- 深入了解设置：MCP 指南
- 专门设置 Claude Code：Claude Code 指南
- 使用基于 API 密钥的集成：API 参考
总结
这个版本不是关于一个大的闪亮表面。它是关于在歧义蔓延的地方紧化产品。
我们让批量验证流程更清晰。我们让异步监控更有用。我们让进度报告更真实。我们让 MCP 故事与我们实际构建的平台相匹配。
这些改进相互强化。
当 UI 说得少但意思更多时，产品会变得更容易信任。当文档描述真实的架构时，它会变得更容易集成。当体验下的接口承载更清晰的语义时，它会变得更容易发展。
这是我们继续推动 BillionVerify 的方向。
如果你已经在使用 BillionVerify，这些改变应该会让你的日常工作流程感觉更直接、更可预测。
如果你现在正在评估这个平台，这个更新很好地展示了我们如何看待产品质量：用户界面的清晰性在上面，明确的契约在下面，文档与现实相符。