经过 27 年的编码，我停止了在冗长的小而痛苦的工程任务上花费时间。 AI 代理现在处理提交消息、拉取请求描述、代码注释、命名约定、Git 卫生、问题跟踪和发布工作流程，其一致性超出了大多数团队手动管理的能力。我最喜欢 AI 的一个方面是我没有预料到的：它在开发者们很少喜欢做的任务上表现出色，而当我们正确做这些任务时，它们会消耗大量的时间。让我们从提交消息开始，每个人都忘记的朋友。我不记得自己花了多少小时来写出良好的提交消息、有效的 PR 描述以及所有使更改对其他人易于理解的周边上下文。我曾与之合作过的大多数工程师几乎没有写有意义的提交消息。然后，当审查或合并某个内容时，我们耗费更多的时间挖掘代码，只为理解提交或 PR 的内容。现在，我将这些工作委派给 AI。它按我希望的方式编写提交消息和 PR 描述，准确程度让我一开始有些害怕，而现在我绝对喜欢。这让我能够专注于应用程序，而不是为那些可能在喝咖啡时只简单浏览一遍的开发者写一本小书。注释终于变得便宜 这不仅仅是关于提交和 PR 的问题。这同样适用于代码中的注释。这个话题上显然出现了明显的两极分化。有些工程师喜欢代码中的良好注释（例如我），而另一些则乐意从代码库中删除每一个注释。老实说，我理解这两种立场。多年来，我找到了平衡。我不想仅仅为重复代码中已经说过的内容，而将整个代码库重写成可读的人类英语。但我确实有关于注释的具体规则：不使用表情符号，不使用装饰性的废话，根据我所使用的语言适当的注释，一致的格式，适当的文件头，当有助于 LLM 上下文时，提供完整的文件路径，单行的事实描述，关于文件所属于的架构层的信息，等等。我记得我花了数百小时手动维护这些细节。哦，每当有内容更改时，头部和注释也必须更改。现在这些大部分都是自动化的。代码库保持良好的描述，我不需要将脑细胞倾注于维护那些有用但令人痛苦重复的细节。不要指责我。多年来，我以为在代码库中投入这么多精力是专业工作的一个部分。现实不断让我清醒，几乎没有人关心，除了那些也做这种工作的少数人。讽刺的是，最重视这些结构的受众现在是 LLM。它们喜欢这个上下文。它们可以使用我之前写的规则、注释、路径、意图和架构描述。这使得与代理的合作更加愉快。你得到的互动是：你写了这个规则，但现在你让我要做相反的事情。我们该如何协调这一点？这种互动使得 AI 辅助的工程过程变得更加流畅。代码库停止仅仅是一堆源文件，而开始承载足够明确的意图，以便代理能够挑战不一致性。命名仍然很困难，因此我停止了手动完成所有工作 我过去用于命名文件、类、函数、模块及其周围内容所花费的时间是不可思议的。我为我合作的团队编写了数十本开发者指南。命名约定、目录结构、后缀、前缀、抽象、约定的例外，最终是例外的例外。 AI 在这方面的表现更好。项目一年后，不再出现 30 或 40 种不同的文件命名风格。命名冲突减少了。不再需要在十分钟内努力回忆六个月前负责某个紧急检查的文件的名称。一切命名都变得一致。甚至改变主意也变得几乎无关紧要。我可以说：不要使用 class PostgreSQLClient {} 。使用像 class DatabaseClient {} 这样的通用名称。然后，代理可以进行重构、更新引用、运行测试、修复缺失部分，并在票据中标记相关复选框。改变主意过去是昂贵的。现在，对于许多更改，这主要是一条指示。我还停止了监视 Git Git 是我很高兴让代理做无聊工作的另一个领域。我不再重复同样愚蠢的错误第 100 次：在 dev、main 或某个无关的特性分支上开始工作。这种情况持续发生。我会合并一个 PR，稍后再回到本地环境中，开始更改代码，才意识到我仍然处于刚合并并在远程删除的分支上。现在，代理为我检查这一点：您在 dev 上。我将创建适当的分支并在那里继续工作。