收益：
- 能够通过为人工智能提供清晰的模式和目的，获取强大的 SQL 和 pandas 代码并逐行读取和验证它
- 能够捕获静默错误，例如行计数、拟合函数和合并/连接后的吞吐量
- 能够在调试中解决问题而不静默它，并避免在生产环境中测试代码的情况下运行代码
数据科学有两种主要语言：SQL（结构化查询语言——从数据库查询数据的语言）和Python（具体来说，pandas 库——以编程方式操作表的标准工具）。在本单元中，我们将学习使用人工智能作为代码合作伙伴：通过正确的问题从中获取可靠的 SQL 和 pandas 代码，阅读和验证该代码，调试它，并且永远不要盲目运行它。 AI 在几秒钟而不是几分钟内编写重复的代码；但您的工作是确保它生成的代码以正确的逻辑处理正确的列。工作代码并不意味着正确的代码。
为什么用人工智能生成代码功能强大但风险很大
AI 在代码生成方面提供了三大优势：速度（在几秒钟内编写 30 行 groupby-pivot 操作）、提醒（提醒你忘记的 pandas 函数）和教学（逐行解释代码）。但它带来三个风险：静默逻辑错误（对错误列求和的代码运行没有错误）、拟合函数（建议不存在的方法）和产量陷阱（适用于小数据但在 1000 万行时崩溃的代码）。所以黄金法则是：像你自己编写的一样阅读人工智能的代码。不要运行你不明白的行。
SQL：在源头处理数据
SQL 允许您从数据库检索数据并在那里进行处理；您可以汇总数百万行代码，而无需将它们拖入 Python。基本构建块：SELECT（哪些列）、WHERE（哪些行）、GROUP BY（分组和汇总）、JOIN（连接表）、HAVING（分组后过滤器）。 AI 在编写复杂的 JOIN 和窗口函数时非常有帮助，但请务必检查两件事：JOIN 是否通过正确的键（错误的键会重复行）以及过滤器逻辑是否正确（尤其是 NULL 行为和日期范围）。
注意：请勿直接针对生产数据库运行 AI 生成的 SQL 查询。首先使用小副本或 LIMIT 进行测试。切勿在未验证 WHERE 条件的情况下运行 UPDATE/DELETE 查询；错误的WHERE可以删除整个表。
Python/pandas：灵活分析
pandas 是在 Python 中操作表（DataFrame）的标准方法。对人工智能最有效的利用是给它一个明确的方案和目的。最常用的操作：filter、groupby、merge、pivot_table、apply。人工智能可以快速写出这些内容；您要检查的是逻辑：分组是否在正确的列中，合并是否意外更改了行数（始终检查合并后的行数），链式操作是否更改了原始行数。
交易
SQL
熊猫
检查站
过滤
哪里
df[df.x > 5]
NULL/NaN 行为
分组
分组依据
df.groupby()
它是正确的列吗？
合并
加入
df.merge()
行数变化
总结
平均值()、总和()
.mean(), .sum()
收集了哪一列
排序依据
订购依据
.sort_values()
方向（升/降）
重复数据删除
独特
.drop_duplicates()
在哪几列？
调试：使用AI
当代码失败时，人工智能是一个优秀的调试伙伴。给它完整的错误消息和相关的代码片段。但要小心两个陷阱。首先，人工智能可能会建议一种“沉默”错误的解决方案（例如隐藏警报）——这不会修复错误，而是隐藏错误。其次，人工智能有时会在“解决”问题的同时默默地改变另一种行为。规则：理解修复，解决而不是静音，并验证修复后输出仍然正确。
想要可解释和可维护的代码
从人工智能购买代码时，要求代码具有可读性和可维护性，而不仅仅是“有效”的代码。当您或同事几个月后打开该代码时，它应该能够理解它的作用。为此，请养成让 AI 包含三件事的习惯：有意义的变量名称（orders_temiz，而不是 df2）、关键步骤的简短注释行（解释原因，而不是正在做什么）以及命名常量而不是幻数（ACCEPT_ESIGI = 0.85 而不是埋在代码中的 0.85）。还要避免长单行链（一行连接五个动作）；这些使调试变得困难。默认情况下，人工智能通常会生成简洁且“智能”的代码；如果你明确地说“编写可读、可解释、可维护”，你将得到更可维护的输出。这也是可重复性的基础（单元 10）：不被理解的代码是无法安全地重新运行的代码。
三个迷你箱子
案例 1 — JOIN 复制。一位分析师将订单与产品表结合起来，发现总营业额增加了 3 倍。原因：每个产品在产品表中有多行（不同颜色）； JOIN 复制每个订单。 AI的代码“工作”了，但行数从24万行跃升至69万行。教训：总是检查合并/连接后的行数。
情况 2 — 拟合函数。他向实习生推荐了 AI df.groupby('x').summarize()； pandas中没有这样的方法（有.agg()）。代码不起作用，实习生迷失了20分钟。课程：验证文档中您不认识的功能； AI可以编造方法。
案例 3——产量崩溃。一个代码是在 apply 中查询数据库的每一行；它运行了 5,000 行，运行了 400 万行，花了 9 个小时，然后停止了。当 AI 建议采用矢量化（批量）解决方案时，时间缩短至 40 秒。教训：适用于小数据的代码可能会在大数据上崩溃；考虑效率。
四个可复制模板
1）使用schema请求SQL：
您的角色：SQL 助手 (PostgreSQL)。表：- 订单（id、customer_id、日期时间戳、金额数字）- 客户（id、城市文本） 任务：获取 2024 年每个城市的总营业额和订单数，按营业额降序排列。解释一下如何处理 NULL 城市。我将首先使用 LIMIT 测试查询；更新/删除生成。
2）带有检查点的pandas进程：
我有 DataFrames df （订单）和 df_customers （客户）。计算每个城市的平均金额。重要提示：打印合并前后的行数，以便我可以查看是否存在重复。解释一下您在哪一列中合并以及为什么选择内部/左侧。
3）代码解释及验证：
Explain the following pandas code line by line: what does each line do, what assumptions does it make, in what cases could it give wrong results?让我知道我是否使用了软糖功能。代码：[粘贴]
4）调试：
这段代码给出了这个错误。完整错误消息：[粘贴]。代码：[粘贴]。解释错误的根本原因并修复它。通过实际解决问题来解决问题，而不是通过消除警报来解决。还指出修复是否更改了输出。
弱提示/强提示
弱提示：
编写一个查询，给出每个城市的销售额。
表名、列、数据库类型、NULL 行为不清楚。 AI很常见，它可能会产生不适合你的表的查询。
强力提示：
您的角色：SQL 助手 (MySQL 8)。表：销售额（id、城市 varchar、金额小数、日期 date）。任务：获取2024年每个城市的订单总额、平均金额、数量；按总量递减排序；仅显示订单数超过 100 的城市 (HAVING)。NULL 排除城市。解释查询；我将用 LIMIT 进行测试。
这里数据库、模式、过滤器、排序和NULL规则是显而易见的。
常见错误
- 运行代码而不阅读它。工作代码不是正确的代码；操作错误列的代码也可以正常运行。
- 合并/连接后不检查行数。错误的键会默默地重复行并增加总数。
- 不验证拟合函数。人工智能可能会建议不存在的方法；从文档中确认您不认识它。
- 不考虑效率。应用/循环处理数百万行的小数据崩溃；矢量化。
- 直接在生产数据库上运行。特别是在没有 WHERE 或测试的情况下运行 UPDATE/DELETE 是灾难性的。
提示：养成在从 AI 收到的每段代码中添加“验证行”的习惯：预处理和后处理的行数、一些示例行以及手动的关键总数。这三项检查可以捕获大多数无声的逻辑错误。
综上所述
AI是快速生成SQL和pandas代码的强大伙伴，但它并不是盲目的权威。给他明确的计划和目的；阅读它生成的代码，就像您自己编写一样；检查merge/JOIN后的行数、拟合函数和吞吐量；如果没有在生产数据库上进行测试，请勿运行它。调试时，旨在解决问题，而不是沉默它。有效的代码不是正确的代码；只有您才能保证准确性。
应用任务
选择一个分析问题（例如“每个渠道的月营业额”）并使用 SQL 和 pandas 向 AI 请求代码。逐行阅读这两段代码，检查合并/连接后的行数，并手动验证至少一个临界和。比较两个代码是否产生相同的结果；如果不同，找出原因。
清单
- [ ] 我是否向 AI 明确提供了表格/架构和目的？
- [ ] 我是否逐行阅读并理解了它生成的代码？
- [ ] 我是否检查了合并/连接后的行数？
- [ ] 我是否验证了文档中无法识别的功能？
- [ ] 我是否首先在安全/小数据上而不是在生产环境中测试了代码？