bid-tender-writer

# 投标技术标编制工作流（BidPilot 适配版） 本 skill 将工程级标书编制方法论提炼为可执行的五阶段工作流，全部使用 BidPilot 平台的既有工具完成。**默认自主推进**：用户给出目标后，你应当独立完成项目选择、资料核对、章节起草和合规自查，不把每个阶段都抛回给用户确认。仅在真正无法判断（多个同样合适的候选、目标模糊、缺少关键信息且无法从工具结果推断）时才提问。 ## 〇、自主选项目 用户明确要求编制交付内容但未指定项目时： 1. 先 `search_projects` 列出项目。 2. 只能依据当前会话中用户明确指出的项目、当前活动项目或工具返回的唯一候选继续，不能根据项目名称中的词语猜测目标。 3. 只有一个可验证候选时，用返回的短 id 继续。 4. 存在多个候选且上下文不能唯一确定时，请用户用短 id 确认。 5. 任何情况下不编造 ID，一律使用工具返回的 id/short_id。 ## 一、设计原则（必须严格遵守） 1. **单一事实来源**：阶段 1 获得的招标要求是唯一依据。**严禁**凭模型记忆补充招标文件中没有的信息（预算、工期、资质、技术规格）。信息缺失时，能通过检索补齐就补齐；无法补齐则明确标注"待补充"，而不是脑补。 2. **分阶段验证**：每个阶段基于工具返回的真实数据推进，禁止把多个阶段合并成一次性输出；但阶段之间**自主衔接**，不在阶段边界停下来等待确认。 3. **按分点应答**：正文阶段必须严格对照评分项逐一应答，确保没有评分点被漏掉。写完每章要核对覆盖了哪些评分项。 4. **本地化优先**：涉及项目所在地的地理、产业、政务信息化基础等描述时，必须基于真实资料撰写。严禁使用"该地区资源丰富、产业兴旺"之类的通用空话。资料不足时明确标注"待补充"，而不是编造。 ## 二、五阶段工作流 ### 阶段 1：招标要求解析 **目标**：把招标文件的关键信息结构化提取，建立投标依据。 **操作**： 1. 用户上传招标文件或指出项目后，用 `list_requirements(project_id)` 获取全部招标要求。 2. 用 `get_readiness_summary(project_id)` 获取项目就绪度概览（覆盖哪些要求、缺哪些）。 3. 用 `list_evidence(project_id)` 查看已入库的证据材料。 4. 用 `semantic_search(project_id)` 检索项目中与招标要求相关的资料。 **关键提取项**（逐项核对，缺失必须标注）： - 项目名称、采购人、预算（如有） - 评分办法与分值分布 - 废标条款 / 实质性响应条款（典型措辞包括：否决、无效、拒收、不予采纳） - 资格要求、★▲关键条款 - 技术规格要求 **产物**：在回复中列出结构化要求摘要 + 就绪度缺口。**据此自主推进到阶段 2。** ### 阶段 2：就绪度评估（对标评分矩阵） **目标**：把评分点拆成可追踪的矩阵，每一分都有归属和证据。 **操作**： 1. 用 `get_readiness_summary(project_id)` 查看就绪度评分与缺口。 2. 用 `list_readiness_gaps(project_id)` 列出每个未满足要求的具体缺口。 3. 对每个评分点明确：分值、评分标准、所需证据、当前状态（已覆盖/缺证据/未应答）。 **自检清单**： - 每个评分点是否都有对应的证据或明确缺位？ - 缺失项是否已列为 gap，等待用户补充资料或授权检索？ **产物**：就绪度评估表（评分点 × 分值 × 证据 × 状态）。**据此自主推进到阶段 3。** ### 阶段 3：大纲生成 **目标**：基于评分点反推章节骨架，确保每章覆盖对应评分项。 **操作**： 1. 用 `get_project_outline(project_id)` 获取项目大纲（若已有模板章节）。 2. 用 `list_sections(project_id)` 获取章节列表，确认 section_key。 3. 若大纲缺失或未覆盖评分点，基于评分项自主补充章节结构；若无法判断，再简要说明。 **关键约束**： - 每条评分项对应的章节标题必须准确体现该评分项名称。 - section_key 必须原样使用工具返回的值，禁止编造。 **产物**：章节骨架（评分项 → 章节映射）。**据此自主推进到阶段 4。** ### 阶段 4：分章节撰写 **目标**：对照评分点逐章撰写，每章有明确归属。 **操作**： 1. 无资料时用 `write_section(project_id, section_key, ...)` 直接写入。 2. 有资料时用 `start_draft_section(project_id, section_key)` 启动起草（可指定 provider_config_id、reasoning_effort）。 3. 撰写前用 `semantic_search` 检索相关证据，确保内容有依据。 **撰写规范**： - 每章开头声明本章覆盖的评分项。 - 关键数字、承诺必须来自工具返回的招标要求或证据，禁止编造。 - 涉及本地化信息时基于真实资料，不足则标注"待补充"。 **自检**：每章写完后核对是否覆盖了分配的全部评分项，证据是否充分。 ### 阶段 5：合规终审 **目标**：终审全部章节，产出合规报告。 **操作**： 1. 用 `list_claim_review_queue(project_id)` 查看待审主张（AI 生成的、需人工确认的陈述）。 2. 用 `list_readiness_gaps(project_id)` 复查是否仍有未覆盖要求。 3. 逐条核对：评分项覆盖率、★▲关键条款响应、实质性响应、废标条款规避。 4. 用 `submit_review_decision` 处理审校队列中的主张（通过或驳回）。 **终审校验项**： - 每个评分点是否都有对应章节应答？ - 是否有承诺与招标要求不符？ - 是否有模板残留或未完成的占位内容？ - 是否有废标风险（未实质性响应、缺资格材料等）？ **产物**：合规终审报告（覆盖情况 + 风险清单 + 待人工确认项）。**全部通过后交付。** ## 三、适用边界 - 只有用户明确要求产生或审校正式投标响应内容时才读取并执行本 Skill。 - 上传文件、提到招标、询问市场机会或检查资料并不等于请求编制标书。 - 机会搜索与公告核验使用 `opportunity-deep-research`；外部资料发现与入库使用 `bid-research`；普通项目读取直接使用相应只读工具，不加载本 Skill。 - 阶段之间自主衔接，不设人工确认关卡；仅高风险操作（删除/审批/提交决策）由服务端审批拦截。