（旧版全文）告别预设逻辑：从12306未来畅想看万千应用程序的颠覆性重塑与数据就绪觉醒

梁敬彬

438人浏览 · 2026-01-24 19:11:26

梁敬彬 · 2026-01-24 19:11:26 发布

梁敬彬梁敬弘兄弟出品

应用程序大模型化之路——从12306未来畅想看预设模式颠覆与AI就绪的数据觉醒（原文链接）

从阿里云PolarDB开发者大会的现场回来，我的心情久久不能平静。站在台下，听着阿里数据库掌舵人李飞飞激情澎湃的演讲，我脑海里那盏关于未来软件架构的灯，突然被点亮了。

李飞飞在台上并没有大谈特谈那些玄之又玄的未来主义概念，而是非常务实、甚至有些犀利地抛出了一个观点：我们始终强调的是AI就绪（AI Ready），而不是AI原生（AI Native）。

最击中我天灵盖的一句话是：当前主流大模型，本质上只吃冷数据和温数据。真正有业务价值的，是热数据，但它们进不了模型。

在这里插入图片描述

这句话就像一把手术刀，精准地剖开了当前AI落地最大的痛点，也让我瞬间回想起了我过去死磕12306架构的心路历程。

熟悉我的读者都知道，我对12306有着一种近乎偏执的关注。从《⓵悟！从12306改签困惑到数据库设计》里探讨改签逻辑的死结，到《⓶惊！12306业务系统升级也能被普通人推动？》里为普通用户的发声，再到《⓷妙！探索12306车内换座的最优分配法》里用算法寻找最优解。我一直在思考：为什么我们的国民级应用，哪怕做到了极致的并发，依然让人觉得不够懂我？

今天，站在2026年的路口，结合PolarDB大会给我的启发，我想脱离具体的代码细节，为大家复盘并预演一场应用程序从预设到觉醒的五阶段颠覆性进化。

这不仅关乎技术，更关乎我们每一个人的生活，关乎未来十年的行业格局。如果你是程序员、DBA、产品经理，或者是像我妈妈一样对手机操作感到头疼的普通用户，这篇文章，都是写给你的。

在这里插入图片描述

1. 规则筑高墙，众生困笼中

——第一阶段：确定性逻辑的预设时代

我们先来回望一下，我们目前绝大多数人所处的阶段。我称之为预设时代。

在这个阶段，软件开发的底层逻辑是确定性。程序员就像是一个翻译官，把产品经理的需求翻译成计算机能听懂的 if-else、when-then、for-loop。

以12306为例，当你打开APP时，你看到的每一个按钮、每一个输入框，都是程序员预设好的。你想买票？好，系统预设了你必须输入出发地、目的地、时间。你想选座？好，系统预设了你只能选A/B/C/D/F。

但是，真实的生活是非预设的。

我妈妈每次让我帮她买票，她的需求从来不是冷冰冰的G1次二等座，而是充满了生活气息的诉求： “儿子，我要去北京看孙子。别让我起太早，你知道我早上要遛弯；但我也不想太晚到，怕耽误做晚饭。还有，我腿脚不好，别让我买那种离厕所和开水间特别远的位置。最重要的是，上次坐车旁边那个小伙子一直在打电话，吵死我了，这次能不能给我找个安静点的地儿？”

在第一阶段的架构里，面对妈妈的这段话，系统是崩溃的。程序员会摊手说：梁老师，这需求没法做啊！数据库里没有安静这个字段，也没有遛弯时间这个参数。我们只能预设几种通用的筛选条件，用户必须削足适履，把自己变成机器能理解的结构化数据，才能买到票。

这就是第一阶段的悲哀：人被关进了代码编织的笼子里。我们习惯了去适应机器，习惯了在买奶茶时只能选三分糖而不能说我是糖尿病患者。我们把这种适应当成了数字化，殊不知，这只是最原始的电子化填空题。
在这里插入图片描述
这个阶段的应用，本质上是工具。工具是冷的，它不在乎你是谁，它只在乎你按没按对按钮。

2. 助手虽神勇，旧瓶装新酒

——第二阶段：AI辅助编码的提效陷阱

时间来到2024年左右，大模型（LLM）开始爆发。很多企业欢呼雀跃，宣称进入了AI时代。但我认为，这依然停留在预设时代。

在这个阶段，最大的变化发生在开发端。以前写一套车票查询逻辑，我可能需要敲一天代码。现在，有了GitHub Copilot，有了各种AI编程助手，我只需要写一行注释：//生成高铁查询接口，支持按时间排序，AI刷地一下就帮我生成了完美的函数，甚至连单元测试都写好了。
在这里插入图片描述

效率暴增，成本骤降。以前需要10个人的开发小组，现在2个资深架构师带着AI助手就能干完。于是我们看到了大量的裁员，看到了程序员群体的焦虑。

但是，请大家冷静思考一下：对于用户端（比如我妈妈）来说，APP变了吗？完全没有。

界面还是那个界面，按钮还是那个按钮，逻辑还是那个预设的逻辑。 AI在这个阶段，仅仅是帮程序员更快地造出了那个预设的笼子。它并没有打破笼子，只是让造笼子的成本降低了。

这就像是给马车换上了特种橡胶轮胎，马跑得更轻松了，车夫更省力了，但对于乘客来说，它依然是一辆颠簸的马车，而不是汽车。

在这里插入图片描述

很多所谓的AI应用，其实就停留在这一层。他们把AI当成了超级外包，用来降本增效，却忘记了AI真正的价值在于重构体验。如果你只盯着怎么少雇几个程序员，那你永远走不出预设的怪圈。

3. 意图瞬通达，万物皆可连

——第三阶段：交互式智能的破壁时刻

真正的变革，始于第三阶段。这也是我们正在跨越的门槛。在这个阶段，程序终于开始听懂人话了，交互方式从GUI（图形界面）转向了CUI（对话界面+多模态），现在终于摆脱预设时代了。

回到12306的例子。在第三阶段，我妈妈终于不需要我帮忙了。她只需要打开APP，按住语音键，把那段啰嗦的要求说一遍： “给我买张去北京的票，要带小孙子一起，对面最好也是带小朋友的，这样孩子有玩伴。我要靠窗，脚下要有充电口，我还想离餐车近点，方便给孩子热饭，但我腿脚不好，别让我走太远。”

如果是以前的系统，这段话就是噪音。但在第三阶段，APP背后的AI大脑会瞬间运转，将这段非结构化的语言拆解为极其复杂的业务指令：

带小孙子 -> 触发儿童票关联逻辑，锁定连座需求。

对面也是带小朋友的 -> （这是难点！）这是一个极具人性化的非预设需求。系统需要去检索已售出的座位信息，分析旅客画像。

靠窗、有充电口 -> 检索车型数据库，匹配CR400BF等特定车型的插座布局。

离餐车近、少走路 -> 这是一个矛盾需求（通常餐车在中部，进站口在两端）。AI需要计算最优解：选择5号或9号车厢（邻近餐车），同时结合该车站的3D地图，判断电梯口的位置，计算出步行距离最短且离餐车最近的权重。同理，当你走进奶茶店，不再需要勾选少糖/去冰，而是直接说：我是糖尿病患者，给我来一杯秋冬热饮，不要奶精，血糖负担要最低。系统会自动调用营养学知识库，分析配料表，避开植脂末和果糖，推荐一杯使用代糖、纯茶底的温热饮品。这才是非预设。用户不再需要学习系统的规则，而是系统去适应用户的意图（Intent）。
在这里插入图片描述

写到这里，作为一名数据库老兵，我必须给大家泼一盆冷水，或者说，揭示一个更深层的问题： AI怎么知道哪个座位对面是小朋友？AI怎么知道哪个座位底下有充电口？数据源从何而来？

现在的12306数据库里，只有已售/未售的状态，可没有旅客带有3岁儿童这样的标签，更没有座椅插座好坏的实时记录。

这就是第三阶段的核心挑战：数据源的融合与推理。要实现上述场景，应用程序必须打通多渠道数据源：历史行为数据：通过分析对面座位购票人的历史订单，发现该用户经常购买儿童票，推断其为带娃家长。 UGC数据（用户生成内容）：整合社交媒体、论坛、APP内的用户反馈。比如有人吐槽G1次4车5F的充电口坏了，系统要能实时抓取并标记。 IoT数据：未来的列车座椅可能有传感器，实时上报状态。跨场景数据：结合打车软件、地铁数据，像一个全能Agent一样，安排好下高铁-坐地铁-回酒店的无缝衔接。

没有底层数据的打通，AI就是无米之炊。这也就引出了我们接下来要谈的，至关重要的技术支撑。
在这里插入图片描述

4. 热数赋灵光，基石定乾坤

——底层技术支撑：AI就绪数据库的必然性

为什么现在的ChatGPT能聊天，却买不好票？为什么主流电商的AI客服只能车轱辘话，却不能帮我精准下单？

这里就要提到李飞飞总在PolarDB大会上反复强调的那个观点了：当前大模型只吃冷数据和温数据，真正有业务价值的热数据进不了模型。

冷数据：大模型训练时的知识（比如北京是中国的首都、复兴号通常有充电口）。温数据：通过RAG（检索增强生成）挂载的文档（比如12306最新的退票规则）。热数据：此时此刻、每分每秒都在变化的库存、价格、交易状态。

当你问AI：现在G1次有票吗？ AI如果只靠模型，它只能瞎编（幻觉），因为它不知道这一秒钟发生了什么。 AI如果想知道，它必须去查询数据库。

但问题来了：用户的意图是模糊的向量（离厕所近、对面是孩子），而传统数据库是精确的关系型数据（where seat_no = ‘1A’）。让AI大模型直接去查传统数据库，效率极低且容易出错。

此时，类似PolarDB 这样的AI就绪数据库就成为了解决问题的关键。PolarDB在一个内核里，既能处理结构化热数据（高并发的余票库存），又能处理非结构化向量数据（把离厕所近转化为空间向量）。这意味着，AI不需要跨系统查询，直接在数据库内部就能完成意图到数据的匹配。

热数据实时决策：PolarDB本来就是为双11这种高并发场景生的，它能确保AI拿到的数据是毫秒级新鲜的。只有基于热数据，AI的决策（比如给你锁这张票）才是可执行的，而不是一句空话。

模型算子化：把AI的能力下沉到数据库算子层。不是应用去调AI，而是数据库自己就有AI的能力，在查询的过程中就完成了推理。

在这里插入图片描述

所以，我常跟身边的DBA朋友说，不要觉得AI来了数据库就没事干了。恰恰相反，AI越智能，对数据库的要求就越变态。只有当数据库做好了AI就绪，应用才能从聊天机器人进化为业务执行者。这正是PolarDB正在修筑的护城河。

5. 润物细无声，越用越知心

——第四阶段：用户驱动的自进化时代

跨过了数据融合的门槛，我们将迎来更迷人的第四阶段。在这个阶段，程序不再是一个死板的代码块，而是一个有记忆、能成长的有机体。

回到我妈妈的例子。第一次，她费劲地跟手机说了那堆要求（靠窗、近餐车、怕吵……）。系统不仅执行了，还默默记住了。

第二次，当她再说我要去上海时，系统不会再问她要不要靠窗、腿脚好不好。系统会直接调用我妈的偏好模型：检测到用户梁妈妈，偏好安静车厢、强需求充电口、行动不便需近电梯。正在为您匹配G2次列车的中部车厢……

在这里插入图片描述
更神奇的是，这个模型不需要程序员去写代码更新。它是自进化的。如果某一次，系统推荐了5号车厢，但我妈妈没有买，而是手动改成了9号。系统会立刻捕捉到这个负反馈，自动调整权重：原来梁妈妈对离餐车近的权重没那么高，但对离厕所近的权重非常高。

在这里插入图片描述

在第四阶段，每一个用户的APP都是独一无二的。千人千面不再是广告术语，而是功能层面的现实。程序就像一个贴身的老管家，越用越顺手，越用越懂你。这种黏性，将是未来软件最大的壁垒。

6. 伙伴非工具，未雨先绸缪

——第五阶段：全场景的主动智能伙伴

终于，我们来到了推演的终局：第五阶段。在这里，应用程序彻底完成了从工具到伙伴的蜕变。它不再是被动等待指令，而是主动预判需求。

想象一下这样的场景：我接到一个去上海的紧急出差任务，订了机票。不需要我打开12306，也不需要我打开滴滴。我的智能伙伴已经开始在后台疯狂运转（就像一个全能Agent）：

监测：它发现我的航班延误了2小时，落地上海虹桥已经是深夜，赶不上原定的高铁。

决策：它自动帮我退掉了高铁票（免去了改签费），并预订了虹桥机场附近的酒店（因为它知道我太晚不喜欢折腾）。

安排：它帮我预约了落地的专车，并通知了明天早上的客户我的行程变动。

通知：做完这一切，它只是在手机上弹了一条消息：XXX先生，航班延误，已为您调整为明早高铁，今晚入住机场全季，专车已约好。您放心休息。

在这里插入图片描述

这才是终极的觉醒。它打通了航空、铁路、酒店、网约车的数据孤岛；它具备了极其复杂的逻辑推理能力；它像一个真正的、高智商的人类助理一样在思考。这不仅仅是方便，这是对人类注意力的彻底解放。

看到这里，肯定有人会问：“梁老师，费这么大劲把系统搞得这么先进，难道仅仅是为了让人偷懒吗？”如果你这么想，格局未免小了。这不仅仅是为了便利，更是一场关于释放人类“认知盈余”的深刻变革。试想一下，当人类不再需要把宝贵的脑力浪费在选座位、查攻略、对账单，甚至不再需要编写那些重复枯燥的“搬砖代码”时，我们省下来的巨大精力并非消失了，而是汇聚成了攻克真正难题的洪流。

这种脑力的解放，将直接打破学科与创新的壁垒。当交互效率提升到极致，一位物理学家可能不再需要精通复杂的数据库，就能像聊天一样调用生物学模型，量子力学与医学的结合将不再被技术鸿沟阻隔；几万亿级的蓝海市场也将随之诞生，全新的商业模式将在AI基座上百花齐放。正如蒸汽机曾把人类从繁重的体力劳动中解放出来，AI就绪的应用程序旨在将人类从低效的脑力劳动中彻底解放——这，才是科技进步的终极意义。

在这里插入图片描述