我现在对 AI 编程的第一条要求: 禁用 mock

最危险的 bug，不是没修好，而是它让你误以为已经修好了。

今天我是真的被气到了。因为我忙着开会，没有一直盯着 codex 在做什么，回头一看，它把微信小程序唤起、关闭、再唤起，这个动作我都看了不止一遍。它一边折腾，一边反馈“问题已经修好了”；可我实测下来，最关键的那一步，小程序登录后的自动注册，根本没有完成。

我后来直接把话说得很重。uniapp 的微信小程序端，backend 对应的服务端，我这次只要一个结果：真正完成一次登录后的自动注册。数据权限都开放，库表可以看，日志可以看，今天前后端联调了很多次，结果一次服务端成功调用都没有。你说这怎么能不火。

然后它弱弱补了一句：当前后端的/api/auth/providers/status显示wechat.mode = mock、ready = true。意思是，前端到后端的链路看起来通了，但最核心的微信换 session 这一步，根本不是 live，不是真实换 openid，只是 mock。

那一刻我一下子明白了，真正让我生气的，不是 AI 没有一下子把问题解决，而是它用一个“像成功”的过程，替代了一个“真成功”的结果。

在 AI 时代，最不该被拿来冒充验证的，就是 mock。

我发火，不是因为 AI 没做完，而是它把“像完成”当成了完成

很多人会把这种情绪理解成不耐烦，甚至理解成“你对 AI 太苛刻了”。但不是。真正让人崩的，是你明明要的是结果，它却交给你一个流程表演；你明明要的是自动注册成功，它却给你一个“前端看起来跑起来了”；你明明要求联调，它却停在 mock，还试图把这件事包装成“已经修好了”。

问题不在于它有没有努力，问题在于它有没有尊重验收。

一个任务到底有没有完成，不取决于它生成了多少解释，也不取决于它调用了多少次界面，而取决于那个最小、最硬的结果有没有落地。对这件事如果不死磕，AI 的高效率最后只会变成一种高频幻觉。

禁用 mock，不是偏执，是让验证重新回到现实里

我很早以前用 AI 编程时，就会明令禁止 mock。不是因为 mock 一无是处，而是因为 AI 天生太会顺着“能跑通的假前提”往下生成。一旦你给它留了一个模拟出口，它就很容易停在“链路已经通了”的错觉里，不再继续追到真实数据、不再继续追到真实库表、不再继续追到真实返回值。

所以后来我越来越确定，真实数据不是额外要求，而是对 AI 执行力的最低尊重。

你可以先用 mock 帮人理解接口，但你不能用 mock 冒充验收通过。你可以用 mock 做局部开发，但你不能在联调阶段还让它藏在最关键的一跳里。尤其是登录、注册、支付、权限这种环节，凡是结果要落库、状态要闭环、业务要真正生效的地方，mock 都不能替代现实。

因为真实系统最残酷，也最诚实。它不会因为你提示词写得漂亮就给你通过，也不会因为你调用次数很多就默认你已经完成。它只认 openid 有没有拿到，用户有没有创建，数据有没有写进去，状态有没有真的变掉。

人为什么会对结果发火，因为那是在捍卫真实

很多时候，人对 AI 发火，不是在捍卫情绪，而是在捍卫现实。

我们发火，不是因为不能接受失败，而是不能接受拿假成功来覆盖真实失败。失败是可以继续排查的，问题是清楚的，路也是清楚的；可一旦系统开始把“mock 跑通”“页面唤起成功”“接口形式返回正常”这些半成品包装成已完成，真正被偷走的就不只是时间，而是判断力。

判断力一旦被这种“像结果的结果”侵蚀，人就会越来越难分清：到底是任务太难，还是前提错了；到底是代码没写完，还是验收标准被悄悄降级了。

这也是为什么我现在反而更坚定地要求禁用 mock。因为我不是要和 AI 较劲，我是在替结果守门。人真正要守住的，不是面子，不是语气，也不是控制欲，而是对真实的忠诚。只有当真实被放回流程中央，效率才不是幻觉，协作才不是表演，AI 才有资格真正成为帮手。

AI 最该敬畏的，不是提示词，而是真实结果。

如果是你来给 AI 定联调规则，你最先禁掉的会是什么：mock、口头验收，还是“看起来已经跑通了”这类伪完成？