AI Agent 写完代码却没人看懂？Whiteboard 把架构审查搬到一块可追溯画布上
AI 编程工具提高了提交速度，却也带来一个新问题：代码合并了，团队却说不清 Agent 为什么这样设计。只看 diff，容易陷入函数级细节；只看聊天记录，又很难把需求、架构和最终实现串起来。Whiteboard 的思路是把 Agent 的工作过程放进一个本地桌面工作区，让人和 Agent 在同一块画布上讨论设计、查看代码，并追踪决策。
它不是普通的流程图工具
Whiteboard 是一个开源桌面 IDE，定位是“人和 Agent 一起做软件架构”。项目 README 明确提到它可以连接 Claude Code、Codex 等编码 Agent，并让 Agent 通过 SDK 在应用内画布上描述工作。它目前面向本地 checkout，采用 MIT 许可证；官方文档还强调，未来的团队托管产品不会取消自托管能力。
它的关键不是画图本身，而是把图和代码关联起来。序列图、实体关系图、Agent trace 中的引用，都可以跳转到对应代码；浏览代码时仍然保留 VS Code 生态中的快捷键和 LSP 能力。这样，架构图不再是评审前临时制作的装饰，而是可以回到实现细节的导航入口。
三个值得关注的工作面
1. 从架构意图跳到实现
在一次 API 变更中，可以先让 Agent 说明拟议 API、使用示例和设计动机，再进入实现。Whiteboard 的推荐提示词就是从这类问题开始，而不是直接要求“把功能写出来”。对于大型改动，这种顺序能让人先审查边界，再审查代码。
2. 语义化 diff 降低噪声
项目包含一个用 Rust 编写的 AST 感知 diff 查看器。它可以把新增的大函数概括成伪代码，并折叠或隐藏测试、文档等不一定需要逐行阅读的变化；这些默认行为还可以通过 WASM 插件系统调整。它并不是替代 Git diff，而是把审查注意力集中到真正改变行为的部分。
3. 把 Agent 决策留下来
Whiteboard 还提供决策日志方向：Agent 可以查询并关联自己的 trace，让人看到需求如何被实现，以及哪些选择是 Agent 自主做出的。对于“代码能跑但没人敢维护”的项目，这类记录比一段最终总结更有价值，因为它保留了取舍发生的上下文。
一个可落地的审查流程
可以把它接入一次较大的 Agent 开发任务：
- 在本地打开项目，并连接 Claude Code、Codex 或其他编码 Agent。
- 先让 Agent 对当前分支相对主分支的变化做架构级说明，要求输出 API、依赖关系和风险点。
- 在 Whiteboard 中查看图、trace 引用和语义 diff；发现问题时，用剪贴板标记具体区域，再让 Agent 重画或解释。
- 回到代码确认实现，最后把决策记录和评审结论一起留在本地工作区。
这个流程的重点是“先建立可检查的解释，再接受实现”。它适合 API 变更、跨模块重构和需要多人理解的 Agent 生成代码，不适合把每一次小修复都包装成完整架构评审。
当前限制也很重要
Whiteboard 目前不能直接编辑文件，跨多个仓库的浏览支持也还不完善；共享评审后，后续更新不会自动同步给其他人，需要重新分享。它因此更像一个架构与审查工作台，而不是新的代码编辑器或协作平台。隐私方面，项目说明本地运行，匿名遥测不包含代码、diff、文本、提示词或模型输出，并允许用户关闭遥测；使用远程模型时，仍应单独考虑模型提供商的数据处理边界。
如果你的团队已经开始用 Agent 批量生成代码，真正稀缺的可能不是又一个自动补全按钮，而是理解系统变化的时间。Whiteboard 用图、语义 diff 和决策日志把这段理解过程显式化，值得作为本地 Agent 工作流中的一个审查层来试用。