第1章 数据清洗规则提示词的核心认知与规则设计
1.1 数据清洗规则提示词的定义、目标与适用场景
我最早接触数据清洗规则提示词，是在一个电商订单表里踩坑。当时表里混着"北京市""北京""京"三种写法，用传统脚本写映射规则，改一次要动三处代码。后来换成用自然语言描述清洗意图，让模型按规则输出，事情一下子变轻了。数据清洗规则提示词，说白了就是用结构化的自然语言，把"脏数据长什么样、要变成什么样、依据什么判断"讲清楚，让模型或清洗工具能稳定执行的一套指令。它不追求代码级别的精确语法，追求的是业务人员能读懂、能改、能复用的表达。
它的目标不复杂：把隐含在脑子里的清洗经验显性化。我见过的团队里，老员工知道"这个字段超过三位小数就是录入错误"，新人只能靠猜。写成提示词之后，这条经验就变成可传递的资产。适用场景也集中在这几类：字段格式统一、缺失值填充、异常值标记、跨表一致性核对、多源数据合并前的预处理。这些活儿共同点是规则明确但写法琐碎，正好适合用提示词来固化。
判断一个任务适不适合用提示词做清洗，我有个粗糙的标准。规则能在一两段话里说清、数据量不是海量到必须走分布式、清洗结果需要人工复核的，基本都合适。反过来，涉及复杂正则回溯或者毫秒级响应的场景，提示词不是最优解。这个边界感挺重要，我见过有人拿提示词去处理千万级日志，结果等待时间比人工还长，那就本末倒置了。
1.2 数据清洗规则提示词的关键构成要素：数据对象、清洗目标、约束条件、输出格式与校验标准
一条能用的清洗提示词，我习惯检查五个零件齐不齐。数据对象是第一个，得说清"对哪张表、哪个字段、哪类记录动手"。我踩过的坑是只写"清洗手机号"，结果模型把座机也改了一遍。写清楚对象，等于划定作业范围，后面的规则才有落点。
清洗目标是第二个零件，描述"要变成什么样"。这里容易犯的错是目标太虚，比如"让地址规范起来"。我一般会改成"省市区三级用空格分隔，去掉'省''市'后缀重复"。约束条件是第三块，规定"不能碰什么"和"必须保留什么"。比如"不要修改原始ID列""空值保持为空，不填默认值"。这层约束能防止清洗动作误伤。
输出格式和校验标准是后两个零件，经常被忽略。输出格式说清"结果是一张新表还是原表加一列标记"，校验标准说清"怎么算洗对了"。我写提示词时会附上一句"输出前统计修改行数，并对修改前后各抽三行对照"。校验标准不一定要多复杂，但得有，否则跑完一圈不知道效果好坏。这五个要素凑齐，提示词才算有了骨架。
1.3 从业务规则到提示词：字段级、记录级与表级清洗规则的拆解方法
业务规则往提示词转化，我习惯按粒度分三层来拆。字段级最好处理，规则基本是单列内部的格式和取值问题。比如"年龄列只留整数，去掉'岁'字和空格"，直接描述转换动作就行。这一层的关键是穷举边界情况，我通常会把"空值、负数、超长文本、特殊字符"这四类情况在提示词里各点一句，防止模型遇到没见过的写法就自由发挥。
记录级规则涉及同一行多个字段的联动关系。举个例子，订单表里"实付金额不能大于商品总价加运费"，这种跨字段约束用提示词表达时，我会写成判断句式："若实付金额大于商品总价与运费之和，将该行标记为'suspect'并输出原因说明"。记录级规则容易写漏方向，到底是标记、是修正还是直接剔除，提示词里得明确态度。我一般倾向于标记而非自动改，保留人工判断的余地。
表级规则处理的是整张表的统计特征和跨表关系。比如"用户表中手机号重复率不得高于百分之二""订单表的日期范围应落在业务系统开放区间内"。这类规则写成提示词时，我会把阈值和比较方式写死，避免模型自己定标准。三层拆完，我习惯再回头看一眼：字段级规则能不能单独跑、记录级规则依赖哪些字段级结果、表级规则触发后怎么反馈。这个依赖关系理清楚，提示词才能拆成可编排的模块，而不是一坨搅在一起的指令。
1.4 数据清洗规则提示词的编写原则、表达技巧与常见误区
写清洗提示词这些年，我攒了几条自己的原则。第一条是"说人话，不说行话"。与其写"执行正则归一化处理"，不如写"去掉电话号码里的横杠和空格，只留数字"。模型不是编译器，业务人员也不是程序员，双方都能看懂的表达最稳。第二条是"一个提示词只干一件事"。我试过把格式统一和缺失值填充塞进同一段，结果模型两件事都做得马虎。拆开写，每段聚焦一个动作，效果明显更稳。
表达技巧上，我偏爱用示例来锚定标准。光说"日期格式统一为YYYY-MM-DD"还不够，加一句"比如'2024年3月5日'改成'2024-03-05'"。正例给一个，反例也给一个，模型对边界的理解会准很多。还有个小技巧是把否定条件单独成行，像"不要改动已经符合格式的值""不要用零填充缺失的金额"，这类句子放在规则末尾，能减少误伤。
常见误区我列几个自己踩过的。一个是规则写得过于笼统，"清洗一下客户信息"这种提示词等于没说。另一个是忽略数据分布，比如对偏态严重的金额列写"去掉超过均值三倍的值"，结果把正常大额订单也标了。还有一个隐蔽的坑是提示词里混入了互相矛盾的约束，像"保留原始值"和"统一格式"同时出现却没说明优先级。我现在的做法是把冲突点提前想一遍，在提示词里写明"格式统一优先，原始值另存一列备查"。这种小句子能省掉很多来回。
1.5 数据清洗规则提示词的质量评估与迭代优化：可测试性、可复用性与可解释性
评估一条清洗提示词好不好，我有三个私下用的尺子。可测试性排第一：拿一批已知脏数据跑一遍，结果能不能用简单查询验证对错。我写提示词时会顺手想好验证语句，比如"跑完后统计status='suspect'的行数，与人工标注对比"。如果一条提示词没法快速验证，我基本会推倒重写，因为没法验证就没法迭代。
可复用性看的是换一张表、换一个数据源还能不能用。我评判的标准很朴素：把表名和字段名换成占位符之后，规则主体是否还成立。能成立说明抽象层次够了，下次遇到相似场景改几个参数就能上。我见过写得特别贴合某张表的提示词，字段名写死、阈值写死，换个月份数据就失效，这种复用成本太高，不如一开始就留出参数位。
可解释性是最后一道关，也是我最近越来越看重的一点。清洗动作跑完之后，得能说清"为什么这行被改了"。我的做法是在提示词里要求输出变更说明列，比如"原值'北京'改为'北京市'，原因：补全省份后缀"。这条要求增加了输出体积，但换来的是审计和复核的便利。可解释性好的提示词，新人接手时看输出就能明白规则逻辑，不用追着老人问。迭代优化就建立在这三把尺子上：测出问题、找到失效场景、补上解释缺口，改一版再跑一轮。我一般不追求一次写到位，跑三轮左右提示词才慢慢稳定下来。
第2章 数据清洗规则提示词模板、示例与落地实践
2.1 数据清洗规则提示词模板：通用结构、参数占位符与版本管理
我手头有个用了快两年的模板骨架，每次开新清洗任务先把它拖出来改。结构不长，就四块：角色交代、任务对象、规则清单、输出要求。开头我一般写"你是一名数据清洗助手，下面给你一张表的字段说明和清洗规则，请严格按照规则处理"，这句看着像废话，实际能稳住模型的行为边界，让它别自作主张加戏。任务对象那一段写清表名、字段清单和样本行，样本行不用多，三五条足够让模型知道数据长什么样。
规则清单是模板的核心，我习惯用编号列表写，每条规则占一行，格式统一成"条件→动作→例外"。举个例子："字段：phone。条件：包含非数字字符。动作：去除非数字字符。例外：空值保持为空，不做填充。"这种三件套写法有个好处，改规则时只需要动某一行的某个部分，不用通读整段话重新理解逻辑。规则编号也别省，后面出问题排查的时候，"第4条规则误伤了"比"那个手机号的规则"好定位得多。
参数占位符是我后来才重视起来的。最开始我写提示词习惯把表名、字段名、阈值直接写死，换个场景就得从头改。现在模板里到处是大括号占位符，比如{表名}、{目标字段}、{阈值}、{日期格式}。实际使用时用脚本做字符串替换，一条模板能派生出一批具体提示词。我试过把同一套清洗逻辑套到六个业务表上，只改占位符参数，半小时搞定，以前这活儿得干一整天。
版本管理这块我吃过亏。有一次改了个阈值，忘了备份旧版，结果新规则跑出来效果不对，想回退都找不到原文件。现在我给每个模板文件命名都带版本号和日期，像clean_rule_template_v1.3_20240315.md，文件头里再写一段变更记录：改了什么、为什么改、谁改的。团队里几个人共用模板的时候，这招能省掉大量"谁动了我的提示词"的扯皮。版本号不用太复杂，小改加小数点后一位，大改加整数位，够用就行。
2.2 数据清洗规则提示词示例：缺失值处理、格式标准化、异常值识别、去重与一致性校验
缺失值处理的提示词，我写的时候会把策略拆细。不是笼统说"处理空值"，而是按字段分别指定。比如用户表里，age字段空着就填-1做标记，city字段空着就保留空值但加一列city_missing标为1，order_amount空着则整行标记为待复核。这些策略写进提示词时，我会附上判断依据："金额字段缺失可能影响对账，不做自动填充，仅标记。"这句话是给模型看的，也是给后来接手的人看的。
格式标准化我常用的示例是手机号和日期。手机号那条我写："去掉所有非数字字符，若结果长度不等于11，标记为'invalid_phone'，不修改原值。"日期那条写："将'YYYY年M月D日'、'YYYY/M/D'、'YYYY.M.D'三种写法统一为'YYYY-MM-DD'，无法识别的保留原值并标记。"每条规则后面我都跟一句正例一个、反例一个，模型对边界的把握会稳很多。试过只写规则不给例子，跑出来的结果时不时冒出点惊喜，加了例子之后惊喜少了大半。
异常值识别这块我踩过的坑最多。早期写"金额超过均值三倍视为异常"，结果偏态分布的数据里正常大额订单全被标了。后来改成用分位数描述："金额字段超过99分位数的记录标记为'high_value'，低于1分位数的标记为'low_value'，两者都不自动修改。"提示词里我会强调"标记而非删除"，因为异常值不等于错误值，得留给人看。有时候我还会加一条"输出异常记录清单及对应分位数阈值"，方便复核时对照。
去重和一致性校验经常一起出现。去重的提示词我写："以order_id为唯一键，重复记录保留update_time最新的一条，其余标记为'duplicate'并输出被剔除记录的ID列表。"一致性校验跨表用得多，比如订单表和用户表的user_id对齐："检查订单表中user_id是否都存在于用户表，不存在的记录标记为'orphan_order'。"这类提示词的关键是把"怎么算一致"写清楚，是精确匹配还是允许模糊匹配，得提前定好，不然模型会自己选一种，选得对不对全看运气。
2.3 面向不同数据类型的提示词示例扩展：表格数据、文本数据、日志数据与多源异构数据
表格数据的提示词相对好写，行列结构清晰，规则容易落到具体单元格上。我处理Excel和CSV居多，提示词里会带上列名清单和每列的数据类型，比如"price为浮点数，quantity为整数，order_date为日期"。类型声明不是给模型看的装饰，它能帮模型判断"price列出现'待定'两个字"属于类型冲突，该走异常标记流程。表格数据还有个特点是空值多，我一般会在提示词开头加一句"空单元格统一视为NULL处理"，省得模型把空格当有效值。
文本数据的清洗提示词完全是另一套写法。我做过一个商品评论的清洗，目标是去掉HTML标签、表情符号和重复标点。提示词写的是："清除所有<...>形式的标签，保留标签内的文字；将连续三个以上相同标点压缩为一个；表情符号替换为对应文字描述，如'😊'替换为'[微笑]'。"文本清洗最难的是边界模糊，什么算噪声什么算信息，得在提示词里一条条掰扯清楚。我通常会附一段清洗前后的对照文本，让模型有参照物。
日志数据的提示词我写得最谨慎，因为日志格式多变、字段不固定。我的做法是先让模型做结构解析，再做规则清洗。提示词分两段：第一段写"将每行日志按空格切分，识别时间戳、级别、模块名、消息体四部分，输出为JSON格式"；第二段写针对各部分的清洗规则，比如"时间戳统一转为ISO8601格式，级别字段只保留INFO/WARN/ERROR/DEBUG四种值"。日志清洗对格式容错要求高，我会在提示词末尾加一句"无法解析的行原样保留并标记为'unparsed'，不要丢弃"。
多源异构数据的提示词更像一份协调说明书。我遇到过的场景是把CRM系统导出的客户表和Excel手工维护的拜访记录合并，字段名对不上、格式对不上、粒度也对不上。提示词里我先写字段映射关系："CRM的cust_name对应拜访记录的客户名称，CRM的cust_id对应拜访记录的客户编号。"再写格式统一规则和冲突处理规则："同一客户在两表中名称不一致时，以CRM为准，差异记录输出对照清单。"多源场景的提示词一定要把"谁优先、谁兜底"写明白，不然模型会在冲突处随机选边，选完还不告诉你选了哪边。
2.4 数据清洗规则提示词与清洗流程及工具链的协同：规则编排、批量处理、人工复核与审计
提示词写完不是终点，得嵌进流程里才产生价值。我现在的做法是把清洗流程拆成几个环节：规则加载、批量执行、结果落库、人工复核、审计留痕。提示词模板对应"规则加载"这一环，执行脚本读模板、填参数、调模型接口，输出结构化结果。批量处理时我会按数据量分批，每批五千到一万行，批次之间加个短暂间隔，避免接口限流。这个数字没什么科学依据，纯粹是试出来的经验值。
规则编排上我偏好串行而非并行。字段级规则先跑，记录级规则依赖字段级结果，表级规则最后做全局统计。提示词之间的依赖关系我在模板文件里用注释标出来，比如"本规则需在phone_format规则执行后运行"。串行编排的好处是每一步结果都能单独验证，出问题知道卡在哪一环。并行的效率优势对我来说不是刚需，数据量没大到那个份上。
人工复核环节我坚持保留，哪怕规则跑得再顺。复核的入口是清洗结果里的标记列：suspect、invalid_phone、duplicate这些标签就是给人看的。我在提示词里要求每类标记附带简短原因说明，复核人员扫一眼就知道该不该放行。复核界面不用复杂，一个表格加筛选功能就够，重点是把标记和原因放在同一行，减少来回切换。
审计留痕这事儿我吃过亏才长记性。早期清洗跑完只留最终结果，原始数据覆盖掉了，后来业务方质疑某条记录被改错了，翻遍日志找不到依据。现在提示词里固定要求输出三样东西：清洗后的表、变更明细表（记录原值、新值、规则编号、执行时间）、规则版本号。变更明细表是审计的核心，有了它，任何一条改动都能追溯到具体规则和具体时间。存储成本不高，换来的是出问题时能自证清白。
2.5 常见问题排查与最佳实践清单：模板复用、示例校准、效果验证与持续优化
模板复用最常见的翻车方式是占位符没改全。我有次复制模板改表名，漏了一个字段占位符，跑完发现规则作用在了一个不存在的列上，模型没报错，默默跳过了。后来我加了个自检步骤：执行前先扫一遍模板，确认所有占位符都被替换成实际值，有残留就中止。这个检查用几行脚本就能做，省下的是事后排查的时间。
示例校准是另一个高频问题。提示词里给的例子如果和实际数据分布差太远，模型会按例子去套，套歪了还不自知。我的习惯是每次换数据源都抽二十行样本过一遍提示词，看输出是否符合预期。样本里特意混入边界情况：全空行、超长文本、特殊字符、格式混杂的记录。二十行跑下来没问题，再放大批量。这个动作花不了几分钟，能挡住大部分低级错误。
效果验证我一般看三个指标：修改率、误改率、漏改率。修改率是清洗动作实际改动的行数占比，太高说明规则太激进，太低说明规则没起作用。误改率和漏改率靠人工抽样估算，抽一百行，数一数改错的几条、该改没改的几条。这三个数字连续跑三轮稳定下来，我才认为提示词可以定版。阈值因场景而异，我经手的任务里，修改率落在百分之五到百分之十五之间比较常见。
持续优化是个慢功夫。我的做法是建一个错例库，每次复核发现规则判错的案例，连同原始提示词版本、错误类型一起存进去。每个月翻一次错例库，看哪类错误反复出现，针对性地改模板。有时候改一条规则措辞就能消掉一批错例，有时候得调整整个模板结构。优化节奏不用太急，跑上两三个月，提示词的稳定性会明显上一个台阶。我现在手头那套模板已经迭代到第七版，前几版的问题回头看都挺明显，当时却觉得已经够好了，这大概就是迭代的意义。
