企业官网建设流程全解析

老系统AI改造这个话题，我最近聊得不少。团队里只要有人提一句"我们能不能接入大模型"，接下来往往就是一连串的灾难现场：有人直接开始搭向量数据库，有人立项做智能 Agent，有人甚至想把老系统的数据访问层推翻重写。最后兜兜转转，发现钱花了、排期拖了、业务方却看不到能用上的东西。真正的问题在于，大部分团队把"AI改造"想成了"换一套新系统"，而老系统之所以还活着，恰恰是因为它改不动、不敢改、换不起。

这篇文章想聊的是另一条路：基于 Java 生态，把 AI 能力当一个"旁路插件"加进老系统，不强行改变原有事务链路，用增量式的低代码侵入方案，先把一两个高频场景跑通。适合后端开发、架构师，以及被业务方反复追问"到底能不能上 AI"的技术负责人参考。

在动手之前，先想明白一个反直觉的结论：老系统 AI 改造，真正的难点从来不是算法，也不是模型选型，而是如何做到"业务不停摆、代码少改动、效果看得见、出问题能回滚"。下文的所有内容，都是围绕这四条展开的。

1. 老系统AI改造为什么总翻车：先搞清"低成本"的真正含义

1.1 常见的三种翻车姿势

我见过太多次项目从热血沸腾到无人问津的完整过程。姿势一，是"上来就建知识库"。团队花两周把 PDF、Word 全部灌进向量库，结果业务方抛出第一个问题"某某合同在哪个页面写的违约条款"，系统回复牛头不对马嘴，因为没有先做文档解析和知识治理。姿势二，是"张口就做 Agent"。任务拆解、工具调用、多轮对话编排，复杂度成倍上涨，老系统那点可怜的数据接口根本喂不动它。姿势三最致命，是"把 AI 改造等同于重写系统"。重新设计表结构、换成微服务、引入全套新框架，最后老系统没死，新系统也没生出来。

翻车的共同点是把 AI 当成了主角，把老系统当成了障碍。正确的姿态应该是反过来：老系统是主角，AI 是一个可以随时插拔的增强件。

1.2 低成本落地的四条判断标准

我给"低成本"下了四个务实的标准，任何一个项目在启动前都可以拿这套标准去卡一下：

• 改动边界可控：不改变现有业务表的读写主链路，不加全局拦截器，不重构核心服务。
• 失败路径安全：AI 服务挂了、超时了、返回乱码，都不能影响原业务的正常完成。
• 可灰度可回滚：通过开关和配置决定什么请求会调用 AI，出问题一键关掉。
• 收益可量化：改造后必须对应到一个业务指标，比如审批效率提升、客服转人工率下降、录入错误率降低。

如果一个方案满足不了以上四点，不管技术多花哨，都不算一个合格的"低成本方案"。

1.3 真正的最小闭环长什么样

低成本改造的最小组件其实是一个"建议器"：老系统把业务数据发给 AI，AI 返回一个建议或结构化结果，老系统把它展示给操作人员，由人来决定是否采纳。这个模式叫"人机协同建议模式"，它的特点是天然不追求全自动，避开了大模型可靠性的死穴。

比如客服工单系统，老逻辑是把工单按关键词分优先级。旁路加上 AI 后，系统自动读取工单标题和描述，生成三行摘要和分类建议，客服点一下"采纳"就回填到表单，不点也不影响原流程。整个过程老表的字段没有变化，只是在界面上多了一个"AI 建议卡"。

这样一个闭环最快多久能跑通？我实际操作过，从零到上线，大概三天到一周。后面我会详细拆解每一步具体怎么做。

2. Java生态里的四个低成本抓手：不改主流程也能接入大模型

Java 生态做 AI 集成，不需要一上来就上深度学习框架，更不需要会写 Python。老系统只要是 Java 技术栈，下面这四个抓手就够用了，它们全部是旁路思路。

2.1 接口抽象加策略模式：给 AI 供应商留一个"插座"

无论你最终接什么模型，代码里都应该先定义一套自己的接口，而不是直接绑定某个 SDK。这样做的原因很现实：大模型供应商的 API 变化速度快，价格策略变化也快，今天用这家，明天可能就要换那家；而且老系统往往有私有化部署需求，你可能需要同时兼容在线 API 和本地小模型。

接口设计上，只需要关心业务语义，不要泄漏 HTTP 细节。这样做的好处是后续换供应商、加本地模型、接内部模型平台，都只是新增一个实现类的事。业务方完全无感知。

2.2 JDK HttpClient 加线程池：用最简单的组件异步调用

很多老项目还在用RestTemplate或OkHttp做外部请求，但对于高并发的老系统改造来说，调用大模型 API 有一个特殊之处：外部接口延迟很高，动辄几秒，如果像普通接口一样同步调用，会把线程池打满。最佳实践是异步调用。

JDK 11 之后自带的java.net.http.HttpClient配合CompletableFuture已经足够好用，不需要额外引入重量级 HTTP 框架。如果项目跑在 JDK 17 及以上，还可以用虚拟线程简化并发模型，老系统也能低成本享受到新特性带来的好处。

2.3 定时任务和增量扫描：不碰事务边界的旁路数据通道

老系统性能最怕的就是在事务里做额外操作，比如调用外部 API、做复杂计算。我的做法是把 AI 调用全部搬到事务外面。常见姿势是在业务表上增加一个ai_status字段，主流程只负责把这条记录的 ID 扔进一个待处理队列或表里，提交事务后由后台定时任务批量扫描处理。

这种方式的好处是彻底解耦。即使 AI 服务挂了，后台任务重试失败，也不会影响用户在前台的下单、审批、查询操作。这本质上是一种"异步补偿"的架构思路，Java 里用@Scheduled加数据库轮询表就能实现，成本非常低。

2.4 本地小模型和向量检索：可选的私有化支线

不是所有场景都需要调用外部大模型。涉密数据、内部文档、离线环境，往往要求模型本地部署。Java 生态里可以借助一些本地推理能力实现，比如基于 GGUF 格式的精简模型，配合 Java 的 JNI 绑定或 HTTP 微服务来调用。再配合一个简单的向量索引类库，可以支撑小规模知识库问答。

这一条支线不是必须的，但它给了老系统一个非常重要的选项：当网闸隔离、数据合规要求变严时，系统不至于完全依赖外网 API。

3. 落地架构拆解：一个旁路式AI增强模块怎么设计

3.1 模块划分：新增一个 ai-advisor 子模块

我不会把 AI 代码直接塞进老业务模块。哪怕老系统是个单机 WAR 包，我也会先在工程里新建一个独立的ai-advisor模块，或者至少一个独立的ai包。这个模块自己做三件事：调用外部模型、解析返回结果、落库待处理任务。老业务模块只依赖这个模块暴露的少量接口。

如果老系统是 Maven 多模块结构，就在父工程下加一个子模块。如果是传统单工程，就在包路径上做物理隔离。原则一样：AI 相关的依赖，比如 HTTP 客户端、JSON 解析、延迟队列，绝不污染老业务模块的依赖树。

模块建好后，对外只暴露一个门面类，我习惯把它命名为AiAdvisorGateway，提供几个语义明确的方法。业务方只关心"帮我生成摘要"或者"帮我打点标签"，完全不接触具体模型和提示词。

3.2 门面接口的代码细节

给你看一下我实际用的接口形态：

public interface AiAdvisorGateway { /** * 生成业务摘要建议 */ AdviceResult suggestSummary(BusinessContext context); /** * 生成分类/打标建议 */ AdviceResult suggestCategory(String content, List<String> candidateCategories); /** * 从文档内容提取结构化字段 */ <T> T extractFields(String content, Class<T> targetType); /** * 判断当前请求是否应该触发AI调用（灰度开关） */ boolean shouldInvoke(AdviceTrigger trigger); }

BusinessContext是一个轻量上下文对象，里面只放数据摘要、业务类型、调用场景枚举，不直接引用老系统的实体类。这样做的目的，一方面是防止老系统实体序列化后过大，浪费 token；另一方面是防止老系统字段变更时连带影响 AI 模块。

AdviceResult是我定义的一个通用返回：

public class AdviceResult { private String summary; // 给用户看的摘要文本 private String structuredJson; // 结构化结果，可以转成对象 private double confidence; // 置信度0~1 private String suggestionId; // 本次调用的追踪ID private boolean acceptedOnly; // 是否仅建议，不自动执行 }

所有字段都设计为"软类型"，老系统拿到后只做展示或人工确认，不做强制类型转换。这套接口在实战中非常耐折腾，因为模型输出千变万化，业务系统必须把它当外部数据看待，不能假设模型永远按格式返回。

3.3 灰度开关与埋点设计

老系统改造最怕的风险就是"一上线就全量接进来，发现效果不对还来不及撤"。所有 AI 调用点都必须支持开关和灰度。

我用得比较顺手的方案是一个简单的配置中心，没有配置中心的老系统就用application.yml加@Value注解：

ai-advisor: enabled: true # 总开关 sample-rate: 20 # 抽样率, 20表示20%的请求触发 whitelist-users: 1001,2002,3003 # 白名单用户 timeout-ms: 5000

执行调用前，用这样一个方法判断：

public boolean shouldInvoke(AdviceTrigger trigger) { if (!settings.isEnabled()) return false; if (settings.getWhitelistUsers().contains(trigger.getUserId())) return true; return ThreadLocalRandom.current().nextInt(100) < settings.getSampleRate(); }

在实际项目中，我建议灰度路径分三步走：第一步只开放给内测用户；第二步开放真实业务量的 10%；第三步全量。每步持续观察一个指标：AI 建议的采纳率。采纳率低于 30% 就停止放量，先调提示词和场景设计。

埋点方面，老系统往往没有监控体系，最简单粗暴的做法是在AiAdvisorGateway内部打日志文件，记录每次调用的耗时、token 消耗、返回结果、是否被采纳。这些数据攒下来，足够你判断一个场景能不能值得继续投入。

4. 外部大模型API的工程化细节：重试、限流与兜底

4.1 为什么必须自己处理超时和重试

商用大模型 API 的稳定性远达不到企业级接口的标准。高峰期延迟从一秒飙到十几秒非常常见，偶发 5xx 错误也是常态。如果你用默认的 HTTP 客户端直接调，可能出现三种灾难：用户请求长期挂起、线程池被打满、异常直接抛进老业务代码导致用户看到报错。

我的默认配置是：连接超时 2 秒，读取超时 8 秒，总超时 10 秒，重试一次，重试间隔 200 毫秒。超过总超时立即降级返回一个"AI服务暂不可用"的提示。在这种配置下，AI 服务的短暂抖动对用户的感知就是界面上少了一块建议内容，而不是系统报错。

实现上，我用HttpClient.Builder构建实例，再用CompletableFuture做超时控制：

HttpClient client = HttpClient.newBuilder() .connectTimeout(Duration.ofSeconds(2)) .build(); CompletableFuture<HttpResponse<String>> future = CompletableFuture .supplyAsync(() -> sendRequest(client, request)) .completeOnTimeout(null, 10, TimeUnit.SECONDS); HttpResponse<String> resp = future.join(); if (resp == null) { return AdviceResult.degraded("AI服务超时，跳过本次建议"); }

这里还有个小坑：completeOnTimeout返回 null 后，join()拿到的就是 null，所以返回类型用HttpResponse<String>，不要用 Optional。这是我在写代码时踩过的细节。

4.2 限流队列：保护老系统和外部 API 两头

很多老系统的用户量其实不大，但某些批量场景会在短时间产生大量 AI 请求，比如后台定时扫描历史工单。如果不做限流，外部 API 会报 429，老系统的数据库也会被批量更新拖慢。

我最常用的限流器是 Guava 的RateLimiter或者 JDK 自带工具类手动实现一个令牌桶。但注意：限流不要放在调用链路上做同步阻塞。正确的做法是，所有 AI 任务先进一个阻塞队列，由独立的一个或几个消费者线程按固定速率处理。

我实现过一个简化版流程：

BlockingQueue<AiTask> taskQueue = new LinkedBlockingQueue<>(1000); // 生产者：业务线程把任务丢进队列 if (!taskQueue.offer(task)) { log.warn("AI queue is full, task dropped"); return AdviceResult.degraded("AI队列已满"); } // 消费者：固定线程池, 每任务间隔50ms, 相当于每秒20次 Executors.newScheduledThreadPool(1).scheduleWithFixedDelay(() -> { AiTask task = taskQueue.poll(); if (task != null) { executor.submit(() -> processTask(task)); } }, 0, 50, TimeUnit.MILLISECONDS);

offer失败直接丢弃任务，配合一个超时重试机制，保证 AI 服务过载时系统能优雅降级，而不是把业务线程拖死。

4.3 缓存与幂等：同一段文本别调用两次大模型

大模型 API 按 token 计费，而且老系统里同一段内容经常被多次展示。比如工单列表页和详情页都可能触发摘要，如果两端都调用，一次工单处理就烧两次钱。我在设计时会引入两个层次的缓存。

第一层是结果缓存，以内容 hash 加场景为 key。使用 Caffeine 做本地缓存，过期时间设 24 小时。第二层是幂等控制：如果一条业务记录已经生成了 AI 建议且未被采纳，后台任务重复扫描时直接跳过，不再调用外部 API。

缓存需要注意的一点是，模型输出有时会受提示词微小变化影响，所以 key 里除了文本内容，还要带上提示词模板的版本号。提示词一旦升级，旧缓存自动失效。

4.4 让大模型稳定输出 JSON：解析与校验缺一不可

老系统做结构化提取时，比如让 AI 从合同文本里抽出"甲方名称、金额、有效期"，关键不是提示词写得多好，而是你如何处理模型的"幻觉式格式化"。大模型偶尔会不按约定返回 JSON，甚至在一个 JSON 里混进额外文字。

我的做法分成三步。第一步，在提示词里要求只输出 JSON，并且用代码块包裹；第二步，解析时先剥离代码块标记，再找最外层 JSON 边界；第三步，用 Jackson 把字符串转成目标类型，失败就抛错走降级，绝不把原始字符串直接给前端。

以下代码专门处理带代码块的返回：

public static <T> T parseModelJson(String modelOutput, Class<T> type) throws JsonProcessingException { String json = modelOutput.trim(); // 去掉 ```json ... ``` 包裹 if (json.startsWith("```")) { json = json.substring(json.indexOf('\n') + 1); json = json.substring(0, json.lastIndexOf("```")); } // 只取第一个 { 到最后一个 } 的范围 int start = json.indexOf('{'); int end = json.lastIndexOf('}'); if (start >= 0 && end > start) { json = json.substring(start, end + 1); } return objectMapper.readValue(json, type); }

这一步是老系统改造里最容易省掉，也最容易翻车的环节。

4.5 成本记账：每个功能模块花了多少钱

AI 改造上线后，业务方第一个问的往往是"这玩意一个月要烧多少钱"。如果你没有记账系统，这个问题根本答不上来。我的建议是在门面层统一记录 token 消耗和调用次数，按业务场景维度聚合。

最轻量的做法是加一个ai_usage_log表，字段包括：业务场景、调用时间、模型名、输入 token 数、输出 token 数、耗时、是否命中缓存。后台写一个统计 SQL，按月按场景做汇总。有了这张表，你还可以反向定位哪个场景调用量异常，及时调整灰度比例。

5. 知识库与文档问答的落地姿势：解析、切片与检索

5.1 文档解析链路：被低估的脏活累活

如果你的老系统里有大量合同、制度、说明书需要做问答，真正的核心工作量在文档解析，而不是向量化。Java 生态解析 PDF、Word、Excel 的方案很成熟，常见的有 PDFBox、POI 等。但每类文件都有自己的坑：PDF 有扫描件和文本件之分，Word 有老版.doc和新版.docx之分，Excel 有合并单元格和换行符问题。

我的处理链路是：文件上传 → 格式识别 → 内容抽取 → 清洗 → 按标题层级切块 → 向量化 → 入库。清洗这一步最关键，要去掉页眉页脚、水印文字、连续空行、奇怪的 Unicode 字符。如果文档是扫描件，还要接 OCR 能力，这一步成本高、准确率影响大，能不做就先不做。

以合同为例，解析后我会保存两个版本：一个是"规范文本"用于检索，一个是"原始段落"用于展示引用来源。宁可多存一份数据，也不能丢失溯源能力。

5.2 切片策略：别按固定长度硬切

很多教程教你按每 500 个字切一段，不分内容类型，这是偷懒的写法。合同、制度文件一旦按固定长度硬切，极容易把"违约条款"和"免责条款"的上下文切断，检索时召回的内容就是残缺的，AI 回答自然跑偏。

我常用的切法是这样的：优先按文档里的标题层级切块，比如一级标题是"第三章 售后责任"，二级标题是"3.1 退换货政策"，那么一个切片就是"3.1 退换货政策"对应的完整段落。如果段落太长超过模型上下文限制，再按句子边界二次切分，并让相邻切片保留少量重叠，比如 50 到 100 字的上下文。

切完块后，每个块要存三样元数据：来源文件 ID、文档标题路径、页码或章节号。检索命中的答案，必须能追溯到原文出处，否则业务方不敢信这个答案。

5.3 向量化与相似度检索的 Java 实现

如果内部文档量不大，比如几千个切片，用 Java 在本地做向量检索完全可行，不需要引入分布式向量数据库。我采用的是嵌入模型把文本变成向量数组，然后通过余弦相似度做暴力检索，几千条数据毫秒级就能出结果，性能完全够用。

核心代码思想如下：

double[] queryVector = embeddingModel.embed(query); List<ScoredDoc> results = new ArrayList<>(); for (DocChunk chunk : allChunks) { double score = cosineSimilarity(queryVector, chunk.getVector()); results.add(new ScoredDoc(chunk, score)); } results.sort((a, b) -> Double.compare(b.getScore(), a.getScore())); // 取topK并过滤低于阈值的

cosineSimilarity的实现就是标准的点积除以模长。如果文档量增长到几万条以上，可以换用基于 HNSW 的库，或者把向量归一化后存到支持向量索引的数据库。这些替代方案在中小规模下可以先不碰。

5.4 把检索结果拼进提示词：万能三段式

知识库问答的提示词，我提炼了一个三段式模板：角色限定、检索内容、回答要求。

• 角色限定：比如"你是一个合同审阅助手，只依据提供的资料回答，不编造内容"。
• 检索内容：把 TopK 命中的切片拼进提示词，用检索结果:\n...分隔。
• 回答要求："如果检索内容不足，回答'资料中未找到，请补充资料'；不要总结检索内容之外的结论"。

这段提示词看似简单，但能有效压制大模型最常见的幻觉。另外，检索的 TopK 一般取 3 到 5 个切片，超过 5 个提示词太长，浪费 token，回答质量反而下降。

6. 典型改造案例：老审批系统如何快速加上AI摘要风险提示

6.1 案例背景与目标

某后台审批系统是典型的 Java Web 老应用，核心逻辑是：审批人打开一个待审批单据，查看表单和附件内容，然后做出同意或驳回的决策。单据内容很杂，有采购申请、费用报销、合同付款三种类型。审批人普遍抱怨：单子内容多，经常漏看关键信息；归属类型选错，流程走到了错误节点。

我们定下的 AI 改造目标有三个：给每张单据生成一段摘要，提示关键风险点；根据单据内容推荐最可能的审批类型；所有建议都只是"展示给审批人"，不自动填表，不自动流转。

6.2 改动清单：到底动了哪些代码

这是这类改造项目最有说服力的一张表。整个项目最后就改了以下五个点：

审批主流程的 Service、DAO、事务配置一行都没动。这就是旁路式改造的核心价值：哪怕出问题，临时把 ai-advisor 模块禁用，系统立即恢复原样。

6.3 核心调用链路的代码示意

单据提交时，老业务照常执行原来的事务逻辑，只在事务提交后发送一个事件：

@Transactional public void submitOrder(Order order) { orderMapper.insert(order); // 原有业务逻辑... } // 事务提交后的旁路事件投递 public void submitOrderWithAi(Order order) { submitOrder(order); if (aiAdvisorGateway.shouldInvoke(AdviceTrigger.ORDER_SUBMIT)) { aiTaskQueue.offer(new AiTask(order.getId(), ADVISE_TYPE_ORDER_REVIEW)); } }

定时任务里拿到待处理的单据 ID，组装上下文，调用门面接口。这里有一个关键点：组装上下文时只取必要字段，比如单据金额、供应商名称、物料清单、历史同类单的驳回原因，这些字段的序列化大小要控制住。整段上下文最好控制在两千字以内，这样单次调用成本可控，延迟也在 3 秒上下。

返回结果解析后，插入一张ai_advice表，记录摘要、风险点、推荐审批类型、置信度。审批人打开详情页，前端从新接口读取这张表，在页面右侧展示。

展示效果大致是这样：摘要文本下有四个风险标签，比如"金额超预算""供应商未在名录""合同未盖章"；推荐审批类型默认不选中，审批人自己点选，如果 AI 推荐对了，他才会点一次"采纳"。这个采纳数据，正好用来做后续的效果评估。

6.4 置信度阈值与人工兜底逻辑

AI 建议不是全量展示的。我们设了一套规则：综合置信度低于 0.6 时，页面不展示 AI 建议区域，只在前端埋点记录"已跳过"。置信度来自两部分：模型返回的置信度字段，以及规则引擎的硬校验，比如单据金额超过某个阈值直接提升风险等级。

人工兜底逻辑一定要简单粗暴：AI 建议永远不覆盖用户已填写的内容；用户点击"采纳"时才填充字段；任何时候用户都可以一键隐藏 AI 建议区域。产品层面叫"AI 只提意见，人来做决定"。

这套改造整体花了四天半：两天做接口和后台任务，一天做提示词调优，一天做前端展示和埋点，半天联调。业务方对结果的评价是"有点像样的 AI 功能了"——这个评价在传统团队已经算不错了。

6.5 上线后的效果观察与迭代

灰度一周后，我们拉取埋点数据：AI 建议展示率 72%，摘要打开率 100%（因为就在页面上），风险标签采纳率 41%，审批类型推荐准确率 63%。准确率不算惊艳，但审批人反馈"至少能帮我快速抓住单子的重点"，这意味着价值已经成立了。

后续迭代我做了两件事。一是每月收集 badcase，看哪些单子 AI 总是判断错，针对性地补充提示词里的业务规则说明。二是在 AI 建议旁边加了一个"为什么"按钮，点开能看到命中的检索片段或者关键字段，这在很大程度上提升了业务方对 AI 的信任度。

7. 改造过程中的坑与我的处理经验

7.1 数据脱敏：别把敏感字段直接发给模型

这是整个改造里最不能妥协的一条红线。老系统里经常有手机号、身份证号、银行账号，直接拼进提示词发给大模型 API 是不合规的。我的处理规则是：上下文组装时执行脱敏策略，手机号中间四位打码，身份证号只保留前后各两位，银行账号只保留后四位。如果某些字段在业务上必须用于 AI 判断，那就改成"脱敏后的特征值"，比如隐藏姓名，只保留"是否为本司员工"布尔值。

另一个容易被忽略的点是日志。调用外部模型的请求体千万不要原样打印到日志文件里，否则脱敏就没有意义了。

7.2 中文编码与扫描件 OCR 的现实问题

老系统里的文档大多是中文文本，解析时最容易遇到编码问题。PDF 提取出来是乱码的，多半是因为文本流用了自定义编码映射，这时需要额外处理字体编码。Word 文档要考虑段落内嵌图片，文字可能被切割在多个 text run 里，提取时要注意拼接。

扫描件 OCR 的成本容易偏离预期。一套 OCR 服务的授权费用、GPU 资源和识别准确率，可能在项目后期成为最大的隐性成本。我的建议是：启动阶段不要接 OCR，先把已有的文本类文档跑通，产出价值后再评估是否值得补上扫描件管道。别让脏活累活拖死整个项目。

7.3 模型幻觉的兜底机制

老系统 AI 改造一定会碰到幻觉问题。摘要可能漏了关键金额，分类建议可能张冠李戴，提取的合同日期甚至可能是完全不存在的"2025年2月30日"。我的兜底机制分成三个层次：

第一，字段级别的规则校验。比如提取出的日期必须能通过日期解析，金额必须是正数，枚举字段必须落在候选集合里。校验不过就标记为低置信度，不展示。第二，引用来源展示。凡是知识库问答，答案必须带上原文切片引用。第三，人为确认。任何 AI 生成的内容都不能直接写入业务核心字段，必须经过人工点击确认。

7.4 一个长期视角的提醒

我最后想分享的经验是：AI 改造在传统 Java 老系统里，永远不要追求一步到位。第一版能跑通一个场景就是巨大胜利。后续扩展时，你可以把同一套AiAdvisorGateway门面复用到其他模块，比如客服知识库、质检报告生成、报表解读，每一次复用的边际成本都远低于第一次搭建。

另外，保持对提示词的版本管理，时刻记录哪个版本的提示词对哪个场景产生了什么效果。这些沉淀下来的资产，比模型本身更值钱。老系统不会消失，但它会以另一种方式变得更有智能，这大概就是传统系统改造最让人上瘾的地方。