7.8 KiB
| name | description |
|---|---|
| cn-it-bid-writer | 面向中文 IT/系统集成类投标项目的投标文件生成与交付 skill，负责基于当前项目目录内的招标文件和项目资料完成拆标、目录定稿、双产物正文填写与最终交付。当用户需要对招标文件进行操作的时候，可以启用这个skill。 |
cn-it-bid-writer
这是什么
这是一个由AI驱动， 用中文撰写标书的skill
目标
outline产出技术标书和商务(包含其它部分除技术标)标书目录，可以同时产出，也可以只产出一种outline+business通过产出的商务把标书目录，生成完整商务(包含除技术标)之外的标书。outline+technical通过产出的技术把标书目录，生成完整技术标书。
执行规则，严格遵守
- 必须按照规定workflow执行。
- 所有输出只能写到和用户提供的目录下的
work/、reports/、final/。所有创建的文件也只能在用户提供的这个目录下。 - 不能补充任何脚本，只能用项目现有脚本，所有脚本在scripts目录下。
- 脚本执行需要使用本 skill 内
.venv/作为虚拟环境来执行，脚本启动命令是虚拟环境的python，不是python3。 - 所有操作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。
执行流程
- 理解资料阶段
- 读
SKILL.md。 - 读当前项目
rfp/原文。 - 若主文档不足，继续在当前项目内深挖评分办法、技术规范、附件、分册和其他候选原文。
- 建立项目约束、评分约束、风险约束、三层业务分类和输出边界。
- outline 阶段 按照用户要求
- 目录节点统一使用
heading(level/text/children)表达 - 目录阶段的唯一详细流程、循环下钻规则、门禁要求与 Mermaid 流程图，统一以
references/outline-stage.md为准 - 只有在
references/outline-stage.md规定的全部目录门禁通过后，才允许生成：work/final_outline_technical.jsonwork/final_outline_business_other.jsonfinal/技术标_目录版.docxfinal/商务及其他_目录版.docx
- business 阶段
- 只写
work/final_bid_content_business_other.json中的workflow_bucket=business。
- technical 阶段
- 只写
work/final_bid_content_technical.json中的workflow_bucket=technical。
- other 阶段
- 只补
workflow_bucket=other，并并入work/final_bid_content_business_other.json。
- final 阶段
- 生成：
final/技术标.docxfinal/商务及其他.docx
阶段规则
1. 理解规则阶段
必须遵守：
/references/understandbid.md
1. outline
必须遵守
references/outline-stage.mdreferences/docx-ops.md
2. business
- 只写商务及其他文件中的
workflow_bucket=business，并配合workflow_bucket=other文件中的技术占位。 - 商务事实只认招标文件明示内容和用户真实材料。
- 缺件时只允许占位、缺件说明、附件索引空位或阻塞说明。
- 不得在商务及其他中补写任何技术正文。
- 只能写
final_outline_business_other.json中的叶子节点；若节点仍过于抽象，必须回退目录阶段。
商务材料必须进一步分桶组织，至少按以下业务桶判断归属、缺件和证据：
资格与准入
- 营业执照、资质证书、许可证、注册登记、法定代表人身份证明、授权委托等。
合规声明与承诺
- 无重大违法声明、联合体声明、原厂承诺、保密承诺、售后承诺、真实性声明等。
商务响应
- 商务条款响应、工期/服务期、交付地点、付款条件、质保期、偏离表、响应表等。
业绩与团队
- 类似业绩、项目负责人、实施团队、履历、证书、服务能力证明等。
财务与纳税社保
- 财务报表、审计报告、纳税证明、社保证明、开户信息等。
附件与索引
- 招标文件要求附后的证明材料、附件目录、盖章页、扫描件索引、技术转引占位等。
处理要求：
- 每个商务节点都应先判断属于哪个业务桶，再决定承载内容和缺件策略。
资格与准入、合规声明与承诺中的硬门槛缺失，应优先标记为高风险或阻塞。业绩与团队、财务与纳税社保不得用通用表述冒充真实材料。附件与索引只负责承载证据入口和材料定位，不替代正文判断。
3. technical
- 只写
work/final_bid_content_technical.json中的workflow_bucket=technical。 - 技术正文开始前，必须先明确总目标、建设主线、分系统主次和评委检索路径。
- 技术材料不足时，可以补专业技术方案，但不能伪造既有事实，必须保证技术框架和方案前后一致。
- 技术正文必须展开到架构、模块、实施、培训、验收、运维、风险控制等承载位。
- 图表必须服务具体评审主题，不能为了看起来专业而堆砌。
- 技术方案必须按章节填充，不允许一次性生成全部技术方案内容。最高允许一次性填充三级子标题。
- 只能对
final_outline_technical.json中的叶子节点写正文，不允许直接用父节点概述代替其全部子节点。 - 若叶子节点仍然是抽象标题，必须先回退目录阶段继续下钻，不得硬写正文。
4. other/finalize
- 不额外创造默认“报价子 workflow”。
- 通过总体验收前，不得对外宣称“完整投标文件”。
最终验收
导出前必须同时检查：
废标/否决项是否已有明确承载位、证据位或阻塞说明。合规项是否完整进入正式目录和交付物。评分项是否已得到优先展开，且目录深度与正文强度匹配评分重点。- 技术标目录是否合法。
- 商务及其他目录是否合法，且技术占位位置正确。
- 技术正文深度是否匹配项目复杂度。
- 图表是否真的承载评审主题。
- 证据链是否完整。
任一项不过，不得汇报“已完成”，但可以生成完整的占位草稿。占位内容仅限于资质、商务、声明、索引、技术转引等非技术实质内容；技术部分必须完整呈现于技术标，不得用占位代替。
References
按阶段和任务读取，不要一次性全读：
- DOCX 渲染与交付：
references/docx-assembly.mdreferences/docx-ops.md