一句话画出系统架构图这个说法乍听上去更像夸张的标题党。但如果你在一个支持 Skill 的 AI 编程助手里试过输入“把订单服务、用户服务、商品服务画成一张架构图标出互相调用关系”几秒钟后看到一张结构清晰的系统架构图落地你会意识到这不是演示动画而是已经能放进实际项目文档里的生产力工具。这件事最近在开发者圈子里讨论度很高。Skill 这个词从“AI 圈的黑话”迅速变成了“干活的时候真的会用的武器”。很多人第一反应是去问“哪个 Skill 最好用”但真正常被忽略的问题是为什么一句话就能画出系统架构图这句话背后的机制是什么如果你自己要用、要调、要写一个这样的 Skill又该从哪下手这篇文章不准备做热门 Skill 清单式的搬运而是把 Skill 这件事拆开讲清楚它到底解决什么问题、内部是怎么运转的、一个画架构图的 Skill 是怎么从零写出来的、以及它和普通 Prompt、Agent、插件之间到底是什么关系。看完之后你会发现Skill 的真正价值根本不在于多一句少一句提示词而在于把人的经验固化成了一套可复用的工作流。1. 先弄清楚这句话能画出图到底是 AI 的功劳还是 Skill 的功劳1.1 一张架构图背后至少发生了四件事当你说“把订单服务画成系统架构图”时很多人以为模型天生就能画图。实际上模型不会直接输出一张 PNG 图片它做的事是先理解需求再设计架构表达把结果转换成一种图描述语言最后交给渲染工具出图。整个过程可以拆成这样需求解析从一句话里提取出系统边界、服务名称、关系类型。结构设计决定图里放哪些模块、哪些放子模块、哪些用数据库、哪些用消息队列。格式生成把设计好的结构写成 Mermaid 或 Draw.io 能识别的文本语法。图像渲染渲染工具读取文本生成 SVG、PNG 或 HTML 页面。这里有一个容易误判的点AI 在第一步和第二步里表现得很聪明会让你觉得它“懂了架构”。但真正让它稳定输出可渲染文本的其实是第三步和第四步的结构化约定。如果没有这些约定同一个模型可能这次生成 Mermaid下次生成 PlantUML再下次直接输出一段含糊的自然语言描述图就画不出来了。所以一张架构图的价值一半靠模型的推理能力另一半靠的是“把推理结果约束成标准格式”的流程。1.2 Skill 和普通 Prompt 的本质区别可复用、可编排、可调用工具如果你用过 ChatGPT 或同类产品应该试过在提示词里写“请用 Mermaid 画一个订单系统架构图”。这句话在某些时候也能生效。那为什么还要 Skill区别在于普通 Prompt 是一次性指示Skill 是固化下来的操作流程。同一个需求普通 Prompt 每次生成的质量取决于模型当前状态、上下文干扰和提示词本身的完整程度。而 Skill 把以下内容预置好了何时触发用户说哪些关键词时启用。执行步骤先做什么、后做什么、每一步的输入输出是什么。格式规范最终必须输出什么语法。工具调用是否需要调用渲染工具、是否需要读取文件、是否需要保存结果。边界处理信息不足时怎么办语法错误时怎么修正。换句话说普通 Prompt 像是你临时给一个聪明同事口述了需求而 Skill 像是给这个同事一份经过验证的作业指导书。同一个聪明人有了指导书之后产出质量会稳定得多尤其是面对重复任务的时候。这也是“一句话画出系统架构图”能被当成一个产品卖点的原因它不是依赖模型超常发挥而是把一次成功经验压缩成了可复用的固定流程。2. 拆开一个“画架构图 Skill”的内部结构2.1 描述文件告诉 Agent 什么时候该用这个 Skill市面上的 Skill 包不管叫什么名字核心组织方式大同小异。通常一个 Skill 会包含一个描述文件、若干规则文件、可能还有脚本和模板。描述文件是入口里面写明这个 Skill 的名称、用途、触发条件和使用说明。一个画系统架构图的 Skill描述文件通常会长这样--- name: system-architect description: 适用于把系统描述、服务清单、业务流程转换为系统架构图。 trigger: - 架构图 - 系统图 - 模块关系图 - 架构设计 - 服务调用关系 --- # 使用说明 当用户要求绘制系统架构图时按以下流程执行 1. 先列出用户提到的所有服务、模块、存储和外部依赖。 2. 识别服务之间的调用关系、数据流向和依赖方向。 3. 使用 Mermaid 语法输出架构图。 4. 如果用户没有指定技术栈默认使用通用架构图风格。这段描述不是给用户看的是给 Agent 看的。Agent 拿到这段描述后会把它当作任务执行的附加约束。Skill 能否被正确触发很大程度上取决于这段描述写得好不好。这里的核心原则是描述越明确触发越稳定步骤越具体输出越一致。2.2 执行步骤从自然语言到结构化输出的转换流程很多人写 Skill 时只写了“描述”和“触发条件”没有写执行步骤。结果就是Skill 确实被启用了但输出质量完全看运气。真正有效的画架构图 Skill会把从自然语言到架构图的转换过程拆成可检查的步骤。举例来说一个面向微服务架构图的 Skill可以把处理流程定成这样提取实体列出所有明确提到的服务、模块、中间件、数据库、外部系统。确认边界判断哪些实体属于内部组件哪些是外部依赖。识别关系找出服务间的调用、数据流、依赖、继承、聚合等关系。选择图类型根据关系复杂度决定用层次架构图、调用关系图还是部署拓扑图。生成 Mermaid按标准语法输出节点命名规范关系方向一致。自检检查节点是否有孤立项检查关系是否有未定义节点。这套步骤看起来简单但它的意义在于让 Agent 不再“自由发挥”。尤其当你处理复杂系统时没有步骤约束的模型往往会漏掉数据库、漏掉外部依赖或者把调用方向画反。2.3 输出模板为什么必须用 Mermaid 或 Draw.io 这类中间格式“一句话画出系统架构图”里最容易被低估的一环是输出模板。AI 不可能直接输出位图。它需要一种既接近自然语言、又能被程序解析的中间格式。Mermaid 是目前最流行的选择之一因为它的语法足够简单文本形态易于生成而且可以被很多渲染工具转换。一个典型的 Mermaid 架构图这样写graph LR A[前端应用] -- B[API 网关] B -- C[订单服务] B -- D[用户服务] C -- E[(订单数据库)] C -- F[消息队列] F -- G[库存服务] D -- H[(用户数据库)]这段内容的可读性很强模型不容易学歪而且渲染工具成熟。Draw.io 则更偏图形编辑场景支持的位置和样式更丰富但语法组织成本也更高。在 Skill 设计里输出模板的作用是“把好结果固定下来”。你不需要每次让模型自己想怎么画而是告诉它遇到这类任务默认就用这套语法结构、这套命名方式、这套布局逻辑。这会让输出质量变得极其稳定。3. 从零写一个可以“一句话画图”的 Skill3.1 设计输入想清楚用户会用哪些方式来描述一张图写 Skill 的第一件事不是写步骤而是确认输入边界。你要先想清楚用户可能用哪些话触发这个 Skill常见输入大概分三类直接指定模块“画一个订单系统包含订单服务、用户服务、支付服务、库存服务。”指定关系“用户服务调用订单服务订单服务发送消息到库存服务。”描述业务场景“我要做一个电商平台包括商品、订单、用户、支付、库存画出它们之间的关系。”如果 Skill 只覆盖第一种输入那一旦用户说“我要做一个电商平台”Agent 可能不知道先要补充需求信息。所以设计输入时需要同时设计“信息不足时怎么办”的规则比如如果用户没有明确提到组件关系先列出基础组件结构。 如果用户只描述了业务需要先推断常见微服务模块再生成架构图。这一步决定 Skill 的“可得性”。很多 Skill 不好用不是因为步骤写得不好而是因为它只能处理用户碰巧说对了关键词的情况。3.2 设计步骤与规则先定边界再填组件最后连关系真正进入 Skill 开发时步骤设计要遵守一个顺序先确认边界再填组件最后连关系。边界决定了图里能出现什么。比如一个订单系统架构图开发者需要确认是否包含部署环境、是否包含外部支付回调、是否包含消息队列、是否包含缓存。有些信息如果用户没给Skill 可以按默认规则处理也可以反问。从工程效率看最好给出一套默认规则避免每张图都要交互。一个通用规则的参考写法默认结构 - 前端 / 客户端 - 网关 / 入口 - 业务服务 - 数据存储 - 中间件消息队列、缓存 - 外部依赖组件填充阶段注意节点命名规范。Mermaid 中节点 ID 最好不要直接用中文可以用拼音或英文缩写展示名称用中文。例如graph LR UI[客户端] -- GW[API 网关] GW -- ORD[订单服务] GW -- USR[用户服务] ORD -- DB[(订单库)]关系连接阶段最重要的是方向的统一。上面这个例子里数据流是从 UI 到服务的调用方向。如果你想展示数据依赖方向可能需要用反向箭头。最好在 Skill 里明确“默认展示请求调用方向”。3.3 接入渲染让图像从文本变成 PNG 或 HTMLSkill 能生成 Mermaid 文本但这只完成了一半。有些使用场景里用户希望直接得到一张图片文件或者一段可以嵌入文档的代码。渲染这一步需要工具支持。常见的路径有三种在线渲染服务调用 Mermaid Live 或类似服务把代码转成图片链接。本地命令行工具用 Mermaid CLI 在本地把.mmd文件转成 SVG 或 PNG。编辑器插件如果你用的是支持 Mermaid 的编辑器或笔记工具渲染是自动的。在实际开发环境里你更需要的是一个可自动调用的本地渲染脚本。大致流程是Agent 生成 Mermaid 文本 → 保存到临时目录 → 调用渲染命令 → 输出图片 → 返回图片路径。伪代码如下# 将生成的架构图保存为 arch.mmd # 调用 Mermaid CLI 渲染 mmdc -i arch.mmd -o arch.png如果当前环境没有安装 Mermaid CLI也可以在 Skill 里加一条规则输出 Mermaid 代码块由用户复制到支持 Mermaid 的在线工具或编辑器里手动渲染。这样 Skill 的学习成本和环境依赖都会更低适合刚起步时跑通流程。3.4 小样本验证先用三条典型输入跑通写完 Skill 后不要立刻拿去处理复杂系统。用三条典型输入跑一遍验证输出是否符合预期。推荐验证顺序最小输入“订单服务、用户服务、数据库。”常规输入“订单系统包含订单服务、用户服务、支付服务支付服务调用外部支付接口订单数据写入 MySQL。”模糊输入“帮我画一个电商系统的架构。”第一条验证的是基本生成能力是否正常第二条验证的是关系识别和外部依赖处理第三条验证的是默认推断逻辑。三条都能稳定输出可用结构后再把 Skill 放进真实工作流里。这条链路看起来简单但很多人写 Skill 时恰恰跳过了小样本验证这一步直接拿真实项目去测结果一会儿能用一会儿不能用很难定位是模型问题、Skill 规则问题还是输入信息不足的问题。4. Skill 真正改变的是什么从一次性对话到可复用工作流4.1 模型能力没变但每次调用都稳定复用了相同的判断这几年做 AI 工具的人会有一个感受模型的能力提升是缓慢的但我们的使用效率可以因为流程改进而明显提升。Skill 所做的正是这件事。它没有给模型增加什么魔法推理能力也不会让一个不懂架构的模型突然变成架构师。它的价值是把一次成功实践固化下来让后续每一次调用都沿用同一套判断标准。比如一个画图 Skill 今天画得好是因为它在步骤里写清楚了“先列组件再画关系”。明天再画它还是用同样的步骤。如果你只是写普通 Prompt可能明天换一种问法模型就漏掉了一个数据库节点。Skill 减少的正是这种随机性。4.2 Agent、插件、Skill 三者的关系需要重新理解经常有人混淆 Skill 和 Agent或者把 Skill 和插件画等号。这三个概念在不同产品里有边界差异但可以从抽象层面理解Agent是执行者负责感知目标、制定计划、调用工具、汇总结果。插件是工具能力比如文件读取、网络请求、图片渲染。它回答的是“我能做什么”。Skill是操作流程是“怎么做”的方法论。它回答的是“当遇到某类任务时按什么顺序、用什么格式、遵守什么规则去执行”。画系统架构图这个例子就很容易说清Mermaid CLI 是插件Agent 是调度者system-architect 这个 Skill 是流程手册。Agent 判断用户想要架构图然后去调用这个 SkillSkill 又告诉 Agent 要调用插件去渲染。所以“Skill 和 Agent 哪个重要”是个伪问题。缺了 Agent 没人指挥缺了插件没有执行能力缺了 Skill 则每次都要重新碰运气。4.3 对个人开发者意味着什么开始积累自己的技能包Skill 的出现把“个人经验”变成了一种可保存、可分享、可迭代的数字资产。过去一个老工程师带新人要讲清楚怎么画架构图得花不少时间。现在完全可以把这套判断流程写进 Skill 文件里。新人拿到这个 Skill再配合 Agent 执行能少走很多弯路。同样你自己觉得某个工作流处理得好比如日志分析、需求拆解、测试用例生成、数据库设计都可以用 Skill 的格式把它沉淀下来。时间长了你拥有的就是一套个人技能库。它不依赖某个具体项目存活也不会因为项目结束而丢失。这也是为什么最近关于 Skill 开发、Skill 推荐、如何写一个 Skill 的讨论热度这么高。大家逐渐意识到这不止是 AI 使用技巧还是一种新的知识管理方式。5. 说清楚边界哪些场景不适合用 Skill哪些坑最容易踩5.1 排查链路一句话没画出图按什么顺序查使用 Skill 时最常见的失败现象是“一句话下去什么都没出来或者出来的图很离谱”。遇到这种情况不要立刻去调描述文件按下面的顺序逐层排查排查层检查点常见问题触发层描述文件的 trigger 是否覆盖了用户输入用户没提“架构图”只说了“画个系统关系”输入层用户描述是否提供了足够的组件信息只有“电商系统”四个字没有更多约束规则层Skill 步骤是否有默认推断规则缺少默认组件结构时模型靠猜工具层渲染工具是否可用Mermaid CLI 未安装路径不对权限不足输出层生成的 Mermaid 语法是否合法节点 ID 含特殊字符、括号未转义、关系指向未定义节点这五层从前往后走先确认触发再确认输入再看规则最后才怀疑工具。很多人习惯先怀疑模型能力但大多数时候问题出在更基础的地方。5.2 典型坑点过度相信默认模板忽略个性化需求画架构图 Skill 最容易犯的错是把默认模板当万能方案。架构图并非只有一种画法。不同目的需要的图完全不同给产品经理看的业务架构图需要强调模块和流程。给开发看的服务架构图需要强调服务和存储的关系。给运维看的部署架构图需要强调环境、实例和网络层。给新成员看的系统概览需要简化细节、突出边界。如果 Skill 只写一套步骤不区分使用场景那么它生成的图可能“看起来规范”但完全不符合当前受众的需求。所以在写 Skill 时至少应该增加一个“意图识别”步骤如果用户的目标是系统设计评审则输出服务调用关系图。 如果用户的目标是文档概览则输出模块层次架构图。 如果用户提到部署环境则输出部署架构图。这一步能做到什么程度取决于你的 Skill 写得有多细但这恰恰是个人经验最有价值的地方。5.3 长期使用的工程化要求如果你只是想尝鲜在支持 Skill 的工具里装一个现成包就够了。但如果要长期使用尤其是希望它在项目里真正可靠还需要补上几块拼图版本管理Skill 文件应该纳入 Git 管理每次调整都要有记录。输入模板高频场景要内置几个典型输入模板减少临场发挥。输出验收定义节点数量合理性、是否有孤立节点、是否有未定义依赖等检查指标。异常回退当推理结果不符合预期时要有降级方案比如只输出 Mermaid 代码让用户手动调整。可组合性画架构图 Skill 最好能和需求文档生成 Skill、接口文档生成 Skill 串联使用而不是孤立存在。这些要求并非一篇文章能讲完但它们决定了 Skill 到底是一次性的玩具还是能长期产生价值的工作流组件。6. 如果只记住一句话看到 Skill 这个概念时别只关注“哪个 Skill 最好用”或者“哪个 Skill 包很火”。从“一句话画出系统架构图”这个场景往里看你会理解Skill 真正提升的不是单次输出质量而是把一次成功经验变成可重复、可维护、可分享的流程。画架构图只是一个起点。日志分析、测试用例生成、数据库建模、需求拆解、代码评审所有你心里早有成熟方法论的重复工作都可以用这种方式固化成 Skill。它不是替代你的判断而是把你的判断标准廉价地复制到每一次执行里。如果今天只做一件事建议从你最近最熟悉的一项重复工作开始写成一个最小的 Skill用三条典型输入跑通验证。跑通之后你就会有体感为什么这个机制最近这么火以及它到底值不值得你投入时间。真正昂贵的一直不是一次输出而是每次都要重新从零开始。Skill 要做的就是让那些经过验证的思考路径不再被遗忘。