Whiteboard：让 AI Agent 和人类在同一块设计画布上协作
AI 编程工具已经能写出大量代码，但“代码能不能被人理解”仍然是另一个问题。纯文本 diff 往往把注意力拉到行级变化，架构取舍、接口关系和 Agent 做过的决定反而容易被淹没。Whiteboard 的思路是提供一个本地运行的桌面画布，让人和编码 Agent 在同一个软件设计工作区里讨论、画图并回到代码。
它解决的不是画图，而是设计与实现之间的断层
Whiteboard 是一个 MIT 许可的开源桌面应用，官方 README 将它定位为“人类与 Agent 共同架构软件”的画布。它可以连接 Claude Code、Codex 等编码 Agent，让 Agent 把工作结果绘制到应用内画布上。
这个定位和普通白板工具不同：画布不是项目结束后的展示物，而是审查过程的一部分。README 展示的典型流程是，让 Agent 针对当前分支与最新 main 做审查，并把结果打开到 Whiteboard 中。人类可以查看序列图、实体关系图或 Agent trace 中的引用，再跳回对应代码。
它还提供语义 diff 视图。项目说明该视图使用 Rust 实现、面向 AST 感知的代码变化；较大的新增函数可以摘要为伪代码，测试和文档变化也可以折叠或隐藏。这样做的价值不在于让 diff 变得“更漂亮”，而在于先突出会影响设计的变化，再按需深入实现细节。
五分钟上手路径
官方给出的 Quickstart 很直接：先从 dev.fast/install 下载并打开 Whiteboard，也可以在 macOS 上使用 Homebrew：
brew install --cask devdotfast/tap/whiteboard
然后在欢迎界面连接 Claude Code、Codex 或其他编码 Agent。接着可以从一个具体的审查请求开始，例如：
Review my current branch against up-to-date main. Use Whiteboard to show the important design changes, sequence diagrams, and decisions that need human review.
这里有一个重要的使用边界：Whiteboard 当前并不是编辑器替代品。项目的已知限制明确写着，用户暂时不能直接在 Whiteboard 中编辑文件；它更适合阅读、讨论和审查。真正的修改仍应回到 Agent、编辑器或终端中完成。
为什么它适合 Agent 工作流
第一，设计对象和代码对象可以互相跳转。团队讨论 API 变化时，不必在架构图和仓库之间手工寻找对应关系。
第二，决策不会只存在于聊天记录里。Whiteboard README 提到，工具允许 Agent 查询并链接自己的 trace，用来展示需求、实现方式以及 Agent 自主做出的决定。对于需要复盘的重构任务，这比“模型说它已经考虑过了”更可审查。
第三，它强调本地运行。项目说明 Whiteboard 面向本地 checkout；匿名遥测不包含代码、diff、画布文字、提示词或模型输出，并且用户可以关闭遥测。对于涉及内部仓库的设计评审，这是比直接上传整个项目更容易接受的默认姿势。
实际使用时的三个建议
先从单一问题开始。 不要一上来要求 Agent 绘制整个系统。可以先限定为“解释这次 API 变更”或“说明这个 PR 的数据流”，让画布服务于一个明确决策。
把人类评审点写进提示词。 例如要求列出兼容性风险、错误处理和迁移成本。Whiteboard 能展示结果，但评审标准仍需要人类给出。
注意当前限制。 多仓库工作支持还不完善，分享后的评审更新也不会自动同步给其他机器。它更适合作为单仓库、单次设计审查的本地工作台，而不是已经完成的团队协同 SaaS。
Whiteboard 值得关注的地方，不是又增加了一个 Agent 面板，而是把“理解代码变化”提升成一等工作流。随着 Agent 生成的代码越来越多，能否快速看懂它为什么这样改，可能比能否再快几秒写完代码更重要。