ChatKit Widgets：AI 都能干活了，为什么还要我一直打字

现在很多 AI 助手都能查数据、调接口了，但用起来还是有个烦人的地方：什么都要打字。

让它查一下自动化执行结果，它告诉你失败了 7 条，问要不要看详情。输入“看一下”，它把详情列出来，又问要不要重跑。再输入“重跑一下”。

明明一个按钮就能解决，非要聊上几个来回。

当然可以一次把指令写完整。但人用软件的时候，不会每次都提前想好后面三步要干什么。经常是看到结果，才决定接下来点哪里。

ChatKit Widgets 就可以用在这里：在 AI 的回复里放卡片、列表、按钮，让用户直接操作。

先看一个测试报告

拿一个假设的场景来说。让 AI 查最近一次回归结果，它可以返回这样一张卡片：

回归测试 #20261025-01
共 128 条，通过 121 条，失败 7 条

支付模块    5 条失败    [查看日志]
账户模块    2 条失败    [查看日志]

[重跑失败用例]

看哪里，点哪里。不用再输入“帮我看一下支付模块这 5 条失败用例的日志”，也不用担心它理解成另一次执行。

这里的 Widgets 指的是 ChatKit 对话里的组件。官方提供了卡片、列表和各种子组件，也有 Widget Builder，可以先调布局，再把生成的 JSON 接到后端。官方文档

这个东西吸引我的地方，是它承认了一个很普通的事实：有些操作，点一下就是比说一句方便。

开放的问题适合聊。比如“最近支付模块为什么老出问题”，用户自己也不知道要查什么，让 AI 帮忙找。等它查出几个具体的失败任务，再给几个操作入口就行了，没必要继续猜用户说的是哪一个。

卡片怎么来的

它用结构化数据描述界面。一个容器，里面放文字、布局组件和按钮，组成一棵组件树。组件说明

比如把前面的报告缩到只剩一句摘要和一个按钮，大致是这样：

{
  "type": "Card",
  "children": [
    {
      "type": "Text",
      "value": "回归测试：128 条用例，7 条失败"
    },
    {
      "type": "Button",
      "label": "查看失败详情",
      "onClickAction": {
        "type": "test_run.show_failures",
        "payload": {
          "run_id": "run_20261025_01"
        }
      }
    }
  ]
}

test_run.show_failures 是自己定义的动作名，run_id 是自己系统里的任务 ID。ChatKit 不认识测试平台，这部分得自己接。

上面只是说明结构的 JSON，没包含完整服务端，也没跑过完整项目。

后端把查到的数据填进卡片，前端按组件定义渲染。可以先做几套固定模板：报告摘要用一套，失败列表用一套，任务确认用一套。模型负责分析结果，展示格式先固定下来，至少排查问题的时候少一个变量。

如果想把现有平台里某个复杂页面搬进来，还得先看看组件能不能表达。日志里搜索、跳转行号、多个任务对比，这些功能都加上以后，一条聊天消息未必装得下。

点下去以后，还得自己干活

按钮上绑定的是 Action。用户点击后，应用收到动作类型和参数，再做后续处理。服务端可以在 ChatKitServer.action 里接，也支持把动作交给客户端。Actions 文档

比如点“查看失败详情”，后端拿到 run_id，查权限，查失败用例，再把结果返回。官方的自定义集成支持输出 widget，也可以更新已有组件。自定义集成文档

查详情这一步，我觉得直接调业务接口就够了。用户已经点得很明确，不需要再让模型猜一次他要做什么。到了“分析这几条失败有没有关系”，再让模型读日志。

重跑也是一样。真正容易出问题的地方，还是我们熟悉的那些接口和任务状态。

比如用户点了重跑，接口返回成功。卡片上写什么？

写“重跑成功”就有点含糊。是任务创建成功了，还是已经跑完而且全过了？比较准确的应该是“已创建重跑任务 #xxx”，后面再跟执行进度。

还有一种情况：用户昨天查过报告，今天翻回聊天记录，点了一下旧卡片。测试环境可能早就释放了。后端得重新查当前状态，不能因为昨天给过这个按钮，今天就照样执行。

聊天记录留着，里面的操作却不一定一直有效。这个比普通页面麻烦一点：普通页面刷新后往往会重新取数据，历史消息里的按钮却可能一直在那里。

做测试的，看到按钮就开始想多点两下

真接进测试平台，我第一反应就是：连续点两下重跑，会怎么样？

如果创建出两个任务，哪一个算用户想要的？如果第一次请求超时了，用户又点了一次，服务端其实已经建好任务了怎么办？

这些问题本来就有。换成 AI 助手以后，也一样得测。

还有 run_id。虽然它最初是后端填进卡片的，点击请求到了服务端，还是要查用户有没有权限访问这个任务。官方也明确提醒，Action 和 payload 来自客户端，要当作不可信输入处理。Actions 文档

卡片里没显示别人的任务，不代表用户传不进来别人的 ID。

此外，查不到结果的时候显示什么，模型分析失败后还能不能看原始日志，用户换个设备打开旧消息还能不能继续操作，也都值得试试。

所以测这种功能，光看 AI 回答对不对还不够。得顺着按钮往下走，看看任务是不是真的创建了，创建了几次，界面说的和后台实际发生的是不是一回事。

先放几个有用的按钮

如果要在测试平台试这个东西，我会先做报告摘要、查看日志、重跑确认这几个地方。

特别是重跑之前，把环境、用例数量、执行范围摆出来，比让 AI 回复一句“好的，马上帮你重跑”踏实。用户看一眼，也容易发现“等等，我不是要跑这个环境”。

至于大段日志、复杂筛选、多份报告对比，跳到完整页面也没什么不好。对话里留个摘要和入口就行。

我想看的效果很简单：原来要打三次字，现在点一下就能办完；原来得复制一个长任务 ID，现在直接选对应的报告。

如果做完以后，用户还是要反复解释“不是这条，是上面那条”，那卡片做得再漂亮也没帮上什么忙。