是否放入参考样例取决于模型理解力、项目复杂度和输出确定性要求；需放样例的三种场景：陌生业务域锚定范式、多义需求强制区分实体与状态、PostgreSQL高级特性需最小可行样例。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
在Cursor中写数据库表设计提示词时，是否放入参考样例取决于你当前的AI模型理解力、项目复杂度和你对输出确定性的要求——如果提示词里不放样例，AI可能生成符合命名规范但字段语义偏差较大的结构；如果放错样例，它会机械套用格式而忽略业务逻辑。
需要放参考样例的三种明确场景
方法一：当你刚接手一个陌生业务域（如保险理赔、高校排课），且团队已有成熟表结构沉淀
直接贴出1张真实表的建表SQL（含注释、索引、软删除字段），并标注【此为团队现行user_profile表规范】。AI会锚定这个结构范式，自动继承id/bigserial、created_at/updated_at/deleted_at、status/lang等基础字段，避免漏掉团队强制约定。
方法二：当需求描述存在多义性，例如“用户积分”可能指累计值、可用值、冻结值
此时在提示词末尾追加一句：“参考样例：积分记录表需拆分为user_point_log（流水）与user_point_balance（余额快照），字段含point_type varchar(20) not null comment 'INCOME/EXPENSE/FROZEN'”。这能强制AI区分实体与状态，而不是笼统建一张user_point表。
方法三：当使用PostgreSQL且需触发器或分区策略
Agents 正在你的整个代码库中处理越来越复杂、运行时间更长的任务。本次版本引入了新的 agent 框架改进，以实现更好的上下文管理，并在编辑器和 CLI 中带来了许多提升使用体验的修复。
必须给出带PARTITION BY RANGE (created_at)或CREATE TRIGGER ... BEFORE INSERT的最小可行样例。因为Cursor内置的PostgreSQL知识库对高级特性覆盖有限，不给样例时AI大概率生成语法错误或不可执行的伪代码。
不放参考样例反而更稳妥的情况
第一步：确认你的Cursor已启用Windsurf插件并加载了团队SQL模板（如sql-create-template.md）
第二步：在提示词开头明确声明：“严格按sql-create-template.md中的命名规范与基础字段生成，禁止自行增减字段”
第三步：用自然语言精确约束业务规则，例如：“订单表必须包含origin_channel varchar(32) not null comment '来源渠道：app/wechat/pc'，且该字段需建立idx_origin_channel索引”
这种写法下，AI会优先调用本地模板而非依赖记忆中的模糊样例，生成结果稳定性更高。若同时塞入外部样例，反而可能引发模板与样例冲突，导致created_by字段被遗漏或lang字段类型写成char(5)。
放样例时最关键的避坑点
只保留一张最核心的表作为样例，且【必须删除样例中所有业务敏感字段名，替换成通用占位符】。例如把真实的“insured_id bigint not null”改成“subject_id bigint not null”，否则AI会误判“insured_”是固定前缀，在新表中强行复制出insured_order、insured_product等错误命名。
