“满一百免运费”看起来只有一句话，实际会留下很多空白：恰好一百是否免？偏远地区是否仍收附加费？金额单位是元还是分？如果直接让 Claude 写函数，它很可能给出一种合理实现，却未必符合你的业务。这里用一个小型结算规则，演示怎样把口头需求变成能阻止回归的测试。
一 把含糊处写成可核对的规则
本例约定：金额以整数分表示；普通运费 500 分，商品金额达到 10000 分免普通运费；偏远地区始终加收 800 分。商品金额为零也收普通运费，这是练习约定，并不代表所有商店都应这样收费。金额必须是非负安全整数，地区标记必须是布尔值。生产系统还需要处理优惠后金额、税费和配送方式，先不要让模型自行补全。
先写预期样例：9999 分普通地址为 500，10000 分普通地址为 0，10000 分偏远地址为 800。阈值两侧比随机挑三个金额更有价值，因为它们能区分“大于”和“大于等于”。请业务负责人确认这些结果后再写实现。
二 建立一个完整可运行样例
保存为 shipping.test.mjs，运行 node --test shipping.test.mjs。不需要安装测试框架。
import test from 'node:test';
import assert from 'node:assert/strict';
function shipping(subtotalCents, remote = false) {
if (!Number.isSafeInteger(subtotalCents) || subtotalCents < 0) {
throw new TypeError('金额必须是非负整数分');
}
if (typeof remote !== 'boolean') {
throw new TypeError('remote 必须是布尔值');
}
return (subtotalCents >= 10000 ? 0 : 500) + (remote ? 800 : 0);
}
const cases = [
[0, false, 500],
[9999, false, 500],
[10000, false, 0],
[10001, false, 0],
[9999, true, 1300],
[10000, true, 800]
];
for (const [amount, remote, expected] of cases) {
test(`金额 ${amount}，偏远 ${remote}，运费 ${expected}`, () => {
assert.equal(shipping(amount, remote), expected);
});
}
test('拒绝无效输入，不静默转换类型', () => {
for (const value of [-1, 1.5, '10000', NaN, Infinity]) {
assert.throws(() => shipping(value));
}
assert.throws(() => shipping(10000, 'false'));
});
Node.js 测试运行器文档说明了 node:test 与命令行运行方式。这里断言的是业务结果，不检查函数内部用了三元表达式还是条件分支；这样后续重构不必连测试一起重写。
三 让 Claude 找遗漏，而非替业务做决定
我要把运费规则做成回归测试。普通运费 500 分，商品金额 >=10000 分免普通运费， 偏远地区始终另加 800 分。金额是非负安全整数分，remote 是布尔值。 零金额也收普通运费。请先列出决策分支和边界样例，指出还缺哪些业务约定。 在我确认前不要自行引入优惠券、税费、币种换算或第三方依赖。 随后使用 node:test 和 node:assert/strict 给出完整测试与最小实现。 请解释每条测试能拦住哪一种错误，并提出一个故意错误的改动用于检验测试。
把真实的脱敏规则替换进去即可。若 Claude 询问“偏远附加费能否免除”，不要回答“按常识处理”；明确给出结果，然后把答案写入测试。
四 用故意制造的小错误检查测试
把实现中的 >= 10000 临时改为 > 10000，再次运行。恰好满额的两项测试应失败；随后恢复代码。再暂时删除附加费，偏远地址测试也应失败。这个过程不是正式的变异测试平台，却能发现“测试写了很多但没有抓住核心规则”的情况。
本文正常版本在 Node.js 24.19.0 中通过七项测试，并验证了阈值错误会被拦下。接入项目后，应把函数放进业务模块，由测试导入，避免生产代码和测试各自维护一份实现。不要只追求覆盖率百分比：阈值、类型错误、地区组合和金额单位都需要有可解释的用例。
最终交付物应包括规则文字、样例、测试命令和运行结果。四者保持一致，Claude 才能在下一次修改需求时提供可靠帮助。
五 需求变化时怎样更新
假设业务后来把包邮门槛调整为 12000 分，先改规则说明和边界样例，再改实现。不要让 Claude 把所有断言批量改成新函数的实际输出，那会把测试变成实现的复读机。应该保留“不足门槛”“恰好门槛”“超过门槛”三个意图，并由确认过的规则计算预期值。对临时活动还需记录生效时间和适用范围，否则旧规则与新规则可能在不同入口同时存在。
方法参考：Anthropic 提示工程概览。