需求文档写了三行,剩下的 AI 给你补齐

AI 无法替代你理解业务，但它可以替代你「翻代码」。文档是等不来的，AI 是用出来的。

|0x00 一个很真实的场景

某次迭代需求来了，业务分析侧给了一份文档，里面列了一百多个字段的中文名和英文名，然后就没了。

没有来源表，没有加工逻辑，没有命名规范说明，没有自测方法。这不是个别现象，是常态。

传统上，这种文档到数仓手里，得花大量时间一个字段一个字段地核对来源，然后逐行写代码，最后再手工设计测试用例。

现在不用了。

|0x01 整体思路：给 AI 喂足够多的上下文

「字段从哪来」这个问题有时候比写代码本身还费时间。

解法是：让 AI 直接读取底层表的 SQL 源码，自己判断哪些字段已存在、哪些需要新增关联。有几个前提：

1. 源码要能让 AI 读到（不是从文档粘截图，是实际 SQL 文本）
2. 需求文档要整理成 AI 能理解的格式（表格不行，纯文本可以）
3. 要告诉 AI「在哪张表里找」，否则它会乱猜

整体流程：

整理需求文档（纯文本格式）
    ↓
让 AI 读取底层表源码，分析字段存在性
    ↓
AI 生成三层 ETL 代码（明细层 → 汇总层 → 应用层）
    ↓
引入命名规范，让 AI 按规范重命名
    ↓
AI 生成自测 SQL，逐层验证数据一致性

|0x02 踩过的几个坑

坑一：需求文档格式

原始文档里的字段信息是表格形式，AI 读了之后格式识别经常出错。解法是手动把表格内容 copy 成纯文本再粘进提示词。

文档结构化程度直接影响 AI 的理解效率。 如果一开始需求文档就用结构化格式维护，这步完全可以省掉。

坑二：字段对应关系不确定

同一个业务概念在底层表里有两个候选字段，不确定该用哪个。解法是让 AI 生成验证 SQL，通过匹配率对比来判断：

SELECT
    COUNT(CASE WHEN t.candidate_field_a = r.target_field THEN 1 END) * 1.0 / COUNT(*) AS match_rate_a,
    COUNT(CASE WHEN t.candidate_field_b = r.target_field THEN 1 END) * 1.0 / COUNT(*) AS match_rate_b
FROM dev_table t
LEFT JOIN ref_table r ON t.order_id = r.order_id

坑三：字段命名带历史痕迹

AI 初版代码直接沿用了底层表的原始命名，字段名带有大量历史系统后缀，不符合当前命名规范。效果最好的方法是提供「参考范例」：找一张已经按规范命名的表的 SQL，让 AI 对标着改。

坑四：字段被重复写入

大规模代码生成时，AI 可能在底层明细层写了重复字段——同一个字段出现两次。解法：每次 AI 生成代码后，让它做一次自检，或者用脚本做结构化比对。

坑五：上下文超限

单次对话跑太长之后，AI 开始「遗忘」前面的约定。解法：长任务换 Cursor（自动压缩 context，改动可视化更方便）；深度业务分析用 Claude Code（理解能力更强）。两者各有长处，结合使用。

|0x03 工具选型的真实建议

|0x04 效率提升到底多少

• 字段来源分析：节省 35%+ 时间（原来人工逐行翻源码）
• ETL 代码编写：节省 30%+ 时间（AI 生成初版，人工审查）
• 问题溯源（数据差异排查）：节省 80%+ 时间

溯源效率为什么提升这么多？AI 配合表血缘查询工具可以直接读取依赖关系和源码，把原本半天的排查压缩到十几分钟。

|0xFF 最后

AI 无法替代你理解业务，但它可以替代你「翻代码」。

需求文档细节不足是常态，不是业务侧的问题，是分工的问题。把「给 AI 补上下文」当成一项技能来练——把源码文本塞进去、把字段名和需求放一起、把约束写清楚——效果会比「催对方补文档」好得多。

文档是等不来的，AI 是用出来的。