赢乘招标文件解析

概述

Analyze Tender Documents

Produce a complete, source-traceable interpretation of the supplied tender package. Treat extraction, semantic analysis, strategy, writing, audit, formatting, and external delivery as separate responsibilities.

Non-negotiable rules

1. Keep source files local unless the user explicitly authorizes a named external service in the current turn.
2. Read every generated review batch. Never replace full review with “key chapter only” sampling, even for long files.
3. Bind every factual conclusion to an exact evidence excerpt and source block ID.
4. Preserve original wording, amounts, units, dates, formulas, lot identifiers, and defined terms.
5. Mark absence as not_found, ambiguity as clarification, contradictions as conflict, and deductions as inferred. Never silently complete missing facts.
6. Do not label a clause “废标/否决/无效” merely because it contains “须、应、必须、不得” or an asterisk. Use rejection only when the tender text explicitly states a rejection or invalidity consequence.
7. Separate tender requirements from bidder capability. Do not claim “已具备、缺失、可满足” without bidder evidence.
8. Treat statutes, standards, dates, and external facts as potentially current. Verify against authoritative sources only when the user asks for legal/current-validity review; keep that evidence separate from tender-source evidence.
9. Do not generate a bid document, DOCX, HTML workbench, upload, submit, or deploy as part of parsing unless the user separately requests that action.

Summary output priorities

Apply these rules to every user-facing summary, report, and Word view, regardless of mode:

• Exclude routine platform operations (client use, standard commitment letters, ordinary electronic signatures, and ordinary uploads) and ordinary regional registration materials (for example, out-of-province filing, entry-information screenshots, or entry-registration certificates). Retain them only when the user asks, or they establish a time/format/version limit or a non-standard operation.
• Exclude generic statutory eligibility recitals and absence statements, such as “仅列政府采购法第二十二条一般条件” or “未明确提取到特定资格要求”. Retain only specific, actionable qualification, licence, personnel, performance, or evidence thresholds.
• Exclude price-score formulas, benchmark prices (including lowest-evaluated-price benchmarks), high/low-price handling, price deductions, routine tax-inclusive-total-price and fixed-price/no-adjustment terms, and tied-ranking or purchaser-selection rules. A price item may state its score only.
• Exclude scoring-accounting restrictions such as personnel not being counted repeatedly or one person/role being limited to one score item.
• State substantive requirements, parameters, and evidence only; omit boilerplate enforcement or outcome language such as “负偏离作无效响应处理”, “缺失不得分”, and other statements that merely restate what follows from a failed requirement.
• Summarize technical parameters and performance indicators in short sentences: retain only decisive specifications, quantities, capacity thresholds, compatibility, and delivery requirements; do not reproduce parameter tables line by line.
• For every ★ item, list the specific technical, service, qualification, material, or delivery requirement that makes it special. Do not list the generic “实质性要求” label or the consequence of a negative deviation.
• List each retained scoring item on its own line with its score. Where subitems exist, state the item score, subitem score, and quantity/per-item score only. Exclude missing-item, insufficiency, deduction, and no-score rules; do not compress the retained scores into a generic paragraph.
• For personnel scoring, state each role's source-backed qualification, title/certificate, experience, tenure, social-security or other evidence, score method, and cap. Do not invent fields absent from the source.
• For every project in every output mode, add one 项目难点 of no more than 50 Chinese characters. Select the single most material source-grounded challenge from schedule, coordination, payment, tender eligibility, technical delivery, site conditions, or another project-specific constraint; label it as an inference and do not invent facts.

Workflow

1. Establish the source set

List all supplied files, amendments, clarification notices, annexes, bills of quantities, drawings, templates, and bidder materials. Keep tender-issued sources separate from bidder-supplied capability evidence.

Resolve the target lot only if the user already specified it or the source package makes the scope unambiguous. Otherwise analyze all lots and add a clarification question; do not choose a lot for the user.

2. Extract locally

Run:

python3 "<skill-dir>/scripts/extract_tender.py" 
  --input "<file-or-directory>" 
  --output "<work-dir>/tender_extract" 
  --ocr auto

Repeat --input for multiple paths. The extractor supports PDF, DOCX, DOC, XLSX, TXT, Markdown, CSV, and common image formats. It emits stable block IDs, source hashes, per-page/per-part locators, tables, OCR/quality status, and exhaustive review batches.

Inspect source_manifest.json and extraction_quality.md before analysis. Stop and report a blocked source when it is encrypted, corrupt, unsupported, or still requires OCR. Never treat an empty extraction as an empty tender requirement.

3. Review every batch

Read review_batches/index.json, then read every review_batches/RB-*.md file. Record each completed batch ID in analysis.json.scope.reviewed_batches.

Use the first pass to capture facts and clauses without strategy. Use a second pass across all batches to find:

• duplicate or conflicting dates, amounts, names, and requirements;
• amendments that supersede earlier clauses;
• cross-references whose target text sits elsewhere;
• lot-specific versus package-wide requirements;
• scoring subitems, caps, prerequisites, formulas, and deductions;
• explicit invalid/rejection consequences;
• required templates, signatures, seals, file formats, naming, encryption, upload, and packaging rules.

Read [references/classification-rules.md](references/classification-rules.md) before classifying mandatory/rejection rules, conflicts, lots, scoring, or bidder fit.

4. Build structured analysis

Copy analysis_template.json from the extraction directory to analysis.json and fill it according to [references/analysis-schema.md](references/analysis-schema.md).

Use these evidence objects everywhere:

{"source_ref":"S001-P0007-B0002","quote":"投标截止时间为……"}

Make quote an exact excerpt from that block. Keep interpretations in notes or inference_reason, not inside the quote.

Populate at minimum:

• claims: project, lot, timeline, qualification, submission, format, technical, commercial, contract, deliverable, and other source facts;
• scoring_items: every scoring row/subrow, including formulas and caps;
• risk_items: explicit rejection risks separately from eligibility, scoring, performance, commercial, and clarification risks;
• conflicts and clarifications;
• downstream_handoff: source-backed requirement IDs for later writing or audit.

Do not embed general tender advice, invented responsibilities, arbitrary Day 1–14 schedules, assumed competitors, or proposed solution content in the factual layer.

5. Validate before reporting

Run:

python3 "<skill-dir>/scripts/validate_analysis.py" 
  --analysis "<work-dir>/analysis.json" 
  --extract-dir "<work-dir>/tender_extract" 
  --report "<work-dir>/validation_report.json"

Fix all errors. Review warnings explicitly. delivery_pass=true requires:

• all extraction sources readable and no unresolved OCR/source failure;
• every review batch accounted for and none left unreviewed;
• all evidence references valid and excerpts found in their referenced blocks;
• no unsupported explicit rejection classification;
• all downstream handoff IDs valid and no inferred claim promoted as a must-respond fact.

6. Render the report

Run only after validation:

python3 "<skill-dir>/scripts/render_report.py" 
  --analysis "<work-dir>/analysis.json" 
  --validation "<work-dir>/validation_report.json" 
  --output "<work-dir>/招标文件解析报告.md"

Deliver the analysis JSON, Markdown report, validation report, and extraction-quality report. State limitations prominently when delivery_pass=false; do not describe the package as fully parsed.

Output contract

Use these canonical artifacts:

tender_extract/
├── source_manifest.json
├── blocks.jsonl
├── extracted_text.md
├── extraction_quality.md
├── analysis_template.json
├── tables/
└── review_batches/
    ├── index.json
    └── RB-*.md
analysis.json
validation_report.json
招标文件解析报告.md

Treat analysis.json as the semantic single source of truth. Treat the Markdown report as a rendered view. Downstream bid-writing or compliance skills must consume IDs from the validated JSON instead of re-parsing a prose summary.

Scoped modes

• A模式（分类解析 Word）：当用户要求“A模式”时，交付一份分类汇总 Word。每个项目类别为 H1、每个项目为 H2；项目下依次设置采购编号/方式/预算/最高限价/报名截止/开标或开启时间表格，以及“项目解析、关键响应要点、评分体系、评分要点”。文件未载明报名或开标时间而用户明确要求查询时，逐项以四川政府采购网等指定官方公告的当前轮次为准，并核对更正公告；在表头标注“采购公告”。按用户指定模型生成语义摘要；生成后渲染并检查中文字体、表格、分页及最终 Word。
• For “只看评分表”, still extract and review the entire source package, but render only scoring plus related qualifications, format rules, rejection clauses, and conflicts.
• For “只看废标风险”, output the source-backed substantive requirements associated with explicit rejection clauses, without repeating the boilerplate rejection result; list keyword-only candidates under clarification or another risk type.
• For “值不值得投”, first finish source parsing; then request or load bidder evidence and produce a separate fit assessment. Keep tender facts unchanged.
• For amendments or clarification notices, add them to the same source set and apply the precedence rules in the classification reference.