1998年愚人节，IETF发布了一份正经的RFC文档，定义了"超文本咖啡壶控制协议"。27年后，一位开发者用AI工具花了8小时，把它变成了能跑的生产级仪表盘。
这不是考古，是复活。
一个没人当真过的协议
HTCPCP（Hyper Text Coffee Pot Control Protocol，超文本咖啡壶控制协议）诞生于1998年4月1日，RFC编号2324。作者Larry Masinter当时在MIT工作，他写了一份格式规范的协议文档，定义了BREW、PROPFIND等方法，甚至还规定了Accept-Additions头部来声明你要加奶还是加糖。
最著名的是418状态码：I'm a teapot。当你试图用咖啡壶协议向茶壶发送冲泡指令时，服务器必须返回这个错误。
这个玩笑被写进了HTTP标准文档的附录，成了程序员之间的暗号。你在GitHub上搜"418"，能找到17万个相关项目。但27年来，几乎没人真的实现过一个能交互的HTCPCP控制台。
直到今年愚人节前夕，一位叫Ivan的开发者提交了BrewOps。
8小时，从0到部署
Ivan在DEV社区的提交记录显示，整个项目用Google AI Studio完成。不是Copilot那种代码补全，是端到端：AI帮他搭Next.js脚手架、写Tailwind样式、设计模拟终端的滚动日志逻辑，最后直接部署到Google Cloud Run。
他给的指令很具体："要有那种严肃开发者工具的深色模式美学"。
出来的东西确实像回事。左侧是设备列表，显示你的咖啡壶和茶壶网络；中间是操作面板，下拉选择Accept-Additions（牛奶/糖浆/酒精）；右侧是实时终端，滚动显示BREW请求的响应头。当你选中"Earl Grey Teapot"却点冲泡咖啡时，界面会触发418错误，弹出一个弹跳的茶壶动画。
Ivan申报了两个奖项：致敬Larry Masinter奖，和最佳Google AI使用奖。
第二个奖项的申报理由写的是："整个应用从零到部署，全部由AI代理完成。"
为什么偏偏是这个玩笑
我问过几个全栈工程师朋友，他们第一反应是：这玩意儿有什么意义？
但Ivan的提交说明里有一句话："Tired of walking to the breakroom only to find the coffee pot empty?"（厌倦了走到茶水间发现咖啡壶空了？）这是典型的产品经理话术——先讲痛点，再讲方案，哪怕这个痛点是编的。
HTCPCP的荒诞感恰恰在这里：它用正经的协议格式解决一个不存在的问题。BrewOps的UI越严肃，这种反差就越强烈。深色模式、终端日志、实时状态监控——全是DevOps工具的标准配置，但监控的对象是虚拟咖啡壶。
这种"用生产级态度对待无意义事物"的做法，在开发者圈子里是一种特定的幽默。类似的有：用Kubernetes编排家用路由器，或者给猫做OKR看板。
但BrewOps的不同之处在于，它完全由AI生成。
AI生成代码的边界测试
Ivan公开了Google AI Studio的项目链接。从对话记录能看出，他没有写一行原始代码，全部通过自然语言指令迭代。第一轮是"做一个HTCPCP仪表盘"，第二轮是"加上418错误的动画效果"，第三轮是"终端日志要有那种黑客帝国的感觉"。
每一轮AI都直接修改代码并重新部署。
这引出了一个实际问题：当AI能完整实现一个功能明确、边界清晰的小项目时，开发者的角色变成了什么？Ivan的答案是"产品定义者"——他负责提出需求、验证效果、决定什么时候算"完成了"。
但BrewOps的代码复杂度有限。它不需要处理并发，不需要持久化存储，甚至不需要真实的硬件连接。当Ivan试图让AI实现"用真实HTCPCP协议控制树莓派咖啡机"时，对话记录显示他遇到了阻碍：AI反复生成模拟代码，无法正确处理GPIO引脚调用。
边界就在这里。AI能完成"看起来能跑"的演示，但跨到物理世界时，幻觉问题依然明显。
418的遗产
Larry Masinter现在在Adobe做标准架构师。2014年有人提议从HTTP标准中移除418状态码，理由是"浪费代码点"，被他亲自下场阻止。他在邮件列表里写："有些事物之所以存在，是因为它们让人微笑。"
BrewOps的GitHub仓库里，有人开了个issue：建议支持HTCPCP-TEA扩展协议，也就是RFC 7168。这是2014年的另一个愚人节RFC，定义了茶壶控制协议。
Ivan回复说："AI说可以试试，但我得先确认它不会把两个协议搞混。"
如果明年有人用AI生成一个同时支持HTCPCP和HTCPCP-TEA的统一控制台，你会想去部署一个吗？
热门跟贴