Bid Document De-AI Checker

Bid technical proposals often contain AI-generated traces, making the content appear template-driven, vague, and lacking human authenticity. This undermines credibility and can affect scoring in evaluations. This skill detects and eliminates such traces to produce more human-like writing.

Problem Background

In bid documents, the technical proposal sections need precise responses to tender requirements, but common AI traces include:

• Vocabulary layer issues: AI citation markers, bot residuals, Markdown remnants, self-Q&A structures, polite AI tones, which directly expose AI generation.

• Template issues: Repetitive connective word skeletons, similar openings and endings, tag-based breakdowns, leading to template-like content.

• Vague content: Empty cases, perfect solutions, unjustified technology selections, lacking substantive details.

• Fabricated data: Numbers without sources, perfect integers, unproven qualifications, weakening document credibility.

• Inconsistencies: Contradictions, overly uniform structures, no constraints or risk descriptions, appearing unrealistic.

The essence of AI flavor is filler padding, sentence skeletons, and rhetorical shells. Version 8.1 expands this to data and consistency layers, detecting fabricated data and over-perfection features.

Core Detection System

This skill employs a six-layer detection system covering 42 types of AI traces, categorized into three priority levels:

• P0 (Direct AI Exposure): Must be handled immediately. Includes AI citation markers in vocabulary layer, connective skeletons in template layer, literary narration in promotion layer, etc.

• P1 (Vague/Template/Fabrication): Requires context judgment. Such as empty cases in content layer, source-less numbers in data layer.

• P2 (Suggested Optimization): Optional for users. Like filler phrases in vocabulary layer, perfect title hierarchies in consistency layer.

The detection layers are:

1. Vocabulary Layer: Identifies AI-specific words and patterns, e.g., 将 word commitments, self-Q&A.

2. Template Layer: Checks for structural repetition and patterns, like shell removal.

3. Content Layer: Verifies authenticity of cases and technology selections.

4. Promotion Layer: Avoids over-promotion and meta-narration.

5. Data Layer: New in v8.1, detects credibility of numbers and qualifications.

6. Consistency Layer: New in v8.1, checks internal document consistency and lack of human features.

Workflow and Rewrite Method

The skill follows a strict workflow:

1. Detection Phase: First, conduct comprehensive detection and output an annotated or checklist report. Never modify the original text directly.

2. Approval Phase: After user confirms detection results, authorize entry into rewriting.

3. Rewrite Phase: Rewrite based on the detection report, with the core principle of tender response anchoring—ensuring rewritten content directly corresponds to tender requirements, using only existing numbers from the tender for quantifications.

Validation is done through black-box scripts like check_forbidden.py, check_density.py, etc., to ensure quality.

Applicable Scope and Notes

This skill is limited to bid document technical proposal sections, applicable to:

• Main chapters of bid technical proposals, such as system architecture design, functional plans, technology selection, project cases.

• Bid self-checks and post-bid rewrites.

Not applicable to:

• Commercial bids, price scores, implementation plans.

• Company introductions, project teams, after-sales services, quality assurance chapters.

• Contracts, scanned images.

Note: Commercial/qualification/financial sections contain legal format language and are not checked. Users must first confirm the detection scope upon triggering, and if P0 proportion is high, pause and await confirmation.