用Python构建可控的Stable Diffusion AI绘画工作流:从批量出图到提示词工程

1. 为什么要自己搭一套可控的AI绘画工作流

1.1 从“生成一张图”到“批量出图并筛选”

很多人接触到AI绘画的第一步,是在某个网页或聊天机器人里敲一句描述,等几秒拿到一张图。这个流程对尝鲜足够,但对真正想用AI绘画做内容生产、设计初稿、插画探索的人来说,远远不够。真正动手用Python把Stable Diffusion组织成一套工作流之后,你会发现核心竞争力根本不是“能画图”,而是“能系统地画出你想要的那一类图”。

我一开始也是从现成的WebUI界面入手,玩了一段时间之后发现几个痛点:一是出图参数每次都要手调,重复劳动太多;二是想批量尝试几十个提示词变体,靠鼠标点简直折磨;三是生成结果和后续处理(比如批量压缩、二次筛选、按关键词归档)完全脱节。这些问题靠现成工具很难优雅解决,但用Python把它们串联起来之后,整个使用体验发生了质变。

这篇文章不是教你运行某个现成的开源界面,而是从工程师的视角,把Stable Diffusion当成一个“绘画引擎”,用代码去调度它,搭出一套可以反复迭代、批量产出、自动整理的AI绘画流水线。适合那些已经玩过文生图、想更进一步做自动化产出的人,也适合想理解AI绘画底层调用逻辑的开发者。

1.2 现成工具和自建流程之间,差的是“过程”

有人会问:WebUI不好用吗?ComfyUI不是已经支持节点式流程了吗?说实话,现成工具在单次生成和可视化调参上做得非常好,尤其是节点式工作流,确实把很多复杂逻辑可视化了。但我的实践感受是,当你的需求从“画一张好图”变成“每天生成几百张候选图、自动打标、按评分归档、定期更新提示词库”的时候,代码的灵活性是图形界面很难给的。

代码工作流的好处有三点:

  • 可复现:所有参数、提示词、随机种子都写在脚本里,一次调好,之后随时重现完全相同的结果。
  • 可批量:循环遍历提示词组合、遍历风格关键词、遍历采样参数,用代码做网格搜索,一次性产出几十上百张图,再统一筛选。
  • 可集成:生成结果可以自动接入图像处理、OCR打标、文件重命名、甚至训练数据集准备等后续环节。

这不意味着要抛弃现成工具,而是把“探索期”和“生产期”分开:探索期用可视化界面找感觉,生产期用Python脚本批量干活。后面我会详细讲我在这个过程中的选型思路和具体实现。

2. 核心选型:Stable Diffusion的接入方式和运行环境准备

2.1 本地推理和API调用怎么选

要搭Python工作流,第一步是决定Stable Diffusion模型跑在哪里。目前主流方式无非两种:本地运行推理,或者调用云端的推理接口。

我自己的实践路径是两套都试过,最终根据场景分流。对于需要严格保护内容隐私、需要高频调试参数的项目,我倾向于本地跑;对于临时需求、显存不够的机器、或者需要快速验证思路的场景,就走API。

两种方式的对比可以看下面这张表:

对比项本地运行推理调用云端API
硬件门槛需要独立显卡,显存至少6GB起步只要网络稳定,普通电脑即可
出图速度取决于显卡型号,中等以上显卡较快受网络延迟和服务排队影响
隐私性模型和数据都在本地,完全可控图片和提示词会经过服务端
调试灵活性可以改底层逻辑,自由控制每一步只能在接口允许的参数范围内操作
综合成本电费和硬件成本,长期使用更低按量计费,轻量使用更划算

如果你手里的显卡是8GB以上显存,真诚建议本地先跑通,因为调试过程中的自由度差距真的很大。后面涉及的一些高级玩法,比如临时修改采样过程中的中间结果,本地方案才能做到。

2.2 Python环境与依赖管理的几个细节

Python环境这件事,看起来简单,实际操作中翻车概率最高的地方之一。我建议直接用虚拟环境加依赖锁定文件的方式管理。

我习惯用venv或者conda创建一个独立的Python 3.10环境,然后安装diffusers库以及配套的transformers、accelerate、safetensors。这里有个关键点:不同版本的diffusers对应不同的模型读取方式,如果模型卡在某个旧格式上,可能需要额外的兼容层。

装完基础依赖之后,我一般会做一次验证性的小推理,输出一张64x64的小图,确认整条链路是通的,再开始写正式工作流。这一步虽然土,但能帮你把“环境问题”和“代码问题”区分开,排查起来会轻松很多。

另外,显存管理也要提前规划。Windows系统下PyTorch默认会预留一部分显存,容易造成“明明显存还有富余却报OOM”的假象。可以通过环境变量或者PyTorch的显存优化选项来控制显存分配策略,比如开启内存高效注意力机制,显存占用能大幅下降。

3. 把绘画流程拆解成Python代码:从文生图到批量调度

3.1 一次文生图调用的最小代码骨架

在Python里调用本地Stable Diffusion模型,最核心的逻辑其实就几件事:加载模型、组装提示词、设置采样参数、执行生成、保存结果。下面这个骨架代码是我日常使用的起点:

import torch from diffusers import StableDiffusionPipeline pipe = StableDiffusionPipeline.from_pretrained( "本地或在线模型路径", torch_dtype=torch.float16, safety_checker=None, # 按需关闭或保留 ) pipe = pipe.to("cuda") prompt = "a quiet library at night, warm lighting, highly detailed" negative_prompt = "blurry, low quality, watermark" image = pipe( prompt=prompt, negative_prompt=negative_prompt, width=512, height=512, num_inference_steps=25, guidance_scale=7.5, generator=torch.Generator("cuda").manual_seed(42), ).images[0] image.save("output.png")

这段代码看起来简单,但每个参数都有讲究。guidance_scale控制的是“提示词对画面的约束力”,调太高画面会僵硬、过饱和,调太低画面会自由散漫、偏离描述。在我的经验里,7到8是大多数Prompt的甜区,但特定风格可能需要到12以上。

num_inference_steps影响生成质量和耗时,通常20到30步就能达到不错的效果,强行拉高到50步以上收益递减明显。这个参数和采样器是联动的,不同采样器收敛速度不一样,后面细说。

3.2 采样器选择对出图风格的真实影响

很多人忽略采样器的作用,觉得“反正都是去噪”。实际用下来,采样器对画面的影响非常明显,尤其是在同样的提示词和步数下,不同采样器会带来完全不同的纹理和细节倾向。

我常用的是DPM++ 2M Karras,它的特点是细节丰富、收敛快,适合绝大多数写实和插画场景。如果追求更柔和的画面过渡,Euler a也不错,缺点是容易丢失部分锐利细节。做像素风或者扁平插画的时候,DDIM反而有奇效,因为它的采样轨迹更稳定,不容易出现额外纹理。

我的建议是,在批量生成之前先花一下午做“采样器对比测试”:固定提示词、种子、步数,只切换采样器,把结果拼在一张图里看。这个过程很耗时,但做完之后你对风格控制的直觉会强很多,以后再选采样器就不再靠猜。

3.3 批量生成的并发控制与显存调度

批量化生成是工作流的核心优势,但不能无脑循环。显存是硬约束,尤其是连续生成时,前一张图的中间过程还未完全释放,下一张图又申请显存,很容易爆。这里有两个实用策略:串行分批和重复使用Pipeline对象。

串行分批的做法是,把要生成的图像列表切成小批次,每次生成若干张,然后强制让显存回收一下再继续。做法如下:

for batch_start in range(0, len(prompts), batch_size): batch = prompts[batch_start:batch_start + batch_size] for idx, prompt in enumerate(batch): image = pipe(prompt=prompt, ...) image.save(f"output_{batch_start}_{idx}.png") torch.cuda.empty_cache()

注意torch.cuda.empty_cache()不要放在每一张图生成之后立即调用,否则频繁的显存清理会拖慢整体速度。放在一个批次结束之后比较合理。

另一个容易犯的错是每次循环都重新加载一次模型。模型加载是非常重的操作,加载一次可能要十几秒甚至几十秒。正确的做法是启动时加载一次,循环里反复调用同一个Pipeline对象,只在必要时切换模型路径。如果你需要频繁切换不同模型,可以考虑用多进程分别常驻,但这涉及更复杂的工程调度,一般需求用不上。

4. 发散创新的核心实践:提示词工程与变体生产

4.1 提示词语法结构:从“一句话描述”到“结构化标签”

发散创新这个词,落在AI绘画上,核心就是“提示词的自由组合”。我的观察是,新手喜欢写一整句流畅的描述,比如“一个穿着红色连衣裙的女孩站在海边,夕阳西下,天空有很多云,画面很唯美”。这种做法不是不行,但可控性和组合性很差——你很难精确修改某一个方面而不影响整体。

我常用的做法是结构化标签式提示词,把画面拆成几个维度:

  • 主体:人物、物体、场景的明确描述
  • 环境:时间、天气、光线条件
  • 风格:媒介、画风、渲染方式
  • 质量词:高细节、杰作、8K

下面是我体系里的一个示例提示词:

subject = "a young astronaut standing in a field of tall grass" environment = "golden hour, warm sunlight, light wind" style = "cinematic lighting, photorealistic, 35mm film grain" quality = "highly detailed, sharp focus, masterpiece" negative = "blurry, lowres, oversaturated, deformed, watermark" prompt = ", ".join([subject, environment, style, quality])

把提示词拆成组件之后,发散创新的玩法就打开了。你可以只替换style部分,保持主体和环境不变,批量生成同一场景下不同画风的版本;也可以只替换subject,测试同一个环境对不同主体的适配度。

4.2 批量变体生成:用代码展开创意空间

我在实践中最常用的是“网格化变体生成”。假设我有3个主体关键词、3种风格、3种光照环境,常规手动操作要生成27张图才能覆盖所有组合。有了Python循环,这项工作就变成了一次脚本运行。

更进一步的玩法是引入随机性。每次生成时,从每个维度的候选词库里随机抽取一个组合,同时种子的随机性也放开,这样能稳定地产出多样性极强的候选图池。之后再由人或者程序进行筛选。

我写过一个组合生成器,核心逻辑大概是这样:

import itertools import random subjects = ["a fox", "a robot", "a lighthouse", "a vintage car"] environments = ["misty forest", "rainy street", "desert at dusk"] styles = ["watercolor", "cyberpunk", "studio photography"] for combo in itertools.product(subjects, environments, styles): prompt = f"{combo[0]}, {combo[1]}, {combo[2]}, highly detailed" print(prompt)

这段代码会输出12种组合,每种组合都可以作为一次独立的生成任务。如果再加上随机权重,可以进一步探索“意外之喜”,这是发散创新的核心乐趣。

不过这里我要提醒一句:批量生成出来的图片,真正能用的比例通常不高,10张里出1到2张满意的就算不错。所以筛选和归档流程一定要提前设计好,否则图片文件夹很快就会变成一团乱麻。

4.3 图生图与局部重绘:从单张图片发散出系列

文生图只是基础,真正让创作爆发式扩展的是图生图和局部重绘。图生图的原理是把一张参考图作为起始噪声的引导,让生成结果在保留原图结构的同时,按照新提示词演化。

我经常做的事是,先用文生图批量生成一批候选,挑出最满意的一张,然后用图生图功能结合不同风格提示词,把这张图“重新演绎”成不同版本。这样做的好处是构图和主体形态被保住了,但色彩、画风、细节在变化,产出的系列作品既有统一感又有差异度。

局部重绘则是更精细的玩法,它可以只对画面中的某个区域重新生成。比如我对一张人像的构图满意,但觉得背景太杂乱,就通过图像处理工具生成蒙版,把背景区域标记出来,再让模型只重绘蒙版区域。

用Python做局部重绘,需要同时传入原图、蒙版图、提示词和重绘区域参数。核心逻辑是:

from diffusers import StableDiffusionInpaintPipeline pipe = StableDiffusionInpaintPipeline.from_pretrained(...) image = pipe( prompt="background with snowy mountains", image=original_img, mask_image=mask_img, height=512, width=512, ).images[0]

注意蒙版图必须是单通道或者RGB格式的二值图,白色区域是重绘区,黑色区域是保留区。刚开始做蒙版时,我因为通道格式不对,折腾了挺久,这个细节容易踩坑。

5. 出图之后:画质提升、筛选归档与重复劳动自动化

5.1 放大与后处理:模型出图只是起点

Stable Diffusion直接输出的512x512或768x768图,放在社交媒体上尚可,但要做印刷、做海报或者高质量展示,分辨率通常不够。最常用的方案是结合放大算法做超分,然后再做一次“二次修复”。

我的后处理流程分三步:先做图像放大,再做轻微锐化,最后统一转成目标格式和色彩空间。放大这一步可以用独立的超分模型,也可以用Stable Diffusion自带的放大技术,后者效果通常更好,但耗时更长、显存占用更大。

在Python里写后处理脚本,我习惯用图像处理库配合超分模型一起用,先对图像做预处理,比如降噪、对比度拉伸,再喂给放大模型。需要提醒的是,放大倍数不建议一口气拉到4倍以上,容易出现伪影和塑料感。稳妥做法是分两次,2倍加2倍,中间做一次质量校验。

5.2 筛选策略:批量图片不可能一张张人工看

批量生成之后,最大的痛点不是生成而是筛选。我自己走过弯路:生成的图片全丢在一个文件夹里,命名也不规范,筛选的时候只能靠眼睛一张张看,效率低到让人崩溃。

后来我设计了一套简单的筛选工作流:首先在生成阶段就按种子_风格_主体_序号的格式命名文件,这样看到文件名就能知道图片的生成参数;其次把“满意”和“保留”分开目录,筛选过程中用快捷键移动文件;最后定期归档,把有潜力的底图放进素材库,其余清空。

还可以更进一步,用图像相似度算法做初步去重。批量变体生成时,很多图片视觉上非常接近,人工对比很费眼神。我写了一个脚本,基于感知哈希算法计算图片间的相似度,超过阈值就自动标记重复,大大减少人工筛选的量。

5.3 提示词库与参数记录:让创作经验可积累

发散创新最大的敌人是“遗忘”。今天调出来的好参数,如果不记录下来,过两周再想复现可能就得从头试。我强烈建议把提示词和参数当成代码一样做版本管理。

我的做法是把提示词拆成基础词库和风格词库,放到结构化配置里统一管理。每次批量生成时,脚本会把所有参数自动写进一个日志文件,包含提示词、负面词、种子、分辨率、采样器、步数等等。这些日志既是复盘素材,也是后续优化工作流的依据。

如果生成结果里有什么惊喜发现,我会顺手把对应的提示词组合抽出来,补充进词库。这个做法的好处是,你的“创意资产”会随着使用次数增多而指数级变厚,而不是每次从零开始摸索。

6. 把工作流扩展成更复杂的应用场景

6.1 从单机脚本到多进程并行出图

当单块显卡已经满足不了批量生成的速度需求时,下一步就是横向扩展。手头有两三块显卡的机器,可以按显卡拆任务,每张卡跑一个独立的Python进程,处理不同的提示词集合。

需要注意设备号和显存分配不能冲突。我在一个4卡服务器上做过测试:每张卡分配一个进程,每个进程加载自己的模型实例,总共4路并行,吞吐量几乎是单卡的3.8倍,显存调度得当的话,这个扩展效率已经很可观。

多进程并行的另一个优势是容错。单个进程崩溃不会拖垮整批任务,只需要重启那一路的进程并跳过已完成部分。做大量生成任务时,这个可靠性比速度本身更重要。

6.2 与外部系统的联动:自动出图、自动发布

工作流一旦代码化,就有无限的外部串联可能。比如内容运营场景,可以从数据库读取一批主题关键词,自动生成对应的配图,再通过接口自动发布;或者做设计前的灵感探索,从需求文档里抽取关键词,自动生成风格参考图,供团队内部评审。

我自己做过的一个小工具,是把电视脚本里的标题和场景描述自动转成提示词,批量生成分镜参考图。虽然效果不能当最终画面用,但作为沟通工具比纯文字描述高效太多。这个功能的代码逻辑并不复杂,核心就是把文本解析和生成脚本串起来。

6.3 训练自己的风格模型:工作流进阶方向

当积累了一定量的优质生成图之后,可以考虑更进阶的玩法:用自己产出的图集去做风格模型的微调,让模型学会专属的画风。这一步需要一定的数据清洗能力,适合已经工作流成熟、图片产出稳定的阶段。

数据清洗要注意两点:一是图片风格必须高度统一,否则模型会学得四不像;二是配上干净准确的提示词,文本和图像的配对质量直接决定微调效果。我并不是每次都需要做微调,但手头攒了几千张优质图之后,训练一个专属风格模型,画风统一度确实有质的提升。

7. 我踩过的坑和一些实在建议

7.1 那些“调了一整天”的黑盒问题

这个过程中我遇到最多的问题集中在模型加载和显存管理上。比如加载自定义模型时,偶尔会遇到结构不兼容的报错,解决方案往往不是找新版本依赖,而是检查模型文件和版本之间的匹配关系。

显存问题是另一个常客。我在生成过程中出现过“显存明明够却OOM”的情况,尝试了各种优化后才意识到是碎片的逐步膨胀,单独执行一个生成任务没问题,循环生成几十张之后就会陆续累积。处理办法是定期执行显存回收并重置整个Pipeline对象,虽然速度会有短暂下降,但稳定性提升了非常多。

还有一类问题是结果不可复现。同样的提示词、同样的种子,换了不同的diffusers版本之后,生成结果居然不一样。这是浮点数运算和采样器实现细节导致的版本差异。如果你是做严谨对比实验的,建议锁死依赖版本,不要随意升级。

7.2 给刚开始搭工作流的人三条建议

先小后大。不要一开始就追求完美的大平台方案,先把“一张图生成并保存”的最小闭环跑通,再逐步添加批量、筛选、后处理模块。

多做对比实验。提示词的调整、参数的选择,靠看的直觉远远不够,保留对比图是最直观的经验积累方式。

给文件起好名字。看似不起眼,但良好的命名规范会在批量筛选和复盘时节省大量时间。

7.3 我的个人体会:AI绘画工作是“筛选的艺术”

用Python驱动Stable Diffusion工作流这么久,我最大的体会是:AI绘画不是设计的终点,而是灵感的放大器。它真正改变的不是“画出最终作品”的能力,而是以低成本把创意空间展开、用大量视觉预览辅助决策的能力。

对创作者而言,最有价值的不是某一张“神图”,而是那一整套能够持续生成、筛选、迭代的系统思维。把灵感变成程序里的参数组合,再用批量出图去验证,这个过程本身就是当下创作方式里特别吸引人的地方。

如果你也准备动手搭自己的第一套AI绘画工作流,别想太多,先跑通一张图。之后每往前推进一步,都像是在打通一条专属于你的创意管道。

相关新闻

Spring Boot GraalVM原生镜像容器化实战:启动提速与内存优化

Spring Boot GraalVM原生镜像容器化实战:启动提速与内存优化

凡是维护过 Java 系服务的人,应该都对 Spring Boot 打包进容器这件事有一肚子话想说:镜像动不动几百 MB,部署一台实例 JVM 先吃 300MB 内存,启动要等好几秒,还有 JIT 预热那段时间接口表现飘忽不定。这些年在做容器化的…

2026/10/20 19:07:06 阅读更多 →
HG680-LC/LY/LV线刷救砖全教程:Hi3798MV310短接与HiTool烧录实战

HG680-LC/LY/LV线刷救砖全教程:Hi3798MV310短接与HiTool烧录实战

手里那台HG680-LC刷完某个“精简优化包”之后,第二天开机就卡在开机LOGO上,指示灯有规律地闪,电视却始终没有画面。当时第一反应是完蛋了,后来拆开主板确认SoC是Hi3798MV310,心里反而踏实下来——这类芯片方案的盒子有…

2026/10/20 19:07:06 阅读更多 →
测试工程师面试必问:30个Linux命令实战详解与排查思路

测试工程师面试必问:30个Linux命令实战详解与排查思路

面试测试工程师,如果面试官只让你准备一个技术点,那我建议押 Linux 命令。原因很朴素:不管是环境部署、日志排查、接口验证还是性能定位,Linux 都是绕不开的底层操作环境。你平时写用例、点界面,真到排查线上 bug&…

2026/10/20 19:07:06 阅读更多 →

最新新闻

模型量化如何影响推理性能?实战解析原理、选型与问题排查

模型量化如何影响推理性能?实战解析原理、选型与问题排查

在AI推理优化这条路上,量化是我见过投入产出比最高的手段。很多人以为量化就是把模型从FP32变成INT8,体积缩小、推理变快,但实操后才发现,AI模型量化对推理性能的影响并不只有正向:有时速度反而下降,精度却…

2026/10/20 20:20:51 阅读更多 →
基于Simulink的23自由度分布式电驱动整车动力学模型搭建与仿真

基于Simulink的23自由度分布式电驱动整车动力学模型搭建与仿真

做分布式电驱动车辆的控制,最头疼的问题就是你手上的整车模型到底该建多细。我这次在Matlab Simulink里完整搭了一套23自由度整车动力学模型,把车身六个方向的运动、四个车轮的垂向跳动、车轮旋转、转向系统、以及分布式驱动链条的扭转自由度全部拉进来了…

2026/10/20 20:20:51 阅读更多 →
用JSON和Python命令行构建个人技能管理工具:从数据建模到实践

用JSON和Python命令行构建个人技能管理工具:从数据建模到实践

1. 为什么需要技能管理工具:需求拆解与设计取舍上周末想更新简历,结果发现我根本说不清“现在到底会什么”。十几项技能分散在旧简历、脑图、收藏夹和一摞笔记本里,有的早已过期,有的只停留在“看过教程”的阶段,还有的…

2026/10/20 20:20:51 阅读更多 →
企业微信回调验证与AES加解密:.NET开发者接入指南

企业微信回调验证与AES加解密:.NET开发者接入指南

接手过几个企业微信自建应用的项目,每次新人对接时几乎都会卡在同一个地方:管理后台保存“接收消息服务器”配置时提示URL验证失败,或者明明验证过了,消息却一直推送不进来。这个环节看着只是填几个参数,背后实际上是一…

2026/10/20 20:20:51 阅读更多 →
vLLM Prefix Caching 原理:如何用 Paged KV 消除重复计算

vLLM Prefix Caching 原理:如何用 Paged KV 消除重复计算

先说一个我遇到过的情况。某个线上推理服务,所有请求都带着同一段两千多字的 system prompt,并发一上来,GPU 利用率看着很高,但真正对用户有用的计算没多少——大部分算力在一遍遍重复计算同一段内容的 K 和 V。很长一段时间里&am…

2026/10/20 20:20:51 阅读更多 →
用Design.md构建符合产品风格的原型设计:设计令牌实战指南

用Design.md构建符合产品风格的原型设计:设计令牌实战指南

上周跟某团队聊原型评审,对方把三个页面的设计稿拍在我面前,主色蓝就出现了五种,没有两个颜色值相同。评审会开了一个小时,快一半时间在争论“这个蓝到底是不是我们品牌那个蓝”。原型阶段最让人心累的从来不是画得快不快&#xf…

2026/10/20 20:19:47 阅读更多 →

日新闻

CLRC663芯片Pin-to-Pin替代实战:从评估到量产全记录

CLRC663芯片Pin-to-Pin替代实战:从评估到量产全记录

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/20 1:01:30 阅读更多 →
ESP32舵机控制指南:原理、多路驱动与避坑实战

ESP32舵机控制指南:原理、多路驱动与避坑实战

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/20 1:01:30 阅读更多 →
位移法实现一阶低通滤波:单片机ADC采样降噪实战

位移法实现一阶低通滤波:单片机ADC采样降噪实战

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/20 1:01:30 阅读更多 →

周新闻

基于GMM的语音识别系统原理与MATLAB实现详解

基于GMM的语音识别系统原理与MATLAB实现详解

说到基于高斯混合模型(GMM)的语音识别系统,很多人第一反应就是一堆数学公式,觉得门槛很高。但如果你真的在MATLAB里把它落地跑通,会发现核心其实就是三件事:把声音变成特征向量,用GMM给每个类别…

2026/10/20 10:02:13 阅读更多 →
数字图像处理入门:反白、灰度化、调色板修改与导出txt实践

数字图像处理入门:反白、灰度化、调色板修改与导出txt实践

数字图像处理这四个字听起来挺唬人,但落到具体操作上,无非就是让计算机按你的想法“摆弄”像素。我在一个模拟项目X里用了一套特别经典的基础处理流程:对图像做反白、改调色板、彩色转灰度,最后把像素数据导出成txt文件。单看每一…

2026/10/19 17:32:41 阅读更多 →
机器人大脑技术盘点:具身智能的感知、决策与数据闭环

机器人大脑技术盘点:具身智能的感知、决策与数据闭环

如果你的信息流最近也天天刷到“机器人大脑”这个词,你会发现一个很有意思的现象:每个人说的“大脑”根本不是同一个东西。有人指的是大语言模型,有人指的是运动控制系统,还有人指的是能理解物理世界的端到端模型。在2026年这个时…

2026/10/20 2:50:50 阅读更多 →

月新闻

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/20 10:02:08 阅读更多 →
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/20 9:50:17 阅读更多 →
黑夜航拍船只数据集训练YOLOV5模型全流程解析

黑夜航拍船只数据集训练YOLOV5模型全流程解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/20 9:50:45 阅读更多 →