# 设计备注

## 为什么不把 64 卦全塞进 `SKILL.md`

`SKILL.md` 负责启用条件、流程和输出准则，不负责充当整本卦书。  
把所有卦义、爻辞和场景说明都放进去会让上下文成本过高，也不利于按需读取。

## 为什么把资料查询和正式解读分开

用户有时只想查一个卦名或术语，有时则要完整问事。  
把这两种需求拆开后，可以避免在简单查询时也触发整套解卦流程。

## 为什么先整理结构化结果，再生成自然语言结论

如果没有统一的中间结构，不同轮次很容易出现：

- 动爻遗漏
- 本卦与变卦判断混写
- 追问时口径漂移

先整理出本卦、动爻、变卦、问事主题和风险点，再组织自然语言，后续更容易接脚本和 UI。

## 为什么脚本不直接决定解读文案

脚本的职责应是：

- 查询
- 标准化
- 派生变卦
- 保存会话状态

核心解释原则必须保留在文档和模板层，避免脚本逻辑过度绑定具体文案。

## 什么时候只做说明，不做断言

这些情况应优先做知识说明或风险提醒：

- 用户只问术语定义
- 用户没有给出足够问事背景
- 用户想把医疗、法律、投资等决策完全交给卦象
- 输入信息冲突，暂时无法确定唯一卦象