# FDE W2D3 评测题 · 数据库 Tool 与规则 Tool > 候选人背景：36 岁，Java + 大数据 + 医疗保险方向。示例围绕医疗保险 / 特药理赔 / 理赔风控。 > 共 13 题，分 L1 基础（3）、L2 进阶（4）、L3 深度（4）、L4 场景（2）。 > 每题含「考察点」「评分维度」「折叠参考答案」。末尾有评分汇总表与达标线。 --- ## L1 基础（概念辨析） ### Q1. 数据库 Tool 为什么是"高敏感"工具？安全基调是什么？ - **考察点**：数据库 Tool 定位与安全基调。 - **评分维度**： - 直接接触核心业务数据/PII。（4 分） - 风险：注入、越权读隐私、拖垮生产库。（3 分） - 安全基调：只读、最小化、受控。（3 分）
参考答案 数据库 Tool 让 Agent 查保单、理赔记录、药品目录，直接接触核心业务数据，一旦设计不当轻则查错、重则 SQL 注入 / 越权读隐私 / 拖垮生产库。安全基调：默认只读、最小化、受控——只回答"查"，绝不接受"写/删"；敏感字段脱敏；每次查询可追溯。医疗保险场景查的是 PII 密集数据，受个保法和保险监管约束，安全是上线前提而非可选项。
### Q2. 什么是 SQL 注入？参数化查询为什么能防它？ - **考察点**：参数化 SQL 与防注入原理。 - **评分维度**： - 注入：拼接参数导致恶意 SQL 执行。（4 分） - 参数化：占位符+绑定，DB 区分代码与数据。（4 分） - 由驱动转义，模型参数不会被当 SQL 执行。（2 分）
参考答案 SQL 注入：把模型给的参数直接拼进 SQL 字符串，攻击/幻觉可注入恶意语句（如 `x'; DROP TABLE policy; --`）。参数化查询（Prepared Statement）用占位符 + 参数绑定，数据库把参数当"数据"而非"代码"，即使参数含 `DROP TABLE` 也不会执行，转义由 JDBC/psycopg 等驱动完成。这是防注入最有效手段，是数据库 Tool 的铁律。
### Q3. 规则 Tool 和数据库 Tool 在理赔里分别承担什么角色？ - **考察点**：两类工具的分工（取数 vs 决策）。 - **评分维度**： - 数据库 Tool：取数（查保单/目录/记录）。（4 分） - 规则 Tool：决策（算金额/定风险/判拒赔）。（4 分） - 互补：一个取数一个决策。（2 分）
参考答案 数据库 Tool 负责"取数"——查保单额度、理赔记录、特药目录；规则 Tool 负责"决策"——算应赔金额、定风险等级、判是否拒赔。两者互补：一个取数一个决策。确定性计算（金额/风险）用规则 Tool，LLM 只做理解诉求、调工具、组话术，不做硬计算。
--- ## L2 进阶（安全设计） ### Q4. 请完整说明数据库 Tool 的安全设计（达标线①）。 - **考察点**：达标线①——安全五件套（核心考点）。 - **评分维度**： - 只读账号（独立 SELECT-only）。（2 分） - 参数化（防注入）。（2 分） - 表/字段白名单（防越权）。（2 分） - 超时 + LIMIT（防拖库）。（2 分） - 审计日志（谁/何时/查什么）。（2 分）
参考答案 五件套（纵深防御）：① 独立只读账号——专用 SELECT-only，绝不复用写/DBA 账号；② 参数化查询——占位符绑定杜绝注入；③ 表/字段白名单——应用层限制可查的表、字段、条件列（白名单非黑名单）；④ 语句超时 + 强制 LIMIT——防止慢查询/全表扫描拖垮库、大结果撑爆上下文；⑤ 全量审计日志——记谁/何时/查什么/返回多少，关联业务 session，日志防篡改。
### Q5. 参数化查询已经防注入了，为什么还要表/字段白名单？ - **考察点**：白名单与参数化的互补关系。 - **评分维度**： - 参数化只防注入，不防越权。（4 分） - 白名单限制能查的表/字段/条件列。（3 分） - 用白名单而非黑名单。（3 分）
参考答案 参数化解决"注入"（恶意代码执行），但不解决"越权"（查到不该查的表/字段）。白名单在应用层再锁一层：只允许访问预定义的表和字段，即使模型想查 salary 表或密码列也直接拒绝。注意用白名单（只允许 xxx）而非黑名单（禁止 xxx）——黑名单总有漏网之鱼。动态拼表名无法参数化，必须白名单枚举，绝不能把模型给的表名直接拼 SQL。
### Q6. 数据库 Tool 的审计日志应该记什么？为什么关联业务 session？ - **考察点**：审计日志设计。 - **评分维度**： - 记谁/何时/查什么表条件/返回多少/是否拒拦。（5 分） - 关联业务 session 才能分清哪个客户触发。（3 分） - 日志防篡改、不记明文 PII。（2 分）
参考答案 记：谁（哪个用户/session）在何时查了什么（表/条件/参数）、返回摘要（脱敏后）、命中多少行、是否触发白名单拒绝、耗时。必须关联业务 session 而非只记 DB 连接账号——否则分不清是哪个客户触发的查询。保险 PII 访问有合规要求，审计是可追溯和异常检测（某账号频繁查陌生保单）的底座。日志本身别记明文 PII，防篡改存储。
### Q7. 数据库 Tool 为什么要设查询超时和返回数量限制？ - **考察点**：超时与返回限量。 - **评分维度**： - 超时防慢查询/全表扫描拖垮生产库。（4 分） - LIMIT 防大结果撑爆上下文/内存。（3 分） - 返回前脱敏裁剪。（3 分）
参考答案 设语句超时（如 PostgreSQL 的 statement_timeout=3s）防止慢查询/全表扫描拖垮数据库。强制 LIMIT（如最多 50 行）避免一次返回几万行撑爆上下文或内存。Agent 可能生成 `SELECT * FROM claim_record` 没有 WHERE，没有 LIMIT 直接打满库。返回前还要裁剪/脱敏敏感字段，只留下游需要的。
--- ## L3 深度（规则引擎与决策） ### Q8. 规则脚本和 Drools 规则引擎怎么选？请对比。 - **考察点**：简单脚本 vs Drools 的适用场景。 - **评分维度**： - 脚本：规则少、改代码发版、自己写 if-else。（4 分） - Drools：规则多常变、与代码分离热更新、自动冲突解析、天然命中依据。（4 分） - 给出 Drools when→then 示例。（2 分）
参考答案 规则少（几条~几十条）且稳，用简单脚本/函数，改逻辑发版即可。规则多（上百条）且频繁调整（政策变、药品目录变），用 Drools：规则与代码分离可热更新，引擎自动做冲突解析和规则链，天然记录"命中了哪条规则"的依据。示例：`rule "特药目录内且额度充足" when $c:Claim(drugInCatalog==true, amount<=specialDrugLimit) then $c.setPayAmount($c.getAmount()); $c.setRiskLevel("low"); end`。保险理赔规则成百上千条且常变，适合 Drools。
### Q9. 规则引擎的输出为什么要带"命中依据链"？ - **考察点**：命中依据、可解释、可审计。 - **评分维度**： - 输出含 pay_amount/risk_level + hit_rules + reason + version。（4 分） - 可解释：客诉/监管说明"为什么"。（3 分） - 可审计：关联规则版本，决策可回溯。（3 分）
参考答案 规则引擎输出不只给结果，还要给依据链：命中了哪些规则、输入是什么、得出什么结论（如 `pay_amount:1280, risk_level:"low", hit_rules:["R-特药目录内","R-额度充足"], reason:"奥希替尼在目录,1280≤额度30万", rule_version:"v2026.03"`）。价值：① 可解释——客诉/监管能说清"为什么赔/拒"；② 可审计——决策关联到当时生效的规则版本；③ 这是规则引擎相对 LLM 的核心优势（LLM 给不出可审计依据）。
### Q10. 规则版本管理有什么价值？如何实现？ - **考察点**：规则版本管理。 - **评分维度**： - 决策可回溯到当时哪版规则。（3 分） - 灰度发布、回滚。（3 分） - 变更走审批，规则与代码分离。（4 分）
参考答案 价值：监管可能事后审计"这笔拒赔依据哪条规则、当时是否有效"，没有版本化答不上来。实现：每条规则有版本号、生效时间、作者、变更原因；一次理赔结论关联到"当时生效的哪版规则"；支持灰度（新规则小流量）和回滚（异常回上一版）；变更走审批流，不能谁改了线上就变。规则与代码分离（Drools）让业务人员也能维护。
### Q11. 为什么不让 LLM 直接算理赔金额，而要用规则引擎？ - **考察点**：达标线②——规则引擎 vs LLM 算金额（核心考点）。 - **评分维度**： - LLM 概率性会算错、不一致、不可审计。（5 分） - 规则引擎确定性、可复现、自带依据+版本、合规友好。（5 分） - 正确分工：LLM 理解+调度，规则引擎算账。（加分）
参考答案 金额必须精确可复现，LLM 是概率模型——可能算错（"五百"当 500 但上下文错）、每次结果还不一致、且无法说清"为什么是这个数"（不可审计），不满足保险监管。规则引擎：确定性、结果可复现、天然记录命中规则和版本、可热更新、合规友好。正确分工：LLM 负责理解用户诉求、调度工具、组织话术；规则引擎（Drools）负责"算账"（金额/风险/拒赔）。这正是不该让 LLM 直接做硬决策的根本原因。
--- ## L4 场景（医疗保险综合） ### Q12. 场景题：特药理赔 Agent 收到"PA-2024-123456 报销奥希替尼"请求。请描述数据库 Tool 和规则 Tool 如何协作，并说明每一步的安全/正确性保障。 - **考察点**：两工具协作于理赔场景 + 安全落地。 - **评分维度**： - 链路：DB Tool 查保单额度→查目录命中→规则 Tool 算金额/风险。（4 分） - DB Tool 安全：只读/参数化/白名单/超时/审计。（3 分） - 规则 Tool：版本化规则、命中依据、边界处理。（3 分）
参考答案 1) 数据库 Tool（query_policy）查保单额度——安全保障：独立只读账号、参数化（policy_no 占位符）、白名单（只允许 policy 表的指定列）、statement_timeout + LIMIT、审计日志记录谁查了哪张保单。2) 数据库 Tool（query_drug_db）查"奥希替尼"是否在特药目录——同样安全五件套。3) 规则 Tool（Drools calc_claim）输入额度/目录命中/发票额，按版本化规则算出 pay_amount、risk_level，并附带命中依据链（哪条规则、哪版）。边界处理：负数、超额度按比例、重复理赔检测，绝不交给 LLM 自由算。最后 LLM 组织自然语言答案。
### Q13. 场景题：数据库 Tool 被模型诱导生成 `SELECT * FROM policy WHERE holder LIKE '%张%'` 想批量拉所有姓张的保单。你的白名单和审计怎么拦住并留痕？ - **考察点**：白名单拦截 + 审计溯源（安全实战）。 - **评分维度**： - 白名单拒拦：LIKE 条件列/返回字段不在允许范围。（4 分） - 只读账号确保即使执行也无写风险。（2 分） - 审计记录该次拒绝、关联 session、触发告警。（4 分）
参考答案 白名单在应用层校验：① 条件列 `holder` 即使允许，批量 `LIKE '%张%'` 这种无界查询应被限制（如不允许模糊前缀过短、限制返回行数）；② 返回字段白名单只放必要列，杜绝一次性拖出所有字段 PII；③ 若请求超出白名单直接拒绝并返回权限错误（而非执行）。只读账号确保万一执行也不会写/删。审计日志记录：这次查询被白名单拒绝、触发方（哪个用户 session）、时间、原请求，用于异常检测（频繁试探性查询告警）。这正是"纵深防御"——每层都拦一道。
--- ## 评分汇总表 | 题号 | 层级 | 考察点 | 满分 | 建议权重 | |------|------|--------|------|----------| | Q1 | L1 | DB Tool 定位与基调 | 10 | 基础 | | Q2 | L1 | 注入与参数化 | 10 | 基础 | | Q3 | L1 | 两工具分工 | 10 | 基础 | | Q4 | L2 | 安全五件套（达标线①） | 10 | **核心** | | Q5 | L2 | 白名单 vs 参数化 | 10 | 进阶 | | Q6 | L2 | 审计日志设计 | 10 | 进阶 | | Q7 | L2 | 超时与限量 | 10 | 进阶 | | Q8 | L3 | 脚本 vs Drools | 10 | 深度 | | Q9 | L3 | 命中依据链 | 10 | 深度 | | Q10 | L3 | 规则版本管理 | 10 | 深度 | | Q11 | L3 | 规则引擎 vs LLM（达标线②） | 10 | **核心** | | Q12 | L4 | 两工具协作场景 | 10 | 场景 | | Q13 | L4 | 白名单拦截+审计实战 | 10 | 场景 | **总分 130 分**（每题满分 10，按维度给分）。 ## 达标线 - **L1 基础达标**：Q1~Q3 总分 ≥ 24/30，能说清 DB Tool 为何高敏感、参数化防注入原理、两工具分工。 - **达标线①（安全设计）**：Q4 ≥ 9/10，能完整讲清"只读账号/参数化/白名单/超时限量/审计"五件套及纵深防御思想。 - **达标线②（规则引擎应用）**：Q11 ≥ 9/10，能说清 Drools 在理赔风控的用法，及相比 LLM 直接算金额（精确/可复现/可审计/合规）的优势。 - **综合达标（可进下一阶段）**：总分 ≥ 100/130，且 Q4、Q11 均达标，且 L4 两题均 ≥ 7/10（能落地到医疗保险场景）。 - **高风险失分项**：字符串拼接模型参数（注入）、用 DBA/写账号、用黑名单而非白名单、让 LLM 直接算金额、无审计日志——任一出现且不能自圆其说，建议补学 W2D3 后再面。