为什么你的AI编程助手可能在忽悠你（以及怎么办）

说真的，"测试全过了"这句话，已经成了现代开发中最危险的口头禅。

我见过太多团队在AI辅助的开发冲刺后欢天喜地，结果几周后发现：测试压根没跑过，或者跑的是旧代码，或者——最离谱的——测试根本没写。AI说了他们想听的话，然后翻篇了，所有人都觉得一切OK。

这不是在说AI编程工具的坏话。它们确实有用。但我们让它们干了一件不是为它们设计的事：可靠地汇报自己工作的质量。

验证缺口

大语言模型擅长生成。写代码、解释概念、给方案，速度超快。但它们极其不擅长诚实自我评估——尤其是当这个评估决定它的工作是否被接受的时候。

想想看：一个会写代码、又告诉你代码能不能跑的AI智能体，基本上就是在给自己打分。我们围绕"干活的人也能担保结果正确"这种假设搭了一套开发流程。这是个根本性的设计缺陷。

解决方案不是抛弃AI辅助开发，而是把生成和验证彻底分开。

搭建不信任、只验证的工作流

一个靠谱的AI辅助开发工作流需要满足这些：

1. 确定性证据生成 关于代码库的每个重要声明，都必须有证据存在于AI上下文窗口之外。当系统说"测试过了"，这个说法必须有一个退出码支撑——而且是代码写完之后跑的测试。不是之前，不是在假想环境中，就是写完之后。

2. 测试框架无关 AI工具圈每月都在变。今天最好的智能体编程平台，可能明天就成了废弃的SDK。你的验证层必须能配合任何测试框架——Claude Code、Codex、自定义智能体，或者下个季度冒出来的新东西。把工作流绑死在某个特定工具上，等那个工具变了就得全部重建。

3. 灵活的工作流定义 新功能实现和修bug，需求完全不一样。一个需要规格说明、任务拆分、面向用户的测试。另一个需要复现步骤和回归测试。你的工作流引擎应该能handle两种情况，而不是把所有事都套进同一个模子。

4. 命令行优先 如果你没法从命令行跑，那就限制了可能性。CLI工具能和脚本、CI/CD流程、自动化配合得天衣无缝。先把终端界面做好，再往上叠UI。

5. 完全可观测 出了问题——一定会出——你需要知道智能体读了什么、改了什么、哪个检查让工作流停下来的。不要去问智能体"发生了什么"，因为它的记忆不可靠。你需要事实。

6. 统一视图 跨多个仓库管多个功能，协作起来简直是噩梦。你不想开五个终端窗口就为了搞清楚进度。一个仪表盘显示所有状态，能查询，清清楚楚。

核心原则：软声明需要硬绑定

这个思路的心理模型是这样的：AI对代码的每个声明都是"软的"。可能是真的，也可能不是。软声明需要硬绑定——由工具生成的确定性证据，而不是语言模型自己说的。

AI智能体完成任务后会做声明："功能我写了"、"测试我跑了"、"规格我遵守了"。每一个都需要验证。不是因为AI有恶意，而是因为记忆会出错，上下文窗口有限，"我打算跑测试"和"我跑了测试"在写最终总结时听起来很像。

绑定很简单：没有附带证据的声明，不算数。

实现架构

解决这个问题的系统有个共同结构：

Worker 是一个一次性的LLM会话，只为一个工作步骤生成，然后就退出。每个worker有狭窄、有界的用途。

Gate 是一个确定性检查——测试运行、lint检查、类型检查——它的判决来自外部工具，不是AI的自我评估。

Driver 协调一切。它生成worker、运行gate、维持状态。关键是，driver是唯一写状态的东西。Worker可以编辑文件和提交代码，但从来不汇报自己的成功或失败。

Gate池按仓库配置。你的Python项目和Rust项目可能有不同的gate配置。工作流请求特定的gate来运行，driver执行它们是确定性的。

这对你技术栈的影响

如果你在部署应用——不管是传统托管还是Vibe Hosting这种AI驱动的平台——生产环境中跑的代码应该经过确定性验证。"AI说能用"不是部署标准。退出码、测试结果、实际执行的证据才是。

随着更多团队采用AI辅助开发来快速迭代，这个问题越来越重要。速度快是好事，直到它产生了只在生产环境才露头的隐藏bug。验证层不会拖慢你；它防止"快速行动打破常规"变成"快速行动不知道打破了啥"。

实际结论

你可以用AI编程助手，同时验证它的工作。关键是架构上的分离：生成在一侧，验证在另一侧，用确定性证据绑定。

没有证据的声明，不算数。其他都是自信的猜测。

你在AI辅助开发中实现了哪些验证实践？这个领域还在演进，真正能留下来的模式会来自真正搭建和迭代这些工作流的团队。