企业官网建设流程全解析

【虎鲸进化论 02】三阶跃迁：Tab 补全 → Vibe Coding → Agent，人在每一层退到哪里

本文是「虎鲸进化论」系列第 3 篇（正文第 02 篇）。上一篇：古法编程的黄昏；下一篇预告：意图工程 —— 当写代码变成写目标与验收。

前言

上一篇的结尾，停在那个按下去的 Tab 上。

这一篇从头讲起：从那个 Tab 到现在，一共只发生了三次跃迁—— 补全、结对、代理。三次跃迁之后，同一个人的产出和同一个人的角色，都换了一副样子。

我想把这三次跃迁讲细一点，因为很多人（包括当年的我）是在第一次跃迁里就"满意"了，然后被第二、第三次跃迁的加速度甩在后面。每一层跃迁的分界线在哪、人退到了哪一层、新增了什么技能 —— 这是这篇的全部内容。

一、第一阶（补全）：人机关系 = 打字机加速器

最初的样子大家应该都见过：IDE 装个插件，写一行开个头，灰字提示跳出来 —— 按 Tab 接受。

那个阶段，最强的工具就是"补全流"。说实话，最初它的能力相当有限：

• 补一个字段名、一个方法签名、一行的后半截；
• 偶尔能把一个 if、一段 join 顺着你的习惯写完；
• 再复杂的，它就废了 —— 它的"视野"就是当前文件 ± 几屏，看不到别处的约定。

注意它的原理也很朴素：补全本质上是"词级/行级的概率续写"—— 你敲下select * from，它在猜下一个标识符该是什么；至于"你查这张表要干嘛"，它没概念，也不需要有。这个"不需要有"，就是第一阶和第二阶的全部差距。

但就是这个"有限的它"，已经让手速这个维度的差距贬值了。以前组里比的是谁 SQL 写得快、谁记得住函数名；那阵子大家比的是"谁补全用得多" —— 虽然现在看有点好笑，但当时它确实改变了工位上的气压。

这一阶的本质：人还是写手，AI 只是打字机加速器。输入、判断、责任，全部还在人身上；它唯一改掉的，是手指的磨损。

它的边界也很清楚：单文件、短上下文、零自主性。你只要一跨文件、一跨系统，它就变回一个傻乎乎的联想器。

二、第二阶（结对）：提示词进、代码出、人肉串联

真正的分水岭，是从"补全"升级到"对话"。

你开始对着一个聊天窗描述需求：“给我写个 Spark 作业，读这张表，按 XX 聚合，输出到 XX。” 然后一段像模像样的代码流出来。多文件、跨语言、带注释、甚至带测试 —— 只要你能把上下文说清楚。

代价也随之而来：它的"记性"和它的"饭量"是同一件事—— 一次能吞的上下文是几万 token 量级，大致相当于把你最近改过的那几个文件摊在桌上；再远的信息，它就"记不清"了。于是那个阶段的你，一半时间在写需求，另一半时间在"摆桌子"。

这个阶段后来被起了个名字，叫Vibe Coding：不逐字写，只把握方向，剩下的交给"感觉"。

但亲身用过的人都知道它的边界：每一步都要人盯。

• 它写完一段，你要跑一遍、看一眼，才能放下心；
• 上下文得靠人一勺一勺喂：把相关文件贴进去、把历史对话说清楚；
• 任务一长，它就"忘了前面"或者"想岔了"，你得把它拽回来。

所以那个阶段的日常是：提示词进、代码出、人肉串联。人从"写手"变成了"结对的另一半"—— 但请注意，代码的解释权还在人手里：每一行你都读过，不然不敢发。

那时候组里还有个自我安慰的说法：“我们负责串，它负责亮 —— 串联，也是核心技术。”现在回头看，这句话的保质期比冰箱里的酸奶还短。

有意思的是，这个阶段已经开始出现后来一切的预兆：链路一长，人就串不动了；而"串"这件事，恰好是机器最擅长做的事。

三、第三阶（代理）：目标进、结果出

先讲个真实的瞬间。

第一次让它整夜干活，是在一个再普通不过的周四。睡前我把需求丢给它 —— 大意是"把智能运维平台这个接口的校验逻辑补齐，跑一遍相关用例，没问题就提分支"。然后我去睡觉。

第二天早上，我打开电脑的手是悬着的，心想"八成给我搞砸了"。结果它交上来的东西把我钉在椅子上坐了一会儿：

• 分支在，用例跑了，报告写了；
• 中间它自己发现有个边界条件没说清，它没有瞎猜，而是按我留的口径默认处理，并在报告里标了出来；
• 报告的最后一行写着：这段逻辑我没完全读懂，建议你复核。

那一刻的感觉不是"省了时间"，是**“链接方式变了”**。

（说出来有点丢人：我当时的第一反应不是成就感，是查岗 —— 真假？这报告不能是它编的吧？后来很多年我都庆幸自己养成了这个习惯：对它的信任，是从查岗开始的。）

这一阶和之前的本质区别，不在生成质量，而在结构：

• 交互单位变了：从"一段代码"变成"一个目标"；
• 执行方式变了：tool call 循环 —— 规划、调用、观察、再规划，自己拆 subtask，自己验证；
• 人机关系变了：从"结对"变成委派 + 验收。

人退得更深了。键盘、光标、提示词，现在连"串联"都不用做了 —— 人只负责两件事：给目标、做验收。

当然，这一阶的门槛也彻底换了地方：它能力的天花板不再取决于模型参数，而取决于你能给它多少上下文、多少工具、多少反馈。这句话背后的东西，是整个卷Ⅱ和卷Ⅲ要讲的事 —— 先记住这个判断：能力 = 上下文 × 动作空间 × 反馈回路。

四、把三阶并排看：人退到哪里，新技能是什么

这张表里有三行值得单独说：

第一行，“人的新技能”。每一层跃迁，人不是"没活干了"，而是被推上了一层新台阶：提示 → 上下文 → 目标与验收。这些技能上一代人也有 —— 它们叫需求分析、技术方案、测试验收。也就是说：行业把"实现层"的活收回去了，把人推回了"定义层"。你以为你在学新东西，其实是在重学一遍软件工程的老手艺。

第二行，“典型失败”。一阶、二阶的失败你能当场看见；三阶的失败，是最危险的一种：格式漂亮、语气确定、退出码 0，但答案是错的。“AI 的产能是真的，AI 的自信是假的”—— 这句判断我在另一个系列里已经领教过一轮，后面的卷Ⅲ里，它还会以更凶的形态出现。

第三行，“责任落点”。这是三阶跃迁里真正变了的东西：从"我写的代码"，到"我批的代码"。键盘声没有了，但签字笔还在人手里—— 什么时候交出去、交到什么程度，这个决定权，目前还在我们这边。（顺便说一句大实话：在这个行业里，签字笔大概是所有"工具"里最不容易被裁的那个 —— 它贵，就贵在要担责。）

五、一个必须说破的机制：为什么"中级能吊打资深"

三阶跃迁之后，组里出现了一个反直觉的现象，也是这个系列最早的悬念之一：AI 用得好的普通工程师，产出可以压过不用 AI 的资深专家。

机制其实不复杂 —— 跃迁把两种能力的"汇率"改了：

• 实现能力被压平了。写 SQL 快不快、记得住几个函数、会不会调引擎参数 —— 这些"资深"积攒了十年的实现层优势，被三阶跳了一大截；
• 判断能力被放大了。同样面对一台会干活的 Agent，能不能定义对目标、能不能识破"自信的错"、能不能在验收时抓住狸猫换太子 —— 这些能力，用 AI 的人乘上 N 倍杠杆，不用的人乘 1 倍。

于是差距不是被抹平，而是换了一根轴：从"谁写得好"换成"谁定义得对、验收得住"。

这句话在卷Ⅳ里还会被算一遍总账。这里先埋个线头。

结语（回味点）

回头看，三次跃迁真正的分界线，不是模型发布会的日期，而是两个问题换了主人：

"怎么做"归了它；"做没做对"还在人手里。

人退到意图层之后，手里还剩什么手艺？我能告诉你的是：我把旧手艺丢了三遍，才攒出新的 —— 而且攒的过程相当难看。

边界声明

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

下一篇计划聊：意图工程—— 当写代码变成写目标与验收，开发者真正的手艺变成了什么；以及为什么连需求分析师都开始自己修 bug 了。

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