过去一年AI编程助手的使用方式基本没变过。打开编辑器打开对话窗口输入prompt看AI吐代码复制粘贴测试循环。说实话这个流程做了几个月后慢慢发现一个问题有些事情用对话来做效率就是不高。比如你手上有一堆issue要分类想快速梳理代码结构或者要同时看多个项目的工作状态——这些场景天生适合可视化操作而不是一条条对话追问。GitHub显然也注意到了这个限制。一个变化正在发生GitHub Copilot最近推出了一个叫canvas的功能说白了就是在Copilot里创建可交互的视觉工作区。开发者可以用/create-canvas命令生成一个画布画布可以展示信息、支持拖拽操作还能和AI实时互动。翻了下GitHub博客上的详细介绍发现这个功能解决了几个很实际的场景。比如issue分拣——你输入一个prompt要求创建issue卡片界面画布就会生成类似Tinder左滑右滑的交互界面左滑reject右滑ship每张卡片对应一个issue。说实话看到这个例子愣了几秒——这个思路比在命令行里一个一个看issue状态不知道舒服到哪里去了。真正的问题是为什么现在才有人做出这种东西不是替代对话是补充GitHub在博客里提到了一些我觉得很有意思的点。画布不是要替代对话式交互而是要解决那些不太适合对话的任务。那问题来了什么任务不适合对话举个例子。你要理解一个项目的代码架构。传统做法是问AI这个项目结构是什么样的AI给你文本描述描述里出现一堆类名和函数名你在脑子里拼出架构图。而有画布功能后你输入/create-canvas Render a colorful, interactive diagram showing how the code in this project is working together画布直接生成一个可拖拽的架构图。怎么说呢这其实解决了AI编程助手一个长期存在但很少被讨论的问题AI的输出是线性的但开发者的思考不是线性的。当你需要理解复杂关系时一个静态的对话流不如一个可视化的交互界面有效。从实际使用来看画布的另一个价值在于——你可以持续迭代。你不是一次性设计好画布功能而是可以随时让Copilot在现有画布上增加新功能、修改已有组件。这个迭代的特性我觉得比画布本身更值钱。工程实践中的真实价值GitHub举了几个例子我挑两个说说。一个是worktree视图。如果你同时处理多个分支、多个会话终端里敲git worktree list看输出信息是一回事但如果能可视化看到哪些是活动的、哪些是孤立的、一键清理体验完全不同。画布就是把这种终端操作视觉化了。另一个是prompt教练。它会分析你之前的prompt指出哪里可以改进——比如拼写错误、缺少上下文、语法问题。这个功能看着简单但用起来其实挺有用。因为说实话大多数人写的prompt质量都不怎么样包括我自己。这里容易被忽略的是画布不仅仅是GitHub自己做的那几个例子。它是一个开放的扩展机制开发者可以创建自己的画布。这意味着真正有价值的东西可能不是GitHub官方做的而是社区里长出来的。对开发者意味着什么翻了下Hacker News上的讨论有人担心画布功能会让Copilot从一个简单的编程助手变成一个过于复杂的IDE也有人觉得这是Copilot app发展到一定阶段的自然演进。我认为两种说法都有道理但更值得关注的是另一个角度AI IDE正在重新定义编程工具的边界。以前IDE是做代码编辑的聊天窗是做问答的项目管理工具是做任务跟踪的。现在Copilot想把这三者打通让AI能同时出现在编辑、对话、可视化的场合。中间这个可视化环节——也就是画布——恰恰是过去一年多AI编程工具发展中最缺失的一块。当然画布现在还是早期阶段。能在多大程度上替代现有的项目管理工具能不能真的改变开发工作流这些都还是未知数。但至少有一点可以肯定AI编程助手的下一阶段不是把对话做得更好而是让开发者不用再只用对话。关于维基框架维基框架关注企业应用开发中的长期维护问题。在实际项目中业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素因此我们希望提供一套更容易扩展和维护的基础框架。官网framewiki.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版
GitHub Copilot推出画布功能 从聊天到可视化协作
发布时间：2026/7/22 11:15:20
过去一年AI编程助手的使用方式基本没变过。打开编辑器打开对话窗口输入prompt看AI吐代码复制粘贴测试循环。说实话这个流程做了几个月后慢慢发现一个问题有些事情用对话来做效率就是不高。比如你手上有一堆issue要分类想快速梳理代码结构或者要同时看多个项目的工作状态——这些场景天生适合可视化操作而不是一条条对话追问。GitHub显然也注意到了这个限制。一个变化正在发生GitHub Copilot最近推出了一个叫canvas的功能说白了就是在Copilot里创建可交互的视觉工作区。开发者可以用/create-canvas命令生成一个画布画布可以展示信息、支持拖拽操作还能和AI实时互动。翻了下GitHub博客上的详细介绍发现这个功能解决了几个很实际的场景。比如issue分拣——你输入一个prompt要求创建issue卡片界面画布就会生成类似Tinder左滑右滑的交互界面左滑reject右滑ship每张卡片对应一个issue。说实话看到这个例子愣了几秒——这个思路比在命令行里一个一个看issue状态不知道舒服到哪里去了。真正的问题是为什么现在才有人做出这种东西不是替代对话是补充GitHub在博客里提到了一些我觉得很有意思的点。画布不是要替代对话式交互而是要解决那些不太适合对话的任务。那问题来了什么任务不适合对话举个例子。你要理解一个项目的代码架构。传统做法是问AI这个项目结构是什么样的AI给你文本描述描述里出现一堆类名和函数名你在脑子里拼出架构图。而有画布功能后你输入/create-canvas Render a colorful, interactive diagram showing how the code in this project is working together画布直接生成一个可拖拽的架构图。怎么说呢这其实解决了AI编程助手一个长期存在但很少被讨论的问题AI的输出是线性的但开发者的思考不是线性的。当你需要理解复杂关系时一个静态的对话流不如一个可视化的交互界面有效。从实际使用来看画布的另一个价值在于——你可以持续迭代。你不是一次性设计好画布功能而是可以随时让Copilot在现有画布上增加新功能、修改已有组件。这个迭代的特性我觉得比画布本身更值钱。工程实践中的真实价值GitHub举了几个例子我挑两个说说。一个是worktree视图。如果你同时处理多个分支、多个会话终端里敲git worktree list看输出信息是一回事但如果能可视化看到哪些是活动的、哪些是孤立的、一键清理体验完全不同。画布就是把这种终端操作视觉化了。另一个是prompt教练。它会分析你之前的prompt指出哪里可以改进——比如拼写错误、缺少上下文、语法问题。这个功能看着简单但用起来其实挺有用。因为说实话大多数人写的prompt质量都不怎么样包括我自己。这里容易被忽略的是画布不仅仅是GitHub自己做的那几个例子。它是一个开放的扩展机制开发者可以创建自己的画布。这意味着真正有价值的东西可能不是GitHub官方做的而是社区里长出来的。对开发者意味着什么翻了下Hacker News上的讨论有人担心画布功能会让Copilot从一个简单的编程助手变成一个过于复杂的IDE也有人觉得这是Copilot app发展到一定阶段的自然演进。我认为两种说法都有道理但更值得关注的是另一个角度AI IDE正在重新定义编程工具的边界。以前IDE是做代码编辑的聊天窗是做问答的项目管理工具是做任务跟踪的。现在Copilot想把这三者打通让AI能同时出现在编辑、对话、可视化的场合。中间这个可视化环节——也就是画布——恰恰是过去一年多AI编程工具发展中最缺失的一块。当然画布现在还是早期阶段。能在多大程度上替代现有的项目管理工具能不能真的改变开发工作流这些都还是未知数。但至少有一点可以肯定AI编程助手的下一阶段不是把对话做得更好而是让开发者不用再只用对话。关于维基框架维基框架关注企业应用开发中的长期维护问题。在实际项目中业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素因此我们希望提供一套更容易扩展和维护的基础框架。官网framewiki.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版
