Excel 转 Markdown：把电子表格变成 LLM 能推理的表格
把一张电子表格原样粘给语言模型再提问，你经常会得到一个信心满满、却把列认错了的答案。这不是模型蠢。 电子表格是一个坐标网格——单元格 B7 里存着一个数，文件里没有任何地方写着这个数属于"第三季度营收" 那一列。人靠位置推断出来，把值粘成一团之后，模型也得推断，只是证据差得多。
Excel 转 Markdown 用一张真正的竖线表格解决这个问题：表头行、分隔行，然后是对齐的 数据行。这种格式对"哪个值属于哪列"毫不含糊，模型也处理得很好——训练数据里到处都是 Markdown 表格。 想在线把 Excel 文件转成 Markdown 表格，把 .xlsx 或 .xls 拖进上面的框就行。免费、 无需账号、上限 50 MB、不保留任何东西。
输出长什么样
工作簿是一组工作表，输出里每张表自成一节，标着它的标签名。这个标注比听起来重要——"假设"、 "2024 实际数"、"请勿编辑"实实在在地说明了下面的数字该怎么对待，看得到标签名的模型会用上它。
在每张表内部，第一个有内容的行被当作表头，跟着对齐分隔行，然后每个数据行用竖线分隔渲染出来。 结构上读起来就是：列名横在顶上，值在下面对齐排列，一行一条记录。数据一旦成了这个形状，你就可以问 按列的问题——"哪些地区增长超过 10%"、"找出状态为受阻且负责人为空的行"——模型手里的信息足够真正去 核对，而不是猜。
公式、值，以及你真正拿到的是什么
这一点常让人意外。对公式单元格，.xlsx 存了两样东西：公式本身
（=SUMIF(D:D,"North",F:F)）和上次 Excel 重算时缓存下来的结果。转换读的是缓存值。
你拿到的是 184,500，不是那个 SUMIF。
这是正确的默认——你要推理的是数字本身——但有两个值得记住的后果。第一，模型看得到答案是什么， 看不到它怎么来的，所以它没法审计你的逻辑，也发现不了写错的区间。第二，如果文件是脚本或导出 工具生成的、写了公式却从没在 Excel 里打开过，缓存值可能缺失或过期，那些单元格转出来就可能是空的 或错的。打开文件，让它重算一遍，保存，再转换。十秒钟，排除一整类困惑。
会弄坏表格的那些东西
Markdown 表格是刚性的：每一行的列数必须相同。电子表格一点也不刚性。几乎所有转得一团糟的案例， 根子都在这对矛盾上。
- 合并单元格。合并单元格把内容存在合并区域左上角的那格，其余是真空的。横跨 A1:F1 的大标题会变成一个值后面跟五个空白，而如果那是第一行，它就会被当成表头。报表侧边向下 合并的分类标签，只在每组第一行出现一次，其余行什么都没有。
- 多行表头。经典的"2024"横跨三列、下面是"Q1 / Q2 / Q3"的版式，在 Markdown 表格里 没有对应表示。其中一行成为表头，另一行沦为一条塞满季度名的数据行。
- 空白间隔行和列。Excel 里的视觉留白，到输出里就是空行和无名列，悄悄吃掉 token， 稀释整张表。
- 数据不从 A1 开始。角上一个 logo、第 2 行一句备注、真正的表格从第 6 行开始—— 转换器无从得知第 1 到第 5 行只是装饰。
- 一张表里放了好几块数据。并排的三个独立数据块，会变成一张特别宽、大部分是空的 网格。
所有这些的解法是同一个，而且很无聊：转换前复制一份工作表，顶上只留一行表头、一表一块数据、不合并、 不留间隔行。两分钟的整理，胜过事后任何巧妙的提示词。
日期、数字，以及你的单元格为什么显示 45231
Excel 并不把日期存成日期。它存的是从纪元起算天数的序列号，你看到的——15/03/2024、Mar-24 或"星期五"——
只是叠在上面的显示格式。转换读的是底层的值，格式没带过来的话，日期列就会以裸整数出现。日期对分析
重要的话，转换前先把它们固定成无歧义的文本：加一列 =TEXT(A2,"yyyy-mm-dd")，用那一列。
ISO 格式还顺带消除了英式/美式日月顺序的歧义——那种歧义会不声不响毁掉所有日期推理。
数字格式同理。显示 £1,250.00 或 12.5% 的单元格，存的是 1250 和 0.125。百分比以小数出现是最容易 绊倒人的一个——你让模型找大于 10 的值，它在一列 0.125 里什么也找不到。单位不明显的地方，把它写进 列标题而不是依赖单元格格式："增长率（%）"或"营收（GBP）"。
宽度、token，以及知道何时收手
同样的数据，Markdown 表格比扁平形式花的 token 多，因为每一行都要为分隔符买单。粗略地说，每多一列， 每一行就多一根竖线和一些填充——一张 40 列、5,000 行的表，在读到第一个值之前，预算里已经有相当一块 花在了标点上。宽表正是 xlsx 转 Markdown 从"有用"滑向"用不起"的地方。
两个习惯能管住这件事。转换前删掉不需要的列——大多数导出带着二十个字段，而你的问题只碰其中四个。 再盯着输出下方的 token 计数器，它立刻告诉你结果是塞得进模型的上下文窗口，还是应该先过滤。表格特别大、 问题又不需要列对齐的话， Excel 转文本是更省的路线， 本页顶部的切换按钮会把你的文件直接带过去。
.xlsx、.xls 和 CSV
现代 .xlsx 是装着 XML 的 ZIP 包——结构良好，解析可靠。老式 .xls 是 2007 年之前的二进制格式，这里 同样处理，但要知道它的上限是 65,536 行、256 列，而且老会计系统和 ERP 导出的文件有时依赖一些转换 中活不下来的怪招。有得选的话，先另存为 .xlsx。
数据本来就是 CSV 的话，干脆绕开 Excel——直接去 CSV 转 Markdown。少一跳 格式转换，也没有 Excel 在导入时"贴心地"把产品编码变成日期、把邮编的前导零削掉的风险。
常见问题
怎么把 Excel 表格转成 Markdown 表格？
把 .xlsx 或 .xls 传到上方，每张工作表都会以竖线表格返回，可以直接贴进 README、wiki、Pull Request 或模型提示词。免费、单文件 50 MB、无需账号。表头行仍然是表头行，对齐关系能完整走完全程。
表头行和列对齐会保留吗？
会——这正是在这里选 Markdown 而不选扁平文本的全部理由。竖线表格保住了"哪个值在哪个表头下面"，读它的助手能正确回答"EMEA 地区 3 月的数字是多少"。把同一张表压成纯文本，这个问题就没法回答了。
合并单元格和多行表头会怎么样？
它们会被压得很难看。Markdown 竖线表格只有一行表头，也没有"单元格横跨两列"的概念，所以带着"Q1 2026"合并横幅、下面三个子列的报表会丢掉横幅。按干净的矩形数据搭的表转换得完美无缺；按打印好看来搭的表通常需要手工修。
特别宽的表转出来还能读吗？
机器能读，人读着难受。四十列的表会变成四十列的竖线表格，一行长达几千个字符。模型解析毫无压力。要给人看的话，先在 Excel 里转置，或者转换前削减到真正要紧的那几列。
图表和数据透视表会转换吗？
不会。图表是没有文本体的绘图对象；数据透视表转出来的是它当前显示的那些单元格，而不是一个活的透视。你拿到的是底层的值网格——而这通常本来就是你想交给模型的东西。
工具箱里的其他家伙
电子表格往往是跟着别的东西一起来的。File2Txt 在一个页面处理所有支持的格式，值得认识的邻居有：处理财务报告的 PDF 转 Markdown、处理数字 最终落脚的那份演示文稿的 PowerPoint 转 Markdown， 以及同一份数据来自 API 时的 JSON 转 Markdown。
代码这边有 GitHub 仓库转文本工具和 本地文件夹转换器，还有处理网页的 Web2Txt。想看比电子表格更宽的 视角，读这篇 为 LLM 准备文件的指南。
Repo2Txt 由 v12hero 开发和维护，那是一位独立开发者，专做隐私优先的原生应用和 Web 应用。