David Gewirtz 坐在电脑前，盯着刚生成的三千行代码。他想起二十年前在洛杉矶那家融合菜餐厅的夜晚——主厨端上来的东西能吃，但绝不会想再来第二次。
这位 ZDNET 专栏作家最近密集测试了各种"氛围编程"项目。他发现一个被刻意忽略的真相：把代码控制权交给AI，和当年管理外包承包商一样，需要一套完整的验收体系。
餐厅困境：你不知道盘子里是什么
那家洛杉矶餐厅的主厨特供没有菜单。Gewirtz 回忆，"我知道会有食物端上来，但完全不知道要吞下去什么。"
AI 编程工具的现状惊人地相似。用户输入一句自然语言描述，系统返回可运行的代码。但代码内部的具体实现、架构选择、依赖关系——这些对使用者近乎黑箱。
Gewirtz 的比喻很直接：这就像让一群承包商或下属替你写代码。在测试和评估之前，"你根本不知道会得到什么"。
他观察到两种极端叙事在争夺注意力。一种是"一句话生成百万美元应用"的暴富幻想，另一种是"AI 代码必然崩溃引发末日"的恐慌。两者都是对现实的漫画式扭曲。
提示工程不是玄学，是契约条款
"垃圾进，垃圾出"这句老话在 AI 编程时代有了更深的含义。
Gewirtz 强调，一切取决于提示词的质量。如果描述不够清晰，对话过程缺乏持续监督，返回的代码将"难以消化"。这不是技术故障，是流程失控。
他早年做产品经理时管理外包团队的经验突然变得 relevant。工程经理的核心能力——分配工作、评估产出、维持质量标准——在 AI 时代没有被淘汰，反而更加关键。
区别在于，人类承包商至少能解释自己的决策逻辑。AI 生成的代码往往缺乏这种可追溯性。当系统提示"修复了 bug"，它不会说明修复的是哪个 bug、用了什么方法、可能引入什么副作用。
维护黑洞：当代码库变成债务
Gewirtz 在系列文章中反复测试的一个命题是：氛围编程项目既"令人惊叹"又"工作量巨大"。
这种矛盾来自一个被低估的维度——时间。AI 能在几分钟内生成原型，但后续的维护成本不会因此消失。当原始提示词被遗忘，当生成代码的上下文丢失，修改和调试的难度可能超过从头重写。
他对比了两种场景。传统开发中，开发者对自己的代码有完整的心智模型。氛围编程中，这个模型被 AI 的随机性切割成碎片。六个月后再看这段代码，使用者可能和第一次阅读开源项目的陌生人没有区别。
更隐蔽的风险在于技术债务的累积速度。AI 倾向于选择能立即运行的方案，而非长期可维护的架构。当多个 AI 生成的模块相互耦合，系统可能陷入"能跑就别动"的僵局。
控制幻觉：你以为在驾驶，其实在副驾
第一个需要破除的迷思是"失控恐惧"。
Gewirtz 指出，工程经理管理外包团队的历史可以追溯到金字塔时代。分配任务、验收成果、把控质量——这些能力在 AI 编程中依然适用。真正的挑战不是控制权丧失，而是控制方式的转变。
从直接阅读代码，转向设计测试用例和验收标准。从逐行审查，转向架构层面的约束设定。这种转变对许多开发者并不自然。
他建议把 AI 当作一个能力极强但沟通成本较高的合作者。需要更精确的需求文档，更严格的接口定义，更自动化的回归测试。这些基础设施的投入，决定了氛围编程是加速器还是债务制造机。
可持续性的三个检查点
基于多次项目实践，Gewirtz 提炼出一套维持 AI 编程项目健康度的方法。
第一，提示词版本化。像管理代码一样管理提示词，记录每次改动的上下文和目标。这相当于为 AI 的"决策过程"保留审计线索。
第二，强制人工验收。每个 AI 生成的功能模块必须通过人类设计的测试集，才能进入主干。测试即文档，测试即契约。
第三，定期重构窗口。设定固定周期，专门用于偿还技术债务。AI 生成的代码不会自动变干净，需要主动干预。
这些方法的核心是把 AI 从"替代者"重新定位为"加速器"。代码的最终责任仍在人类一方，这个边界不能模糊。
承包商模式的回归
Gewirtz 的最终判断是：AI 编程不会消灭软件工程师，但会改变工程师的工作性质。
从亲手建造，转向设计建造规则。从编写实现，转向验证实现。从个体技艺，转向系统工程。这种转变在 IT 行业历史上发生过多次——从机器码到高级语言，从单体应用到微服务，每次都有人预言"程序员末日"，每次都有新的复杂层涌现。
氛围编程的真正风险不是技术失败，而是组织能力的错配。当管理层相信"AI 能替代工程师"，而工程师尚未建立"管理 AI"的新技能栈时，项目会陷入最危险的中间状态。
那个洛杉矶餐厅的夜晚给 Gewirtz 的教训是： novelty 不等于 quality，speed 不等于 sustainability。AI 编程工具提供了前所未有的 novelty 和 speed，但 quality 和 sustainability 的账单，终究要有人支付。
现在他每次启动 AI 编码会话前，会先打开一个空白文档写下验收标准——就像当年给外包团队写技术规范书一样。
热门跟贴