一次流式响应为什么卡住：从页面查到反向代理

最近接入流式接口，服务端任务还在跑，页面却没有变化，有时直到最后才一下出现整段内容。接入时调整过代理缓冲和超时，也在测试环境验证过。相同的表象仍可能来自不同位置，不能看到卡顿就归给模型。

排查要找到数据经过各层的时间：上游产出、应用写出、代理转发、浏览器解析和界面更新。最终响应正确，只能说明内容最后到了，不能说明中间没有等待。

调研 AI 数据分析产品时，我关注哪些环节

上传表格，问一个问题，几秒后得到图表和解释，演示很吸引人。若要每周用它做分析，我更关心几次修改以后计算口径有没有变、结果能否核对、导出能否交付。

这轮调研没有统一到足够可靠的横向成绩，不做产品排名。我把输入、计算、修改和交付拆开观察，保留一套以后可以重复使用的任务。

AI 已经能生成像样的前端页面，原来的低代码可视化产品还应该投入在哪里？这个问题不能只拿一次漂亮的生成结果回答。页面要接业务数据、改参数、发布并交给别人维护，后面的工作同样决定产品能不能用。

我目前比较三条路线：生成平台配置，直接生成代码，以及平台组件与自由代码混合。还没有足够统一的收益数据，下面是基于现有能力的判断与验证办法。

最近用 AI 写页面，布局、样式和简单交互确实快了不少。生成一个能点的保存按钮不难，困难是确认它在请求失败、重复点击、切页和继续输入时仍然保存了正确内容。

这让我更在意任务约定与状态流。代码生成越方便，遗漏的条件越容易跟着一个看起来完整的界面一起通过评审。

“选一个场站，下面的图表一起刷新。”这类需求我以前很容易直接想到事件总线，导航器发事件，图表订阅，接起来就能跑。最近越来越多参与需求、交互和排期，发现需要解释的事情发生在事件之前。

首次进入选什么，清空表示全部还是不查，保存后怎样恢复，换组织导致原设备不可见时怎么办，这些都不是组件各自猜一个默认值就能解决的。

“标题字号改成 20，能耗换成平均功率。”两句话都像改配置，影响却不同。字号改变外观，指标替换还会改变单位、聚合和坐标轴。让模型直接改整份页面，容易把这些区别藏起来。

我的方案让模型提出业务命令，编辑器负责定位、校验和保存。命令进入原来的版本与历史机制，用户能够查看差异，也能按明确规则撤销。

上个月准备 RAG 分享时，“提问、检索、回答”画在一张图上很直观。整理产品资料以后，困难却大多发生在回答之前。文字找到了，条件没找到，模型仍然会给出方向错误的操作建议。

比如页面已经发布，用户问为什么改不了标题。库里同时有修改标题的步骤与发布页面只读的规则，命中前一份不等于回答有了依据。这个问题适合用来检查资料、召回、上下文和生成各自做了什么。