2026 年 9 月 24 日，Show HN 刊出 devdotfast/whiteboard，標題寫著「An open-source IDE for thoughtful software design」。24 小時內 357 分、125 則留言。這個 repo 2026 年 8 月 18 日才建立，我查資料當天（9 月 25 日）是 1,078 星、439 次 commit、4 位核心作者，背後是 YC W26 團隊。這篇整理它在做什麼，以及 Hacker News 網友買不買帳。
它在做什麼
一句話：你的 coding agent 從終端機透過本機 MCP server，在桌面 app 的畫布上畫序列圖、ERD，把執行過程的 trace 掛上去，每個節點都能點回對應的程式碼。
底層是把整份 Code-OSS vendor 進來，不是維護 patch 的 fork。官方給的理由很實際：coding agent 處理 patch 很痛苦，而且上游 VS Code 有 45% 是他們根本用不到的 Copilot 程式碼。代價是體積，收益是程式碼導航、鍵位、LSP 全部照 VS Code 的習慣來。
三個核心功能：
- Semantic diff viewer：用 Rust 寫的 AST-aware diff，大段新增函式自動摘要成 pseudocode，測試與文件變更預設折疊，WASM plugin 系統可客製。這是討論串裡被點名最多的亮點。
- 圖與程式碼雙向跳轉：點序列圖的節點跳到程式碼，反向也通。官方主張這是 Markdown + Mermaid 給不了的，因為 Mermaid 沒有 go-to-definition。
- Decision log：agent 可以把自己的 trace 查詢出來掛回畫布，呈現「你下的需求怎麼實作、agent 自主做了哪些決定」。
平台支援到 2026 年 9 月 25 日為止：macOS 只有 arm64 的 dmg，Linux 只有 Fedora 的 rpm，Windows 寫在 roadmap。安裝後 736 MB。
「IDE」這個詞，當天就改了
討論串最大的共識是這個詞用錯了。README 的已知限制第一條就寫「目前不能編輯檔案」，留言區為此冒出好幾條：有人玩文字遊戲，寫「這次的 IDE 是 I Don’t Edit」，有人直接問「不能編輯還叫 IDE？」。
作者 sidkmenon 的回覆是「IDE is a misnomer，我們會改」，理由是選這個詞因為最接近的對照物是 VS Code，而很多人現在只拿 VS Code 看程式碼、審 diff。他當天就把官網與 GitHub 從 IDE 改成了 canvas。產品上線第一天就換定位詞，這件事本身比任何評測都誠實。
HN 認同什麼
Semantic diff 被反覆點名。 有人說 pseudocode 摘要是這場討論裡最像「明年會滿街都是」的技巧，也有人認為多數 coding harness 的 diff 體驗都做得不好，這塊是真缺口。
演示動畫拿高分。 留言形容手繪線條配合串流圖逐步生成的手法「12 個月後會到處都是，這是第一次看到」，並認為動畫一眼就交代清楚產品在做什麼，比多數 launch 的截圖有效。
痛點描述具體。 一位工程師寫，跟 agent 工作一陣子後他「再也想不起 code 的形狀」，資訊量大到記不住，連回覆同事 async 問題都答不上來。另一位提到公司限制 AI 工具，但 Whiteboard 本機運作、無強制資料蒐集，「不用說服公司就能過審」。
品類沒有名字。 留言區給了四種叫法：Code Navigator、orchestrator 或 ADE（Agentic Development Environment）、control plane、agent multiplexer。作者反駁 ADE 這個方向，說 ADE 解決的是 context 切換；Whiteboard 做的正相反，要幫你在人是高價值的環節看懂東西。
HN 質疑什麼
第一個是 N+1 source of truth，也是最難解的。 留言指出這類工具會變成團隊裡多出來的一份真相，必然隨著專案推進過期；叫 agent 去更新，圖與設計文件又會劣化成看不懂的 slop。作者群的回答分成兩層：圖都錨定在程式碼上，所以能偵測 drift；hosted 版本的目標是自動維護整個 software map。團隊成員 ketan 更直接承認圖是 ephemeral，長久的價值其實是兩件事：ship 出來的 code 更好，我自己的心智模型也跟上了。
第二個是 736 MB。 有人只留了一句「736mb on macOS /facepalm」。作者認帳，給出對照數字：vanilla Cursor 或 VS Code 約 1 GB、Zed 約 400 MB，承諾未來用原生重寫把體積壓下去，眼下連 138 MB 的 diff viewer 都還在最佳化。
第三個是 Markdown + Mermaid 到底夠不夠。 有人質疑 C4 圖的文字化傳統本來就是為了讓 LLM 維護，為什麼要重造；也有人問為什麼不建構在 likec4 這類開源方案上。官方的回答只有一條：差別在 spec 與程式碼的錨定、以及導航體驗。這條辯論沒有結論。
其他質疑：scope 太窄，有人說與其看別人的不如自己在 harness 裡重建，有人說這比較像一個 MCP 加 GUI 的 feature 而不是產品；平台缺口，Windows 的聲浪最大，有人說他認識的工程師九成在 Windows 上，Linux 則只有 Fedora；競品密集，同一場討論裡至少五個人說自己也在做類似的事，包含 whiteboard-mcp.com、mtford 的 revue，還有幾個自己寫的 skill。
最值得記的一條是官方 GIF 被抓包。 有留言逐行比對 demo 畫面與 diff，發現序列圖上一條標著「wait for release」的箭頭在 diff 裡根本不存在。作者承認那是設計階段用的示意圖，忘了換，當天就改成真實 session 的截圖。宣傳素材裡那張圖，也可能不是產品畫的，這提醒跟任何 AI 工具評測都通用。
Codex 的安全警告也是真問題。 有人貼出 Codex 提示「Whiteboard 需要把 repo 資料上傳到它的 authoring server」，與「本機執行」的宣傳對不起來。作者澄清 authoring server 就是跑在本機的 stdio MCP server，資料沒有離開機器，純粹是名詞用得不好。
討論串尾端還有兩則反對 AI 的留言，一則說 AI 該少一點、人的思考該多一點，一則抱怨讓 agent 寫、再讓 agent 解釋，等於集體放棄理解自己的程式碼。作者沒有硬辯，只丟出自家部落格文章。
商業化還沒有答案
目前是 free、開源、本機執行。團隊說正在做 hosted 的多人版本，但定價未定，甚至承認自己「還不確定」。這條路如果走成 hosted-only，會撞上留言區的另一個警告：企業使用者無法說服公司再批准一個 GitHub App，付費改走本機 gh 權限才活得下來。
我的判讀
我會追蹤它，但不會現在裝。
硬體上就先卡住了：macOS 只出 arm64，我的 2014 年 MacBook Pro 是 Intel，連安裝檔都沒有，屬硬體級阻擋；M4 的 MacBook Air 可以跑。它主打的看懂 agent 做了什麼，這確實對應到我日常讀大量 diff 的需求，但目前只能看不能編輯，替代的是閱讀面不是編輯面。加上定位五週內從 IDE 改口 canvas，hosted 版本連定價都沒有，加上純圖表需求用 Mermaid 加 PlantUML 就能蓋掉，我傾向等三個條件出現再回頭評估：出 .deb 或 Windows 版本、加入檔案或 spec 編輯、hosted 版本定價明朗。
這次整理的資料來源是 GitHub API、README 與 releases、HN 討論串原文、官方 dev.fast/about 頁面，資料查證日期 2026 年 9 月 25 日。