一部死去的系统给AI时代的“技术傲慢”上了一课一、 一块来自2006年的琥珀最近我在硬盘深处挖到了一套代码。它不知属于哪家公司但从散落的注释推断曾是某个大型电子代工厂的采购命脉。2006年6月20日一位名叫Ris的程序员在XXX的一台服务器上敲下了第一行20年后这套由Classic ASP VBScript SQL Server拼凑而成的巨兽已经彻底停摆。服务器早已关机域名也已注销。代码安静地躺在硬盘上如同一块封存了时光的琥珀。起初我以为这不过是一堆等待被扔进历史垃圾堆的技术债务。然而当我一行行读完这些陈旧的代码我才意识到我发现的不是什么垃圾而是一座被严重低估的宝藏。它用一种最朴素的方式拷问了当下最时髦的命题AI你真的懂什么是“发生过”吗二、 技术债的表象与历史的真相这套系统有多“老”看一眼便知。它用frameset切割页面用table进行像素级的排版用.swf文件作为Banner动画。它的字符集是早已被淘汰的Big5繁体中文登录页面的HTML里甚至直接预填了测试账号和密码。所有的数据库连接字符串都被硬编码在一个叫conn.asp的文件里就在这个满是“坏味道”的文件里藏着几行不起眼的注释任何一个现代程序员看到这里都会眉头紧锁。我尝试让AI将这个文件重构为一个现代化的配置中心方案。AI不负众望迅速给出了一个漂亮的YAML配置文件配合环境变量和密钥管理服务的完美方案。但AI犯了一个致命的错误它完全忽略了2008/1/1这个日期的意义。在它看来这只是一个需要被抽象化的魔法数字。但在现实中这是一个法律。三、 代码里的“伤痕”是组织命运的切片2008/1/1到底意味着什么我翻阅了项目中散落的文档和SQL文件才拼凑出真相这一天是该公司所在地区某项税法调整的生效日。在此之前下达的订单遵循旧规则在此之后则必须按新法规执行。这个日期不是一个可以被随意替换的配置项而是一条刻在代码里的法律红线。类似的时间锚点在系统中比比皆是它们像化石一样记录着这家企业每一次的“命运转折”2008/12/29一个字段fac_type被加入注释写着“add by tao”。2009/1/10新增supply_url标志着供应商认证体系的引入。2009/7/1又一次信息调整。2010/3/6某个关键的邮件签核脚本被重写旧版本以xxx20100306.asp的形式被刻意保留。每一个日期都是一次组织架构的调整、一次业务流程的变更、一次应对外部环境的应激反应。AI能读懂语法的结构却读不懂语法背后那一刀刀真实的“伤痕”。四、 冗余的代码是组织博弈的“化石”再往深处挖我发现了第二个层次的复杂性——业务的“地质断层”。系统里有一个函数负责将货主代码翻译成中文全称。实现方式极其“原始”十几个elseif一字排开。为什么一个采购系统需要支持十几个法人实体答案藏在现实里在同一片厂区内可能同时存在着多家独立运营的法人公司。员工分别签合同采购分别下单财务各自记账但他们共用着同一套厂房、同一个仓库、同一批供应商。于是这个系统的“采购订单”并非一张表而是按法人分库存储的十几张表。同样的流程需要为不同法人发送不同格式的邮件。在某个目录下诞生了这样的“奇观”YBxxx_email.vbs (B 类) YCBxxx_email.vbs (C 类 - 子类 1) YCFxxx_email.vbs (C 类 - 子类 2) ...共6份几乎一模一样的脚本我问AI“能否合并成一个配置驱动的脚本”它再次给出了一个堪称完美的重构方案模板引擎、国际化、SendGrid集成应有尽有。但它永远不会知道这6份脚本之所以存在不是因为技术做不到而是因为在2007到2010年间每增加一个法人就会有一位强势的业务主管坚持“我们部门的邮件模板必须和其他厂不一样”代码的冗余是组织博弈的投影。组织的冗余则是利益格局的固化。AI可以消除代码的冗余却无法消除人性的冗余。五、 “上帝模式”里的20种事故AI一件也写不出来系统里隐藏着一个“上帝模式”——一个只有System角色才能看到的菜单。上面罗列着20多个工具名字触目惊心某某单据删除 还原签核状态 启动代理人 修改经管主管 订单退回签核作业 订单结存数量清零 ...每一个工具的背后都是一起真实发生过的线上事故。“启动代理人”因为某位主管休产假整个厂的采购签核流程因此瘫痪。“还原签核状态”因为系统崩溃导致一张关键单据的状态卡在了中间。“修改经管主管”因为人员变动大量旧单据仍挂在已离职的主管名下。“订单结存数量清零”因为月末结算发现重大差异需要紧急修复。这20多个工具是这家企业在十几年运营中“出过的所有事”的总和。它们是经验的结晶也是痛苦的伤疤。AI可以写出无数个微服务、无数条Kafka消息队列但它永远写不出这20多个工具。因为它从未经历过那20多种痛苦。六、 时间堆出的数据AI永远无法“生成”第四层宝藏藏在upload/目录下。这里有几百份Excel和PDF文件命名格式惊人地统一CL090526015.xls、HL080515030.pdf。前缀是单据类型中间是日期后缀是流水号。每一份文件都是一个真实业务场景的切片。它们是手写的、传真的、扫描的原始凭证。十几年下来堆积如山。我让AI为我“生成”一个现代化的采购系统架构图。它很快画出了一幅包含微服务、Kubernetes、Kafka、Elasticsearch的完美蓝图。但是它永远无法“生成”那份名为CL090526015.xls的文件。那份Excel是2009年5月26日下午一位仓库管理员在断网的电脑上手工录入存入U盘再走到联网电脑上上传的。这一系列动作在那个特定的时空背景下只发生了一次就再也无法复制。数据不是AI从海量语料中“学习”出来的它是时间一点一滴“堆”出来的。七、 最深处的矿藏在“代码语录”里最深层的宝藏并不在代码里。它藏在验收备注.txt里藏在出货情报使用.pdf里藏在一个名为shuoming.txt的文件里——里面只有一句话“XX采购管理系统”。它甚至藏在系统最核心的状态机逻辑里。那段决定单据流转命运的代码没有被写在.asp文件中而是被放在一个名为“代码语录”的目录下的txt文件里% if trim(rs(xxx_cfmstatue))N then 一级主管没有签核 if trim(rs(xxx_chkstatue))N then 二级主管没有签核 ...5层嵌套5个状态变量每个有N/R/Y/F/C/A六种取值为什么是txt而不是asp因为它被复用在十几个页面里每次都是直接Copy-Paste。为什么变量名是中文拼音因为写代码的人就是最终的使用者。为什么它叫“代码语录”因为这根本就不是一段严谨的程序而是一套“口口相传”的业务规则被以代码的形式冻结在了2010年。AI可以训练GitHub上所有的开源代码但它永远无法训练这个名为“代码语录”的目录。因为这里的“代码”记录的不仅是逻辑更是人情世故。八、 致AI你无法迁移的是“有人需要它这样”我曾试图让AI制定一个迁移方案将这个系统迁移到现代化技术栈。它给出了一个堪称完美的12步计划从“Big5转UTF-8”到“VBS重写为Python Worker”再到“frameset改造为SPA”。每一步都正确无比但每一步都注定无法执行。因为它不知道Big5转UTF-8会破坏掉十几年来积累的所有Excel文件的文件名编码。VBS脚本运行在Windows计划任务中拥有NT AUTHORITY\SYSTEM的最高权限一旦迁到Linux Worker这个权限模型将不复存在。将frameset改为SPA后那些习惯了老界面的资深员工打给CIO的投诉电话会瞬间淹没IT部门。现代化最大的敌人从来不是技术本身而是那句潜台词“这个系统之所以长成这样是因为有人需要它长成这样。”九、 结语AI生成代码但生成不了“发生过”写到这里我忽然明白了。我们这代人疯狂地追逐着“新”新技术、新框架、新范式。AI的出现更是将这种对“新”的渴求推向了极致——上周的最佳实践这周就可能成为历史。但这套已经死去的代码却向我展示了另一种价值——“旧”的价值。它运行的十几年恰好是中国制造业狂飙突进的十几年。每一次外部的剧烈变化都在它身上留下了不可磨灭的烙印一次税法变更 → 一个硬编码的日期一次供应商认证改革 → 一个新加的URL字段一次中转仓模式上线 → 一整个新目录一次采购流程变革 → 又一个新目录它不是一套代码它是一部用代码写成的《企业史记》。AI可以生成代码但生成不了记忆。代码可以被重写但记忆无法被重写。那一个个日期、一个个文件名、一个个“丑陋”的if-else背后是一个个具体的人、一件件真实的事、一次次艰难的抉择。那个叫Ris的程序员2006年6月20日敲下第一行代码时或许不会想到他的作品会在20年后以一种如此特殊的方式给这个被AI浪潮席卷的时代上了如此深刻的一课。这套系统今天已经死了。不是因为代码写得不好而是因为它所服务的那个业务形态、那个组织结构、那个时代都已经过去了。但它静静地躺在硬盘上的那个瞬间比AI生成的任何代码都更加沉重。因为它真的“发生过”。而AI永远无法生成“真的发生过”的东西。