Claude数据库字段说明提示词怎么生成可直接用的版本

你有没有遇到过这种情况：明明给了一段接口返回的JSON，想让它自动生成字段说明文档，结果每次出来的东西都掺着“可能”“一般”“建议”这类模糊词。字段类型给你标个“字符串”，但到底是UUID还是纯数字，它根本没区分。嵌套结构直接被压平，层级信息丢失得一干二净——开发写DTO的时候字段对不上，测试造数据的时候反复报错，项目节奏被拖得一塌糊涂。

其实这不是Claude的错，而是提示词的粒度不够精确。下面这套方法，已经被验证过可以在多次生成中稳定产出可直接用的字段说明。

第一步：强制三段式推理路径

明确告诉模型，它必须按固定流程处理这件事，不能跳过任何环节。在提示词最前面插入一条指令——

——作为不可跳过的流程锚点。

紧接着用编号把三步清晰分开：1. 先分析→2. 再判断→3. 最后输出。

• 第1步
  ：要求模型逐字段提取key、value示例值、数据类型（string/number/object/array）、是否必填。这一步是基础数据拆解，不能含糊。

• 第2步
  ：必须标注该字段在业务中的实际含义。举个例子，order_id不是“单纯字符串”，而是“支付系统生成的幂等标识符”。这一步是在做业务上下文嵌入。

• 第3步
  ：只有在前两步完成之后，才能生成带中文说明的字段列表。

关键操作是在第3步指令末尾加上这句话——

。别小看这个句，少了它，模型就会跳过判断直接编造描述。

第二步：用带干扰项的样例反向约束分析粒度

光给指令还不够，还要在样例里埋下“陷阱”，迫使模型必须真正理解字段含义，而不是套模板走流程。

在提示词里粘贴这个JSON：{"status": 0, "data": {"items": [{"id": "abc", "price": "99.5"}]}}，同时强调：

。这样模型必须先识别类型与业务含义之间的错位，才能正确进入输出阶段。

在样例里加入"tags": []和"remark": null这类值，并要求：

。这种设计让模型无法靠模板填充，必须逐项判断。

第三步：关闭自由发挥通道

模型最擅长的就是“凭经验补全”，而我们恰恰需要它停下来、只基于给定数据做判断。怎么做？在提示词末尾写入硬性禁令：

• 禁止出现“可能”“一般”“通常”“建议”等模糊表述；
• 所有字段说明必须基于当前JSON中真实出现的值推导；

• 【若字段值为数字但无小数点，则不得描述为“浮点数”】
  。

这三条禁令加在一起，相当于关掉了模型凭经验编造数据的通道。它只能从你给的JSON出发，做“确定性”判断。

第四步：注入MySQL上下文锚点防止漂移

Claude容易在生成过程中“漂移”——明明在说字段说明，它突然给你回到通用语法定义上去。如何避免？用MySQL建表的现实约束把它牢牢“钉”住。

：先声明数据用途——“本批字段将用于MySQL 8.0表orders的建表语句生成，字段名与嵌套路径已固定。”

：给出DBA确认过的字段约束原文——“根据DBA确认，order_id为VARCHAR(32)，NOT NULL且需加索引；price为DECIMAL(10,2)；status为TINYINT，取值0/1/2分别对应待支付/已支付/已取消。”

：指定输出格式——“仅输出Markdown表格，列头为字段名｜类型｜是否必填｜说明，不加任何额外文字、不换行、不补空行。”

切记，这三步一个都不能少。只写一句“要字段说明”的话，Claude大概率会输出带缩进的树状图或YAML格式，根本没法直接贴进建表SQL里用。