不用再切换工具了：Copilot 现在能在对话里直接画图、改图

写代码的时候突然需要一张图，过去的标准动作是：停下手里的活，打开另一个工具，把需求再讲一遍，等图生成，再手动搬回项目。2026 年 10 月 28 日，GitHub 在更新日志里宣布，这个切换可以省了：Copilot 现在能直接在对话里用自然语言生成和修改图片，图会内联预览，并直接存进你的项目。

这不是 Copilot 变成了一个设计工具，而是一次很务实的减法：把“要一张配图、一个占位、一个示意”这类小活，收进程序员已经在用的对话里。值不值得用，取决于你怎么看它的三条线：计费单独立、预览不等于可用、水印默认关闭。

到底发了什么：对话里要图，图直接进仓库

按 GitHub 更新日志的说法，流程是这样的：你在任何一个 Copilot 对话里用日常语言描述想要的图片，无论是新开一个对话，还是正在做一个编码任务的中途，都可以提。你选定的推理模型会调用一个专门的图片生成工具，这个工具由 GPT Image 2.5 Flare 驱动；生成结果先在对话里内联预览，确认后直接保存到你的项目工作区。

入口覆盖三处：VS Code 里的 Copilot 对话、独立的 GitHub Copilot 应用、Copilot 命令行工具。状态是公开预览，面向 Copilot Pro、Pro+、商业版和企业版。组织和企业管理员可以通过 Copilot 的模型策略关掉图片生成功能，这一点对有合规要求的团队很重要：不是所有人都默认能用，而是管理员可以一键收回。

计费是单独的一条线。图片请求不占用你当前对话模型的按消息配额，而是消耗图片 token，计入你套餐里的 AI 额度。换句话说，你在对话里要图，不会把写代码的额度挤掉，但会在另一本账上记一笔。公开预览阶段价格细节以后还可能变，现在值得记下的只是这个结构：两本账，别混着算。

它省掉的是切换，不是设计本身

GitHub 对这个功能的定位说得很克制：它解决的是上下文切换。以前的流程里，需求要在两个工具里讲两遍，图的版本和代码的版本还容易脱节。现在需求只讲一遍，图和代码落在同一个工作区，改起来也顺手：发现配图里有个元素不对，直接在对话里说一句改掉，不用重新导出导入。

但这不等于 Copilot 替你做了设计判断。模型不知道你的品牌色板有没有更新，不知道这张图会不会用在正式发布的文档里，也不知道图里的文字在小尺寸下还认不认得出。它给的是“能用的初稿”，不是“能直接发布的成品”。对 vibe coding 的小团队来说，这个区分尤其重要：demo 里放一张 AI 生成的示意图没问题，写进用户手册、官网首页、应用商店截图之前，仍需要人眼过一遍。

还有一个容易被忽略的点：图存进工作区，就进了版本控制。一次随手生成的十几张尝试图，如果不清理，会跟着仓库走很久。建议顺手立一条规矩：对话里生成的图先放一个专门的草稿目录，定稿后再挪到正式的资源目录；废弃的尝试图及时删除，不要让仓库替你存着一堆“以后也许有用”的图片。

水印默认关闭：方便，但责任在你

GitHub 给了一个可选项：可以在 Copilot 生成和修改的图片上加一个看得见的“Made with AI”水印，但默认是关闭的，需要用户或组织主动打开。这个默认值值得多想一秒。

从好用的角度看，默认关闭是对的：大多数时候你要的只是一张内部占位图、一个演示用的示意，加水印反而碍事。从负责任的角度看，默认关闭也意味着“是否标注 AI 生成”这个决定被交给了使用者。对内使用的草图，不标问题不大；对外发布、尤其是可能被当成真实照片、真实产品截图、真实人物照片的内容，不标注就可能误导读者。

务实的做法是按用途分两档：内部占位、演示草稿、头脑风暴用的图，不用纠结水印；对外发布、放进文档和官网的图，要么打开水印，要么在图注里写明 AI 生成。团队可以在模型策略或内部规范里把这条写死，不要留给每个人临场决定。标注不是给图片减分，而是给读者一个判断依据。

什么活适合它，什么活不适合

• 适合：占位图和示意图，比如空状态插画、演示用的界面示意、文档里的流程示意、头脑风暴时的多个方向草图；改图也适合，比如“把背景换成浅色”“把这个元素去掉”这类小改。
• 适合：需要快速验证想法的场合，比如给同事看三个不同的首页配图方向，先定方向再找设计师细化，比空口描述快得多。
• 不适合：需要精确还原的图，比如产品真实界面截图、数据图表、带精确文字的示意图——模型生成的文字和数字容易出错，必须人工逐字核对。
• 不适合：涉及真实人物、真实地点、真实品牌素材的图，生成结果可能失真或侵权风险高，别拿对话生成当摄影和采购的替代品。
• 不适合：对版权和来源有硬性要求的正式出版物，除非你已经确认了组织内部对 AI 生成图片的使用政策。

给小团队的三条使用建议

第一，把图片生成当成对话的一部分来管理，而不是当成独立的设计流程。需求描述要像写给同事一样具体：用途、尺寸感觉、主角、背景、风格、不要什么。描述越具体，返工越少；只说“来一张好看的图”，等于把决策权全交给模型。

第二，建立“预览—核对—定稿”三步。预览时看构图和感觉，核对时逐字看图里的文字、逐个数图里的人手和元素、确认没有多余的奇怪细节，定稿后才挪进正式资源目录并提交。公开预览意味着行为还可能变，别把未经核对的图直接写进发布流程。

第三，定期对一次账。月底看一眼图片 token 消耗了多少 AI 额度，哪些图最后真的用上了，哪些只是随手试试。如果试错的图占了大头，说明需求描述还可以再具体一点，或者有些活根本不值得生成——直接用现成的图标和照片更快。

还有一条是给管理员的：先确认你们的套餐在公开预览的覆盖范围内，再决定要不要通过模型策略统一关闭或放开。如果团队里有人要对外发布 AI 生成图片，先把水印和标注规则定下来，再放开权限，顺序不要反。

放在 10 月 28 日这一批里看，它的位置

10 月 28 日前后，GitHub 一口气推了不少 Copilot 更新，里面有模型路由、跨仓库协作、桌面操作等更大的题目。图片生成在其中算一个小功能，但它有一个其他大功能没有的特点：上手零门槛。不需要学新的编排概念，不需要改工作流，只要在已经会用的对话里多说一句话。

小功能的意义往往不在发布当天，而在它被用顺之后：当“要一张图”不再是一次切换，团队做 demo、写文档、做演示的摩擦就小了一点。摩擦小了，文档和演示才更可能被及时更新，而不是拖到发布前夜。对小团队来说，这种不起眼的顺滑，有时比一个大功能更实在。

当然也要留一句提醒：公开预览就是公开预览。计费方式、可用模型、预览行为都可能调整，现在顺手的用法，三个月后不一定原样存在。把它当成提效的帮手，别把它写进不可替代的关键路径。

对话示例：怎么描述，决定了要改几遍

描述图片需求时，有一个简单的检查法：把你的描述念给一个没见过这个项目的同事听，他能不能在脑子里画出大概的样子。如果不能，模型也大概率只能猜。比较好的描述会同时给五个要素：用途、主角、场景、风格、排除项。比如：“给一款记账应用的空状态页画一张插画，主角是一只正在打盹的猫，背景是浅米色，风格是扁平简洁，不要文字，不要出现真实品牌标志。”用途决定了图的职责，排除项决定了返工次数。

改图的时候也一样，不要只说“再好看一点”。“好看”不是一个可执行的指令，模型只能随机换一个方向。更有效的说法是指向具体的元素：“把猫换成在伸懒腰的姿势，背景再浅一点，整体留白多一点。”每一次修改只动一到两个元素，改完先看结果再决定下一步；一次改五处，出问题也说不清是哪一处改坏的。

还有一类需求要提前想好：图里的文字。模型生成中文、英文短词尚可一试，但长句子、标语、数据标签很容易出现错字、多字、字母粘连。凡是图里有文字的，生成后第一件事就是逐字读一遍，不要只看整体感觉。正式场合的图，更稳妥的做法是让模型只出图形部分，文字后期用设计工具或代码叠加上去，这样文字百分之百可控。

成本账：免费的不是图片，是切换

图片生成省掉的是时间，不是费用。每一张图都要消耗图片 token，计入套餐的 AI 额度；反复试错十几张，额度消耗是实打实的。对个人开发者来说，这个消耗通常不大；对一个团队来说，如果每个人都随手生成、又不清理，月底的额度账单会比预期高一截。

控制成本的办法不复杂。第一，需求描述先写具体，减少无效尝试；第二，批量要图的时候先定方向：先出三张不同方向的小稿，定一个方向再细化，而不是沿着十个方向各出一张；第三，定期清理草稿目录，顺便数一下这个月真正用上的图有几张。如果用上的不到三分之一，说明很多生成其实是不必要的，下次可以先问一句：这张图真的需要生成，还是现成的图标、照片、截图就够了？

另外要注意计费口径的变化。公开预览阶段的计费方式以后可能调整，现在“图片 token 计入 AI 额度”这个结构是确定的，具体价格和额度换算要以 GitHub 当时的说明为准。把图片生成写进团队预算时，留一点弹性，别按首月的试用消耗去推全年。

和设计师协作：用它定方向，不是用它定稿

对有设计师的团队，Copilot 图片生成最合适的角色是“方向稿工具”，而不是“出图工具”。产品经理或开发者先用对话生成三到五个不同方向的草图，拿着草图和设计师讨论：这个方向的感觉对不对，哪个元素值得保留，哪个要去掉。讨论有了具体的图做锚点，比纯文字描述快得多，也减少了“我以为你说的是这个”的误会。

定稿仍然交给设计师。原因有三点：品牌一致性需要人工把关，模型不知道你上一版的色板和字体规范；正式发布的图需要可追溯的来源和版权确认，对话生成的图在这一点上是模糊的；细节的精确度，比如图标的对齐、留白的比例、文字的排版，仍然需要专业工具来收尾。把对话生成定位成“讨论的起点”，设计师会欢迎它；定位成“替代设计师”，只会制造不信任。

对没有设计师的小团队，道理也一样，只是定稿的人换成了自己。流程可以简化为：对话出方向稿，自己选一张，用设计工具或代码做最后的调整——改文字、调尺寸、统一色调。最后一步的人工调整花不了多少时间，却能把“AI 味很重”的图变成“能见人”的图。

常见失败长什么样，遇到怎么处理

文字出错是最常见的失败。图里的标语多个字母、少个笔画，或者中英文混排时断行奇怪。处理办法是缩小文字的任务：让模型只生成无文字的图形，文字后期叠加；如果必须带文字，生成后逐字核对，错了就只改文字部分，不要整图重画。

风格漂移是第二种失败。同一组图，第一张是扁平风，第二张突然变成了写实风。原因是描述里没有固定风格词。处理办法是把风格描述写成固定的一句话，每次复用同一句，比如“扁平插画，柔和配色，大量留白”，不要每次换着词说。风格词固定了，成组图的统一感才会出来。

元素多余或缺失是第三种。画面里多了一只手、少了一个关键物件，或者主角被裁掉一半。处理办法是逐项点名：描述里把必须有的元素列出来，把不要的元素也列出来，生成后按清单核对。清单核对听起来笨，但比“感觉不对、再来一张”省时间得多。

最后一种失败不是图的失败，而是流程的失败：图生成了，没人知道它对应哪个需求、哪个版本。处理办法是命名规范：文件名里带上用途和日期，比如 empty-state-cat-draft-2026-10-28，定稿后改名去掉 draft。仓库里的图有了名字和状态，后来的人才知道哪张能用、哪张只是尝试。

一句话总结：它值得开，但别写进关键路径

如果用一句话给这个功能定性，那就是：它值得打开试用，但不值得写进不可替代的关键路径。值得试用，是因为上手成本几乎为零，省掉的切换时间是每天都能感受到的；不写进关键路径，是因为它还在公开预览，计费、模型、行为都可能变，而且生成结果永远需要人核对。把这两句话同时记住，就不会出现两种极端：一种是听说能画图就什么都拿它画，另一种是觉得是预览版就完全不用。

对 vibe coding 的独立开发者和小团队来说，最好的试用方式是先拿一个真实的小需求开刀：比如下一次发版说明里需要的一张空状态插画，或者演示视频里需要的一张示意图。从头到尾走一遍描述、预览、核对、定稿、清理的流程，看看自己的描述习惯要改哪里，看看额度消耗是不是在预期内。走完一遍，你对这个功能的判断就不再是听来的，而是自己试出来的。工具的价值，最终都是这样试出来的。