做技术汇报时，架构图真正要解决的是“听众能否看懂系统边界、关键关系和这次变化”。把一段系统名称交给 AI，得到漂亮盒子并不等于画对了架构。本篇用虚构的社区工具借用服务，分别处理快速初稿、可继续修改的源文件，以及把图放进 PPT 后的可读性。示例只说明方法，没有声称已扫描代码、渲染文件或完成真实交付。
先确定这一页要回答什么
先问听众需要作什么决定。向运营解释借用流程，可以画用户、借用服务与通知渠道；向研发评审一致性，需要展开库存校验、预约记录与异步通知；向负责人汇报个人贡献，则在同一底图上标注已完成、进行中和未纳入范围。不要用一个颜色同时表示团队归属、运行环境和完成状态。
准备最小输入包：模块清单、关系表、术语表、已知限制和待确认项。每个模块记录稳定编号、职责、部署形态与来源；每条关系记录调用方向、传递内容、同步或异步、协议已知与否。没有证据的数据库、缓存、消息队列不要让模型自动补齐。计划中的组件必须明显标“拟议”，不能画成已上线。
交付标准先约定：能在目标幻灯片尺寸读清标签，箭头含义一致，边界与图例完整，源文件可重新打开，输出格式与目标 PowerPoint 环境兼容。把“十分钟出图”当时间预算，不当质量保证；到时先保住正确边界和可读主链路，不为填满画面新增无根据的模块。
场景一：从一句描述形成可核对的架构初稿
原始描述可以是“居民查询工具并预约，管理员确认领取，系统发通知”。先让 Agent 返回问题和关系表，再画图：居民访问门户，门户调用借用 API，API 查询库存与预约记录，已确认的业务事件触发通知。是否存在独立通知服务、消息中间件或第三方接口，都要核实。描述不足时可画带问号的候选边，而不是把惯例当现状。
把每个节点和箭头逐项对回输入。N-01 门户负责交互，不应同时被标为数据库；E-03 表示 API 读取库存，箭头就不能被解读为数据复制。若一次借用请求既更新记录又产生通知，说明它们在当前实现中怎样衔接，未知的事务和失败补偿留作评审问题。静态关系图回答谁依赖谁，执行顺序另用时序或流程视图解释。
按 C4 的层次选择视角时，上下文图看人与外部系统，容器图看系统内部主要应用与数据存储，组件图再展开单个容器内部，代码层级按需要使用。部署图是补充视图，不是把第四层代码图换个名字。小型汇报不必四层齐画；一张容器图加一张关键流程图可能更适合当前问题。
初稿的验收不是“看起来专业”，而是节点有责任、关系有语义、外部边界无遗漏、未知项可见。请另一位熟悉系统的人不听讲解直接复述主路径；如果他把通知失败理解为借用记录回滚，就说明图还缺少边界或注释。用评审反馈修正关系表，再调整布局，避免只修图不修事实。
场景二：把可编辑性作为交付要求
需要多人反复评审时，先选源格式再选图片。Mermaid 文本适合用版本管理比较关系变化；.drawio 文件适合在图形编辑器中移动、分组和连接节点。SVG 是矢量输出，但“导入后仍是可编辑业务节点”取决于工具和导出方式，不能因为扩展名是 SVG 就作保证。PNG 适合稳定展示，却通常不能恢复成原来的节点与连线。
GitHub 上的 jgraph/drawio 提供通用图形编辑器代码，代码许可为 Apache-2.0，图标等资产还应按仓库具体条款核对。选择它作为可编辑源文件参考，是因为已有图形编辑与导出工作流，不需要另造编辑器；采用前仍要确认实际版本、运行方式和集成成本。这里没有安装或部署该仓库，也不把开源代码等同于所有服务免费。
保留 architecture-v1.drawio 或等价图源、模块关系表、导出文件与简短 README。README 说明编辑器版本、字体、页面尺寸、输出方式和已知限制。不要只交一张截图。若选择包含图源的导出，必须实际重新打开验证源是否完整；即使某格式能带源，也不能代替独立源文件备份。
修订时用稳定节点编号。假设评审提出增加管理员确认，不要随手在旧图旁加一个方框；先更新关系表，确定它是现有模块的新责任，还是需要独立组件。再修改源图，记录改变的节点、关系和理由，重新导出并检查所有引用此图的页面，防止 PPT 中还留着上一版。
实操：一次加入通知失败路径的修订
设初稿只画“确认借用→通知成功”。评审指出短信可能失败。先把事实写清：借用是否已经提交，通知是否可重试，谁查看失败队列，用户在哪里查询最终状态。当前没有实现的补偿机制只能标为建议，不能当现有能力。
在主架构图保留借用服务与通知边界，另加一张小流程图表达成功、失败和重试的业务关系。每条失败边附触发条件，不用红色虚线替代语义。通知失败不一定意味着借用失败；应由团队确认业务规则后，再用注释说明最终状态。这样图既能进入汇报，也能成为后续技术讨论的入口。
给 Agent 的任务可以写为：“只用 modules.csv、relations.csv 与 review-notes.md，生成社区工具借用服务的架构初稿。先报告冲突和缺失信息，节点与关系保留编号。未核实的组件标为拟议。提供可编辑源文本及导出建议，不访问生产环境，不声称已经渲染或测试。列出与上一版相比的关系变化。”先接受关系正确性，再接受视觉效果。
场景三：放进 PPT 后重新验收
先确认页面比例、主题字体、背景和图的预留区域。标题应直接陈述这一页的信息，例如“通知故障与借用记录分开恢复”，而不是只有“系统架构”。保留一条清楚的阅读方向，把主链路与辅助关系区分开；关系密集时拆页，不靠不断缩小字号装下全部内容。
选择输出时区分展示与编辑需求。目标环境支持且经过实际检查的矢量格式可减少放大模糊；兼容性不足时用足够分辨率的 PNG，并保留源图。PDF 适合分发和打印，但插入、转换和逐元素编辑能力依工具而异。不能把“可打印 HTML”直接说成“已经生成可编辑 PPTX”。
在目标演示软件里打开，查看文字替换、透明背景、线宽、箭头、裁切与字体缺字。使用正常放映比例检查，不只在编辑器里放大预览；再导出 PDF 检查分页和裁切。核对正文与图的版本号，确认成功路径、失败注释和责任图例都在。用形状、线型和标签共同表达含义，不让读者只能靠颜色区分重要信息。
最终产物至少包含可编辑源、展示导出、所在幻灯片、关系表和验收记录。记录实际用哪个软件和版本检查过哪些页面；没有打开过 PowerPoint，就写待验证，而不是宣称跨工具兼容。汇报前改一处标签也要重新看相关页，自动布局可能同时改变箭头路径与文字位置。
Skill 选择与本次关联结果
本次 SkillPI 目录以 diagram 检索取得“Write a codebase wiki page”候选，其页面用途是读取组件实现并形成带源码引用和 Mermaid 的技术文档。它更适合已有代码的文档梳理，而非从一句描述直接交付可编辑 PPT；其页面许可证与再分发状态仍未核实，本次也未能取得固定版本原文，因此不把它作为已核验的推荐安装关联。
原文列举的其他绘图技能也不凭名称生成 SkillPI 链接。当前流程可先使用团队已经掌握的绘图和幻灯片工具。后续候选须核查来源仓库、固定版本、许可、输入输出、是否需要 API Key、外部连接器、Node.js 或图片渲染依赖，再用同一个脱敏案例试用。生成源文件、渲染成功和目标软件验收是三个独立结果。
故障排查与 FAQ
图太密怎么办？先减少这一页要回答的问题，按层次拆分，并提供跳转或编号；不要删除真实依赖来制造整齐。导出图片模糊怎么办？检查导出尺寸、页面缩放和目标软件的压缩设置，必要时更换经过验证的矢量方式。字体错位怎么办？确认目标机器字体与替代规则，避免用很窄的文本框刚好卡住长标签。
不会代码能做吗？可以先用模块与关系表让 Agent 起草，再在图形工具中改，但仍需有人确认系统事实。拿到 Mermaid 就算成图了吗？不算，它还需要兼容渲染器和布局检查。能否保证十分钟完成？不能，取决于输入质量、图复杂度与环境；优先交付可审阅初稿并列出剩余检查。以后技能增多怎么更新？定期用固定样例核对候选能力与来源，真正满足某一步的输入、输出和权限前提后再关联，保留替换原因和验收日期。