氛围编程，调试的终结？

微信 ezpoda免费咨询：AI编程 | AI模型微调| AI私有化部署
AI模型价格对比 | AI工具导航 | ONNX模型库 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

这篇文章是对上周一篇关于日志进展的前一篇帖子的后续。一位同事对我提出的"我们很快将运行自己不完全理解的代码"这一观点提出了质疑。他持怀疑态度。我们仍然会是编写代码的人，对吧？只有你写过的代码你才能维护，对吧？……对吧？

这是假设——但它已经在瓦解。

1、你不再需要编写（甚至阅读）每一行代码

我给他举了一个简单的例子。我需要一个表单中的拖拽排序功能。我以前做过，但这次我让 Cursor 来做：把这个 React 组件拿去做，让行可拖拽，持久化排序顺序，并生成测试。

它做到了。我运行了测试，全部通过；然后我在从未打开代码的情况下发布了这个功能。不是因为我不能，而是因为我不需要。这并不意味着我总是盲目发布。大多数时候，我仍然会审查，但我不需要审查的情况越来越常见了。

这并非医疗事故或 vibe-coding。信任来自两件事：我知道如果出问题我能调试和修复，而且我有足够的验证来判断输出是否可靠。如果代码能工作、通过测试、交付了功能，我不需要微观管理每一行代码。这种转变已经到来——而且还在加速。

2、已经习惯于放弃控制

这让我回到了站点可靠性的话题。生产系统也走在同样的轨道上。我们正在步入这样一个世界：软件在自我监控，预测故障，并在人类察觉之前悄悄地修复它们。想想空客建议飞行员在湍流中保持自动驾驶：计算机不会恐慌或过度修正；它们平稳地度过。这就是运维的未来——系统能够吸收颠簸，而不需要你抓住控制权。

这种转变不会消除人类，但它确实改变了工作方式。我们不会再整天盯着图表，因为关键决策不会在仪表板中可见。Elastic、Grafana 和 Splunk 等供应商不会消失，但它们需要在一个软件在警报触发之前就自行诊断和纠正的世界里重新定义自己的价值。

而且这发生得比你想象的更快。不是因为技术缓慢且可预测地成熟，而是因为激励是残酷的：最先消除停机和值班电话的公司将拥有不可撼动的优势，而其他所有人都将争先恐后地跟进。在短短几年内（抱歉，我是说几周），默认的假设将是你正在为 MCP 构建——即标准的机器控制平面，它消费你的日志、解读你的信号并代表你采取行动。如果你不为其编写代码，你将被抛在后面。

3、更强大的原语（我们可能并不完全理解）

最后我想说这些。我主修计算机工程。我知道如何在 FPGA 上设计 8 位微处理器……在 1990 年代末。你认为我完全理解我正在写字的笔记本电脑中的 Apple M4 芯片吗？概念上，是的——我理解原理。但我不知道它做的每一件事，逐条指令地。而这没关系。

我们一直都在接受这种抽象。正如 Edsger W. Dijkstra 所说："抽象的目的不是模糊，而是创造一个新的语义层次，在其中我们可以绝对精确。" 抽象给了我们新的构建块——更小、更锐利的思维单元——让我们不再担心每个晶体管，而是在处理器、操作系统或语言的层面上进行设计。

代码生成即将再次重新定义这个构建块。它不仅仅是另一个抽象层；它是我思考软件的一个新"原子"。一旦这种转变站稳脚跟，我们将开始升级——不是因为我们知道得更少，而是因为我们正在使用更强大的原语。

原文链接: The End of Debugging

汇智网翻译整理，转载请标明出处