Copilot把“冻结窗格”加在切片器中间，AI生成的图表布局为什么总差一口气？

摘要：用 Copilot 或任意大模型生成 Excel 报表、Power BI 看板、ECharts 图表时，最常见的翻车不是数据算错，而是“布局错位”——冻结窗格被插到切片器中间、图例压住数据标签、坐标轴被裁掉半截。本文把这类问题归因为“空间语义缺失”，提出一条贯穿全文的分析主线：AI 生成的是“元素清单”，而人类需要的是“约束满足后的几何布局”。围绕这条主线，文章拆解大模型在二维排版上的能力边界，给出提示词约束、模板注入、后处理校验三套可落地的工程方法，并附完整代码与排错清单。

目录

一、问题现场：一个“冻结窗格插进切片器”的真实事故

先把场景还原清楚。某运营同学让 Copilot 帮忙整理一份月度销售报表：数据区在 A1:F200，右侧 G 列放三个切片器（渠道、区域、月份），希望冻结前两行表头。结果生成的脚本把 FreezePanes 的锚点设在了 G3，冻结线正好从切片器中间穿过，切片器上半截被锁死、下半截还能滚动，交互直接失效。这不是孤例。在中文技术社区与 Stack Overflow 上，关于“AI 生成的 Excel 宏把冻结窗格放错位置”“Copilot 生成的图表图例遮挡数据”的提问长期存在，只是很少有人把它当成一个系统性问题来讨论。

笔者认为，这类事故之所以高频，是因为它踩中了一个被普遍低估的事实：大模型输出的是“语义上合理的元素清单”，而不是“几何上可行的布局方案”。模型知道“报表需要冻结窗格”，也知道“报表需要切片器”，但它并不真正理解“冻结线是一条贯穿整表的水平分割线，切片器是浮在单元格之上的独立对象，两者在 z 轴和坐标轴上存在互斥关系”。语义正确、几何错误，于是就有了“差一口气”的观感。

1.1 三类高频布局事故的归纳

把近两年公开可见的案例做一次归类（样本来自公开论坛帖、开源项目 issue 与笔者日常收集的复现记录，属整合数据，非严格抽样统计），可以归纳出三类高频事故，它们恰好对应三种不同的空间约束被违反：

三类事故的共同点在于：它们都不是“数据错误”，而是“约束未满足”。这提示我们，评价 AI 生成的图表布局，不能只看它“画了什么”，而要看它“有没有把不该碰的东西碰在一起”。

1.2 为什么“差一口气”比“完全错误”更麻烦

完全错误会被立刻发现并回滚，而“差一口气”的布局往往能通过肉眼初检——整体看起来像那么回事，只有真正用起来才暴露问题。这在工程上是最糟糕的失败模式：它把校验成本从生成时转移到了使用后。本文评述：这与软件工程中“静默失败（silent failure）”的危害同构，布局错误越接近正确，越容易被放过，最终以“报表看着怪怪的”这种模糊反馈沉淀下来，难以定位、难以复现。

二、根因分析：为什么大模型天生不擅长二维布局

要解决问题，先要承认问题的结构性。大模型在二维布局上的短板，不是“训练不够”，而是“表征方式不匹配”。语言模型的输入输出都是离散 token 序列，它对“位置”的理解是“在序列中的先后”，而不是“在平面上的坐标”。当它被要求生成一段 VBA 或 ECharts 配置时，它实际上是在做“文本续写”，而不是“几何求解”。

2.1 表征错配：token 序列里没有坐标系

一个直观的对照：人类设计师在排版时会先在脑中建立一个画布，把元素放进去，检查重叠与留白；而模型生成 grid: { left: 60, right: 40 } 这样的配置时，它依赖的是训练语料中“类似配置通常这么写”的统计关联，而不是“这个值放进去后会不会压住图例”的推演。前者是模式匹配，后者是约束求解，两者在能力层级上完全不同。

笔者认为，这解释了一个反直觉现象：模型在“生成看起来专业的代码”上表现很好，在“生成不会互相打架的布局”上表现很差。因为前者只需要模仿风格，后者需要维护全局一致性。布局本质上是一个约束满足问题（Constraint Satisfaction Problem），而自回归生成是逐 token 决策，缺乏全局回溯机制——它没法在写到第 200 个 token 时回头修改第 20 个 token 埋下的坐标冲突。

2.2 训练信号的缺失：语料里几乎没有“布局失败”的负样本

公开代码语料中，大量是“能跑通的最终版本”，而“因为图例遮挡改了三次才跑通”的中间过程极少被记录。这意味着模型很少见到“错误布局长什么样、错在哪里、怎么修”的完整轨迹。它学到的是“正确结果的分布”，而不是“从错误到正确的修正路径”。这直接导致它在面对需要多轮调整的布局任务时，倾向于一次性给出一个“看起来合理”的方案，而不是主动暴露不确定性。

本文评述：这与程序合成领域的经典观察一致——仅用“输入-输出对”训练，模型难以学会中间推理；引入“执行反馈”后，合成成功率显著提升。布局生成同理，若能把“渲染结果与约束校验”作为反馈信号回灌，模型的表现会有质的变化。这也是后文“后处理校验”方法论的立足点。

2.3 一个可检验的推论

如果上述分析成立，那么可以推出一个可检验的预测：当布局约束被显式写成“可判定的规则”时，模型的表现应显著优于只给“目标描述”时。例如，与其说“帮我把报表排得好看点”，不如说“冻结线 y 坐标必须小于切片器最小 y 坐标，且两者不相交”。前者是模糊目标，后者是可判定约束。后文的实战部分，正是围绕“把模糊目标翻译成可判定约束”展开的。

三、工程解法：提示词约束、模板注入与后处理校验

方法论的骨架可以概括为三层防御：事前用提示词把约束说死，事中用模板把结构锁死，事后用校验把错误拦住。三层各自独立生效，叠加后能把布局事故率压到可接受范围。下面逐层给出可直接复用的操作路径。

3.1 第一层：把布局约束写成“可判定的提示词”

操作要点是把“好看”“合理”这类形容词，替换成带数值、带比较关系的硬约束。下面是一段可直接复用的提示词模板，适用于 Excel VBA、ECharts、Power BI 主题 JSON 等场景：

你是一名报表布局工程师。请生成 [目标产物]，并严格遵守以下约束：
1. 冻结窗格锚点 (row, col) 必须满足：row <= 表头行数，col <= 数据区最右列；
2. 切片器/图例等浮动对象的最小外接矩形，不得与冻结线相交；
3. 所有文本标签的估算宽度（字符数 × 字号 × 0.6）不得超过容器宽度；
4. 若任一约束无法同时满足，请显式输出 CONFLICT 并说明冲突项，不要静默取舍。
输出格式：先给约束满足性自检表，再给代码。

关键在最后一条：强制模型在冲突时“报错而非硬编”。预期结果是模型先输出一张自检表，逐条标注 PASS/FAIL，再给代码。常见错误是模型忽略“估算宽度”这类需要计算的约束，直接宣称全部满足——这时需要第二层兜底。

3.2 第二层：模板注入，把“自由发挥”关进笼子

与其让模型从零生成整段配置，不如给它一个“骨架 + 插槽”，只让它填数据相关的部分。以 ECharts 为例，可以把 grid、legend、title 的坐标全部写死，只留 series.data 和 xAxis.data 作为插槽：

const BASE_OPTION = {
  grid:   { left: 64, right: 32, top: 72, bottom: 56, containLabel: true },
  legend: { top: 12, left: 'center', itemGap: 16 },
  title:  { left: 16, top: 8, textStyle: { fontSize: 14 } },
  tooltip: { trigger: 'axis' }
};
// 模型只需返回 { xAxisData: [...], seriesData: [...] }
function buildChart(payload) {
  return {
    ...BASE_OPTION,
    xAxis: { type: 'category', data: payload.xAxisData },
    yAxis: { type: 'value' },
    series: [{ type: 'bar', data: payload.seriesData }]
  };
}

预期结果是布局部分完全确定，模型只影响数据。常见错误是把模板也给模型“参考”，结果它顺手把 grid.left 改成了 20——所以模板要以“不可修改的常量”形式注入，并在提示词中明确“禁止修改 BASE_OPTION”。

3.3 第三层：后处理校验，用代码做“几何体检”

无论提示词多严，都要假设模型会犯错。校验层的职责是把“肉眼才能发现的重叠”变成“代码可判定的矩形相交”。核心算法就是轴对齐包围盒（AABB）相交检测，复杂度 O(n²)，对报表级元素数量完全够用：

function overlaps(a, b) {
  return !(a.x + a.w <= b.x || b.x + b.w <= a.x ||
           a.y + a.h <= b.y || b.y + b.h <= a.y);
}
// boxes: [{id, x, y, w, h, kind}]
function auditLayout(boxes) {
  const issues = [];
  for (let i = 0; i < boxes.length; i++) {
    for (let j = i + 1; j < boxes.length; j++) {
      if (overlaps(boxes[i], boxes[j])) {
        issues.push({ pair: [boxes[i].id, boxes[j].id], type: 'OVERLAP' });
      }
    }
  }
  return issues;
}

预期结果是拿到一个 issue 列表，空列表即通过。常见错误是只检测“同层元素”，忘了浮动对象与冻结线这类“跨层”关系——冻结线不是矩形而是水平线，需要单独写一条“线段与矩形相交”的判断。本文评述：校验层的价值不在于算法多复杂，而在于它把“布局正确性”从主观判断变成了可回归的测试用例，这是工程化的分水岭。

四、实战演练：从零搭一套“布局可验证”的生成流水线

下面把三层防御串成一条可运行的流水线。环境：Node.js 18+、Playwright 1.40+（用于真实渲染取包围盒）、任意支持函数调用的模型 API。最终效果是：输入一句需求，输出一张图表，并附带一份布局体检报告。

4.1 步骤一：定义元素清单与约束

操作：先用 JSON 描述“有哪些元素、各自约束是什么”。预期结果：得到一份机器可读的布局契约。常见错误：把约束写成自然语言，导致后续无法自动判定。

{
  "elements": [
    { "id": "title",  "kind": "text",   "anchor": "top-left" },
    { "id": "legend", "kind": "float",  "anchor": "top-center" },
    { "id": "plot",   "kind": "canvas", "anchor": "center" }
  ],
  "constraints": [
    { "type": "no-overlap", "a": "legend", "b": "plot" },
    { "type": "inside",     "child": "plot", "parent": "canvas" }
  ]
}

4.2 步骤二：调用模型生成配置

操作：把 3.1 的提示词模板与 4.1 的契约一起送入模型，要求它返回 ECharts option。预期结果：得到一段可渲染的 JSON。常见错误：模型返回带注释的“伪 JSON”，需在解析前做一次清洗（去注释、去尾逗号）。

4.3 步骤三：真实渲染并提取包围盒

操作：用 Playwright 打开一个空白页，注入 ECharts 与 option，渲染后通过 DOM 查询取各元素 getBoundingClientRect()。预期结果：拿到每个元素的真实 x/y/w/h。常见错误：在图表动画未结束时取坐标，得到中间态——需等待 finished 事件后再取。

const { chromium } = require('playwright');
async function measure(option) {
  const browser = await chromium.launch();
  const page = await browser.newPage({ viewport: { width: 900, height: 560 } });
  await page.setContent('<div id="c" style="width:900px;height:560px"></div>');
  await page.addScriptTag({ path: 'echarts.min.js' });
  const boxes = await page.evaluate((opt) => {
    const chart = echarts.init(document.getElementById('c'));
    chart.setOption(opt);
    return new Promise(res => {
      chart.on('finished', () => {
        const rect = id => {
          const el = document.querySelector(id);
          const r = el.getBoundingClientRect();
          return { x: r.x, y: r.y, w: r.width, h: r.height };
        };
        res({ plot: rect('canvas'), legend: rect('div[class*=legend]') });
      });
    });
  }, option);
  await browser.close();
  return boxes;
}

4.4 步骤四：跑校验并自动回修

操作：把包围盒送入 3.3 的 auditLayout，若有 issue，则把 issue 列表拼进下一轮提示词，要求模型“只修冲突项，不动其他”。预期结果：通常 1–2 轮即可收敛。常见错误：把整段配置重新生成，导致已修好的部分又被改坏——务必限定修改范围。

拓展阅读：ECharts 官方配置手册对 grid 与 containLabel 的说明见 ECharts 配置项文档；Excel 冻结窗格的官方说明见 Microsoft 支持；Playwright 的截图与元素定位教程见 Playwright 官方文档。

五、排错清单与验证方法

把常见故障整理成一张可逐条勾选的清单，配合验证方法使用。下表为笔者基于公开案例与复现记录整理的排错表（整合数据，非严格统计）：

验证方法的核心原则是“可回归”：把每次事故都沉淀成一条校验用例，下次生成时自动跑。本文评述：布局问题的根治不靠“更聪明的模型”，而靠“更笨但更可靠的检查”。模型负责生成，代码负责守门，这个分工在可预见的未来都不会过时。

六、总结与前沿预判

回到标题里的那个事故：Copilot 把冻结窗格加在切片器中间，表面看是“模型不够聪明”，深层看是“我们用语言模型的方式要求它做几何求解”。本文的主线——AI 生成元素清单，人类需要约束满足后的几何布局——解释了为什么“差一口气”会反复出现，也指明了工程上的出路：把模糊目标翻译成可判定约束，用模板锁住结构，用校验拦住错误。

前沿预判方面，笔者认为接下来两年会出现两个明显趋势。其一，可视化库会原生提供“布局约束声明”能力，把 AABB 校验、锚点关系内置为配置项，而不是让每个团队自己写校验脚本。其二，模型侧会更多采用“生成-渲染-反馈”的闭环训练，把渲染结果的约束满足性作为奖励信号。这两条路径并不互斥，前者降低工程门槛，后者提升模型上限，合流之处就是“AI 生成的图表终于不差那一口气”的时刻。

主要参考文献

1. Apache ECharts 官方文档. 配置项手册（grid / legend / containLabel）. 2024. https://echarts.apache.org/zh/option.html
2. Microsoft Support. 冻结窗格以锁定行和列. 2024. https://support.microsoft.com/zh-cn/office/
3. Playwright Documentation. Locators and Screenshots. 2024. https://playwright.dev/docs/intro
4. Chen M, Tworek J, et al. Evaluating Large Language Models Trained on Code. arXiv:2107.03374, 2021.
5. Austin J, Odena A, et al. Program Synthesis with Large Language Models. arXiv:2108.07732, 2021.
6. Li Y, Choi D, et al. Competition-level Code Generation with AlphaCode. Science, 2022.
7. Wu T, Jiang E, et al. AI Chains: Transparent and Controllable Human-AI Interaction. CHI, 2022.
8. Satyanarayan A, Moritz D, et al. Vega-Lite: A Grammar of Interactive Graphics. IEEE TVCG, 2017.

说明：文中涉及案例归类与排错表为笔者基于公开论坛帖、开源 issue 与复现记录的整合数据，非严格抽样统计；参考文献总览 60 余篇（含近三年文献占比过半），此处仅列主要 8 篇，引用请以原始文献为准。