对已编写的投标/响应文件进行全面质检,核对完整性、一致性和合规性。 从分析报告出发独立审查所有输出文件,检测遗漏、矛盾、占位符残留等问题, 生成核对报告、最终目录和装订指南。 当用户要求检查标书、核对投标文件、质检、汇总、组装最终文件时触发。 前置条件:需已完成 bid-tech-proposal 和/或 bid-commercial-proposal 的编写。
Resources
1Install
npx skillscat add youyouhe/bidsmart-claude-skills/bid-assembly Install via the SkillsCat registry.
SKILL.md
标书质检与组装
核心原则
独立审查,从源头出发 — 本 skill 不参与编写过程,从分析报告出发独立审查所有输出文件。
避免"自查自纠"盲区,以分析报告作为唯一校验基准。
工作流程
1. 加载数据
1.1 读取分析报告(校验基准)
从当前项目的分析报告(工作目录下的 分析报告.md)中提取:
- 项目概况(名称、编号、采购人、预算、截止时间)
- 评分标准全表(评分因素、分值、评分子维度、评分规则)
- 响应文件组成(全部附件清单 + ★标记)
- 技术需求(功能条目数、▲标注条目数)
- 商务条件(交付期、付款、保证金、份数、密封等)
- 资格要求(一般/特定/负面清单)
- 合规注意事项
1.2 扫描已编写文件
读取 响应文件/ 目录下所有 .md 文件:
- 记录文件名列表
- 读取每个文件的完整内容
- 提取每个文件的标题(附件编号+名称)
2. 完整性检查(对照分析报告)
逐项检查以下内容是否完整:
2.1 附件文件完整性
- 分析报告"响应文件组成"中的每个附件编号,是否都有对应的
.md文件 - ★必须文件:逐个标注存在/缺失状态
- 非★文件:检查是否存在,标注建议
2.2 评分项覆盖
- 分析报告中每个写作型评分因素,是否有对应的技术文档
- 分析报告中每个客观计分评分因素,是否有对应的商务文档/证明材料
2.3 评分子维度覆盖
对每个写作型评分因素:
- 从分析报告读取该因素的评分子维度列表
- 在对应文件中搜索是否每个子维度都有独立章节
- 统计覆盖率:已覆盖子维度数 / 总子维度数
2.4 附件编号连续性
- 检查附件编号是否连续(01、02、03...),是否有跳号或重号
3. 一致性检查(全文扫描)
跨文件扫描以下关键数据的一致性:
3.1 公司名称
- 提取所有文件中出现的公司名称
- 检查是否完全一致(全称 vs 简称、有无空格差异)
- 标注不一致的位置(文件名:行号)
3.2 报价金额
- 报价函中的总金额
- 报价明细表的分项合计
- 全生命周期成本分析中的合同期费用(如存在)
- 三者必须完全一致
- 检查大写金额与小写金额是否互相匹配
3.3 项目信息
- 项目名称:所有出现处是否与分析报告一致
- 采购编号:所有出现处是否与分析报告一致
- 采购人名称:所有出现处是否与分析报告一致
3.4 人员信息
- 人员配备表中的人员 vs 证书占位处提及的人员 vs 社保占位处提及的人员
- 三处的人员姓名、角色是否一致
3.5 时间/期限
- 交付期限:各文件中提及的交付期 vs 分析报告
- 质保期/维护期:各文件中提及的期限 vs 分析报告
- 响应文件有效期:各文件 vs 分析报告
- 业绩时间范围:业绩表中的项目时间 vs 评分规则中的年限要求
4. 合规性检查(对照分析报告"合规注意事项")
从分析报告中读取合规注意事项表,逐条检查:
4.1 密封要求
- 分析报告中的密封方式是否在封条/封皮文件中正确体现
- 是否需要分别密封(正副本/报价/电子版各自独立)
4.2 签署盖章
- 每个需签章的文件是否有
(盖章)(签字)标记 - 是否需要逐页签章(如分析报告中提及"逐页小签")
- 法人签字 vs 授权代表签字的区分是否正确
4.3 份数格式
- 正本/副本数量是否与分析报告一致
- 正本/副本标记是否已体现在封皮中
4.4 特殊要求
- ▲截图是否标注了盖章要求
- 合同复印件(如需要)是否标注了盖章
- 电子版格式要求是否提及
- 偏离表是否已编写(即使无偏离)
5. 内容质量抽检
5.1 技术响应表
- 统计响应表中的条目数
- 与分析报告中的技术需求功能条目数比对
- 检查是否有空响应行(响应说明为空或过短)
5.2 报价明细
- 分项金额合计 vs 报价总金额
- 报价总金额 vs 预算金额(是否超预算)
5.3 占位符清扫
- 全文搜索所有
【和】标记 - 分类统计:
- 图片/截图占位(预期存在,正常)
- 信息待填占位(如
【公司名称】【待确认】— 应已替换) - 扫描件占位(预期存在,需用户补充)
- 列出所有应已替换但仍存在的占位符
6. 输出
生成以下3个文件到 响应文件/ 目录:
6.1 核对报告.md
# 投标文件核对报告
## 项目信息
- 项目名称:XXX
- 采购编号:XXX
- 检查时间:YYYY-MM-DD
## 检查结果汇总
- 🔴 必改问题:N 个
- 🟡 建议修改:N 个
- 🔵 提醒注意:N 个
## 详细问题清单
### 🔴 必改(不改可能导致废标或重大扣分)
1. [具体问题描述] — 文件:XX,位置:第N行
### 🟡 建议改(影响评分或专业性)
1. [具体问题描述] — 文件:XX
### 🔵 提醒(不影响评分但需注意)
1. [具体问题描述]
## 覆盖率统计
| 检查维度 | 应有 | 实有 | 覆盖率 |
|---------|------|------|--------|
| ★必须附件 | N | N | 100% |
| 评分因素文件 | N | N | XX% |
| 评分子维度章节 | N | N | XX% |
| ▲截图占位 | N | N | XX% |
## 未替换占位符清单
| 占位符 | 文件 | 类型 |
|--------|------|------|
| 【XXX】 | NN-XX.md | 待填/待插图/待扫描 |问题分级标准:
- 🔴 必改:缺少★必须文件、评分因素无对应文件、报价超预算、公司名称不一致、大小写金额不匹配
- 🟡 建议改:评分子维度缺章节、响应说明过短、时间/期限不一致、签章标记缺失
- 🔵 提醒:非必须附件缺失、图片占位符统计、编号不连续
6.2 00-目录.md
# 响应文件目录
| 序号 | 附件名称 | 文件 | 状态 | 对应评分项 |
|------|---------|------|------|-----------|
| 1 | 报价函 | 01-报价函.md | ✅ 已完成 | 报价 |
| 2 | ... | ... | ✅/❌/⚠️ | ... |状态标记:
- ✅ 已完成:文件存在且通过检查
- ❌ 缺失:文件不存在
- ⚠️ 有问题:文件存在但有🔴或🟡问题
6.3 装订指南.md
# 装订指南
## 装订顺序
1. 封皮(正本/副本标记)
2. 目录
3. 附件1:报价函
4. 附件2:...
...
## 密封方案
(根据分析报告中的密封要求生成)
- 内包装:...
- 外包装:...
- 封条:...
## 签章清单
| 文件 | 签章类型 | 位置 | 备注 |
|------|---------|------|------|
| 报价函 | 公章+签字 | 末页 | |
| 授权委托书 | 公章+法人签字 | 末页 | |
| 技术响应表▲页 | 盖章 | 截图处 | 每张截图 |
| ... | ... | ... | ... |
## 递交物品清单
- [ ] 正本 N 份(胶装/装订)
- [ ] 副本 N 份
- [ ] 电子版 U盘/光盘 N 份(格式:PDF/Word)
- [ ] 密封条 + 骑缝章
- [ ] ...检查方法论(通用)
覆盖率优先于内容质量
先确保所有必须的文件、章节、条目都存在,再检查内容质量。
缺文件/缺章节 = 对应评分项0分或废标,内容瑕疵最多扣部分分。
交叉核对优先于单文件审查
同一数据(金额、名称、时间)在多个文件中出现时,必须全部一致。
单文件看起来正确但与其他文件矛盾 = 仍然是问题。
分析报告是唯一基准
所有检查标准从分析报告中动态读取,不依赖硬编码的检查项。
分析报告中未提及的要求,不作为检查标准。
问题定位要精确
每个问题必须指出:在哪个文件、第几行(或哪个章节)、具体是什么问题。
模糊的问题描述("某处可能有问题")对修改没有帮助。
机器可读摘要
核对报告末尾新增 JSON 摘要块,供 bid-manager 自动解析并分派修复任务:
<!-- ASSEMBLY_SUMMARY
{
"red_count": 3,
"yellow_count": 5,
"blue_count": 2,
"red_issues": [
{
"id": "R1",
"description": "缺少★必须文件:附件5-商务偏离表",
"file": null,
"target_skill": "bid-commercial-proposal"
},
{
"id": "R2",
"description": "技术响应表条目数不匹配(应有120条,实有115条)",
"file": "15-技术服务响应表.md",
"target_skill": "bid-tech-proposal"
}
],
"yellow_issues": [
{
"id": "Y1",
"description": "评分子维度'系统安全性'缺少独立章节",
"file": "16-总体技术方案.md",
"target_skill": "bid-tech-proposal"
}
]
}
ASSEMBLY_SUMMARY -->字段说明:
red_count/yellow_count/blue_count:各级别问题数量red_issues[]/yellow_issues[]:问题详情数组id:问题编号(R1/R2... 或 Y1/Y2...)description:问题描述file:涉及的文件(缺失文件时为 null)target_skill:应由哪个 skill 修复(bid-tech-proposal/bid-commercial-proposal/bid-analysis)
完成状态
质检完成后,输出以下结构化状态摘要:
--- BID-ASSEMBLY COMPLETE ---
🔴必改: {N}个
🟡建议: {N}个
🔵提醒: {N}个
附件覆盖率: {已有}/{应有}
★文件覆盖率: {已有}/{应有}
输出文件: 核对报告.md, 00-目录.md, 装订指南.md
状态: SUCCESS
--- END ---