前言¶

標書初稿寫完只是第一步，真正決定生死的是後面那輪自查。技術標、商務標裏最常見也最致命的問題往往是三類：踩了招標文件裏的廢標紅線、暗標部分留下了公司或人員身份信息、正文數據與證件或業績材料對不上。這類問題靠人工通讀很容易漏，一是檢查項太多，二是不同專業的關注點差異大。

下面介紹的 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