1.7.1. 后记

今年是第四年评上 HashiCorp Ambassador，说起来很惭愧，去年做的工作很少，今年抱着试试看的心态提交了申请，还是获得接纳了，非常感动，心想今年无论如何也要做一些工作了，于是把之前在编写 AVM Opa Policy 规则库时学习到的 Rego 规则编写成了Rego 101 中文教程，一开始想着也是编写成一本电子书的形式，但实际评估了内容总量以后觉得还是略显单薄了，它作为文章来说过长，作为书来说又太短，并且 Rego 是 Styra 的项目，拿来作为贡献给 HashiCorp 中文社区的内容来说未免挂羊头卖狗肉了。

1.7.1.1. 工具链和工具观

Azure Verified Modules 是我重点参与了几年的项目，从最初开始我就与海外的同事跨部门一起合作，从代码规范和流程的制定，到测试环境的搭建，CI 流水线的设计和打磨，各种工具的开发、升级和维护，一路走到今天。AVM 和它之前的一些顶着 Azure 头衔的 Terraform 模块一样，从一开始可能都是一线架构师、工程师为了提升代码复用率，加速交付而自发开发的，而后在维护的过程中发现这样那样的问题，核心约束是，绝大多数模块的贡献者本身也是兼职维护这些项目的，要求他们全职全身心投入代码的维护、升级并不现实，同时基础设施即代码（Infrastructure as Code）又是一个不断迭代、不断更新的领域，例如云平台的 API 会升级，会有新的产品出现，Terraform 本身也在不断添加各种实用的新功能，所以我们迫切地需要一个杠杆，通过这个杠杆可以放大人的效率，使得我们可以用有限的人力、精力，去维护不断增长的模块。

这个杠杆就是工具链。就像我们在“一个模块，一个仓库”里提到过的，Azure Verified Modules 这样的开源 Terraform Module 项目有别于其他常见的开源软件的治理模型：它所管理的是数百、甚至数千个结构高度一致，实现代码不同，但必须遵循一致的高标准的仓库群，量变带来质变，任何在维护单个仓库时可能不起眼的任务，在放大到数百倍规模以后，都有可能变成一个非常复杂的问题，仅凭人力或是期待维护者的责任心是不现实的。

传统的 Linter 可以用来在代码合并之前发现并阻止典型的编码反模式，但在处理 AVM 这样的项目时光是被动的检测、阻止还不够，有时还必须主动对数百个代码仓库进行定制化修改，例如添加遥测代码、统一升级 Provider 版本等等。

在这个过程中，我认识到我们需要大量的工具作为杠杆来放大人的力量，所以有了例如 yorbox 这样比较简单的小工具，也有 avmfix、grept、mapotf 这样更复杂一些的工具。以往中国的互联网和软件企业中普遍存在着轻视工具的倾向，广泛存在的鄙视链中总是以高并发之类的底层、后端或是框架、中间件方向的工作为鄙视链上游，视对接、接口、API、工具等为鄙视链下游。须知，人类本质上是一个被工具所塑造和规训的生物，我们的生活方式，我们的思维模式，实际上极大地受到了我们使用的工具的影响和约束。一个简单的例子，美国存在大量的小镇，其布局就如同复制粘贴一般，由一条主街（Main Street）和以主街为轴心两翼拓展开的一些住宅区所构成，这种小镇就是受到汽车和公路这种技术和工具的影响，整个小镇居民的生活、工作都是被汽车和公路所约束的。再比如日本以其发达的轨道交通网络闻名于世，日本的例如东京都市圈、阪神都市圈的布局和居民的生活方式就极大地被轨道交通这种工具所影响和塑造。更加新的例子就是中国发达的电子商务生态，外卖业态，彻底改写了中国城市的线下商业生态，购物中心、商业中心的布局都受到其深度影响，极少数头部主播依靠 4g 5g 移动互联网直播带货这种技术和工具，具备了以往可以匹敌国家级传统媒体的广告推销能力，也改变了人们消费的习惯。在实际生活中，各种工具组成的工具链是人类接触到各种技术的入口，所以很难想象一个高效能团队怎么能够不利用大量的工具组成工具链来实现能力的放大。

在这个过程里我发现我处于一个很有趣的位置，我既做过运维，理解他们的痛点，我本身也是软件开发，我明白应该如何开发一个软件，HashiCorp 在工具方面又有非常多值得学习和借鉴的地方可以参考。我很欣喜地看到 Terraform 从一个初生的工具逐步成长为今天世界 500 强用云的标准配置，成为基础设施即代码的事实标准，相关的工具层出不穷，一片勃勃生机万物竞发的姿态。。。

Terraform 与 OpenTofu 之争是让我感到非常心痛的事件，从此社区分裂成为两个，并且逐步开始有互不兼容的倾向。我开发 mapotf 的一个愿望也是，既然大家都是基于 HCL 的工具，那么我们完全有可能开发一个针对 HCL 的元编程工具，针对某些问题（例如动态的 ignore_changes 列表）提供中立的解决方案，两个社区都可以受益，甚至于，曾经我幻想过是否有可能有一天两个社区握手言和，重新归为一统。不管我的这个愿望是否可以成真，我都希望基础设施即代码这项技术可以茁壮发展。

1.7.1.2. 大语言模型的语言

在为 AVM 提交的工作中大量使用了大语言模型，比如 GitHub Copilot，ChatGPT，Google Gemini 等，我使用 AI 帮我撰写各种脚本代码（因为我本人不太擅长 Bash 脚本），或是为我的代码编写各种单元测试，再或者是为我的代码和变更撰写文档与说明。但实际上我做 mapotf 和 Terraform 的另外一个动机，是因为 AI。

目前绝大多数人和 AI 交互使用的都是自然语言，但从 AI 很擅长编写计算机代码来看，你完全可以通过非自然语言的方式与之进行交流。当前物理世界与 AI 之间存在交流的屏障，这个屏障就是人类，AI 只能通过文本形式返回它的回答，而这个回答需要通过人类自身，或是人类为它安装的各种插件来解释或执行。

让我们回顾一下 Terraform 的两大特点：声明式的语言，代表撰写者可以把状态迁移等一系列很复杂的问题委托给 Provider 开发者，自己只要用简单易懂的代码描述期待的状态即可；开放式的 Provider 架构，意味着任何东西只要有 API 可以操控，就可以为之编写 Terraform Provider，进而使用声明式代码来编排。虽然目前 Terraform 基本上都是用来编排和操作各种公有云、私有云，以及运行在云端的各种软件服务，可是所谓“基础设施”从来就没有约束过必须是软件基础设施，你完全可以为各种搭配了 API 的硬件编写 Provider，这样我们再用各种工程手段“教会” AI 如何用 Terraform 代码描述它对真实世界期待的状态，就可以实现 AI 直接操纵和编排物理世界，复杂度可以无限地高，因为我们可以为它提供各种各样的 Terraform 模块，只需要极其精炼的一段代码，可能就可以编排出小到工厂产线布局，大到企业、国家的资源调配，战略部署。我预感未来会出现少数极其适应 AI 的人，他们会为 AI 开发各种各样的工具链和领域特定语言，成千上万倍地放大自身的能力，进而出现大量的“一人公司”、“超级个体”。

我们前面说到，人类本质上是一个被工具所塑造和规训的生物，那么人类智慧本质上是一个被语言这个工具所塑造和约束的东西，凡是可计算的问题的解，必然是语言可以描述的，反过来，语言描述能力的边界，就是人类解决问题能力的边界；所以可以得到这样一个猜想：使用自然语言的 AI，其能够解决问题的复杂度不会超过人类可以解决的高度，但一个使用非人类可以理解的，蕴含的熵密度更高的语言，则可能为一个超越人类的智慧所运用。我们可以把各种小工具组合在一起成为工具链，把工具链封装成新的工具，我在设计和开发 grept 和 mapotf 的过程中也发现，我们也完全可以基于某种语言去设计一种更高层的元语言，基于元语言就可以轻松实现在下层语言层面看非常复杂的事情（例如在 Terraform 看，动态 ignore_changes 的实现很复杂，但在 mapotf 看就很容易），所以我认为要想进一步解放 AI 的生产力，我们必须为它设计一系列的领域特定语言，让它用这些新层次的工具进行推导工作。或者这么说，未来一个超人类的 AI 所使用的推理语言，大概率是我们人类所无法理解的，就像无论你如何努力，都不可能教会边境牧羊犬最基础的数学证明推导过程。

1.7.1.3. 致谢

最近一年发生了很多很多事情，国际关系愈发紧张，我所在的小环境也开始动荡起来。旧的秩序正在崩解，新的玩家跃跃欲试；旧的共识被一页页撕碎，新的观点正在用血与火书写。愿读者们能够在这愈加跌宕起伏的环境中坐和放宽，成为时代的弄潮儿而不是被大浪卷走。在此感谢各位的阅读！感谢家人们的支持！感谢同事们的帮助！感谢一切朋友们的友善！感谢这个时代！