程序员每天都在遵守 RFC，只是自己不知道

最近我们发布的 x-cmd v0.9.13对x rfc ls做了两个小调整修复了管道或重定向时输出空表的问题把非交互场景下的默认输出从CSV 改成了 TSV。改动不大都是为了让x rfc在脚本和自动化场景里更顺手。借这个机会聊聊 RFC 本身。很多开发者觉得 RFC 离自己很远长长的编号、干巴巴的英文文档看起来像是网络工程师才会去翻的东西。但实际上你每天都在按它定的规矩写代码。RFC 一直在你身边RFC 全称 Request for Comments是 IETF 维护的文档系列。HTTP、TLS、DNS 这些互联网的基础协议都写在 RFC 里。不过“协议”这个词还是太远了说点你手边的。拿 404 说。你随便访问一个不存在的页面不管是浏览器、Nginx还是用 Go、Java、Rust 写的后端返回的都是同一个数字。这不是谁跟谁私下约定过而是大家都照着 RFC 9110 里那张状态码表在实现。Cache-Control也一样前端、后端、CDN 对同一个 Header 理解一致靠的不是默契是文档把每种取值的行为写死了。这些约定不是某个框架发明的。框架负责实现RFC 负责记录协议该怎么工作。你接口里返回的 JSONRFC 8259、浏览器里种的 CookieRFC 6265背后也各有各的那份。平时你感觉不到它们的存在。可一旦遇到需要确认“约定俗成的规范到底是什么”的时刻比如一个 Header、一个状态码、一个参数往往还是要回到 RFC那是最接近标准答案的一手资料。具体到日常RFC 能帮我们什么RFC 的价值不是让你每天背协议。它真正派上用场的通常是这三种时刻。开发时它是争议的裁判。很多问题看起来像 Bug其实只是理解不同。比如一个 Header 到底应该怎么解释Expires和max-age同时出现时哪个优先Cookie 为什么没有按照预期发送博客、教程可能给出不同答案但 RFC 能告诉你协议原本如何定义。设计时它是别人已经想清楚的答案。设计一个和互联网交互的系统时哪些内容应该缓存、哪些操作应该幂等、错误该如何表达这些问题其实都被前人反复讨论过。RFC 不会替你完成业务设计但它能让你少重新发明一些已经存在的约定。协作时它是共同语言。跨团队、跨语言栈开发时最容易出现的问题是每个人都按照自己的经验理解同一个概念。一句“按照 RFC 6265 的 Cookie 规则处理”往往比解释半天更有效因为大家参考的是同一份公开资料。没人看不是因为没价值既然天天都在用为什么没什么人读过我觉得这不能怪大家。对普通开发者来说以前根本没有理由直接接触它。框架把协议封装好了教程把格式总结好了。真遇到疑问搜博客、去 StackOverflow 抄个高赞答案也比翻几十页干巴巴的英文原文划算得多。久而久之“RFC 离我很远”就成了一种集体错觉天天在遵守却从没翻开过。大家都知道它有只是很少觉得值得打开。AI 改变了使用 RFC 的成本其实有了搜索引擎之后RFC 一直在那里谁都能找到。拦住人的从来不是“找不到”是“读不动”。AI 砍掉的正是“读”这一段成本。过去确认一个 Header 字段意味着翻几十页英文现在只需要一句话。它对普通开发者的意义也跟着变了从“知道有却很少打开”变成日常里真正用得上的东西。RFC 从来不是新东西真正变新的是 AI 让它变成了一份可以随手参考的资料。当然AI 要替你读 RFC手头也得有一件趁手的工具能快速检索、拉取原文一条命令就够。所以我们最近也顺手把x rfc打磨了一下让它在脚本、终端和 AI Agent 里都更好用一些。把x rfc --help扔给你的 AI Agent它自己就知道该怎么调用。毕竟今天真正需要读 RFC 的很多时候已经不是人而是 AI。