像人一样使用大模型 —— 现代大模型的痛点与工程化解决方法

不要奢望基础大模型可以解决你所有的问题，即使它有一天真的会像人一样工作，那它也是有能力边界的。

自从大模型AI爆发以来，它在两个应用领域获得了巨大的成功：内容生产与代码生成。现如今在内容生成领域已经有一批账号获得了成功，不论是在短视频领域还是公众号领域。

但是由于大模型或者说transformer架构本身的限制，实际上任何模型都无法接收无限或者源源不断流式的tokens，所以都有上下文长度限制，就目前（2026-1-3），deepseek的最长上下文长度是128k，Qwen3最长也是128k，GPT-5则是400k，Gemini 3则有着夸张的2M到10M的上下文长度。

依然不是无限增长的，但是在用户使用过程中必然随着深度使用，其知识将会越来越深刻越来越广泛，上下文必然在使用过程中是一直增长的。于是基于向量数据库的外置记忆系统成为了一个主流的解决方案，每次携带的记忆可以从向量数据库中查询出最要紧的部分放入上下文使得不用每次将所有的内容全部输入到大模型。

有些知识与概念并不是最新的，所以接入搜索引擎，查询到最新消息输入到大模型是保持知识更新的一种方法。绝大多数系统都会接入搜索以获得最新的知识。

有时候大模型需要主动调用工具使用工具能力来帮助用户完成工作，现在的大模型Agent框架都具备工具调用能力，并且一些新的协议比如MCP也帮助大模型获得了调用与执行的能力。

可以简单的将现代大模型开发总结为以下流程：

搜索引擎 记忆系统 工具信息 用户提示词等等
         ↓
        输入
         ↓
       大模型
         ↓
   内容输出 工具调用

痛点

大模型开发的基础框架已经确定了。但是无法避免抽卡式的内容输出、大模型幻觉问题与越用越蠢的现象也没有得到很好的解决。我们需要一种更加合理的方式来完成用户的需求。

对的，用户的需求这一点观念需要深刻的被理解。即，用户是用户，大模型厂商通常会忽略或者将提示词工程工作交给用户来做，但是其实用户也无法写出（或者说任何人都无法写出）足够专业的提示词，说到底模型始终是一个黑盒，是一个无法被精确预测的概率游戏，我们无法理解其中规则，但是大模型可以。

2025年发生了一件事情 nof1交易竞赛**，它的思路是完全将大模型作为交易员而非顾问或者助手来使用，用户每三分钟提供一次详细数据信息，比如价格、交易量、头寸、收益以及各种指标等等让大模型自行决策与交易。国产的几个大模型获得了不错的成绩。这给了我一些启示，大模型可以作为独立的智能存在，它可以自行做好一些事情。

或许的虚拟的赛博世界，大模型的活动方式确实是具有高智能的，但是确是不符合人的思维与行为模式的，所以给人以一种怪异的，幻觉的，错误的大模型输出错误的感觉。

那么这与我们遇到了幻觉、长上下文注意力涣散、抽卡输出有什么关系呢？我们细想一下，实际上我们要解决的是一个问题：构建一个可被大模型理解的上下文。而解决这个问题我的的答案是让大模型自己决定自己解决。

解决

你是否使用大模型解决过乱码问题，比如下面的：

这乱码是什么意思？`寮€濮嬬幆澧冩鏌?..
鐜妫€鏌ュ畬鎴愶紝鎵€鏈夊繀闇€鐨勬枃浠跺拰鐩綍閮藉凡鍑嗗灏辩华銆?寮€濮嬫暟鎹簱鍒濆鍖?..
閽卞寘琛ㄥ垱寤烘垚鍔?璐︽埛琛ㄥ垱寤烘垚鍔?浠诲姟琛ㄥ垱寤烘垚鍔?浠诲姟鎵ц璁板綍琛ㄥ垱寤烘垚鍔?鏁版嵁搴撳垵濮嬪寲瀹屾垚
鍚姩瀹氭椂浠诲姟 4锛宑ron琛ㄨ揪寮? 0 10 * * *
鍒濆鍖栦簡 1 涓畾鏃朵换鍔?瀹氭椂浠诲姟鍒濆鍖栧畬鎴?`

大模型可以在不知道编码的情况下解码出来信息：

这段乱码是UTF-8编码的中文被错误地以其他编码（如GBK、ISO-8859-1等）解码显示的结果。正确解码后应该是这样的：
```
开始环境检查...
环境检查完成，所有必需的文件和目录都已准备就绪。
开始数据库初始化...
钱包表创建成功
账户表创建成功
任务表创建成功
任务执行记录表创建成功
数据库初始化完成

启动定时任务 4，cron表达式：0 10 * * *
初始化了 1 个定时任务
定时任务初始化完成
```

也就是说AI模型本身实际上并不是直接使用的人类眼睛看到的编码。它模型内部本身（或者说计算机本身）使用的是自己的一套不为人知语言系统。那么，我们写的提示词，难怪大模型可能会理解偏差。

等等，理解偏差，这事情在人类协作的时候也是常见的问题，那我们是如何解决这个问题的呢？我们要开会确认每个细节是否是各方想象的一样，最后由各方自行记住并且由需求方记录变更。

我是一个程序员，我接到的并非是直接的原始需求，而是由产品经理整理过一遍的具体需求。产品经理是项目组内部的人，那么在实际我们使用大模型过程中也是需要经由产品经理这一角色与用户（也就是我们）确认需求形成需求文档之后才能交给大模型处理，又因为内部人才最了解大模型运作，那么产品经理这一角色也应当是大模型（或者说是构建出来的agent）。

这里不得不提一下Claude Code以及类似的GUI应用，比如Trae和Qoder等等，他们的其中一个问题是管线流程是不对的，用户提出需求之后没有确认需求没有形成指导就直接开始工作了。在需求不明确的时候直接开工，使得需要频繁返工，而频繁返工又带来了上下文问题，提高了幻觉，这就形成了恶性循环。

Claude Code?

那我们在真是开工之前多家一层，用来转换用户需求就行了吗？现在的Claude Code协作方式是错误的，它只适合用来做小任务写小项目，一旦项目规模变大，复杂度提高，这整个管线就将无法适应。我们需要构建专门的角色来帮助对接用户，沟通其他角色。实际上，我们需要模拟我们实际生成生活中的工作流程、协作方式。比如在软件开发领域，用户给出的需求通常是不明确的，需要产品经理来将用户需求转换成各方程序员可以听懂的语言，产品经理和用户协商并确认需求之后，这个需求才会向下流转，架构将根据需求进行系统设计，确认需要划分的子系统与模块，需要做的端。用户、产品和架构确认之后会现成明确的需求文档与系统设计文档，接着才会向下流转到开发阶段，此时各端给出详细设计并与产品、架构确认通过之后，正式写代码。

可以看到Claude Code实际上直接将多个角色杂糅在了一起，用户直接使用大模型，可能将导致上下文过长，各方面知识混乱与术语混乱。我们需要构建专门的角色来承接用户需求，做系统设计与架构设计、进行前后端开发、进行测试等等，在开发过程中需要现成可以指导后续流程的文件，并且这个问题应当是经过用户确认之后的，明确的指导文件（这用来保障用户理解与大模型理解的一致性）。

Multi Agent协作？

那这不就是一个Multi Agent协作系统吗？是，也不是，实际上我们需要构建的是一个更强的又更加分工明确的系统，整个系统围绕项目设计，实际项目中所需要的角色都将在系统中被实现被驱使，这有点像将不同的角色划分为不同的agent然后通过流程系统维护他们的相互协作，用户始终只面对整个系统中需要面对的角色，在软件开发过程中是产品经理与技术架构师，在影片制作过程中主要是导演与编剧。

系统围绕项目构建，每个角色都将有自己对于这个项目的记忆、知识与理解。好比产品经理不会了解代码是如何写的，而程序员不该知道原型是如何画的。在整个项目的实现过程中各个角色将自行决策哪些知识与记忆需要被持久化，不明确的地方需要从哪里获取知识与记忆，每个角色都有基于自身角色对项目独特的理解。

是的，我们将大模型当作人一样来使用，并且希望它们像人类一样自行协作，解决外部问题，从而解决用户的问题。

DDD √

领域驱动设计与nof1启发了我。DDD的一些理念，比如统一语言、领域建模、分层架构等等在实际开发的协作过程中其实是比较难做到的，但是如果对象是大模型，我们构建的系统也按照这个方向区做那实际上是可以做到的，并且这使得需求的提出者（也就是用户）在整个流程中不会一脸懵逼无从入手。在构建系统角色的时候我们也需要专注于领域设计，一方面避免各个角色脱离指导闭门造车，另一方面各个角色关注的领域都将是独特的，有自己的上下文。

我们还需要避免流程化，无记忆，无意识的流水线式生成。扣子（Coze）是一个反例，我们需要用户在这个过程中有反馈，并且各个角色可以根据用户的反馈改进自身工作，保障系统围绕项目而非任务或者计划工作。

结语

目前来看，在内容生产领域与代码生成领域都可以构建这样一套系统帮助提高效率，实现其想法。

对于内容生产领域其流程应当是：

用户输入需求 -> 编剧编写故事与剧本|导演确认影片基调叙事结构，镜头语言等等。用户确认剧本与计划没问题之后进入下一步 -> 场记根据编剧与导演要求，设计每个镜头的详细信息，用户确认后进行下一步 ->  选角与美术生成资产（背景与角色），用户设置且确认之后进入下一步 -> 摄影和声效根据镜头与资产生成相应的短片、对白、音效与背景音乐 -> 剪辑根据要求合成长影片 

用户只会直接面对编剧与导演。这里的编剧、导演、场记、选角、美术、摄影、声效、剪辑将全是AI。

对于代码生成领域其流程应当是：

用户提出需求 -> 产品经理现成需求文档与架构师规划系统设计，用户确认之后进入下一步 -> UI设计画出原型（如果需要的画），用户确认后进行下一步 -> 各端开发根据系统设计文档与需求文档给出详细设计方案 -> 各端开发并调试 -> QA审查 -> 产品验收 -> 用户验收

同样的，产品经理、架构师、UI设计师、前后端等开发、QA都将是AI。