让 AI 用 pandas 写数据脚本：读 CSV、按月汇总、输出统计，注释每步作用

一、为什么"让 AI 写脚本"是个接口设计问题

很多人第一次让大模型写 pandas 代码，得到的是一段"看起来对"的脚本：pd.read_csv 读进来，groupby 一下，to_csv 出去。运行之后要么报 KeyError，要么月份列变成 2024-01-01 00:00:00 这种没法直接看的字符串，要么金额列被当成 object 类型做不了求和。

问题不在模型"不会写 pandas"，而在于需求本身没有被写成可执行的规格。模型只能根据你给的文字猜测：日期列叫什么？月份按自然月还是滚动 30 天？缺失值算不算进分母？输出是一张表还是三张表？这些猜测一旦和真实数据错位，代码就废了。

本文的核心主张是：把提示词当作接口契约（interface contract）来写。契约包含三部分——输入的数据结构（列名、类型、语义）、输出的数据结构（行粒度、列含义、格式）、以及中间过程的约束（缺失值策略、时区、精度）。契约越明确，模型生成的代码越接近可直接交付的产物。本文评述：这一思路与软件工程中的"契约式设计"（Design by Contract, Meyer 1986）一脉相承，只不过契约的消费方从编译器变成了概率模型，因此需要额外的校验层来弥补模型的不确定性。

为了让讨论落地，本文全程使用一个具体场景：一份电商订单明细 CSV，字段包括订单号、下单时间、商品类目、数量、单价、金额、渠道。目标是按月汇总出订单数、销量、销售额、客单价，并输出统计摘要。这个场景足够小，能在一篇文章里讲透；又足够真实，覆盖了实际工作中 80% 的"读 CSV 做月报"需求。

延伸阅读：Pandas 官方 10 分钟入门教程（pandas.pydata.org/docs/user_guide/10min.html）与 groupby 用户指南（pandas.pydata.org/docs/user_guide/groupby.html）是理解本文代码的基础；想系统学习提示词工程，可参考 OpenAI 官方指南（platform.openai.com/docs/guides/prompt-engineering）。

二、提示词契约：把需求写成可执行规格

2.1 契约的四个字段

一份合格的提示词契约至少包含四个字段：Schema（结构）、Semantics（语义）、Constraints（约束）、Acceptance（验收）。下面给出本文使用的模板，读者可以直接套用。

【Schema】
输入 CSV 列：order_id(str), order_time(str), category(str),
            qty(int), unit_price(float), amount(float), channel(str)
输出表列：month(str, YYYY-MM), orders(int), qty(int),
         revenue(float, 2位小数), aov(float, 2位小数)

【Semantics】
- month 取 order_time 所在自然月
- orders = 该月去重 order_id 数
- qty = 该月 qty 求和
- revenue = 该月 amount 求和
- aov = revenue / orders

【Constraints】
- 用 pandas 2.x，允许 pyarrow 后端
- 缺失 amount 的行剔除，并在日志中计数
- 不使用循环，全部向量化
- 每行代码上方写中文注释说明作用

【Acceptance】
- 输出行数 = 数据覆盖的月份数
- revenue 总和与原表 amount 总和（剔除缺失后）误差 < 0.01
- 脚本可直接 python run.py 执行无报错

这份契约把"按月汇总"这个模糊需求拆成了模型可以逐条满足的清单。本文评述：Acceptance 字段是多数人忽略但价值最高的一环——它把"我觉得对"变成了"脚本自己证明对"。这与测试驱动开发（TDD）中"先写断言再写实现"的顺序一致，只不过这里的断言由人类写进提示词，实现由模型完成。

2.2 为什么"注释每步作用"要写进契约

要求模型为每步写注释，不只是为了可读性。研究表明，让模型在生成代码时同步生成自然语言解释，能显著降低逻辑错误率——因为解释过程迫使模型"想清楚再写"。这一现象在链式思考（Chain-of-Thought, Wei et al. 2022）与"先解释后编码"的提示策略中都有体现。本文评述：注释在这里承担了双重角色，既是给人类看的文档，也是模型自我约束的推理痕迹。实践中笔者发现，明确要求"每行代码上方写中文注释"后，模型写出 groupby 时漏掉 observed=True 的概率明显下降。

2.3 契约的迭代方式

契约不是一次写成的。推荐的工作流是：先用真实 CSV 的 head() 和 dtypes 输出喂给模型，让它补全 Schema；再针对输出表提出 2-3 个边界问题（跨年怎么办、缺失怎么算、金额精度几位），把回答固化进 Constraints；最后运行 Acceptance 断言，失败则把报错信息贴回对话继续迭代。这个循环通常 2-3 轮即可收敛。

三、读 CSV：参数陷阱与 dtype 治理

3.1 read_csv 的五个高频陷阱

模型默认生成的 pd.read_csv("data.csv") 在真实数据上经常翻车。下表整理了五个最常见的陷阱及其后果，数据来自 pandas 官方文档与笔者在多个项目中的实测归纳。

本文评述：这些陷阱的共同点是"默认推断在真实数据上不可靠"。pandas 的类型推断是为交互式探索设计的，不是为生产管道设计的。生产脚本应当显式声明每一列的类型，把推断权从 pandas 手里收回来。这与数据库建表时必须声明列类型是同一个道理。

3.2 用 dtype 字典做"类型契约"

把 Schema 字段直接翻译成 dtype 参数，是让 AI 生成代码最稳的做法。下面这段代码展示了完整的读取函数，每行都有注释。

import pandas as pd
import numpy as np

# 定义列类型契约：把 Schema 翻译成 pandas 能执行的 dtype 字典
DTYPES = {
    "order_id": "string",      # 订单号保持字符串，防止前导零丢失
    "order_time": "string",    # 先按字符串读入，后续统一解析日期
    "category": "category",    # 类目基数低，用 category 省内存
    "qty": "int32",            # 数量为整数，int32 足够
    "unit_price": "float64",   # 单价保留双精度
    "amount": "float64",       # 金额保留双精度
    "channel": "category",     # 渠道同样用 category
}

def load_orders(path: str) -> pd.DataFrame:
    """读取订单 CSV，返回类型受控的 DataFrame。"""
    # 用 utf-8-sig 兼容 Excel 导出的 BOM 头
    # thousands 处理千分位，na_values 统一缺失标记
    df = pd.read_csv(
        path,
        dtype=DTYPES,
        encoding="utf-8-sig",
        thousands=",",
        na_values=["", "NULL", "N/A", "-"],
        keep_default_na=True,
    )
    # 统计缺失金额行数，便于后续日志与验收
    n_missing = int(df["amount"].isna().sum())
    # 剔除缺失金额的行：无法参与汇总
    df = df.dropna(subset=["amount"]).copy()
    # 把剔除数量挂到 attrs，供调用方读取
    df.attrs["dropped_missing_amount"] = n_missing
    return df

本文评述：df.attrs 是 pandas 1.0 引入的元数据容器，用来在管道中传递"这次清洗丢了多少行"这类信息，比全局变量或打印日志更干净。很多 AI 生成的脚本会忽略这一步，导致数据质量问题被静默吞掉。

3.3 大数据量下的分块与后端选择

当 CSV 超过内存时，read_csv 的 chunksize 参数可以把文件切成迭代器。pandas 2.x 还引入了可选的 pyarrow 后端（dtype_backend="pyarrow"），在字符串列上通常比默认的 numpy object 后端更省内存、更快。根据 pandas 官方 2.0 发布说明，pyarrow 后端对字符串列的存储效率提升在多数场景下可达数倍，但需要安装 pyarrow 依赖。本文评述：是否启用 pyarrow 后端应基于实测——它在字符串密集的表上收益明显，在纯数值表上收益有限，且部分第三方库对 ArrowDtype 支持尚不完整，生产环境建议先在测试集上验证。

四、日期解析：从字符串到"月"的语义转换

4.1 to_datetime 的正确姿势

"按月汇总"的第一步是把字符串变成时间对象。模型常写的 pd.to_datetime(df["order_time"]) 在格式统一时没问题，但遇到混合格式（如 2024/1/5 与 2024-01-05 并存）会退化成逐行解析，速度骤降甚至报错。

# 显式指定格式，避免逐行推断，速度提升明显
# format="mixed" 是 pandas 2.0+ 新增，允许列内格式不一致
df["order_time"] = pd.to_datetime(
    df["order_time"],
    format="mixed",      # 允许混合格式，逐行解析但可控
    errors="raise",      # 解析失败直接报错，不静默变 NaT
    utc=False,           # 按本地时间处理，不做时区转换
)

# 解析后检查是否有 NaT，若有说明数据有问题
n_nat = int(df["order_time"].isna().sum())
if n_nat:
    raise ValueError(f"存在 {n_nat} 行无法解析的日期，请检查数据源")

本文评述：errors="raise" 是生产脚本应有的默认值。模型倾向于用 errors="coerce" 把解析失败变成 NaT，看似"健壮"，实则把数据问题藏了起来。宁可让脚本在解析阶段就失败，也不要让错误数据流到汇总结果里。

4.2 Period 还是 Timestamp？

"月"在 pandas 里有两种表达：Timestamp 截断到月初（2024-01-01），或 Period（2024-01）。两者的区别在跨月运算时才会暴露。

本文评述：如果最终产物是给人看的月报，Period 更合适；如果还要做时间序列重采样或与其它 Timestamp 对齐，用 Timestamp 截断到月初更省事。笔者的经验是：在汇总阶段用 Period 生成月份标签，在计算阶段用 Timestamp，两者通过 .dt.to_period("M") 和 .dt.to_timestamp() 互转。

# 生成月份标签：先转 Period 再转字符串，得到 YYYY-MM
df["month"] = df["order_time"].dt.to_period("M").astype(str)

# 如果后续需要按时间排序，保留一个 Timestamp 版本
df["month_ts"] = df["order_time"].dt.to_period("M").dt.to_timestamp()

4.3 时区与跨年边界

如果订单时间带时区（如 ISO 8601 的 2024-01-01T00:30:00+08:00），直接 to_datetime 会得到带时区的 Timestamp，此时 .dt.to_period("M") 会按 UTC 还是本地时区切分，取决于是否先 tz_convert。本文评述：跨时区业务必须在契约里写明"按哪个时区划分自然月"，否则同一批数据在不同机器上可能得到不同的月度汇总结果——这是最隐蔽也最致命的一类 bug。

五、按月汇总：groupby 聚合链的工程写法

5.1 从需求到聚合表达式

契约里的五个输出列，对应五种聚合逻辑：orders 是去重计数，qty 是求和，revenue 是求和，aov 是派生指标。pandas 的 groupby().agg() 支持用命名聚合（named aggregation）一次性表达，可读性远高于先 groupby 再多次赋值。

monthly = (
    df.groupby("month", observed=True)   # observed=True 避免 category 产生空组合
      .agg(
          orders=("order_id", "nunique"),  # 去重订单数
          qty=("qty", "sum"),              # 销量求和
          revenue=("amount", "sum"),       # 销售额求和
      )
      .reset_index()                       # 把 month 从索引还原成列
)

# 派生指标：客单价 = 销售额 / 订单数，保留两位小数
monthly["aov"] = (monthly["revenue"] / monthly["orders"]).round(2)
# 销售额同样保留两位小数，避免浮点尾差
monthly["revenue"] = monthly["revenue"].round(2)
# 按月份排序，保证输出稳定
monthly = monthly.sort_values("month").reset_index(drop=True)

本文评述：observed=True 是 category 类型分组时最容易踩的坑。默认 observed=False 会为所有类目组合生成笛卡尔积行，即使某些组合在数据中不存在，结果表会凭空多出大量空行。pandas 官方文档已提示该默认值在未来版本可能变更，显式写 observed=True 是更稳妥的做法。

5.2 多维度汇总：pivot_table 与 groupby 的取舍

如果需求从"按月"扩展到"按月 × 渠道"，groupby 依然可用，但 pivot_table 在生成交叉表时更直观。

# 按月 × 渠道的销售额交叉表
pivot = pd.pivot_table(
    df,
    index="month",          # 行：月份
    columns="channel",      # 列：渠道
    values="amount",        # 值：金额
    aggfunc="sum",          # 聚合：求和
    fill_value=0,           # 缺失组合填 0，便于后续计算
    observed=True,          # 同样避免空组合
).round(2)

# 增加一列合计，方便快速核对
pivot["合计"] = pivot.sum(axis=1).round(2)

本文评述：pivot_table 的 fill_value=0 与 groupby 的"缺失即不存在"是两种不同的语义。前者认为"该月该渠道销售额为 0"，后者认为"该月该渠道没有记录"。在报表场景中通常前者更符合业务预期，但必须和业务方确认——这是契约里应当写明的语义分歧点。

5.3 resample：时间序列视角的另一种写法

当数据已经是 DatetimeIndex 时，resample("M") 比 groupby 更贴合时间序列语义，且能自动补齐缺失月份（配合 asfreq）。

# 将 order_time 设为索引后重采样
ts = df.set_index("order_time")
monthly_ts = ts.resample("M").agg(
    orders=("order_id", "nunique"),
    qty=("qty", "sum"),
    revenue=("amount", "sum"),
)
# 重采样后索引是月末日期，转成 YYYY-MM 标签
monthly_ts.index = monthly_ts.index.to_period("M").astype(str)

本文评述：resample("M") 的标签默认是月末（如 2024-01-31），而 groupby 用 Period 得到的是 2024-01。两者数值一致但标签不同，混用会导致对不上账。建议在契约里明确"月份标签格式为 YYYY-MM"，并在代码里统一转换。

六、输出统计：多表、多格式与可复现性

6.1 输出什么：三张表的分工

一个完整的"输出统计"通常包含三张表：明细汇总表（按月一行）、交叉透视表（按月 × 维度）、总体摘要表（全期一行，含总计与均值）。前两张前面已经给出，第三张用 describe 或手动聚合都能做。

# 总体摘要：一行汇总全期关键指标
summary = pd.DataFrame({
    "指标": ["总订单数", "总销量", "总销售额", "整体客单价", "覆盖月份数"],
    "数值": [
        int(df["order_id"].nunique()),
        int(df["qty"].sum()),
        round(float(df["amount"].sum()), 2),
        round(float(df["amount"].sum() / df["order_id"].nunique()), 2),
        int(monthly.shape[0]),
    ],
})

6.2 输出格式：CSV、Excel、Parquet 怎么选

# 输出 CSV：utf-8-sig 保证 Excel 打开不乱码
monthly.to_csv("out/monthly.csv", index=False, encoding="utf-8-sig")

# 输出 Excel：多 sheet 一次写入
with pd.ExcelWriter("out/report.xlsx", engine="openpyxl") as writer:
    monthly.to_excel(writer, sheet_name="按月汇总", index=False)
    pivot.to_excel(writer, sheet_name="渠道透视")
    summary.to_excel(writer, sheet_name="总体摘要", index=False)

# 输出 Parquet：供下游程序读取，保留类型
monthly.to_parquet("out/monthly.parquet", index=False)

6.3 可复现性：随机种子、版本与时间戳

如果脚本里用到任何随机过程（如抽样校验），必须固定随机种子。此外，建议在输出目录写一个 run_meta.json，记录 pandas 版本、Python 版本、输入文件哈希与运行时间。本文评述：可复现性是数据脚本从"能跑"到"可信"的分水岭。很多 AI 生成的脚本完全没有版本记录，导致三个月后没人能解释某个月的数字为什么和现在重跑的不一样。

import json, hashlib, platform, datetime

def file_hash(path: str) -> str:
    """计算文件 SHA256，用于记录输入数据版本。"""
    h = hashlib.sha256()
    with open(path, "rb") as f:
        for chunk in iter(lambda: f.read(8192), b""):
            h.update(chunk)
    return h.hexdigest()[:16]

meta = {
    "run_at": datetime.datetime.now().isoformat(timespec="seconds"),
    "python": platform.python_version(),
    "pandas": pd.__version__,
    "input_hash": file_hash("data/orders.csv"),
    "rows_in": int(len(df)),
    "rows_dropped": df.attrs.get("dropped_missing_amount", 0),
}
with open("out/run_meta.json", "w", encoding="utf-8") as f:
    json.dump(meta, f, ensure_ascii=False, indent=2)

七、校验层：让 AI 代码"自证清白"

7.1 把 Acceptance 写成断言

契约里的 Acceptance 字段应当逐条翻译成 Python 断言，放在脚本末尾。这样每次运行都会自动验证结果，失败即报错。

def validate(monthly: pd.DataFrame, df: pd.DataFrame) -> None:
    """按契约的 Acceptance 字段逐条校验。"""
    # 1. 输出行数等于数据覆盖的月份数
    expected_months = df["month"].nunique()
    assert len(monthly) == expected_months, \
        f"月份数不符：期望 {expected_months}，实际 {len(monthly)}"

    # 2. 销售额总和与原表误差小于 0.01
    diff = abs(monthly["revenue"].sum() - df["amount"].sum())
    assert diff < 0.01, f"销售额对不上，误差 {diff}"

    # 3. 客单价 = 销售额 / 订单数
    recomputed = (monthly["revenue"] / monthly["orders"]).round(2)
    assert (recomputed == monthly["aov"]).all(), "客单价计算不一致"

    # 4. 无空值
    assert not monthly.isna().any().any(), "输出表存在空值"

validate(monthly, df)
print("全部校验通过")

本文评述：断言的价值在于把"人工核对"变成"机器核对"。在 LLM 生成代码的场景下，这一步尤其重要——模型可能写出语法正确但逻辑偏差的代码，只有断言能在无人值守时抓住它。这与数据工程中"数据质量检查（data quality check）"的实践一致。

7.2 用 pytest 做回归测试

把校验逻辑抽成 pytest 用例，可以在每次修改提示词或数据后快速回归。下面是一个最小测试文件。

# test_pipeline.py
import pandas as pd
from pipeline import load_orders, build_monthly

def test_monthly_columns():
    """输出表必须包含契约规定的五列。"""
    df = load_orders("data/orders.csv")
    monthly = build_monthly(df)
    assert list(monthly.columns) == ["month", "orders", "qty", "revenue", "aov"]

def test_revenue_conservation():
    """销售额守恒：分组求和等于整体求和。"""
    df = load_orders("data/orders.csv")
    monthly = build_monthly(df)
    assert abs(monthly["revenue"].sum() - df["amount"].sum()) < 0.01

def test_no_empty_month():
    """不允许出现订单数为 0 的月份。"""
    df = load_orders("data/orders.csv")
    monthly = build_monthly(df)
    assert (monthly["orders"] > 0).all()

7.3 静态检查与"AI 代码气味"

在运行前，可以用 ruff 或 flake8 做静态检查，捕捉未使用变量、未定义名称等问题。此外，笔者总结了几个"AI 代码气味"值得警惕：

• 过度使用 apply：模型常把本可向量化的操作写成 df.apply(lambda ...)，在大数据上慢几个数量级。
• 静默 coerce：用 errors="coerce" 掩盖解析失败，导致数据质量问题被吞。
• 硬编码列名：列名散落在多处，改一处漏一处。应集中为常量或 Schema 字典。
• 缺少 observed 参数：category 分组时产生空组合，结果表虚胖。
• 浮点直接比较：用 == 比较金额，应改用 abs(a-b) < eps。

本文评述：这些"气味"并非模型独有，人类新手也常犯。但模型的特点是错误模式高度一致——同一类提示词会反复触发同一类错误。因此，把上述清单固化成提示词里的"禁止事项"，比事后逐条修改更高效。

八、完整脚本：逐行注释的端到端实现

把前面各节拼起来，得到一份可直接运行的完整脚本。它读取 CSV、解析日期、按月汇总、输出三种格式，并自动校验。

"""
orders_monthly.py
读取订单 CSV，按月汇总订单数/销量/销售额/客单价，输出 CSV+Excel+Parquet。
"""
import json
import hashlib
import datetime
import platform
from pathlib import Path

import pandas as pd

# ---------- 配置区：所有路径与常量集中管理 ----------
INPUT = Path("data/orders.csv")
OUTDIR = Path("out")
OUTDIR.mkdir(exist_ok=True)

DTYPES = {
    "order_id": "string",
    "order_time": "string",
    "category": "category",
    "qty": "int32",
    "unit_price": "float64",
    "amount": "float64",
    "channel": "category",
}

# ---------- 读取 ----------
def load_orders(path: Path) -> pd.DataFrame:
    """读取 CSV 并做基础清洗。"""
    df = pd.read_csv(
        path,
        dtype=DTYPES,
        encoding="utf-8-sig",
        thousands=",",
        na_values=["", "NULL", "N/A", "-"],
    )
    n_missing = int(df["amount"].isna().sum())
    df = df.dropna(subset=["amount"]).copy()
    df.attrs["dropped_missing_amount"] = n_missing
    return df

# ---------- 日期与月份 ----------
def add_month(df: pd.DataFrame) -> pd.DataFrame:
    """解析日期并生成 YYYY-MM 月份列。"""
    df["order_time"] = pd.to_datetime(
        df["order_time"], format="mixed", errors="raise"
    )
    df["month"] = df["order_time"].dt.to_period("M").astype(str)
    return df

# ---------- 汇总 ----------
def build_monthly(df: pd.DataFrame) -> pd.DataFrame:
    """按月聚合，返回契约规定的五列。"""
    monthly = (
        df.groupby("month", observed=True)
          .agg(
              orders=("order_id", "nunique"),
              qty=("qty", "sum"),
              revenue=("amount", "sum"),
          )
          .reset_index()
    )
    monthly["aov"] = (monthly["revenue"] / monthly["orders"]).round(2)
    monthly["revenue"] = monthly["revenue"].round(2)
    return monthly.sort_values("month").reset_index(drop=True)

# ---------- 校验 ----------
def validate(monthly: pd.DataFrame, df: pd.DataFrame) -> None:
    """按契约验收条件逐条断言。"""
    assert len(monthly) == df["month"].nunique(), "月份数不符"
    assert abs(monthly["revenue"].sum() - df["amount"].sum()) < 0.01, "销售额不守恒"
    assert not monthly.isna().any().any(), "输出存在空值"

# ---------- 输出 ----------
def write_outputs(monthly: pd.DataFrame) -> None:
    """输出 CSV、Excel、Parquet 三种格式。"""
    monthly.to_csv(OUTDIR / "monthly.csv", index=False, encoding="utf-8-sig")
    monthly.to_parquet(OUTDIR / "monthly.parquet", index=False)
    with pd.ExcelWriter(OUTDIR / "report.xlsx", engine="openpyxl") as w:
        monthly.to_excel(w, sheet_name="按月汇总", index=False)

# ---------- 主流程 ----------
def main() -> None:
    df = load_orders(INPUT)
    df = add_month(df)
    monthly = build_monthly(df)
    validate(monthly, df)
    write_outputs(monthly)
    print(f"完成：{len(monthly)} 个月，剔除缺失 {df.attrs['dropped_missing_amount']} 行")

if __name__ == "__main__":
    main()

本文评述：这份脚本刻意保持了"函数短小、职责单一、常量集中"的风格。它没有用任何高级技巧，但每一处都对应契约里的一条要求。笔者认为，让 AI 生成代码时，目标不应是"最短"，而应是"最容易被断言验证"。可验证性优先于简洁性，这是数据脚本区别于算法竞赛代码的关键。

九、前沿观察：LLM 代码生成在数据工程中的边界

9.1 学术侧：从 Codex 到数据专用模型

自 Codex（Chen et al. 2021）证明大模型可以生成可执行代码以来，学术界对"自然语言转数据分析代码"的研究持续升温。近年出现了一批面向表格数据的基准，如 WikiTableQuestions、Spider、以及更贴近 pandas 场景的 DataBench 类工作。这些基准的共同发现是：模型在单表简单聚合上准确率较高，但在多表连接、日期语义、缺失值策略上错误率显著上升。

本文评述：这一结论与本文的工程观察一致——"按月汇总"看似简单，真正的难点不在 API 调用，而在语义约定。因此，提升 AI 写数据脚本质量的关键，可能不在于换更强的模型，而在于把语义约定显式化，让模型少猜。

9.2 工程侧：执行反馈闭环

当前主流做法是"生成—运行—报错—再生成"的闭环。把运行时的报错信息、断言失败信息回传给模型，让它自我修正，通常能在 2-3 轮内得到可运行代码。本文评述：这个闭环的瓶颈在于反馈信号的质量。如果只回传"AssertionError"，模型很难定位；如果回传"销售额不守恒，误差 1234.5，可能原因：缺失值处理不一致"，模型往往一次就能改对。因此，写清晰的断言消息，本身就是提升 AI 协作效率的手段。

9.3 风险与边界

• 幻觉 API：模型可能调用不存在的 pandas 参数或方法。对策：锁定 pandas 版本，运行前静态检查。
• 数据泄漏：把真实数据贴进对话可能违反合规要求。对策：用脱敏样本或合成数据做提示。
• 过度信任：模型生成的代码"看起来对"就上线。对策：强制断言与代码评审。
• 维护断层：团队不理解 AI 生成的代码，出问题无人能改。对策：要求逐行注释，并把契约文档化。

本文评述：这些风险并非不可控，但需要把"AI 生成"纳入现有的软件工程流程——版本控制、代码评审、自动化测试、监控告警，一个都不能少。把 AI 当作"打字很快但需要复核的初级工程师"，是目前最务实的心态。

十、结论与操作清单

本文的主线是：让 AI 写 pandas 脚本，本质是把需求写成接口契约，再用校验层兜底。围绕这条主线，给出了从提示词模板、CSV 读取、日期解析、按月汇总、多格式输出到断言校验的完整路径。

最后给出一份可直接执行的操作清单：

1. 先用真实 CSV 的 head() 和 dtypes 生成 Schema，写进提示词。
2. 把输出表的列名、类型、行粒度写清楚，作为 Semantics。
3. 把缺失值策略、时区、精度、是否补零写进 Constraints。
4. 把"销售额守恒""月份数一致"等写成 Acceptance 断言。
5. 要求模型为每行代码写中文注释，并禁止 apply、coerce 等气味写法。
6. 运行后把报错或断言失败信息回传，迭代 2-3 轮。
7. 把最终脚本纳入版本控制，配套 pytest 回归测试。
8. 输出目录写 run_meta.json，记录版本与输入哈希。

本文评述：这套流程的价值不在于"用 AI 省了多少时间"，而在于它把原本隐性的数据语义显性化了。即使某天不用 AI，这份契约和断言依然是团队最宝贵的资产。

主要参考文献

说明：本文参考文献与资料共计 60 余篇，涵盖 pandas 官方文档、LLM 代码生成学术论文、提示词工程指南与公开数据集说明，其中近三年（2022-2024）文献占比超过 50%。上述 9 篇为主要引用。示例数据集为模拟数据，字段结构参考 UCI Online Retail 数据集，预处理包括：剔除缺失 CustomerID 与金额的行、统一日期格式为 ISO 8601、金额字段保留两位小数、类目与渠道字段转为 category 类型。