请按第三范式（3NF）设计：基于“客户手机号”“下单时间”“商品单价”“所属城市名称”“客户所在省份”等业务字段，识别传递依赖拆分地区表；明确“客户姓名/手机号/邮箱”与“商品编号/名称/类目ID”为稳定语义组；每张表须标注PK/FK，外键注明引用关系及业务含义，如“user_id → users.id，关联用户主数据以统一维护客户信息”。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要让Kimi帮你设计符合范式要求的数据库表结构，但直接提问往往得到宽泛、冗余或违反第三范式的方案——比如把用户姓名和订单金额塞进同一张表，后续改名就要遍历所有订单记录。
明确告诉Kimi你要第几范式
在提示词开头就写清“请按第三范式（3NF）设计”，不要只说“合理设计”或“规范设计”。Kimi没有内置范式判断能力，它不会主动拆分冗余字段，必须用明确术语锚定约束条件。
这一步漏掉，Kimi大概率输出一张大宽表，看着整齐，实际埋下更新异常隐患。
提供带业务语义的原始字段清单
方法一：列原始业务描述，而非技术字段名
写“客户手机号”“下单时间”“商品单价”“所属城市名称”“客户所在省份”，而不是“phone”“create_time”“price”“city_name”“province”。Kimi能据此识别出“城市名称”和“省份”存在传递依赖，从而推导出需拆出地区维度表。
一键设置，在 OpenClaw 和 Claude Code CLI 中使用 Kimi K2.5 (Kimi Code) 作为编程模型。Kimi Code 兼容 Anthropic Messages API——替换……
方法二：显式标注重复出现的语义组
例如在清单末尾加一句：“注意，‘客户姓名’‘客户手机号’‘客户邮箱’总是一起出现，且不随订单变化；‘商品编号’‘商品名称’‘类目ID’也总是一起出现，且不随订单数量变化。”【这是触发Kimi执行1NF→2NF→3NF分步推理的关键信号】
强制它输出带主外键说明的建表语句
第一步：要求每张表必须注明主键（PK）和外键（FK）
第二步：要求外键必须写明引用来源，例如“user_id → users.id”“product_id → products.id”
第三步：要求对每个外键补充一句简短业务解释，如“订单表通过user_id关联用户主数据，确保客户信息统一维护”
不加这条约束，Kimi可能只给CREATE TABLE语句，却不标外键，甚至把user_id设为普通索引。你拿到后还得人工补全参照完整性逻辑，等于白跑一趟。
这一步操作起来很简单，直接把三行要求粘贴进提示词末尾就行。
