القائمة
根据用户意图生成差异化候选架构方案，简单需求直接给出唯一方案
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| 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 个元素。
阿里云 ROS 模板部署技能，负责可用性查询、执行部署与失败恢复
使用 InfraGuard 审查 ROS 模板；有发现时直接修复并验证，初始扫描干净时直接输出模板
阿里云 Alibaba Cloud Policy as Code / InfraGuard 合规策略生成、校验与策略库查询
使用专用 ROS 模板询价工具预估 ROS 模板的月度部署费用，支持按需修复和校验模板问题
阿里云 ROS 模板生成——将架构方案转化为可部署的 ROS YAML 模板
阿里云 Alibaba Cloud ROS/Terraform IaC 模板生成、解释、完善、校验、询价与部署