Menu
根据用户意图生成差异化候选架构方案，简单需求直接给出唯一方案
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
阿里云 ROS 模板部署技能，负责可用性查询、执行部署与失败恢复
使用 InfraGuard 审查 ROS 模板；有发现时直接修复并验证，初始扫描干净时直接输出模板
阿里云 Alibaba Cloud Policy as Code / InfraGuard 合规策略生成、校验与策略库查询
使用专用 ROS 模板询价工具预估 ROS 模板的月度部署费用，支持按需修复和校验模板问题
阿里云 ROS 模板生成——将架构方案转化为可部署的 ROS YAML 模板
阿里云 Alibaba Cloud ROS/Terraform IaC 模板生成、解释、完善、校验、询价与部署
| name | iac-aliyun-architecture |
| description | 根据用户意图生成差异化候选架构方案，简单需求直接给出唯一方案 |
| conclusion_schema | {"type":"object","required":["candidates"],"additionalProperties":false,"properties":{"candidates":{"type":"array","minItems":1,"items":{"type":"object","required":["name","output_path","products","topology","monthly_estimate","pros","cons"],"properties":{"name":{"type":"string","description":"方案名称（体现核心差异）"},"output_path":{"type":"string","description":"模板文件路径，格式: templates/{index}-{kebab-case-name}.yml"},"products":{"type":"array","items":{"type":"string"}},"resource_intents":{"type":"array","items":{"type":"object","required":["product","action"],"additionalProperties":false,"properties":{"product":{"type":"string"},"action":{"type":"string","enum":["create","use_existing","reference","forbid"]},"role":{"type":"string"},"source":{"type":"string"},"notes":{"type":"string"}}},"description":"本方案中每个资源的新建、复用、引用或禁止语义；从 intent.resource_intents 继承或收窄"},"topology":{"type":"string"},"monthly_estimate":{"type":"string"},"pros":{"type":"array","items":{"type":"string"}},"cons":{"type":"array","items":{"type":"string"}}}}}}} |
根据前一步提取的用户意图，设计阿里云架构方案供用户选择。
方案数量取决于需求复杂度，而非固定出 2-3 个凑数：
判断标准：如果你需要添加用户完全没提到的产品来"制造"差异，那就不该有多个方案。
当需求确实存在设计取舍时，根据场景从以下维度中选择最相关的来构建差异方案：
| 维度 | 适用场景 | 示例 |
|---|---|---|
| 成本梯度 | 用户未明确预算，需求可高可低配 | 开发环境 vs 生产环境规格 |
| 可用性级别 | 业务关键程度不明确 | 单可用区 vs 多可用区冗余 |
| 托管 vs 自建 | 同一能力有托管服务和自建方案 | RDS vs 自建 MySQL on ECS |
| 架构模式 | 业务规模和演进方向不确定 | 单体 vs 微服务、同步 vs 异步 |
| Serverless vs 传统 | 流量模式不确定 | FC + API Gateway vs ECS + SLB |
| 弹性策略 | 负载是否可预测 | 固定规格 vs 弹性伸缩组 |
| 数据方案 | 数据量级/访问模式不明确 | 单实例 RDS vs 读写分离 vs PolarDB |
不要机械地套用上表。选维度的依据是用户意图中实际存在的不确定性——哪里有取舍，就在哪里提供选择。
resource_intents如果 intent 中存在 resource_intents，它是架构设计的硬约束：
action=create 的资源可以作为本方案要新建的资源。不要把 action=use_existing 或 action=reference 的资源设计成新建资源。action=use_existing/reference 必须作为已有资源引用，后续模板中应通过参数（如 VpcId）或用户提供 ID 引用，不得生成对应的新建资源。换句话说，use_existing/reference 必须作为已有资源引用。action=forbid 的资源不得出现在候选方案的新增资源里，也不得作为“顺手补齐”的依赖加入。resource_intents 原样或按方案收窄后写入每个 candidate，供模板生成步骤继续执行同一约束。示例：intent 表示“已有 VPC 中创建安全组”时，candidate 应包含 resource_intents: [{"product": "VPC", "action": "use_existing"}, {"product": "SecurityGroup", "action": "create"}]。不得生成 VSwitch，也不得设计成“创建 VPC + VSwitch + SecurityGroup”。
调用 complete_step 提交结论。字段定义见 tool schema。
templates/{index}-{英文简写}.ymltemplates/1-simple-nginx.yml、templates/2-high-availability-slb.yml当只有 1 个方案时，candidates 只有 1 个元素。