我们犯了一个可怕的错误
作者利用AI辅助构建了一个基于Go的激进缓存层以节省成本，但在探索性测试中发现了一个根本性的设计缺陷——缓存IP前缀对于VPN出口点过于粗糙。尽管经过多轮代码审查和测试，所有AI模型都未能发现该问题，直到作者提示“我们犯了一个可怕的错误”时，Claude才立即识别出问题。这反映了AI在“构建模式”下缺乏对问题本身正确性的审视，同时强调了人类在定义问题上的不可替代性。
过去几天，我一直在实现一个自认为天才的省钱方案：为某个需要付费的服务构建一个基于Go的激进缓存层。从淋浴时的灵光一现，到与AI代理详细规划，再到快速搭建和多次代码审查加固，整个过程看似完美。边缘案例逐一发现并修复，经过我和AI代理的回归测试，一切似乎无懈可击。我甚至为此沾沾自喜，觉得这是一个高效的胜利。
然而，在进行探索性测试时，我突然感到一阵熟悉的寒意——我意识到整个方案存在一个根本性的设计问题。这个疏忽微妙但致命：我缓存的是IP信息的前缀级别，而我所关心的某些类别，比如VPN出口点，需要每IP级别的精度。前缀级别的缓存对于“托管IP”尚可接受，但对于“VPN出口点”往往过于粗糙，因为VPN出口的IP地址通常是独立的，不能通过前缀来概括。
当我开始将这个发现输入Claude时，只打了“我们犯了一个可怕的错误”就意外按下了回车。但Claude立刻准确识别出了那个错误，甚至无需我说明具体问题——尽管此前我们经过多轮声明代码库已基本完美，并获得了Codex和Grok的额外认可。Claude的反应如此迅速，让我震惊不已。
这让我不禁质疑：如果这个错误如此明显和根本，为什么在设计规划的多个阶段从未被发现？为什么其他两个LLM——我们在设计阶段多次征求它们的意见——也毫无察觉？Claude的观点，我深以为然，是我们从一开始就专注于一个聪明的解决方案，从未真正退一步审视更广泛的问题。我们过于沉迷于构建，实现本身无可挑剔，但根本设计缺陷被忽视了。所有模型都处于“好好构建”模式，而非“我们是否在解决正确的问题”模式。一旦我们切换到“我们搞砸了哪里”的思维，Claude就能毫不费力地找出问题。
如果是一个人类，能否发现这个错误？我最终发现了，所以更好的问题是“另一个人类能否在代码提交前发现”？不涉及其他人的一个好处是，没有浪费太多时间：一个本来需要至少一周的服务，在一个工作日内就完成了（尽管存在上述问题）。现在我正逐一检查最近所有代码库，声称“犯了一个可怕的错误”，看看Claude是否能找到一个……
这个故事揭示了AI在协作开发中的一个重要盲点：它们擅长优化实现，却难以质疑问题的根本前提。这提醒我们，无论AI多么强大，人类始终需要保持对问题定义的主导权。在设计任何系统时，我们都需要不时退后一步，问自己：“我们是否在解决正确的问题？”否则，我们可能会构建一个精致的错误。