LLM编码普及让IT人员软件选型更难，大量速成项目涌入

IT人员的工作之一就是挑选软件，无论是应用程序还是软件库。这个流程会因你的需求或组织需求不同而有不同要求，但总体来说，每个人都绕不开一些基本标准，比如：

随着LLM编程的兴起，这些标准的评估方式发生了变化。如今，要做出一个乍看质量不错、测试和文档齐全、背后似乎还有良好组织的软件，实在太容易了；但实际上，那可能只是某个人利用业余时间用LLM快速生成的项目。当你深入细节去审查时，会发现它可能缺乏精确性和一致性，充斥着大量LLM生成的样板内容，范围界定也不清晰。这不仅仅是使用LLM的问题，而是因为要把一个项目做好，需要大量时间去明确边界和细节——无论软件是由人类编写的，还是在LLM辅助下完成的，都是如此。

而且随着时间推移，这类快速生成的项目数量正在激增。所以当有人试图为某种需求挑选软件时，表面上的可选方案似乎比以前多得多，但深入细节后往往发现，这些选项大多不是真正可用的选项。

结果是，现在筛选软件的工作量比以前更大。需要过目的项目常常比AI浪潮之前多出一个数量级，而且更难判断哪些项目质量好、六个月后依然存在，哪些则不然。一个不错的判断标准往往是人们在项目上投入了多少——如果投入的时间多，未来就更可能继续投入时间维护和推进项目，尽管投入的精力已经不能再通过项目规模来衡量了，毕竟现在文本生成很廉价。

很多AI项目不过是几周或几个月的业余时间代码生成产物，有时候针对自己的特定需求用LLM重新生成一个，反而比直接使用现有项目更划算。

这推高了软件选型的成本。决策者现在需要花更多时间评估项目，过去那些 superficial 的技术标准——比如检查测试结果、代码覆盖率、文档的有无和篇幅——已经不那么有用了。这些东西现在都能快速生成，不再能决定质量。AI时代之前留下的唯一标准，往往只剩下社区规模，这让软件选型看起来更像人气竞赛，而非技术评估。

所有这些，即便在我的具体工作中，也给我的IT工作增添了压力。最近我遇到很多有趣的项目，但其中不少是LLM生成、辅助程度不一的项目。这让我很焦虑，因为我很想用它们，但大多数项目会像生成时一样迅速消亡——开发者一旦失去兴趣，或者维护所需的token变得太贵，项目就完了。所以最近我开始检查LLM编程的痕迹，如果有替代方案，就尽量避免使用依赖LLM的项目。因为对我来说，直接忽略LLM生成的项目，比认真评估它们更高效。

有不少工具可以快速检查项目中LLM的使用情况，我最近用过的几个：

我希望软件仓库能提供徽章或明确标注，提示软件是自动生成的，或者有个通用索引来给“AI程度”打分，也许还能和其他软件选型标准放在一起。

期待看到更多人分享他们应对这些新挑战的方法和感受。我想听听你们用什么工具和数据来过滤内容中的噪音——拜托别说“我直接用XYZ AI” :)

IT世界变化太快，也许快到人们（包括我）跟不上的程度，我真的需要宣泄一下这些给我们的工作带来的压力！