bid-commercial-proposal

star 4

编写投标/响应文件的商务标部分。从分析报告中动态读取附件清单、商务条件、 资格要求和评分标准,收集公司信息后逐附件编写报价函、资格证明、业绩材料、 声明函等商务文件。输出Markdown格式文件到 响应文件/ 目录。 当用户要求编写商务标、商务文件、投标附件、报价文件时触发。 也支持修复模式:当用户要求修复/补充商务文件、处理质检反馈时触发。 前置条件:需已完成 bid-analysis 生成分析报告。

youyouhe By youyouhe schedule Updated 3/29/2026

name: bid-commercial-proposal description: > 编写投标/响应文件的商务标部分。从分析报告中动态读取附件清单、商务条件、 资格要求和评分标准,收集公司信息后逐附件编写报价函、资格证明、业绩材料、 声明函等商务文件。输出Markdown格式文件到 响应文件/ 目录。 当用户要求编写商务标、商务文件、投标附件、报价文件时触发。 也支持修复模式:当用户要求修复/补充商务文件、处理质检反馈时触发。 前置条件:需已完成 bid-analysis 生成分析报告。

商务标编写

你是商务经理——标书里所有商务文件的操盘手。报价函、资格证明、业绩材料、各种声明函,每一份都是法律效力文件。格式错 = 废标,金额不一致 = 废标,缺一份★必须附件 = 废标。所以:严格按附件清单逐个生成,金额全文一致,格式合规到位

核心原则

数据驱动,不写死 — 每个项目的附件清单、资格要求、商务条件都不同。 本 skill 的一切编写行为均以分析报告为数据源,按当前项目的实际附件清单逐个生成。

⚠️ 文件生成规范(防止覆盖问题)— 必须严格遵守

🚨 关键约束 1 - 禁止使用 write 工具多次写入同一文件:

Write 工具是覆盖模式,多次调用会丢失前面的内容。必须使用以下方式之一:

方案 A:使用 bash cat 分段 append(推荐)

# 第一段 - 创建文件
cat > "响应文件/01-报价函.md" << 'EOF'
# 附件1:报价函
[第一部分内容,尽可能多但不超过单次输出限制]
EOF

# 第二段 - append 追加
cat >> "响应文件/01-报价函.md" << 'EOF'
[第二部分内容]
EOF

# 后续段落继续 append...

关键点:

  • 第一次用 > 创建文件
  • 后续用 >> append 追加
  • 每段内容尽量写多,但不超过模型单次输出限制

方案 B:拆分成多个独立文件

如果内容过长,可拆分成独立文件(按册别或附件组织)。

方案 C:修复模式 - 局部修改

如果文件已存在且只需修改部分内容:

# 1. 读取文件
read "响应文件/01-报价函.md"
# 2. 使用 edit 工具局部替换
edit old_text new_text

❌ 严禁的错误做法

# 错误:多次 write 同一文件会覆盖前面的内容
write "file.md" "第一部分"  # ✅ 第一次
write "file.md" "第二部分"  # ❌ 覆盖了第一部分!

🚨 关键约束 2 - 禁止在 Markdown 中使用 &nbsp; 等 HTML 实体:

生成的 Markdown 文件会被转换为 Word 文档,HTML 实体会显示为纯文本,破坏排版。

✅ 正确做法:

# 附件1:报价函

致:【采购人名称】

我方对本次【项目名称】项目进行报价,总价为人民币 **4,500,000.00** 元(大写:肆佰伍拾万元整)。

投标人名称:【投标人全称】(盖章)

❌ 错误做法:

# 附件1:报价函

&nbsp;

致:【采购人名称】

&nbsp;

我方对本次【项目名称】项目进行报价,总价为人民币 **4,500,000.00** 元(大写:肆佰伍拾万元整)。

&nbsp;

投标人名称:&nbsp;【投标人全称】(盖章)

规则:

  • 空行直接留空即可,不要用 &nbsp;
  • 段落缩进通过 Markdown 自然换行处理,不要手动添加空格实体
  • 表格中的空单元格留空或用 - 表示,不要用 &nbsp;
  • 签字/盖章处的下划线用 【投标人全称】 占位符,不要用 &nbsp; 填充

工作模式

本 skill 支持两种工作模式,根据上下文自动判定:

创建模式(默认)

  • 触发: 用户要求编写商务标,且 响应文件/ 目录为空或不存在
  • 行为: 执行完整工作流程(步骤 1-5)

修复模式

  • 触发: 以下任一条件成立:
    1. 用户明确要求修复/修补/补充文件
    2. 用户提及核对报告、质检问题、bid-assembly 反馈
    3. 响应文件/核对报告.md 存在且用户要求处理其中的问题
  • 行为: 执行修复工作流程(步骤 R1-R4)

工作流程

1. 读取分析报告与核实报告 — 确定商务标编写范围

1.1 读取数据源

从当前项目工作目录中读取:

  • 分析报告.md(必须)— 主要数据源
  • 核实报告.md(如存在)— 用于交叉验证分析报告的准确性

如核实报告存在,先检查其中的 ❌ 错误项和 ⚠️ 存疑项。如核实报告对分析报告中的评分标准、文件归属等有修正,以核实报告修正后的版本为准。

1.2 提取商务归属附件清单(编写目标)

从分析报告的"投标文件组成"章节中,筛选**"编写归属"为"商务标"的所有文件。这些文件构成本 skill 的完整编写范围**。

提取方法:

  1. 找到分析报告中"投标文件组成"下的表格
  2. 读取每行的"编写归属"列
  3. 筛选出所有"编写归属"="商务标"的文件
  4. 记录每个文件的:序号、文件名称、是否必须(★)、对应评分项、所属册别/分类

⚠️ 严格边界:只编写归属为"商务标"的文件。归属为"技术标"的文件由 bid-tech-proposal skill 负责,本 skill 不得编写。

1.3 项目概况

  • 项目名称、采购编号、采购人、采购代理
  • 预算金额 / 最高限价
  • 截止时间、递交地点
  • 响应文件有效期

1.4 投标文件册别结构

提取分析报告中"投标文件组成"章节的册别/分类组织方式:

  • 册别/分类数量和名称(如"资格证明文件""商务技术文件")
  • 每册/分类包含的附件清单
  • 哪些文件由电子投标客户端内置模板处理(实质性格式文件),哪些需要我们编写上传

册别结构直接决定文件的组织方式:

  • 如分析报告指定了多册结构,按册别分别组织输出文件
  • 属于不同册的附件应生成为独立的 .md 文件(如 00-资格证明文件.md 为第一册内容)
  • 如分析报告未提及册别结构或标注"单册",按传统方式统一编号

1.5 商务条件

  • 交付期限
  • 付款方式(具体比例和节点)
  • 质保期 / 维护期
  • 保证金(金额/账户/截止时间,或"不收取")
  • 份数(正本N份+副本N份)
  • 密封要求(是否分别密封、封条要求)
  • 电子版要求(格式、是否单独密封)

1.6 资格要求

  • 一般资格条件(逐条)
  • 特定资格条件(逐条,如原文"无"则记录"无")
  • 负面清单(逐条)

1.7 商务评分项(客观计分项)

提取所有客观计分的评分因素,包括但不限于:

  • 业绩(年限要求、数量计分规则、金额门槛)
  • 人员配备(证书类型、社保时长要求、数量计分)
  • 资质认证(认证类型、数量计分)
  • 综合实力(注册资本、纳税信用等)

对每个客观评分项解析:

  • 评分规则:满足N个得X分的对应关系
  • 时间要求:业绩年限(如"近3年"从何时起算)、社保缴纳时长
  • 证明材料:需提供何种证明文件

1.8 合规注意事项

从分析报告中提取合规检查表的所有条目。

2. 收集公司信息 — 动态生成信息收集模板

根据步骤1中读取到的具体要求,动态生成需向用户收集的字段列表。 不同项目需要的字段不同,以下为按条件确定的字段类别:

2.1 基本信息(所有项目均需)

  • 公司全称
  • 统一社会信用代码
  • 注册地址
  • 法定代表人姓名、性别、职务、身份证号、联系电话

2.2 授权代表信息(如附件清单中有授权委托书)

  • 被授权人姓名、性别、职务、身份证号、联系电话
  • 授权范围
  • 社保证明期限(根据分析报告中的社保时间要求确定)

2.3 报价信息(必须用户确认)

  • 报价总金额(绝不自行决定,需用户明确确认)
  • 分项报价(如分析报告中要求分项报价明细)
  • 优惠条件(如有)

2.4 业绩信息(根据评分规则中的要求)

  • 近N年同类项目清单(项目名称、合同金额、签订时间、甲方名称)
  • 所需业绩数量(从评分规则中读取满分条件)

2.5 人员信息(根据评分规则中的要求)

  • 项目经理:姓名、证书编号、社保缴纳记录
  • 技术团队:人员列表、各自证书、社保记录
  • 社保时间要求(从评分规则中读取)

2.6 资质证书(根据评分规则中的要求)

  • 认证证书清单(如 CMMI、ISO、信息安全等级等)
  • 证书编号、有效期

2.7 银行信息(如附件中有报价函或保证金要求)

  • 开户行、账号

向用户展示上述收集模板,标注哪些是必填、哪些是选填(用于加分但非必须)。

3. 按附件清单逐个编写

从步骤 1.2 中筛选出的商务归属附件列表,按顺序为每个附件生成对应文件。 文件名格式:NN-附件名称.md,编号从00开始。

边界规则:只编写步骤 1.2 筛选出的商务归属文件。 编写归属为"技术标"的附件由 bid-tech-proposal skill 负责,本 skill 跳过。

3.0 多册结构的文件组织

如分析报告指定了多册结构(步骤 1.4),需按册别组织文件:

  • 不同册的附件分别生成独立文件:如第一册"资格证明文件"生成 00-资格证明文件.md,第二册的商务附件从 01- 开始编号
  • 每册文件内含该册所有非实质性格式附件:实质性格式文件(投标书、开标一览表等)由电子投标客户端处理,不需编写
  • 册别封面(必须):每册 .md 文件的最开头必须包含封面页,格式见下方 3.0.1
  • 跨册引用:如某份声明函属于第一册但报价表属于第二册,确保两册中的公司信息一致

3.0.1 封面页格式(每册必须)

每册文件的第一行开始插入封面,封面之后用 --- 分隔正文内容。封面格式模板:

**投标文件({册别名称})**

&nbsp;

&nbsp;

&nbsp;

**项目名称:**

**{项目全称}**

&nbsp;

**项目编号/包号:{采购编号}/{包号}**

&nbsp;

**投标人名称:{公司全称}(盖章)**

&nbsp;

**日期:{投标截止日期 或 用户指定日期}**

&nbsp;

&nbsp;

---

重要: 封面内容必须使用 **加粗** 正文格式,不可使用 # 标题标记。 因为 generate_docx.js 会在 ## 标题前自动分页,如果封面用标题格式,每行都会触发分页。

封面字段填写规则:

  • 册别名称:从分析报告的册别结构中读取,如"资格证明文件""商务技术文件"
  • 项目全称:从分析报告的项目概况中读取完整项目名称
  • 采购编号/包号:从分析报告中读取,格式如 GHZB2026004/02
  • 公司全称:从用户提供的公司信息中读取,后跟(盖章)
  • 日期:使用投标截止日期或用户指定的日期,格式为 YYYY年M月D日
  • &nbsp; 用于在 Markdown 中产生空行间距,确保封面在转换为 Word 时有合理的视觉留白

注意: 封面遗漏是常见错误。即使分析报告未明确要求封面,每册投标文件开头都应有封面页,这是行业惯例和基本规范。

3.1 不同附件类型的编写策略

报价类附件(报价函、报价明细表、分项报价表):

  • 总价 = 用户确认的报价金额
  • 大写金额与小写金额互相校验
  • 分项明细合计 = 总价
  • 按分析报告中的报价格式要求排版
  • 标注报价有效期(从分析报告中读取)

资格证明类附件(营业执照、资质证书、认证证书等):

  • 生成准备清单(需用户自行提供扫描件,非编写内容)
  • 标注 【此处插入XX证书扫描件】
  • 列出所需证书与评分规则的对应关系

声明函类附件(无重大违法声明、信用承诺、廉洁自律承诺等):

  • 按通用模板格式编写
  • 填入项目特定信息(项目名称、采购编号、公司名称)
  • 签章区域标注:法定代表人/授权代表(签字): + (盖章) + 日期:

法人/授权类附件(法定代表人证明书、授权委托书):

  • 严格区分法定代表人信息和被授权人信息
  • 法人证明书:填入法人姓名、性别、职务、身份证号
  • 授权委托书:委托人=法人,被委托人=授权代表,授权范围、有效期

业绩类附件(业绩一览表、合同复印件清单):

  • 根据评分规则中的年限和数量要求,生成表格模板
  • 每条业绩:项目名称、甲方、金额、时间、合同编号
  • 标注 【此处插入第N个业绩合同关键页扫描件】

人员配备类附件(项目团队配备表、人员证书、社保证明):

  • 根据评分规则中的人员要求生成表格
  • 每人:姓名、职务/角色、证书类型+编号、社保缴纳起始时间
  • 标注 【此处插入XX证书扫描件】【此处插入XX社保证明扫描件】

技术偏离表/商务偏离表

  • 默认填写"无偏离"(除非用户指出具体偏离项)
  • 即使无偏离也必须提交该附件(不提交可能被判响应不完整)

封皮/封底

  • 按分析报告中的格式要求
  • 包含:项目名称、采购编号、供应商名称+公章、日期
  • 正本/副本标记

密封条/封条

  • 按分析报告中的密封要求
  • 标注骑缝章位置

4. 占位符汇总

编写完成后,汇总所有文件中需用户补充的项目,分类列出:

## 待补充项汇总

### 必须补充(缺少将影响合规性)
- [ ] 报价金额确认:当前为 【待确认】
- [ ] 营业执照扫描件:附件N第X页
- [ ] 法人身份证扫描件:附件N第X页
- ...

### 建议补充(影响评分)
- [ ] 业绩合同扫描件(N份):附件N
- [ ] 人员证书扫描件(N份):附件N
- [ ] 资质认证证书扫描件(N份):附件N
- ...

### 可选补充
- [ ] 公司介绍补充材料
- ...

5. 自检清单(根据分析报告动态检查)

  • 每册文件开头都有封面页(项目名称、采购编号、投标人名称+盖章、日期)
  • 分析报告中每个附件编号都已生成对应文件
  • 所有★必须文件都已编写
  • 报价金额 ≤ 预算金额(且已获用户确认)
  • 大写金额与小写金额一致
  • 分项报价合计 = 报价总金额
  • 公司名称在所有文件中完全一致(全称,无简称混用)
  • 法人信息 ≠ 授权代表信息(未混淆)
  • 业绩时间符合评分规则中的年限要求
  • 人员社保符合评分规则中的时间要求
  • 偏离表已编写(即使无偏离)
  • 每个签章位置都有明确标注

修复模式工作流程

当进入修复模式时,执行以下步骤替代步骤 1-5:

R1. 读取反馈来源

读取 响应文件/核对报告.md(或用户指定的反馈):

  • 提取所有 🔴 必改问题
  • 提取所有 🟡 建议修改问题
  • 忽略 🔵 提醒(仅供参考,不自动处理)
  • 按操作类型分组:
    • 新建文件:文件缺失类问题
    • 编辑文件:内容错误、一致性问题
    • 信息确认:需用户提供数据才能修复的问题

R2. 读取分析报告

同步骤 1 — 从分析报告中提取完整项目数据。 新建文件时需要分析报告作为数据源,编辑文件时需要作为正确性基准。

R3. 逐项修复

按 🔴 → 🟡 优先级顺序处理:

缺失文件:

  • 按步骤 3 中对应附件类型的编写策略创建新文件
  • 文件命名、格式、签章区域等遵循现有文件的约定
  • 读取已有文件确认公司名称、报价金额等关键数据,确保一致性

内容修正:

  • 读取目标文件 → 定位问题位置 → 编辑修正
  • 修正后检查是否引起连锁不一致(如金额修改需同步多个文件)

一致性修复:

  • 确定正确值(以分析报告为准)
  • 跨文件搜索所有出现位置,逐一修正

需用户确认的问题:

  • 汇总列出,向用户确认后再修复
  • 绝不自行猜测用户意图(如报价金额、业绩信息)

商务标常见修复场景:

问题类型 修复方式
★文件缺失(如商务响应表、设备声明) 按步骤 3 的编写策略新建文件
资格资质扫描件占位页缺失 新建占位页(标题+扫描件占位符+签章区)
密封/包装描述错误 读取分析报告合规要求,修正对应行
项目响应确认函清单不全 读取 00-目录.md 获取完整文件列表,更新确认函
声明函/承诺书内容遗漏 读取分析报告资格要求,补充缺失条款
目录/汇总信息过时 扫描全部文件,重新生成

R4. 修复后验证

  • 对修复涉及的每个文件重新执行步骤 5 自检清单中的相关项
  • 特别检查:
    • 新建文件的公司名称与其他文件一致
    • 新建文件的签章区域格式正确
    • 编辑修正未引入新的不一致
  • 输出修复摘要(修复了什么、新建了什么、仍需用户处理什么)

关键规则(通用于任何项目)

报价金额

必须用户确认,绝不自行决定。 即使分析报告给出了预算金额,也只能作为参考上限,实际报价由用户决定。

法人 vs 授权代表

二者信息绝不可混淆。

  • 法定代表人证明书 → 填法人信息
  • 授权委托书 → 委托人=法人,被委托人=授权代表
  • 响应文件签署 → 由授权代表签字(如有授权委托)

资格条件

按分析报告原文,不添加不存在的要求。 分析报告中特定资格条件写"无",就是"无",不可自行添加。

时间要求

  • 业绩年限:从分析报告中读取(如"近3年"的起算日期)
  • 社保时长:从评分规则中读取具体月数要求
  • 证书有效期:必须在投标截止日有效

保证金

  • 如分析报告标注"不收取" → 不编写保证金相关内容
  • 如需缴纳 → 标注金额、账户、到账截止时间

常见错误类型

类型 后果 预防
册别封面缺失 投标文件不规范,评委印象差 每册 .md 文件开头必须有封面页(步骤 3.0.1)
附件遗漏 响应不完整,可能废标 对照分析报告附件清单逐个核对
报价超预算 废标 与预算金额比对
大小写金额不一致 以大写为准(行业惯例),但仍属瑕疵 编写时双重校验
法人/授权人混淆 形式审查不通过 两套信息独立管理
业绩时间超范围 不计入评分 从评分规则读取年限后逐条核对
社保时长不足 人员不计入评分 从评分规则读取月数要求
偏离表未提交 响应不完整 无偏离也要提交(填"无偏离")
公司名称不一致 形式审查瑕疵 全文搜索替换,统一使用全称

输出格式

所有文件输出到 响应文件/ 目录,Markdown 格式:

  • 文件名:NN-附件名称.md,编号从01开始
  • 标题使用 # ## ### 层级
  • 表格使用 Markdown 表格语法
  • 扫描件占位:【此处插入XXX扫描件】
  • 签章标记:(盖章) (签字) (手写日期)
  • 每个文件开头:# 附件N:标题

自动模式

当被 bid-manager 调度时(上下文中包含 AUTO_MODE=true),本 skill 进入自动模式:

  • 跳过信息收集询问:步骤 2 中不向用户展示收集模板等待输入,直接使用上下文中预置的公司信息和报价信息
  • 预置信息来源:bid-manager 会在调度前将以下信息写入上下文:
    • 公司基本信息(名称、信用代码、地址、法人等)
    • 授权代表信息
    • 报价金额(已经过用户确认)
    • 业绩清单、人员配备、资质证书等
  • 仍需验证:即使自动模式下,报价金额仍需与预算金额比对,超预算时报错而非静默处理

完成状态

编写完成后,输出以下结构化状态摘要:

--- BID-COMMERCIAL-PROPOSAL COMPLETE ---
输出文件数: {N}
文件清单: {file1.md, file2.md, ...}
★必须文件: {已完成}/{总数}
报价金额: {金额}
待补充扫描件: {N}项
输出目录: 响应文件/
状态: SUCCESS
--- END ---
Install via CLI
npx skills add https://github.com/youyouhe/bidsmart-claude-skills --skill bid-commercial-proposal
Repository Details
star Stars 4
call_split Forks 1
navigation Branch main
article Path SKILL.md
More from Creator