数据清洗规则的“可发布版本”，核心只有一个标准：每一条规则都必须能被任何团队成员直接理解、直接执行，完全不需要二次解释。

举个例子——customer_id列里出现了字符串'NULL'？直接转为空值。amount列出现了负数？整行删除。created_at列有'30/May/2026'、'2026/05/31'、'31-May-2026'三种格式？统一转换为'YYYY-MM-DD'。简单来说，每一条规则都必须以列名开头、动作动词明确、阈值清晰，绝不能模棱两可。

也就是说，用Codeium生成的数据清洗规则，要能直接复制粘贴到团队文档、交接给ETL工程师，或者顺手写入Airflow DAG的注释中。而不是每次还得人工补字段名、添加阈值、修改动词。可发布版本的核心就在这里：业务语义清晰、字段锚定精准、操作动作明确、边界条件清楚，完全不需要依赖开发者二次解读。

第一步：用真实样例锁定数据形态

第一步，提示词开头直接贴上真实数据的前几行——比如【data/orders_2026Q2.csv】的前三行，包含列头，一个空格都不能少。这一步不能省略，否则Codeium会按照通用CSV结构自行脑补，比如把'30/May/2026'当作ISO格式而忽略斜杠分隔的问题。

紧接着用中文直接描述你看到的脏数据：“customer_id列出现字符串'NULL'而非None；amount列存在负值但业务禁止退款单单独导入；created_at格式不统一，包含'30/May/2026'、'2026/05/31'、'31-May-2026'三种写法。”

关键点：必须写出具体值和分隔符，不能只说“日期格式不统一”——Codeium无法从模糊描述中提取正则锚点。

第二步：强制绑定业务动词与校验阈值

用“必须满足以下全部条件”收口，逐条写死：

① 所有规则必须以列名开头，例如“customer_id列中值为'NULL' → 转为空”；禁止出现“该字段”“对应列”等指代。

② 每条规则包含唯一动作动词：转为空、替换为、删除整行、标记为异常、截断至X位小数。不允许使用“清洗”“处理”“标准化”这类无指向动词。

③ 数值类规则必须带阈值：如“amount < -0.01 → 删除整行”，不能写“过滤异常金额”。

④ 字符串操作必须指定trim范围：如“customer_id列 → trim()仅去除首尾空格，不处理中间连续空格及全角空格”。

第三步：指定输出结构，禁用技术黑话

在提示词末尾加一句：“严格按以下四区块顺序输出，不得合并、拆分或增减：① 清洗目标（一句话，主语是文件名，如‘将【data/orders_2026Q2.csv】中手机号转为11位纯数字’）；② 原始问题模式（表格，列名：问题现象|正则表达式|替换动作）；③ 边界校验逻辑（Python伪代码，只准用if/else、len()、isdigit()、replace()、pd.isna()）；④ 异常样本兜底说明（列举1条无法自动修复的样本，如‘+86 (138) 1234-5678 → 含括号+国家码+短横线，需人工核对后录入’）。”

这一步操作起来很简单，直接复制粘贴即可。但漏掉任一区块，输出就无法直接贴进清洗脚本的docstring里。

第四步：注入真实约束，避免理想化方案

第一步：写明数据来源与更新节奏，例如“该文件来自iOS端埋点日志，每日增量约20万条，清洗需在2分钟内完成”。

第二步：标注资源限制，例如“测试环境内存上限4GB，禁止使用df.fillna(method='ffill')全量前向填充”。

第三步：绑定角色权限，例如“你是一名数据平台组SRE，无权修改上游Kafka Schema，但可要求业务方在event中增加country_code字段”。

不写这些，Codeium会默认用Pandas全量加载+fillna均值，而你的生产环境根本跑不动。

第五步：加版本与生效声明，锁定可发布性

在提示词最后追加：“末尾另起一行，写：【版本】v20260617；【生效时间】2026年6月18日00:00起执行；【适用环境】仅限prod-data-pipeline-v3集群。”

这三行必须用【】包裹，且字段名、时间、环境名与你实际系统完全一致。Codeium会原样输出，下游团队可直接抄进清洗脚本或运维文档中。