用 C# 从 Excel 数据生成 Word 文档

从 Excel 数据生成 Word 文档，是指把电子表格的行作为数据源，生成一个或多个结构化的 Word 文件，通常借助模板或一套文档生成流程来完成。传统做法是用 Word 邮件合并：把 Excel 列映射到 .docx 模板中的域，让 Word 按行各输出一份文档。同样的任务可以用文档 SDK 在 C# 中自动化，也可以进一步交给一个 AI 文档智能体，把需求固化为一段自然语言指令。本文比较这几条路线，说明邮件合并在哪些场景下力不从心，并演示一个基于 Spire.Agent.Office（面向 Office 文档的 AI 智能体 SDK）的可运行 C# 示例。

快速导航

• 从 Excel 数据生成 Word 文档，到底指什么？
• 传统方式：从 Excel 到 Word 的邮件合并
• .NET 中从 Excel 生成 Word 文档的三种自动化方式
• 用 C# 从 Excel 生成个性化 Word 文档
• 常见问题

1. 从 Excel 数据生成 Word 文档，到底指什么？

这个说法听起来接近”把 Excel 转换成 Word”，但意图不同。转换 .xlsx 到 .docx 只改变文件格式，内容大致保持不变。从 Excel 数据生成 Word 文档则是构建新的文档，其内容来源于电子表格中的单元格：每位客户一份订单表、每个区域一份月度报告、根据地址列表批量生成的信函或标签、根据订单表生成的一组发票。

这类需求的基本形态几乎总是一样：

用一句实在的话来说就是：”我有一张 Excel 表，记录了客户及其订单；我需要为每位客户生成一份 Word 文档，包含他们的信息、商品明细和总额。”关键在于”来源于”三个字：文档内容来自数据，所以这是”数据到文档”的生成，而非格式切换。

这正是本文要解决的问题。下文围绕满足这一需求的不同途径展开，以及应该在何时停止手工连线字段。

2. 传统方式：从 Excel 到 Word 的邮件合并

在 UI 层面，对于”把这张 Excel 列表变成多份 Word 文档”，默认答案是 Word 邮件合并。大多数人在检索这项任务时想到的就是这个功能，微软也为它提供了逐步操作指南。其机制简单且广为人知：

你在信函模板中放一个类似 «CustomerName» 的域，把它绑定到 Excel 数据源的 Customer 列，运行合并，Word 就会按行输出文档，并用对应值替换该域。由于行数可能多达数千，它把”打开文件、复制文本、改名字”变成了一次零代码的批量操作。

邮件合并只擅长一种工作形态：把这个列放进那个域，反复多次。信函、信封、标签和布局固定的通知是它的主场。它在 Office 内运行、无需编程，对于那些稳定、只含域的文档，它确实是合适的工具。

3. 邮件合并的局限

文档一旦不再是带空位的固定表单，而必须依数据而定，局限就出现了。邮件合并只做值的替换，它不决定结构、不推理内容、也不生成任何新东西。

对比两类请求。第一类是邮件合并能处理的：

“把客户姓名放进姓名位、地址放进地址位、订单放进订单明细。”

第二类才是大多数真实报表实际提出的需求：

“读取这个 Excel 工作簿，分析每位客户的数据，生成一份包含商品明细与总额的个性化报告，加上一段购买模式摘要，并把每个结果保存为独立的 Word 文档。”

第二类请求在邮件合并的三大假设上全部落空：

• 结构多变。 只有三行明细的客户，和三十行的客户，需要的文档正文不同。合并域假定布局固定、空位固定；它们不会让表格按数据所需扩展行数。
• 内容需要计算，而不是复制。 “概括购买模式”和”标记高价值客户”产生的文字与判断，没有任何一列能提供，也就没有可绑定的源字段。
• 输出是成批的真实文件。 每条记录都应该是独立命名的一份 Word 文档，而且整个流程要在应用内无人值守地运行，而不是靠 Office 向导。

客观地说，这就是邮件合并的真实定位：它在字段映射上很出色，但当文档结构、内容或输出逻辑必须随数据变化时，它就不那么合适了。更深层的需求——把数据变成文档——是一个生成问题，也正是下面几条自动化路线要解决的起点。

4. 把需求转化为指令：智能体方式

适合这个正确版问题的方案是 AI 文档智能体：一个架设在确定性文档引擎之上的自然语言层。你不必逐一列举模板字段和逐字段的代码，只需描述输出结果；智能体能够处理传统邮件合并难以表达的需求——读取数据、塑造结构、撰写分析——而文档引擎则保证输出真实、格式正确的 .docx（或 PDF）。

把它看成一个链路会更直观：

传统邮件合并难以表达的那些环节——尤其是中间的三个——恰恰是智能体最能发挥价值的地方。它能解读一列意味着什么（”Total Amount””Sales””Net”这三个表头可能命名的是同一个概念）、为每条记录塑造文档结构，并撰写摘要段落。你提供的是一句话，而不是一张字段映射表。

请带着这个信息读完全文：邮件合并把 Excel 列映射到 Word 域；AI 智能体从需求生成文档。 前者是一次值替换步骤，后者才是需求的本来面目。

5. .NET 中从 Excel 生成 Word 文档的三种自动化方式

选对路线比写代码更重要，因为每条路线的成本曲线不同。对于需要这种工作流的 .NET 应用，现实的选择有三类：

一个能决定大多数情况的捷径：

• 形态从不改变、每列一个域、批量信函——邮件合并难逢敌手。
• 形态不变，但需要在代码中实现，要求确定且可测试——用 SDK 字段绑定循环。
• 文档必须随数据变化、需要分析、或频繁改动——这正是 AI 智能体回收成本的地方，因为改动的成本往往可以降为更新指令，而不是修改代码里的映射和版式逻辑。

6. 用 C# 从 Excel 生成个性化 Word 文档

“每条记录一份 Word 文档”需求的一个具体可用版本，是客户订单摘要。输入是一张客户订单工作簿和一个轻量 Word 模板；输出是每位客户一份个性化文档。完整的配置——token、包和项目接线——在集成入门教程中有说明；这里我们聚焦生成调用本身。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

using Spire.Doc;
using Spire.Agent.Office.AI;
using Spire.Agent.Office.Extensions;

AIOptions options = new AIOptions
{
    SpireToken = spireToken,
    WorkDir = @"C:\order-ops\output",   // 生成的文档写入的文件夹
    TimeoutMs = 300000
};

using (Document doc = new Document())
{
    // 模板提供逐记录锚点；工作簿是数据源。
    doc.LoadFromFile(@"C:\order-ops\templates\order-summary-template.docx");

    // savePath = null：一条指令为每条记录生成一份文档，
    // 写入 WorkDir 输出文件夹，无需对行写 C# 循环。
    AIResult result = doc.AI(options).ExecuteInstruction(
        doc,
        "读取 Q3-orders.xlsx 中的客户订单数据。逐行生成一份独立的 " +
        "Word 订单摘要，每位客户一份。包含他们的联系信息、" +
        "每一条商品明细（数量与金额）、订单总额，以及一段购物模式摘要。" +
        "将总额超过 50,000 的客户标记为高价值。将每份文档保存为独立文件，" +
        "文件名以 output_ 开头，后接客户名称（例如 " +
        "output_acme-order-summary.docx）。",
        null,
        new[] { @"C:\order-ops\input\Q3-orders.xlsx" });

    if (result == null || !result.Success)
        throw new InvalidOperationException($"Generation failed: {result?.ErrorMessage}");
}

自己运行时有三点需要注意。第一，指令正是生成逻辑所在之处：分析（”购买模式摘要”）、条件逻辑（”标记总额超过 50,000 的客户”）和逐记录结构（”每一项商品明细”）。第二，工作簿要整洁：第一行为表头、每行一条记录、没有空行或合并的表头单元格——这与 Word 自带数据源的要求一致。第三，基础文档锚定了输出的版式；一个轻度结构化的基础文档能成为智能体塑造每条记录结构的有用起点。如果基础文档完全空白，同样的指令则会生成一份合并文档。

这里有一条命名规则要紧：智能体写入 WorkDir 的文档必须以 output_ 前缀开头，否则 SDK 不会把它们视为生成的文件。这就是为什么上面的指令要求生成 output_acme-order-summary.docx 这样的文件名，而不是裸的客户名。

保存目标或文件名模式上的 .docx 扩展名决定了输出格式；把同样的指令指向 .pdf，智能体就会导出完全相同的文档用于分发，无需单独的渲染步骤。

关键 API 调用

• Document.AI(options)——把 AI 文档处理器挂载到 Word 文档对象上
• ExecuteInstruction(doc, instruction, savePath, attachments)——执行生成；null 作为 savePath 表示”写入 WorkDir“，工作簿通过 attachmentPaths 一并传入
• AIResult.Success / AIResult.ErrorMessage——校验执行结果并暴露失败信息

7. 没有智能体时，你需要写什么

作为对照，同一任务走 SDK 字段绑定路线，则需要显式地完成所有步骤。下面的代码有意做了简化，以展示涉及的应用程序逻辑量；生产实现还需要加载并分组工作簿数据：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

using Spire.Doc;
using Spire.Xls;

// 形态固定没问题；每一种变化都意味着更多接线。
foreach (DataRow row in customersTable.Rows)
{
    using (Document doc = new Document())
    {
        doc.LoadFromFile(@"templates\order-summary-template.docx");

        // 逐个锚点查找替换……
        doc.Replace("{{CustomerName}}", row["Customer"].ToString(), true, true);
        doc.Replace("{{TotalAmount}}", row["Amount"].ToString("C"), true, true);

        // 明细行在第二张工作表：你要按客户手工关联，
        // 创建表格，并插入到书签处……
        // "标记高价值客户"的规则是你维护的一个 if/else，
        // 而每名客户的摘要段落是手工编写的模板。
        doc.SaveToFile($@"out\{row["Customer"]}-order-summary.docx");
    }
    // ……每一种新规则、列或版式变化，都意味着改这里并重新编译。
}

智能体并没有让人不再需要代码——它省去的是映射与版式代码。区别在于逻辑放在哪里：是放在列索引和查找替换里，还是放在一句业务人员能读能改的话里。当业务规则或文档结构频繁变化时，自然语言方式能减少需要维护的映射与版式代码量。这种”模板 + 数据”模式不止适用于订单摘要：用 Spire.Agent.Office 批量生成合同就演示了把同一条指令、逐记录生成一份文档的流程应用到合同上的做法。

8. AI 的边界与应用逻辑的起点

一条有用的边界，不是”AI 能做什么、不能做什么”，而是应用应该继续负责什么。文档生成智能体架设在确定性代码之上，它并不取代代码。

与理解电子表格无关的部分，仍由你的应用负责：

• 文件发现与访问——找到工作簿、检查权限、暂存输入
• 工作流调度——任务何时运行、由什么触发、以什么顺序执行
• 数据源管控——哪个工作簿是合法输入，它来自哪里
• 错误处理与重试——文件缺失或运行失败时怎么办
• 最终审核——生成文档在交付前由人工复核

智能体负责语义性的环节：

• 理解——从不同的工作簿中读懂每一列的含义
• 规划结构——确定文档需要多少章节和行
• 分析——把订单数据转化为摘要和高价值标记
• 组织——根据需求组装个性化 Word 文档

把确定性的”管道”留在代码里，那里可测试、可审计；把语义生成交给智能体。双方各司其职。用 C# 做 AI 合同审查从另一侧展示了同样的分工：智能体负责”审查文档内容”这一语义环节，而应用负责其周围的确定性文件处理。

9. 常见问题

它能替代 Word 邮件合并吗？

它不是一个可直接替换的方案，而是把同一件事做得更彻底。邮件合并把 Excel 列映射到固定的 Word 域，这对形态稳定的信函足够。AI 智能体也能做这件事，而且还能按内容读取工作簿、逐记录塑造结构、加入分析并撰写正文。对于简单、形态固定的输出，邮件合并仍是好工具；当文档必须随数据变化时，智能体承担的工作更多。

如何从 Excel 数据生成多份 Word 文档？

把工作簿作为附件传入，保存路径设为 null，并把 AIOptions.WorkDir 指向一个输出文件夹。一条逐行处理的 ExecuteInstruction 指令，就能让智能体为每条记录生成一份独立文档，分别保存到该文件夹。逐记录批量生成无需再对行写 C# 循环。

不用邮件合并，能从 Excel 生成 Word 文档吗？

可以。在 C# 中你可以直接用 SDK 绑定模板，也可以把工作簿交给 AI 智能体，让它从自然语言指令中读取数据，并返回真实的 .docx 或 PDF。邮件合并只是其中一条路线，并非唯一，而且一旦文档需要分析或条件章节，它就是最不灵活的一条。

邮件合并和 AI 文档生成有什么区别？

邮件合并把定义好的域绑定到定义好的列：Excel 列进、Word 域出。AI 文档生成则把请求和数据放在一起理解，所以它能解读每一列的含义并据此塑造文档结构、生成条件性或分析性内容，并能用一条指令组装多份文档。前者是映射步骤，后者是生成任务。

能在 C# 中从 Excel 文件生成个性化 Word 文档吗？

可以。把 Word 模板或空白文档加载到 Spire.Doc，附加 Excel 工作簿，再调用 ExecuteInstruction 描述个性化输出。智能体会读取每条记录并生成与之一一对应的文档，可逐记录保存，也可合并为一份文件，全程都在你自己的 .NET 应用内完成。

AI 智能体能利用 Excel 数据生成 Word 文档吗？

可以。Spire.Agent.Office 把语言模型与确定性的 Word、Excel 层配对，因此指令能被理解，结果仍是团队可以打开、排版和分发的真实 Word 文件。智能体解读的是电子表格的内容，而非依赖固定的列映射，这正是异构输入能生效的原因。

准备好自动化你的 Word 生成了吗？

如果你的工作流是”把 Excel 数据变成个性化 Word 文档”，最快的路径就是描述输出结果，其余交给智能体。跟着集成入门教程，在 .NET 中跑通你的第一个指令驱动的 Word 工作流。

延伸阅读

• 用 Spire.Agent.Office 生成各种 Word 模板——把同样的生成模式应用到不同的 Word 模板
• 用 Spire.Agent.Office 自动化学生成绩分析与排名——一个 Excel 侧的工作流，为本文生成的文档提供数据
• Spire.Agent.Office 产品概览——覆盖所有 Office 文档格式的 AI 智能体 SDK