在 ChatGPT 客户端复制回答，粘出来常常只剩排版好的文字，代码围栏、标题、列表全部丢失；改用「请输出 Markdown 源码」的提示词，一遇到代码块又失灵。本文拆开前端渲染与模型输出的两层原因，给出结构包裹法、示例法、会话级规则等可复现写法，并说明换工具入口的取舍。
在 ChatGPT 的桌面端和手机客户端里选中一段回答复制，粘到编辑器或笔记软件中，常常只剩下「排好版的文字」：标题变成普通一行，列表丢失缩进，代码块外层的反引号围栏消失，表格塌成一片。想要能直接进仓库、进文档的 Markdown 源码，只能切回网页端再复制一遍。
有人为了绕开这一步，干脆在提问时加一句「请以 Markdown 源码形式输出」。刚开始确实有效，可一旦回答里出现代码块，这句话就失灵了，往往要反复强调三四遍，模型才「反应过来」。换设备、换账号同样复现，说明这既不是网络问题，也不是某台电脑的问题。原因其实分两层：一层在客户端，一层在提示词的表达方式上。把两层分开看，才找得到稳定的写法。
问题拆成两半：渲染在前端，约束在提示词
先确认一个事实：模型返回的本来就是带 Markdown 标记的纯文本，把它变成粗体、标题、代码块的是客户端的前端渲染。也就是说，「复制出来没有源码」这件事发生在显示和复制环节，不在生成环节。
这带来一个容易被忽略的后果：模型看不到自己的输出被渲染成了什么样。它只知道「我写了三个反引号」，不知道界面上显示的是一个带底色的代码块，更不知道你复制时拿到的是什么。所以「请不要渲染」这类要求，指向的是一个它无法控制的对象——它能改变自己输出的结构，改变不了你客户端的行为。
为什么「请输出 Markdown 源码」会失效
否定式表述容易被反向牵引
「不要输出渲染后的内容」「不需要排版」这类句子，关键词全落在「渲染」「排版」上。模型按概率续写，注意力被这些词吸走，很容易理解成「要输出带格式的内容」。日常沟通里也一样：告诉一个人「别想大象」，他脑子里先出现的就是大象。
代码块会打断外层格式约定
一旦回答里出现三个反引号的围栏，模型会切换到「写代码示例」的模式，把开头那句「整体用源码输出」当成背景噪音丢掉。这就是为什么纯文字回答时有效、一有代码块就失灵。
对话越长，早期约束越弱
上下文里塞进越多轮解释、纠正和情绪化措辞，最早那条格式要求占的权重就越低。反复强调不但没帮忙，反而把大量「渲染」「源码」的词堆进上下文，让模型的判断更摇摆。
三种可复现的提示词写法
1. 结构包裹法：把「别渲染」换成「整体套一层围栏」
这是最稳的一招。不要求模型「不渲染」，而是要求它把整条回答放进一个外层代码块里。客户端渲染出来的就是一个代码块，复制出来天然是源码。模板可以直接抄：
从现在起，你的每条回答都遵守下面的约定：
1. 整条回答的完整内容，整体放进一个用四个反引号包起来的代码块，语言标记写 markdown；
2. 代码块内部保留原始的标题、列表、表格和代码围栏，不要改写、不要省略；
3. 代码块外面不要加任何解释性文字。
外层用四个反引号，是为了让内部的三反引号不提前闭合围栏。这个约定的好处是它描述的是「做什么」，而不是「别做什么」，模型更容易执行，也更容易在长回答中保持。
2. 示例法：给一两个迷你问答，比讲十句道理管用
模型的模仿能力远强于理解抽象约束的能力。在正式提问前，先给一组很短的示范：
- 问：把这段 JSON 转成表格。答：（给出一段被围栏包住的 Markdown 表格）
- 问：解释一下闭包。答：（给出一段被围栏包住的、带小标题和代码块的回答）
示范里的格式就是你要的格式，后面的问题大概率会沿用。示范要短，两三行即可，太长反而稀释重点。
3. 开关词加会话级规则
如果不想每次都写一长段，可以固定一个短标记，比如每次提问前加一行「输出模式：RAW」，并在会话开头用一段话定义这个标记的含义。更省事的做法是利用自定义指令、项目指令或系统提示，把约定固化下来，每个新会话只需生效一次。
需要提醒的是，这些写法都不是百分之百稳定：模型版本、客户端版本变化后效果可能不同。重要产出建议先小样本验证，再批量使用。
从工具层绕开：别让前端替你做决定
提示词只是权宜之计，更彻底的做法是换一个不替你渲染的入口：
- 走 API，配一个能显示原始 Markdown 的客户端（LibreChat、Open WebUI、Cherry Studio 这类），复制出来就是源码；
- 在浏览器开发者工具里查看流式响应的原始内容，确认返回体本身就是 Markdown，这能帮你判断问题出在哪一层；
- 用命令行或脚本直接调接口，把结果写进文件，完全跳过剪贴板。
如果你习惯用命令行工具跑批量文本任务，又不想让本地机器长时间挂着、或者本地网络不稳导致任务中断，租一台放在机房里的独享 Mac 远程连接使用也是可选方案——整机长期在线，网络环境相对稳定。这只是备选路径，与纯格式问题没有必然关系。
「语气强硬一点是不是更有效」值得信吗
讨论里出现过两种对立看法：一种认为骂两句、施压一下模型会更卖力；另一种认为清晰、友善、带示例的沟通才可复现。从机制上看，情绪化措辞确实会改变输出的用词分布，可能让你「感觉」它更配合，但这种效果不稳定、不可复现，还会占用上下文预算，把早期的格式约定挤得更远。「友善」本身也不是魔力，它的价值在于更少的歧义和更明确的结构。
比较务实的做法是：把情绪成本省下来，换成结构化约束和示例。如果两种风格都想试，建议做个对照——同一个问题、相近的上下文长度，各跑几轮，看哪种稳定命中你要的格式。这类结论只能自己验证，别人的经验未必适用于你的模型版本。
检查清单
| 检查项 | 目的 |
|---|---|
| 看原始响应或换个客户端粘贴 | 判断问题出在渲染层还是生成层 |
| 用「整体围栏包裹」替代「请不要渲染」 | 把否定指令改成结构指令 |
| 准备一两个格式示例 | 用模仿代替说理 |
| 约定前置到会话开头或自定义指令 | 避免在第五轮追问里才提要求 |
| 格式漂移就新开会话 | 绕开长上下文对早期约束的稀释 |
| 需要稳定产出时走 API 或写文件 | 彻底跳过剪贴板 |
小结
「复制不到 Markdown 源码」的根子在客户端渲染，模型对此无能为力；「请输出源码」失效，则是因为否定式表述和代码块的双重干扰。把要求从「不要做什么」改写成「把什么放进什么结构里」，再配上一两个示例，成功率会明显提高。真要长期稳定地产出源码，换一个不替你渲染的入口，比反复调提示词更划算。