D3 Day 3 View
返回总览 周计划原文 合并文档原文
Ontology

# Day 3 语义本体 MVP

这一天把自然语言问题统一切成 8 个核心字段。Day 3 不是追求大模型多聪明，而是先让结构稳定、可落日志、可被 Orchestrator、User Agent 和 Hermes 共用。

上游依赖
Day 1 的 `SemanticParseLog` / `AgentRun`，Day 2 的资产 API。
下游交接
Day 4 路由、Day 5 查询解释、Day 6 风险巡检都直接消费这 8 字段。
当天关键
名字统一、类型统一、日志统一、低置信度有澄清问题。
Three-Layer Mapping

## 三层文档映射

### 路线图

周计划要求建立用户问题的统一语义解析层，覆盖场景、意图、对象、时间、指标、约束、风险、权限 8 字段。

day_3_semantic_ontology_mvp.md

### 执行细则

执行层拆成 8 字段定义、字段枚举、Schema、解析服务、对象提取、时间范围、指标约束、风险权限、API、前端调试入口和评测集。

agent week plan/day_3

### 架构依据

主要受语义本体、财务标准模型和数据治理约束。应收、应付、报销的对象语义必须能回到最小业务表和标准对象。

02 14 06
Build Order

## 推荐开发顺序

Step 1先固定 8 个字段名字、类型、默认值和示例。
Step 2把 `scenario`、`intent`、`permission.level` 的枚举定死。
Step 3做请求/响应 Schema，再写解析服务。
Step 4补对象提取、时间范围、指标约束、风险和权限映射。
Step 5接 API、日志、调试入口和最小评测集。
Must Deliver

## 今天必须产出的东西

### 8 字段统一结构

- `scenario`、`intent`、`entities`、`time_range`
- `metrics`、`constraints`、`risk_flags`、`permission`
- 附带 `confidence`、`clarification_required`、`run_id`

### 规则解析优先版

- 先用关键词和规则解析打底。
- 报销 / 应收 / 应付 / 知识 / unknown 场景都能落到结构。
- 越权动作能识别为 `approval_required` 或 `forbidden`。

### 日志和调试入口

- 每次解析都要落 `SemanticParseLog`。
- 前端可直接输入一句话看 8 字段结果。
- 低置信度问题必须给澄清问题。

### 最小评测集

- 至少覆盖报销、应收、应付、知识、越权动作。
- 每条样例要写期望 `scenario`、`intent` 和权限级别。
- 当天目标是可评测，而不是追求完美准确率。

Acceptance Snapshot

## 验收快照

语义结构
8 字段在 Schema、服务层、日志里名字完全一致。
关键识别
“本周报销超标风险”“客户 A 本月应收”“供应商 B 明天要付多少钱”都能落到正确场景和意图。
权限结果
“帮我直接付款”不能被识别成可直接执行动作。
日志与前端
连续调用多次都能在日志中查到，并能通过调试入口观察结果。
Common Misses

## 这一天最容易漏掉的点

- 字段结构和日志结构各写一套名字，后面 Trace 很难串。
- 只做 `scenario` 和 `intent`，不做 `permission`，Day 4 会直接失去拦截依据。
- 只在服务里返回结果，不把解析过程落库或落日志，后续无法复盘误判样例。