Whiteboard：为AI时代软件设计而生的开源IDE

当"理解"成为软件开发的新瓶颈

随着Claude Code、Codex等智能编码代理成为行业标准，一个矛盾正在浮现：开发者获得了前所未有的编码速度，却越来越难以理解自己代码库的实际结构。一批未经充分理解就被合并的PR，正在积累一种被称为"认知负债"（cognitive debt）的隐性成本。

Whiteboard正是针对这一痛点而生。这是一款获得YC W26投资、以MIT协议开源的桌面应用，由Sid、Alex、Ketan和Milan四位前技术负责人打造。他们在为上一个创业项目迭代MVP的过程中亲身体会到：当越来越多的代码变更在缺乏理解的情况下被合并，团队甚至逐渐失去了向自己系统贡献代码的能力。

项目核心理念来自Geoffrey Litt提出的观点——在AI辅助开发时代，"理解"（understanding）已经取代编写本身，成为软件开发真正的瓶颈。

Geoffrey Litt是麻省理工学院CSAIL的研究员，长期关注"可塑性软件"（malleable software）与终端用户编程。他提出的这一观点背后有更深层的技术逻辑：当AI代码生成的速度远超人类阅读与审查的速度时，代码库的增长率与开发者的认知容量之间会出现结构性错位。"认知负债"与技术负债（technical debt）类似，但后者描述的是代码质量层面的妥协，前者描述的是团队对系统理解深度的下降——即便代码本身通过了测试和审查，团队也可能逐渐丧失在系统中进行有意图修改的能力。这种现象在使用Claude Code、Devin等自主代理的团队中尤为突出，代理产生的代码往往缺乏人类熟悉的惯用模式，增加了后续维护的认知门槛。

让人与AI代理在同一画布上共同设计

Whiteboard试图重现一种正在消失的体验：与另一位开发者进行"白板会议"，结束时双方都对系统有了深刻理解。它插入到你已经在用的工具链中，并为AI代理提供一套SDK，让代理能够在应用内的画布上"作画"来描述自己的工作。

团队最初基于HTML artifacts构建了MVP，但很快遇到瓶颈——纯HTML工具难以将规格说明或图表与实际代码建立连接。于是他们做出了几个关键的架构决策，将产品重新构建在更坚实的基础之上。

三个核心能力

基于CodeOSS的代码-图表联动

Whiteboard构建在CodeOSS（VSCode开源内核）之上。当你点击时序图、实体关系图，或者代理执行轨迹中的某段引用时，可以直接跳转到底层对应的代码。在代码导航时，你能开箱即用地获得VSCode的快捷键绑定和LSP支持。

团队指出，这一设计特别有价值，因为很多设计上的权衡往往要到第一版实现完成后才会暴露出来——这也是应对AI生成"slop"（低质量堆砌代码）的一种实用手段。

CodeOSS是微软Visual Studio Code的开源内核，去除了微软专有插件市场和遥测组件后发布于GitHub。VSCode本身正是构建在CodeOSS之上，因此Whiteboard用户能直接继承VSCode生态中积累多年的快捷键系统和扩展兼容性。LSP（Language Server Protocol）是微软于2016年提出的标准化协议，将语言分析能力（代码补全、跳转定义、引用查找、错误提示）从编辑器中剥离为独立进程，编辑器只需实现客户端即可对接任何语言的服务端。正是由于LSP的存在，Whiteboard无需重新实现语言智能，就能让用户在图表与代码之间跳转时享受到与主流IDE同等的代码导航体验。

语义化的AST感知Diff查看器

Whiteboard用Rust编写了一个语义级、AST感知的diff查看器，让你只查看真正与自己相关的代码变更。它内置了一些合理的默认策略：大型新增函数会被概括为伪代码，单元测试和大段文档变更会被折叠或隐藏。整套逻辑通过基于WASM的插件系统完全可定制。这个diff库（diffr）也已单独开源。

传统的文本级diff工具（如git diff）以行为单位对比两个文件版本，这意味着代码格式化调整、注释改动或参数换行都会产生大量噪音变更，掩盖真正的语义差异。AST（Abstract Syntax Tree，抽象语法树）感知的diff工具则先将代码解析为语法树，再在树结构层面进行比对，能够识别出"函数被重命名"或"参数顺序调整"等语义操作，而不仅仅是字符串变化。在AI代理动辄生成数百行代码的场景下，这一能力尤为关键：开发者无需逐行阅读自动生成的样板代码和测试文件，而是直接聚焦于影响业务逻辑的核心变更。Whiteboard选择用Rust实现此库并通过WASM暴露插件接口，使其能嵌入浏览器或跨平台桌面环境而无需原生依赖。

决策日志（Decision Log）

面对AI代理自主做出的一连串决策，开发者往往难以还原其推理链条。Whiteboard为代理提供了查询并将自身执行轨迹链接到画布的工具，从而让你能够看清：你设定的需求是如何被实现的，以及代理在自主运行过程中究竟做了哪些决策。

真实使用场景

据官方介绍，Salesforce、Modal等公司的工程师已经在将Whiteboard作为架构评审或规格级变更的审查工具——本质上是任何他们希望深度介入的变更。

两个典型工作流值得关注：

审查自己AI代理的产出：由于Whiteboard让大规模代码审查变得更轻松，开发者通常会让AI代理先生成原型，同时创建一个对应的Whiteboard会话，然后在此基础上迭代设计。

审查他人的变更并分层处理：Whiteboard可以与Greptile这类工具组合使用。例如，对小型变更运行自动化代码审查器，而将需要人类判断的变更升级到Whiteboard会话中。这种"自动化处理简单变更、人类聚焦复杂变更"的分层思路，正是AI辅助开发规模化后的现实需求。

开源策略与商业化路径

Whiteboard桌面应用以MIT协议开源，目前支持macOS和Linux平台。团队的商业化计划清晰：未来会向企业收费提供托管版Web服务，包含会话创建管理、轨迹存储、多人协作评审等功能，但承诺产品将始终保持可自托管。

这次Show HN发布获得了255个点赞和95条评论的热度，反映出社区对"AI时代如何维持代码可理解性"这一议题的高度关注。当编码速度不再是瓶颈，理解与设计的工具化，或许正是下一波开发者工具的竞争焦点。