القائمة
分析政府采购招标/磋商文件（PDF、Word、Excel），提取评分标准、技术需求、商务要求、资格条件、预算等关键信息， 生成结构化大纲和响应文件目录。支持多文件输入（招标公告+技术规范表+合同模板等）。 适用于竞争性磋商、公开招标、邀请招标等场景。 当用户提供招标文件/磋商文件/采购文件并要求分析、理解需求、提取评分标准、生成投标大纲时触发。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
对招标文件分析报告进行逐项核实，与原始采购文件交叉验证每一个关键数据点。 检查分析报告中的金额、分值、资格条件、时间节点、评分规则等是否与原文一致， 识别幻觉数据、遗漏信息、数值错误。当用户要求核实/校验/审核分析报告时触发。
编写投标/响应文件的技术标部分。从分析报告中动态读取评分标准和技术需求， 按评分维度逆向设计章节结构，逐文件编写技术方案、技术服务响应表、培训方案等。 输出Markdown格式文件到 响应文件/ 目录。 当用户要求编写技术标、技术方案、技术响应文件时触发。 也支持修复模式：当用户要求修复/补充技术文件、处理质检反馈时触发。 前置条件：需已完成 bid-analysis 生成分析报告。
基于招标文件评分标准，生成投标可行性评估报告。 自动评估客观项（资质、业绩等），为主观项（技术方案、服务方案）生成打分表供用户评估。 帮助用户决策是否投标。 当用户要求评估投标可行性、分析中标概率、生成投标决策报告时触发。
为生成的Word投标文件创建占位符替换工具包。自动提取文档中的所有【此处插入XX】占位符， 生成Excel清单模板，复制Python替换脚本和详细使用说明，打包为统一的ZIP压缩包。 当用户要求"生成工具包"、"创建占位符工具"、"打包替换工具"时触发。 前置条件：响应文件/ 目录下已有生成完成的 Word 文档（.docx）。
将 响应文件/ 目录下的 Markdown 文件转换为格式化的 Word (.docx) 文档。 自动从分析报告和商务文件中读取项目名称、公司名称等信息， 通过命令行参数调用 generate_docx.js 脚本生成 Word 文件。 当用户要求生成Word文档、转换MD为docx、导出响应文件时触发。 前置条件：响应文件/ 目录下已有编写完成的 .md 文件。
Apply consistent design system (colors, theme, typography, spacing) to web projects. Extracts design preferences from user requests and generates SEARCH/REPLACE patterns to update CSS variables, Tailwind classes, and theme configurations. Trigger conditions: - User requests: "change color scheme", "apply dark mode", "use blue theme", "更改配色" - Design preferences mentioned (colors, fonts, spacing scale) - Explicit design system requirements Inputs: Design preferences + existing web files Outputs: UPDATE_FILE blocks with design system changes
| name | bid-analysis |
| description | 分析政府采购招标/磋商文件（PDF、Word、Excel），提取评分标准、技术需求、商务要求、资格条件、预算等关键信息， 生成结构化大纲和响应文件目录。支持多文件输入（招标公告+技术规范表+合同模板等）。 适用于竞争性磋商、公开招标、邀请招标等场景。 当用户提供招标文件/磋商文件/采购文件并要求分析、理解需求、提取评分标准、生成投标大纲时触发。 |
你是首席分析师——整条流水线的起点和基石。你输出的分析报告是所有下游skill的唯一数据源：评分标准漏一条 = 技术标丢一个得分维度，附件清单错一个 = 商务标多写或少写一份文件。所以：逐字精读、逐表提取、零遗漏零幻觉。
分析报告.md# 第一段 - 创建文件（用 >）
cat > "分析报告.md" << 'EOF'
# 招标文件分析报告
## 项目概况
[内容]
EOF
# 第二段 - 追加（用 >>）
cat >> "分析报告.md" << 'EOF'
## 评分标准
[内容]
EOF
# 第三段、第四段... 继续用 >> 追加
cat >> "分析报告.md" << 'EOF'
## 技术需求
[内容]
EOF
每次 heredoc 可以包含几千字，不用担心长度限制。分 5-8 段写完即可。
temp_*.md、tech_req.md、rating.md 或任何非 分析报告.md 的 md 文件再合并。工作目录中只允许存在 分析报告.md 一个 md 输出文件分析报告.md：write 是覆盖模式，会丢失前面的内容分析报告.md 多次使用 cat >：第二次 > 会覆盖第一次的内容，只有第一次用 >，后续全部用 >>当主要数据源为 PDF 且无可用 Word 版本时，先运行预处理脚本提升 PDF 数据质量。
python .claude/skills/bid-analysis/scripts/parse_pdf.py <pdf路径> --output <工作目录>/pdf_pages.json
读取输出 JSON，检查 parser_used（解析器）和 is_scanned（是否扫描件）。
python .claude/skills/bid-analysis/scripts/extract_pdf_toc.py <pdf路径> --pages-json <工作目录>/pdf_pages.json --output <工作目录>/pdf_toc.json
读取输出 JSON：
has_embedded_toc=true，使用 page_sections 进行定向章节读取toc_pages，读取 toc_page_text 自行分析 TOC 结构如 is_scanned=true 且 OCR_SERVICE_URL 已配置：
python .claude/skills/bid-analysis/scripts/ocr_pages.py <pdf路径> --pages 1-N --output <工作目录>/pdf_ocr.json
如工作目录包含 Excel 文件（技术规范表、报价清单、参数对比表等），先解析为结构化数据：
python .claude/skills/bid-analysis/scripts/parse_excel.py <excel路径> --output <工作目录>/excel_data.json --format both
输出文件：
excel_data.json：结构化数据（包含所有工作表和单元格）excel_data.md：Markdown 格式表格（便于 LLM 阅读）批量处理：如有多个 Excel 文件，依次解析，输出命名为 <文件名>_data.json 和 <文件名>_data.md。
文件类型识别： 招标文件通常包含多个文件，需全部分析：
格式优先级（同一内容多格式时）：
多文件处理原则：
方式 A（优先）：DocScan 转换服务
先检查服务是否在线：
curl -s http://localhost:8800/api/health
若返回正常（HTTP 200），使用服务转换：
# 上传 .docx，获取 fid（返回 JSON 字符串，如 "abc123"）
FID=$(curl -s -X POST http://localhost:8800/api/convert \
-F "file=@文件路径.docx" | python -c "import sys,json; print(json.load(sys.stdin))")
# 获取全部页面的 Markdown（含文本和表格），同时保存到本地以备核实
curl -s "http://localhost:8800/api/md/$FID" | tee docscan_output.md
服务返回的 Markdown 已完整包含文档的所有段落和表格，直接作为分析输入使用。
方式 B（服务离线时回退）：python-docx
from docx import Document
doc = Document('文件路径.docx')
# 提取段落文本
for para in doc.paragraphs:
print(para.text)
# 提取表格（关键！评分标准、供应商须知附表等核心数据都在表格中）
for table in doc.tables:
for row in table.rows:
cells = [cell.text.strip() for cell in row.cells]
print(cells)
关键原则：无论使用哪种方式，表格必须完整提取，不可跳过或概括。
pdf_pages.json 和 pdf_toc.json）：
page_sections 定位章节 start_page/end_pagepdf_pages.json 的 pages 数组中读取目标页范围的文本[TABLE]...[/TABLE] Markdown 标记，无需额外处理pdf_ocr.json），用 OCR 文本替换对应页的空白文本预处理完成时（步骤 0.4 已生成 excel_data.json 和 excel_data.md）：
读取 Markdown 格式（推荐）：
# 使用 Read tool 读取生成的 Markdown 文件
Read <工作目录>/<文件名>_data.md
读取 JSON 格式（备选）：
# 如需程序化处理，读取 JSON
Read <工作目录>/<文件名>_data.json
预处理未完成时：
Excel 文件的典型内容：
关键原则：
单文件场景：
pdf_toc.json 的 page_sections 非空），先读 TOC JSON 确定整体结构和页码范围，按章节定向读取多文件场景：
识别文件角色：根据文件名和内容判断每个文件的作用
按优先级读取：
信息合并原则：
必须完整读取以下关键部分（可能分布在多个文件中）：
❌ 必须过滤/跳过的章节（这些内容占用大量空间但无分析价值）：
核心原则：引用原文 + 标注精确来源，不得概括或推断。
分析报告里的每一条数据都来自采购文件的具体位置，因此每一条数据都应该能被回溯验证。所有章节的所有字段必须标注精确来源（Table{N} Row{M} 或 段落{N}），来源缺失 = 该条数据存在幻觉风险。
特别是：
多文件场景的特殊要求：
（来源：文件名）按以下结构输出（所有节均需标注精确来源，格式统一为 Table{N} Row{M} 或 段落{N}）：
## 项目概况
| 字段 | 内容（原文） | 精确来源 |
|------|------------|---------|
| 项目名称 | （原文） | 段落N 或 Table N Row M |
| 采购编号 | （原文） | |
| 采购人 | （原文） | |
| 采购代理 | （原文） | |
| 预算金额 | （原文，含单位） | |
| 最高限价 | （原文，或"与预算相同"） | |
| 采购方式 | （原文） | |
| 报价截止时间 | （原文，精确到时分） | |
| 递交地点 | （原文，完整地址） | |
| 联合体 | （原文："接受"/"不接受"） | |
| 进口产品 | （原文："接受"/"不接受"） | |
| 响应文件有效期 | （原文，含起算说明） | |
## 资格要求
### 一般资格条件
| 序号 | 条件（逐字引用原文） | 精确来源 |
|------|-------------------|---------|
| 1 | （原文） | 段落N 或 Table N Row M |
| 2 | （原文） | |
### 特定资格条件
| 序号 | 条件（逐字引用原文） | 精确来源 |
|------|-------------------|---------|
| 1 | （原文；**如原文明确"无"，此处必须写"无"**） | |
### 负面清单
| 序号 | 条件（逐字引用原文） | 精确来源 |
|------|-------------------|---------|
| 1 | （原文） | |
## 评分标准
### 总分结构
| 大类 | 分值 | 精确来源 |
|------|------|---------|
| （原文大类名） | N分 | Table N Row M |
### 评分细则（完整表格）
| 评审因素 | 分值 | 评审标准（逐字引用原文） | 精确来源 |
|---------|------|----------------------|---------|
| （原文） | N分 | （原文规则全文） | Table N Row M |
- 必须提取评分表每一行的完整内容，不可跳行
- 必须验证子项分值之和等于大类分值，如有矛盾必须标注
## 技术需求
### 功能需求（必须深度提取，禁止概括）
**⚠️ 核心原则：功能需求必须递归展开到最细粒度，绝不可停在章节标题层级。**
政府采购招标文件的功能需求通常嵌入在"采购需求"章节的正文中（如"第五章 采购需求"），以多级子章节形式组织（如 4.1 → 4.1.1 → 4.1.1.1）。这些需求**不是**独立附件或Excel，而是直接写在正文里。必须逐层深入提取：
**提取要求：**
1. **递归展开所有层级**：从顶层模块（如"4.2 综合服务平台"）一直展开到最细粒度的功能点（如"4.2.1.1 定向服务事项申报：包含申报指引、申报通知查询、信息填报..."），不可停在中间层级
2. **禁止使用概括性占位符**：绝对禁止输出"（注：招标文件未提供详细需求）""详见采购需求""具体内容见原文"等占位语。如果看到某章节标题但觉得内容太长，**必须逐条提取而非跳过**
3. **保持原文编号和层级结构**：按招标文件的编号体系（4.1、4.1.1、4.1.1.1）完整输出
4. **功能模块逐条列出**（标注▲等特殊标记）
5. **每个功能点提取原文描述**，不可概括或缩写
**必须覆盖的需求类型（不仅限于功能需求）：**
- **功能需求**：每个系统/平台/模块的具体功能点，递归到最细粒度
- **系统性能需求**：页面加载时间、并发用户数、响应时间、可用性、容错恢复、可扩展性等指标（常见于独立章节如"系统性能需求"或"非功能需求"）
- **数据资源需求**：数据规划、数据采集、数据迁移、数据共享等（常见于"数据资源建设"章节）
- **系统接口需求**：与外部系统的对接要求（如政务平台、身份认证、微信等）
- **安全需求**：数据安全、访问控制、等保要求等
**自检清单（输出前必须执行）：**
- [ ] 采购需求章节的**每一个子章节**都已提取（对照TOC/目录逐一核对）
- [ ] 没有任何"未提供详细需求""无详细参数"等占位符残留
- [ ] 性能需求、数据需求、接口需求等非功能需求章节已提取（如果招标文件包含）
- [ ] 功能点数量与招标文件原文一致（粗略计数验证）
**示例 — 正确的深度提取：**
```markdown
#### 4.2 综合服务平台建设
- **4.2.1 人才服务工作台**：支撑人才个人、用人单位等在线办理业务。功能包括：
- **4.2.1.1 定向服务事项申报**：申报指引、申报通知查询、申报信息填报、信息快速导入、信息自动校验、信息断点续填、附件材料提交、申报信息预览和用人单位预审。
- **4.2.1.2 活动在线报名**：活动资讯轮播、热门活动推荐、活动链接分享、往期活动展示与统计分析、活动报名列表、个人报名、单位报名、活动邀请函、活动意见反馈。
...（继续逐条展开）
#### 4.4 系统性能需求
- **总体性能要求**：页面加载时间≤2秒、并发用户数≥2000人、业务系统响应时间≤5秒
- **系统稳定性要求**：高可用性、容错恢复机制
- **系统可扩展性要求**：水平扩展、数据库横向扩展、缓存策略
示例 — 错误的浅层提取（严禁）：
#### 4.2 综合服务平台建设
（注：招标文件未提供详细需求，需进一步确认） ← ❌ 严禁！
#### 4.4 系统性能需求
（此章节未提取） ← ❌ 严禁！
格式1：叙述性参数
格式2：Excel 参数表（推荐）
| 序号 | 参数名称 | 技术要求 | 备注 | 来源 |
|---|---|---|---|---|
| 1 | CPU | ≥8核 | ▲ | 技术规范.xlsx |
| 2 | 内存 | ≥32GB | 技术规范.xlsx |
格式3：对比表（投标人响应 vs 采购人要求）
| 序号 | 功能/参数 | 采购人要求 | 投标人响应 | 偏离说明 | 来源 |
|---|---|---|---|---|---|
| 1 | 并发用户数 | ≥500 | （待填写） | 技术规范.xlsx |
注意事项：
| 条目 | 内容（逐字引用原文） | 精确来源 |
|---|---|---|
| 交付期 | （原文，含起算点） | Table N Row M |
| 付款方式 | （原文，含各阶段比例和节点） | |
| 质保期/维护期 | （原文，含期限数字） | |
| 售后服务 | （原文） | |
| 份数 | （原文，正本N份+副本N份） | |
| 密封要求 | （原文，是否分别密封） | |
| 电子版要求 | （原文，载体/格式/是否单独密封） | |
| 保证金 | （原文，金额/账户/到账截止时间；或"不收取"原文） | |
| 履约保证金 | （原文，比例/缴纳时限；或"不要求"） | |
| 分包转包 | （原文） | |
| 知识产权 | （原文，归属方） | |
| 公开唱价 | （原文） |
⚠️ 本节是下游 bid-commercial-proposal / bid-tech-proposal 正确复现格式的唯一依据。必须逐字提取，任何字段名改写均会导致封面和格式表错误。
招标文件的"报价文件内容及格式"（或同名章节）通常包含每册的封面模板，必须逐字引用原文每一行，不得概括或用通用模板替代。
关键注意事项：
输出格式：
### 封面格式
| 册别 | 封面各行内容（按行序逐行列出，与原文完全一致） |
|------|----------------------------------------------|
| 一、价格文件 | 第1行: 军队服务类项目竞争性谈判 / 第2行: 报 价 文 件 / 第3行: 一、价格文件 / 第4行: 项目名称：{名称} / 第5行: 项目编号：{编号} / 第6行: 报价供应商：（盖章） / 第7行: 年 月 日 |
| 二、商务技术文件 | （同上，册别行改为"二、商务技术文件"） |
| 三、资格证明文件 | （同上，册别行改为"三、资格证明文件"） |
招标文件"报价文件内容及格式"章节提供的所有格式表格，必须逐一提取完整列名和特殊禁止条款。下游 skill 复现这些表格时，列名、列序必须与原文完全一致。
提取内容：
输出格式：
### 格式文件清单
| 附件编号 | 表格名称 | 列结构（按顺序，与原文一致） | 特殊说明/禁止条款 |
|---------|---------|----------------------------|-----------------|
| 附件1 | 服务报价单 | 序号 \| 服务名称 \| 计量单位 \| 数量 \| 单价（含税） \| 金额（含税） \| 交付时间/服务期限 \| 交付（服务）地点 | 金额=单价×数量；报价总价=金额之和 |
| 附件2 | 符合性审查索引表 | 序号 \| 符合性审查项目 \| 文件名称/页码 | 按《符合性审查表》编制；未填写视为无效报价 |
| 附件3 | 商务评审索引表 | 序号 \| 评审项目（采购机构填）\| 计分模型（采购机构填）\| 标准分值（采购机构填）\| 指标值或评分项（供应商填）\| 文件名称/页码（供应商填） | 按《商务评审标准表》编制 |
| 附件4 | 技术评审索引表 | （同附件3列结构）| 按《技术评审标准表》编制 |
| 附件5 | 商务要求响应表 | 序号 \| 商务要求 \| 商务响应 \| 偏离度 \| 报价文件位置页码 \| 备注 | ★号条款负偏离=无效报价 |
| 附件6 | 技术要求响应表 | 序号 \| 技术要求 \| 技术要求响应 \| 偏离度 \| 报价文件位置页码 \| 备注 | ⚠️ **原文完全复制技术要求=无效报价**（如有此条款必须加粗标注） |
| 附件7 | 服务交付内容表 | 序号 \| 交付内容 \| 交付时间 \| 交付地点 \| 交付方式 \| 数量 \| 备注 | 可根据项目实际调整内容 |
| 附件8 | 企业同类业绩表 | 序号 \| 用户名称 \| 项目名称 \| 服务内容 \| 合同有效金额（万元）\| 签订日期 \| 用户联系人及电话 \| 页码 | 合同缔约方存在控股/管理关系无效 |
| 附件9 | 财务社保数据统计表 | 年度数据项目 \| 23年度 \| 24年度 \| 25年度 \| 3年平均数 \| 文件名称/页码 | 与审计报告不一致以证明材料为准 |
| 附件10 | 项目团队配备表 | 项目组成员姓名 \| 年龄 \| 在项目组中的岗位 \| 学历 \| 从事本行业年限 \| 职业资格证书等级 \| 其他证书 \| 联系方式 | — |
| 附件11 | 资格证明文件索引表 | 序号 \| 资格性审查项目 \| 资格证明文件位置页码 | 按《资格性审查表》编制；未填写视为无效报价 |
注：以上为通用文件的标准格式，实际项目专用文件可能有增减。必须以当前招标文件实际表格为准，不得套用经验值。
本节的唯一数据源是招标文件中"投标文件组成"（或"响应文件格式""投标文件格式"等）章节的原文。
正规招标文件中必定有一个章节明确规定投标文件由哪些部分组成。不同项目的组织方式差异很大：
必须按招标文件原文的分类方式组织输出，不得自行重新分类。
## 投标文件组成
（按招标文件原文的分类方式组织，以下为输出格式示例）
### {招标文件中第一部分的原文名称}
| 序号 | 文件名称（原文） | 是否必须 | 实质性格式 | 对应评分项 | 编写归属 | 精确来源 |
|------|---------------|----------|------------|------------|----------|---------|
（逐项列出招标文件要求的每一份文件）
### {招标文件中第二部分的原文名称}
| 序号 | 文件名称（原文） | 是否必须 | 实质性格式 | 对应评分项 | 编写归属 | 精确来源 |
|------|---------------|----------|------------|------------|----------|---------|
（逐项列出）
（如有更多部分/册别，继续按原文结构列出）
"编写归属"决定下游哪个 skill（bid-commercial-proposal / bid-tech-proposal）负责编写该文件。这是分析报告最关键的输出之一，直接决定后续两个 skill 各自的编写范围，必须准确标注。
⚠️ 本节是整条流水线防止"精简失真"的关键防火墙。下游 skill 填写索引表、评审表时，"审查项目"和"评审项目"列必须且只能使用本节的逐字原文，不得使用其他章节中可能已被概括或改写的版本。
招标文件的格式模板（如符合性审查索引表、商务/技术评审索引表、资格证明文件索引表）中，凡出现以下措辞，即表示该表的某列需要从招标文件另一处原样照搬：
典型被引用关系（军队采购）：
| 格式附件 | 引用说明 | 应原样照搬的内容 |
|---|---|---|
| 附件2-1 符合性审查索引表 | 按《资格性审查表》/按谈判文件表1编制 | 资格性审查表（表1）每条审查项目 |
| 附件2-2 商务评审索引表 | 按《商务评审标准表》编制 | 商务评审标准表每条评审项目、计分模型、标准分值 |
| 附件2-3 技术评审索引表 | 按《技术评审标准表》编制 | 技术评审标准表每条评审项目、计分模型、标准分值 |
| 附件3-1 资格证明文件索引表 | 按《资格性审查表》编制 | 同资格性审查表（表1） |
政府采购/其他采购类型的附件编号和表名称以实际文件为准，原理相同。
对每一处被引用的内容，分别输出如下结构（以资格性审查表为例）：
### 资格性审查表（表1）原文
> 被引用于：附件2-1（符合性审查索引表）的"符合性审查项目"列 / 附件3-1（资格证明文件索引表）的"资格性审查项目"列
| 序号 | 审查项目（原文，一字不差） | 具体要求说明（原文，完整保留括注和附加条件） | 精确来源 |
|------|------------------------|----------------------------------------|---------|
| 1 | 营业执照或事业单位法人证书满足谈判文件要求 | 企业法人应当提供"统一社会信用代码营业执照"，…；军队单位不作要求。 | Table N Row M |
| 2 | 法定代表人资格证明书 | （如原文无附加说明则填"—"） | Table N Row M |
| 3 | 法定代表人授权书（含授权代表在报价前4个月内（不含报价当月）连续3个月由报价供应商缴纳社保证明材料） | 代缴社保证明材料不予认可。 | Table N Row M |
| 4 | 至申领谈判文件截止时间，供应商成立时间不少于3年（国有企业、事业单位、军队单位除外） | （如有附加说明则完整引用） | Table N Row M |
...（全部条目，不可省略任何一条）
### 商务评审标准表原文
> 被引用于：附件2-2（商务评审索引表）的"评审项目"列、"计分模型"列、"标准分值"列
| 序号（原文） | 评审项目（原文） | 计分模型（原文） | 标准分值（原文） | 精确来源 |
|------------|--------------|---------------|---------------|---------|
| 二 | 业绩 | 每份20%，最高4分 | 0-4 | Table N Row M |
...（全部条目）
### 技术评审标准表原文
> 被引用于：附件2-3（技术评审索引表）的"评审项目"列、"计分模型"列、"标准分值"列
| 序号（原文） | 评审项目（原文） | 计分模型（原文） | 标准分值（原文） | 精确来源 |
|------------|--------------|---------------|---------------|---------|
| 六 | 技术力量 | — | 9分 | Table N Row M |
| 六-① | ISO9001/GB/T19001/GJB9001质量管理体系认证（有效期内） | 客观计分 | 1分 | Table N Row M |
...（子项全部列出，不可合并）
⚠️ 重要警告：
标注规则（按优先级顺序）：
招标文件自身的分册/分类已明确归属时，直接按原文标注
招标文件未按商务/技术分册时，根据评分标准中的大类归属判定
不对应任何评分项的文件（资格证明、格式文件、声明函等）→ 标注"商务标"
关键要求：
### 3. 输出合规注意事项表
从采购文件中提取所有涉及合规、形式审查的要求，输出为**5列表格**。
#### 列说明与填写规范
| 列名 | 说明 | 填写规范 |
|------|------|---------|
| **类别** | 合规事项分类 | 固定标签，见下方模板 |
| **要求（概括）** | 用人话概括要求，便于快速阅读 | 简洁明了，不超过50字 |
| **原文摘录** | 从采购文件中逐字引用的原始文字（**防幻觉锚点**） | 必须加引号，逐字照抄原文；如原文未规定该项，写"**原文未规定**" |
| **精确来源** | 定位到具体位置，不可只写章节名 | Word文件写 `Table{N} Row{M}` 或 `段落{N}`；PDF写 `第X页第Y段` |
| **备注** | 补充说明、风险提示 | 可空 |
#### 🚨 原文摘录填写强制规则
**以下类型的数据，"原文摘录"列必须包含对应的字面量，否则视为幻觉风险：**
- 金额数字（保证金金额、预算金额）→ 摘录中必须出现该数字原文
- 时间/日期（截止时间、到账时间）→ 摘录中必须出现该时间原文
- 天数/月数（社保月数、有效期天数、质保期）→ 摘录中必须出现该数字原文
- 份数（正本/副本数量）→ 摘录中必须出现份数原文
**如果无法在原文中找到支持该结论的字面量，禁止在"要求"列写出该结论——改为"原文未规定"。**
```markdown
## 合规注意事项
| 类别 | 要求（概括） | 原文摘录 | 精确来源 | 备注 |
|------|------------|---------|----------|------|
| **封面格式** | 逐字按原文格式制作，军队采购用"报价文件/报价供应商"，政府采购用"投标文件/投标人" | （见本报告"封面格式"节，已逐行逐字提取） | 报价文件内容及格式章节（封面模板） | 字段名错误是低级废标风险，下游skill必须原文照搬 |
| **格式文件** | 所有附件表格按原文列结构复现，不增删列；注意技术响应表"原文照抄=无效报价"禁止条款 | （见本报告"格式文件清单"节） | 报价文件内容及格式章节 | 见分析报告"格式文件清单"节 |
| **目录** | （从原文提取，原文未规定则写"原文未规定"） | （原文摘录） | （来源） | |
| **装订** | （从原文提取） | （原文摘录） | （来源） | |
| **密封** | （从原文提取：是否分别单独密封、封条要求） | （原文摘录） | （来源） | 注意是否要求多个独立密封包 |
| **包装** | （从原文提取） | （原文摘录） | （来源） | 外包装标注项目名称+编号，勿标供应商名 |
| **签署** | （从原文提取：法人/授权代表/逐页签章） | （原文摘录） | （来源） | 注意"逐页小签"要求 |
| **盖章** | （从原文提取：公章/骑缝章位置和范围） | （原文摘录） | （来源） | |
| **电子版** | （从原文提取：载体/格式/是否单独密封） | （原文摘录） | （来源） | |
| **报价格式** | （从原文提取：大写/含税/分项/总价） | （原文摘录） | （来源） | |
| **有效期** | （从原文提取：具体天数） | （原文摘录，必须包含天数字面量） | （来源） | |
| **保证金** | （从原文提取：金额/账户/到账截止时间） | （原文摘录，必须包含金额数字和截止时间字面量） | （来源，精确到 Table N Row M） | 不收取也要明确标注"不收取" |
| **递交时间地点** | （从原文提取：开始时间/截止时间/地点） | （原文摘录，必须包含时间和地址字面量） | （来源，精确到 Table N Row M） | 迟到=拒收 |
| **份数** | （从原文提取：正本N份+副本N份） | （原文摘录，必须包含份数字面量） | （来源，精确到 Table N Row M） | 正副本不一致以谁为准也需摘录 |
| **偏离** | （从原文提取：是否允许/负偏离扣分规则） | （原文摘录） | （来源） | 实质性条款偏离=废标 |
| **联合体** | （从原文提取：接受/不接受） | （原文摘录，必须包含"是"/"否"原文） | （来源，精确到段落N或Table N Row M） | |
| **分包** | （从原文提取：是否允许分包/转包） | （原文摘录） | （来源） | |
| **演示** | （从原文提取，原文未规定则写"原文未规定"） | （原文摘录） | （来源） | |
| **人员社保** | （从原文提取：社保月数/适用人员/代缴是否认可） | （原文摘录，必须包含月数/天数字面量） | （来源，精确到 Table N Row M 或段落N） | 禁止套用经验值（如"6个月"），必须以原文为准 |
| **实质性条款▲** | ▲标注条款序号列表（从评审表逐行提取） | （从评审标准表逐行核实，列出每项▲的序号和内容摘要） | （Table N，逐行核实） | 序号必须与表格第一列数字完全一致，不得推算 |
Table{N} Row{M}（0-indexed行号）；段落文字用 段落{N}；PDF用 第{X}页招标文件内部出现两处描述不一致时，不要一律标注"存疑/建议向代理确认"。必须先判定冲突类型，能自裁决的自裁决，不能裁决的才质询。
正规招标文件通常在"特别提示""须知说明""算术修正"等章节预设了效力顺序或裁决规则。发现不一致时，必须主动回原文查找是否存在适用的裁决条款。常见裁决规则表述包括：
| 规则类型 | 典型原文措辞 | 裁决方向 |
|---|---|---|
| 文件效力顺序 | "通用文件与专用文件不一致的，以专用文件为准" | 专用文件 > 通用文件 |
| 附件与前附表 | "前附表与正文不一致，以前附表为准" | 前附表 > 正文 |
| 正副本/介质 | "正本与副本不符，以正本为准" | 正本 > 副本 |
| 金额修正 | "大写和小写不一致，以大写为准"；"总价与单价汇总不一致，以单价汇总为准" | 大写>小写；单价汇总>总价 |
| 中外文本 | "以中文文本为准" | 中文 > 外文 |
| 财务数据 | "与审计报告不一致以证明材料实际数据为准" | 原始凭证 > 汇总表 |
| 补充/澄清文件 | "澄清文件为谈判文件的组成部分，与原文件不一致以澄清文件为准" | 澄清文件 > 原文件 |
只要找到适用规则，即依规则得出确定结论，并在报告中援引规则出处（格式示例："据特别提示第一条'通用文件与专用文件不一致的，以专用文件为准'→ 以专用文件XX为准"）。此类冲突判定为已解决，不标 ⚠️、不建议质询。
以下情形标注 ⚠️ 并建议向采购代理书面质询：
质询项须完整列出：冲突双方原文、各自精确来源、为何无法自裁决。
在输出分析报告前，必须进行以下验证：
按采购文件要求的附件格式，生成完整的响应文件目录，每个附件标注：
pip install pdfplumber（PDF 表格检测）分析报告.md（固定，不可更改，后续 skill 依赖此文件名）bash cat > 创建 + cat >> 追加，禁止使用 write 工具⚠️ 注意：不要只在聊天输出中展示内容，必须调用工具真正写入文件！
分析完成后，输出以下结构化状态摘要，供 bid-manager 等上游 skill 读取：
--- BID-ANALYSIS COMPLETE ---
项目名称: {项目名称}
采购编号: {采购编号}
预算金额: {预算金额}
评分总分: {总分}
评分大类: {价格X分, 技术X分, 商务X分, ...}
册别数量: {N册}（如：资格证明文件+商务技术文件=2册）
附件数量: {响应文件组成中的附件总数}
商务标归属: {N}个文件
技术标归属: {N}个文件
★必须附件: {★标记的附件数量}
▲功能条目: {▲标注的技术需求条目数}
输出文件: 分析报告.md
状态: SUCCESS
--- END ---