В изследователска публикация от 22 октомври 2026 г. Anthropic и Theorem описват използване на Claude за доказване на свойства на софтуер от 123 отворени библиотеки. Основният режим разглежда статични, еднонишкови RISC-V програми под моделиран Linux, с фиксиран бюджет за памет и входове под 64 MB. Това са допускания на проверката, не обещание, че всички приложения с тези библиотеки са без грешки.
Доказва се твърдение, а не общо впечатление
Важната промяна е възможността генерираният аргумент да бъде проверен отделно от езиковия модел. Убедително обяснение на правилността и формално проверено доказателство са различни резултати. При формалния подход първо трябва да е ясно какво точно се твърди, за коя програма и при какви условия.
Публичното хранилище на Theorem съдържа твърдения за компилирани тестови входни точки и машинно проверими доказателства с Rocq. То включва също списъци на неприключили или проблемни случаи и контролни примери. Наличието на този материал позволява проверка на конкретен артефакт; SIExpo не е изпълнявал проверяващата среда и не твърди независимо възпроизвеждане.
Официалното описание на Rocq го представя като система за формални доказателства. Практическият смисъл е, че приемането на доказателството се подчинява на формални правила, а не на оценка дали текстът звучи правдоподобно. Но остават доверени компоненти и определенията, върху които е построено твърдението. Неточна спецификация може да остави важен въпрос извън проверката.
Защо обхватът има значение
Представете си собствена библиотека с функция за обработване на файл. Доказателство, че конкретна компилирана входна точка приключва без определен вид отказ, не описва автоматично поведението на целия сървър, който я използва. Сървърът може да има други входове, паралелни операции, настройки или зависимости. Това е редакционен пример за четене на обхвата, не диагноза на публикуван проект.
Полезната проверка би свързала версията на изходния код, компилирания файл, твърдението и резултата от проверяващия инструмент. При промяна на който и да е от тях трябва да се установи кое доказателство продължава да важи. Старо успешно изпълнение на проверката не удостоверява непременно нов бинарен файл със същото име.
Поправката също трябва да бъде оценена
Ако в процеса на доказване бъде променена програмата, остава отделният въпрос дали тя още върши необходимата работа. Функция, която веднага отказва всеки вход, може да избегне част от отказите и едновременно да бъде безполезна за продукта. Затова бихме разглеждали промяната на поведението и математическото твърдение заедно, вместо да приемаме един зелен резултат като достатъчна оценка.
Този подход допълва тестовете и прегледа на изискванията, без да отменя нуждата да знаем какво очакваме от системата. Новината е мащабът на описания експеримент и публикуваните проверими артефакти. Реалният напредък се оценява чрез точните доказани свойства и ограничения, а не чрез разширяване на формулировката до „изчезване на всички бъгове“.
*AI илюстрация: концептуална редакционна визия, не документална снимка или действителен екран от продукта.*
*Редакционна проверка: 2026-10-26T09:35:38.064383+00:00.*
