大数据与AI：用AI写数据清洗脚本时，一次要完整代码和分步骤先验证数据加载、再处理逻辑，效果差多少？

一、问题的真实形态：不是“要不要分步”，而是“在哪一步锚定假设”

在真实的数据团队里，这个问题的提出方式往往很朴素：“我让 AI 一次性把清洗脚本写完，它写得挺快，但跑起来一堆错；后来我改成先让它只写读取数据那一段，跑通了再写清洗，感觉稳多了，但来回聊了七八轮。”这段描述里其实藏着两个被混为一谈的变量：生成粒度与验证时机。前者是“一次要多少代码”，后者是“什么时候用真实执行结果去校准模型的下一个输出”。

很多讨论把二者捆绑，得出“分步一定更好”或“一次性更省事”的粗糙结论。笔者认为，这种捆绑恰恰是争议的根源。分步之所以有效，主要不是因为“代码短了模型更不容易错”，而是因为每一段生成都被一次真实执行结果所锚定，模型后续输出建立在“已验证的事实”而非“它自己上一轮的猜测”之上。反过来，一次性生成之所以在某些场景下并不差，是因为当任务足够简单、数据模式足够标准时，模型的先验知识本身就足以覆盖全部假设，锚定与否影响不大。

因此，本文把问题重新表述为：在给定任务复杂度与数据异质性的条件下，把“假设锚定”放在生成流程的哪个位置，能使总成本（生成 + 调试 + 返工 + 维护）最小？这个表述的好处是，它不预设答案，而是把“一次性”和“分步”都视为同一优化问题在不同参数下的解。

从软件工程视角看，这其实是“需求不确定性下的增量开发”在 LLM 辅助编程中的再现。Boehm 的螺旋模型强调“每轮迭代以可执行产物降低风险”，而数据清洗脚本的特殊性在于：它的“需求”往往不是人写出来的，而是数据本身“告诉”你的——空值率、编码混杂、时间格式漂移、单位不一致，这些只有跑过才知道。

这也解释了为什么数据清洗特别容易触发“一次性生成失败”：模型在生成时看不到你的真实数据，它只能基于对“典型数据集”的统计先验去猜列名、猜类型、猜缺失模式。任务越贴近“典型”，猜中的概率越高；任务越贴近“你们公司那张祖传宽表”，猜中的概率越低。分步验证的本质，就是用真实数据把模型的先验逐步替换为事实。

二、分析主线：上下文可验证性框架

为了让全文有一条贯穿的逻辑线，笔者提出一个用于分析此类问题的框架——上下文可验证性（Context Verifiability，CV）。它衡量的是：在模型生成某一段代码的那一刻，该代码所依赖的关键假设中，有多大比例已经被“可执行的事实”所确认。

2.1 框架的三个维度

笔者把 CV 拆成三个可观测维度，便于工程上操作：

• 数据事实锚定度（Data Grounding）：模型是否见过真实的 schema、样本行、空值分布、取值域。未见过的，只能靠猜。
• 执行结果锚定度（Execution Grounding）：上一段代码是否已被真实运行，其输出（行数、类型、异常）是否回灌给模型。
• 约束显式度（Constraint Explicitness）：业务规则（如“金额不得为负”“身份证必须 18 位”）是否以可检查的形式写进了提示词或测试。

一次性生成在这三个维度上通常都很低：模型没见过数据、没跑过代码、约束靠它自己脑补。分步验证则逐段抬高三个维度。本文后续所有对比，都可以还原为“CV 高低”的差异，而不是“提示词写得好不好”的玄学。

2.2 为什么用 CV 而不是“代码行数”或“轮次”

行数和轮次都是结果指标，不是原因指标。同样聊 5 轮，如果每轮都把执行结果贴回去，CV 很高；如果只是反复说“再改改”，CV 几乎不涨。CV 框架的价值在于：它告诉你该往对话里放什么——不是更多的形容词，而是更多的“事实回灌”。这一点在第六节的提示词模板里会具体落地。

三、一次性生成的真实代价：四类典型失效模式

要公平比较，先得看清一次性生成到底“错在哪”。笔者结合公开的代码生成评测文献与自身复现实验，归纳出四类高频失效模式。它们不是随机错误，而是有结构性成因的。

3.1 模式一：Schema 幻觉（列名、类型、编码全靠猜）

模型在没看到真实表结构时，会生成诸如 df['user_id'] 的代码，而真实列可能叫 uid 或 UserID。这类错误在一次性生成中占比很高，且往往在脚本跑到中段才暴露。更隐蔽的是类型幻觉：模型假设某列是数值，实际是带千分位逗号的字符串，astype(float) 直接抛异常。

公开研究普遍指出，LLM 在“未见过的私有 schema”上的代码正确率显著低于“标准公开数据集”。这并不奇怪：模型对公开数据集的列名分布有强先验，对私有表则没有。Schema 幻觉的根因是 Data Grounding 缺失，而这恰恰是分步验证第一步就能消除的。

3.2 模式二：缺失值策略的“默认暴力”

一次性生成时，模型常给出 df.dropna() 或 df.fillna(0) 作为“清洗”。这两行在语法上永远正确，在业务上可能灾难性错误：把“未填写”当成 0，会污染均值、扭曲分位数；直接删行可能删掉 30% 的样本。模型不知道你的缺失是 MCAR、MAR 还是 MNAR，也不知道某列的缺失本身携带信息（例如“未投诉”字段为空可能意味着“无投诉”）。

这类错误的特点是“能跑通、不报错、结果错”，比 Schema 幻觉更危险，因为它不会触发异常，只会悄悄污染下游。笔者认为，这是分步验证相对于一次性生成收益最大的一类场景——因为只有在看到真实空值分布后，人才能决定策略，而模型无法替你做这个业务判断。

3.3 模式三：规则顺序与副作用耦合

清洗规则之间常有顺序依赖：先去重再补全，与先补全再去重，结果不同；先做单位换算再做阈值过滤，与反过来，结果也不同。一次性生成时，模型往往按“看起来合理”的顺序排列，但这个顺序未必符合你的业务语义。更麻烦的是副作用：某条规则修改了共享的 DataFrame，后续规则在“已被污染”的数据上继续操作，错误层层放大。

这类问题在代码审查时也不容易看出来，因为每一行单独看都对。它需要“分段执行 + 中间态检查”才能暴露，这正是分步验证“逻辑切片”环节的价值。

3.4 模式四：异常处理与边界条件的“样板化”

模型倾向于生成“看起来很专业”的 try-except 和日志，但异常类型、捕获范围、重试策略往往是套模板。例如捕获了 Exception 却只打印不处理，或对“文件不存在”和“编码错误”用同一套处理逻辑。在真实流水线里，这些样板代码会掩盖真正的失败，让问题在更晚、更贵的位置爆发。

上表是笔者对公开案例与复现实验的归纳（模拟数据整理，非单一来源统计）。可以看到，四类模式中有两类“不报错”，这解释了为什么很多团队觉得“一次性生成也能用”——他们只统计了报错，没统计静默错误。

四、分步验证的收益结构：把错误挡在“便宜的位置”

软件工程里有个朴素的经验：缺陷发现得越晚，修复成本越高。数据清洗脚本尤其如此——错误如果流到下游报表或模型，排查成本会指数级上升。分步验证的核心收益，不是“让模型少犯错”，而是改变错误被发现的位置。

4.1 错误位置的“成本梯度”

笔者把数据清洗中的错误发现位置粗略分为四档，成本依次上升：

1. 加载阶段：读文件、看 schema、抽样。发现成本最低，只需重跑几行。
2. 单条规则执行后：跑完一条规则，检查中间态行数、空值率、取值域。成本低。
3. 整脚本跑完：需要定位是哪条规则导致，成本中等。
4. 下游消费后：报表异常、模型指标漂移，回溯成本最高。

分步验证把大量错误从第 3、4 档拉到第 1、2 档。一次性生成则相反，它把错误“攒”到最后一起爆发。这就是为什么很多人的体感是“分步聊得久，但总时间更短”——聊的轮次多了，但每轮都很短，且没有昂贵的回溯。

4.2 分步不是“越碎越好”

这里要泼一盆冷水：分步验证也有成本。每一轮对话都要重新组织上下文、贴执行结果、描述期望，这些都是人工开销。如果任务很简单（比如“把 CSV 读进来，去掉全空行，存成 parquet”），分步的对话开销可能超过它节省的调试时间。

笔者认为，分步的粒度应该由“假设的不确定性”决定，而不是由“代码行数”决定。一段 50 行的代码，如果依赖 5 个你也不确定的业务规则，就该拆；一段 200 行的标准 ETL 模板，如果 schema 已确认、规则已明确，一次性生成反而更高效。这个判断标准，比“一律分步”或“一律一次性”都更经得起检验。

五、量化对比：缺陷密度、返工轮次与 Token 成本

本节给出可复现的对比实验设计，以及基于公开基准参数构建的模拟数据结果。需要强调：以下数值为模拟数据，用于说明量级与趋势，不代表任何特定模型或团队的真实指标。读者可用同一设计在自己的数据上复现。

5.1 实验设计（可复现）

任务集：选取 3 类典型清洗任务——(A) 单表结构化清洗（去重、类型转换、缺失处理）；(B) 多表关联清洗（主外键、维度对齐）；(C) 半结构化日志清洗（正则解析、字段抽取）。每类构造 10 个变体，共 30 个任务。数据来源为公开数据集的脱敏子集与合成数据，预处理细节见文末参考文献说明。

两种工作流：(1) 一次性生成完整脚本；(2) 三段式分步（加载验证 → 逻辑切片 → 集成回归）。评价指标：首次可运行率、缺陷密度（每百行有效缺陷数）、返工轮次、总 Token 消耗、人工介入分钟数。所有执行在同一 Python 环境、同一模型版本下完成，温度设为低值以减少随机性。

5.2 模拟结果与解读

这组模拟数据揭示了一个反直觉但重要的结论：分步验证的 Token 消耗更高，但人工时间更少。如果只盯着 API 账单，一次性生成“更便宜”；如果算上工程师排查静默错误的时间，分步更划算。这与近年关于“LLM 辅助编程生产力”的实证研究结论方向一致——收益高度依赖任务复杂度与验证机制，而非单纯的生成速度。

另一个值得注意的点是“返工轮次”指标：分步反而更多。这提醒我们，不要用“聊了几轮”来评价效率。轮次多不等于低效，轮次少也不等于高效，关键看每轮是否在缩小不确定性。

需要说明的是，上述数字会随模型能力、任务类型、数据异质性显著变化。笔者不建议把具体数值当作“标准答案”，而建议把实验设计搬回自己的团队：用你们真实的 10 张表、20 条规则跑一遍，得到的结论才对你有效。

六、可操作路径：三段式分步协议与提示词模板

理论说完，落到能直接抄作业的层面。笔者把分步验证整理为“三段式协议”，每一段都有明确的输入、输出和验收标准。

6.1 第一段：加载验证（只做“看见数据”）

目标：让模型和你都确认数据的真实形态。这一段的产物不是清洗代码，而是数据画像：schema、样本、空值率、取值域、异常样例。提示词可以这样写：

你是数据工程师。先不要写清洗逻辑。
我给你一份数据的路径和 5 行样本（见下）。
请只输出一段 Python 代码，完成以下"数据画像"：
1) 读取数据，打印 shape、dtypes、每列空值数与空值率；
2) 对每个 object 列，打印唯一值数量与前 10 个高频值；
3) 对每个数值列，打印 min/max/均值/分位数；
4) 打印 3 行随机样本。
要求：代码可直接运行，不依赖我本地不存在的包；
输出后附一段"你观察到的数据风险点"清单，不要给清洗建议。

数据路径：./data/raw/orders_2024.csv
样本：
（粘贴 5 行真实脱敏样本）

跑完这段，把真实输出贴回对话。此时模型对 schema 的认知从“猜”变成“见”，Data Grounding 显著提升。这一步通常只需 1 轮，成本极低，但能消掉第三节里最扎眼的 Schema 幻觉。

6.2 第二段：逻辑切片（一条规则一次确认）

目标：把清洗规则拆成可独立验证的切片，每片都带“验收断言”。关键技巧是让模型先写断言，再写实现——这相当于把 Constraint Explicitness 拉满。

基于上一步的数据画像，现在只处理"缺失值"这一条规则。
请按以下格式输出：
【规则】用一句话描述这条清洗规则；
【断言】用 pandas 断言写出清洗后应满足的条件（如行数变化范围、空值率上限）；
【实现】一段只做这一件事的 Python 函数；
【风险】这条规则可能误伤哪些数据，如何回滚。
不要输出其他规则的代码。缺失值策略请先给 2 个候选方案及各自代价，等我选择后再写实现。

注意最后一句“先给候选方案等我选择”——这是把业务判断权留在人手里。缺失值策略本质是业务决策，模型不该替你拍板。每片跑完、断言通过，再进入下一片。这样错误被挡在第 2 档成本位置。

6.3 第三段：集成回归（拼装 + 全量校验）

目标：把切片拼成完整脚本，并做端到端回归。这一段要特别关注规则顺序和副作用。提示词示例：

把以下已确认的切片函数按合理顺序组装成完整脚本：
（粘贴各切片函数）
要求：
1) 每个函数保持纯函数风格，不修改入参，返回新对象；
2) 在主流程中，每步之后打印行数与关键列空值率，便于回归比对；
3) 给出一个 run_all(input_path, output_path) 入口；
4) 附一段 pytest 风格的回归测试，覆盖：行数守恒/缩减上限、
   关键列非空、金额非负、日期范围合理。
5) 指出你认为最可能出问题的 3 个顺序依赖点。

第三段的产物才是“完整脚本”，但它已经是被验证过的切片拼装而成，而不是一次性猜出来的整体。这就是 CV 框架的落地：完整代码是结果，不是起点。

七、工程落地：验证清单、自动化流水线与工具链

协议要变成团队习惯，得靠清单和流水线，而不是靠个人自觉。

7.1 数据清洗验证清单（可直接用于 Code Review）

7.2 自动化流水线：把“贴回执行结果”变成脚本

人工在对话里贴执行结果容易漏、容易忘。更工程化的做法是写一个薄薄的“回灌脚本”：跑模型生成的代码，捕获 stdout 与异常，自动拼成下一轮提示词的上下文。伪代码如下：

def run_and_feedback(code: str, stage: str) -> str:
    """执行模型生成的代码，把结果整理成回灌上下文。"""
    result = subprocess.run(
        [sys.executable, "-c", code],
        capture_output=True, text=True, timeout=120
    )
    feedback = {
        "stage": stage,
        "returncode": result.returncode,
        "stdout_tail": result.stdout[-3000:],
        "stderr_tail": result.stderr[-1500:],
    }
    # 关键：只回灌"事实"，不回灌"评价"
    return json.dumps(feedback, ensure_ascii=False)

这个脚本的价值在于：它把“执行结果锚定”从人的记忆负担变成流水线动作。团队可以把它接进 CI，每次模型生成后自动跑、自动回灌、自动记录轮次与 Token，形成可审计的生成日志——这对合规要求高的行业尤其重要。

7.3 工具链与拓展资源

验证环节可以复用成熟工具，不必自己造轮子：

• Pandera / Great Expectations：把“断言”写成声明式 schema 与期望，适合做第二段切片的验收。Pandera 文档：pandera.readthedocs.io；Great Expectations：greatexpectations.io。
• pytest + hypothesis：属性测试适合验证“行数守恒”“金额非负”这类不变量。Hypothesis 文档：hypothesis.readthedocs.io。
• DuckDB：本地快速跑 SQL 版清洗逻辑，适合做中间态比对。文档：duckdb.org/docs。
• pandas 官方“10 minutes”教程：作为团队统一的 pandas 基线，减少模型生成风格漂移。pandas 10min 教程。

视频类资源方面，可参考 PyData 与 Data Council 频道中关于“data quality / pipeline testing”的公开演讲（YouTube 搜索 “PyData data validation pandera”“Great Expectations tutorial”），以及 pandas 官方 YouTube 频道的清洗实战。笔者建议团队建立自己的“提示词 + 断言”片段库，比收藏零散视频更有效。

八、前沿预判：从“生成代码”到“生成可验证契约”

如果把视线拉远，当前“一次性 vs 分步”的争论，很可能是一个过渡阶段的产物。近年的研究方向正在把“验证”从人的动作，变成模型与工具链的内建能力。

8.1 执行反馈驱动的生成（Execution-Guided Generation）

程序合成领域早已证明，把执行结果作为反馈信号能显著提升生成质量。近年 LLM 代码生成的研究进一步把“运行测试 → 修正”做成闭环，甚至让模型自己写测试再自己修。本文评述：这条路线本质上是把“分步验证”自动化——人不再手动贴结果，而是由 agent 自动跑、自动回灌。它不会让“一次性生成”消失，而是让“一次性”变成“内部多轮、外部一次”的假象。

8.2 数据契约（Data Contract）作为提示词的一部分

数据契约把 schema、SLA、质量规则写成机器可读的声明。笔者认为，未来的清洗脚本生成，很可能不再从“自然语言描述”出发，而是从“数据契约 + 样本”出发：模型的任务变成“生成满足契约的转换”，验证则由契约引擎自动完成。这会把 CV 的“Constraint Explicitness”维度直接拉满，也会让“一次性生成”在契约明确的场景下重新变得可行。

8.3 对团队的启示

无论工具怎么演进，有一条不会变：模型无法替你承担业务语义的责任。缺失值怎么填、异常值怎么处理、哪条规则优先，这些是数据所有者的事。分步验证的真正价值，是把这个责任边界显式化。工具越自动，这条边界越需要被写清楚——否则自动化只会更快地放大错误。

九、结论与决策树

回到标题的问题：效果差多少？笔者的回答是——差距不在“生成速度”，而在“错误被发现的位置”和“业务决策是否被显式化”。在中等以上复杂度任务上，分步验证用更高的 Token 消耗换更少的人工回溯，综合成本通常更低；在简单、标准、契约明确的任务上，一次性生成完全够用，强行分步反而是浪费。

给一个可直接用的决策树：

1. schema 是否已确认、样本是否已看过？否 → 先做第一段加载验证。
2. 清洗规则是否涉及业务判断（缺失、异常、优先级）？是 → 必须切片，且让人拍板。
3. 规则之间是否有顺序依赖或共享状态？是 → 必须做中间态检查与回归测试。
4. 以上都否，且规则可写成明确断言 → 一次性生成 + 断言验收即可。

最后提醒一句：本文的模拟数据只说明趋势，不构成对你团队的性能承诺。真正靠谱的做法，是拿你们自己的表和规则，按第五节的实验设计跑一遍。数据工程里，没有比“在真实数据上验证过”更硬的结论。

主要参考文献