GitHub用户反馈
Claude Code 用户想要平实英语版回复，现有方案受本地模型与交互显示限制
Claude Code 助手输出常被形容为行话密集的 "Claudish"。已有插件用本地 ollama 模型将每条消息重写为平实英语、仅改屏幕显示并保留原文；但有用户表示想用却不愿安装 Ollama，另有用户报告交互式 TUI 中重写块因上游 bug 不显示。需求具体，现有方案仍有未满足部分。
查看原始信号github:gvzdv/claudish-to-english
目标用户
Claude Code 的日常使用者，包括不熟悉技术行话、希望快速理解助手输出含义的开发者与半技术用户。
潜在需求
在不改动原始回答与保存记录的前提下，让每条 Claude 消息在界面中呈现为平实英语；且这种可读性增强不应要求用户自行部署和维护本地大模型服务。
发生场景
用户在 Claude Code 交互式会话中阅读助手回复时，常遇到行话密集、表述绕口的 "Claudish" 风格输出。现成的重写插件要求自行安装并常驻运行 ollama、拉取约 17GB 模型；一位潜在用户因此表示想用但不愿为此安装 Ollama。
来源证据
有位用户表示很想尝试该插件，但希望它不依赖 Ollama（本地模型服务）。
Ollama Would love to try this if it didn't need Ollama.https://github.com/gvzdv/claudish-to-english/issues/9
为什么值得留意
信号把"AI 回复难以读懂"落成了具体场景：对话界面 + 显示层本地重写 + fail-open 设计。原型已跑通说明解法可行；用户不愿为此安装 ollama、交互式 TUI 不渲染，说明现有形态仍有缺口，值得继续追踪这一需求的变化。
已有方案
- claudish-to-english 插件：通过 ollama 本地模型重写每条消息，仅改屏幕显示并保留原文与记录
- Claude Code 2.1.152 起提供的 MessageDisplay/displayContent 钩子机制（但交互式 TUI 渲染存在上游 bug）
未满足部分
- 在 Claude Code 2.1.227 交互式 TUI（全屏、屏幕阅读器模式）中重写块不显示，属上游 bug（anthropics/claude-code#85773），插件自身无法修复
- 安装门槛：需用户自己装 ollama、拉取约 17GB 模型并保持服务运行，有用户因此放弃尝试
- 重写块只在非交互式 --print 模式生效，交互式显示路径缺失
可能延伸 · 模型推测
- 改用云模型或直接调用 Claude 自身作为重写引擎，免除本地 ollama 依赖（推测）
- 在插件侧为交互式 TUI 渲染缺口做兼容处理，例如把重写内容并入正常输出流（推测）
- 把"只改显示、不改原文"的可读性增强思路扩展到其他 AI 编程工具或聊天界面（推测）
目前未知
- 该仓库的热度只代表关注，不能证明用户量或普遍性
- "Claudish" 术语仅来自插件自身描述，行话密集是否是广泛痛点尚未验证
- 想用但拒绝 Ollama 的只有一条评论，是否代表多数潜在用户未知
- 项目标注为 working prototype，日常稳定性未知
继续核实
- 除该插件外，是否有更多 Claude Code 用户抱怨回复行话密集、难以阅读？
- anthropics/claude-code#85773 的上游渲染缺口是否已修复，修复后插件采用会如何变化？
- 本地模型（ollama）部署门槛是否是这类显示增强功能的普遍采用障碍？
- 用户更偏好"附加平实英语块"还是"直接替换原文"的显示方式？
主题词
plain english rewriteassistant message readabilitylocal llm dependencyhook display rendering