一张白板，为什么正在吃掉PRD：FigJam让“想法”第一次跑在代码前面

很多人以为流程图只是产品经理的“形式主义”，但这段 FigJam 视频展示了一个反直觉的事实：真正决定产品质量的，不是代码，而是代码之前那张所有人都能参与的白板。它正在悄悄改变工程、设计和 AI 团队的协作方式。

最反直觉的一点：流程图不是给“讲清楚”的，而是用来“吵架”的

视频一上来，没有任何教学废话，而是直接丢进一个真实场景：一个外卖 App 团队，正在讨论“再次下单（reorder）”功能的用户体验。注意一个细节——他们不是先写 PRD，也不是先开需求评审，而是直接在 FigJam 里画流程图。

很多人误以为流程图的价值在于“对外展示”，但这段视频恰恰相反：流程图是用来暴露分歧的。比如：用户是否下过单？没有下过怎么办？下过但餐厅关门了怎么办？这些问题，如果不画出来，99% 会在代码阶段才爆雷。

FigJam 的妙处在于，它把“逻辑争论”前移到了最便宜的阶段。一颗菱形（decision），往往能省掉后面几百行 if-else。这对 AI 产品和复杂系统尤其致命重要，因为你永远不可能靠模型去“猜”一个没被定义清楚的业务逻辑。

工程师、设计师同时在线：为什么这对 AI 团队是个信号

视频里有个很容易被忽略的瞬间：工程师直接在 FigJam 里丢了一段代码块，用来说明“是否有历史订单”的判断逻辑。没有切工具，没有开 Jira，也没有“我稍后发你”。

这其实是一个强烈的行业信号：边界正在消失。流程图里出现代码，白板里出现数据结构（用 cylinder 表示数据库），甚至还有 loading skeleton 的备注。这不是“画得更好看”，而是把系统思维前置。

对 AI 从业者来说，这一点尤其重要。无论是推荐系统、对话流程，还是 agent 的多步决策，本质都是状态机和决策树。FigJam 这种低摩擦的协作工具，让非工程角色也能参与系统设计，从而减少“模型很聪明，但产品很蠢”的经典悲剧。

一个被低估的能力：用“循环”和“容器”思考复杂性

视频后半段进入真正有料的地方：他们用一个“容器”标出循环逻辑——检查历史订单是否仍然可用（餐厅是否营业、菜品是否下架、是否是时间限定）。这是很多团队在文档里极少明确标注的复杂性来源。

但恰恰是这些循环，决定了系统的稳定性和用户体验。FigJam 允许你用视觉方式把“这里会反复执行”标出来，这对 AI 系统设计是降维打击。因为一旦循环被明确，你就会自然开始问：有没有边界条件？有没有性能问题？有没有失败兜底？

最后一个细节很“产品老手”：历史订单只显示 8 条，其余进 overflow。这个决定不是拍脑袋，而是直接体现在流程图里的分支逻辑。工具没有替你做决策，但它逼你把决策说清楚。

总结

这段 FigJam 视频真正厉害的地方，不在于教你“怎么画图”，而是在暗示一种工作方式的迁移：从文档驱动，转向可视化思考驱动。对 AI 从业者来说，这是一个值得警惕又值得拥抱的趋势——未来的竞争，不只是模型和算力，而是谁能更早把复杂系统想清楚。

一个可执行的行动建议：下次你在设计一个 AI 功能（无论是 agent 流程还是推荐逻辑），先别急着写 prompt 或架构图，试着用 FigJam 画一张“如果……会发生什么”的决策流。你会比任何代码评审更早发现问题。

关键词： FigJam， 流程图， AI产品设计， 团队协作， 系统思维

事实核查备注： 需要核查的视频事实包括：视频标题、发布时间（2022-04-14）、发布频道 Figma Config；视频中是否真实出现代码块、循环容器、8 条历史订单上限等细节。