校园二手教材交易平台正在开发中，核心业务是学生发布和购买教材、提交评价。实体层面需要覆盖学生、教材、订单、评价四个角色，关键动作包括ISBN唯一校验、分类标签绑定以及订单状态的流转。下面是一套可以直接交给开发团队的数据库设计——不是“建议范式”，而是每张表、每个索引、每条约束都能落地执行。

先锚定一条原则：让Codeium生成的SQL脚本拿过来就能跑，而不是一堆抽象建议。怎么做？其实就四步：给足上下文、锁定输出格式、过滤废话、验证可执行性。

明确角色与上下文输入

向Codeium提问前，先写一段结构化背景。不要空泛地“设计一个数据库”，要明确业务主体、核心实体和关键动作。例如：
“我们正在开发一个校园二手教材交易平台，主要实体有学生、教材、订单、评价；学生可发布教材、下单购买、提交评价；教材需支持ISBN唯一校验和分类标签。”

这一步不能省。缺少具体实体和动词，Codeium很容易吐出“建议使用外键”这种正确的废话，根本导不出CREATE TABLE。

强制要求输出格式为可执行SQL+注释

在提示词末尾明确指定输出结构：

“请按以下格式输出：① 每张表单独用```sql```包裹；② 每条CREATE TABLE语句上方用中文注释说明该表解决什么业务问题；③ 所有字段必须标注是否NOT NULL、默认值、索引类型（如PRIMARY KEY / UNIQUE / INDEX）；④ 外键必须显式写出REFERENCES及ON DELETE行为。”

【不写明ON DELETE行为会导致后续迁移脚本执行失败】

过滤抽象建议，只保留落地项

方法一：用否定指令排除无效内容

在提示词中加入：“不要出现‘可以考虑’‘建议评估’‘需结合实际’等模糊表述；不解释第三范式原理；不讨论MySQL vs PostgreSQL选型。”

方法二：用正向锚定限定范围

追加一句：“仅输出以下6类内容：1. CREATE TABLE语句 2. ALTER TABLE添加索引语句 3. COMMENT ON COLUMN注释 4. INSERT示例数据（仅1条）5. 必要的CHECK约束 6. 触发器定义（仅当涉及状态自动更新时）。”

这两条指令拼进提示词里，就能把Codeium从“建议模式”直接拽进“执行模式”。

验证输出是否具备可执行性

拿到生成的SQL后，别直接跑，先做四件事：

第一步：检查每张表的主键定义。类型必须是BIGINT或UUID（INT在数据量起来后会成为扩容瓶颈）。

第二步：逐行扫描外键字段。确认REFERENCES后跟的是完整表名+字段名，比如REFERENCES students(id)，而不是REFERENCES users(id)这种错配。

第三步：用EXPLAIN ANALYZE模拟查询，验证索引是否覆盖了WHERE + ORDER BY的组合场景。如果没覆盖，说明Codeium漏掉了复合索引。

第四步：复制所有SQL到本地PostgreSQL实例执行。一旦遇到ERROR: type "jsonb" does not exist，立刻删掉该字段，改用TEXT加应用层解析——【Codeium默认生成jsonb但SQLite不支持，必须手动降级】