实测OpenSquilla的"自我验证"，发现AI编程的信任问题真的解决了

上周GitHub上冒出一个让人眼前一亮的新项目：

。

上线不到一个月，GitHub Star已经冲到5000+。它的核心卖点听起来有些夸张——让AI写代码的时候，

。

说实话，AI编程一直存在一个老大难问题：不是“写不对”，而是“写了之后不知道对不对”。很多AI Coding工具改完即交，对错还得人逐行复核，这效率其实大打折扣。

OpenSquilla的思路完全不同：

。这个方向确实值得关注，于是花了两晚上仔细测了一把。

先说它解决了什么问题

传统AI编程的工作流是这样的：

1. 用户提需求
2. AI写代码
3. 人来验证代码是否正确
4. 如果不对，让AI继续改
5. 循环往复，直到人觉得OK

这个流程的核心症结在于：

。

对于简单的函数，比如写一个排序算法，验证成本很低。但对于复杂的系统，比如实现一个分布式锁或复杂的状态机，验证成本会急剧上升——你得自己写测试用例、设计边界场景、运行回归测试，整个过程费时费力。

OpenSquilla的做法是：

。

核心技术：红绿回归证据链

它的工作流分成三步，环环相扣：

第一步：写一个注定失败的测试

AI先写一个测试用例，这个测试用例用来验证“问题确实存在”。

举个例子，如果用户提的需求是“修复排序函数的边界情况bug”，AI会先写一个测试用例，验证“排序函数在某些输入下会返回错误结果”。

这个测试用例必须是

——它必须失败，因为它证明的是bug的存在。

第二步：修复问题，让测试变绿

AI接着修复代码，让测试用例通过。

这时，如果测试从红变绿，就说明AI确实解决了问题。

第三步：跑回归测试

AI运行项目原有的所有测试用例，确保没有引入新问题。

如果所有测试都通过，说明代码交付完成。

实测验证

选了一个极具代表性的场景：给开源项目 micrograd（Karpathy的自动微分库）新增一个“计算正确梯度”的功能。

这个功能的特点是：

。这种bug是最难发现的，肉眼根本无法判断对错。

实测流程如下：

AI先写了一个测试用例，输入特定的梯度计算请求，预期输出是“梯度值在某个范围内”。结果测试失败——说明梯度计算确实有问题。

AI修改了梯度计算的代码，然后重新运行测试。这次测试通过了。

AI运行了micrograd原有的所有测试用例，确保没有破坏其他功能。所有测试通过。

最后，AI把新功能计算出的梯度值，和PyTorch计算出的标准答案进行了对比——前向值与每一个梯度小数点后10位完全一致。

印象最深的三个发现

实测完成之后，看到了几个有意思的点：

发现1：自我验证改变了评价标准

以前评价AI编程工具，看的是“它声称改对了没有”。现在有了自我验证，评价标准变成了“

”。

这意味着，AI编程工具从“承诺制”变成了“举证制”。

发现2：测试驱动开发被重新定义

传统TDD（测试驱动开发）是人写测试、人验证。OpenSquilla把验证环节自动化了，变成了

。

这并不意味着人可以躺平——人的角色变成了

，而不是“执行验证的人”。

发现3：长任务的可信度大幅提升

以前让AI跑一个复杂任务（比如重构一个模块），不放心让它自己跑，必须盯着。现在有了自我验证机制，可以先让AI跑，跑完之后看它的“证据链”——三关全过，就信任它；任一不过，再介入。

技术细节：它是怎么实现的

OpenSquilla的核心架构分为三层：

第一层：Agent层

负责理解用户需求，规划实现步骤，决定是否需要生成测试。

第二层：Coding层

负责代码生成和修改。它有一个显著特点——每次修改都会自动生成对应的测试用例，而不是等用户问了才写。

第三层：验证层

负责执行测试、分析结果、决定是否继续。验证层有三种策略：

• 单元测试：验证单个函数的行为
• 集成测试：验证多个组件的协作
• 对比测试：与已知正确答案对比（如PyTorch）

判断：可验证性将成为AI编程的标配

实测下来，OpenSquilla解决的不是“AI写代码”的问题，而是“

”。

在AI编程工具刚出来的时候，大家关注的是“能不能写对”。现在关注点已经转向“

”。

这是一个很重要的转变——它意味着AI编程从“能用”走向“可信”。

未来，评估一个AI编程工具好不好，不只是看它生成的代码对不对，还要看它有没有

。