2026-03-09 22:20:38 +08:00

10 KiB

Raw Blame History

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。

现有工具

以下脚本属于本 skill 当前可用工具：

parse-rfp 入口：scripts/run_skill.py --mode parse-rfp 用途：解析当前项目 rfp/*.docx，生成 work/document_graph.json 与 work/material_inventory.json。
scan-project 入口：scripts/run_skill.py --mode scan-project 用途：扫描当前项目资料目录，补充材料盘点。
render-outline 入口：scripts/run_skill.py --mode render-outline --bundle <technical|business-other> --outline <path> 用途：把已定稿的双目录事实源分别渲染为目录 Word。
render-bid 入口：scripts/run_skill.py --mode render-bid --bundle <technical|business-other> --content <path> 用途：把双正文事实源分别渲染为正式标书。
write-large-json 入口：scripts/run_skill.py --mode write-large-json --input <source.json> --out <target.json> 用途：安全写出超长 JSON 文件，统一处理 UTF-8、中文路径、分段写入、临时文件落盘与原子替换。边界：只负责 JSON 安全写入，不负责目录判断、正文生成或 DOCX 解析。
outline_linter.py 入口：scripts/outline_linter.py 用途：负责检查技术标目录是否足够专业和精细，防止目录设计太浅薄

允许使用的输出路径：

work/document_graph.json
work/material_inventory.json
work/rfp_constraints.json
work/evaluation_model.json
work/outline_strategy.json
work/final_outline_technical.json
work/final_outline_business_other.json
work/final_bid_content_technical.json
work/final_bid_content_business_other.json
reports/*.md
final/*.docx

固定输出顺序

work/document_graph.json
work/material_inventory.json
work/rfp_constraints.json
work/evaluation_model.json
work/outline_strategy.json（仅未定稿时）
work/final_outline_technical.json（仅已定稿时）
work/final_outline_business_other.json（仅已定稿时）
final/技术标_目录版.docx
final/商务及其他_目录版.docx
work/final_bid_content_technical.json
work/final_bid_content_business_other.json
final/技术标.docx
final/商务及其他.docx
final/技术标.pdf
final/商务及其他.pdf

业务分层

评分项 / 废标项 / 合规项

在理解资料和目录设计阶段，必须先把招标要求按业务风险和评审作用分成三层：

废标/否决项

指资格门槛、实质性响应、星号项、无效投标触发项、必须逐条满足的硬约束。
这些内容优先级最高，必须先确认是否有承载位、是否有证据、是否存在缺件或高风险。
若发现缺失或不确定，不得用泛化正文掩盖，必须显式标记风险、阻塞或占位说明。

合规项

指招标文件明确要求提供、但不一定直接计分的资格、声明、附件、表格、承诺、响应材料。
这些内容必须完整进入目录和交付物，不能因为“不加分”而省略。
若证据不足，只能按缺件规则处理，不能伪造完成。

评分项

指评标办法中有明确分值、等级、比较维度或加分导向的内容。
这些内容必须优先影响目录结构、技术展开深度、图表配置和正文篇幅。
同一章节若同时承载评分项与合规项，应优先按评分逻辑组织，再补足合规要求。

处理顺序：

先锁定 废标/否决项，确保不漏项。
再补齐 合规项，确保正式交付结构完整。
最后围绕 评分项 优化目录颗粒度、技术展开和证据呈现。

执行流程

理解资料阶段

读 SKILL.md。
读当前项目 rfp/ 原文。
若主文档不足，继续在当前项目内深挖评分办法、技术规范、附件、分册和其他候选原文。
建立项目约束、评分约束、风险约束、三层业务分类和输出边界。

outline 阶段

在内存中形成一份完整 canonical outline，覆盖 business、technical、other。
运行现有目录门禁和 linter。
门禁通过后拆分并生成：
- work/final_outline_technical.json
- work/final_outline_business_other.json
- final/技术标_目录版.docx
- final/商务及其他_目录版.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/技术标.docx
- final/商务及其他.docx
若执行 PDF 导出，同步导出对应两份 PDF。

阶段规则

1. 理解规则阶段

必须遵守：

references/rfp-deconstruction.md
references/evidence-escalation.md

1. outline

必须遵守

references/outline-stage.md
references/output-contracts.md
references/tables-and-scoring.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_bucket=other 的正式节点，并写入 work/final_bid_content_business_other.json。
技术占位节点归 workflow_bucket=other，只允许写“详见技术标”等转引说明，不得展开技术实质内容。
不额外创造默认“报价子 workflow”。
通过总体验收前，不得对外宣称“完整投标文件”。

最终验收

导出前必须同时检查：

废标/否决项 是否已有明确承载位、证据位或阻塞说明。
合规项 是否完整进入正式目录和交付物。
评分项 是否已得到优先展开，且目录深度与正文强度匹配评分重点。
技术标目录是否合法。
商务及其他目录是否合法，且技术占位位置正确。
技术正文深度是否匹配项目复杂度。
图表是否真的承载评审主题。
证据链是否完整。

任一项不过，不得汇报“已完成”，但可以生成完整的占位草稿。占位内容仅限于资质、商务、声明、索引、技术转引等非技术实质内容；技术部分必须完整呈现于技术标，不得用占位代替。

References

按阶段和任务读取，不要一次性全读：

商务及其他正文阶段：
- references/business-track.md
- references/output-contracts.md
技术正文阶段：
- references/technical-track.md
- references/tables-and-scoring.md
- references/output-contracts.md
DOCX 渲染与交付：
- references/docx-assembly.md
- references/output-contracts.md

10 KiB Raw Blame History Unescape Escape