给购物车补上免运费规则之前

你准备让编程智能体修改购物车：商品小计满一百元时免运费，否则收十元。直接要求它“把功能做好”很省事，但它可能误解门槛，也可能顺手改动无关代码。更稳妥的起点，是先把规则写成可以运行的测试，再让它修改实现。

这就是测试先行的基本思路。你不需要先学完一套测试理论，只需要把任务缩小到一条规则，并在每一步查看实际结果。

§ 先把一句需求拆成几个例子

测试会比较程序的实际结果与预期结果。预期从哪里来，需要你先决定，而不是交给智能体猜测。这个购物车任务可以先约定：

其中，一百元正好落在门槛上，是最值得检查的地方。如果需求没有说明优惠券是否影响商品小计，就先问清楚。测试能固定约定，却不能替你判断未确定的业务规则。

打开项目后，先请智能体找到现有测试、测试框架和运行命令。已有项目通常不需要为了这个小功能再引入一套工具。可以这样交代：

“请先阅读购物车相关代码和现有测试，说明运费在哪里计算、怎样运行相关测试。暂时不要修改文件，也不要安装依赖。如果发现业务规则不明确，先向我提问。”

接着运行一次现有测试，建立修改前的基线。如果原本就有失败，先记录下来，避免之后把旧问题误认为本次改动造成的问题。

明确位置和命令后，再给出下一步指令：

“只为刚才确认的三种金额添加测试，沿用项目现有写法，不修改业务实现。运行相关测试，报告失败原因，然后暂停。”

测试第一次失败，通常叫作“红灯”。这里要检查的是：它是否因为当前运费计算不符合规则而失败。缺少依赖、导入路径错误或测试根本没有被执行，都不能算有效的红灯。

如果测试直接通过，也不用刻意把代码改坏。先确认测试真的被运行、断言检查了运费结果；现有实现可能已经满足需求，这次只需补上防止以后改坏的测试。

确认失败原因正确后，再允许智能体修改业务代码：

“现在只做让这些测试通过所必需的修改。不要改变测试中的预期值，不要重构无关模块。完成后运行相关测试，列出执行命令和结果。”

测试通过叫作“绿灯”。但一句“已经通过”还不够，你要查看实际执行记录，以及修改前后的差异。特别留意智能体有没有删除断言、跳过测试，或把预期值改成当前错误结果。

如果运行环境不可用，就让它明确说明哪些测试没有执行、缺少什么条件。没有运行过的测试，不应被描述为已经验证通过。

如果新增逻辑重复或命名难懂，可以在测试通过后进行小幅整理。每整理一次，就重新运行相关测试。这一步通常叫作“重构”：改善代码结构，但不改变已经确认的行为。

最后再运行项目要求的更大范围检查，例如购物车模块测试和完整测试集。三条运费测试通过，只能说明这些例子符合预期，并不代表优惠券、退款或其他功能都没有受到影响。

如果你使用 Claude Code、Codex 或 Gemini CLI，可以通过 Vana API 接入模型。它提供 OpenAI 兼容接口，也支持 Anthropic Messages 和 Gemini 原生协议；连接时应按客户端要求选择配置方式，不要把不同协议的设置混用。

需要开始配置时，可以创建一个 Vana API 账户；服务按实际使用的令牌计费，没有月费。不要把密钥写进测试文件或提交到代码仓库，也不要为了测试上传真实客户数据。

无论使用哪个工具，验证方式都一样：先确认规则，再看测试是否因正确原因失败，最后检查实现和运行结果。对初学者来说，测试先行最实用的地方，就是让一次模糊的“帮我改好”，变成几步可以逐一核对的小任务。