库设计需以业务动作为锚点定义意图，每个意图须源自真实操作、绑定数据上下文、按事务边界划分粒度，并映射到可执行技能路径。

在库设计中明确使用意图，核心是把“用户想做什么”和“系统该响应什么”精准对应起来。这不是简单罗列功能，而是围绕业务动线，用意图作为锚点组织数据、逻辑与交互。

意图要从真实业务动作中提炼

意图不是凭空定义的，它来自对一线操作的观察和归类。比如仓库场景里，“发起调拨”“确认出库”“查询库存异常”都是可识别、可触发、有明确结果的动作。每个意图背后对应一个最小闭环任务，而不是模糊的“管理库存”这类宽泛表述。

• 避免把岗位职责直接当意图（如“库管员日常工作”太泛）
• 优先选取有输入、有处理、有输出的动作节点（如“扫描PDA完成拣货确认”）
• 同一类动作的不同变体可归为子意图（如“紧急补货申请”和“常规补货申请”可同属“发起补货”意图）

意图需绑定明确的数据上下文

一个意图生效的前提，是它能关联到具体的数据实体和状态。例如“执行退货入库”这个意图，必须能定位到原始采购单号、退货物料批次、当前库位、质检结果等字段。没有上下文支撑的意图，在数据库层面无法建模，也难以触发准确的技能逻辑。

• 每个意图至少关联1个核心实体（如单据、物料、库位）
• 标注该意图依赖的关键属性（如“发货确认”需依赖“发货单状态=待确认”“物料已齐套”）
• 注明可能改变的数据状态（如“调拨完成”会更新源库位和目标库位的库存数量）

意图边界决定库表结构划分

意图的粒度直接影响数据库概念设计中的实体拆分和关系定义。粗粒度意图容易导致大宽表和冗余字段；过细则增加关联复杂度。合理做法是按事务边界划分：一次完整业务动作涉及的数据集合，就构成一个局部信息结构。

• “创建入库单”和“审核入库单”宜拆为两个意图，对应不同状态字段和操作权限
• “生成盘点任务”和“提交盘点结果”虽属同一业务流，但因数据写入时机和校验规则不同，应分属不同实体或视图
• 跨意图共享的数据（如物料主数据）应独立建模，不随某单一意图耦合

意图要能映射到可执行的技能路径

最终落地时，每个意图都应导向一段确定的处理逻辑。这意味着在设计阶段就要预判其技能实现所需的数据库访问模式——是查一张表？连三张表？是否需要实时聚合？这些都会反向约束索引设计、视图封装甚至分库分表策略。

• 高频查询意图（如“扫码查当前库位库存”）需保障单表响应效率
• 复合操作意图（如“一键关账”）应提前规划事务边界与锁范围
• 带审批流的意图（如“超限领料申请”）要预留状态流转字段和日志追踪能力