对比三种DeepSeek数据库迁移提示词：哪种让AI先给判断标准？

先说几个核心判断。从MySQL 8.0往PostgreSQL 15迁移，并不是所有东西都需要动。有些场景是必须改的，比如SQL语法不兼容、数据类型没有安全映射、索引在PostgreSQL 15里直接失效——这些没得商量。有些则可以跳过，前提是纯ANSI SQL且数据类型完全一致。真正的高危操作，是GENERATED ALWAYS AS这种特性，或者是JSON字段和全文索引混着用，一不留神就会出大问题。

让DeepSeek先输出数据库迁移判断标准

一个很常见的误区是：上来就让AI直接写迁移步骤。结果写出来的东西，要么遗漏关键决策依据，要么缺乏可审计性。正确的做法是，先让它明确“哪些情况必须迁移”、“哪些可以跳过”、“哪些属于高危操作”。换句话说，判定逻辑优先级要在具体执行步骤之前。

关键一步：在提示词开头就强制锚定判断优先级——【必须把‘是否需要迁移’的判定逻辑放在第一条输出，且独立成段，不得与执行步骤混写】。

然后，嵌入三重刚性约束：第一，仅依据SQL语法兼容性、数据类型映射风险、索引失效概率三个维度打分；第二，任何未在MySQL 8.0→PostgreSQL 15官方迁移矩阵中标注的类型转换，一律视为高风险；第三，禁止使用“一般建议”“通常可以”这类模糊表述，每条标准必须含可验证的触发条件，比如“当字段含GENERATED ALWAYS AS时，必须迁移”。

最后，要求模型用表格呈现判断标准。列名固定为“检查项｜触发条件｜风险等级｜依据来源”，其中“依据来源”必须精确到PostgreSQL官方文档章节号或MySQL Release Notes日期，例如“Ref: PG 15 Doc §12.3.2, 2024-06-01”。

两种可立即套用的提示词模板

方法一（精简版，适合内部快速评审）：
“你作为有8年异构数据库迁移经验的DBA，正在为MySQL 8.0→PostgreSQL 15迁移编写技术说明。请严格按以下顺序响应：①先列出迁移必要性的全部判断标准（仅限语法、类型、索引三类），每条标准带明确触发条件和风险等级；②再给出具体迁移步骤。禁止合并①②两部分。”

方法二（审计强化版，含错误拦截机制）：
“角色：金融级数据库迁移合规审查员（持有OCI-DP认证，处理过37次核心账务系统迁移）。任务：生成MySQL 8.0→PostgreSQL 15迁移说明。硬性要求：1. 首段必须是‘迁移准入判断表’，含四列且无合并单元格；2. 表中任意一条标准若缺少‘依据来源’，整份输出作废；3. 当检测到JSON字段、全文索引、自增主键混合使用场景时，必须在判断表首行标红警示。现在开始。”

来源：互联网