OnePixel

GLM+ClaudeCode全局开发规则

2025-12-08T13:45:28Z

一、语言和环境

语言：简体中文（包括代码注释与 Git Commit 信息）
系统：Windows 11 + PowerShell
包管理器：npm

二、交互与澄清规则

当对用户意图、需求或实现方向存在任何不确定时，必须使用 AskUserQuestion 主动提问，禁止自行推断。
在获得明确且充分的信息前，不得进行分析、设计、编码或修改操作。
若用户回答仍含糊，应继续通过 AskUserQuestion 追问，直到以下内容清晰：
- 目标与预期
- 边界与限制
- 优先级与取舍
- 与现有结构或规范的关系
若出现信息冲突、需求变化或可能导致返工的风险，必须再次使用 AskUserQuestion 确认方向。
只有在用户确认理解无误后，才可进入具体实现。

三、工具使用规则

核心原则：文件操作使用专用工具，系统命令使用 Bash。

操作类型	使用工具	禁止
读取文件	Read	cat/head/tail/Get-Content
搜索文件	Glob	find/ls/Get-ChildItem
搜索内容	Grep	grep/rg/Select-String
编辑文件	Edit	sed/awk
创建文件	Write	echo >/cat <<EOF
系统命令	Bash	非系统或工程级命令

Bash 说明：用于 git、pnpm、npm、vite、tsc、docker 等系统命令；不支持 PowerShell 命令。

1.文件修改流程

修改现有文件时，务必按照以下顺序操作：

首先使用Read工具读取文件（了解当前内容）
然后使用Edit工具执行修改（自动触发 VSCode 差异视图）
禁止使用Write覆盖现有文件（除非创建新文件）

原因：Edit工具会在 VSCode 中自动生成修改前后的差异视图，以便于用户审查文件变更。

2.外部工具说明

视觉理解

你不具备原生的视觉理解能力，因此在处理用户上传的任何图片时，必须依赖 zai-mcp-server 所提供的视觉工具来获取图像内容。
在没有通过这些工具获得所需信息之前，禁止回答任何与图片相关的问题，以避免产生虚构内容。
服务器已提供多种视觉工具，能够覆盖不同类型的图像处理需求。你应根据用户的描述主动选择最合适的工具。
如果首次调用未能取得完成任务所需的信息，应自主再次调用，直到具备继续执行的条件。
在整个图像处理过程中，你应将这些工具视作你的视觉输入来源。无需向用户解释你无法直接看图，也不需要说明调用工具的过程。

网络搜索

禁用 WebSearch 工具，当前环境不可用，使用其他可用 MCP 工具代替。

3.Git 操作规范

只读操作（可直接执行）：log、status、diff、branch、show 等
变更操作（需用户二次确认）：commit、push、pull、merge、rebase、reset 等

在 PowerShell 中用 Profile 注入“工作目录选择能力”的本质与实践

2025-12-02T06:52:14Z

一、问题背景：终端已经打开，却无法“选一个目录”

在日常开发中，我们经常遇到这样的场景：

已经打开了 PowerShell；
想用某个命令行工具（例如 claude）在某个项目目录下工作；
却不得不：
- 要么手动输入一长串 cd 路径；
- 要么回到资源管理器复制路径，再粘贴到终端中。

如果你习惯用鼠标和界面操作，这种“必须手敲路径”的方式会显得很不直觉：

终端已经开好了，却不能像 GUI 那样“选一个工作目录再开始干活”。

本文不讨论某个命令本身（例如 claude）的具体行为，而是聚焦在 “配置方法的本质” 上：

为什么把能力写进 $PROFILE 是合适的、推荐的；
这种做法在 PowerShell 里到底算什么；
如何判断它有没有副作用、是否安全。

二、Shell 的核心：当前工作目录（CWD）

无论是 PowerShell、Bash 还是 Zsh，它们在设计上都有一个共同前提：

Shell 只认“当前工作目录”（Current Working Directory，CWD）。

在 PowerShell 中，当前工作目录通常通过内置变量 PWD 表示，它对整个会话有非常重要的影响：

相对路径如何解析；
命令到底在什么目录里执行；
某些工具默认读取、写入的文件范围。

例如，当你在 PowerShell 中执行：

claude

本质上不是“在某个魔法空间运行”，而是：

在当前工作目录下启动 claude，将该目录视为工作上下文。

换句话说，“在哪里执行命令”是由 Shell 当前所在的目录决定的，而不是由工具本身决定。

因此，当我们抱怨“每次都要复制路径、手动 cd”时，真正的矛盾其实是：

Shell 只提供了文本方式的目录切换（Set-Location / cd）；
但我们希望有一个更直观的方式来“指定当前工作目录”。

三、不要怪工具：问题根源在 Shell 层

很多人下意识会从工具入手，尝试：

给 claude 之类的命令加参数；
为每个项目写独立启动脚本；
在资源管理器里增加右键菜单。

这些做法都可以“绕开”当前工作目录的问题，但有一个共性：

它们是“围绕某个工具做适配”，而不是从 Shell 的模型出发解决问题。

更合理、也更通用的思路是：

在 Shell 层补上一种更符合人类习惯的“设定当前工作目录”的能力。

这样一来，不只是 claude，git、npm、docker 等所有依赖当前目录的工具都能一并受益。

四、`$PROFILE` 的本质：启动阶段的脚本注入机制

为了在 Shell 层扩展能力，PowerShell 提供了一个非常关键的机制：$PROFILE。

很多人把 $PROFILE 想成“配置文件”，实际上更精确的描述是：

$PROFILE 是 PowerShell 在启动时自动执行的一段脚本。

它有两个关键特征：

自动执行：每次启动 PowerShell 会话时，都会执行一次 $PROFILE 中的代码；
作用范围仅限当前会话：不会修改 PowerShell 程序本身，也不会直接改系统级配置。

也就是说，把逻辑写进 $PROFILE，本质上是在做这件事：

在每一个 PowerShell 会话的初始化阶段，预先往当前会话里“注入一些自定义能力”。

这与在终端中手动执行一个 .ps1 文件没有本质区别，只是由“手动执行一次”变成了“每次启动自动执行”。

五、这种配置方法到底在做什么？

从“方法论”的角度看，把函数写入 $PROFILE 并不是在：

修改 PowerShell 内核行为；
Hook 或重载内置命令；
改动全局 PATH、注册表或系统设置。

而是在做一件更小、更可控的事情：

在 Shell 初始化阶段，向当前会话的命名空间中注册自定义函数和别名。

例如，我们在 $PROFILE 中定义：

# 选择工作目录并切换到该目录
function work {
    # 加载窗体程序集
    Add-Type -AssemblyName System.Windows.Forms | Out-Null

    # 创建文件夹选择对话框
    $dialog = New-Object System.Windows.Forms.FolderBrowserDialog
    $dialog.Description  = "请选择工作目录"
    $dialog.SelectedPath = "D:\"   # 默认起始目录

    # 用户取消时直接返回
    if ($dialog.ShowDialog() -ne [System.Windows.Forms.DialogResult]::OK) {
        return
    }

    # 获取并校验所选路径
    $path = $dialog.SelectedPath
    if (-not (Test-Path -LiteralPath $path)) {
        return
    }

    # 切换到工作目录
    Set-Location -LiteralPath $path
}

# 简短别名：wd
Set-Alias wd work

从 PowerShell 的视角看，这只是：

定义了一个函数名 work；
为它添加了一个别名 wd；
函数本身只在被调用时才执行。

这意味着：

PowerShell 启动时只是在当前会话中“多注册了一个命令”；
除非你手动输入 work 或 wd，否则这段代码不会运行；
它不会主动修改路径、不会自动弹窗、不会影响脚本执行流程。

六、为什么可以认为这是“推荐的做法之一”？

PowerShell 的官方设计初衷之一，就是鼓励用户通过 Profile 定制自己的交互式环境。典型用法包括：

定义常用函数，例如：
- gs → git status
- gcmsg → git commit -m
定义别名，例如：
- ll → Get-ChildItem -Force
设置提示符、默认编码、常用环境变量等。

也就是说：

在 Profile 中放入“函数 + 别名”，是 PowerShell 中非常常见、且被广泛接受的扩展方式。

真正需要警惕的并不是“往 $PROFILE 里写东西”这件事本身，而是：

写入了什么代码；
这些代码是否在启动阶段就产生了副作用。

如果只是像上面那样：

定义一个函数 work；
设置一个别名 wd；
函数只在手动调用时才会执行；

那么这种配置方式就属于既符合 PowerShell 的设计理念，又足够温和、安全的用法。

七、如何在配置前评估“是否会有副作用”？

在把任何逻辑写入 $PROFILE 之前，可以按下面这套简单标准来做自检。

1. 推荐放入 Profile 的内容

函数定义；
别名声明；
轻量且幂等的环境准备逻辑（例如设置提示符、少量环境变量）。

特点是：

不会对系统做不可逆修改；
不会显著拖慢终端启动速度；
不会强制与用户交互（例如启动时弹出对话框）。

2. 不推荐放入 Profile 的内容

启动即执行的重操作：
- 大量文件扫描；
- 网络请求；
- 启动后台服务等；
自动修改系统级配置：
- 注册表；
- 全局 PATH；
- 系统代理设置等；
会阻塞启动、强制交互的逻辑：
- 每次开终端都弹出窗口；
- 每次启动都要求输入确认。

只要 Profile 中新增的内容满足以下条件，基本可以认为是安全的：

不会在启动时自动执行复杂操作；
只在你主动调用对应函数或别名时才生效；
所有影响都限制在当前 PowerShell 会话中，关掉窗口即可完全结束。

上文的 work / wd 设置就属于这种范畴。

八、即使出了问题，也可以方便撤回

即便配置出错，PowerShell 也提供了比较友好的“逃生机制”。

1. 使用 `-NoProfile` 启动干净会话

如果 Profile 写错导致终端启动异常，可以用下面的方式打开一个不加载 Profile 的会话：

pwsh -NoProfile

在这个干净会话里，就可以放心地编辑 Profile 文件：

notepad $PROFILE

删除或注释掉有问题的部分即可。

2. 临时移除函数和别名

在当前会话中，如果只是想临时禁用某个函数或别名，也可以直接删除它们的定义：

Remove-Item Function:work -ErrorAction SilentlyContinue
Remove-Item Alias:wd -ErrorAction SilentlyContinue

下次启动 PowerShell 时，如果 Profile 不再定义这些内容，它们也不会被重新创建。

3. 事先备份 Profile

在做任何修改之前，也可以先备份一份当前 Profile：

if (Test-Path $PROFILE) {
    Copy-Item $PROFILE "$PROFILE.bak-$(Get-Date -Format 'yyyyMMddHHmmss')"
}

一旦出现问题，可以直接用备份文件覆盖回去。

九、总结：这类配置的“本质”是什么？

从配置方法的角度来看，把 “工作目录选择能力” 写入 $PROFILE，本质是在做这样一件事情：

利用 PowerShell 的初始化机制，把一次性的自定义逻辑，转化为每个交互式会话默认可用的 Shell 能力。

具体而言：

不是在改 claude，也不是在改 PowerShell 内核；
而是在“Shell 启动阶段”往当前会话中注入一个小能力：
- 通过 GUI 选择目录；
- 把这个目录设置为当前工作目录；
- 然后交给你习惯的命令（例如 claude）继续工作。

理解了这一点之后，这种方式就不仅仅适用于某一个工具，而是可以推广到所有依赖当前目录的命令行工具：

git：在选中的目录中执行版本管理；
npm / pnpm：在对应项目下安装依赖、运行脚本；
docker：在指定目录中读取配置与资源；
各类自定义脚本、构建工具等。

最终，这样的配置方式既保留了 Shell 的灵活性，又在交互层面补上了一个“人类更习惯”的操作入口，同时通过 Profile 的机制，将这种能力自然地融入每一次交互式会话中。

使用 GitHub Desktop 同步 Fork 仓库并保持与上游更新一致

2025-11-21T15:06:00Z

在基于开源项目进行二次开发或搭建个人博客时，我们通常会先 fork 一份原仓库，然后在自己的仓库上持续更新，例如发布文章、修改配置、或加入个性化功能。而与此同时，原仓库（upstream）仍然在不断更新。如果不及时同步，会导致自己的仓库逐渐落后。

为了保持项目健康、减少未来的冲突，本教程将详细记录如何使用 GitHub Desktop 完整同步 upstream 更新，并在同步过程中保留自己所有的提交。

一、为什么需要同步 Fork？

当你 fork 了某个开源项目后：

你会不断添加自己的内容（文章、配置、主题等）
上游作者也在持续更新（新功能、修复、优化等）

如果不保持同步：

新功能无法获得
Bug 修复无法合入
冲突风险不断增加

因此：定期同步 upstream 是保证 Fork 健康且可维护的关键步骤。

二、添加 upstream 源（首次必须完成）

在 GitHub Desktop 中：

打开项目
上方菜单 Repository → Repository Settings
左侧选择 Remotes
点击 Add 添加一个新的远程源：
- Name： upstream
- URL： 原仓库地址（例如 https://github.com/YYsuni/2025-blog-public.git）

添加后，你将拥有：

origin： 你自己的仓库
upstream： 原作者的仓库

三、检查 upstream 是否有更新

在 GitHub Desktop 主界面：

点击左上角 Fetch origin
当 upstream/main 有更新时，你会看到更新提示

这时就可以开始同步流程。

四、合并 upstream/main 到你的 main

操作步骤：

菜单栏 Branch → Merge into current branch
在弹出的列表中选择：
```
upstream/main
```
GitHub Desktop 会提示：

There will be X conflicted files when merging upstream/main into main
点击 Create a merge commit 继续

GitHub Desktop 将开始合并操作。若没有冲突，会直接合并成功；若有冲突，则进入下一步。

五、解决冲突（Conflict Resolution）

当出现冲突时，GitHub Desktop 会显示红色提示，并展示冲突文件列表。

点击：

Open in Visual Studio Code

即可打开冲突文件。文件中会出现标准冲突标记：

<<<<<<< HEAD
你的改动
=======
上游的新内容
>>>>>>> upstream/main

你需要：

根据情况选择保留内容
或者将两者合并
删除所有冲突标记（<<<<<<<、=======、>>>>>>>）

保存后回到 GitHub Desktop。

六、完成合并并推送到 GitHub

回到 GitHub Desktop：

冲突文件会显示为已解决（绿色 ✔）
点击 Commit merge 提交此次合并
最后点击右上角 Push origin 推送到你的仓库

此时 GitHub 页面将显示：

This branch is ahead of upstream/main
This branch is not behind the upstream

表示同步完成。

七、“ahead X commits” 是否会影响后续同步？

不会影响。

“ahead X commits” 的含义是：

相比上游，你的仓库多了 X 次提交
多出来的通常是：文章更新、配置变更、GitHub App 自动提交等

这是完全正常的，不会影响：

同步 upstream
Vercel 构建部署
仓库使用

真正会导致冲突的是：你改动了与 upstream 相同的代码位置，与提交次数无关。

因此：

ahead 10 次正常，ahead 100 次也完全没有问题。

八、同步流程一键总结

以后每次同步只需要按下面流程：

Fetch origin
Merge upstream/main → main
有冲突 → 用 VS Code 解决
Commit merge
Push origin
Vercel 自动部署

完成！你就成功同步 upstream 最新代码，同时保留了自己全部的提交与内容。

九、总结

GitHub Desktop 提供了非常友好的 UI，让 fork 同步变得简单直观。通过本文，你可以：

正确添加 upstream
及时获取上游更新
处理冲突
保留自己的所有提交
保持 fork 与 upstream 始终同步

Trancy：开启您的 AI 语言学习新纪元

2025-11-02T14:12:58Z

在全球化日益深入的今天，掌握多门语言已成为个人与职业发展的重要助力。然而，传统的语言学习方式往往枯燥低效，难以持久。Trancy应运而生，以其创新的AI技术为核心，为用户提供沉浸式、个性化的语言学习体验，让语言学习变得轻松而高效。

沉浸式AI语言学习平台

Trancy不仅支持YouTube、Netflix等主流视频平台的双语字幕生成，还集成了网页内容AI翻译、全文翻译等强大功能，帮助用户将任意内容转化为量身定制的学习材料。无论您是语言初学者还是进阶学习者，Trancy都能助您快速提升听、说、读、写全方位能力。

INFO

Trancy支持多达10种语言的学习，涵盖英语、日语、西班牙语等主流语种，助力用户开拓国际视野。

核心功能详解

YouTube/Netflix AI双语字幕

通过Trancy，用户可在YouTube、Netflix、HBO Max、TED、edX、Coursera等平台观看视频时，实时生成准确的双语字幕。剧院模式与阅读模式自由切换，全面助力口语与听力练习。

TIP

字幕阅读模式将视频缩小至一侧，以文本形式突出显示字幕，便于用户专注理解句子上下文并快速掌握视频概要。

AI查词：依托OpenAI技术，深度解析单词释义与用法。
AI语法分析：智能拆解复杂句子结构，把握核心短语。
智能断句：基于NLP技术，将杂乱字幕重组为完整句子，提升翻译准确性。
听说练习：每日通过视频坚持听说训练，趣味与效率兼得。

网页AI划词翻译

Trancy的网页划词翻译支持多语种互译、全文翻译及词句收藏功能，极大提升外文阅读效率。

句子翻译：一键翻译整句，突破单词翻译局限，便于理解文章整体含义。
单词翻译：划词即译，无需跳转页面，生词可随时加入单词本备查。
AI句子结构分析：解析疑难句式，深入理解语法逻辑。
AI词性标注：基于智能断句，标记关键词词性（如形容词等）。
生词高亮：浏览网页时自动高亮陌生词汇，实现被动记忆。

全文沉浸式翻译

Trancy的上下文对照翻译打破信息壁垒，让用户无缝探索更广阔的知识世界。

双语网页阅读：无需离开当前页面，直观对比原文与译文，提升理解与翻译准确度。
快速段落翻译：通过鼠标悬停或快捷键，即时获取段落翻译，实现高效无干扰阅读。
自定义翻译引擎：支持Google、DeepL、Microsoft、Open AI等多种引擎，按需选择。
多网站兼容：针对Twitter等新闻网站、技术论坛、社交平台进行定制化优化。

个性化学习中心

Trancy提供强大的学习中心功能，帮助用户系统化管理学习进度与内容。

稍后观看：收藏喜爱的视频，集中复习与分享，与好友共学。
真实例句库：保存常用句子，应用于实际语言交流。
自定义学习主题：聚焦感兴趣的话题与语言，个性化定制学习计划。
多端同步：基于网页的学习中心，支持随时随地按需学习。

IMPORTANT

用户可通过Trancy学习中心快速开启个性化语言学习之旅。

进阶功能一览

Trancy持续迭代，提供更多专业工具以优化学习体验：

倍速播放：调整视频语速，辅助理解与练习。
单词高亮：从字幕中提取生词并高亮标记，便于复习。
字体调整：自定义字幕大小与样式，提升可读性。
拟真语音合成：通过自然语音改善发音与口语技能。
外部词典集成：接入专业词典，获取详细词汇解释。
快捷键支持：全功能键盘快捷键，操作如飞。
OpenAI句法分析：基于AI与自然语言处理技术，提供详细句法解析。
语音识别：利用语音识别技术提升听力与发音水平。

Trancy以AI技术为基石，将语言学习融入日常娱乐与阅读，真正实现了“学以致用”。无论您是学生、职场人士还是语言爱好者，Trancy都是您理想的语言学习伴侣。立即访问Trancy官网开启您的多语之旅！

什么是模型上下文协议（MCP）？

2025-11-01T13:38:21Z

MCP（Model Context Protocol，模型上下文协议）是一个用于连接AI应用与外部系统的开源标准。

通过MCP，像Claude或ChatGPT这样的AI应用可以连接到数据源（如本地文件、数据库）、工具（如搜索引擎、计算器）和工作流（如专业化提示）——使它们能够访问关键信息并执行任务。

可以将MCP视为AI应用的USB-C端口。正如USB-C为连接电子设备提供了标准化方式，MCP为连接AI应用与外部系统提供了标准化方式。

MCP能够实现什么？

智能代理可以访问您的Google Calendar和Notion，充当更个性化的AI助手。
Claude Code可以使用Figma设计生成完整的Web应用程序。
企业聊天机器人可以连接组织内的多个数据库，使用户能够通过聊天分析数据。
AI模型可以在Blender上创建3D设计，并使用3D打印机将其打印出来。

为什么MCP很重要？

根据您在生态系统中的位置，MCP可以带来多方面的益处。

开发者：MCP减少了构建或集成AI应用或智能代理时的开发时间和复杂性。
AI应用或智能代理：MCP提供了对数据源、工具和应用程序生态系统的访问，这将增强能力并改善最终用户体验。
最终用户：MCP带来更强大的AI应用或智能代理，它们可以访问您的数据并在必要时代表您执行操作。

Seedream MCP：把 AI 图像生成带到你的对话核心

2025-10-31T09:45:24Z

用一句自然语言，在你熟悉的对话式工作台里完成文生图、图生图、多图融合与组图生成；结果自动保存到本地，并一键生成 Markdown 引用。

为什么是现在、为什么是 Seedream MCP

做创作或开发的这几年，我一直在不同工具之间来回切换：写完提示词要去平台生成，复制临时 URL 回到文档，再手动下载、改名、归档。链接 24 小时过期、素材找不到、版本管理混乱……这些都在消耗创作力。

Seedream MCP 正是为了解决这些真实痛点而生。它基于 Model Context Protocol（MCP）标准，天然适配支持 MCP 的客户端（如一些对话式 IDE / 助手），把强大的 Doubao·Seedream 4.0 图像生成能力"搬进"你的日常对话与编辑环境里：

在同一个窗口里完成 文生图、图生图、多图融合、组图生成；
生成后 自动下载并按日期/工具分类保存到本地，杜绝临时 URL 过期；
自动产出 Markdown 引用，即拿即用；
遵循 MCP 标准，与支持 MCP 的工具生态即插即用。

这不是再造一个平台，而是让你 少切换、更专注。

它具体能做什么

1）文生图：把你的创意一句话"落地"为高质量图片，支持 1K/2K/4K 尺寸与水印开关。

2）图生图：用一张参考图 + 指令，快速得到风格化或结构保真的新图。

3）多图融合：把 2–5 张参考图的特征"熔炼"为一个全新画面，适合品牌氛围、概念探索。

4）组图生成：一次生成一组内容关联的图像序列，利好选题封面、活动 KV、故事板草图。

加分项：

自动保存与本地归档：生成后即刻落地到你设定的目录，智能命名、按日期/工具分类，省掉手工整理。
Markdown 引用就绪：自动返回本地图片的引用代码块，写文档/发帖不再反复上传。
稳健的错误处理：网络抖动、超时、配额异常等都有友好的回退策略与日志记录。

谁会爱上它

品牌与电商：快速试错素材、A/B 多版本主图、活动 KV 方向探索。
产品与视觉团队：在需求对话中直接"打样"，把灵感即时可视化。
内容创作者与媒体：文章配图、系列封面、栏目视觉一次成套产出。
教育/科研/社团：教案插图、海报草图、活动物料的快速生成与复用。

工作流长这样

在支持 MCP 的客户端里启用 Seedream MCP；
绑定你的火山引擎 ARK API Key；
直接对它说你想要的画面（或给它一张参考图）。

示例提示（只为说明用法，实际可自由发挥）：

多图融合：

"将三张品牌素材融合为统一海报风格，主色保留蓝金，质感更现代。"

文生图：

"暮色中的港口城市，霓虹与海雾交织，远处船只出航，2K，无水印。"

生成完成后，你会同时得到：在线预览 URL + 本地保存路径 + Markdown 引用。该贴该发，该存该用。

与你现有栈的关系

不替代你现有的创作平台，而是把"最后一公里"接到你的对话工作流里；
不强绑客户端，MCP 标准意味着更好的可移植性与互操作性；
不干扰团队协作，自动保存与统一命名让素材管理更可控。

常见问答

Q：需要准备什么？

A：一枚有效的火山引擎 Doubao·Seedream 4.0 API Key（ARK），以及一个支持 MCP 的客户端。

Q：尺寸与水印能调吗？

A：支持按需选择 1K/2K/4K，并可开关水印。

Q：本地保存如何组织？

A：默认按日期与工具类型分类，文件名包含时间戳与内容哈希，方便检索与版本管理。

Q：安全性如何？

A：你自持 API Key，生成结果直接保存到本地指定目录；同时提供详细日志，便于审计与排错。

现在就试试

仓库地址（Star 一下以示鼓励）：

GitHub - tengmmvp/Seedream_MCP: Seedream 4.0 MCP（即梦生图MCP）

也欢迎你在 Issue 中提出想法与需求，我会持续改进体验与文档。如果你愿意共建插件与工作流模板，也非常期待合作。

Seedream MCP 让"想法 → 画面"的路径变短，把注意力还给创作本身。今天，就在你的对话框里，开始产出下一张满意的图吧。