DeepSeek需按角色、数据库平台、开发阶段三维度精准生成建表提示词：DBA侧重约束索引，后端关注ORM兼容，产品经理只需业务字段说明；必须显式声明数据库版本及语法细节；不同开发阶段对应简化版、加固版或灰度迭代版建表需求。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要让deepseek精准生成适配不同角色、不同数据库平台、不同开发阶段的建表提示词，而不是只输出一条通用sql——因为dba关注字段约束与索引策略，后端工程师需要orm映射兼容性，而产品经理只关心业务字段含义和可见性。按角色视角拆解建表需求
第一步：明确当前使用者身份，直接决定提示词中必须前置的角色声明。【不写角色定义，DeepSeek大概率按通用开发者视角输出，忽略权限控制、审计字段、历史兼容等关键要素】
方法一：面向DBA的提示词结构
“你作为拥有10年Oracle与MySQL双平台经验的数据库架构师，请为电商订单履约系统设计核心表orders的建表语句。要求：主键使用BIGINT自增；created_at与updated_at设为TIMESTAMP WITH TIME ZONE并自动更新；status字段用TINYINT枚举（0待支付/1已支付/2已发货/3已完成/4已取消），加CHECK约束；对user_id、order_no、status三字段组合创建复合索引；禁止使用JSON类型存储地址信息，须拆分为province/city/district三字段。”
方法二：面向后端工程师的提示词结构
“你作为熟悉Django ORM与SQLAlchemy的Python后端工程师，请生成PostgreSQL兼容的orders表建表语句，需满足：字段名与Django Model字段一一对应（如order_no → order_no，not null → blank=False）；created_at用timestamptz类型；status字段用ENUM类型（'pending','paid','shipped','completed','cancelled'）；外键user_id引用users表id字段；自动添加django_migrations兼容的id SERIAL PRIMARY KEY。”
方法三：面向产品经理的提示词结构
“你作为负责B端SaaS订单模块的产品经理，请用中文描述orders表应包含哪些业务字段、每个字段代表什么业务含义、是否必填、是否有默认值、取值范围限制。例如：‘order_no：订单编号，全局唯一，系统自动生成，不可编辑，格式为ORD-YYYYMMDD-XXXXX’。不要输出任何SQL代码，只输出带编号的字段说明清单。”
按数据库平台动态适配
DeepSeek对不同数据库的语法差异敏感度有限，必须显式声明平台类型，否则可能混用MySQL的AUTO_INCREMENT和PostgreSQL的SERIAL。
① 在提示词开头强制锁定平台：【必须写明“我使用的是MySQL 8.0”或“我使用的是PostgreSQL 15”，不能只说“主流关系型数据库”】
② 针对特定平台补全语法细节：
— MySQL场景追加：“启用严格模式，禁用隐式类型转换，字符集统一为utf8mb4，排序规则为utf8mb4_unicode_ci”
— PostgreSQL场景追加：“启用pg_trgm扩展支持模糊搜索，对order_no字段创建GIN索引，启用row-level security策略模板”
— SQL Server场景追加：“主键使用UNIQUEIDENTIFIER DEFAULT NEWID()，启用temporal table版本控制，所有字符串字段使用NVARCHAR而非VARCHAR”
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
③ 当需跨平台兼容时，采用条件指令：“请分别输出MySQL 8.0和PostgreSQL 15的建表语句，两套语句需保证字段语义完全一致，但语法各自符合平台规范；特别注意：MySQL的TINYINT(1)布尔字段在PostgreSQL中必须用BOOLEAN类型替代，且默认值写法不同。”
按开发阶段注入上下文锚点
同一张表，在原型期、上线前、迭代期的建表需求完全不同——提示词必须携带阶段信号，否则DeepSeek无法判断是否允许破坏性变更。
方法一：原型验证阶段
“当前处于MVP快速验证阶段，orders表仅需支撑基础下单流程。请生成最简建表语句：仅包含id、user_id、order_no、total_amount、status、created_at六个字段；所有字段允许NULL；不建索引；不设外键；不启用任何约束；字段类型优先选择开发效率最高的（如MySQL用VARCHAR(255)而非精确长度）。”
方法二：生产上线前阶段
“该表即将部署至日均百万订单的生产环境，需满足高并发写入与复杂查询。请生成加固版建表语句：user_id与created_at组合为分区键（按月RANGE分区）；order_no字段加UNIQUE索引；status字段单独建索引；total_amount用DECIMAL(12,2)确保精度；所有TEXT字段改用MEDIUMTEXT预留扩展空间；禁用任何可能导致锁表的操作（如ALTER TABLE ADD COLUMN）。”
方法三：灰度迭代阶段
“现需在现有orders表中新增discount_amount字段（优惠金额），要求：兼容历史数据（默认值为0.00）；不影响现有应用读写；不触发全表重建；字段位置插入在total_amount之后；同步更新对应的索引覆盖范围。”
