最近我们发布的 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 负责记录协议该怎么工作。

你接口里返回的 JSON（RFC 8259）、浏览器里种的 Cookie（RFC 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。