wa-review

架构完善性审查

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

请用户描述工作负载：

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

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

如果用户已提供架构详情，或您当前所在代码库包含 IaC，请跳过提示并开始探索。

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

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

• SaaS、无服务器、数据分析、机器学习、IoT、容器、游戏、金融服务、医疗保健

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

步骤 2：基础设施探索

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

您必须检查：

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

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

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

您必须使用 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）——针对单个支柱的领域专属证据收集指南：要检查哪些资源、哪些模式应标记为 HIGH RISK，以及该支柱专属的报告格式。每个全面审查子代理都会加载其支柱的操作手册（步骤 4b），以便发现结果由具体的文件:行证据支撑，而非泛泛复述 BP。

全面审查的强制加载模式

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

Read: references/manifest.md

这会在约 24 KB 的内容中提供每个 BP ID 和标题。

步骤 4b——并行调度 6 个支柱子代理（全面覆盖的强制要求）：

为何采用此模式： 实测表明，单个 Agent 尝试在一条回复中枚举全部 307 个 BP 时，只会产生 20–60 条发现并停止——无论提示词强度、检索策略（本地文件、MCP 或混合方式）如何，也无论是否明确要求“评估全部 307 项”。这是模型简洁倾向所形成的稳定行为均衡。

解决方案： 缩小每个子代理的范围。一个 Agent 审查一个支柱时，会自然地枚举该支柱的 30–55 个 BP。调度 6 个并行子代理（每个负责一个支柱），汇总后可覆盖 约 307 个 BP——在 evals/study_mcp 中实测覆盖率为 100%（307/307），且零幻觉。

在同一轮中调度全部 6 次 Task 调用（并行执行）。每个子代理都必须返回结构化 Markdown 表格，以便顶层汇总器逐字合并发现结果，无需改写。

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

## {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## 格式

将以下校准规则原样附加到每个支柱子代理提示词中：

应用证据充分性门槛：缺失或不确定的信息属于 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 调用。 每个子代理都使用独立上下文独立运行，因此每个子代理都能彻底审查，而不会挤占其他子代理的工作量。统一的表格格式使汇总成为机械式拼接，而非解释性摘要——这样可以避免叙述式子代理输出中观察到的约 30–70% 召回损失。

成本/延迟： 所需 Token 约为单 Agent 审查的 3–4 倍（每个子代理都会重复加载工作上下文），但总耗时取决于最慢的单个支柱（约 2–3 分钟）。用户需要在成本与覆盖率之间权衡。 何时跳过子 Agent 调度：

• 用户明确要求进行 快速审查 / 评分模式 / 限定支柱范围的审查——这些模式保持单 Agent
• 在 受成本限制 的环境中，无法接受 3-4 倍的 token 用量——改为单 Agent 审查，但要如实告知用户，覆盖范围约为 50-60 个 BP，而非 307 个

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

全部 6 个子 Agent 返回后，将其发现合并为一份结构化报告。**重要：**逐条保留每个子 Agent 给出的 BP 引用。汇总步骤应当是合并，而不是摘要——不得改述、归类或省略子 Agent 提出的 BP 引用。实证测量表明，召集整理时通常会损失召回率：子 Agent 提出了 250-307 个 BP，而草率汇总会将最终报告中的数量压缩至 60-90 个。

汇总规则——请全部遵守：

1. 必须提供完整 BP 清单。 报告必须包含“完整 BP 清单”部分（见步骤 6），并为每个子 Agent 提出的每个 BP 状态分别列出一行。如果子 Agent A 将 SEC03-BP02 列为未实施，该条目就必须逐字出现在清单中，不得改述。
2. 不得按支柱压缩。 最终输出中，严禁将某个子 Agent 提出的 45 条 BP 引用缩减为“每个支柱的前 5 项发现”。每条引用的 BP 都必须出现在清单中。高严重性发现还必须在“严重和高风险发现”部分中提供完整详细说明，但这是清单之外的补充，绝不能取代清单。
3. 写作前核对数量。 返回报告前，统计汇总草稿中 PILLAR##-BP## 格式的 BP ID 数量。如果数量少于子 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).

Empirical measurement shows this section is where recall reaches the user. Skipping it or truncating it drops final-report recall from ~1.00 (what the subagents surface) to ~0.30 (what the assembler compresses to). **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, effort, AWS services. This section EXPANDS on rows in the Full BP Ledger — it does NOT replace them.}

## Medium Risk Findings
{Same format, condensed. 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):

    高重要性
         │

┌─────────┼─────────┐ │ 先 │ 计划 │ │ 执行 │ │ │ │ │ ───┼─────────┼─────────┼─── │ │ │ │委派 │ 延后 │ │ │ │ └─────────┼─────────┘ │ 低重要性 低工作量 高工作量

| 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}

第 6b 步：输出结构化结果（wa-review.json）

在 Markdown 报告之后，还要输出机器可读的 wa-review.json，以便随时间对审查结果进行差异比较（CI 门禁）、跨工作负载汇总，或导入 WA Tool。Markdown 供人阅读；此文件供工具使用。请遵循 schemas/wa-review-v1.schema.json 中的版本化契约。

将文件写入工作负载根目录下的 wa-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）。非完整审查不会覆盖全部 307 个 BP；请在 recall_note 中说明。
• 将 skill_version 设为此 skill 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 必须说明覆盖率具有高召回率但并不全面（wa-review 的 F1 约为 0.96），以免下游门禁将未发现条目视为控制措施存在的证据。
• recommendation 应提供文字指导——不得包含代码差异（这是仓库的设计原则）。

结构（权威且完整的定义请参阅 schema）：

{
  "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, F1 approx 0.96. High recall but not exhaustive; absence of a finding is not proof of implementation."
}

上方的第二条发现展示了按主题组织的 lens 发现：没有 bp_id，而是使用 title。该条为建议项（会报告，但不会触发门禁）。

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

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

第 7 步：提供后续协助

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

你希望我：

• 针对某个支柱进行深入分析并扩展分析内容？
• 为特定发现生成 IaC 模板以进行修复？
• 针对特定架构变更制定迁移计划？
• 将你的工作负载与特定 WA Lens 进行详细比较？
• 生成自动化检查（Config 规则、自定义指标），以持续确保合规？
• 设置持续运行的 WA 门禁：将 wa-review.json 提交为基线，并在 CI 中运行 tools/wa-ci？
• 生成 WA Tool 导入文件，以便在 AWS 控制台中跟踪？

校准指南

• 如果工作负载具备多可用区、加密、支持回滚的 CI/CD、监控和自动扩缩容，则属于成熟工作负载——大多数发现应归为改进项，而非严重问题
• 不要为构建良好的工作负载凭空捏造严重问题——准确性优先于危言耸听
• 当业务关键性为“低”或“标准”时，应接受较简单的架构（内部工具使用单区域架构即可）
• 当业务关键性为“关键”时，应采用更严格的标准（需要多区域灾难恢复、混沌测试，并预期 RTO 低于一分钟）
• 每项确定的发现都必须有具体的代码、配置、运行时或用户明确提供的证据作为依据——没有依据时，不要给出泛泛的建议
• 如果无法根据现有证据确定某项内容，请注明“无法确定”，将严重性留空，并说明需要哪些运行时或访谈数据
• 应突出肯定优势——成熟的工作负载应让人感到其得到了认可，而不只是受到批评