简介一份家用照片打印机规格对比文档面向计划选购惠普Photosmart 7660与爱普生Stylus Photo R210的家庭用户和摄影爱好者。文档围绕适合人群、特色功能、打印速度、打印精度、墨滴技术、墨盒系统、参考价格与成本控制等维度展开对比特别点出两款机型均自带读卡器、液晶显示屏支持无边距打印其中爱普生R210还支持光盘盘面打印适合个性化光盘制作。在参数层面二者黑白打印速度均为12页/分钟、彩色11页/分钟惠普优化分辨率达4800dpi、爱普生为5760dpi墨滴技术分别采用热泡3微微升与微压电技术六色墨盒系统也各有成本控制思路。读者可据此判断哪款更贴合自己的打印需求和预算。资源为docx格式共1个文件压缩包大小239KB文档结构清晰、方便查阅。目前已有109人学习浏览适合需要快速了解这两款经典家用照片打印机差异的消费者或相关从业者参考。1. 产品规格资料.docx 不是附件是数据管道的入口产品规格资料.docx 在项目里最常见的命运有两种要么被当成附件在邮箱和群里传来传去要么被人肉打开、复制粘贴、逐行比对。但从工程视角看这个文件名应该是一个数据管道的入口。段落文字是给评审看的而表格里的参数名、参数值、单位、公差才是机器真正要消费的内容。标题虽然只是一个 docx 文件名落到落地路径上就是一条完整链路拆 OOXML 结构、从表格抽键值对、按规则校验版本一致性、再把校验通过的参数反哺成新文档。下面按这条链路逐步展开适合需要同时维护多型号规格文档的开发、测试与文档工程师。2. 拆开产品规格资料.docxOOXML 结构与正文定位要用程序处理产品规格资料.docx第一步不是打开 Word而是先把它当压缩包解开。docx 本质是一个 ZIP 容器里面是若干 XML 文件正文、样式、图片、元数据分别存放在不同路径下。理解了这层结构后面用 python-docx 读表格、做校验、查修订标记时出了问题才知道往哪个文件里看。2.1 先从 zip 包看 docx 的四层文件结构先跑一条命令看看这个文件里到底装着什么unzip -l 产品规格资料.docx | head -30执行后你会看到一批典型的条目最关键的是下面这几个路径内容你在意什么word/document.xml正文全部段落和表格规格参数主要藏在这里word/styles.xml样式定义判断标题层级、表格样式是否规范word/media/*插图尺寸图、接线图、外观图docProps/core.xml作者、修改时间、标题版本审计的辅助信息再直接把正文 XML 拉出来看前 3000 个字符unzip -p 产品规格资料.docx word/document.xml | head -c 3000你会发现正文里全是w:p、w:tbl、w:t这类标签规格值就包裹在w:t里。不同 Office 版本生成的目录结构略有差异但word/document.xml的位置基本固定。所以写解析脚本时不要对 docProps 里的作者、标题字段抱太大希望——很多内部走查文档这些字段不是空的就是复制模板时留下的旧项目名。2.2 body 下的 p 与 tbl段落和表格才是规格正文document.xml的根节点是w:bodybody 里按照文档顺序排列两种块级元素段落w:p和表格w:tbl。一个典型的产品规格资料正文会是一级标题“技术参数”后面跟着若干个表格每个表格里又有若干行w:tr行里是单元格w:tc。w:body xmlns:whttp://schemas.openxmlformats.org/wordprocessingml/2006/main w:p w:rw:t产品型号X-2000/w:t/w:r /w:p w:tbl w:tr w:tcw:pw:rw:t额定电压/w:t/w:r/w:p/w:tc w:tcw:pw:rw:t220V/w:t/w:r/w:p/w:tc /w:tr /w:tbl w:sectPr/ /w:body注意w:sectPr/是节属性包含页面大小、页边距、页眉页脚引用规格文档的 A4/横向设置都在这里改。但解析规格参数时不用关心它。你真正要做的是按 body 顺序遍历p和tbl区分“哪段是标题、哪个表格是参数表”而不是拿正则去全文搜“220V”。2.3 用 python-docx 读产品规格资料.docx 的最小脚本python-docx 是处理这类文档最省事的库它已经帮你把 XML 包成了对象。最小可跑脚本如下from pathlib import Path from docx import Document spec_path Path(产品规格资料.docx) doc Document(spec_path) print(段落数量:, len(doc.paragraphs)) print(表格数量:, len(doc.tables)) for idx, para in enumerate(doc.paragraphs[:20]): text para.text.strip() if text: print(idx, para.style.name, text[:60]) for t_idx, table in enumerate(doc.tables[:3]): print(f表{t_idx}: {len(table.rows)} 行 x {len(table.columns)} 列) for row in table.rows[:5]: cells [c.text.strip().replace(\n, ) for c in row.cells] print( | .join(cells))这段脚本的输出能帮你快速摸清文档规模。doc.paragraphs只返回 body 直属段落不含表格里的段落所以规格资料这种以表格为主的文档段落数量往往比你预期的少。para.style.name用来过滤标题很关键一般“技术参数”“环境要求”这类章节标题会在样式里带有 Heading 字样。table.rows和table.columns拿到的尺寸是网格维度遇到合并单元格时row.cells会出现重复对象这就是下一章要处理的坑。3. 从产品规格资料.docx 表格里抽出结构化参数表格是产品规格资料的核心但表格的排版方式千奇百怪。直接按行列坐标硬索引文档一改版就崩。我的做法是先把表格按形态分类再分别写解析策略这样即使列顺序变化只要形态不变代码改动也限制在很小的范围内。3.1 规格表三种常见形态键值表、矩阵表、明细表打开任意一份“产品规格资料.docx”绝大多数表格逃不出下面三种形态形态长什么样提取方式键值表两列左边参数名右边参数值逐行读取第 0、1 列矩阵表行是参数列是型号或工况先取表头行再按列名映射多行明细表同一部件下多个参数连续出现或一个大表格里混排按第一列分组或按合并单元格分块实际文档里这三种形态经常混在一个表格里。比如一个大表格的前三行是键值对第四行开始变成矩阵。所以抽取之前先打印出每个表格的前几行人工判断形态不要上来就写通用解析器。3.2 合并单元格去重提取前先修正 cell 序列合并单元格是解析表格时最容易错位的地方。Word 的表格底层用w:gridSpan表示水平合并用w:vMerge表示垂直合并。python-docx 的row.cells会按网格把合并过的单元格补齐结果就是同一个w:tc对象在列表里出现多次直接按索引取值会把同一份数据读两遍导致参数错位。我一般会先对每一行做一次去重def _cell_dedupe(row): 去掉合并单元格导致的重复引用按文档顺序返回真实单元格列表。 result [] seen set() for cell in row.cells: if id(cell._tc) not in seen: seen.add(id(cell._tc)) result.append(cell) return result这里的关键参数是id(cell._tc)。cell._tc是单元格底层 XML 元素水平合并时多列共享同一个元素垂直合并时后续行也会引用同一个元素所以用它的 id 去重最可靠。需要注意的是这个去重只是把重复引用压掉垂直合并的单元格在后续行仍然会带着上一行的值提取后要再判断一次“这个值是否属于当前行”。3.3 抽取函数与 JSON 落地把键值表和矩阵表的抽取写成两个独立函数分别用 key_col 和 header_row 这类参数控制起点def extract_key_value_table(table, key_col0, value_col1): entries [] for row in table.rows: cells _cell_dedupe(row) if len(cells) max(key_col, value_col): continue key cells[key_col].text.strip() value .join(cells[value_col].text.split()) if key and value: entries.append({参数名: key, 参数值: value}) return entries def extract_matrix_table(table, header_row0): rows table.rows header [c.text.strip() for c in _cell_dedupe(rows[header_row])] data [] for row in rows[header_row 1:]: cells _cell_dedupe(row) if not cells or not cells[0].text.strip(): continue record {参数名: cells[0].text.strip()} for idx, col_name in enumerate(header[1:], start1): if idx len(cells): record[col_name] .join(cells[idx].text.split()) data.append(record) return header, datavalue .join(cells[value_col].text.split())这行的作用是统一空白规格值单元格里经常有换行、多个空格、甚至单位被拆在两行split 再 join 能把所有连续空白压成单个空格。矩阵表要注意表头也可能有合并单元格所以 header 行同样要走_cell_dedupe否则列名和值对不齐。抽取完直接落成 JSON方便后续校验和对比import json doc Document(产品规格资料.docx) result {键值表: [], 矩阵表: []} for table in doc.tables[:10]: if len(table.columns) 2: result[键值表].extend(extract_key_value_table(table)) else: header, data extract_matrix_table(table) result[矩阵表].append({表头: header, 数据: data}) with open(spec.json, w, encodingutf-8) as f: json.dump(result, f, ensure_asciiFalse, indent2)这里有三个参数要按文档实际情况改doc.tables[:10]是控制只处理前十个表格矩阵表的header_row0默认第一行是表头键值表的key_col0, value_col1默认第一列是参数名。如果某份文档把参数名放在第二列只改调用参数即可不用动函数体。常见误用是把cell.text当成最终值直接入库结果换行符、首尾空格、全角和半角单位混在一起后面校验阶段只能靠人工兜底。4. 多份产品规格资料.docx 的批量校验与一致性检查抽出结构化数据只是第一步。真正让“产品规格资料.docx”产生工程价值的是校验缺失参数、数值越界、单位漂移、版本不一致这些靠人工审阅很难抓全。尤其是同时维护多个型号的规格书时同一参数在不同文档里写法不一样问题会在发布后被客户或产线发现。4.1 校验规则必填、范围、单位漂移校验规则按项目定制但下面五类最常用规则类型检查内容典型案列必填参数表中不存在该参数名明明有防护等级表格里没写类型/范围值能否转成数字且落在合理区间工作温度写成 -200~70单位漂移同一参数在不同文档里用了不同单位电压写成 220V 和 220 伏格式用正则校验编号、型号类参数防护等级 IP65 写成 IP65X唯一性同一参数多章节重复定义且值冲突两处额定功率数值不一致规则先写成字典参数名作为主键后面脚本直接读它import re SPEC_RULES { 额定电压: { required: True, type: number, min: 100, max: 240, unit: {V, 伏, 伏特}, }, 工作温度: { required: True, type: range, min: -20, max: 70, unit: {℃, °C, 度}, }, 防护等级: { required: False, pattern: r^IP[0-9]{2}$, }, }注意这里假设抽取阶段已经将单位单独拆出来了。如果第三章节的抽取函数把“220V”整体放进参数值要先做个剥离m re.match(r^([-0-9.])\s*([A-Za-z°℃%])$, 220V) if m: value, unit m.group(1), m.group(2)正则里的[-0-9.]负责匹配可能带负号和小数点的数字[A-Za-z°℃%]负责匹配单位。这样校验逻辑就不用关心数值里有没有混入单位。4.2 校验脚本与基准对照有了规则和干净的 entries校验函数写起来很直接def validate_entries(entries, rulesSPEC_RULES): errors [] found {name for name, _, _ in entries} for name, rule in rules.items(): if rule.get(required) and name not in found: errors.append(f缺少必填参数: {name}) for name, value, unit in entries: rule rules.get(name) if not rule: continue if pattern in rule and not re.match(rule[pattern], value): errors.append(f{name} 格式不匹配: {value}) if rule.get(type) number: try: v float(value) if v rule[min] or v rule[max]: errors.append(f{name} 越界: {value}) except ValueError: errors.append(f{name} 不是合法数字: {value}) if unit in rule and unit not in rule[unit]: errors.append(f{name} 单位异常: {unit}) return errorsentries是 (name, value, unit) 三元组列表从 JSON 里循环读出来传入即可。found先扫一遍参数名再逐条检查规则这样一条参数缺失和一条参数越界都能在输出里同时出现。多型号场景下我还会拿一个基准型号的 JSON 做交叉对照import glob all_data {} for path in glob.glob(specs/*.docx): doc Document(path) entries extract_entries(doc) # 第 3 章抽取逻辑的汇总入口 all_data[path] {name: value for name, value, _ in entries} base all_data[specs/基准型号.docx] for path, spec in all_data.items(): for name, value in base.items(): if name in spec and spec[name] ! value: print(f{path}: {name} 与基准不一致 {base[name]} vs {spec[name]})这种基准对照特别适合检查“同一参数在不同型号文档里被偷偷改了”的情况。基准型号自身要先保证是评审通过版本否则会把错误扩散到所有对照结果里。4.3 修订痕迹与样式走查发版前的最后一道关口产品规格资料.docx 经常带着未接受的修订痕迹发出来直接发布会给产线造成歧义。Word 的修订记录存在word/document.xml的w:ins和w:del节点里可以用 zipfile 直接扫import zipfile from lxml import etree with zipfile.ZipFile(产品规格资料.docx) as z: xml z.read(word/document.xml) root etree.fromstring(xml) ns {w: http://schemas.openxmlformats.org/wordprocessingml/2006/main} print(插入修订:, len(root.findall(.//w:ins, ns))) print(删除修订:, len(root.findall(.//w:del, ns)))w:ins是新增内容w:del是删除内容只要有一处计数不是 0这份文档就不该进发布目录。这个检查可以写进校验脚本和前面的规则校验一起跑。发布前在 git 仓库里挂个 pre-commit hook用本地脚本防止带修订的 docx 被提交repos: - repo: local hooks: - id: spec-validate name: validate spec docx entry: python scripts/validate_spec.py language: system files: \.docx$这里的entry指向校验脚本files限定只检查 docx 文件改动。pre-commit 会在提交前执行它返回非零就拦截提交比等人工 review 发现要早一大截。5. 反哺用模板生成产品规格资料.docx 并转 Markdown 交付校验通过的结构化数据最后要反哺成两类产物新的产品规格资料.docx以及给知识库用的 Markdown 版本。5.1 用 docxtpl 生成新的产品规格资料.docx如果团队经常要套同一套版式生成不同型号的规格书那就不要每次复制文件再手改。常见做法是维护一份带占位符的 docx 模板用 docxtpl 渲染from docxtpl import DocxTemplate tpl DocxTemplate(规格模板.docx) context { 产品型号: X-2000, 额定电压: 220V, 工作温度: -20~70℃, 生成日期: 2025-01-15, } tpl.render(context) tpl.save(产品规格资料_X-2000.docx)模板里把需要替换的位置写成{{ 额定电压 }}这样的变量render 时传 dict 进去。最容易踩的坑是模板里的变量名和 context 键不一致渲染后文档里残留{{ 额定电压 }}原文不细心看发现不了。5.2 pandoc 转 Markdown 与残留占位符检查交付知识库时我一般用 pandoc 把 docx 转成 Markdownpandoc 产品规格资料.docx -t gfm --wrapnone -o 产品规格资料.md-t gfm指定 GitHub 风格 Markdown表格会转成管道符形式--wrapnone防止长行被折行避免后续 diff 时出现大量无意义改动。转换之后顺手检查一下有没有未渲染的占位符grep -n {{.*}} 产品规格资料.md exit 1 || true这条命令利用 grep 的退出码判断是否还有占位符残留有就拦下没有就继续。发布前把这套流程串成一条命令从模板生成 docx、转 Markdown、跑校验脚本一次执行完再做任何人工确认都会轻松很多。本文还有配套的精品资源点击获取 docx解析与数据校验：从产品规格书提取参数到文档自动化
简介一份家用照片打印机规格对比文档面向计划选购惠普Photosmart 7660与爱普生Stylus Photo R210的家庭用户和摄影爱好者。文档围绕适合人群、特色功能、打印速度、打印精度、墨滴技术、墨盒系统、参考价格与成本控制等维度展开对比特别点出两款机型均自带读卡器、液晶显示屏支持无边距打印其中爱普生R210还支持光盘盘面打印适合个性化光盘制作。在参数层面二者黑白打印速度均为12页/分钟、彩色11页/分钟惠普优化分辨率达4800dpi、爱普生为5760dpi墨滴技术分别采用热泡3微微升与微压电技术六色墨盒系统也各有成本控制思路。读者可据此判断哪款更贴合自己的打印需求和预算。资源为docx格式共1个文件压缩包大小239KB文档结构清晰、方便查阅。目前已有109人学习浏览适合需要快速了解这两款经典家用照片打印机差异的消费者或相关从业者参考。1. 产品规格资料.docx 不是附件是数据管道的入口产品规格资料.docx 在项目里最常见的命运有两种要么被当成附件在邮箱和群里传来传去要么被人肉打开、复制粘贴、逐行比对。但从工程视角看这个文件名应该是一个数据管道的入口。段落文字是给评审看的而表格里的参数名、参数值、单位、公差才是机器真正要消费的内容。标题虽然只是一个 docx 文件名落到落地路径上就是一条完整链路拆 OOXML 结构、从表格抽键值对、按规则校验版本一致性、再把校验通过的参数反哺成新文档。下面按这条链路逐步展开适合需要同时维护多型号规格文档的开发、测试与文档工程师。2. 拆开产品规格资料.docxOOXML 结构与正文定位要用程序处理产品规格资料.docx第一步不是打开 Word而是先把它当压缩包解开。docx 本质是一个 ZIP 容器里面是若干 XML 文件正文、样式、图片、元数据分别存放在不同路径下。理解了这层结构后面用 python-docx 读表格、做校验、查修订标记时出了问题才知道往哪个文件里看。2.1 先从 zip 包看 docx 的四层文件结构先跑一条命令看看这个文件里到底装着什么unzip -l 产品规格资料.docx | head -30执行后你会看到一批典型的条目最关键的是下面这几个路径内容你在意什么word/document.xml正文全部段落和表格规格参数主要藏在这里word/styles.xml样式定义判断标题层级、表格样式是否规范word/media/*插图尺寸图、接线图、外观图docProps/core.xml作者、修改时间、标题版本审计的辅助信息再直接把正文 XML 拉出来看前 3000 个字符unzip -p 产品规格资料.docx word/document.xml | head -c 3000你会发现正文里全是w:p、w:tbl、w:t这类标签规格值就包裹在w:t里。不同 Office 版本生成的目录结构略有差异但word/document.xml的位置基本固定。所以写解析脚本时不要对 docProps 里的作者、标题字段抱太大希望——很多内部走查文档这些字段不是空的就是复制模板时留下的旧项目名。2.2 body 下的 p 与 tbl段落和表格才是规格正文document.xml的根节点是w:bodybody 里按照文档顺序排列两种块级元素段落w:p和表格w:tbl。一个典型的产品规格资料正文会是一级标题“技术参数”后面跟着若干个表格每个表格里又有若干行w:tr行里是单元格w:tc。w:body xmlns:whttp://schemas.openxmlformats.org/wordprocessingml/2006/main w:p w:rw:t产品型号X-2000/w:t/w:r /w:p w:tbl w:tr w:tcw:pw:rw:t额定电压/w:t/w:r/w:p/w:tc w:tcw:pw:rw:t220V/w:t/w:r/w:p/w:tc /w:tr /w:tbl w:sectPr/ /w:body注意w:sectPr/是节属性包含页面大小、页边距、页眉页脚引用规格文档的 A4/横向设置都在这里改。但解析规格参数时不用关心它。你真正要做的是按 body 顺序遍历p和tbl区分“哪段是标题、哪个表格是参数表”而不是拿正则去全文搜“220V”。2.3 用 python-docx 读产品规格资料.docx 的最小脚本python-docx 是处理这类文档最省事的库它已经帮你把 XML 包成了对象。最小可跑脚本如下from pathlib import Path from docx import Document spec_path Path(产品规格资料.docx) doc Document(spec_path) print(段落数量:, len(doc.paragraphs)) print(表格数量:, len(doc.tables)) for idx, para in enumerate(doc.paragraphs[:20]): text para.text.strip() if text: print(idx, para.style.name, text[:60]) for t_idx, table in enumerate(doc.tables[:3]): print(f表{t_idx}: {len(table.rows)} 行 x {len(table.columns)} 列) for row in table.rows[:5]: cells [c.text.strip().replace(\n, ) for c in row.cells] print( | .join(cells))这段脚本的输出能帮你快速摸清文档规模。doc.paragraphs只返回 body 直属段落不含表格里的段落所以规格资料这种以表格为主的文档段落数量往往比你预期的少。para.style.name用来过滤标题很关键一般“技术参数”“环境要求”这类章节标题会在样式里带有 Heading 字样。table.rows和table.columns拿到的尺寸是网格维度遇到合并单元格时row.cells会出现重复对象这就是下一章要处理的坑。3. 从产品规格资料.docx 表格里抽出结构化参数表格是产品规格资料的核心但表格的排版方式千奇百怪。直接按行列坐标硬索引文档一改版就崩。我的做法是先把表格按形态分类再分别写解析策略这样即使列顺序变化只要形态不变代码改动也限制在很小的范围内。3.1 规格表三种常见形态键值表、矩阵表、明细表打开任意一份“产品规格资料.docx”绝大多数表格逃不出下面三种形态形态长什么样提取方式键值表两列左边参数名右边参数值逐行读取第 0、1 列矩阵表行是参数列是型号或工况先取表头行再按列名映射多行明细表同一部件下多个参数连续出现或一个大表格里混排按第一列分组或按合并单元格分块实际文档里这三种形态经常混在一个表格里。比如一个大表格的前三行是键值对第四行开始变成矩阵。所以抽取之前先打印出每个表格的前几行人工判断形态不要上来就写通用解析器。3.2 合并单元格去重提取前先修正 cell 序列合并单元格是解析表格时最容易错位的地方。Word 的表格底层用w:gridSpan表示水平合并用w:vMerge表示垂直合并。python-docx 的row.cells会按网格把合并过的单元格补齐结果就是同一个w:tc对象在列表里出现多次直接按索引取值会把同一份数据读两遍导致参数错位。我一般会先对每一行做一次去重def _cell_dedupe(row): 去掉合并单元格导致的重复引用按文档顺序返回真实单元格列表。 result [] seen set() for cell in row.cells: if id(cell._tc) not in seen: seen.add(id(cell._tc)) result.append(cell) return result这里的关键参数是id(cell._tc)。cell._tc是单元格底层 XML 元素水平合并时多列共享同一个元素垂直合并时后续行也会引用同一个元素所以用它的 id 去重最可靠。需要注意的是这个去重只是把重复引用压掉垂直合并的单元格在后续行仍然会带着上一行的值提取后要再判断一次“这个值是否属于当前行”。3.3 抽取函数与 JSON 落地把键值表和矩阵表的抽取写成两个独立函数分别用 key_col 和 header_row 这类参数控制起点def extract_key_value_table(table, key_col0, value_col1): entries [] for row in table.rows: cells _cell_dedupe(row) if len(cells) max(key_col, value_col): continue key cells[key_col].text.strip() value .join(cells[value_col].text.split()) if key and value: entries.append({参数名: key, 参数值: value}) return entries def extract_matrix_table(table, header_row0): rows table.rows header [c.text.strip() for c in _cell_dedupe(rows[header_row])] data [] for row in rows[header_row 1:]: cells _cell_dedupe(row) if not cells or not cells[0].text.strip(): continue record {参数名: cells[0].text.strip()} for idx, col_name in enumerate(header[1:], start1): if idx len(cells): record[col_name] .join(cells[idx].text.split()) data.append(record) return header, datavalue .join(cells[value_col].text.split())这行的作用是统一空白规格值单元格里经常有换行、多个空格、甚至单位被拆在两行split 再 join 能把所有连续空白压成单个空格。矩阵表要注意表头也可能有合并单元格所以 header 行同样要走_cell_dedupe否则列名和值对不齐。抽取完直接落成 JSON方便后续校验和对比import json doc Document(产品规格资料.docx) result {键值表: [], 矩阵表: []} for table in doc.tables[:10]: if len(table.columns) 2: result[键值表].extend(extract_key_value_table(table)) else: header, data extract_matrix_table(table) result[矩阵表].append({表头: header, 数据: data}) with open(spec.json, w, encodingutf-8) as f: json.dump(result, f, ensure_asciiFalse, indent2)这里有三个参数要按文档实际情况改doc.tables[:10]是控制只处理前十个表格矩阵表的header_row0默认第一行是表头键值表的key_col0, value_col1默认第一列是参数名。如果某份文档把参数名放在第二列只改调用参数即可不用动函数体。常见误用是把cell.text当成最终值直接入库结果换行符、首尾空格、全角和半角单位混在一起后面校验阶段只能靠人工兜底。4. 多份产品规格资料.docx 的批量校验与一致性检查抽出结构化数据只是第一步。真正让“产品规格资料.docx”产生工程价值的是校验缺失参数、数值越界、单位漂移、版本不一致这些靠人工审阅很难抓全。尤其是同时维护多个型号的规格书时同一参数在不同文档里写法不一样问题会在发布后被客户或产线发现。4.1 校验规则必填、范围、单位漂移校验规则按项目定制但下面五类最常用规则类型检查内容典型案列必填参数表中不存在该参数名明明有防护等级表格里没写类型/范围值能否转成数字且落在合理区间工作温度写成 -200~70单位漂移同一参数在不同文档里用了不同单位电压写成 220V 和 220 伏格式用正则校验编号、型号类参数防护等级 IP65 写成 IP65X唯一性同一参数多章节重复定义且值冲突两处额定功率数值不一致规则先写成字典参数名作为主键后面脚本直接读它import re SPEC_RULES { 额定电压: { required: True, type: number, min: 100, max: 240, unit: {V, 伏, 伏特}, }, 工作温度: { required: True, type: range, min: -20, max: 70, unit: {℃, °C, 度}, }, 防护等级: { required: False, pattern: r^IP[0-9]{2}$, }, }注意这里假设抽取阶段已经将单位单独拆出来了。如果第三章节的抽取函数把“220V”整体放进参数值要先做个剥离m re.match(r^([-0-9.])\s*([A-Za-z°℃%])$, 220V) if m: value, unit m.group(1), m.group(2)正则里的[-0-9.]负责匹配可能带负号和小数点的数字[A-Za-z°℃%]负责匹配单位。这样校验逻辑就不用关心数值里有没有混入单位。4.2 校验脚本与基准对照有了规则和干净的 entries校验函数写起来很直接def validate_entries(entries, rulesSPEC_RULES): errors [] found {name for name, _, _ in entries} for name, rule in rules.items(): if rule.get(required) and name not in found: errors.append(f缺少必填参数: {name}) for name, value, unit in entries: rule rules.get(name) if not rule: continue if pattern in rule and not re.match(rule[pattern], value): errors.append(f{name} 格式不匹配: {value}) if rule.get(type) number: try: v float(value) if v rule[min] or v rule[max]: errors.append(f{name} 越界: {value}) except ValueError: errors.append(f{name} 不是合法数字: {value}) if unit in rule and unit not in rule[unit]: errors.append(f{name} 单位异常: {unit}) return errorsentries是 (name, value, unit) 三元组列表从 JSON 里循环读出来传入即可。found先扫一遍参数名再逐条检查规则这样一条参数缺失和一条参数越界都能在输出里同时出现。多型号场景下我还会拿一个基准型号的 JSON 做交叉对照import glob all_data {} for path in glob.glob(specs/*.docx): doc Document(path) entries extract_entries(doc) # 第 3 章抽取逻辑的汇总入口 all_data[path] {name: value for name, value, _ in entries} base all_data[specs/基准型号.docx] for path, spec in all_data.items(): for name, value in base.items(): if name in spec and spec[name] ! value: print(f{path}: {name} 与基准不一致 {base[name]} vs {spec[name]})这种基准对照特别适合检查“同一参数在不同型号文档里被偷偷改了”的情况。基准型号自身要先保证是评审通过版本否则会把错误扩散到所有对照结果里。4.3 修订痕迹与样式走查发版前的最后一道关口产品规格资料.docx 经常带着未接受的修订痕迹发出来直接发布会给产线造成歧义。Word 的修订记录存在word/document.xml的w:ins和w:del节点里可以用 zipfile 直接扫import zipfile from lxml import etree with zipfile.ZipFile(产品规格资料.docx) as z: xml z.read(word/document.xml) root etree.fromstring(xml) ns {w: http://schemas.openxmlformats.org/wordprocessingml/2006/main} print(插入修订:, len(root.findall(.//w:ins, ns))) print(删除修订:, len(root.findall(.//w:del, ns)))w:ins是新增内容w:del是删除内容只要有一处计数不是 0这份文档就不该进发布目录。这个检查可以写进校验脚本和前面的规则校验一起跑。发布前在 git 仓库里挂个 pre-commit hook用本地脚本防止带修订的 docx 被提交repos: - repo: local hooks: - id: spec-validate name: validate spec docx entry: python scripts/validate_spec.py language: system files: \.docx$这里的entry指向校验脚本files限定只检查 docx 文件改动。pre-commit 会在提交前执行它返回非零就拦截提交比等人工 review 发现要早一大截。5. 反哺用模板生成产品规格资料.docx 并转 Markdown 交付校验通过的结构化数据最后要反哺成两类产物新的产品规格资料.docx以及给知识库用的 Markdown 版本。5.1 用 docxtpl 生成新的产品规格资料.docx如果团队经常要套同一套版式生成不同型号的规格书那就不要每次复制文件再手改。常见做法是维护一份带占位符的 docx 模板用 docxtpl 渲染from docxtpl import DocxTemplate tpl DocxTemplate(规格模板.docx) context { 产品型号: X-2000, 额定电压: 220V, 工作温度: -20~70℃, 生成日期: 2025-01-15, } tpl.render(context) tpl.save(产品规格资料_X-2000.docx)模板里把需要替换的位置写成{{ 额定电压 }}这样的变量render 时传 dict 进去。最容易踩的坑是模板里的变量名和 context 键不一致渲染后文档里残留{{ 额定电压 }}原文不细心看发现不了。5.2 pandoc 转 Markdown 与残留占位符检查交付知识库时我一般用 pandoc 把 docx 转成 Markdownpandoc 产品规格资料.docx -t gfm --wrapnone -o 产品规格资料.md-t gfm指定 GitHub 风格 Markdown表格会转成管道符形式--wrapnone防止长行被折行避免后续 diff 时出现大量无意义改动。转换之后顺手检查一下有没有未渲染的占位符grep -n {{.*}} 产品规格资料.md exit 1 || true这条命令利用 grep 的退出码判断是否还有占位符残留有就拦下没有就继续。发布前把这套流程串成一条命令从模板生成 docx、转 Markdown、跑校验脚本一次执行完再做任何人工确认都会轻松很多。本文还有配套的精品资源点击获取