前言¶

标书初稿写完只是第一步，真正决定生死的是后面那轮自查。技术标、商务标里最常见也最致命的问题往往是三类：踩了招标文件里的废标红线、暗标部分留下了公司或人员身份信息、正文数据与证件或业绩材料对不上。这类问题靠人工通读很容易漏，一是检查项太多，二是不同专业的关注点差异大。

下面介绍的 Skill 把这件事规则化：初稿完成后，把标书和本项目招标文件交给它做一次综合自检，按七要素输出缺陷清单并分级。它不是写作工具，也不改写标书正文，只负责找问题。

这是什么¶

「老默标书审核大师」（lm-biaoshu-shenhe）是发布在 SkillHub 上的社区 Skill，坐标 @user_f67fc7cb/lm-biaoshu-shenhe，版本 1.0.0，来源标注为 community，分类 office-efficiency，标签 requires_api_key=false，即不依赖额外 API Key。发布者为 user_f67fc7cb。

它的定位一句话：技术标 / 商务标初稿完成后的综合自检评审工具。解决的问题是，在人工终审之前，先跑一遍覆盖面足够宽的硬检查，把明显会导致废标或扣分的问题捞出来。

当前包为基础版，包含通用规则与脚本，不含企业私有经验。需要把企业内部的历史审核标准加进去时，按包内 references/扩展指引.md 扩展。

检查范围：62 项自动化硬检查¶

官方简介列出的检查维度共 62 项，覆盖面如下：

• 废标红线：招标文件中明确写「否决投标」「废标」的条款逐条比对。
• 暗标身份泄露：暗标部分是否出现公司名、人员名、印章信息等可识别身份的内容。
• 格式元数据：字体、字号、行距、页边距、页眉页脚、表格样式等与招标文件要求是否一致；文件属性中的作者、单位、修订记录等元数据是否清理干净。
• 数据一致性：目录与正文标题、页码、图表编号、前后章节数据是否自洽。
• 规范引用时效性：引用的规范、标准、法规版本是否现行有效，是否已被替代或废止。
• AI 腔调：识别通篇套话、无实质内容的段落，避免评审时被判定为模板化应答。
• 图文与跨标段一致性：同一工程在不同标段文件中的技术参数、工程量、工期表述是否打架。

这些检查项不是提示词里的一句话建议，而是规则化的硬检查，命中即记录。

内置 16 类工程专业审核重点库¶

通用规则之外，Skill 内置了 16 类工程专业的审核重点库，覆盖公路、国铁、市政、房建、水利、轨道等专业。使用时按需动态加载：识别到标书所属专业后，只加载对应专业的检查重点，避免无关规则干扰判断。

这样做的实际意义是，公路项目的工期与取土场约束、房建项目的强制性条文、水利项目的防洪标准，各自的关键点差别很大，放在一套通用规则里要么漏要么误报。

多标段防串标与实证核验¶

这一组能力针对的是同一主体同时投多个标段的情况，是串标认定的主要证据来源：

• 班子比对：多份标书的项目管理班子人员构成、排列顺序、岗位设置做交叉比对，识别高度重合或顺序雷同。
• 他标段词扫描：在当前标书中扫描指向其他标段的词句，例如「本标段之外」「另见某标段」「与其他标段共用」之类表述。
• 证件 OCR 实证核验：对扫描件做 OCR 后回读，核对证件号、有效期、发证机关与正文填写是否一致，避免正文写对但证件扫描件实际不符。
• 业绩矛盾交叉核验：同一业绩在不同章节、不同表格中的金额、时间、项目负责人、合同编号是否互相矛盾。

前两项用于防串标，后两项用于把「纸面一致」落到「实证一致」。

缺陷输出与分级¶

每条缺陷按七要素输出，缺一项都会影响后续整改闭环：

1. 位置：章节号或表格位置。
2. 原文：命中问题的原文摘录。
3. 类型：所属检查维度。
4. 等级：P0 / P1 / P2。
5. 依据：判定所依据的招标文件条款或通用规则。
6. 整改建议：具体怎么改。
7. 关联：与哪一条缺陷属于同一原因或同一章节，便于合并处理。

分级沿用行业习惯：P0 一般为可能导致废标的硬伤，P1 为明显扣分项，P2 为规范性或可读性问题。具体等级判定口径由该 Skill 的内置规则确定。

合规基准：以本项目招标文件为准¶

这一点值得单独强调：合规与废标判定以本项目招标文件为基准，不使用硬编码默认值。

也就是说，Skill 不会拿一套固定的金额门槛、资质等级或评分标准去套所有项目。运行前需要把本项目招标文件提供给它，判定时回读招标文件原文条款作为依据，缺陷清单里的「依据」一栏因此能落到具体条款，而不是笼统的「不符合要求」。

招标文件没写清楚的地方，Skill 不会自行推断出一个默认值补上去。

触发与使用方式¶

Skill 通过触发词唤起，官方列出的触发词包括：全面审查、全维度审查、标书审查、质量检测、查废标、暗标审查、多标段防串标、OCR 证件实证、业绩矛盾交叉核验、班子比对、扫描件 OCR 查询。

典型用法是把材料路径交代清楚，再给出对应触发词：

对本项目的技术标初稿做全面审查，招标文件见 /data/招标文件.pdf，
标书见 /data/技术标.docx。

多标段场景需要同时给出各标段文件路径，并明确要做防串标比对：

对 A、B 两个标段做多标段防串标审查，含班子比对与他标段词扫描。

资料中未给出安装命令或 CLI 参数，Cursor、Codex CLI、Claude Code 下的安装方式差异也未在可抓取页面中说明，需要时以官方页面为准。安装后在对话中直接使用上述触发词即可唤起。

适用场景与注意¶

适合这几类情况：

• 技术标 / 商务标初稿完成后的第一轮自查，在送人工终审之前。
• 多标段同时投标，需要自查是否存在串标痕迹。
• 扫描件比例高的项目，需要核对证件实证信息。
• 需要一份带条款依据和整改建议的缺陷清单，用于内部整改跟踪。

几点限制：

• 基础版不含企业私有经验。如果企业内部有自己的审核口径，需要按 references/扩展指引.md 自行扩展，直接用基础版跑出来的结果不含这部分。
• 它不替代终审。P0 / P1 的最终判定仍应由熟悉该项目的评审人员确认。
• OCR 实证核验依赖扫描件清晰度，模糊或倾斜的扫描件可能读不出关键字段，这类情况应标注为「未能核验」而非「核验通过」。
• 判定基准是本项目招标文件，招标文件本身有歧义时，Skill 给出的结果也会跟着模糊，这类条款需要人工向招标方澄清。

结尾¶

这个 Skill 的价值在于把标书自查从「靠人记忆」变成「按规则跑一遍」：62 项硬检查负责广度，16 类专业重点库负责深度，防串标与 OCR 实证负责证据链，七要素输出负责整改闭环，而以招标文件为基准则保证判定不跑偏到其他项目上。

官方地址：https://api.skillhub.cn/user_f67fc7cb/lm-biaoshu-shenhe
SkillHub 页面：https://www.skillhub.cn/skills/user_f67fc7cb/lm-biaoshu-shenhe