你有没有遇到过这种情况：AI生成的代码看起来没问题，测试也跑通了，但整个项目却越来越难维护？
这不是幻觉。一位长期关注AI辅助开发的工程师最近提出了一个被忽视的问题——AI输出与代码库真相之间的鸿沟。他把这称为一种"不 neatly fit into 'bad code' or 'bad prompting'"的失败模式。换句话说，问题既不是代码写得烂，也不是提示词写得差，而是更深层的信任危机。
当前关于AI编程的讨论，几乎全都围绕着智能体本身打转：
• 怎么提升它的上下文理解？
• 怎么写更好的指令？
• 怎么让它记住项目规则？
• 怎么协调多个智能体协作？
• 怎么让它规划更长的任务链？
这些都是真问题。但他发现还有另一层：即使智能体拥有良好的上下文，它留下的代码库仍可能变得难以信任。
因为代码库不只是代码。它是项目累积状态的集合：结构、假设、测试、文档、运行时预期、旧脚手架、部分实现、清理债务，以及关于"什么已经完成"的各种声明。这个状态需要监督——不是取代开发者，不是取代AI智能体，也不是让另一个AI来评判第一个AI做得好不好。而是更接地气的东西。
具体来说，代码库需要一种本地化的方式来区分：
• 已实现的 vs 声称已实现的
• 已验证的 vs 假设成立的
• 脚手架 vs 真实功能
• 当前的 vs 过时的
• 有组织的 vs 只是排列在一起的
• 安全清理 vs 风险清理
• "看起来做完了" vs 真的做完了
这就是他正在构建的领域。他即将完成的产品叫Scarab Diagnostic Suite（圣甲虫诊断套件）。核心理念很简单：AI可以建得快，Scarab帮助保持代码库的真实。
Scarab不是代码生成器，不是提示词包，也不想成为AI智能体本身。它是一个通过命令行安装的诊断与监督套件，专门面向AI辅助的代码仓库。
设计哲学是：AI智能体需要一个稳定的运行环境。智能体会漂移、丢失上下文、夸大进度，或者在不再成立的假设上继续构建。代码库需要单独的一层来检查、记录、警告、阻断，并指导下一步。
这意味着关键问题发生了转变。以前只问：智能体能完成这个任务吗？现在还要问：代码库还能证明发生了什么吗？
这个转变彻底改变了他对AI编程的思考。他不认为未来只是更大的上下文窗口或更自主的智能体——这些会发生，但赋予智能体越多自主性，周围有稳定的东西就越重要。
某个不盲目信任智能体自信心的东西。某个能说：
• 这是安全的
• 这是不完整的
• 这是过时的
• 这需要审查
• 这不应该自动清理
• 在更深层的诊断可信之前，这需要更强的基线
他认为这类产品空间即将变得非常重要。AI编程智能体可能是工人，但代码库仍需要一种维护真相的方式。这就是他正在构建的周边层。
热门跟贴