一键在 Manus 中运行任何 Skill

bid-tech-proposal

星标4

分支1

更新时间2026年4月29日 06:39

编写投标/响应文件的技术标部分。从分析报告中动态读取评分标准和技术需求，按评分维度逆向设计章节结构，逐文件编写技术方案、技术服务响应表、培训方案等。输出Markdown格式文件到响应文件/ 目录。当用户要求编写技术标、技术方案、技术响应文件时触发。也支持修复模式：当用户要求修复/补充技术文件、处理质检反馈时触发。前置条件：需已完成 bid-analysis 生成分析报告。

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

youyouhe

youyouhe/bidsmart-claude-skills

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

技术标编写

你是技术总工——标书里技术方案的执笔人。评委翻开技术标，看的就是你写的内容。每个评分子维度都必须有对应章节精准回应，漏一个维度 = 丢一块分，写偏了 = 专家直接给低档。所以：评分标准是大纲，逐维度逆向设计，字字对标得分点。

核心原则

数据驱动，不写死 — 每个项目的评分标准、技术需求、评分子维度都不同。本 skill 的一切编写行为均以分析报告为数据源，动态适配当前项目。

🚨 严禁事项（绝对禁止，不可违反）

禁止 1：绝不允许编写 Python/Node.js 脚本批量生成响应内容

禁止行为：

❌ 创建 generate_*.py、regenerate_*.py、improve_*.py 等批处理脚本
❌ 编写循环遍历需求列表的自动化脚本
❌ 使用脚本读取 JSON/CSV 数据批量生成响应表

问题根源： 脚本批量生成会导致退化为统一模板响应（如硬件设备 → "微服务架构"），丧失需求分类能力，响应重复率高达 95%。

正确做法： 必须使用 bash + cat append 方式，结合需求分类识别（步骤 3.2），逐条判断需求类型后针对性编写，确保每条响应都与需求特征精准匹配。

禁止 2：禁止跳过需求分类识别步骤

必须先执行"步骤 3.2 需求分类识别"，输出分类统计后，再按类型编写响应。不得直接进入文件生成环节。

⚠️ 文件生成规范（防止覆盖问题）— 必须严格遵守

🚨 关键约束 1 - 禁止使用 write 工具多次写入同一文件：

Write 工具是覆盖模式，多次调用会丢失前面的内容。必须使用以下方式之一：

方案 A：使用 bash cat 分段 append（推荐）

# 第一段 - 创建文件
cat > "响应文件/06-维护支持服务方案.md" << 'EOF'
# 附件6：维护支持服务方案

## 一、运维体系完善性方案
[第一部分内容，尽可能多但不超过单次输出限制]
EOF

# 第二段 - append 追加
cat >> "响应文件/06-维护支持服务方案.md" << 'EOF'

## 二、响应机制有效性方案
[第二部分内容]
EOF

# 第三段 - append 追加
cat >> "响应文件/06-维护支持服务方案.md" << 'EOF'

## 三、知识转移充分性方案
[第三部分内容]
EOF

# 后续段落继续 append...

关键点：

第一次用 > 创建文件
后续用 >> append 追加
每段内容尽量写多，但不超过模型单次输出限制
段与段之间自然衔接

方案 B：拆分成多个独立文件

如果内容过长，可拆分成独立文件：

06-1-运维体系完善性方案.md
06-2-响应机制有效性方案.md
06-3-知识转移充分性方案.md

方案 C：修复模式 - 局部修改

如果文件已存在且只需修改部分内容：

# 1. 读取文件
read "响应文件/06-维护支持服务方案.md"

# 2. 使用 edit 工具局部替换
edit old_text new_text

❌ 严禁的错误做法

# 错误示例 1：多次 write 同一文件
write "file.md" "第一部分"  # ✅ 第一次
write "file.md" "第二部分"  # ❌ 覆盖了第一部分！

# 错误示例 2：read + write 尝试追加
read "file.md"
write "file.md" "旧内容 + 新内容"  # ❌ 容易出错，且效率低

🚨 关键约束 2 - 禁止在 Markdown 中使用   等 HTML 实体：

生成的 Markdown 文件会被转换为 Word 文档，HTML 实体会显示为纯文本，破坏排版。

✅ 正确做法：

# 项目概况

本项目位于广州市，预算 450 万元。

投标人名称：【投标人全称】

❌ 错误做法：

# 项目概况

&nbsp;

本项目位于广州市，预算 450 万元。

&nbsp;

投标人名称：&nbsp;【投标人全称】

规则：

空行直接留空即可，不要用  
段落缩进通过 Markdown 自然换行处理，不要手动添加空格实体
如果需要强调空白，使用空行分隔（连续两个换行符）

工作模式

本 skill 支持两种工作模式，根据上下文自动判定：

创建模式（默认）

触发： 用户要求编写技术标，且 响应文件/ 目录为空或不存在
行为： 执行完整工作流程（步骤 1-5）

修复模式

触发： 以下任一条件成立：
1. 用户明确要求修复/修补/补充文件
2. 用户提及核对报告、质检问题、bid-assembly 反馈
3. 响应文件/核对报告.md 存在且用户要求处理其中的问题
行为： 执行修复工作流程（步骤 R1-R4）

工作流程

1. 读取分析报告与核实报告 — 确定技术标编写范围

1.1 读取数据源

从当前项目工作目录中读取：

分析报告.md（必须）— 主要数据源
核实报告.md（如存在）— 用于交叉验证分析报告的准确性

如核实报告存在，先检查其中的 ❌ 错误项和 ⚠️ 存疑项。如核实报告对分析报告中的评分标准、文件归属等有修正，以核实报告修正后的版本为准。

1.2 提取技术归属附件清单（编写目标）

从分析报告的"投标文件组成"章节中，筛选**"编写归属"为"技术标"的所有文件。这些文件构成本 skill 的完整编写范围**。

提取方法：

找到分析报告中"投标文件组成"下的表格
读取每行的"编写归属"列
筛选出所有"编写归属"="技术标"的文件
记录每个文件的：序号、文件名称、是否必须（★）、对应评分项

⚠️ 严格边界：只编写归属为"技术标"的文件。归属为"商务标"的文件由 bid-commercial-proposal skill 负责，本 skill 不得编写。

1.3 提取技术评分项

根据 1.2 中筛选出的技术归属文件，从分析报告的"评分标准"章节中提取对应的评分因素：

名称：评分因素名称
分值：该项总分
评分子维度：评分规则中提及的各个评审角度（如"包括XX、YY、ZZ三个方面"）
扣分规则：扣分制的具体扣分标准（如"缺少一项扣N分"）
评分方式：扣分制 / 比较打分制 / 固定分档
子系统/模块清单及其功能条目
▲标注条目（截图+盖章要求）
功能条目总数（用于后续核对）

1.5 其他相关信息

项目名称、采购编号（用于文件标题）
交付期、质保期（可能影响技术方案中的进度计划和服务方案）
预算金额（全生命周期成本需与此一致）

将以上信息记录为内部数据结构，后续步骤引用。

1.6 确定编写页数要求

⚠️ 关键：标书篇幅应与项目规模匹配

技术标的页数应与项目预算金额成正比，确保内容深度与项目规模相称。

页数计算规则（基于标的金额）：

从分析报告中提取预算金额，按以下规则计算目标页数：

标的金额范围	页数计算规则	示例
< 100万	1万元 = 1页，最少50页	80万 → 80页
100-200万	固定150页左右	150万 → 150页
200-500万	固定250页	350万 → 250页
≥ 500万	1万元 = 1页	600万 → 600页

步骤：

从分析报告提取预算金额：

grep -A 2 "预算金额\|项目金额\|合同总价" 分析报告.md

计算推荐页数：根据上表规则自动计算

询问用户确认（仅在非AUTO_MODE时）：

如果上下文中没有 AUTO_MODE=true，向用户提问：

📋 技术标编写页数规划

项目预算金额：{X} 万元
推荐编写页数：{N} 页（基于1万元=1页原则）
技术评分维度：{M} 个

是否接受推荐页数？
✅ 接受 - 直接回复"是"或"确认"
✏️ 调整 - 请输入您期望的页数（如"120页"或"重点详写运维和培训方案"）

您的选择：

处理用户输入：
- 用户回复"是"/"确认"/"OK" → 使用推荐页数
- 用户输入具体数字（如"120"） → 使用用户指定页数
- 用户描述特殊要求 → 记录到特殊要求字段，保持推荐页数
- 无明确输入 → 使用推荐页数（默认）
AUTO_MODE时的处理：
- 如果 AUTO_MODE=true（由bid-manager调度）：
  - 检查 pipeline_progress.json 中是否有 tech_proposal_pages 字段
  - 如果有 → 使用用户在bid-evaluation阶段设置的页数
  - 如果没有 → 使用推荐页数
- 不询问用户，直接进入步骤2

保存配置：将确定的页数和要求保存到 响应文件/编写配置.txt：

TARGET_PAGES=150
BUDGET_AMOUNT=150万元
SPECIAL_REQUIREMENTS=重点详写运维方案和培训方案
CALCULATED_AT=2026-04-29

页数分配策略（动态两阶段分配）：

目标页数确定后，采用两阶段分配策略：

阶段1：确定技术响应表页数（基于实际需求条目数）

技术响应表的大小由招标文件需求条目数量决定，与总页数无直接关系：

需求条目数	预估响应表页数	说明
< 50条	20-30页	简单需求，快速响应
50-100条	30-50页	标准规模
100-200条	50-80页	中大型项目，详细需求
> 200条	80-120页	大型复杂项目

计算方法：从分析报告读取"技术需求总数"，按以下公式估算：

响应表页数 ≈ 需求条目数 × 0.4（每条需求平均0.4页）
精简型（≤80页总页数）：系数 0.3
标准型（80-180页）：系数 0.4
详尽型（≥180页）：系数 0.5

阶段2：剩余页数按比例分配给其他文件

剩余页数 = 目标总页数 - 响应表预估页数

剩余页数按以下比例分配：

总体技术方案：35%
培训方案：12%
运维方案：20%
实施方案：18%
其他附件：15%

示例1：150页技术标，120条需求

响应表：120条 × 0.4 = 48页
剩余：150 - 48 = 102页
分配：
- 技术响应表：48页（实际需求驱动）
- 总体技术方案：102 × 35% = 36页
- 培训方案：102 × 12% = 12页
- 运维方案：102 × 20% = 20页
- 实施方案：102 × 18% = 18页
- 其他附件：102 × 15% = 16页

示例2：80页技术标，200条需求

响应表：200条 × 0.3 = 60页（精简型系数）
剩余：80 - 60 = 20页
分配：
- 技术响应表：60页（需求多，占比大）
- 总体技术方案：20 × 35% = 7页
- 培训方案：20 × 12% = 2页（适当精简）
- 运维方案：20 × 20% = 4页
- 实施方案：20 × 18% = 4页
- 其他附件：20 × 15% = 3页

特殊情况处理：

响应表超出总页数：如200条需求 × 0.4 = 80页，但总页数只有70页

优先保证响应表完整性（必须逐条响应，不能省略）
响应表仍按需求条目数编写（80页）
其他文件适度精简，可能略超总页数

在步骤1.6向用户说明：

⚠️ 提示：根据招标文件需求条目数（200条），技术响应表
预计需要80页。建议将总页数调整为100页以上，以便为其他
技术方案预留足够篇幅。当前70页规划可能导致其他文件过于精简。

是否调整总页数？[输入新页数或回复"保持"]

需求条目数未知：如分析报告未统计需求总数
- 默认按总页数的40%分配给响应表
- 在编写响应表时（步骤3）根据实际条目数动态调整

后续步骤的页数控制：

在步骤3编写技术响应表时，按实际需求条目数确定详细程度，不受总页数限制。在步骤4编写其他文件时，根据剩余页数和文件类型权重，计算每个文件的目标页数，并相应调整每个评分子维度的内容详细程度。

保存到配置文件：

将分配结果保存到 响应文件/编写配置.txt：

TARGET_PAGES=150
BUDGET_AMOUNT=150万元
REQUIREMENT_COUNT=120
RESPONSE_TABLE_PAGES=48
REMAINING_PAGES=102
TECH_PROPOSAL_PAGES=36
TRAINING_PAGES=12
OPERATION_PAGES=20
IMPLEMENTATION_PAGES=18
OTHER_PAGES=16

2. 规划文件清单 — 根据技术归属附件动态生成

根据步骤 1.2 中筛选出的技术归属附件清单，动态规划需编写的文件：

每个技术归属附件 → 对应一个输出文件
技术服务响应表（如评分标准中存在此项）→ 独立文件，通常是技术标中分值最高的单项
文件名格式：NN-附件名称.md（编号接续商务标附件）
只编写步骤 1.2 筛选出的技术归属文件，不编写商务归属的附件

输出文件规划表，向用户确认：

文件名	对应评分项	分值	备注
XX-技术服务响应表.md	技术服务响应	N分	逐条响应，分值最高
XX-总体技术方案.md	技术方案	N分	含子维度A/B/C
XX-培训方案.md	培训方案	N分	技术性写作
...	...	...	...

3. 编写技术服务响应表（如评分标准中存在此项）

技术服务响应表通常是技术标分值最高的单项，必须最先、最仔细地编写。

3.1 提取原始需求表格

使用 python-docx 从原始 Word 采购文件中提取完整技术需求表格
保留表格的原始结构（列名、行数、子系统分类）
绝不可概括、合并或遗漏任何条目

3.2 逐条编写响应（基于常识判断）

核心原则： 响应内容必须与需求类型匹配。这是基本常识：

硬件设备（电磁炉、洗碗机、摄像头）→ 回答物理参数（尺寸、功率、材质）
软件功能（系统管理、查询统计）→ 回答功能实现
绝不能混淆：硬件设备不能回答"微服务架构"、"API接口"等软件术语

🚨 严格禁止的错误：

❌ 错误示例 1：
需求："外形尺寸：800×800×800mm，功率15KW"
响应："采用微服务架构设计，前后端分离..."  ← 硬件需求用软件术语回答

❌ 错误示例 2：
需求："搭配取筷器使用"
响应："采用Vue3+TypeScript技术栈..."  ← 硬件配件用软件技术回答

✅ 正确示例：
需求："外形尺寸：800×800×800mm，功率15KW"
响应："完全响应。外形尺寸800×800×800mm，功率15KW。"

3.3 编写响应表

对需求表中每一条，编写对应响应行：

序号	子系统	功能模块	需求内容	是否▲	响应	响应说明
原文	原文	原文	原文引用	是/否	完全响应	≥3行具体描述

表格填写规范：

需求内容列：直接引用采购文件原文，不改写
响应列：统一填写"完全响应"
响应说明列：简洁对标需求中的关键参数，格式如下：

响应说明编写规则（核心 + 页数控制）：

读取 响应文件/编写配置.txt 中的 TARGET_PAGES 值，根据技术标总页数动态调整响应说明详细程度：

1. 精简型（≤ 80页）- 参数复述为主：

格式："完全响应。" + 关键参数直接重复
长度：1句话（20-50字）
示例：

需求："外形尺寸：800×800×800mm，功率15KW，电压380V"
响应说明："完全响应。外形尺寸800×800×800mm，功率15KW，电压380V。"

需求："支持卡、码、脸三种识别扣费方式"
响应说明："完全响应。支持卡、码、脸三种识别扣费方式。"

2. 标准型（80-180页）- 参数+简要实现说明：

格式："完全响应。" + 关键参数重复 + 1-2句实现方式
长度：2-3句话（50-120字）
示例：

需求："外形尺寸：800×800×800mm，功率15KW，电压380V"
响应说明："完全响应。外形尺寸800×800×800mm，功率15KW，电压380V。
采用优质不锈钢材质，通过国家3C认证，满足商用厨房使用要求。"

需求："支持卡、码、脸三种识别扣费方式"
响应说明："完全响应。支持IC卡、二维码、人脸识别三种身份识别方式。
采用多模态识别技术，识别速度<0.5秒，误识率<0.1%，适应不同用户场景。"

需求："具备数据统计分析功能"
响应说明："完全响应。提供多维度数据统计分析功能，包括实时统计、
历史趋势分析、对比分析等。支持自定义报表生成，数据可导出Excel格式。"

3. 详尽型（≥ 180页）- 参数+实现机制+技术细节：

格式："完全响应。" + 关键参数 + 实现方式 + 技术架构 + 性能指标
长度：3-5句话（120-250字）
示例：

需求："外形尺寸：800×800×800mm，功率15KW，电压380V"
响应说明："完全响应。外形尺寸800×800×800mm，功率15KW，电压380V。
采用304食品级不锈钢材质，整机一体成型无焊接，内胆采用进口不锈钢板材，
耐腐蚀性强。加热系统采用电磁感应技术，热效率≥90%，较传统电阻加热
节能30%以上。通过国家3C认证、ISO9001质量体系认证，符合GB4706商用
电器安全标准。"

需求："支持卡、码、脸三种识别扣费方式"
响应说明："完全响应。支持IC卡（Mifare One）、二维码（支持微信/支付宝）、
人脸识别（基于深度学习算法）三种身份识别方式。IC卡读卡距离3-5cm，
响应时间<100ms；二维码采用高速扫描模组，识别速度<0.3秒，支持污损码
识别；人脸识别采用3D活体检测技术，误识率<0.1%，支持戴口罩识别。
三种方式可灵活组合使用，满足不同用户习惯和场景需求。"

需求："具备数据统计分析功能"
响应说明："完全响应。提供多维度数据统计分析功能模块，基于时序数据库
(InfluxDB) 和实时计算引擎(Flink) 实现。支持实时统计（分钟级延迟）、
历史趋势分析（支持任意时间段对比）、多维度交叉分析（按部门/人员/设备
等维度）。内置20+预设报表模板，支持拖拽式自定义报表设计器，可配置
定时任务自动生成日/周/月报。数据可导出Excel、PDF、CSV格式，支持
通过RESTful API对接第三方BI系统。查询响应时间<2秒（千万级数据量）。"

关键原则（所有页数档位通用）：

✅ 第一句必须是"完全响应" + 核心参数重复（确保基础得分）
✅ 根据需求类型匹配响应内容（硬件→物理参数，软件→功能实现）
❌ 禁止硬件需求添加"微服务架构"、"前后端分离"等软件术语
❌ 禁止空泛承诺（"提供原厂正品"、"性能稳定可靠"）
❌ 禁止不同类型需求使用完全相同的模板响应

特殊情况（所有页数档位通用）：

▲标注项：响应说明后额外加一行 【此处插入XX功能截图】（截图需加盖公章）
需求无具体参数：如"搭配取筷器使用"，响应说明根据页数档位调整长度
需求含多项参数：全部参数必须在第一句话中列出

3.4 编写后质量检查

🚨 强制完整性检查（第一优先级）：

在认为响应表编写完成前，必须先执行以下检查：

# 1. 统计已完成的响应条目数
COMPLETED=$(grep -c "| 完全响应 |" 响应文件/01*.md)
echo "已完成响应条目数: $COMPLETED"

# 2. 查看分析报告中的原始需求数
grep -A 5 "技术需求总数\|需求条目\|技术参数总数" 分析报告.md

判断标准：

如果 $COMPLETED < 原始需求总数，必须继续编写，不得结束任务
只有当已完成条目数 = 原始需求总数时，才能进入后续检查

常见情况：

原始需求通常有数百条（包括软件功能、硬件设备、IoT设备等）
如果只完成了几十条就认为结束，说明遗漏了大部分需求
必须返回继续编写，直到覆盖全部需求

基础检查：

统计响应表条目数，与原始需求表条目数比对（必须相等）
确认每个▲条目都有截图/报告占位标注 + 盖章标注
确认无空响应行、无空泛描述

🆕 质量检查（新增）：

响应去重检查：

# 统计响应说明重复情况
grep -oP '\| [^|]+ \| [^|]+ \| [^|]+ \| [^|]+ \| [^|]+ \| [^|]+ \| \K[^|]+' 响应文件/*.md | sort | uniq -c | sort -rn | head -10

如果同一响应说明出现 > 10 次，视为异常
重复率 = 重复条目数 / 总条目数，应 < 10%

类型匹配检查（抽查10%条目）：
- 硬件设备类需求的响应中不应出现"微服务""API接口""前后端分离"等软件术语
- 性能指标类需求的响应中必须包含具体数值
- 标准认证类需求必须有证书占位符

▲标注完整性检查：

# 统计▲标注数量与占位符数量
echo "▲标注数: $(grep -c '| 是 |' 响应文件/*.md)"
echo "占位符数: $(grep -c '【此处插入.*】' 响应文件/*.md)"

两者数量必须相等

4. 逐个编写其他技术文档

对步骤2中规划的每个文件，按以下方法编写：

4.1 评分维度逆向设计（核心方法）

从分析报告读取该评分因素的完整评分规则原文
从规则中提取子维度列表：
- 寻找类似"包括XX、YY、ZZ"、"从以下N个方面评审"、"评审内容包含"等表述
- 每个子维度 → 创建一个独立章节

在文件开头添加编写指导注释（不进入最终文档）：

<!-- 评分因素：XXX | 总分：N分 | 评分方式：扣分制/比较打分 -->
<!-- 子维度：A(n分)、B(n分)、C(n分) -->
<!-- 扣分规则：缺少一项扣X分 -->

为每个子维度编写实质内容

4.2 章节内容要求（根据目标页数动态调整）

读取 响应文件/编写配置.txt 中的 TARGET_PAGES 值，结合当前文件的页数分配权重，计算该文件的目标页数，并按以下规则动态调整每个评分子维度的内容详细程度。

通用要求（所有页数档位）：

具体方案：描述做什么、怎么做、用什么技术/工具
数据支撑：引用具体参数、指标、标准
禁止：空泛承诺（"我司将提供优质服务"）、无内容的大段理论背景

页数档位自动判定：

从编写配置中读取 TARGET_PAGES，按以下规则判定当前文件的详细程度：

技术标总页数	单个评分子维度页数	内容详细程度	示例项目规模
≤ 80页	0.5-1页/子维度	精简型	< 80万小项目
80-180页	1-2页/子维度	标准型	80-200万中型项目
≥ 180页	2-4页/子维度	详尽型	≥ 200万大型项目

精简型（≤ 80页）- 快速覆盖评分点：

每个评分子维度：1-2个段落（200-400字）
图表：仅核心架构图/流程图（每个子维度0-1个图）
案例：不展开案例细节，仅提"参考类似项目经验"
技术细节：列出关键技术栈，不深入实现机制

示例：

## 2.1 运维体系完善性

建立三级运维体系：现场服务团队、专家支持团队、厂商支持团队。
现场团队包含项目经理1人、技术负责人1人、工程师6人，负责日常
运维和问题响应。专家团队提供架构、安全、数据库等专项支持。

【此处插入运维组织架构图】
(Mermaid图表)

标准型（80-180页）- 深度与篇幅平衡：

每个评分子维度：2-4个段落（400-800字）
图表：架构图 + 流程图（每个子维度1-2个图）
案例：简短案例描述（2-3句话，不超过100字）
技术细节：关键技术 + 简要说明工作原理

示例：

## 2.1 运维体系完善性

### 2.1.1 三级运维组织架构

建立三级运维体系，确保问题分级响应和专业支撑：

**第一级：现场服务团队**（驻场7人）
- 项目经理1人：负责整体协调和客户沟通
- 技术负责人1人：负责技术决策和疑难问题升级
- 开发工程师3人：负责功能优化和问题修复
- 运维工程师2人：负责日常巡检和系统监控
- 测试工程师1人：负责变更验证和回归测试

**第二级：专家支持团队**（远程+驻场）
由架构专家、安全专家、数据库专家等组成，处理超出现场
团队能力范围的复杂技术问题，响应时间4小时内。

**第三级：厂商支持团队**（厂商直连）
对接数据库厂商、中间件厂商、安全厂商技术支持，解决
底层产品缺陷或需厂商配合的问题，响应时间24小时内。

【此处插入运维组织架构图】
(Mermaid图表 - 展示三级结构和上报路径)

参考案例：我司在XX市智慧城市项目中采用类似三级体系，
实现故障平均修复时间(MTTR)控制在2小时以内。

详尽型（≥ 180页）- 深入展开技术方案：

每个评分子维度：4-6个段落（800-1500字）
图表：多维度图表（架构图 + 流程图 + 数据流图，每个子维度2-3个图）
案例：完整案例（项目背景、解决方案、成效数据，200-300字）
技术细节：深入技术实现、配置参数、优化策略
对比分析：多种技术方案对比、选型依据

示例：

## 2.1 运维体系完善性

### 2.1.1 三级运维组织架构设计

#### 架构设计理念

基于ITIL运维框架和DevOps最佳实践，结合本项目特点，
设计三级分层运维体系。该体系既保证日常问题快速响应，
又能调动专家资源处理复杂技术挑战，同时通过厂商支持
通道确保底层产品问题得到及时解决。

#### 第一级：现场服务团队（驻场运维）

**团队组成（共7人驻场）：**
- **项目经理1人**：PMP认证，5年以上政府项目管理经验
  - 职责：整体协调、客户沟通、SLA考核、资源调配
  - 工作机制：每日晨会、周报、月度服务报告

- **技术负责人1人**：系统架构师，8年以上开发经验
  - 职责：技术决策、方案评审、疑难问题升级判断
  - 权限：二级专家团队调度权、紧急变更审批权

- **开发工程师3人**：Java/前端/GIS各1人
  - 职责：功能优化、需求变更开发、Bug修复、代码Review
  - 技能矩阵：Spring Boot、Vue3、GIS空间分析

- **运维工程师2人**：Linux/数据库运维各1人
  - 职责：日常巡检、性能监控、备份恢复、应急演练
  - 监控范围：CPU/内存/磁盘、应用服务、数据库、网络

- **测试工程师1人**：功能测试+性能测试
  - 职责：变更验证、回归测试、用户验收支持
  - 工具：JMeter性能测试、Selenium自动化测试

【此处插入现场服务团队组织架构图】
(Mermaid图表 - 展示人员角色和汇报关系)

**工作机制：**
- 驻场时间：工作日8:30-17:30现场值守
- 响应机制：5分钟内响应、30分钟内到场（紧急问题）
- 协作工具：企业微信群、JIRA工单系统、Confluence知识库
- 交接制度：每日工作日志、问题跟踪表、知识沉淀

#### 第二级：专家支持团队（远程+按需驻场）

**团队组成（共8人远程支持）：**

| 专家类型 | 人数 | 资质要求 | 响应时间 | 典型场景 |
|---------|------|---------|---------|---------|
| 架构专家 | 2人 | 10年经验，架构师认证 | 4小时 | 架构升级、性能瓶颈分析 |
| 安全专家 | 1人 | CISP/CISSP认证 | 4小时 | 安全事件、漏洞修复 |
| 数据库专家 | 2人 | OCP/OCM认证 | 4小时 | SQL优化、数据迁移 |
| GIS专家 | 1人 | GIS高级工程师 | 8小时 | 空间分析、地图渲染 |
| BIM专家 | 1人 | BIM工程师 | 8小时 | 模型处理、轻量化 |
| 中间件专家 | 1人 | WebLogic/Tomcat认证 | 8小时 | 中间件调优、集群部署 |

**调度流程：**
1. 现场技术负责人判断问题类型和复杂度
2. 通过企业微信专家群发起支持请求
3. 对应专家4-8小时内远程接入分析
4. 必要时次日驻场（交通费、差旅费由我司承担）
5. 问题解决后输出技术报告和预防建议

【此处插入专家调度流程图】
(Mermaid流程图 - 展示问题升级和专家响应路径)

#### 第三级：厂商支持团队（厂商直连）

针对底层产品问题（数据库Bug、中间件缺陷、安全产品误报等），
直接对接原厂技术支持，缩短问题解决周期。

**合作厂商清单：**
- 数据库：Oracle、达梦、人大金仓（已签技术支持协议）
- 中间件：东方通、金蝶Apusic（年度服务合同）
- 安全：天融信、绿盟（7×24远程支持）

**对接机制：**
- 专家团队判断为产品层问题后，24小时内提交厂商工单
- 厂商工程师远程诊断或现场支持（P1级48小时到场）
- 我司专家全程跟踪，确保问题解决并回归验证

【此处插入三级运维体系交互图】
(Mermaid图表 - 展示三级之间的信息流和升级路径)

#### 完整案例：XX市智慧城管平台运维实践

**项目背景：**
XX市智慧城管平台，合同金额680万元，系统包含GIS+BIM+
物联网+大数据分析，日均处理工单5000+，峰值并发800用户。

**运维挑战：**
- 系统复杂度高，涉及10+子系统集成
- 业务连续性要求高，停机窗口仅凌晨2-4点
- 数据量大，历史数据3TB+，日增量20GB

**三级体系应用：**
- 一级团队（8人驻场）：处理95%日常问题，平均响应5分钟
- 二级专家（6次驻场）：解决GIS性能瓶颈、数据库死锁、架构优化
- 三级厂商（2次介入）：Oracle RAC故障修复、天融信防火墙策略调整

**运维成效：**
- 系统可用性：99.8%（合同要求99.5%）
- 故障MTTR：1.8小时（合同要求4小时）
- 客户满意度：98分（第三方评测）
- 知识沉淀：运维手册120页、故障案例库80+条

### 2.1.2 运维工具平台建设

（继续编写下一个子维度...）

页数标记使用： 在每个文件开头添加隐藏注释：

<!-- TARGET_PAGES: 150 -->
<!-- FILE_ALLOCATION: 35页（总页数150页 × 技术方案权重23%） -->
<!-- 本文档每个评分子维度约2页详述 -->

图表生成规范

所有架构图、流程图、组织图、甘特图等必须按以下格式生成，便于后续自动渲染：

格式模板：

【此处插入XX图】

```mermaid
graph TD
    A[节点1] --> B[节点2]
    B --> C[节点3]

（后续将自动渲染为 PNG 图片）


**图表类型对照表：**

| 图表类型 | Mermaid 语法 | 示例场景 |
|---------|-------------|---------|
| 系统架构图 | `graph TD` + subgraph | 总体架构、分层架构 |
| 组织架构图 | `graph TD` | 团队结构、运维体系 |
| 流程图 | `graph TD` | 业务流程、问题处理流程 |
| 对接架构图 | `graph LR` | 系统集成、数据对接 |
| 甘特图 | `gantt` | 项目进度、实施计划 |
| ER图 | `erDiagram` | 数据库设计 |

**Mermaid 编写要求：**

1. **节点 ID 用英文**，显示文字用中文括号包裹：
   ```mermaid
   A[应用层] --> B[服务层]

使用 subgraph 表达分层/分组关系：

graph TD
    subgraph 展示层
        A[Web前端]
        B[移动端]
    end
    subgraph 服务层
        C[业务服务]
        D[数据服务]
    end

连接线可加标签（简短）：

A -->|数据同步| B
A -.->|异步通知| C

避免特殊字符：标签中避免 () {} [] 等，用全角或空格替代

甘特图格式：

gantt
    title 项目实施进度
    dateFormat YYYY-MM-DD
    section 准备阶段
    需求确认 :done, 2026-04-01, 7d
    环境准备 :active, 2026-04-08, 5d
    section 开发阶段
    功能开发 :2026-04-13, 30d

示例：组织架构图

【此处插入运维服务组织架构图】

```mermaid
graph TD
    subgraph 第一层：现场服务团队
        PM[项目经理1人]
        TL[技术负责人1人]
        DEV[开发工程师3人]
        OPS[运维工程师2人]
        QA[测试工程师1人]
    end

    subgraph 第二层：专家支持团队
        ARCH[架构专家]
        SEC[安全专家]
        DBA[数据库专家]
        GIS[GIS/BIM专家]
    end

    subgraph 第三层：厂商支持团队
        DB[数据库厂商]
        MW[中间件厂商]
        SECP[安全厂商]
    end

    PM --> TL
    TL --> DEV
    TL --> OPS
    TL --> QA
    TL -.->|疑难问题| ARCH
    ARCH -.-> SEC
    ARCH -.-> DBA
    ARCH -.-> GIS
    DBA -.-> DB
    SEC -.-> SECP

（后续将自动渲染为 PNG 图片）


**禁止使用 ASCII 图**：不要生成 `┌─┐ ├─┤` 这种 ASCII 字符图，必须使用 Mermaid 代码块。

#### 4.3 特殊文件处理

- **培训方案**：需包含培训对象、内容、学时、考核方式、培训资料
- **全生命周期成本**：合同期内费用总计必须 = 报价金额（与商务标交叉核对）
- **运维/售后方案**：响应时间、保修期、人员配备需与商务条款一致
- **实施方案/进度计划**：里程碑时间节点需在交付期限内

### 5. 自检清单

编写完成后，逐项检查：

- [ ] 技术响应表条目数 = 采购文件需求条目数（精确匹配）
- [ ] **🆕 响应去重检查**：统计重复响应说明，重复率应 < 10%
- [ ] **🆕 类型匹配检查**：抽查10%条目，确认硬件设备不含"微服务"等软件术语，性能指标包含具体数值
- [ ] 每个写作型评分因素都有对应输出文件
- [ ] 每个评分子维度都有独立章节（无遗漏维度）
- [ ] 所有▲标注功能有截图占位 + 盖章标注
- [ ] 全生命周期成本合同期费用 = 报价金额
- [ ] 响应说明无空泛描述（逐条抽检）
- [ ] 进度计划在交付期限内
- [ ] 质保期/维护期与商务条款一致

---

### 修复模式工作流程

当进入修复模式时，执行以下步骤替代步骤 1-5：

#### R1. 读取反馈来源

读取 `响应文件/核对报告.md`（或用户指定的反馈）：
- 提取所有 🔴 必改问题
- 提取所有 🟡 建议修改问题
- 忽略 🔵 提醒（仅供参考，不自动处理）
- 按操作类型分组：
  - **新建文件**：文件缺失类问题
  - **编辑文件**：内容错误、一致性问题
  - **信息确认**：需用户提供数据才能修复的问题

#### R2. 读取分析报告

同步骤 1 — 从分析报告中提取完整项目数据。
新建文件时需要分析报告作为数据源，编辑文件时需要作为正确性基准。

#### R3. 逐项修复

按 🔴 → 🟡 优先级顺序处理：

**缺失文件：**
- 按步骤 3 中对应附件类型的编写策略创建新文件
- 文件命名、格式、签章区域等遵循现有文件的约定
- 读取已有文件确认公司名称、报价金额等关键数据，确保一致性

**内容修正：**
- 读取目标文件 → 定位问题位置 → 编辑修正
- 修正后检查是否引起连锁不一致（如金额修改需同步多个文件）

**一致性修复：**
- 确定正确值（以分析报告为准）
- 跨文件搜索所有出现位置，逐一修正

**需用户确认的问题：**
- 汇总列出，向用户确认后再修复
- 绝不自行猜测用户意图（如报价金额、业绩信息）

**技术标常见修复场景：**

| 问题类型 | 修复方式 |
|---------|---------|
| 评分子维度缺章节 | 从分析报告提取缺失子维度，在对应文件中添加章节 |
| 技术响应表条目缺失 | 从原始Word重新提取缺失条目，补入响应表 |
| ▲截图占位缺失 | 在对应条目添加截图占位+盖章标注 |
| 响应说明过空泛 | 读取具体条目，重写为≥3行具体实现描述 |
| 全生命周期金额不一致 | 读取报价文件获取正确金额，修正成本表 |
| 进度超出交付期限 | 读取分析报告交付期，重新排布里程碑 |

#### R4. 修复后验证

- 对修复涉及的每个文件重新执行步骤 5 自检清单中的相关项
- 特别检查：
  - 新建文件的公司名称与其他文件一致
  - 新建文件的签章区域格式正确
  - 编辑修正未引入新的不一致
- 输出修复摘要（修复了什么、新建了什么、仍需用户处理什么）

## 编写方法论（通用于任何项目）

### 扣分制评分项
**章节结构完整无遗漏 > 内容深度。**
先确保每个子维度都有独立章节，再充实内容。缺章节 = 该维度0分，内容薄弱最多扣部分分。

### 客观分评分项
如业绩计数、证书计数、人员配备等 → 由商务标（bid-commercial-proposal）处理，技术标不编写。

### 技术响应表
通常是技术标中分值最高的单项。必须逐条响应，零遗漏。
每条响应说明≥3行具体实现描述，禁止空泛语言。

### ▲功能截图
必须有占位符 `【此处插入XX功能截图】` + 标注 `（截图需加盖公章）`。

### 图表处理

所有图表必须生成为：**占位符 + Mermaid 代码块**。

格式：
```markdown
【此处插入XX图】

```mermaid
(Mermaid 代码)

（后续将自动渲染为 PNG 图片）


禁止直接生成 ASCII 字符图（`┌─┐ ├─┤` 等）。

Markdown 表格用于呈现结构化数据（如进度计划表、模块列表、对比表）。

### 禁止事项
- 空泛描述（"支持该功能""满足要求""提供优质服务"）
- 复制粘贴采购文件需求原文作为响应说明
- 大段无关理论背景/行业趋势凑篇幅
- 编造不存在的功能或未经确认的技术方案

## 常见错误类型

| 类型 | 后果 | 预防 |
|------|------|------|
| **🆕 响应模板化严重** | 专家一眼识破，技术响应性评分低 | 先分类识别需求类型，按类型针对性编写 |
| **🆕 硬件需求软件回答** | 答非所问，该条目0分 | 硬件设备禁止出现"微服务""API"等软件术语 |
| **🆕 性能指标缺数值** | 未实质响应，可能扣分 | 性能指标必须引用具体数值和单位 |
| 评分子维度缺章节 | 该子维度0分 | 从评分规则提取子维度列表，逐个建章节 |
| 技术响应表漏条目 | ▲扣2分/条，其他扣1分 | 编写后核对条目数与原文一致 |
| ▲截图未标注盖章 | 扣2分/条 | 编写时逐条检查▲标注 |
| 响应说明过空泛 | 评委视为瑕疵，可能扣分 | 每条≥3行具体实现描述 |
| 全生命周期金额与报价不一致 | 扣分+审查风险 | 与商务标交叉核对报价金额 |
| 进度超出交付期限 | 不响应商务条款 | 里程碑排入交付期限内 |
| 培训方案缺考核方式 | 评分维度不完整 | 从评分规则逐条检查子维度 |

## 输出格式

所有文件输出到 `响应文件/` 目录，Markdown 格式：
- 标题使用 `#` `##` `###` 层级
- 表格使用 Markdown 表格语法
- 图片占位：`【此处插入XXX图】`
- 截图占位：`【此处插入XX功能截图】（截图需加盖公章）`
- 签章标记：`（盖章）` `（签字）`
- 每个文件开头：`# 附件N：标题`

## 自动模式

当被 bid-manager 调度时（上下文中包含 `AUTO_MODE=true`），本 skill 进入自动模式：

- **页数确定**：步骤 1.6 不询问用户
  - 优先读取 `pipeline_progress.json` 中的 `tech_proposal_pages` 字段（用户在bid-evaluation阶段设置）
  - 如未设置，按预算金额自动计算推荐页数
- **跳过文件规划确认**：步骤 2 中不向用户展示规划表等待确认，直接按分析报告生成文件清单并开始编写
- **跳过中间进度询问**：编写过程中不暂停询问用户意见
- **保留自检**：步骤 5 自检清单仍然执行，发现问题自动修复而非询问用户

## 完成状态

编写完成后，输出以下结构化状态摘要：

--- BID-TECH-PROPOSAL COMPLETE --- 目标页数: {N}页实际页数: {M}页（预估）预算金额: {X}万元输出文件数: {N} 文件清单: {file1.md, file2.md, ...} 技术响应表条目数: {N} ▲截图占位数: {N} 评分子维度覆盖: {已覆盖}/{总数} 输出目录: 响应文件/ 状态: SUCCESS --- END ---

name

bid-tech-proposal

description

技术标编写

核心原则

数据驱动，不写死 — 每个项目的评分标准、技术需求、评分子维度都不同。本 skill 的一切编写行为均以分析报告为数据源，动态适配当前项目。

🚨 严禁事项（绝对禁止，不可违反）

禁止 1：绝不允许编写 Python/Node.js 脚本批量生成响应内容

禁止行为：

❌ 创建 generate_*.py、regenerate_*.py、improve_*.py 等批处理脚本
❌ 编写循环遍历需求列表的自动化脚本
❌ 使用脚本读取 JSON/CSV 数据批量生成响应表

问题根源： 脚本批量生成会导致退化为统一模板响应（如硬件设备 → "微服务架构"），丧失需求分类能力，响应重复率高达 95%。

禁止 2：禁止跳过需求分类识别步骤

必须先执行"步骤 3.2 需求分类识别"，输出分类统计后，再按类型编写响应。不得直接进入文件生成环节。

⚠️ 文件生成规范（防止覆盖问题）— 必须严格遵守

🚨 关键约束 1 - 禁止使用 write 工具多次写入同一文件：

Write 工具是覆盖模式，多次调用会丢失前面的内容。必须使用以下方式之一：

方案 A：使用 bash cat 分段 append（推荐）

# 第一段 - 创建文件
cat > "响应文件/06-维护支持服务方案.md" << 'EOF'
# 附件6：维护支持服务方案

## 一、运维体系完善性方案
[第一部分内容，尽可能多但不超过单次输出限制]
EOF

# 第二段 - append 追加
cat >> "响应文件/06-维护支持服务方案.md" << 'EOF'

## 二、响应机制有效性方案
[第二部分内容]
EOF

# 第三段 - append 追加
cat >> "响应文件/06-维护支持服务方案.md" << 'EOF'

## 三、知识转移充分性方案
[第三部分内容]
EOF

# 后续段落继续 append...

关键点：

第一次用 > 创建文件
后续用 >> append 追加
每段内容尽量写多，但不超过模型单次输出限制
段与段之间自然衔接

方案 B：拆分成多个独立文件

如果内容过长，可拆分成独立文件：

06-1-运维体系完善性方案.md
06-2-响应机制有效性方案.md
06-3-知识转移充分性方案.md

方案 C：修复模式 - 局部修改

如果文件已存在且只需修改部分内容：

# 1. 读取文件
read "响应文件/06-维护支持服务方案.md"

# 2. 使用 edit 工具局部替换
edit old_text new_text

❌ 严禁的错误做法

# 错误示例 1：多次 write 同一文件
write "file.md" "第一部分"  # ✅ 第一次
write "file.md" "第二部分"  # ❌ 覆盖了第一部分！

# 错误示例 2：read + write 尝试追加
read "file.md"
write "file.md" "旧内容 + 新内容"  # ❌ 容易出错，且效率低

🚨 关键约束 2 - 禁止在 Markdown 中使用   等 HTML 实体：

生成的 Markdown 文件会被转换为 Word 文档，HTML 实体会显示为纯文本，破坏排版。

✅ 正确做法：

# 项目概况

本项目位于广州市，预算 450 万元。

投标人名称：【投标人全称】

❌ 错误做法：

# 项目概况

&nbsp;

本项目位于广州市，预算 450 万元。

&nbsp;

投标人名称：&nbsp;【投标人全称】

规则：

空行直接留空即可，不要用  
段落缩进通过 Markdown 自然换行处理，不要手动添加空格实体
如果需要强调空白，使用空行分隔（连续两个换行符）

工作模式

本 skill 支持两种工作模式，根据上下文自动判定：

创建模式（默认）

触发： 用户要求编写技术标，且 响应文件/ 目录为空或不存在
行为： 执行完整工作流程（步骤 1-5）

修复模式

触发： 以下任一条件成立：
1. 用户明确要求修复/修补/补充文件
2. 用户提及核对报告、质检问题、bid-assembly 反馈
3. 响应文件/核对报告.md 存在且用户要求处理其中的问题
行为： 执行修复工作流程（步骤 R1-R4）

工作流程

1. 读取分析报告与核实报告 — 确定技术标编写范围

1.1 读取数据源

从当前项目工作目录中读取：

分析报告.md（必须）— 主要数据源
核实报告.md（如存在）— 用于交叉验证分析报告的准确性

如核实报告存在，先检查其中的 ❌ 错误项和 ⚠️ 存疑项。如核实报告对分析报告中的评分标准、文件归属等有修正，以核实报告修正后的版本为准。

1.2 提取技术归属附件清单（编写目标）

从分析报告的"投标文件组成"章节中，筛选**"编写归属"为"技术标"的所有文件。这些文件构成本 skill 的完整编写范围**。

提取方法：

找到分析报告中"投标文件组成"下的表格
读取每行的"编写归属"列
筛选出所有"编写归属"="技术标"的文件
记录每个文件的：序号、文件名称、是否必须（★）、对应评分项

⚠️ 严格边界：只编写归属为"技术标"的文件。归属为"商务标"的文件由 bid-commercial-proposal skill 负责，本 skill 不得编写。

1.3 提取技术评分项

根据 1.2 中筛选出的技术归属文件，从分析报告的"评分标准"章节中提取对应的评分因素：

名称：评分因素名称
分值：该项总分
评分子维度：评分规则中提及的各个评审角度（如"包括XX、YY、ZZ三个方面"）
扣分规则：扣分制的具体扣分标准（如"缺少一项扣N分"）
评分方式：扣分制 / 比较打分制 / 固定分档
子系统/模块清单及其功能条目
▲标注条目（截图+盖章要求）
功能条目总数（用于后续核对）

1.5 其他相关信息

项目名称、采购编号（用于文件标题）
交付期、质保期（可能影响技术方案中的进度计划和服务方案）
预算金额（全生命周期成本需与此一致）

将以上信息记录为内部数据结构，后续步骤引用。

1.6 确定编写页数要求

⚠️ 关键：标书篇幅应与项目规模匹配

技术标的页数应与项目预算金额成正比，确保内容深度与项目规模相称。

页数计算规则（基于标的金额）：

从分析报告中提取预算金额，按以下规则计算目标页数：

标的金额范围	页数计算规则	示例
< 100万	1万元 = 1页，最少50页	80万 → 80页
100-200万	固定150页左右	150万 → 150页
200-500万	固定250页	350万 → 250页
≥ 500万	1万元 = 1页	600万 → 600页

步骤：

从分析报告提取预算金额：

grep -A 2 "预算金额\|项目金额\|合同总价" 分析报告.md

计算推荐页数：根据上表规则自动计算

询问用户确认（仅在非AUTO_MODE时）：

如果上下文中没有 AUTO_MODE=true，向用户提问：

📋 技术标编写页数规划

项目预算金额：{X} 万元
推荐编写页数：{N} 页（基于1万元=1页原则）
技术评分维度：{M} 个

是否接受推荐页数？
✅ 接受 - 直接回复"是"或"确认"
✏️ 调整 - 请输入您期望的页数（如"120页"或"重点详写运维和培训方案"）

您的选择：

处理用户输入：
- 用户回复"是"/"确认"/"OK" → 使用推荐页数
- 用户输入具体数字（如"120"） → 使用用户指定页数
- 用户描述特殊要求 → 记录到特殊要求字段，保持推荐页数
- 无明确输入 → 使用推荐页数（默认）
AUTO_MODE时的处理：
- 如果 AUTO_MODE=true（由bid-manager调度）：
  - 检查 pipeline_progress.json 中是否有 tech_proposal_pages 字段
  - 如果有 → 使用用户在bid-evaluation阶段设置的页数
  - 如果没有 → 使用推荐页数
- 不询问用户，直接进入步骤2

保存配置：将确定的页数和要求保存到 响应文件/编写配置.txt：

TARGET_PAGES=150
BUDGET_AMOUNT=150万元
SPECIAL_REQUIREMENTS=重点详写运维方案和培训方案
CALCULATED_AT=2026-04-29

页数分配策略（动态两阶段分配）：

目标页数确定后，采用两阶段分配策略：

阶段1：确定技术响应表页数（基于实际需求条目数）

技术响应表的大小由招标文件需求条目数量决定，与总页数无直接关系：

需求条目数	预估响应表页数	说明
< 50条	20-30页	简单需求，快速响应
50-100条	30-50页	标准规模
100-200条	50-80页	中大型项目，详细需求
> 200条	80-120页	大型复杂项目

计算方法：从分析报告读取"技术需求总数"，按以下公式估算：

响应表页数 ≈ 需求条目数 × 0.4（每条需求平均0.4页）
精简型（≤80页总页数）：系数 0.3
标准型（80-180页）：系数 0.4
详尽型（≥180页）：系数 0.5

阶段2：剩余页数按比例分配给其他文件

剩余页数 = 目标总页数 - 响应表预估页数

剩余页数按以下比例分配：

总体技术方案：35%
培训方案：12%
运维方案：20%
实施方案：18%
其他附件：15%

示例1：150页技术标，120条需求

响应表：120条 × 0.4 = 48页
剩余：150 - 48 = 102页
分配：
- 技术响应表：48页（实际需求驱动）
- 总体技术方案：102 × 35% = 36页
- 培训方案：102 × 12% = 12页
- 运维方案：102 × 20% = 20页
- 实施方案：102 × 18% = 18页
- 其他附件：102 × 15% = 16页

示例2：80页技术标，200条需求

响应表：200条 × 0.3 = 60页（精简型系数）
剩余：80 - 60 = 20页
分配：
- 技术响应表：60页（需求多，占比大）
- 总体技术方案：20 × 35% = 7页
- 培训方案：20 × 12% = 2页（适当精简）
- 运维方案：20 × 20% = 4页
- 实施方案：20 × 18% = 4页
- 其他附件：20 × 15% = 3页

特殊情况处理：

响应表超出总页数：如200条需求 × 0.4 = 80页，但总页数只有70页

优先保证响应表完整性（必须逐条响应，不能省略）
响应表仍按需求条目数编写（80页）
其他文件适度精简，可能略超总页数

在步骤1.6向用户说明：

⚠️ 提示：根据招标文件需求条目数（200条），技术响应表
预计需要80页。建议将总页数调整为100页以上，以便为其他
技术方案预留足够篇幅。当前70页规划可能导致其他文件过于精简。

是否调整总页数？[输入新页数或回复"保持"]

需求条目数未知：如分析报告未统计需求总数
- 默认按总页数的40%分配给响应表
- 在编写响应表时（步骤3）根据实际条目数动态调整

后续步骤的页数控制：

保存到配置文件：

将分配结果保存到 响应文件/编写配置.txt：

TARGET_PAGES=150
BUDGET_AMOUNT=150万元
REQUIREMENT_COUNT=120
RESPONSE_TABLE_PAGES=48
REMAINING_PAGES=102
TECH_PROPOSAL_PAGES=36
TRAINING_PAGES=12
OPERATION_PAGES=20
IMPLEMENTATION_PAGES=18
OTHER_PAGES=16

2. 规划文件清单 — 根据技术归属附件动态生成

根据步骤 1.2 中筛选出的技术归属附件清单，动态规划需编写的文件：

每个技术归属附件 → 对应一个输出文件
技术服务响应表（如评分标准中存在此项）→ 独立文件，通常是技术标中分值最高的单项
文件名格式：NN-附件名称.md（编号接续商务标附件）
只编写步骤 1.2 筛选出的技术归属文件，不编写商务归属的附件

输出文件规划表，向用户确认：

文件名	对应评分项	分值	备注
XX-技术服务响应表.md	技术服务响应	N分	逐条响应，分值最高
XX-总体技术方案.md	技术方案	N分	含子维度A/B/C
XX-培训方案.md	培训方案	N分	技术性写作
...	...	...	...

3. 编写技术服务响应表（如评分标准中存在此项）

技术服务响应表通常是技术标分值最高的单项，必须最先、最仔细地编写。

3.1 提取原始需求表格

使用 python-docx 从原始 Word 采购文件中提取完整技术需求表格
保留表格的原始结构（列名、行数、子系统分类）
绝不可概括、合并或遗漏任何条目

3.2 逐条编写响应（基于常识判断）

核心原则： 响应内容必须与需求类型匹配。这是基本常识：

硬件设备（电磁炉、洗碗机、摄像头）→ 回答物理参数（尺寸、功率、材质）
软件功能（系统管理、查询统计）→ 回答功能实现
绝不能混淆：硬件设备不能回答"微服务架构"、"API接口"等软件术语

🚨 严格禁止的错误：

❌ 错误示例 1：
需求："外形尺寸：800×800×800mm，功率15KW"
响应："采用微服务架构设计，前后端分离..."  ← 硬件需求用软件术语回答

❌ 错误示例 2：
需求："搭配取筷器使用"
响应："采用Vue3+TypeScript技术栈..."  ← 硬件配件用软件技术回答

✅ 正确示例：
需求："外形尺寸：800×800×800mm，功率15KW"
响应："完全响应。外形尺寸800×800×800mm，功率15KW。"

3.3 编写响应表

对需求表中每一条，编写对应响应行：

序号	子系统	功能模块	需求内容	是否▲	响应	响应说明
原文	原文	原文	原文引用	是/否	完全响应	≥3行具体描述

表格填写规范：

需求内容列：直接引用采购文件原文，不改写
响应列：统一填写"完全响应"
响应说明列：简洁对标需求中的关键参数，格式如下：

响应说明编写规则（核心 + 页数控制）：

读取 响应文件/编写配置.txt 中的 TARGET_PAGES 值，根据技术标总页数动态调整响应说明详细程度：

1. 精简型（≤ 80页）- 参数复述为主：

格式："完全响应。" + 关键参数直接重复
长度：1句话（20-50字）
示例：

需求："外形尺寸：800×800×800mm，功率15KW，电压380V"
响应说明："完全响应。外形尺寸800×800×800mm，功率15KW，电压380V。"

需求："支持卡、码、脸三种识别扣费方式"
响应说明："完全响应。支持卡、码、脸三种识别扣费方式。"

2. 标准型（80-180页）- 参数+简要实现说明：

格式："完全响应。" + 关键参数重复 + 1-2句实现方式
长度：2-3句话（50-120字）
示例：

需求："外形尺寸：800×800×800mm，功率15KW，电压380V"
响应说明："完全响应。外形尺寸800×800×800mm，功率15KW，电压380V。
采用优质不锈钢材质，通过国家3C认证，满足商用厨房使用要求。"

需求："支持卡、码、脸三种识别扣费方式"
响应说明："完全响应。支持IC卡、二维码、人脸识别三种身份识别方式。
采用多模态识别技术，识别速度<0.5秒，误识率<0.1%，适应不同用户场景。"

需求："具备数据统计分析功能"
响应说明："完全响应。提供多维度数据统计分析功能，包括实时统计、
历史趋势分析、对比分析等。支持自定义报表生成，数据可导出Excel格式。"

3. 详尽型（≥ 180页）- 参数+实现机制+技术细节：

格式："完全响应。" + 关键参数 + 实现方式 + 技术架构 + 性能指标
长度：3-5句话（120-250字）
示例：

需求："外形尺寸：800×800×800mm，功率15KW，电压380V"
响应说明："完全响应。外形尺寸800×800×800mm，功率15KW，电压380V。
采用304食品级不锈钢材质，整机一体成型无焊接，内胆采用进口不锈钢板材，
耐腐蚀性强。加热系统采用电磁感应技术，热效率≥90%，较传统电阻加热
节能30%以上。通过国家3C认证、ISO9001质量体系认证，符合GB4706商用
电器安全标准。"

需求："支持卡、码、脸三种识别扣费方式"
响应说明："完全响应。支持IC卡（Mifare One）、二维码（支持微信/支付宝）、
人脸识别（基于深度学习算法）三种身份识别方式。IC卡读卡距离3-5cm，
响应时间<100ms；二维码采用高速扫描模组，识别速度<0.3秒，支持污损码
识别；人脸识别采用3D活体检测技术，误识率<0.1%，支持戴口罩识别。
三种方式可灵活组合使用，满足不同用户习惯和场景需求。"

需求："具备数据统计分析功能"
响应说明："完全响应。提供多维度数据统计分析功能模块，基于时序数据库
(InfluxDB) 和实时计算引擎(Flink) 实现。支持实时统计（分钟级延迟）、
历史趋势分析（支持任意时间段对比）、多维度交叉分析（按部门/人员/设备
等维度）。内置20+预设报表模板，支持拖拽式自定义报表设计器，可配置
定时任务自动生成日/周/月报。数据可导出Excel、PDF、CSV格式，支持
通过RESTful API对接第三方BI系统。查询响应时间<2秒（千万级数据量）。"

关键原则（所有页数档位通用）：

✅ 第一句必须是"完全响应" + 核心参数重复（确保基础得分）
✅ 根据需求类型匹配响应内容（硬件→物理参数，软件→功能实现）
❌ 禁止硬件需求添加"微服务架构"、"前后端分离"等软件术语
❌ 禁止空泛承诺（"提供原厂正品"、"性能稳定可靠"）
❌ 禁止不同类型需求使用完全相同的模板响应

特殊情况（所有页数档位通用）：

▲标注项：响应说明后额外加一行 【此处插入XX功能截图】（截图需加盖公章）
需求无具体参数：如"搭配取筷器使用"，响应说明根据页数档位调整长度
需求含多项参数：全部参数必须在第一句话中列出

3.4 编写后质量检查

🚨 强制完整性检查（第一优先级）：

在认为响应表编写完成前，必须先执行以下检查：

# 1. 统计已完成的响应条目数
COMPLETED=$(grep -c "| 完全响应 |" 响应文件/01*.md)
echo "已完成响应条目数: $COMPLETED"

# 2. 查看分析报告中的原始需求数
grep -A 5 "技术需求总数\|需求条目\|技术参数总数" 分析报告.md

判断标准：

如果 $COMPLETED < 原始需求总数，必须继续编写，不得结束任务
只有当已完成条目数 = 原始需求总数时，才能进入后续检查

常见情况：

原始需求通常有数百条（包括软件功能、硬件设备、IoT设备等）
如果只完成了几十条就认为结束，说明遗漏了大部分需求
必须返回继续编写，直到覆盖全部需求

基础检查：

统计响应表条目数，与原始需求表条目数比对（必须相等）
确认每个▲条目都有截图/报告占位标注 + 盖章标注
确认无空响应行、无空泛描述

🆕 质量检查（新增）：

响应去重检查：

# 统计响应说明重复情况
grep -oP '\| [^|]+ \| [^|]+ \| [^|]+ \| [^|]+ \| [^|]+ \| [^|]+ \| \K[^|]+' 响应文件/*.md | sort | uniq -c | sort -rn | head -10

如果同一响应说明出现 > 10 次，视为异常
重复率 = 重复条目数 / 总条目数，应 < 10%

类型匹配检查（抽查10%条目）：
- 硬件设备类需求的响应中不应出现"微服务""API接口""前后端分离"等软件术语
- 性能指标类需求的响应中必须包含具体数值
- 标准认证类需求必须有证书占位符

▲标注完整性检查：

# 统计▲标注数量与占位符数量
echo "▲标注数: $(grep -c '| 是 |' 响应文件/*.md)"
echo "占位符数: $(grep -c '【此处插入.*】' 响应文件/*.md)"

两者数量必须相等

4. 逐个编写其他技术文档

对步骤2中规划的每个文件，按以下方法编写：

4.1 评分维度逆向设计（核心方法）

从分析报告读取该评分因素的完整评分规则原文
从规则中提取子维度列表：
- 寻找类似"包括XX、YY、ZZ"、"从以下N个方面评审"、"评审内容包含"等表述
- 每个子维度 → 创建一个独立章节

在文件开头添加编写指导注释（不进入最终文档）：

<!-- 评分因素：XXX | 总分：N分 | 评分方式：扣分制/比较打分 -->
<!-- 子维度：A(n分)、B(n分)、C(n分) -->
<!-- 扣分规则：缺少一项扣X分 -->

为每个子维度编写实质内容

4.2 章节内容要求（根据目标页数动态调整）

通用要求（所有页数档位）：

具体方案：描述做什么、怎么做、用什么技术/工具
数据支撑：引用具体参数、指标、标准
禁止：空泛承诺（"我司将提供优质服务"）、无内容的大段理论背景

页数档位自动判定：

从编写配置中读取 TARGET_PAGES，按以下规则判定当前文件的详细程度：

技术标总页数	单个评分子维度页数	内容详细程度	示例项目规模
≤ 80页	0.5-1页/子维度	精简型	< 80万小项目
80-180页	1-2页/子维度	标准型	80-200万中型项目
≥ 180页	2-4页/子维度	详尽型	≥ 200万大型项目

精简型（≤ 80页）- 快速覆盖评分点：

每个评分子维度：1-2个段落（200-400字）
图表：仅核心架构图/流程图（每个子维度0-1个图）
案例：不展开案例细节，仅提"参考类似项目经验"
技术细节：列出关键技术栈，不深入实现机制

示例：

## 2.1 运维体系完善性

建立三级运维体系：现场服务团队、专家支持团队、厂商支持团队。
现场团队包含项目经理1人、技术负责人1人、工程师6人，负责日常
运维和问题响应。专家团队提供架构、安全、数据库等专项支持。

【此处插入运维组织架构图】
(Mermaid图表)

标准型（80-180页）- 深度与篇幅平衡：

每个评分子维度：2-4个段落（400-800字）
图表：架构图 + 流程图（每个子维度1-2个图）
案例：简短案例描述（2-3句话，不超过100字）
技术细节：关键技术 + 简要说明工作原理

示例：

## 2.1 运维体系完善性

### 2.1.1 三级运维组织架构

建立三级运维体系，确保问题分级响应和专业支撑：

**第一级：现场服务团队**（驻场7人）
- 项目经理1人：负责整体协调和客户沟通
- 技术负责人1人：负责技术决策和疑难问题升级
- 开发工程师3人：负责功能优化和问题修复
- 运维工程师2人：负责日常巡检和系统监控
- 测试工程师1人：负责变更验证和回归测试

**第二级：专家支持团队**（远程+驻场）
由架构专家、安全专家、数据库专家等组成，处理超出现场
团队能力范围的复杂技术问题，响应时间4小时内。

**第三级：厂商支持团队**（厂商直连）
对接数据库厂商、中间件厂商、安全厂商技术支持，解决
底层产品缺陷或需厂商配合的问题，响应时间24小时内。

【此处插入运维组织架构图】
(Mermaid图表 - 展示三级结构和上报路径)

参考案例：我司在XX市智慧城市项目中采用类似三级体系，
实现故障平均修复时间(MTTR)控制在2小时以内。

详尽型（≥ 180页）- 深入展开技术方案：

每个评分子维度：4-6个段落（800-1500字）
图表：多维度图表（架构图 + 流程图 + 数据流图，每个子维度2-3个图）
案例：完整案例（项目背景、解决方案、成效数据，200-300字）
技术细节：深入技术实现、配置参数、优化策略
对比分析：多种技术方案对比、选型依据

示例：

## 2.1 运维体系完善性

### 2.1.1 三级运维组织架构设计

#### 架构设计理念

基于ITIL运维框架和DevOps最佳实践，结合本项目特点，
设计三级分层运维体系。该体系既保证日常问题快速响应，
又能调动专家资源处理复杂技术挑战，同时通过厂商支持
通道确保底层产品问题得到及时解决。

#### 第一级：现场服务团队（驻场运维）

**团队组成（共7人驻场）：**
- **项目经理1人**：PMP认证，5年以上政府项目管理经验
  - 职责：整体协调、客户沟通、SLA考核、资源调配
  - 工作机制：每日晨会、周报、月度服务报告

- **技术负责人1人**：系统架构师，8年以上开发经验
  - 职责：技术决策、方案评审、疑难问题升级判断
  - 权限：二级专家团队调度权、紧急变更审批权

- **开发工程师3人**：Java/前端/GIS各1人
  - 职责：功能优化、需求变更开发、Bug修复、代码Review
  - 技能矩阵：Spring Boot、Vue3、GIS空间分析

- **运维工程师2人**：Linux/数据库运维各1人
  - 职责：日常巡检、性能监控、备份恢复、应急演练
  - 监控范围：CPU/内存/磁盘、应用服务、数据库、网络

- **测试工程师1人**：功能测试+性能测试
  - 职责：变更验证、回归测试、用户验收支持
  - 工具：JMeter性能测试、Selenium自动化测试

【此处插入现场服务团队组织架构图】
(Mermaid图表 - 展示人员角色和汇报关系)

**工作机制：**
- 驻场时间：工作日8:30-17:30现场值守
- 响应机制：5分钟内响应、30分钟内到场（紧急问题）
- 协作工具：企业微信群、JIRA工单系统、Confluence知识库
- 交接制度：每日工作日志、问题跟踪表、知识沉淀

#### 第二级：专家支持团队（远程+按需驻场）

**团队组成（共8人远程支持）：**

| 专家类型 | 人数 | 资质要求 | 响应时间 | 典型场景 |
|---------|------|---------|---------|---------|
| 架构专家 | 2人 | 10年经验，架构师认证 | 4小时 | 架构升级、性能瓶颈分析 |
| 安全专家 | 1人 | CISP/CISSP认证 | 4小时 | 安全事件、漏洞修复 |
| 数据库专家 | 2人 | OCP/OCM认证 | 4小时 | SQL优化、数据迁移 |
| GIS专家 | 1人 | GIS高级工程师 | 8小时 | 空间分析、地图渲染 |
| BIM专家 | 1人 | BIM工程师 | 8小时 | 模型处理、轻量化 |
| 中间件专家 | 1人 | WebLogic/Tomcat认证 | 8小时 | 中间件调优、集群部署 |

**调度流程：**
1. 现场技术负责人判断问题类型和复杂度
2. 通过企业微信专家群发起支持请求
3. 对应专家4-8小时内远程接入分析
4. 必要时次日驻场（交通费、差旅费由我司承担）
5. 问题解决后输出技术报告和预防建议

【此处插入专家调度流程图】
(Mermaid流程图 - 展示问题升级和专家响应路径)

#### 第三级：厂商支持团队（厂商直连）

针对底层产品问题（数据库Bug、中间件缺陷、安全产品误报等），
直接对接原厂技术支持，缩短问题解决周期。

**合作厂商清单：**
- 数据库：Oracle、达梦、人大金仓（已签技术支持协议）
- 中间件：东方通、金蝶Apusic（年度服务合同）
- 安全：天融信、绿盟（7×24远程支持）

**对接机制：**
- 专家团队判断为产品层问题后，24小时内提交厂商工单
- 厂商工程师远程诊断或现场支持（P1级48小时到场）
- 我司专家全程跟踪，确保问题解决并回归验证

【此处插入三级运维体系交互图】
(Mermaid图表 - 展示三级之间的信息流和升级路径)

#### 完整案例：XX市智慧城管平台运维实践

**项目背景：**
XX市智慧城管平台，合同金额680万元，系统包含GIS+BIM+
物联网+大数据分析，日均处理工单5000+，峰值并发800用户。

**运维挑战：**
- 系统复杂度高，涉及10+子系统集成
- 业务连续性要求高，停机窗口仅凌晨2-4点
- 数据量大，历史数据3TB+，日增量20GB

**三级体系应用：**
- 一级团队（8人驻场）：处理95%日常问题，平均响应5分钟
- 二级专家（6次驻场）：解决GIS性能瓶颈、数据库死锁、架构优化
- 三级厂商（2次介入）：Oracle RAC故障修复、天融信防火墙策略调整

**运维成效：**
- 系统可用性：99.8%（合同要求99.5%）
- 故障MTTR：1.8小时（合同要求4小时）
- 客户满意度：98分（第三方评测）
- 知识沉淀：运维手册120页、故障案例库80+条

### 2.1.2 运维工具平台建设

（继续编写下一个子维度...）

页数标记使用： 在每个文件开头添加隐藏注释：

<!-- TARGET_PAGES: 150 -->
<!-- FILE_ALLOCATION: 35页（总页数150页 × 技术方案权重23%） -->
<!-- 本文档每个评分子维度约2页详述 -->

图表生成规范

所有架构图、流程图、组织图、甘特图等必须按以下格式生成，便于后续自动渲染：

格式模板：

【此处插入XX图】

```mermaid
graph TD
    A[节点1] --> B[节点2]
    B --> C[节点3]

（后续将自动渲染为 PNG 图片）


**图表类型对照表：**

| 图表类型 | Mermaid 语法 | 示例场景 |
|---------|-------------|---------|
| 系统架构图 | `graph TD` + subgraph | 总体架构、分层架构 |
| 组织架构图 | `graph TD` | 团队结构、运维体系 |
| 流程图 | `graph TD` | 业务流程、问题处理流程 |
| 对接架构图 | `graph LR` | 系统集成、数据对接 |
| 甘特图 | `gantt` | 项目进度、实施计划 |
| ER图 | `erDiagram` | 数据库设计 |

**Mermaid 编写要求：**

1. **节点 ID 用英文**，显示文字用中文括号包裹：
   ```mermaid
   A[应用层] --> B[服务层]

使用 subgraph 表达分层/分组关系：

graph TD
    subgraph 展示层
        A[Web前端]
        B[移动端]
    end
    subgraph 服务层
        C[业务服务]
        D[数据服务]
    end

连接线可加标签（简短）：

A -->|数据同步| B
A -.->|异步通知| C

避免特殊字符：标签中避免 () {} [] 等，用全角或空格替代

甘特图格式：

gantt
    title 项目实施进度
    dateFormat YYYY-MM-DD
    section 准备阶段
    需求确认 :done, 2026-04-01, 7d
    环境准备 :active, 2026-04-08, 5d
    section 开发阶段
    功能开发 :2026-04-13, 30d

示例：组织架构图

【此处插入运维服务组织架构图】

```mermaid
graph TD
    subgraph 第一层：现场服务团队
        PM[项目经理1人]
        TL[技术负责人1人]
        DEV[开发工程师3人]
        OPS[运维工程师2人]
        QA[测试工程师1人]
    end

    subgraph 第二层：专家支持团队
        ARCH[架构专家]
        SEC[安全专家]
        DBA[数据库专家]
        GIS[GIS/BIM专家]
    end

    subgraph 第三层：厂商支持团队
        DB[数据库厂商]
        MW[中间件厂商]
        SECP[安全厂商]
    end

    PM --> TL
    TL --> DEV
    TL --> OPS
    TL --> QA
    TL -.->|疑难问题| ARCH
    ARCH -.-> SEC
    ARCH -.-> DBA
    ARCH -.-> GIS
    DBA -.-> DB
    SEC -.-> SECP

（后续将自动渲染为 PNG 图片）


**禁止使用 ASCII 图**：不要生成 `┌─┐ ├─┤` 这种 ASCII 字符图，必须使用 Mermaid 代码块。

#### 4.3 特殊文件处理

- **培训方案**：需包含培训对象、内容、学时、考核方式、培训资料
- **全生命周期成本**：合同期内费用总计必须 = 报价金额（与商务标交叉核对）
- **运维/售后方案**：响应时间、保修期、人员配备需与商务条款一致
- **实施方案/进度计划**：里程碑时间节点需在交付期限内

### 5. 自检清单

编写完成后，逐项检查：

- [ ] 技术响应表条目数 = 采购文件需求条目数（精确匹配）
- [ ] **🆕 响应去重检查**：统计重复响应说明，重复率应 < 10%
- [ ] **🆕 类型匹配检查**：抽查10%条目，确认硬件设备不含"微服务"等软件术语，性能指标包含具体数值
- [ ] 每个写作型评分因素都有对应输出文件
- [ ] 每个评分子维度都有独立章节（无遗漏维度）
- [ ] 所有▲标注功能有截图占位 + 盖章标注
- [ ] 全生命周期成本合同期费用 = 报价金额
- [ ] 响应说明无空泛描述（逐条抽检）
- [ ] 进度计划在交付期限内
- [ ] 质保期/维护期与商务条款一致

---

### 修复模式工作流程

当进入修复模式时，执行以下步骤替代步骤 1-5：

#### R1. 读取反馈来源

读取 `响应文件/核对报告.md`（或用户指定的反馈）：
- 提取所有 🔴 必改问题
- 提取所有 🟡 建议修改问题
- 忽略 🔵 提醒（仅供参考，不自动处理）
- 按操作类型分组：
  - **新建文件**：文件缺失类问题
  - **编辑文件**：内容错误、一致性问题
  - **信息确认**：需用户提供数据才能修复的问题

#### R2. 读取分析报告

同步骤 1 — 从分析报告中提取完整项目数据。
新建文件时需要分析报告作为数据源，编辑文件时需要作为正确性基准。

#### R3. 逐项修复

按 🔴 → 🟡 优先级顺序处理：

**缺失文件：**
- 按步骤 3 中对应附件类型的编写策略创建新文件
- 文件命名、格式、签章区域等遵循现有文件的约定
- 读取已有文件确认公司名称、报价金额等关键数据，确保一致性

**内容修正：**
- 读取目标文件 → 定位问题位置 → 编辑修正
- 修正后检查是否引起连锁不一致（如金额修改需同步多个文件）

**一致性修复：**
- 确定正确值（以分析报告为准）
- 跨文件搜索所有出现位置，逐一修正

**需用户确认的问题：**
- 汇总列出，向用户确认后再修复
- 绝不自行猜测用户意图（如报价金额、业绩信息）

**技术标常见修复场景：**

| 问题类型 | 修复方式 |
|---------|---------|
| 评分子维度缺章节 | 从分析报告提取缺失子维度，在对应文件中添加章节 |
| 技术响应表条目缺失 | 从原始Word重新提取缺失条目，补入响应表 |
| ▲截图占位缺失 | 在对应条目添加截图占位+盖章标注 |
| 响应说明过空泛 | 读取具体条目，重写为≥3行具体实现描述 |
| 全生命周期金额不一致 | 读取报价文件获取正确金额，修正成本表 |
| 进度超出交付期限 | 读取分析报告交付期，重新排布里程碑 |

#### R4. 修复后验证

- 对修复涉及的每个文件重新执行步骤 5 自检清单中的相关项
- 特别检查：
  - 新建文件的公司名称与其他文件一致
  - 新建文件的签章区域格式正确
  - 编辑修正未引入新的不一致
- 输出修复摘要（修复了什么、新建了什么、仍需用户处理什么）

## 编写方法论（通用于任何项目）

### 扣分制评分项
**章节结构完整无遗漏 > 内容深度。**
先确保每个子维度都有独立章节，再充实内容。缺章节 = 该维度0分，内容薄弱最多扣部分分。

### 客观分评分项
如业绩计数、证书计数、人员配备等 → 由商务标（bid-commercial-proposal）处理，技术标不编写。

### 技术响应表
通常是技术标中分值最高的单项。必须逐条响应，零遗漏。
每条响应说明≥3行具体实现描述，禁止空泛语言。

### ▲功能截图
必须有占位符 `【此处插入XX功能截图】` + 标注 `（截图需加盖公章）`。

### 图表处理

所有图表必须生成为：**占位符 + Mermaid 代码块**。

格式：
```markdown
【此处插入XX图】

```mermaid
(Mermaid 代码)

（后续将自动渲染为 PNG 图片）


禁止直接生成 ASCII 字符图（`┌─┐ ├─┤` 等）。

Markdown 表格用于呈现结构化数据（如进度计划表、模块列表、对比表）。

### 禁止事项
- 空泛描述（"支持该功能""满足要求""提供优质服务"）
- 复制粘贴采购文件需求原文作为响应说明
- 大段无关理论背景/行业趋势凑篇幅
- 编造不存在的功能或未经确认的技术方案

## 常见错误类型

| 类型 | 后果 | 预防 |
|------|------|------|
| **🆕 响应模板化严重** | 专家一眼识破，技术响应性评分低 | 先分类识别需求类型，按类型针对性编写 |
| **🆕 硬件需求软件回答** | 答非所问，该条目0分 | 硬件设备禁止出现"微服务""API"等软件术语 |
| **🆕 性能指标缺数值** | 未实质响应，可能扣分 | 性能指标必须引用具体数值和单位 |
| 评分子维度缺章节 | 该子维度0分 | 从评分规则提取子维度列表，逐个建章节 |
| 技术响应表漏条目 | ▲扣2分/条，其他扣1分 | 编写后核对条目数与原文一致 |
| ▲截图未标注盖章 | 扣2分/条 | 编写时逐条检查▲标注 |
| 响应说明过空泛 | 评委视为瑕疵，可能扣分 | 每条≥3行具体实现描述 |
| 全生命周期金额与报价不一致 | 扣分+审查风险 | 与商务标交叉核对报价金额 |
| 进度超出交付期限 | 不响应商务条款 | 里程碑排入交付期限内 |
| 培训方案缺考核方式 | 评分维度不完整 | 从评分规则逐条检查子维度 |

## 输出格式

所有文件输出到 `响应文件/` 目录，Markdown 格式：
- 标题使用 `#` `##` `###` 层级
- 表格使用 Markdown 表格语法
- 图片占位：`【此处插入XXX图】`
- 截图占位：`【此处插入XX功能截图】（截图需加盖公章）`
- 签章标记：`（盖章）` `（签字）`
- 每个文件开头：`# 附件N：标题`

## 自动模式

当被 bid-manager 调度时（上下文中包含 `AUTO_MODE=true`），本 skill 进入自动模式：

- **页数确定**：步骤 1.6 不询问用户
  - 优先读取 `pipeline_progress.json` 中的 `tech_proposal_pages` 字段（用户在bid-evaluation阶段设置）
  - 如未设置，按预算金额自动计算推荐页数
- **跳过文件规划确认**：步骤 2 中不向用户展示规划表等待确认，直接按分析报告生成文件清单并开始编写
- **跳过中间进度询问**：编写过程中不暂停询问用户意见
- **保留自检**：步骤 5 自检清单仍然执行，发现问题自动修复而非询问用户

## 完成状态

编写完成后，输出以下结构化状态摘要：

bid-tech-proposal

同仓库更多 Skills

技术标编写

核心原则

🚨 严禁事项（绝对禁止，不可违反）

禁止 1：绝不允许编写 Python/Node.js 脚本批量生成响应内容

禁止 2：禁止跳过需求分类识别步骤

⚠️ 文件生成规范（防止覆盖问题）— 必须严格遵守

方案 A：使用 bash cat 分段 append（推荐）

方案 B：拆分成多个独立文件

方案 C：修复模式 - 局部修改

❌ 严禁的错误做法

工作模式

创建模式（默认）

修复模式

工作流程

1. 读取分析报告与核实报告 — 确定技术标编写范围

1.1 读取数据源

1.2 提取技术归属附件清单（编写目标）

1.3 提取技术评分项

1.5 其他相关信息

1.6 确定编写页数要求

2. 规划文件清单 — 根据技术归属附件动态生成

3. 编写技术服务响应表（如评分标准中存在此项）

3.1 提取原始需求表格

3.2 逐条编写响应（基于常识判断）

3.3 编写响应表

3.4 编写后质量检查

4. 逐个编写其他技术文档

4.1 评分维度逆向设计（核心方法）

4.2 章节内容要求（根据目标页数动态调整）

图表生成规范

技术标编写

核心原则

🚨 严禁事项（绝对禁止，不可违反）

禁止 1：绝不允许编写 Python/Node.js 脚本批量生成响应内容

禁止 2：禁止跳过需求分类识别步骤

⚠️ 文件生成规范（防止覆盖问题）— 必须严格遵守

方案 A：使用 bash cat 分段 append（推荐）

方案 B：拆分成多个独立文件

方案 C：修复模式 - 局部修改

❌ 严禁的错误做法

工作模式

创建模式（默认）

修复模式

工作流程

1. 读取分析报告与核实报告 — 确定技术标编写范围

1.1 读取数据源

1.2 提取技术归属附件清单（编写目标）

1.3 提取技术评分项

1.5 其他相关信息

1.6 确定编写页数要求

2. 规划文件清单 — 根据技术归属附件动态生成

3. 编写技术服务响应表（如评分标准中存在此项）

3.1 提取原始需求表格

3.2 逐条编写响应（基于常识判断）

3.3 编写响应表

3.4 编写后质量检查

4. 逐个编写其他技术文档

4.1 评分维度逆向设计（核心方法）

4.2 章节内容要求（根据目标页数动态调整）

图表生成规范

同仓库更多 Skills