关键观点
形式化方法从显式化意图开始形式化工作的第一步不是证明，而是把开发者对程序行为的隐含认识转化为清晰、无歧义的规格。例如，列表最大值不仅是某个测试用例的预期结果，还必须属于该列表，并且不小于任何其他元素。规格描述“应该做什么”，验证则判断实现是否满足规格。完整形式化验证追求覆盖所有可能输入，而不是少数人工挑选的案例。
形式化工作的第一步不是证明，而是把开发者对程序行为的隐含认识转化为清晰、无歧义的规格。例如，列表最大值不仅是某个测试用例的预期结果，还必须属于该列表，并且不小于任何其他元素。规格描述“应该做什么”，验证则判断实现是否满足规格。完整形式化验证追求覆盖所有可能输入，而不是少数人工挑选的案例。
为什么重要: 如果无法准确表达预期行为，再强的证明工具也只能证明实现符合一个可能错误或空洞的规格。
支撑证据
Can we figure out what a function is supposed to actually be doing and write that down in a way that can be shown to anybody?
规格成本阻止形式化验证覆盖一切简单数学函数容易定义，但真实程序会迅速牵涉编码、权限、快捷方式、目录类型和具体文件系统等上下文。此时，准确写出函数在所有情况下应该如何响应，可能成为一项庞大的建模工作。对多数低风险功能，覆盖主要路径的测试和一个在绝大多数情况下正确的实现已经足够。追求百分之百的完整性，未必能产生合理的投入回报。