代码的“健壮性”这五个字，今天在我草稿纸上被圈了两个红点，像两个血痂。上周那个数据采集脚本，就因为一个边界条件没处理好，把三万多条商品详情页的SKU数据全搅成了一锅粥，字段错位，价格和规格对不上。客户催报告催得跟催命一样，我硬是花了两天一夜手动清洗和重新爬取，DOM树解析、反爬绕过、多线程调度全白干了，最后还得赔笑脸。这种低级错误，在2016年那会儿我可能骂一句娘就过去了，但现在不行，2024年了，交付压力大得喘不过气，一次返工就能把利润全吃掉。
我复盘了一下那个bug，本质上就是个“如果列表为空则跳过”的逻辑，我写成了“如果列表不为空则继续”，脑子里想的是A，手指敲出来是B。人脑在连续编码四五个小时后，就是会短路。以前团队还在的时候，还能指望测试同事兜底，现在回归超级个体，每一行代码的坑都得自己填。我开始意识到，靠“我下次注意”是纯粹的自我欺骗，必须把验证环节机械化。
所以我现在让AI干这个脏活累活了。不是那种笼统的“帮我写个测试”，那没用。我的新流程是，先把核心函数或类的代码块丢给GPT-4，然后给它一个非常具体的指令模板：“请基于以下Python函数，生成pytest单元测试用例。要求：1. 覆盖所有参数的有效输入边界（包括空值、极值、非法类型）。2. 模拟该函数在爬虫场景中可能接收的真实数据格式（例如包含缺失字段的JSON、HTML解析后的None值）。3. 对涉及外部API调用的部分，使用`unittest.mock`模拟正常响应与异常响应（如429频率限制、502错误）。4. 输出测试用例代码，并附上每个用例的测试意图注释。”
这么一来，AI生成的东西立刻就能用。它给我列了十几个测试用例，有些边界情况我自己根本想不到，比如模拟网络抖动导致的部分HTML标签缺失时，我的解析函数会不会崩溃。我把这些用例跑一遍，绿了，心里才踏实。这比我自己吭哧吭哧写测试快多了，关键是更全面。AI没有思维盲区，它只会冷酷地遍历逻辑路径。
但这还不是终点。我把它升级成了自动化流水线。用n8n搭了个简单的流程：每次我在Git主分支推送新的功能代码，就自动触发一个工作流。这个工作流会调用Claude的API，把变更的代码diff发过去，让AI分析这次改动可能影响的范围，并自动生成或更新对应的集成测试用例脚本，然后自动在测试环境跑一遍。如果测试通过，才允许合并。这套东西刚开始搭费点劲，但跑顺了之后，相当于雇了个不知疲倦的测试员，24小时盯着我的代码质量。
慢就是快，稳就是赢。这话我现在才嚼出真味。2021年断尾求生那会儿，为了快，什么都自己硬上，结果漏洞百出，修bug的时间比开发还长。现在引入AI写测试，看似多了一个步骤，慢了，但实际上杜绝了深夜救火的恐慌，交付速度反而因为返工率骤降而提上来了。所谓的“健壮性”，不就是让系统在没人盯着的时候，自己也能扛住各种奇葩情况吗？我的代码要这样，我这个人，也得这样。
