体系文件速查

解决什么问题

体系审核里最费时也最费上下文的环节，是从一堆 .doc/.docx 里翻找具体的文件编号、程序文件全名、目标数值、培训日期、人员姓名。把几十万字全文读进上下文，既慢又贵，模型记不住细节，还容易杜撰编号——这正是《审核记录撰写》技能里多份错误清单的来源。本技能把这件事交给本地脚本：索引落磁盘，检索只回传命中片段。查一个编号从读入数十万字变成回传约 200 字片段，复核整张检查表从逐条人工比对变成一条命令出清单，编号杜撰风险改为由索引比对直接标出。

技能如何工作

核心是三步：建索引、检索、校验。

• 建索引：audit_index.py 用文件 (mtime, size) 指纹做增量合并，只对新增或变更文件重新读取，秒级完成；旧索引首次无指纹时会全量重建一次。遇到 .doc 时按目录一次启动 soffice 批量转成 .docx，取代逐文件启动的卡顿。产出写入 .audit_index/：index.json（含指纹）、codes.txt（全部编号）、docnames.txt（全部文件名）。脚本只读资料，不修改任何原始文件。
• 检索：audit_find.py 是字面匹配，不做语义联想，默认回传 8 段约 160 字片段，--list 只列出关键词分布在哪些文件。要领是先 --list 定位在哪个文件，再针对该文件取片段，不要一次拉大量结果。
• 校验：audit_verify.py --from-docx "检查表.docx" 对照索引核查引用编号，退出码 0 表示全部通过，1 表示存在虚构引用，此时必须修正并重新生成 Word，不能放过。

推荐节奏是：接新项目先跑 audit_prepare.py --check 预览待转换 .doc 数量再批量执行；日常新增或修改文件后直接增量更新；全程用 audit_find 取数绝不读全文；出稿由 audit_verify --from-docx 收口。它与《文件审核》《审核记录撰写》《审核报告撰写》协同，后三者统一按「调用《体系文件速查》步骤 N」引用，不硬编码脚本路径。

适用边界

• 检索是字面匹配，不做语义联想。查不到时换同义词（如「供方」「供应商」「采购」），或用 --any 放宽。
• 编号识别正则为「字母-字母数字」组合（如 FJHA-QES-CX-28、YTYY-04-06-06）。企业编号规则特殊（纯数字、含中文）时 audit_verify 可能漏识，改用 audit_find 直接搜核实。
• 索引按项目独立，.audit_index/ 属于项目缓存，不要提交或删除原始资料；不同项目请用各自目录路径分别检索，不要混用。
• 自证防护：文件名含「检查表」「审核记录」「审核报告」「不符合」「审核计划」等字样的文件会被标记为审核产出物，不参与佐证。否则检查表里杜撰的编号会因为「自己写过一次」而被误判为真——这是本工具最容易出错也最危险的地方，已内置防护。若产出物命名不含上述关键词，需手动把它移出体系资料目录后再建索引。
• 环境前置：脚本依赖指定 venv 与 python-docx、openpyxl，.doc 转换依赖 LibreOffice（Windows 也可走 PowerShell Word COM 方案）。目录路径含空格或中文时必须用英文双引号包裹。任何脚本跑之前先确认索引是否存在、依赖是否就绪，避免中途崩溃或空白输出。