pstack 新增形式化验证 meta-skill
pstack 新增了一个 skill /create-formal-verification-skill
pstack v0.15.27 新增 /create-formal-verification-skill,这是一个 meta-skill,会根据待验证的系统特性自动生成定制验证 skill 与配套验证套件,例如状态机与并发行为生成基于 TLA+ 的方案,Rust 未定义行为生成基于 Kani 的方案。该功能仍处于 beta 阶段,作者用它以 TLA+ 建模自家代码时已发现若干 bug。poteto 认为建模与规范同步这两个历史瓶颈正适合由 LLM 接管,而形式化验证能给 agent 提供“数学上不可能违反”的强反馈。
查看原帖pstack v0.15.27 附带了一个新技能 /create-formal-verification-skill! 它仍处于 beta 阶段,与 /create-verification-skill 类似,这是一个 meta-skill,会根据你想要验证的特性来创建一个新技能和形式化验证套件。例如,你可能想用 TLA+ 对状态机和并发系统进行建模,或者在 Rust 中使用 kani 来检查未定义行为。 如果你刚接触形式化验证,可以把它理解为用数学方法证明系统的属性和不变量(必须始终为真的事物)或“定律”。通常,这意味着用另一种语言(如 TLA+)对你的程序进行建模,然后对该规范运行求解器。较新的方法(如 kani 和 @bendlang)采用了不同的思路,不需要单独的语言:你在 Rust 中编写 kani,在 Bend 中编写 bend(它也是一种编程语言,证明以定律的形式编写,并在其类型系统中表达)。 从历史上看,形式化验证从未成为主流,因为建模和编写证明非常困难。对你的业务需求进行建模并保持同步相当困难!但我预计未来我们会看到形式化验证领域出现更多创新,因为能够形式化验证代码确实做了你期望的事情,会让你的 agent 在编写正确软件方面如虎添翼。 不过与此同时,我一直在尝试用 TLA+ 对我们的代码进行建模,并且已经通过 /create-formal-verification-skill 创建的技能发现了几个 bug。 试试看,并告诉我效果如何!
查看原文
pstack v0.15.27 ships with a new skill /create-formal-verification-skill! it's still in beta, and similar to /create-verification-skill, this is a meta-skill that creates a new skill and formal verification suite based on the characteristics you want to verify. for example, you may want to model state machines and systems with concurrency using TLA+, or use kani in rust to check for undefined behavior. if you're new to formal verification, think of it as mathematically proving properties and invariants (something that must always be true) or "laws" of your system. usually, this means modeling your programs in a separate language like with TLA+ and then running the solver on that spec. newer approaches like with kani and @bendlang take a different approach where there is no separate language: you write kani in rust, and bend in bend (it's also a programming language, and the proofs are written as laws and expressed in its type system). historically formal verification never reached mainstream status because of the difficulty in modeling and writing proofs. it's quite difficult to model your business requirements and keep them in sync! but i expect that we will see more innovation in formal verification in the future as being able to formally verifiy that the code does what you intended gives your agents superpowers in writing correct software. in the meantime though, i've been experimenting with modeling our code with TLA+ and have already found several bugs with the skill created by /create-formal-verification-skill. try it out and let me know how it goes!
正文
pstack 新增了一个 skill /create-formal-verification-skill
定位是 meta-skill:不直接帮你做形式化验证,而根据你想验证的系统特性,自动生成一个定制的验证 skill 和配套验证套件。比如你要验证状态机和并发行为的正确性,它会生成基于 TLA+ 的方案;要排查 Rust 代码的未定义行为,则生成基于 Kani 的方案。
背后的概念:形式化验证 测试只能证明 “bug 存在”,无法证明 “没有 bug”;形式化验证则是对系统的性质做数学证明:证明某个不变量 (即“必须永远为真”的性质或“定律”) 在所有可能的情况下都成立。
poteto 点出了两条技术路线的分别: · 传统路线(外置建模):用一门独立的规范语言 (如 TLA+) 给系统建模,再运行求解器/模型检查器去穷举状态空间验证规范。代码和证明是两套东西。 · 新路线 (同语言证明):Kani 直接写在 Rust 里,Bend 的证明以 laws 的形式表达在其类型系统中;没有单独的建模语言,证明和代码活在同一处。
形式化验证是个 “理论很美、实践从未进入主流” 的领域,poteto 指出了两个历史原因:建模本身很难 (把业务需求抽象成形式化模型是专业 skill),以及规范与实现难以同步 (需求一变,两份东西都要改)。
她的判断是:这两个瓶颈恰好是 LLM 擅长接管的,让 agent 承担建模和同步的苦活。而反过来,形式化验证给 agent 提供的是传统测试给不了的强反馈:“数学上不可能违反”,这对让 AI 写出正确的软件是质的提升,她称之为“超能力”。