C# 中基于 AI 的 Word 格式设置、摘要和索引生成

组织通常会随时间积累成百上千份 Word 文档。这些文件可能来自不同的部门、员工、供应商或旧系统,导致字体、标题结构、编号、间距、页眉和其他格式不一致。

为发布、迁移或归档准备此类文档不仅仅是一项简单的格式设置任务。在许多情况下,组织还需要识别每份文档的内容、提取关键元数据、创建简明摘要,并将结果整理成可搜索的文档索引。

传统的 Word 自动化可以很好地处理固定的格式规则,但当文档结构各异时,它就会变得困难重重。基于 AI 的方法则可以先理解内容的逻辑角色——例如标题、标题层级、正文、日期和文档类型——然后应用相应的文档操作。

在本文中,我们将使用 Spire.Agent.Office for .NET 在 C# 中构建一个三阶段的 Word 处理工作流:

Word 文档 → 格式标准化 → 元数据和摘要提取 → 文档索引

为什么基于 AI 的 Word 文档标准化很重要

标准化一组 Word 文档并不总是像将每个段落设置为相同字体那么简单。

一个典型的组织可能有如下文档:

1
2
3
4
5
Input/
├── 员工差旅政策.docx
├── 供应商入驻指南.docx
├── 安全事件报告.docx
└── 远程工作规范.docx

即使这些文档涉及相似的业务流程,它们的内部结构也可能大相径庭。

例如,一份文档可能使用真正的 Word 标题 1 样式作为章节标题,而另一份文档只是使用粗体的 16 磅文本。有些文档可能使用编号章节,如:

1
2
3
1. 制定目标
2. 适用范围
3. 部门职责

而其他文档可能使用不一致的编号,如:

1
2
3
I. 制定目标
二、 适用范围
3) 部门职责

传统的文档自动化通常需要开发者检查段落位置、样式或文本模式,并为每种变化编写规则。

AI 辅助文档处理改变了这种方法。开发者无需指定“第 3 段应为标题”,而是可以描述期望的结果:

识别文档标题和标题层次结构,规范化标题样式和编号,并保留原始内容。

AI 层负责解释文档结构,而底层的 Word 文档引擎则执行实际的文档处理。

这使得该方法对于半结构化业务文档集特别有用,这些文档内容不同,但期望的输出标准是一致的。

本示例将自动化的内容

我们的示例工作流包含三个处理阶段。

阶段 1:标准化 Word 格式

每份源文档都将根据共享的企业样式进行分析和重新格式化。处理包括:

  • 规范化字体和字号
  • 识别文档标题
  • 应用一致的标题层级
  • 规范化标题编号
  • 标准化段落间距
  • 添加通用页眉
  • 在页脚添加页码
  • 保留原始文本、表格、图像和超链接

结果是每份输入文档都得到标准化版本。

阶段 2:提取元数据和摘要

然后对标准化后的文档逐一进行分析,提取如下信息:

  • 文档标题
  • 部门
  • 文档类型
  • 生效日期或发布日期
  • 关键词
  • 摘要

每份结果都保存为一个小型的结构化 Word 元数据文档。

阶段 3:构建文档索引

最后,将元数据文件合并并转换为单个 Word 文档索引。

完成的索引可以包含类似如下信息:

序号 标题 部门 类型 日期 摘要
1 员工差旅政策 人力资源部 政策 2026年7月15日 规定了差旅审批和报销要求。
2 供应商入驻指南 采购部 流程 2026年6月3日 描述了注册和审批新供应商的流程。
3 安全事件报告 信息技术部 报告 2026年8月8日 总结了安全事件及应对措施。

这不仅生成了更整洁的 Word 文件,还提供了整个文档集的有用概览。

为 C# 设置 Spire.Agent.Office

首先,创建一个 .NET 项目并通过 NuGet 安装 Spire.Agent.Office

您可以通过 Visual Studio 的 NuGet 包管理器安装该包,或使用 .NET CLI:

1
dotnet add package Spire.Agent.Office

然后导入所需的命名空间:

1
2
3
4
5
using System;
using System.IO;
using Spire.Agent.Office.AI;
using Spire.Agent.Office.Extensions;
using Spire.Doc;

AI 文档处理遵循一个简单的模式。

首先,使用 SpireToken 配置一个 AIOptions 实例:

1
2
AIOptions options = new AIOptions();
options.SpireToken = "your SpireToken";

您可以 联系我们申请用于测试的临时 SpireToken。获取令牌后,在调用 AI 处理 API 之前将其赋值给 SpireToken 属性。

接下来,加载 Word 文档并创建 AIDocumentProcessor

1
2
3
4
5
6
7
8
9
10
11
12
using (Document doc = new Document())
{
doc.LoadFromFile("input.docx");

AIDocumentProcessor processor = doc.AI(options);

processor.ExecuteInstruction(
doc,
"您的自然语言指令",
"output.docx"
);
}

关键在于指令。我们无需手动编写一长串 Word API 调用,而是描述文档应呈现的样子,让代理执行相应的操作。

在以下部分,我们将把这种方法应用于整个 Word 文件目录。

使用 AI 标准化 Word 格式

假设从不同部门收集的文档使用了不一致的字体、标题、编号和页面布局。

我们希望它们都遵循相同的企业文档样式:

  • 所有文本使用 宋体 字体
  • 正文使用 12 磅
  • 文档标题使用 20 磅粗体
  • 标题 1 使用 16 磅粗体
  • 标题 2 使用 13 磅粗体
  • 一致的多级编号
  • 1.15 倍行距
  • 企业页眉
  • 居中页码
  • 不更改原始措辞

以下代码处理输入目录中的每个 .docx 文件,并将标准化版本保存到新目录。

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
33
34
35
36
37
38
39
using System;
using System.IO;
using Spire.Agent.Office.AI;
using Spire.Agent.Office.Extensions;
using Spire.Doc;

string inputFolder = @"E:\Documents\Input";
string outputFolder = @"E:\Documents\Standardized";
string spireToken = "your SpireToken";
Directory.CreateDirectory(outputFolder);

string aiRule = """
分析此 Word 文档的结构,并根据以下企业文档规则标准化其格式:

1. 保留所有原始措辞。不要重写、总结、缩短或删除任何文档内容。
2. 使用 宋体 作为默认字体,正文字体大小为 12 磅。
3. 识别主文档标题并将其格式化为 20 磅粗体。
4. 识别逻辑标题层次结构并应用适当的 Word 标题样式。标题 1 使用 16 磅粗体,标题 2 使用 14 磅粗体。
5. 将章节编号规范化为一致的层次结构,例如适当时使用 1.、1.1 和 1.1.1。
6. 普通正文段落使用 1.15 倍行距,并保持段落间距视觉上一致。
7. 在文档页眉中添加“企业文档库”。
8. 在页脚中添加居中页码。
9. 保留所有现有表格、图像、超链接和其他文档对象。
10. 保持整体文档结构和原始含义不变。
""";

var aiOpts = new AIOptions { SpireToken = spireToken };

foreach (var file in Directory.GetFiles(inputFolder, "*.docx"))
{
var fileName = Path.GetFileName(file);
var savePath = Path.Combine(outputFolder, fileName);

using var doc = new Document();
doc.LoadFromFile(file);

var res = doc.AI(aiOpts).ExecuteInstruction(doc, aiRule, savePath);
Console.WriteLine(res.Success ? $"已处理: {fileName}" : $"失败: {fileName} - {res.ErrorMessage}");
}

指令中一个重要细节是要求 识别逻辑标题层次结构

这与简单更改每个粗体段落的字体不同。代理可以分析段落所代表的内容,并确定其是作为文档标题、主要章节标题、小节还是普通正文。

对于文档管理工作流,正确的标题样式特别有用,因为它们可以改善导航、自动目录生成、PDF 书签、可访问性以及后续文档解析。

另一个重要规则是:

保留所有原始措辞。

格式设置和内容重写通常应视为不同的任务。当此阶段的目标是文档标准化时,AI 不应同时重写或总结源文本。

执行后,输出目录包含标准化副本:

1
2
3
4
5
Standardized/
├── 员工差旅政策.docx
├── 供应商入驻指南.docx
├── 安全事件报告.docx
└── 远程工作规范.docx

以下示例展示了格式不一致的 Word 文档在 AI 标准化前后的对比。

标准化 Word 格式

提取元数据并生成文档摘要

格式标准化后,下一步是了解每份文档的内容。

手动打开数百个文件并记录其标题、部门、日期、类别和摘要非常耗时。这是一项 AI 文档理解能力尤为有用的任务。

在本示例中,我们将从每份文档中提取六个字段:

  • 标题
  • 部门
  • 文档类型
  • 日期
  • 关键词
  • 摘要

指令要求输出可预测的结构,而不是返回自由形式的散文。这使得结果更易于后续处理。

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
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
using System;
using System.IO;
using Spire.Agent.Office.AI;
using Spire.Agent.Office.Extensions;
using Spire.Doc;

string inputFolder = @"E:\Documents\Standardized";
string outputFolder = @"E:\Documents\Metadata";
string spireToken = "your SpireToken";

Directory.CreateDirectory(outputFolder);

string aiRule = """
分析此 Word 文档并创建一份简明的元数据报告。

从实际文档内容中提取以下信息:
- 标题
- 部门或负责的业务职能
- 文档类型,如政策、流程、报告、指南或备忘录
- 生效日期或发布日期
- 3 到 5 个关键词
- 约 50 到 80 字的摘要

创建一个仅包含这些字段的新简明文档。
请使用以下确切标签:

标题:
部门:
文档类型:
日期:
关键字:
总结:

不要编造无法从源文档合理确定的信息。如果特定日期或部门不可用,请使用“未指明”。确保摘要实事求是,仅基于源文档。
""";

var aiOpts = new AIOptions { SpireToken = spireToken };

foreach (var file in Directory.GetFiles(inputFolder, "*.docx"))
{
var fileName = Path.GetFileNameWithoutExtension(file);
var savePath = Path.Combine(outputFolder, $"{fileName}_Metadata.docx");

using var doc = new Document();
doc.LoadFromFile(file);

var res = doc.AI(aiOpts).ExecuteInstruction(doc, aiRule, savePath);
Console.WriteLine(res.Success ? $"元数据已提取: {fileName}" : $"失败: {fileName} - {res.ErrorMessage}");
}

生成的元数据文档如下所示:

提取元数据并生成文档摘要

使用固定标签的要求很重要。

如果提示只是简单地说“总结文档”,不同的文档可能会产生差异很大的输出结构。要求使用一致的字段可以大大简化将中间文件合并为最终索引的过程。

指令还明确告诉代理不要编造缺失的元数据。对于业务记录,"未指明" 通常比猜测文档从未声明的部门或日期更有用。

从多个 Word 文件构建文档索引

此时,我们为每份已处理的文档都生成了一个元数据文件:

1
2
3
4
5
Metadata/
├── 员工差旅政策_Metadata.docx
├── 供应商入驻指南_Metadata.docx
├── 安全事件报告_Metadata.docx
└── 远程工作规范_Metadata.docx

最后一步是将这些独立的元数据文件整合为一个基于 Word 的文档索引。

我们无需手动打开每个元数据文档、提取其中的文本,然后在 C# 中合并结果,而是可以直接通过 attachments 参数将所有元数据文件传递给 Spire.Agent.Office。AI 代理会读取所附的文档,从每个文档中提取标记字段,并创建一个包含合并索引的新 Word 文档。

当 AI 任务依赖于多个辅助文件,而非单个主输入文档时,attachments 参数非常有用。在此示例中,没有需要修改的现有 Word 文档。因此,我们创建一个空的 Document 对象,并将元数据文件作为生成最终索引的信息来源。

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
33
34
35
36
37
38
39
using System;
using System.IO;
using Spire.Agent.Office.AI;
using Spire.Agent.Office.Extensions;
using Spire.Doc;

string metadataFolder = @"E:\Documents\Metadata";
string outputPath = @"E:\Documents\文档索引.docx";
string spireToken = "your SpireToken";
var attachments = Directory.GetFiles(metadataFolder, "*_Metadata.docx");

string aiRule = """
读取附件中提供的所有元数据文档,并创建一个合并的 Word 文档索引。

在文档顶部创建标题“文档索引”。

创建一个包含以下列的表格:
序号 | 标题 | 部门 | 文档类型 | 日期 | 关键词 | 摘要

要求:
1. 为每个元数据文档创建一行。
2. 从 1 开始顺序编号。
3. 从每个附件中提取标记字段的值。
4. 保留提取的信息,不要编造缺失数据。
5. 当字段不可用时使用“未指明”。
6. 使表格标题加粗。
7. 摘要列比其他列更宽。
8. 使用适合内部文档登记册的简洁专业样式。
9. 生成仅包含最终文档索引的独立 Word 文档。
""";

var aiOpts = new AIOptions { SpireToken = spireToken };

using var doc = new Document();
var res = doc.AI(aiOpts).ExecuteInstruction(doc, aiRule, outputPath, attachments);

Console.WriteLine(res.Success
? $"文档索引已创建: {outputPath}"
: $"创建文档索引失败: {res.ErrorMessage}");

最终输出保存为:

1
文档索引.docx

现在,员工无需逐一打开每个原始文档,而是可以使用一个合并索引来快速了解有哪些文档可用,以及每个文件包含哪些内容。

从多个 Word 文件构建文档索引

这类索引在以下场景中尤其有用:将文件迁移到文档管理系统之前、准备内部知识库、审查遗留文档集合,或为长期保留而整理记录。

可靠 AI 文档处理的最佳实践

AI 使半结构化文档处理更加灵活,但可靠的结果在很大程度上仍然取决于任务的设计方式。

将格式设置与内容分析分离

避免要求代理在一个大指令中同时完成标准化格式、重写文本、总结文档和提取元数据。

这些是不同的操作,目标也不同。

更安全的工作流是:

1
2
3
4
5
6
7
8
9
10
11
原始文档

格式标准化

标准化文档

元数据提取

结构化元数据

文档索引

这也使问题更容易识别和调试。

明确定义格式规则

诸如以下指令:

使文档看起来专业。

留有过多的解释空间。

当一致性很重要时,请指定实际的企业规则:

1
2
3
4
5
6
宋体,正文 12 磅
文档标题 20 磅
标题 1 为 16 磅
标题 2 为 14 磅
1.15 倍行距
1. / 1.1 / 1.1.1 编号

同样的原则也适用于页眉、页脚、表格格式和页面布局。

保护原始内容

对于格式设置任务,请明确包含如下要求:

保留所有原始措辞。

以及:

不要重写、总结、缩短或删除文档内容。

在自动化批量处理期间,还应保留源文件,而不是覆盖它们。

实用的文件夹结构为:

1
2
3
4
5
Documents/
├── Input/
├── Standardized/
├── Metadata/
└── 文档索引.docx

请求结构化元数据

当提取的信息将被程序化地重复使用时,可预测的输出比创造性的输出更有价值。

不要使用:

告诉我这份文档是关于什么的。

而是使用固定模式:

1
2
3
4
5
6
标题:
部门:
文档类型:
日期:
关键字:
总结:

这大大简化了下游处理。

明确处理缺失信息

并非每份文档都包含部门名称、生效日期、文档编号或负责人。

告诉 AI 在信息缺失时应如何处理:

使用 “未指明” 而不是猜测。

这对于文档管理、法律、财务、合规和其他记录敏感的工作流尤其重要。

审查高重要性输出

在高风险工作流中,AI 生成的元数据和摘要不应自动被视为权威记录。

对于普通的内部文档组织,自动化结果可能就足够了。对于受监管的档案、法律记录、合规文件或官方保留系统,提取的字段和分类仍应根据组织的审查要求进行验证。

结论

批量 Word 处理通常涉及两个不同的问题。

第一个是 文档自动化 :更改字体、应用样式、创建页眉和页脚、管理编号和生成 Word 文件。

第二个是 文档理解 :确定内容所代表的含义、识别文档类型、查找日期和部门、提取关键词以及生成摘要。

当开发者确切知道要修改什么内容时,传统 Word API 非常高效。当文档不一致且软件必须先理解其结构再决定如何处理时,AI 辅助处理变得尤为有用。

在 C# 中使用 Spire.Agent.Office,可以将这两种能力结合到一个工作流中:

分析 → 标准化 → 提取 → 整理

在上述示例中,一个包含不一致 Word 文档的文件夹被转换为标准化的文档集、一组结构化元数据记录,并最终生成一个集中的 Word 文档索引。

相同的架构可以扩展到其他企业工作流,例如政策库、流程手册、合规文档、项目档案、人力资源记录、供应商文档和遗留文档迁移。

开发者无需手动逐一审查和整理文件,而是可以用自然语言定义所需的文档规则和信息结构,自动化工作流中的重复部分,同时仍然生成真实、可编辑的 Word 文档。