投标技术应答生成器

投标响应里最耗时的往往不是写正文，而是把招标文件里的评分标准、技术要求、服务要求、废标条款拆清楚，再逐点组织成可交付的技术/服务方案。真正危险的不是写得慢，而是漏掉某个必答项、把不确定的人员或资质写成确定承诺，或者最后交给 Word 的 Markdown 里还带着 ---、**加粗**、代码块和表格分隔符。

它解决什么问题

这个技能面向的是投标文件中的服务/技术方案部分，不是完整商务标或法律标。它能把一份 招标文件.doc 或 招标文件.docx 转成可追踪、可复核、可合并的标书写作流程，核心目标是让每一段应答都能回指到招标文件的具体评分项或要求。

工作方式

流程分四步：

1. 提取招标关键点：先读取招标文件，生成 KeyPointsOfTheTenderDocuments.md，覆盖项目基本信息、采购背景、技术/服务要求、商务相关要求、资格材料、废标/否决条款、评分标准、格式要求和必须逐点应答清单。
2. 规划动态模块：生成 ModulePlan.md，不预设固定章节数。先分析评分方法和响应文件结构，再决定要写哪些模块，并记录每个模块对应的评分项。
3. 逐模块生成：按计划生成 model1.md、model2.md …… modelN.md。每段正文尽量具体到项目执行层面，避免空泛口号。对不确定、缺失、矛盾或依赖投标人实际情况的信息，统一写成 【需人工确认：...】。
4. 合并 Word：调用 scripts/build_bid_response_docx.py，按模块顺序合并成 投标文件技术应答整合稿.docx。脚本会去掉内部追溯章节，清理残留 Markdown，把图片占位、流程图占位、简单表格和 【需人工确认：...】 转换成 Word 可处理形式，并套用宋体/Times New Roman、小四正文、首行缩进、1.5 倍行距和标题编号。

适用边界与注意点

• 它只负责服务/技术方案，不生成报价、合同条款或完整商务法律标包。
• 它不会编造人员姓名、证书编号、业绩案例、设备清单或承诺；资料不足时会显式标记 【需人工确认：...】，最终稿中会显示为红色加粗。
• ReferenceDocuments/ 只作为辅助资料，不能覆盖招标文件；如果没有该目录，继续基于招标文件工作即可。
• 合并前仍需人工检查评分响应覆盖、格式装订要求、签章页和所有 【需人工确认：...】 事项。