让 AI 写建表语句、改索引、生成接口文档，第一版通常看着挺像样，问题都在细节里：字段类型不对齐业务、索引看着合理其实用不上、文档和真实代码已经对不上。这篇不讲概念，只给一条能落地的流程和每一步的校验点，帮你判断哪些产出能直接用、哪些必须退回重来。
后端用 AI 写建表语句、调索引、生成接口文档，第一版通常看着挺像样，问题都藏在细节里：字段类型不对齐业务、索引看着合理其实根本走不上、文档和真实代码早就对不上。这篇不讲概念，只给一条能落地的流程，和每一步的校验点，帮你判断哪些产出能直接用、哪些必须退回重来。
一个前提先说清：这三类任务的正确姿势都是「你定口径，AI 出草稿，你按判据验收」。凡是把口径也交给 AI 猜的，回来一定是一堆通用模板，改起来比从零写还慢。下面按喂上下文、审建表、审索引、审文档、以及不该用的场景，逐步过一遍。
第一步：先把你手里的上下文喂够，别急着让它写
建表和索引类任务，最少要给三样东西：现有表结构或 DDL、这张表的读写场景（谁写、谁查、查询条件长什么样）、数据量级区间。只贴一句「帮我设计订单表」，出来必然是通用模板，字段名和类型都得重写。上下文越具体，返工越少。
- 建表任务最小输入
- 现有 DDL + 读写场景 + 数据量级区间，三者缺一产出就偏
- 接口文档最小输入
- 路由定义或函数签名 + 请求响应示例 + 错误码约定，缺了模型会自己编字段名
- 不确定的口径
- 宁可留空让它列假设，也别让它猜；凡是标了「假设」的条目就是你回去确认的清单
- 把表结构片段、公共约定（命名规范、时间字段类型、主键策略）整理成一段固定前置说明，每次复用，比反复口述稳定得多
- 长项目分多次问时，每次都把这段前置说明带上，否则模型会按自己的默认习惯漂移
- 让它先复述一遍它理解的输入，确认没跑偏再让它动手，比事后纠正省事
建表语句拿到手，按这四条逐条过
模型给的建表语句，别急着执行，按下面四类逐条核对。错在字段类型和约束上的，后期迁移代价最大；错在命名和注释上的，影响的是半年后接手的人。
| 核对项 | 看什么 | 常见坑 |
|---|---|---|
| 字段类型与长度 | 金额用定点还是浮点、时间戳带不带时区、字符串长度上限 | 复述业务时用了默认类型，没对齐业务 |
| 约束与默认值 | 主键策略、唯一约束、非空、默认值、外键 | 你没提的地方它自作主张加了或漏了 |
| 命名与注释 | 字段名是否符合团队规范、注释是否写清业务含义 | 注释只是复述字段名，等于没写 |
| 迁移友好度 | 新列是否可空、有无默认值、加索引会不会锁表 | 语句能建但生产跑不动 |
- 先在非生产环境跑一遍把 DDL 放到影子库或本地执行，确认能建、字段对、约束生效，再去考虑上线
- 对照现有库统一做法主键、时间字段、命名风格和已有表比一比，不一致的地方要么改语句、要么在评审里说明原因
- 把「假设」逐条确认产出里标注的不确定项，一条条回去问业务或看代码，确认完再定稿
索引建议不能照抄，先换成执行计划看
索引是这三类任务里最容易翻车的。模型给的联合索引看着有理，套到真实查询上可能压根走不上。所以拿到建议后，第一步不是执行，而是换成执行计划验证。
- 把模型给的索引套到真实查询上，用执行计划确认它到底走没走；没走索引的优化建议等于没给
- 看查询条件的选择性与顺序：模型常按字段出现顺序堆联合索引，实际应按选择性高低和是否等值来排，顺序反了索引基本废掉
- 写入放大要算进去：每加一个索引都会让写入变慢、占存储，读多写少的表可以放宽，高频写入的表要问一句「这个索引值不值」
- 索引不是越多越好，先看现有索引能不能覆盖，再谈新增；能靠调整查询写法规避的，优先不改结构
有几种情况不要盲信任何建议，包括 AI 给的：小表全表扫描可能比走索引更快；数据分布极度倾斜时索引效果有限；统计信息过期时执行计划本身就不可信。先确认自己不属于这几类，再谈优化。
接口文档产出后，对一遍代码再交出去
接口文档最大的风险不是格式丑，是和代码对不上。模型最常见的错误是漏字段、把可选写成必填、只写成功响应不写失败返回。产出后逐项和真实代码或接口测试对照，是必须走的一步。
| 核对维度 | 对什么 | 不通过怎么办 |
|---|---|---|
| 字段级 | 路径、方法、参数名、必填与否、类型、返回结构 | 以代码为准改文档 |
| 错误码与边界 | 各类失败返回、参数校验失败、鉴权失败、限流 | 补齐才算完整 |
| 示例可执行性 | 请求示例实际发一次，请求体和响应体是否对得上 | 对不上就回去改文档 |
| 维护方式 | 文档是否从注释或 Schema 生成 | 纯手写注定会过期 |
维护方式比格式更重要。文档最好从代码注释或 Schema 生成，AI 只用来补描述和示例；纯手写的文档从交付那天起就开始过期。这条决定了你下次是再生成一遍，还是又手动改一轮。
这些情况别指望 AI 一次给对
有几类场景属于高影响操作，AI 可以帮你列检查项，但决策要人来定，并且必须先在没有真实流量的环境里演练。把它们当辅助，不要当结论。
- 涉及线上大表结构变更、分库分表拆分、历史数据迁移的方案，属于高影响操作，必须先在非生产环境演练
- 性能瓶颈已明确但根因复杂（锁竞争、连接池、慢查询混合）时，把执行计划和监控指标一起给模型做辅助分析，别拿它的一句话结论当定论
- 合规或审计要求严格的库表，字段命名和注释有硬性规范，产出必须过人工评审，不能直接执行
- 任何可以直接对生产库执行 DDL 的场景，都不要让 AI 直连，产出走人工审核加变更流程，这是底线不是建议
反过来，低风险场景可以放心用：新表草稿、本地库试验、文档初稿、查询改写的备选方案。判断标准就一条——产出错了，能不能在影响业务之前被发现。
下一步想对比各家模型在代码类任务上的表现，或找能接进本地开发流的工具，可以先到站内的工具目录和模型资料库看看当时的整理，再决定用哪个干活。→常见问题
AI 生成的建表语句能直接在项目里用吗？
新项目、新表、本地开发环境可以先跑一遍再人工调整，成本不高。但生产库的表结构变更不要直接执行，尤其是大表加列、改类型、加索引这几类，先在影子库或测试环境验证，确认锁表时间和回滚方案，再走变更流程上线。
索引优化建议怎么判断靠不靠谱？
唯一可靠的办法是把查询放到真实或接近真实的数据量上跑执行计划。看它是否命中、扫描行数降了多少、代价估算是否合理，再对比加索引前后的写入开销。数据量太小或统计信息不准时，结果都不足以支撑结论，这种时候先别下判断。
让 AI 写接口文档，怎么防止它和代码脱节？
把文档生成挂在代码定义或 Schema 上，让 AI 负责补描述、补示例、补错误码说明，而不是从零手写结构。每次接口变更后重新生成一遍并人工核对字段级差异，比事后补救省事。纯手写文档在多人协作的项目里几乎一定会过期。
