从 MCP 到本地工具链，CLI 博客需要新的分类方式

旧分类为什么失效

如果把 CLI 相关内容仍然分成“产品新闻”“教程”“工具推荐”这几类，今天已经越来越不够用了。因为很多变化同时跨越了多个层级: 它既是一个产品发布，也是一个工作流变化，还是一个接口层变化。

例如，MCP 相关内容表面上像协议新闻，但它又直接影响本地工具如何接入模型、编辑器如何调用外部能力、CLI 如何组织上下文。把这种变化简单塞进“协议”或“AI”栏目里，读者往往看不出它和自己工作方式的关系。

这就是为什么 CLI 内容比普通软件资讯更需要结构。它涉及的不是单个应用，而是一整条从终端表面、工具链、协议层再到团队协作方式的链路。

更适合 CLI 的三层结构

对 cli.news 这样的站点来说，更适合的不是按厂商或产品线硬切，而是按变化发生的层级来组织。

第一层是工作表面，也就是 terminal、shell、IDE 内置终端、浏览器实验界面这一类直接承接操作的入口。第二层是工具链，也就是 CLI、本地代理、脚本、模板与自动化链路。第三层是协议与连接层，包括 API、MCP、远程执行接口和协作集成。

当一篇文章进入系统时，我们要先判断它主要改变的是哪一层，然后再决定它与哪些教程、目录或 studio 练习有关。这种组织方式更容易让不同层级之间形成连续阅读关系。

• 工作表面 入口在哪里，用户如何看到和操作它。

• 工具链 实际的命令、脚本、代理和组合方式如何变化。

• 协议层 工具之间如何连接，权限和上下文如何流动。

从发布追踪转向工作流追踪

很多技术媒体习惯以“谁发布了什么”来组织内容，但对 CLI 读者来说，更重要的往往是“这会不会改变我的工作流”。这两者并不总是一回事。

一个小的版本更新，如果改变了下载入口、引入了新的上下文机制或影响了团队协作边界，实际意义可能远大于一篇单纯的功能列表。同样，一个看似大的发布，如果没有改变真实使用路径，未必值得被放到核心位置。

因此，CLI 博客不该只像发布公告的整理器，而应该更像一个工作流观察器。它要帮助读者判断某个变化会影响谁、影响哪一层、以及应该接到站点的哪个位置去继续阅读。

博客结构应该做什么

如果 /blog 只是把文章按时间倒序排出来，那么它只能解决“最近发了什么”，却解决不了“我该从哪条线理解这个世界”。真正有用的博客结构，应该至少做三件事。

1. 把文章放进长期主题，而不是只放进日期流。
2. 让文章和教程、目录、实践入口之间能互相跳转。
3. 帮助读者区分“这是一条短期新闻”还是“这是一条长期结构变化”。

这也是为什么我们把 /news 改成 /blog。前者更像滚动信息流，后者更适合承载判断、专题和持续积累的主题文章。

对 CLI 世界来说，变化会越来越快，但真正有价值的内容，应该让读者在速度之外也能看到结构。