在无限代码时代中不可或缺的人类元素

“在AI时代，你开发团队里最让人捏把汗的，不再是那个磨磨唧唧的软件工程师，而是那个手速飞快的！” 就那种能像开了挂一样，嗖嗖嗖地交付功能的家伙。速度快的团队，仪表盘上每个冲刺周期都绿油油的，看起来挺美。但别急着乐，这背后可能藏着大坑呢。

在一个代码白菜价、无限供应的世界里，速度可不能说明你是不是真的在赢。它只能告诉你，你积累的那些不理解、修不好、控制不了的东西，增长得有多快。😨

不过，这事儿咱们后面再说。先来聊聊软件工程以前是啥样，现在又发生了啥翻天覆地的变化。

50多年了，咱们这些人在这里都是靠掌握一门神秘的语言吃饭。我们因为懂这门语言，所以能赚钱。我们因为会说“机器语”，所以能拿到薪水。

要是业务老大想搞个新功能，比如新的结账流程、搜索栏、数据管道，那可就头疼了。他们有想法，但没语法。他们得我们把这些人类想法翻译成Java、SQL、React。我们懂怎么让机器听懂人话。

因为这种技能稀缺，我们就能收点“保护费”。这“保护费”就是我们的薪水、时间表、敏捷仪式，还有整个职业生涯的保障。

但有些东西变了。现在，机器也开始说自己的语言了。字典都公开了，翻译“保护费”也在迅速归零。

我可得说明白：这可不是说软件工程要完蛋了。但咱们历史上最闪亮的部分——把英文需求翻译成语法实际行为——现在都变成商品了。

现在咱们得好好想想：要是编码不再稀缺，那软件工程的价值到底在哪里呢？

危机：通货膨胀与效率陷阱

我听到很多人在担心“替代”的问题。但我们面临的是通货膨胀危机，不是替代危机。

想想经济学吧。你印太多钱，货币就贬值了。你“打印”太多代码（现在咱们几乎能无限量地做），写代码的价值就下降了。

咱们正从稀缺时代走向富足时代。而这，导致了我看到公司现在犯的最大错误。

我把它叫“效率陷阱”。项目经理们看到这富足，心想：“哈哈！AI让开发者速度提升50%，那我就裁掉50%的人，还能保持同样的产出。”（对于那些质疑这句话的人：这句话是ChatGPT写的。它自信、简洁，而且完全错误。50%的生产力提升意味着你可以裁掉三分之一的团队，而不是一半。这跟演讲的其他部分完美契合，所以我保留它了。）

但别光看AI那自信的样子：这种想法从根本上就是错的。项目经理们只看到了短期的收益，却忽视了长期的复杂性。

富足背后藏着风险呢！🙅‍♂️每一行代码的添加，每一个微服务的部署，每一次集成的尝试，都可能悄无声息地让系统的复杂性超出我们的掌控。系统表面上看可能风平浪静，仪表盘上绿油油的，但 underneath，脆弱性就像野草一样疯长。

这时候，直觉就靠不住了。看着产出像坐火箭一样飙升，我们可能就会想：“哎哟，这得赶紧给它来个严格体检，得加把劲监控它，得让它跑得更快更稳。”

但在AI时代，速度不再是领跑者，反而成了落后者。对速度的迷信，最终只会把你推向失败的深渊。

你一门心思地追求速度，结果就是在给复杂性添砖加瓦。而当你开始注重理解，真正弄清楚你造了什么，它怎么运作的时候，系统就像打通了任督二脉，速度自然而然就上来了，成了副产品。

只顾着产出，不关心产出的质量，这样的团队早晚得歇菜，不是因为慢，而是因为太害怕去触碰自己亲手搭建的“大观园”。

维护现有的老古董代码都让你头疼，那你等着瞧，你团队后面那堆代码山，得有多壮观！

转变：懂时间均值才是王道

在任何系统中，价值都往瓶颈上跑。要是写代码就像呼吸一样简单、快速、成本低……那新的瓶颈在哪里？

瓶颈不再是写代码，而是理解代码。

瓶颈在于你知道这段代码到底干啥，它在哪表现得好，更重要的是，它在哪掉链子。

咱们得戒掉对速度的迷恋，开始追求MTTU——理解时间均值。

DevOps和SRE老司机们早就用这个来衡量故障和诊断之间的时间差了；现在咱们也得跟上潮流，用它来评估代码本身。

对开发者来说，MTTU就是非原作者的人能自信回答的时间：

这代码到底干啥？

它要是挂了，我得去哪找毛病？

关键在于：如果你能优化MTTU……如果你能让系统和团队最大化理解……其他的一切都会水到渠成。速度、可靠性、可维护性，这些都会自然而然地变好。

如果你只顾着产出，忽视了理解，系统迟早得歇菜。不是因为慢，而是因为复杂性增长得比谁都能想象得快。

从现在开始，你做的每一个架构决策，都是在压缩还是增加MTTU。

快速理解并验证你未亲手编写过的代码，这是新时代的杀手锏。这也是资深人士在这个新时代能发挥余热的原因。

你多年的经验积累，模式识别能力、思维模型、宝贵的判断力，现在终于派上用场了。

AI能生成无限的可能，但你才是那个能审视这些方案，理解它们对你系统意味着什么的人。

但话说回来，这个指标和原则为什么这么重要呢？

诊断：别被表象迷惑了双眼。哎哟，这个问题一出，真是让人哭笑不得啊！你说AI编码不行？别逗了，它那是太能耐了，能耐到有点儿过分了！AI啊，它就是一个永远只会说“是”的“好好先生”，啥事儿都往大里搞，偏向于搞个大新闻。

你给它个问题，它不是给你修修补补那么简单，直接给你整出一堆东西来。就像你让AI去修个灯泡，它不仅能给你换灯泡，还给你整了个智能控制系统，你说它是不是有点儿过了？

它写的代码看起来没问题，用了正确的库，缩进也正确，甚至能过它自己写的单元测试。但是，兄弟，你看过丹尼尔·卡尼曼的《思考，快与慢》没？那里面说的系统1和系统2思维，还有这代码看似强大实则隐藏的问题，你肯定懂吧？

AI这代码写出来，直接激活了我们的大脑系统1，一看，嘿，挺像那么回事儿，就点头了：“嗯，不错！”可这恰恰是陷阱啊！我们太容易相信它了，结果大脑一歇菜，啥都不想了。

我们没去验证它是不是真的适合我们的系统，更别提用系统2那慢悠悠的思考方式去分析了。就这样，我们让AI做了我们本来不会让人类做的事情，这不就是第二个陷阱嘛！

哎，说到这，我就想起个事儿。想象一下，一个团队要搞个简单的功能，比如一个提交用户名和邮箱的网络表单。以前啊，开发者可能就随便写个文件，加点儿验证逻辑，完事儿。

但现在呢？直接让AI去“稳健”地处理提交。AI那是啥，那是建筑大师啊，直接给你建了个独立的微服务、重试队列、无服务器函数，甚至还搞了个分布式日志服务，你说它是不是有点儿过了？

技术上没问题，语法上也没毛病，可这就是问题所在。AI它那是局部优化，只顾着解决眼前的问题，不管你整个系统的其他部分。那你的工作呢？你是全局优化者，你是架构师，你得知道这个表单怎么跟用户会话、计费系统和遗留数据库融在一起。

现在好了，AI给你整出一堆新服务和新队列，直接给你搞了个复杂性高峰。你得把所有这些新玩意儿都装进大脑里，还得去想五个服务的故障模式，这不是给大脑加负担嘛！

哎，这认知负担一上来，危险可就大了去了！当方案变得辣眼睛，脑子里都塞不下了，咱就歇菜了，不再吭哧吭哧验证架构。以前总琢磨“这靠谱不？”，现在就只管“能跑就行”。哎，架构师这活儿都给撂了，蓝图太乱，看了都头疼。

话说回来，咱这约束得说说“架构验证”。这不是说咱码代码有多慢，关键在于带宽，是序列化带宽。

要想当个顶呱呱的架构师，你得保证方案安全、合规，还得能把它整个逻辑在脑子里过一遍。你要能想象出，改了X会不会把Y给坑了？

现在啊，咱们这儿AI这玩意儿，输入是无限量的，可咱大脑这序列化带宽是固定的。

序列化带宽，就是你把系统塞进脑子里的能力。AI打字再快，要是你跟不上逻辑，那系统就悬了。

那些AI信徒、乐观主义者（还有那些推销AI工具的供应商）就爱说：“别担心！咱们给AI搭个上下文，给它文档，再给它来点提示。”这简直就是行业里最害人的谎言！你连上下文都不懂，还提什么？

软件里的上下文可不是个静态数据库，想怎么存就怎么存。上下文是活蹦乱跳的。

你不知道“用户”这货和“账单”那玩意儿还藏着掖着，直到你看到代码想搞它。你也不知道这重试逻辑咋就触犯了新规，直到你看到队列建起来了。

上下文就是代码和现实世界的碰撞。

AI就只看代码，就你懂现实世界的上下文。

你要是理解代码的速度赶不上你造的速度，那你就失去了发现这些碰撞的能力，也就失去了管理系统的能力。

瓶颈不是打字快慢，是架构验证的快慢。

来来来，看看咱们的Jira看板，还拿速度衡量进度呢，什么冲刺的功能数、关闭的工单、交付的代码行数。这不就是咱们制造认知债务的罪魁祸首嘛！

在新世界里，“好速度”就是保持理解时间不变，还能把功能搞出来。“坏速度”就是提高MTTU（平均修复时间）来搞出功能。

你要是用了AI，四小时就搞出一个功能，结果下周就挂了，还得让一个资深工程师花三天才搞明白怎么修，那你的MTTU比代码速度还高。

要是你的MTTU太高，那你就陷入认知债务了。

这债务可不光留在代码里，它还会泄露出去。

表现为：

- 事件持续时间更长（因为根本原因谁都不清楚）。

- 入职速度更慢（因为新员工看不懂这地图）。

- 功能瘫痪（因为大家都怕碰那“魔法代码”）。

为了说明这事儿，我再问你个问题：嘿，各位小伙伴们，来来来，举手表决一下，过去一个月里，有多少人像无头苍蝇一样，合了个自己都半懂不懂的PR？如果你们心里想着“稍后再说，回头再仔细看”，那也请举手表示一下！要是你真的这么做了，别忘了也举举手哦。

哈哈，是啊，我自己也没那么做过！这就是我们迫切需要一个新协议的原因嘛。

协议时间：规范驱动开发，别急着走神，我可不是说那种让人头大的瀑布式规范哦！

回顾一下：到目前为止，我已经跟你说了哪些东西出了问题，为什么出了问题。但我不想让大家焦虑地走，所以今天给大家带来一个明天就能用的协议。

重要通知：我们必须改变协议，要转向对AI和MTTU友好的规范驱动开发啦！

在这个新世界里，我们不是先看代码，而是先建结构，这得分为三个层次：

第一层：微观规范（人类引导和地图）

这可是你的生存工具，让你日常保持理智的小帮手。它就像是你的“认知把手”，在你写代码之前，你得在脑子里（或者便利贴上）先定义好高层次的意图。

目标：“添加用户归档功能。”

约束：“必须是可逆的。”

架构适配：“这属于用户服务还是管理服务？”

微观规范就像是你的“废话和不合适检测器”，让你能看看AI的输出，立刻就能判断：这段代码符合我们系统的形状吗？看起来符合我们要求的功能吗？

要是AI想为一个简单的UI更改重写数据库模式，微观规范会让你立刻拒绝它。

第二层：主规范（共享契约）

这层规范让大家保持一致。一旦你知道了代码的形状，就得来点实质内容了，这就是主规范。

对AI来说：它是说明书，里面有验收标准、具体的边界情况、输入/输出定义。

对你来说：它是技术验证的清单。

在AI生成代码之后（修复了明显的bug），你得从“架构师”变成“审计员”，对照主规范检查代码。

“它处理了我们要求的空值情况吗？”“它实现了我们定义的具体重试逻辑吗？”在这里，你验证技术要求。

如果说微观规范检查的是代码的灵魂，那么主规范检查的就是身体。

第三层：全局上下文（潜意识）

这层是你的进化系统，让你随着时间越来越快。最后，我们有了这个增效器。

随着我们构建，我们会发现我们不断重复某些指令：“使用Tailwind”，“不要使用‘any’类型”，“遵循仓库模式”。

我们不会把这些指令塞进每个规范里，而是把它们卸载到全局上下文中。

这就是像CLAUDE.md文件或.cursorrules文件这样的工具发挥作用的地方。

我们把这些话当作我们的进化规则集。嘿嘿，这样一来，我们就能越来越高效地开发了！🚀🎉哎哟，每当AI这个小家伙在风格上犯了个小错，咱们可不只是简单修修代码那么简单。咱们得更新全局上下文，给它加条新规矩。这就像给AI开个小灶，让它慢慢学会咱们的工程文化。

时间一长，这AI就越来越懂咱们了，变成个模式小达人。这样一来，咱们在审查语法、导入和文件夹结构上的时间就能大大减少，感觉就像给工作加了加速器一样。

那省下来的时间都去哪儿了呢？嘿嘿，它都去干些咱们平时顾不上的事情了，比如现实世界的那些“模糊性”问题。不管AI多懂咱们的代码库，它可不懂咱们的战略，更不知道营销团队刚改了发布日期，也不知道用户那个“恨之入骨”的模态框。

这时候，你不再是那个只会修代码的代码审查员，而是变成了现实世界的审查员。微观规范是灵魂，是代码的味儿；主规范是身体，是代码的实质；全局上下文是潜意识，是代码的指导原则。

就算有了这些，你可能还是得问，提示和上下文都确定了，咱们还剩啥用啊？人类能干的事情，AI在未来20年内估计是干不出来的。咱们有三道护城河，让AI想取代咱们都挺难的：

护城河1：影子架构

AI看的是代码，你看得是现实世界的依赖关系。比如，AI看到API里有个错误消息：“Err(500)”，它可能建议改成“Internal Server Error(500)”，听起来挺高大上的。但你清楚，运维团队有个监控脚本，专门用grep找“Err(500)”，要是改了，监控就失效了，服务器说不定还得周末加班呢。

护城河2：问题定义（价值**）

AI只会按提示回答，而你懂得隐含的需求。比如，业务部门说“快速搜索”，AI可能直接上Elasticsearch，花大价钱搞实时响应。但你清楚，“快”可能就是“一秒以内”，一个简单的SQL查询就能搞定。

护城河3：系统悲观主义者（副作用**）

AI只看到表面，你懂得系统的副作用。这就像玩儿游戏，AI是新手，你可是老玩家，知道哪些改动可能会带来什么后果。

一旦你接受了从代码审查员到编排和评估者的角色转变，“提示工程”的争论也就不存在了。AI想取代你，可没那么容易。这三道护城河，就是你的护身符！AI，简直就是局部修复的“小能手”啊！给你一个错误，它分分钟帮你搞定，还能给你写上“护身符”，什么异常啊，都逃不过它的“火眼金睛”。但问题来了，它对那些“系统性副作用”就睁一只眼闭一只眼了。就像它只会给数据库加个“重试循环”，却不知道前端和负载均衡器也在默默努力，结果自己修复了个寂寞，还弄出一堆“重试风暴”，等着在流量高峰时给你来个“大惊喜”。

它只看文件，而你，你得把“爆炸半径”也给考虑进去。你得问：“这代码要是完美了，会不会又炸出什么幺蛾子？”但这种“高阶操作”可不像在训练营里学的那么简单。那在这个新世界里，初级开发者还能混个啥？

初级开发者，简直就是“探险家”嘛！如果你刚入行，有点小焦虑，那说明你有点“慧眼”。但记住，AI可不是来取代你的，它是来让你变得更“危险”的。那些“资深人士”啊，都被自己的“思维定势”给限制了，知道“应该”怎么做，所以就让AI干那些“显而易见”的事。而你，没有这些“先见之明”，所以你可以在AI的“指导下”快速探索，因为你需要“忘记”的东西太少啦！

这就让那些C级项目经理和招聘经理犯嘀咕了：“AI都表现得跟中级开发者似的了，我们还得花钱培养人干啥？”哈哈，因为AI是“引擎”，不是“司机”啊！

现在，初级开发者的价值不是“码农”，而是“选项大师”。以前，我们不确定怎么搞，得派个“资深人士”花三天时间做个原型，那得多贵啊！现在，我们直接派个初级开发者，跟他说：“这里有个需求，用AI试试三种方法，列出利弊，给我最靠谱的那个。”初级开发者这就成了“投资回报率”的“即时”保障，因为他们是资深人士的“超级助手”。

他们在AI的“幻想世界”里穿梭，验证库，过滤噪音，把筛选好的“选项”交给资深人士。就像探险家在AI的“丛林”里开路，把安全的路线带回来。

他们之所以有价值，就是因为他们承担了“探险”的任务，让资深人士能做出“高回报”的选择。在这个过程中，他们也学会了成为“资深人士”的“判断力”。

至于那些“资深人士”，你们就是“指挥家”啊！你们定义规则，决定哪里可以“复杂”，哪里不能。你们检查代码和其他库的“接触点”，确保AI写的代码，旋律还是那么“和谐”。

就像每一行AI生成的代码都是一件“乐器”，只有你们才能确保它演奏出正确的“旋律”。你们是唯一一个能看到整首“交响乐”的人！