前言¶

寫標書的人通常卡在兩件事上：一是招標文件幾十上百頁，廢標項、評分項埋在正文裏，靠人工逐頁篩；二是技術標寫到後面章節，前後數據、名稱、方案描述對不上，臨提交才發現邏輯衝突。通用大模型能幫你潤色段落，但它不知道「廢標項」爲什麼要單獨列一張表，也不知道多個標段的目錄該怎麼拆。

Yibiao 就是針對這個場景的 Skill。

這是什麼¶

Yibiao 是招投標/標書寫作領域的專家技能，座標 @user_f95727ff/bid-document-writer，版本 1.0.0，來自社區（community），分類 content-creation，發佈者 user_f95727ff，標籤 requires_api_key=false。

它的方法論來自開源社區項目 OpenBidKit_Yibiao，覆蓋從招標文件進到 Word/PDF 出的完整流程。定位是：把標書寫作拆成可執行步驟，讓 Agent 按步驟走，而不是自由發揮。

核心功能¶

主流程是七個環節：

1、招標文件解析：把招標公告、技術要求、商務條款讀進來，抽出約束條件。
2、多標段識別：一份招標文件含多個標段時，區分各標段的範圍、資格與評分差異。
3、目錄生成與編輯：按標段和評分項生成目錄骨架，可編輯調整。
4、全局事實設定：先定一批全局事實（公司名、資質、業績數據、方案口徑），後面正文統一引用。
5、正文撰寫/擴寫：按目錄逐節寫技術標或商務標內容。
6、圖文編排：插入圖表和圖片，控制位置與說明文字。
7、Word/PDF 導出：產出可提交的文檔。

配套的四個檢查與優化能力：

• 廢標項檢查：按風險、錯別字、邏輯三類分別掃描。
• 標書查重：從元數據、目錄、正文、圖片四個維度比對。
• 企業知識庫 RAG 檢索：用企業自有資料庫輔助寫作，而不是憑空生成。
• 全文一致性保障與 Prompt 緩存成本優化：前者保證前後表述不打架，後者在長文檔場景下控制調用成本。

安裝與啓用¶

已抓取資料裏只給出元數據，沒有安裝命令、目錄路徑或配置文件字段。可確認的信息：

座標：@user_f95727ff/bid-document-writer
版本：1.0.0
來源：community
分類：content-creation
標籤：requires_api_key=false
官方地址：https://api.skillhub.cn/user_f95727ff/bid-document-writer
SkillHub 頁面：https://www.skillhub.cn/skills/user_f95727ff/bid-document-writer

requires_api_key=false 表示使用該 Skill 不需要額外配置 API Key。由於資料中沒有給出 npx skills add 之類的安裝命令，也沒有說明 Cursor、Codex CLI、Claude Code 各自的接入差異，這裏不提供未經覈實的命令。需要安裝時，請以官方頁面爲準。

典型用法¶

官方資料給出的觸發方式是意圖驅動的：當用戶需要寫或生成投標技術方案、撰寫技術標或商務標、檢查廢標風險、對標書查重、用企業資料庫輔助寫作、優化標書質量與一致性，或提到「招投標/投標/標書/技術標/商務標/廢標項/查重/投標方案/評分項」時使用。

也就是說，實際操作是把招標文件或需求描述交給 Agent，由它按上述七個環節推進。例如先給招標文件讓 Agent 解析並識別標段，再讓它生成目錄供你編輯，確認後再進入正文撰寫，最後要求導出 Word 並跑一遍廢標項檢查。

適用場景與注意¶

適合：經常寫投標文件、需要處理多標段、對廢標風險敏感的團隊或個人；以及已經有企業資料庫、希望寫作時引用自有資料的場景。

注意幾點：

• 它輸出的是結構化寫作流程，最終標書仍需人工覈對資質數據、業績真實性和技術承諾。
• 企業知識庫 RAG 的效果取決於資料庫本身的質量和權限邊界。
• Prompt 緩存成本優化對長文檔更有意義，短文檔收益有限。
• 本次抓取到的元數據顯示評分 100000、下載 963，與早期快照的數值不同，以官方頁面實時數據爲準。

小結¶

Yibiao 的價值在於把標書寫作從「一次性生成一大段文字」改成「解析、拆標段、定目錄、定事實、寫正文、編排、導出」的順序流程，並配上廢標項檢查和查重。對招投標場景來說，流程正確比文字漂亮更重要。

官方地址：https://api.skillhub.cn/user_f95727ff/bid-document-writer