六条提示词驱动的数据科学工作流：从脏数据到可交付模型

1. 项目概述：用六条提示词，把数据科学项目从“脏数据”推到可交付模型

你有没有过这种经历：客户甩过来一个Excel文件，名字叫“final_v3_cleaned_revised_2024.xlsx”，点开一看——第一行是合并单元格的标题，第三行突然空了两列，第七列全是“#N/A”，最后一列写着“备注（请忽略）”？然后老板说：“这个模型下周要上线，能跑通就行。”这时候，你不是在写代码，是在和时间、混乱和模糊需求赛跑。我干这行十年，带过二十多个工业级数据项目，最常被问的问题不是“模型怎么调参”，而是“怎么在三天内让一个没人碰过的数据集说出人话”。这篇内容讲的，就是我日常用的那套“六步快车道”工作流——它不依赖你是否精通PyTorch底层源码，也不要求你背下所有Scikit-learn参数，它只依赖一件事：你能不能把真实问题，翻译成ChatGPT真正听得懂的六句话。

核心关键词全在这里： Towards AI - Medium 。这不是指某篇具体文章，而是代表一种已被验证的、面向实战的数据科学协作范式——把大模型当作你的“资深协作者”，而不是“自动答题机”。它不替你思考业务逻辑，但能瞬间补全你缺失的工程细节；它不帮你判断该用XGBoost还是LightGBM，但能根据你描述的特征分布，自动生成带异常值处理、类别编码、交叉验证分层的完整训练脚本；它甚至能在你写错pandas语法时，指出“你这里用了inplace=True但没赋值给变量，后续df会报KeyError”，比IDE的linter还准。我试过用这套方法，把一个零售客户“销售预测”项目的原型开发周期，从传统流程的5天压缩到9小时——其中3小时在清洗数据，4小时在调试特征工程，2小时在本地验证结果。关键不是速度本身，而是整个过程里，你始终掌控着方向盘，AI只是帮你踩油门、打方向、看后视镜。适合谁？刚转行想快速出活的新人、被业务方催得焦头烂额的中级工程师、需要快速验证想法的产品经理，甚至是对技术细节不深究但必须对结果负责的团队负责人。它解决的从来不是“能不能做”，而是“能不能在截止日期前，交出一个经得起追问的版本”。

2. 整体设计思路：为什么是六步，而不是三步或十步？

2.1 六步结构的底层逻辑：覆盖数据科学闭环的六个不可跳过节点

很多人看到“六条提示词”就以为是凑数，其实每一步都卡在数据科学落地的真实断点上。我拆解过上百个失败项目，发现87%的延期不是因为算法不行，而是卡在某个环节的“信息黑洞”里——比如你花了两天写完数据清洗脚本，结果发现原始数据里有个隐藏字段“status_flag”，它的取值逻辑是“当order_date晚于ship_date时置为1”，而这个规则只存在于业务方三年前发的一封邮件里。六步法的设计，就是用提示词主动去“凿穿”这些黑洞。它不是线性流水线，而是一个带反馈的增强回路：

1. 理解层（Prompt 1） ：强制你把模糊的业务目标，翻译成可量化的指标定义。比如“提升用户留存”必须明确为“将次日留存率从22%提升至26%，以DAU>10万的用户群为基准，排除注册未满24小时的样本”。这一步堵死了后期“需求理解偏差”的源头。
2. 探索层（Prompt 2） ：不是简单跑 df.describe() ，而是让AI基于你的业务描述，预判数据里最可能藏雷的三个位置。它会说：“根据你提到的‘电商订单’场景，我建议重点检查：① payment_method 字段中‘other’类别的占比，若超15%需确认是否为数据录入错误；② delivery_time_days 与 order_amount 的相关性，若r<-0.3则暗示高价值订单配送延迟更严重；③ user_id 重复率，若>5%需排查账号共享或爬虫行为。”——这相当于给你配了个有十年电商经验的DBA坐旁边盯屏。
3. 清洗层（Prompt 3） ：生成的代码不是通用模板，而是带着上下文注释的“手术刀”。比如处理缺失值，它不会只写 df.fillna(0) ，而是：“因 discount_rate 缺失意味着未参与促销活动，故填0；但 review_score 缺失可能源于用户未评价，填均值会扭曲分布，故创建 is_reviewed 布尔特征并保留原缺失。”——每行代码背后都有业务理由。
4. 建模层（Prompt 4） ：关键在“约束条件注入”。你告诉它：“数据量仅12000条，特征维度达87，且存在3个强相关类别变量”，它就会避开需要大量数据的深度学习，推荐CatBoost，并自动生成处理类别嵌入的代码，连 cat_features 参数列表都帮你列好了。
5. 验证层（Prompt 5） ：拒绝“准确率85%”这种废话。它输出的是分层验证报告：在新用户子集上AUC=0.72，在老用户子集上AUC=0.89，说明模型对冷启动场景泛化不足；同时给出修复建议：“增加 days_since_first_purchase 特征，或对新用户样本加权。”——这才是业务方能看懂的结论。
6. 交付层（Prompt 6） ：生成的不是 .py 文件，而是可直接部署的Dockerfile+API接口文档+监控埋点说明。比如它会写：“在 /predict 端点返回JSON中，必须包含 confidence_interval_low 和 confidence_interval_high 字段，用于前端展示预测可信度，计算方式为：对预测结果进行100次Bootstrap采样后取5%和95%分位数。”

这六步环环相扣，少一步，后面就可能崩盘。我曾见一个团队跳过第2步“探索层”，直接进清洗，结果模型在上线后一周崩溃——因为AI在Prompt 3里生成的清洗逻辑，假设 user_age 缺失值都填中位数，但实际业务中，缺失 user_age 的用户全是海外注册，其消费行为模式与国内用户截然不同。而Prompt 2本该提醒：“ user_age 缺失率>40%，且与 country_code 强相关，请先按地域分组分析。”

2.2 为什么不用更少的步骤？——三步法的致命陷阱

有人尝试“理解-建模-交付”三步走，结果惨烈。根本原因在于，它把数据科学当成了纯算法问题，忽略了两个血泪教训：

• 数据漂移的隐形成本 ：一个在历史数据上AUC=0.92的模型，上线后首周就掉到0.65。追查发现，清洗脚本里有一行 df = df[df['order_amount'] > 0] ，而新渠道的订单系统把退款单记为负值，导致所有退款行为被过滤。三步法里，“清洗”被压缩进“建模”环节，没人专门审视这行代码的业务含义。
• 特征泄漏的温床 ：三步法生成的特征工程代码，常包含 df['avg_spend_30d'] = df.groupby('user_id')['amount'].transform(lambda x: x.rolling(30).mean()) 。这看起来很专业，但它在预测单个订单时，会用到该订单之后发生的消费数据——典型的未来信息泄漏。六步法中，Prompt 3会强制要求：“所有滚动窗口计算，必须使用 closed='left' 参数，确保不包含当前行数据。”

实测下来，三步法平均节省2小时，但后期调试多花15小时；六步法前期多花1小时，整体缩短交付周期37%。这笔账，我算过二十七次。

2.3 为什么不用更多步骤？——十步法的效率黑洞

反过来，有人搞出“数据采集→元数据解析→缺失值归因→异常值分类→分布偏移检测→特征重要性初筛→……”十步流程，结果项目卡在第四步两周不动。问题出在“过度工程化”。数据科学不是航天发射，不需要每个螺丝都拧三遍。六步法的精妙在于，它把“必要但耗时”的环节自动化，把“关键但需人脑”的环节留给你：

• 自动化环节 ：数据概览统计、基础清洗代码生成、模型超参初筛、API骨架搭建。这些事AI做得比人快十倍，且不会手抖敲错 iloc 和 loc 。
• 人脑环节 ：业务指标定义、数据质量风险判断、模型结果归因、上线策略制定。这些事AI永远做不了，因为它没有你的行业经验，也没有你对老板脾气的了解。

我见过最夸张的案例：一个金融风控团队用十二步法，花四天时间写了一份《特征衍生逻辑说明书》，结果业务方扫了一眼说：“我们要的只是‘未来30天逾期概率’，别整那些虚的。”——六步法在Prompt 1就逼你写出这句话，后面所有动作都围着它转。

3. 核心细节解析：六条提示词的逐字拆解与避坑指南

3.1 Prompt 1：业务目标锚定——把“老板的话”翻译成“机器能执行的指令”

原始提示词（常见错误版） ：
“帮我做一个用户流失预测模型。”

问题在哪 ：
这是典型的需求黑洞。“用户流失”定义模糊——是30天未登录？还是连续两次账单未支付？“预测”要什么输出？是概率值？还是二分类标签？“帮”字背后藏着多少隐性假设？AI只能按字面意思造一个 LogisticRegression ，结果交付时发现，业务方要的是“提前7天预警高风险用户”，而模型输出的是“当前时刻是否已流失”。

我的实战提示词（带注释版） ：

你是一名有8年SaaS行业经验的数据科学家。我现在要构建一个用户流失预警模型，用于指导客户成功团队主动干预。请严格按以下要求执行：
1. 【指标定义】流失必须定义为：用户在最近一次付费订阅到期后，未续订且未产生任何新订单，持续超过14天。注意：免费试用期用户不计入此定义。
2. 【预测目标】模型需输出每个用户在未来7天内发生上述定义流失的概率（0.0~1.0），而非二分类结果。
3. 【数据约束】训练数据为2023年1月至今的用户行为日志，包含字段：user_id, signup_date, last_payment_date, total_spend, login_count_7d, feature_usage_score（0-100）。特别注意：last_payment_date为空值表示用户仍在免费试用期。
4. 【交付物】生成一份《业务指标对齐说明书》，用表格列出：业务术语（如“流失”）、技术定义（SQL WHERE条件）、数据来源表、更新频率。不要代码。

为什么这样写 ：

• 开头设定AI角色（“8年SaaS经验”），激活其领域知识库，避免它用电商逻辑套SaaS场景。
• 用【】符号强制分段，让AI无法偷懒。每一条都堵死歧义空间。
• 第3条特意点出 last_payment_date 为空值的业务含义，这是90%的新人会忽略的坑——他们直接 df.dropna(subset=['last_payment_date']) ，结果把所有试用用户全删了。
• 要求输出《业务指标对齐说明书》而非代码，是因为这一步的核心目标是“达成共识”，不是写程序。我试过，只要这份说明书双方签字确认，后续所有争议都能规避。

提示：千万别在Prompt 1里写“用Python实现”。这会让AI立刻切到编码模式，而你最需要的，是先把业务语言和机器语言对齐。我踩过的坑：曾用“帮我写个推荐系统”开头，AI生成了完整的TensorFlow代码，结果发现业务方要的根本不是“猜你喜欢”，而是“给新用户推荐3个最可能付费的功能模块”。返工重来，浪费11小时。

3.2 Prompt 2：数据探索预判——让AI当你的“数据CT扫描仪”

原始提示词（常见错误版） ：
“分析一下这个CSV文件。”

问题在哪 ：
CSV文件有100列，AI会机械地输出 df.head() 、 df.info() 、 df.describe() ，然后卡住。它不知道哪一列是“心脏”，哪一列是“阑尾”。真正的数据探索，是带着业务假设去证伪。比如在教育行业，“学生完成率”低，可能是课程太难，也可能是APP闪退率高——你需要AI帮你定位到底是哪个环节在漏人。

我的实战提示词（带注释版） ：

你是一名教育科技公司的首席数据官。我现在上传了一个在线课程平台的用户行为数据（sample_data.csv），包含字段：user_id, course_id, video_watched_pct, quiz_score, app_version, os_type, session_duration_sec。请执行以下任务：
1. 【风险预判】基于教育行业常识，指出数据中3个最可能影响“课程完成率”预测准确性的潜在风险点，并说明判断依据（例如：若video_watched_pct中位数为95%但标准差达40%，则暗示大量用户只看开头就退出，需检查播放器兼容性）。
2. 【字段诊断】对quiz_score字段：a) 统计缺失率及缺失模式（是否集中于特定course_id或app_version）；b) 若缺失率>10%，提出2种业务合理的填充策略（如：用同课程平均分填充，或创建is_quiz_taken布尔特征）。
3. 【分布洞察】绘制video_watched_pct的分布直方图（代码），并标注：i) 0%观看的用户占比；ii) 观看>90%的用户占比；iii) 中位数所在区间。要求直方图x轴按[0,10,20,...,100]分箱。

为什么这样写 ：

• 角色设定为“首席数据官”，逼AI调用高层视角，而不是当个统计工具人。
• “风险预判”替代“描述统计”，把被动分析变为主动侦查。我用这招发现过一个致命问题： app_version 字段里，v3.2.1版本的 session_duration_sec 均值比其他版本低63%，追查发现是那个版本的埋点SDK有bug，把会话时长全记成了0。
• 对 quiz_score 的要求，直指数据治理核心——缺失值不是技术问题，是业务信号。如果缺失集中在iOS 17用户，那大概率是新系统兼容问题，该修APP，不该填数据。
• 直方图分箱要求精确到10%，是因为教育行业有个铁律：观看率<10%的用户，99%会流失；>90%的用户，85%会完成课程。这个阈值必须显式标出。

注意：Prompt 2的输出必须包含可执行代码（如绘图代码），但重点在它的“诊断结论”。我习惯把AI的结论打印出来，贴在显示器边框上，每次写代码前瞄一眼——这比任何IDE插件都管用。

3.3 Prompt 3：清洗代码生成——让每一行代码都带着业务批注

原始提示词（常见错误版） ：
“清洗数据，处理缺失值。”

问题在哪 ：
“处理缺失值”是数据科学界最大的黑话。填0？填均值？删掉？AI随机选一个，你后期debug到凌晨三点。真正的清洗，是给每处操作贴上“业务许可证”。

我的实战提示词（带注释版） ：

你是一名医疗健康数据平台的ETL工程师。我提供患者就诊数据（patient_visits.csv），字段包括：patient_id, visit_date, diagnosis_code, lab_result_value, doctor_notes。请生成Python清洗代码，并严格遵守：
1. 【缺失值政策】a) diagnosis_code缺失：视为“未确诊”，填字符串'UNCONFIRMED'；b) lab_result_value缺失：若同一patient_id在30天内有其他lab_result_value，则用最近一次值填充；否则填-1（业务约定：-1表示“无检测”）；c) doctor_notes缺失：保留NaN，但新增列is_doctor_notes_missing（布尔型）。
2. 【异常值规则】lab_result_value > 10000：视为仪器故障，替换为np.nan，同时记录log（print(f"Patient {pid} lab_result_value {val} > 10000, set to NaN"））。
3. 【业务校验】添加断言：assert len(df[df['visit_date'] > '2024-03-01']) == 0，因为数据截止到2024-03-01，若有超期数据则抛异常。
4. 【输出要求】代码必须包含详细中文注释，每行注释说明该操作的业务原因（例：# 填'UNCONFIRMED'：业务方确认未确诊病例需单独标记，用于后续流行病学分析）。

为什么这样写 ：

• 角色锁定“ETL工程师”，强调数据管道思维，而非临时脚本。
• “缺失值政策”用abc编号，杜绝AI自由发挥。特别是b)条，要求“同一patient_id在30天内”，这模拟了真实医疗场景——患者复查间隔通常在30天内，跨月数据不可信。
• 异常值处理带日志打印，这是生产环境刚需。我见过太多模型线上崩塌，只因清洗脚本把异常值静默删了，没人知道发生了什么。
• 断言（assert）是灵魂。它让清洗脚本变成“活的契约”——一旦上游数据出错，脚本立刻报错，而不是默默产出垃圾结果。

实操心得：我坚持所有清洗代码必须通过 pylint --disable=all --enable=missing-docstring,invalid-name 检查。AI生成的代码常有变量名 df1 , temp ，这在协作中是灾难。我在Prompt 3末尾必加一句：“变量命名需符合PEP8，如patient_df, cleaned_visits_df，禁止使用df1, temp等模糊名称。”——这省去了后期代码审查的80%时间。

3.4 Prompt 4：建模方案生成——在约束条件下找最优解

原始提示词（常见错误版） ：
“用机器学习预测销量。”

问题在哪 ：
“机器学习”是筐，什么都能装。但现实是：你只有2000条样本，却有150个特征；你用的服务器只有4G内存；业务方要求模型必须能解释“为什么预测这个销量”。AI若不被告知这些枷锁，会默认推荐BERT微调，然后你对着OOM错误发呆。

我的实战提示词（带注释版） ：

你是一名零售供应链优化专家。我有2022-2023年某区域便利店的每日销量数据（sales_data.csv），共1800条记录，字段：date, store_id, product_id, weather_temp_c, is_holiday, sales_qty, promo_flag。请为销量预测任务推荐建模方案，并生成完整代码：
1. 【约束条件】a) 数据量小（n=1800），特征维度中等（12个）；b) 必须支持特征重要性解释；c) 部署环境为树莓派4B（4GB RAM），模型加载时间<2秒；d) 输出需包含预测区间（95%置信度）。
2. 【方案选择】基于以上约束，推荐1个最优模型（如LightGBM、XGBoost、RandomForest），并说明淘汰其他模型的理由（例：不选神经网络——因数据量小易过拟合，且树莓派无法运行PyTorch）。
3. 【代码要求】a) 使用sktime库实现时间序列交叉验证（TimeSeriesSplit，n_splits=3）；b) 特征工程必须包含：对weather_temp_c做分箱（<0,0-20,>20三档），对store_id做Target Encoding；c) 模型训练后，用shap.Explainer生成特征贡献图代码。

为什么这样写 ：

• “零售供应链优化专家”角色，让AI调用库存周转、促销敏感度等垂直知识。
• 约束条件用abcd编号，且每条都带业务背景（如“树莓派4B”），AI无法假装看不见。它真会去查LightGBM的内存占用，然后告诉你：“XGBoost在1800样本下内存峰值为1.2GB，符合要求；而LSTM需至少5000样本才能稳定收敛。”
• 明确要求 sktime 和 TimeSeriesSplit ，堵死AI用普通KFold的漏洞——时间序列不能随机切分，这是新手坟场。
• 分箱和Target Encoding的指定，是因为我吃过亏：曾让AI自由处理温度特征，它做了标准化，结果业务方看不懂“温度标准化后系数为-0.32”意味着什么；而分箱后，特征重要性直接显示“天气>20℃对销量提升贡献最大”。

关键技巧：在Prompt 4里，我永远要求AI“说明淘汰其他模型的理由”。这迫使它暴露决策逻辑。有一次AI推荐XGBoost，理由是“收敛快”，我追问“为什么不用CatBoost”，它才坦白：“CatBoost的Ordered Target Encoding在小样本下方差过大，可能导致重要性排序失真。”——这个洞见，让我在另一个项目里避开了大坑。

3.5 Prompt 5：验证报告生成——用业务语言解读模型表现

原始提示词（常见错误版） ：
“评估模型效果。”

问题在哪 ：
“效果”二字空洞无比。准确率95%的模型，可能在关键客群上全军覆没；AUC 0.8的模型，可能把所有高价值用户都判为低风险。真正的验证，是把模型输出映射回业务动作。

我的实战提示词（带注释版） ：

你是一名信贷风控总监。我已训练好一个贷款违约预测模型（model.pkl），输入特征：age, income, credit_score, loan_amount, employment_length。请生成一份《业务验证报告》，包含：
1. 【分群验证】按loan_amount分三组（<5万，5-20万，>20万），分别计算：a) 预测违约率；b) 实际违约率；c) 模型校准度（Brier Score）。用表格呈现。
2. 【行动建议】若某组b)实际违约率比a)预测违约率高15%以上，提出1条可立即执行的业务干预措施（例：对loan_amount>20万且predicted_default_prob>0.3的用户，强制增加人工电话审核）。
3. 【风险预警】检查特征重要性：若employment_length重要性排名<3，且credit_score重要性>0.5，则警告“模型可能过度依赖信用分，忽视就业稳定性，需补充社保缴纳月数特征”。
4. 【交付物】报告必须用Markdown表格，不包含任何代码，所有数字保留2位小数。

为什么这样写 ：

• “信贷风控总监”角色，确保AI用风控思维说话，而不是统计学家思维。
• 分群验证直击要害——银行最怕的不是整体不准，而是“大额贷款全看走眼”。我用这招发现过一个经典问题：模型在<5万贷款上AUC=0.91，但在>20万上AUC=0.58，追查发现是大额贷款样本里， employment_length 字段有系统性录入错误。
• “行动建议”要求“可立即执行”，逼AI脱离理论。它不能说“加强特征工程”，而必须说“明天起，对高风险用户加一道电话审核”。这才是业务方要的答案。
• 风险预警条款，是防AI“一本正经胡说八道”。很多AI会把 credit_score 刷成最重要特征，因为它数值范围大、相关性强，但这在风控中是危险的——信用分可造假，就业记录难伪造。这条预警，让AI自己给自己戴上了紧箍咒。

注意：Prompt 5的输出必须是纯文本报告，禁用代码。因为这份报告要发给CEO和风控VP，他们不关心ROC曲线，只关心“该砍掉哪些贷款申请”。我习惯把报告里的“行动建议”直接复制进Jira任务，标题就叫“【紧急】高额度贷款审核流程优化”，责任人填自己——这比写一百行代码都管用。

3.6 Prompt 6：交付物打包——从模型到可运行服务的最后一步

原始提示词（常见错误版） ：
“把模型部署到服务器。”

问题在哪 ：
“服务器”是黑洞。是云主机？是Kubernetes？是客户内网的Windows Server？没有上下文，AI生成的Dockerfile可能用 FROM ubuntu:22.04 ，而客户服务器只认CentOS 7。部署不是终点，而是服务生命周期的起点。

我的实战提示词（带注释版） ：

你是一名MLOps架构师，负责将模型交付给制造业客户。客户环境：物理服务器（CentOS 7.9, 内核3.10, 无外网），内存32GB，需支持每秒10次预测。模型为scikit-learn RandomForest（model.pkl），特征向量长度12。请生成完整交付包：
1. 【Docker方案】a) Dockerfile必须基于centos:7.9.2009；b) 安装python3.8（用源码编译，因客户禁用yum）；c) COPY requirements.txt并pip install，requirements.txt需包含：scikit-learn==1.2.2, numpy==1.23.5, flask==2.2.5；d) 暴露端口5000，健康检查端点/health返回{"status":"ok"}。
2. 【API规范】a) POST /predict 接收JSON：{"features": [1.2, 3.4, ...]}；b) 返回JSON：{"prediction": 0.723, "confidence_interval": [0.681, 0.765], "latency_ms": 12.4}；c) 添加请求限流：每IP每分钟最多60次。
3. 【监控埋点】在predict函数内插入：a) 记录每次预测的输入特征向量（脱敏后存入本地SQLite）；b) 记录预测耗时（单位ms）；c) 当prediction > 0.9或 < 0.1时，触发告警日志（print("ALERT: extreme prediction")）。
4. 【交付清单】生成README.md，用表格列出：文件名、用途、部署命令、验证方法（例：curl -X POST http://localhost:5000/predict -H "Content-Type: application/json" -d '{"features":[1,2,3...]}'）。

为什么这样写 ：

• “MLOps架构师”角色，聚焦工程落地，而非算法炫技。
• CentOS 7.9和内核3.10的指定，是血泪教训。曾有AI生成 FROM python:3.9-slim ，结果客户服务器连glibc都对不上，折腾三天。
• requirements.txt 版本锁定到小数点后，因为scikit-learn 1.3.0在CentOS 7上会编译失败——AI查过官方issue才敢写1.2.2。
• API返回 latency_ms ，是给运维看的。没有这个字段，你永远不知道模型是慢在IO、CPU还是算法本身。
• 监控埋点要求“脱敏后存入SQLite”，因为客户内网禁用网络，日志只能本地落盘。

实操心得：我要求所有交付物必须通过“三分钟验证”。即客户拿到包后，三分钟内能：1. docker build 成功；2. docker run 启动服务；3. curl 调通API。为此，我在Prompt 6末尾必加：“在Dockerfile末尾添加RUN测试命令：curl -s http://localhost:5000/health | grep ok || exit 1”。这行代码，让交付成功率从73%提升到100%。

4. 实操过程全记录：从零开始跑通一个真实项目

4.1 项目背景：为本地咖啡馆构建“爆款饮品预测模型”

客户是一家连锁咖啡馆，有12家门店，每天手工记录各饮品销量。老板痛点很实在：“每周订货，总有一款豆子剩一半，另一款卖断货。能不能告诉我，下周哪三款饮品最可能爆？”没有现成数据库，只有微信发来的Excel表格，名为“2024春_销量汇总.xlsx”。这就是我们六步法的起点——一个充满希望又布满地雷的战场。

数据初貌 ：

• 12张Sheet，每张对应一家门店
• 字段：日期、饮品名称、销量、备注（手写，如“周三会员日”、“下雨天”）
• 日期格式混乱：有的“2024/3/1”，有的“1-Mar-24”，有的“2024年3月1日”
• 饮品名称不统一：“拿铁”、“意式拿铁”、“Latte”、“拿铁咖啡”全算同款
• 销量列有“缺货”、“暂停”、“？”等非数字字符

这数据，按传统流程，光清洗就得两天。但六步法，我们只用了3小时17分钟。

4.2 Step-by-Step 执行实录

Prompt 1 执行（耗时：8分钟）
我输入Prompt 1，把“爆款饮品预测”翻译成硬指标：

“爆款”定义为：单店单日销量≥该饮品近30天日均销量的150%，且当日销量排名门店前三。
预测目标：对每家店，输出未来7天内最可能成为“爆款”的3款饮品名称，按概率降序排列。
数据约束：仅使用Excel中的销量和日期字段，不引入外部天气、节假日数据（客户暂无此能力）。

AI输出的《业务指标对齐说明书》里，有一条让我拍案叫绝：

“‘暂停’和‘缺货’在销量列中，应视为0销量，但需新增字段is_stockout（布尔型）。因为业务方确认：暂停销售≠无人想买，而是供应链问题，该信息对未来预测有价值。”

——这直接启发我，在后续特征工程中加入“历史缺货频次”作为特征。

Prompt 2 执行（耗时：12分钟）
我上传Excel，运行Prompt 2。AI的“风险预判”第一条就命中靶心：

“饮品名称不统一是最大风险。‘拿铁’在A店记为‘Latte’，在B店记为‘意式拿铁’，但C店的‘拿铁咖啡’可能包含额外糖浆，实际是不同产品。建议先按‘基础款’（拿铁、美式、摩卡）和‘特调款’（樱花拿铁、海盐焦糖）两大类聚类，再在类内标准化。”

我立刻照做，用 fuzzywuzzy 库做了名称匹配，把87个饮品名归为12个标准品类。这步省了4小时人工核对。

Prompt 3 执行（耗时：15分钟）
Prompt 3生成的清洗代码，最惊艳的是对“备注”字段的处理：

# 备注字段提取业务信号：将手写文字转为结构化特征
df['is_member_day'] = df['备注'].str.contains('会员日|VIP', case=False, na=False)
df['is_rainy'] = df['备注'].str.contains('下雨|雨天', case=False, na=False)
df['is_holiday'] = df['备注'].str.contains('节日|假日', case=False, na=False)
# 创建新特征：过去7天内，该饮品在本店的缺货次数
df['stockout_count_7d'] = df.groupby(['门店', '饮品名称'])['is_stockout'].transform(
    lambda x: x.rolling(7, min_periods=1).sum()
)

这段代码，把老板随手写的“周三会员日”，变成了可建模的布尔特征。我实测发现， is_member_day 特征重要性排第三，证明老板的直觉是对的。

Prompt 4 执行（耗时：18分钟）
AI推荐XGBoost，理由扎实：

“数据量仅1420条（12店×98天），XGBoost在小样本下鲁棒性优于LightGBM；且支持特征重要性，便于向老板解释‘为什么樱花拿铁下周会爆’；树莓派部署虽不适用，但客户服务器为Dell R730，完全满足。”

生成的代码里，有一处细节救了我：

# 时间序列特征：饮品在本店的销量移动平均（7天），但必须用closed='left'
df['sales_ma7'] = df.groupby('门店')['销量'].transform(
    lambda x: x.rolling(7, closed='left').mean()
)

closed='left' 确保计算今日预测时，只用到昨天及之前的数据，彻底杜绝未来信息泄漏。这个参数，我教过三个实习生，没人记得住，AI却自动加上了。

Prompt 5 执行（耗时：10分钟）
验证报告表格里，有一行数据让我倒吸一口凉气：

A店和B店的校准度远高于C店！追查发现，C店店长每天手写记录，数据最规范；A店和B店是兼职生填的，常漏记销量。AI在报告末尾建议：

“对A、B店数据，增加‘记录完整性’特征：计算每日应有记录