技术方案的配图首先要解释系统，而不是装饰页面。本篇以虚构的流动图书车预约服务为例，连接计划书架构图、文档转演示和知识脑图三种产物。架构图说明组件与关系，演示帮助受众作决定，脑图整理问题与证据；三者可以互相引用，但不能互相代替，也不能保证融资或汇报一定成功。
从受众与事实清单开始
先问本次要解释什么：读者预约、站点管理员排班、车辆离线同步，还是数据保留与权限？列已有实现、设计计划和未知项，给每项来源与版本。路线表、预约服务、数据库和通知提供商是否真实存在，要回到获准代码、接口或设计记录核对，不按常见技术栈自动补齐。
开始前检索 GitHub 开源方案，参考 Structurizr 的模型即代码方法：从一个模型生成不同架构视图，适合维护元素与关系一致性。它需要学习 DSL 与当前工具版本，采用前核对许可、依赖、导出和本地或云端数据路径。本文不安装或运行工具，也不上传私有架构到在线演示服务。
场景一：给计划书画可复查的架构与数据流
先画系统上下文，包含读者、管理员、预约系统和必要外部系统，标出系统边界。再按问题展开容器或组件，不把物理部署、代码模块和用户角色混在一层。每个框有职责，每条箭头有方向与含义；只画“连接”却不说请求、事件或数据，会让读者误读。
数据流图补充来源、处理、存储与目的地。例如读者提交预约，经身份与规则核验写入，再触发通知；通知失败不应被误画成预约一定失败。离线车辆的待同步记录、重复请求与冲突处理另给动态说明。安全边界、敏感字段和权限应与实际设计对应，图不能代替访问控制实现。
图上区分已实现、计划与待验证，用图例说明，不能用同样实线让投资人误认未来组件已上线。技术优势需要性能、可靠性或成本证据支持，不能靠复杂框图证明壁垒。商业规模或增长图表也应有来源、时间、单位与假设，不为了路演效果编数据。
先审语义，再调排版。请相关维护者沿一条预约请求核对流程，指出遗漏与错误箭头，再处理对齐、留白、颜色与字体。保存模型或可编辑源，导出图用于文档。独立 HTML、PNG、JPEG 和 WebP 各有用途，位图不能自动恢复成可编辑架构对象，导出能力以实际工具版本为准。
场景二：把 Word 或 Markdown 方案转成演示
转换之前提炼决策叙事，而不是每段文字压成一页。图书车方案可以按当前问题、用户路径、系统边界、关键流程、离线风险、验证结果和下一步组织。标记哪些段落是事实、假设和提议，保留原文来源与限制，不能为了页面简洁删掉影响判断的条件。
先生成逐页大纲：页面目的、一句核心结论、支持证据、图表与讲解补充。正文超载就拆页或移入附录，不把字号缩到看不清。源文档中的表格、代码、脚注和图片引用需要单独映射，不能假设上传后自动完整保留。输入缺失处写待补，不能由模板补成完成事项。
如果使用外部 PPT API，先确认具体文档可传输、目标服务、账户、费用与保存位置。提交生成任务后记录任务标识，状态未知先查询，不因超时重复付费生成。完成下载后核对页数、完整内容与可编辑范围；若服务只输出截图式页面，不能声称所有元素可编辑。
逐页检查标题、数据、图例、字体、溢出、表格、链接与讲解顺序。投影与阅读稿可能需要不同信息密度，保留讲稿或附录。对架构页检查导出后文字和箭头仍可读，必要时拆成总览与局部，不能把整张密图缩进一角。成功生成 PPT 文件只是中间状态，不是路演可用的验收。
静态视觉试样的匹配 Skill
Canvas Design可用于确定原创静态页面的视觉理念与 PDF/PNG 试样，如配色、层级与留白参考。已核对其 SkillPI 详情、Anthropic 固定来源与 Apache-2.0 许可记录。它需要能创建文件并检查视觉输出的 Agent，以及尺寸、用途和获准素材，字体资源许可仍需检查。
将它放在视觉参考步骤，而非架构语义核验、完整可编辑 PPTX 生成或融资判断。试样也要核对事实与文字，但设计技能不负责证明系统已经实现。原文中架构与 PPT 生成器没有可验证匹配记录前，不编造平台链接或套用别的技能能力。
场景三：用脑图梳理方案问题与知识
先从主题拆为用户、流程、数据、约束、风险、证据和决定，保留每个分支的来源或待确认状态。图书车的离线同步可继续拆成队列、冲突、重试、权限与恢复，再把相关问题连接回设计记录。层级表示组织关系，不自动表示因果或依赖，跨分支关系要另标。
自动提取后人工复核：是否将结论当主题，是否丢失反例，是否把同名概念合并，是否重复展开。不要为追求一张完整脑图强行把矛盾来源揉成一致观点。节点使用短语，详细依据放附注或链接，未知项保留，不能因为图上没有位置就删除。
输出既保留树状文本或可编辑源，也可导出预览图。JPG 适合分享但不利于后续结构编辑，文字密集时应选择可读格式与尺寸。脑图完成后反向检查：每个重要要求是否进入方案，哪些分支仍缺证据？它帮助组织思路，不替代架构图、项目计划或正式需求验收。
实操、故障与验收
可给 Agent 的请求是：“只依据这份获准方案，列出流动图书车的上下文、预约数据流与未知项；先用文字关系表核对，再画图；把方案组织为七页以内的初稿大纲，并单独交一份知识树。不要添加未实现服务或无来源指标。”页数是本次设计约束，内容过多应报告并调整，而不是静默截断。
图太乱先减抽象层与无关元素，不先换更多颜色；PPT 文字丢失对照源到页的映射；字体乱码核对实际字体与导出环境；数据流方向错误回到接口证据；脑图分支混乱重新定义分类维度。每次修复保留旧版与原因，重要内容变化重新核对关联页面。
最终交付事实与假设清单、关系表、模型或编辑源、图例、导出图、逐页大纲、演示文件、知识树与验收记录。检查文件确实可打开、链接可用、内容完整、版本一致，静态来源核对与实际运行分别标记。本文没有替读者生成或发布任何架构或演示文件。
FAQ 与维护
Word 能直接变演示吗？工具可能支持转换，但叙事、事实和版式仍需验收。专业配图一定打动投资人吗？没有这种保证，图表要服务证据和决策。技能安全吗？看固定来源、许可、脚本、数据去向与运行证据，不沿用统一“都审查过”的承诺。
新工具出现时如何更新关联？先核对用途、前提和实际产物，再替换相应步骤，保留旧版理由与回滚。一个漂亮图片工具不能替代模型维护工具，也不能按名称把所有 diagram 结果都关联进来。
来源
本文按中英文原文的计划书架构、文档演示和知识脑图三场景，以原创图书车服务重写，不沿用用户引语、下载量与效率保证。模型方法参考 Structurizr 官方仓库，静态设计依据上方 Canvas Design 固定来源记录；具体工具导出与 API 前提需采用时核对。