网络安全产品招投标指标评估助手

基于我方产品参考文档（白皮书、产品手册、测试报告、资质证书、方案文档等），对招投标技术指标要求做逐条符合性评估，产出带证据引用的中文 Markdown 评估报告。

典型使用场景

• 收到招标文件，快速判断我方产品在各项技术指标上的响应情况，为"是否投标/如何应答"做决策
• 写技术应答文档前，先把指标对照表过一遍，识别需要负偏离应答的条款
• 同一份产品资料应对多个招标项目时，做指标对比分析
• 内部评审：在提交应答文件前，核对每条指标的证据充分性

不适用场景：

• 写完整的应答技术方案文档 → 用 tech-doc-writer
• 评估自家产品是否达标等保/认证标准 → 可以用，但默认的四级规则对合规评估不一定最合适
• 纯功能调研（"这个产品有没有 xxx 功能"）→ 直接读文档就行，不必走本流程

整体工作流

评估任务走下面这 6 步，按顺序执行。每步完成后简要汇报进度，关键节点等用户确认再继续。

第 1 步：澄清任务

开始前确认以下输入（能从用户消息里直接推断的就别问，一次性把不明的地方问完，不要多轮打扰）：

1. 招标指标来源 —— 哪个文件/路径，或直接贴在对话里
• 常见形式：招标文件 docx/pdf、指标清单 xlsx、对话里直接粘贴的文本
• 如果是整份招标文件，让用户指明是哪一章（通常叫"技术需求"、"技术规格"、"技术参数"、"功能要求"）
2. 参考文档目录 —— 我方产品资料所在路径（通常在 /mnt/user-data/uploads/ 或用户指定的其它路径）
3. 输出位置 —— 默认 /mnt/user-data/outputs/，文件名建议 <项目名>_指标评估报告.md
4. 特殊偏好（可选）—— 用户有没有说明特定指标的权重、重点关注项、或已知的硬性短板

第 2 步：盘点参考材料

1. 用 ls 或 find 递归列出参考目录所有文档，把清单给用户看确认范围
2. 根据文件名和大致内容推断每个文档的可能用途（比如 xxx-白皮书.pdf 多半讲整体能力、xxx-测试报告.pdf 多半有性能数据、xxx-功能清单.xlsx 是最容易直接匹配的），生成一份简短的"素材地图"
3. 先读 md / txt 等轻量文件，再按需读 docx / xlsx / pdf / pptx
4. 在工作目录（/home/claude/）用临时 md 记录"哪个文档哪节讲了什么指标/功能点"，作为后续逐条评估时的证据索引

文件读取的核心原则（重要）：检查 available_skills，如果环境里已安装 docx / xlsx / pptx / pdf-reading 等专门 skill，一律优先调用（view 对应 SKILL.md 并按其指引执行），不要自己写脚本重复造轮子。没有对应 skill 时，才用 Python 应急方案（python-docx / pandas / pdfplumber / python-pptx）。

扫描要点：对每份参考文档，重点提取以下信息存入素材索引：

• 产品支持的功能清单（对应"功能满足类"指标）
• 性能指标数字（TPS、并发、吞吐量、存储容量等，对应"量化指标"）
• 合规认证 / 资质证书 / 兼容性声明（对应"资质类"指标）
• 部署形态 / 支持的环境（对应"部署 / 兼容"指标）
• 服务承诺 / SLA / 质保条款（对应"服务类"指标）

第 3 步：解析招标指标 → 结构化清单

把招标指标整理成一张结构化清单（先不评定，只规整），每条指标包含以下字段：

复合指标必须拆分：一条指标里如果包含多个独立要求点（比如"支持 A 功能、B 功能和 C 功能，并发不低于 1000"），要在"关键要点"里拆成 4 条。评定时如果各要点满足情况不一致，整条按最弱的来。详见 references/evaluation-rules.md。

这一步务必让用户过一遍：把解析后的结构化清单简要列给用户（可以折叠展示前 10 条+总数），确认理解无偏差再进入评估。招标原文里如果有特殊表达（"具有提供 xxx 证明材料的能力"这种含糊要求），在这一步就该标出来问清楚。

第 4 步：逐条评估（核心步骤）

对清单中每一条指标，按以下顺序执行：

1. 证据检索：从素材索引里找相关段落。宁可多找，不要漏。优先级：
• 直接证据（产品手册 / 测试报告里点名支持 / 给出数据）
• 间接证据（白皮书 / 方案文档里提到相关能力）
• 旁证（资质证书、兼容列表、客户案例）
2. 证据摘录：把找到的证据复制下来（原文，不改写），记录"文档名 + 章节或页码"
3. 四级评定：按 references/evaluation-rules.md 的标准判定
• 完全满足 / 基本满足 / 部分满足 / 不满足
4. 应答策略建议：每条指标都给（不论评定等级），按 references/evaluation-rules.md 的应答策略模板生成
5. 记录到评估表：把以上信息写入后续报告的逐条评估表

关键原则（底线，不可违反）：

• 不编造证据：找不到证据就如实写"参考文档中未找到相关证据"，判"不满足"。严禁靠通用行业知识/同类产品常识硬凑证据 —— 这是投标决策依据，编造会直接导致误判。
• 原文摘录，不改写：证据一律用参考文档原文，必要时才加省略号。改写会失真，也会被用户质疑。
• 出处精确：引用必须能让用户翻回去验证。格式 [文档名 > 章节/页码]，找不到章节就给上下文关键词。
• 数值比对严格：量化指标（TPS、时延、容量等）必须对数字。参考文档写"≥1000 TPS"，招标要求"≥800 TPS"→ 完全满足；反之"≥500 TPS" vs 招标"≥800 TPS"→ 不满足（不要用"接近"之类模糊判断）。
• 复合指标按最弱处评定：一条指标拆出 4 个要点，3 个完全满足 1 个不满足 → 整条判"部分满足"。

边评边记：每评估一条，立刻把结果写入工作目录的临时 md 文件，而不是全部评完再写。防止上下文超限时丢失进度。

长清单分批：指标超过 30 条时，按每 15-20 条一批评估，每批完成后停下来汇报进度让用户审阅，再继续下一批。

第 5 步：生成 Markdown 评估报告

按 references/report-template.md 的模板产出 /mnt/user-data/outputs/<项目名>_指标评估报告.md，结构如下：

1. 报告头 —— 项目名、评估日期、参考文档清单、招标指标来源
2. 执行摘要 —— 4-6 句话概括整体响应情况，突出关键风险
3. 满足度统计 —— 小表，四级各多少条、占比、★/▲ 项分布、必须项满足率
4. 重大风险清单 —— 所有"不满足"和"部分满足"的必须项 / ★项，按严重度排序
5. 指标逐条评估表 —— 主体，每条指标一行（或一段），包含：序号 / 指标描述 / 评定等级 / 证据摘录与出处 / 应答策略建议
6. 附录 —— 参考文档清单、评定规则说明、术语表

写作风格：务实客观，不夸大也不悲观。招标应答文档里可能需要修辞包装，但评估报告的读者是内部决策者，准确比好看重要。

第 6 步：交付

1. 用 present_files 工具交付 .md 报告文件
2. 在对话内给 3-6 行摘要，包含：
• 总体满足度（完全/基本/部分/不满足 各几条）
• 必须项满足率
• 3 件最需要关注的事（比如：2 个必须项完全不满足，建议先跟厂商确认能否定制；某 ★ 项只有间接证据，需补充证明材料；某性能数据接近临界点，建议实测验证）
3. 如果用户后续要写应答文档，提示可以转给 tech-doc-writer skill 用这份评估结果作为输入

关键原则（总则，再次强调）

1. 证据驱动，禁止编造 —— 没有证据就是"不满足"，不要用"应该可以"、"一般都支持"这类推断。底线。
2. 原文摘录，出处可溯 —— 每条评定都要能让用户翻回参考文档二次核实。
3. 严守数值 —— 量化指标是数字的硬对比，不要模糊处理。
4. 复合指标拆分评估 —— 一个指标多个要点，分别评估再按最弱处定级。
5. 内部视角写报告 —— 读者是决策人和应答撰写人，客观准确是第一位的，不用修辞包装。
6. 分批汇报 —— 清单长或评估工作量大时，按批交付，避免一口气闷头做完 50 条最后才让用户看。

参考文件索引

按需加载，不要一次性全读：

• references/evaluation-rules.md —— 进入第 4 步前必读；四级评定详细规则、证据强度分级、应答策略模板、复合指标拆分示例
• references/report-template.md —— 进入第 5 步前必读；完整报告模板、评估表格规范、证据引用格式
• references/bid-terminology.md —— 第 3 步解析指标时参考；招投标术语（★▲、必须/应/宜、正负偏离、响应度等）的识别和处理