周一早上九点，我被一个报错卡死了

那天早上，我接手了一个同事留下的 Python 脚本，任务是批量处理 2000 多个 CSV 文件，把里面乱七八糟的日期格式统一成 ISO 标准。脚本跑起来不到三分钟就报错：ValueError: time data '2024/3/5' does not match format '%Y-%m-%d'。我盯着屏幕看了十分钟，脑子里全是「这数据到底有多少种格式」的绝望。后来我打开 Claude，把报错信息原样粘进去，加了一句「帮我写个能处理各种常见日期格式的解析函数」。它给出的方案是先用 dateutil.parser 做宽松解析，再对解析失败的行单独标记。我花了五分钟改完，重新跑，2000 个文件全部通过，耗时 4 分 12 秒。这个事让我意识到：AI 辅助编程不是帮你写代码，是帮你把「卡住的时间」压缩到几乎为零。

那次之后我摸到第一个门道：给 AI 的上下文，决定了它输出的质量。光贴报错不够，你要把「输入数据长什么样」「你期望的输出是什么」也说清楚。我试过只贴报错，它给的修复方案经常是「把格式改成 %Y-%m-%d」，但实际问题是有 7 种不同的日期格式混在一起。后来我改成这样描述：「输入是 CSV 里的一列，包含 2024/3/5、2024-03-05、2024.3.5、20240305 这几种，请写一个函数统一转成 datetime 对象，处理不了的返回 None。」效果立竿见影，它直接给出了带正则预处理的完整方案。所以我的第一条建议是：把「数据长什么样」写进提示词，别只贴错误信息。这个方法在 Cursor 和 GitHub Copilot 里都适用，我 90% 的报错都是靠这个方式解决的。

需求拆解：把一句话变成 20 个子任务

三周前，我帮一个做电商的朋友写个「自动比价」脚本。他原话是：「帮我写个程序，每天早上去京东和淘宝搜几个商品，把价格发到我邮箱。」这种需求直接丢给 AI，它大概率会给你一个「爬虫 + 邮件」的大杂烩代码，跑起来全是反爬问题。我当时的做法是：先花 15 分钟把需求拆成 6 个模块——商品搜索接口、页面解析、价格提取、数据对比、邮件发送、定时调度。每个模块单独问 AI，让它给出最小可运行的代码片段。比如搜商品，我让它先返回前 5 条结果的标题和价格，不要管翻页；页面解析，我让它用 BeautifulSoup 写个函数，只提取 span.price 里的文本。这样每个片段都能单独验证，哪一步挂了就单独修。

拆解的核心逻辑是：AI 擅长写「函数级」的代码，不擅长设计「系统级」的架构。你让它一口气写 20 个子任务，它会把错误处理、异常捕获全揉在一起，出错时你根本不知道是网络问题还是解析问题。我实测过：拆成 6 个独立函数后，每个函数的调试时间平均不到 8 分钟，整个项目从零到调通用了 2 小时 40 分，比我自己写快了差不多 3 倍。具体操作上，我用的提示词模板是：「我要实现 [功能]，输入是 [类型]，输出是 [类型]，请给我一个独立的 Python 函数，包含最基本的异常处理，注释写清楚每一行的作用。」这个模板我用了快两个月，成功率很高，尤其在处理文件操作、网络请求这类有明确边界的任务时。

让 AI 自己找 bug：把「修复方案」变成「选择题」

上周五下午，我在写一个从 PDF 里提取表格数据的脚本，用 pdfplumber 库。脚本在本地 20 个 PDF 上跑得好好的，换到同事发来的 3 个扫描版 PDF 上，直接报 IndexError: list index out of range。我一开始让 AI 直接修，它给的建议是「加一个 if 判断」，但我根本不知道这个 if 该判断什么。后来我换了个问法：「这行代码在什么情况下会越界？请列出 3 种可能的场景，并告诉我每种场景对应的数据特征。」它列出的第二种场景是「PDF 页面里没有表格边框线，导致 table.find_tables() 返回空列表」，我一看，扫描版 PDF 确实是没边框的。然后我让它针对「空列表」场景给修复代码，它给出了一个判断 if not tables: continue 的方案，问题立刻解决。

这个技巧的关键是：别让 AI 直接给答案，先让它分析「为什么会发生」。AI 在生成修复代码时，经常基于「最常见的原因」瞎猜，但实际报错原因可能很偏门。你让它先列可能场景，其实是在逼它做「根因分析」。我统计过自己过去两周的调试记录：用「直接修」的方式，一次修对的概率大概只有 35%；用「先列场景再选择」的方式，一次修对的概率能到 70% 以上。而且这个过程里，你对代码的理解会加深——因为 AI 列出的场景，你会在脑子里跟自己的数据比对，这比单纯复制粘贴修复代码有用得多。如果你用的是 Cursor，还可以直接选中报错行，按 Cmd+L 让它解释这段代码的「假设条件」，效果类似。

调通之后：让 AI 帮你写测试和文档

代码能跑了，不代表能交付。我有个习惯：任何脚本在发给别人之前，必须有三样东西——单元测试、使用说明、参数注释。以前这些事最烦人，要花的时间比写代码还多。现在我用 AI 做的流程是这样：代码写完后，我把整个函数文件丢给 AI，说「请为每个函数写 3 个测试用例：一个正常输入、一个边界输入、一个异常输入」。它生成的测试代码，我只需要改改输入值就能跑。比如我之前写的日期解析函数，它给出的边界测试是「空字符串」和「None」，异常测试是「2024-13-45」这种非法日期，跑完确实能暴露问题——我的原函数对空字符串会抛异常，我加了个 try-except 才过。

文档方面，我让 AI 根据函数签名和 docstring 自动生成 README，重点包含「安装依赖」「运行命令」「输入输出示例」三块。实测下来，AI 生成的文档有 80% 内容可以直接用，剩下 20% 需要我补充「实际数据格式」和「已知限制」。这个环节的价值在于：AI 写测试和文档的速度是人的 10 倍以上，而且不会遗漏「边界条件」。我算过一笔账：手动写测试和文档，一个 200 行的脚本大概要 1 小时；用 AI 辅助，压缩到 15 分钟，其中大部分时间在「改参数」而不是「想逻辑」。对个人开发者来说，这省下来的时间足够我再多写一个功能模块了。

💬 你在用什么AI工具？

写了这么多，我用的工具其实一直在变：从最早的 GitHub Copilot，到后来换 Cursor，现在主力是 Claude 配 Continue 插件。每个工具都有自己的脾气：Copilot 在补全「重复性代码」上很强，Cursor 的「多文件编辑」能力在重构时很香，Claude 的「长上下文」让它更适合分析整个项目的报错。但工具好不好用，不是看官方宣传，得看真实用户怎么投票。我在 AI House 排行榜（aibunkhouse.com/rankings/）上看过几个工具的评分，有些排名靠前的工具我压根没听过，但评论区里有人说「处理长文档比 GPT-4 稳」，我就去试了试，确实有惊喜。你也去逛逛呗，看看最近大家都在给哪些工具打高分，顺便给你用得顺手的那个投一票——反正投票又不要钱，就当给开发者一点鼓励。对了，你最近调通一个最难搞的 bug，用的是哪个工具？评论区聊聊，我下篇文章想写个「工具实测对比」，需要点真实案例。