实测OpenSquilla的"自我验证"，发现AI编程的信任问题真的解决了
上周GitHub上冒出一个让人眼前一亮的新项目：
OpenSquilla
上线不到一个月，GitHub Star已经冲到5000+。它的核心卖点听起来有些夸张——让AI写代码的时候，
自动生成可验证的证据链，证明代码是对的
说实话，AI编程一直存在一个老大难问题：不是“写不对”，而是“写了之后不知道对不对”。很多AI Coding工具改完即交，对错还得人逐行复核，这效率其实大打折扣。
OpenSquilla的思路完全不同：
把验证内化进Agent本身
先说它解决了什么问题
传统AI编程的工作流是这样的：
- 用户提需求
- AI写代码
- 人来验证代码是否正确
- 如果不对，让AI继续改
- 循环往复，直到人觉得OK
这个流程的核心症结在于：
验证这一步完全依赖人
对于简单的函数，比如写一个排序算法，验证成本很低。但对于复杂的系统，比如实现一个分布式锁或复杂的状态机，验证成本会急剧上升——你得自己写测试用例、设计边界场景、运行回归测试，整个过程费时费力。
OpenSquilla的做法是：
让AI在交付代码之前，先自己跑一遍“红绿回归证据链”
核心技术：红绿回归证据链
它的工作流分成三步，环环相扣：
第一步：写一个注定失败的测试
AI先写一个测试用例，这个测试用例用来验证“问题确实存在”。
举个例子，如果用户提的需求是“修复排序函数的边界情况bug”，AI会先写一个测试用例，验证“排序函数在某些输入下会返回错误结果”。
这个测试用例必须是
红的
第二步：修复问题，让测试变绿
AI接着修复代码，让测试用例通过。
这时，如果测试从红变绿，就说明AI确实解决了问题。
第三步：跑回归测试
AI运行项目原有的所有测试用例，确保没有引入新问题。
如果所有测试都通过，说明代码交付完成。
三步全过才算交付，任一不过直接打回。
实测验证
选了一个极具代表性的场景：给开源项目 micrograd（Karpathy的自动微分库）新增一个“计算正确梯度”的功能。
这个功能的特点是：
梯度一旦算错，模型不会报错也不会崩溃，只会悄悄越学越偏
实测流程如下：
Step 1：AI写失败测试
AI先写了一个测试用例，输入特定的梯度计算请求，预期输出是“梯度值在某个范围内”。结果测试失败——说明梯度计算确实有问题。
Step 2：AI修复梯度计算
AI修改了梯度计算的代码，然后重新运行测试。这次测试通过了。
Step 3：AI跑回归测试
AI运行了micrograd原有的所有测试用例，确保没有破坏其他功能。所有测试通过。
Step 4：AI与PyTorch对比
最后，AI把新功能计算出的梯度值，和PyTorch计算出的标准答案进行了对比——前向值与每一个梯度小数点后10位完全一致。
印象最深的三个发现
实测完成之后，看到了几个有意思的点：
发现1：自我验证改变了评价标准
以前评价AI编程工具，看的是“它声称改对了没有”。现在有了自我验证，评价标准变成了“
它能否自证改对了
这意味着，AI编程工具从“承诺制”变成了“举证制”。
发现2：测试驱动开发被重新定义
传统TDD（测试驱动开发）是人写测试、人验证。OpenSquilla把验证环节自动化了，变成了
AI写测试、AI验证
这并不意味着人可以躺平——人的角色变成了
“审核证据的人”
发现3：长任务的可信度大幅提升
以前让AI跑一个复杂任务（比如重构一个模块），不放心让它自己跑，必须盯着。现在有了自我验证机制，可以先让AI跑，跑完之后看它的“证据链”——三关全过，就信任它；任一不过，再介入。
技术细节：它是怎么实现的
OpenSquilla的核心架构分为三层：
第一层：Agent层
负责理解用户需求，规划实现步骤，决定是否需要生成测试。
第二层：Coding层
负责代码生成和修改。它有一个显著特点——每次修改都会自动生成对应的测试用例，而不是等用户问了才写。
第三层：验证层
负责执行测试、分析结果、决定是否继续。验证层有三种策略：
- 单元测试：验证单个函数的行为
- 集成测试：验证多个组件的协作
- 对比测试：与已知正确答案对比（如PyTorch）
判断：可验证性将成为AI编程的标配
实测下来，OpenSquilla解决的不是“AI写代码”的问题，而是“
AI写代码的信任问题
在AI编程工具刚出来的时候，大家关注的是“能不能写对”。现在关注点已经转向“
能不能证明写对了
这是一个很重要的转变——它意味着AI编程从“能用”走向“可信”。
未来，评估一个AI编程工具好不好，不只是看它生成的代码对不对，还要看它有没有
