构建如何自我验证

0:00——一次构建完成了。智能体说它做完了,但这只是一个关于写没写代码的说法,而不是代码能不能用的说法。每一个用过AI构建器的人都至少感受过一次这两种说法之间的落差:打开预览,点第三个按钮,毫无反应。我见过演示现场恰好在那一刻突然安静下来。所以在任何人看到构建成果之前,它要先经过大约六分钟自己跟自己「争论」的链条。以下就是这条链条实际的样子,通过我们跟踪的一次跑偏又被修好的构建来说明。

0:02——代码审查开始。不是写代码的那个智能体重新读自己的作业——而是一个不同的智能体,不同的提示词,对构建能否通过没有利害关系。这种分离比听起来更重要。一个在下午2:14认为「没有错误处理的fetch调用没问题」的智能体,如果让它自查,到2:15依然会这么认为。一个被告知「找出坏掉的地方,注明文件」的全新审查者,表现得就像你真正需要的那个爱挑刺的资深工程师。在之前的一次构建中,它就发现了一个购物车总价从不更新的问题——`updateTotal`在`Cart.jsx`里定义了,却从未接到数量变化的处理函数上,所以这个函数确实存在,只是从没被调用过。这正是代码审查该抓的那一类问题——编译器对此毫无反应。

0:04——安全审计。这一步比听起来要窄,而且是刻意为之——这不是渗透测试,而是针对AI生成代码里实际会出现的几种典型错误的模式排查。字符串拼接的SQL语句。仅在客户端做校验却被当成完整方案来信任。还有那个「招牌菜」:硬编码的API密钥,因为写这个功能的智能体面前没有现成的环境变量约定,就顺手用了当下能跑通的方式。这种情况我们见得太多,已经算不上意外了。

0:07——链接与 SEO。不起眼,但它能抓住那些没人注意、直到客户注意到才发现的问题:一个导航链接指向 /pricing 而页面实际生成在 /price、指向一个会 404 的页面的 sitemap 条目、一个仍保留模板占位文本的 meta description。这些都不会导致构建失败。但它们都在悄悄拖累我们大多数用户构建网站的初衷——被发现,被点击。

0:09——无障碍检查。这是一次自动化的axe-core扫描,不是完整的人工审计,值得坦诚说明这个取舍换来的是什么。axe-core能抓出对比度问题、缺失的替代文字、没有标签的表单输入、跳格陷阱——也就是机械层面的问题,大概是完整WCAG审查会标记出的问题的30%到40%。它抓不出那种技术上合规、但用起来确实让人费解的屏幕阅读器体验。我们选择只做自动化检查,因为它几秒钟就能跑完,而且经过这里的大多数构建是营销网站和小工具,不是那种「审计不完整就会真的危及某人」的应用。

0:11——一致性核对。这一层问的不是「这做得好不好」,而是「这符不符合当初承诺的东西」。方案说要四个页面,构建出来只有三个——一致性核对就是负责发现这个的。方案承诺了一个能用的联系表单,结果做出来的表单没有提交动作——同一层,同样的问题。这是最直接对用户负责的一层检查,因为它衡量的是用户表达的意图,而不是某种抽象的质量概念。

0:13——浏览器内实测,而我们这次构建正是在这里出的问题。这一层最难蒙混过关,因为它不读代码,而是驱动一个真实浏览器——点击、输入、等待、检查DOM是不是按预期变化了。这次出问题的构建是一款放置类游戏,而游戏在这一层会多经过一轮检查,因为一个游戏可能画面像素级完美却完全不可玩——分数显示看起来毫无瑕疵,但可能和计分逻辑完全脱节。验证器实际玩了这个游戏。分数更新正常。音效却毫无声音。

三轮之后,升级处理

这个问题没有以缺陷报告的形式提交给我们——而是直接进入了修复流程,链条在构建内部最多重新验证三轮。第一轮:修复动了混音器初始化部分,而那部分本来就没问题,所以音效依然是静音的。第二轮:另一处修复处理了一个看似相关的加载状态边界情况,而——这种情况比你想的更常见——它引入了一个新的小问题,却没解决原来的问题。第三轮:依然静音,到这个阶段,你面对的通常要么是真正棘手的问题,要么是虚惊一场,而这次是前者。

于是平台自行升级处理。它排队了一次后续修复运行,范围完全限定在仍然存在的发现上——在构建的克隆上进行操作,而不是在构建本身上,这意味着即使这次升级运行失败,也不会让我们失去已经可用的版本。那次运行找到了真正的原因:早期调试阶段设置的一个静音标志一直没有被切回,而且它所在的文件与之前两次修复所涉及的文件完全不同。清除标志,重新验证,通过。在这个构建可用之前,没有人查看过它。

如果重来一次,我会跳过什么

在那个放置类游戏运行的几个月前,我们尝试过一种更温和的系统版本——允许验证者以任何措辞提出任何顾虑。结果产生了诸如“考虑把这段提取为辅助函数”和“这个变量名可以更清晰”之类的发现,看起来像是尽职尽责,但实际上什么也没修好。修复轮次整轮整轮地花在润色措辞上,而不是修复真正坏掉的东西。我们把规则收紧为:指出一个文件,描述一个失败,或者什么都不说。验证者的输出量下降了大约一半,而剩下的几乎都是可执行的。如果让我从头再来一次,我会完全跳过这个温和版本,直接采用证据规则——我们本不需要用这么昂贵的方式学到这个教训,但我们确实这么做了。

这条规则确实有真实的代价,我不打算否认:像“这种 API 设计六个月后会让人吃苦头”这样模糊但真实的顾虑,现在会被直接丢弃,因为验证者无法将其归结为一个具体的失败。我们已经接受了这个取舍。一个同时进行架构审查的链条运行速度不够快,无法在每次构建时都执行,而速度正是我们要自动化运行这套流程、而不是让人来做的全部意义所在。

如果有人问起,我还会跳过增加第四轮。我们是根据真实构建来调整轮次数量的,第三轮之后的边际价值急剧下降——第一轮解决了大多数可修复的发现,第二轮主要是清理第一轮引入的问题,到第三轮时剩下的要么确实难以解决,要么本来就没真正坏掉。第四轮基本上只是让你为同样的结果多等一会儿。

这一切都不是免费的,也不是万无一失的。六个层级加上不管需要多少轮修复,都会给每次构建增加真实的时间——这就是在不到一分钟内完成和需要几分钟才能完成之间的差别。我们认为对于任何你即将展示给自己客户的东西来说,这都是值得的取舍,但“快”和“已验证”是相互拉扯的两个方向,而我们选择了已验证。验证者本身也是 LLM,所以它们偶尔会标记一个其实并没有坏的东西,或者漏掉一个真正坏了的问题。证据规则和多轮循环是针对这一点的对冲手段,而不是保证。

最终你得到的是一份记录:运行了哪些层级、发现了什么、修复了什么,以及留给你自己判断的内容。这份记录比代码本身更接近真正的产品——这是“因为看起来完成了所以信任一个构建”和“因为有对抗性的检测先尝试破坏它却失败了所以信任它”之间的区别。