# Microsoft’s New Bing has Changed Online Search in the Last 6 Months, Here’s How

**作者：吉祥法师**

## 核心变革：从链接列表到研究助理

在过去的六个月里，微软的新必应（New Bing）从根本上颠覆了在线搜索的范式。它不再是传统搜索引擎那种仅提供排名链接的“信息目录”，而是进化为一个能够生成合成答案、提供引用来源、并支持多轮对话的“研究助理”。这一转变的实践影响是深远的：用户的提问方式正在改变，内容创作者需要重新思考内容结构，而开发者则需围绕“检索+生成”的新架构设计产品。

新必应的核心变革在于，它能够在搜索界面内直接生成答案，而不是强迫用户点击多个结果自行拼凑信息。这看似只是一个用户界面的微调，但实际上它深刻改变了用户行为：用户点击次数减少，对合成答案的信任度增加，同时对可验证来源的需求也更为迫切。用户不再满足于获得一个链接列表，他们期望获得一个直接、准确且附有证据的答案。

对于用户而言，这意味着你需要学会提出更“像任务”的问题，而不是堆砌关键词。对于开发者而言，你的优化目标不再仅仅是“排名第一”，而是需要同时优化“答案可信度”，这意味着你的内容需要具备高质量的检索友好性、清晰的来源标记，以及易于被引用和归因的结构。

## 新必应的实践工作原理

要理解新必应，可以将其视为两个并行运行的处理流水线：

1.  **检索（Retrieval）**：它利用必应的底层搜索基础设施，找到相关的网络来源。这是获取原始信息的步骤。
2.  **生成（Generation）**：它使用大语言模型（LLM），基于检索到的证据，组合成一个连贯、可读的答案，并以对话方式呈现。

当这个流程运行良好时，你会得到一个逻辑清晰、切题且附有引用的优质答案。当它表现不佳时，你可能会看到过于笼统的陈述、过时的信息，或者一些与特定结论关联不紧密的引用。理解这个基本原理，是有效使用和开发新必应的前提。

## 如何优化使用新必应以获得更优搜索结果

如果你觉得新必应的搜索结果不如传统必应“精准”，问题通常不在于引擎本身，而在于你的提问方式。你需要从“为排名搜索”切换到“为答案搜索”。

### 高效提示模式：获取带引用的答案

以下提示模式能够强制新必应执行“检索、比较和引用”这一系列动作，从而产出高质量的答案。这些模式适用于消费者用户和开发者体验。

- **带约束的比较**：“将方案A与方案B在企业单点登录（SSO）场景下进行比较。优先考虑安全性、管理开销和部署时间。列出各自的优缺点并引用来源。”
- **要求清单输出**：“给出一个从WordPress迁移到Headless架构的检查清单。包括风险、每步预估工作量以及引用。请以表格形式输出。”
- **请求验证步骤**：“从至少3个来源总结关于X的信息，然后展示你将如何验证关于Y的说法。列出你的验证步骤。”
- **限定时间范围**：“关于这个功能，在过去6个月内发生了什么变化？请尽可能引用官方发布说明或更新日志。”

### 快速验证工作流

新必应可以缩短研究时间，但你仍然需要一个验证闭环，特别是针对数字、政策、定价和法律相关的细节。

1.  **扫描“高特异性”声明**：在答案中找出包含具体日期、阈值、精确限制或定价层级的信息。
2.  **检查引用**：点击或检查与这些声明关联的引用来源。
3.  **核实原文**：确认源页面中确实包含该声明，不要依赖二次转述。
4.  **交叉验证**：对于任何可能影响决策的信息，至少再检查一个独立的来源。
5.  **测试边界**：提出一个后续问题来测试答案的极限，例如：“在什么情况下，这个建议会失效？”

这个工作流是纠正“听起来很自信但实际上是错误”的有效解药。当你开发的应用程序依赖于AI生成的摘要时，这也正是你希望用户采取的行动。

## 开发者指南：围绕新搜索体验构建应用

大多数开发团队不应尝试“逆向工程”新必应的内部聊天逻辑。相反，你应该明确自己的构建目标：是链接发现、检索加合成，还是端到端的AI助手？

### 方案A：使用必应网页搜索API（结构化、确定性方法）

如果你需要稳定、可预测的结果，并且可以完全控制结果的呈现方式，那么必应网页搜索API是最直接的选择。你将获得结构化的搜索结果，可以自行排序、过滤和展示。然后，可以选择性地将排名靠前的结果输入到另一个独立的答案生成器中。

**适用场景**：产品搜索、开发者文档搜索、新闻聚合工具，或任何必须一致显示来源的应用。

### 方案B：使用Microsoft Copilot / Azure AI实现对话式用户体验

如果你的产品本质上是对话式的（例如：“回答关于我们文档的问题”或“研究这个主题”），那么你很可能会采用检索增强生成（RAG）架构。实际操作中，你会将搜索/检索步骤与LLM驱动的响应步骤结合起来。即使你做得很好，仍然需要在答案中展示引用或证据片段。用户在看到可审计的答案时，信任度会更高。

### 方案C：优化内容信号（站点地图、结构化数据和索引健康度）

新必应依然依赖于搜索系统能够理解网络内容。如果你的内容难以被爬取、结构混乱或意义模糊，那么被引用为来源的概率就会大大降低。以下是一些值得投入的基础优化工作：

- **准确的站点地图**：当内容发生变化时，及时更新站点地图。
- **相关的Schema标记**：在适当的位置使用FAQPage、Article、Product、HowTo等结构化数据标记。
- **清晰的标题和定义性段落**：使用易于被引用的、明确的标题和段落。
- **稳定的URL**：避免对规范页面进行频繁的重定向。

开发者也可以提供帮助：生成干净的HTML，避免仅在客户端JavaScript中渲染关键内容，并确保服务器返回有意义的元数据（如Open Graph标签和标准meta标签）以供预览。

## 分步实施指南

以下是三种实用的实施路径，它们都旨在保持引用的完整性和用户的信任。

### 指南1：调用必应网页搜索API并渲染结果

此指南假设你已经拥有一个来自Microsoft Azure的必应网页搜索密钥和端点。具体字段名可能因SDK而异，但流程是固定的。

1.  **获取凭证**：创建一个必应网页搜索密钥，并存储在环境变量中，例如 `BING_WEBSEARCH_KEY`。
2.  **构建请求URL**：包含查询参数 `q`（查询词）、`count`（结果数量，例如10）以及可选的 `market`（市场）和 `language`（语言）参数以获得本地化结果。
3.  **发送请求**：使用HTTPS协议，并在请求头中包含 `Ocp-Apim-Subscription-Key` 字段（或使用SDK的等效方法）。
4.  **解析结果**：提取返回结果中的标题、URL、摘要以及任何可用的结构化元数据。
5.  **渲染到UI**：展示一个包含摘要的链接列表；可选地允许用户优化查询。

**常见错误**：只信任摘要（snippets）。始终保留目标URL，以便用户可以验证，也便于你的UI可以展示“为何如此推荐”。

### 指南2：添加带引用的“搜索+答案”用户界面

你可以获得类似新必应的体验，而无需复制其内部架构。关键在于将检索和生成的步骤分离，并将引用附加到每个独立的声明上。

1.  **步骤1 - 检索**：使用用户的查询调用必应网页搜索API，请求5-10个结果（`count=5` 或 `10` 是一个好的起点）。
2.  **步骤2 - 选择证据**：按相关性对结果进行排序，并可选择性地按域名信任度进行过滤（优先选择新闻、官方文档、标准机构等）。
3.  **步骤3 - 生成**：将用户的提示（prompt）加上精炼后的证据包发送给你的答案生成模型。
4.  **步骤4 - 引用**：强制模型通过一个能映射到URL的ID来引用证据项。
5.  **步骤5 - 渲染**：展示答案文本，然后显示一个列出所用所有来源URL的引用面板。

这种设计使得在答案出错时进行调试变得容易得多：你可以检查证据包，而不是猜测模型“记住了”什么。

### 指南3：通过检索优先设计降低幻觉风险

“幻觉”发生在模型在没有证据的情况下自行填补空白。为了减少这种情况，你需要在系统提示和用户界面中采用“检索优先”的契约。

- **约束声明**：指示模型仅陈述在检索来源中存在的事实。
- **使用“未找到”回退**：如果证据不存在，则提出一个澄清性问题，或告知用户无法验证。
- **要求结构化输出**：例如，“提供一个包含声明、证据、来源URL的表格。”
- **限制每轮范围**：将大问题分解为子问题，以提高命中率。例如，不要说“总结整个政策”，而要说“总结取消条款，并引用退款资格的确切行文”。

养成这个习惯，是让新必应变得更可靠的有效方法。

## 边界情况和常见陷阱

新必应的“答案优先”用户界面可能会隐藏一些你通常会在浏览链接列表时注意到的问题。以下是开发者和高级用户最常遇到的边界情况。

### 当必应答案与经典搜索不符时

- **覆盖范围不匹配**：答案可能只综合了少于你预期的来源数量。
- **意图重排序**：对话式查询可能倾向于“最有帮助的叙事”，而不一定是最广泛的信息来源。
- **时间敏感性**：对于快速变化的话题，经典搜索可能优先显示最新结果，而合成答案可能因来源不一致而出现滞后。

**应对策略**：当答案涉及重要决策时，将其视为一个待验证的假设，并通过引用来源进行核实。

### 如何处理付费墙、区域限制或最新内容

- **付费墙**：优先引用公开的摘要或官方文件。
- **区域限制**：在API调用中设置正确的市场和语言参数。
- **最新内容**：在提示（prompt）中要求“官方更新日志来源”，并包含“最后更新日期”。

### 引用不匹配及如何检查

引用通常很有帮助，但它们并不总是无误的。如果你看到一条具体的声明，但其引用的来源并没有明显地包含该声明，你有两个选择：

1.  **提出有针对性的后续问题**：“请引用支持关于X的声明的确切行文。”
2.  **在引用的页面内搜索**：使用页面的搜索功能或在开发者工具中查找与声明对应的关键词。

对于应用开发而言，最佳实践是将引用按句子或要点进行附加，而不是作为整个段落的通用参考。

## 故障排除：当结果出错时

当新必应（或你的必应集成）返回令人失望的结果时，不要只是简单重写查询。使用一个明确的调试清单。

### 查询重写清单

- **指定输出格式**：“给出一个对比表格”比“告诉我关于……”效果好得多。
- **添加约束**：区域、时间范围、版本和受众（例如“针对React开发者”或“针对2026年合规要求”）。
- **要求定义**：先定义X，然后进行比较。这可以减少歧义。
- **拆分请求**：先找到来源A，然后从这些来源中总结B。

### 集成问题检查清单

- **凭证错误**：验证是401还是403响应；如有必要，更换密钥。
- **查询过于宽泛**：使用更少的中止词（stop words），使用更多的独特术语（如产品名称、精确功能名称）。
- **结果太少**：从 `count=10` 开始进行检索；之后可以降采样。
- **错误的市场/语言**：如果目标用户是特定区域的iPhone或iPad用户，请相应设置市场和语言参数。
- **证据格式**：如果内容分块（chunking）不当，生成器可能会遗漏关键事实。

如果你正在构建一个“新必应风格”的答案UI，一个至关重要的步骤是记录你发送给模型的证据列表。这能使故障排查速度得到极大提升。

## 微软新必应与经典必应搜索对比

| 目标 | 经典必应 | 新必应 |
| :--- | :--- | :--- |
| **快速定义** | 通常更快，点击1-2个链接即可 | 通常更快得到一个合成解释 |
| **证据密集型研究** | 很好，因为你可以看到多个来源 | 很好（如果引用准确且你验证了它们） |
| **带约束的比较** | 需要手动从多个页面拼凑信息 | 更擅长在一个答案中构建权衡框架 |
| **调试特定声明** | 搜索声明，然后打开最佳页面 | 请求引用，并检查来源 |

如果你的用户需要可审计性，请设计你的用户界面，使他们能够通过1-2次点击，从答案文本无缝跳转到底层来源。

## 常见问题解答

### 微软的新必应和微软Copilot是一样的吗？

它们在如何提供对话式帮助方面密切相关，但在“表面呈现”和产品包装上有所不同。在实践中，你会在必应体验内部以及微软拥有的其他助手界面中看到类似Copilot的行为。

### 如何让新必应更可靠地引用来源？

明确要求引用，并约束任务。像“引用官方更新日志来源”和“包含一个包含声明、证据、来源URL的表格”这样的提示（prompts）非常有效，因为它们强制检索结果与声明之间对齐。

### 使用新必应会减少出版商的流量吗？

有可能。因为“答案优先”的体验可能会在用户无需点击的情况下满足其信息需求。这就是为什么结构化数据（Schema）、清晰的易于引用的结构以及快速的索引优化如此重要。你的目标应该是成为被引用的来源，而不仅仅是那个被点击的链接。

### 如果开发者觉得引用不一致，应该怎么做？

采用检索优先的设计：将搜索/证据步骤与生成步骤分离，为每个证据项附加ID，并要求模型将声明与这些ID关联起来。同时，记录证据包用于调试。

### 如果不直接使用新必应，我能构建类似的东西吗？

可以。常见的模式是使用必应网页搜索API进行检索，再加上你自己的答案生成层（或使用微软Azure AI的方法）进行合成。用户可以获得两方面的优势：经过排序的证据和可读的叙事。

## 结论

微软的新必应通过将“答案”提升为搜索界面的“一等公民”，并辅以鼓励验证的引用，彻底改变了在线搜索。通过调整你的提问方式、验证高精度声明并构建检索优先的系统，你将能够享受到合成搜索的速度，同时无需牺牲信任。

对于开发者而言，成功的策略非常简单：将搜索结果视为证据，将这些证据附加到你生成的所有陈述中，并设计一个让用户能够快速、轻松审计来源的用户界面。这就是构建一个能够经受住真实世界检验的、新必应式体验的方法。