目录

1. 补充明确的验证手段
   1. 编译通过
   2. Web 界面操作步骤
   3. sqlite3 数据库
   4. python 片段代码
2. 为 AI 提供可验证的环境/文档
   1. 本地可跑单测的能力
   2. 本地全套运行环境

正文

我觉得是验证结果的手段缺失的问题。

题主说的体验我最近只在 GLM 4.6 的claude code上面体验到，一些比较复杂的难题，总是倾向于使用 mock 代码占位、假装构建成功等等，给人一种总是想连忙结束会话的感觉，等我去检查的时候发现编译是不通过的。

使用 Gemini/Deepseek 3.2 的时候，体验会好一点。对于我不懂的 Rust 在 Mac上面交叉编译 Windows msvc 版本的难题， 我会告诉它，最终的目标是编译成功。所以中间的代码分析/头文件缺失/mingw和llvm的安装，他尽管可以任意发挥，只要最终能够编译成功，就是有用的。可能中间的代码或者解决方案对于精通 Rust 的人来说是不达标的，但是对于外行来说，只看疗效并不看代码质量。只要不报错，编译通过，运行还可以，就是完成任务了。

我还在写 Web 网站时候发现，只描述功能和预期是不够的，写得前后端代码效果总是在某些地方不如人意，有时候是提示词里面没有说清楚，有时候是另外一个功能的代码破坏了另外一个功能。还要有验证手段，我会让 AI 参考功能流程，使用 chrome devtools mcp 来进行测试/验收/Debug，它能够访问首页，点击登录，输入密码，最终登录成功，输入关键词，点击搜索，并看到最终的表格效果。如果我告诉他某个按钮点击没反应，它是能够 debug 出来这个按钮的事件被另外一处 js 监听了，最终给的解决方案可能很抽象（我虽然是后端，我也能够看出来它写的不是好代码），但是对用户来说，能够跑通就行。

在写一些后端代码得时候，有能够复现的工作环境是最好的，比如写一个脚本的时候，AI 会自动去帮忙编译执行验证，如果代码依赖的配置/数据库/其他依赖导致项目只能在 prod 跑起来，就没法在本地验收确认结果了，这种是最难的，体验差的时候，需要人工在本地IDE和线上运行环境中间反复粘贴代码，甚至包括复制运行日志给 AI Debug。所以要要求写后端代码的时候，必须能在本地 IDE 能跑起来，能准备好数据库/配置/其他依赖能资源，能够让 AI 来写单元测试，来执行单元测试，启动服务器，验证 /api 接口。

这部分体验最好的还是写 python 项目的代码，几乎任意片段代码 ai 都可以 import 进行验证。数据库是 sqlite3 的时候，体验也是很好的，ai 可以直接验证 sqlite3 里面有没有数据，表的 schema 是什么，是否需要根据需求进行 DDL等等。运行起来的所有日志ai也是可以自己读到的。

我的体验来说，只要给出验证手段，在铁一样的失败结果面前，AI 只会羞愧地反复道歉，不会再自吹自擂了。当然有可能成功之后的代码可能看起来还是狗屁不通的。