技能提升网架构图画得很完整，评审会上却没人能回答峰值流量翻倍会先坏在哪里，也说不清主区域故障后多久能恢复。组件齐全不等于方案可以决策。
AI能把散落的需求、假设和设计选择整理成一份评审文档。每个关键结论都要带来源、适用条件和验证办法，架构师仍需为取舍负责。
先准备一份能追溯的输入包
本次任务至少要收齐组件图、容量仪表、安全检查表、恢复时间线和接口卡。每份资料记录版本、截止时间和提供人；数字、条款或决定来自哪里，也要能够回查。资料缺失时保留空白和待确认标记，不让AI补出一个看似完整的答案。
从不可妥协的约束开始
先写清数据范围、合规要求、响应目标、峰值负载和恢复时间。没有证据的容量数字标成待验证假设，不能直接作为采购或上线依据。
数据流比组件清单更容易暴露缺口
沿着一次真实请求追踪入口、鉴权、存储、异步任务和外部依赖。对每段标明失败方式、重试规则和数据一致性要求，避免只画方框。
把取舍写进正文而不是会议口头说明
DOCX Skill可以基于System Design 模板生成可继续编辑的DOCX，并保留表格和章节结构。每个备选方案都写明收益、成本、操作复杂度和放弃它的原因。
恢复目标需要对应真实步骤
RTO和RPO后面要接恢复流程、负责人、依赖和演练记录。声明多活或自动切换之前，先确认数据复制、密钥和第三方服务在故障时是否仍可用。
评审结论必须能转成验证任务
容量测试、安全测试、故障演练和监控建设分别列出负责人和完成标准。没有验证计划的架构结论只能算假设。
把结果分成可采用、待确认和不能判断
AI输出后，按需求、设计、取舍和验证重新标记结论。证据完整且计算可复核的内容进入正式稿；依赖假设的内容交给负责人确认；超出资料或职责边界的内容明确写成不能判断。这样可以避免把排版完整误当成结论可靠。
交付前由人确认什么
把DOCX渲染成页面后逐页检查表格、分页、目录、图片和批注位置。任何结论都应能回到输入材料；涉及财务、投资、技术安全或法律责任时，由相应负责人作最终判断。
