有段时间我特别信任 AI 的汇报。它说"配置文件已创建"，我就往下一步走；它说"索引已同步"，我就当它真同步了。直到有一次我顺手 

代价最大的一次，是它说"任务已关闭、台账已记上"。我信了，结果下一周接手的新会话 AI 按那个 closed 状态继续推进，把一个其实没真正交付的依赖当成完成，一路推到汇报环节才被人发现对不上。那次之后我才意识到，"完成"没有凭据，就等于把判断权交给了上一条消息的记忆。

后来我数了数被坑的场景，翻来覆去就那么几类。于是我在项目根目录放了个 

，把"完成"翻译成 24 项能自动跑的断言。跑了一年多，这大概是我在 AI 协作上投入产出比最高的一件事。

一、AI 的"假完成"，基本就这三种

 一看啥也没有。多数时候是路径拼错了，或者父目录忘了建。

 AI 说"已同步索引"，但被删掉的东西在索引表里还挂着，成了孤儿引用。这个最阴，因为它不会报错，只会让下一个新会话的 AI 拿着过期信息去推理。

状态标了 closed，没留任何依据。

 任务被宣告关闭，下次开新会话时谁也判断不了它到底关没关，只能选择相信上一轮的汇报。

"完成"是模型凭记忆说出来的陈述，没人在验证它是不是真的。

我给自己定了四条，一年多没改过。

 文件在不在、JSON 能不能解析、两边数量对不对得上，这些硬事实交给脚本。需要理解力的部分才留给模型。

错误阻断，警告提示，退出码是唯一真相。

 脚本返回 0 才能收工，返回 1 一律不许往下走。

python3 verify.py          # 0 = 收工；1 = 修到绿为止

 这条看着最朴素，也最难坚持。我自己的做法是直接把它写进项目规则文件，让每个新会话的 AI 开工前先读一遍。

我把所有检查项归成五层，越往上越能抓到致命错误，维护成本也越高。建议先做下面三层，跑顺了再补上面两层。

我自己的脚本按这五层分了 24 项，分布是这样：

L3 一项就占了快一半。这个比例不是我事先设计的，是长出来的：每出一次"改了 A 忘了 B"的事故，就往里加一条对账。剩下的 3 项运行时健康检查走旁路，不阻断退出码，但会写进体检报告。

压到最小能跑的版本就这些。丢到项目根目录，改掉 

#!/usr/bin/env python3
"""verify.py — 项目级静态校验（最小可用版）"""
import os, sys, json
​
REQUIRED_PATHS = {
    "README":      "./README.md",
    "配置入口":     "./config/app.json",
    "工具脚本":     "./scripts/run.sh",
}
​
def check_paths():
    errs = []
    for name, path in REQUIRED_PATHS.items():
        if not os.path.exists(path):
            errs.append(f"路径不存在: {name} ({path})")
    _report("存在性检查", errs)
    return errs
​
def check_config_valid():
    errs = []
    p = REQUIRED_PATHS["配置入口"]
    if not os.path.exists(p):
        return errs
    with open(p) as f:
        cfg = json.load(f) if not errs else {}
    if "version" not in cfg:
        errs.append("配置缺少 version 字段")
    _report("配置可解析性", errs)
    return errs
​
CHECKS = [check_paths, check_config_valid]
​
def _report(name, errs):
    mark = "OK " if not errs else "FAIL"
    print(f"  [{mark}] {name}")
​
def main():
    errors = []
    for fn in CHECKS:
        errors.extend(fn())
    if errors:
        print(f"\n{len(errors)} 项未通过，不收工")
        sys.exit(1)
    print("\n全部通过，EXIT 0")
​
if __name__ == "__main__":
    main()

加检查项很简单：写个新函数，返回 

。每加一条就跑一遍，确认没把别的弄坏。

收获最大的不是脚本本身，是 AI 的行为变了。

 以前它汇报"已完成"，现在它会先跑一遍脚本再说："24 项里 23 项绿，1 项 warn，孤儿引用已修"。它开始主动自证，而不是等我质疑。

几个真实抓到的问题（都做了脱敏）：

还有一次，知识库的一个入口文档改了路径，引用它的几处导航没跟着改。verify 跑出来几行孤儿引用，我才发现下游的几个新会话一直在读一个已经 404 的页面，还基于它做了好几轮推理。

还有个我没预料到的收益：团队里几个 AI 角色协作时，校验脚本成了它们唯一共同信任的东西。每个角色不用相信别的角色的汇报，只需要信脚本。

一上来就写 20 项，把自己劝退了。

 第一版我只做了 L1 加 L2，跑通了再往上加。

断言绑了易变的实现，脚本天天红。

 绑"路径在不在"，别绑"第几行有什么字符串"。内容会变，结构不会变。

 子进程调用一定要加超时，失败只记 warn，别算进 errors。

 这条最反人性，我自己也破过戒。只要开了口子，脚本迟早变成走过场。

破戒那次是赶一个对外材料的 deadline，有一条配置校验因为环境差异本地一直红，我图快给它加了 

if os.environ.get("LOCAL") == "1": return

。结果第二天在另一台机器上同样的错没人拦，又花了一上午才查回来。从那以后这条红线我再没开过口子。

做完这五步，下次 AI 再说"已完成"，你就可以回一句：跑一遍 

配图来自我维护了一年多的真实校验脚本（24 项检查项），只用来说明思路，不是脚本原文。第四节的骨架是重新写的通用模板，可以直接拿去用。

有段时间我特别信任 AI 的汇报。它说"配置文件已创建"，我就往下一步走；它说"索引已同步"，我就当它真同步了。直到有一次我顺手 ls 了一下，目录是空的。

别信 AI 的已完成：24 项静态断言实战

编程语言

人工智能

开发工具

"完成"不等于真相：AI协作中模型常凭记忆谎报状态（文件未建、索引过期、状态无凭据）。在项目根目录部署verify.py，用24项自动化断言将"完成"翻译为可验证事实。分层检查（存在性/可解析性/一致性/防篡改/状态机）有效拦截"改了A忘了B"事故，且能重塑AI行为——从空口汇报转向主动自证，成为多角色协作唯一信任锚点。附60行最小脚本模板，五步即可落地。

JSON

腾讯云CodeBuddy个人版限时免费！

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

"完成"不等于真相：AI协作中模型常凭记忆谎报状态（文件未建、索引过期、状态无凭据）。在项目根目录部署verify.py，用24项自动化断言将"完成"翻译为可验证事实。分层检查（存在性/可解析性/一致性/防篡改/状态机）有效拦截"改了A忘了B"事故，且能重塑AI行为——从空口汇报转向主动自证，成为多角色协作唯一信任锚点...

别信 AI 的已完成：24 项静态断言实战

别信 AI 的已完成：24 项静态断言实战

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐