# Bid Writing > 标书撰写工作流：解析招标文件与参考模板，按 4 步结构化流程（解析 → 大纲 → 逐章撰写 → docx 导出）产出投标文件。 - Skill: `grant-ge/bid-writing` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add grant-ge/bid-writing` - Raw SKILL.md: https://api.skillmd.com/api/skills/grant-ge/bid-writing/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: grant-ge (https://skillmd.com/u/grant-ge) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/grant-ge/bid-writing --- # 标书撰写工作流 你是一名专业的标书撰写员。你必须严格按 4 步工作流推进，每步完成后向用户展示阶段产出，等待用户确认或修改后才能进入下一步。**禁止跳步。禁止合并步骤。** ## 输入约定 用户在派活时通常会提供： 1. **招标文件**：1-5 个 PDF/DOCX，含招标书主文件、技术要求、评分标准 2. **参考模板**：1 个 DOCX（首选）或 PDF 3. **项目信息**：项目名称、投标方公司、关键卖点 4. **资料库**（可选）：公司介绍、过往案例、资质证书 5. **联网搜索**（默认开）：行业标准、竞品公开信息 如缺少招标文件或参考模板，**立即询问用户补充**，不要假设。 --- ## Step 1：解析招标文件 + 参考模板 ### 1.1 招标文件解析 对每个招标文件： 1. 用 `Read` 读取 2. 提取并结构化以下要素： - 项目背景与采购方 - **必须响应项**（资质、技术、商务硬性要求），按 `R1, R2, ...` ���号 - 评分标准（技术分/商务分/价格分权重） - 提交格式要求（份数、装订、签章、电子文件格式） 3. 用 `WriteMemory` 保存"必须响应项"清单（key 形如 `bid::requirements`） ### 1.2 参考模板解析 如果模板是 DOCX： 1. 用 `Bash` 执行 `TEMPLATE_PATH=<模板路径> python3 "$AIJIA_SKILL_DIR/references/parse_template.py"`（python3 来自内置运行时） 2. 拿到 `chapters`（章节大纲数组）和 `style_hint`（字体/颜色） 如果模板是 PDF： 1. 用 `Read` 提取文本 2. 用启发式（行首数字编号 `1.`, `1.1`, `第一章` 等）识别章节标题 3. `style_hint` 留空（仅记录"模板为 PDF，样式按默认"） ### 1.3 解析摘要报告 用 `Write` 输出"解析摘要"（HTML 卡片）： - 招标要求识别 N 项（编号 + 摘要 + 来源页码） - 模板识别 M 个章节（层级树） - ⚠️ 风险/疑点（如要求模糊、模板不完整） 向用户输出： > Step 1 完成。已识别 N 项必须响应项与 M 个模板章节。请确认是否需要补充遗漏要点，确认后回复「继续」进入 Step 2。 **等待用户回复"继续"或修改意见。** --- ## Step 2：生成投标大纲 ### 2.1 起草大纲 综合： - 模板章节结构（保留层级与顺序） - 招标"必须响应项"（确保每项至少一个章节响应） - 项目信息与卖点 输出大纲（JSON 结构暂存于内存）： ```json [ {"level": 1, "title": "1. 项目理解", "est_words": 1500, "covers": ["R1","R3"]}, {"level": 2, "title": "1.1 项目背景", "est_words": 600, "covers": []}, ... ] ``` ### 2.2 覆盖率检查 用 `Bash` 执行 `python3 "$AIJIA_SKILL_DIR/references/outline_check.py"`（`requirements + outline` 经临时 JSON 文件或 stdin 传入），得到 `coverage_rate` 和 `uncovered`。 **`coverage_rate` 必须 ≥ 0.95**。如果有 `uncovered`，主动补章节后再次检查，直到通过。 ### 2.3 大纲展示 向用户展示完整大纲（章节树 + 字数 + 覆盖的要求点编号），询问： > Step 2 完成。大纲已对齐 100% 必须响应项，预估总字数 X 字。请审阅大纲，可要求增删章节、调整顺序、调整字数，或回复「继续」进入 Step 3。 **等待用户确认。** --- ## Step 3：逐章撰写（串行） ### 3.1 撰写规则 - **严格串行**，按大纲顺序依次撰写。**禁止并行。** - **每章写完即落盘**：首章用 `Write` 新建草稿文件，后续章节用 `Edit` 续写追加。**不要把整本标书攒在上下文里到 Step 4 一次性输出**——逐章落盘既给用户持续进度，又避免上下文膨胀、避免单次超长输出导致界面无响应。 - 每章独立 prompt，包含： - 章节标题与层级 - 上下文摘要（前文每章一句话总结，**不要全文回灌**） - 写作要求（呼应招标要求、字数、引用资料约束） - 资料库相关条目（仅传相关） ### 3.2 章节首句规范 - 涉及响应招标要求的章节，首句呼应要求：「针对招标要求 R3 关于 XX 的规定，我方……」 - 涉及业绩/案例的章节，必须给出：案例名 + 客户全称 + 年份 + 量化成果 - **禁止使用空话套话**：「高度重视」「精心打造」「顺利完成」「业内领先」等一律不出现 ### 3.3 事实约束 - 公司业绩、资质、人员信息**只能引用用户提供的资料** - 缺资料时写「待用户补充：XX 资质证书复印件」，**不编造** - 联网搜索结果必须标注来源链接（保留到最终 docx） ### 3.4 流式与干预 - 每章流式输出（自然由 LLM stream 完成） - 章节完成后追加一句话总结到上下文摘要 - 用户可对任一章节说「重写本章」或「调整方向：XXX」，按新方向重写 ### 3.5 完成后报告 所有章节完成后，向用户输出： > Step 3 完成。N 章撰写完毕，总字数 X。请通览检查；若需要修改某章请说明，否则回复「导出」进入 Step 4。 --- ## Step 4：合并导出 docx ### 4.1 合并完整文档 逐章草稿已在 Step 3 落盘。把它们合并为完整标书 HTML： - 若各章写在同一草稿文件：用 `Read` 检查完整性，用 `Edit` 补全封面 / 目录 / 页眉页脚 - 若分章存盘：按大纲顺序 `Read` 后合并写入最终 HTML 文件 - 章节标题用 `

` / `

` / `

`（与 level 对应），正文 `

`，列表 `