architecture

architecture 技能概览

architecture 技能的作用

architecture 是一个用于在 HTML 和 CSS 中构建分层系统视图的制图技能，而不是通用的绘图提示词。它能帮助你把粗略的系统想法转化成可读性更强的架构图，带有分区配色、基于网格的布局以及清晰的组件层级。

适合谁使用

如果你需要向工程师、利益相关方或评审者解释平台结构、服务边界、请求流或基础设施层，architecture 技能就很适合。它适合那些希望在 Diagramming 工作流中生成架构图的用户，这类图既便于快速编辑，又容易在 Markdown 中渲染，而且能够在不同项目之间保持一致。

最适用的场景与限制

它最适合用户/应用/数据/基础设施视图、微服务拓扑图、企业应用总览，以及仪表盘风格的系统摘要。它不适合像素级精细自定义绘制、正式 UML 建模，或类似图表的数据可视化；在这些场景下，其他工具通常会更合适。

如何使用 architecture 技能

安装并先看对文件

安装 architecture 时，使用 npx skills add markdown-viewer/skills --skill architecture 添加该技能，然后先从 SKILL.md 开始阅读。接着检查 layouts/ 里的布局文件和 styles/ 里的样式预设，在写内容之前先选一个最符合你结构的模板。

把粗想法变成可用提示词

有效使用 architecture 的起点是明确目标，而不是只说“做一张架构图”。要把系统用途、需要展示的层次、关键组件，以及它们之间的关系说明白。例如：“为一个支付平台创建架构图，包含公共 API、认证层、订单服务、数据库、队列和外部 PSP 集成。”

先选对模板，再补细节

在加细节之前，先决定图的形态。一般分层系统用 layouts/layer-layouts.md，权重相近的服务集合用 layouts/grid-catalog.md，集成平台用 layouts/hub-spoke.md，而当流程方向最重要时，用 layouts/connectors.md。如果不确定，先看 layouts/banner-center.md、layouts/dashboard.md 和 layouts/pipeline.md，因为它们展示了最常见的组合模式。

遵守 HTML 约束

architecture 技能要求在 Markdown 中直接嵌入 HTML，图形部分外面不要再套 fenced code block。HTML 块内部要保持连续，中间不要插入空行，因为解析器对结构非常敏感。构建图时要分步骤来：先搭框架，再放容器，然后加标签和内容，最后再做样式微调。

architecture 技能 FAQ

architecture 技能比普通提示词更好吗？

通常是的，尤其当你需要可重复的 Diagramming 架构输出时。这个技能提供了布局模式、HTML 规则和样式约定，可以减少猜测，让结果比一次性的提示词更容易渲染和修改。

使用前我应该提供什么？

告诉它系统目标、主要层次、关键服务，以及任何重要的方向性流转或边界。如果你已经知道输出形态，也请直接说明，比如“单栈”“左右分栏”或“hub and spoke”，这样技能就不用再猜结构。

什么时候不该用 architecture？

当目标是精确视觉草图、正式软件符号，或分析型图表时，不要用它。如果你的输出需要严格几何关系、基于标准的 UML，或数据量很大的图表，那么比起 architecture 技能，其他工具会更匹配。

它适合新手吗？

适合，只要你能用自然语言描述一个系统。新手最容易拿到好结果的方式，是先从一张图、一个受众、一个布局开始，而不是一上来就试图把整个平台一次性建模出来。

如何改进 architecture 技能

让技能做更少但更清晰的决定

architecture 技能在你先定义好受众和细节层级时表现最好。明确说明这张图是给工程师、管理层还是文档使用的，并且只保留真正改变叙事的组件；盒子太多通常会削弱可读性。

说明流程，不只是列部件

一个常见失败模式是只列组件，却不说明它们如何交互。改进 architecture 的用法，应该先写出主路径，比如“browser → API gateway → service → database”，然后只在确有必要时再补充缓存、异步队列或第三方调用等例外情况。

让布局匹配问题本身

如果第一版看起来很拥挤，问题往往不是内容不好，而是模板选错了。可以围绕更合适的结构重写提示词：平台栈视图用分层布局，服务组合图用网格目录，依赖关系和箭头才是重点时用 connectors。

用具体修改来迭代

在第一稿之后，直接提出明确修改：减少嵌套、放大核心服务、分离外部系统，或者简化标签。给 architecture 技能更好的输入，应该说明哪些要保留、哪些要改；这比笼统要求“更清爽一点”更有效，因为后者没有指出具体问题。