墨墨墨墨墨宝の宝藏之地

这段时间做 AI 项目，我越来越觉得一句话特别危险：

“这个功能其实已经差不多了，再优化一下就行。”

如果放在传统软件时代，这句话很多时候还真没什么问题。

比如一个 Java 系统接口慢了，可能优化一下 SQL。

页面体验不好，调一下前端。

某个流程不顺，改一下业务逻辑。

因为传统软件大部分行为都是确定性的。

输入是什么，流程怎么走，输出应该是什么，通常都比较清楚。

系统出了问题，也比较容易沿着模块边界去定位。

所以传统软件工程一直强调：

稳定。

谨慎。

最小改动。

核心链路能不碰就不碰。

如果一个系统已经上线，结果为了一个小问题把整个底层架构重做，在传统项目里往往会被认为是非常不成熟的行为。

但 AI 项目越来越让我觉得，这套经验虽然仍然有价值，却不能完全照搬。

因为 AI 系统里经常会出现一种很奇怪的现象：

用户看到的只是差一点，工程上可能差的是一整层架构。

比如客户会说：

“这个通用问答其实已经能用了，就是有些问题不够灵活。”

听起来像是小优化。

但你真正往下分析，可能会发现问题根本不在 Prompt。

原来的系统可能是：

用户问题
→ 固定工作流
→ 知识库检索
→ 模型回答

只要问题落在预设流程里，效果还可以。

可一旦用户的问题需要：

先读文件，

再查知识库，

根据结果决定还要不要继续调用别的能力，

甚至需要动态组合多个工具，

固定工作流马上就会暴露边界。

这时候客户看到的是：

“有些问题回答不了。”

工程师看到的却是：

“现有架构缺少动态决策能力。”

如果真的想解决，那就不是再加两个判断条件那么简单。

可能需要从：

固定 Workflow

升级成：

动态路由

Tool Calling
多步执行
状态管理
上下文管理
终止条件

这已经不叫优化。

这叫换了一套运行逻辑。

知识库更明显。

客户可能只是说一句：

“这个 PDF 的回答效果再优化一下。”

听起来甚至比通用问答还小。

结果你一查：

文本解析不完整。

那就加 OCR。

加完 OCR 以后发现表格结构丢了。

那就做 Layout Analysis。

表格能识别了，图片语义又丢了。

那就做多模态解析。

内容解析出来以后，Chunk 切分又破坏了上下文。

那就做父子节点、层级切分。

检索命中了一个局部片段，但完整语义还不够。

那就继续改召回、Rerank、上下文组装。

最后回头一看。

最开始客户说的是：

“优化一下 PDF。”

最后做出来的却快变成一套 Document Intelligence 系统。

这就是 AI 项目里很反直觉的一点：

用户体验上的小差距，和工程改造成本之间，经常不是线性关系。

有时候甚至可以粗暴地理解成：

效果从 70% 到 80%，可能只需要调调参数。

80% 到 90%，可能要改策略。

90% 到 95%，可能就得重新思考底层架构。

客户看到的是：

“不就再提高几个点吗？”

工程师看到的是：

“这几个点可能要把半套系统重做。”

这也是为什么现在很多 AI 项目特别容易出现需求失控。

因为需求表面看起来很小。

“回答再聪明一点。”

“检索再准一点。”

“记住用户之前说的话。”

“自动判断该用哪个工具。”

每一句听起来都像优化项。

但真正拆下去，很可能分别对应：

RAG 架构调整，

Memory 系统，

Agent Runtime，

Context Management，

规划与执行机制。

这几个东西单独拎出来，都足够做成一个完整模块。

所以我现在越来越觉得，AI 项目里的需求评估不能只问：

“这个功能改起来要多久？”

而应该先问：

这个差距到底属于哪一层？

我大概会把它分成三类。

第一类是参数级问题。

比如：

TopK 不合适，

Prompt 表达不好，

温度参数有问题，

某个阈值需要调整。

这种确实可以叫优化。

第二类是策略级问题。

比如：

检索方式不对，

切分策略不合适，

上下文组织有问题，

工具路由逻辑需要调整。

这种已经不是简单调参数了，而是在修改系统行为。

第三类是架构级问题。

比如：

固定工作流根本无法覆盖需求，

系统缺少长期记忆，

知识库缺少多模态解析，

单轮调用无法支持多步任务。

这时候再说“优化一下”，其实是在掩盖真正的改造成本。

而现实项目里最麻烦的地方，就是这三种问题在客户看来往往没有区别。

客户只会看到：

“现在不好用。”

至于为什么不好用，是参数问题、策略问题还是架构问题，他通常不会关心。

这其实也很正常。

客户本来就不应该理解你的系统架构。

真正应该判断这件事的人，是产品、架构、研发和项目团队。

所以 AI 项目里一个很重要的能力，可能不是“怎么快速改”，而是：

怎么判断一个看起来很小的问题，背后到底需要多大的工程动作。

这也是我现在越来越警惕“先做出来再说”的原因。

因为 AI 系统很多时候并不是简单地往上堆功能。

每增加一层能力，都可能改变之前的设计假设。

最早可能只是：

Prompt + LLM。

后来发现知识不够，就加 RAG。

再后来发现单次检索不够，就加 Rerank。

再后来发现固定流程不够，就加 Agent。

Agent 跑多轮以后上下文越来越长，又开始做 Context Management。

希望跨会话记住用户，又开始做 Memory。

系统就这样一点点长大。

有时候并不是团队喜欢过度设计。

而是随着能力边界不断往外扩，之前那套架构本身就开始不够用了。

所以我现在反而能理解，为什么 AI 产品的架构演进速度会这么快。

传统系统很多时候是在一个稳定业务模型里不断迭代。

而现在大量 AI 产品，其实还在不断验证：

这个系统到底应该长成什么样。

但这里还有一个非常重要的前提。

AI 项目经常需要重构，不代表这些重构应该发生在客户现场。

这是两回事。

产品研发阶段因为验证出了新的能力边界，重新设计底层架构，我觉得完全正常。

甚至很多时候是必须的。

但一个成熟的交付体系，应该尽量让这种探索发生在总部。

总部负责：

验证方案，

演进架构，

形成稳定基线，

再把成熟能力交给现场。

而不是：

产品本身还没想清楚，

销售先卖出去，

然后现场一边交付，一边替总部探索下一代架构。

如果所有产品研发阶段应该解决的问题，都被推迟到了客户现场，那现场当然会越来越像救火。

客户只是说：

“这里再优化一下。”

现场的人脑子里可能已经开始想：

“是不是得把整个流程重写了？”

这也是我现在觉得 AI 交付特别累的一个原因。

很多时候真正累的不是代码量。

而是你永远不知道客户口中的“一点点”，最后会不会一路挖到底层。

所以如果以后再有人对一个 AI 功能说：

“这个应该不用怎么改吧，再优化一下就行。”

我大概会先问一句：

你说的这个‘一下’，到底是参数级、策略级，还是架构级？

因为在 AI 时代，这三者之间的差距，可能比功能本身大得多。

而我现在越来越相信一句话：

AI 项目里最危险的需求，往往不是那些一看就很复杂的需求，而是那些看起来只差一点的需求。