谷歌工程师发现：AI写代码3年后，人类反而更忙了

去年QCon伦敦，Birgitta Böckeler讲"从自动补全到智能体"时，"氛围编程"（vibe coding）这个词才出生两个月。MCP协议正当红，Claude Code还在襁褓里。一年过去，她回来复盘，发现行业偷偷换了一套玩法。

上下文工程（context engineering）成了新战场。这个词去年6月才出现，简单说就是：你给AI看什么，决定它写出什么。但别以为是扔个AGENTS.md文件那么简单——Böckeler在Thoughtworks带团队做AI辅助交付，看过太多团队在这个环节栽跟头。

从"氛围编程"到"约束编程"

氛围编程的精髓是：你描述 vibe，AI 出代码，人类几乎不看。Böckeler 承认这很爽，"像有个无限耐心的结对编程伙伴"。但她话锋一转：当代码库超过一定规模，或者团队超过一定人数，这种放任就是技术债务的自动生产线。

她的团队现在谈的是"架构约束"和"安全网工程"（harness engineering）。不是让AI随便写，而是给它画好跑道——哪些能碰、哪些必须问、哪些直接拒绝。这像教新手司机：不是放手让他上高速，而是先装好副刹车。

一个具体例子：某客户让AI生成微服务拆分方案，AI给出了一份"技术上可行"的设计，却忽略了团队现有的运维能力。结果？新服务上线后，值班工程师凌晨三点被告警炸醒。Böckeler 说，这就是上下文没给够：AI不知道你们的on-call轮值表长什么样。

成本账没人算清

AI写代码快了，但Böckeler提醒领导者算另一笔账：维护成本。她见过团队用AI两周重构完一个模块，半年后却发现没人能讲清楚里面的业务逻辑——包括当初"写"它的人。

更隐蔽的是安全。AI生成的代码可能通过所有测试，却带着训练数据里埋的偏见或漏洞。Böckeler 的团队现在强制要求：关键路径的AI生成代码必须有人类架构师签名，不是走形式，是真的要回答"为什么这样设计"。

她的数据来自Thoughtworks全球项目库：2024年，使用AI编码助手的团队，代码产出量平均增长40%，但同期技术债务相关工单增长27%。速度换了债务，只是账单还没到期。

领导者的两难

Böckeler 给在场技术负责人的建议很直白：别问"我们用了多少AI"，问"我们怎么控制AI的边界"。她的团队开发了内部工具，把公司编码规范、安全红线、甚至特定客户的合规要求，都转成AI能理解的约束条件。

这不是限制创造力，是降低认知负荷。她类比：好的代码审查不是找茬，是让提交者知道"我覆盖了哪些风险"。AI时代，这个审查要前置到提示词（prompt）设计阶段。

演讲最后有人问：五年后还需要人类程序员吗？Böckeler 没给预测，只说她观察到的现象——最会用AI的团队，花在"教AI理解业务"上的时间，比写代码还多。

如果AI真的能替代程序员，为什么教它反而成了新工种？