Qoder Canvas：为智能体而非人类构建的设计系统

让 AI 编程智能体总结一个拉取请求，答案会落在聊天窗口里：Markdown、代码块、差异摘要。任务规模小的时候这样做没问题。一旦任务变得复杂，文本就变成了一场寻宝游戏。风险、文件和后续步骤被埋在回复里，人类不得不把片段复制回提示词才能继续。

Qoder 团队在阿里云社区发文，给出了一个具体的答案。在一篇阐述 Qoder Canvas 背后思路的文章中，他们描述了一个近期的转变：智能体开始以 HTML 生成复杂结果。仪表盘、PR 评审、架构图、测试报告和研究结论变成了可阅读、可筛选、可点击的页面。关键在于：智能体的输出不一定是文本，它可以是一个交互式工件。

HTML 过于自由，无法成为答案

仅靠 HTML 并不能解决问题，团队对这一缺陷直言不讳。它过于自由。智能体可以随意创造颜色、布局和组件，每一次生成都可能变成一张漂亮但孤立的单页。Qoder 的赌注是：输出问题本质上是一个设计问题。他们将 Canvas 描述为面向编程智能体的设计系统，由代码库、组件系统、设计令牌和任务上下文构建而成。

设计系统的下一个读者是机器

这里的差距，在于为人类编写的设计系统和机器能使用的设计系统之间。人类会为组件带来大量隐性判断。设计师查看 Figma，工程师阅读组件文档，团队通过 Storybook、组件 API、设计指南和评审流程保持一致。人知道哪个组件适合哪个场景，哪些 props 是主路径。智能体完全没有这些。

智能体对组件库的所有理解，都来自代码库中可读的内容：类型声明、导出关系、注释、示例、使用频率、文件结构和最近的修改痕迹。团队认为，输出质量与其说取决于库本身，不如说取决于库在代码中的表达方式。一个仅以裸类型声明暴露的组件只告诉智能体它可以使用；而一个写明了用例、边界、反例和示例的组件则告诉它应该如何被使用。对智能体来说，PieChart 上的一条注释, , 它适合展示比例，而不适合展示趋势或排名，后者应使用 LineChart 或 BarChart, , 就是设计系统的一部分。如果这条注释从未被写下来，智能体就会选错图表。

原子、组件与配方层

Qoder 按照 Atomic Design 的思路来构建 Canvas。最底层是原子（Atoms）：用于颜色、字体排印、间距、圆角、阴影和状态语义的设计令牌。它们不承载业务含义，只是稳定的视觉原语，智能体应该从 useHostTheme().tokens 等语义令牌中获取值，而不是每次重新发明一套调色板。上层是基础组件：Button、Tag、Card、Table、Input、PieChart、LineChart、FileReview 和 DiffGroup。标签表达状态，图表表达数据关系，差异表达代码变更。

真实的智能体任务很少是“画一个组件”。它们更像是“生成一份代码评审”或“解释一个失败的测试”。这正是配方层（recipe layer）的用武之地。recipe.md 不列组件；它告诉智能体，对于某一类任务，信息应该如何组织、证据放在哪里、要暴露哪些操作、要避免哪些视觉形式。团队给出的例子是：一份代码评审配方要求智能体先解释变更，按风险对问题进行排序，为关键发现展示差异证据，并为每个可修复的问题附加一个 AI Fix。

Canvas 是工作台，不是报告

如果 Canvas 只是把结果组织得更清晰，那它仍然停留在输出的层面。用户会回到 Chat，重新描述问题，粘贴文件名，再解释一遍为什么这段 diff 很重要。真正的转变发生在交互层：每一个结构化节点都成为下一个动作的入口。Canvas 代码评审中的一个问题条目，不仅仅是一段风险描述。它带有优先级、相关文件、差异证据、影响范围、推荐的修复策略，以及它来自的配方。

点击 AI Fix 发送的不是一句简单的“帮我修一下”。它会将发现、相关文件、差异证据、设计系统约束和验证要求一起打包回 Chat。点击 Generate Test 会把缺失的覆盖逻辑、风险路径和边界条件带入测试生成。这就是 Canvas 与普通 HTML 的分界线。HTML 组织结果；Canvas 把结果、上下文和下一步动作放到同一个结构中。没有这些上下文，按钮就只是按钮；背后有了设计系统和配方，按钮就变成了一个可执行的协作点。

智能体如今身处界面之中

Qoder 将 Canvas 称为 Agentic UI 的早期形态。传统界面假设由人类操作系统。智能体时代在界面内加入了第二个行动者, , 它读取上下文、提出建议、调用工具、修改文件。问题也随之改变：智能体在做什么、为什么这样做、哪些上下文会带入下一步、哪些操作需要人工确认，以及错误能否被暂停、修改或回滚？

这一方向并非 Qoder 独有。我们曾报道过 Cursor 的 Design Mode 更新，它解决的是同一问题的输入侧：在实时浏览器视图中指向、绘制或说出一个改动，而不是把视觉 bug 转译成文本提示词。Qoder 解决的是输出侧。一个减少了告诉智能体改什么的摩擦；另一个减少了阅读它产出的摩擦。两者都认为聊天窗口不再是承载这项工作的合适容器。

Canvas 能否成立，取决于团队是否能保持配方诚实。一个面向智能体的设计系统，只有在代码库确实表达了团队所称的内容时才能起作用。机器读者无法推断出那些从未被写下来的决策。