关于 AI 的思考

AI 现在很火，LLM 的诞生和火爆，让 AI 达到了前所未有的高度。无数开发者、公司趋之若鹜，都希望能在这个风口分到一杯羹。

不禁回忆起好几年前，我在啃吴恩达的机器学习课程时的场景。那时候的我，也对 AI 充满了兴趣，但在尝试了一段时间后，我发现 AI 的门槛太高了，最终也没有坚持下去。

现在，Dify、扣子这类的编排工具，极大降低了 AI 应用的制作门槛。很多从来没有接触过 AI 开发、甚至没有接触过代码的人，也在尝试进行 AI 相关的应用创造。这些编排工具，有点低代码平台的味道，AI 的低代码平台。

我认为在这样繁华火爆的背后，也需要去冷静思考。LLM 不是万能，也不是所有的应用场景都适合用 LLM 来实现。有些功能用 LLM 来实现，有些高射炮打蚊子的感觉了，成本也是需要考虑的。

其实 Dify、扣子这类编排工具，是真正吃了风口的 AI 好应用。他们本身并不依赖 LLM，本质上还是普通应用。他们提供的是 AI 工具，这类工具的需求是真正有需求的地方。而他们的诞生又降低了门槛，让更多的用户涌进来，对他们来说扩大了自身的市场需求。

我个人还是更喜欢传统的代码来实现功能和需求，更可控，更易于维护。现在的 AI 发展，还没有到能够完全替代传统开发的地步。我认为，未来也达不到这样的地步。AI 可以极大的辅助代码开发，但不会替代传统代码。根本上来看，还是成本问题。如果任何需求底层都是通过 LLM 来实现，那成本是相当高的，也是没有必要的。至少目前 AI 编排工具这类实现的应用，无法去完全替代传统的代码应用。

现在还有一些 AI 项目在往另一个赛道发展，就是通过描述需求让 AI 生成完整的项目代码。这个方向我是比较认可的，不过对于特别复杂的项目，我感觉可行性还是有限。一个特别略微复杂点的项目，与其通过不断的提示词来描述需求、改进代码，可能还不如直接手撸代码来的方便。完整的复杂项目来说，人工整合还是必不可少的。

代码生成这个方向，我还是觉得像 GitHub Copilot 这样作为辅助工具的应用场景更大一点。我现在在写代码的时候，因为有 GitHub Copilot 的存在，效率已经得到了大大的提升。但可能由于成本的问题，GitHub Copilot 现在并不会基于整个项目的上下文进行代码提示，似乎还是基于当前文件的上下文，对于整个项目的融会贯通上还不够智能。确实作为商业项目，读取整个项目代码在成本上不太现实，并且 token 长度技术上可能也无法支持。其实也不用读取完整项目，自己调用搜索去根据关键词查找多个文件中需要的部分，作为上下文，可能也是个路子。

不管怎么说，AI 的发展是个好事情，对于每个人来说都是机会与挑战。