企业官网建设流程全解析

【虎鲸进化论 01】古法编程的黄昏：大数据开发十年手撸范式为什么崩了

本文是「虎鲸进化论」系列第 2 篇（正文第 01 篇）。上一篇：从按 Tab 到赛博飞升；下一篇预告：三阶跃迁 —— Tab 补全 → Vibe Coding → Agent。

前言

序章里留了一句话：要讲进化，先画进化前的地貌 —— 因为今天所有故事的最大背景板，是一套没人敢碰的黑箱。

这篇就干两件事：把"进化前"的地貌画出来，再回答一个问题 ——为什么这套稳稳跑了十年的手撸范式，会在短短几年里崩掉？

（先声明：文中涉及的系统与平台均为化名；所有描述都是行业里通行的形态，不指向任何具体单位。）

一、十年前的一天，大概是这样过的

早上到工位，先看调度平台的告警：昨晚又有一个作业挂了。打开日志，翻了 [NN 分钟]，发现是上游一张表迟到了 —— 顺手写个临时 SQL 把下游补上。

然后开始今天的正活：需求方要三张报表、一个接口。熟练的流程是这样的：

1. 写 SQL —— 抽数、聚合、拼宽表，通常几百行起步；
2. 写 Shell —— 把 SQL 包起来，挂到调度上，配依赖、配告警、配重跑参数；
3. 如果逻辑复杂，写 Java 或 Scala —— UDF、Spark 作业、自定义算子；
4. 上线 —— 改配置、发版本、盯一晚。

这套"SQL + Shell + Java + Scala"的四件套，是那一代大数据开发的通用姿势。四件套各管一段，分工相当清楚：

顺带说一句：能把这四件套都写利索的人，在组里地位是不低的 —— "懂引擎"和"只会写 SQL"之间，有一条看不见的等级线。别以为"只会写 SQL"很轻松 —— 真到引擎层，executor 内存、shuffle 分区、数据倾斜，会一样不少地找上你；而"懂引擎"的那几位，下午的战场还有另一张桌子：智能运维平台的后端 —— Spring 那套接口、权限、任务编排、明细报表，也都归他们接。我们这个组从来不是"纯大数据"：大数据 + 智能运维后端，双线并行 —— 这是编制表上看不出来的那一半。

二、为什么这套范式稳了十年

事后复盘，它稳，是因为它在当年的约束下，其实是最优解：

第一，交付物形态和组织结构是配套的。报表、指标、接口 —— 需求的终点大多是"数据出得来"。SQL 是离数据最近的表达方式，改一版、跑一遍、看一眼数，闭环很短。

第二，学习路径平缓，人力供给充足。培训机构三个月能产出"会写 SQL 的劳动力"，而这恰好覆盖了大部分工作量。这套范式是非常"可复制"的。

第三，它天然支持分工。谁写调度、谁写逻辑、谁对接需求，边界清楚。出了事，责任也能顺着链条找到人。

第四，也是最容易被忽略的 —— 它给"经验"留了巨大的溢价空间。哪张表有坑、哪个口径是老板亲定的、哪个作业重跑要跳过哪一步 —— 这些不在任何文档里，只在老员工的脑子里。经验，是这套体系里的硬通货。

所以你看，它没有任何理由不稳。要修它的动力，几乎为零。

三、三笔从来没进过报表的账

但任何范式都有它的隐性成本。手撸范式有三笔账，从来没有人把它算进工时报表里：

第一笔：样板劳动的复利。

抽数 SQL 的骨架十年不变：select、join、group by、落临时表、再 join 一次宽表。逻辑各不相同，但"形状"高度重复。一个熟手一天写的几百行 SQL 里，真正有信息量的可能只有几十行 —— 剩下的都是仪式。

仪式不可怕，可怕的是它有复利：十年里，全组全行业在这套仪式上烧掉的工时，是一个天文数字。而这笔账，在任何一张报表上都看不见。

第二笔：经验主义运维。

作业挂了怎么办？第一反应不是"查因果"，而是"试"：先重跑一次，不行就换个时间点重跑，再不行就跳过那个上游，最后实在不行，手动补数据。

这套排查法，我们内部有个更诚实的名字：对外叫"经验"，对内叫"玄学"。核心思想是 —— 昨天这么试成了，今天应该也行；实在不行，就假定今天的宇宙常数变了。

这不是懒 —— 是因为因果链条不可见。调度依赖、上游口径、作业内部逻辑，散在三四个系统里，没有任何一个地方能告诉你"为什么挂了"。于是在长期实践中，"枚举各种可能性"被固化成了一套手艺：老员工重跑的手法、判断的直觉，全是这么攒出来的。

这套手艺有一个致命特点：它只对"昨天挂过的那种"管用。没挂过的新花样，谁也不知道。

第三笔：知识口传。

系统的真正知识 —— 口径、依赖、坑、潜规则 —— 存在三个地方：老员工的脑子、群聊记录、和"某个人还没离职"这件事本身。

它不可检索、不可交接、不可审计。人员一旦流动，知识就蒸发；而为了对抗蒸发，组织发明了一堆补充动作：交接文档（没人看）、代码注释（没人写）、周会口头同步（没人记）。这套组合拳的全部功效，是把"知识蒸发"的时间从"离职当天"推迟到"离职后一周"—— 聊胜于无，主要胜在让 HR 的交接表看起来好看。

十年下来，这三笔账谁也没还，只在账本外越积越厚。

四、黑箱是怎么炼成的

三笔账积到一定程度，就凝固成了那个东西：祖传系统。

它的构成其实很朴素：

• 人员流动几轮，经手人自己都记不全；
• 文档停留在"初版设计"，与现状差了几个版本；
• 没有测试 —— 或者说，测试就是"跑起来别报错"；
• 改动靠"敬畏"：谁也不敢动，动之前先备份，动之后盯三天。

于是它就成了系统_A：能跑，但没人说得清它是怎么跑的；能改，但没人敢改。

外人以为这是技术难题。其实它是组织难题：黑箱不是算力堆出来的，是"没还的三笔账"沉积出来的。

我后来常想，我们对它的恐惧其实是精确的 —— 恐惧的不是复杂，是"不透明"：你不知道改一行会动到哪，所以宁愿绕着走。整套运维于是被制度化成八个字：小心谨慎，不断试错。

五、为什么最先被 AI 攻破的，恰好是我们这一行

这正是这个系列最有意思的部分。

那几年 AI 开始横扫编程领域，但各语言的"沦陷"速度不一样。大数据开发，属于沦陷得最快的那一档。现在回头看，原因很清楚：

1. 模式化程度高。SQL、ETL、报表逻辑，是典型的"高重复 + 低创新"文本 —— 恰恰是语言模型最擅长的分布。
2. 语义边界清晰。一段 SQL 的意图，人看了就懂，AI 看了也懂；不需要跨十个抽象层去猜。
3. 反馈回路极短。SQL 写完能不能跑、数对不对，当场就能验证 —— 这让"AI 生成 + 人验收"的循环转得飞快。
4. 错了可回滚。数据任务大多数不是不可逆操作，这让试错成本低到可以忽略。

换句话说：我们这行的活，恰好长在了 LLM 的舒适区上。

当年让我们引以为傲的"高技术密度"—— 复杂 SQL、引擎调优、作业改造 —— 在 AI 眼里，大多是模式识别问题；而当年那些"只有老员工知道"的坑，恰好也是 AI 最缺的上下文。

这两件事，决定了后面所有的故事：它先吃掉"手艺"，再要"上下文"。

结语（回味点）

现在你明白序章里那笔"遗产"的构成了：不是某个系统的代码，是十年手撸范式攒下的三笔账，外加一座叫系统_A的黑箱。

我们曾以为那些是护城河。掀开看，是一层叠一层的债 ——而债务，比护城河好拆多了。

范式不是被修掉的，是被跳过去的。第一次让我心里"咯噔"一下觉得时代变了的，不是什么大动作、大模型、大新闻 —— 相比后面要讲的事，它小得近乎可笑：

只是某天下午，我在 IDE 里按了一下 Tab。

边界声明

• 本文为个人观察与判断，不代表任何任职单位的立场；
• 文中涉及的组织、系统与人名均为化名或模糊处理，数字为个人口径的测量或估算；
• 文中观点按 实测 / 推理 / 立场 分层标注，欢迎按同一标准检验。

下一篇计划聊：三阶跃迁—— Tab 补全、Vibe Coding、Agent 三个阶段，人分别在每一层退到了哪里。

转载请注明出处：
https://lizhiyong.blog.csdn.net/article/details/167922120