技能使用指南

architecture-selection（架构选择）Skill 是什么？如何一键提升架构选型效率？

架构选择Skill 内置单体、微服务、事件驱动、服务器less 模式判据，结合 C4 建模、可扩展性策略、技术选型矩阵与 ADR 输出结构化架构方案，帮助团队快速完成选型、评估风险并沉淀决策记录。了解它如何降低架构门槛、减少返工，立即上手体验。

架构选择Skillarchitecture-selection
8 个章节 约 13 分钟阅读 AI 智能生成

架构选择Skill：把架构决策从“拍脑袋”变成可复用的工程流程

  • 它是什么：一款面向系统架构设计的 AI 技能，内置单体、微服务、事件驱动、服务器less（无服务器）等主流模式的选择判据，并用 C4 模型、可扩展性策略、技术选型矩阵和 ADR（架构决策记录）把结论落成文档。
  • 核心能力：按“团队规模、领域复杂度、扩展需求、运维成熟度”等因素从上到下逐条匹配架构模式，输出结构化方案：模式、组件、扩展策略、技术选型、ADR、风险。
  • 关键约束：明确反对“简历驱动架构”“一上来就微服务”“没测瓶颈就做扩容”，强调先评估团队运维成熟度、记录权衡、为每项技术准备退出策略。
  • 适合谁用：技术负责人、架构师、后端工程师、创业团队 CTO，以及需要写架构文档、做技术评审的研发团队。
  • 使用门槛：以自然语言对话方式调用，无需额外部署；把项目背景、约束条件讲清楚，输出质量会明显提升。

该技能叫什么？如何一键安装 AI 技能提升开发效率？

技能中文名：架构选择Skill 技能英文名：architecture-selection 技能ID：11712

它要解决的问题很具体：架构决策往往依赖少数人的经验，讨论容易停留在“我觉得微服务更先进”，缺少统一的判据、可对比的权衡、可追溯的决策记录。架构选择Skill 把这件事流程化：给定系统需求与团队现状，它会先评估团队的操作成熟度，再按内置的模式选择表给出推荐，并强制输出风险与 ADR，让决策从“个人偏好”变成“可评审的工程产物”。

一键安装的思路与步骤

AI 技能的通用安装逻辑是“获取技能 → 挂载到 AI 客户端/Agent 运行环境 → 验证生效”，具体入口以官方说明为准：

  1. 确认安装前提：准备好可用的 AI 编程客户端或 Agent 运行环境（支持技能/插件机制的版本），并确认当前账号具备技能安装权限。
  2. 定位技能：在技能市场或技能列表中按技能ID 11712、英文名 architecture-selection 或中文名 架构选择 检索。
  3. 执行一键安装：点击安装/启用入口，等待技能加载完成；企业环境下可能需要管理员在组织级统一启用，以官方说明为准。
  4. 验证是否生效：新建会话，输入一句测试指令，例如“帮我为一个 6 人团队的新电商项目做架构选型，业务是简单 CRUD + 少量促销活动”。若返回内容包含架构模式及理由、组件、扩展策略、技术选择及锁定风险、ADR、风险等结构化字段，说明技能已生效。
  5. 绑定项目上下文：该技能会读取项目的 CLAUDE.md、docs/specs/、根目录 CONSTITUTION.md 等约束文件，建议先补齐这些文件，让推荐结果贴合真实项目。

这种“一键安装”的价值在于：不用自己写一大段提示词去约束 AI 的架构思维，技能本身已经把评估顺序、反模式清单、输出字段固化了，团队多人使用时判断标准也更容易统一。

该技能的主要功能和特点

  • 模式选择决策表：把单体、微服务、事件驱动、服务器less、CQRS 五种模式整理成“如果看到 X，就选 Y，理由是 Z”的匹配表，并要求从上到下评估、第一个匹配者获胜，避免过度设计。
  • 团队成熟度优先：在推荐复杂架构前先评估团队的操作成熟度；明确“不要从微服务开始”，而是从简单方案起步，等出现扩展证据再演进。
  • C4 分层建模：支持系统上下文（级别1）、容器（级别2）、组件（级别3）、代码（级别4）四级描述，并按受众选择合适层级——给业务方看上下文图，给开发看组件图。
  • 可扩展性策略库：覆盖水平扩展（无状态、共享会话、连接数）、多级缓存（浏览器 → CDN → 应用 → 数据库）与失效策略（TTL、直写、后写、缓存旁路）、数据库扩展（读副本、分片、分区、CQRS）。
  • 可靠性模式：断路器、隔板、重试（指数退避）、超时、速率限制，并配有断路器“关闭 → 打开 → 半开”的状态说明。
  • 技术选型评估矩阵：按适合性、成熟度、团队技能、性能、操作、成本、锁定、安全八个维度打分加权，输出可对比的量化结论。
  • 锁定风险标注：每个技术选择都要给出 低、中、高 的锁定风险评估，并考虑退出策略，避免被单一供应商绑死。
  • ADR 强制产出：内置 ADR 模板（状态、上下文、决策、后果、被否替代方案），要求“没有 ADR 就不算做完架构决策”。
  • 反模式清单：大泥球、分布式单体、简历驱动、过早优化、象牙塔架构、金锤子，逐一给出问题与解法。

和普通工具比强在哪：普通画图工具只负责“把图画出来”，通用 AI 对话容易给出“看情况”的空话。这个技能的差异在于它先给判据、再给结论、最后逼你写下权衡和风险，输出的是可直接进评审会的材料。

如何使用该技能？

以下按典型使用路径给出步骤，示例可直接改写复用。

  1. 补齐项目背景材料。让技能读取项目 CLAUDE.md（架构、约定、优先级）、docs/specs/ 下的需求与约束、根目录 CONSTITUTION.md（如存在）。如果没有这些文件，就在对话里直接说明。
  2. 描述需求与约束。建议包含：团队人数与经验结构、领域复杂度、预期流量与增长曲线、读写比例、上线时间要求、运维能力、合规要求。
    • 输入示例：“团队 8 人，都是全栈，运维只有 1 人兼职；业务是 SaaS 工单系统，日活预计 5000，读写比 10:1；3 个月要上线 MVP；预算有限。”
  3. 请求架构选型。例如：“用架构选择技能给出模式推荐，并输出组件、扩展策略、技术选型、ADR 和风险。”
  4. 阅读结构化输出。预期得到：pattern（模式+理由）、components（名称/职责/技术/扩展画像）、scalingStrategy、techChoices（类别/选择/理由/锁定风险）、adrs、risks。
  5. 按需下钻建模层级。对业务方说“给我 C4 级别1系统上下文”，对开发说“给我订单服务的 C4 级别3组件图”。
  6. 做技术选型对比。例如：“在 PostgreSQL 和 MongoDB 之间做选择，用评估矩阵打分，权重按适合性 25%、成熟度 15%、团队技能 20%、性能 15%、操作 15%、成本 10%。”
  7. 复核与落地。重点检查三件事：是否在测出真实瓶颈前就做了扩容设计、每项技术是否写了退出策略、每个关键决策是否都有对应 ADR。确认后把 ADR 归档到项目文档目录。

输出说明：输出字段是固定的，但呈现形式可以是表格、图示化描述或文档段落；若不满意，可直接追加约束，如“运维能力按低成熟度重算”“把微服务方案的成本风险展开”。

同类型竞品对比分析

方案名称 定位 核心功能 安装/使用门槛 适用场景 优势与不足
架构选择Skill（architecture-selection） 架构决策辅助技能，嵌入 AI 客户端 模式选择表、C4 建模、扩展性与可靠性模式、技术评估矩阵、ADR 生成、锁定风险评估 低，一键安装后自然语言调用；需准备项目上下文材料 新系统选型、单体与微服务之争、扩展性规划、架构评审 优势：判据固定、强制记录权衡、输出结构化可直接评审；不足：依赖输入信息质量，不产出可运行代码与真实压测数据
通用 AI 对话（不安装技能） 通用问答助手 可讨论架构概念，回答灵活 极低，开箱即用 概念答疑、头脑风暴 优势：零门槛；不足：结论易泛化、缺少固定评估顺序与 ADR 产出，多人使用标准不一致
架构绘图工具（如 C4 建模类工具） 图表与文档表达 绘制上下文图、容器图、组件图 中，需学习建模语法与工具操作 对外汇报、架构文档沉淀 优势：图形规范、美观；不足：只表达不决策，选型判断仍需人来完成
云厂商架构咨询/Well-Architected 评估 人工咨询服务与评估框架 架构评审、成本与可靠性建议 高，需要预约、评审周期长，可能产生费用（以官方说明为准） 大型系统上线前评审、合规审计 优势：深度定制、结合真实资源账单；不足：周期长、成本高，不适合日常快速决策

怎么选：日常研发中的选型讨论与文档产出，优先用技能把“判据和记录”补齐；需要对外交付规范图形时再配合绘图工具；涉及大规模迁移或合规审计时，引入人工评估。

该技能的典型应用场景与实际体验情况

场景一：创业团队 MVP 选型（技术负责人） 痛点：团队 6 人，纠结要不要直接上微服务“以免以后重构”。 使用方式：给出团队规模、领域复杂度、上线时间，请求选型。技能按匹配表命中“小团队（<10人）+ 简单领域 + 快速迭代 → 单体”，并说明“不要从微服务开始，等扩展证据出现再演进”。 实际体验：结论明确、理由可引用，能有效压制“技术虚荣”式争论；注意要把“未来 12 个月增长预期”讲清楚，否则容易被判定为简单领域。

场景二：单体拆分评估（后端架构师） 痛点：老系统代码库膨胀，是否拆微服务缺少客观依据。 使用方式：要求输出微服务方案的权衡表与风险清单，并列出分布式单体、数据一致性等反模式预警；再要求按 C4 级别2、级别3 描述目标容器与组件划分。 实际体验：能快速得到“操作复杂性、分布式调试、数据一致性”三类代价的具体描述，便于向管理层解释成本；注意技能会强调先测瓶颈，需配套真实监控数据才有说服力。

场景三：技术选型评审（研发团队） 痛点：数据库、消息中间件选型靠“谁嗓门大”。 使用方式：让技能按八维度评估矩阵打分，并要求为每项技术标注锁定风险（低/中/高）与退出策略。 实际体验：加权打分把主观争论转成可讨论的分项分歧，评审效率明显提升；注意权重需要团队自己确认，否则分数只是参考。

场景四：架构文档与决策留痕（技术文档负责人） 痛点：半年后没人记得当初为什么这么设计。 使用方式：要求为每个关键决策生成 ADR，包含状态、上下文、决策、正负面后果、被否替代方案及否决理由。 实际体验：ADR 模板结构完整，直接归档即可；建议在项目里固定 ADR 编号规则，避免编号混乱。

整体上手难度：低。会用自然语言描述需求即可，但“输入越具体、输出越可用”这一点非常明显。

该技能能为用户带来的价值

  • 决策提速：把原本需要多次会议、多人对齐的选型讨论，压缩为一轮结构化输出，模式推荐、技术对比、风险清单一次拿到。
  • 降低门槛：小团队没有专职架构师，也能按成熟方法论做选型，避免“简历驱动架构”和“过早优化”这两类高代价错误。
  • 减少返工：强制评估团队运维成熟度与锁定风险，能在设计阶段就暴露“选了却运维不动”“上了却迁不走”的隐患。
  • 决策可追溯：ADR 让每个关键选择都有上下文与否决理由，人员流动后仍能还原决策逻辑，长期看是最有价值的部分。
  • 标准统一：多人多团队使用同一套判据与输出字段，架构评审从“各说各话”变成“按同一张表对齐分歧”。

常见问题 FAQ

Q1：怎么安装这个技能？收费吗？ A：在支持技能机制的 AI 客户端中按技能ID 11712 或英文名 architecture-selection 检索并一键启用即可；是否需要付费、是否支持组织级批量启用，以官方说明为准。安装后用一句架构选型问题测试，若返回包含模式、组件、扩展策略、技术选择、ADR、风险的结构化结果，即表示生效。

Q2：它会直接替我决定用微服务还是单体吗？ A：它会给出明确推荐并附理由，但推荐基于你提供的团队规模、领域复杂度、扩展需求、运维成熟度等信息。信息缺失时结论会偏保守（倾向简单方案），这是设计上的刻意选择——先从简单开始，出现扩展证据再演进。

Q3：适合谁用？非架构师能用吗？ A：适合技术负责人、架构师、后端工程师、创业团队 CTO，以及需要写架构文档和做技术评审的人。非架构师也能用，因为它把判据写成了表格，照着描述现状即可；但要得到高质量结果，仍需把业务与团队约束讲清楚。

Q4：和架构绘图工具、云厂商评估服务怎么选？ A：需要“做决策并留下记录”，用本技能；需要“画出规范图形对外汇报”，配合绘图工具；涉及大规模迁移、合规审计、真实成本核算，再引入人工评估服务。三者是互补关系，不是替代关系。

Q5：它会读取我的项目文件吗？会不会有泄露风险？ A：技能设计上会参考项目 CLAUDE.md、docs/specs/、CONSTITUTION.md 等文件以贴合项目约束，是否读取、读取范围取决于你所使用客户端的权限配置。涉及敏感信息时，建议只提供脱敏后的需求描述，并按团队的数据安全规范执行。