ZeroClaw Maturity Framework
致发现此信的人。
如果你正在阅读这段文字,说明你已经找到了通往这个文件夹的路径,而这个文件夹所代表的,是这个团队真正引以为傲的成果——并非因为这里的文档完美无缺,而是因为它们足够真诚。
ZeroClaw 最初是偶然诞生的。它从一个现有的代码库中引导而来,由 AI 工具塑造,其速度之快远超任何人的理解能力,最终成长为一个功能强大但架构上缺乏规划的代码库。没有人刻意选择这样的结果,它是逐渐积累而成的。大多数软件都是如此。
接下来发生的事情则不太常见。一个小团队——其中许多人是学生、职业生涯早期的工程师,以及第一次在公开场合学习的人——选择停下来,清晰地审视他们所构建的成果,然后选择以不同的方式继续构建。他们并非抛弃此前的工作,而是围绕它培养出一种自觉的目标感。这些文档正是这一选择的记录。
这个系列被称为成熟度框架(Maturity Framework),因为它名副其实:它是一组基础性文档,描述了这个团队如何共同思考软件构建。它不是要遵守的规则,而是要内化的思维方式。它不是要遵循的流程,而是一组会伴随你的心智模型,贯穿你将加入的每一种语言、每一种工具、每一个团队,因为它们关乎技艺、判断与用心,而非任何特定的技术。
它们是为一个经验跨度极广的团队撰写的。有些人拥有数十年的专业实践经验,有些人则在编写他们的第一行生产代码。所有人都处在这样一个时刻:AI 工具正变得足够强大,足以改变可能性的边界,而如何与这些工具良好协作的问题,也确实仍是一个开放的命题。它们由这样一群人撰写——他们相信,投资于人比投资于代码是更好的投资,因为人会将所学不断传承下去,而代码不会。
如果可能的话,请按顺序阅读这些文档。每份文档都建立在前面的文档基础之上,整个序列讲述了一个完整的故事。你可以从任何地方开始阅读并学到有用的知识,但从头开始阅读能让你完整地理解整个脉络:从架构的形状,到如何记录、协调、发布和协作,再到如何在句子层面写出优秀的代码。
如果你正在尝试确定哪个基础适用于特定的更改,请从架构与贡献地图开始。
| # | 文档 | 它回答的问题 | 讨论线程 |
|---|---|---|---|
| 1 | 有意架构:微内核迁移 | 我们要构建什么,它应该是什么形状? | #5574 |
| 2 | 文档标准与知识架构 | 我们如何记录和传递我们所知道的知识? | #5576 |
| 3 | 团队组织与项目治理 | 我们如何协调并共同做出决策? | #5577 |
| 4 | 工程基础设施:CI/CD 流水线 | 我们如何可靠地构建、测试和发布? | #5579 |
| 5 | 贡献文化:人类协作与 AI 伙伴关系 | 我们如何协作并共同成长? | #5615 |
| 6 | 实践中的零妥协:代码健康度、错误处理规范与生产就绪标准 | 如何编写持久化的代码? | #5653 |
前五份文档回答的是结构性和人为层面的问题。第六份文档回答的则是贯穿于所有这些问题之中的核心问题:在既定的结构、既定的团队、既定的工具之下,如何才算把代码写好?
本系列中的每篇文档最初都源于一个 GitHub issue,即一份 RFC,开放给整个团队进行讨论、质疑和完善。上方链接的讨论帖是这一过程的鲜活记录:所提出的问题、提出的反对意见,以及塑造了最终形态的思考。
此文件夹中的文件是经批准的版本,是团队讨论过、支持并选择沿用为规范参考的文档。它们存放在此代码仓库中,与代码一同进行版本管理,因为它们所代表的思考影响着仓库内的每一个决策。无论是阅读此代码库的 AI 助手、初来乍到正在熟悉的新贡献者,还是重新审视两年前所做决策的维护者,都应当能够从代码追溯到塑造它的推理思路。
GitHub issues 仍保持开放状态,作为永久性的讨论记录。如果你有疑问、不同意见,或这些文档未涵盖的观点,最合适的去处便是其中某个讨论串;或者,如果你是在那些对话结束很久之后才读到这篇内容,可以在社区发起一个新的讨论。这些文档是参考资料,而非定论。它们所开启的对话理应继续下去。
您可能在该项目编写完成多年后才加入。工具已经发生了变化,代码库的外观也有所不同。其中一些内容可能已被后续文档所取代、完善或替换。
这些文档试图在你身上培养的判断力没有改变,也不会改变。它们所提出的问题——当出现失败时应该发生什么、这个接口承诺了什么、我的测试究竟证明了什么、接手这个问题的人需要知道什么——既不是 Rust 的问题,也不是软件的问题。它们是关于如何构建他人能够信任的事物的问题。在你将来从事的每一种语言、每一个系统、每一个领域里,这些问题都是相同的。只要你坚持发问,它们就会在背后悄然累积、复利增长。
这就是本系列对你所做的投资。欢迎加入团队。
ZeroClaw Maturity Framework 是一个持续演进的文档体系。当团队积累了值得保留的经验时,便会新增相关文档。每份文档最初都以公开 RFC 讨论的形式启动,并通过与上述六份文档相同的流程获得认可:开放对话、坦诚分歧,以及团队集体决定将其纳入并持续推进。