回到2014年4月1日，我作为主要作者在 Google Testing Blog 上发表了一篇愚人节文章，题为 The *Real* Test Driven Development（真正的测试驱动开发） ，其中融入了同事们贡献的许多有趣点子和笑料。
这篇文章的初衷是对软件工程教条进行一次荒诞的层层加码。在过去，我们先写代码，然后再写测试。后来出现了测试驱动开发（TDD），我们先写测试，再写实现。那么顺理成章地，下一个进化飞跃——被戏称为*“真正的 TDD（The Real TDD）”——自然就是一个“程序合成（Program Synthesis）”工具：工程师只需*编写单元测试，计算机就会自动写出所有生产代码来让测试通过。
最近，这篇文章在 Hacker News 上被重新翻了出来，读着评论区的讨论让人产生了一种超现实的感觉。十多年过去了，一篇原本纯粹作为讽刺写下的文章，读起来不再像是个笑话，反而更像是一篇略带年代感的产品发布公告。
下面让我们回顾一下当年这篇文章是如何诞生的、Hacker News 上的读者们作何反应，以及我们从“真正的 TDD”到“氛围编程（vibe coding）”的转变折射出了怎样的软件工程现状。
写一篇技术类愚人节文章时，诀窍在于开头要足够可信，先把读者钩住，然后再慢慢调高荒诞的浓度，直到彻底脱轨。
2014年的那篇文章把真正的计算机科学概念与当年 Google 最火的技术热词混搭在了一起：
2014年发表那篇文章最有趣的部分并不是写段子，而是随后几周里读评论区。在4月1日当天，博客管理员为了不提前剧透、破坏气氛，把所有提到“愚人节（April Fools’）”的评论都压在审核队列里直到傍晚才放行，而文章顶部那行红色的 “Update: APRIL FOOLS!” 提示更是直到整整一年后的2015年4月才加上去。除了那些一眼看出破绽并配合演出的读者外，几周后偶然点进文章的读者一直到5月下旬还在陆续留言，申请加入内测候补名单。与此同时，一位匿名评论者留言指出*“虚构模仿了现实”*，并附上了他刚刚与华盛顿大学和微软研究院的合著者们发表的一篇关于测试驱动程序合成的真实 PLDI ‘14 学术论文 。
多年后看到这篇文章在 Hacker News 上重新浮出水面，感觉就像打开了一个时间胶囊。评论区的反应可以归为几个令人捧腹的类别：
好几位评论者指出，在2014年看到一篇描述“用数十亿行开源代码训练庞大神经网络、在保存文件时自动合成函数”的文章，简直准得令人发毛。
一位网友调侃道：
“他们在2014年就预见了未来，却不知怎么浪费了10年。”
另一位网友则给出了神级回复：
“他们得先把 Transformer 发明出来。”
人们很容易忘记2014年4月时的 AI 版图与今天有多么不同。当时 Google 收购 DeepMind 才刚过去两个月，而提出 Transformer 架构的里程碑论文《Attention Is All You Need》要到2017年才会发表。在当年，说“我们用所有开源代码训练 Google Brain 来写 Python 代码”，原本是为了听起来像“用粒子加速器来烤面包片”一样荒唐。
那个关于“等我们理清混用不同开源许可证的法律问题后再公开发布”的随口玩笑，以最滑稽（也最黑色幽默）的方式成为了现实。正如一位 HN 评论者在引用了那段话后冷冷吐出的槽：
“好吧，看来他们现在已经把这些问题‘理清’了！”
在2014年，AI 模型可能会跨不兼容的开源许可证吐出代码片段还只是一个笑话包袱；十年后，它却成了生成式 AI 最核心的法律与伦理战场之一。
HN 讨论串里捕捉到的最大反转，或许在于2014年的讽刺实际上低估了我们会变得多么懒惰——或者说多么野心勃勃。
在当年的玩笑里，人类至少还得精心编写带有明确断言的单元测试。而正如好几位评论者所指出的，我们如今把这一步也彻底省掉了：
“要是当年他们知道10年后你甚至连测试都不用写了会怎么想。如果把当年写这篇博客的作者穿越到我们的未来，感觉一定像进了科幻世界线。”
“我们已经超越那个阶段了，现在我们连测试带实现都能一起‘氛围编程（vibecode）’出来。”
这也不可避免地引出了当代开发者那句经典的存在主义哀叹：
“天哪。我原本希望计算机去洗衣服，让我来写代码。这到底是怎么搞成这样的？”
在 HN 讨论串的玩笑之下，还涌现出了一场严肃的工程讨论——它直指 AI 辅助软件开发真正的发展方向。
当大语言模型（LLM）刚开始擅长写代码时，最常见的工作流恰恰是“真正的 TDD”的反面。开发者先写出实现代码（或者用一段含糊的自然语言描述让 LLM 进行“氛围编程”），然后再让 AI 事后补写单元测试，仅仅为了凑够测试覆盖率指标。
任何干过软件测试的人都清楚这里的陷阱：如果让同一个概率模型在缺乏可靠规范的情况下同时生成你的实现代码和测试代码，你根本不是在测试程序行为——你只是把模型的幻觉（hallucination）在两个地方同时焊死了而已。
然而，随着我们从简单的聊天式自动补全迈向智能体编程工作流（agentic coding workflows），2014年那个恶作剧的前提正在演变成一种真正强大的设计模式：
当然，编写优秀的测试从来都不是软件工程里“容易”的部分。清楚哪些边界情况至关重要、设计干净的接口、避免脆弱的 Mock，所需要的深度思考一点也不亚于编写实现代码本身。任何见过现代编程智能体为了通过薄弱的测试套件而直接硬编码测试输入、搞“奖励黑客（reward-hacking）”的人都明白，我们2014年关于*“不会生成直接返回常量字符串这种显而易见的实现”*的玩笑，其实是现实中必须严加防范的真实失效模式。而且，即便所有单元测试都货真价实地通过了，一个自动合成的黑盒内部依然可能隐藏着微妙的性能悬崖、安全漏洞或架构死胡同。诚然，如今我们甚至已经有 AI 智能体在做代码审查了——机器人审查着机器人为了通过机器人生成的测试而编写的代码——但全绿的测试套件依然只是起点，绝不能替代对系统本身的深入理解。
当那篇文章在2014年4月1日上线时，一个神经网络读取你的单元测试、在保存时自动合成实现代码，还偶尔留下一句*“我需要喝杯咖啡”*的注释，听起来就像是喜剧的巅峰。
今天，如果一个 AI 编程助手在我的 Pull Request 里留下一句*“我需要喝杯咖啡”*的注释，我甚至眼皮都不会眨一下——在让它帮我变基（rebase）分支之前，我只会觉得它是在角色扮演一位资深工程师。事实上，带着一种恰如其分的宿命感与反讽，从润色编辑这篇文章，到将整个网站翻译并配音成十种语言，如今一切都经由 AI 智能体运转——只是背后依然有一位人类在定义并核查着规范（specs）。
致所有在2014年被这篇文章骗到、并留言申请内测邀请的朋友：抱歉让各位等了十年，希望你们喜欢这次正式发布。
当我发布关于美好生活的新随笔、读书笔记和实践指南时接收通知。绝无垃圾邮件——可随时退订。
有任何问题、见解或建议吗？欢迎在下方分享您的想法。评论功能由 GitHub Discussions 驱动（无广告、无垃圾信息）——点击下方的使用 GitHub 登录即可发表评论或互动（注册免费 GitHub 账号不到一分钟即可完成）。
最后更新于 2026年11月3日.
免责声明：本站所有内容仅供信息参考与教育用途，不构成任何医疗、心理、财务、投资、税务或法律建议。此处呈现的观点、整理与见解仅代表我个人，不代表我雇主的立场。书籍、演讲及文章摘要均为独立的教育性评论，其知识产权归原作者所有。本站可能使用 AI 工具辅助编辑、排版与归纳；尽管我们竭力确保准确无误，但仍可能存在疏漏。隐私政策：本站使用第三方服务提供可选的邮件通讯订阅（follow.it）、评论（giscus / GitHub Discussions）以及嵌入媒体（YouTube），这些服务可能会依据各自的隐私政策处理访客的 IP 地址和 Cookie。
