用gemini生成数据库字段说明时，需剔除“该字段表示…”等空洞套话，代之以真实约束；必须基于真实ddl反向推导，并明确写入服务、读取方、取值来源等业务动词与数据流向。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
用Gemini生成数据库字段说明时，字段描述千篇一律、全是“该字段表示…”“用于存储…”“一般为…”这类空洞句式，开发查表时得反复确认业务含义，联调时间被无谓拉长。
砍掉三类默认套话
打开Gemini对话框前，先删掉你习惯写的三句话：❌“该字段表示用户ID”❌“用于记录创建时间”❌“一般为非空”。这三句一出现，模型立刻触发训练集中高频的“字段模板库”，自动补全成“该字段表示…，类型为…，长度为…”，不带任何业务上下文。
把“该字段表示用户ID”替换成“【用户注册时由auth_service分配的64位整数，不可修改，关联t_user_base.id】”——方括号里的内容必须是真实约束，不是形容词。
把“用于记录创建时间”改成“【UTC时区，精确到毫秒，由DB触发器自动生成，不接受客户端传入】”。
【若字段在真实建表SQL中未设DEFAULT或NOT NULL，description里禁止出现‘默认为NULL’‘建议非空’等虚构约束】
用真实建表语句反向锚定
方法一：直接粘贴DDL片段
在提示词开头插入你刚从生产环境导出的真实建表语句（哪怕只有一行）：created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NOW()，然后写：“以上字段的description须严格基于此DDL反推语义，不得添加DDL未体现的逻辑。”
方法二：标注字段在SQL中的物理位置
告诉Gemini：“字段在CREATE TABLE语句中位于第7列，前一列为status INT，后一列为updated_by VARCHAR(32)”，它会据此推断该字段大概率是操作时间戳而非业务时间。
这一步操作起来很简单，直接复制pg_dump或SHOW CREATE TABLE结果就行。但注意：不能替换为created_at DATETIME这种伪代码，否则Gemini会按MySQL默认行为补全“可为空”“无默认值”等错误假设。
强制绑定业务动词与数据流向
第一步：识别字段是否参与关键路径
在提示词中明确写：“若字段名含‘_at’‘_time’‘_ts’，且类型为TIMESTAMP/TIMEZONE，则description必须包含其被哪个服务写入、被哪个报表读取。例如：【由order_service写入，下游BI宽表daily_order_summary每日02:00同步】。”
第二步：区分写入源与校验规则
对user_id这类字段，禁止只写“用户唯一标识”，必须拆解：“【前端JWT payload中sub字段解码所得；若为空则拒绝写入；不接受数据库自增】”。
第三步：枚举所有真实取值来源
不要写“可能来自注册/登录/第三方授权”，要写：“取值仅来自/auth/login（code=200）、/auth/wechat/bind（code=201）、/auth/admin/create（code=200），三者返回格式一致”。
