AI进入旧城，为什么这么难——从《置身钉内》看AI落地的真实困境

Fri, 12 Jun 2026 09:00:00 +0800

一座看不见的城

我们谈论AI的时候，总在谈论一个很轻盈的词——“智能”。仿佛只要模型够强，数据够多，算力够大，一切旧世界的问题就会自动消解。

但如果把镜头从实验室拉回到企业、拉回到真实的产品线、拉回到那些已经运转了十年甚至二十年的系统旁边，你会发现一件事：AI不是降临在一片空旷的新大陆上，它要穿过旧城。

旧城有旧城的规矩。街道是十年前规划的，下水道是五年前补的，电线杆上还挂着二十年前的广告。你不可能把一座新城一夜之间盖在旧城上面——你必须理解它、尊重它、然后一点一点地改造它。

读《置身钉内》这本书的时候，我对这种"旧城"的隐喻有了更深的体会。钉钉作为一个服务了数亿用户、承载了无数企业工作流的成熟产品，在引入AI能力时面临的困境，其实是整个AI落地浪潮的缩影。

Demo很酷，但Demo不是产品

每一个做AI产品的人都经历过这样的时刻：在内部演示的时候，效果惊艳，掌声雷动，大家觉得未来已经来了。然后产品上线，用户开始用，反馈如潮水般涌来——不是赞叹，是困惑。

“为什么它不理解我的上下文？” “为什么它在我最需要精确的时候开始胡说？” “为什么它和我已经在用的工具完全不兼容？”

这不是模型的问题，这是系统的问题。

一个成熟的toB产品，背后可能有数百个微服务，数千个API接口，数十个数据库，以及——最关键的——无数条业务规则。这些规则有些写在代码里，有些写在文档里，有些只存在于某个老员工的脑子里。AI要在这个系统里发挥作用，它必须理解这些规则，遵循这些规则，甚至在某些情况下，优雅地绕过这些规则。

而Demo不需要做这些。Demo只需要展示一个精心挑选的场景，在这个场景里，一切恰好工作。

技术债：旧城的地基

在软件工程里有一个概念叫 Technical Debt，技术债。它指的是为了快速交付而做出的妥协——那些"以后再说"的重构、那些硬编码的配置、那些临时方案变成永久方案的历史遗留。

任何一个运转了五年以上的系统，都有沉重的技术债。这些债务不像金融债务那样有一个明确的数字挂在墙上，它们隐藏在各个角落：

一个核心模块的维护者已经离职三年，没人敢动那部分代码
两个系统之间的数据同步靠一个每天凌晨三点运行的 cron job
某个关键功能的逻辑分散在五个不同的服务里，没有任何文档描述它们之间的关系
数据库的 schema 经历过三次大迁移，有些表名还是最初设计时的命名，但含义已经完全变了

AI要进入这样的系统，它面对的不是一张白纸，而是一幅已经画了无数笔的画布。你不能简单地把AI"接入"系统，就像你不能在一栋已经建好的楼里随意加一层——你得先搞清楚承重墙在哪里，管道在哪里，地基能承受多少。

接口层的问题

AI通常通过API与现有系统交互。但旧系统的API往往是这样的：

1
2
3


GET /api/v1/users/{id}
GET /api/v2/users/{id}
GET /api/internal/users/{id}

三个接口，返回三个不同版本的数据结构，各有各的字段、各有各的边界条件。哪个是"正确的"？答案是：取决于你问谁，取决于你在什么场景下使用。

AI要理解这种复杂性，需要的不仅是 NLP 能力，还需要对整个系统架构的深度理解。而这种理解，目前的AI还远远做不到自动化获取。

数据层的问题

数据是AI的燃料，但旧系统里的数据往往是一片沼泽。格式不统一，编码不一致，有些字段是空的，有些字段的含义在不同时期发生了变化。更麻烦的是，数据之间存在着隐式的关联——这些关联没有被任何 foreign key 或文档记录，它们只存在于业务逻辑中。

当你试图用这些数据来训练或 fine-tune 一个模型时，你会发现模型的输出质量远不如预期。不是因为模型不够好，而是因为喂给它的数据本身就是一个混乱的世界的投影。

组织惯性：比技术债更重的墙

如果说技术债是旧城的物理结构，那么组织惯性就是旧城的文化结构——那些不成文的规矩、那些"我们一直这么做的"的流程、那些部门之间的微妙关系。

AI落地最难的部分往往不是技术，而是组织。

决策链的阻力

在一个成熟的组织里，引入AI意味着改变工作流程。而改变工作流程意味着有人需要学新东西，有人需要放弃旧习惯，有些人的权力结构会发生变化。

一个中层管理者可能会说：“这个AI工具确实好用，但我们团队已经习惯了现在的流程，切换成本太高了。“这句话表面上是在谈效率，实际上可能是在说：“如果AI能自动完成我团队里三个人的工作，那我管理的意义是什么？”

这种阻力不是恶意的，它是人性的自然反应。但在AI落地的过程中，这种阻力往往比任何技术难题都更难以克服。

部门墙的阻碍

AI要发挥最大价值，通常需要跨部门的数据和流程整合。但在大多数组织里，部门之间的数据是割裂的，流程是不互通的，甚至连基本的沟通都充满了摩擦。

想象一下：AI想做一件很简单的事——自动把销售团队的客户反馈整理成产品需求文档。这需要访问销售部门的CRM系统、产品部门的需求管理工具、以及设计部门的原型工具。但CRM的权限在销售总监手里，需求管理工具的权限在产品VP手里，原型工具的权限在设计负责人手里。要让AI同时访问这三个系统，你需要三个人的审批，而这三个人之间可能本身就有矛盾。

这不是AI能解决的问题，这是组织治理的问题。

钉钉的困境：大象跳舞

《置身钉内》记录了一个非常有意思的现象：钉钉作为一个已经非常成熟的协作平台，在引入AI能力时面临的挑战，远比从零开始做一个AI产品要大得多。

为什么？因为钉钉不是一个白板，它是一座已经住了几亿人的城市。

用户习惯的惯性

钉钉的用户——尤其是企业用户——已经形成了一套根深蒂固的使用习惯。他们知道在哪里打卡、在哪里审批、在哪里开会、在哪里看通知。任何对这些习惯的改变，都会引发巨大的反馈。

当AI试图改变用户的工作流时——比如用AI自动生成会议纪要、自动分类消息、自动推荐待办——它实际上是在挑战用户已经建立了几年的肌肉记忆。即使AI做得比人好，用户也需要一个适应期。而在toB场景下，这个适应期的成本是由整个组织承担的。

功能复杂度的指数增长

钉钉本身已经有数百个功能模块。每加入一个AI功能，不是简单地"加一个按钮”，而是要和现有的所有功能产生关联。AI生成的会议纪要需要关联到日程、关联到参会人、关联到项目空间、关联到待办列表。每一个关联都意味着一组新的接口、一套新的逻辑、一轮新的测试。

这就是所谓的 Feature Interaction Complexity——功能交互复杂度。当一个系统的功能数量从N增加到N+1时，潜在的交互关系从 N² 增加到 (N+1)²。这意味着每增加一个功能，系统复杂度的增量是在加速增长的。

向后兼容的诅咒

作为一个服务了数亿用户的平台，钉钉有一个不可打破的铁律：向后兼容。任何新功能都不能破坏现有用户的使用体验，不能让已有的API失效，不能改变已有数据的含义。

这意味着AI功能必须以"增量"的方式加入，而不是"重构”。你不能说"我们重新设计一下消息系统，让它更适合AI处理"——因为那意味着几亿用户的消息记录需要迁移，几千个第三方应用需要适配。

这种向后兼容的要求，就像在一座运转中的城市里修地铁——你不能封路，不能停水停电，不能让居民搬走。你只能在所有人都照常生活的情况下，一寸一寸地推进工程。

理想与现实的差距

AI行业有一个普遍的乐观情绪：模型能力每几个月就翻一倍，按照这个速度，再过两三年，所有问题都会迎刃而解。

但这种乐观忽略了一个关键事实：模型能力的增长是指数级的，但系统改造的速度是线性的，甚至是对数级的。

模型可以越来越强，但旧系统的改造速度受限于：

人力资源（能理解旧系统的人就那么多）
组织能力（跨部门协调需要时间）
风险控制（不能为了快而出事故）
合规要求（数据隐私、行业监管）

这意味着，即使AI模型在三年内变得无所不能，它在旧系统中的落地仍然需要五年、十年甚至更久。

“最后一公里"的悖论

AI落地的"最后一公里"往往是最难的。前面90%的工作可能只需要30%的精力（训练模型、搭建基础设施、做出Demo），但最后10%的工作——让AI在真实场景中稳定、可靠、无缝地工作——可能需要70%的精力。

这就像自动驾驶。在高速公路上自动驾驶已经做得很好了，但在老旧小区的窄巷里、在没有标线的乡间道路上、在暴雨天的积水路段上，自动驾驶还有很长的路要走。而那些"最后一公里"的场景，恰恰是用户最需要AI的地方。

被忽视的隐性成本

AI落地的困难不仅体现在技术层面和组织层面，还体现在一些容易被忽视的隐性成本上。这些成本在项目启动时往往不可见，但随着项目的推进，它们会像滚雪球一样越滚越大。

数据标注和清洗的无底洞

AI需要高质量的数据才能工作。但在旧系统中，数据的质量往往参差不齐。当你试图为AI准备训练数据或 fine-tuning 数据时，你会发现大量的时间花在了数据清洗上——修正格式不一致、填补缺失值、处理异常数据、统一编码标准。

这些工作看起来是"一次性的”，但实际上它们是持续性的。旧系统中的数据每天都在产生，每天都在变化，每天都在积累新的"脏数据"。你需要一个持续的数据治理流程，而这个流程本身就是一个独立的项目。

测试和验证的复杂性

AI的输出是概率性的，而不是确定性的。这意味着传统的软件测试方法——给定输入，验证输出——在AI场景下不再完全适用。你需要新的测试策略：统计性测试、A/B测试、人工抽检、对抗性测试……每一种策略都有它的成本。

更麻烦的是，AI在旧系统中的行为可能受到系统状态的影响。同一个请求，在系统负载高和负载低的时候，可能得到不同的结果。在数据更新前和数据更新后，可能得到不同的结果。这种不确定性让测试变得极其复杂。

运维和监控的新挑战

传统的系统运维已经有成熟的工具和方法论。但AI系统引入了一些全新的运维挑战：

模型漂移：随着时间推移，模型的准确率可能会下降，因为现实世界的数据分布在变化
推理延迟：AI推理需要额外的计算资源，可能影响系统的整体响应时间
成本控制：AI推理的成本与调用量直接相关，在流量高峰期可能产生巨额费用
故障定位：当系统出错时，你需要判断是AI的问题还是旧系统的问题，这往往需要两套完全不同的排查思路

这些隐性成本在项目规划时往往被低估。项目计划书上的预算和时间表，很少能准确反映这些持续性的投入。

从AI视角看旧城

前面我们从旧系统的视角看了AI落地的困难。现在让我们换一个视角——从AI的角度来看旧城。

AI的能力边界

当前最先进的AI模型——无论是大语言模型还是多模态模型——都有明确的能力边界：

理解上下文有限：虽然有几十万 token 的上下文窗口，但真正有效的注意力范围远小于此
缺乏持续记忆：每次对话都是独立的，除非额外构建记忆系统
幻觉问题：会生成看起来正确但实际上错误的信息
推理深度有限：擅长模式匹配，但在需要深度逻辑推理的场景下仍然薄弱

这些能力边界意味着，AI不是万能的。它需要在合适的场景下使用，需要有人来兜底它可能犯的错误。在旧系统中，这种"兜底"机制往往不存在——因为旧系统是为确定性逻辑设计的，不是为概率性输出设计的。

AI需要的"接口"

AI要在旧系统中发挥作用，它需要一组清晰的"接口"——不仅是技术层面的API接口，还包括：

语义接口：系统的业务概念是什么？每个术语的含义是什么？
约束接口：哪些操作是合法的？哪些操作之间有依赖关系？
反馈接口：AI的输出是否正确？谁来评判？评判的标准是什么？
权限接口：AI可以做什么？不可以做什么？越权了怎么办？

在新系统中，这些接口可以在设计时就定义清楚。但在旧系统中，这些接口是隐式的、分散的、不完整的。要把它们显式化，需要大量的知识梳理和工程工作。

一种可能的出路

说了这么多困难，并不是要得出"AI落地不可能"的悲观结论。恰恰相反，正是因为看清了困难的本质，我们才能找到更务实的路径。

渐进式改造

与其试图一次性"AI化"整个系统，不如从最痛的点切入，一个一个场景地攻克。每解决一个场景，就积累一份对旧系统的理解，就降低下一个场景的改造难度。

这种方法的缺点是慢，但它的优点是稳。在toB场景下，稳比快更重要——因为一个出错的AI比没有AI更可怕。

建设"AI中间层"

与其让AI直接对接旧系统的每一个接口，不如在中间建一个抽象层。这个抽象层负责把旧系统的复杂性封装起来，对AI暴露一组简洁、一致、语义明确的接口。

这就像在旧城上面建一座高架桥——不改变旧城的结构，但在旧城之上建立一套新的交通系统。这种方式的好处是可以逐步推进，坏处是需要额外投入来维护这个中间层。

新旧并行

有时候，最聪明的策略不是改造旧城，而是在旧城旁边建一座新城。让新功能在新架构上运行，旧功能继续在旧系统上运行，两者通过桥接的方式互通。

随着时间的推移，越来越多的功能迁移到新城，旧城慢慢变成历史遗迹。这是一种"自然淘汰"的策略，它不追求一步到位，而是让时间成为你的盟友。

退远镜头看风口

回到最初的那个画面：AI站在风口上，但这个风口处在旧城中央。

这个画面提醒我们，技术的突破从来不发生在真空中。每一项新技术都要穿越旧世界的复杂性，都要在理想与现实之间找到自己的位置。

那些真正改变世界的技术——互联网、移动互联网、云计算——都经历过这个阶段。它们不是一夜之间替代了旧世界，而是在旧世界的缝隙中找到了生长的空间，然后一点一点地扩展，直到旧世界的大部分已经被重新定义。

AI也会走这条路。只是这条路比我们在Demo里看到的要长得多、弯得多、泥泞得多。

而理解这一点，恰恰是做好AI落地的第一步。

AI落地 on 文艺技术笔记