Infusion 文档生成 CLI 工具

infusion 文档生成 cli 工具

Infusion 是一个开源工具，用于在代码文件中生成文档。它使用OpenAI gpt-4模型来编写注释。这是我的项目，我用 Python 编写的。

GitHub 链接：
https://github.com/SychAndrii/infusion

explainer.js 是一个开源工具，用于解释代码文件中的代码片段。它使用 Groq 模型来编写注释。这是我的队友 @aamfahim 的一个项目，他用 Node.JS 编写的

GitHub 链接：
https://github.com/aamfahim/explainer.js

我目前正在塞内卡理工学院 (Seneca Polytechnic) 参加一门开源课程，我们的任务是与另一个人合作，审查彼此的代码，并使用 GitHub 问题提出一些改进建议。我将描述这个过程。

沟通方式

两个存储库生成的大多数问题都是通过 Discord 调用使用同步通信完成的。之后，我们使用 Discord 消息进行异步交谈，因为使用 bash 脚本简化项目设置对我来说是一个困难的问题，并且每次我需要测试它是否在他的机器上运行时打电话给我的队友似乎没有必要。在我的机器上使用 Docker 容器和 WSL Linux 子系统进行测试与在 Al 的系统上进行测试不同，它突出显示了重要的错误。

审查某人代码的经历

在检查队友的代码时，我没有遇到任何异常，因为我有丰富的 Node.JS 开发经验。我喜欢创造问题，然后立即提出解决方案。我们遇到的一个问题是，我们无法找到一种方法让我在我创建的问题上贴上标签，只有 Al 可以做到，这很烦人。

有人审查我的代码的经历

Al 提出了很多改进的空间，特别是在安装我的 CLI 工具方面。当他第一次分叉我的存储库时，最终用户需要手动安装特定版本的 python，这绝对是一项令人沮丧的任务。此外，他还强调了为了方便使用工具而可能进行的其他改进，例如引入 .env 文件，这样您就不必在每次启动该工具时输入 API 密钥。我喜欢从其他人那里获取对我的代码的输入，因为它可以让我成长为一名开发人员，并且它肯定会扩展我对开发生命周期的看法。

审查和测试期间的问题

我们遇到的大部分问题都与我的工具有关，因为 Al 的 CLI 程序是用 Node.JS 编写的，而且我们都有很多使用它的经验。相比之下，我们都不喜欢Python生态系统，所以我们在与它交互时遇到了很多麻烦。在测试 Al 的存储库时，我发现他的 README 中编写的文档具有误导性或难以理解，尤其是模型和 api-key 选项。我们必须经历反复试验的过程，才能确定他的工具接受哪些 API 密钥和模型。在测试我的存储库时，Al 系统上的 python 版本非常过时（2.7），因此他必须手动安装 3.10.6（使用我的工具所需的版本）。然而，即便如此，问题并没有结束。尽管他安装了它，但我的工具使用 pipelinev 创建的虚拟环境仍然无法识别它。此后，我们每次启动工具时都对输入使用该工具所需的 API 密钥感到沮丧。最后，自述文件对安装没有帮助。我们试图遵循它们，但我们不断收到与 PATH 上无法识别的某些脚本相关的错误。就在那时，我决定我们需要某种自动化工具来为您完成所有安装。我的一个想法是对应用程序进行 docker 化，但随后它需要我以某种方式将 Docker 卷映射到为我的工具指定的输出目录和输入文件，这将使一切变得更加复杂。因此，我记得很多包管理器实际上是命令行工具，如果您通过克隆 GitHub 存储库来安装它们，那么您需要通过执行某种 bash 设置脚本来设置它们。这就是我决定实施的想法。最后，我们都无法找到一种方法来为我们提交的问题分配错误或增强等标签。

我提交的问题

https://github.com/aamfahim/explainer.js/issues/13
https://github.com/aamfahim/explainer.js/issues/12
https://github.com/aamfahim/explainer.js/issues/11
https://github.com/aamfahim/explainer.js/issues/10
https://github.com/aamfahim/explainer.js/issues/9

总结我发现的问题，它们主要涵盖了该项目的自述文件中编写的选项实际上不起作用，或者它们的工作方式被误导性描述的情况。

在我的存储库中提交的问题

https://github.com/SychAndrii/infusion/issues/11
https://github.com/SychAndrii/infusion/issues/10
https://github.com/SychAndrii/infusion/issues/9
https://github.com/SychAndrii/infusion/issues/8

总结一下我的仓库中发现的问题，它们主要与我的工具使用的便利性有关。此外，当您向我的工具提供语法正确的源代码的文件时，存在一个错误，它会将其识别为不包含有效源代码的文件。

我设法解决的问题

我解决了所有问题。所有这些都花了不到 30 分钟的时间来修复，但有一个问题，我花了大约 2-3 个小时才修复：
https://github.com/SychAndrii/infusion/issues/8

这看起来很奇怪，因为自述文件的增强应该很容易实现，但是 Al 的第一个建议要求我完全重新制作我的工具的安装过程，这需要我引入 2 个安装脚本 - 一个用于 bash 和一个用于 Powershell。我大部分时间无法解决的问题是，即使这些安装脚本正确安装了所需版本的python，但该版本的python并没有传递到虚拟环境，您需要在使用我的工具之前进入虚拟环境。最终，我解决了这个问题。

我学到了什么

我的 README 技能确实得到了提高。我提供示例用法的方式让最终用户感到非常困惑。此外，我终于使用 bash 和 powershell 语言自己做了一些事情，不是为了学校作业，不是因为这是一项要求，而是因为我想简化与我的工具交互的过程。最后，我决定面对我绝对无法忍受的语言——那就是Python。使用它对我来说绝对不是一件愉快的事，但我认为如果你今天想找到工作，能够使用它是至关重要的，尤其是在人工智能趋势方面。

以上就是Infusion 文档生成 CLI 工具的详细内容，更多请关注其它相关文章！