如果你的日常工作流是”Gemini 负责调查、Claude 负责写”，大概率遇到过这种情况：Gemini 花了几分钟整理出一份很详细的资料，里面有表格、有分点、还有几段被折叠起来的长文本，结果直接框选复制粘贴到 Claude 里之后，表格散架了，折叠的部分根本没选中，页面上”点赞””分享””重新生成”这些按钮的文字反而混了进去。这篇文章想聊的，就是为什么这种双 AI 协作场景下，用 Markdown 文件做信息中转，比直接复制粘贴更靠谱。
直接复制粘贴，会在哪几个地方出问题
Gemini 页面本质上是一个网页应用，复制粘贴依赖浏览器怎么处理 DOM 结构。当调查内容变长、变复杂时，几个具体的坑会反复出现：
| 复制粘贴时的问题 | 具体表现 |
|---|---|
| 长文本被折叠 | Gemini 生成的长回答或多段代码常常默认收起一部分，没展开就选中复制，那部分内容根本不会出现在剪贴板里。 |
| 表格变形 | 网页里的结构化表格粘贴出来往往变成错位的空格或制表符，行列关系全部丢失，Claude 读到的是一团乱码文本。 |
| 界面元素混入 | 整页框选容易把”赞、踩、复制、重试”这类按钮文字也带进去，污染了原本干净的调查内容。 |
这几个问题单独看都不严重，但放在”调查—撰写”这种链式协作里会被放大：Claude 拿到的资料如果本身残缺或错位，写出来的报告在事实和数据上就会跟着出错，而这种错误往往很难在成稿阶段一眼看出来。
用 Markdown 文件做中转,具体怎么操作
解决办法并不复杂，核心思路是让 Gemini 直接产出结构化的文本，而不是依赖浏览器渲染后的页面去复制。这套语法本身有一份公开的 CommonMark 规范，规定了标题、列表、表格、代码块统一该怎么写，几乎所有编辑器和 AI 工具都认这套写法，这也是为什么 Markdown 能在两个不同的 AI 产品之间无损搬运。具体到操作层面，建议按下面三步走：
第一步，在 Gemini 端把内容”结构化”。调查做完之后，不要急着复制，先追加一句指令，比如”请把以上调查结果整理成结构化格式，多维度对比用表格呈现，重点数据加粗”。这一步的意义在于让 Gemini 自己按 Markdown 语法输出，而不是留一堆折叠的散段。
第二步，把内容导出或复制为 .md 文件。可以用官方的”导出到 Google 文档”再下载为 Markdown，也可以用浏览器扩展一键导出，甚至手动把 Gemini 输出的原始 Markdown 文本粘贴进纯文本编辑器另存为 .md 都可以，关键是保留的是 Markdown 源码，而不是渲染后的网页样式。
第三步，把 .md 文件直接交给 Claude，而不是把里面的文字复制粘贴进对话框。现在的 Claude 支持直接上传文件作为附件，配合一句”这是调查得到的原始资料，请根据这些数据撰写报告”，Claude 读到的是完整、干净、结构没有被破坏的原文。
进阶：把调查资料放进 Claude 的项目知识库
如果同一个课题需要多次调查、分批撰写，单次上传文件的做法会显得零散。这时候可以把 Gemini 针对这个课题陆续导出的多个 .md 文件，全部放进 Claude 的 项目知识库 里。这样 Claude 在同一个项目下的每一次对话，都能随时调阅之前所有轮次的调查结果,不需要重复上传，写报告时的数据一致性和前后逻辑连贯性也会明显更好。
简单说，Markdown 在这里扮演的角色不是”格式好看”，而是一个双方都能无损解析的中间层——Gemini 写什么样,Claude 就能原样读到什么样。
写在最后
双 AI 协作的价值在于让每个模型做自己擅长的事，但前提是信息在两者之间搬运时不能失真。比起纠结用哪个浏览器插件、哪种导出方式,更值得记住的是一个原则：让产出资料的一方直接给结构化文本,让接收资料的一方直接读文件,中间尽量不经过”渲染成网页—肉眼框选—粘贴进对话框”这一段最容易出错的手工环节。这套办法不复杂,但坚持下来,报告的准确度会有实实在在的差别。
