AI 时代的平台工程
两个月前，正是我 Aha moment 不断，多巴胺爆炸的时刻，每天都会记录下很多灵感和想法，准备在未来写成文章，或者开发成工具。
其中有一条是这样的：
AI 时代的平台工程（CLI+Skill+MCP，可访问所有基础设施，比如拉取知识库，读取 story，拉取流水线信息并修复，所有的点都集中到了 CLI 工具上，CLI 就是 AI 时代的平台门户）
这个想法一直躺在 to do 列表的最底下，优先级被无限拉低。因为我觉得这个想法太超前了，现在的开发人员甚至还不愿意离开 IDE 去拥抱 CLI。
然而就在今天，客户发来了一个需求：
希望能在 Claude Code 里把需求列出来，代码开发完，质量流水线检查通过，mr 发起且成功进入 release，部署到测试环境。这个链条全 AI 化。
更进一步，本地可以启动多个 Agent，其中一个得去检查我的代码构建流水线是不是通过了，如果没通过，得自动去修复我的开发分支才行。
看完客户的需求，我知道，是时候了。
CLI 带来的想象
我当时盯着这条需求看了很久。
不是因为它有多复杂。这种程度的自动化，单拆每一个步骤，技术上都没什么新鲜的。Jenkins 能跑流水线，GitLab 能发 MR，Kubernetes 能部署，这些早就是标配了。
但把这些东西串成一条链，让 Agent 在 CLI 里一口气跑完，中间不需要人插手，这事儿就有点不一样了。
你想想看这个画面。
你坐在电脑前，打开终端，跟 Claude Code 说，「帮我实现这个需求」。Agent 去读 story，理解要做什么，然后打开代码库开始写。写完跑测试，挂了，自己修。修完发起 MR，MR 的流水线又挂了，它去查日志，定位问题，再修。全部通过之后，合并进 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 可以直接操作基础设施，如果自然语言可以替代表单和按钮，如果开发者不需要学习一套新的界面就能使用平台能力，那「门户」这个中间层还有必要存在吗？
我觉得，CLI+Skill+MCP 架构下的平台工程，不是在现有门户上加一层 AI，而是重新思考平台能力的交付方式。
Skill 就是平台能力的原子单元。一个操作 GitLab 的 skill，一个查询流水线的 skill，一个部署的 skill。这些 skill 可以被组合，被复用，被不同的 Agent 调用。它们的目标用户不是「人」，而是「Agent」。
这有点像从 SOA 到微服务的演变。以前我们以为服务必须通过统一网关暴露，后来我们发现服务之间可以直接通信。同样，平台能力以前必须通过门户暴露，现在 skill 之间可以直接协作，CLI 只是一个最自然的入口。
当然，我不是说开发者门户会消失。需要可视化、需要审批、需要非技术人员参与的场景，门户仍然有价值。但对于开发者日常的工作流，CLI+Agent 可能是更优的体验。
CLI 即门户
写到这里，我回头去看客户那条需求。
我现在觉得，这个需求描述的不是一个「功能」，而是一种「工作方式」。
在这种方式里，开发者不再是各个环节的搬运工。他们提出需求，Agent 负责执行。开发者的角色从「操作者」变成了「指挥者」。
两个月前，我在那个只有 markdown 文件的 folder 里，看到了个人工具的极简形态。
今天，我又看到了这种极简形态在团队工程实践里的投射。
也许几周之后，我们实现了这套围绕 CLI 的平台工程之后，我会有更多的心得分享。
时代的瞬变
最后，我想聊聊最近几个月的飞速变化。
两个月前我自认为超前的想法，在两个月后已经被客户提出来了。这说明什么？
敏捷二十年，我们仍然是行业领先。
DevOps十年，我们仍然可以吃到时代红利。
然而AI时代，仅仅两个月，客户就和我们站在了同一起跑线上。
这说明，AI 时代的技术变革正在以肉眼可见的速度发生。我们不再是站在时代的边缘看风景，而是直接被卷入了这场风暴。
作为咨询师，我们必须躬身入局，置身事内，亲历风暴中心，get your hands dirty。
否则，被超越和被取代只是时间问题。