diff --git a/超音数设计思路.md b/超音数设计思路.md
index a048a5d..333ba48 100644
--- a/超音数设计思路.md
+++ b/超音数设计思路.md
@@ -24,7 +24,6 @@
 
 <img alt="supersonic_components" src="https://github.com/tencentmusic/supersonic/assets/3949293/23b396c2-d832-430e-936d-0a23b4085aea" height="50%" width="50%" >
 
-
 ### Semantic Layer
 
 当AI领域的LLM满级输出吸走大部份聚光灯的时候，BI领域也有一位召唤师在猥琐发育——它就是Semantic Layer（另一种常见叫法是Metric Store）。所以它的核心价值是什么？我们可以用两个拟人化的角色来类比：
@@ -61,7 +60,16 @@ Schema mapper会将所有达到匹配阈值要求的schema项及其相似度得
 
 ### Rule-based Parser
 
+针对前文提到的效率问题，除了做时间的朋友，等待LLM进化突破之外，还可以想办法在应用层规避。比如，对于一些简单的问题输入，可以尝试基于规则来做语义解析，这也是从Google Analyza论文里带来的启发。这就是Rule-based Parser的由来。
 
+当前的设计方案是，通过经验整理一份表单，如下表所示，明确列举每类语义对象（指标/维度/取值/时间/算子）的组合会映射到哪一种查询意图。Rule-based parser再根据schema mapping的结果，从表单中查到对应的查询意图，这个有点类似slot filling的思路。
+
+<img width="1630" alt="rule-based parser slot-filling" src="https://github.com/tencentmusic/supersonic/assets/3949293/1df91461-6f09-45c5-bde0-607deab28a10">
+
+引入Semantic Parser的抽象，分别有rule-based和LLM-based的实现。输入问题首先经过rule-based parser，如果有查询意图命中，则根据启发性算法来决定是否可以跳过LLM-based parser。当前，启发性算法会根据schema mapping命中的词汇总长度除以问题总长度来判断，超过配置的阈值则认为规则可以满足需要，决定跳过LLM，如果跳过那么提升效率的目的就达到了。
+
+与此同时，semantic parser可以定制扩展，并通过SPI配置的方式替换或补充超音数的默认实现，也可以选择完全去掉rule-based parser配置。
 
 ### Chat Plugin
 
+