如何让我的 DeepSeek 生图

最近这段时间，我越来越明显地感觉到一件事：

AI 编程已经很强了，但真正做一个完整项目的时候，代码反而不一定是最麻烦的。

现在不管是 Codex、Claude Code，还是各种 AI Agent，你让它写个后台、搭个官网、做个管理系统，很多时候它都能干得七七八八。

但项目做到一半，经常会卡在一些非常“低级”的地方。

比如：

• 首页缺一张 Banner；
• 产品介绍需要几张配图；
• Landing Page 需要一个科技感背景；
• 项目 README 想加一张宣传图；
• 做完网站以后，还缺一张 OG 分享图；
• 甚至公众号文章写完了，还得专门再去做封面。

这个时候，我们的工作流通常就断了。

AI 在终端里写代码。

我打开生图网站。

复制提示词。

生成图片。

下载。

找到下载目录。

把图片拖进项目。

再回来告诉 AI：

图片我放好了，你接着改页面吧。

看起来每一步都不复杂。

但一天干几十次以后，真的很烦。

所以最近我做了一个很简单的东西：

Silico Grove Image Skill。

它的目的只有一个：

让 Codex、Claude Code 这类 AI Agent，自己去生图。

项目地址：

https://github.com/Rodert/silicogrove-image-skill

这个项目目前已经开源，仓库里提供了完整的 Skill 文件、脚本、参考文档和 Agent 相关配置。

---

一、以前 AI 写代码，现在 AI 连图片也自己做

这个 Skill 最简单的理解方式就是：

给你的 AI 编程助手增加一个“生成图片”的工具。

比如我正在让 Codex 做一个 AI 产品官网。

以前我可能会这样说：

帮我做一个 AI 产品官网。

使用 Next.js。
整体使用黑色科技风。
首页需要一个比较有冲击力的 Hero 区域。

Codex 很快就可以把页面写出来。

但是 Hero 背景怎么办？

以前可能就是随便放一个渐变背景，或者去 Unsplash 找一张图。

现在，我可以直接告诉它：

给这个网站生成一张 16:9 的首页 Banner。

深色科技风。
画面中包含 AI 芯片、数据流和未来城市。
不要出现文字。

生成完成以后直接放到项目的 public/images 目录，
然后修改首页代码引用这张图片。

后面的事情，就可以交给 Agent。

大概变成：

理解需求
    ↓
编写页面
    ↓
调用生图 Skill
    ↓
生成图片
    ↓
等待图片任务完成
    ↓
下载图片
    ↓
保存到项目目录
    ↓
修改代码引用图片
    ↓
继续完成项目

我觉得这个变化其实挺重要的。

因为它并不是简单地：

“AI 又会调用一个图片 API 了。”

而是：

图片生成这件事情，终于进入了 Agent 的完整工作流。

---

二、这和直接去 ChatGPT 生一张图有什么区别？

可能有人会问：

现在能生图的平台这么多，我为什么还需要一个 Skill？

因为这两种使用方式，本质上完全不一样。

我自己打开 ChatGPT、生图网站或者其他图片工具，通常是这样的：

我
↓
打开生图平台
↓
输入提示词
↓
生成
↓
下载
↓
找到图片
↓
放进项目
↓
继续开发

而使用 Skill 以后：

我
↓
AI Agent
↓
Silico Grove Image Skill
↓
图片模型
↓
本地项目

中间大量操作都可以不需要我参与。

这才是我觉得 Skill 最有意思的地方。

Skill 不是为了让我少打开一个网站。

而是为了：

尽可能不让我参与这些中间步骤。

---

三、安装甚至可以直接让 AI 自己完成

我做这个 Skill 的时候，一个很重要的原则就是：

不要又搞出一堆复杂的安装教程。

所以项目 README 最上面直接放了一段可以复制给 AI 的提示词。

你甚至可以直接告诉 Codex：

请安装并使用这个 Silico Grove 生图 Skill：

https://github.com/Rodert/silicogrove-image-skill

README 本身就是按照“把这段内容直接交给 AI Agent”这个思路设计的。

第一次使用的时候，Agent 会检查本地是否已经配置 API Key。

如果没有，就提示配置。

配置完成以后，会把 Key 保存到当前用户的本地配置目录里，后续正常生图时直接复用，不需要每次都重新输入，也不要求用户自己去折腾环境变量。

这个细节我觉得很重要。

因为一个 Skill 如果每次使用之前还需要：

export API_KEY=xxxx

再设置一堆环境变量，其实使用体验已经开始变差了。

---

四、它不只是文生图，还可以直接改图

除了最基本的 Text to Image，这个 Skill 还支持参考图编辑。项目中的 Skill 定义明确提供了 generate 和 edit 两类工作流。

比如你已经有一张产品图。

直接告诉 Agent：

把这张产品图背景换成白色摄影棚背景。

产品本身不要改变。
保持真实摄影效果。

或者：

参考这张图。

保留人物和主体，
把整体风格调整成赛博朋克，
背景换成未来东京街道。

再或者做开发的时候：

这张 Banner 风格和现在的网站不统一。

参考网站目前的 UI，
重新调整成黑色、银色、科技感，
尺寸保持不变。

这样图片修改也可以继续留在开发上下文里面。

这对于做网站、App、小程序甚至电商页面，我觉得都会比较方便。

目前 Skill 对本地参考图支持 PNG、JPG、JPEG 和 WebP，并对上传图片大小做了限制。

---

五、我还专门把它设计成了异步任务

图片生成和文本生成有一个很大的区别：

图片往往需要等。

有时候几十秒，有时候更久。

所以这个 Skill 没有把它简单做成一次 HTTP 请求然后傻等，而是采用异步任务。

Agent 提交图片任务以后，会获得对应的任务 ID，然后持续查询任务状态。

图片完成以后，再下载到本地。

而且任务 ID 会被记录下来。即便中间出现本地连接中断，已经被服务器接受的生图任务也不会因此停止；客户端也会避免在状态不明的时候盲目重新提交，从而降低重复生成、重复计费的风险。

简单来说就是：

Agent
  │
  ├── 提交生图任务
  │
  ├── 获得 Task ID
  │
  ├── 等待 / 查询状态
  │
  ├── 图片完成
  │
  └── 下载到本地

而不是：

请求失败？
    ↓
不知道生成没生成
    ↓
再来一次
    ↓
可能生成两张

这个问题平时自己点网页可能感觉不明显。

但是一旦进入 Agent 自动化工作流，任务状态管理其实非常重要。

---

六、生成的不是一个 URL，而是真正的本地文件

这也是我特别想做的一点。

很多 API 调用完成以后，只会返回：

{
  "url": "https://xxxxx/image.png"
}

如果只是聊天，这没什么问题。

但是对于 Coding Agent 来说不够。

因为下一步它很可能需要：

<img src="/images/banner.png" />

所以 Silico Grove Image Skill 默认的思路就是：

图片生成完成以后，直接下载到本地输出目录。

于是 Agent 就可以继续干：

生成 banner.png
        ↓
保存到 public/images/
        ↓
修改 index.tsx
        ↓
引用 /images/banner.png
        ↓
运行项目

这一点看起来非常小。

但我觉得这是“生图工具”和“Agent Skill”之间一个很明显的区别。

---

七、目前可以接 GPT Image，也可以接 Gemini 图片模型

Skill 目前的默认模型是 gpt-image-2，默认尺寸为 1024x1024，默认质量为 high。同时它也对 Gemini 图片工作流进行了适配，例如 gemini-3.1-flash-image。

所以从 Agent 的角度来看，不需要特别关心底层到底是哪一家。

未来甚至可以继续增加更多图片模型。

最终我们想要的体验其实应该是：

用户：

给这个页面做一张科技感 Banner。

而不是：

用户：

POST /v1/images/xxx

model=xxx
quality=xxx
size=xxx
response_format=xxx

API 参数应该逐渐退到后面。

意图才应该站到前面。

---

八、我觉得 Skill 真正有意思的地方，不是“插件越来越多”

最近我越来越喜欢研究 Agent 和 Skill。

不是因为 Skill 这个名字有多新。

实际上很多 Skill 的底层，就是：

提示词
+
脚本
+
API
+
工具
+
一些规则

真正让我觉得有意思的是：

我们正在一点点把原来需要“人操作软件”的能力，交给 Agent。

比如以前：

搜索资料，需要打开浏览器。

做图，需要打开生图平台。

部署，需要打开服务器。

操作数据库，需要打开客户端。

发邮件，需要打开邮箱。

现在这些东西，都正在慢慢变成：

Search Skill
Image Skill
Deploy Skill
Database Skill
Email Skill
...

然后交给 Agent 调用。

最后可能会变成：

你
↓
Agent
├── Coding
├── Search
├── Browser
├── Image
├── Video
├── Database
├── Deploy
└── ...

这时候 AI 编程真正改变的，就不只是：

“程序员写代码更快了。”

而是：

一个人能够控制的工具越来越多了。

---

九、以后做一个网站，可能真的只需要说一句话

比如以后我希望能直接给 Codex 一句话：

帮我做一个 AI 图片生成产品官网。

要求：

1. Next.js
2. 首页深色科技风
3. 自己生成 Hero Banner
4. 自己生成三张产品功能配图
5. 自己生成 Logo 占位图
6. 所有图片放到 public/images
7. 页面完成以后运行测试
8. 有问题自己修改

然后去干别的。

Agent 自己开始：

写代码
↓
生图
↓
改图
↓
保存图片
↓
引用图片
↓
运行
↓
发现问题
↓
继续修改

我觉得这才是 Coding Agent 接下来真正有意思的地方。

不是让 AI 帮我们操作更多软件。

而是逐渐让我们不用再操作这些软件。

---

最后

Silico Grove Image Skill 目前已经放到 GitHub：

https://github.com/Rodert/silicogrove-image-skill

使用方式也非常简单。

甚至不用认真研究安装教程。

把仓库地址直接丢给你的 Codex、Claude Code 或其他支持 Skill 的 Agent，让它自己看。

然后告诉它：

给我生成一张图。

就可以开始了。

我一直觉得，现在可能真的是技术人非常好的一个时代。

大模型以前所未有的速度发展，中国又有极其成熟、性价比非常高的制造业，再加上今天发达的互联网、支付和全球物流体系。

以前很多事情，需要一个团队才能做。

现在一个程序员加上一堆 Agent，就已经可以干很多以前想都不敢想的事情。

所以我现在越来越关注的，也不只是：

AI 能不能帮我们把代码写得更快。

而是：

当代码、图片、视频、搜索、部署、运营这些能力全部变成 Skill 以后，一个人到底能做多大的事情？

这个问题，可能比单纯讨论哪个大模型跑分更高，有意思得多。