虽然“Does current AI represent a dead end?"本文旨在引起讨论，但是对于软件开发者来说，其中一些观点尤其相关：

“当前的 AI 该系统缺乏与其功能密切相关的内部结构，不能作为组件开发或重用，也不能分离或分阶段开发关注点。

这篇文章只讨论如何使大语言模型？（LLM）与其讨论如何在开发过程中使用，不如作为产品解决方案的一部分。 AI 例如，工具(例如，Cursor 和Zed AI 这样的 AI 代码工具)。虽然借助于使用 LLM 开展特定的软件开发生命周期活动（SDLA）我们确实面临着一些挑战，但是我们开发产品的方式通常不同于最终销售给客户的产品。因此，在下图中，我们关注以上两个部分:

图片来自卡内基梅隆大学软件工程研究所。

当前 LLM 面临的问题是，它们像汽车一样被出售——用户需要为整个产品付费，而不是指望将它们作为组合模块的一部分。汽车的不可分解不是问题，因为驾驶是一项严格控制的活动。即使你能像乐高积木一样组装汽车，它也不会被允许上路。

这大概就是大型科技公司所期待的——他们想卖给你一个完整的产品或服务，而不是一系列可以很容易被别人构建的可组件。保持 LLM 神秘有助于维持其高价值地位。

LLM 运行模式违反了计算领域的一个基本原则，即任务应该被分解。

这违反了计算领域的一个基本原则，即任务应该可以分解。一个高效的软件组件，无论是自行开发还是外部采购，都应该由可以进行单元测试的代码组成。这些组件必须能够可靠地与其他组件合作。

即使使用了一种产品 Oracle 在数据库中，我们仍然可以理解数据在概念设计方面是持久的。当我们决定使用哪种类型的存储技术时，测试机制已经准备好了。与此同时，数据库技术也在不断创新，但客户永远不会认为存储器制造商在某种程度上控制了软件。

在学术界，可分解性的缺失往往伴随着可解释性的缺失。我们可以总结其他和其他。 LLM 与交付软件相关的商业问题因素。

我们无法将 LLM 行为与训练数据分离。

现在，我们不能将军 LLM 行为与训练数据分离。众所周知 LLM 经过训练，但训练过程通常是不公开的，但结果被期望“原封不动”地接受。这种对组件“腌制”的期望在烹饪中可能是可行的，但不适用于软件组件的开发。

由于缺乏可靠的方法或方法来防止安全和隐私问题成为关注的焦点。 LLM 泄露一些敏感信息。不能从外部介入神经网络，向它解释哪些信息是私密的，哪些不应该泄露。

法律所有权问题仍然困难。我们可以证明，冷计算的操作结果是可重复的，同样的答案会在输入相同的情况下得到。然而，因为 LLM 带着无法摆脱的训练“负担”，我们根本无法证明他们没有侵犯现有的知识产权——事实上，他们很可能已经被侵犯了。

那些致力于减少碳足迹的公司正朝着和 LLM 制造商朝着相反的方向前进， LLM 制造商需要惊人的计算资源来获得性能下降。

这篇文章不是讨论如何使用它。 LLM 辅助开发，也不是为终端用户提供的。 LLM 工具。我使用的文本编辑器内置了一些形式。 AI 功能，但这些操作没有保证。众所周知，这些功能通常是走过场的功能——一些必须出现在产品中的“噱头”，而不是核心部分。

我认为 LLM 除非服务被引入产品，否则前景不大。 LLM 产品本身就是产品。

鉴于前面提到的原因，我想 LLM 除非是产品本身，否则作为服务被引入产品的前景不大。但即便如此，这对任何企业来说都是一个巨大的陷阱。当 Zoom 创始人 Eric Yuan 提出在 Zoom 中引入 AI 当替身代替与会者参加会议时，他自然被嘲笑。他认为这种能力自然会出现在“技术栈底层”。外包重大创新 LLM 制造商，实际上是把自己的产品路线图交给了另一家公司。

软体开发者应该如何应对？

那么，软件开发者应该如何应对呢？我们都知道，一个组件应该有明确的责任，可以被替换，可以和其他组件一起测试。如果是外部组件，也要遵循相同的计算标准——我们应该能够根据这些标准重建它们。

我们不应该因为追求短期热度而轻易改变游戏规则。关键是设计一个可以为企业提供所需功能的过程，然后开发一个可持续建设的平台。

作为开发者，我们应该保持开放的态度，拥抱真正可以解释和测试的东西。 AI。

作为开发者，我们应该保持开放的态度，拥抱真正可以解释和测试的东西。 AI。如果涉及到训练过程，这个过程应该是可监控的、可报告的、可重复的、可解释的、可逆的。如果我们发现 LLM 如果你认为一件事是真的，但事实并非如此，你必须能够通过一系列明确的步骤快速纠正它。如果这个描述没有意义，那么目前是基于 LLM 计算同样毫无意义。但是从理论上讲，我看不出为什么未来不能改变这种状况。

我担心的是，这种差异就像科学和圣物信仰的对比。我们可以做一系列不可行的实验(如果把圣物切成几块，这些碎片还会保持神圣吗？)，但我们不应该期望这两个领域有任何融合的可能。