程序员述职答辩 PPT 画图指南：结构图、架构图、流程图与逻辑图的绘制思路与实战方法

• 文档
• 教程
• 后端

导读

述职、答辩、评审、技术分享，几乎每一场都要靠图说话。可很多程序员能写代码却画不出图：梳理不出架构、画不清流程、讲不明白逻辑。本文以 CodeGuide 仓库中《PPT画成这样，述职答辩还能过吗？》一文为主线，系统讲解述职答辩 PPT 中五类核心技术图（结构图、架构图、功能图、流程图、逻辑图）的定位、画法与适用场景，并结合仓库内架构设计文档与 ThreadLocal 源码分析，给出从"思维导图起步"到"逻辑图画明白"的完整进阶路径。读完你不仅能掌握每类图该画什么、怎么画，还能理解一张好图背后的技术深度与沟通逻辑。

一、为什么程序员必须学会画图

PPT、Word、Excel 都是工具，但它们在各自领域的内容展现形式完全不同。软件行业的 PPT 里，出现最多的往往是架构图——把真实系统用图的方式表达出来。一张清晰的架构图，应当以解决共识、减少分歧、降低沟通成本为结果。

这句话可以拆成四个可落地的标准，仓库中《工作两三年了，整不明白架构图都画啥？》一文给出了很好的提炼：

• 好看：提升沟通效率；
• 好懂：提升交流共识；
• 好用：提升交付质量；
• 好搞：提升实施速度。

代码本质上是数学逻辑的具体实现，偏理科的逻辑与架构设计，抽象内容很难靠纯文字达成共识。这也是为什么"分享、评审、述职、答辩"几乎离不开画图——图表不是为了内卷，而是为了让所有人在同一共识下协同工作。

二、述职准备的第一步：用思维导图梳理内容

开始画 PPT 之前，先别急着打开 PPT。原文档中组长给谢飞机的建议，正是最实用的一步：

先把这次述职要讲的内容，用思维导图总结出来，比如：介绍自己、参与项目、系统架构、核心流程等等。之后每一个章节再画出你要的图稿，这些图稿是辅助你来演讲的。不要大片大片写文字，文字部分是你要很流畅地说出来的，但不是照着 PPT 念出来的。

思维导图在这里承担的是目录与提纲的作用，它决定了 PPT 的章节骨架。仓库中《大学四年到毕业工作5年的学习路线资源汇总》也印证了这一工具的定位：XMind 用于画出树形结构的思路整理，Visio 用于绘制各种流程图（网络图、组织结构图、工程设计等），二者配合可以覆盖从梳理思路到产出图稿的全过程。

也就是说，述职 PPT 的产出链路是：

1. 用 XMind 梳理述职内容的章节结构（介绍自己、参与项目、系统架构、核心流程）；
2. 为每个章节绘制对应的图稿（架构图、流程图等）；
3. 图稿只是演讲的辅助，真正的表达要靠流畅的口述，而不是念 PPT 上的文字。

三、画图前的认知：架构图不止一种

很多人一提架构图就头疼，是因为把"架构图"当成了一张固定的图。实际上，面向不同的人群和场景，架构图可以分为多种类型。仓库中的架构专题文档给出了完整分类：

• 业务架构：需求初期业务结果和过程的描述，侧重业务规划、业务模块和流程，回答"做什么、为什么做"；
• 应用架构：服务复用、跨组协同，考虑输入法、支付、消息等公共能力如何沉淀为平台服务；
• 产品架构：业务提需求、产品定方案，比业务架构更细腻，考虑模块分层与边界；
• 数据架构：解决数据的获取、存放与使用，涉及数据库、大数据汇总与分析；
• 技术架构：离程序员最近的架构设计，描述整个系统如何落地，包含结构、功能、流程、逻辑等具体实现方案。

而《笔记整理：技术架构涵盖内容和演变过程总结》进一步指出，架构不只是 IDEA 里的工程结构，而是应用场景、业务规模、服务类型、部署结构、开发框架、技术选型综合在一起的结果。画架构图前先想清楚这六个要素，图才有内容可画，而不是凭空画一堆方框。

此外，如果希望从更宏观的视角理解架构描述维度，可以了解Zachman 框架——由约翰·扎科曼（John Zachman）在 1987 年创立的企业架构理论。它以"数据（What）、功能（How）、网络（Where）、人（Who）、时间（When）、原因（Why）"六个横向角度，叠加规划者、拥有者、设计者、建造者、分包者、产品六个纵向视角，把企业信息体系描述清楚。这一部分可以当作架构设计的扩展知识学习。

四、述职 PPT 的五类核心图：画法、难度与点评

原文档以实际图稿为例，给出了述职中最常用的五类图，每一类都配有难度与点评。下面逐类展开，并结合仓库源码补充深度。

1. 结构图：站在全局视角观察系统

• 用途：为了站在某个全局角度观察整体系统视角，画一些较粗粒度的结构图。原文档示例采用立体图（物理视图的一种方式），体现从研发开发到上线运维的整体视角，展示系统软硬件的关联关系，反映系统组件如何部署到机器节点。
• 难度：四颗星（⭐⭐⭐⭐）。立体图在 PPT 里相对难画，但展示效果好，尤其适合描述系统部署结构与实施过程。
• 点评：这类图的关键是"全局视角"——把组件、机器节点、部署关系在一张图里说清楚。如果你需要这类图的参考，仓库中《API 网关 - 媲美美团这套Shepherd网关架构！》等网关系列文章中的部署结构示意，都是很好的观察对象。

原文档还玩了个"恶搞"：把结构图的文字全部替换成虚构内容后，图依然很有画面感。这恰恰说明结构图的骨架（框、线、层级关系）本身就有很强的表达力，文字只是注脚。

2. 架构图：展示分层与标准

• 用途：展示系统架构分层、制定标准规范的演示图，也用于描述系统服务分层（如支付宝架构演变、微信支付架构等）。
• 难度：三颗星（⭐⭐⭐）。这类图不难画，结构上分上下和左右：上下代表系统分层，左右代表不同区域分块。
• 点评：按"上下分层、左右分块"的结构，基本就能把系统架构说明白。不必拘泥于某种形式，重点是把事情讲清楚。

值得注意的是，仓库中《工作两三年了，整不明白架构图都画啥？》还补充了架构图的三个常见变体，难度逐级提升：

• 架构选型图（⭐⭐⭐）：新项目初期做技术选型，在负载、网关、架构、治理、框架、服务、数据、环境与支撑服务上圈定技术栈；
• 微服务架构图（⭐⭐⭐⭐）：技术选型完毕后"搭积木"，把每个区域用合适的技术填充进去；
• 技术架构图（⭐⭐⭐⭐）：面向研发层做技术实现指导，把系统分层和实现结构划分清楚，通常配合工程目录结构一起讲解。

3. 功能图：定义核心数据流向与交互

• 用途：在表述完系统架构后，对系统核心数据流向、通信方式、交互关系进行定义和展示。这是架构图中的核心业务实现部分，有了统一结构，所有研发都能在一个标准下开发。
• 难度：三颗星（⭐⭐⭐）。
• 点评：原文档中的示例是一张面向领域驱动设计（DDD）的系统模块交互图，从左到右展示数据流向及与其他系统间的数据关系。这类图的核心价值在于区分系统边界职责，避免定义混乱、职责不清、乱开发。

如果你在做 DDD 落地的述职，仓库中《初识领域驱动设计DDD落地》与《怎么说服领导，能让我用DDD架构》里的模块划分思路，可以直接迁移到功能图的边界划分上。

4. 流程图：指导功能实现的核心走向

• 用途：研发最常见的图，即 Visio 中画的业务流程，用于指导研发开发。可以由产品设计，再由研发整理成技术实现流程。
• 难度：两颗星（⭐⭐）。
• 点评：这类图通常体现在 Visio 的泳道图里，而画在 PPT 中的是经过缩减后展示核心流程的版本（例如是否过风控等分支不一定画出）。重点在于对核心重点流程的讲解和示意。

流程图的价值在于"每一个走向都在指导功能实现"。以仓库中的拼团交易为例，《第2-10节：责任链抽象模板设计》与《第2-11节：交易规则责任链过滤》展示了如何把"校验、过滤、结算"等环节抽象为责任链节点——这种由流程图抽象出的实现模型，正是述职时"画一张图讲一个核心流程"的最佳素材。

5. 逻辑图：最难也最见功力的图

• 用途：逻辑图是整个系统架构图的一部分，也是最难的部分，因为它要把系统中复杂的逻辑展示到图上，尤其是涉及数学逻辑的内容。
• 难度：四颗星（⭐⭐⭐⭐）。
• 点评：难点在于把本身抽象的数学逻辑，用很好的图表达清楚，让受众看图就能理解逻辑核心，从而极大降低沟通成本。

原文档中的示例是ThreadLocal开放寻址插入数据的逻辑图。它背后对应的技术深度，恰恰在仓库《面经手册 · 第12篇《面试官，ThreadLocal 你要这么问，我就挂了！》》中有完整分析，可以从三个层面理解这张逻辑图：

第一层：数据结构。ThreadLocal底层是数组结构，配合哈希计算下标，本质上是一个散列表；发生哈希碰撞时不采用链表或红黑树，而是开放寻址（+1 向后寻址，直到找到空位置或垃圾回收位置）。同时Entry是弱引用实现（static class Entry extends WeakReference<ThreadLocal<?>>），只要没有强引用存在，GC 时就会被回收。

第二层：散列算法。ThreadLocal使用的是斐波那契（Fibonacci）散列法，核心代码是：

private static final int HASH_INCREMENT = 0x61c88647; private static int nextHashCode() { return nextHashCode.getAndAdd(HASH_INCREMENT); }

神秘数字0x61c88647来自黄金分割点(√5 - 1) / 2 ≈ 0.6180339887，用2^32 * 0.6180339887计算得到十进制-1640531527，即十六进制的0x61c88647。

第三层：散列效果验证。文档中给出了单元测试，对比斐波那契散列与普通散列在 16 个槽位上的分布：

@Test public void test_idx() { int hashCode = 0; for (int i = 0; i < 16; i++) { hashCode = i * HASH_INCREMENT + HASH_INCREMENT; int idx = hashCode & 15; System.out.println("斐波那契散列：" + idx + " 普通散列：" + (String.valueOf(i).hashCode() & 15)); } }

测试结果显示斐波那契散列在 16 个槽位上分布非常均匀，而普通散列在 15 个以后已经开始产生碰撞。斐波那契散列减少碰撞，让数据存储更分散，获取数据的时间复杂度基本保持在 O(1)。

画这类图的启示：一张合格的逻辑图，背后必须有扎实的源码与数学原理支撑。画图不是画方框，而是"先读懂逻辑、再表达逻辑"。这也是为什么原文档点评强调——逻辑图最难的部分，是把抽象的数学逻辑用图表达清楚，让看图的人"一眼就懂"。

五、工具选型：从 PPT、Visio、XMind 到 AI 辅助绘图

关于画图工具，原文档的结论非常务实：

• 文章里的图其实都是在PPT上画的，只要有格子、线条、颜色等元素就可以画图；
• 其他工具也一样，例如Visio也能画；
• XMind是非常好的思路整理工具。

这三者的分工可以概括为：XMind 理思路、Visio 画严谨流程、PPT 出呈现效果。仓库的开发者学习路线中，也一直把 XMind、Visio 作为研发的必备工具项。

而在当前仓库中，画图这件事已经有了新的演进方向：AI 辅助画图。仓库收录了《draw.io + ai Agent，确实打开新思路》一文，介绍了 draw.io（一个用于绘制通用图表的 JavaScript 客户端编辑器）如何与 AI 结合：

• MCP 方式对接：通过drawio-mcp-server建立 AI 与 draw.io 的连接。配置方式是在 MCP 服务配置中声明：

{ "mcpServers": { "drawio": { "command": "npx", "args": [ "-y", "drawio-mcp-server" ] } } }

对接之后，可以在对话框里提问，AI 实时出设计图；也可以把自己的代码拖进去，让它直接出架构图、流程图、模型图，再手工微调。

• 二开方式使用：基于 draw.io 二次开发并结合 AI 能力的 Web 应用（如 next-ai-draw-io），通过自然语言命令和 AI 辅助可视化来创建、修改和增强图表。仓库中《第4-0节：ai + draw.io 产品设计》更进一步，展示了基于 AI Agent 智能体脚手架，用 react 把 draw.io 嵌入程序，AI 以 xml 格式返回绘图内容、draw.io 渲染出来的完整闭环。

这对述职画图意味着什么：逻辑清晰的架构图、流程图，可以让 AI 快速生成初稿，你再基于对系统的理解做校正与细化。但正如原文档强调的——图是辅助表达的工具，最终能不能把系统讲明白，靠的还是自己对技术深度的理解。

六、总结

• 述职 PPT 中的图，本质是降低沟通成本的辅助工具，画图的顺序应该是：先 XMind 理清述职内容结构，再逐章产出图稿，最后用口述把内容讲流畅；
• 软件行业 PPT 以架构图居多，而架构图不止一种：业务架构、应用架构、产品架构、数据架构、技术架构面向不同人群，画之前先明确受众与目标；
• 五类核心技术图各有侧重：结构图讲全局部署、架构图讲分层与标准、功能图讲数据流向与边界、流程图讲核心业务走向、逻辑图讲抽象数学逻辑；
• 逻辑图最难画，因为它需要先把逻辑真正读透（如 ThreadLocal 的开放寻址 + 斐波那契散列），才有表达的基础；
• 工具上，PPT、Visio、XMind 都能满足需求，AI + draw.io 等新方式可以大幅提升出图效率，但图背后的技术理解无法替代。

最后借用原文档的一句忠告：PPT 图稿的主要目的是把复杂逻辑讲清楚、降低沟通成本，但如果有人拿 PPT 跟你画大饼，记得不要吃。很多程序员别说画 PPT，连把自己写的代码讲到所有人都听懂都不容易。为了走得更远，一定要突破这种逻辑思维的表述能力——多学、多看、多做。

• 文档
• 教程
• 后端