重读Ada语言设计史，GNAT（GCC的Ada前端）的开源实践堪称范本。Ada诞生于高可靠系统需求，其契约式设计若仅依赖商业闭源，恐难逃生态萎缩。其实开源实现却让社区持续注入活力：跨平台适配、错误处理机制优化，甚至为Rust的panic设计提供隐性参考。这恰似书法临帖——骨架需法度（语言规范），笔意靠迭代（社区协作）。开源项目中，设计文档的清晰度直接决定协作效率。诸位在贡献语言类项目时，是否也遇到过“文档即契约”的瞬间？

看到书法比喻直接进来 哈哈 咱练字的最懂 规范好搞 笔意难搞啊 楼主平时也写两笔？

文档即契约？在语言实现里，这事儿比表面复杂得多。我去年参与过一个小型编译器前端的维护，用的是类似Ada的强规范语言（虽然没Ada那么重），当时就踩过坑：spec写得再漂亮，如果测试套件没覆盖边界 case，社区 PR 一进来照样炸。GNAT 的厉害之处其实不在文档多清晰，而在于它把 ACATS（Ada Conformity Assessment Test Suite）和 GCC 的 regression test 深度绑定——这才是真正的“可执行契约”。

举个具体例子：Ada 的 discriminant check 在 task 初始化时的行为，ISO/IEC 8652:1995 里描述得很抽象，但 GNAT 的 test suite 里有整整 37 个 .adb 文件专门验证不同组合下的异常传播路径。后来有人提 PR 改进 ARM 架构下的栈对齐处理，CI 直接跑挂了其中两个 test，根本不用人工 review 逻辑对不对——test failed 就是 failed。

反观现在很多新语言项目，README 写得像哲学论文，但连 basic conformance test 都没跑全。Rust 的 panic 设计确实受 Ada 启发，但人家 panic=abort / panic=unwind 的行为差异，也是靠 miri + stdarch 的 exhaustive testing 才稳住的，不是光靠 RFC 文档。

btw，楼主提到“跨平台适配”，其实 GNAT 在嵌入式端的 portability 得益于一个冷门设计：它把 target-specific 的 runtime 抽象成独立的 RTS（Run-Time System）包，比如 ravenscar-sfp 这种 profile。社区贡献者只要按接口实现几个 primitive（如 s-bbsums.adb），就能跑在 bare metal 上——这比文档更重要，这是架构级的协作契约。

其实所以与其说“文档即契约”，不如说“可验证的 spec + 自动化 test harness = 真契约”。我在外贸写 SOW（Statement of Work）时也一样：条款写得天花乱坠，不如附上验收 test case 清单来得实在。毕竟，code don’t lie。

你有没有试过给语言项目提 PR 时，因为 test suite 不全被 maintainer 拒了？我上次就被拒过，后来自己补了 12 个 test 才 merge……