157 lines
8.2 KiB
Markdown
157 lines
8.2 KiB
Markdown
---
|
||
name: cn-it-bid-writer
|
||
description: 面向中文 IT/系统集成类投标项目的投标文件生成与交付 skill，负责基于当前项目目录内的招标文件和项目资料完成拆标、目录定稿、双产物正文填写与最终交付。当用户需要对招标文件进行操作的时候，可以启用这个skill。
|
||
---
|
||
|
||
# cn-it-bid-writer
|
||
|
||
## 这是什么
|
||
|
||
这是一个由AI驱动， 用中文撰写标书的skill
|
||
|
||
## 目标
|
||
|
||
- `outline`
|
||
产出技术标书和商务(包含其它部分除技术标)标书目录；默认交付顺序是先技术目录，后商务目录
|
||
- `outline+business`
|
||
通过产出的商务把标书目录，生成完整商务(包含除技术标)之外的标书。
|
||
- `outline+technical`
|
||
通过产出的技术把标书目录，生成完整技术标书。
|
||
|
||
## 成品导向原则
|
||
|
||
门禁、脚本检查和渲染校验都只是基础门槛，不是完成定义。
|
||
本 skill 的最终目标是生成可直接用于投标的中文标书；无论目录、标题、正文、图表、附件还是最终 Word 排版，都必须服务“可直接交付给评委或采购人阅读”的成品标准。
|
||
|
||
默认文档格式基线如下，若招标文件或正式模板另有明确要求，则以后者优先：
|
||
|
||
1. 标题编号默认使用 `1 / 1.1 / 1.1.1 / 1.1.1.1`。
|
||
2. 一级标题默认黑体、小三；二级标题黑体、四号；三级标题黑体、小四；四级标题默认楷体或黑体小四，并在同一项目内保持统一。
|
||
3. 正文默认宋体、小四，首行缩进 2 字符，1.5 倍行距。
|
||
4. 表格默认宋体，五号或小五，表头加粗。
|
||
5. 图、表、附件标题统一编号，默认采用 `图3-1 XXX / 表4-2 XXX / 附件5-1 XXX`。
|
||
6. 占位内容必须显式标明“占位/待替换/待补充”，不得伪装成正式材料。
|
||
|
||
## 执行规则，严格遵守
|
||
|
||
1. 必须按照规定workflow执行。
|
||
2. 所有输出只能写到和用户提供的目录下的 `work/`、`reports/`、`final/`。所有创建的文件也只能在用户提供的这个目录下。
|
||
3. 不能补充任何脚本，只能用项目现有脚本，所有脚本在scripts目录下。
|
||
4. 脚本执行需要使用本 skill 内 `.venv/`作为虚拟环境来执行，脚本启动命令是虚拟环境的python，不是python3。记住是本skill当前文件夹下`.venv/`目录，不是你现在的工作目录，是本skill的目录。
|
||
5. 所有操作word脚本使用本skill提供的工具脚本
|
||
|
||
## 现有工具
|
||
|
||
以下脚本属于本 skill 当前可用工具：
|
||
|
||
- `scripts/docx_index.py`
|
||
用途：读取并索引现有 Word 标书或模板结构，提取标题、段落、列表、表格等节点信息，供 AI 先理解文档结构再决定写入位置。
|
||
|
||
- `scripts/docx_query.py`
|
||
用途：按标题、正文文本、锚点等方式查询 Word 中的目标位置，供 AI 在写标书前精确定位章节、段落或表格。
|
||
|
||
- `scripts/docx_create.py`
|
||
用途：根据结构化输入直接创建新的 Word 文档，适合生成目录版 DOCX、占位稿或空白章节骨架。
|
||
|
||
- `scripts/outline_check.py`
|
||
用途：对目录阶段的结构化结果做门禁检查，重点检查目录深度、抽象标题下钻、对象化节点、重复切面和商务中的技术占位。
|
||
|
||
- `scripts/outline_export.py`
|
||
用途：在目录门禁通过后导出结构化 JSON，并生成最终目录版 DOCX。
|
||
|
||
- `scripts/docx_patch.py`
|
||
用途：对现有 Word 标书执行插入、替换、删除等修改操作，把已经生成好的标书内容准确写入指定位置。
|
||
|
||
- `scripts/render_docx.py`
|
||
用途：对写入后的 Word 标书做渲染校验，尝试导出 PDF 和页面图，检查文档是否损坏或排版异常。
|
||
|
||
- `scripts/docx_cli.py`
|
||
用途：统一调用 DOCX 索引、查询、写入和渲染能力。
|
||
|
||
具体操作方式、参数说明和示例见 `references/docx-ops.md`。
|
||
|
||
|
||
## References
|
||
|
||
- 理解招标：`references/understandbid.md`
|
||
- 目录阶段：`references/outline-stage.md`
|
||
- DOCX 脚本接口：`references/docx-ops.md`
|
||
- DOCX 渲染与交付：`references/docx-assembly.md`
|
||
|
||
## 非 outline 阶段规则
|
||
|
||
### business
|
||
|
||
1. 只写商务及其他文件中的 `workflow_bucket=business`，并配合 `workflow_bucket=other` 文件中的技术占位。
|
||
2. 商务事实只认招标文件明示内容和用户真实材料。
|
||
3. 缺件时只允许占位、缺件说明、附件索引空位或阻塞说明。
|
||
4. 不得在商务及其他中补写任何技术正文。
|
||
5. 只能写 `final_outline_business_other.json` 中的叶子节点；若节点仍过于抽象，必须回退目录阶段。
|
||
|
||
商务材料必须进一步分桶组织，至少按以下业务桶判断归属、缺件和证据：
|
||
|
||
1. `资格与准入`
|
||
- 营业执照、资质证书、许可证、注册登记、法定代表人身份证明、授权委托等。
|
||
2. `合规声明与承诺`
|
||
- 无重大违法声明、联合体声明、原厂承诺、保密承诺、售后承诺、真实性声明等。
|
||
3. `商务响应`
|
||
- 商务条款响应、工期/服务期、交付地点、付款条件、质保期、偏离表、响应表等。
|
||
4. `业绩与团队`
|
||
- 类似业绩、项目负责人、实施团队、履历、证书、服务能力证明等。
|
||
5. `财务与纳税社保`
|
||
- 财务报表、审计报告、纳税证明、社保证明、开户信息等。
|
||
6. `附件与索引`
|
||
- 招标文件要求附后的证明材料、附件目录、盖章页、扫描件索引、技术转引占位等。
|
||
|
||
处理要求：
|
||
|
||
1. 每个商务节点都应先判断属于哪个业务桶，再决定承载内容和缺件策略。
|
||
2. `资格与准入`、`合规声明与承诺` 中的硬门槛缺失，应优先标记为高风险或阻塞。
|
||
3. `业绩与团队`、`财务与纳税社保` 不得用通用表述冒充真实材料。
|
||
4. `附件与索引` 只负责承载证据入口和材料定位，不替代正文判断。
|
||
|
||
### technical
|
||
|
||
1. 只写 `work/final_bid_content_technical.json` 中的 `workflow_bucket=technical`。
|
||
2. 技术正文开始前，必须先明确总目标、建设主线、分系统主次和评委检索路径。
|
||
3. 技术材料不足时，可以补专业技术方案，但不能伪造既有事实，必须保证技术框架和方案前后一致。
|
||
4. 技术正文必须展开到架构、模块、实施、培训、验收、运维、风险控制等承载位。
|
||
5. 图表必须服务具体评审主题，不能为了看起来专业而堆砌。
|
||
6. 技术方案必须按章节填充，不允许一次性生成全部技术方案内容。最高允许一次性填充三级子标题。
|
||
7. 只能对 `final_outline_technical.json` 中的叶子节点写正文，不允许直接用父节点概述代替其全部子节点。
|
||
8. 若叶子节点仍然是抽象标题，必须先回退目录阶段继续下钻，不得硬写正文。
|
||
|
||
### other/finalize
|
||
3. 不额外创造默认“报价子 workflow”。
|
||
4. 通过总体验收前，不得对外宣称“完整投标文件”。
|
||
|
||
### final
|
||
|
||
生成：
|
||
|
||
- `final/技术标.docx`
|
||
- `final/商务及其他.docx`
|
||
|
||
## 最终验收
|
||
|
||
导出前必须同时检查：
|
||
|
||
1. `废标/否决项` 是否已有明确承载位、证据位或阻塞说明。
|
||
2. `合规项` 是否完整进入正式目录和交付物。
|
||
3. `评分项` 是否已得到优先展开，且目录深度与正文强度匹配评分重点。
|
||
4. 技术标目录是否合法。
|
||
5. 商务及其他目录是否合法，且技术占位位置正确。
|
||
6. 技术正文深度是否匹配项目复杂度。
|
||
7. 图表是否真的承载评审主题。
|
||
8. 证据链是否完整。
|
||
|
||
除上述业务验收外，还必须满足文档成品验收：
|
||
|
||
1. 标题命名自然、专业、适合直接作为投标 Word 目录使用，不允许出现只为通过门禁而生的生硬标题。
|
||
2. 标题编号连续，标题层级、字体、字号、段落格式符合默认标书格式或模板格式。
|
||
3. 图表编号、附件编号连续且可追溯。
|
||
4. 目录、正文、图表、附件、占位提示在文档中的位置关系正确，不错位、不跳号、不混册。
|
||
5. 最终 DOCX 渲染校验、格式校验、编号校验、占位扫描应共同通过后，才可视为“可交付”。
|
||
|
||
任一项不过，不得汇报“已完成”，但可以生成完整的占位草稿。占位内容仅限于资质、商务、声明、索引、技术转引等非技术实质内容；技术部分必须完整呈现于技术标，不得用占位代替。
|