FigJam 白板协作、评审证据与归档治理手册
白板上已经达成一致，为什么两周后没人说得清
一次订单拆分评审里，十几个人在 FigJam 上画出了服务边界、失败补偿和迁移顺序。会后白板链接发进群，大家都认为结论已经沉淀。开发真正开始时，却发现三种颜色的便签没有图例，连接线交叉后无法判断方向，投票最高的方案后来又被口头否决，行动项没有 owner，外部顾问仍通过公开链接保留编辑权。白板记录了协作过程，却没有形成可执行、可审计的工程事实。
FigJam 适合快速发散、可视化关系和多人同步编辑；它不是工单系统，也不是架构决策记录的最终事实源。务实的用法是让白板承载“探索与评审现场”，再把结论、责任和版本证据回写到 Issue、任务单或 ADR。这样既保留空间思考的优势，也不会把一张无限画布变成无法治理的项目数据库。
从浏览器创建第一块受控白板
FigJam 可以从 Figma 文件浏览器创建，也可以直接访问 https://figjam.new/ 或 https://www.figma.com/jam。文件创建和基础对象能力要以目标团队的 plan 与权限为准；开放会话只在支持它的付费团队空间提供，自定义模板和组织级公开分享控制还需要相应管理员能力。启用前先在目标团队管理页确认，不要把某个套餐页面的能力当成所有文件都稳定具备。FigJam 入门指南列出了文件创建入口、Page、Section、便签、图形与连接线的基本行为。
新建文件后不要直接把链接发给所有人。先将文件命名为 PAY-142 Order Split Review，移动到团队约定的 Architecture Reviews project，再建立以下 Page：
00-Readme
01-Context
02-Options
03-Decision
99-Archive00-Readme 不是装饰页，它要写清白板 owner、关联工单、信息分级、参与规则、颜色图例和归档位置。01-Context 保存问题与约束，02-Options 保存可比较方案，03-Decision 只保存已确认结论和行动项，废弃探索移动到 99-Archive，不要直接删除导致评审上下文断裂。
浏览器和 Figma 桌面应用都能操作 FigJam。首次验证可以在 01-Context 建一个 Section，放入一张便签、一种 Shape 和一条带箭头的 Connector；再分别用一个已受邀的成员账号和一个临时 visitor 测试。两端应看到相同对象位置、文字与连接关系；visitor 只能在开放会话期间编辑，不能用它验证长期权限。若画布空白或拖动严重卡顿，先检查浏览器 WebGL、扩展、代理与设备图形能力；若只有协作者看不到，优先检查文件、project 和 team 的继承权限。
实验结束时移除测试成员，把测试 Section 移到 99-Archive 或删除整份实验文件。结束开放会话只会撤销 visitor 的临时编辑能力；有 view 权限的人仍可能查看和复制文件，公开链接也不会因为会话结束自动关闭。因此要分别关闭 open session、收紧 public link，并用无痕窗口验证 visitor 不能再编辑，不能笼统地把“访问被拒绝”当成唯一预期。
对象不是贴纸，关系也不是装饰线
FigJam 的主要对象包括 Text、Sticky、Shape、Image、Table、Section、Connector，以及投票、计时器、评论、组件、插件和 Widget 等协作工具。FigJam 文件界面说明给出了这些对象和工具的当前入口。工程白板不需要把每种对象都用一遍，而要为对象建立稳定语义：
Sticky 保存短事实、疑问或候选项，每张只表达一个判断。Shape 表示稳定实体或状态，例如服务、队列、用户动作。Connector 表示调用、数据、控制或依赖关系，必须有方向和必要标签。
Section 表示可独立阅读、评审或导出的工作单元。Table 适合承载可导出的行动项，不适合伪装成完整工单系统。Comment 保存针对对象的讨论，确认结论后应回写到正式记录。
一个可读的最小流程可以这样约定：矩形表示系统，圆角矩形表示外部参与方，菱形只表示决策，红色边框表示失败路径，实线表示同步调用，虚线表示异步事件。颜色不能单独承载语义，还要有文字和图例，否则色觉差异、打印或导出灰度都会让信息丢失。
连接线必须真正吸附到对象，而不是视觉上贴近对象。正向验证很简单：拖动上游 Shape，连接线端点应跟随移动；如果线留在原地，它只是自由线段。再删除下游对象，观察是否留下悬空关系。白板交付前可以逐个移动关键节点，这比肉眼看连线是否“差不多贴上”更可靠。
用 Section 把无限画布变成可评审单元
无限画布最危险的地方，是所有人都能添加内容，却没人知道哪里已经稳定。Section 可以容纳并一起移动对象，也可以从一组已选对象创建。每个 Section 应包含标题、状态、owner、输入与输出链接，例如：
section:
id: option-b-outbox
title: 方案 B - Transactional Outbox
status: reviewed
owner: platform-team
source_ticket: PAY-142
decision_record: ADR-027
evidence:
- failure-path-labeled
- data-owner-confirmed
- rollback-reviewed状态可以采用 Draft -> In Review -> Accepted -> Archived，但它必须是团队约定，不是 FigJam 内建工作流。改变状态时同时更新工单或 ADR，避免白板和正式系统各维护一套状态。Section 名称最好带稳定 ID，不要用“最终版”“最新讨论”这类会迅速失真的词。
模板能加快结构建立。Figma 提供的模板可从文件浏览器、模板选择器或 Section 中插入；Community 模板通常通过复制进入自己的 Drafts。模板使用指南说明了这些入口。引入模板后必须检查第三方链接、示例数据、插件或 Widget、颜色语义和分享设置，不能把 Community 来源直接当成企业标准。
Organization 与 Enterprise 场景可以发布自定义 FigJam 模板，发布者需要相应文件编辑权，具体能力见 自定义模板说明。模板应有 owner 和版本字段，重大变化先复制到 Sandbox 做一次完整评审，再替换团队入口。否则模板一更新，历史白板与新白板表达同一颜色却含义不同。
组织一次不会丢结论的评审
评审开始前，主持人只开放 01-Context 与 02-Options 的编辑区域，将已确认背景锁定或放到只读引用中。参与者先静默补充事实，再讨论分歧，最后用投票辅助排序。投票结果只是输入，不能自动等于决策：安全、合规、容量或成本否决项可能推翻最高票方案。
评审结束时必须在 03-Decision 创建三个对象：决策句、拒绝方案及原因、行动项表。行动项至少包含 ID、动作、owner、截止语义、验收证据和外部工单链接。例如：
id,action,owner,due,evidence,work_item,status
ACT-01,"验证重复消息补偿",backend-owner,T+3,"测试报告链接",PAY-143,Open
ACT-02,"复核客户数据边界",security-owner,T+2,"审批记录链接",SEC-028,Open
ACT-03,"补充回滚路径",platform-owner,T+4,"演练记录链接",OPS-061,OpenT+N 表示相对评审结束的约定时间，真正进入工单后应由工单系统保存实际日期。白板里不应复制真实客户数据、访问令牌或生产日志；证据链接也应指向受控存储，而不是开放对象存储 URL。
当结论已进入 ADR 或 Issue 后，在白板决策区放回链：ADR-027 指向正式决策，工单再反向保存 FigJam Section 链接和归档版本。这样删除或迁移任一平台时，另一端仍能说明对象身份和历史来源。
正向实验：从白板结论闭环到工单
创建一个 Retry Strategy Review Section，放入两个候选方案，每个方案都有成功路径、失败路径、代价和回滚条件。邀请一个测试协作者评论，再由主持人完成以下动作：
把选中方案移动到 03-Decision，状态改为 Accepted。为未选方案保留“Rejected because”说明，而不是删除。从行动项表创建虚构工单 PAY-143，工单保存 Section 深链接。
在 Section 中回填工单与 ADR-027 链接。创建命名版本 PAY-142 decision accepted。导出决策 Section 为 PDF，并记录文件哈希。
哈希用于证明归档文件是否被替换，不证明内容正确：
sha256sum PAY-142-order-split-decision.pdf \
> PAY-142-order-split-decision.pdf.sha256
sha256sum --check PAY-142-order-split-decision.pdf.sha256预期输出包含 OK。Windows 环境也可使用系统提供的文件哈希工具，但团队仓库应统一算法与清单格式。随后用只有查看权限的测试账号分别打开白板链接和工单链接：应能定位同一个 Section、同一个 ADR 与行动项 ID；不应获得不必要的编辑权。
若深链接只打开文件首页，重新选中 Section 后复制链接；若 PDF 缺少连接线或对象被截断，检查导出选择是否完整覆盖 Section、对象是否真正位于 Section 内；若哈希校验失败，先确认文件是否被重新导出，再更新归档版本，禁止只改 .sha256 文件掩盖变化。
清理时撤销测试协作者、关闭临时公开分享、删除测试导出或移动到规定归档位置，并把实验工单标记为 Test/Cancelled。用无痕窗口确认编辑入口消失。
反向实验：让连接关系和行动项故意失真
复制刚才的 Section，故意做三处破坏：把一条 Connector 改成未吸附的自由线；删除行动项 owner；修改白板决策却不更新工单与 ADR。然后把 Section 整体向右拖动。
自由线不会跟随目标对象，形成第一条故障证据；行动项表出现空 owner，说明工作不可执行；白板、工单和 ADR 的结论文本或版本指纹不一致，说明事实源漂移。排查顺序是先验证对象关系，再验证责任字段，最后比较跨系统版本。不要先花时间调整颜色和排版。
修复时重新吸附 Connector 并重复拖动验证，为行动项补齐唯一 owner，把正式决策更新到 ADR，再让白板只保存摘要与链接。重新创建命名版本和导出哈希。旧 PDF 保留为 superseded 证据或按保留策略删除，不能覆盖后继续沿用旧哈希。
访客、Guest 与开放会话不是一回事
Figma 权限可以在 team、project 和 file 层继承，也可以显式授予。can view 与 can edit 决定具体文件行为，seat 决定可使用的产品能力。分享与权限指南强调 seat 与 permission 分离；遇到“有 Collab seat 但打不开文件”时，要查文件授权，遇到“能看但不能编辑”时，要查 permission 和上层继承。
外部邮箱加入组织资源后可能成为 guest，只能访问被明确授权或通过链接可访问的资源。Enterprise 管理员可以限制、审批或禁止 guest，但 public link 仍需单独治理，详见 访客限制说明。最小权限做法是：内部成员从 project 继承，外部人员只获单文件权限，评审结束即撤销；敏感白板禁用 public link、复制和导出。
开放会话适合临时工作坊。官方当前列出的支持团队包括 Professional、Education、Organization 和 Enterprise；拥有 FigJam 文件 can edit 的人可以启动一次 24 小时开放会话，过期或主动结束后可以重新启动下一次。未登录 visitor 通过链接即可在会话期间编辑，不占团队 seat 账单，也不等于长期 guest 授权。visitor 不能查看版本历史、改变分享设置、安装插件或结束会话；未登录 visitor 不应被假定拥有稳定的评论和音频能力，使用这些能力应登录或创建账号并在目标团队实测。开放会话指南说明了 visitor 的临时能力和会话限制。主持人要在开始前复制脱敏白板，在结束后主动 End now，导出必要证据并删除临时文件。不要在包含路线图、客户数据或安全拓扑的主白板上直接开启公开编辑。
公开链接通常默认方便协作，却也最容易形成长期数据出口。Organization 或 Enterprise 管理员可以禁用 public link 和 open session；开放会话本身还可设置密码。Enterprise 的公开链接过期控制针对设计文件，不能据此承诺 FigJam 开放会话会按同一规则过期；FigJam 会话仍按 24 小时周期并可被主持人提前结束，见公开分享管理。配置后必须用组织外无痕会话分别验证 visitor 的编辑权限、会话结束后的查看权限和 public link 状态，后台开关截图不能代替访问测试。
导出、版本与归档怎么形成证据
FigJam 支持把全部或选中区域导出为 PNG、JPG、PDF，也可以把 Sticky 或 Table 导出为 CSV；可导入的对象还包括常见图片、PDF、CSV 和部分视频格式。官方要求导入和导出由 FigJam 文件 can edit 的成员执行；归档责任应落在具名成员或自动化身份上，不要把 visitor 的临时编辑能力当成可审计导出身份。FigJam 导入导出指南列出了当前格式和权限条件。
归档时至少保存三层内容：
FigJam 原始文件链接与命名版本，保留可交互对象和评论上下文，但前提是文件仍保留且归档人员仍有权限；链接本身不是离线备份。决策 Section 的 PDF 或 PNG，提供不依赖编辑器的可读快照。行动项 CSV 与 manifest.json，提供机器可检查的责任和来源字段。
{
"artifactId": "PAY-142-order-split-review",
"source": "figjam",
"sourceSection": "decision-order-split",
"namedVersion": "PAY-142-decision-accepted",
"decisionRecord": "ADR-027",
"workItems": ["PAY-143", "SEC-028", "OPS-061"],
"exports": [
"PAY-142-order-split-decision.pdf",
"PAY-142-order-split-actions.csv"
],
"classification": "internal",
"retention": "project-policy",
"owner": "architecture-owner"
}Figma 的版本历史会自动保存检查点，can view 成员可以浏览，can edit 成员才能创建、命名、删除版本信息或恢复版本。Starter 团队和 Drafts 的历史可见范围只有 30 天；其他团队的实际保留能力应以文件所在 plan 为准。恢复版本是非破坏操作，但后续评论不会随画布版本一起消失，因此敏感评论不能靠恢复旧版本清除。版本历史指南解释了权限、命名版本和恢复行为。重要评审结束后创建语义化命名版本，但仍要把 PDF/PNG、CSV、manifest 和哈希作为独立归档证据。
大白板性能问题先从对象结构下手
白板变慢常被笼统归因于网络。实际瓶颈可能来自单 Page 对象过多、超大图片或视频、复杂嵌入、Widget、浏览器内存、多人高频编辑和 GPU/WebGL。诊断时先复制文件，在副本中逐 Page 隔离：关闭嵌入与 Widget、移除大图、把已完成 Section 移到归档 Page，再比较缩放、拖动与首次打开时间。
性能治理以趋势为依据。记录每轮评审新增对象数、二进制素材大小、打开到可交互时间和浏览器内存告警；当归档后这些指标仍单调上升，说明需要拆文件，而不是继续把 Section 缩小。拆分时保留索引页和稳定深链接，并在旧白板注明 successor，避免产生两份都叫“主白板”的事实源。
导入高清截图和录屏前先确认是否真的需要原文件。白板用代理图预览，原始素材放受控对象存储并用权限链接引用，通常比把所有二进制塞进 FigJam 更稳定。链接也要有保留策略；原文件删除后，白板中只剩缩略图不能算可恢复归档。
敏感信息、插件与 AI 能力的边界
白板常在会议中快速粘贴日志、用户截图、邮件和浏览器标签，这些内容会进入版本历史、导出物、缩略图和协作者缓存。主持人应在会议前提供脱敏素材，禁止粘贴 token、Cookie、客户姓名、生产 URL 和未公开架构。会后执行一次四角扫描：画布可见对象、评论、隐藏或归档 Page、导出文件。
Plugin、Widget 与 AI 功能可能读取选中对象或生成新内容。团队准入时记录供应者、权限、外部网络、数据保留、owner 和撤销方式；敏感白板不运行未经批准的扩展。开放会话访问者的能力与登录成员不同，也不能假定所有 AI 或评论能力都可用。功能入口缺失时先看会话类型、seat、plan 与管理员策略，不要绕过策略复制到个人 Drafts。
从白板复制到 ADR 前必须人工复核。投票、聚类和 AI 摘要可以加速归纳，却不能证明事实准确；架构结论要由具名 owner 确认，安全和合规否决项要保留原始证据。自动摘要若省略反对意见，应以原始 Section、评论和命名版本为准。
常见失败按第一证据排查
受邀者打开后仍请求权限：检查链接是否指向同一文件、邀请邮箱是否正确、上层 project/team 是否限制访问、组织是否要求 guest 审批。不要通过开启 anyone link 临时绕过。
协作者能看不能编辑：分别核对 seat 与 file permission，再看开放会话是否已结束。开放会话结束后 visitor 不会自动获得长期访问。
导出只包含一小块或对象被截断：确认导出前选中的是 Section 或完整对象集，检查对象是否真正位于 Section 内。用导出 PDF 与画布逐角对照后再归档。
连接线移动后脱离节点：端点没有吸附到对象，或对象被替换。重新吸附并执行拖动验证，关键连接再加方向文字。
模板入口不可用：确认 plan、组织资源设置和文件编辑权限。Community 文件复制到 Drafts 后也不会自动成为组织模板。
白板与工单结论不同：比较命名版本、ADR 状态和工单更新时间，指定 ADR 或工单为最终事实源，把白板旧结论标记 superseded，而不是双向反复覆盖。
删除文件后又被恢复：检查 Trash 中的文件、原 project 是否仍存在以及谁拥有恢复权限。删除不等于立即不可恢复，敏感数据处置还要遵循组织保留与永久删除流程。
团队治理与平台退出
每个长期 FigJam 文件都需要 owner、信息分级、外部协作者清单、关联正式记录、归档周期和删除条件。模板 owner 负责语义一致性，会议主持人负责当次权限与结论，工单或 ADR owner 负责后续事实。把这些责任都压给“白板创建者”，人员变动后会立即失效。
治理抽查应寻找可操作证据：无 owner 的行动项、没有方向的 Connector、没有工单回链的 Accepted Section、长期公开链接、超过保留期的导出文件、个人 Drafts 中的团队模板、离职人员创建的关键文件。发现问题后要指定修复期限和关闭证据，而不是只发一条规范通知。
成本不仅来自 seat，还来自协作摩擦、二进制存储、归档系统和迁移工作。开放会话 visitor 不计入团队 billing，但会话结束后若把参与者转为受邀成员，账单会按分配的 seat 类型变化；对偶发参与者使用 View、Guest 或受控开放会话前，先核对能力与安全要求。不要为了节省 seat 把敏感文件公开，也不要为每个旁听者购买超出实际需要的权限。
退出 FigJam 时，先冻结新编辑，创建最终命名版本，导出 PDF/PNG、行动项 CSV 和 manifest，迁移 ADR 与工单回链，再撤销 guest、public link、Plugin、Widget 和自动化凭证。随后在替代平台重建一块代表性 Section，验证连接方向、文字、图片、行动项和来源哈希均可读取。仅下载一张全画布 PNG 会丢失评论、对象关系、深链接和责任字段，不能算完成迁移。
白板完成的判断标准
一场 FigJam 协作结束时，参与者应能从稳定 Section 看懂上下文、方案、失败路径和结论；每个行动项有唯一 owner、外部工单和验收证据；ADR 或工单保存最终事实并反向链接白板；导出文件和哈希能够证明归档快照未被替换，命名版本和文件链接只在权限与保留策略仍满足时提供上下文；外部权限和临时会话已经回收。
当连接线、投票、便签和评论都能落到这条证据链上，FigJam 才真正提高工程效率。否则它只是把会议室里会消失的白板，换成了一张更难清理的在线白板。