简介这是一份围绕剧情记录与范文写作整理的docx文集面向剧本创作、文案撰写及需要剧情素材的写作爱好者可用于查找情节桥段、模仿叙事口吻、快速搭建故事框架。资源包内仅1个docx文档约20KB下载后即可在Word中直接阅读与摘录。文集按主题收录多类内容以讲故事口吻复述匡衡凿壁偷光的故事归纳《瘟疫论》中戾气致病、传染途径与治法要点整理党的群众路线教育实践活动谈心谈话记录范文列出宫斗剧情设计思路如新秀入宫挑刺、探病不请安、联合高位妃子陷害、借孕期膳食冲突设局等还解析《老师的恩惠》的叙事结构与人物关系。每部分多附知识点小结便于对照取用。目前已有6371人学习适合作为剧情写作与范文参考的素材库。1. 一个「范文大全.docx」为什么不该直接手改同事把一个 800 多页的 docx 丢过来文件名就叫「文爱剧情记录范文大全.docx」要求按主题拆成几十个独立文件、统一标题层级和页眉、再照着模板批量产出一批新范文。第一反应是打开 Word 手动改改到第三个文件就会发现标题有的用「标题 1」有的直接加粗正文有的在表格里有的在文本框里页眉页码每个文件都不一样。手工改完下一批素材进来又要重来一遍。这类以「范文大全」命名的文档集合本质是一个弱结构化的文本仓库内容按主题堆积格式靠人工维护没有主键、没有版本号、没有校验规则。真正要解决的从来不是写范文而是文档工程——把这个 docx 拆开读懂、抽成结构化数据、按模板批量生成、再建索引让它可检索、最后加一层校验兜底。适合看下去的人有三类需要批量处理 docx 的后端或数据工程师做内容平台、知识库、审核系统的开发者以及被 Word 手工劳动困住的运营同学。后面按「先读懂 OOXML 结构 → 模板化批量生成 → 入库检索 → 校验与审计」的顺序推进每一步都给出能直接跑的代码和参数。2. 用 python-docx 拆解 docx 范文的段落、样式与表格2.1 先确认 docx 只是一个改了扩展名的 zip 包不要一上来就写解析逻辑先用系统自带的解压工具看一眼内部结构这一步能省掉后面大量猜测# -l 只列目录不求解压先看包里有什么 unzip -l 文爱剧情记录范文大全.docx | head -30典型输出里会看到[Content_Types].xml、_rels/.rels、word/document.xml、word/styles.xml、word/numbering.xml、word/media/。所有可见文字都在word/document.xml样式定义在word/styles.xml自动编号规则在numbering.xml图片和嵌入对象在media/。python-docx 做的事情就是把这几份 XML 解析成对象树。理解这一点之后很多玄学就有了答案为什么改了文字样式没变——因为样式定义在 styles.xml段落只是引用了一个 styleId为什么复制粘贴后编号乱了——因为 numbering.xml 没跟着复制。2.2 遍历段落paragraph 和 run 的边界在哪里最朴素的抽取脚本长这样from docx import Document # 加载整包几百页的文档会吃掉几百 MB 内存够用但别并行开太多 doc Document(文爱剧情记录范文大全.docx) for idx, para in enumerate(doc.paragraphs): text para.text.strip() if not text: # 空段落多是排版留白先跳过 continue print(f{idx:04d} | {para.style.name:12} | {text[:40]})三个参数值得说明。para.text是段落内所有 run 文本拼接后的结果run 是 Word 里一段连续相同格式的文字一个字被加粗过就会拆成独立 runpara.style.name返回的是样式名称而不是 styleId中文 Word 里可能叫「标题 1」英文环境里叫Heading 1idx只是该段落在doc.paragraphs列表里的下标表格内部的段落不参与编号所以它不等于文档里的物理顺序。样式名和语义的对应关系建议先人工梳理一张对照表后续抽取全靠它样式名业务语义常见混用问题Normal正文段落标题也用 Normal仅靠加粗区分Heading 1 / 标题 1一级章节中英文样式名不一致判断时别用等号Heading 2 / 标题 2二级章节层级跳跃出现 H1 直接接 H3List Paragraph列表项手工输入1.而不是用自动编号Table Grid表格表格样式被套到普通段落上提示判断样式时用style.name.startswith(Heading)或同时匹配中英文名直接用 Heading 1在中文 Office 环境下会全军覆没。2.3 按文档顺序同时取出段落和表格doc.paragraphs只给段落doc.tables只给表格两者各自成列表丢失了它们在正文里的先后关系。范文类文档经常一段说明 一张对照表 一段结论顺序错了整篇的逻辑就散了。正确做法是直接遍历 body 的子元素from docx import Document from docx.oxml.ns import qn from docx.table import Table from docx.text.paragraph import Paragraph def iter_block_items(doc): 按文档物理顺序产出 Paragraph 和 Table表格不再被跳过 body doc.element.body for child in body.iterchildren(): if child.tag qn(w:p): # w:p 段落元素 yield Paragraph(child, doc) elif child.tag qn(w:tbl): # w:tbl 表格元素 yield Table(child, doc) doc Document(文爱剧情记录范文大全.docx) for block in iter_block_items(doc): if isinstance(block, Paragraph): print(P, block.style.name, block.text[:30]) else: print(T, len(block.rows), 行, len(block.columns), 列)qn(w:p)的作用是把简写展开成带命名空间的全名{http://schemas.openxmlformats.org/wordprocessingml/2006/main}p这是 lxml 的比较方式直接写字符串w:p永远匹配不上。iterchildren()只遍历直接子节点不会钻进表格内部正好符合顶层块的语义。2.4 解析阶段最容易踩的三个坑第一个坑是文本框。Word 里的文本框内容不在body的直接子节点里而在w:drawing下的w:txbxContent中用上面的遍历函数抓不到。范文文档为了排版好看经常把说明文字塞进文本框抽完发现少了几段先怀疑这里。第二个坑是 run 被切碎导致关键词匹配失败。搜「范文模板」四个字如果范文和模板分别在不同的 run 里paragraph.text能拼出完整句子但你若逐个 run 去正则匹配就永远命中不了。稳妥做法是先拼出整段文本做匹配再回写到 run 级别修改。第三个坑是修订和批注。文档如果带未接受的修订document.xml里会出现w:ins和w:del节点前后文字被拆开。抽数据前先用doc.save()另存一份看看有没有内容差异或者显式检查w:ins是否存在避免把批注文字当成正文入库。3. docxtpl 批量生成 docx 范文占位符、循环与样式继承3.1 为什么选 docxtpl 而不是用 python-docx 硬拼用 python-docx 从零构建文档每一段都要手工指定样式对象、字体、行距、编号代码量大且极易和设计稿对不上。docxtpl 的思路反过来先在 Word 里把一份范文的样式调到满意把要替换的地方写成 Jinja2 占位符剩下的事交给渲染引擎。样式、页眉页脚、页边距、水印全部跟着模板走这是它最大的价值。代价是模板必须由人来维护占位符写错一个字符就会渲染失败。所以实践里通常把模板目录纳入版本管理改模板要过 code review。3.2 最小可用渲染三行代码跑通一份范文from docxtpl import DocxTemplate # 模板里写 {{ title }} 和 {{ body }}样式在 Word 中调好 tpl DocxTemplate(范文模板.docx) context { title: 分类说明示例, body: 这里是从结构化数据里取出来的正文内容。, } tpl.render(context) # 渲染到内存不落盘 tpl.save(输出_001.docx) # 必须显式 save文件名自己控制render()只做占位符替换不修改模板文件本身save()负责写出。context 的 key 必须和模板里的变量名完全一致Jinja2 默认对缺失变量渲染成空字符串而不报错所以生成后一定要做一次残留占位符检查——这一点在第 5 章会写成脚本。3.3 表格行循环与条件段落常用标签速查范文类文档最核心的场景是一段固定说明 一张可变长度的表格表格行数由数据决定模板里必须用循环标签。模板写法作用使用位置{{ name }}普通变量替换任意 run 内{%p if cond %}整段条件显示独占一个段落{%tr for item in items %}整行循环复制整行并渲染表格行的第一个单元格{%tc for col in cols %}整列循环表格列的单元格内{{r rich_text }}插入富文本保留加粗、颜色需要样式混排处{%tr for %}和{%tr endfor %}必须分别写在要重复的那一行的首尾写在单元格内部会被当成普通文本。如果数据里某些字段可能为空用{%p if item.remark %}包住整段比在变量后面做三元判断可读性好得多。3.4 批量生成脚本与三个必调参数import json from pathlib import Path from docxtpl import DocxTemplate tpl DocxTemplate(范文模板.docx) out_dir Path(output); out_dir.mkdir(exist_okTrue) with open(records.jsonl, encodingutf-8) as f: for line in f: rec json.loads(line) # jinja_env 可挂自定义过滤器做日期格式化、字数截断 tpl.render(rec, autoescapeFalse) tpl.save(out_dir / f{rec[doc_id]}.docx)第一个必调参数是autoescape。docx 内容不是 HTML开启转义会把中文标点和引号变成实体正文里出现amp;这种字样基本都是它干的默认关掉即可但转义责任就落到输入数据清洗上。第二个是模板复用。DocxTemplate 对象可以被多次render()但每次渲染会改写内部的 XML 树稳妥做法是每轮重新DocxTemplate(tpl_path)实例化或者把模板文件读成 bytes 反复from_string避免上一轮的循环残留污染下一轮。第三个是输出文件名。用doc_id而不是标题做文件名标题里带/、:、换行符的概率不低Windows 上直接抛异常。落盘后用python-docx回读一次断言段落数大于 0比事后人工翻文件可靠得多。4. 把 docx 范文转成可检索数据JSON 结构、入库与全文查询4.1 一篇范文该拆成哪几个字段拆得太粗检索不到拆得太细查询要拼半天。以段落级为最小单元通常最合适字段设计如下字段类型说明doc_idstring文档唯一标识建议用文件相对路径的哈希source_filestring原始 docx 文件名便于回溯categorystring主题分类从一级标题或目录推断block_indexint在文档中的物理顺序从 0 开始style_namestring段落样式名用于判断是标题还是正文levelint标题层级正文为 0textstring段落纯文本level字段是后续做按章节切分的关键遇到 level1 就开一个新章节level2 归到上一个章节下正文全部挂到当前章节里。4.2 从 docx 到 JSONL 的抽取脚本import hashlib, json from pathlib import Path from docx import Document from docx.oxml.ns import qn from docx.table import Table from docx.text.paragraph import Paragraph def level_of(style_name: str) - int: # 兼容「标题 1」和「Heading 1」两种写法 for i in (1, 2, 3): if style_name in (f标题 {i}, fHeading {i}): return i return 0 def parse_docx(path: Path): doc Document(str(path)) doc_id hashlib.md5(str(path).encode()).hexdigest()[:12] items, idx [], 0 for child in doc.element.body.iterchildren(): if child.tag qn(w:p): para Paragraph(child, doc) text para.text.strip() if not text: continue items.append({ doc_id: doc_id, source_file: path.name, block_index: idx, style_name: para.style.name, level: level_of(para.style.name), text: text, }) idx 1 elif child.tag qn(w:tbl): for row in Table(child, doc).rows: cells [c.text.strip() for c in row.cells] items.append({ doc_id: doc_id, source_file: path.name, block_index: idx, style_name: TableRow, level: 0, text: | .join(cells), }) idx 1 return items with open(records.jsonl, w, encodingutf-8) as out: for p in Path(docs).glob(*.docx): for it in parse_docx(p): out.write(json.dumps(it, ensure_asciiFalse) \n)表格行统一拼成|分隔的字符串入库检索时能命中单元格内的关键词需要还原结构时再按分隔符切回去。ensure_asciiFalse必须开否则中文全变成\uXXXX文件体积翻三倍且没法肉眼校对。4.3 SQLite 建表与中文全文索引CREATE TABLE doc_block ( id INTEGER PRIMARY KEY, doc_id TEXT NOT NULL, source_file TEXT NOT NULL, category TEXT, block_index INTEGER, style_name TEXT, level INTEGER, text TEXT ); -- FTS5 虚拟表trigram 分词器对中文按三字符切分无需外部分词库 CREATE VIRTUAL TABLE doc_fts USING fts5( text, source_file, contentdoc_block, content_rowidid, tokenizetrigram ); INSERT INTO doc_fts(rowid, text, source_file) SELECT id, text, source_file FROM doc_block;SQLite 默认的unicode61分词器按空白和标点切词中文整段会被当成一个 token搜模板永远搜不到范文模板。trigram分词器把文本切成连续三字符片段对中文短词召回效果可用代价是索引体积大约是原文的 3 到 5 倍。如果数据量在百万段以上常见做法是先用 jieba 分词把空格分隔的结果写入一个独立的text_tokenized列再建 FTS 索引。4.4 查询与高亮把命中还原成上下文SELECT d.source_file, b.block_index, snippet(doc_fts, 0, [, ], …, 12) AS ctx FROM doc_fts JOIN doc_block b ON b.id doc_fts.rowid JOIN doc_block d ON d.id doc_fts.rowid WHERE doc_fts MATCH 范文 ORDER BY rank LIMIT 20;snippet()的五个参数依次是表名、列号、命中前缀、命中后缀、省略号、上下文词数。用[ ]做标记而不是 HTML 标签前端渲染时自己决定高亮样式能避免 XSS 面的麻烦。ORDER BY rank走的是 FTS5 内置的 BM25 排序不加这一句返回顺序就是插入顺序翻页体验会很差。5. docx 范文合集的格式校验与内容审计脚本5.1 校验三件事占位符残留、样式漂移、空段落批量生成的文档最容易出三类问题写成脚本一次性扫完import re, sys from pathlib import Path from docx import Document PLACEHOLDER re.compile(r\{\{.*?\}\}|\{%.*?%\}) # 未被渲染的 Jinja2 标签 ALLOWED_STYLES {Normal, Heading 1, Heading 2, 标题 1, 标题 2} def check(path: Path): doc Document(str(path)) problems [] for i, para in enumerate(doc.paragraphs): if PLACEHOLDER.search(para.text): problems.append((残留占位符, i, para.text[:40])) if para.style.name not in ALLOWED_STYLES: problems.append((样式越界, i, para.style.name)) if para.text and para.style.name.startswith((Heading, 标题)): problems.append((空标题, i, )) return problems bad 0 for p in Path(output).glob(*.docx): for kind, idx, detail in check(p): bad 1 print(f[{kind}] {p.name} 段落{idx}: {detail}) sys.exit(1 if bad else 0)退出码这一行是关键非零退出码能让 CI 直接判定构建失败比在日志里翻几百行输出高效得多。ALLOWED_STYLES用集合而不是列表几百页文档逐段判断时差着数量级。5.2 内容审计关键词清单与命中隔离文档集合在对外发布前需要过一遍内容审计做法是把敏感词清单放到外部配置文件里命中即隔离而不是直接删除import json, shutil from pathlib import Path rules json.loads(Path(audit_rules.json).read_text(encodingutf-8)) KW rules[keywords] # [替换词A, 替换词B] quarantine Path(quarantine); quarantine.mkdir(exist_okTrue) def audit(path: Path) - list: hits [] for i, para in enumerate(__import__(docx).Document(str(path)).paragraphs): for kw in KW: if kw in para.text: hits.append({para: i, kw: kw}) return hits for p in Path(output).glob(*.docx): h audit(p) if h: shutil.move(str(p), quarantine / p.name) # 移出发布目录保留原始文件 print(p.name, 命中, len(h), 处已隔离)规则文件独立于代码运营改词不需要发版。命中记录要带上段落索引方便人工复核时直接定位而不是把整个文件重新读一遍。5.3 把校验挂到提交流程上单次跑脚本容易忘挂到 pre-commit 才是真正落地的做法。在.pre-commit-config.yaml里加一个 local hookentry指向校验脚本files限定为^output/.*\.docx$pass_filenames: false这样每次提交生成物都会自动过一遍占位符和样式检查。如果语料目录有几百份文档用 pytest 的参数化把每个 docx 变成一个测试用例更合适import pytest from pathlib import Path from scripts.check import check pytest.mark.parametrize(docx, sorted(Path(output).glob(*.docx)), idslambda p: p.name) def test_docx_quality(docx): assert check(docx) [], f{docx.name} 存在格式问题参数化的价值在于失败粒度一份文档出问题只挂一个用例其余照常跑完ids让报告里直接显示文件名而不用去翻索引映射。把output/和quarantine/一起纳入.gitignore只提交模板和规则文件仓库就不会被二进制文档撑爆。本文还有配套的精品资源点击获取