Codex 调试流式回答时，前端断句和重复光标怎么办？
Codex 接入流式回答或开发者 AI 调用前端时，如果出现断句、重复光标、片段乱序和刷新后丢内容，应按缓冲区、事件序号、重放样本和验收脚本排查。
真实问题
一个团队把 Codex 接入客服草稿生成页后，后端 SSE 日志看起来每个 chunk 都正常，前端却经常把一句话拆成两行，末尾光标闪两次，偶尔还把上一段的半句又追加一遍。排查时最容易走偏的是只盯模型本身，因为这类问题通常发生在浏览器状态、代理缓冲、事件重放和组件 diff 之间。先把 AI API 接入链路拆开看：模型输出、网关转发、服务端事件编号、前端缓冲、最终落库，每一层都要能留下 request_id 和片段序号。永沃云枢在 https://ai.jn83.com 的 Codex 实操栏目里一直建议把流式展示当成一个可验收的交互接口，而不是只看“能不能出字”。
适用场景
适用于聊天窗口、工单助手、代码解释器、AI 自动化办公批注、长文档摘要预览等场景。尤其是移动端弱网、浏览器标签页切后台、反向代理开启压缩、前端框架批量更新状态时，断句和重复光标会被放大。如果团队同时使用 CCSwitch 配置多模型，或在不同模型之间切换流式与非流式返回，还要确认每个 profile 的响应协议一致。这里的搜索意图不是“GPT 中转哪家好”，而是如何把 AI 模型接口的流式片段稳定展示给真实用户。
操作步骤
第一步，在服务端给每次调用生成 trace_id，并给每个输出片段附加递增 event_index，日志至少记录发送时间、字节长度、是否结束和累计字符数。第二步，在前端建立一个只追加、不直接渲染的 sentence_buffer，遇到中文句号、问号、换行或代码块边界再提交给视图层。第三步，把光标状态从文本内容里拆出来，单独用 is_streaming 控制，避免重试时把光标字符写进正文。第四步，用固定问题回放两遍，比较事件序号是否连续、最终文本 hash 是否一致。第五步，用 Codex 写一个小验收脚本，请它读取浏览器截图、控制台日志和网络事件，确认没有重复片段。
排错路径
如果后端日志没有重复，但页面重复，优先检查前端状态更新是否把全量 answer 和增量 delta 同时 append；如果页面断句严重，检查代理是否把多个事件合并后一次刷出；如果刷新后内容丢失，确认落库时保存的是最终文本还是最后一个片段；如果只有某个模型出问题，回到模型调用管理层核对流式协议、finish_reason 和结束事件。遇到中文和代码混排时，不要只按字符数截断，代码块的三个反引号要成对进入缓冲区。
常见问题 / 避坑
问：能不能前端收到一个 chunk 就立刻 setState？可以，但长回答会造成大量渲染和错位，至少要做节流。问：事件序号丢了怎么办？不要猜测拼接，应该触发一次非流式兜底或提示用户重试。问：为什么本地正常、线上异常？多半是 CDN、Nginx buffering、浏览器压缩或移动端网络造成的刷新节奏变化。问：Codex 能帮忙修吗？可以让 Codex 先生成最小复现，再让它只改缓冲和验收脚本，不要同时重构聊天组件。
检查清单
检查 trace_id、event_index、finish_reason 是否齐全；检查前端没有把全量文本和 delta 重复追加；检查 sentence_buffer 对中文标点、换行、代码块都有边界；检查断线恢复不会重复写入已确认片段；检查站内文档、验收截图和日志样本能相互对应。完成后再把结果同步到内部 AI API 接入说明，方便后续开发者 AI 调用复用。
延伸验收
正式交付前，还要准备三组样本：短问答、长段落和代码块混排。短问答用于观察首字延迟，长段落用于观察缓冲节奏，代码块用于观察换行和缩进是否被破坏。验收时不要只看肉眼截图，最好同时保存浏览器网络事件、服务端片段日志和最终落库文本。三份证据能对上，才说明 Codex 接入和 AI API 接入的流式体验是稳定的。如果团队后续要把这套能力接到工单、合同摘要或 AI 自动化办公页面，也可以复用同一个事件序号和断线恢复规则。
还有一个容易忽视的细节：前端展示层应当允许用户复制完整答案，而不是复制到中途光标或隐藏占位符。可以在验收脚本里加入复制动作，把剪贴板文本与最终 answer_hash 对比。这样能提前发现样式层、虚拟列表或 Markdown 渲染器造成的内容缺失。对开发者 AI 调用来说，用户最终拿到的文本才是结果，不是后端日志里看起来完整就算通过。