Claude 中文回答看不懂？原因排查与提示词改善方案

让模型“用简体中文回答”几乎是现在所有人的标配指令，但不少人发现：语言确实选对了，读起来还是累。句子是中文的，词却像从另一套体系里搬来的——“收口”“落地”“对齐”“拉齐水位”这类动词出现在很奇怪的位置，一句话塞进三四个自造名词，读完还得在脑子里再翻译一遍。有人把这叫“中译中”：先看懂 AI 中文，再翻译成人话。

这种疲惫感的来源不止一个。一部分在模型侧：训练语料里的技术中文本身就翻译腔重、造词多；一部分在使用侧：指令里只说了“用中文”，没说“用什么中文”；还有一部分在渲染侧：小众字体、细笔画宋体、乱码，都会放大阅读负担。下面按“现象—原因—可操作方案—注意事项”的顺序拆开讲。

先确认：你遇到的是哪一种“看不懂”

把症状分分类，后面的对策才有针对性：

• 生造词密集：出现一批词典里没有、但结构上很像术语的复合词，每个都能猜，连起来就模糊。
• 动词抽象化：把具体动作换成抽象动词，比如不说“删除这段配置”，而说“把这段配置处理掉”。
• 翻译腔句式：长定语前置、被动句堆叠、主语缺失，一句话四十个字以上。
• 模板化结构：先总结、再分点、再总结，信息密度低，翻半天才看到关键命令。
• 英文缩写不解释：首次出现的缩写直接使用，读者被迫反查。
• 乱码或缺字：这一条通常不是模型的问题，见后文“渲染层”。

如果主要症状是前五条，靠提示词基本能改善大半；如果是最后一条，去查终端编码和字体。

为什么会这样

1. 语料结构决定表达习惯。 中文技术内容里有大量从英文翻译过来的文档，句式生硬、术语直译。模型学的是这种分布，输出的自然也是这种味道。

2. “专业”被错误地对齐成了“堆术语”。 模型收到的隐含要求往往是“严谨、结构化、专业”，而它实现“专业”最省力的方式就是换更抽象的词、加更多限定语。

3. 压缩倾向。 模型倾向于用一个短词概括一长串概念，节省 token。问题是这个短词只在它的上下文里成立，读者没有那份上下文。

4. 中英概念映射缺失。 某个英文概念在中文里没有公认译法时，模型会现场造一个，而且每次造的还不一样。

5. 版本差异真实存在，但别当成玄学。 不同模型、不同版本在中文表达风格上确实会有差别，有人会觉得某个版本“说话正常”。这类主观感受可以参考，但官方并不承诺风格稳定，具体表现请以你当前使用的模型和渠道为准。

6. 内置指令不可见。 很多产品的系统提示里带有“使用中文回答”“保持专业”之类的设定，和你的自定义指令叠加后，效果未必是你想要的。

方案一：把“说人话”写进常驻指令

只在对话框里说一句“用中文”远远不够。把下面这段放进自定义指令、项目说明或 CLAUDE.md 之类的常驻文件里，效果比每次临时叮嘱稳定得多：

始终使用简体中文回答。语言要求：
1. 用日常书面语，像给同事解释问题，不用比喻性动词和生造复合词。
2. 英文术语首次出现时保留原文并加一句解释，之后统一用同一译法。
3. 单句不超过 40 字，避免三重以上从句。
4. 结论先行：第一段直接给答案，再展开理由。
5. 不要写“综上所述”“值得注意的是”这类填充句。
6. 命令、参数、报错信息原样保留，不翻译、不改写。

几个容易忽略的细节：

• 给一个反例。加上“不要写成‘把能力收口到某某层’这种句子”，模型的模仿能力会立刻收敛。
• 明确受众。写“读者是刚入行的开发者”比写“要通俗”有效得多。
• 指令别太长。超过十几条，模型会挑着执行。

方案二：维护一份术语对照表

比抽象的“说人话”更有效的，是直接给词。表格形式最省事：

注意事项：

• 黑名单控制在 10 条以内。太长会分散注意力，反而漏掉核心要求。
• 每条给出“改成什么”，只列禁用词，模型会换一个同样难懂的词。
• 这份表可以随着你遇到的坏词逐步追加，比一次性写全更实用。

方案三：两段式输出，让模型自己“中译中”

一次成稿往往带着模型的默认文风。改成两步，让它自己重写：

第一步：先列出技术要点，可以写得粗糙，允许术语。
第二步：保留第一步的全部结论和命令，用初中生能看懂的语言重写一遍，
        不要新增内容，不要删减结论。

第二个技巧是复述检验：在复杂任务开始前，让模型用三句话复述你的需求，确认无误再输出。需求理解偏了，语言再顺也没用。

方案四：用格式约束降低阅读成本

• 对比类内容强制用表格，不要用长段落罗列。
• 代码块只放能直接执行的内容，解释写在代码块外。
• 要求“每条不超过两行”，比要求“简洁”可执行得多。
• 长文档先要目录和一句话摘要，再决定要不要读全文。

方案五：交叉验证表达

同一个问题让两家不同厂商的模型各答一遍，挑表达更清楚的那份，把它的措辞当作模板回灌给常用的那个——“以后按这个风格写”。这比凭空描述风格要准。但不必迷信“某个版本中文最好”的说法，模型更新频繁，结论很快过期。

渲染层：字体和终端也占一半阅读负担

有人觉得换成某款仿宋、某款衬线字体好看，但小字号下细笔画的中文衬线体在高分屏上确实更费眼；聊天界面和编辑器里，等宽无衬线字体通常更耐读。另外：

• 出现方块、问号、乱码，先查终端或编辑器的编码是否为 UTF-8，再查字体是否缺字，不要先怀疑模型在输出乱码。
• 深色模式下对比度过低会显著增加疲劳。
• 行距、字号、窗口宽度，调一遍比换模型省事。

环境与账号：别为了“纯净”踩坑

有些讨论会建议用第三方工具给网络环境打分、测“纯净度”。这类分数没有权威标准，反复切换线路反而容易触发风控，不建议作为常规手段。账号共享、买卖、绕开地区限制同样有封号风险，重要工作不要押在上面，具体规则以平台官方最新说明为准。

如果任务本身是长时间挂着跑命令行 AI 工具，真正的痛点往往是本地机器休眠、网络抖动导致会话中断。这种情况可以考虑把任务放到一台长期在线的远程 Mac 上（整机放在机房、按月租用、远程连接使用），网络环境相对稳定，适合长会话；本地环境本来就稳的话没必要折腾。

需要你自己验证的地方

• 提示词效果随模型版本和接入渠道变化，同一段指令在网页端和 API 端表现可能不同。
• 网页端的内置系统提示无法修改，只能用自定义指令覆盖，能覆盖多少不保证。
• 不建议使用所谓“破限”“去限制”类提示词换取更自然的表达，稳定性和合规性都有问题。

小结：一份可以直接执行的清单

1. 先分清是“文风问题”还是“编码字体问题”。
2. 把语言要求写进常驻指令，而不是每次临时说。
3. 指令里加反例，给出目标读者。
4. 维护一张不超过 10 条的术语对照表，每条都写“改成什么”。
5. 复杂任务用两段式：先要点，再重写成人话。
6. 强制表格、短段落、结论先行。
7. 换字体、调编码，别急着换模型。
8. 网络与账号走合规路径，不用来路不明的“纯净度”工具。

这些做法不保证让输出立刻变得像人写的，但把“看不懂”从常态压到偶发，通常一周之内就能感觉到差别。