aws-well-architected-framework-review

说明

已弃用。 此技能已由 Agent Toolkit for AWS 中的 aws-well-architected-review 取代。 此处不再接受新功能；请参阅 issue #147。

Well-Architected 审查

第 1 步：定义工作负载范围

请用户描述工作负载：

您希望我审查哪个工作负载？请提供以下信息：

• 工作负载名称和简要说明
• 要分析的代码包/目录（IaC、应用程序代码、CI/CD 配置）
• 业务关键性（关键、高、标准、低）
• 当前痛点（可选——您已知存在问题的方面）

如果用户已经提供架构详情，或您正在包含 IaC 的代码库中工作，请跳过提示并开始发现。

重要提示：如果没有可供分析的代码或 IaC（例如，用户通过口头描述架构），请根据已提供的信息继续审查。使用架构描述中的明确陈述作为证据，生成完整报告。将未提及的详情视为未知，而不是将其视为缺少某项控制的证据。将无法验证的实施详情标记为 Cannot Determine，说明需要哪些证据才能确认；如果用户已提供足够的上下文以进行有意义的审查，请勿要求其提供代码。

判断是否适用专门的 WA Lens：

• SaaS、Serverless、Data Analytics、Machine Learning、IoT、Containers、Games、Financial Services、Healthcare

如果从代码中能明显看出适用的 Lens（例如，大量使用 Lambda → serverless），请注明并应用该 Lens 的专属问题。

第 2 步：基础设施发现

分析代码库中的所有基础设施即代码和部署配置。

必须检查：

• CDK 代码（TypeScript、Python、Java、Go）
• CloudFormation 模板（YAML、JSON）
• Terraform 配置（.tf 文件）
• SAM/Serverless Framework 模板
• CI/CD 流水线定义（CodePipeline、GitHub Actions 等）
• 监控配置（CloudWatch 警报、控制面板）
• 部署配置（CodeDeploy、ECS 部署设置）

对于每个基础设施组件，请记录：

• 资源类型、逻辑名称和配置
• 定义所在的文件路径和行号
• 与安全相关的配置（IAM、加密、网络）
• 与弹性相关的配置（多 AZ、备份、扩缩容）
• 与成本相关的配置（实例类型、容量模式）

记录工作负载的主要 IaC 方言（CDK、CloudFormation、Terraform 或 SAM）——第 6 步将使用此方言为每项发现生成 Fix: 区块。如果工作负载没有 IaC，请注明修复区块将改用 AWS CLI 命令。

必须使用 PlantUML 创建架构图，展示：

• 所有主要组件及其关系
• 数据流和外部依赖项
• 信任边界和网络边界

第 3 步：应用程序架构发现

分析应用程序代码中的架构模式：

• 入口点（API 处理程序、事件处理器、计划任务）
• 服务通信模式（同步/异步、重试、超时、断路器）
• 数据访问模式（查询、缓存、连接管理）
• 错误处理和弹性模式
• 身份验证/授权逻辑
• 可观测性埋点（日志记录、跟踪、指标）

---STOP--- 检查点：发现阶段已完成——请在评估前展示发现结果。

以下是我发现的工作负载情况：

• 基础设施：{发现的 IaC 资源摘要}
• 架构模式：{检测到的关键模式}
• 范围：{分析的文件/资源数量}

是否继续进行完整的 57 个问题评估，还是要调整范围？

在用户明确确认之前，不得越过此处继续。

第 4 步：通过代码证据评估 WA Framework 的全部问题

重要——不要只生成简短评审。 最常见的失败模式，就是引用 20–30 条最佳实践（BP）后便停止。参考语料包含 57 个问题对应的 307 条 BP；真正完整的评审 MUST 评估全部 307 条。每条 BP 都必须获得以下五种状态之一：已实现、部分实现、未实现、不适用或无法确定（并说明理由）。如果你发现引用的 BP 少于 200 条，就说明评审尚未完成。请反复检查，直到涵盖每一条 BP。

根据 Well-Architected Framework 的全部 57 个问题评估工作负载。对于每个问题，请提供：

• 状态：“已实现”“部分实现”“未实现”“不适用”“无法确定”
• 证据：具体的文件路径和行号
• 差距：缺少什么或有哪些方面可以改进
• 风险：差距可能造成什么后果

证据充分性门槛

仅在应用此门槛后，才能指定状态：

• 已实现——有明确证据表明 BP 已完整实现。
• 部分实现——有明确证据表明 BP 已部分实现，并指出了具体差距。
• 未实现——有明确证据表明该控制不存在；或者已检查权威且足够完整的来源，而该控制按理应出现在其中，却未出现。
• 不适用——该 BP 不属于工作负载范围；请说明针对该工作负载的理由。
• 无法确定——现有证据缺失、无法定论、仅涉及运行时，或超出已检查的范围。请明确指出需要哪些具体制品、指标、配置或访谈答复才能作出判断。

没有证据不代表不存在证据。口头说明中未提及某项控制，或代码／IaC 并非该控制的权威依据时，MUST 标为 无法确定，而不是 未实现。例如，“未配置备份”支持标为 未实现；未提及控制目标或 TCO 分析，则只能支持标为 无法确定。

对于“已实现”“不适用”和“无法确定”，严重性留空。对于“无法确定”，请提供验证操作，而不是整改发现。不要将不确定性转化为高或严重级别的发现。

6 大支柱及其问题：

• 卓越运营（OPS 1–11）：组织、可观测性、部署风险、运营准备度、事件管理、演进
• 安全性（SEC 1–11）：基础、安全身份、权限、检测、网络／计算保护、数据保护、事件响应、应用安全
• 可靠性（REL 1–13）：配额、网络拓扑、服务架构、分布式系统、监控、扩缩容、变更管理、备份、故障隔离、灾难恢复
• 性能效率（PERF 1–5）：资源选择、计算、数据／存储、网络、优化流程
• 成本优化（COST 1–11）：财务管理、用量治理、监控、退役、服务选择、资源规格调整、定价模式、数据传输、需求管理、演进
• 可持续性（SUS 1–6）：区域选择、需求匹配、架构模式、数据管理、硬件选择、组织流程

审查深度

开始评估前，请根据用户的请求确定审查深度：

完整审查（用户说“WA review”“full review”或“comprehensive”时的默认选项）：

• 评估全部 57 个问题
• 每个支柱都加载 references/pillars/{pillar-slug}.md（并行子 Agent 调度见步骤 4b）；每个支柱文件都包含该支柱的全部问题和最佳实践
• 在发现项中引用具体的 BP ID（例如：“SEC03-BP02：未定义权限边界”）

快速审查（用户说“quick review”“high-level”“summary”或要求节省时间时）：

• 仅在问题层面评估全部 57 个问题（不要加载单个 BP 参考文件）
• 根据代码中的发现，使用上文的支柱摘要评估每个问题
• 标出明显的缺口，但不要穷尽检查每项 BP
• 速度更快、细节更少，但仍覆盖所有支柱

按支柱范围审查（用户指定特定支柱时，例如“仅审查安全性和可靠性”“评估我的安全状况”“找出单点故障”“优化成本”）：

• 仅评估用户所请求支柱的问题
• 加载 references/pillar-playbooks/{pillar}.md，应用特定领域的发现步骤（收集通用基础设施扫描之外的专用证据）
• 对这些支柱采用完整审查深度（加载 BP 参考文件）
• 完全跳过其他支柱——除非存在明显的严重跨支柱问题，否则不要评论其他支柱
• 生成聚焦于支柱的报告，并附上特定领域的评分卡（例如：安全性：6 个领域的评分卡；可靠性：单点故障表 + 测试计划）

表示按支柱范围审查的触发短语：

• 安全性：“security assessment”“IAM review”“encryption audit”“assess my security posture”
• 可靠性：“reliability plan”“identify SPOFs”“assess disaster recovery”“fault tolerance review”
• 成本：“cost optimization”“right-sizing review”“reduce AWS spend”“cost assessment”
• 性能：“performance assessment”“latency analysis”“bottleneck identification”
• 可持续性：“sustainability review”“carbon footprint”“resource efficiency audit”
• 卓越运营：“operational assessment”“CI/CD review”“observability audit”

评分模式（用户要求“score”“grade”“scorecard”“matrix”或“just give me a number”时）：

• 分析所提供路径下的代码库
• 对全部 57 个问题执行快速扫描（不加载 BP 参考文件）
• 仅生成结构化评分卡和筛选后的发现项——不生成完整叙述性报告
• 遵循深度参数：
  • “critical only” → 仅显示 Critical 级发现
  • “critical and high” → 显示 Critical 和 High 级发现
  • “all”（未指定时的默认值）→ 显示 Critical、High、Medium 和 Low 级发现
• 输出格式：

## WA Score: {workload_name}

**Overall: {X.X}/5** | OPS: {}/5 | SEC: {}/5 | REL: {}/5 | PERF: {}/5 | COST: {}/5 | SUS: {}/5

| Pillar | Score | Critical | High | Medium | Low |
|--------|-------|----------|------|--------|-----|
| Operational Excellence | {1-5} | {n} | {n} | {n} | {n} |
| Security | {1-5} | {n} | {n} | {n} | {n} |
| Reliability | {1-5} | {n} | {n} | {n} | {n} |
| Performance Efficiency | {1-5} | {n} | {n} | {n} | {n} |
| Cost Optimization | {1-5} | {n} | {n} | {n} | {n} |
| Sustainability | {1-5} | {n} | {n} | {n} | {n} |

### Findings ({depth} and above)
| # | Pillar | Severity | Finding | Evidence |
|---|--------|----------|---------|----------|
| 1 | {pillar} | {Critical/High/...} | {one-line finding} | {file:line} |
...

### Summary
{1-2 sentence takeaway: overall posture + single most impactful action}

触发短语：“score my app”“WA scorecard”“grade this”“give me a score matrix”“how does my architecture score”

如果不明确，请询问：

您希望进行完整审查（针对每个问题进行深入的 BP 级分析——全面但耗时更长）、快速审查（问题级评估——更快），还是评分（仅提供评分卡和主要发现项）？

覆盖策略——先查看清单，再查看支柱文件

全面审查的目的是实现 BP 级别的全面覆盖。 为可靠地实现这一点，参考语料分为三层：

1. references/manifest.md（约 24 KB）——包含每个 BP ID 及一行标题的轻量目录。进行任何全面审查时，务必先加载此文件。它展示了可供引用的全部 307 个 BP。
2. references/pillars/{pillar-slug}.md（6 个文件，每个约 150–580 KB）——按支柱合并的参考资料，包含某个支柱的所有问题和完整 BP 内容。加载这些文件以获取完整 BP 详情（实施指南、反模式、资源）。
3. references/pillar-playbooks/{pillar}.md（6 个文件，每个约 3–5 KB）——针对某个支柱的领域专属证据收集指南：要检查哪些资源、哪些模式应标记为高风险，以及该支柱专属的报告格式。每个全面审查子 Agent 都会加载其支柱的操作手册（步骤 4b），以便调查结果有具体的文件:行证据支持，而非泛泛复述 BP。

全面审查的强制加载模式

步骤 4a——加载清单（强制，1 次 Read 调用）：

Read: references/manifest.md

这会以约 24 KB 的内容提供每个 BP ID 及其标题。

步骤 4b——并行派发 6 个支柱子 Agent（全面覆盖的强制步骤）：

采用此模式的原因： 要求单个 Agent 在一次回复中列举全部 307 个 BP 时，它会提前停止——只返回部分列表，却把审查当作已完成，无论提示有多强、检索策略如何（本地文件、MCP 或混合方式），或是否明确要求“评估全部 307 项”。限制来自模型偏向简洁的特性，而非缺少参考资料，因此强化提示并不能解决问题。

解决方法： 缩小每个子 Agent 的范围。当一个 Agent 只审查一个支柱时，它可以专注列举该支柱的 30–55 个 BP。派发6 个并行子 Agent（每个支柱一个），才能覆盖全部 307 个 BP 语料。可使用 evals/cli_effectiveness/ 中的测试工具，在自己的运行环境中衡量差异。

在同一轮中派发全部 6 次 Task 调用（并行执行）。每个子 Agent 都必须返回结构化的 Markdown 表格，以便顶层汇总器原样合并调查结果，无需改写。

必需的返回格式（每个子 Agent）：

## {Pillar} Findings

| BP ID | Status | Severity | Evidence | Recommendation |
|-------|--------|----------|----------|-----------------|
| SEC03-BP02 | Not Implemented | High | No permission boundaries found in cdk/iam.ts | Add IAM permission boundaries per role |
| SEC04-BP01 | Partially Implemented | Medium | CloudTrail on, but no S3 access logging | Enable S3 server access logging |
| ...one row per BP evaluated in this pillar... |

行要求：

• 每个评估的 BP 占一行（每个支柱目标为 30–55 行；必须覆盖支柱文件中的每个 BP）
• 状态：必须且只能是 Implemented / Partially Implemented / Not Implemented / Not Applicable / Cannot Determine 之一
• 严重程度：Critical / High / Medium / Low（Implemented/Not Applicable/Cannot Determine 可留空）
• 证据：分析代码时提供具体的文件:行引用；口头审查时提供明确引用的事实；或写明 Cannot Determine — need {specific evidence}
• BP ID 只能采用规范的 PILLAR##-BP## 格式

将以下确切的校准规则附加到每个支柱子 Agent 的提示中：

应用证据充分性门槛：信息缺失或不明确时，状态应为 Cannot Determine，而非 Not Implemented。只有在明确缺少某项控制措施，或权威来源中未包含必须出现的控制措施时，才使用 Not Implemented。Cannot Determine 的严重程度留空，并说明所需的具体证据。

派发模板：

Task(subagent_type="general-purpose",
     description="Review Operational Excellence",
     prompt="Read references/pillars/operational-excellence.md and references/pillar-playbooks/operational-excellence.md (domain-specific evidence-collection checklist: what to examine and what to flag as HIGH RISK), then review the following workload ONLY for the OPS pillar. Enumerate EVERY BP in the pillar file (all 30+ BPs) — do not filter to 'top issues'. Return findings as the mandatory markdown table (columns: BP ID | Status | Severity | Evidence | Recommendation) with one row per BP. Do NOT prepend narrative summary text before the table. Workload: {workload description + code}")

Task(subagent_type="general-purpose",
     description="Review Security",
     prompt="Read references/pillars/security.md and references/pillar-playbooks/security.md (domain-specific evidence-collection checklist), then review the workload ONLY for the SEC pillar. [same table format, every BP as a row] Workload: {workload}")

Task(subagent_type="general-purpose",
     description="Review Reliability",
     prompt="Read references/pillars/reliability.md and references/pillar-playbooks/reliability.md (domain-specific evidence-collection checklist), then review the workload ONLY for the REL pillar. [same table format, every BP as a row] Workload: {workload}")

Task(subagent_type="general-purpose",
     description="Review Performance Efficiency",
     prompt="Read references/pillars/performance-efficiency.md and references/pillar-playbooks/performance-efficiency.md (domain-specific evidence-collection checklist), then review the workload ONLY for the PERF pillar. [same table format, every BP as a row] Workload: {workload}")

Task(subagent_type="general-purpose",
     description="Review Cost Optimization",
     prompt="Read references/pillars/cost-optimization.md and references/pillar-playbooks/cost-optimization.md (domain-specific evidence-collection checklist), then review the workload ONLY for the COST pillar. [same table format, every BP as a row] Workload: {workload}")

Task(subagent_type="general-purpose",
     description="Review Sustainability",
     prompt="Read references/pillars/sustainability.md and references/pillar-playbooks/sustainability.md (domain-specific evidence-collection checklist), then review the workload ONLY for the SUS pillar. [same table format, every BP as a row] Workload: {workload}")

总计：在一轮中调用 6 次 Task。 每个子 Agent 都在独立的上下文中运行，因此都可以彻底审查，不会挤占其他子 Agent 的上下文。统一的表格格式使汇总成为机械式拼接，而非解释性总结——叙述式的子 Agent 输出会诱使汇总器丢弃其认为多余的引用。 **成本/延迟：**与单 Agent 审查相比，分派会显著增加 token 消耗，因为每个子 Agent 都会重复获取工作负载上下文。由于子 Agent 并发运行，墙钟时间取决于耗时最长的单个支柱，而不是六个支柱耗时之和。用户需要在成本和覆盖范围之间权衡——请使用 evals/cli_effectiveness/ 中的测试工具，在你自己的运行环境中同时衡量两者。

何时跳过子 Agent 分派：

• 用户明确要求快速审查 / 评分模式 / 按支柱范围审查——这些模式保持单 Agent
• 成本受限的环境无法接受额外的 token 消耗——进行单 Agent 审查，但要坦诚告知用户，审查只覆盖 307 个 BP 中的一部分，而非全部

步骤 4c — 汇总子 Agent 的发现（逐字保留引用）：

所有 6 个子 Agent 返回结果后，将其发现合并为一份结构化报告。**重要：**逐一保留每个子 Agent 生成的所有 BP 引用。汇总步骤是合并，不是总结——不要改述、归类或省略子 Agent 提出的 BP 引用。汇编时通常会丢失覆盖范围：子 Agent 提出了整个语料库中的内容，而草率的汇总只会将其中一部分带入最终报告。

汇总规则——必须全部遵守：

1. **必须包含完整 BP 账本。**报告必须包含“完整 BP 账本”部分（见步骤 6），为每个子 Agent 提出的 BP 状态组合各列一行。如果子 Agent A 将 SEC03-BP02 标为“未实施”，该条目必须原样出现在账本中，不得改述。
2. **不得按支柱压缩。**最终输出中不得将某个子 Agent 提出的 45 条 BP 引用缩减为“每个支柱的 5 个主要发现”。每条被引用的 BP 都必须出现在账本中。高严重性发现也必须在“严重与高风险发现”部分中附上完整详细说明，但这是在账本之外的补充，绝不能取代账本。
3. **写作前核对数量。**返回前，统计汇总草稿中的 BP ID 数量（格式为 PILLAR##-BP##）。如果数量少于子 Agent 引用总数，就说明有遗漏——请返回并补齐。
4. 跨支柱模式和优先级排序属于补充分析，应引用账本，而非取代账本。

对于每条 BP 引用，账本行应显示：

• 已实施——工作负载体现了此 BP（引用 BP + 证据）
• 部分实施——有所覆盖，但仍有缺口（引用 BP + 缺口）
• 未实施——明确或权威的证据表明工作负载缺少此 BP
• 不适用——此 BP 不适用于工作负载的情境（简要说明原因）
• 无法确定——证据不足以作出判断（指出所需的具体证据）

覆盖范围预期——完整审查必须评估全部 307 个 BP。每个 BP 都必须标注五种状态之一。无法确定 计入评估覆盖范围；穷尽式覆盖并不要求凭空编造确定状态。有证据表明某项实践缺失时，将其标为“未实施”是有效且有价值的发现。

第 4d 步 — 必须进行覆盖审计（不得跳过）

在生成最终报告之前，你必须进行自我审计；如果覆盖不完整，则需反复检查：

1. 计数：目前已评估多少个唯一 BP ID（采用规范的 PILLAR##-BP## 格式）？统计所有五种状态——已实施、部分实施、未实施、不适用和无法确定。
2. 对照目标：完整审查需评估清单中的全部 307 个 BP。少于此数量即表示审查不完整。
3. 如果已评估数量少于 307，则不得继续生成最终报告。请改为反复检查：
   • 将已评估的集合与 references/manifest.md 中完整的 307 个 BP 列表进行对照。
   • 对于每个尚未评估的 BP，如果尚未加载对应的支柱文件，则先加载，然后添加一条评估记录（已实施 / 部分实施 / 未实施 / 不适用 / 无法确定）。
   • 重复进行计数检查。
4. 继续反复检查，直到 307 个 BP 全部都有评估记录。如果某个 BP 确实不适用（例如，针对无服务器架构的 BP 不适用于容器工作负载），请标记为不适用，并用一行说明理由——不得默默跳过。

**重要性说明：**默认情况下，Agent 往往会列出 20–30 个最显著的发现后就停止。这会导致审查流于表面，遗漏系统性问题。WA 语料库的价值在于全面覆盖——评估每个 BP，揭示所有差距。付费购买 WA 审查的客户期待的是完整的 307 项 BP 评估，而不是模型凭第一印象列出的内容。

审计输出格式（在最终报告中，置于执行摘要之前）：

## Coverage audit
- BPs evaluated: {count} / 307
- Iterations performed: {N}
- Status distribution: {implemented} Implemented, {partial} Partial, {not_impl} Not Implemented, {na} N/A, {cannot_determine} Cannot Determine

如果“已评估 BP 数量”少于 307，则说明审查尚未完成——请返回第 4d 步。

注重效率时——快速审查模式

如果用户明确要求进行快速审查、提供高层摘要或评分，或者时间有限，则只加载 references/manifest.md（24 KB），并按问题级别或 BP ID 引用 BP，不加载支柱文件。这样可以获取规范的 BP ID，但会跳过深入的实施内容。

按支柱范围审查

对于单支柱审查，加载 references/manifest.md 和该支柱的文件（例如 references/pillars/security.md）。

何时应用 WA Lens

Lens 是叠加式的——它们会在核心 57 个问题框架的基础上补充特定领域的最佳实践，而不会替代框架中的问题。

何时应用 Lens：

• 工作负载明显符合某个 Lens 的领域（例如，以 Lambda 为主 → 无服务器；基于 LLM → 生成式 AI）
• 用户明确要求进行特定 Lens 的审查

如何应用：

• 首先完成核心框架评估（全部 57 个问题）
• 然后从 references/lenses/{lens-name}/ 加载相关 Lens，并评估其他特定 Lens 的最佳实践
• 在核心评估结果之后单独设置一个章节，报告 Lens 的评估结果

如果用户只要求审查某个 Lens（例如，“根据无服务器 Lens 审查我的应用”）——这也是有效的。仅加载该 Lens 的参考资料，并根据这些资料进行评估。

可用的 Lens：

• references/lenses/serverless-applications/ — Lambda、API Gateway、Step Functions、事件驱动
• references/lenses/generative-ai/ — LLM 工作负载、RAG、微调、提示词工程
• references/lenses/agentic-ai/ — AI Agent、编排、工具使用、护栏
• references/lenses/responsible-ai/ — 公平性、可解释性、治理、监控
• references/lenses/hybrid-networking/ — Direct Connect、VPN、Transit Gateway、DNS
• references/lenses/migration/ — 各支柱的评估、动员、迁移阶段
• references/lenses/devops-guidance/ — CI/CD、自动化治理、开发生命周期、可观测性、安全测试
• references/lenses/machine-learning/ — ML 生命周期（MLOPS）、模型训练/部署、数据工程、负责任的 ML
• references/lenses/data-analytics/ — 数据管道、治理、数据目录、数据沿袭、分析性能与成本
• references/lenses/games-industry/ — 游戏后端、实时多人游戏、玩家数据、在线运营
• references/lenses/saas/ — 多租户、租户隔离、入驻、计量、分级
• references/lenses/financial-services/ — FSI 工作负载的法规遵从、数据驻留、韧性、可审计性
• references/lenses/life-sciences/ — GxP、经验证的系统、临床/研究数据、法规遵从
• references/lenses/end-user-computing/ — 虚拟桌面/应用、流式传输、身份、终端交付
• references/lenses/supply-chain/ — 供应链数据、集成、可追溯性、韧性
• references/lenses/video-streaming-advertising/ — 视频管道、流式传输交付、广告技术、变现
• references/lenses/telco/ — 电信网络工作负载、5G/边缘、OSS/BSS、电信级可靠性
• references/lenses/sap/ — AWS 上的 SAP、S/4HANA、HANA 数据库、SAP 环境韧性
• references/lenses/modern-industrial-data-technology/ — 工业数据平台、OT/IT 融合、制造分析
• references/lenses/microsoft-workloads/ — AWS 上的 Windows Server、SQL Server、Active Directory、.NET
• references/lenses/connected-mobility/ — 网联汽车、远程信息处理、车队数据、汽车平台
• references/lenses/healthcare-industry/ — HIPAA、临床数据、互操作性、患者隐私
• references/lenses/container-build/ — 容器镜像构建、供应链安全、注册表、CI/CD
• references/lenses/high-performance-computing/ — HPC 集群、并行工作负载、调度、低延迟网络
• references/lenses/streaming-media/ — 媒体流式传输、直播/VOD 交付、编码、内容工作流
• references/lenses/iot/ — IoT 设备、遥测、边缘计算、车队预置、OTA 更新
• references/lenses/government/ — 公共部门、隐私设计、合规、实时安全
• references/lenses/mergers-and-acquisitions/ — 并购尽职调查、多账户/多云治理、集成、技术债务、收购后的成本与安全
• references/lenses/maori-data/ — Māori 数据治理、数据主权、Te Ao Māori 原则、原住民数据保护与保留

步骤 5：风险评估

针对每项发现，使用影响 × 可能性进行评估：

影响：轻微（影响范围有限）| 中等（影响部分用户）| 严重（全面中断、数据丢失、违反法规）

可能性：低（需要特定条件）| 中（正常运行时可能发生）| 高（常见故障模式、控制措施薄弱）

影响	可能性	风险等级
严重	高	严重
严重	中	高
严重	低	高
中等	高	高
中等	中	中等
中等	低	中等
轻微	高	中等
轻微	中	低
轻微	低	低

识别跨支柱冲突：

• 影响性能的安全控制措施
• 降低可靠性的成本优化
• 增加成本的可靠性模式

---STOP--- 检查点：风险评估已完成——生成报告前请确认发现。

我已完成评估。以下是摘要：

• 严重发现：{count}
• 高风险发现：{count}
• 中等风险发现：{count}
• 低风险发现：{count}
• 跨支柱冲突：{count}

要我生成完整报告，还是先讨论具体发现？

在用户明确确认之前，不要越过此处继续操作。

步骤 6：生成报告

输出结构化报告：

# Well-Architected Review: {Workload Name}

## Executive Summary
- **Date**: {date}
- **Workload**: {name}
- **Business Criticality**: {level}
- **Lens Applied**: {lens or "General"}
- **Packages Analyzed**: {list}
- **Questions Assessed**: 57/57
- **Findings**: {X} Critical, {Y} High, {Z} Medium, {W} Low
- **Overall Maturity**: {1-5} — {one-line justification}

## Architecture Overview
{PlantUML diagram}
{Brief description of architecture, key services, data flows}

## Pillar Scorecard
| Pillar | Score (1-5) | Questions Assessed | Key Strength | Key Gap |
|--------|-------------|-------------------|--------------|---------|
| Operational Excellence | {score} | 11/11 | {strength} | {gap} |
| Security | {score} | 11/11 | {strength} | {gap} |
| Reliability | {score} | 13/13 | {strength} | {gap} |
| Performance Efficiency | {score} | 5/5 | {strength} | {gap} |
| Cost Optimization | {score} | 11/11 | {strength} | {gap} |
| Sustainability | {score} | 6/6 | {strength} | {gap} |

## Per-Question Assessment
| ID | Question | Status | Risk Level | Key Evidence |
|----|----------|--------|------------|--------------|
| OPS 1 | Priorities | {status} | {risk or N/A} | {evidence} |
| OPS 2 | Organization structure | {status} | {risk or N/A} | {evidence} |
| ... | ... | ... | ... | ... |
| SUS 6 | Process and culture | {status} | {risk or N/A} | {evidence} |

{Complete this table for all 57 questions — do not truncate}

## Full BP Ledger (MANDATORY)

**This section MUST list every BP citation produced by every subagent.** Concatenate all 6 subagent tables here, sorted by pillar then BP ID. Do NOT filter, cluster, or paraphrase. If a subagent surfaced 45 BPs for its pillar, this ledger shows 45 rows for that pillar. Target row count: 250-307 (one row per BP evaluated across all pillars).

This section is where the subagents' coverage actually reaches the user. Skipping or truncating it discards most of what they surfaced, however complete their tables were. **Do not skip this section.**

| BP ID | Pillar | Status | Severity | Evidence | Recommendation |
|-------|--------|--------|----------|----------|-----------------|
| OPS01-BP01 | Operational Excellence | {status} | {severity or blank} | {evidence} | {recommendation} |
| OPS01-BP02 | Operational Excellence | {status} | {severity or blank} | {evidence} | {recommendation} |
| ... | ... | ... | ... | ... | ... |
| SUS06-BP05 | Sustainability | {status} | {severity or blank} | {evidence} | {recommendation} |

{After writing this table, count the rows and confirm the count matches the sum of subagent rows. If not, you dropped citations — go back and add them.}

## Critical and High Risk Findings
{For each: ID, pillar, title, description, evidence (file:line), impact assessment, recommendation, **Fix:** block (see "Fix blocks" below), effort, AWS services. This section EXPANDS on rows in the Full BP Ledger — it does NOT replace them.}

## Medium Risk Findings
{Same format, condensed — each finding still carries its **Fix:** block. Also references ledger rows.}

## Low Risk Findings
{Summary table: ID | Pillar | Title | Recommendation. Also references ledger rows.}

## Cross-Pillar Trade-offs
{Conflicts between pillars and recommended resolution}

## Prioritize Improvements — Eisenhower Matrix

Not all findings should be addressed at once. Focus on a selected number of issues that make the most business impact and are easiest to implement. Then iterate.

Classify each finding by **importance** (business value) and **effort** (time, complexity, headcount):

    HIGH IMPORTANCE
         │

┌─────────┼─────────┐ │ DO │ PLAN │ │ FIRST │ │ │ │ │ ───┼─────────┼─────────┼─── │ │ │ │DELEGATE │ DEFER │ │ │ │ └─────────┼─────────┘ │ LOW IMPORTANCE LOW EFFORT HIGH EFFORT

| Quadrant | Action | Findings |
|----------|--------|----------|
| **Do First** (High Importance, Low Effort) | Implement immediately | {finding IDs} |
| **Plan** (High Importance, High Effort) | Schedule in roadmap, break into phases | {finding IDs} |
| **Delegate** (Low Importance, Low Effort) | Batch together, assign to available team member | {finding IDs} |
| **Defer** (Low Importance, High Effort) | Revisit in next iteration | {finding IDs} |

### Solution Characteristics

For each solution in "Do First" and "Plan":
- **SMART goal**: Specific, Measurable, Achievable, Relevant, Time-bound
- **Owner**: Identify who is responsible
- **Simple over complex**: Choose the simplest solution unless complexity is a non-negotiable requirement
- **Two-way door decisions**: Solutions should be extensible and evolve over time — avoid static solutions that cannot adapt
- **Pattern-based**: Target solutions that can be codified, reused, and re-shared (reference AWS Architecture Center)

## Prioritized Remediation Plan

### Quick Wins (< 1 week) — "Do First" quadrant
| Finding | Action | SMART Goal | Owner Suggestion | Effort |
|---------|--------|-----------|-----------------|--------|
{Config changes, enabling features, adding tags/alarms — simple, high-impact}

### Foundation (1-4 weeks) — "Plan" quadrant
| Finding | Action | Phases | Effort | Dependencies |
|---------|--------|--------|--------|--------------|
{Multi-AZ, CI/CD improvements, monitoring, caching — phased approach}

### Strategic (1-3 months) — "Plan" quadrant (complex)
| Finding | Action | Phases | Effort | Dependencies |
|---------|--------|--------|--------|--------------|
{DR, re-architecture, compliance programs — two-way door design}

### Deferred — Revisit Next Iteration
{Findings in "Delegate" and "Defer" quadrants with brief justification for deferral}

## Next Steps
{Top 5 concrete actions from the "Do First" quadrant — the team should start this week}

修复代码块 — 可直接复制的修复片段

报告中的每项 🔴 严重/高风险和 🟡 中等风险发现都必须包含一个 Fix: 代码块，其中提供最简短、可直接复制的修复片段，供用户自行应用：

• 匹配语言。 使用步骤 2 中记录的主要 IaC 方言（CDK / CloudFormation / Terraform / SAM）生成代码片段。如果工作负载没有 IaC（例如口头审查），则改用等效的 AWS CLI 命令。
• 以证据为依据。 只要来源可用，就使用发现证据中的实际资源名称和标识符，而非通用占位符。
• 最简化。 只包含弥补问题所需的行；未更改的周边配置用注释省略。
• 仅供报告使用。 修复内容应出现在报告中，供用户审阅和应用。不要将其应用到用户的代码库，也不要将其作为差异/补丁输出（仓库设计原则：审查和指导，而非修改代码）。JSON 产物的 recommendation 字段（步骤 6b）仅使用文字；修复代码块仅放在 Markdown 报告中。
• 复用反模式示例。 如果某项发现符合支柱手册中列出的具名反模式，请从该条目的 Right 示例开始。
• 适用范围。 适用于完整报告和按支柱划分的报告。评分模式和快速审查不提供代码片段，完整 BP Ledger 表也不提供代码片段——修复内容应放在发现部分。

示例（发现 SEC08-BP02，Terraform 工作负载，证据 infra/rds.tf:12）：

Fix:

# infra/rds.tf — aws_db_instance.orders (line 12)
resource "aws_db_instance" "orders" {
  # ...existing configuration...
  storage_encrypted = true
}

步骤 6b：生成结构化输出（aws-well-architected-framework-review.json）

在 Markdown 报告之后，还要生成机器可读的 aws-well-architected-framework-review.json，以便随时间对审查结果进行差异比较（CI 门禁）、跨工作负载汇总，或导入 WA Tool。Markdown 面向人类；此文件面向工具。请遵循版本化契约：schemas/aws-well-architected-framework-review-v1.schema.json。

将其写入工作负载根目录下的 aws-well-architected-framework-review.json（或用户指定的路径）。根据刚刚报告的同一组发现填充文件——不要重新运行分析，只需序列化 Full BP Ledger 中已有的内容。

规则：

• 每个评估过的 BP 都要有一个 findings 条目，包括 implemented 和 not_applicable 条目。使用者必须能够区分已评估且通过的 BP 与从未评估的 BP，因此不要删除通过的条目。
• 对于核心框架 BP，bp_id 必须使用规范的 PILLAR##-BP## 格式——这是基线差异比较所依据的身份键。大多数 lens BP 也提供规范 ID（例如 IOTCOST01-BP01）；请使用该 ID。
• 某些 lens 按主题组织，且不公开 BP ID（serverless-applications、saas、government、healthcare-industry、container-build、sap、streaming-media，以及少数混合情况）。对于这类发现，请省略 bp_id，并提供 title（以及 lens）。标题不是稳定键，因此这类发现仅作为建议报告，不会被设为门禁。不要为了满足差异比较而杜撰 BP ID；这会导致不同审查中的键不一致。
• 将 review_mode 设为实际执行的审查深度（full、quick、pillar-scoped、score）。非 full 审查不会覆盖全部 307 个 BP；请在 recall_note 中说明。
• 将 skill_version 设为此技能 frontmatter 中的 version，并生成唯一的 run_id（例如 {date}T{time}-{workload-slug}），确保同一天的两次审查也能区分。
• 每个差距（not_implemented / partially_implemented）都必须带有 severity（critical/high/medium/low）。CI 门禁会按严重性排序，因此未评级的差距会导致构建默认失败。只有 implemented / not_applicable / cannot_determine 才应省略 severity。
• recall_note 必须说明覆盖范围具有高召回率但并不完整，确保下游门禁不会将缺少的发现视为某项控制措施存在的证明。不要声称未经此环境测量的覆盖率。
• recommendation 应保持为指导性文字，绝不能是代码差异（仓库设计原则）。

结构（权威且完整的定义请参见架构）：

{
  "schema_version": "1.0.0",
  "workload": "{workload name}",
  "date": "{YYYY-MM-DD}",
  "review_mode": "full",
  "skill_version": "2.3.0",
  "run_id": "{date}T{time}-{workload-slug}",
  "lens": ["{lens-name}"],
  "business_criticality": "{critical|high|standard|low}",
  "pillar_scores": {
    "operational_excellence": 3, "security": 2, "reliability": 2,
    "performance_efficiency": 3, "cost_optimization": 4, "sustainability": 3
  },
  "findings": [
    {
      "bp_id": "SEC08-BP01",
      "pillar": "security",
      "status": "not_implemented",
      "severity": "high",
      "evidence": { "file": "infra/s3.tf", "line": 14 },
      "effort": "low",
      "recommendation": "Enable SSE and BlockPublicAccess on the uploads bucket."
    },
    {
      "title": "Use asynchronous invocation for non-critical Lambda work",
      "lens": "serverless-applications",
      "pillar": "performance_efficiency",
      "status": "not_implemented",
      "severity": "medium",
      "recommendation": "Move the notification path to async invocation so the request path is not blocked."
    }
  ],
  "recall_note": "Full review. High recall but not exhaustive; absence of a finding is not proof of implementation."
}

上面的第二个 finding 展示了按主题组织的 lens 发现：没有 bp_id，而是使用 title。它仅作为建议报告，不会被设为门禁。

写入文件后，请告知用户该文件的位置，并引导其用于 CI：

我还写入了 aws-well-architected-framework-review.json（机器可读，符合 schemas/aws-well-architected-framework-review-v1.schema.json）。 请将其提交为 .well-architected/baseline.json，并将 tools/wa-ci 接入流水线，以便根据 Well-Architected 差异对未来的 PR 设置门禁。

步骤 7：提供后续选项

交付报告后，提供以下选项：

您希望我：

• 针对某个支柱进行深入分析并扩展分析内容吗？
• 生成 IaC 模板以修复某项具体发现吗？
• 针对某项具体架构变更制定迁移计划吗？
• 将您的工作负载与某个具体 WA Lens 进行详细比较吗？
• 生成自动化检查项（Config 规则、自定义指标）以持续确保合规吗？
• 设置持续运行的 WA 门禁：将 aws-well-architected-framework-review.json 作为基线提交，并在 CI 中运行 tools/wa-ci？
• 生成 WA Tool 导入文件，以便在 AWS 控制台中进行跟踪吗？
• 将 🔴/🟡 发现登记为跟踪问题，并附上汇总 epic 吗？（步骤 7b——仅在可使用问题跟踪器 CLI 时提供）

步骤 7b：将发现记录为跟踪问题（可选——需确认）

一种可选的输出模式，可将报告中的发现转化为跟踪事项，避免报告过时。绝不自动运行——每次审查都必须经过一次明确的用户确认，默认选择否（设计原则：让用户保持掌控）。

检测跟踪工具。 提出此选项前，先检查问题跟踪工具是否确实可用：优先使用 gh CLI（gh auth status 成功，且工作负载仓库配置了 GitHub 远程地址）；仅当运行时提供了等效工具时，才使用其他跟踪工具。如果没有可用工具，则静默跳过——不要提出此选项——并在报告页脚添加一行：Tracking-issue filing skipped — no issue tracker CLI available.

只询问一次（仅在跟踪工具可用时），作为步骤 7 所提供选项的一部分：

要我将这些发现记录为跟踪问题吗？我会为每个 🔴 Critical/High 和 🟡 Medium 发现创建一个问题，并创建一个包含优先级检查清单的汇总 Epic。Low 和 Cannot Determine 项目只保留在报告中。（默认：否）

当且仅当用户确认时，创建：

1. 为每个 🔴 Critical/High 和 🟡 Medium 发现创建一个问题
   • 标题：[WA][<PILLAR>] <finding title>（例如，[WA][SEC] Uploads bucket lacks Block Public Access）
   • 正文：严重级别、规范格式的 BP ID（SEC01-BP02；若该视角未提供 BP ID，则写明视角和发现标题）、证据引用（文件:行号），以及报告中的修复后续步骤——包括存在时的 Fix: 区块。
2. 一个汇总 Epic
   • 标题：[WA] Well-Architected review — {workload name} ({date})
   • 正文：支柱评分表，以及按 Eisenhower 象限分组、链接到每个发现问题的检查清单（- [ ] #<n> …）（Do First → Plan → Delegate → Defer）。

规则：

• 问题是审查产物，不是代码变更——正文应提供指导和供复制的修复片段，绝不能应用差异。
• 除非用户要求，否则不要添加标签、指派人员或里程碑——将分流工作留给团队。
• 不要为 Low 或 Cannot Determine 项目创建问题（避免跟踪工具中的噪声）；这些项目保留在报告中。
• 完成后，列出创建的问题 URL，并注明该 Epic 是跟踪入口。

校准指南

• 具有多可用区、加密、支持回滚的 CI/CD、监控和自动扩缩的工作负载属于成熟工作负载——大多数发现应是改进项，而非 Critical
• 不要为构建良好的工作负载凭空制造 Critical 发现——准确性优先于警报
• 当业务关键性为“low”或“standard”时，应接受较简单的架构（内部工具使用单区域即可）
• 当业务关键性为“critical”时，应采用更严格的标准（多区域 DR、混沌测试，预期 RTO 小于一分钟）
• 每条可确定的发现都必须有具体的代码、配置、运行时或用户明确提供的证据作为依据——不得提出缺乏依据的泛泛建议
• 如果无法根据现有证据得出结论，请写明“Cannot Determine”，将严重级别留空，并说明还需要哪些运行时或访谈数据
• 应显著肯定优点——成熟的工作负载应让人感到其得到了认可，而不只是受到批评