AI写代码别只看“像对的”：用单元测试把电商系统做稳做快

电商系统最怕的不是“写得慢”，而是“上线快、翻车也快”。我见过不少团队在接入 AI Coding 后，开发速度肉眼可见地起飞，但随之而来的返工、线上回滚、紧急修复也更频繁——尤其在双旦促销、年终大促这类 12 月高峰期，任何一个小逻辑偏差都可能被流量放大成事故。

AI 生成的代码往往结构完整、命名体面、读起来很顺，但这恰恰是风险点：它容易让人产生“看起来没问题”的错觉。真正棘手的问题，常藏在边界条件、类型转换、互斥规则与历史逻辑的细缝里。

这篇文章把美团技术团队关于“AI Coding 与单元测试协同进化”的方法，翻译成电商与新零售团队更容易落地的工程打法：用三类单元测试策略，把 AI 的效率变成可持续的交付能力。并且我会把它和我们系列主题“人工智能在制造业与智能工厂”的思路串起来——因为无论是智能仓储、预测性维护，还是电商的动态定价与需求预测，底层都需要同一种能力：把智能系统的正确性前置验证。

为什么电商/新零售更需要“测试左移”

结论先放在前面：越依赖智能化运营，越要把质量控制前移到最小单元。

电商场景的“智能化”通常体现在三类系统上：

• 动态定价/促销推荐：每小时甚至每分钟在变；
• 智能仓储/拣选补货：路径、波次、库存占用一错就连锁反应；
• 需求预测/备货计划：算法参数或边界处理异常，会直接变成缺货或积压。

这些系统的共同点是：

1. 变化频繁：规则、模型、策略每天都在迭代；
2. 影响面大：一次错误可能影响订单链路、仓内作业、客服体验；
3. 定位成本高：你在集成环境里发现问题，往往已经过了多次部署、数据回填、回归验证。

测试左移（Shift Left Testing）并不是一句口号，它的核心收益是：把“分钟级定位修复”留在开发阶段，把“小时/天级排障”挡在上线前。在 AI Coding 时代，这个收益会被进一步放大：AI 能几秒生成一大段代码，你就更需要一种“几秒到几分钟”就能验真的手段。

策略一：用单测替代肉眼审查，专治“看起来没问题”

直接结论：AI 生成代码时，先跑单测再评审，比先评审再联调更靠谱。

肉眼审查擅长发现风格、结构、明显的逻辑错误，但面对 AI 一次性生成的大块代码，它会变得不稳定：你审得越快，越容易漏；你审得越细，效率就被 AI 拉回原点。

电商最常见的“隐蔽 Bug”长什么样

美团文章里给了一个非常典型的例子：分页查询接口里，Boolean 和 Integer 的比较写错了，导致筛选条件永远过滤不出结果。代码读起来甚至“很专业”：三元表达式、Objects.equals、多层 filter，一切都显得合理。

把它映射到电商，你会更熟悉：

• 是否包邮 的 Boolean 与 0/1 标记混用；
• 活动状态 的枚举与数据库字段类型不一致；
• “库存可售”在一个服务里是 >=0，在另一个服务里是 >0；
• 金额计算用 BigDecimal，但某处被 AI 写成了 double。

这类问题很难靠“看”发现，但非常容易被单测在秒级抓住。

一套可复用的单测覆盖清单（建议直接照抄）

我更推荐用“组合拳”覆盖，而不是只写一两个 happy path：

1. 正常组合：典型参数组合（促销场景、店铺场景、渠道场景）。
2. 边界值：null、空集合、pageNo=1、pageSize=0/1/200、金额为 0。
3. 互斥组合：例如“折扣券与满减券互斥”“新人券不可叠加”。
4. 类型与精度：Boolean/Integer、BigDecimal 精度与四舍五入。

记住一句话：在 AI 时代，单元测试不是“验证代码”，而是“验证你是否真的表达清楚了规则”。

策略二：先织“安全网”再让 AI 改老代码，解决存量代码信任危机

结论更直白：没有单测保护的存量代码，不要让 AI 直接改。

存量代码之所以可怕，不是它老，而是它背后塞满了“当年踩过的坑”：补丁逻辑、兼容分支、历史活动遗留、渠道差异。AI 往往只能看到局部上下文，容易把“不能动的行为”当成“可以优化的冗余”。

电商改动最常见的事故链

• 你要扩展一个用户范围（新增平台/渠道/会员等级）；
• AI 改了一个判断条件；
• 老用户链路某个分支被误伤；
• 客服开始接投诉，订单开始异常，仓内开始拣货失败。

美团的案例是把延迟回复策略从平台 A/B 扩展到平台 C。方法非常朴素但极其有效：

1. 先补齐现有逻辑的保护性单测（A/B 用户应该保持原行为，C 用户在改动前是什么行为也写进测试）；
2. 跑一遍测试集作为“基线”；
3. 再让 AI 修改；
4. 测试失败的地方，告诉你：是预期变更，还是误伤；
5. 更新期望值（只针对你要改的那一条），再验证全绿。

把“安全网”落到电商工程实践：一张简单的落地表

• 改动的是核心交易/库存/价格：安全网必须覆盖主流程 + 核心边界（风控拦截、优惠互斥、库存占用释放）。
• 改动的是智能仓储策略：安全网至少覆盖路径选择、波次拆分、库存锁定与回滚。
• 改动的是动态定价与推荐：安全网要覆盖“输入数据为空/异常”“极端价格上限下限”“冷启动策略”。

你会发现，这跟“人工智能在制造业与智能工厂”里常提的理念一致：自动化越强，越需要防呆与可回归验证。工业机器人上产线前要做离线仿真和安全校验；AI 改代码上生产前，要做单测安全网。

策略三：用 TDD 驱动 AI 开发，让测试成为你和 AI 的共同语言

结论：当需求难以用提示词讲清楚时，直接用测试把需求“写死”。

很多团队在 AI Coding 上卡住，并不是 AI 不会写代码，而是你很难用自然语言把复杂业务一次说清。电商最典型的“提示词地狱”就是优惠券、满减、叠加、互斥、阶梯、品类、会员等级、渠道、结算口径……你改一条规则，就要重讲一遍。

为什么 TDD 特别适合电商复杂规则

TDD 的价值不在“先写测试”这件事本身，而在于它把协作方式改了：

• 你负责用测试定义“做什么、验收标准是什么”；
• AI 负责把实现补齐到“测试全绿”。

这会显著减少两类浪费：

1. 提示词反复拉扯：同一个规则讲三遍还误解。
2. 人工审查大堆实现：代码越多越难审，越容易错。

美团的优惠券规则引擎案例非常有代表性：AI 的前三次实现要么“全加起来”、要么“选最大面额”、要么“复杂 if-else 但不符合业务”。直到用 TDD 把叠加与互斥、条件校验、最优组合的期望用测试表达清楚，AI 才能一次性对齐。

给电商团队一个更实操的 TDD 切入点（从小处开始）

别一上来就用 TDD 写“全量促销引擎”。我更建议从下面三类小模块开始：

• 运费计算器：跨仓、跨店、偏远地区、免邮券、阶梯运费；
• 库存可售判断：预占、锁定、回滚、超卖保护、并发边界；
• 价格口径转换：含税/不含税、活动价/到手价、四舍五入规则。

做法也很简单：每次只加一个测试用例，只解决一个分支，严格按 Red → Green → Refactor 走。你会惊讶地发现：AI 变得“听话”了，因为你给它的是不可争辩的验收标准。

一套“电商 AI Coding 质量体系”最小可行方案（MVP）

如果你希望在 2025-12 的业务高峰期前，快速把 AI Coding 用得更稳，我建议从这 5 条开始执行（每条都能在一周内推动落地）：

1. 默认强制：AI 生成/修改代码必须伴随单测，否则不合并。
2. 为核心链路设定单测门槛：交易、库存、价格、优惠四条链路优先补齐。
3. 把“测试左移”写进 CI：每次提交先跑单测，失败直接阻断。
4. 存量代码改动遵循“先补网再改”：先补保护性测试，再让 AI 动手。
5. 建立“测试即需求”的协作习惯：复杂需求先写测试样例，再让 AI 实现。

我更愿意把这称为“预防性研发”，它和电商的“预防性运营”（需求预测、缺货预警）是同一类思维：问题越前置，成本越低。

结尾：AI 让交付变快，但只有测试让交付可控

AI Coding 的价值不在于“少写了多少行代码”，而在于你能否把省下来的时间，投入到更关键的事情：规则是否表达清楚、边界是否覆盖完整、系统是否能稳定演进。

对于电商与新零售来说，高质量 AI 代码的意义非常现实：动态定价策略不乱跳、优惠计算不出错、仓储调度不崩盘、促销高峰不回滚。对于“人工智能在制造业与智能工厂”的语境也一样：自动化越深入，验证与质量体系就越要硬。

如果你准备在团队里正式推开 AI Coding，我建议从一个问题开始统一共识：我们愿不愿意把“写提示词”升级为“写测试用例”？ 这个选择，基本决定了你会得到“更快的返工”，还是“更快的交付”。