# 僵尸网络自检项目 — 多领域专家联合评审报告
> 版本：v1.0 | 日期：2026-07-14
> 评审范围：设计思路 v2 + 信息收集策划方案 + 多维度分析框架 v1.0 + 维度框架优化方案 v2.0 + 资料查找方案 v2.0
> 评审方法：模拟 8 个不同领域专家独立评审，然后交叉汇总
---
## 评审专家阵容
| 编号 | 专家角色 | 关注维度 | 模拟背景 |
|------|---------|---------|---------|
| E1 | 安全架构师 | 系统架构、可扩展性、分层设计 | 15年企业安全架构经验，设计过3款商业EDR |
| E2 | 恶意软件分析师 | 检测技术深度、样本覆盖、对抗博弈 | 逆向分析500+样本，专注APT和僵尸网络 |
| E3 | 事件响应专家 | 取证流程、IR playbook、处置闭环 | 大厂CSIRT负责人，处理过200+安全事件 |
| E4 | 软件工程专家 | 工程化、代码质量、可维护性、性能 | 主导过百万级用户桌面软件开发 |
| E5 | 威胁情报分析师 | 情报源覆盖、IoC生命周期、误报控制 | 威胁情报平台架构师，管理千万级IoC库 |
| E6 | 用户体验专家 | 易用性、报告可读性、用户分层 | 安全产品交互设计师，服务过企业级和个人级产品 |
| E7 | 法律合规专家 | 法律风险、隐私保护、分发合规 | 网络安全法务顾问，服务过多家安全厂商 |
| E8 | 终端用户代表 | 实际需求、使用场景、心理预期 | 普通办公用户视角，非技术背景 |
---
## E1. 安全架构师评审
### 整体评价
**评分：8/10 — 架构思路清晰，但缺少关键的系统设计约束和非功能性需求定义**
### 优点
1. **分层检测设计扎实**：从网络→进程→持久化→文件→行为五层覆盖，符合纵深防御原则
2. **模块化设计意识好**：10大检测模块+3个分析方法的设计，便于后续扩展
3. **渐进式深度策略合理**：Depth 1→5 的递进设计避免了"一上来就全量扫描"的资源浪费
4. **维度交叉矩阵有深度**：核心/重要/补充三级标注，有工程指导价值
### 问题与建议
**问题1：缺少非功能性需求定义**
> 当前方案聚焦"检测什么"，但没定义"检测需要多快""消耗多少资源""报告多快出""工具多小"。
建议补充非功能性需求矩阵：
| 指标 | MVP目标 | 完整版目标 |
|------|---------|----------|
| 扫描时长 | <5分钟（快速）/ <15分钟（全量） | <3分钟（快速） |
| 内存占用 | <200MB | <150MB |
| CPU占用 | 峰值<30% | 峰值<20% |
| 安装包大小 | <50MB | <30MB |
| 报告生成 | <30秒 | <10秒 |
| 离线可用 | 全部检测项离线运行 | 同左 |
| 管理员权限 | 仅需部分模块提升权限 | 同左 |
**问题2：缺少系统架构图和模块间通信设计**
> 方案列了模块清单，但没有定义模块间如何协作。比如网络模块发现可疑连接后，如何自动触发进程模块深入调查？
建议设计事件驱动架构：
```
检测引擎核心
├── 扫描调度器（控制各模块执行顺序和优先级）
├── 事件总线（模块间通信）
│ ├── 网络模块 → 发布 "可疑连接" 事件
│ ├── 进程模块 → 订阅 "可疑连接" → 查询关联进程
│ ├── 持久化模块 → 订阅 "可疑进程" → 检查自启项
│ └── 情报模块 → 订阅 "可疑IP/域名" → 查询情报
├── 规则引擎（YARA/Sigma/Sysmon 规则加载和匹配）
├── 关联引擎（多维度线索交叉关联）
└── 报告引擎（风险评分+报告生成）
```
**问题3：缺少基线管理的架构设计**
> 方案提到"基线对比"但没定义基线怎么存储、怎么版本管理、怎么在多设备间同步。
建议：
- 基线格式标准化（JSON Schema 定义）
- 基线版本管理（类似 Git 的 diff 机制）
- 基线加密保护（防止被篡改）
**问题4：缺少对"被感染环境下运行"的架构考虑**
> 如果设备已被感染，恶意软件可能尝试干扰扫描工具。方案在 S12 提到了工具自身防护，但架构层面缺少设计。
建议：
- 工具启动时做自完整性校验
- 关键扫描逻辑在受保护内存区域执行
- 对扫描结果做签名保护，防止被篡改
---
## E2. 恶意软件分析师评审
### 整体评价
**评分：8.5/10 — 检测技术覆盖面非常全面，但部分检测项缺少具体判定逻辑**
### 优点
1. **家族覆盖广**：14个主流家族的特征库，从Mirai到Kimwolf都覆盖了
2. **反规避意识强**：14种反检测技术逐一给出对策，这在同类方案中很少见
3. **C2 检测深入**：checksum8 URI、JARM指纹、Beaconing CV变异系数、FFT傅里叶——技术深度到位
4. **持久化覆盖全**：14+位置的检测列表是我见过最完整的之一
### 问题与建议
**问题1：检测项缺少"判定阈值"定义**
> 方案列了很多检测项，但大部分没写"怎么判定为恶意"。比如"空闲时CPU>30%"——挖矿检测用30%合适吗？后台更新、杀毒扫描都可能触发。
建议为每个检测项定义：
```
检测项：空闲时CPU异常占用
判定逻辑：
- 采集条件：用户空闲≥10分钟（通过GetLastInputInfo判断）
- CPU阈值：持续5分钟 >20%（非单次峰值）
- 排除白名单：已知良性高CPU进程（索引服务/Defender扫描/Windows更新）
- 关联确认：同时检查是否有矿池域名/IP连接（双条件命中才告警）
- 误报率目标：<5%
```
**问题2：缺少"良性软件特征库"**
> 只知道"恶意长什么样"不够，还得知道"正常长什么样"。很多检测项的误报根源是不知道良性软件也会产生类似特征。
建议建立良性软件特征库：
- 已知良性进程的命名管道列表（Chrome/VSCode/Docker等）
- 已知良性软件的注册表自启项（OneDrive/Teams/Spotify等）
- 已知良性软件的网络连接目标（微软/Google/各厂商更新服务器）
- 已知良性软件的DLL加载列表
**问题3：进程注入检测的误报问题没有充分讨论**
> malfind 检测 RWX 内存区域，但 .NET CLR、JIT 编译器、调试器、游戏反作弊系统都会产生合法的 RWX 内存。
建议：
- 列出 malfind 的已知良性来源清单
- 设计排除规则（按进程名+内存大小+内存特征组合排除）
- 对于关键进程（explorer/svchost/lsass）的注入告警单独提级
**问题4：缺少对"无文件攻击"的专项检测策略**
> 虽然提到了无文件攻击，但没给出完整的检测链路。无文件攻击是目前最高级的规避手段之一。
建议补充无文件攻击检测专项：
```
无文件攻击检测链：
1. PowerShell 脚本块日志 → 检测 IEX/DownloadString/Assembly.Load
2. .NET Assembly 内存加载 → ETW 事件 + AMSI 日志
3. WMI 事件订阅 → 检查 __EventFilter + CommandLineEventConsumer
4. 注册表存储 payload → 检测非标准键值中的 Base64/二进制数据
5. 计划任务执行解释器 → schtasks 中的 powershell/wscript/mshta
6. 进程内存中的反射DLL → malfind + ldrmodules 交叉确认
```
**问题5：建议增加"行为链检测"概念**
> 单个行为可能误报，但行为链不会。比如"svchost从Temp目录启动"可能误报，但"svchost从Temp启动 → 连接非常规端口 → 创建计划任务"就是高置信度告警。
建议设计行为链检测引擎：
- 定义常见恶意行为链模板（基于ATT&CK技术序列）
- 实时关联引擎按链模板匹配
- 链完成度越高，置信度越高
---
## E3. 事件响应专家评审
### 整体评价
**评分：7.5/10 — 检测能力强，但检测后的处置闭环设计不足**
### 优点
1. **NIST 易失性优先原则**：数据采集顺序正确，不会因为先采持久数据而丢失易失证据
2. **10步SOP流程**：从准备到报告的全流程覆盖
3. **风险分级模型**：严重性×紧迫性×置信度三维评分实用
4. **ATT&CK 攻击链重建**：能帮助用户理解"发生了什么"
### 问题与建议
**问题1：检测到感染后的"下一步"不够清晰**
> 方案说"只检测不清理"，这是正确的。但用户拿到报告后，看到"🔴 严重：确认C2通信"，然后呢？
建议增加"响应建议引擎"：
```
对每个高风险发现，报告应包含：
1. 威胁描述：发现了什么，意味着什么
2. 紧急动作：立即断网 / 立即终止进程 / 立即禁用服务
3. 取证建议：需要保留什么证据（内存镜像/进程列表/网络日志）
4. 清理选项：手动清理步骤 / 建议重装系统 / 推荐专业工具
5. 预防建议：如何防止再次感染（补丁/配置/行为改变）
6. 专业帮助：何时需要联系安全专业人员
```
**问题2：缺少"证据保全"设计**
> 如果用户后续需要报警或请专业团队处理，扫描时获取的数据需要以可验证的方式保存。
建议：
- 扫描结果生成带时间戳和哈希的完整证据包
- 证据包格式兼容标准取证工具（如 Velociraptor 可导入的格式）
- 关键发现附带"证据链"（数据来源→处理过程→结论）
**问题3：缺少"误报确认"和"用户反馈"机制**
> 安全工具最大的体验问题是误报。当前方案没有设计"用户标记误报 → 工具学习"的闭环。
建议：
- 报告中每个发现项都有"这是误报"按钮
- 用户标记后，自动将相关指标加入白名单
- 白名单可导出/导入，支持多设备共享
- 定期上传匿名化的误报数据（可选），帮助改进规则
**问题4：时间线分析缺少"因果推断"**
> 当前时间线只做"按时间排列"，但没做因果推断。比如"23:15 可疑文件创建 → 23:16 网络连接建立 → 23:17 计划任务创建"——这三个事件有因果关系，应该自动关联。
建议：
- 设计因果推断规则（文件创建→进程启动→网络连接→持久化建立）
- 在时间线上自动标注因果关系链
- 用不同颜色区分"原因事件"和"结果事件"
**问题5：缺少"感染严重度评估"全局指标**
> 报告有多个发现的各自评分，但缺少一个全局评估："这台设备整体风险有多高？还能不能用？"
建议设计全局风险评分：
```
全局风险 = Σ(单项风险分 × 权重) × 链完整性系数
链完整性系数：
- 发现完整攻击链（入侵→执行→持久化→C2） → ×1.5
- 发现部分攻击链（3+环节关联） → ×1.2
- 仅孤立发现，无关联 → ×1.0
全局风险等级：
>50 → 设备已被完全控制，建议断网+重装
30-50 → 设备可能被控制，建议断网+深度清理
15-30 → 存在风险，建议尽快排查
<15 → 低风险，建议加固
```
---
## E4. 软件工程专家评审
### 整体评价
**评分：7/10 — 方案设计很全面，但工程化落地的关键决策点缺失较多**
### 优点
1. **四期开发计划**：MVP→增强→完整→智能，渐进式开发策略正确
2. **技术选型合理**：Python + psutil/Volatility/YARA 是成熟的技术栈
3. **项目文件结构**：模块化目录结构清晰
4. **测试验证专题**：考虑了测试环境、样本获取、性能基准
### 问题与建议
**问题1：没有定义 MVP 的"最小可用范围"**
> 四期计划说"第一期做网络审计+进程审计+持久化审计"，但每块具体做多少个检测项？做到什么程度算"完成"？
建议定义 MVP 的验收标准：
```
MVP 验收标准（Definition of Done）：
- 网络审计：netstat + DNS缓存 + 防火墙规则 + 端口监听（4项）
- 进程审计：进程列表 + 签名验证 + 路径验证 + 父子关系（4项）
- 持久化审计：注册表Run + 计划任务 + 服务 + 启动文件夹（4项）
- 输出：控制台文本报告 + JSON 结构化数据
- 运行：单文件 exe，双击即可运行，无需安装
- 耗时：<5分钟
- 依赖：仅依赖标准库 + psutil（打包进exe）
- 验证：EICAR 测试文件能被检出
```
**问题2：缺少依赖管理策略**
> 方案提到了 Volatility 3、YARA、pyshark 等外部工具，但没有说明如何打包分发。
建议：
- MVP：纯 Python 标准库 + psutil，PyInstaller 打包成单 exe
- 第二期：内置 YARA Python 绑定（编译进 exe）
- 第三期：Volatility 3 作为子进程调用（随 exe 分发）
- 抓包：用 ctypes 调用 Windows API 而非依赖 Wireshark
- 绝不要求用户安装额外软件
**问题3：缺少配置管理设计**
> 扫描工具有大量可配置项（检测项开关/白名单/情报API Key/报告格式），但没有定义配置文件格式和管理方式。
建议：
```yaml
# config.yaml 示例
scan:
mode: quick # quick | full | custom
modules:
network: true
process: true
persistence: true
memory: false # MVP 阶段关闭
file: false
behavior: false
whitelist:
processes: [chrome.exe, code.exe, ...]
network_destinations: [*.microsoft.com, *.google.com, ...]
startup_items: [OneDrive, Teams, ...]
intelligence:
virustotal_api_key: ""
abuseipdb_api_key: ""
report:
format: [html, json] # html | json | pdf | csv
language: zh
detail_level: standard # minimal | standard | detailed
```
**问题4：缺少性能预算和优化策略**
> 全量扫描涉及文件哈希计算、YARA 扫描、内存取证等重操作，但没有性能预算。
建议：
- 定义各模块的性能预算（如文件哈希<2分钟，YARA<3分钟，内存取证<5分钟）
- 大目录扫描使用多线程/异步IO
- YARA 扫描只扫可执行文件（按扩展名+魔法数字过滤），不扫全盘
- 基线对比只做增量 diff，不全量重算
- 支持扫描中断和恢复
**问题5：缺少 CI/CD 和自动化测试设计**
> 安全工具的规则更新和回归测试非常重要。
建议：
- GitHub Actions：每次提交自动跑 EICAR 测试 + 单元测试
- 规则更新：规则库独立于主程序，支持热更新（从 GitHub Releases 拉取）
- 回归测试：每次规则更新后自动跑已知样本验证检出率不下降
**问题6：跨平台兼容性问题**
> 方案提到要支持 Android/路由器/IoT，但 Python + Windows API 的技术栈在那些平台上不适用。
建议：
- 明确 MVP 只支持 Windows
- 跨平台检测作为独立模块设计（不是简单移植）
- Linux/macOS 版本使用不同的系统 API（/proc、launchd 等）
- Android/IoT 考虑用 Agent 模式而非独立工具
---
## E5. 威胁情报分析师评审
### 整体评价
**评分：8/10 — 情报源覆盖全面，但缺少 IoC 生命周期管理设计**
### 优点
1. **13个情报源**：从 VirusTotal 到 CNCERT，覆盖了主要免费和商业源
2. **交叉验证原则**：多源聚合验证，不依赖单一情报源
3. **时效性要求明确**：2025-2026 数据优先，避免使用过时 IoC
4. **JARM 指纹库**：这个很有前瞻性，很多同类工具没做
### 问题与建议
**问题1：缺少 IoC 生命周期管理**
> IoC 不是静态的——IP 会回收、域名会过期、哈希会变。当前方案没有定义 IoC 的更新、过期、淘汰机制。
建议设计 IoC 生命周期：
```
IoC 生命周期：
1. 采集 → 从多源拉取
2. 验证 → 交叉验证（至少2源确认）
3. 入库 → 带时间戳、来源、置信度
4. 使用 → 检测时查询
5. 过期 → 90天未更新的 IoC 标记为"低置信度"
6. 淘汰 → 180天未更新或被验证为误报的 IoC 移除
```
**问题2：缺少本地 IoC 缓存策略**
> 每次扫描都实时查询13个 API？速率限制怎么办？离线怎么办？
建议：
- 本地维护 IoC 缓存数据库（SQLite）
- 定期同步更新（每日/每周）
- 扫描时优先查本地缓存，仅对缓存未命中的项做在线查询
- 在线查询做速率控制（各API限速不同）
- 缓存命中率统计（用于优化缓存策略）
**问题3：API Key 管理和安全问题**
> 用户需要配置多个情报源的 API Key，但没有讨论如何安全存储。
建议：
- API Key 加密存储（DPAPI on Windows）
- 首次运行引导用户配置（而非要求一次性配全）
- 支持部分配置（没配 VirusTotal Key 就跳过该源，不影响其他检测）
- Key 不出现在报告和日志中
**问题4：缺少"情报质量评估"机制**
> 不是所有情报源质量一样。VirusTotal 的多引擎检测有误报，AbuseIPDB 的 IP 标记可能过时。
建议为每个情报源定义质量权重：
| 情报源 | 权重 | 说明 |
|--------|------|------|
| VirusTotal（多引擎一致≥5） | 0.9 | 高置信度 |
| VirusTotal（单引擎报毒） | 0.3 | 低置信度 |
| AbuseIPDB（>1000 reports） | 0.7 | 较高 |
| AbuseIPDB（<10 reports） | 0.3 | 较低 |
| OTX Pulse | 0.6 | 中等 |
| ThreatFox | 0.8 | 较高 |
| 本地 YARA 命中 | 0.7 | 中高 |
| 行为分析命中 | 0.6 | 中等 |
**问题5：缺少"未知威胁"的情报策略**
> 当前情报体系主要检测已知威胁。对于零日攻击/新型变种，IoC 体系会失效。
建议补充行为情报策略：
- 不依赖 IoC，而是基于行为特征检测
- "这个进程的行为模式与已知僵尸网络家族相似度>80%"→告警
- 与 A3 恶意软件家族维度的行为特征库联动
---
## E6. 用户体验专家评审
### 整体评价
**评分：6.5/10 — 技术方案很强，但用户视角的设计严重不足**
### 优点
1. **C1 用户场景维度**：区分了6种用户场景，有差异化意识
2. **渐进式深度检测**：不一上来就吓用户，先快速筛再深入
3. **风险分级**：🔴🟠🟡🟢 四级比"发现10个问题"更易理解
### 问题与建议
**问题1：没有定义"目标用户画像"**
> 方案说"普通家庭用户""游戏玩家""开发者"等6种场景，但没说这个工具的目标用户是谁。是给安全小白用的？还是给有一定技术基础的IT人员？还是给专业安全人员？
建议明确目标用户分层：
```
第一层（主要）：有一定计算机基础的个人用户
- 知道什么是进程、IP、注册表
- 能看懂简单的安全报告
- 需要工具帮助判断"我的电脑是否安全"
第二层（重要）：IT运维/技术爱好者
- 有一定安全知识
- 需要详细的技术报告
- 可能用于检查公司分配的设备
第三层（未来）：专业安全人员
- 需要原始数据导出
- 需要与其他工具联动
- 可能用于快速初步排查
```
**问题2：报告设计缺少"可操作性"**
> 报告告诉用户"发现3个高危风险"，但没告诉用户"现在该做什么"。
建议报告结构设计：
```
报告结构（面向非专业用户）：
1. 🔴🟢 一句话结论："您的电脑当前[安全/存在风险/已被感染]"
2. 需要立即做什么（最多3条，用大白话）
3. 发现了什么（按严重度排序，每条包含）
- 问题描述（大白话）
- 可能的影响
- 建议的处理方式
4. 详细技术信息（可折叠，默认收起）
5. 附录：原始检测数据（JSON导出）
```
**问题3：缺少"首次使用引导"设计**
> 用户第一次打开工具，看到一堆检测项，会懵。
建议设计引导流程：
```
首次使用：
1. 欢迎页 → 工具做什么、不做什么、需要什么权限
2. 环境检查 → 检查是否管理员、是否安装必要组件
3. 快速扫描 → 自动执行一次快速扫描（~2分钟）
4. 结果展示 → 一句话结论 + 风险摘要
5. 建议下一步 → 全量扫描 / 查看详情 / 建立基线
```
**问题4：缺少"误报处理"的用户交互设计**
> 用户看到告警后觉得是误报，怎么处理？
建议：
- 每个告警项有"忽略此项"和"标记为误报"按钮
- 标记误报后自动加入白名单
- 提供"查看为什么触发"的详情展开
- 提供"这个发现意味着什么"的解释
**问题5：缺少"扫描进度"和"结果预览"设计**
> 全量扫描15分钟，用户不知道进度。
建议：
- 实时显示扫描进度（当前模块/总进度百分比）
- 扫描过程中即时显示发现的问题（不等全扫完才出结果）
- 允许用户中途中止扫描并查看已有结果
- 扫描完成后弹窗提醒
---
## E7. 法律合规专家评审
### 整体评价
**评分：7.5/10 — 合规意识到位，但部分法律风险分析不够深入**
### 优点
1. **明确了防御性质**："仅检测不清理"的定位避免了法律风险
2. **法规覆盖全面**：网络安全法/数据安全法/个人信息保护法/刑法285-286条都覆盖了
3. **开源协议考量**：考虑了GPL/MIT/Apache 2.0的差异
4. **暗网研究边界**：明确"仅通过安全厂商报告了解，不直接访问暗网"
### 问题与建议
**问题1：缺少"安全产品备案"的深入分析**
> 方案提到"工具发布可能涉及安全产品备案"，但没深入分析。
建议：
- 根据《计算机信息系统安全专用产品检测和销售许可证管理办法》，销售安全专用产品需要公安部检测和销售许可
- 如果工具开源免费、不商业化，备案要求不同
- 如果仅个人使用不公开发布，不涉及备案
- 建议策略：MVP阶段个人使用 → 开源发布 → 视情况申请备案
**问题2：缺少"威胁情报数据合规"分析**
> 工具查询 VirusTotal/AbuseIPDB 等国外情报源，可能涉及数据出境。
建议：
- 查询的 IP/域名/哈希不属于个人信息，一般不涉及数据出境
- 但如果查询结果中包含其他用户的信息（如某IP关联的域名注册信息），需注意
- API Key 属于用户个人数据，需加密存储
- 建议在隐私政策中说明数据流向
**问题3：缺少"免责声明"设计**
> 工具可能误报导致用户误操作（如误删文件），需要法律免责。
建议免责声明要点：
```
免责声明要点：
1. 本工具仅提供安全自检参考，不保证100%准确
2. 检测结果不构成专业安全评估意见
3. 用户根据检测结果采取的行动由用户自行承担责任
4. 工具不修改/删除任何系统文件
5. 工具不上传用户隐私数据
6. 因使用本工具产生的任何损失，开发者不承担责任
```
**问题4：缺少"检测结果的法律效力"分析**
> 如果用户用这个工具检测后报警或诉讼，检测结果有法律效力吗？
建议：
- 明确说明"本工具检测结果不具备司法证据效力"
- 如果用户需要司法证据，应使用专业取证工具（如 FTK/EnCase）并遵循证据链保全流程
- 可以提供"证据导出"功能，但标注"仅供参考，不作为司法证据"
**问题5：开源协议选择建议不够具体**
> 建议明确推荐：
> - **MVP阶段**：GPL v3（强制开源，防止被闭源商业利用）
> - **如果后续商业化**：Apache 2.0（允许闭源商业使用，但保留专利保护）
> - 引用的开源组件需逐一检查协议兼容性（如 Volatility 是 GPL，YARA 是 BSD）
---
## E8. 终端用户代表评审
### 整体评价
**评分：6/10 — 方案太技术化了，普通用户看不懂也用不了**
### 从普通用户视角的问题
**问题1："僵尸网络"这个词就让人困惑**
> 普通用户不知道什么是"僵尸网络"。他们关心的是"我的电脑安全吗？有没有被黑客控制？"
建议：
- 工具名称改为更通俗的，如"电脑安全体检"而非"僵尸网络自检"
- 报告中用"被黑客控制""被恶意软件感染"而非"成为僵尸节点"
- 报告开头用一句话解释："本工具检查您的电脑是否被恶意软件控制，是否在您不知情的情况下被用于攻击他人"
**问题2：用户不想看到注册表、进程树、TLS指纹**
> 技术细节对普通用户没有意义，只会增加焦虑。
建议：
- 默认报告只显示"结论+建议"，技术细节全部折叠
- 提供"简版报告"（1页）和"详细报告"（完整版）两个选项
- 简版报告示例：
```
✅ 网络连接：正常
✅ 系统进程：正常
⚠️ 开机启动项：发现2个可疑项
✅ 系统文件：正常
✅ 安全设置：正常
总评：低风险
建议：检查启动项中的"WindowsHelper"和"QuickUpdate"，
如果您不认识这两个程序，建议删除。
```
**问题3：用户担心工具本身是否安全**
> "你让我下载一个安全工具扫描我的电脑，我怎么知道这个工具本身不是木马？"
建议：
- 工具代码完全开源（GitHub）
- 提供代码签名（至少自签名+哈希校验）
- 发布页面提供 SHA256 校验值
- 工具启动时显示"本工具不会：修改文件/删除文件/上传数据/连接外部服务器（除情报查询外）"
**问题4：用户不想配置 API Key**
> 普通用户不知道什么是 API Key，也不会去 VirusTotal 注册。
建议：
- MVP 完全不需要配置任何 API Key
- 情报查询作为可选增强功能，默认关闭
- 如果要启用，提供一键引导（跳转到注册页面+截图教程）
**问题5：用户关心"扫描完了我该做什么"**
> 如果发现风险，用户需要明确的行动指引。
建议：
- 每个风险项都附带"建议操作"（用大白话）
- 低风险："可以忽略，下次扫描时关注"
- 中风险："建议处理，这里有步骤指导"
- 高风险："建议立即断网，联系技术人员"
- 严重："立即断网，建议重装系统，这里有备份指引"
---
## 交叉评审：专家共识与分歧
### 共识点（8位专家一致同意）
1. **检测技术覆盖面足够全面** — 10大模块+14专题+10维度的设计在同类工具中属于领先水平
2. **"只检测不清理"的定位正确** — 避免了误操作风险，也降低了法律风险
3. **渐进式深度检测策略合理** — 先快筛再深入，兼顾效率和准确性
4. **MVP 范围需要进一步收窄** — 当前第一期计划仍然偏大，需要明确定义"最小可用产品"
5. **用户体验是最大短板** — 方案从技术视角出发，缺少用户视角的设计
6. **报告可操作性需要增强** — 不能只告诉用户"发现了什么"，还要告诉用户"该做什么"
### 分歧点
| 议题 | 安全派观点 | 易用派观点 |
|------|----------|----------|
| 检测深度 vs 速度 | 应该全量深度扫描，宁可慢也要准 | 快速扫描覆盖80%场景，深度扫描作为可选 |
| 技术细节展示 | 完整展示所有技术细节 | 默认隐藏，按需展开 |
| API Key 配置 | 必须配置才能获得最佳效果 | 零配置也能用，API Key 是可选增强 |
| 报告格式 | JSON+HTML 双格式 | 简版HTML为主，JSON作为导出选项 |
| 跨平台支持 | 从MVP开始就要考虑跨平台 | MVP只做Windows，跨平台是以后的事 |
### 优先改进建议（按紧急度排序）
| 优先级 | 改进项 | 来源专家 | 理由 |
|--------|--------|---------|------|
| P0 | 定义 MVP 验收标准（最小范围+完成定义） | E4 | 没有明确边界就无法开始编码 |
| P0 | 设计面向用户的报告结构（简版+详版） | E6/E8 | 用户体验是最大短板 |
| P0 | 为关键检测项定义判定阈值和误报排除规则 | E2 | 没有阈值的检测项等于没有检测项 |
| P1 | 设计系统架构图和模块间通信机制 | E1 | 架构设计是编码前提 |
| P1 | 设计配置管理方案（YAML配置文件） | E4 | 可配置性影响所有模块 |
| P1 | 设计响应建议引擎（发现风险后该做什么） | E3 | 检测闭环需要处置指引 |
| P1 | 定义非功能性需求（性能/资源/时长预算） | E1/E4 | 性能预算影响技术选型 |
| P2 | 设计 IoC 生命周期管理 | E5 | 情报时效性影响检测准确性 |
| P2 | 设计良性软件特征库 | E2 | 降低误报的关键 |
| P2 | 设计用户引导流程（首次使用） | E6/E8 | 降低使用门槛 |
| P2 | 设计误报反馈和学习机制 | E3/E6 | 持续改进检测质量 |
| P3 | 设计证据保全机制 | E3 | 支持后续专业处置 |
| P3 | 设计行为链检测引擎 | E2 | 降低误报+提高置信度 |
| P3 | 完善法律合规分析（备案/免责/证据效力） | E7 | 降低法律风险 |
| P3 | 设计工具自身防护机制 | E1/E2 | 防止被恶意软件干扰 |
---
## 总结
### 方案整体评分
| 维度 | 评分 | 说明 |
|------|------|------|
| 检测技术覆盖度 | 9/10 | 业界领先水平，10大模块+14专题+10维度 |
| 分析框架深度 | 8.5/10 | 多维度交叉+ATT&CK映射+反规避对策，有深度 |
| 工程化可行性 | 7/10 | 缺少架构图/性能预算/MVP边界定义 |
| 用户体验设计 | 6/10 | 技术视角主导，用户视角不足 |
| 处置闭环设计 | 6.5/10 | 检测强、处置弱，缺少响应建议引擎 |
| 合规风险评估 | 7.5/10 | 合规意识到位，部分分析需深入 |
| **综合** | **7.5/10** | **技术方案优秀，工程化和用户体验是主要短板** |
### 一句话总结
> 这是一个"检测能力达到专业级，但工程落地和用户体验还需要补课"的方案。建议在开始编码前，先用1-2天时间完成 P0 级改进（MVP边界+用户报告+检测阈值），这会大幅提升后续开发效率。
---
_本评审报告基于现有5份文档的完整内容进行。建议将P0级改进建议整合到方案中后，再开始第一期MVP编码。_