企业官网建设流程全解析

在网络安全毕业设计里，XSS 漏洞检测是一个被写烂了的题目，但同时又是一个几乎每年都会出现在答辩现场的热门方向。大多数同学交上去的方案，要么是“爬虫 + 正则匹配”，要么是用现成工具跑一遍报告，然后写一个包装精美的文档。这样的毕设很难有亮点，也经不起评委追问：你的检测规则从哪来？遇到混淆绕过怎么办？误报率和漏报率怎么平衡？如果你的选题正好是“基于 LLM 大模型 + AI 智能体 + 机器学习的 XSS 漏洞智能检测系统”，那这篇文章就是为你准备的。

先说一个明确判断：这个毕设选题的真正价值，不在“用了大模型”这个噱头，而在于它把三种不同复杂度的技术按照正确的职责组织到了一起。机器学习负责快速判断，LLM 负责语义理解和生成解释，AI 智能体负责把检测过程编排成一条可追踪的工作流。它不是一个“模型包打天下”的玩具，而是一套接近真实安全产品形态的工程系统。这篇文章会从题目拆解、架构设计、核心代码、实验设计、论文写作和答辩准备几个角度，完整讲清楚这套毕设应该怎么做。

1. 这个毕设项目到底解决什么问题

XSS（跨站脚本攻击）之所以难检测，是因为它本质上不是“规则能穷尽”的问题。攻击者构造的 payload 可以千变万化：大小写混写、HTML 实体编码、Unicode 混淆、嵌套绕过，甚至利用浏览器解析器的差异来躲过语义检查。传统 WAF 和规则引擎只能覆盖已知模式，遇到没有见过的变种就漏报；而如果规则写得过严，又会产生大量误报，把正常输入当成攻击。

这个项目要解决的问题，就是把“规则引擎的确定性”和“大模型的语义理解能力”结合在一起。机器学习模型先对输入做初筛，抽取字符分布、敏感函数、编码方式等特征，快速识别出可疑样本；LLM 再对可疑样本做深度研判，理解这段输入在浏览器上下文里到底会不会被执行；AI 智能体则负责把这个过程组织起来，像安全分析师一样做信息收集、检测、验证和报告生成。

从毕设角度讲，这个选题的好处是技术栈丰富，既有传统安全知识，又有机器学习建模，还能体现大模型应用能力。论文里可以写的东西非常多：系统架构、特征工程、模型对比、Agent 工作流设计、实验分析。但它的难点也很明显：如果只是把几个 API 拼在一起，没有形成清晰的检测链路，答辩时很容易被问住。

什么样的同学适合选这个题目？我的判断是：如果你已经掌握 Python 基础，懂一点 Web 安全原理，现在正在学机器学习或大模型应用，这个题目是一个很好的“组合型”毕业设计。它不需要你发明新的检测算法，但要求你能把已有技术合理地组织成一套能运行、能验证、能讲清楚流程的系统。这也正是企业里做安全产品的基本思路：不是找一个万能模型，而是让不同能力协同工作。

2. XSS 漏洞基础与检测逻辑重构

在动手写代码之前，先把 XSS 的基础重新梳理一遍。这不是凑字数，而是因为 LLM 和机器学习介入后，检测逻辑和传统方案完全不同。

2.1 三类 XSS 的核心区别

XSS 通常分为三类：反射型、存储型和 DOM 型。

反射型 XSS 是攻击脚本通过 URL 参数传入，服务端直接拼接返回给浏览器解析。存储型 XSS 是把恶意脚本保存到数据库里，下次页面加载时被渲染，危害最大。DOM 型 XSS 则不走服务端，纯前端 JavaScript 读取 URL 或本地存储中的数据，直接放进 DOM 操作里执行。

其中 DOM 型 XSS 对 LLM 方案尤其值得关注。因为它不经过服务端，传统 WAF 很难拦截，且触发点藏在 JavaScript 代码逻辑里。很多同学在毕设里会把 DOM 型单独作为一个检测场景，用 LLM 分析 JS 代码中的危险函数调用链（比如location.search→innerHTML），这是一个很好的创新点，也是答辩时的加分项。

2.2 传统检测方法为什么不够

传统 XSS 检测主要靠正则和黑名单规则。比如检测<script>标签、javascript:协议、onerror事件等。

这种方案有两个致命问题。第一是绕过容易：攻击者可以写成<scr<script>ipt>，或者用 HTML 实体编码让正则失效。第二是缺少上下文判断：同一段字符串，放在文本节点里没事，放在<img src>属性里就可能变成注入点。规则引擎很难理解这种“上下文差异”。

另一种常见思路是使用无头浏览器（Puppeteer、Selenium）动态执行页面，看是否有弹窗或请求发出。这种方式检测准确率高，但速度慢、开销大，不适合做实时检测。

2.3 引入 LLM 和机器学习后检测逻辑如何重构

我用一张表来对比三种方案的核心逻辑差异：

重构后的检测逻辑是：先由规则引擎做第一层过滤，过滤掉明显正常或明显恶意的数据；机器学习模型做第二层判断，输出一个可疑分数；超过阈值的样本交给 LLM 智能体系统做深度分析；智能体在分析过程中调用工具（比如请求解码、DOM 解析、浏览器验证），最终生成检测结论和修复建议。

这个“漏斗式”架构是这个系统的核心设计思想，它在论文里会是你和其他“只调用大模型”方案拉开差距的地方。

3. 系统整体架构设计

这套系统的架构可以分成四层：数据接入层、检测分析层、智能体协调层、交互展示层。

3.1 四层架构

数据接入层负责接收待检测的 URL、HTTP 请求或文本数据。可以做成一个 Web 服务，接收表单提交，也可以做成批量扫描模式，读取文件中的 URL 列表。

检测分析层由三部分组成：规则引擎、机器学习模型、LLM 调用服务。规则引擎保证基础召回率，机器学习模型做高效初筛，LLM 做深度判断。

智能体协调层是这个系统最有“设计感”的地方。AI 智能体不是一个单一的 LLM 调用，而是一个可编排的工作流。系统里可以定义四个 Agent：信息收集 Agent 负责解析 URL、解码参数、提取页面特征；检测 Agent 负责调用机器学习模型和规则引擎；验证 Agent 负责通过无头浏览器动态验证可疑输入；报告 Agent 负责生成检测结论和修复建议。这四个 Agent 由一个协调器（Orchestrator）统一调度。

交互展示层面向用户，也就是答辩时老师看到的界面。可以是简单的 Web 页面，支持输入 URL、查看检测结果、查看报告历史。

3.2 技术选型建议

技术选型不需要追求新，要追求自己能讲清楚。

推荐如下组合：

• 后端：Python + FastAPI 或 Flask，两者都有大量文档支持，适合快速开发
• 机器学习：scikit-learn 做特征工程和传统模型，PyTorch 做深度模型（可选）
• Web 前端：Vue 或 React，如果不会，用 Jinja2 模板渲染一个简单页面也完全够用
• LLM 接入：通过 API 调用商用大模型，或基于开源模型本地部署
• 智能体编排：可以使用 LangGraph、PydanticAI 等框架，也可以用 Python 写一个简单的状态机
• 数据库：SQLite 足够做毕设演示，MySQL 适合展示工程能力

这里要特别说明：毕设不是企业级产品，不要为了用框架而用框架。哪怕智能体编排是你手写的 200 行状态机代码，只要逻辑清楚，答辩时的说服力比套用一个大而全的框架更强。

4. 机器学习检测模块实现

机器学习层是整个系统的“加速器”。它不需要做到 100% 准确，但要把大部分明显可疑的样本筛出来，并且控制误报率，否则后面 LLM 的压力会非常大。

4.1 特征提取

XSS payload 有一些统计规律：包含 HTML 标签、事件属性、JavaScript 函数名、编码符号、特殊字符异常集中等。我们可以把这些信息转成特征向量。

常用的特征包括：

• payload 长度
• 特殊字符占比（<、>、"、'、(、)）
• 是否包含<script、onerror、javascript:、alert(等敏感关键字
• URL 编码、Hex 编码、Unicode 编码的出现次数
• 字符串熵值（混淆程度越高的字符串，熵值通常越大）

下面是一个完整的特征提取和模型训练示例。

# 文件路径：src/ml/feature_extractor.py import re import math from collections import Counter XSS_KEYWORDS = [ "<script", "onerror", "onload", "onclick", "javascript:", "alert(", "confirm(", "prompt(", "document.cookie", "window.location", "innerhtml", "img src", "svg", "iframe" ] def string_entropy(text: str) -> float: """计算字符串熵值，用于衡量混淆程度""" if not text: return 0.0 freq = Counter(text) length = len(text) entropy = -sum((count / length) * math.log2(count / length) for count in freq.values()) return entropy def extract_features(payload: str) -> list: """从 payload 中提取特征向量""" lower_payload = payload.lower() special_chars = sum(1 for c in payload if c in '<>"\'()/') url_encoded = len(re.findall(r'%[0-9a-fA-F]{2}', payload)) hex_encoded = len(re.findall(r'\\x[0-9a-fA-F]{2}', payload)) keyword_hits = sum(1 for kw in XSS_KEYWORDS if kw in lower_payload) features = [ len(payload), # payload 长度 special_chars, # 特殊字符数量 url_encoded, # URL 编码次数 hex_encoded, # Hex 编码次数 keyword_hits, # 敏感关键字命中次数 round(string_entropy(payload), 4), # 字符串熵值 ] return features

4.2 模型训练与评估

训练脚本使用 scikit-learn 的 TF-IDF 向量化或上述手工特征，配合一个分类模型。逻辑回归是很好的基线，XGBoost 通常能拿到更好的效果。

# 文件路径：src/ml/train_model.py import joblib import pandas as pd from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.linear_model import LogisticRegression from sklearn.model_selection import train_test_split from sklearn.metrics import classification_report from src.ml.feature_extractor import extract_features # 假设 data/dataset.csv 有 text 和 label 两列，label 为 1 表示恶意 df = pd.read_csv("data/dataset.csv") X = df["text"].tolist() y = df["label"].tolist() X_train, X_test, y_train, y_test = train_test_split( X, y, test_size=0.2, random_state=42, stratify=y ) # 使用 TF-IDF 做文本向量化 vectorizer = TfidfVectorizer( analyzer="char_wb", ngram_range=(2, 4), max_features=5000 ) X_train_vec = vectorizer.fit_transform(X_train) X_test_vec = vectorizer.transform(X_test) # 训练基线模型 model = LogisticRegression(max_iter=1000, C=1.0) model.fit(X_train_vec, y_train) y_pred = model.predict(X_test_vec) print(classification_report(y_test, y_pred, target_names=["benign", "malicious"])) # 保存模型和向量器 joblib.dump(model, "models/xss_lr_model.joblib") joblib.dump(vectorizer, "models/xss_vectorizer.joblib")

这段代码直接决定毕设实验里“机器学习模型”部分的数据。建议训练时保存以下指标：准确率、精确率、召回率、F1 值、AUC 值。其中召回率（对恶意样本的检出能力）比准确率更重要，因为漏掉一个 XSS 的代价远高于多查一次。

4.3 如何构造训练数据集

很多同学卡在数据集这一步。公开可用的 XSS 数据集确实比较零散，但毕设层面有几种可靠来源：

• XSSed 和 PayloadBox 等社区的公开 payload 列表
• OWASP 测试用例和 w3af 测试数据
• 自己构造的正负样本：从公开项目里抽取正常 URL 参数作为负样本，把公开 payload 经过简单变形后作为正样本
• CTF 题目中的 XSS 关卡 payload

需要强调一点：数据集来源和构造方式，论文里要写清楚。评审老师最在意的是你的实验可复现性，而不是准确率数字本身。

5. LLM 与 AI 智能体检测模块实现

这一章是这个项目的“门面”，也是最容易写砸的部分。门面做得好，答辩分数会明显高一个档位。

5.1 LLM 在 XSS 检测中具体做什么

一个常见误区是“用 LLM 判断文本是否恶意”。这种做法成本高、延迟大，而且大模型对“恶意”的理解不一定可靠。更合理的用法是让 LLM 做三件事：

第一，语义研判。对于机器学习模型标为“可疑”的输入，LLM 从语义层面判断这个输入是否真的会被浏览器当作代码执行。比如一段看起来包含<script>的文本，如果它出现在 JSON 数据字段中且不经过 HTML 解析，那就是误报。

第二，绕过分析。攻击者经常用编码、拼接、大小写混写等方式绕过规则。LLM 可以通过解码和语义还原，识别出被混淆后的真实意图。

第三，报告生成。把检测过程中的证据链（原始输入、解码结果、机器学习得分、命中的规则）整理成人类可读的漏洞报告，并生成修复建议。

下面是一个调用 LLM 做检测推测的示例。注意密钥要从环境变量读取，不能硬编码到代码里。

# 文件路径：src/llm/detector.py import os from openai import OpenAI client = OpenAI(api_key=os.getenv("OPENAI_API_KEY")) SYSTEM_PROMPT = """ 你是一名 Web 安全专家，负责判断一段输入是否构成 XSS 攻击风险。 请从语义层面分析输入的最终执行意图，输出 JSON 格式结果： { "is_xss": true/false, "risk_level": "high/medium/low", "attack_type": "反射型/存储型/DOM型/未知/无", "reason": "简要说明判断依据", "bypass_technique": "识别到的绕过手法，如编码混淆、大小写混写等" } 注意：如果输入本身不具备执行上下文，即使包含危险字符，也不应判断为 XSS。 """ def llm_analyze(payload: str, context: str = "") -> dict: """ 调用 LLM 进行 XSS 语义分析。 context 参数用于传入输入所在的上下文，比如 HTML 属性还是 JavaScript 区域。 """ user_content = f"输入内容：{payload}\n上下文：{context or '未知'}" response = client.chat.completions.create( model="gpt-4o-mini", # 按实际可用模型调整 temperature=0, response_format={"type": "json_object"}, messages=[ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": user_content}, ], ) return json.loads(response.choices[0].message.content)

这里给一个明确的提醒：response_format={"type": "json_object"}不是所有模型都支持。如果使用的是开源模型或不同厂商 API，需要根据实际支持的参数调整。代码里不要写死某个模型版本，要预留出配置项。

5.2 AI 智能体工作流设计

智能体是这个项目中“把流程变成产品”的关键。很多同学理解的 Agent 就是“让大模型多轮对话”，这不够。在 XSS 检测场景里，智能体应该像安全分析师一样，按照固定步骤完成检测任务，而不是自由发挥。

我建议设计一个简单的五步工作流：

1. 解析阶段：Triage Agent 接收原始输入，提取 URL 参数、请求头、响应体中的候选数据
2. 初筛阶段：将候选数据送入规则引擎和机器学习模型，得出可疑分数
3. 深度分析阶段：对可疑分数超过阈值的输入，调用 LLM 做语义分析
4. 动态验证阶段：对 LLM 判断为高风险的数据，用无头浏览器执行页面并观察行为
5. 报告生成阶段：汇总所有阶段的证据，交给报告 Agent 生成人类可读的漏洞描述和修复建议

这里用 Python 类来组织每个 Agent，便于代码维护，也让论文里的系统设计图有代码支撑。

# 文件路径：src/agent/workflow.py from dataclasses import dataclass from enum import Enum class RiskLevel(Enum): LOW = "low" MEDIUM = "medium" HIGH = "high" @dataclass class DetectionTask: task_id: str payload: str context: str url: str = "" @dataclass class DetectionResult: task_id: str risk_level: RiskLevel rule_hits: list ml_score: float llm_reason: str evidence: list report: str = "" class BaseAgent: """所有 Agent 的基类，定义统一的执行接口""" name = "base" def run(self, *args, **kwargs): raise NotImplementedError class TriageAgent(BaseAgent): """Agent 1：解析和提取候选数据""" name = "triage" def run(self, task: DetectionTask): # 实际实现：解析 URL、解码参数、提取候选输入 decoded_payload = task.payload.replace("&lt;", "<").replace("&gt;", ">") return decoded_payload class DetectionAgent(BaseAgent): """Agent 2：调用规则引擎和机器学习模型做初筛""" name = "detection" def __init__(self, ml_model, vectorizer): self.ml_model = ml_model self.vectorizer = vectorizer def run(self, decoded_payload: str): # 规则命中列表 rule_hits = [] if "<script" in decoded_payload.lower(): rule_hits.append("script_tag") if "onerror" in decoded_payload.lower(): rule_hits.append("event_handler") # 机器学习打分 vec = self.vectorizer.transform([decoded_payload]) ml_score = self.ml_model.predict_proba(vec)[0][1] return rule_hits, ml_score # orchestrator.py 中根据风险等级决定是否继续调用 LLM Agent # 这样可以控制成本，避免每个请求都走大模型

这个流程能体现一个工程判断：不是所有数据都要送进 LLM。只有当规则命中或机器学习得分超过阈值时，才调用大模型。这个设计在论文中非常加分，因为它说明你考虑了成本、延迟和系统负载问题。

5.3 动态验证模块

动态验证是 XSS 检测中“实锤”的一步。用 Playwright 或 Selenium 加载构造好的 URL，等待页面执行，然后检查是否有弹窗alert或特定 DOM 变化。

# 文件路径：src/agent/verifier.py from playwright.sync_api import sync_playwright def verify_xss_with_browser(url: str) -> dict: """ 使用无头浏览器动态验证 XSS 是否触发。 只允许在授权的测试环境中运行。 """ result = {"triggered": False, "evidence": ""} with sync_playwright() as p: browser = p.chromium.launch(headless=True) page = browser.new_page() # 监听 JavaScript 对话框 page.on("dialog", lambda dialog: dialog.accept()) # 注入探针，检测 alert 是否被调用 page.add_init_script(""" window.__xss_detected = false; const originalAlert = window.alert; window.alert = function(msg) { window.__xss_detected = true; window.__xss_msg = msg; }; """) try: page.goto(url, timeout=10000) page.wait_for_timeout(2000) result["triggered"] = page.evaluate("window.__xss_detected") result["evidence"] = page.evaluate("window.__xss_msg") except Exception as e: result["evidence"] = f"页面加载异常: {e}" finally: browser.close() return result

这段代码要注意：page.on("dialog", ...)是为了防止 alert 阻塞无头浏览器。实际检测时，要通过自己注入的探针来判断是否触发，而不是真让页面弹窗。动态验证模块在答辩时可以现场演示，效果很好。

6. 实验设计与结果评价

毕设的实验部分决定了论文的质量。这部分要回答三个问题：数据集是什么样、评价指标是什么、对比实验怎么做。

6.1 数据集描述

建议论文里用一张表清楚描述数据集构成。

注意：不一定要真实跑到这个量级，但要按照这个思路去整理数据。即使最终只有 2000 条数据，只要写清楚构造方式，论文依然有说服力。

6.2 评价指标

XSS 检测场景下，最需要关注的指标是：召回率（Recall）、误报率（False Positive Rate）、F1 值。论文里不能只给一个准确率，因为恶意样本通常只占少数，模型只要把所有样本都判为正常就能拿到很高准确率，但这毫无意义。

建议给出混淆矩阵，并用如下指标：

• 真正例（TP）：恶意样本被正确识别
• 假正例（FP）：正常样本被误报为恶意
• 假负例（FN）：恶意样本被漏报
• 召回率 = TP / (TP + FN)
• 精确率 = TP / (TP + FP)
• F1 = 2 * 精确率 * 召回率 / (精确率 + 召回率)

6.3 对比实验设计

这是论文的核心章节。建议设计三组对比：

第一组，规则引擎 vs 机器学习模型。证明机器学习在变种 payload 上召回率更高。

第二组，机器学习 vs 机器学习 + LLM。证明引入 LLM 能降低误报，同时识别出机器学习判断不了的复杂混淆样本。

第三组，无智能体的串行流程 vs 有智能体的编排流程。证明 Agent 工作流在复杂检测任务上更可控，且能够输出结构化报告。

这里给你一个实验结果的示意表格（数字需要根据你自己的实验填充）：

这个表格的启示是：规则最快但漏报高，机器学习性能均衡，LLM 最慢但误报最低，智能体工作流虽然慢但是可以做深度验证。不同方案适合不同场景，毕设系统的“智能”体现在能根据风险等级动态选择检测深度。

7. 毕设落地：文档、PPT 与答辩准备

很多同学拿到一套源码后，最容易犯的错是直接打开项目跑一遍，然后就去写论文。这个流程缺少一个关键环节：先理解每个模块的职责，再改造成自己的设计。

7.1 项目目录结构建议

一个结构清晰的规范化项目，比花哨的界面更能打动评审老师。

xss-intelligent-detection/ ├── README.md ├── requirements.txt ├── docs/ │ ├── 开题报告.md │ ├── 中期报告.md │ └── 毕业论文.md ├── data/ │ ├── dataset.csv │ └── raw_payloads/ ├── models/ │ ├── xss_lr_model.joblib │ └── xss_vectorizer.joblib ├── src/ │ ├── ml/ │ │ ├── feature_extractor.py │ │ ├── train_model.py │ │ └── predict.py │ ├── llm/ │ │ └── detector.py │ ├── agent/ │ │ ├── workflow.py │ │ └── verifier.py │ ├── web/ │ │ ├── app.py │ │ └── templates/ │ └── rules/ │ └── xss_rules.py └── tests/ └── test_detection.py

7.2 毕业论文大纲

论文大纲建议如下：

• 第一章 绪论：选题背景、研究意义、国内外研究现状
• 第二章 相关技术：XSS 漏洞原理、机器学习基础、大语言模型与智能体技术
• 第三章 系统需求分析与总体设计：功能需求、架构设计、检测流程设计
• 第四章 系统详细设计与实现：机器学习模块、LLM 模块、智能体模块、Web 展示模块
• 第五章 系统测试与实验分析：测试环境、数据集、实验结果、对比分析
• 第六章 总结与展望：工作总结、不足之处、未来改进方向

7.3 答辩时大概率会被问到的问题

提前准备好这些问题，比准备任何 PPT 动画都重要：

• 为什么不用纯 LLM 做检测，而是要和机器学习配合？
• 你的机器学习模型训练数据哪里来的？正负样本比例是多少？
• LLM 的幻觉问题怎么处理？如果大模型给出错误判断怎么办？
• 你的智能体和普通程序有什么本质区别？去掉 Agent 层系统会怎样？
• 检测系统的性能指标是多少？和现有工具（如 W3AF、XSStrike）相比有何优势？
• 系统能拦截 DOM 型 XSS 吗？处理流程是什么？

每个问题都要能用一个具体例子回答，不要只背概念。

8. 常见问题与排查方法

在毕设开发过程中，有几个高频问题几乎每个同学都会遇到。这里整理成排查表，遇到问题时按顺序检查。

9. 工程与安全最佳实践

毕设代码虽然不需要达到生产级标准，但作为安全方向的毕设，代码本身就代表了你的专业态度。下面几条建议值得注意。

第一，所有测试只能在授权环境中进行。XSS 检测系统涉及对网页的访问和执行，一定要在自建的测试站点或明确授权的靶场上运行。论文里要加一段“测试环境与法律声明”，说明测试范围仅限于本实验环境。这不是形式主义，而是安全从业者的基本素养。

第二，API 密钥必须放在环境变量或配置文件中，绝对不能提交到 Git 仓库。答辩时如果现场演示，也建议使用本地部署的开源模型或提前准备好的演示数据，避免现场出现网络或密钥问题。

第三，LLM 检测结果需要保留完整证据链。系统设计时，要把“输入数据、解码过程、规则命中、模型分数、LLM 判断理由、浏览器验证结果”都记录下来。这既是检测系统可解释性的要求，也是论文实验数据的重要来源。

第四，控制成本。LLM API 调用是按次数收费的。在系统设计里加一个“采样频率控制”参数，只对可疑样本做深度分析。论文里提到这一点，会让老师觉得你有工程成本意识。

第五，模型需要持续更新。XSS 攻击手法一直在进化，训练数据里没有的模式会随着时间失效。论文的展望部分可以写：后续可以引入主动学习机制，把人工确认过的检测结果加入训练集，实现模型的持续迭代。

10. 总结

这个毕设项目的本质，不是“用大模型做安全检测”这个新概念，而是如何把规则引擎、机器学习、大语言模型、智能体编排这四种能力组合成一个可靠、可解释、可演进的检测系统。规则引擎保证速度和基础覆盖，机器学习提供泛化能力，LLM 负责语义理解和绕过分析，智能体把整个流程串成一条有逻辑的工作流。

如果你正在准备这个题目，建议按照下面的节奏推进：先跑通最小闭环，也就是“规则初筛 → 机器学习打分 → LLM 研判”，然后加入智能体工作流，最后再做 Web 展示层。不要一开始就追求界面美观或功能全面，先把检测链路跑通，让每个模块都能输出中间结果，这样论文和答辩才会有扎实的数据支撑。

这个题的难点也恰恰是亮点。当别的同学还在讲“我用了 BERT 做文本分类”时，你已经能说清楚“不同风险等级的样本如何分配到不同的检测资源，LLM 的判断如何被验证，整个系统如何形成一个闭环”。这个差距，就是优秀毕业设计和普通毕业设计的差距。