这次数据损坏的直接原因是一个边界条件没处理好，爬虫在解析某个商品页的 DOM 树时，因为商家把“库存”字段写在了两个不同的 div 里，我的正则匹配到了第一个就返回了，结果那个 div 里写的是“库存：充足”，真正的数字在后面的 span 里。脚本跑了三天，把几千条库存数据全记成了“充足”，下游的库存预警系统直接瘫痪，客户打电话过来骂娘的时候，我后背全是冷汗。
以前我根本不屑写测试。觉得那是大厂流程的产物，我们这种野路子出身的，讲究的就是一个快，脚本能跑通、数据能出来就行，出问题了再修呗。这种思维在 2016 到 2018 年那会儿特别管用，那时候需求变得快，甲方要的就是“明天上线”，你跟他提单元测试他能把你轰出去。但现在不行了，2024 年了，我的交付物复杂度早就不是当年几个 Python 脚本能比的，n8n 工作流里十几个节点环环相扣，一个 API 频率限制没处理好，或者返回的 JSON 结构稍微变一下，整个流程就断在中间，查错成本高得吓人。
让我彻底转变的，就是这次“库存：充足”事件。我花了整整一个下午，手动去回溯日志，模拟各种页面结构，试图补全所有可能的边界情况。越写越绝望，你永远不知道那些前端开发会在什么时候、用什么奇葩方式把数据塞进页面。DOM 结构千变万化，光靠人脑去穷举，效率低到令人发指。那一刻我意识到，我过去鄙视的“流程”，其实是一种对“不确定性”的防御。而我的“快”，在系统稍微复杂一点之后，就变成了反复踩坑、修修补补的“慢”。
所以我开始让 AI 介入测试环节。具体做法是，我不再要求 ChatGPT 直接给我写一个完美的、覆盖所有情况的测试套件——那不可能，它也不了解我业务的所有细节。我换了个思路：我把我的核心函数代码丢给它，然后给它几个典型的、我遇到过的问题案例作为“提示”。比如，我会说：“这是我的解析函数，它从 HTML 里提取库存数字。请根据以下我踩过的坑，生成对应的测试用例：1. 库存信息分布在多个标签内；2. 库存显示为‘充足’、‘缺货’等文本；3. 页面结构缺失库存模块返回空值。” AI 会根据这些“坑”，生成一堆带着各种奇奇怪怪 HTML 片段的测试代码。这些代码当然不会完全正确，但它提供了一个极其丰富的“测试用例素材库”。
我的工作就从“创造测试用例”变成了“筛选和修正测试用例”。AI 生成的用例里，可能 30% 是重复的，40% 是边界模糊的，但剩下那 30% 里，总有几个是我完全没想到的刁钻角度。比如，它可能会生成一个用例，模拟库存数字被包裹在一段 JavaScript 注释里，或者前后有不可见的 Unicode 字符。这些情况在实际中虽然罕见，但一旦发生就是致命伤。我把这些有价值的用例挑出来，整合进我的 pytest 框架里。这个过程，相当于用 AI 的“穷举想象力”来弥补我人脑的“经验盲区”。
这带来了两个根本性的变化。第一是心理上的，我不再害怕修改代码了。以前加个新功能都提心吊胆，生怕把哪个老逻辑搞崩了。现在有几百个测试用例兜底，改完一键跑测试，大部分回归问题都能被抓出来。这种安全感是之前没有的。第二是交付节奏上的，看起来前期写测试、让 AI 生成用例花了时间，但后期调试、救火的时间被大幅压缩。尤其是面对客户临时加的需求，我能更快地评估改动的影响范围，而不是凭感觉瞎搞。
说到底，2024 年还在手工作坊式地写代码、调脚本，已经是一种效率上的犯罪。AI 不是来替代我写核心逻辑的——那个依然需要我的业务理解和设计——但它是绝佳的“辅助脑”和“压力测试机”。把那些重复、繁琐、需要大量穷举思维的工作丢给它，比如生成测试数据、构造边界场景，我才能把精力集中在真正的架构和业务逻辑设计上。所谓“慢就是快”，现在我的理解是，把时间投入到构建自动化的防御体系（比如测试）上，看起来起步慢了，但系统健壮了，后续的每一次迭代才能真正快起来。稳，不是不出错，而是出了错能立刻知道、立刻定位、立刻修复。这才是这个阶段，一个靠交付质量和可靠性吃饭的超级个体，最核心的竞争力。
