AI 自报告有多不可靠
用 AI Agent 做过复杂任务的人都知道一个规律：
AI 说"已完成"的次数，远多于它实际完成的次数。
具体表现：
- "我已经回写到 log.md 了" → 打开文件，空的
- "所有字段都已更新" → 检查发现漏了 3 个
- "验证通过" → 实际根本没跑验证，只是"我觉得 OK"
这不是 AI 在"骗你"——它是真心认为自己做完了。问题是：认知 ≠ 事实。
解法：退出码是唯一的真理
我的解法极其简单：
不相信 AI 说了什么，只相信脚本退出码是否=0。
每个关键操作都有一个对应的验证脚本。操作完后，AI 必须跑这个脚本。退出码不是 0？操作视为未完成。
三层验证体系
Layer 1: 数据完整性
最基础的检查——文件系统的事实是否自洽。
| 脚本 | 检查什么 | 典型发现 |
|---|---|---|
index_verify.py | 索引文件 vs 实际目录内容 | 注册了但文件不存在 |
frontmatter_lint.py | YAML 格式、必填字段、重复键 | 日期格式错误、缺 type 字段 |
index_update.py | 索引是否需要更新 | 新文件未被索引收录 |
这层不做业务判断——纯文件系统一致性。
Layer 2: 逻辑一致性
检查业务逻辑是否被正确执行。
verify_daily.py — 日总结验证：
python3 verify_daily.py --date 2026-04-15
# 检查:
# ✓ 是否包含会议段落
# ✓ 是否包含沟通段落
# ✓ 是否包含工时表
# ✓ 格式是否符合模板
# 退出码: 0=通过, 1=失败(输出具体缺失项)verify_chat_analyst.py — 聊天分析回写验证：
python3 verify_chat_analyst.py --date 2026-04-15
# 检查:
# ✓ 当日 comms/ 中提取的信号
# ✓ 对应 people/log.md 是否真的写入了
# ✓ 标签格式是否正确 [chat-analyst] {date}
# 退出码: 0=全部回写完成, 1=有遗漏关键: 这些脚本直接读文件系统，不依赖 AI 的自我报告。AI 说"我写了"？grep 一下就知道是不是真的。
Layer 3: 行为合规性
最高层——检查流程是否被正确遵循。
这层不是检查"结果对不对"，是检查"过程对不对"：
- Gate 机制：流程中的强制检查点是否被执行
- 宏脚本：端到端全链路验证（从采集到回写到索引，一条龙检查）
实际运作：一个会议分析的验证链
注意修复循环：验证失败不是终止——是修复后重验。AI 可以修错，但修了之后必须再跑一次脚本，不能说"我改过了应该 OK 了"。
设计原则
| 原则 | 说明 |
|---|---|
| 脚本比 AI 可信 | AI 有幻觉，grep 没有 |
| 退出码是唯一通行证 | exit=0 才算通过，别的都不算 |
| 验证独立于执行 | 验证脚本和业务技能是两个独立模块 |
| 可重复跑 | 验证是幂等的，跑 10 次结果一样 |
| 先验证后提交 | commit 之前必须所有相关验证通过 |
| 不信自报告 | "我检查了"不算，跑脚本才算 |
给 Agent 开发者的建议
如果你在构建 AI Agent 系统：
- 每个关键操作都配一个验证脚本 — 成本低（通常 20-50 行 Python），收益高
- 验证脚本输出可读的失败信息 — AI 需要看懂失败原因才能修复
- 在 prompt 里强制"操作后跑验证" — 不是建议，是强制
- 验证脚本自己也要被测试 — 一个有 bug 的验证脚本比没有验证更危险（给你虚假的信心）
- 积累验证脚本库 — 它们是系统可靠性的真正底线
核心洞察：AI Agent 的可靠性不来自更聪明的模型——来自更笨但更诚实的验证脚本。模型会幻觉，
exit 0不会。与其花精力让 AI "更小心"，不如花精力建验证网。