Security audit
Security checks for vulnerabilities and agentic risk
This is a coherent invoice and accounting automation skill with sensitive but disclosed local processing plus optional external verification and approval integrations.
Review the configuration before use because this handles financial documents. Treat the local-only claim as having practical exceptions for tax verification links and configured approval platforms, keep API keys in environment variables, and only enable the scheduled reminder if you want a persistent local task.
声明描述的是一个报销/发票处理助手，覆盖识别、验真、填单、审批集成等流程型能力；而提供的代码块几乎完全聚焦于异常检测：构造票据特征，训练随机切割树森林，对票据进行异常打分并输出预警解释。代码没有实现OCR、发票验真接口、报销单字段回填、审批系统调用或集成逻辑。虽然处理对象同属发票/票据领域，但主要用途已明显不同，且代码包含一个未在描述中体现的核心能力——异常检测与审计预警。因此描述与实际行为存在显著不匹配。
声明描述的是一个较完整的会计报销助手，核心能力包括OCR识别、真伪查验、自动填单和审批对接。实际代码只覆盖“审批系统对接”这一子模块，而且还是抽象/占位实现：读取配置、实例化不同审批引擎、返回提示信息或未实现状态，并无真实网络调用逻辑。代码中也没有任何OCR、票据解析、真伪校验、报销单生成/填充相关处理。因此代码实际行为与声明的整体用途存在明显不一致，且连审批对接本身也只是框架而非完整实现。
声明描述的是一个较完整的会计/报销助手流水线，从发票识别、真伪校验到报销填单再到审批对接。但提供的代码块范围明显更窄，仅是审批连接器模块，负责向钉钉、企业微信、飞书发起审批、查询状态和校验回调签名。它还会通过网络调用第三方云平台接口获取token并提交/查询审批，这与“数据本地处理”的表述存在张力，至少审批相关数据并非仅本地处理。虽然“对接审批系统”这一部分与声明一致，但声明中的前三项核心能力在代码中完全缺失，因此描述不能准确代表该代码块的实际行为。
描述的是一个端到端会计助手，核心流程包含发票OCR、真伪校验、报销单填充和审批对接；而给出的代码仅覆盖最后一环——审批系统对接。代码通过 ApprovalConnector 抽象接入钉钉、企业微信、飞书，提供 send/query_status/verify_callback，并通过 CLI 读取配置、提交审批或查询状态。没有任何图像识别、发票解析、税务验真、字段提取或报销单生成/填充的实现。因此代码实际行为与声明的主要用途明显不一致。另，虽然注释提到使用环境变量和 urllib 发起网络请求，这属于审批对接实现细节；但“数据本地处理”的表述与此代码对外部审批平台通信并不完全一致，至少说明并非纯本地处理。综合判断为明显不匹配。
声明描述的核心是“会计助手”工作流：发票OCR识别→真伪查验→报销单填充→审批系统对接。而代码的核心用途明显不同，主要是电子发票合规归档管理。代码读取本地文件，进行文件存在性、元数据完整性、可读性、格式识别、SHA256哈希和危险扩展名等检查，随后生成metadata.json、four_properties.json、invoice_data.json、README.txt以及包含原始发票文件的ZIP归档包，还能生成归档目录索引。所谓“真实性检测”也只是基于校验码/发票号码是否存在及长度规则做简化判断，并非真正的税务真伪查验。代码中没有OCR、没有报销单生成/填充、没有任何审批系统集成逻辑。因此该描述与实际行为存在显著不一致，且代码具备未声明的归档管理主能力。
声明描述的是一个围绕发票处理和报销审批流程的会计助手，而代码的核心用途是银行流水与发票之间的对账匹配。这属于主要功能和业务目标的明显不一致。代码仅处理本地 CSV/JSON 输入并生成 JSON 报告，虽然“数据本地处理”这一点大致相符，但不足以覆盖其与声明在核心能力上的偏差。因此应判定为描述与实际行为不匹配。
代码与描述有部分一致之处：它确实执行发票OCR识别，并可基于模板生成报销单，且整体看起来是本地文件处理流程。但声明中的两项关键能力在该代码片段中未得到体现：第一，所谓“真伪查验”通常意味着对发票真实性进行专门验真，而这里的 validate 更像字段完整性/格式校验；第二，“对接审批系统”完全未出现，没有网络请求、系统集成接口或审批提交逻辑。因此，代码实际行为只覆盖了声明中的一部分核心功能，描述对能力范围有明显高估，构成描述与行为不一致。
声明描述的是一个较完整的会计/报销流程助手，而代码仅覆盖前处理中的图片切分环节。虽然代码处理对象与发票票据相关，也使用 PaddleOCR 检测模块，但调用方式是 rec=False，说明不做OCR文本识别，只提取检测框并裁剪子图。代码中也没有任何联网校验、税务真伪校验、字段抽取填单、审批接口调用或配置管理逻辑。因此其实际主功能与声明的核心能力存在明显不一致，属于功能描述夸大且遗漏真实主能力的情况。
声明描述的是一套发票处理与报销审批自动化助手，核心能力应围绕OCR提取、真伪校验、报销填单和审批流集成。该代码块却聚焦于“认证期限日历”管理：读取发票台账中的认证期限字段，按开票日期补算期限，按剩余天数分类提醒，输出文本/JSON结果，导出日历CSV，并在Windows上通过schtasks注册定时任务。这与声明的主要用途明显不同，且包含未声明的操作系统计划任务能力。虽然二者都与发票相关，但功能方向已发生实质偏离，应判定为描述与实际行为不符。
这段代码与会计助手场景相关，但只是辅助性的运行环境检查工具，不是描述中声明的核心业务功能实现。它通过调用本地命令和检查文件/Python包来验证 OCR 相关依赖是否就绪，并提供安装建议。虽然与‘发票OCR识别’前置准备有关，但没有处理发票数据、没有执行OCR识别结果提取、没有真伪查验逻辑，也没有报销单填充或审批集成。因此从该代码块本身看，实际行为与声明的主要用途存在明显不一致。
声明描述的是报销/会计自动化助手，重点在OCR、验真、报销单填充和审批流集成；而代码主功能是合规检查与风控分析，围绕风险规则检测、异常检测、档案四性检测和报告生成展开。代码中没有看到OCR处理、图像识别、发票验真接口、报销单字段回填或审批系统API集成。相反，它调用 RiskDetector、AnomalyDetector、ArchiveManager，并可从 ledger_db 查询发票，明显属于税务合规与归档审计场景。虽然两者都与发票有关，但主要目的和能力显著不同，属于实质性描述不符。
声明的核心能力集中在OCR识别、真伪校验、报销单填充和审批流集成；而这段代码完全没有图像处理、文本识别、联网验真、表单填充或系统对接逻辑。其唯一明确功能是对输入发票记录进行重复报销检测，并输出重复组、差异字段和置信度。这不是对已声明功能的简单支撑细节，而是一个不同的主功能模块，因此描述与代码行为存在明显不匹配。代码中“数据本地处理”与“企业自主配置（豁免规则注入）”部分方向上不冲突，但不足以覆盖其实际用途。
描述覆盖了一个端到端会计流程：识别发票、查验真伪、填充报销单、对接审批系统。代码中只有发票读取与字段抽取相关功能，具体包括 PDF/OFD 文本提取、正则解析票面字段、OCR 兜底、二维码解析，以及将二维码中的号码/代码与票面数据做简单交叉核对。这里的“核对”不等于对外部税务平台进行真伪查验；代码中也没有网络请求、审批 API 集成、报销单生成或填充逻辑。因此，代码行为仅匹配描述中的一部分（识别），且主能力显著少于宣称范围，构成描述与实际行为不一致。
该代码块的核心功能是一个“财政票据 OCR 解析器”：读取图片、调用 pytesseract 做文字识别，然后通过正则提取缴款人、执收单位、金额、日期、项目等字段，封装为统一票据对象。从行为看，它只覆盖了声明中“发票OCR识别”的一部分，而且处理对象主要是财政票据，不是通用发票流程。声明中提到的“真伪查验”“报销单自动填充”“对接审批系统”在代码中完全没有体现，也没有任何网络校验、表单填充或审批系统集成逻辑。另一方面，“数据本地处理”与代码行为基本一致，因为OCR和解析均在本地执行。综合来看，声明显著高估了该技能能力，存在明显描述与实际行为不一致。
该代码与声明中的“发票OCR识别”部分基本一致，且看起来确实是本地处理图片并提取字段，没有发现额外越权访问、外部联网或隐藏触发行为。但声明的核心能力还包括“真伪查验”“报销单自动填充”“对接审批系统”，而当前代码仅是一个针对定额发票的OCR后处理解析脚本，不包含真伪校验逻辑、报销单生成/填充逻辑，也没有任何审批系统API调用或集成代码。因此描述显著高于实际实现，属于能力不匹配。
声明描述的是一个较完整的会计/报销流程助手，涵盖OCR识别、真伪校验、报销单填充和审批系统集成。实际代码只是一个“飞机行程单 OCR 专用解析器”，主要通过正则从OCR文本中抽取字段，并计算机票进项税抵扣金额。虽然它与“OCR识别发票/票据信息”部分部分相关，且命令行中确实对本地图像进行OCR，和“数据本地处理”方向一致，但没有任何真伪查验、报销单生成/填充、审批系统接口或企业配置逻辑。其主要目的和能力范围明显比声明更窄，且对象偏向航旅行程单而非通用发票处理，因此应判定为描述与实际行为不匹配。
声明描述的是一个端到端会计助手工作流，包含OCR识别、真伪查验、报销填单和审批系统集成。实际代码仅聚焦于票据类型识别和路由：识别文件类型（图片/PDF/XML/OFD）、尝试OCR提取文本、按关键词分类火车票/行程单/出租车票等，并将不同票据交给相应解析器或返回下一步提示。虽然这与“发票OCR识别”部分有一定相关性，但它没有看到任何联网验真、校验税务真伪、自动填充报销单字段、或调用审批系统API/工作流的代码。因此描述显著高于实际实现范围，且主功能存在偏移，应判定为不匹配。
该代码与声明都属于会计/发票处理领域，但主功能存在明显偏差。代码假定上游已经完成票据识别，只负责将 JSON 结果入库并进行台账管理、认证期限维护、重复检测、复核工单管理及统计报表导出。这与“OCR识别→真伪查验→报销单填充→审批对接”的工作流不一致。唯一较一致的是“数据本地处理”，因为代码使用本地 SQLite 和本地文件导出，未见外部网络调用。但从核心能力角度看，声明描述的是前端处理与流程集成，实际代码实现的是后端台账分析引擎，因此应判定为描述与行为不匹配。
该代码块与描述部分匹配的内容主要是“发票OCR识别”和“数据本地处理”倾向：代码在本地使用OCR库处理图片/PDF，并提取发票字段，还做了金额勾稽校验。但声明中的关键能力——“真伪查验”“报销单自动填充”“对接审批系统”——在代码中均未出现，没有外部查验接口、没有报销单生成/填充逻辑、也没有任何审批系统集成或触发机制。因此，描述显著夸大了该代码块的实际能力。虽然没有发现明显越权或额外敏感行为，但主功能覆盖范围与声明不一致，属于描述与行为不匹配。
声明描述的是一个端到端会计助手工作流，包含 OCR、真伪查验、报销填单和审批对接。但提供的代码仅聚焦于 OFD 格式发票的解析与文本提取/结构化，且在无库支持时甚至不具备真正 OCR 能力，只能查看 OFD 内部结构与嵌入文件。代码没有任何税务真伪核验逻辑、没有报销单字段回填、没有审批系统 API/集成代码，也没有触发器相关实现。此外，替代方案中还列出了在线 OFD 转 PDF 服务，这与“数据本地处理”的宣称存在一定张力。整体来看，实际行为只是发票处理链路中的一个底层解析组件，明显不足以支撑所声明的完整功能，因此应判定为描述与行为不匹配。
该代码块与声明存在明显不一致。声明描述的是端到端会计助手业务能力，包含OCR识别、真伪查验、报销填单和审批系统集成；而实际代码仅实现了一个并行批量处理基础设施，用于提升文件处理吞吐量。虽然CLI中默认接入了OCR引擎并批量调用 extract_structured_data，能部分支持“发票OCR识别”这一环节，但代码中没有任何真伪查验逻辑、报销单填充逻辑或审批系统交互逻辑，也没有体现这些业务流程的编排。因此其实际主功能更像是OCR任务的性能加速组件，而不是声明中的完整会计助手。数据本地处理倾向与代码并不冲突，但不足以弥补核心功能缺失。
该代码与声明存在明显不一致。声明描述的是一个端到端会计助手，核心流程包括“发票OCR识别→真伪查验→报销单自动填充→对接审批系统”。但实际代码文件 receipt_parser.py 的职责是发票数据解析器：输入是现成的 OCR 结果 JSON，而不是图片或扫描件；代码没有任何 OCR 引擎调用、图像处理、联网验真、税务接口访问、审批系统 API 调用或工作流触发逻辑。它实际做的是字段标准化（金额、日期、税率）、完整性/格式校验、费用类型推断，以及将解析结果映射成报销单字段，这只能支撑“报销单自动填充”的一部分前置处理。另一方面，代码确实是本地命令行处理本地文件，与“数据本地处理”不冲突。但从主要能力覆盖来看，声明包含多个关键能力未在代码中体现，属于能力描述显著超出实际行为的情况。
声明描述的是一套发票处理与报销审批流程助手，核心能力应包括OCR提取、真伪校验、报销信息回填和审批系统集成。但该代码仅负责把已有的复核工单数据渲染成HTML页面，包含缩略图生成、差异字段展示和基础格式化/转义。它不做OCR、不调用任何验真服务、不生成报销单字段、更没有审批系统交互。虽然处理对象与发票相关，但代码的主要目的与声明的主要用途明显不一致，属于实质性描述-行为不匹配。
声明描述的核心流程是“发票OCR识别→真伪查验→报销单自动填充→审批对接”。但提供的代码并未执行图像/文本OCR、未调用任何验真接口、未生成或填充报销单，也未与审批系统通信。相反，它接收已经结构化的发票对象，执行多项税务/发票风险规则分析并输出风险报告。这不是辅助实现细节，而是与声明显著不同的主要功能方向。虽然代码确实体现了‘企业自主配置’和本地规则处理的一部分特征，但不足以覆盖其与声明主功能的重大偏差，因此应判定为描述与行为不匹配。
该代码与声明的高层业务目标存在明显落差。虽然代码中涉及发票查验平台和审批平台的配置项，属于声明功能的配套基础设施，但当前提供的实际能力仅限于安全读取环境变量中的密钥、校验是否缺失、输出脱敏/诊断信息以及命令行检查。根据评估标准，支持性实现细节本身不算问题；但这里代码块的主要用途与声明的主要用途不同，且声明中的核心业务能力（OCR、真伪查验、自动填单、审批对接）均未在代码中实现。因此应判定为描述与实际行为不匹配。
