longsky21/dsh-bidding

招标工作台 · Bidding Assistant

一个行业无关的投标文件制作工作台：把「读招标文件 → 对齐评分标准 → 逐章生成 → 废标自查 → 导出可编辑 Word」
串成一条可复核的流水线，让 AI 写标书这件事可审计、可回滚、不瞎编。

不绑定任何行业：知识库与术语规范由使用者自建——银行、制造、医疗、政企、工程、软件服务……只要能整理出
招标要求与自家素材，就能用同一套流程。（仓库自带的示例项目是"某银行金融科技系统建设"，仅作演示。）

License: MIT
Python
Node
Host: DeepSeek Harness
PRs Welcome

Bidding Assistant 是一个行业无关的工作台，用于借助 LLM 智能体制作招标/投标文件。
它解析招标邀请书，将评分标准映射到章节，在人工参与下逐章起草，运行确定性的提交前检查，并导出可编辑的 Word 文档——同时保持
仅限人工填写的字段（价格、人员）留空，并拒绝编造事实。

逐章生成

目录

- 它解决什么问题
- 截图
- 核心能力
- 工作流
- 快速开始
- 试一试：内置演示项目
- 适配你自己的行业
- Skills 与提示词资产（可脱离 DSH 使用）
- 目录结构
- 工具清单
- 它是怎么做到「不瞎编」的
- 质量红线与合规声明
- 路线图
- 排障记录
- 贡献
- 许可

它解决什么问题

做过投标的人大概都经历过这些：

| 痛点 | 现状 | 本项目的做法 |
|---|---|---|
| 招标文件太厚 | 200+ 页，评分表、技术规范、废标条款散在各处 | 结构化解析（表格 + 正文全文），抽出评分项、需求矩阵、废标条款、递交截止时间 |
| 写了不看评分 | 几十万字，评分项对不上，白写 | 评分项 → 章节映射 + 评分覆盖表，缺哪一项一屏可见 |
| 重复劳动 | 每份标书 80% 内容与上一份相似 | 历史标书按章节索引，双通道复用（叙述走 Markdown 改写；复杂表格/截图走 OOXML 原样搬运） |
| 一致性事故 | 复制来的段落里残留别家客户名 | 机构名一致性校验 + 替换规则（他方客户名一律改「某机构」，绝不改成当前采购人） |
| 废标级疏漏 | 资格材料缺失、响应表没逐条应答、报价超预算 | 22 项程序化检查，区分「不通过 / 待人工 / 未实现」，导出前设一道门禁 |
| 格式地狱 | Markdown 表格、流程图、代码块进 Word 就散了 | 导出器保留合并单元格语义；ASCII 图自动重排成 Word 表格；图片自动嵌入并生成图注 |

它不做什么（诚实声明）：不是「一键生成中标标书」。报价、拟投入人员、资质原件、签署日期这些
只能人工确认的内容，它一律留 【待填】 并在章末列出待补清单——填不完就不允许导出正式稿。

截图

| 逐章生成（章节清单 + 生成任务 + 未采用草稿） | 投标检查（22 项，区分不通过 / 待人工） |
|---|---|
| 逐章生成 | 投标检查 |

| 文档输出（章节勾选、文件名分段、导出门禁） |
|---|
| 文档输出 |

截图为内置演示项目（合成数据，项目名"某银行金融科技系统建设"），不含任何真实客户信息。

核心能力

- 招标文件结构化解析：.docx / .doc / .rtf → JSON（表格全保留 + 正文全文 + 缺件信号）
- 评分覆盖与缺口分析：评分项 / 招标要求 ×（参考标书 + 知识库）确定性对比，产出缺口清单
- 逐章生成（人在环）：子 agent 只允许写 output/章节/.draft/，人工点「采用」才替换正式章（旧章自动备份）
- 双通道图文复用：叙述内容走 Markdown 改写；含复杂表格/截图的整节走 OOXML 片段原样插入（图片关系重映射）
- 表单类章节填充：投标函、开标一览表、偏离表、人员表、保证金、资格证明……能填的填实
（主体信息、证书编号、保证金金额与账户、正副本份数），报价与人签项一律留空
- 交付前清理：剥离内部注记与本地路径、图片按需压缩、ASCII 图重排、文件名规范化
- 检查与门禁：22 项检查（响应表逐条、限价、机构名、占位符、图示、格式…），导出前给出可执行清单
- 技术标 / 商务标可分可合：生成时可按册批量跑（只跑技术标或只跑商务标），导出时可选择整本合成一个文件、只导其中一册，或分册各出一个 docx（技术标/商务标分开装订的场合）
- 可回滚：所有替换都留 .bak-；批量生成脚本脱离服务进程运行，跨重启存活

工作流

flowchart LR
A[招标文件.doc/.docx/.rtf] --> B[结构化解析表格+正文全文]
B --> C{采购方式}
C -->|公开招标| D[评分项 → 目录映射评分覆盖表]
C -->|单一来源| E[技术深度 +唯一性论证]
D --> F[逐章生成草稿 → 人工采用]
E --> F
G[历史标书章节索引] --> F
H[自建知识库 kb/资质·业绩·财务·人员·方案] --> F
I[本地知识库检索] --> F
F --> J[22 项投标检查+ 一致性校验]
J --> K{导出门禁}
K -->|通过| L[可编辑 Word封面·目录·图表]
K -->|未过| F
L --> M[人工补齐报价人员·签署·盖章]
M --> N[递交]

快速开始

环境要求

| 依赖 | 版本 | 用途 |
|---|---|---|
| Python | 3.9+ | 解析 / 校验 / 导出脚本（python-docx；可选 Pillow 做图片压缩） |
| Node.js | 20+ | 工作台插件（client 半区）+ 逐章生成驱动 |
| DeepSeek Harness (DSH) | 0.1.0-rc+ | 工作台宿主与子 agent 运行时（内部部署；没有 DSH 也能用「方式 B」纯脚本） |
| 本地知识库（可选） | — | 复用历史标书表述；任何支持问答式检索的本地库均可 |

git clone https://github.com/longsky21/dsh-bidding.git
cd dsh-bidding
pip install python-docx pillow

方式 A：装成 DSH 工作台（推荐）

1) 把插件装到 DSH profile（DSH 只从 profile 目录加载 client 插件）
bash tools/sync-plugin.sh push

2) 在 ~/.dsh/profiles/web/cordis.patch.yml 末尾追加（插件注册）
cat >> ~/.dsh/profiles/web/cordis.patch.yml  bash tools/sync-plugin.sh check|push|pull 三个方向分别是：比对、仓库→profile（部署）、profile→仓库（收拢改动）。
改 host 半区（index.js/checks.js/export-plan.js 等）需重启 DSH Web；只改 client 半区刷新浏览器即可。

方式 B：只用命令行脚本

不需要 DSH 也能用（解析、校验、导出、缺口分析都是纯 Python）：
bash
招标文件 → 结构化 JSON
python3 scripts/parse_tender.py input/招标文件.docx output/项目-结构化.json

招标要求 × 参考标书/知识库 → 响应缺口
python3 scripts/coverage_gap.py projects/我的项目

机构名一致性校验（历史标书的他方客户名残留会让标书"串门"）
python3 scripts/check_consistency.py projects/我的项目/output/章节/*.md \
--meta projects/我的项目/output/项目-结构化.json

功能/技术响应表逐条核对（漏项/多项/空结论）
python3 scripts/check_response_table.py \
--meta output/项目-结构化.json --chapter output/章节/03-系统功能模块及逐项响应.md

合并导出可编辑 Word（封面 + 目录 + 分部分 + 图表）
python3 scripts/export_bid.py --manifest manifest.json --out output/投标文件.docx \
--project-root projects/我的项目

技术标 / 商务标分开，或合成一本

招标实务里两册经常分开装订、分开密封，有时只投其中一册。本项目两个环节都支持：

① 生成：章节页签有两个批量入口，互不影响（串行队列，一章完成再起下一章）

| 入口 | 覆盖章节 | 典型内容 |
|---|---|---|
| ⚡ 批量生成技术标 | 01~12 | 项目理解、平台架构、功能逐项响应、项目管理、实施计划、验收、售后、培训 |
| ⚡ 批量生成商务标 | 13~25 | 投标函、开标一览表、报价明细、偏离表、人员表、资格证明、保证金 |

命令行同理（tools/gen-chapters.mjs）：
bash
node tools/gen-chapters.mjs --root projects/我的项目 --from 01 --to 12   # 只跑技术标
node tools/gen-chapters.mjs --root projects/我的项目 --nos 13,14,15      # 只跑指定商务标章节

② 导出：文档输出页签的「导出范围」四选一

| 范围 | 结果 |
|---|---|
| 整本 | 技术标 + 商务标合成一个 docx（默认） |
| 只导技术标册 | 仅技术标章节，一个文件 |
| 只导商务标册 | 仅商务标章节，一个文件 |
| 分册导出 | 技术标、商务标各一个 docx（文件名自动带 -技术标 / -商务标） |
按册归类由结构表决定：技术标册 = technical + service 部分；商务标册 = bid_letter + qualification + commercial 部分。
某一册还没有章节时，导出会明确提示（而不是把整本塞给你），分册导出则跳过空册并说明。

试一试：内置演示项目

examples/demo-project/ 是一份合成数据的完整项目（6 章 + 评分覆盖 + 缺口报告 + 示例导出件），
复制到工作区即可看到与截图一致的界面：
bash
cp -r examples/demo-project projects/演示项目-某银行金融科技系统建设

适配你自己的行业

这个工具本身不含任何行业内容——行业知识全部来自你自建的资料。三处入口：

1. 结构化知识库 kb/（Obsidian 风格目录，规范见 docs/kb-spec.md）：按模块放资质、业绩、财务、人员、方案、模板；
条目的 frontmatter 会被程序读取，用于组装商务标与检索。
2. 历史标书：放进项目的 input/参考/，extract_reference.py 会切分章节、抽出他方客户名与图片，
供逐章复用；复用规则（谁该被替换、谁不能替换）写在提示词里。
3. 提示词与术语口径：prompts/ 下是解析规范与系统提示词模板；把你所在行业的固定术语表
（同一概念只允许一种写法）填进去，一致性检查就会按它执行。

示例只演示结构与流程；换成你的行业资料后，工作台的章节结构、评分覆盖、检查项都随之变化。

公司级配置

代码里不含任何公司信息——公司名、简称、子公司、历史标书里的他方客户名、检索用知识库 ID、
行业术语表，全部放在工作区根的 config/company.json（默认被 .gitignore 忽略，不进仓库）：
bash
cp config/company.example.json config/company.json   # 然后按你的公司填写

| 键 | 用途 | 可选环境变量覆盖 |
|---|---|---|
| 公司全称 / 公司简称 | 封面「投标人」自动填写；一致性校验时视为自有主体（不算他方名残留） | DSH_BID_BIDDER |
| 关联单位 | 投标函/资格声明里要据实填报的子公司、关联企业 | — |
| 已知他方名 | 历史标书里出现过的别家客户名 → 复用这些表述时判为"必须替换"的高置信残留 | — |
| 自有知识库ID | 逐章生成时检索用的知识库 | DSH_BID_KB_ID |
| 术语表 | 每章提示词里的"术语统一"红线（同一概念只允许一种写法） | — |

没有配置文件也能跑：封面投标人会退回读 kb/ 里的公司条目，术语红线退化为通用表述。

Skills 与提示词资产（可脱离 DSH 使用）

这个仓库里"怎么写标书"的知识是独立的 Markdown 资产，不依赖 DeepSeek Harness，也不绑定任何 agent 框架——
换成 Claude Code / Cursor / Cline / 自建 agent，或干脆全人工，都能直接用：

| 资产 | 位置 | 作用 |
|---|---|---|
| tender-workflow（投标文件制作全流程） | skills/tender-workflow/SKILL.md | 七步工作流 + 命令速查 + 解析契约 + 质量红线 + 技术标/商务标分册与合并导出约定 |
| 章节生成指令模板 | prompts/章节生成指令-模板.md | 给"一章"用的完整提示词模板（六块结构：定位 / 依据 / 评分点 / 响应清单 / 红线 / 执行约束） |
| Agent 系统提示词 | prompts/system-prompt.md | 投标助手的人设与职责（公司信息、知识库 ID 均为占位符） |
| 招标文件解析规范 | prompts/招标文件解析规范.md | 结构化抽取契约（字段清单 + 抽取规则 + 输出模板） |
| 资产说明与三种用法 | skills/README.md | 有 agent 框架 / 只有通用对话框 / 全人工，三种场景怎么落地 |

三种用法

1. 有 agent 框架：把 skills/tender-workflow/SKILL.md 放进框架的 skills 目录（或 Rules / system prompt 指向它），
逐章写稿时把 prompts/章节生成指令-模板.md 里的 {{...}} 换成项目实际值贴进去；
2. 只有通用大模型对话框：把 SKILL.md 与章节模板作为上下文贴入，按七步推进；解析、校验、导出仍在本地跑脚本（无需联网）；
3. 全人工：用 SKILL.md 第 1 节的七步当检查表、第 5 节的质量红线做交付前自查，解析与校验用 scripts/ 下的脚本。

工作流里"够不够响应评分点""这句是不是别家客户"这类判断留给人确认，所以它们写成给 agent 看的说明而非硬编码逻辑——
这也是本仓库只提供「确定性脚本 + 提示词资产 + 可选工作台」三层结构的原因。

目录结构
text
dsh-bidding/
├── scripts/                 # 工具链（纯 Python，可单独使用）
├── tools/
│   ├── dsh-bidding-workbench/   # DSH 工作台插件（host + client 半区，可版本控制的副本）
│   ├── sync-plugin.sh           # 插件同步（check / push / pull）
│   ├── restart-dsh-web.sh       # 重启 DSH Web 并校验插件版本
│   └── gen-chapters.mjs         # 逐章生成驱动（脱离服务进程，跨重启存活）
├── config/company.example.json  # 公司级配置示例（本地复制为 company.json，不入库）
├── skills/                  # 可移植 skill（tender-workflow）+ 资产说明
├── prompts/                 # 解析规范、系统提示词、章节指令模板
├── templates/               # docx 输出骨架、结构表、评分表示例
├── examples/demo-project/   # 匿名演示项目（试用 / 截图用）
├── docs/kb-spec.md          # 结构化知识库规范（行业无关模板）
├── docs/troubleshooting.md  # 排障记录（部署/重启/导出/门禁/网络，均为真实踩坑）
├── docs/images/             # 界面截图
├── kb/                      # 结构化知识库（含隐私，默认 .gitignore）
├── projects//        # 单个投标项目的输入与产物（含客户资料，默认 .gitignore）
└── raw/                     # 通用资料 drop zone（默认 .gitignore）

隐私设计：projects/（招标文件与产物）、kb/（证件号、扫描件）、raw/ 全部在 .gitignore 中
——本仓库开源的是工具，不是你的标书。

工具清单

| 脚本 | 作用 |
|---|---|
| parse_tender.py | 招标文件 → 结构化 JSON（表格 + 正文全文） |
| parse_tender_set.py | 多份招标材料合并解析（主文件 + 技术规范书等） |
| analyze_tender_note.py | 文字版招标说明 → 结构化 JSON + 解析清单 |
| coverage_gap.py | 招标要求 × 参考标书/知识库的确定性覆盖比对 → 缺口清单 |
| check_consistency.py | 机构名一致性校验（退出码 1 = 有残留） |
| check_response_table.py | 响应表逐条核对（漏项/多项/空结论/非「响应」结论） |
| export_bid.py | 多章节合并导出整本投标文件 .docx（封面/目录/分部分） |
| md_to_docx.py | 单文件 Markdown → docx |
| flow_blocks.py | ASCII 架构图 → Word 表格；箭头流程 → 方框 + 箭头 |
| internal_notes.py | 交付稿剥离内部注记与本地路径 |
| image_prep.py | 大扫描件按需降采样/重编码（成品体积可控） |
| list_placeholders.py | 【待填】 汇总成"按责任方分工"的清单 |
| extract_reference.py | 历史标书 → 章节切分 + 他方客户名清单 |
| reuse_fragments.py | OOXML 片段复用（高保真搬运参考标书整节） |
| score_map.py | 评分项 → 章节映射与评分覆盖表 |
| build_outline.py | 章节文件 → output/大纲.json |
| import_contracts.py | 合同台账 Excel → 业绩索引（筛案例用） |
| find_cases.py | 按条件筛历史案例 |
| docx_to_knowledge.py | 公司材料 docx → 文字 + 图片中间产物（供知识库沉淀） |
| make_demo_project.py | 生成匿名演示项目 |
| company_config.py | 读公司配置（config/company.json；与插件侧 company-config.js 同源） |
| tools/gen-chapters.mjs | 逐章生成驱动（串行、跨重启、自动跑一致性校验） |
| tools/sync-plugin.sh | 工作台插件同步（check/push/pull） |

它是怎么做到「不瞎编」的

AI 写标书最大的风险不是写不好，而是写得像真的。本项目的对策是工程约束，不是提示词祈祷：

1. 草稿制：生成只写 output/章节/.draft/NN-名.md，正式章必须人工点「采用」才替换（旧章自动备份）。
2. 事实白名单：资质/业绩/财务/人员只能来自你的知识库与合同台账；台账之外的信息必须先补录才能用。
3. 未知即标注：拿不到的写 【待填】 并在章末列待补清单，而不是编一个看起来合理的数字。
4. 报价零参与：所有金额单元格由人工填写，导出器与提示词双重禁止模型定价；只引用招标文件公布的预算/保证金做红线检查。
5. 替换规则防串门：历史标书里别家客户名一律改写为「某机构」或删除，禁止替换成当前采购人
（那会把别人家的业绩写成本项目的既成事实）。
6. 交付前清理：内部注记（"本章对应评分表…"）、本地路径（kb/…、output/…）在导出时剥离并报告。
7. 一切可回滚：每次覆盖都有备份；批量生成把状态写进 .draft/_batch-status.json。

质量红线与合规声明

- 不编造资质、业绩、合同额、人员、数字与法规条文；知识库里没有的明说需要补充。
- 术语口径统一：同一概念全篇只用一种写法（术语表由你在提示词中定义）。
- 数据不出内网：解析、校验、生成、检索均可完全本地运行；联网检索仅用于公开法规等通用信息。
- 最终决策在人：报价、人员配置、资质原件、签署盖章由人确认，工具不替代投标决策与法律责任。
- 使用者应自行确保对招标文件、历史标书等材料拥有合法使用权。

路线图

- [x] 招标文件结构化解析 + 评分覆盖 + 缺口分析
- [x] 工作台插件（项目状态 / 逐章生成 / 投标检查 / 文档输出）
- [x] 双通道图文复用（Markdown 叙述 + OOXML 高保真片段）
- [x] 22 项投标检查 + 导出门禁 + 占位符分工清单
- [x] ASCII 图示重排、内部注记清理、图片交付压缩
- [ ] 图片/表格全局编号与交叉引用（图 3-1、表 3-2）
- [ ] 锁定交付稿 + 受控回灌（人工在 docx 里改过的内容安全回流到 md）
- [ ] 行业模板示例（工程、政企、软件服务）
- [ ] 英文文档

版本

当前 v1.0.0（首个公开版本）。变更记录见 CHANGELOG.md。

贡献

欢迎 Issue 与 PR。请遵守两条底线：不提交任何真实客户材料（projects/、kb/、raw/ 已在 .gitignore 中），
不为“看起来更聪明”而放宽不编造约束。

许可

MIT © 2026 longsky21