让人和 AI 在同一块画布上做设计：Whiteboard 把「理解」当成瓶颈来解

先画清楚，再让 AI 动手

在 Hacker News 上露面的 Whiteboard 是一个开源桌面应用，主张一句话：让人类和智能体在同一块工作区里一起设计软件。它接的是你已经在用的编码智能体（如 Claude Code、Codex 等），然后给智能体一套 SDK，让它在应用内的画布上把要做的事画出来——时序图、实体关系图、流程结构都行。MIT 许可，跑在本地的代码检出上。

它想解决的是「看不懂智能体干了什么」

项目自己的解释是：纯 HTML 工具没法把设计图和代码连起来，而真正的问题在于权衡往往是在第一版实现之后才暴露的。所以它做了两件具体的事。一是反向跳转：点画布上的时序图、ER 图或某段智能体执行记录，能直接跳到对应的代码，代码浏览沿用 VS Code 的键位和语言服务。二是一套用 Rust 写的语义化 diff 查看器——不是逐行比对，而是理解语法树的比对：只显示与本次审阅相关的改动，新增大函数被摘要成伪代码，单元测试和文档改动直接折叠隐藏，规则可以用基于 WASM 的插件改写。

决策日志：把智能体的自主判断留在台面上

他们发现最难受的一点是：很难判断智能体自主做了哪些决定，以及这些决定如何影响了一次改动。于是做了决策日志——让智能体查询并链接自己的执行记录到画布上，你能看到自己当初提的要求、它怎么实现、中间哪些决定是它自己下的。对一个已经开始把日常改动交给智能体的团队来说，这比再多的代码生成能力都实用。

一个值得学的工程手法：站在最成熟的开源基座上

Whiteboard 的编辑器直接内嵌（vendor）了 VS Code 的 Code OSS。它的理由是：既然大家只把编辑器用来逐行看 diff，那就做一个专门给审阅用的编辑器，起点当然选最成功的那个。而且它不学其他分支靠维护补丁集，而是直接吸收上游代码、定期合并安全与功能更新——因为编码智能体处理补丁很吃力，而上游里有大约 45% 的代码是团队根本不需要的组件。它还老实列出了已知限制：不能直接编辑文件、跨多个仓库的联合审阅支持不好、共享出去的评审不会同步后续更新。项目推荐用 GPT-6 Luna 或 Claude Opus 5.5 这类模型，理由是智力、成本与速度的组合。

对做企业数字化、小团队的实际启发

第一，AI 写代码之后，瓶颈从「产出」转到了「理解」：代码变多不等于进展，能不能讲清楚为什么这么改才是。小团队可以照搬这条流程——重要改动先让智能体把结构画出来，人确认方向，再让它写实现、附一份决策说明。第二，代码评审别再看裸 diff，按「这次到底动了什么」过滤是能自己实现的，哪怕先用规则做一层折叠也能省下大量注意力。第三，让智能体交出自己的决策记录，而不是只交结果，这是把 AI 产出纳入正常工程管理最便宜的一步。第四，做内部工具时优先复用最成熟的开源项目做基座，把资源留给自己业务真正独特的那部分——这也是我们给客户做系统时反复验证过的取舍。