智能文档的三个方向：AI 写作工具的选型与避坑

智能文档的三个方向：AI 写作工具的选型与避坑

一、智能文档不是"AI 替你写"

市面上有 40 多个 AI 写作工具，从 Notion AI 到 Jasper，从 WPS AI 到飞书智能文档。但用一个简单的 Prompt 让 AI 输出一篇 3000 字的文章，结果往往是一篇"看起来像文章"的文字集合——结构松散、论述空洞、没有独特信息增量。

智能文档的落地不是"AI 替你写"这一种模式。在实际产品和技术选型中，有三个在工程上经过验证的方向。

二、方向一：AI 辅助写作 —— 最热门但最容易被错误使用

AI 辅助写作的工程难点不在"调用 LLM API"，而在"如何让 AI 生成的文本有信息增量"。一个没有信息增量的 AI 文章 = 废文。

常见错误 1：想用 AI 直接生成终稿

// 错误做法：让 AI 从零生成完整文章
async function generateArticle(topic: string): Promise<string> {
const prompt = `请写一篇关于"${topic}"的 3000 字技术文章。`;
// 结果：一篇看起来像话但毫无信息增量的文字
return callLLM(prompt);
}

正确做法：人写骨架，AI 填充血肉

interface ArticleStructure {
title: string;
sections: Array<{
heading: string;
keyPoints: string[]; // 人工确定的核心观点
codeExamples: string[]; // 人工准备的代码片段
dataPoints: string[]; // 人工收集的数据
}>;
}

async function assistWriting(structure: ArticleStructure): Promise<string> {
let article = `# ${structure.title}\\n\\n`;

for (const section of structure.sections) {
article += `## ${section.heading}\\n\\n`;

const prompt = `
你是技术文章协作助手。根据以下要求扩展段落：

核心观点：${section.keyPoints.join('；')}
参考代码：${section.codeExamples.join('\\n')}
支撑数据：${section.dataPoints.join('；')}

要求：
1. 围绕核心观点展开，不要偏离
2. 使用提供的代码和数据，不要编造
3. 每段不超过 200 字
4. 行文简洁，不写废话
`;

const expanded = await callLLM(prompt);
article += expanded + '\\n\\n';
}

return article;
}

// 关键区别：
// ❌ 让 AI 从标题生成全文 → 无信息增量
// ✅ 人工准备观点、代码、数据 → AI 负责语言组织和连贯性

常见错误 2：没有领域知识输入

// 好的辅助写作 = 用户知识 + AI 表达力
interface AssistedWritingInput {
// 用户提供：领域知识和判断
domainKnowledge: {
personalExperience: string; // 个人实践经验
dataAnalysis: string; // 数据分析结论
codeReview: string; // 代码审查发现
benchmarks: string; // 性能测试结果
};
// AI 负责：语言表达和组织
aiResponsibility: {
expandParagraph: (point: string, example: string) => string;
generateTransition: (prev: string, next: string) => string;
suggestAlternatives: (text: string) => string[];
checkReadability: (text: string) => { score: number; suggestions: string[] };
};
}

工具选型提示：

三、方向二：文档智能结构化 —— 最有工程价值的方向

将非结构化文档（PDF 合同、扫描件发票、手写笔记）中的信息提取为结构化数据，这是智能文档中 ROI 最高、技术挑战也最大的方向。

技术难点不在于 LLM，而在于三件事：

// 文档结构化管道的技术架构
interface DocumentStructuringPipeline {
// 层 1：文档解析
parser: {
// PDF 解析：表格、文字、图片位置
pdf: (buffer: Buffer) => Promise<PageLayout[]>;
// OCR：扫描件文字识别
ocr: (image: Buffer) => Promise<OCRResult>;
// 格式转换：Word → Markdown
convert: (buffer: Buffer, format: string) => Promise<string>;
};

// 层 2：版式理解
layoutAnalyzer: {
// 表格识别与合并（跨页表格）
detectTables: (pages: PageLayout[]) => TableRegion[];
// 标题层级还原
buildOutline: (pages: PageLayout[]) => Heading[];
// 图文关联
matchCaptions: (pages: PageLayout[]) => CaptionImagePair[];
};

// 层 3：信息抽取
extractor: {
// 关键字段抽取（合同金额、甲方乙方、签署日期）
extractFields: (text: string, schema: FieldSchema[]) => ExtractedField[];
// 实体识别（人名、公司名、金额、日期）
recognizeEntities: (text: string) => Entity[];
// 关系抽取（A 公司是 B 公司的供应商）
extractRelations: (text: string) => Relation[];
};

// 层 4：结构化输出
formatter: {
toJSON: (extracted: ExtractedData) => StructuredJSON;
toCSV: (extracted: ExtractedData) => string;
toDatabase: (extracted: ExtractedData) => Promise<void>;
};
}

// 关于表格跨页合并的关键问题
interface TableMergeStrategy {
// 问题：一个表格从第 1 页延伸到第 3 页
// 第 1 页：表头 + 前 5 行
// 第 2 页：中间 8 行（没有表头）
// 第 3 页：最后 3 行（没有表头）

// 策略 1：基于位置检测
// 如果下一页第一条内容是一行数据（有相同列数）且不是新标题 → 延续当前表格

// 策略 2：基于表头匹配
// 当检测到与当前表头结构相同的内容时 → 新表格的开始

// 策略 3：LLM 辅助判断
// 对于复杂情况，将连续两页的内容送给 LLM 判断是否是同一个表格
}

关键工程决策：

// 是否使用 LLM 做版式理解？
// LLM（如 GPT-4V）可以识别表格结构，但：
// – 速度：1 页耗时 3-5 秒，100 页 = 5-8 分钟
// – 成本：1 页约 $0.01-0.03，100 页 = $1-3
// – 准确性：对复杂表格的识别准确率约 85%

// 规则引擎 + LLM 的混合方案
function hybridTableRecognition(page: PageLayout): TableRegion[] {
// Step 1: 用规则引擎快速判断"这块区域可能是表格"
const candidates = ruleBasedTableDetection(page); // < 10ms

// Step 2: 对于简单表格（规则引擎置信度 > 0.9），直接输出
const highConf = candidates.filter(c => c.confidence > 0.9);

// Step 3: 只对复杂候选（置信度 < 0.9）使用 LLM
const lowConf = candidates.filter(c => c.confidence <= 0.9);
const llmResults = lowConf.length > 0
? callLLMVision(page.image, lowConf)
: [];

return […highConf, …llmResults];
}
// 这种混合方案将 LLM 调用量减少了 70%，总体准确率不低于纯 LLM 方案

选型建议：

四、方向三：文档知识库检索 —— RAG 在文档场景的垂直优化

将企业内部的所有文档（技术文档、产品手册、会议纪要、合同）构建为一个可检索的知识库，是智能文档最成熟的应用方向。

但这个方向的最大坑是：通用 RAG 框架（LangChain、LlamaIndex）在文档场景下效果不佳。

// 文档 RAG 的特殊挑战
interface DocumentRAGChallenges {
// 1. 文档层级丢失
// 普通切分将"第三章 第二节 第 3.2.1 小节"切成了 5 个独立的 chunk
// 丢失了它们之间的层级关系
hierarchyLoss: true;

// 2. 跨页引用断裂
// "如上表所示" —— 但这个"上表"在另一个 chunk 中
crossReferenceBreak: true;

// 3. 图文分离
// 文档中的"如图 3 所示"变成了无意义的占位文字
textImageSeparation: true;

// 4. 表格语义丢失
// 表格被切成纯文本后，列之间的对应关系消失
tableSemanticLoss: true;
}

// 文档场景的 RAG 优化策略
class DocumentAwareRAG {
// 策略 1：保持文档层级结构的切分
chunkWithHierarchy(doc: Document): Chunk[] {
const chunks: Chunk[] = [];
for (const section of doc.sections) {
const chunk: Chunk = {
text: section.content,
metadata: {
// 保留层级信息，用于检索时的上下文加权
path: section.path, // ['第三章', '第二节', '3.2.1']
parentTitle: section.parent?.title,
sectionNumber: section.number,
// 用于父级上下文扩展
parentChunkId: section.parent?.chunkId,
},
};
chunks.push(chunk);
}
return chunks;
}

// 策略 2：检索时扩展上下文
async retrieveWithContext(query: string): Promise<RetrievalResult[]> {
const rawResults = await this.vectorSearch(query);

return Promise.all(
rawResults.map(async (result) => {
// 检索到子节内容，同时拉取其父节内容作为上下文
const parentChunk = result.metadata.parentChunkId
? await this.getChunkById(result.metadata.parentChunkId)
: null;

// 合并上下文
return {
…result,
// 如果有父级内容，将其作为前置上下文
context: parentChunk
? `${parentChunk.metadata.path.join(' > ')}\\n${parentChunk.text}\\n—\\n${result.text}`
: result.text,
};
})
);
}
}

文档 RAG 的实用性评估：

// 不同文档类型的 RAG 效果评估
const DOCUMENT_RAG_PERFORMANCE = {
// 技术文档（API 文档、使用手册）
// 结构清晰、术语固定、检索效果最好
'technical-docs': { precision: 0.85, recall: 0.82 },

// 产品需求文档（PRD）
// 结构半固定、术语多变、检索效果一般
'product-specs': { precision: 0.72, recall: 0.68 },

// 会议纪要
// 无固定结构、口语化、检索效果差（需要摘要预处理）
'meeting-notes': { precision: 0.55, recall: 0.48 },

// 合同文档
// 结构固定但术语密集、问句匹配度低、检索效果一般
'contracts': { precision: 0.70, recall: 0.65 },
};

// 效果差的文档类型，需要在入库前做预处理
async function preprocessForRAG(docType: string, content: string): Promise<string> {
switch (docType) {
case 'meeting-notes':
// 会议纪要 → 先用 LLM 提取结构化摘要
return extractMeetingSummary(content);
case 'contracts':
// 合同 → 先提取关键条款
return extractContractClauses(content);
default:
return content;
}
}

五、三个方向的优先级与投入建议

AI 辅助写作：不要自研。Cursor、Claude、ChatGPT 已经足够好。把精力放在"如何让团队用好现有工具"而不是"如何做出更好的 AI 写作工具"。

文档智能结构化：最能产生商业价值的方向。找 1 个垂直场景（发票、合同、简历）深耕，做完整从"上传 PDF → 提取字段 → 对接业务系统"的闭环。不要追求通用文档结构化平台。

文档知识库检索：优化重心在文档层级切分和上下文扩展，而非选择更贵的 Embedding 模型。一个层级感知的切分策略比 3 个 SOTA Embedding 模型的效果提升更大。

五、总结

智能文档三个方向的避坑要点：

可执行建议：选一个垂直场景（发票/合同/简历）做完整的"上传 → 提取 → 对接业务系统"闭环验证，而非一开始就追求通用文档结构化平台。

六、总结

智能文档三个方向的避坑核心：

智能文档的本质不是"AI 更强"，而是"文档更结构化"。最难的部分不是 AI，而是如何在保持文档原始信息不丢失的前提下，让 AI 理解文档的组织方式。