AI 的上限取决于你的「完成定义」：把模糊任务变成可检验任务

本文讲一个简单的想法：AI 的表现好不好，取决于我们的「完成定义」（Definition of Done）——也就是我们在「任务完成」和「任务没完成」之间划下的那条清晰的线。

我们会看到：完成定义到底是什么、为什么 AI 在机器可检验的任务上显得神奇、为什么在只有人能判断的任务上显得不可靠、AI 背后运行的循环如何制造出这个差距，以及如何写出一个能把模糊任务变成可检验任务的完成定义。

内容涵盖：

• 什么是完成定义
• 完成定义精确的任务
• 完成定义模糊的任务
• 为什么 AI 恰好在我们能度量的地方最强
• 如何写出更好的完成定义

我是 Amit Shekhar，Outcome School 创始人，长期教 AI 与机器学习课程。

什么是完成定义

每当我们把任务交给 AI，涉及两样东西。

第一样是目标：我们想要什么。

第二样是检验器：我们怎么知道 AI 真的做到了。

完成定义 = 目标 + 检验目标的方式

大多数时候，我们给了目标，却忘了检验器。我们说”做这个功能”，AI 给我们两百行代码，然后我们坐在那里逐行读，判断它对不对。这种情况下，我们自己就是检验器。

检验器（也叫验证器）是任何能看着输出、不带任何观点地说出”通过”或”不通过”的东西。单元测试是检验器。编译器是检验器。读代码的人也是检验器——只是一个很慢、而且累了一天答案会变的检验器。

本文的核心论点是：AI 在拥有快速且精确检验器的任务上极其强大，在没有检验器的任务上不可靠。差别不在模型的智力，而在我们的完成定义。

完成定义精确的任务

学这个概念最好的方式是举例。

假设我们先写测试，像这样：

@Test
fun `should return the discounted price`() {
    val price = calculateDiscountedPrice(1000, 20)
    assertEquals(800, price)
}

然后我们把任务交给 AI：写 calculateDiscountedPrice 函数，让这个测试通过。

这里，完成定义不是观点问题。测试要么绿要么红。AI 可以写函数、跑测试、看到失败、修代码、再跑测试。它自己重复这个循环，直到测试通过。

这里有一个重要观察：我们不需要信任 AI，只需要跑检验。

很多任务都属于这一类：

• 代码必须能编译。 编译器给出明确的通过或失败。
• 函数对特定输入必须返回特定输出。 比较一下，就知道结果。
• Bug 必须不再复现。 跑一遍步骤，崩溃要么还在要么消失。
• SQL 查询必须产出精确结果。 跑一下比较行即可。
• 数学答案必须与已知答案一致。 直接核对。

在所有这些场景里，机器检验机器。完成与未完成之间有一条硬边界，AI 可以自己一路走到边界。

这就是为什么 AI 在这些场景显得神奇：给它一个失败的测试，它会一直工作到测试通过。检验器在做最难的工作——一次又一次告诉我们真相。

完成定义模糊的任务

现在换到另一面。

我们打开编辑器，输入：“做登录功能。”

AI 做完了。代码能编译。界面打开了。用户能登录了。

现在，大问题来了：做完了吗？

我们不知道。原因是我们从没说过”做完”意味着什么。

看看这一句话里藏了多少东西：

• 网络中途失败会发生什么？
• Token 存储得安全吗？
• 密码输入框为空时会怎样？
• 错误提示对真实用户够友好吗？
• 这段代码六个月后还容易改吗？

这些没有一条被写下来，所以没有一条能被检验。AI 产出了看起来完整的东西，而看起来完整不等于完整。

但这里还有一个陷阱：单元测试的例子里，红色测试清楚地告诉我们还没完成；而这里没有任何东西变红。没有失败不等于正确。

再一个陷阱：有时测试存在也救不了我们。如果测试只覆盖正常路径，绿色只能证明正常路径能跑。AI 会在测试变绿的瞬间停下来——因为对 AI 来说，绿色就是完成。

代码之外也有同样的问题：

• “给这段内容写一个好摘要。”
• “给这个应用设计一个干净的架构。”
• “把这段代码改得更可读。”

“好""干净""可读”这些词承担了全部工作，而它们没有一个能被机器检验。

所以在这类任务里，唯一剩下的检验器是人。这正是我们无法完全信任 AI 产出的原因——不是 AI 弱，而是产出和我们之间没有隔着任何东西。

为什么 AI 恰好在我们能度量的地方最强

那么问题来了：为什么差别这么尖锐？

答案在循环里。

AI 不是一发就写出完美答案。它工作在循环里：尝试、检验结果、看到错误、修复、再试。真正的力量就在这个循环里。

但这个循环要持续运转，需要一样东西：每次尝试之后，它需要”我完成了吗”这个问题的答案。

有检验器的地方，循环自动运转。

AI 写函数、跑测试、看到红、读报错、修那一行、再跑测试。它可以重复十次五十次，不用问我们任何事。每一轮都给它诚实的信号，每一轮都让它更接近。测试变绿的瞬间，循环自己停下。

所以我们最终看到的，不是 AI 的第一次尝试，而是在多轮检验中幸存下来的那次尝试。

没有检验器的地方，循环在第一轮后就死了。

我们要一个干净的架构。AI 写了点东西。现在，没有东西可跑。没有红，没有绿。没有信号回来，AI 没有理由再试，它就停在那里。

所以我们看到的只是第一次尝试。一次猜测，我们却把它当成最终答案来读。

存在廉价精确检验器的地方，AI 有很多次机会；不存在的地方，AI 只有一次机会。

这就是我们作为开发者一直感受到的全部差别。同一个模型、同样的智力，一个场景里它在校正自己五十次之后才把输出给我们，另一个场景里它直接把第一次输出甩给我们。

而当检验器缺失时，我们就成了检验器。我们读输出、找问题、要求修改、AI 再试。循环还在转，但现在它以我们的速度在转，每一轮都消耗我们的时间和注意力。

如何写出更好的完成定义

那怎么办？答案说起来简单做起来难：把任务从模糊侧搬到精确侧。

看几个实操方法。

先写测试，再下任务。 这是能做出的最大改变。AI 得到一个自己能命中的靶子，我们得到绿或红的答案，而不是一个观点。

给出精确的输入和期望输出。 不说”把这个日期正确解析”，而是说：输入 25-08-2026，输出必须是 2026-08-25。

给出必须跑干净的命令。 “构建命令和测试命令都必须通过”是完成定义；“确保它能用”不是。

把边界情况变成实际用例。 不要写”妥善处理错误”，要写清单：空输入、网络超时、过期 token、重复请求。清单里每一行现在都可以被检验。

把模糊质量变成数字。 “把这个 API 变快”没法检验；“1000 行数据下响应必须低于 200 毫秒”可以检验。

然后是通常被跳过的一步：

诚实面对仍然不可检验的部分。 有些部分永远需要我们自己的判断。这个设计是否符合产品的方向？这里没有检验器，假装有，正是弱决策悄悄进入代码库的方式。

当我们知道哪部分有检验器、哪部分没有，我们就能精确知道 AI 产出的哪部分可以直接接受、哪部分必须自己读。这比用同等的怀疑去读一切要好得多。

模型不是上限，我们的清晰度才是上限。 我们能把”完成”说得越锋利，能安全交接的工作就越多。

所以，下次把任务交给 AI 之前，先问一个问题：我打算怎么检验它？

原文信息

• 作者：Amit Shekhar（@amitiitbhu），Outcome School 创始人，AI 与机器学习讲师 原文地址：