316 lines
11 KiB
YAML
316 lines
11 KiB
YAML
# BidMaster-CLI 提示词配置文件
|
||
# 所有AI相关的提示词统一在此管理
|
||
|
||
# ============================================================================
|
||
# 系统消息配置
|
||
# ============================================================================
|
||
system_messages:
|
||
# LLM通用系统消息
|
||
default: "你是一个专业的招投标文档分析助手。"
|
||
|
||
# RAG内容生成系统消息
|
||
rag_generator: "你是一个专业的标书撰写助手。"
|
||
|
||
|
||
# ============================================================================
|
||
# 文档解析相关提示词
|
||
# ============================================================================
|
||
parser_prompts:
|
||
# AI解析评分表格
|
||
parse_scoring_table: |
|
||
请从复杂的评分表格中提取评分项和分值,并智能分类,返回JSON。
|
||
|
||
表格内容:
|
||
{table_text}
|
||
|
||
要求:
|
||
1. 仔细分析表格结构,即使有合并单元格也要正确提取
|
||
2. 从"评审内容"、"评分因素"、"评分标准"等列中提取评分项名称
|
||
3. 从"分值"列或评分标准描述中提取具体分值(如3分、5分、40分)
|
||
4. 忽略总分构成等汇总信息,只提取具体评分项
|
||
5. 智能分类各评分项:
|
||
|
||
**技术类别:**
|
||
- technical_solution: 技术方案、技术条款、技术完整性、技术先进性
|
||
- equipment_spec: 设备规格、产品参数、设备可靠性、技术指标
|
||
- implementation: 项目实施、施工方案、进度计划、实施能力
|
||
- quality_safety: 质量管理、安全管理、环境管理、质量体系
|
||
- after_sales: 售后服务、维保服务、培训服务、技术支持、服务部分
|
||
- compliance: 技术资质、认证证书、技术合规性、技术条款应答
|
||
|
||
**商务类别:**
|
||
- commercial: 价格评分、报价、商务条件、企业资质、财务状况、业绩、商务条款应答、响应文件制作质量、同类项目业绩、商务部分
|
||
|
||
示例输入分析:
|
||
- "响应文件制作质量 3分" → 商务类别
|
||
- "同类项目业绩 5分" → 商务类别
|
||
- "技术条款应答 2分" → 合规类别
|
||
- "商务条款应答 2分" → 商务类别
|
||
|
||
格式:
|
||
{{
|
||
"scoring_criteria": [
|
||
{{"item_name": "响应文件制作质量", "max_score": 3, "description": "文件格式内容要求", "category": "commercial"}},
|
||
{{"item_name": "同类项目业绩", "max_score": 5, "description": "项目经验证明", "category": "commercial"}},
|
||
{{"item_name": "技术条款应答", "max_score": 2, "description": "技术要求符合性", "category": "compliance"}}
|
||
]
|
||
}}
|
||
|
||
只返回JSON,无其他文字:
|
||
|
||
# AI解析偏离表格
|
||
parse_deviation_table: |
|
||
请提取表格中的偏离项,返回JSON。
|
||
|
||
表格内容:
|
||
{table_text}
|
||
|
||
要求:
|
||
1. 提取技术要求和响应类型
|
||
2. 响应类型如:正偏离、负偏离、无偏离等
|
||
3. 忽略序号和表头
|
||
|
||
格式:
|
||
{{
|
||
"deviation_items": [
|
||
{{"requirement": "设备需符合国标", "response_type": "正偏离"}},
|
||
{{"requirement": "技术指标要求", "response_type": "无偏离"}}
|
||
]
|
||
}}
|
||
|
||
只返回JSON,无其他文字:
|
||
|
||
# AI识别表格类型
|
||
identify_table_type: |
|
||
分析表格内容,判断这是什么类型的表格。
|
||
|
||
表格内容:
|
||
{table_text}
|
||
|
||
请判断这个表格属于以下哪种类型:
|
||
1. scoring - 评分表:包含评分项、分值、评分标准等内容,例如:
|
||
- 有"分值"、"评分标准"、"得分"等列
|
||
- 有具体的分值数字(如3分、5分、40分等)
|
||
- 有"商务部分"、"技术部分"、"服务部分"等分类
|
||
- 有评审内容和评分因素
|
||
|
||
2. deviation - 偏离表:包含技术要求、响应类型、偏离说明等
|
||
3. other - 其他表格:不是评分表也不是偏离表
|
||
|
||
注意:即使表格结构复杂、有合并单元格,只要包含评分标准和分值信息就是评分表。
|
||
|
||
只返回一个单词:scoring 或 deviation 或 other
|
||
|
||
|
||
# ============================================================================
|
||
# 目录生成相关提示词
|
||
# ============================================================================
|
||
toc_prompts:
|
||
# 生成子章节
|
||
generate_sub_chapters: |
|
||
为以下大类别生成专业的标书子标题:
|
||
|
||
【大类别】: {parent_title}
|
||
【评分项】:
|
||
{criteria_info}
|
||
【招标上下文摘录】:
|
||
{context_snippets}
|
||
【全局技术一致性提示】:
|
||
{tech_consistency_prompt}
|
||
|
||
生成要求:
|
||
1. 为每个评分项生成对应的子标题名称(不要包含编号)
|
||
2. 重要评分项可添加三级子标题(不要包含编号)
|
||
3. 充分参考上下文摘录中的专业术语和业务背景,体现定制化判断
|
||
4. 必须遵循“全局技术一致性提示”中的架构/技术选型/术语口径，确保全篇一致
|
||
5. 只返回标题文本,编号由Word自动管理
|
||
|
||
返回JSON格式:
|
||
{{
|
||
"sub_chapters": [
|
||
{{"title": "技术架构设计", "level": 2, "score": 5, "children": []}}
|
||
]
|
||
}}
|
||
|
||
只返回JSON:
|
||
|
||
# 审查目录结构
|
||
review_structure: |
|
||
请审查这个标书目录结构的合理性和完整性。
|
||
|
||
【技术评分项分布】:
|
||
{criteria_summary}
|
||
|
||
【当前生成的章节结构】:
|
||
{chapters_summary}
|
||
【招标主题线索】:
|
||
{document_themes}
|
||
|
||
【审查要求】:
|
||
1. 是否缺少重要的标准章节?
|
||
2. 章节顺序是否合理?
|
||
3. 是否覆盖了主题线索中的关键内容?
|
||
4. 每个评分项是否都有对应章节?
|
||
|
||
返回JSON格式:
|
||
{{
|
||
"overall_assessment": "总体评价",
|
||
"suggestions": [
|
||
{{"type": "add/modify/reorder", "description": "建议内容", "priority": "high/medium/low"}}
|
||
],
|
||
"optimization_score": 85
|
||
}}
|
||
|
||
只返回JSON:
|
||
|
||
# AI调整章节结构
|
||
adjust_chapters: |
|
||
请根据用户选择的建议调整以下标书章节结构。
|
||
|
||
【当前章节结构】:
|
||
{chapters_text}
|
||
|
||
【用户选择应用的建议】:
|
||
{suggestions_text}
|
||
|
||
【调整要求】:
|
||
1. 根据用户选择的建议对章节结构进行合理调整
|
||
2. 保持章节的逻辑性和完整性
|
||
3. 每个章节都要有明确的标题和层级
|
||
4. 保持专业的标书格式
|
||
|
||
返回JSON格式:
|
||
{{
|
||
"adjusted_chapters": [
|
||
{{
|
||
"id": "chapter_1_technical_solution",
|
||
"title": "技术方案",
|
||
"level": 1,
|
||
"score": 0,
|
||
"children": [
|
||
{{
|
||
"id": "chapter_2_1_architecture",
|
||
"title": "系统架构设计",
|
||
"level": 2,
|
||
"score": 0,
|
||
"children": []
|
||
}}
|
||
]
|
||
}}
|
||
]
|
||
}}
|
||
|
||
只返回JSON:
|
||
|
||
# 根据用户反馈优化目录
|
||
optimize_with_feedback: |
|
||
你是一个专业的标书目录结构优化助手。
|
||
|
||
**⚠️ 警告:如果你不按照用户的要求修改目录结构,将被视为任务失败!⚠️**
|
||
|
||
**🔥 强制要求:你必须完全执行用户的修改要求,不能返回未修改的结构!🔥**
|
||
|
||
当前目录结构:
|
||
{current_toc}
|
||
|
||
用户反馈意见:
|
||
{feedback}
|
||
|
||
**执行步骤(必须严格遵守):**
|
||
1. **理解要求**:分析用户具体要求什么修改
|
||
2. **执行修改**:必须按要求修改目录结构,不能保持原样
|
||
3. **确认修改**:检查确保已经按用户要求进行了修改
|
||
|
||
**重要修改规则:**
|
||
- 如果用户说"内容太少,多补充"或"多增加",必须增加新的同级别子章节
|
||
- 如果用户指定某个章节,只修改该章节
|
||
- 如果用户要求"调整顺序",必须重新排列
|
||
- 如果用户要求"修改标题",必须更新标题
|
||
|
||
**具体示例:**
|
||
|
||
示例1:用户说"售后服务章节多增加一个子标题"
|
||
- 在"售后服务"下新增子章节(如"技术支持服务"、"培训服务"等)
|
||
|
||
示例2:用户说"合规响应的内容太少,多补充一些"
|
||
- 在"合规响应"下除了"技术实力",还要增加:
|
||
* "资质认证展示"
|
||
* "成功案例介绍"
|
||
* "行业认可度说明"
|
||
* "合规承诺声明"
|
||
|
||
**最终检查:**
|
||
修改完成后,你必须确认已经按用户要求进行了实际修改,不能返回相同的结构!
|
||
|
||
请返回优化后的目录结构JSON,格式如下:
|
||
{{
|
||
"chapters": [
|
||
{{
|
||
"id": "chapter_1",
|
||
"title": "章节标题",
|
||
"level": 1,
|
||
"score": 0.0,
|
||
"children": [
|
||
{{
|
||
"id": "chapter_1_1",
|
||
"title": "子章节标题",
|
||
"level": 2,
|
||
"score": 0.0,
|
||
"children": []
|
||
}}
|
||
]
|
||
}}
|
||
]
|
||
}}
|
||
|
||
只返回JSON,不要其他内容。
|
||
|
||
|
||
# ============================================================================
|
||
# 内容生成相关提示词
|
||
# ============================================================================
|
||
content_prompts:
|
||
# RAG内容生成
|
||
generate_with_rag: |
|
||
你是一个专业的标书撰写助手。请根据以下信息生成标书章节内容:
|
||
|
||
当前章节: 《{title}》
|
||
章节定位: {chapter_path}
|
||
写作模式: {writing_mode}
|
||
篇幅要求: {length_hint}
|
||
子标题分工: {child_outline}
|
||
分值关注: {score_info}
|
||
评分要点:
|
||
{rubric_points}
|
||
|
||
写作目标:
|
||
{objectives}
|
||
|
||
一致性约束:
|
||
{consistency_rules}
|
||
|
||
上下文参考:
|
||
{context_summary}
|
||
|
||
重点提示:
|
||
{guidance_part}
|
||
|
||
评分说明:
|
||
{requirements_summary}{emphasis_part}{rag_part}
|
||
|
||
要求:
|
||
1. 内容专业、详实,符合招标文件要求
|
||
2. 突出技术优势和实施能力，在技术上，流程上一定要保证各个环节章节的一致性
|
||
3. 严格遵守写作模式与篇幅要求: 有子标题仅写父级统领概要(不展开子标题正文)，无子标题输出完整正文
|
||
4. 严禁新增任何章/节级标题或“商务条款、技术偏差、响应情况”等模板段,如需结构化仅使用普通段落或加粗语句
|
||
5. 开头不得出现“经认真研读招标文件要求”“偏差说明如下”等跨章节套话,内容必须围绕《{title}》本身展开
|
||
6. 格式上结合招标要求，先总述响应招标内容，点明标题的主要内容是什么，再分开将业务部分、技术实现一一说明，通过编号的形式让内容更有条理。最后如有必要可有一段总结性的内容，但不一定必须。一定要专业、条理清晰，符合招标文件的严格要求
|
||
7. 业务描述上一定要流程化、场景化
|
||
8. 技术描述上一定通俗易懂，但又不失专业性，特别是一些非常切题的或者应用性契合很好的技术一定要写明白
|
||
9. 一定要遵循知识库中提供的内容，严格遵守
|
||
10. 内容中不要提及招标单位的具体名称，如果需要提及，可用需求单位、业主单位等类似词语代替
|
||
11. 内容中不要出现专业软件的具体版本号，比如unity等
|
||
12. 如果内容需要，就生成markdown格式的表格，表格格式和内容由你来决定，一定要专业
|
||
|
||
请直接输出章节内容,不要包含章节标题。
|