AgentSkillsCN

bid-assembly

对已编写的投标/响应文件进行全面质检，核对完整性、一致性和合规性。 从分析报告出发独立审查所有输出文件，检测遗漏、矛盾、占位符残留等问题， 生成核对报告、最终目录和装订指南。 当用户要求检查标书、核对投标文件、质检、汇总、组装最终文件时触发。 前置条件：需已完成 bid-tech-proposal 和/或 bid-commercial-proposal 的编写。

中文原作
SKILL.md
--- frontmatter
name: bid-assembly
description: >
  对已编写的投标/响应文件进行全面质检，核对完整性、一致性和合规性。
  从分析报告出发独立审查所有输出文件，检测遗漏、矛盾、占位符残留等问题，
  生成核对报告、最终目录和装订指南。
  当用户要求检查标书、核对投标文件、质检、汇总、组装最终文件时触发。
  前置条件：需已完成 bid-tech-proposal 和/或 bid-commercial-proposal 的编写。

标书质检与组装

核心原则

独立审查，从源头出发 — 本 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

markdown
# 投标文件核对报告

## 项目信息
- 项目名称：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

markdown
# 响应文件目录

| 序号 | 附件名称 | 文件 | 状态 | 对应评分项 |
|------|---------|------|------|-----------|
| 1 | 报价函 | 01-报价函.md | ✅ 已完成 | 报价 |
| 2 | ... | ... | ✅/❌/⚠️ | ... |

状态标记：

  • •✅ 已完成：文件存在且通过检查
  • •❌ 缺失：文件不存在
  • •⚠️ 有问题：文件存在但有🔴或🟡问题

6.3 装订指南.md

markdown
# 装订指南

## 装订顺序
1. 封皮（正本/副本标记）
2. 目录
3. 附件1：报价函
4. 附件2：...
...

## 密封方案
（根据分析报告中的密封要求生成）
- 内包装：...
- 外包装：...
- 封条：...

## 签章清单
| 文件 | 签章类型 | 位置 | 备注 |
|------|---------|------|------|
| 报价函 | 公章+签字 | 末页 | |
| 授权委托书 | 公章+法人签字 | 末页 | |
| 技术响应表▲页 | 盖章 | 截图处 | 每张截图 |
| ... | ... | ... | ... |

## 递交物品清单
- [ ] 正本 N 份（胶装/装订）
- [ ] 副本 N 份
- [ ] 电子版 U盘/光盘 N 份（格式：PDF/Word）
- [ ] 密封条 + 骑缝章
- [ ] ...

检查方法论（通用）

覆盖率优先于内容质量

先确保所有必须的文件、章节、条目都存在，再检查内容质量。 缺文件/缺章节 = 对应评分项0分或废标，内容瑕疵最多扣部分分。

交叉核对优先于单文件审查

同一数据（金额、名称、时间）在多个文件中出现时，必须全部一致。 单文件看起来正确但与其他文件矛盾 = 仍然是问题。

分析报告是唯一基准

所有检查标准从分析报告中动态读取，不依赖硬编码的检查项。 分析报告中未提及的要求，不作为检查标准。

问题定位要精确

每个问题必须指出：在哪个文件、第几行（或哪个章节）、具体是什么问题。 模糊的问题描述（"某处可能有问题"）对修改没有帮助。

机器可读摘要

核对报告末尾新增 JSON 摘要块，供 bid-manager 自动解析并分派修复任务：

markdown
<!-- 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）

完成状态

质检完成后，输出以下结构化状态摘要：

code
--- BID-ASSEMBLY COMPLETE ---
🔴必改: {N}个
🟡建议: {N}个
🔵提醒: {N}个
附件覆盖率: {已有}/{应有}
★文件覆盖率: {已有}/{应有}
输出文件: 核对报告.md, 00-目录.md, 装订指南.md
状态: SUCCESS
--- END ---