在 AI 辅助编程逐渐进入日常开发流程后，真正需要警惕的问题已经不只是语法错误。相比一眼可见的报错，更隐蔽的风险在于：代码可以运行，测试也能通过，却在某个合法业务状态上悄悄违反了接口约定。掘金上一篇关于任务 API 的复盘文章，提供了一个颇为典型的样本。
一个看似合理的校验，把合法请求挡在门外
这次问题出现在一个任务状态修改接口上。按照约定，前端通过 PATCH /api/tasks/:id 提交 JSON 数据，其中 completed 字段用于表示任务是否完成。接口只允许修改 completed，且该字段必须是布尔值。
AI 生成的校验代码采用了常见的写法：先从请求体中取出 completed，再用 if (!completed) 判断，如果为假就返回 400 错误，并提示“completed 必须是布尔值”；校验通过后再把 completed 赋值给任务对象并返回。
从表面上看，这段代码似乎完成了参数校验：有错误码，有错误信息，也拦截了非法输入。上线初期，请求 { “completed”: true } 确实能够正常执行，因此代码并未引起怀疑。
直到有用户希望把误标记为完成的任务重新恢复为未完成，服务才暴露出问题。当请求体为 { “completed”: false } 时，接口返回了 INVALID_STATUS 错误。换句话说，代码并没有阻止“撤销完成”这个业务动作，而是把合法的 false 误判成了无效值。
根因不在 AI，而在语言语义与业务规则错位
复盘发现，问题出在 JavaScript 的真假值判断机制上。if (!completed) 检查的并不是“completed 是否为布尔值”，而是“completed 是否为真值”。在 JavaScript 中，false、0、空字符串、null、undefined 都会在条件判断中被视为假值。
因此，当 completed 为 false 时，!completed 为 true，代码直接进入了错误分支。这种错误并不表现为崩溃，也不容易被常规流程测试捕获，因为正向路径完全正常，只有涉及“合法假值”的场景才会触发异常。
文章将这次失误归因于三个因素叠加。
- 需求表达不够精确。如果只告诉 AI“completed 必须是布尔值”，AI 可能生成最常见的非空校验，而不是真正检查类型。更准确的描述应是：completed 必须存在，且只能是 true 或 false；false 是合法值，不能视为缺失。
- 测试覆盖不完整。原有测试只验证了“可以将任务标记为完成”，也就是发送 completed: true 后返回 200，并确认字段为 true。它没有验证“可以恢复为未完成”，因此无法发现 false 被拒绝的问题。
- 代码审查停留在表面检查。审查者容易问“有没有参数校验”“有没有返回 400”“有没有测试”，这些问题都可能得到肯定回答。但更关键的问题是：合法值的完整集合是什么？每一个合法值是否都被测试过？false、0、空字符串在当前语言里是否会被混淆？
修复只需一行，但前提是识别业务边界
文章给出的修复方式并不复杂。对于明确要求布尔值的字段，不应使用真值判断，而应直接检查类型：如果 typeof completed !== “boolean”，再返回 400。这样，true 和 false 都能通过校验，符合接口契约。
也就是说，最终修复代码只有一行变化，但这一行改动依赖的前提，是开发者先意识到错误并非接口逻辑不支持撤销，而是校验实现误解了“布尔值”的含义。
修复之后，文章建议至少补充两组回归测试：一组验证可以把未完成任务标记为完成；另一组验证可以把已完成任务恢复为未完成。除此之外，还应补充非法输入测试，例如 undefined、null、0、字符串 “false” 等值都应返回 400。这类测试的价值不在于数量，而在于把“能完成”和“能撤销”两个业务状态都固定下来。
文章还提到，故障发生后，与 AI 协作排查时也不应只问“这段代码有什么问题”。更有效的方式是提供完整上下文，包括接口规则、实际故障、合法值范围，并要求 AI 输出已确认事实、最可能根因、需要检查的语言语义风险、最小修复方案、必须补充的回归测试，以及如何修改需求说明和 Prompt。尤其需要明确的是，false 也是合法业务状态，否则 AI 仍可能重复给出错误的非空校验。
对 AI 编程工程实践的提醒
这次案例给出的启示并不只限于一个接口。文章总结了几条值得开发者保留的检查清单：正常流程通过，不等于所有合法状态都被支持；语言中的真假值，不能替代业务规则校验；测试要覆盖值域，而不是只覆盖成功和失败；AI 输出中的简洁判断，尤其需要检查边界含义。
文章特别提到，以后看到 if (!value)、if (value)、value || defaultValue 这类写法时，建议多检查一眼。它们在处理字符串、数字、布尔值时，可能会把“合法的假值”误判成“缺失值”。
从更宏观的角度看，这次失误并不是 AI 不会写代码，而是开发流程把一个精确的业务规则交给了一个模糊的校验实现。AI 可以快速生成看起来合理的代码，但它不会自动理解某个字段在业务上是否允许为零、为空、为 false。这些边界条件必须被明确写进需求、测试和接口契约。
这也意味着，AI 编程时代对开发者的要求并没有降低。相反，开发者需要更清晰地确认规则、识别语言语义风险，并通过回归测试验收结果。每一次线上故障，都应沉淀为可重复执行的测试，而不是只完成一次临时修补。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/ai-xie-de-dai-ma-tong-guo-ce-shi-ye-ke-neng-chu-cuo-yi-ci
