一句话定义：表格进上下文（Table-in-Context）指的是把结构化表格数据以模型能正确理解的形式放进提示词，而不是把导出的 CSV 原样粘贴进去。
模型看到的不是表格，是一串 token
在分词器眼里，CSV 里那几十个逗号、换行、引号，跟字母数字没有本质区别，都是扁平的一维序列。所谓“第 3 行第 5 列”，模型得自己在注意力里重建出来：先数逗号确定列号，再数换行确定行号，还得记住表头第 5 个字段叫什么。列一多、单元格里带英文逗号、有空值缺列，这套重建就会出错——表现出来就是“读串行”：把 A 公司的营收按到了 B 公司头上。
打个比方：这就像你把一张 Excel 表按行念给电话那头的人听，中间不报列名、不说明换行，念到第二十行，对方早忘了第几列是“同比增速”。表格的空间结构进了上下文就没了，只剩时间顺序。
常见的四种摆法
| 形态 | 模型实际看到的样子 | 好处 | 风险 | |
|---|---|---|---|---|
| 裸 CSV | 一长串扁平 token | 省事，写入快 | 列错位、引号逗号打架，长表容易丢中间行 | |
| Markdown 表格 | 每行都带 ` | ` 分隔，表头在顶部 | 行列关系肉眼和模型都易辨 | 宽表逐行重复，token 涨得多 |
| JSON 记录数组 | 每条记录字段名显式重复 | 字段含义最明确，最抗错位 | 冗余最大，长表很贵 | |
| 裁剪后的子集 | 只留需要的列和行 | 又便宜又准 | 前面得先有一层筛选逻辑 |
同一个表，选哪种不是审美问题，是准确率和成本的取舍。
跟相邻概念的区别
表格问答（Table QA）是一个任务，结构化输出（Structured Output）管的是模型往外吐什么，表格进上下文管的是往里塞什么。它也常和 RAG 混为一谈：检索解决“该拿哪几行”，进上下文解决“拿到的这几行怎么摆”，两件事，后一件经常被忽略。
对干活的人意味着什么
第一，先裁再喂。多数时候你只需要三列，而不是三十列；行数上千就先在代码里过滤或聚合，别指望模型替你扫全表。第二，别用裸 CSV。至少换成 Markdown 表格，字段含义关键的用 JSON，把单位写进列名（如“营收_万元”）。第三，重要行放前面，长表中间位置的内容模型更容易漏。第四，躲开电子表格习惯：合并单元格、两行表头、脚注行，这些对人友好，对 token 序列是灾难，先规整成一行一记录的干净表再进上下文。
各家模型对长上下文的实际表现差异不小，具体能力以官方页面为准，别拿别人的经验当保证。