现状
tuiapp_v2 在流式输出（streaming）期间，助手消息中的 Markdown 语法不会实时渲染为富文本样式。用户看到的始终是原始 Markdown 源码（如 **粗体**、# 标题、代码块围栏、表格语法等），直到整条回答输出完毕（m.done == True）后，TUI 才一次性替换为经过 Rich Markdown 渲染的样式化文本。
代码层面
_assistant_segments() 方法（约 L4117–L4126）中有一个显式的分流逻辑：
- 流式阶段（
not m.done）：对末尾文本段使用 Text.from_ansi(content) 直接显示原始内容（附带 ANSI SGR 样式转换），跳过 Markdown 解析。代码注释写明原因是 "Markdown parsing per chunk is the streaming-lag root cause"。
- 完成阶段（
m.done == True）：才调用 _render_md() 走完整的 Rich HardBreakMarkdown 渲染管线。
体感差异
参考 Claude Code（cc）的 TUI 体验：Claude Code 在流式输出过程中会实时解析和渲染 Markdown 语法——代码块在围栏闭合后立刻高亮，标题、列表、粗体等在字符到达时就呈现样式。用户可以在回答仍在生成时就开始阅读格式化后的内容。
而当前 tuiapp_v2 的行为是：整个回答期间只看到纯文本 Markdown 源码，回答结束后突然"跳变"为美化后的富文本。这种延迟渲染降低了流式阅读的可读性——尤其是在回答包含大量格式化内容（表格、代码块、列表）时，原始 Markdown 语法的视觉噪音会影响用户在生成过程中边看边理解。
期望
希望 tuiapp_v2 能在流式输出过程中实时渲染 Markdown 语法，让用户在回答仍在生成时就能看到格式化后的内容，而不是等到整条回答完成后再一次性替换。
现状
tuiapp_v2在流式输出（streaming）期间，助手消息中的 Markdown 语法不会实时渲染为富文本样式。用户看到的始终是原始 Markdown 源码（如**粗体**、# 标题、代码块围栏、表格语法等），直到整条回答输出完毕（m.done == True）后，TUI 才一次性替换为经过 Rich Markdown 渲染的样式化文本。代码层面
_assistant_segments()方法（约 L4117–L4126）中有一个显式的分流逻辑：not m.done）：对末尾文本段使用Text.from_ansi(content)直接显示原始内容（附带 ANSI SGR 样式转换），跳过 Markdown 解析。代码注释写明原因是 "Markdown parsing per chunk is the streaming-lag root cause"。m.done == True）：才调用_render_md()走完整的 RichHardBreakMarkdown渲染管线。体感差异
参考 Claude Code（cc）的 TUI 体验：Claude Code 在流式输出过程中会实时解析和渲染 Markdown 语法——代码块在围栏闭合后立刻高亮，标题、列表、粗体等在字符到达时就呈现样式。用户可以在回答仍在生成时就开始阅读格式化后的内容。
而当前
tuiapp_v2的行为是：整个回答期间只看到纯文本 Markdown 源码，回答结束后突然"跳变"为美化后的富文本。这种延迟渲染降低了流式阅读的可读性——尤其是在回答包含大量格式化内容（表格、代码块、列表）时，原始 Markdown 语法的视觉噪音会影响用户在生成过程中边看边理解。期望
希望
tuiapp_v2能在流式输出过程中实时渲染 Markdown 语法，让用户在回答仍在生成时就能看到格式化后的内容，而不是等到整条回答完成后再一次性替换。