Claude Code 乱猜字段名 我给它写了一个数据库查询约束 Skill
在尝试通过Claude Code查询保单表时，AI频繁因猜测字段名而导致SQL执行报错，这一问题暴露了数据库查询场景中的核心痛点：人工智能缺乏主动验证表结构的意识。
被 Claude Code 气到的一天
事情是这样的。
我尝试通过Claude Code查询某张保单表的退保记录，目标锁定在最近一个月的数据。下达的指令非常简洁。
Claude响应迅速，立即生成了一段SQL语句。
SELECT id, policy_no, created_at, surrender_amount, status FROM policy_surrender WHERE created_at >= DATE_SUB(NOW(), INTERVAL 30 DAY);初看似乎没什么问题。
然而执行结果却直接报错。
问题在于created_at字段根本不存在。这张表记录创建时间的字段实际名为create_time。
我立即纠正道："字段名应该是create_time，而非created_at。"
Claude回应"抱歉，我马上修改"，随后重新生成了SQL。
SELECT id, policy_no, create_time, surrender_amount, status FROM policy_surrender WHERE create_time >= DATE_SUB(NOW(), INTERVAL 30 DAY);这次字段名对了，但执行依旧报错。
surrender_amount字段同样不存在。该表存储退保金额的字段实际是refund_amount。
我再次纠正，Claude再次道歉并修改。随后发现status也不对，实际字段名为surrender_status。
三个字段全部猜错。
更令人困扰的是，它在编写SQL时完全没有事先查询表结构的意识。这种表现很像一个刚入职的实习生，听到需求直接开始编码，完全不参考数据库文档。
为什么 AI 会"瞎猜"？
这个问题并非Claude Code独有，Kimi、DeepSeek、GPT等模型同样存在。
根本原因在于AI的"常识"与数据库的实际字段名之间存在巨大差异。
AI接触过大量代码和数据库设计，它"熟知"记录创建时间的字段通常命名为created_at、create_time、gmt_create、created_date等。因此当收到"查询某张表"的指令时，它会从经验库中挑选一个最"常见"的字段名。
问题在于，你的数据库字段命名未必符合这些"常识"。
以保险行业系统为例，许多字段命名带有历史遗留特征：
- 有的字段叫
create_time（标准中文拼音风格） - 有的叫
crt_tm（缩写风格） - 有的叫
createdAt（驼峰风格） - 甚至有的叫
c_time（极简风格）
AI猜对的概率大约在四分之一到六分之一之间。在涉及5到10个字段的复杂查询中，它全部猜对的概率可想而知。
更令人担忧的是，AI不会主动表明"我在猜测"。它生成SQL时语气极为自信，仿佛真的查验过表结构一般。只有在执行报错后，你才能发现它是在盲目推测。
我的解法：给 Claude 写了一个 6 步 Skill
经过多次被"折磨"后，我决定不再每次都手动纠正。我为它设计了一个数据库查询Skill，将其塑造成一个"遵守规矩的实习生"。
这个Skill的核心思想十分简洁：在任何SQL编写之前，必须先行查询表结构。这就像老程序员带新人时常说的："先别急着写代码，先看看表里有哪些字段。"
6 步流程
用户查询需求 → 第1步：查表结构 → 第2步：查数据量 → 第3步：判断范围 → 第4步：生成SQL+检查索引 → 第5步：用户确认 → 第6步：执行并保存知识库
第1步：查表结构（最关键）
Claude必须首先执行以下操作。
DESCRIBE policy_surrender;-- 或SHOW COLUMNS FROM policy_surrender;-- 或（PostgreSQL）SELECT column_name, data_type, column_comment FROM information_schema.columns WHERE table_name = 'policy_surrender';然后将结果明确展示给用户，而非悄悄进行。
第2步：查数据量
在生成SQL之前，先确认表的数据量。
SELECT COUNT(*) FROM policy_surrender;第3步：判断范围，防止慢查询
如果数据量超过10万（阈值可自定义），必须暂停操作。
Claude需向用户提示如下：
不是直接执行，而是先进行询问。
第4步：生成 SQL，并检查索引
Claude根据表结构生成SQL，然后自行检查WHERE条件是否能命中索引。
EXPLAIN SELECT * FROM policy_surrender WHERE create_time >= '2025-05-01';如果EXPLAIN结果显示type为ALL（全表扫描），Claude必须向用户发出警告。
第5步：用户确认
Claude将生成的SQL展示给用户，等待用户确认后再执行，不可自行运行。
第6步：保存知识库
查询完成后，Claude将该表的表结构、字段含义、数据量及索引信息保存到项目知识库。
后续用户再次查询该表时，Claude可直接读取知识库，无需重复执行DESCRIBE。
Skill 写成什么样？
Claude Code支持项目专属的Skill（位于.claude/skills/目录）。我的Skill文件内容如下。
# 数据库查询 Skill## 约束规则当用户要求查询数据库时，必须严格遵守以下流程：### 1. 查表结构- 执行 `DESCRIBE {table_name}` 或 `SHOW COLUMNS FROM {table_name}`- 将结果展示给用户- 不准猜测字段名，必须基于实际表结构### 2. 查数据量- 执行 `SELECT COUNT(*) FROM {table_name}`- 如果数据量 > 100000，暂停执行，提示用户缩小范围### 3. 判断范围- 询问用户是否需要加 WHERE 条件- 提供时间范围、ID 范围等建议### 4. 生成 SQL + 检查索引- 根据表结构生成 SQL- 执行 `EXPLAIN` 检查索引命中情况- 如果全表扫描，警告用户### 5. 用户确认- 展示 SQL，等待用户确认- 未经确认不准执行### 6. 保存知识库- 将表结构信息保存到 `.claude/knowledge/db/{table_name}.md`- 格式：字段名 | 类型 | 含义 | 索引- 下次查询同一表时，优先读取知识库## 禁止行为- 禁止猜测字段名- 禁止不查表结构直接写 SQL- 禁止不检查索引就执行大数据量查询- 禁止未经用户确认执行 SQL## 示例用户：查一下 policy_surrender 表最近 30 天的数据正确流程：1. DESCRIBE policy_surrender → 展示字段2. SELECT COUNT(*) → 判断数据量3. 询问用户：是否需要加时间范围？建议按 create_time 查询4. 生成 SQL：SELECT * FROM policy_surrender WHERE create_time >= DATE_SUB(NOW(), INTERVAL 30 DAY)5. EXPLAIN 检查索引6. 展示 SQL，等待确认7. 执行并保存知识库实际效果如何？
Skill上线后，Claude的行为模式发生了显著变化。
以前的表现如下。
我：查一下 policy_surrender 表最近 30 天的数据Claude：（直接生成 SQL，3 个字段名全猜错）现在的表现如下。
我：查一下 policy_surrender 表最近 30 天的数据Claude：我先查一下这张表的表结构。（执行 DESCRIBE，展示结果）这张表有 120 万条数据，建议加时间范围。你想按 create_time 查最近 30 天吗？（我确认后，生成 SQL，EXPLAIN 检查索引，展示给我看）这是 SQL，确认执行吗？（我确认后，执行）结果已保存到知识库，下次查这张表不用重复查结构。不仅字段名不再猜错，更大的收益体现在以下几方面。
- 慢查询被拦截：有几次我差点执行全表扫描，Claude发出提醒后我添加了索引条件。
- 知识库逐渐积累：项目中30多张核心表的结构都被记录下来，新同事询问字段含义时可直接查阅知识库。
- 我无需再反复纠正：它已清楚规则，为我节省了大量口舌。
当然，偶尔仍会遇到需要人工介入的复杂场景。例如字段名特别模糊、中英文混杂，或业务含义与字面意思相差甚远时，Claude查看表结构后仍可能理解错误。这时我会直接告知正确答案，并让它更新知识库——"人工干预、知识库积累、避免重复错误"这一闭环运转起来后，操作越来越顺畅。
其他 AI 工具也能用吗？
这个Skill本质上是一套约束规则，并非Claude特有。
我随后将其改编为Prompt模板，同样适用于Kimi、DeepSeek等工具。
你是一个数据库查询助手。当用户要求查询数据库时，必须按以下步骤执行：1. 先执行 DESCRIBE {table_name}，展示表结构2. 执行 SELECT COUNT(*) FROM {table_name}，判断数据量3. 数据量超过10万时，提示用户缩小范围4. 根据表结构生成SQL，执行EXPLAIN检查索引5. 展示SQL，等待用户确认6. 执行并保存表结构信息禁止猜测字段名。禁止未经确认执行SQL。效果类似，但不如Claude Code的Skill那样自动化——因为Kimi和DeepSeek缺乏直接执行SQL的能力，需要手动复制粘贴。不过约束规则本身依然有效，至少能防止AI胡乱猜测字段名。
我仅在Claude Code上深度使用这个Skill，因为它能即时反馈、直接执行SQL，还能自动优化自身。其他工具我主要用来生成思路和初稿。
写在最后
为AI设定严格的查询流程能有效避免字段误判问题，这揭示了在数据库查询场景中，建立正确工作习惯远比依赖AI自由发挥更为关键。AI的创造力是双刃剑，它敢于猜测、尝试和犯错，但在数据库查询领域，"敢于猜测"恰恰是灾难的根源。一个好的Skill并非限制AI，而是帮助它在特定场景下建立正确的工作习惯。就像带领实习生一样，若没有持续的反复训练，它不会主动先查阅文档再动手编码。Claude Code的Skill机制正是为AI构建"肌肉记忆"的有效工具。如果你也曾因AI乱猜字段名而烦恼，不妨尝试这套6步流程，花费10分钟编写一个Skill，长期节省的纠正时间将远超这10分钟。