Kibana 仪表板 API 中的向后兼容性意味着什么

在技术预览期间，API 结构可能会随版本发生变化。[1]现在已不再如此。正式发布 (GA) 意味着：

• 完全向后兼容。新字段和面板类型将陆续添加，但现有字段和行为保持不变。未来如需引入任何破坏性变更，都会经过慎重评估，并且只会在新的 Elastic Stack 主版本中引入。

• 可用于生产环境，并提供全面支持。该 API 享有 Elastic 提供的全面支持保障。您可以放心地在生产环境中使用该 API，进行自动化部署、跨环境发布以及以编程方式管理仪表板。

Kibana 新增用于标签、Markdown 和链接面板的 API 终端

Elastic 9.5 还新增了一个用于标签的独立终端，让您可以对仪表板进行分类和筛选。现在，您可以通过专用 CRUD 终端以编程方式管理这些标签，从而更轻松地跨环境大规模组织仪表板。

新的 Markdown 和链接面板终端现已在 Serverless 中提供，并将在下一个 Elastic Stack 版本 (9.6) 中推出。

Kibana 仪表板 API 支持哪些面板类型？

仪表板 API 支持 9.5 中的所有按值面板（即直接在仪表板中定义的面板，而非保存以供重复使用的库面板）。每种受支持的面板类型都有一个类型化且经过验证的架构。

面板类型

状态

XY 图表

支持

指标

支持

饼图

支持

仪表盘图

支持

热图

支持

数据表

支持

树状图

支持

Discover 会话

支持

控件

支持

Markdown

支持

链接

支持

ML 面板

支持

Observability 面板

支持

Maps

即将推出

Vega

即将推出

如何以代码形式管理 Kibana 仪表板

仪表板 API 支持一套完整的以代码形式管理仪表板的工作流：将仪表板导出为简洁、可进行差异比较的 JSON，将其提交到 Git 并作为唯一可信来源，在拉取请求中审查更改，然后将同一定义部署到开发、预发布和生产环境。一旦以代码形式管理仪表板，就应将 Git 作为唯一可信来源：下次部署会覆盖直接在 UI 中所做的更改。

在空间、集群或阶段之间迁移仪表板时，主要挑战在于仪表板会按 ID 引用 Data view、库可视化等对象。由于这些 ID 是自动生成的，且不同环境中的 ID 各不相同，因此从一个环境导出的仪表板可能会引用另一个环境中不存在的对象。有三种方法可以处理这个问题，以下按自动化程度从高到低列出：

• 使用 Terraform。Elastic Stack Terraform 提供程序会跟踪每项资源，并自动映射各环境中的 ID，因此当您将仪表板从开发环境发布到生产环境时，引用可保持一致。

• 定义按值的 Elasticsearch 查询语言 (ES|QL) 面板。构建面板时，可移植性最高的方法是在仪表板中直接使用 ES|QL 定义其可视化。ES|QL 查询会从查询中指定的索引读取数据，因此面板不会包含对 Data view 或库对象的外部引用。这样便可获得一个完全自包含、可移植的仪表板。

• 分配一致的 ID。如果您引用 Data view、库可视化等已保存对象，请使用 PUT (upsert) 并指定 ID 来创建这些对象，而不要使用会自动生成 ID 的 POST。使用易读的 ID（例如 logs-prod），这样更便于在不同环境中重复使用和识别。

有关这些可移植性模式以及完整的以代码形式管理仪表板的工作流的详细介绍，请参阅“以代码形式管理仪表板”文档。

使用 PUT 通过仪表板 API 创建 Kibana 仪表板

下面是一个简单示例：使用 PUT 而非 POST 创建包含指标面板的仪表板，并以仪表板名称 (service-health-overview) 作为自定义 ID。同样的逻辑也适用于创建保存到库中的独立可视化。

Kibana 仪表板 API 路线图：Maps、Vega 和独立终端

我们正在积极扩展 API 的功能范围。下一步将支持 Maps 和 Vega 面板，并为其添加类型化架构。我们还在为 Discover 会话（除了现有的仪表板面板支持之外）、Vega、Maps 和注释构建独立的 CRUD 终端，使其与仪表板生命周期解耦。

有关完整的架构定义，请参阅仪表板 API 文档。对于 Terraform 用户，Elastic Stack Terraform 提供程序支持正式发布 (GA) 的仪表板 API。

注意

1. 核心终端自技术预览以来未发生变化。如果您基于 9.4 构建了集成，这些集成在 9.5 中也可正常运行。仅有两项轻微的破坏性变更，分别影响仪表板列表和时长单位格式，详见此处。

Kibana AI 仪表板创建的新增功能

功能

技术预览版 (9.4)

GA (9.5)

错误处理能力

无法重试失败的 ES|QL 查询

自动重试最多三次，并进行查询检查和调整

ES|QL 生成成本

所有查询均通过主模型路由

分层模型路由，价格最多可降低 5 倍

时间范围

固定默认窗口

基于数据时间分布的自动选择

筛选控件

不支持

自动为相关性最高的字段添加

Vega-Lite 图表

不支持

自然语言创建，包括散点图、箱形图、条件格式、自定义工具提示

图表编辑

不支持

通过自然语言编辑现有的 Vega-Lite 面板

AI 仪表板生成的自动错误恢复

在技术预览版中，代理不会重试失败的 ES|QL 查询。在 9.5 中，它检测查询错误并重试最多三次，检查每个错误并调整查询，然后再放弃。实际上，这消除了大部分空面板问题，并生成首次尝试即可正确渲染的仪表板。

为什么在 Elastic 9.5 中创建 AI 仪表板更便宜？

并非仪表板生成过程中的每一步都需要同等程度的推理。在 9.5 中，ES|QL 生成默认使用较轻量级模型，仅在需要时才回退到主模型。如果您的连接器使用 Anthropic 的 Claude Opus 4.8，这意味着所有面板的 ES|QL 生成成本将降低 5 倍。

根据您的数据自动选择时间范围

仪表板只有在显示正确的数据窗口时才有用。现在，代理会应用改进的逻辑来选择适配查询数据的合理时间范围，除非用户要求特定的时间范围。它会考虑数据的时间分布并进行相应的调整，无论是实时事件的最后一小时，还是趋势分析的过去 90 天，而不是默认使用固定的时间窗口。

AI 生成的仪表板上的自动筛选控件

仪表板创建现在支持控件；也就是说，交互式筛选器允许查看者按字段值缩小仪表板范围，而无需编辑底层查询。生成仪表板时，代理会自动在顶部添加控件，用于筛选最相关的字段。

使用自然语言创建 Vega-Lite 图表：图表类型和默认之外的格式

Vega 和 Vega-Lite 支持 Kibana 中的各种图表类型和自定义功能。使用 9.5，您可以直接用纯语言构建它们，而无需自己编写代码。

散点图、箱形图以及更多 Vega-Lite 图表类型

散点图、箱形图、分面小倍数、气泡图和组成图（类似将直方图与热图结合）等多种图表均由 Vega-Lite 支持。类似“向我显示响应时间与请求大小的散点图，按服务名称着色”这样的提示会生成一个具有正确数据映射的 Vega-Lite 面板。他们使用 Kibana 的默认调色板与仪表板的其余部分融为一体。

标准图表上的条件格式、自定义工具提示和标签

即使对于仪表板中已有的图表类型（如柱形图、折线图或面积图），有时您也需要比默认功能提供的更多控制。Vega-Lite 通过聊天功能填补了这一空白。一些示例包括：

• 条件颜色格式：以不同的颜色标记高于阈值的数据点；例如，当某些指标的峰值超过您的服务级别目标 (SLO) 时，将折线或柱状图中的数据点标记为红色。您可以向代理提出类似的问题：将折线图中所有高于 500 毫秒的点都变成红色。

  

• 自定义标记和标签：向数据点添加表情符号、符号或行内文本标签，使状态指示器一目了然。

  

• 自定义工具提示：使用不属于图表轴的其他指标、上下文或计算值来丰富悬停状态。可以提出类似这样的问题：添加一个工具提示，显示总记录数和每条柱状图的百分比。

  

这也适用于编辑现有的 Vega 图表。如果您的 Vega-Lite 面板需要进行一些调整，例如更改颜色标度、调整坐标轴或切换标记类型，请在聊天中描述更改，而不是深入研究 JSON 代码。

我们如何在 Kibana 中构建自然语言 Vega-Lite 生成

从句子生成 Vega-Lite 图表并不是一次性 向模型请求 JSON 提示。我们构建了一个小型的代理管道，将自然语言意图转化为经过验证、数据支持的图表。

当收到请求时，代理首先确定 Vega-Lite 是否合适。对于 Vega-Lite 请求，它将可视化建立在针对 Elasticsearch 的真实 ES|QL 查询之上，然后使用模型生成 Vega-Lite 代码。在渲染之前，结果会经过一个规范化层，纠正模式并绑定规范查询。它还应用了渲染安全转换。

有几个设计选择使该工作流可靠：

• 类型化工具调用：图表创建是一个结构化的工具调用，而不是将自由格式的 Vega-Lite 粘贴到对话中。

• 受限生成：模型在定义的模式内生成 Vega-Lite 代码，使输出更可预测且易于验证。

• 精选示例：结构模式（如分面、分层标记和热图）可在不复制底层数据的情况下提供指导。

• 执行和验证循环：在图表创作之前执行查询，验证失败会触发 ES|QL 生成的纠正性重试。

尝试在 Kibana 中创建 AI 仪表板和 Vega-Lite 图表

要尝试使用自然语言仪表板创建和 Vega-Lite 图表，请升级到 Elastic 9.5（或开始免费试用），然后在 Kibana 中打开聊天。然后要求它根据您的数据构建仪表板。对于 Vega-Lite，您可以尝试请求创建想要但从未创建过的图表类型，例如散点图或气泡图。如果结果不完全准确，请告诉代理需要修改的内容。它会与您一起迭代。

这需要企业许可证。开始使用。

本文中描述的任何功能或功能性的发布和时间均由 Elastic 自行决定。当前尚未发布的任何功能或功能性可能无法按时提供或根本无法提供。

该智能体可以从零开始构建仪表板，也可以与您已有的内容配合使用。查看仪表板时打开 AI Chat 侧边栏，它就会自动关联当前仪表板。您可以询问某项指标为何激增，按区域对其进行细分，或添加对比面板。您现有的仪表板会成为分析起点，而不只是最终产物。

幕后解析：我们如何在 AI Chat 中构建仪表板

我们通过“技能”让智能体学会特定任务；技能是说明如何处理特定问题的结构化描述。但是，构建仪表板技能意味着要教 LLM 生成有效的 Kibana 仪表板，而旧版 Saved Object API 使这一过程变得非常棘手：JSON 深度嵌套、版本之间存在细微差异，引用关系也很脆弱。我们需要一种全新的方法

专为以编程方式构建仪表板而打造的 API

新的仪表板 API 正是为这种场景而构建的。它没有暴露原始内部状态，而是为每种面板类型提供类型化、验证过的模式。API 负责在干净的外部结构与 Kibana 内部表示之间进行转换，因此代理可以专注于仪表板应包含的内容，而不是如何格式化它。

一个技能、一个工具、多种操作

dashboard-management 技能提供一个 manage_dashboard 工具，该工具接受有序的操作数组。每项操作都是一个独立动作：设置元数据、添加 Markdown 面板、根据自然语言创建基于 ES|QL 的可视化内容、编辑现有面板、将面板分组到可折叠分区，或重新定位网格中的项目。

智能体可以通过一次调用描述整个仪表板：标题、描述、分区，以及其中的每个面板：

操作按顺序执行，因此后面的步骤可以参考前面的步骤并在此基础上进行扩展。这种设计使对话始终集中在意图上，而不是实施细节上。

可视化管道：从自然语言到 ES|QL 再到可视化

当您请求生成仪表板时，智能体会探查您的数据，包括索引、字段映射和类型，然后规划可视化内容并调用 manage_dashboard。

每个面板都会经过各自的流水线：图表类型选择、ES|QL 生成、可视化配置和验证。我们将这一步从主智能体线程中隔离出来；每个面板的可视化构建都需要多次模型调用，如果混入主上下文，就会撑大上下文窗口，并干扰推理过程。

在 manage_dashboard 内部，所有面板会并发构建，然后按顺序重新组装。最终生成的是一个包含内嵌面板的完整仪表板，不会产生孤立的可视化内容，也不会出现同步问题。

为何将可视化创建纳入仪表板工具中

我们最初的方法是使用一个独立的 create_visualization 工具：每个面板调用一次，然后将每个附件移交给仪表板工具处理。这种方法确实可行，但每个可视化内容都需要单独的工具调用、独立的生命周期，以及明确的移交过程。更糟糕的是，在对话中编辑可视化内容并不会同步更新仪表板面板，容易让用户感到困惑。

我们将可视化创建直接纳入 manage_dashboard。同样的并行工作流仍会运行，但面板会直接组装到仪表板结构中，无需中间附件。调用更少，没有同步问题，生命周期也更统一。

独立可视化内容仍然可用；您可以通过附件引用将现有图表添加到仪表板中。但如果要从头开始构建，内联创建是更简洁的路径

面向安全团队

SOC 分析师和检测工程师在调查中途无法承受来回切换到仪表板编辑器的时间成本。借助 AI Chat，您可以按规则类型、主机或 MITRE 战术统计告警量，并在约一分钟内在对话线程中看到结果。随着威胁搜寻推进，您可以在不中断上下文的情况下逐步添加面板，例如进程执行异常、网络连接和时间线对比。

完成后即可保存。该仪表板可作为事件后复盘的参考、下一位分析师的起点，或每周威胁简报的基础，无需重复说明。

阅读这篇博客文章，详细了解安全团队如何使用仪表板创建功能以及近期推出的其他 AI Chat 功能。

面向可观测性和站点可靠性工程师 (SRE)

当服务在凌晨 2 点出现性能下降时，您没有时间从头开始构建仪表板。借助 AI Chat，SRE 可以描述所需指标（按服务划分的 p99 延迟、与部署事件相关的错误率、过去一小时的 Pod 重启次数），并在约一分钟内在调查对话线程中获得完整仪表板。随着排查思路逐渐清晰，智能体可以逐步细化仪表板：添加面板、更改时间窗口，或按区域细分。

保存仪表板后，它会立即在战情室中供所有加入事件处理会议的成员使用，并保持相同的面板和分析框架。事件结束后，它会成为事件后复盘的基础。

未来发展

我们正在推进 token 优化、更丰富的全屏交互、更广泛的面板支持，并持续提升质量。技术预览阶段正是确定开发优先事项的合适时机；如果有任何缺失，请通过顶部菜单中的“提交反馈”图标告知我们。

试用

升级到 Elastic 9.4（或开始试用），以全屏模式打开 AI Chat，并在真实调查场景中试用。您可以让智能体为您正在查看的指标生成图表，然后要求它继续细分。当分析脉络清晰成形后，即可保存并分享：相同的面板，相同的分析框架，无需重复说明。需要企业许可证（开始使用）。本文中描述的任何特性或功能，其发布及发布时间均由 Elastic 自行决定。当前尚未推出的任何特性或功能可能无法按时交付，甚至可能不会交付。

正因如此，我们才构建了只读仪表板。这是您一直在要求的控制权。放心地共享仪表板，无需担心下一个拥有编辑权限的人会更改或破坏仪表板。

注意：只读权限在 Elastic Cloud Serverless 中可用，并且从 9.3 版本开始在 Elastic Cloud Hosted 和 Elastic Self-Managed 中可用。

当“人人皆可编辑”成为障碍时

在 Kibana 中，共享通常意味着空间层级的权限。如果有人可以在某个空间创建仪表板，他们也可以编辑或删除其他人的仪表板。这对协作来说原本是件好事，直到情况变得不妙。一次意外的编辑可能会导致错误的决策、失去信任和大量的清理工作。

我们听说过一些替代方案：“我们在仪表板名称中加上‘只读’，希望用户能注意到”。或者：“我们给它们贴上标签，然后祈祷好运。”希望并不是一种权限模型。您需要一种真正的方法来锁定仪表板，同时又不将所有人拒之门外。

到底出了什么问题

Deb 和 Kevin 都拥有对运营空间中的日志监控仪表板的编辑权限。Kevin 对图表进行了一些更改。当 Deb 回来后，发现数字与她之前提交的不符。她必须追溯哪些地方发生了变化（通常凭记忆），然后进行修正，还要弄清楚有多少份报告发出了错误数据。

只读仪表板：合理的所有权和控制权

只读仪表板可解决此问题，让您能够控制其他用户是否可以编辑该仪表板。共享仪表板时，您可以选择：编辑（默认，与当前相同）或查看。在查看模式下，只有你（和 Kibana 管理员）可以对其进行更改或删除。其他人可以打开它、使用它、信任它，但他们无法对其进行修改。

您将获得的内容

• 仪表板完整性：在查看模式下，该空间内具有编辑权限的其他用户无法修改或删除仪表板。如果他们尝试，会被告知仪表板已锁定。您的图表和逻辑将保持原样。

• 您掌控一切：你是所有者。您随时都可以编辑、完善和更新。以“仅查看”的方式共享并不会将您锁定，而是会锁定其他人看到的版本。

• 灵活的生命周期：您可以随时将仪表板切换回“可编辑”状态。Kibana 管理员仍然可以管理所有仪表板（例如，在仪表板所有者离开的情况下）。因此，不会出现无人管理的情况。

您可以广泛共享最终确定的关键任务仪表板，并确信这些仪表板将保持一致。所有 Elastic 层级和产品（包括 Serverless）均提供此功能。

谁能做什么？

按角色快速参考：

• 仪表板所有者：您创建了它；您拥有完全的编辑权限。

• Kibana 管理员：可以管理所有仪表板。

• 具有空间编辑权限的用户：可以创建和编辑自己的仪表板；但不能编辑或删除仅查看的仪表板。

• 具有空间视图的用户：只能查看（和列出）仪表板。

操作

仪表板所有者

Kibana 管理员

具有空间编辑权限的用户

具有空间视图的用户

列出并查看仪表板

✔

✔

✔

✔

创建新的仪表板

✔

✔

✔

✘

修改/删除可编辑的仪表板

✔

✔

✔

✘

修改/删除只读仪表板

✔

✔

✘

✘

如何启用只读

您可以在保存新仪表板时设置仅查看模式，也可以稍后从共享菜单中设置。

保存新仪表板时

• 创建您的仪表板，然后单击“保存”。

• 在“另存为新仪表板”模态框中，找到“权限”。

• 从“可编辑”更改为“可查看”。

• 单击“保存”。完成。它对其他所有人都是只读的。

对于您已拥有的仪表板

• 打开仪表板。

• 打开“共享仪表板”菜单。

• 在共享模式中，找到“权限”并切换到“可查看”。将立即应用更改；空间中的其他用户将无法再编辑或删除它。

• 您可以将鼠标悬停在“共享”操作上，查看给定仪表板拥有的权限类型。

查看哪些仪表板被锁定

在主仪表板列表中，无法编辑或删除的仪表板有一个禁用选择复选框。这为找出“仅查看”的内容提供了一种简便的方法。

在仪表板中，您还会发现“编辑”操作已禁用，并且会出现一个工具提示，说明仪表板已设置为“仅查看”。

试用

只读仪表板现已推出。创建仪表板，将其切换到“可查看”，然后共享。您的团队将获得单一可信来源，而您则高枕无忧。标题中不再包含“请勿编辑”字样。

我们很想听听您是如何使用只读仪表板的。在我们的社区论坛中分享您的反馈。

变量控件是什么？

如果您以前用过 Kibana 仪表板，您可能知道我们经典的仪表板控件。那些方便的下拉菜单可以显示数据中的数值，让您只需点击几下就能筛选。

可变控件表面上看起来很相似，但却有巧妙的变化：它们并非自动筛选仪表板上的每个面板，而是可以直接插入单个可视化内部的 ES|QL 查询中。

这意味着您可以决定每个控件的适用范围。更妙的是，您可以将它们用于各种创意技巧，例如实时调整时间间隔、切换细分字段，或更改可视化参数。简而言之，它们为您的仪表板提供了真正的交互式体验，使您能够更快、更轻松地获得见解。

变量控件用例

好吧，变量控件听起来很有用，但您实际上能用它们做些什么？下面举例说明它们如何提升仪表盘的功能性：

筛选已选择的可视化内容

想要筛选部分可视化内容，但保留其他内容不变？变量控件功能可以让您做到这一点。选择要响应的面板，并在可视化的 ES|QL 查询中将它们连接起来。

选择不同的时间间隔

让用户可以在“5 分钟”、“1 小时”、“1 天”或任何合理的时间间隔之间切换。构建有预定义时间间隔的变量控件，并将其连接到时间序列查询。

更改函数

与其为每个操作创建多个图表，不如让仪表板用户选择自己想要查看最大值、平均值、不同百分位数或任何其他聚合器。

按不同字段分组

有时，您需要在调查过程中按不同维度对数据进行细分。通过变量控件，您可以定义多个“分组依据”字段，让仪表板用户选择有助于他们发现见解的字段。

如何创建？

创建变量控件的最简单（可能也是最有趣）方法是直接从可视化中的 ES|QL 查询编辑器中创建。只需开始输入查询，使用自动完成菜单，Kibana 就会帮助您创建。

但是如果您更喜欢以变量本身为基础开始创建，也可以前往：添加面板 → 控件 → 变量控件，然后在创建控件后将变量添加到可视化中。

示例 1：具有多值选择的筛选控件

1. 选择由 ES|QL 查询驱动的可视化，并在 WHERE 条件中单击“创建控件”。

2. 您将自动被重定向至变量创建弹出面板，此时“来自查询的值”这一类型已自动选定，并且变量的名称已经预填。请记住，控件的名称必须以“?...”开头，以便在可视化查询中使用。

您通常需要这样的查询来获取字段中的值，并根据仪表板中选择的时间范围进行更新：

3. 保存控件时，您会看到它出现在仪表盘的顶部，可视化查询也会用变量控件名称进行更新。

4. 如果要在控件中添加多值选择，则需要在查询中使用MV_CONTAINS函数，并在步骤 2 创建控件时选择“允许多选”（9.3 及更高版本可用）。

示例 2：时间间隔控制

如果您正在构建时间序列，可轻松地为日期直方图间隔添加一个变量控制：

1. 为时间序列编写 ES|QL 查询时，单击“创建控件”。为时间间隔创建变量时，最好使用 TBUCKET 而非 BUCKET，这样它就可以接受更具可读性的间隔，例如“1 小时”、“1 天”等。我们也会很快推出 TBUCKET 自动选项，以便自动适应时间范围。

2. 确定用于填充下拉菜单选项的时间间隔。

3. 在下拉菜单中选择不同的时间间隔，查看可视化如何变化。

示例 3：函数变量

1. 用“静态值”类型控件构建一个变量，并在下拉菜单的值中添加函数名。为了替换函数，请使用以“??...”开头的变量名。

2. 在 ES|QL 查询中包含变量名称。

示例 4：字段变量

1. 您可以使用“静态值”类型的控件，并填入所需字段的名称。为了让变量名在字段中生效，使用以“??...”开头的变量名非常重要。

2. 在可视化查询中引用想要的变量。

Discover 中的变量控件

变量控件不仅仅是仪表盘的功能，还可以直接在 Discover 的 ES|QL 编辑器中使用。您可以在 Discover 中构建控件，以获得更快的数据探索体验，并将其引入仪表盘，反之亦然。

技术细节

到现在为止，您可能已经注意到变量控件有一些规则，比如它们可以引用查询的哪些部分，以及您需要使用的命名前缀（“?...”用于值，“??...”用于字段或函数）。这是因为变量不仅仅是在客户端进行简单的字符串替换。它们实际上是查询语言本身最重要的因素（在 ES|QL 中称为参数）。

这种设计具有一些很大的优势。首先，Kibana 可以理解每个变量的上下文，这使我们能够自动为您生成并预先填充其配置。它也更加安全：由于该语言严格验证变量输入，因此可以防止恶意注入，并在出现异常时轻松处理错误。此外，它将复杂的验证和错误处理转移到服务器而不是客户端，从而提高了性能和稳定性。关于性能，最佳做法是创建包含快速查询的变量，因为它们在仪表盘之前加载，所以慢速查询会影响整个仪表盘的性能。

当然，这种架构暂时也有一些限制。变量尚不支持用于筛选的“Any”选项，目前也不能与LIKE或 FROM（用于切换数据源）等操作符结合使用。好消息是什么？我们正在着手添加这些功能。

控件的未来发展趋势

我们不会就此止步！我们所关注的一些改进包括：

✨ 在仪表板上随处放置控件的能力

✨ 控件链式连接：意味着一个控件的输出成为下一个控件的输入。

✨ 选择选项更理想，比如变量的“任意”选择

✨ 新控件类型（搜索类型控件和数据源变量）

✨ 以及更多您一直要求的生活质量改进，比如预筛选常规控件

如果您有任何想法或反馈，欢迎向我们提出。