这种「假完成」我上周遇到三次——AI 一口气报 5 次「全过」，3 次是假的，全是旧数据被覆盖这类无声坑。它是真觉得自己完成了，因为它的测试压根抓不住。问题不出在测试数量，出在断言设计。

这是 AI 编程避坑系列第 2 篇，承接《5 步驯服 Coding Agent》：那篇讲流程，这篇讲第三步「验收检查怎么写」里最容易翻车的一环。

先掰词

断言 = 测试里写死的一句「什么才算对」。 像验货对着清单逐项打勾，不是快递说「到了」就算到。断言只写「成功了没」，没写「它把旧数据覆盖了没」，测试全绿也拦不住假完成。

断言设计 4 步

第 1 步：预期和「不应发生」都要写

一条完整用例 = 前置条件 + 输入操作 + 预期结果 + 不该出现什么 + 怎么检查。

拿「导入 2 条新消息」举例：断言总数加 2 之外，还必须断言旧记录的原文、发布者一个字没变。关键字段逐个比，别只数条数。我练习题里的真实写法：

def import_messages(existing: list[dict], batch: list[dict]) -> list[dict]:
    seen = {(m["room_id"], m["msg_id"]) for m in existing}
    result = list(existing)          # 不改动已有记录（原文/发送者/采集时间保留）
    for m in batch:
        key = (m["room_id"], m["msg_id"])
        if key not in seen:          # 身份 = 房间 + 消息ID，不是文本
            seen.add(key)
            result.append(dict(m))   # 拷贝存入，避免外部对象后续被改
    return result

配套断言不能只写 len(result) == 2，必须逐字段比对已存在的 M01 原文未被改写——只检查「成功」，就永远发现不了「它把错误内容覆盖进去了」。

第 2 步：红灯要坏得对

TDD 先红再绿，但红的失败原因必须是「目标行为还没实现」。缺依赖、模块导不进来，那是考场坏了，不算验收——先修运行条件，这条测试还没开始检查业务规则。

测试第一次就直接绿：别故意改坏代码造假红灯。要么这个行为早已实现（保留测试即可），要么你的断言漏了关键结果。后者更常见。

第 3 步：查逻辑——固定假数据 + 模型替身

去重、筛选、引用越界这类题有标准答案，像数学题。喂固定假数据，把模型换成替身（它自己记录被调用几次），逐字段断言。数数是程序干的活，不归模型：

• 快照为空 → 断言 call_count == 0，模型一次都不许被调
• 引用越界 → 断言被拒，返回越界的 ID 清单

def validate_answer(answer: dict, input_ids: set[str]) -> tuple[bool, list[str]]:
    bad = [i for i in answer["cited_ids"] if i not in input_ids]
    return (len(bad) == 0, bad)

替身的价值是稳定制造「没调用 / 乱调用」这些边界，真模型反而演不出来。

第 4 步：看效果——真模型多跑几轮

摘要准不准、有没有编——程序能校验「引用没越界」，校验不了「引用真的支撑了回答」。这类必须真实调用 + 多样本 + 语义标准：允许措辞变，固定住「意思必须保留」。比如「爬长城很累吗」和「爬到一半能返回吗」被概括时，两条的差异有没有被揉掉——这是语义检查，替身做不了。

一次通过不等于稳定，同一条至少跑几轮看一致性。

速查表

1. 用例五件事：前置｜输入｜预期｜不应发生｜检查方法
2. 关键字段逐个比，不只数条数
3. 红灯 = 目标行为没实现，不是考场坏了；第一次就绿先查断言漏没漏
4. 逻辑用替身逐字段断言，效果用真模型多样本多跑几轮

验收时多看一眼

AI 报告「测试全部通过」时，去它的汇报里找两行：真实模型调用过没有？页面实际操作过没有？我那 3 次假完成，两次都是单元测试全绿、但「测试全过」覆盖的只是程序逻辑那一半——模型效果和用户流程根本没被执行过。

一句话收束：AI 写代码算不算做完，不能它嘴上说了算，断言说了算。

本篇最早于 2026 年 10 月 19 日发布于小红书，此为博客完整版。