从Skill开发到架构设计：AI应用开发中的微服务式实践与感悟

这两天正在调试一个自动创作文案的 Skill 工作流，目标是实现从选题到发布的全流程自动化。

当然，这套系统并非为此公众号准备——这里的文章依然坚持99%手工打造，以确保分享的真诚与深度。在此，我想聊聊近期开发 Skill 过程中的几点有趣发现。

从程序到 Skill，再到 Agent 的演进

一切的起点很简单：一段精心设计的提示词。最初，我每次都手动将其复制到大模型的聊天框中执行。

为了提升效率，我开发了一个浏览器插件。只需输入主题，点击按钮，插件便会自动组合主题与提示词，填入输入框并提交。

随后，这个工具进化成了 Gemini APP。它能够根据关键词进行多维度选题，最终生成完整的文章，甚至自动添加配图。

至此，虽然深度借助了 AI，但创作工具的载体本质上仍是“程序”——无论是浏览器插件还是 APP，都由代码构建。

后来，随着 Claude Code 等智能开发环境的兴起，以及 Skill 概念的普及，我将这套流程整个迁移进了 Skill 体系中。

Skill 再向前一步，便会演变成一个拥有交互界面的 Agent。那么，这个 Agent 是否又变回了最初的 Gemini APP 呢？形式或许相似，但内核与构建范式已截然不同。

写 Skill，也是在设计架构

随着功能不断叠加——从选题库获取灵感、依据提示词生成文案、自动配图、对生图提示词进行优化、回写选题库状态，并且生图功能本身还要支持多个不同的渠道——项目的复杂度悄然上升。

某天，我注意到项目左侧那庞大的目录结构。虽然只是为了实现一个自动化流程，但不同的功能被拆分成了独立的 Skill，这些 Skill 之间相互调用、协同工作。

这场景瞬间让我回想起几年前埋头构建微服务系统的日子：将一个单体系统拆分为数个独立的服务，服务间通过明确的接口进行通信。

区别在于，过去我用 Java 编写，依赖 Spring Cloud、Dubbo 等框架；而现在，我用的是 Skill 和智能体协议。短短几年间，开发范式的变迁着实有些神奇，甚至令人恍惚。

以生图功能为例，目前它需要支持 Nano Banana、Z-Image 等不同渠道，并能根据调用方的参数自动适配。未来还可能接入即梦等新渠道，因此必须预留足够的扩展性。

这不就是在进行架构设计吗？需要考虑模块化、解耦、接口抽象和未来的可扩展性。

过去先找 SDK，现在先找 MCP

以往需要集成第三方服务时，开发者的第一反应是寻找官方的 SDK 或查阅在线 API 文档。

而现在呢？我的第一反应变成了：先去搜一下官方有没有提供 MCP 协议支持。例如，当我计划用飞书多维表格作为选题库时，虽然早年也调用过它的 API，但我并没有去翻旧代码或找API文档，而是直接在搜索引擎中键入了“飞书 MCP”。

结果，还真有。

这种转变意味着，我们与外部服务交互的“接口”正在从代码层面的 API 调用，向更声明式、更智能化的模型上下文协议演进。这或许正是 AI 时代带给开发者工作流的一个显著变化。

本文由云栈社区发布，一个专注于分享与交流的技术社区。