时间差不多1个半月左右，一个半月我花掉了3.5万人民币token的费用。而这，还是使用当前市面上最便宜的，性价比最高的模型，如果使用claude，估计会翻一倍，达到恐怖的7万人民币。而这，领域还仅仅只限制在 “编程” 领域这一个范围内，类似使用loveable这种东西并不在统计范畴内。

所谓的深度pair，就是完成不用顾及成本，只需要关心效果，但凡有需要就提问，就和身边真正做了一个人一样，甚至还能抽空聊聊天，把沟通的频率加快到无时无刻不在发生，让对话保持和自己思路同步的节奏，不用瞻前顾后，替AI考虑。这成本似乎看起来不可思议，似乎看起来不可想象，但是实实在在就是花了这么多。

整个结果下来给我一个非常深的感受，那就是当一个项目在1万行代码以下，当一个项目不需要上下文，彻底从头开始，大模型能带来非常好的效果和体验，而这两个条件的约束下，我仅仅称之为入门的教程，使用if else也能达到类似的效果，不外乎穷举逻辑复杂些。

其次一个肤浅的认知，但凡月花费token在5千以下的，都没资格说自己体验过把AI作为生产力工具。

当一个项目的代码量在一万行以上的时候，哪怕这个项目是完全使用大模型从0开始编写的，它依旧会表现的一脸懵圈。而这，让我觉得大模型的记忆能力，一定需要发生质的改变，才能彻底解决一个核心问题，那就是：

大模型根本必须区分哪些东西是它自己写的，而这种区分不能是上下文记录的方式。

这就相当于一个人能一眼看出签名是不是自己写的，这本书是不是自己写的，只需要看目录就能知道自己书写的内容是什么，而这种记忆是大模型不具备的，这种能力的缺失会导致大模型完全无法驾驭大型项目，单纯依靠rag或者微调，都是死胡同。
目前我正在设想一种架构，用新的工程能力去解决两个问题：

  • 如何让大模型能一眼识别这是自己的产出，从而快速会议起整个项目的上下文，避免大幅度的无用代码的重播。
  • 如何让大模型的接口标注化，避免出错的时候才知道能力缺失，比如一个大模型是否支持图像输入，只有调用接口的时候报错才知道，否则需要人提前基于模型名字手工去登记约束，而这，明显是在开历史倒车。

在Agent流行的今天，到底花多少token，并不取决于用户本身的问题输入，因为Agent会基于自己的逻辑进行反复的思考和推理，多次与大模型交互，可能用户的问题只输入了一个字，但是发生了1000次和大模型的交互，而这1000次则是由Agent自由发挥出来的。
这也是我消耗token量最大的原因，当然，这并没有什么问题，因为我自己做Agent的时候也是这样干的，甚是Agent能自我思考，还会成为销售的卖点之一。

在这个月的时间内，我和AI进行深度Pair的代码工程量大概在20万行代码左右，刚好最近我又重新思考大数据的一些内容，而Hadoop 3.3.1整个工程已然超三百万行代码，我尝试过使用和他进行深度Pair，然后放弃了，因为如果使用Hadoop的话，一周可能3.5万就花光了。

我所选择的项目大约20万行代码，且将我所不擅长的领域，前端开发丢给AI去搞，虽然不擅长，但是如果AI写出来，我依旧能读的懂，能修改，这样AI则能完全弥补我所面对的能力不足的短板问题。

在这个过程中我无时无刻不面临一个非常痛苦的问题，就是如何让大模型知道，这个事它已经干过，这是一个非常痛苦的事情。当然很多搞过Agent的人会嗤之以鼻说这不就是Agent自己的历史记录，或者自己做一个历史记录，再结合大模型自身的Cache能力，能保留历史记录的同时，还能降低Token的成本。

这当然是一种缓和的方案，但是这种固化，低效，且不具备任何智能的硬记忆丝毫不能让大模型有进化的能力，它永远像一个5岁的小孩，我告诉他1+1等于2，它知道了，我告诉它3+4等于7，它也知道了，但是当他知道3+4等于7的时候，它已经忘掉了1+1等于2。

对我来说，我不是获得了智能，我是获得了智能在某一个时间的快照。

这个快照永远是在那个时间点，无论我如何优化处理，它的智商永远无法跃级。

回到最痛苦的这个问题上来说，我希望大模型是在一个连续的思路下我和进行Pair，而不是在背诵文章一样在一个连续的文本复制列表的场景下和我进行Pair。

这就导致每次我和它沟通的时候表达出：基于上一个修改的思路进行调整的时候，它都无法准确的定义出上一个修改的思路到底是什么，哪怕曾经我告诉过它这个思路是什么。我需要继续附带无数的样例和源码去解释这个思路是什么，不厌其烦的讲述。

而这，好歹还能通过连篇的废话去反复告诉他，能解决，紧接着一个更麻烦的问题是，目前并没有特别好的读代码的功能，大模型具备语言层面的能力，但是并不具备非常友好的代码阅读能力。

而这个阅读能力的构建，除了考验大模型自身之外，也考验工具本身的查找能力，比如我尝试让AI帮我解决一个问题：

将整个工程中使用到await axios.post和await fetch发起网络请求的地方都添加一个header xxx=xx。

在这个任务下，修改非常简单，难的是需要找到使用的地方，我将循环次数设置到1000次以上去，在20多万行代码中，AI狂奔了大半小时，成功找到且改掉的地方也寥寥无几。

在反复多次调整话术，甚至指导它定向去找之后，效果依旧没有达到预期。最后只能自己上手去修改，而在这多次来回，几个小时的AI自由发挥之后，几千块的Token没了。

中间本质的问题在于，如果要完成这样一个相对简单的问题来说，AI首先需要做到：找到位置->修改代码，而找到位置AI自身无法直接实现，需要借助工具，而不同工具呈现出来的查找能力是不一样的，特别是在海量的工程内进行搜索，虽然这只是IDE的一个control+shift+F的功能而已。

其次受限于窗口大小的限制，就算找到了也不见的能直接发送所有片段，只能逐个修改，对于无法的代码片段，会直接导致上下文不足从而引起质量不符合预期的问题，且在这样的问题下，由Agent发挥一堆之后，不但质量不行，成本还非常高。在这个过程中我无数次遇到出现上下文超长，直接导致Agent宕掉，既没有获得结果，费用也消耗了情况。

我认为一个Agent未来在商业逻辑上应该发生调整，那就是Agent的收费不应该和LLM绑定，应该完全解耦合。

因为目前所有Agent在收费上有一个很反常的逻辑就是无论Agent是否成功解决问题，甚至可能中途直接挂掉了，但是依旧需要付费，因为消费了Token，而Token是LLM收的，LLM只要使用就会产生Token，那么购买Agent到底是购买的什么？这是所有做Agent的场景下需要仔细思考的商业逻辑。

AI对于存量知识的理解，是难以跨越的门槛，这个门槛随着项目复杂度的上升，会出现指数级的增长，当我和AI进行深度Pair的时候，最严重的时候是下发一个修改命令后，吃顿饭回来，AI还在那读代码呢。。费用到是水涨船高。

当然因为我用的是成品面向C端的AI工具，对于企业来说，或者有企业服务经验的人会直观认识到说，这种情况下，典型应该构建企业内部代码知识库，提升代码效果，将企业知识，包括代码，文档，构建于一个知识库内，提升AI对存量知识的理解能力，加速查找过程，可以深度解决上下文的问题。

关于这个，下次有空再说了，我只能说，算了，算了，我在Hadoop这300万以上的代码工程中，尝试搞了这套，差点没累死。。

扫码手机观看或分享：