以调试为先的人工智能工作流：为何我让我的助手故意搞砸事情

2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家 

大多数人使用人工智能助手来编写代码。而我开始先用它来破坏代码。

这听起来有违直觉，但工作流程中的这一改变让我的缺陷率降低了一半，并使代码审查真正变得有意义。

先写后查的问题

默认的人工智能编码工作流程如下：

1. 描述你想要的功能
2. 人工智能编写代码
3. 你进行审查
4. 你（可能）发现缺陷
5. 你修复它们

问题就出在第4步。审查人工智能生成的代码很难，因为代码看起来是正确的。它结构良好、缩进规范、变量命名合理。你的大脑会将其模式匹配为“优质代码”，从而忽略其中的逻辑错误。

我称之为正确性表演——代码展现出专业能力，但实际上并不正确。

先调试的方法

我采用的做法如下：

第一步：编写规格说明（30秒）

函数：calculateShippingCost(订单)
- 输入：包含 items[]、目的地、配送方式 的订单
- 输出：{ cost: 数值, estimatedDays: 数值 }
- 规则：订单金额超过100美元免运费，加急配送费用为基础费用的2倍，
  国际配送额外收取15美元固定费用，空订单应抛出错误

第二步：请求失败场景（人工智能的第一项任务）

根据上述规格说明，列出此函数可能失败或产生错误结果的10种方式。
请具体说明——包括会触发每种失败的输入。

人工智能会返回类似以下内容：

1. items 数组为空 → 应抛出错误，但可能返回0美元
2. 订单总额恰好为100美元 → 边界情况：判断条件是 > 还是 >=？
3. 商品价格为负数 → 总费用可能变为负值
4. 缺少目的地 → 国际配送检查静默失败
5. 加急配送 + 国际配送 + 免运费 → 各规则应按什么顺序应用？
6. 单件商品价值101美元 → 享受免运费，但加急费用是基础费用的2倍，基础费用是多少？
7. 浮点数精度问题：33.33美元 × 3 = 99.99美元，而非100美元
8. 配送方式缺失（shipping_method 为 null）→ 行为未定义
9. 目的地为 ""（空字符串）→ 非 null，但无效
10. 商品数量为0 → 是否计入总金额？

这个过程只需10秒钟，我就已经比编写规格说明时更清楚地理解了自己的需求。

第三步：将失败场景转化为测试用例（人工智能的第二项任务）

为每个失败场景编写一个测试用例。每个测试用例当前都应失败
(因为我们尚未编写实现代码)。使用 Vitest。

现在，在编写任何实现代码之前，我就已经有了10个测试用例，明确定义了什么是“正确”。

第四步：编写实现代码（人工智能的第三项任务）

编写 calculateShippingCost() 函数，使其通过全部10个测试用例。