很多团队一遇到模型回答不准，第一反应就是“数据不够好”或者“模型太笨”。于是开始疯狂堆算力、买更多标注数据，甚至重新从头训练。
这当然有用，但成本高得吓人。而且很多时候，问题根本不在模型本身，也不在原始数据有多脏，而在于你没告诉模型该怎么处理这些“脏”东西。
传统流程里，数据清洗是个苦力活。你要写正则、做去重、人工校对，试图把输入变成完美的教科书式文本。现实是，真实世界的业务数据永远带着噪声：错别字、口语化表达、缺失字段，甚至逻辑矛盾。
要把这些数据洗到“完美”，往往需要耗费数周的人力。更尴尬的是，过度清洗有时会丢掉关键语境。比如客服对话里的语气词，删干净了，情绪分析反而不准。
这时候，与其死磕清洗脚本，不如换个思路：承认数据就是不干净的，然后教模型怎么在这种环境下工作。
提示词工程（Prompt Engineering）常被误解为只是调调语气或加几个“请仔细思考”。其实，它更像是在推理阶段嵌入了一层动态的逻辑校验。
举个例子。假设你要从杂乱的电商评论里提取“产品缺点”。原始数据里满是广告刷屏和无关吐槽。
传统的做法是先清洗掉广告，再喂给模型。但你可以直接在 Prompt 里写明规则：
DCCCODEBLOCK0_
这样，模型在推理时自动完成了“二次清洗”。它不仅能识别语义，还能根据指令过滤噪声。这种即时性的逻辑约束，比静态的数据预处理灵活得多。
很多人迷信模型训练，觉得只要微调（Fine-tuning）做得好，模型就能自动学会忽略噪声。
确实，微调能改变模型的偏好，但它很难让模型凭空获得“常识性”的纠错能力。如果训练数据里本身就混杂了大量错误标注，模型学到的反而是“如何正确地犯错”。
相比之下，通过精心设计的 Prompt，你可以明确指定边界条件。比如要求模型“只依据原文回答，不要发散”，或者“遇到模糊信息时标记为不确定”。这些规则写在 Prompt 里，修改只需几秒钟；要是写进模型参数里，你得重新跑一遍训练 pipeline。
不要把提示词工程看作临时补丁，它是低成本下提升鲁棒性的核心手段。
当然，这不代表数据清洗不重要。高质量的基础数据依然是地基。但在资源有限、迭代速度要求高的场景下，先优化 Prompt，往往能用 20% 的精力解决 80% 的bad case。
下次看到模型输出离谱，先别急着骂数据烂。看看你的 Prompt，是不是没把规矩讲清楚。
