---
name: dri-text-analysis
description: 使用 DRI 文本分析法（Data-Rule-Interaction）对自然语言需求描述进行逐词拆解与领域建模。将非结构化的业务需求文本降维为数据(D)、规则(R)、交互(I)三个维度的结构化架构抽象，直接产出可用于系统设计的概念表格。适用于需求分析、领域语言提取、架构设计前的文本解析，以及将长篇需求文档转化为清晰的开发任务拆解。
---

# DRI 文本分析法 (Data-Rule-Interaction Text Analysis)

一种将自然语言业务需求降维拆解为系统设计基石的分析标准。本质上是在做**需求工程中的领域语言（Ubiquitous Language）提取**，对后续的面向对象设计、数据库建模、接口设计乃至代码脚手架生成都极具价值。

## 何时使用此技能

当用户有以下行为时使用此技能：

- 提供了一段业务需求描述，需要从中提炼系统的数据模型、业务规则和交互边界
- 说"帮我分析一下这段需求"或"把这段文字拆解成系统设计"
- 说"对项目进行DRI分析"或"用DRI方法解析需求文档"
- 想在动手写代码前，先把需求文档转化为结构化的架构抽象
- 需要检查需求是否存在断层（有数据没交互、有交互没规则等）
- 正在做领域建模，需要从自然语言中提取实体、服务、接口等概念
- 想把长篇需求文档拆解为可分配给不同技术组件的开发任务

## 核心概念

### 三元抽象模型

软件系统的核心目的是：**接收外部指令，处理信息，并保存状态。** DRI 模型用三个维度完整覆盖：

```
┌──────────────────────────────────────────────┐
│                                              │
│   触发(I) ──→ 执行(R) ──→ 读写(D)           │
│                                              │
│   反馈(I) ←── 回调(R) ←── 变化(D)           │
│                                              │
└──────────────────────────────────────────────┘
```

数据是**体**，规则是**法**，交互是**相**。

此模型与经典 ECB 模式（Entity-Control-Boundary）高度契合：

| DRI 概念 | ECB 模式 | 六边形架构 | Clean Architecture |
|---------|----------|-----------|-------------------|
| 数据 (D) | Entity | Domain Model | Entities |
| 规则 (R) | Control | Application Service | Use Cases |
| 交互 (I) | Boundary | Port / Adapter | Interface Adapters |

### [D] 数据 (Data) — 系统的"状态"与"资产"

回答 **"系统里有什么"**。

- **词性特征**：名词、名词短语、特定数值、状态枚举词。
- **识别依据**：它是否代表了系统中需要被"记住"、"存储"、"查询"或"更新"的信息？
- **子分类**：
  - **实体 (Entity)**：具有唯一标识和生命周期的业务对象（如 `监控节点`、`画面帧`）
  - **属性 (Attribute)**：实体的具体特征值（如 `温度数值`、`运行状态`）
  - **常量/配置 (Constant)**：阈值、枚举值等（如 `80度`、`异常`）
  - **流/资源 (Stream/Resource)**：瞬态或持久化的数据资源（如 `视频流`、`现场截图`）
  - **消息 (Message)**：系统间传递的数据载体（如 `报警通知`）
- **典型词汇**：记录、数值、状态、属性、配置、快照、列表、模型、上下文

### [R] 规则 (Rule) — 系统的"引擎"与"法则"

回答 **"系统如何运作"**。

- **词性特征**：表示计算、判断、比较的动词，条件关联词。
- **识别依据**：它是否定义了事物变化的条件？是否包含 If-Then 逻辑、数学运算或约束？
- **子分类**：
  - **条件判断 (Condition)**：If-Then 逻辑的触发条件（如 `如果...连续3秒超过...`）
  - **阈值比较 (Threshold)**：数值比较运算（如 `超过`、`大于`、`等于`）
  - **时间约束 (Temporal)**：涉及时间窗口的判定（如 `连续3秒`、`每隔5分钟`）
  - **领域服务 (Domain Service)**：封装的复杂业务逻辑链（如 `火灾智能推理逻辑`）
  - **状态变更 (State Transition)**：实体状态的转换动作（如 `更新为异常`）
  - **数据处理 (Processing)**：数据转换、提取、计算（如 `提取温度`、`计算平均值`）
- **典型词汇**：如果、判断、超过、匹配、计算、过滤、验证、触发、转换

### [I] 交互 (Interaction) — 系统的"边界"与"触角"

回答 **"系统由谁触发，又影响谁"**。

- **词性特征**：表示动作转移、跨越边界的动宾短语，外部系统/物理设备的专有名词。
- **识别依据**：它是否涉及信息的输入/输出（I/O）？是否是系统与外部世界的触点？
- **子分类**：
  - **入站 (Inbound)**：外部 → 系统的数据流入（如 `接收视频流`、`用户点击`）
  - **出站 (Outbound)**：系统 → 外部的数据流出（如 `发送通知`、`渲染画面`）
  - **外部角色 (Actor)**：与系统交互的人或第三方（如 `管理员`、`玩家`）
  - **外部设备/渠道 (Channel)**：I/O 的物理或逻辑载体（如 `摄像头`、`企业微信`、`API 接口`）
- **典型词汇**：点击、接收、发送、接口、推送、显示、上传、下载、渲染

### [O] 其它 (Other)

连词、介词、代词等语法结构词（如"的"、"地"、"将"、"和"），在系统建模中无实际抽象价值，标注时忽略。

## 分析流程

### 第一步：行内逐词标注

对原始文本逐词或逐词组进行拆解，在关键短语后紧跟方括号标签。

**标注语法**：`词汇[标签:子分类]`

标签取值：
- `D:实体` `D:属性` `D:常量` `D:流数据` `D:消息` `D:状态枚举`
- `R:条件起点` `R:阈值比较` `R:时间约束` `R:领域服务` `R:状态变更` `R:处理动作`
- `I:输入设备` `I:输入动作` `I:输出渠道` `I:输出动作` `I:外部角色` `I:接收端`

### 第二步：概念抽象汇总表

将标注结果合并提炼，输出为结构化表格：

| 抽象维度 | 提取出的具体概念 | 系统设计映射 | 备注/设计建议 |
|---------|----------------|------------|-------------|
| **数据 (Data)** | 从标注中提取的所有 D 标签内容 | 领域模型/实体、配置项、持久化表设计 | 瞬态 vs 持久化、可配置 vs 硬编码 |
| **规则 (Rule)** | 从标注中提取的所有 R 标签内容 | 核心算法、领域服务、状态机 | 需重点编写单元测试的部分 |
| **交互 (Interaction)** | 从标注中提取的所有 I 标签内容 | 入站网关、出站网关、UI 组件 | 容错、重试、并发处理 |

### 第三步：断层检查

完成表格后执行 D-R-I 交叉验证：

1. **数据无交互**：存在数据但没有任何交互去创建/修改/读取它 → 需求可能遗漏了输入输出。
2. **交互无规则**：存在交互（如接收数据）但没有规则去处理 → 需求可能遗漏了业务逻辑。
3. **规则无数据**：存在规则但没有操作的目标数据 → 规则可能是冗余的或数据定义缺失。
4. **孤立实体**：某个数据实体既不被规则引用，也不通过交互暴露 → 可能是过度设计。

## 完整案例

### 原始文本

> "监控系统通过摄像头实时接收视频流，提取当前画面帧的温度数值。如果温度连续3秒超过80度，则触发火灾智能推理逻辑，系统自动通过企业微信向管理员发送包含现场截图的报警通知，并在数据库中将该监控节点的运行状态更新为异常。"

### 步骤一：行内标注

> 监控系统`[I:接收端]` 通过 摄像头`[I:输入设备]` 实时接收`[I:输入动作]` 视频流`[D:流数据]`，提取`[R:处理动作]` 当前画面帧`[D:实体]` 的 温度数值`[D:属性]`。如果`[R:条件起点]` 温度`[D:属性]` 连续3秒`[R:时间约束]` 超过`[R:阈值比较]` 80度`[D:常量]`，则触发`[R:状态变更]` 火灾智能推理逻辑`[R:领域服务]`，系统自动通过 企业微信`[I:输出渠道]` 向 管理员`[I:外部角色]` 发送`[I:输出动作]` 包含 现场截图`[D:流数据]` 的 报警通知`[D:消息]`，并在数据库中将该 监控节点`[D:实体]` 的 运行状态`[D:属性]` 更新为`[R:状态变更]` 异常`[D:状态枚举]`。

### 步骤二：概念抽象汇总表

| 抽象维度 | 提取出的具体概念 | 系统设计映射 | 备注/设计建议 |
|---------|----------------|------------|-------------|
| **数据 (Data)** | 视频流、画面帧、温度数值 | **领域模型**：`VideoFrame`, `Temperature` | 视频流属于瞬态内存数据，画面帧可能需要缓存 |
|  | 80度（阈值常量） | **配置项**：`ALARM_TEMP_THRESHOLD = 80` | 应设计为可配置参数，而非硬编码 |
|  | 报警通知、现场截图 | **消息/资源**：`AlarmMessage`, `ImageResource` | 截图需持久化至对象存储，通知记入日志 |
|  | 监控节点、运行状态、异常 | **持久化实体**：`MonitorNode (Status: Normal/Error)` | 对应数据库中的节点表及状态枚举字段 |
| **规则 (Rule)** | 提取（温度） | **数据处理**：图像识别/传感器数据解析算法 | 将非结构化数据转化为结构化数据 |
|  | 如果...连续3秒超过... | **推理引擎/状态机**：时序数据滑动窗口判断 | 核心业务规则，需重点编写单元测试防误报 |
|  | 触发火灾智能推理逻辑 | **领域服务**：`FireReasoningService` | 封装复杂的判定链条 |
|  | 更新为（异常状态） | **状态变更**：`Node.setStatus(ERROR)` | 确保状态变更的原子性和一致性 |
| **交互 (Interaction)** | 摄像头、接收 | **入站网关**：视频流接收端口/硬件驱动 | 需考虑高并发与网络延迟的容错边界 |
|  | 企业微信、管理员、发送 | **出站网关**：企业微信 Webhook API 客户端 | 需处理网络调用失败的重试机制 |

### 步骤三：断层检查

- ✅ 所有数据均有对应的规则进行处理
- ✅ 所有交互均有对应的规则进行衔接
- ✅ 所有规则均有明确的数据操作对象
- ⚠️ 潜在遗漏：未提及"报警通知"的持久化存储（是否需要记录历史报警？）

## 输出模板

分析完成后，按以下结构组织输出：

```markdown
## DRI 分析结果

### 一、行内标注

> [在此放置标注后的原始文本]

### 二、概念抽象汇总表

| 抽象维度 | 提取出的具体概念 | 系统设计映射 | 备注/设计建议 |
|---------|----------------|------------|-------------|
| **数据 (Data)** | ... | ... | ... |
| **规则 (Rule)** | ... | ... | ... |
| **交互 (Interaction)** | ... | ... | ... |

### 三、断层检查

- [x] / [ ] 数据覆盖检查
- [x] / [ ] 规则覆盖检查
- [x] / [ ] 交互覆盖检查
- ⚠️ [列出发现的遗漏或冗余]

### 四、设计建议

[基于分析结果给出的架构层面建议]
```

## 标注注意事项

- **一词多标**：同一个词在不同上下文中可能属于不同维度。如"温度"单独出现时是 `[D:属性]`，但"提取温度"中的"提取"是 `[R:处理动作]`。
- **粒度把控**：标注粒度以"对系统建模有意义"为准。虚词不标注。
- **隐含概念**：注意文本中未明确说出但暗示的概念。如"实时接收"暗示了需要"流处理管道"或"消息队列"。
- **领域术语**：对行业特有术语保持敏感，它们往往是核心实体或服务的直接来源。