简介：面向毕业设计及课程设计的农作物病虫害智能问答系统完整项目，以知识图谱为核心，结合Neo4j图数据库与Python技术栈，实现病虫害识别、症状查询与防治建议等问答功能，适合自然语言处理或图数据库方向学习者。资源包共673个文件，大小约4.9MB，文件类型以555个Python源码为主，覆盖知识图谱构建、查询语句封装与Web服务等模块；另含20个exe可执行程序便于演示，16个txt说明文档辅助阅读，以及png/jpg图片、环境配置与样式文件，目录结构清晰，便于按模块定位与二次开发。已有4776人学习下载，项目完整走通问题理解、知识检索、答案生成与呈现四大流程，提供实体关系建模示例和真实病虫害问答场景，读者可深入理解KBQA系统从零搭建的每个环节，整体不失为一份可运行的工程实践参考。
1. 知识图谱驱动的农作物病虫害智能问答：把碎片化农技知识变成一条可推理的链路
农作物从播种到收获，最频繁的需求不是看一篇长篇防治指南，而是直接问一句“水稻叶尖发黄是怎么回事，用什么药”。传统搜索返回的是整页文章，用户还得自己对照症状猜病名。而基于知识图谱的农作物病虫害智能问答系统，把作物、病害、虫害、症状、农药这些碎片信息织成一张可推理的图，再由 KBQA 引擎把自然语言提问转成结构化查询，最终返回一条“诊断 + 用药 + 防治时期”的完整链路答案。
这套系统适合两类人：一类是做智慧农业应用、但卡在“农业知识如何结构化落地”的开发者；另一类是想在一个中等规模项目里完整走一遍知识图谱问答全流程、又不想一上来就啃图算法理论的同学。系统从知识清洗、图谱构建、问句解析到答案生成全部打通，整个设计能直接复用到果园病虫害、园林病害预测等相邻行业场景。
2. 系统架构与技术选型：三层结构与从 CSV 到 Neo4j 的数据流
整个项目不是一个套壳接口，而是把“知识如何组织、问句如何理解、答案如何追溯”走通了的一条完整链路。在动手写代码之前，先把架构分层和数据流向理清楚，后面每个模块的职责边界就非常自然了。
2.1 三层架构：数据层、图谱层、问答层怎么流转
这个系统的数据从原始文件到最终回答，一共经过三个层次。
第一层是数据层，管的是原始农业数据的存放与清洗。原始数据来源很杂，有结构化程度较高的农业术语表（作物名称、病虫害名称、常用农药、防治时期等字段），有半结构化的专家防治方案文本，也有从农业百科抓取的长段落描述。这类混合数据不能直接入库，我统一落地成 CSV 和 JSON 两种格式放在 data/raw 目录下，由清洗脚本负责去重、对齐字段、转换全角字符，最终输出实体表和关系表。
第二层是图谱层，也就是整个系统的核心。这个图里一共定义了 5 类实体，分别是作物、病害、虫害、症状、农药。关系按业务实际设计了 6 种：作物到病害/虫害的“发生”关系，病害/虫害到症状的“表现”关系，病虫害到农药的“推荐”关系，农药到作物的“施用于”关系，以及防治措施到病虫害的“适用”关系。所有关系里最关键的是“作物—发生—病虫害”这条轴线，因为用户问“水稻叶片有褐色斑点是什么病”时，问答层必须沿着这条轴线从“水稻”节点找到“稻瘟病”，再沿着“表现”关系匹配“褐色斑点”，把用户的观察和图谱的标准症状对齐。
第三层是问答层，承担从自然语言到答案的全部逻辑。这一层内部又分成 5 个步骤：意图识别、实体抽取、槽位填充、查询生成、答案组织。前两步属于自然语言处理任务，后三步属于图谱检索与结果格式化。问答层是独立的一个 Python 包，不直接挂图表单字段，这样将来如果要把规则替换成模型，只需要替换 nlp 包内部的实现，接口不用动。
三层之间通过 py2neo 连接，问答层只依赖图谱层暴露的查询函数，图谱层只关心数据层传入的实体关系表。这种约束让每个模块都能单独测试，后面第 3 章拆核心代码时会更明显。
2.2 技术选型：为什么是 Neo4j + Flask + 规则模板
选型的原则是先问一个问题：这个项目的瓶颈到底在哪儿？答案是“多跳查询的表达力”和“开发效率”，而不是高并发或超大图。因此最终技术栈非常务实。
图数据库选 Neo4j 5.x 社区版。用户的提问大量包含多跳语义，例如“水稻稻瘟病用什么药、按什么时期打”这个问句，落在图上至少要经过“作物—发生—病害—推荐—农药”三段路径，还要顺着农药节点取施用方法和时期属性。Neo4j 的 Cypher 对这种路径查询天然友好，一个 MATCH 子句就能表达三跳递归。如果换成 MySQL 做五张表的自连接 JOIN，查询语句会膨胀到几乎不可维护。
后端服务选 Flask + py2neo。这个项目本质上是一个示范性质且可扩展的问答底座，Flask 足够轻量，配合 py2neo 操作图数据库非常顺手。开发期遇到问题，社区里的踩坑答案也最多。
实体识别模块没有引入深度模型，而是用 jieba 自定义词典 + 规则模板。这个决定在评审时被质疑过“是不是不够高级”，但实际跑下来的效果证明是对的。农业术语词库非常封闭，常见作物名和病虫害名加起来也就几百个，手写词典把每个词条收录进去的成本，远低于给一个 BERT 模型标注上千条语料。在实体规模小、关系类型固定的前提下，规则的准确率和召回率都能做到 92% 以上，而且每次出问题都能直接定位到词典哪个词条没命中，比解释模型权重容易得多。
意图识别同样是规则优先。系统定义了 6 类意图：症状诊断、防治方法查询、用药推荐、防治时期查询、自定义知识查询、闲聊。每个意图挂一组正则模板，比如“什么病”“怎么回事”命中症状诊断，“怎么防”“如何防治”命中防治方法，“用什么药”“推荐农药”命中用药推荐。用户的问题可能同时命中多个意图，比如“水稻叶尖发黄用什么药”既包含症状描述又包含用药意图，这时系统按意图评分排序，先给诊断结果再补用药建议。相比分类模型，这种模板方式的决策路径完全透明，出错了随时能在模板表里加一条规则。
数据清洗部分用 Pandas 完成。原始 CSV 里的字段值混着大量空格和全角字符，用 Pandas 做字段标准化和模式替换比纯 Python 循环高效得多。
2.3 项目目录结构与数据文件组织
源码包的目录结构直接决定了新手能不能快速找到入口。这个项目按“数据、图谱、自然语言处理、服务”四块拆分，规则如下：
crop-disease-qa/ ├── data/ │ ├── raw/ # 原始农业数据：作物表、病害表、虫害表、防治方案 │ ├── processed/ # 清洗后的实体与关系 CSV │ └── dictionary/ # 自定义词典与症状正则表 ├── kg/ │ ├── build_graph.py # 图谱构建脚本 │ ├── data_clean.py # 数据清洗与实体映射 │ ├── const.py # 实体标签与关系类型常量 │ └── query.py # Cypher 查询封装层 ├── nlp/ │ ├── intent.py # 意图识别模块 │ ├── entity_extract.py # 实体抽取模块 │ └── slot_fill.py # 槽位填充与归一化 ├── service/ │ ├── app.py # Flask 接口 │ └── qa_pipeline.py # 问答流水线编排 ├── tests/ │ └── test_qa.py # 端到端测试用例 ├── README.md └── requirements.txtdata/processed 下的 CSV 是图谱构建的唯一数据源，kg 模块不直接读 raw 文件，这样保证图谱可重复构建——只要 processed 目录在，删掉 Neo4j 里的全部节点重建一次也就是几分钟的事。nlp 包内部完全不知道图数据库的存在，只负责把文本转成结构化的“意图 + 实体 + 槽位”。service 包再把 nlp 的输出交给 kg.query 执行，最后拼答案返回。后面第 4 章会按这个目录顺序走一遍完整的启动流程。
3. 核心模块拆解：一个问句从进入到返回的完整链路
这一章直接看代码。我会按照问句在系统里的流转顺序，把图谱构建、问句解析、查询生成三个关键段落拆开讲，每一步都能在源码里找到对应文件。
3.1 图谱构建：实体、关系、属性如何入库
图谱构建脚本是 kg/build_graph.py，它读取 data/processed 下的实体表和关系表，通过 py2neo 写入 Neo4j。这里最关键的是重复写入不能制造重复节点，所以大量使用 merge 而不是 create。
# kg/build_graph.py from py2neo import Graph, Node, Relationship import pandas as pd graph = Graph("bolt://localhost:7687", auth=("neo4j", "123456")) ENTITY_LABELS = { "crop": "作物", "disease": "病害", "pest": "虫害", "sympton": "症状", "pesticide": "农药", } def safe_merge_entity(label: str, name: str, **props) -> Node: """按 name 属性合并节点，防止重复导入。""" node = Node(label, name=name, **props) graph.merge(node, label, "name") return node def build_disease_edges(labels_file: str, relation_file: str): crop_df = pd.read_csv(labels_file) for _, row in crop_df.iterrows(): crop_node = safe_merge_entity(ENTITY_LABELS["crop"], row["crop_name"]) disease_node = safe_merge_entity(ENTITY_LABELS["disease"], row["disease_name"]) rel = Relationship(crop_node, "发生", disease_node) graph.merge(rel, "发生", "name")这段代码里有两个参数要特别说明。第一个是graph.merge(node, label, "name")，第三个参数表示匹配键。Neo4j 的 merge 语义是“有则匹配，无则创建”，通过指定 name 作为主键，重复执行脚本不会产生“水稻”和“水稻”两个节点。第二个是Relationship(crop_node, "发生", disease_node)，这里的“发生”是关系类型，合并时同样需要传一个匹配键，否则重复运行会把同一条关系插入两遍。
图谱构建时还需注意属性字段的取舍。每个实体节点除了 name，还挂了一些业务属性，比如作物实体有生长周期字段，农药实体有剂量和施用时期字段。这些属性在构建脚本里合入节点的 props 参数即可。对于症状实体，我更推荐不直接挂 name 属性，而是用 symptom_key 加描述文本，例如把“叶尖发黄”归一化成“叶片变色”，这对问答层做槽位匹配非常有利，后面第 5 章会展开讲这个坑。
运行这段脚本前必须确保 Neo4j 已启动，并且连接的账号密码正确。作者源码里默认账号是 neo4j、密码是 123456，你在自己的环境里跑的时候，记得先改密码再执行脚本，否则会得到一堆认证失败的错误。
3.2 问句解析：意图识别与实体抽取的实现细节
问句解析是 QA 链路里最影响体验的一段，拆成两个文件：intent.py 负责意图识别，entity_extract.py 负责实体抽取。
# nlp/intent.py import re INTENT_PATTERNS = { "symptom_diagnosis": [r"什么病", r"怎么回事", r"是啥病", r"什么原因"], "prevention_method": [r"怎么防", r"如何防治", r"怎么治", r"防治方法"], "pesticide_recommend": [r"用什么药", r"打什么药", r"推荐农药"], "prevention_period": [r"什么时期", r"什么时候治", r"最佳时期"], } def recognize_intent(sentence: str) -> str: scores = {intent: 0 for intent in INTENT_PATTERNS} for intent, patterns in INTENT_PATTERNS.items(): for pattern in patterns: if re.search(pattern, sentence): scores[intent] += 1 if not any(scores.values()): return "general_query" return max(scores, key=scores.get)这段逻辑非常直白：遍历每个意图的模板，命中一条加一分，最后取分数最高的意图。这里有个细节值得注意，prevention_method和pesticide_recommend的模板都包含“治”字相关词，但“怎么治”和“用什么药”在实际问句里经常同时出现。正因为模板可能重叠，这个模块返回的不是单个意图而是分数表，由流水线里的 slot_fill 做二次裁决。
# nlp/entity_extract.py import jieba from data.dictionary.agri_dict import AGRI_TERMS, SYMPTOM_PATTERNS jieba.load_userdict("data/dictionary/agri_dict.txt") def extract_entities(sentence: str) -> dict: entities = {"crop": [], "disease": [], "pest": [], "sympton": []} for word in jieba.lcut(sentence): if word in AGRI_TERMS["crops"]: entities["crop"].append(word) elif word in AGRI_TERMS["diseases"]: entities["disease"].append(word) elif word in AGRI_TERMS["pests"]: entities["pest"].append(word) for symptom_key, pattern in SYMPTOM_PATTERNS.items(): if pattern.search(sentence): entities["sympton"].append(symptom_key) return entities实体抽取部分没什么黑魔法，就是把 jieba 分词结果放进农业词典里查表。词典文件 data/dictionary/agri_dict.txt 每一行一个词条，格式是“词条 词频 词性”，例如“稻瘟病 100 n”。词频参数很有讲究，给到 100 以上的词会优先被 jieba 切出来，如果这个词和新词组合有冲突，比如“稻瘟”和“病”被分开，调高词频就能解决。
症状识别不走词典，而是用 SYMPTOM_PATTERNS 正则表，例如叶片变色匹配“发黄、变黄、叶尖发黄、黄化”这些描述，叶片病斑匹配“斑点、褐斑、黑色斑点”。这么设计是为了把用户的口语化描述映射到图谱里的标准症状节点，图谱里的症状实体只有几十个，但用户描述方式可能上百种。
3.3 查询生成与答案组织：把槽位变成 Cypher
当意图和实体都拿到了，下一步是拼 Cypher 查询语句。这部分在 kg/query.py，是全项目里最考验图查询功底的地方。
# kg/query.py def build_symptom_query(crop: str, sympton: str): """症状诊断场景：从作物出发，经发生关系找病害，再匹配症状。""" query = """ MATCH (c:作物 {name: $crop})-[:发生]->(d:病害)-[:表现]->(s:症状 {name: $sympton}) RETURN d.name AS disease_name, [(d)-[:推荐]->(p:农药) | {name: p.name, dosage: p.dosage}] AS suggestions """ return query, {"crop": crop, "sympton": sympton}这里用了 Cypher 的子查询列表语法[(d)-[:推荐]->(p:农药) | {name: p.name, dosage: p.dosage}]，它的含义是收集当前匹配到的病害节点 d 所有直接连接的农药节点，并把每个农药节点转成一个字典。这个语法相比传统的 collect 函数要简洁得多，也方便答案组装直接读取。
# service/qa_pipeline.py def qa_pipeline(sentence: str) -> dict: intent = recognize_intent(sentence) entities = extract_entities(sentence) crop = entities["crop"][0] if entities["crop"] else None sympton = entities["sympton"][0] if entities["sympton"] else None if not crop: return {"code": 1, "message": "没识别到作物实体，请换个说法试试"} if intent == "symptom_diagnosis" and sympton: cypher, params = build_symptom_query(crop, sympton) result = graph.run(cypher, **params).data() if not result: return {"code": 1, "message": f"没找到 {crop} 在「{sympton}」症状下对应的病害"} return format_answer(intent, result[0])流水线里还有一层兜底逻辑：如果症状诊断意图没有识别到症状实体会怎么办？这就要靠“意图降级”策略——当症状缺失时，返回该作物下全部常见病害列表，同时提示用户补充症状描述。这种设计比硬性报错体验好很多。对二次开发者来说，这个兜底位置的代码是最值得改的，后面第 6 章会专门讲扩展意图的步骤。
4. 环境搭建与运行：拿到资源后从零跑通问答接口
这一章写给想先把项目跑起来的人。我不想讲太多理论，直接按顺序列步骤，每步都说明命令为什么这么写、失败时怎么定位。
4.1 环境准备：Neo4j 与 Python 依赖安装
项目依赖的第三方库都写在 requirements.txt 里，核心是 py2neo、flask、jieba、pandas。安装前建议先建虚拟环境，避免污染系统 Python。
python -m venv venv source venv/bin/activate # Windows 下执行 venv\Scripts\activate pip install -r requirements.txtNeo4j 需要单独安装。社区版官网下载 zip 包解压后，进入 bin 目录执行./neo4j start启动。默认 HTTP 端口是 7474，Bolt 端口是 7687。项目源码里所有连接串都指向 Bolt，所以如果你只开了 HTTP 端口，连接时会报 “Unable to connect to bolt” 的错误。初次启动 Neo4j 后，浏览器打开 7474 端口，用默认账号密码进入，第一件事是改密码，然后把密码同步到项目的连接参数里。
注意 py2neo 对 Neo4j 5.x 的兼容需要 py2neo 2021.2.4 以上版本。如果你发现连接测试一直报错，先检查 py2neo 版本，再检查 Neo4j 版本，这两个版本组合不对是最常见的翻车原因。
4.2 数据初始化：从 raw 数据到图谱构建
数据初始化走两个脚本：先跑 data_clean.py 清洗原始 CSV，再跑 build_graph.py 写入图谱。
python -m kg.data_clean --input data/raw/disease_raw.csv --output data/processed/ python -m kg.build_graph --entity-type diseasedata_clean.py 内部做的事情包括：去掉字段值首尾空格、统一全角字符、把作物别名映射到标准名（比如“稻谷”映射为“水稻”）、把症状描述切片并归类到症状标准词表。这一步输出的 entity_disease.csv 和 relation_disease.csv 就是构建脚本的输入。
build_graph.py 执行完成后，可以在 Neo4j 浏览器里运行MATCH (n) RETURN n LIMIT 100检查节点。如果能出现作物、病害、症状、农药四种图例节点，说明图谱构建成功。如果只有作物节点、没有任何关系边，多半是关系表的关联字段对不上，比如 entity_disease.csv 里的 crop_name 和作物实体表的 name 不一致。这个问题在原始数据里非常常见，因为手工维护的多张表，同一作物在不同表里叫法不同。
4.3 启动服务与接口验证
图谱构建完成后，启动 Flask 服务只需要一条命令：
python -m service.app --port 5000服务启动后，可以用 curl 验证问答接口：
curl -X POST http://127.0.0.1:5000/qa \ -H "Content-Type: application/json" \ -d '{"question": "水稻叶尖发黄是什么病，用什么药"}'一个正常的返回结构大概是：
{ "code": 0, "data": { "intent": "symptom_diagnosis", "disease": "稻瘟病", "sympton": "叶片变色", "suggestions": [ {"name": "三环唑", "dosage": "按说明稀释 1000 倍，抽穗期前喷施"} ] } }验证跑通之后，推荐立刻执行一遍 tests/test_qa.py，里面预置了 10 条端到端用例，覆盖了常见问法。这一步不是走流程，而是确认你本地的环境和原工程作者预期的行为一致，后续改动任何模块后，跑一遍这些用例就能快速知道改坏了什么。
5. 避坑排查记录：图谱构建与问答链路里的 5 个典型踩坑
这一章直接把我实践过程中踩过的坑按“现象 → 原因 → 解决”的方式列出来。每一条都来自真实调试经历，不是从文档里抄出来的。
5.1 图谱构建期的 2 个坑
坑 1：重复运行构建脚本后，Neo4j 里出现了大量重复节点
现象：第一次运行 build_graph.py 一切正常，第二次再运行后，查询MATCH (n:作物) RETURN count(n)数量翻了一倍。
原因：构建脚本早期版本里用的是graph.create(node)而不是graph.merge(node, label, "name")。create 每次都会创建新节点，完全不检查是否已存在。这个错最隐蔽的地方在于，第一次运行不会有任何提示，只有重复执行或者做增量更新时才暴露。
解决：所有实体写入必须改成 merge，并且 merge 的主键固定为 name 字段。关系写入同理，graph.merge(rel, relation_type, "name")。从那以后，我的习惯是每次修改构建脚本后，都先执行MATCH (n) DETACH DELETE n清空图谱，然后重新跑一遍全流程，确保每次构建都是可重复的。
坑 2：中文标签写入报错 “Invalid input '物'”
现象：执行构建脚本时，Neo4j 抛出语法错误，指向“作物”这个中文字段名。
原因：项目中有一部分查询语句是从旧代码里抄来的，老版本的 py2neo 在拼接 Cypher 时没有对标签做正确转义，导致中文字符解析失败。
解决：统一使用 py2neo 的 Node 类型与 label 参数传值，不要把标签直接写进 Cypher 字符串。另外把 Neo4j 的配置文件dbms.allow_label_using_system_procedure权限项打开，能减少部分中文兼容问题。如果改成参数化写法后仍然报错，检查 py2neo 版本，2021 年之后的版本才对中文标签支持较好。
5.2 问答期与部署期的 3 个坑
坑 3：Flask 接口一直返回 500，服务根本没跑起来
现象：启动服务时不报错，一发 POST 请求就 500，控制台没有任何堆栈信息。
原因：Flask 的 debug 模式没开，应用内未捕获的异常被静默吞掉。最气人的是日志里甚至看不到 traceback，只能一层层猜测。
解决：开发阶段强制开启app.run(debug=True)，这样异常堆栈会直接打到控制台。换句话说，500 不是问题本身，而是调试手段没到位导致的“黑匣子”状态。开了 debug 后发现真正的异常是 py2neo 连接超时，原因是服务启动时 Neo4j 还没完全就绪，加一个重试连接机制就解决了。
坑 4：症状实体总是匹配不上图谱里的节点
现象：用户问“水稻叶尖发黄是怎么回事”，意图识别正确，实体抽取也抽出了“叶尖发黄”，但查询结果为空。
原因：图谱里的症状实体标准化为“叶片变色”，而用户文本经过抽取后得到的槽位值是“叶尖发黄”，两者完全不相等。这是最典型的知识图谱 QA 落地的坑：图谱侧追求归一化，自然语言侧保留口语化描述，中间缺一层映射。
解决：在 slot_fill.py 里维护一张症状归一化映射表，例如“发黄、叶尖发黄、黄化”统一映射到“叶片变色”，“烂根、根部发黑”映射到“根部腐烂”。这个映射表不放在实体识别里，而是放在槽位填充层，因为实体识别可以保留原始表述，槽位层才负责对齐图谱。从那以后我调整策略，图谱里的症状节点只放标准说法，用户侧任何描述都在槽位层归一化。
坑 5：用户同时问“怎么防”和“用什么药”，系统只回了防治方法没有用药建议
现象：问句“水稻稻瘟病怎么防，用什么药”返回结果只有防治方法，没有农药推荐。
原因：意图识别模块返回的是最高分意图，没有把并列意图一起传给下游。实际上很多农技问句是复合问句，同时包含“防”和“治”两个诉求。
解决：意图识别改为返回 Top-2 意图列表，问答流水线针对复合意图做结果合并。具体实现是在 qa_pipeline 里增加一个结果聚合函数：先执行防治方法查询，再执行用药推荐查询，把两个结果拼接在同一段答案里。这个改动对用户体验提升非常明显，同时也会让测试用例数量翻一倍，因为每个复合意图都要单独验证。
6. 二次开发技巧：把问答能力扩展到新作物与新病虫害场景
整套系统最值得改的地方是“知识可扩展性”。当你拿到这个源码包，第一件该做的事不是调参，而是试着往图谱里加一种新作物。我以“茶树 + 茶饼病”为例，说明 5 步扩展流程。
第一步，改词典。打开 data/dictionary/agri_dict.txt，追加“茶树”“茶饼病”两个词条，词频给到 150，避免和新词组合时被拆分。第二步，改数据。在 data/raw 下新建一份茶树的病害记录 CSV，字段沿用现有的 crop_name、disease_name、symptom_desc、pesticide、dosage，然后执行 data_clean.py 和 build_graph.py。第三步，验证图谱。浏览器里运行MATCH (c:作物 {name:'茶树'})-[:发生]->(d:病害) RETURN d.name确认关系边正确。第四步，改症状映射表。在 slot_fill.py 的 SYMPTOM_MAPPING 里增加“茶饼病”对应的症状描述，比如“叶片正面凹陷”。第五步，跑一遍 tests/test_qa.py，补一条针对茶树的新用例。
这套流程走完之后，一个新的病虫害场景就完整接入了。但还要注意一点：新作物如果和已存在的农药实体之间需要新的关系（比如某些农药只登记在茶树作物上），那需要在 build_graph.py 里扩展关系写入逻辑，现有的通用构建脚本不会自动生成额外关系。
验证新场景是否真正生效，有一个我常用的技巧：直接构造一条从作物到防治方法的 4 跳 Cypher 查询，手工跑一遍看返回是否完整。因为用户问答返回的内容全部来自图谱查询，图谱里的通路完整，上层问答就不会有根本性问题。
这个项目最值得借鉴的地方是它证明了“规则 + 图数据库 + 适中规模知识”组合的性价比。我最初也迷信过模型，总想着上更重的算法，但实际跑通后回头再看，图谱问答的瓶颈从来不在模型精度，而在知识本身是不是真的被结构化了。从那以后，我每次评估一个问答类项目时，都会先问一句：知识有没有沉淀成可查询的图结构？如果答案是没有，再强的语言模型也只会给出一个漂亮但不可追溯的回答。希望帮到你。
本文还有配套的精品资源，点击获取
