Drupal (AI) Playground: Adding more structures to my playground

Building new modules using AI

我正在搭建一个实验场来进行人工智能实验。我上一篇文章讨论了 使用人工智能为 Drupal 开发并贡献一个新的实体/字段标签模块。我期待着接下来能创造出什么。在继续前进之前，我想暂停一下，探索人工智能如何帮助我管理和维护我现有的贡献模块。

一、使用人工智能维护我贡献的模块

在过去的十年里，我创建并管理了许多贡献模块。我不确定具体有多少个，而且让它们都保持最新状态一直很有挑战性。从长远来看，我相信一个具备合适技能的人工智能代理可以帮助我管理我那多得让人应接不暇的模块列表。首先，我需要将我的模块克隆到我的本地开发环境中。

二、通过 Composer 克隆我贡献的模块

我手动克隆每个模块的仓库是不现实的。幸运的是，Composer 支持 Git 仓库。然而，使用 Composer 设置和测试每个模块的 Git 仓库仍然可能非常耗时。由于人工智能擅长处理重复性、可预测的任务，这是一个让我的人工智能助手介入并让我的生活更轻松的绝佳机会。

三、使用代理技能让事情变得更轻松

由于 为本地开发克隆 Drupal 仓库 相当简单，这为开发自定义代理技能提供了一个很好的机会。和许多与人工智能相关的任务一样，最好向人工智能寻求帮助。因此，我让 Claude 协助我规划我的 drupalorg-project-clone 技能。

这是由 Claude Code 和 Codex 生成的我的新 drupalorg-project-clone 技能的前置说明：

通过机器名称（模块、主题或配方）将单个 Drupal.org 项目作为 Git 仓库克隆到 composer.json 或 composer.sandbox.json 中，用于本地贡献工作。当你已经知道项目机器名称时使用。获取 Drupal.org 的 Git 说明以确定正确的分支，在安装前解析项目类型，遵循本地仓库的 Composer 约定，并在需要时将打包版本替换为基于 Git 的开发分支。

将十几个仓库添加到一个人的 composer.json 文件中会让人类更难审查依赖项。当然，人工智能跟踪一个大的 composer.json 文件毫无问题。为了帮助人类管理一个可能包含数十个模块、配方和库的 Git 仓库的大 composer.json，我发现 Composer 合并插件 是将项目的 composer.json 拆分为多个子文件的理想工具。

四、使用 Composer 合并插件组织我的 Composer 依赖项

我开始使用 Composer 合并插件将 Webform 模块的外部库隔离到一个专门的 composer.libraries.json 文件中。多年来，我在本地 Drupal 开发环境中添加了一些其他的 Composer 子文件。我使用 Composer 子文件按类型（库、配方和沙盒）和状态（已弃用或宽松）来组织依赖项。

以下是我目前正在使用的 Composer 子文件的完整列表。

`composer.recipes.json`: 用于存储 Drupal 配方。

一般来说，这个文件会跟踪已安装的配方。

`composer.sandbox.json`: 用于存储我正在开发的贡献模块。

这些模块正在我的本地环境中进行克隆和开发。所有列出的模块都被克隆到 /web/module/sandbox 和 /web/themes/sandbox 目录中。

`composer.deprecated.json`: 用于跟踪已从 Drupal 卸载、现在应从 Composer 中移除的自定义模块。

完全移除一个模块涉及两个步骤：首先，在部署期间卸载该模块，卸载后，就可以删除其 Composer 依赖项。对于每两周发布一次的项目，这个文件确保我们在卸载模块后不会忘记移除依赖项。

`composer.lenient.json`: 用于跟踪需要升级到下一个 Drupal 版本的模块。

我喜欢这个文件的地方在于，我可以开始进行 Drupal 主要版本的升级，跟踪哪些模块还没有升级，并使用 `mglaman/composer-drupal-lenient` 和 Drupal.org 的一个补丁来监控和测试模块的升级状态。如果我还没准备好完全切换到下一个 Drupal 版本，我只需从我的 `composer.json` 中移除对这个文件的引用。

五、打造一项为我节省大量手动工作的技能

我的新 drupalorg-project-clone 技能一次只能克隆一个仓库。我真的很想为我正在积极维护的每个项目克隆仓库。与其假设一个自定义提示就能克隆所有仓库，在执行之前让人工智能展示其计划会更安全。我创建了第二个技能 drupalorg-projects-clone，用于查找给定 Drupal.org 用户的所有项目，询问应该克隆哪些项目，然后克隆所有相关项目。

六、使用两个代理比一个更好

我还不确定 Claude Code 是否能成功克隆我所有的贡献模块。根据我过去的经验，我知道不必仅仅依赖 Claude Code；我也可以使用 Codex 作为替代的编码助手或代码审查员。Claude Code 已经开发出了一个功能完备的技能，我想看看 Codex 是否能帮助改进它。正如我所料，通过利用两个非常能干的初级开发者，Codex 发现了一些差异，并让两个技能更加清晰明了。

七、向我的实验场添加模块

我对人工智能所能做到的事情越来越不感到惊讶了，但当 Claude 列出我为 Drupal 贡献的每个模块时，我还是有了恍然大悟的时刻。

我花了一整篇文章来解释我是如何克隆和组织我贡献的模块的。接下来，我需要开始使用人工智能来帮助我维护它们。我乐观地认为，人工智能可以立即改善大多数模块的测试覆盖率、文档、弃用修复和规划。

八、我还让 Drupal.org 承受了一些额外的机器人流量

值得注意的是，我的 drupalorg-project-clone 技能反复访问 Drupal.org 的 API 和网页以检索元数据。在观察 Claude 工作时，我预计 Drupal.org 的 CDN 会通过速率限制来阻止持续的流量。令人惊讶的是，Drupal.org 毫无问题地处理了额外的负载。如果 Drupal.org 的基础设施不堪重负，我会让 Claude 更新技能，以限制请求并遵守速率限制。

说实话，我认为按名称克隆单个项目的能力比克隆用户的所有项目更有价值。同时，我认为推广 Drupal.org 上的工具很重要，这些工具能帮助人们看到代理技能的潜力。

九、帮助 Drupal 社区创建代理技能

Drupal 社区围绕人工智能有很多活动，在芝加哥 DrupalCon 之后，Drupal 的人工智能最佳实践 项目启动了。每个人都处于人工智能之旅的不同阶段。如果你开发了一些你认为 Drupal 社区会受益的技能，那就参与进来。如果你好奇想看看社区正在构建什么技能，请尝试一下。

从头开始开发个人技能或在现有技能的基础上进行开发都是完全可以的。这肯定有点像狂野西部或《星际迷航》，这取决于你对人工智能的看法。不过，写这部分内容让我想起要确保我的 Drupal（人工智能）实验场包含我的 GNU `LICENSE.txt`，所以你可以随意使用我的 drupalorg-project-clone 技能来克隆 ai_best_practices 仓库，并为社区做出贡献。

十、总结

人工智能是辅助编码的工具，就像 Composer 是管理 PHP 包的工具一样。在这篇文章中，我希望读者能发现我使用 Composer 合并插件来组织和管理 Drupal 项目的方法很有用。在我们使用人工智能工作的过程中，无论是个人还是在我们的社区中，开发技能绝对是值得的。