两个月前正是我 Aha moment 不断多巴胺爆炸的时刻每天都会记录下很多灵感和想法准备在未来写成文章或者开发成工具。其中有一条是这样的AI 时代的平台工程CLISkillMCP可访问所有基础设施比如拉取知识库读取 story拉取流水线信息并修复所有的点都集中到了 CLI 工具上CLI 就是 AI 时代的平台门户这个想法一直躺在 to do 列表的最底下优先级被无限拉低。因为我觉得这个想法太超前了现在的开发人员甚至还不愿意离开 IDE 去拥抱 CLI。然而就在今天客户发来了一个需求希望能在 Claude Code 里把需求列出来代码开发完质量流水线检查通过mr 发起且成功进入 release部署到测试环境。这个链条全 AI 化。更进一步本地可以启动多个 Agent其中一个得去检查我的代码构建流水线是不是通过了如果没通过得自动去修复我的开发分支才行。看完客户的需求我知道是时候了。CLI 带来的想象我当时盯着这条需求看了很久。不是因为它有多复杂。这种程度的自动化单拆每一个步骤技术上都没什么新鲜的。Jenkins 能跑流水线GitLab 能发 MRKubernetes 能部署这些早就是标配了。但把这些东西串成一条链让 Agent 在 CLI 里一口气跑完中间不需要人插手这事儿就有点不一样了。你想想看这个画面。你坐在电脑前打开终端跟 Claude Code 说「帮我实现这个需求」。Agent 去读 story理解要做什么然后打开代码库开始写。写完跑测试挂了自己修。修完发起 MRMR 的流水线又挂了它去查日志定位问题再修。全部通过之后合并进 release 分支触发部署到测试环境。整个过程里你没有打开 Jira 看任务状态没有打开 GitLab 看 MR 进度没有打开 Jenkins 看流水线日志。甚至没有打开 IDE。所有的东西在一个界面里完成。用自然语言说话就行。这听起来像科幻吗说实话两个月前我也觉得像。但那个礼拜我搞了 7 个智能体之后我意识到一件事。markdown 即需求skill 即功能大模型即解释器命令行即软件。那个只有几个 .md 文件的 folder 里发生的事情和客户的这个需求其实是同一件事。只是规模不同。这么做可行吗说到这我需要正经聊聊这个架构的可行性。不然你肯定觉得我只是在画饼。CLI 作为入口skill 封装业务能力MCP 连接外部系统。这三件套听起来挺抽象的但每一层都有对应的东西在。CLI 这层不用多说。Claude Code、Codex CLI这些工具已经证明了开发者可以在命令行里完成从需求到代码的全过程。不是「可以」是「已经在发生」。我自己过去两个月的日常工作几乎都在 Claude Code 里完成IDE 打开的次数屈指可数。Skill 这层其实就是前阵子我说的「skill 即功能」。每个 skill 是一个 markdown 文件描述了在特定场景下 Agent 应该怎么做。操作 GitLab 的是一个 skill查询 Jenkins 流水线的也是一个 skill部署到 Kubernetes 的还是一个 skill。它们不是代码是自然语言写的行为说明书。但大模型能读懂并执行。MCP 的作用是让 Agent 可以标准化地访问外部系统比如文件系统、数据库、API 服务。以前你要让 Agent 操作 GitLab得写一堆 API 调用代码。现在有了 MCP你告诉 Agent「用 GitLab MCP 去查一下这个项目的流水线状态」它就知道怎么做了。这三层加在一起形成了一个完整的平台工程能力栈。CLI 是开发者天天在用的环境。Skill 是平台能力的原子单元。MCP 是连接基础设施的通用插头。它不是要取代 Jira、GitLab、Jenkins 这些东西。而是让 Agent 能够统一地、自然地操作这些东西。就像你不需要知道 USB 协议的细节就能用手机充电一样开发者不需要知道 GitLab API 的每一个细节就能让 Agent 去操作它。那么开发者门户呢你肯定会问既然要整合这么多能力为什么不干脆做一个漂亮的 Web 界面开发者门户不香吗坦率的讲这个疑问我也有过。传统的平台工程答案确实是开发者门户。Backstage、Port做得都挺好的。统一的界面有目录有文档有自助服务。应用团队想看部署状态点开页面就能看到。想申请一个环境填个表单就行。但这里有一个问题。开发者门户始终是一个「额外的」东西。你需要打开浏览器登录找到对应的功能点击填表单等待结果。半年前看还是能够节省你去各个平台找页面的时间的但现在来看每一步都在把你从当前的工作流里拉出来。你在写代码突然要去看一下流水线状态你得切换窗口、切换思维、切换注意力。看完再回到代码里刚才的思路已经断了一半。CLI 不一样。你本来就在终端里工作。Agent 就在你手边。你不需要切换上下文不需要改变习惯。打个比方。开发者门户像是一个办事大厅你要办什么业务得走过去取号排队填表。CLI 像是一个贴身的秘书你随口说句话它就去办了。当然办事大厅有它的用处。有些业务确实需要正式的流程需要审批需要留痕。但日常的大部分事情秘书模式显然更高效。而且CLI 里的 Agent 可以并行工作。客户说的「本地可以启动多个 Agent」这在 CLI 环境里是很自然的事情。一个 Agent 写代码另一个 Agent 在后台监控流水线发现问题自动修复。它们通过文件系统或者简单的消息机制通信不需要复杂的协调框架。在 Web 门户里你很难实现这种「贴身且并行」的体验。门户的设计假设是「一个用户在一个页面里做一件事」。那么IDE 呢说到这另一个问题也来了。既然不想离开开发环境那直接集成在 IDE 里不是更自然吗这个问题更有意思。因为最近 IDE 的变化确实有点不一样。VS Code 最新版开始走 Agent 优先的设计路线。Cursor 直接默认就是 Agent 模式。以前AI Agent 是 IDE 的一个插件。你在 VS Code 里装个 Copilot它帮你补全代码。AI 是 IDE 的附属品是锦上添花。但现在角色正在翻转。Cursor 的本质不是「一个更好的 IDE」。它是「一个能写代码的 Agent」。IDE 只是 Agent 用来操作文件的一个工具。Agent 才是主角IDE 在变成配角。IDE 正在变成 Agent 的一个插件。而且像 Codex 桌面版这样的工具已经完全摒弃了 IDE Agent 插件这样的设计它就是一个 Agent或者说是一个有界面的 CLI。它不需要 IDE。我大胆预测一下IDE 将在2026年迎来它的终结。AI 时代的平台工程聊到这我想起平台工程这个概念本身的演变。几年前的平台工程主要解决的是 DevOps 的混乱。每个团队有自己的 CI/CD 配置重复造轮子。平台工程团队的做法是抽象出通用的平台能力然后通过开发者门户暴露给应用团队。这个思路是对的。但它有一个隐含的假设平台能力必须通过一个「门户」来交付。AI 时代的到来让这个假设开始松动了。如果 Agent 可以直接操作基础设施如果自然语言可以替代表单和按钮如果开发者不需要学习一套新的界面就能使用平台能力那「门户」这个中间层还有必要存在吗我觉得CLISkillMCP 架构下的平台工程不是在现有门户上加一层 AI而是重新思考平台能力的交付方式。Skill 就是平台能力的原子单元。一个操作 GitLab 的 skill一个查询流水线的 skill一个部署的 skill。这些 skill 可以被组合被复用被不同的 Agent 调用。它们的目标用户不是「人」而是「Agent」。这有点像从 SOA 到微服务的演变。以前我们以为服务必须通过统一网关暴露后来我们发现服务之间可以直接通信。同样平台能力以前必须通过门户暴露现在 skill 之间可以直接协作CLI 只是一个最自然的入口。当然我不是说开发者门户会消失。需要可视化、需要审批、需要非技术人员参与的场景门户仍然有价值。但对于开发者日常的工作流CLIAgent 可能是更优的体验。CLI 即门户写到这里我回头去看客户那条需求。我现在觉得这个需求描述的不是一个「功能」而是一种「工作方式」。在这种方式里开发者不再是各个环节的搬运工。他们提出需求Agent 负责执行。开发者的角色从「操作者」变成了「指挥者」。两个月前我在那个只有 markdown 文件的 folder 里看到了个人工具的极简形态。今天我又看到了这种极简形态在团队工程实践里的投射。也许几周之后我们实现了这套围绕 CLI 的平台工程之后我会有更多的心得分享。时代的瞬变最后我想聊聊最近几个月的飞速变化。两个月前我自认为超前的想法在两个月后已经被客户提出来了。这说明什么敏捷二十年我们仍然是行业领先。DevOps十年我们仍然可以吃到时代红利。然而AI时代仅仅两个月客户就和我们站在了同一起跑线上。这说明AI 时代的技术变革正在以肉眼可见的速度发生。我们不再是站在时代的边缘看风景而是直接被卷入了这场风暴。作为咨询师我们必须躬身入局置身事内亲历风暴中心get your hands dirty。否则被超越和被取代只是时间问题。